Website Redesign SEO: The 2026 Migration Checklist

SEO for a website redesign is the work of moving an existing site's addresses, content and signals to a new structure without losing the rankings the old site earned. It is a mapping exercise before it is anything else, and it belongs at the start of the project rather than in the week before launch.

This assumes the decision to redesign is already made. Scope, budget, timeline and choosing an agency are covered in our website redesign guide. What follows is the migration itself: the table you build, the rules the redirects follow, what gets checked on staging, and what to watch afterwards.

Rankings drop after a redesign for mechanical reasons, not mysterious ones. A URL that returns 404 leaves the index. A page that no longer exists stops ranking. Internal links that break stop passing signals. None of that is bad luck, and all of it is preventable with a table built before launch.

What genuinely breaks search performance:

• Missing redirects. The old address returns an error and the page is dropped along with everything it accumulated.
• Deleted pages. Retiring a page that was earning organic entries removes that traffic, with or without a redesign attached.
• Broken internal linking. Links are how pages get discovered and how importance is signalled. Rebuilt navigation that points at old addresses degrades both.
• Wholesale rewriting of titles and headings. These describe what a page is about. Replacing every one of them changes which queries the page is relevant for.
• Content that only renders client-side. If the new build hides the main content behind JavaScript execution, it may not be indexed at all.

What does not break it, despite what most checklists claim. A visual redesign on unchanged URLs with unchanged content carries very little search risk, because almost nothing search cares about has moved. And a temporary redirect does pass signals: according to Google Search Central, server-side redirects convey ranking and canonicalisation signals. The reason to use a permanent one is that it declares the move permanent, not that the alternative leaks value.

The distinction matters because it tells you where to spend the budget. Migration effort belongs on the URL inventory and the redirect map, not on rewriting metadata that was already working.

The URL map is the single artefact the whole migration runs on, and it has to be built before templates exist. Every old address gets a row, and every row gets a decision. A URL with no recorded decision is an unhandled URL, which is how sites end up discovering their losses from a 404 report six weeks after launch.

Build it from six sources, in this order. No single source is complete, which is the whole reason for using six:

1. Indexed URLs from Search Console, under Indexing and then Pages.
2. A full crawl of the current site.
3. The current sitemaps.
4. Pages with organic entries and conversions, from analytics.
5. URLs with external links pointing at them.
6. A content export from the CMS, which catches pages that are published but unlinked.

That ordering is industry practice rather than a Google requirement, and it is worth stating plainly because most checklists present their own ordering as if it were documented. What is documented is what happens when an address is missed.

The table below is the specification we use. Downloading a list of tips is not useful; a column structure is, because it is the thing you actually fill in.

Redirects follow three rules, and all three are documented rather than matters of taste. Use permanent redirects for a permanent move, resolve every one in a single hop, and keep them in place for at least a year. Sites that break rankings during a redesign usually break one of these three.

Permanent, because the move is permanent. According to Google Search Central, a permanent redirect tells search engines the original URL should no longer be served. That is the signal you want when a page has genuinely moved for good.

One hop, never a chain. Old to new, directly. Chains of old to interim to new waste crawl requests and add failure points. This is easy to violate accidentally: a slug change followed months later by a second slug change produces a chain unless the first redirect is repointed at the final address. Audit the map for chains as a build step rather than as a habit.

Keep them for at least a year. Google's guidance on site moves is to keep redirects in place for a minimum of a year, and longer causes no harm. Note the direction of that instruction: it is a floor, not an expiry date. There is no reason to remove a redirect while the old address still receives traffic or holds external links.

One more decision belongs here: what to do with pages you are deliberately removing. Redirect them only where a genuinely equivalent page exists. Redirecting a retired page to the homepage because something has to be done with it is worse than letting it return a clean error, because it produces an irrelevant destination for anyone who follows the link.

Multilingual sites carry an extra failure mode, and it is the one most migration checklists skip entirely. When URLs change in several languages at once, the annotations that tie those language versions together break simultaneously, and the result is the wrong language version being shown in the wrong market.

Three requirements have to hold after the move. According to Google's documentation on localized versions, language annotations must reference canonical URLs, every version has to list every other version including itself, and a default entry can be declared for unmatched languages.

The practical consequence is that language annotations must be regenerated against the new addresses as part of the launch, not left to resolve through the redirects. A redirect tells a crawler where a page went; it does not repair an annotation that still points at the old address.

This is also where a stable identifier earns its keep. If each language has its own localised slug, something other than the slug has to join the versions together. A permanent identifier that never changes, even when every visible address does, is what makes the annotation regeneration mechanical rather than manual. That single design decision is the one we would repeat first, and it is covered further in our guide to website architecture and search visibility.

Staging is where the migration is verified, and it comes with one switch that has to be thrown in the right order. Block staging from being indexed before any work starts, and unblock production at go-live. Reversing that pair is one of the more common ways to lose a month, because a staging site competing with production is both an index problem and a duplication problem.

What to check before the switch:

• Redirect resolution. Run the full list of old URLs against staging and confirm each one resolves in a single hop to the intended destination. Test the list, not a sample.
• Internal links point at final addresses. Not through redirects. Check content bodies as well as navigation and buttons, because they are usually stored separately.
• Canonical tags reference the new URLs. Self-referencing, not pointing at the old site.
• Language annotations reference each other, in both directions.
• Content parity. The new page carries the substance that made the old page rank. A page that loses half its content during migration loses the reason it was relevant.
• Rendering. Confirm the main content is present without client-side execution. According to Google Search Central, Googlebot does render JavaScript, but rendering is deferred and resource-dependent, so content that only appears after execution is at greater risk of being missed.
• Sitemaps. Generated from the new structure, with accurate last-modified dates.

