Website redesign without losing SEO: protecting the traffic you have

Redesigns lose traffic for reasons that have nothing to do with the design

The phrase “we lost our rankings after the redesign” implies a causal link that almost never exists. Google does not penalise a new visual identity. What it notices, quite quickly, is that a page it used to know is now a 404, that a URL it had ranked now redirects to a homepage, that a page which used to contain a specific answer now contains positioning, or that the whole site is asking not to be indexed because a staging directive shipped with the deployment.

Every one of those is mechanical, preventable, and invisible in a design review — which is why migrations go wrong on projects where nobody was careless. Everyone was looking at the right things for their discipline, and nobody was looking at the URL layer.

There is a second, subtler failure that is not mechanical at all: the redesign improves the site for the buyer who is already convinced, and quietly removes the pages that were bringing in the buyer who is not. Marketing teams simplify, and simplification applied to a long tail of pages that each earn a handful of visits is indistinguishable from deletion.

So a safe migration is really two disciplines. Preserve the mechanics — URLs, redirects, directives, markup, speed. And preserve the substance: the specific content that currently answers a specific question. The first is a checklist. The second is an argument to have with the stakeholder who wants a cleaner site, and it is better had before the wireframes exist than after.

The baseline audit to take before anyone opens Figma

You cannot protect what you have not measured, and the baseline becomes impossible to reconstruct once the old site is gone. Take it first, not “when we get to the SEO phase”.

Crawl the existing site, completely. Screaming Frog, Sitebulb or the equivalent gives you every URL with its status code, title, meta description, heading structure, canonical tag, indexability, word count and internal link count. Export it. This file is the spine of the entire migration.

Export Search Console performance data by page. The Performance report gives clicks, impressions, click-through rate and average position, filterable by page and query. Export page-level data for the longest window available and query-level data for your top pages. This is which URLs actually earn something — a different list from the one your team thinks matters.

Export the top landing pages from analytics, with organic conversions. A page with modest traffic and a high conversion rate is worth more than a page with heavy traffic and none, and it is exactly the sort of page that gets consolidated away.

Pull your backlink data. Export the pages with external links pointing at them. These are the URLs where a redirect failure costs most, because links are the hardest asset to rebuild.

Benchmark performance. Record current Core Web Vitals field data at origin and template level, plus lab measurements per template. A common redesign outcome is a site that is objectively prettier and measurably slower, and without a benchmark you will argue about that from memory.

Record your structured data and rich results, because those are generated by templates and templates are what a redesign replaces. And save the raw HTML of your top pages — not a screenshot, the source. When someone asks in three months what the old page said, that is the only reliable answer.

Two more if the site is large: log file analysis, to see what Googlebot actually crawls rather than what your sitemap claims, and an inventory of every subdomain, because migrations routinely forget the help centre.

Building the URL map and the redirect matrix

The URL map is a spreadsheet with one row per old URL and one column for its destination. It is dull, it is the most valuable artefact in the project, and it should be built by someone who understands both the old site’s content and the new site’s information architecture.

Start from the union of three lists: every URL from the crawl, every URL with impressions in Search Console, and every URL with an external link. The union matters — crawls miss orphaned pages that still rank, and Search Console reveals URLs no internal link points at any more.

Then classify each URL. The classification, not the mapping, is where the thinking happens.

Situation	What to do	Why
URL unchanged, content unchanged	Nothing — but verify the URL really is byte-identical	Trailing slashes, casing and protocol all make a different URL
URL changed, content substantially equivalent	301 to the new URL	The standard case; signals consolidate on the new address
Page merged into a broader page	301 to the merged page, and check it actually covers the old topic	A redirect to a page that does not answer the query behaves like a soft 404
Page removed, close equivalent exists	301 to the closest genuine equivalent, never to the homepage by default	Bulk redirects to the homepage are treated as soft 404s and waste the signal
Page removed, no equivalent, no value	Return 410 or 404 deliberately	An honest 404 beats a misleading redirect and clears the index faster
Paginated, faceted or parameterised URLs	Decide the pattern before launch; map the canonical form rather than every variant	These generate the largest volume and the worst chains. Rules, not rows

