Website Redesign SEO: The 2027 Migration Checklist

Website redesign SEO is the technical preservation and expansion of organic rankings, backlink equity, and crawl architecture during a site relaunch through 1:1 301 redirect mapping, parity content audits, and Core Web Vitals engineering across €4,500 to €9,000 corporate website rebuilds.

This assumes the decision to redesign is already made. Scope, our services, pricing (bespoke builds run from €1,500 to €4,500), timeline and choosing an agency are covered in our website redesign guide. What follows is the technical migration itself: the mapping table you build, the rules the redirects follow, what gets checked on staging, and what to monitor afterwards.

Rankings drop after a redesign for mechanical reasons, not mysterious ones. A URL that returns an error gets dropped from the index. A page whose content is removed stops ranking for its terms. Internal links that break stop passing signals. None of this is bad luck, and all of it is prevented with a table built before anything launches.

What actually costs you search performance:

• Missing redirects. The old address returns an error, and the page is dropped from the index with whatever signals it had earned.
• Deleted pages. Removing a page that held organic rankings removes the rankings. A redesign is not a license to delete URLs without accounting for their traffic.
• Broken internal links. Links are discovery signals and priority signals. Navigation that points at old addresses breaks both.
• Wholesale title and heading rewrites. Headings tell search engines what a page is about. Rewriting them wholesale changes the terms the page is relevant for.
• Content that only renders in the client. If the new design defers main content behind client-side JavaScript, search engines may miss it on first pass.

In contrast, a purely visual redesign on identical URLs with unchanged content carries almost no search risk. The redirect type also matters less than many checklists claim: Google's site move guidance states that permanent redirects don't cause a loss in PageRank. Where 301 and 302 differ is canonicalization. According to Google Search Central, Google treats a permanent redirect as a signal that the target should become the canonical URL, and a temporary one as no such signal. So put the effort into the URL map, not into rewriting titles that already work.

According to Ahrefs site migration studies and Vezert 2027 technical SEO services telemetry, 44% of post-redesign organic traffic drops are caused by missing or chained 301 redirects, 27% by pruning high-ranking body copy, 17% by broken internal link graphs, and 12% by lost JSON-LD schema and canonical tags. To safeguard your rankings during a platform switch, pair this checklist with our website migration guide, our website redesign checklist, and our fixed-scope corporate websites and pricing.

These problems usually start when SEO arrives after the build; our piece on why SEO and web development must work together explains the handoff.

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. Google lists both 301 and 308 as permanent and handles them the same way; 308 also keeps the request method, which matters for forms and APIs rather than for ordinary pages.

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. A common mistake is blanket-redirecting deleted or pruned pages to the homepage. Google's site move documentation warns that redirecting many old URLs to one irrelevant destination, such as the home page, might be treated as a soft 404, in which case the old page's signals are not carried over. Every retired URL should either map 1:1 to an equivalent replacement or return an explicit 410 Gone (or 404), which tells search engines the page was removed on purpose. The exception is genuine consolidation: when several old pages merge into one new page, redirecting all of them to it is fine.

If the redesign also includes moving hosts, CMS platforms or domain names, see our dedicated guide to website migration for DNS cutover protocols and server-level redirection rules.

The Change of Address tool in Search Console only applies when the domain or subdomain changes. A redesign that keeps the same domain doesn't need it.

For the pages that slip through, see our 404 error page design ideas and examples.

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 ranking recovery window is documented anywhere. Google says fluctuation should be expected while the site is recrawled and reindexed, and the only duration it gives concerns indexing: on a medium-sized site it can take a few weeks or more before Google gradually starts showing the new URLs. 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 localized URLs across five languages at once. This is the case migration guides treat worst, because the failure modes multiply when every language changes address on the same day. The account below is drawn from repository history rather than memory.

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

1. Stable ID added to content indexes before any renaming. Every article kept a permanent identifier while each language got its own visible slug. Without this, renaming slugs across five languages breaks the link between versions.
2. Language annotations rebuilt to read explicit paths before slugs moved, not after. The reverse would have created a window with broken language signals.
3. Slugs generated, then files renamed. A single renaming commit touched 491 files.
4. Redirect map built, then plugged into the build. As of August 3, 2027, it holds 383 permanent redirects: 358 are blog articles (93% of the map), Spanish and French carry 96 each (25% each), German 92 and Dutch 89.
5. Internal links in content rewritten to final addresses, so internal navigation does not pass through redirects.
6. Sitemaps with language alternatives, then markdown mirrors and machine-readable index.

What went wrong, which is more useful than what worked:

The first internal link pass missed fields that were not obviously links, such as schema call-to-action keys. The lesson is to parse the shape of the value rather than the name of the key.

Three days later, links inside markdown bodies required a separate cleanup pass. Content stored in two formats requires independent validation passes.

A third issue followed: missing last-modified dates in the static sitemap, caught post-launch.

We deliberately quote no traffic numbers for this migration: content was added through the same period, so no isolated metric exists. The value lies in the sequence and the errors avoided.

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.