Website Redesign SEO Checklist: How to Migrate Without Losing Your Rankings

A redesign goes live on a Friday. By the following Wednesday the organic traffic chart looks like a cliff. I have seen that sequence often enough to stop calling it bad luck. It is almost always the same short list of failures: URLs changed without a map, templates shipped without their metadata, staging directives leaked into production, and nobody owned the first 30 days.

This website redesign SEO checklist is written for the people who carry that risk. That means founders approving the budget, CTOs whose team ships the build, and technical leads who get the call when organic leads fall. It assumes you already know what a redirect, a canonical tag and a crawl are. What it covers is the order of operations, who owns each task, and the numbers worth checking at each stage.

The work runs in five phases: discovery and benchmarking, redirect architecture, technical preservation, staging verification, and a 30-day post-launch protocol.

Why Website Redesigns Crash Organic Rankings: The 30 to 50 Percent Traffic Wipeout

A redesign loses rankings when Google can no longer match the old URLs, content and signals to the new site. The damage usually comes from three places: changed URLs without redirects, deleted pages that were holding links or rankings, and new templates that drop titles, headings or structured data. In my experience, drops of 30 to 50 percent in organic sessions are common in the first weeks of a badly managed launch, and some sites never fully recover.

The reason is that a redesign is rarely just a redesign. It tends to bundle a new information architecture, a new CMS or front-end framework, rewritten copy and a new navigation, all in one release. Each of those is a separate variable that search engines have to reprocess. When they all change on the same day, you lose the ability to tell which change caused which loss.

The principle I work from is simple. Change as little as possible of what search depends on, and document every change you do make. Design, spacing, imagery and interaction patterns can change freely. URLs, primary headings, internal link paths, indexable content and structured data should only change when there is a reason you can defend.

Phase 1: Pre-Migration Discovery and Benchmarking

Before a single design is approved, take a full snapshot of everything that currently earns traffic. You need a crawl, a performance baseline and a URL inventory that you can compare against after launch. Without that snapshot you cannot prove what broke, and you will spend the post-launch weeks arguing from memory.

Crawling Staging vs. Production

Crawl the live site first and keep that file as your source of truth. Screaming Frog is my default tool here. The free version stops at 500 URLs, so anything larger needs the paid licence. Run the crawl with JavaScript rendering enabled if the current site depends on it, and export status code, indexability, canonical, title, H1, meta description, word count and inlinks for every URL.

The same crawl configuration is then reused on staging later. Using identical settings matters, because it lets you compare the two crawls row by row instead of guessing whether a difference comes from the site or from the crawler setup.

Mapping Every High-Value URL and Ranking Query

The crawl tells you what exists. Google Search Console tells you what matters. Export pages and queries for the last 16 months, which is the full window Search Console keeps. The interface caps exports at 1,000 rows, so for larger sites use the API or a Looker Studio connector. Then merge that data with GA4 landing pages, and add backlink counts per target URL from Ahrefs or Semrush.

Sort every URL into one of three tiers:

• Tier A: URLs with conversions, the top 20 percent of clicks, or meaningful referring domains. These keep the same URL wherever possible, the same primary heading intent and the same core content.
• Tier B: URLs that rank or earn some traffic but do not convert directly. These can change more, but need an exact redirect target.
• Tier C: URLs with no traffic, no links and no conversions. These can be consolidated, redirected to a close parent or retired.

Record a benchmark table before launch so the comparison later is honest:

Phase 2: 1:1 301 Redirect Architecture (Avoiding Lazy Catch-All Homepage Redirects)

Every old URL that has traffic, links or rankings needs a single 301 redirect to its closest equivalent on the new site. Pointing everything at the homepage is the shortcut that costs the most, because Google often treats redirects to irrelevant pages as soft 404s, which means the old page’s value is not passed on. The redirect map should be finished before launch, tested on staging, and left live for at least 12 months.

A redirect map is a spreadsheet with one row per old URL. It does not need to be elegant. It needs to be complete and verified.

A few rules I do not bend on:

• One hop only. A redirect to a URL that redirects again creates a chain. Chains waste crawl effort and are the most common thing I find when auditing a migration that underperformed.
• Update internal links to the final URL. Redirects are a safety net for external links and bookmarks. Your own navigation, body links and sitemap should point straight to the new address.
• Normalize the variants. Protocol, www versus non-www, trailing slashes, uppercase paths and tracking parameters all need a defined behaviour, otherwise they create duplicate entry points.
• Retire pages honestly. If a page has no equivalent, a 410 or 404 is better than a misleading redirect. If a close parent category exists, redirect there.

Pattern-based rules save time on large sites, but they need careful testing. A simple example in nginx looks like this:

# Single-hop 301 for a retired service URL
location = /services/seo-package/ { return 301 /services/seo-audit-services/; }

# Pattern rule for dated blog URLs
rewrite ^/blog/\d{4}/\d{2}/(.*)$ /resources/$1 permanent;

Test every rule before it goes near production. Load the full list of old URLs into Screaming Frog in list mode, follow redirects, and confirm that each one ends in a 200 response after exactly one hop.

Phase 3: Technical Preservation for Schema, Canonical Tags, Meta Data and Breadcrumbs

The new templates must carry across everything the old ones did for search, even when nobody sees it on screen. Designers and developers rebuild what is visible. Titles, canonicals, structured data and internal link paths are invisible, so they are the first things to disappear. Check each of these on the new templates, not just on a sample page.