Record the result of each check against the mapping table rather than in someone's head. The status column exists so that partial verification is visible instead of assumed.

The checklist below is grouped by phase rather than by topic, because the order is what makes it work. Items done in the wrong phase are the ones that get missed. Each entry is an action with a verifiable result, not a reminder to be careful.

Before the content freeze

1. Export indexed URLs from Search Console.
2. Crawl the current site in full and reconcile against that export.
3. Pull pages with organic entries and conversions from analytics.
4. Pull URLs holding external links.
5. Build the mapping table with every URL from every source, deduplicated.
6. Record a decision for every row: keep, redirect, consolidate or remove.
7. Record the current position and traffic of the pages that matter most, as a baseline.

On staging

1. Confirm staging is blocked from indexing.
2. Implement redirects and test the entire old-URL list against them.
3. Audit for chains and loops; every redirect resolves in one hop.
4. Repoint internal links to final addresses, in content as well as navigation.
5. Verify canonical tags and language annotations.
6. Verify content parity for the pages carrying the most search value.
7. Confirm main content renders without client-side execution.

On launch day

1. Unblock production from indexing and verify it, then verify staging is still blocked.
2. Submit regenerated sitemaps.
3. Spot-check live redirects against the list a second time, in production.
4. Confirm analytics, goals and form tracking fire on the new templates with a real submission.

In the first weeks

1. Watch index coverage for spikes in errors and excluded pages.
2. Compare the pages that mattered most against the baseline, individually.
3. Fix newly discovered 404s by adding rows to the mapping table, keeping it the single source of truth.
4. Keep redirects in place, at minimum for a year.

Every cause of post-redesign traffic loss can be graded by how strong the evidence for it is, and that grading changes what you do about it. Causes documented by Google get engineering time. Claims that circulate without a documented basis get scepticism, particularly the ones involving specific recovery timelines.

The table below separates the two. The last row is the one worth reading twice: no numerical recovery window is documented anywhere. Google states that fluctuation should be expected while signals are reprocessed, and gives no duration. Figures like ninety days or three to six months come from individual vendor experience with undisclosed methodology, which is a different class of claim from documentation.

Answer that question with mechanism instead. Changes become visible as Google recrawls the affected URLs, which takes days to weeks depending on crawl rate, and consolidation of signals across redirects takes further time that Google describes only qualitatively.

In May 2026 this site moved its entire content set to localised URLs in five languages at once. That is the case chewed over worst in other migration guides, because the failure modes multiply when every language changes address on the same day. The account below is drawn from the repository history rather than from memory.

The order of operations, which is the part that matters:

1. A stable identifier was added to the content indexes before any renaming. Each article kept one permanent id that never changes, while every language got its own visible slug. Without that, changing slugs in five languages severs the link between language versions.
2. Language annotations were rebuilt to read explicit paths, before the slugs moved, not after. Migrating first and repairing annotations afterwards would have meant a window with broken language signals.
3. Slugs were generated, then files renamed. One rename commit changed 491 files.
4. The redirect map was built, then wired into the build. As of 3 August 2026 it holds 383 permanent redirects. 358 of them are blog URLs, which is 93 % of the map, and Spanish and French carry 96 entries each, 25 % of the total apiece.
5. Internal links in content were rewritten to final addresses, so that internal linking does not travel through redirects.
6. Sitemaps with language alternates, then the markdown mirrors and the machine-readable index.

What went wrong, which is more useful than the parts that worked:

The first pass over internal links missed keys that did not look like links. Fields named for calls to action rather than for URLs were skipped, and a follow-up commit was needed. The lesson generalises: scan by value shape, not by field name.

Three days later a second gap surfaced. Links inside markdown content were not covered by the pass over structured fields and had to be fixed separately. Content held in two representations needs two passes, and the second one is the one that gets forgotten.

A third issue appeared afterwards: missing last-modified dates in the static sitemap, found after launch rather than before.

We are deliberately not quoting a traffic result for this migration. There is no isolated measurement to attribute it to, since content was being added throughout the same period. The value of the account is the sequence and the mistakes, not a number.

Monitoring after go-live is about specific pages, not about a total. A site-wide traffic line moves for many reasons and will not tell you whether the migration worked. The pages you listed as mattering most, checked individually against the baseline you recorded, will.

What to watch, in the order it becomes informative:

• Index coverage. New errors and newly excluded pages appear here first and usually point at a missing redirect or a blocked path.
• Crawl activity on the old addresses. While Google is still requesting them, the move is still being processed.
• The baseline pages, one at a time. Position and impressions per page, compared with what you recorded before the freeze.
• New 404s. Each one is a row that was missing from the mapping table. Add it to the table, not just to the server configuration, so the table stays authoritative.
• Rendering of new templates, if the build changed its rendering approach.

Resist the urge to intervene in the first days. Redirect fixes and genuine errors should be corrected immediately, but rewriting titles or restructuring pages while signals are still consolidating makes it impossible to tell which change caused what. Ongoing work after that point is covered in our guide to post-launch optimization.

If you would rather have the migration run by people who have done it across five languages, that is part of our SEO services.