A few rules that save pain later.

Redirect to the specific equivalent, or to nothing. The temptation with a few thousand retired URLs is a catch-all rule sending everything to the homepage. Google treats an irrelevant redirect target as a soft 404, so you get neither the ranking nor a clean removal. If there is no equivalent, let it 404.

Use server-side permanent redirects. Google’s redirect documentation ranks server-side redirects most reliable, meta refresh second and JavaScript redirects last, because rendering can fail. Use HTTP 301 or 308 configured at the server or CDN.

Redirect in one hop. Google’s site move guidance advises avoiding chains longer than five redirects and recommends no more than three. Chains appear silently when a site has been migrated before: the 2021 rule points at the 2023 URL, which now points at the 2026 URL. Flatten every chain against the final destination before launch.

Keep the redirects. Google’s guidance is explicit: “Keep the redirects for as long as possible, generally at least 1 year.” Treat the map as a permanent asset; the only reason to remove a rule is that it has become a chain.

If the domain or subdomain is changing, use the Change of Address tool. It requires ownership of both properties under one account and the 301s already in place, and it forwards signals for 180 days. It does not apply to HTTP-to-HTTPS moves, www changes or restructures within the same domain.

Content parity: what has to survive the rebuild

This is the part no checklist can automate, and the part that causes the losses that do not recover.

The rule is simple to state: for every URL that currently earns traffic, the destination page must answer the same query at least as well. Not “cover the same topic” — answer the same query. A long guide to a specific problem, replaced by a short service page that mentions the problem, is a downgrade regardless of how much better the new page looks.

Apply parity checks at three levels.

Page level. For each top-earning page, compare old and new on: the primary query it ranks for, whether that query’s answer is still present, word count, headings, images and their alt text, tables, downloadable assets, and any FAQ or how-to content that generated a rich result.

Template level. Titles and meta descriptions are usually template-generated. Redesigns often replace a considered per-page title with a pattern, and a site full of “Services | Company” titles will lose click-through rate at the same rankings. Check the H1 too: many new templates render it from a display field and end up saying “Overview” on four hundred pages.

Site level. Count indexable pages before and after. A large unexplained reduction is either a deliberate consolidation you can justify page by page, or a template excluding something by accident.

The uncomfortable conversation to have early is about the long tail. Sites that have published for years accumulate pages that each earn very little, and the aggregate is often a large share of organic traffic and a larger share of the queries that bring in new buyers. Consolidating those into fewer “better” pages is a legitimate strategy with a cost, and it should be decided deliberately by someone looking at the data — not incidentally, by a sitemap exercise in a workshop.

Internal links, anchor text and the crawl paths you cannot see

Internal linking is the redesign casualty nobody notices, because nothing is broken. The pages still exist. They are simply no longer linked to.

A cleaner navigation with fewer top-level items means pages previously reachable in two clicks are now reachable in four, or only from a sitemap. Crawlers follow links, and pages that lose links lose the internal signal that helped them rank. This is a real mechanism and it is entirely self-inflicted.

Before launch, do three things. Compare internal inbound link counts per URL between the old crawl and the staging crawl; any page dropping from many internal links to one or two needs a deliberate decision, not an accident. Check anchor text, because a redesign that replaces descriptive links with “Learn more” throws away the meaning they carried. And check that pagination, filters and any “load more” pattern still produce crawlable links — an infinite scroll implemented purely in JavaScript can make an entire archive unreachable.

The related concern for larger sites is crawl budget. If a new faceted navigation generates tens of thousands of parameterised URLs, crawlers spend their time there instead of on your commercial pages. Decide the rules for parameter handling, canonicalisation and robots directives before the build ships; retrofitting them means undoing an index that has already been polluted. That belongs in the build specification alongside the web development tasks, not in a post-launch audit.

Staging hygiene: noindex, robots.txt and the canonical traps

More migrations are damaged by directives than by anything else, because the failure is silent and total.