• Titles and meta descriptions. Carry across the existing values for every Tier A page. Do not let the CMS regenerate them from a default pattern.
• Headings. Keep one H1 per page and preserve the intent of the existing H1 and H2s on pages that rank.
• Canonical tags. Each indexable page should have a self-referencing canonical using the absolute production URL. A canonical that still points to the staging domain is one of the most damaging launch errors, and it is easy to miss. For the logic behind canonicals and redirects, our canonical and duplicate content guide covers it in full, so I will not repeat it here.
• Structured data. Carry over Organization, Breadcrumb, Article, Product or FAQ markup as applicable, then validate each template in Google’s Rich Results Test. Breadcrumb markup should match the visible breadcrumb trail on the new site.
• Internal linking. A new navigation can quietly remove links to important pages. Compare inlink counts for Tier A URLs between the old crawl and the staging crawl.
• XML sitemap. It should list only 200-status, indexable, canonical URLs. Remove redirected and noindexed URLs.
• Hreflang and pagination. If either exists today, confirm they survive the template change.
• Rendered content. If the new front end relies on JavaScript, confirm that the main content, links and metadata appear in the rendered HTML, not just in the browser.
• Analytics and conversion tracking. Confirm that Google Tag Manager, GA4 events and form tracking fire on the new templates. A migration with perfect SEO and broken tracking still looks like a failure on the dashboard.

Phase 4: Staging Site Verification Before the DNS Switch

Staging has to be reachable for your crawler and invisible to Google until the moment you launch, and then the switch has to remove every barrier at once. The failure I see most is a staging noindex tag or a blanket Disallow rule in robots.txt that ships to production unchanged. A site can lose most of its visibility within days of that mistake.

Protect staging with HTTP authentication rather than relying only on robots.txt. Then run these checks in the 24 hours before launch:

1. Crawl staging with the same Screaming Frog configuration used on the live site, and use its crawl comparison feature to compare against the production crawl.
2. Check for zero unexpected 4xx and 5xx responses across the Tier A and Tier B URL lists.
3. Run the full redirect map and confirm single-hop 301s to 200 pages.
4. Compare titles, H1s, canonicals and word counts for Tier A URLs. Flag any that changed without approval.
5. Confirm indexing directives. The noindex tag and password protection come off at launch, and the production robots.txt should not contain staging rules.
6. Validate structured data and rendered HTML on one page from every template type.
7. Test forms, checkout and conversion events end to end.
8. Run PageSpeed Insights on key templates. Lab scores on staging are only indicative, but a major regression is worth catching early.

Responsibilities split cleanly between engineering and search. This table is the version of the redesign SEO checklist I hand to teams so that nothing sits between two owners:

Phase 5: Post-Launch Day 1 to Day 30 Monitoring Protocol

The first 72 hours after launch are the highest-risk window, and the 30 days that follow decide whether rankings stabilize. Treat launch as the start of the migration, not the end. Someone needs to own monitoring with a calendar, a checklist and the authority to ask for fixes the same day.

Some volatility in the first two weeks is normal, because Google needs time to recrawl and reprocess the new URLs. A steady decline after week three is not normal, and usually points to a redirect, canonical or internal linking problem you can still fix. For what to expect in terms of recovery and compounding, see our realistic SEO timeline after launch.

Agree rollback and escalation rules before launch, not during it. For example: if more than a handful of Tier A URLs return 404s, noindex or redirect to the wrong page, the fix ships within 24 hours, not at the next sprint.

Why Engineering Teams Need an Independent Pre-Migration SEO Audit Before Going Live

An independent review catches what the people building the site cannot see, because they are testing against the spec they were given. Developers verify that pages load, forms work and components render. Nobody on the build team is usually checking what Google will see: the redirect behaviour, the rendered metadata, the canonical targets and the internal link graph. A separate reviewer also has no stake in the launch date.

A pre-migration SEO audit compares the staging crawl with the production baseline, checks the redirect map line by line, validates templates and indexing directives, and ends with a clear go or no-go recommendation before the DNS switch. It is a fixed piece of work with a defined end, and it is cheap compared with the cost of getting it wrong.

Here is an illustrative calculation. Suppose organic search drives $40,000 a month in pipeline. A migration that loses 30 percent of that for three months costs about $36,000, before counting the engineering time to diagnose and repair it. Prevention is almost always the cheaper line item.

The cleanest time to bring in an outside reviewer is when the staging build is feature-complete but the launch date is still flexible, usually one to two weeks before launch. At that point there is time to fix what the review finds without delaying the release.

Redesign SEO Checklist Sign-Off: What Must Be True Before You Switch DNS

A redesign is ready to launch when every item below is true and someone has put their name against it. If any line is uncertain, the launch date moves. This is the shortened version of the SEO checklist for website redesign work that I keep at the top of every migration plan.

• A full pre-launch crawl and performance baseline are saved and shared.
• Every Tier A and Tier B URL has a tested one-hop 301 to a relevant 200 page.
• Internal links point to final URLs, and no redirect chains remain.
• Titles, headings, canonicals and structured data are verified on every template.
• Staging noindex, authentication and robots.txt rules are removed from the production release.
• The XML sitemap lists only indexable 200 URLs and is ready to submit.
• Analytics and conversion tracking are confirmed on the new templates.
• A named owner has a 30-day monitoring calendar and rollback rules.