Website Migration SEO Checklist: Keep Rankings and AI Citations

A website migration is any change that moves, restructures, or re-platforms your URLs, and it is the most common cause of sudden organic traffic loss. In 2026 it has a second failure mode: a migration can quietly break your AI visibility even when rankings survive. This checklist covers both, in the order the work actually happens.

Know which migration you are running

The higher the risk, the more of the checklist below is mandatory rather than optional. Wherever you can, avoid stacking a domain change on top of a replatform: if traffic drops, you want to know which change caused it.

The four phases at a glance

Every migration checklist that ranks for this topic uses the same four phases, and for good reason: each one has a different owner and a different way to fail. This is the summary; the detailed checks follow.

Before launch: capture the baseline

You cannot prove a migration worked, or diagnose one that did not, without a record of the site before it changed.

• Crawl the current site in full: every URL, status code, title, canonical, and structured data type.
• Export Search Console performance data for your top pages and queries. Search Console keeps 16 months; save it before you need it.
• Export your top linked pages from a backlink tool: the URLs with the most referring domains.
• Export top landing pages from analytics by traffic and by conversions.
• Run your AI prompt set and record which of your URLs each engine cites. Method in measuring brand visibility in ChatGPT.
• Inventory your structured data, including every @id.
• Decide the fate of every URL: keep, merge, or retire.

Before launch: build the redirect map

• Map every URL with traffic, links, or citations to its new equivalent, one to one.
• Redirect to the closest equivalent, never wholesale to the homepage, which search engines tend to treat as a soft 404.
• Use server-side 301 or 308 redirects, not JavaScript or meta refresh.
• Flatten chains. Update any existing redirects so old URLs point directly at their final destination.
• Test the map on staging by crawling the full list of old URLs against it.

Before launch: staging hygiene

• Staging sits behind authentication, not just a noindex tag that someone will forget.
• The launch runbook removes staging noindex and Disallow rules. Write the step down; it is the most common launch-day disaster.
• Content parity is confirmed. Key copy, headings, internal links, and structured data all carried over, including facts on the About page.
• Entity identifiers are planned. Keep your Organization @id stable. If the domain changes, decide the new @id once and update every reference to it.
• The new site passes the technical SEO checklist for AI search, including rendering without JavaScript.

Launch day

• Deploy redirects with the new site, not an hour after it.
• Check production robots.txt and meta robots immediately.
• Crawl the old URL list: every URL should return a single 301 to a 200.
• Submit the new sitemap in Search Console and Bing Webmaster Tools.
• For a domain change, use Search Console’s Change of Address tool, with both old and new properties verified.
• Push changed URLs through IndexNow so Bing and other participating engines recrawl sooner.
• Validate structured data on every key template.
• Check canonical, hreflang, and Open Graph URLs point at the new locations.

The first 90 days

• Week one, daily: Search Console page indexing, crawl stats, and new 404s.
• Fix 404s as they appear from logs and Search Console, redirecting any with links or traffic.
• Weekly: compare rankings and traffic against your baseline, page by page.
• Re-run your AI prompt set at 2, 6, and 12 weeks and confirm citations resolve to live pages.
• Update external profiles: your Google Business Profile website field, LinkedIn, directories, sameAs targets, and the official website statement on Wikidata.
• Ask your most valuable linking sites to update their links.
• Keep redirects for at least a year, and indefinitely where you can.

If traffic drops after launch: triage in this order

Some dip in the first two to four weeks is normal while engines recrawl. A drop that deepens after that, or one concentrated in a few sections, has a cause, and it is usually one of these. Check them in order, because the first ones are the most common and the fastest to fix.

1. Robots and noindex. Fetch production robots.txt and view source on key templates. A shipped staging rule explains a sudden, site-wide fall.
2. Redirects. Crawl the old URL list again. Look for 404s, chains, and redirects that land on the homepage or a category instead of the matching page.
3. Rendering. Compare raw HTML with the rendered page for your top templates. Content that only appears after JavaScript runs is invisible to many crawlers.
4. Content parity. Diff the old and new versions of your top 20 landing pages. Lost sections, headings, internal links and FAQs explain page-level drops.
5. Canonicals and internal links. Canonicals pointing at old or staging URLs, and navigation still linking through redirects, both slow recovery.
6. AI citations. Re-run your prompt set. If engines still cite old URLs that now fail, fix those redirects first; they are the ones carrying live referral traffic.

The AI-specific risks

Traditional migration checklists stop at rankings. These five risks are new, and they are easy to miss because nothing looks broken.

1. Entity split. If your Organization @id changes, engines can end up with two partial records of your brand. Keep identifiers stable, or change them once, consistently, everywhere. See Organization schema for AI search.
2. Orphaned citations. AI answers and the articles they draw on keep old URLs in circulation long after a move. Without redirects, those citations lead to errors, and engines learn to stop trusting them.
3. Rendering regressions. A move to a JavaScript-heavy framework can leave crawlers that do not execute JavaScript with an empty page. See JavaScript rendering and AI crawlers.
4. Lost facts. Rewritten About and service pages often drop the plain facts, such as founding year, location, and founders, that engines used to identify you.
5. New bot blocking. A new host or CDN can ship with AI bot blocking switched on. Check it on launch day.

Where migration planning starts

The cheapest migration fix is the one made before launch. If you are planning a redesign, replatform, or domain move and want it done without losing rankings or AI visibility, our web development service runs migrations with this checklist built in, from baseline to 90-day monitoring.