The staging noindex. Staging sites are correctly blocked from indexing. The problem is when the block lives in the codebase rather than the environment, and the deployment carries it to production. Every migration needs an explicit, named check of the production robots meta tag and X-Robots-Tag header immediately after launch, done by a person who has been told this is their job.

The two directives that do not combine. Google is unambiguous: “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” To remove a page from the index, allow it to be crawled and serve noindex. Blocking it in robots.txt stops the crawler ever seeing the instruction.

robots.txt is not a privacy control. Google states plainly that it is “not a mechanism for keeping a web page out of Google”, and that a disallowed page “can still be indexed if linked to from other sites”. Use authentication for anything genuinely private.

Hard-coded canonicals. The classic failure is a rel="canonical" written during development that points at the staging hostname, or a template emitting a canonical pointing at the homepage for every page. Spot-check canonicals across every template after launch, and use the URL Inspection tool to compare the user-declared canonical with the Google-selected one — they can differ, and the discrepancy is diagnostic.

Sitemaps. Generate a fresh XML sitemap of new canonical URLs only, within the documented limits of 50,000 URLs or 50MB uncompressed per file, split with a sitemap index if you exceed either. Exclude redirected, noindexed and non-canonical URLs. Set lastmod honestly: Google uses it only where it is consistently and verifiably accurate, so a build process that stamps today’s date on every page makes the field worthless.

hreflang, if you have it. Every cluster needs rebuilding against the new URLs with reciprocal annotations. Broken hreflang produces the wrong language version ranking in the wrong market, which is harder to spot than a straight traffic drop.

Launch day: the runbook

Have a written sequence with named owners. Not a shared understanding — a document.

1. Before the switch: final crawl of staging with JavaScript rendering on, confirming status codes, canonicals, indexability, titles and structured data on every template. Confirm redirect rules are loaded and tested against at least a hundred real old URLs, including the awkward ones with parameters, uppercase and trailing slashes.
2. Immediately after the switch: check robots.txt on production. Check the robots meta tag on the homepage and on one page of every template. Confirm all four combinations of www and protocol land in one place in one hop.
3. Within the first hour: run a redirect test across the full old URL list, not a sample. Every row should return a single 301 to a 200. Fix anything returning a 404, a chain, or a redirect to a page that does not answer the old query.
4. Same day: submit the new sitemap, and if the domain changed, start the Change of Address process. Use URL Inspection to request indexing for the handful of pages that matter most commercially.
5. Same day: confirm analytics and tag deployment on the new templates. A tracking failure looks exactly like a traffic collapse in the one report everyone will be staring at. If you are also changing consent or tagging architecture, do it separately — our note on consent mode and server-side tracking explains why bundling that into a migration makes both harder to diagnose.
6. Same day: re-benchmark performance against the baseline, and check structured data still validates on every template that had it.
7. Keep the old site on a restricted address, and keep the old logs and analytics exports somewhere permanent.

The first weeks: what to monitor, and when to actually worry

Google is clear that a wobble is normal: “the visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site’s rankings will settle down over time.” Its documentation also notes that a small to medium-sized site can take some weeks for most pages to move across, with larger sites taking longer. So the first question is not “has traffic dropped” but “is this the shape of a settling period, or the shape of a fault?”

Monitor these, in order:

• Coverage and indexing. Watch the count of indexed pages and the exclusion reasons. A rise in “Not found (404)”, “Excluded by noindex tag”, “Blocked by robots.txt” or “Duplicate without user-selected canonical” is a fault, not a fluctuation.
• Search Console Performance, segmented. Clicks and impressions by page group and by query, not just the site total. A single broken template and an even decline everywhere produce the same headline number and need entirely different responses.
• Crawl errors and server logs. Googlebot hitting old URLs and receiving 404s means the redirect map has gaps. The logs tell you which, and in what volume.
• Core Web Vitals. The Search Console report uses Chrome User Experience Report field data, so a new site starts with none and accumulates it over a 28-day window. Do not read the first week as a verdict; do read lab measurements immediately, because they show a regression before the field catches up. Our guide to INP, LCP and CLS covers how those metrics behave.
• Conversions, not just sessions. A migration that holds traffic and loses enquiries has broken a form, a phone link or a tag.

