SEO for a website redesign: keeping what already ranks

A redesign is the most common way a business loses search traffic it spent years earning, and it happens quietly. The new site looks better, everyone is pleased, and a month later somebody notices the enquiries have thinned. By then the cause is a decision made during the build that nobody thought of as an SEO decision.

None of this is difficult. An SEO website redesign is a sequence, and the work sits before launch rather than after it. This is the order we run, and website migration SEO follows the same order when the platform or the domain changes as well.

What actually causes the drop

In our experience it is almost never the design. It is one of a short list of mechanical failures, and every one of them is preventable.

• URLs changed and nothing tells search engines where the old ones went
• Content was trimmed during the rebuild, so the page that used to answer a question no longer does
• The staging site's crawl blocking went live along with the design
• Internal links were rebuilt around a new menu, so pages that were well linked internally are now three clicks from anywhere
• Templates changed, taking titles, headings and structured data with them
• A new platform started producing several URLs for the same page, and none of them is declared canonical

Inventory first, and take it before anything is deleted

You cannot protect what you have not written down. Before the build starts, assemble one list of every URL on the current site with enough data attached to make decisions about it.

1. A full crawl of the current site, which gives you every URL, its title, its headings and its status code
2. Search Console data for pages and queries, which tells you what actually earns impressions and clicks rather than what you assume does
3. Analytics for landing pages, which tells you what gets visited and what converts once it does
4. A backlink export, because a page nobody visits may still be the one carrying links from other sites
5. The XML sitemap and the server logs if you can get them, which between them catch the URLs the other four missed

Join those into a single spreadsheet, one row per URL. Everything that follows is a decision written in a column of that sheet, which is also what makes it reviewable by somebody other than the person who built it.

Give every old URL a decision

Three outcomes, and each row gets exactly one. Keep, meaning the page survives at the same address or a new one. Merge, meaning its content joins a better page and the URL redirects there. Retire, meaning it goes and you have decided consciously what happens to anyone who arrives.

Merging is where judgement is required. Several thin pages about the same thing usually deserve to become one good page, and that is an improvement rather than a loss, provided the redirects point at it. What does not work is merging four pages into a category listing and hoping the relevance survives the move. A redirect to a page that does not answer the same question is treated by search engines much as a deletion is.

The redirect map, done properly

This is the single deliverable that decides whether a migration holds. It is a mapping from every old URL to one new URL, produced before launch, tested on staging, and deployed at the same moment as the new site.

• Use permanent redirects for anything that has genuinely moved, and keep temporary ones for things that are genuinely temporary
• Redirect to the closest equivalent page, never to the home page as a catch-all, which loses the relevance you are trying to preserve
• Avoid chains: old to new in one hop, not old to interim to new, because every hop is another chance for something to break
• Watch for pattern changes the platform introduces on its own, such as trailing slashes, upper case characters or a new path prefix
• Keep the old redirect rules from previous migrations, since a URL that has moved twice still needs to reach the current page
• Serve a useful page rather than a generic error for anything genuinely retired, and let it return the correct status code

Test the map on staging before launch, then run the full list again within an hour of going live. A redirect rule that works in a config file and not on the live server is common enough that we treat launch day verification as part of the job rather than a precaution.

Keep the parts that were doing the ranking

A page ranks because of what is on it. If the redesign replaces nine hundred words of specific, useful explanation with a headline and a photograph, the redirect is correct, the design is better and the ranking still goes. Content parity is not sentimentality about old copy. It is keeping the substance that earned the position, in the same page, under headings that still say what the page is about.

Where a rewrite is genuinely wanted, do it properly rather than by subtraction. In our experience the pages that survive a redesign best are the ones that came out longer and clearer, and the ones that suffer are the ones that came out prettier and emptier.

Templates carry search, individual pages do not

On a rebuilt site almost everything that matters to search is produced by a template. That is an advantage, because it means the work is finite and checkable.

• Title and description patterns that produce something sensible for every page, including the ones nobody reviews
• One H1 per page, and a heading order that follows the structure of the content rather than the visual design
• Canonical tags that point to the URL you want indexed, and that do not all point at the home page, which is a failure mode we still see
• Structured data from schema.org built into the templates, so organisation, breadcrumb, article and FAQ markup arrive with the page rather than as a later project
• Internal links in the body content, not only in the navigation, since that is how a deep page gets reached and understood
• A sitemap generated from the site rather than maintained by hand, so it cannot drift out of date

