Agent-ready migration checklist
A checklist for keeping AI engines able to read and find your pages through a site migration or redesign, so you do not go invisible the day you relaunch.
The most dangerous day for your AI readiness is launch day. The redesign looks gorgeous, the team celebrates, and somewhere under the new theme the structured data is gone, the URLs changed, and half your pages just became unreachable to the engines that used to read them.
Nobody notices, because a migration is reviewed by humans looking at how it looks. The machine reading is invisible, so the part that broke is invisible too.
What this guide does
It is a checklist for getting through a migration or redesign without going dark to AI engines. The goal is that the new site reads to a machine at least as well as the old one did, instead of relaunching into silence.
Why migrations break readiness
A migration touches exactly the things engines depend on, all at once.
- Structured data gets dropped when templates are rebuilt.
- URLs change, and the pages engines already read return a 404.
- Internal links break, orphaning pages no machine can now reach.
- The clean labels that made a page legible get stripped by the new theme.
Each of these is invisible in a visual review. The page renders, so it passes human eyes. The machine layer underneath is the part that quietly fell off.
Before the move, baseline
You cannot tell what a migration broke if you never recorded what worked. So scan the current site first.
Record which pages read well, which schema is present and valid, and which engines name you on which prompts. This baseline is the entire point of comparison later. Skip it and you are guessing whether the new site is better or worse, with no way to know.
Preserve the URLs that read well
Engines have already discovered and read your current pages at their current addresses. Change the address without a redirect and you throw that away.
List the URLs that read well today and make sure each one maps to a working address on the new site, with redirects in place. A page that moves silently is a page an engine has to rediscover, if it ever does.
Carry the structured data across
This is the one migrations break most. The old pages had schema. Do not assume the new ones inherited it.
Treat every important page's markup as something to verify after the rebuild, not something the platform carried for you. A new template can render a beautiful page with none of the labels that made the old one legible. Present to a person, blank to a machine. The recheck mechanics are in keep schema valid after edits.
Rebuild the links, rescue the orphans
A restructure reshuffles your internal links, and some pages land with no inbound link at all. Those orphans are now unreachable.
After the move, check that important pages still have paths to them and relink anything the new structure stranded. This is the same discovery problem covered in internal linking for AI discovery and fixing crawlability issues, made acute because a migration breaks links in bulk.
After launch, scan and re-prove
Now compare the new site to the baseline. Scan it, see what dropped, and fix what the move broke before the gap costs you.
Then keep re-proving. The weeks after a launch are when drift is worst: redirects you missed surface slowly, schema gaps reveal themselves as engines re-crawl, orphaned pages stay lost until you relink them. A migration is not done at launch, it is done when the new site reads as well as the old one did, proven by a scan, not assumed from a demo.
Old way versus new way
The old way reviewed a migration the way you review a design: does it look right, does it click through, does the form submit. All human checks.
The new way adds the reader you cannot see. Before you celebrate the launch, you ask whether a machine can still read, find, and name the pages it could read yesterday. Same migration, one more reviewer, and that reviewer is the one deciding whether you show up in answers.
The damaging admission
This checklist does not guarantee your citations survive the move, and we will not pretend it can. It protects the readability and discoverability a migration tends to break, which is the part you control. The engine still decides what it does with a readable page.
And if you are migrating a small static site you rarely touch, the full ceremony here is more than you need. Capture a baseline, preserve your URLs, and move on. We would rather scope this down for you than walk you through a checklist built for a site that does not change.
How the watch helps after a launch
On WordPress, with the Citedon plugin connected, the watch re-proves readiness in the volatile weeks after a relaunch and lets you apply the fixes a migration broke, after you approve each one. Watching and fixing are the paid part. The scan is free.
On other platforms, the scan still gives you the before-and-after comparison and the list of what broke, and you apply the fixes by hand.
Scan before you migrate, and after
The cheapest insurance against a silent relaunch is a baseline you can compare to. Get it before you touch anything.
Run a free scan on your current site to capture what reads well today, then scan again after launch to see what the move cost you. Keep it honest afterward with how to keep schema valid after edits.