Website Migration SEO: The Checklist That Keeps Your Rankings
Dominik Breitbach founded taismo, an SEO and GEO agency from Munich. He guides website migrations on the technical side so that hard-earned rankings survive the move. His focus: Clean redirects, indexability, and Core Web Vitals.
🔄 Last updated: 31 July 2026
A website migration is any change to a site’s domain, URL structure, platform, or design that alters how search engines access it. Migrations are among the most common causes of sudden ranking losses, and the damage rarely comes from the new look. It comes from what breaks behind the scenes: Missing redirects, lost content, and technical errors nobody tested. This checklist walks you through a migration that keeps your visibility intact instead of resetting it overnight.
👉 Relaunch on the horizon? We protect your rankings with an SEO audit before anything moves.
Why a website migration puts rankings at risk
A migration changes many things at once: A new structure, new URLs, a different content management system, rewritten pages. For Google, that is like a well-known store moving overnight and taking down every sign. Your rankings hang on specific URLs that Google has crawled, evaluated, and linked into its index over months or years. When those URLs disappear without a clear forwarding address, the accumulated trust does not transfer. It evaporates.
Even a technically clean move needs patience. Google’s site move documentation states that a medium-sized website takes a few weeks for most pages to be processed, and larger sites take longer. A migration with errors stretches that window into months, and the errors typically surface only after traffic has already dropped. That is why website migration SEO is not a task you check off after launch. It is part of the project plan from day one, and handled well, a migration often leaves you stronger than before: Faster templates, cleaner structure, better content.
The five most common causes of ranking losses
Almost every migration disaster traces back to one of five causes:
- Missing or wrong redirects: Old URLs return errors or point to unrelated pages, so their authority never reaches the new site.
- A new URL structure without a mapping plan: Every renamed address cuts the thread to rankings and backlinks the old URL had earned.
- Deleted or shortened content: Pages that ranked are removed or trimmed, and the rankings leave with them.
- The forgotten noindex block: The staging environment was hidden from Google, and the block ships to the live site.
- Technical regressions: Slower load times, broken internal links, redirect chains, or a misconfigured robots.txt.
Every one of these causes is preventable. What prevents them is not luck on launch day but a structured process, and that process is the rest of this article.
What counts as a website migration
The term covers more than a domain move. Any of these five projects is a migration in the SEO sense, and the risk grows with the number of things that change at once:
| Migration type | What changes | SEO risk |
|---|---|---|
| Redesign on existing URLs | Templates, layout, code | Moderate. URLs survive, but content, internal links, and load times often change silently. |
| URL restructuring | Paths, slugs, categories | High. Every changed URL needs a mapped redirect. |
| CMS or platform switch | The system that generates every page | High. URLs, metadata, and structured data are all rebuilt. |
| Domain move | The address of the entire site | Highest. All signals must transfer to a new host name. |
| Protocol or hosting change | HTTPS switch, new server | Low to moderate. Mostly a redirect and performance question. |
The practical rule: Change one variable at a time. A redesign this quarter and a domain move next quarter are two controlled projects. Both in one weekend is a blind flight, because if rankings drop, you cannot tell which change caused it. Website redesign SEO, CMS migration SEO, and domain migration SEO all follow the same playbook below; they differ only in how many chapters apply.
When to schedule the move
A migration always carries risk, so pick the moment deliberately. Avoid the phases your business depends on: A shop that lives on holiday sales does not migrate in November. A quieter period leaves room to absorb and fix a temporary dip without losing your most important revenue weeks.
Just as important is a honest buffer. A migration pushed through under deadline pressure saves time in exactly the two places that get expensive later: Redirect mapping and testing. Plan the SEO preparation as a fixed work package in the project schedule, not as an afterthought in the final week. The right launch date is one the business can absorb and the team can prepare for with care.
Before you migrate: Benchmark everything
The most important part of a migration happens before the new site goes live. Without a complete inventory of the old site, you are flying blind and will not even know what you lost.
Start with a complete list of every existing URL, enriched with rankings, traffic, and backlinks. Three sources combined catch nearly everything: The XML sitemap, a full crawl of the old site, and the page and query data in Google Search Console. Record which keywords your most valuable pages rank for and screenshot or export the numbers, because after launch the old data is gone. This benchmark is the map the whole migration navigates by, and it is the first deliverable of a pre-migration SEO audit. It also settles priorities: A page with rankings, traffic, or backlinks gets first-class treatment during the move; a page with none of the three can be retired.
URL mapping and 301 redirects: The heart of the migration
When URLs change, the redirect map decides whether the migration succeeds or fails. Every old URL that no longer exists in identical form needs a permanent redirect to the new page that matches its content most closely. One row per URL, old address on the left, new address on the right. This unglamorous spreadsheet is the single most important document of the entire project.
Use a 301 redirect for every mapping, because only a permanent redirect tells Google to transfer the accumulated authority to the new URL. Three rules make the map work. First: Redirect to the matching page, never wholesale to the homepage. Google’s redirect documentation classifies irrelevant redirects as soft 404s, so the authority you tried to save never arrives. Second: Avoid chains. Googlebot follows up to 10 redirect hops before it gives up, and every hop slows crawling and dilutes the signal, so point each old URL straight at its final target. Third: Keep the redirects in place for at least a year. Google recommends this explicitly, because recrawling every old URL takes time, and browsers and backlinks keep using old addresses far longer than you expect. While you map, design the new addresses to last; our guide to URL structure covers the rules that spare you the next migration.
301 or 410? Decide by value, not by habit
Not every old URL deserves a redirect. When a page is removed for good and has no successor, the honest answer is the HTTP status code 410 (Gone): It declares the content permanently removed. The classic mistake is a 301 to the homepage instead. Google treats a redirect to an unrelated target as a soft 404, so nothing is saved and the index just fills with noise. Make the call based on the value and intent of each URL, not on what the redirect plugin makes easy: If the page has rankings, traffic, or backlinks and a close successor exists, a 301 carries those signals over. If there is no successor, serve a 410 and let the URL leave the index cleanly. According to Google’s documentation on HTTP status codes, search treats 404 and 410 the same in the end; the difference is how clearly your signal states the intent.
Content and metadata: Carry over what ranks
Rankings live in content. When texts vanish or shrink during a relaunch, the rankings usually follow. So make it a rule that the content of every ranking page survives the move at least intact, ideally improved. A migration is a fine moment to upgrade thin pages and merge overlapping ones. It is the worst possible moment to delete proven content because it does not fit the new design.
The same discipline applies one level up. Title tags and meta descriptions of important pages are carried over deliberately or improved deliberately, never regenerated at random by the new system. Heading structure, image alt attributes, and above all the internal links between your pages belong on the same checklist. Internal links are easy to lose wholesale when navigation and templates change, and they are a ranking signal Google reads on every crawl. The more of your proven on-page work survives the move, the more stable your rankings stay.
Images and media migrate too
Images are the most commonly forgotten asset in a migration. They have URLs of their own, they rank in image search, and they bring traffic. When every image path changes and nobody redirects the old ones, that visibility is gone. Check whether your important images keep their paths, and redirect them like pages if they cannot.
At the same time, a migration is a good opportunity for image hygiene: Complete the missing alt attributes, and replace oversized files with compressed modern formats such as WebP. That improves load times and user experience. Just make sure the optimization is planned rather than accidental, so proven image rankings do not break as a side effect.
Technical foundation: Crawling, indexing, speed
The new site must be at least as good technically as the old one, because Google will compare them whether you do or not. Before launch, verify three things: The robots.txt does not block anything important, an up-to-date XML sitemap is ready to submit, and every relevant page is indexable. A common and expensive regression is a slower site: If the relaunch worsens your Core Web Vitals, visibility suffers even though everything looks prettier, because page experience feeds into Google’s ranking systems.
Equally important are internal links without broken targets and a logical page hierarchy that makes orientation easy for crawlers and visitors alike. How much these foundations decide is exactly what our guide to technical SEO is about. A migration that neglects the technical layer throws away the biggest advantage a fresh start offers.
We handle the technical side of your website migration, from redirect mapping to indexability to the monitoring after launch, so your visibility survives the move and comes out stronger.
Canonicals and duplicate content
A move easily produces several reachable variants of the same page: With and without www, over HTTP and HTTPS, with and without a trailing slash. Each variant splits signals and creates duplicate content. Enforce exactly one valid version per page with server-side redirects, and give every page a self-referencing canonical link pointing at its own clean URL.
Parameter and archive URLs are the second source of duplicates, especially after a platform switch. Crawl the new site shortly after launch, look for unexpected twins, and canonicalize them properly. That keeps authority bundled on one address per topic instead of spread across four identical ones.
CMS migration: The special pitfalls
If the migration also swaps the content management system, complexity jumps. Every CMS generates URLs, meta fields, and internal structures its own way. What was automatic in the old system must be consciously rebuilt in the new one: Index control, title and meta description output, structured data, and redirect management.
The typical CMS surprise is auto-generated extra URLs. Category archives, tag pages, filter combinations, author pages: The new system creates them unasked, and each one is a potential duplicate. After the move, crawl the site and compare what the CMS actually publishes against what you planned, then control the surplus with noindex or canonicals. Verify the structured data output too, because machine-readable markup rarely survives a platform switch untouched, and it is what connects your pages to rich results and AI answers. This technical stretch of a CMS migration is where specialized support pays for itself fastest.
Domain moves: The extra steps
A domain migration adds three obligations on top of everything above, because this time the host name itself changes and every external signal on the web still points at the old one.
First: Keep the old domain. The redirects from old to new must run for at least a year by Google’s own recommendation, and in practice much longer, because backlinks you do not control will reference the old domain for the rest of its life. Letting the registration lapse hands your redirect traffic, and in the worst case your reputation, to whoever registers the domain next. Budget the old domain as a running cost for years, not months.
Second: Tell Google and your linkers. Use the Change of Address tool in Search Console; it exists precisely to speed up a domain transfer. Then look at your backlink profile and contact the sites behind your most valuable links: A direct link to the new URL is stronger than a link that arrives through a redirect, and most webmasters update links when asked. The same applies to every touchpoint you control yourself: Google Business Profile, ad destination URLs, social profiles, directory entries, and email signatures should point at the new domain on day one.
Third: Update international annotations. If your site serves several language or country versions, the hreflang annotations must reference the new URLs immediately, on every version, in both directions. Half-updated hreflang pairs stop validating and quietly drop your international pages out of their local results, which is a loss the domain redirects alone cannot prevent.
Staging and the noindex trap
New sites are built on a staging environment that is hidden from Google, usually with a noindex directive or a robots.txt block. That is correct while the site is unfinished. The classic, expensive mistake: The block ships to production. The new site goes live, looks perfect, and quietly tells Google not to index it. Traffic does not dip; it collapses.
So the first line of every launch checklist reads: Remove the block, then actively confirm the live site is indexable. The reverse error matters too. A staging site that leaks into the index competes with the real one and creates sitewide duplicates, so keep staging behind authentication, not just behind a robots.txt line that any crawler may ignore. Both failures are fully avoidable when the switch is a planned step instead of an assumption.
On launch day
If the preparation stands, launch day is routine. A few actions have to happen immediately: Remove the indexing block, activate the redirect map, and spot-check that the most valuable old URLs resolve to their new targets with a single 301. Submit the updated XML sitemap in Google Search Console so Google discovers the new structure fast. For a domain move, additionally use the Change of Address tool in Search Console; Google built it precisely to speed up this transfer.
Then walk the site like a first-time visitor: Are the top pages reachable, does the navigation work, do forms submit, does anything throw an error page? Every mistake found on launch day is cheap; the same mistake found in week four has already cost rankings. A calm launch is not luck. It is the visible result of the benchmark and the redirect map.
After launch: Monitor for weeks, not days
After the go-live, the migration enters its proving phase. Watch Google Search Console closely for the first weeks: Is the number of indexed pages stable? Do 404 errors pile up? Are there warnings about redirects or indexability? These signals expose problems early, while they are still cheap to fix.
Ranking fluctuations in the first days are normal; Google is re-evaluating the new structure, and its own documentation warns of temporary traffic changes during a move. What matters is the trend over several weeks. If visibility holds or recovers quickly, the migration worked. If it drops and stays down, the cause is almost always a redirect or indexing problem, and finding it fast limits the damage. That is why the monitoring phase belongs in the project plan, and why many companies hand it to ongoing SEO support: The weeks after launch decide whether the migration protected years of work.
What to expect: A realistic timeline
Knowing the normal course of a migration keeps you from panicking at noise and, more dangerously, from ignoring a real problem. A typical clean migration follows this pattern:
- Days 1 to 14: Googlebot recrawls the old URLs, follows the redirects, and starts swapping index entries. Rankings and impressions fluctuate; single keywords jump or dip daily. This phase is noisy by design and proves nothing yet.
- Weeks 2 to 6: The bulk of a medium-sized site is processed; Google’s documentation names a few weeks as the expected window. Indexed page counts in Search Console approach the old level, and rankings settle back toward their benchmarks.
- Months 2 to 3: Large sites and domain moves need this long for full processing. Image search and long-tail rankings are typically the last to recover, because those URLs are recrawled least often.
The decision rule: Judge against the benchmark, not against feelings. If after four to six weeks the indexed page count keeps falling or visibility sits clearly below the pre-migration level, stop waiting and start debugging, and check the redirect map first, because that is where the cause hides in most failed migrations. Fixed early, a redirect error costs a few weeks of traffic. Diagnosed in month four, it has cost rankings that took years to earn, and rebuilding them costs far more than the migration itself did.
The tools that carry a migration
A clean migration is steered by data, not by gut feeling, and four kinds of tools provide it. A crawler captures the complete old and new site, exposes broken links, redirect chains, and missing canonicals, and delivers the full URL list for the redirect map. Google Search Console shows what is indexed, which queries bring traffic, and which errors appear after launch; it is the most important free source in the whole project.
A rank tracker records the positions of your most important keywords over time, so you can tell a normal fluctuation from a real loss. And a performance tool such as PageSpeed Insights verifies that the new site keeps up with the old one on load times. The specific tool brand matters less than one principle: Measure the same metrics before, during, and after the migration. Only identical metrics make the comparison honest, and only the comparison tells you the migration succeeded.
The website migration SEO checklist
- Benchmark: Inventory all URLs with rankings, traffic, and backlinks.
- Redirect map: One matching 301 target per old URL, no chains; 410 for pages removed for good.
- Secure content: Carry over or improve top content and metadata, never lose it silently.
- Check the tech: Robots.txt, XML sitemap, indexability, load times, internal links.
- Canonicals: Self-referencing on every page, duplicates cleanly canonicalized.
- Defuse the noindex trap: Remove the staging block at launch, confirm indexability.
- Launch: Activate redirects, submit the sitemap, spot-check the top URLs.
- Monitor: Watch Search Console, rankings, and error pages for several weeks.
We run the technical side of your migration: Redirect mapping, indexability, Core Web Vitals, and the monitoring afterwards. So the fresh start strengthens your visibility instead of costing it.
FAQ about website migration SEO
How long does it take for rankings to recover after a website migration?
Google states that a medium-sized site move takes a few weeks to process, and larger sites take longer. Small fluctuations in the first days are normal; a clean migration usually stabilizes within a few weeks, while a lasting drop points to a redirect or indexing error.
Do you lose SEO when you redesign a website?
Not if the redesign keeps URLs, content, and performance intact. Rankings are lost through side effects: Deleted texts, changed URLs without redirects, lost internal links, or slower templates. A redesign with a benchmark and a test plan is safe.
Do I need to redirect every old URL?
Redirect every URL that has rankings, traffic, or backlinks; those redirects are non-negotiable. For pages that had none of the three, a redirect is optional. When in doubt, set one redirect too many rather than lose a valuable page’s signals.
What happens to pages that are removed for good?
Pages without a content successor should return the status code 410 (Gone), which marks them as permanently removed. A 301 to the homepage or an unrelated page looks like a shortcut but is treated by Google as a soft 404 and rescues no rankings.
How long should 301 redirects stay in place?
Google recommends keeping migration redirects for at least one year. Backlinks, bookmarks, and cached results keep using old URLs long after launch, and every redirect you remove early cuts a path that still carried signals.
Should SEO be involved before or after the migration?
Before, without exception. The benchmark and the redirect map must exist before the go-live. Bringing SEO in after the launch means repairing damage instead of preventing it, and repair costs far more time than preparation.
Sources
- Google Search Central: “Site Moves with URL Changes“, Google, 2026.
- Google Search Central: “Redirects and Google Search“, Google, 2026.
- Google Search Central: “HTTP Status Codes, and Network and DNS Errors“, Google, 2026.
- Google Search Central: “Understanding Core Web Vitals and Google Search Results“, Google, 2026.