The staging site, and the block that ships

Staging sites need to be kept out of the index, and there are two ways to do it, which people confuse constantly. A robots.txt disallow, specified in RFC 9309 at rfc-editor.org/rfc/rfc9309, asks compliant crawlers not to fetch the page. A noindex directive in a meta tag or an HTTP header tells them not to index it. They are not interchangeable, and a page blocked in robots.txt can still appear in results, because the crawler never fetched the page and therefore never saw the noindex it was told to ignore.

For a staging environment, HTTP authentication is the more reliable answer, because a password does both jobs and does not depend on anyone honouring a file. Then check the live site on launch day for the block that came along for the ride. A disallow rule and a site-wide noindex both survive a deploy perfectly well, and a site quietly removing itself from the index is not obvious from looking at it.

Do not change everything at once

A redesign, a platform change, a domain change and a new URL structure are four separate migrations. Shipping them in one release feels efficient and makes diagnosis nearly impossible, because when traffic falls you have four candidate causes and no way to isolate any of them.

Where the timetable allows, separate them. Move the domain on its own with the old design intact, let it settle, then launch the redesign on the settled domain. Where that is not possible, and often it is not, the next best thing is to keep the URL structure identical through the rebuild. A redesign that changes nothing about the addresses removes the largest single risk from the launch, and nobody outside the project will miss the tidier paths.

The same logic applies to the copy. Rewriting every page during a migration means the recovery period is also the period in which nobody can tell whether the new writing is working.

Launch day, in order

1. Deploy the redirects with the site, not after it
2. Check robots.txt and a sample of pages for stray noindex directives before anything else
3. Submit the new sitemap in Search Console, and leave the old sitemap accessible for a while so the old URLs get recrawled and the redirects get seen
4. Crawl the live site immediately and compare the output against your inventory sheet, row by row
5. Run the old URL list through a status checker and fix anything that is not a single hop to a real page
6. Verify analytics and conversion tracking on the live site, because a redesign with no measurement means arguing about the drop from memory

What is normal afterwards, and what is not

Some movement after a migration is expected. Search engines have to recrawl and reassess, which takes weeks rather than days on a site of any size, and a period of fluctuation is not evidence that something is broken. A steady decline that does not recover, or a sudden loss of indexed pages, is.

Watch index coverage rather than rankings for the first fortnight. Pages being discovered, crawled and indexed is the process working. Pages appearing as excluded, redirected unexpectedly, or reported with a canonical you did not choose is the process telling you exactly which of the earlier steps was missed.

Who should own this, and when

The uncomfortable part is that the search work has to start before the design does. The inventory informs which pages exist in the new structure, and the URL decisions inform the navigation. Bringing search in during the final fortnight produces a list of problems at the point when the budget is spent and the launch date is fixed.

If you are commissioning a redesign, ask who produces the redirect map, when it will be ready, and who verifies it on launch day. If the answer is vague, that is not a small gap in the proposal. It is the item most likely to cost you the traffic you are rebuilding to keep.

A redesign does not lose rankings because search engines dislike the new design. It loses them because six hundred URLs went somewhere and nobody wrote down where. Tech Conversion

Questions people ask about this

Will a website redesign hurt my SEO?

Only if the mechanics are neglected. Traffic is lost when URLs change without redirects, when content is trimmed during the rebuild, when staging crawl blocks go live, or when templates drop the titles, headings and structured data that were doing the work. Each of those is preventable before launch, and expensive to diagnose afterwards.

What is a redirect map and when should it be written?

It is a mapping from every existing URL to one destination on the new site, with a keep, merge or retire decision behind each row. It should be written during the build, tested on staging, deployed at the same moment as the new site, and re-run against the live server within the hour. It is the deliverable that decides whether a migration holds.

Should I redirect old pages to the home page?

No, other than as a last resort for pages with no equivalent. A redirect to a page that does not answer the same question is treated much as a deletion, so you lose the relevance you were trying to keep. Redirect to the closest genuine equivalent, and where nothing equivalent exists, serve a helpful page with the correct status code.

How long before traffic recovers after a migration?

Expect fluctuation for several weeks while pages are recrawled and reassessed, on a scale that depends on the size of the site. That is normal. What is not normal is a steady decline that does not level off, or a fall in indexed pages. Watch index coverage rather than rankings for the first fortnight, since it identifies which step was missed.