Website relaunch without losing rankings: planning, redirects and monitoring

Imagine a service business whose website was built eight years ago. Since then, three people have added content, a blog was started and neglected again, and individual service pages were copied and slightly altered. The site looks dated, loads slowly and is cumbersome to use on a smartphone. The relaunch has been decided.

What is usually missing is a picture of what the old site actually achieves. Everyone knows the home page. But which of the four hundred addresses bring visitors, which are linked to from other websites, which have been sitting unseen in the index for years? Without that answer, every decision about the new structure is a gamble.

The worry about losses is justified. For search engines, a relaunch is not a cosmetic update but a rebuild of the foundation: addresses change, texts are shortened, navigation and internal linking are created anew. After go-live, Google in principle evaluates a new website that is supposed to pick up the history of the old one.

The causes are rarely exotic. Most often, redirects are missing: the new site has different addresses, and the old ones lead nowhere or land across the board on the home page. Google does not treat this as a move but as pages disappearing. The signals attached to those addresses fizzle out, as do the links from other websites pointing to them.

Almost as common is content that gets "tidied up" during the redesign. A text that has ranked on page one for a particular query for years is shortened because it looks too long in the new layout. Headings are rewritten in a more promotional tone, and the search term people actually search for disappears.

Then there are technical errors that are only noticed after go-live: an index block from the staging environment that moved along with the site, a robots.txt that excludes everything, missing canonical tags, lost structured data, a sitemap with old addresses. None of these errors is hard to avoid. They happen when nobody keeps a list.

Before anything is redesigned, a reliable inventory is needed. It combines three sources, because each has blind spots on its own. A crawl, for example with Screaming Frog, delivers all reachable addresses along with status code, title, headings, canonical and internal linking. It shows what the site is technically.

Search Console shows what Google makes of it: which pages receive impressions and clicks, for which queries, at which position. This often reveals that a few pages carry most of the visibility and seemingly unimportant subpages quietly deliver enquiries. A period of at least twelve months smooths out seasonal fluctuation.

The third source is the backlink profile. Which addresses are linked to by other websites, directories or press sites? A page with little traffic but several high-quality links deserves more care than its traffic suggests. The Search Console reports are enough for this, supplemented by a backlink tool of your choice.

The result is a table in which every known URL is listed with status code, clicks, impressions, referring links and main search query. It is the working document for everything that follows.

The content audit emerges from the inventory table. Each page gets one of four decisions. Keep: the page works, address and content stay. Revise: the topic holds up, but text or structure are weak. Merge: several similar pages compete for the same query and become one stronger page. Remove: the page no longer has a purpose.

Remove does not mean delete without a trace. For pages that disappear, too, a sensible destination is sought, usually the closest page by topic. If there is none, and the address has neither traffic nor links, a clean status code 410 or 404 is the more honest answer than a redirect to an unsuitable page. In our experience, Google treats a redirect to irrelevant content like a soft 404.

When it comes to whether the address structure should be changed at all, restraint pays. A new navigation or a new design does not need new URLs. Every address that can stay is one risk less. Change addresses only if the content management system forces it or the existing structure demonstrably causes problems.

URL mapping is the table that assigns every old address to exactly one new one. It sounds like grunt work, and it is, but this is where it is decided whether signals are carried over. Each row contains the old URL, the target URL, the desired status code and a note giving the reason. Where several old pages have been merged, several rows point to the same target.

The target should serve the same topic, not a loose thematic relation. An old page on "heating maintenance" belongs on the new maintenance page, not on a general overview of services. In addition, it is checked that the target URL itself responds with status 200 and does not redirect in turn.

This is where the danger of chains lies. If an earlier relaunch redirected address A to B, and the new B now goes to C, the result is A, B, C. Every intermediate step costs loading time and raises the risk that something breaks. The rule is: every old URL redirects in a single step directly to the final target. For that, the legacy of earlier redirects must also go into the table.

The standard for permanent moves is status code 301 (alternatively 308). Google has confirmed that a 302, too, passes on signals after some time, but a permanent move should also be marked as permanent.

Building takes place on a staging environment that must be invisible to search engines. The most reliable solution is access protection by password or IP restriction. A noindex directive is the second safeguard, but a robots.txt with Disallow alone is not enough, because blocked addresses can still show up in the index if they are linked. Moreover, Google cannot read a noindex if it is not allowed to fetch the page.

On staging, the work is then not just design but comparison. Titles, meta descriptions, main headings, canonical tags, hreflang (if multilingual) and structured data from the crawl of the old site are set against the new one. A diff report shows every deviation. Not every one is an error, but each should be a conscious decision.

