--- title: 'The website migration SEO checklist: before, launch day, and the 90 days after' url: 'https://mountainairweb.com/blog/website-migration-seo-checklist' markdown: 'https://mountainairweb.com/blog/website-migration-seo-checklist.md' date: '2026-09-02' description: 'Short answer: a website migration keeps its rankings when three things are true. Before the build, you have a complete inventory of every URL and what it currently ranks for. On launch day, every one of those URLs answers with a single-hop permanent redirect (301 or 308) to its new home, with the p…' taxonomy: category: - Migrations tag: - migrations - 'technical seo' - redirects --- [Migrations](https://mountainairweb.com/blog/category:Migrations) September 2, 2026 9 min read # The website migration SEO checklist: before, launch day, and the 90 days after The checklist we run on every platform or domain move, with Google's current site-move rules and the extra lines for AI crawlers. Nicholas Murray Author **Short answer:** a website migration keeps its rankings when three things are true. Before the build, you have a complete inventory of every URL and what it currently ranks for. On launch day, every one of those URLs answers with a single-hop permanent redirect (301 or 308) to its new home, with the production `robots.txt`, no stray `noindex`, and new sitemaps submitted within the hour. For the 90 days after, someone owns the 404 log and the Search Console reports and acts on them weekly. Google's own guidance says to keep those redirects for "generally at least 1 year" and expects a medium-sized site to take "a few weeks or more" to switch over ([Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)). This page is the hands-on list. If you want the reasoning behind it, including what a normal dip looks like versus a real problem, read [how to migrate a website without losing your rankings](https://mountainairweb.com/blog/migrate-a-website-without-losing-rankings) first; this post does not repeat it. Each item has a one-line reason, because a checklist nobody understands gets skipped under deadline pressure. ## Phase 1: Before the build starts This phase is where migrations are won. If the inventory is incomplete, nothing on launch day can fix it. - **Crawl the live site and archive the crawl.** Every URL, status code, title, meta description, H1, canonical, hreflang and inbound internal-link count. This is the baseline you diff against after launch. - **Merge in URLs the crawl cannot see.** Search Console pages with impressions (last 16 months), analytics landing pages, XML sitemaps, server logs and backlink targets. Google itself recommends building the URL map from sitemaps, logs, analytics and CMS exports, not a crawl alone ([Google](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)). - **Include media and documents.** PDFs, images and downloads rank and carry links; they belong in the map. - **Export the content, or scrape it.** Legacy and custom CMSs often have no export. We write a scraper per template (`DOMXPath` in PHP, or a headless browser for JavaScript-rendered pages) that captures title, body, media and the old URL against every item, so the redirect map writes itself from the import. - **Benchmark rankings, traffic and Core Web Vitals.** Top 100 queries by clicks, traffic by landing-page type, CWV field data per template. Without a baseline, "it got worse" is an argument instead of a fact. - **Decide what will not change.** URLs, titles, metas, H1s and body copy stay unless a change is deliberate and logged. Rewrites during a migration are the commonest self-inflicted loss. - **Write the redirect map (see below) and get it signed off.** One old URL to one new URL, single hop, permanent. No catch-all to the home page. - **Plan hreflang and canonicals for the new URLs.** Google's site-move doc is explicit that hreflang annotations must be "updated to use the new URLs," and canonicals must point at production, never staging. - **Build the new `robots.txt` and `llms.txt` now, not on launch day.** Both files move with the site. Decide which AI user agents you allow (see Phase 2). - **Test on staging.** Crawl staging, confirm it is blocked from search, confirm every redirect rule fires in a list-mode crawl of the old URLs, validate structured data on every template. - **Lower DNS TTL.** Google suggests doing this "at least a week in advance" for a host move ([Google](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes)); 300 seconds is our default. - **Verify every domain variant in Search Console.** If the domain is changing, Google's June 2026 update wants a Change of Address request for "all subdomains and the www and non-www variants" of the old domain ([Search Engine Journal](https://www.searchenginejournal.com/google-tightens-requirements-for-domain-migrations/579781/)). You cannot submit for a property you have not verified. - **Freeze content.** Set a date after which nothing is published on the old site, so the import is complete. ### The redirect map The map is a spreadsheet, then a server rule set. Keep both. A sample of what ours looks like: | Old URL | New URL | Type | Notes | |---|---|---|---| | `/about-us.html` | `/about` | 301 | Template change, same content | | `/news/2019/03/spring-update.php` | `/blog/spring-update` | 301 | Date folders dropped; slug preserved | | `/products/widget-a` | `/services/widgets` | 301 | Consolidated; closest topical match, not home | | `/downloads/brochure-2018.pdf` | `/media/brochure.pdf` | 301 | Linked from three external sites | | `/blog/page/2/` | `/blog` | 301 | Pagination removed; one hop, not via `/blog/page/` | | `/fr/a-propos` | `/fr/a-propos` | 200 | Unchanged; listed so the diff shows it was checked | | `/promo-2020` | (none) | 410 | Nothing equivalent exists; a 410 is honest, a redirect to home is not | | `/old-site/(.*)` | `/archive/$1` | 301 regex | Pattern rule, tested against 20 real URLs | Two rules of thumb. Use 301 or 308 and never 302: Google says the indexing pipeline uses a permanent redirect "as a signal that the redirect target should be canonical" and does not do that for temporary ones ([Google](https://developers.google.com/search/docs/crawling-indexing/301-redirects)). And test for chains: Google tolerates up to 10 hops but asks for "ideally no more than 3 and fewer than 5", and AI crawlers are stricter (Phase 2). On WordPress we use the Redirection plugin (2 million+ active installs) because it imports the map from CSV, logs every 404 after launch and can bulk-redirect the ones that matter ([Redirection](https://wordpress.org/plugins/redirection/)). Our last enterprise rebuild shipped 402 rules this way with 404 logging on from the first minute; that log, not the crawl, is what found the campaign URLs nobody had on the list. On a Grav site the same map becomes server rules, exported from the same spreadsheet. ## Phase 2: Launch day Order matters here. Redirects before DNS, verification before anyone sends the announcement email. - **Deploy the redirect rules on the new server before switching DNS.** The first crawler to arrive must find them. - **Confirm the production `robots.txt` is live.** Google's own checklist ends with removing any `noindex` or robots blocks "that were only needed for the migration." A staging block pushed live de-indexes a site in days. - **Confirm no indexable page carries `noindex`.** Crawl the new site in the first hour and filter for it. - **Crawl the old URL list in list mode with redirects followed.** Read the redirect report for 404s, chains and temporary redirects. Fix before you do anything else. - **Diff titles, metas, H1s and canonicals against the baseline.** Anything that changed without a logged decision is a bug. - **Check hreflang reciprocity on a sample of each language pair.** Misaligned hreflang and canonical tags are the usual multilingual failure. - **Submit the new sitemap and keep the old one.** Google advises keeping both: the old sitemap's indexed count should fall while the new one's rises, and you remove the old one only when the move is done. - **Submit Change of Address for every old variant** if the domain changed. The tool forwards signals for "180 days after you start migration," and Google asks you to keep the redirects "at least 180 days, longer if you still see any traffic" ([Google Search Console Help](https://support.google.com/webmasters/answer/9370220)). - **Run URL Inspection on the home page and one page per template.** Request indexing for the templates, not every page. - **Run the Rich Results Test on one page per template.** New themes drop schema quietly. - **Re-test Core Web Vitals on the same pages you benchmarked.** A regression here shows up in rankings weeks later, when it is harder to attribute. - **Keep the old server running and watch both logs.** Google: shut the old host down "once the traffic to the old provider reaches zero." - **Confirm `llms.txt` returns 200 at the root with no redirect.** One May 2026 test found PerplexityBot "does not follow redirects on `/llms.txt` at all" ([CaptainDNS](https://www.captaindns.com/en/blog/ai-crawlers-redirects-handling-gptbot-claudebot-perplexitybot)). - **Confirm the AI user agents you intend to allow are allowed.** The same study observed GPTBot, ClaudeBot and PerplexityBot abandoning chains after about 5 hops, and the search bots (OAI-SearchBot, Claude-SearchBot) after about 3. The vendors' own docs are clear on which agent does what: OpenAI's OAI-SearchBot surfaces sites in ChatGPT search while GPTBot is for training ([OpenAI](https://developers.openai.com/api/docs/bots)); Anthropic runs ClaudeBot for training, Claude-SearchBot for search and Claude-User for user-requested fetches ([Anthropic](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler)); PerplexityBot is search-only and not used for training ([Perplexity](https://docs.perplexity.ai/guides/bots)). Decide per agent, write it down, and carry the same rules to the new host. A `robots.txt` that silently reverts to "allow everything" or "block everything" is a migration bug like any other. - **Check analytics is firing on the new site.** Real-time reports are the quickest signal that the launch is being seen. ## Phase 3: The 90 days after The move is not finished at launch. Google says a medium-sized site takes "a few weeks or more" to show the new URLs, and the AI answer engines are slower: the observed stabilisation window for AI answers to settle on new URLs was "15 to 30 days" against 7 to 14 for Google ([CaptainDNS](https://www.captaindns.com/en/blog/ai-crawlers-redirects-handling-gptbot-claudebot-perplexitybot)). Watch, don't react to the first week. - **Week 1, daily: 404 log.** Redirect anything with inbound links or traffic; let genuine junk 404. - **Week 1, daily: Search Console Page indexing report.** New "Not found" or "Redirect error" entries are bugs, not noise. - **Week 1: Crawl Stats.** A temporary drop in Googlebot's crawl rate right after launch "followed by a steady increase over the next few days" is normal, per Google. A drop that keeps dropping is not. - **Weeks 2 to 4, weekly: rankings sample and traffic by landing-page type.** Compare against the baseline, not against last week. - **Weeks 2 to 4, weekly: old vs new sitemap indexed counts.** The crossover is the clearest sign the move is being understood. - **Week 4: Core Web Vitals field data.** The 28-day window has now rolled over to the new site; this is your first honest CWV reading. - **Monthly: backlink profile.** Links still pointing at old URLs are fine while the redirects stand; links to URLs you forgot are the ones to fix. - **Day 90: review and tidy.** Prune redirect rules that have zero hits and no links. Keep everything else for the full year. - **Day 90: AI visibility check.** Ask ChatGPT, Claude and Perplexity the queries you ranked for before and confirm the citations use the new URLs. ### Signals to watch and where | Signal | Where | What good looks like | |---|---|---| | Page indexing (coverage) | Search Console, Pages report | New URLs move to Indexed; old URLs show as "Page with redirect" | | Index count by sitemap | Search Console, Sitemaps | Old sitemap falls, new sitemap rises, then old sitemap removed | | Crawl behaviour | Server logs, Search Console Crawl Stats | Dip at launch, steady recovery; 200s and 301s, few 404s and no 5xx | | 404s | Redirection plugin log, server log, Search Console "Not found" | Volume falls week over week; new entries get a rule or a 410 | | Core Web Vitals | Search Console CWV report, CrUX, PageSpeed Insights | Same or better than the pre-launch benchmark per template | | Rankings sample | Rank tracker on the top 100 queries from the baseline | Positions hold within a few places after the normal dip | | Traffic by page type | Analytics landing pages vs the baseline | Recovery to baseline within two to six weeks | | AI citations | Manual queries, referral traffic from AI assistants | New URLs cited within 30 days | ## What to do next Print this and work it in order; the honest effort split is roughly 60% before the build, 10% launch day, 30% after. If you want it run for you, [our migration service](https://mountainairweb.com/services/migrations) covers the inventory, the scrape when there is no export, the redirect map and the 90-day watch, and a [free audit](https://mountainairweb.com/free-audit) will tell you whether an existing plan has the gaps we see most. ## More from the journal [See all posts](https://mountainairweb.com/blog) MigrationsAug 12, 2026 ### How to migrate a website without losing your rankings Most migrations lose traffic for a few weeks. Some never get it back. The difference is a redirect… [How to migrate a website without losing your rankings](https://mountainairweb.com/blog/migrate-a-website-without-losing-rankings) AI & SearchOct 7, 2026 ### What AI search optimization actually means (and what it costs to ignore) GEO, AEO and AI visibility are the same job with different labels. Here is how ChatGPT, Perplexity, Google… [What AI search optimization actually means (and what it costs to ignore)](https://mountainairweb.com/blog/what-ai-search-optimization-means) --- ## Navigation - Parent: [Blog](https://mountainairweb.com/blog.md) - Previous: [What a WordPress maintenance plan should actually cover (and what most leave out)](https://mountainairweb.com/blog/what-a-wordpress-maintenance-plan-should-cover.md) - Next: [The WCAG 2.2 AA checklist for marketing websites (what to test, how, and who owns it)](https://mountainairweb.com/blog/wcag-2-2-aa-checklist.md)