Worry immediately if indexed pages fall sharply; the drop is concentrated in one template or directory; Search Console reports noindex or robots blocks you did not intend; the Google-selected canonical differs from your declared canonical at scale; or impressions fall while average position holds, which usually means pages have left the index rather than dropped in it.

Be patient if individual queries move a few positions in both directions, if the drop is broad, shallow and already trending back, or if discovery of new URLs is simply still in progress.

Diagnosing a drop that has already happened

If you are reading this after launch rather than before, work through it in this order. The sequence matters, because each step rules out a class of cause.

1. Confirm it is real. Compare Search Console clicks — which do not depend on your tag manager — against analytics sessions. If Search Console is stable and analytics collapsed, you have a measurement problem, and that is the good outcome.
2. Check the directives. Fetch robots.txt. Check the robots meta tag and X-Robots-Tag header on each template. Five minutes, and it explains a surprising share of catastrophic drops.
3. Test the redirects. Take the top hundred URLs by clicks from the pre-launch export and request each one. Look for 404s, chains, and redirects to pages that do not answer the original query.
4. Segment the loss. Group the losing URLs by template and by directory. Concentrated in one template is a template bug; concentrated in one directory is a mapping gap; spread evenly is more likely content, performance, or a coincidental algorithm update — check the dates against announced updates before assuming causation.
5. Compare the content. For the ten biggest losers, put the old HTML you saved next to the new page. Is the answer still there? Is the title still specific? Did the H1 go generic?
6. Check canonicals per URL. Run URL Inspection on the losers. A Google-selected canonical that differs from yours is a duplication problem redirects and canonical tags should resolve.
7. Check internal links. Did the losing pages lose their inbound internal links in the navigation rewrite?

Only after all seven should you consider that the content was simply outcompeted while you were busy. That happens, and it is not a migration fault — but it is the last hypothesis, not the first.

The pre-launch checklist

A condensed version to attach to the project plan. Every line gets an owner and a date.

1. Full crawl of the current site exported and archived.
2. Search Console page-level and query-level performance exported for the longest window available.
3. Analytics landing pages and organic conversions exported.
4. Backlink data exported; linked URLs flagged as protected.
5. Core Web Vitals field and lab baselines recorded per template.
6. Structured data and rich results inventory recorded; raw HTML of top pages archived.
7. URL map complete, covering the crawl, Search Console and backlink URL sets.
8. Every mapping classified: keep, redirect, merge, or deliberately retire.
9. Redirect rules written as patterns where possible, tested against real URLs, flattened to one hop.
10. Content parity checked page by page for the top-earning URLs.
11. Titles, meta descriptions and H1s reviewed per template, not just on the homepage.
12. Internal link counts compared old versus staging; navigation losses reviewed.
13. robots.txt, meta robots and X-Robots-Tag verified on staging and scheduled for re-verification on production.
14. Canonical tags checked on every template; no staging hostnames anywhere.
15. hreflang clusters rebuilt and reciprocated, if applicable.
16. XML sitemap regenerated with canonical URLs only, within the documented size limits.
17. Analytics, tag manager and conversion tracking verified on new templates.
18. Launch-day runbook written with named owners, and a monitoring plan that defines a fault versus a fluctuation.

None of this is difficult. It is work that has to be scheduled, and it is the first thing to fall off a plan when the launch date is fixed and the design is late. If the redesign is being driven by a web design or e-commerce engagement, insist that the migration plan is a named deliverable with its own owner rather than a line item in someone’s final week.

We run this alongside redesigns as part of our technical SEO practice, and the honest position is that most of it can be done in-house by anyone methodical with a crawler and access to Search Console. The value of bringing someone in is not secret knowledge. It is that they will be the only person on the project whose sole job is to notice that a URL changed.