A website migration SEO checklist comes down to five disciplines: crawl and benchmark before you touch anything, map every indexed URL to a permanent redirect, keep canonicals, hreflang and structured data intact on the new site, verify the move correctly in Search Console, and monitor closely for weeks after launch. Skip any one of these and you risk the most common migration outcome: a traffic drop that takes months to notice and longer to fix. This guide gives you the before, during and after checklist, redirect-map examples you can adapt, and the recovery timeline you should actually expect.
Why Website Migrations Lose SEO Rankings
Search engines rank URLs, not brands, so anything that breaks the connection between an old URL and its accumulated signals (backlinks, click history, topical relevance) resets part of what that page earned. Four causes account for most of the damage teams see after a migration: missing or incorrect redirects that return a 404 or send users to an unrelated page, content that gets thinner or disappears during a redesign, canonical or hreflang tags that point to the wrong version of a page, and staging or old-domain URLs that stay indexed alongside the new ones.
A migration does not need to hit all four to hurt rankings. Even one of these, applied across a large enough section of the site, is enough to show up as a real drop in Search Console within days of launch.
Large migrations add a fifth risk that is easy to miss: crawl budget. Google allocates its crawling effort partly based on how efficiently it can navigate a site, so a launch that briefly multiplies the number of URLs Googlebot has to check (old URLs still resolving, redirects firing, and new URLs all at once) can slow how quickly it discovers and re-indexes the pages that actually matter. A clean, minimal redirect map keeps that temporary spike as small as possible.
Types of Website Migration and Their Risk Level
Not every migration carries the same risk or the same required steps. Match your project to the row below before you scope the work, because a domain change needs steps a same-domain redesign does not.
| Migration Type | What Changes | SEO Risk | Needs Change of Address Tool | |---|---|---|---| | Domain change | example.com to example.net | High: full URL set changes, backlinks re-point | Yes | | Subdomain change | blog.example.com to example.com/blog | High: URL structure and often hosting change | Yes | | HTTP to HTTPS | Protocol only | Low if redirects are correct | No | | WWW to non-WWW (or reverse) | Host prefix only | Low if redirects are correct | No | | Replatform, same URLs | CMS or framework, URLs unchanged | Medium: rendering and markup can change | No | | Replatform with new URL structure | CMS plus new paths | High: combines replatform and redirect risk | Depends on domain | | Visual redesign, same URLs | Templates, content, navigation | Medium: content and internal links often change too | No |
Before the Migration: Crawl, Benchmark and Build Your Redirect Map
Everything in this phase produces the data your redirect map and your post-launch comparisons depend on. Do it two to four weeks before launch, not the night before. If your current site already carries technical debt, a migration is when it surfaces; pair this checklist with our technical SEO checklist for developers for the underlying fundamentals.
| Task | Why It Matters | |---|---| | Full crawl of the current site | Produces the definitive list of live, indexed URLs, not just what is in the sitemap | | Export indexed URLs from Search Console | Catches pages Google has indexed that a crawler might miss, such as old campaign pages | | Export top landing pages from analytics | Flags URLs with real traffic or conversions that must not be lost | | Backlink audit | Identifies pages with external links, so their redirect target gets priority | | Benchmark current rankings, traffic and Core Web Vitals | Gives you a before snapshot to compare against after launch | | Build the one-to-one redirect map | The single largest lever for how much ranking signal survives the move | | Password-protect or noindex the staging environment | Prevents duplicate, unfinished content from being indexed before launch | | Freeze content changes on the old site close to launch | Keeps your crawl and redirect map accurate through launch day |
Writing the Redirect Map: Next.js and Nginx Examples
Once your map exists as data, generating the actual redirects is mechanical. A simple pattern is a small JSON file your build reads from, so the map stays reviewable in a pull request instead of buried inside a config file:
[
{ "from": "/old-blog/post-1", "to": "/blog/post-1" },
{ "from": "/products/widget", "to": "/shop/widget" }
]
In Next.js, the redirects() function in next.config.js reads that map and returns an entry per rule:
const redirectMap = require("./redirect-map.json")
module.exports = {
async redirects() {
return redirectMap.map(({ from, to }) => ({
source: from,
destination: to,
permanent: true,
}))
},
}
Setting permanent: true returns a 308 status code, which search engines treat the same way as a 301: a permanent move whose ranking signals should transfer to the new URL. If you serve from nginx instead, the equivalent is a return 301 inside a matching location block:
location = /old-blog/post-1 {
return 301 /blog/post-1;
}
location = /products/widget {
return 301 /shop/widget;
}
Whichever platform you use, follow the same rules. Google's guidance on redirects is direct: use a 301 when you are sure the change is permanent, and reserve 302 for genuinely temporary moves, since Google treats a 302 as a signal to keep the original URL in its index. Google's site-move documentation adds that you should map each URL to its closest relevant equivalent rather than sending large batches of unrelated pages to the homepage, and keep chains short. If you are also changing rendering strategy as part of the move, for example from client-side rendering to server-side rendering, review our JavaScript SEO guide for React and Next.js alongside this checklist, since rendering changes carry their own indexing risk separate from the URL change itself.
Illustrative scenario: assume a 600-page marketing and blog site is moving from an older CMS to Next.js on the same domain, consolidating 40 thin or duplicate pages into 15 stronger ones and keeping the remaining 560 URLs as is. The redirect map then needs 575 entries (560 one-to-one, plus 40 old URLs mapped to their closest surviving page among the 15), built from a full crawl plus Search Console and analytics exports rather than a CMS export alone, since CMS exports commonly miss old campaign landing pages. For a team with an existing component library, mapping and implementing redirects at this scale typically takes a dedicated engineer 3 to 5 days, separate from the rest of the migration build, while messier or inconsistent legacy URL patterns should budget more. Treat this as a planning scope, not a universal benchmark: actual effort scales with how consistent your existing URL structure already is.
Launch Day: The During-Migration Checklist
Launch day itself is mechanical if the before-phase work is done. Work through this list in order, and do not skip verification steps to save time.
- Deploy redirects first, before DNS or traffic fully cuts over, and spot-check a sample of high-traffic and high-backlink URLs manually.
- Confirm canonical tags on the new site point to the new URLs, not leftover references to the old domain or staging environment.
- Verify hreflang tags resolve to the correct live URLs if you run multiple language or regional versions; a migration is a common way hreflang mappings quietly break, covered in depth in our international SEO and hreflang guide.
- Re-check structured data on templates that changed, using Google's Rich Results Test, since schema fields sometimes get dropped in a CMS or template migration; see our structured data guide for the schema types worth re-verifying.
- Update and submit the new XML sitemap in Search Console, and remove or update the old one once the move is confirmed.
- Update robots.txt so it references the new sitemap and does not accidentally block sections it should not.
- Use the Change of Address tool for a domain or subdomain move. It requires you to own both properties in Search Console under the same account, at the domain level, with a working 301 from the old homepage to the new one already in place; submit it separately from every verified variant of the old domain, including www and non-www, since Search Console's own help page notes it does not move subdomains automatically.
- Repoint analytics and conversion tracking so day-one traffic on the new site is not misread as a drop.
- Update internal links to point directly to new URLs instead of relying on redirects for every internal click.
After the Migration: Monitoring, Recovery Timelines and Rollback
The first weeks after launch are when small mistakes are still cheap to fix. Watch these signals daily for the first two weeks, then weekly for the next two months.
| Signal | Where to Check | What a Problem Looks Like | |---|---|---| | Crawl errors and 404s | Search Console Pages report, server logs | A spike in "Not found" URLs that match your redirect map | | Indexing status | Search Console Pages report, URL Inspection tool | Old URLs still indexed weeks after launch, or new URLs stuck unindexed | | Rankings for benchmark keywords | Rank tracker or Search Console Performance report | Sustained drops beyond the first one to two weeks | | Organic traffic and conversions | Analytics, compared to the pre-migration benchmark | A decline that does not recover on the expected timeline | | Googlebot crawl activity | Server logs | Crawling stalls, or concentrates on the wrong URL set |
Recovery speed depends almost entirely on redirect quality and site size. Google's site-move documentation describes rankings stabilizing over a period of weeks for a well-executed move, longer for large or complex sites, and recommends keeping redirects in place for at least a year, with no penalty for leaving them permanently. If monitoring surfaces a serious problem, such as a broken redirect rule affecting thousands of URLs or a site-wide canonical error, have a rollback plan ready: keep the old environment reachable and DNS changes easy to revert for at least the first 48 to 72 hours after launch.
Server log files are worth the extra setup during this window, because they show what Googlebot actually requested, not just what you intended it to crawl. A log file that still shows heavy Googlebot activity on old, redirected URLs weeks after launch usually means internal links, an old sitemap, or a feed somewhere is still pointing at them, which is a fixable problem only visible in the logs.
Common Website Migration Mistakes That Tank Rankings
- Redirecting everything to the homepage. It resolves the 404, but Google explicitly advises against sending many unrelated old URLs to one irrelevant destination; you lose the topical relevance that made the old page rank at all.
- Building the redirect map from the sitemap alone. Sitemaps often omit old campaign pages, paginated URLs and pages a previous team forgot to remove from the CMS, all of which can still hold indexed rankings and backlinks.
- Letting the old domain or staging site stay indexed. Two live, crawlable versions of the same content create duplicate content signals right when you need Google to trust the new version.
- Chaining redirects. Old URL to older URL to current URL adds latency and, at scale, risks Google not following the full chain.
- Removing redirects too early. Cutting them at 60 or 90 days because the dashboard looks fine is one of the most common ways teams lose value a migration otherwise preserved.
- Treating a visual redesign as risk-free because URLs did not change. Content, internal linking and template changes are reassessed by Google independent of the URL.
How Agentixly Approaches Website Migrations
Agentixly runs website migrations as a joint web development and SEO engagement, because the redirect map is a technical asset and an SEO asset at the same time. Treating them as two separate workstreams run by two disconnected teams is how gaps appear. A typical migration engagement moves through four phases.
- Audit and map (weeks 1 to 3). Full crawl, Search Console and analytics export, backlink audit, and a one-to-one redirect map reviewed line by line before it goes anywhere near code.
- Build (weeks 2 to 6, overlapping). Redirects implemented in your framework or server config, with canonicals, hreflang and structured data carried over deliberately rather than left to a template default.
- Launch and verify. The during-migration checklist above, executed and logged, plus Search Console verification and the Change of Address tool where it applies.
- Monitor (30 to 90 days). Daily then weekly checks against the pre-migration benchmark, with a named owner for any regression found.
What you get: a redirect map you own as a plain file in your repository, not a black box inside a third-party tool, plus a written record of what changed and why. If the migration is part of a larger custom web application rebuild or an accessibility push, we plan the SEO, engineering and accessibility work as one project instead of three.
The Bottom Line
A website migration does not have to cost you rankings. The teams that come through clean treat the redirect map as the center of the project, verify every technical detail on launch day instead of assuming the CMS handled it, and keep watching for weeks after everyone else has moved on to the next project. The teams that lose traffic almost always skipped the crawl, guessed at the redirect map, or pulled redirects too soon.
If you have a migration, replatform or redesign on the roadmap, Agentixly's web development team can build the redirect map and the technical SEO checklist into the project plan from day one instead of firefighting after launch. Talk to us before you set a launch date, not after traffic drops.