For heading structure a simple rule applies: a page has exactly one H1 that carries the topic, with a comprehensible outline beneath it. New templates often use headings as a styling device and thereby destroy the structure. Internal links in the new system must also point to the new addresses, not to old ones that are only corrected via redirect.

Structured data, such as Organization, LocalBusiness, FAQPage or Article per schema.org, rarely migrates automatically. It is output anew in the new template and checked with the Rich Results Test.

Go-live is a sequence with fixed checkpoints, not a push of a button. The day before, the mapping table is ready as redirect rules in the server or system and has been tested against every old URL on staging. On the day itself, the new site is switched live first, then the index block is removed, then everything is checked. The order matters because no step replaces checking the previous one.

The block is especially critical. Password protection, noindex meta tag and X-Robots-Tag header must go, and robots.txt must not exclude anything that is meant to be indexed. Do not check this in the back end but at the real address: source code of the home page, response headers, robots.txt, URL Inspection in Search Console.

Afterwards the new XML sitemap with the final addresses is submitted, not the old one. Spot checks from the mapping confirm that redirects lead in one step to a 200 target. The most important pages are individually submitted for indexing in Search Console.

If the domain stays the same, the relaunch is a renovation within the same house. If it changes, for example because of a renaming, it is a move to a different house, and the risk is considerably higher. Besides URL mapping, redirects are then needed from the old domain to the new one, including for the variants with and without www and for http and https.

In Search Console, both domains are set up as properties, and the Change of Address tool is used for the old domain. The redirects should stay in place for at least a year, better longer, as long as links or users still reach the old address. Anyone who switches off the old domain early cuts off signals that are still on their way.

Other special cases include multilingual sites with hreflang, where every language version must point to the others correctly, parameter URLs and filter pages, media and PDF files that are linked externally, and subdomains. Embedded services and forms should be checked too, because some important source of enquiries may hang on an address nobody had on their radar.

Another stumbling block is the system change itself. New content management systems often create their own URL patterns, add or remove trailing slashes, convert addresses to lowercase or serve the same page under several paths. This produces duplicates that Google then has to laboriously consolidate. Decide in advance which spelling applies, and enforce it with redirects and canonical tags.

Content that is only generated in the browser via JavaScript also deserves a look. If the new system renders text and links only on the client side, a crawler may see very little on the first fetch. Comparing the source code with the rendered result, for example with the Search Console URL Inspection tool, quickly shows whether the essential content arrives reliably.

An honest recommendation: where possible, do not combine a domain change, a system change and a complete content overhaul in one step. The fewer variables change at the same time, the more clearly you can attribute fluctuations later.

There are no guarantees here, and anyone who promises them is promising too much. Google has to crawl the new structure again, follow the redirects and reassess the pages. In our experience, positions and clicks fluctuate in the first days and weeks, even when the work is done cleanly. That is normal and no reason to panic.

What matters is putting the movement into context. A slight up and down for individual search queries is something different from the collapse of entire groups of pages. The latter points to a specific problem that can be found in the data: an area that is not being indexed, a pattern of 404 errors, a faulty redirect rule.

Measurement relies on the Search Console reports: indexing status, crawl stats, 404 errors, clicks and impressions compared with the period before the relaunch. Server logs additionally show whether Googlebot is fetching the new addresses. You should allow several weeks to a few months until a stable picture emerges.

Faster load times, a clean structure and clearer content can lead to better visibility after the relaunch. No serious promises can be made about this, because competition and algorithms play a part.

The most important principle: a relaunch is a migration project with a design component, not the other way round. If you only involve SEO before go-live, all you can do is rescue. If you involve it at the start, you can shape what is preserved and align the page structure with what visitors find anyway.

Second: preserving is a legitimate strategy. Not every address, title and text has to be new. What works well in Google stays untouched for now. You can improve it later, in small steps, with a clean before-and-after comparison.

Third: documentation protects you. The mapping table, the crawl of the old site and the go-live checklist are not bureaucracy but the archive that lets you explain in three months why a page differs from before. Errors can then be narrowed down quickly instead of searching in a fog of speculation.

The fear of ranking losses is justified, but manageable. Most losses do not come from what is new but from what is lost unnoticed: addresses without a redirect, content that was deleted, blocks that stayed in place. There is a method for exactly this, consisting of inventory, mapping, staging comparison, checklist and monitoring.

That is why we would start such a relaunch with the inventory, before any layout exists. The result is a sober basis for decision-making: which pages carry weight and which do not, where a new structure makes sense and where a new look is enough. After that, we can honestly say how high the risk is.

A sensible next step is a short check of your existing website: crawl, Search Console analysis and an assessment of which pages deserve particular protection. This shows whether a relaunch is needed, to what extent and with what effort.