Which AI Citation Checks Belong in a CMS Launch Sign-Off?
A CMS launch sign-off should include the checks that stop a launch silently removing you from AI answers. First, crawler access: robots.txt, noindex rules and bot protection. Then status codes and redirects for every URL that assistants currently cite, and canonical and sitemap hosts pointing to production. Key facts must be present in the raw HTML, not only after scripts run, and structured data must match the visible text. Finish with a short post-launch test of the questions where you are cited today. Most AI search crawlers do not run JavaScript. So a redesign that looks perfect in a browser can be empty to them. Add regression tests for location pages, and alerts that fire when a deploy breaks crawler access.
What belongs in the sign-off list?
| Check | What to verify | Why it matters |
|---|---|---|
| robots.txt | No new disallow rules for search or AI crawlers; diff against the previous file | A staging robots.txt pushed live can block every crawler |
| Noindex | No noindex in HTML or X-Robots-Tag headers on production pages | Removes pages from search indexes that assistants rely on |
| Bot protection | Verified search and AI crawlers are not challenged or blocked | Firewall or CDN rules can silently block them |
| Status codes | Key pages return 200 | Errors drop pages from indexes |
| Redirects | Every URL currently cited by AI answers redirects one-to-one to its new equivalent | Cited URLs are where assistants already look |
| Canonicals | Point to production URLs on the right host | Wrong canonicals can shift indexing elsewhere |
| Sitemaps | List production URLs only, and include new pages | Helps discovery after launch |
| Raw HTML content | Prices, hours, addresses, product facts present without JavaScript | Most AI crawlers do not render scripts |
| Structured data | Valid, and consistent with visible text | Conflicts reduce trust; several assistants read only visible text |
| Old files | PDFs and assets that were cited still resolve or redirect | Cited files often escape migration plans |
Build the list of currently cited URLs before launch, from your AI answer tracking and from server logs showing AI crawler requests. How to handle cited staging URLs is covered in what to check when AI search cites a staging site URL.
How do you check raw HTML content?
This check matters because a Vercel and MERJ study of AI crawler traffic found that none of the major AI crawlers it examined rendered JavaScript. Fetch key pages without running scripts, for example with a command-line request or a text-only crawler, and search the output for the facts that matter. Compare it with what a browser shows: headings, prices, addresses and product details should appear in both. The checklist includes business name, address, phone, opening hours, prices and main product specifications. If a fact appears only in the browser, move it into the server-rendered HTML. Make this an automated test that fails the build when a required fact is missing.
What regression tests should run after changing a business location page?
Location pages carry facts that assistants repeat directly: address, hours, phone and services. After any change to the template or a single page, test:
- Status and indexability: the page returns 200, has no noindex, and its canonical points to itself on the production host.
- Facts in raw HTML: name, full address, phone, hours and services present as text.
- Structured data: LocalBusiness markup with the same address, phone, hours and coordinates as the visible text. Google's local business documentation asks for coordinates with at least five decimal places.
- Consistency: the page matches the Business Profile and the main directory listings.
- Discoverability: the page is linked from the crawlable locations list and included in the sitemap.
- Links out: the Business Profile and directory listings still link to the page's URL, or to its redirect.
- Answer check: a week later, ask "[business] [town] opening hours" and "[business] [town] address" in two or three assistants.
Run these as automated tests on every deployment that touches location templates, and as a manual check after one-off edits. Location page structure is covered in which pages a multi-location business should fix when AI cites the head office.
How to monitor bot visibility over time and get alerts when a deploy breaks it
Combine automated checks in your deployment pipeline with monitoring of real crawler traffic:
In the pipeline:
- Fail the build if production robots.txt disallows search or AI crawlers you intend to allow, or if key templates contain noindex.
- Fail the build if required facts are missing from the raw HTML of test pages.
- Diff robots.txt, canonical hosts and sitemap hosts against the previous release, and require approval for changes.
After deployment:
- Watch server logs for each crawler: requests per day and the share returning 200, 3xx, 4xx and 5xx. Alert on a sharp rise in errors or a sudden drop in successful fetches for Googlebot, Bingbot and the AI search crawlers.
- Watch for challenge or block responses from your CDN or firewall to verified crawler traffic.
- Check Search Console and Bing Webmaster Tools weekly for indexing drops.
- Run a small fixed set of AI answer checks weekly, including control questions, as covered in what a control prompt is in AI search visibility measurement.
Synthetic tests that pretend to be a crawler are useful, but bot protection may treat them differently from real crawlers. Real crawler traffic in your logs is the most reliable signal.
Who should own the sign-off?
The search or web lead, with engineering. Add the AI citation checks to the same release checklist as analytics and accessibility, so they are not skipped under deadline pressure. Keep a record of each launch's checks and results. When citations drop weeks later, it shows what changed and when.
What might an illustrative case look like?
Consider an illustrative insurance broker that launched a new CMS on a Friday. By Wednesday, its pages had stopped appearing in ChatGPT and Perplexity answers. The new CDN configuration was challenging requests from OpenAI's and Perplexity's crawlers, and the office pages loaded hours and addresses by script. Server logs showed AI crawler requests returning challenge pages. The broker allowed verified crawlers through and moved office details into the server-rendered HTML. It then added three pipeline tests: robots.txt diff, noindex detection and required facts in raw HTML. It also set an alert on crawler error rates. Citations returned within two weeks, and the next release caught a staging robots.txt before it went live.
What do people ask about AI checks in launch sign-offs?
Do AI crawlers respect robots.txt?
The main AI search crawlers publish their user agents and say they follow robots.txt. User-initiated fetchers can behave differently, so check each provider's documentation.
How long before we see a problem after launch?
Crawler errors show up in logs within hours. Changes in AI answers can take days or weeks, which is why logs are the early warning.
Should we freeze URLs during a migration?
Keep them where possible. Where they must change, redirect every cited URL one-to-one.
What if a launch has already caused a drop?
Compare the launch date with your crawler logs and citation tracking, then work through the sign-off list in order. Access and status problems are usually the cause, and the quickest to fix.
Published by The Kovmere Team · updated Sep 29, 2026 · More resources