The AI Visibility Checks Your CMS Migration QA Needs.
Launch week on a replatform has a rhythm to it. The redirect map validates, forms submit, analytics fires on the thank-you page, Core Web Vitals hold, and somebody signs the go-live. Every line on the CMS migration QA sheet may be green while one question still goes unanswered: what does a crawler actually receive? Redirects validate, forms submit, analytics fires and Core Web Vitals hold, but unless somebody tests the migrated templates as OAI-SearchBot or another AI crawler, machine access can still remain unverified.
eight25 has led large-scale enterprise replatforms across platforms including Contentful and Contentstack, with migration experience spanning brands such as Sophos and Qlik. In that kind of headless architecture, crawler access is part of implementation quality, not a post-launch SEO task. These four checks belong in the cutover gate beside redirect validation. For a well-inventoried site, the first pass can usually be completed quickly because the goal is to test representative templates rather than every URL.
Traditional CMS migration QA can prove humans can use the site without proving AI crawlers can read it.
A migration can change four things at once that directly affect whether an AI crawler can retrieve and interpret the site: robots.txt, CDN policy, URL structure, and the rendering model. Traditional functional QA often validates those systems from the browser or search-engine perspective without separately testing what AI crawlers receive.
The failure can be unusually quiet. Googlebot can render JavaScript, so a page may remain discoverable in traditional search even when another crawler receives little useful content. Meanwhile, AI-search visibility may weaken without producing an obvious technical error in browser-based analytics. Referral traffic can still be measured, but crawler access and citation frequency usually require server logs or dedicated AI-visibility monitoring.
| Check | What it proves | Pass criteria |
|---|---|---|
| 1. Access | Retrieval crawlers reach the page | 200 on every priority template |
| 2. Content | The response holds the facts | Target claims present in raw HTML |
| 3. Continuity | Existing citations still resolve | One hop, no chains, no 404s |
| 4. Evidence | The gate actually held | Post-cutover log diff matches the baseline |
The first three run before DNS moves. The fourth proves they worked.
Check one: every priority template returns a 200 to a retrieval crawler
Search and retrieval crawlers are what this check protects. OAI-SearchBot, Claude-SearchBot, and PerplexityBot help their respective platforms discover or index web content for search and answer experiences, while separate user-triggered agents such as ChatGPT-User, Claude-User and Perplexity-User may retrieve pages in response to individual requests. Blocking the search-facing crawlers can reduce your eligibility to surface in AI search results even when the site remains accessible to human visitors. Blocking training crawlers such as GPTBot or ClaudeBot can be a deliberate content-policy decision. Blocking search-facing crawlers is different: it can prevent those providers from indexing or surfacing your content through their search systems. Migration week is exactly when an old robots.txt rule, WAF policy or CDN default can accidentally blur that distinction.
Three things go wrong in the same week. Somebody ports the old robots.txt forward with agent rules nobody re-read. The new CDN arrives with bot management on and an unfamiliar user agent classified as a scraper. Staging-era access controls survive on a subdomain nobody remembered was public.
Cloudflare adds another migration variable from 15 September 2026. Its AI traffic controls classify bots as Search, Agent or Training. For new domains onboarding to Cloudflare, Training and Agent traffic will be blocked by default on pages displaying ads while Search remains allowed. Cloudflare is also applying the updated defaults to certain existing Free-plan customers that have not already set their own preference. A replatform is often the moment a domain gets onboarded, so the default lands on a day nobody is thinking about crawler policy. The sharper edge is the multi-purpose rule: Cloudflare judges a crawler doing both Search and Training under both policies, so a Training block also catches Googlebot, Applebot, and BingBot.
A 403 is the CDN. A 404 is the redirect map. A 401 is staging auth that outlived staging. Because a user-agent string can be spoofed, do not trust the header alone. Where the provider publishes crawler ranges, verify both the user-agent token and the source IP against the provider’s current list. OpenAI, Anthropic and Perplexity all publish crawler address data that can be used for this verification.
Check two: the 200 contains the answer, not an empty shell
Passing check one does not mean the crawler received anything worth quoting.Vercel’s crawler research found that major AI crawlers it tested – including OpenAI, Anthropic and Perplexity crawlers – did not execute client-side JavaScript. That makes server-delivered HTML the safer baseline for content you expect answer engines to extract. Crawler capabilities can change, so this should be tested rather than assumed during every migration. The exceptions are Gemini, which rides Googlebot’s rendering infrastructure, and Applebot, which crawls with a browser.
The risk is not headless CMS itself; it is an incomplete rendering strategy during the move to a decoupled front end. A platform such as Contentful or Contentstack gives teams more control over how content is modeled and delivered, but the front end still has to decide what is present in the initial response. In React or Next.js implementations, the answer-bearing components – FAQ content, specifications, certifications, pricing and structured data – should be available through server rendering or static generation rather than depending exclusively on client-side JavaScript.
Diff the raw response against the rendered page, per template:
If important claims, structured data or substantial body content disappear from the raw response, the template is relying too heavily on client-side rendering. The fix is usually narrower than teams expect: server-render or statically generate the answer-bearing modules while leaving genuinely interactive UI client-side. One advantage of a well-architected headless build is that those responsibilities can be separated deliberately instead of being dictated by the CMS rendering layer. You need the sentences you want quoted to survive a request that runs no JavaScript at all.
Check three: the URLs already being cited still resolve in one hop
The must-not-break list for AI visibility is not the must-not-break list for search traffic, and that is the blind spot. A high-traffic page earns its place through volume. A cited page matters for a different reason: a specific URL is already being surfaced as evidence for a particular question. Breaking or unnecessarily chaining that URL during migration creates avoidable risk even if the replacement page contains equivalent content.
Build the list from ninety days of access logs filtered to AI user agents, referrer data for assistant traffic, and the URLs your citation tracking already shows in answers. Hold those to a stricter standard than the rest of the redirect map. [INTERNAL LINK: SEO continuity checklist] Redirect chains add latency, consume crawl effort and create more opportunities for a retrieval path to fail. URLs already earning citations should therefore resolve as directly as possible, ideally in a single hop.
| Failure at cutover | Where it shows up | The check |
|---|---|---|
| Redirect chain of 2+ hops | Cited deep pages, old campaign URLs | curl – sIL and count 3xx lines |
| Asset paths not in the map | PDFs, datasheets, spec documents | Crawl the old asset directory, expect 301 |
| Sitemap regenerated, not resubmitted | Discovery of new URLs stalls | Fetch /sitemap.xml, compare URL count |
| llms.txt orphaned by the rebuild | Site briefing points at dead paths | Fetch it, resolve every URL inside it |
Documents are a common migration blind spot. A PDF library built over a decade may sit outside the CMS, disappear from the page inventory because it is treated as an asset rather than a page, and lose valuable inbound links or AI citations when its paths change.
Check four: the access logs two weeks later agree with the launch-day result
Checks one through three are predictions. Each tests a configuration you believe is final, on a day when several other things are still moving. Evidence arrives later, once real crawlers come back on their own schedule.
Pull thirty days of pre-cutover logs and fourteen days after, filter both to AI user agents, and compare the status distribution. A healthy result should show the expected crawler set continuing to access priority templates with a strongly 200-weighted status distribution. Exact crawl volume may vary, so the more important signals are new 403s, persistent 404s, disappearing crawler families or abrupt changes concentrated on migrated templates. A new 403 cluster points at a CDN rule. A 404 cluster points at the redirect map. Silence from an agent that used to appear is the expensive result, because nothing is failing loudly enough to page anybody.
In practice, none of it survives launch week unowned. Give each line a name and a stage:
| Gate item | Owner | When it runs |
|---|---|---|
| Access check, all templates | Technical lead | Staging, then pre-DNS |
| Raw-HTML content diff | Front-end lead | Staging, then pre-DNS |
| Cited-URL resolution | SEO or analytics lead | Pre-DNS, then 72 hours after |
| Log-based status diff | Analytics lead | 14 days after cutover |
The staging run matters because rendering and schema problems are cheap to fix there. The pre-DNS run matters because the CDN is the variable that changed last. A failure in that second run holds the launch.
At enterprise scale, sampling is the only workable method. At enterprise scale, sampling becomes essential. On eight25’s Sitecore XP-to-Contentful migration for Qlik, roughly 5,000 pages were moved across four regions and 19 languages in five and a half months. A migration at that scale is not validated URL by URL; the practical approach is representative testing across template types, locales and high-value paths. Nobody tests URLs individually.The final sample size depends on template count, locale structure, rendering variation and infrastructure, but it is usually dramatically smaller than the total URL inventory.
When a lighter version is the right call
Two situations justify less than the full gate. If your organization has deliberately blocked training crawlers to protect proprietary content, that decision stands and the gate changes job: If your organization deliberately blocks training crawlers to protect proprietary content, that decision stands. The gate changes job: it verifies that the policy is precise, catching wildcard robots rules, WAF policies or CDN bot controls that were intended to block GPTBot or ClaudeBot but also restrict search-facing crawlers such as OAI-SearchBot or Claude-SearchBot. If your site is largely gated, or your buyers do not research through assistants in any volume you can observe, check three still earns its place and the others can wait for the first post-launch sprint.
What does not bend is sequencing. All of it is cheaper before DNS moves than after. What makes the post-launch version expensive is not the remediation. It is the two quarters of content investment spent solving a problem that was actually a 403.
Frequently Asked Questions
How do you keep AI search visibility through a website migration?
Add three checks to the launch QA gate before DNS moves, and one after. Confirm retrieval crawlers such as OAI-SearchBot, Claude-SearchBot, and PerplexityBot receive a 200 on every priority template. Confirm the facts you want quoted appear in the raw HTML rather than only after JavaScript runs. Confirm the URLs already cited in AI answers resolve in one hop. Two weeks after cutover, diff the access logs against the pre-launch baseline. Standard migration QA verifies human access and rarely verifies machine access.
Should we block AI crawlers in robots.txt during a migration?
Block training crawlers if that is your content policy, and name the agents precisely. Blocking search-facing AI crawlers can prevent your pages from being crawled or indexed directly by those providers and can materially reduce their ability to surface your content in search-based answers. Broad robots, CDN or WAF rules can do this accidentally. Test any rule with a live request rather than reading the file, and remember that CDN bot management can block agents your robots.txt explicitly allows.
How do we find a migration partner who tests AI crawler access before launch?
Ask to see a launch QA runbook from a completed migration and look for machine-access items in it. A serious migration partner should be able to name the crawlers tested, define the pass criteria and identify who owns sign-off. This is especially important in headless replatforms, where CMS architecture, CDN policy and front-end rendering are separate decisions. eight25’s experience running large Contentful and Contentstack migrations makes those dependencies part of the migration conversation rather than an SEO issue discovered after launch. Evaluating a migration partner
Planning a Replatform? Make Machine Access Part of the Architecture Conversation
f your team is evaluating a CMS migration, the useful discussion is not just which platform to choose. It is how content modeling, rendering, redirects, CDN policy and crawler access will work together at launch. eight25 has handled that complexity across enterprise Contentful and Contentstack programs, and we can walk through what a migration-ready QA model should account for before the architecture is locked.