Most landing pages that never get cited in AI Overviews fail something boring: a bot cannot fetch them, the answer sits three scrolls down, the URL moves, or the price contradicts the rest of the site. I learned to check the boring things managing Google Ads. When a landing page changed without warning, I could waste a week rewriting ads before finding the edit that hurt Quality Score. Treat AI visibility like a pre-flight, not a content-quality verdict. Run these 22 checks before you blame the engine or pay for software to score your prose. Each item gives you a pass condition and a way to verify it. The calls a tool cannot make stay with a human.

1–6: Make sure the page can be fetched

  1. Check Googlebot access and indexation. Pass: Googlebot can fetch the live URL, Search Console shows it indexed, the page has no noindex directive, and its canonical points to the intended URL. Check both the page response and the indexed URL; a browser visit proves only that you can see it. If the page is not indexed or eligible to show a snippet, rewriting its answer will not solve the access problem. Verify with a fetch and Search Console before touching copy.
  2. Separate Google-Extended from Googlebot. Pass: your robots policy reflects what each token does. Google-Extended concerns training use; blocking it does not block Google Search or AI Overview eligibility. Blocking Googlebot is a different decision with consequences for Search access. Common miss: disallowing Google-Extended to stop AI Overview citations, then treating unchanged visibility as proof that the page needs a rewrite. A tool can read the rule. A human must decide the policy.
  3. Separate GPTBot from OAI-SearchBot. Pass: your robots.txt rules make the intended distinction between training and search access. GPTBot and OAI-SearchBot serve different purposes; allowing one does not mean you allowed the other. If you want the page available for ChatGPT search citations, check the search bot’s access rather than assuming a GPTBot test settles it. Common miss: blocking both under a broad rule, or allowing both without making a deliberate training choice. Verify the rules; decide the policy yourself.
  4. Check Claude’s search access separately. Pass: the rules for ClaudeBot and Claude-SearchBot reflect whether you want the page available for Claude answers. Read the relevant robots.txt group instead of treating every Claude user agent as the same visitor. Then test the live URL against the access you intended; a rule that looks fine in isolation does not prove the page can be fetched. A tool can report the rule and response. A human must decide which access to grant.
  5. Test the firewall, not just robots.txt. Pass: PerplexityBot is allowed if you want Perplexity visibility, and edge checks find no 403 for the Perplexity and ChatGPT fetchers. Robots.txt can welcome a bot while Cloudflare or AWS WAF turns it away at the door. Common miss: signing off after reading robots.txt without checking the CDN response. Record the status code for each bot you care about; do not infer one bot’s access from another’s.
  6. Confirm the sitemap, canonical, and fetched HTML agree. Pass: the URL appears in the current sitemap, its canonical stays on the intended page, and a bot fetch returns the answer text rather than an empty app shell and a pile of scripts. Compare a relevant bot fetch with what you see in the browser. Common miss: approving the browser version while the fetched HTML contains little more than <div id=root>. A tool can compare the responses; it cannot make missing text citeable.

7–11: Put an answer where it can be used

  1. Lead each target section with a standalone answer. Pass: an H2 states the buyer’s question and the next sentence answers it within roughly 40–60 words, without relying on a previous paragraph for context. Clean, self-contained passages matter; a strong page is not much help when the relevant answer is buried. Read the section opening on its own. A tool can locate the heading and count words, but a human has to decide whether those words answer the question. The passage-first guide covers the writing method.
  2. Give each intent a clear page owner. Pass: the service page handles the buying question, the explainer handles the explanation, and the pricing page handles cost. Common miss: making one page answer all three while another page on the same site gives a competing answer. List the target queries beside their intended URLs before changing headings. A tool can show overlapping terms and pages; it cannot decide which page should own a buyer question. Make that decision first, then edit to support it.
  3. Write headings buyers can recognize. Pass: target H2s use the question or plain-language phrasing a buyer would use, not a clever label that conceals the answer beneath it. Compare each heading with the query it is meant to address, then read the first sentence under it. Common miss: treating a topical heading as an answer heading because both mention the same subject. A tool can flag a wording gap. A human has to check whether the passage makes sense when lifted out of the page.
  4. Check whether the target query shows an AI Overview. Pass: you have looked at the query before optimizing the page for an overview citation. Informational queries trigger AI Overviews more often than transactional or branded ones; a coupon-page query may not offer the citation opportunity you are chasing. Common miss: measuring a page against an overview that does not appear for its target query. Record what the search result actually shows, then decide whether citation is the right objective for that URL.
  5. Remove snippet barriers around the answer. Pass: no nosnippet, restrictive max-snippet, or data-nosnippet setting blocks the passage, and the facts are not trapped in an image, slider, or tab. Inspect the rendered page and the underlying response; a readable screenshot is not a snippet-access test. Common miss: fixing the opening sentence while a page-level directive still limits what can be shown. A tool can find the directives and markup. Use it before asking a writer to try another introduction.

12–15: Catch technical failures before rewriting

  1. Fetch the live URL as the bots that matter. Pass: Googlebot and the relevant AI search fetchers receive a 200 on the intended URL, without a soft 404 or an edge redirect that lands somewhere else. Record the final URL as well as the status code. Common miss: testing only from a normal browser, or seeing a 200 after a redirect and overlooking that the original page has moved. A fetch tool can verify responses; compare results bot by bot instead of declaring the page accessible from one successful request.
  2. Check that the answer exists without JavaScript. Pass: fetched HTML contains the target heading and answer sentence, not just a shell that React fills later. This overlaps with check 6 on purpose: one check establishes that the URL and its HTML are the intended page; this one inspects the exact passage you hope will be used. Search the response for a distinctive sentence from that passage. If it is absent, run the curl and CDN audit before you rewrite the sentence.
  3. Validate schema against what visitors see. Pass: the JSON-LD parses, the applicable markup passes the Rich Results Test, and its price, availability, and ratings match the visible page. Common miss: celebrating valid syntax while a plugin publishes an old offer. A validator can identify markup errors; it cannot decide whether the business fact is true. Put the structured value beside the on-page value and have an owner resolve any difference. Valid schema that contradicts the page is still a problem.
  4. Find pages competing with this URL. Pass: one canonical URL owns the intent, without an indexed print view, tag page, or old test page offering a near-duplicate answer. Search and crawl for variants rather than assuming the canonical tag cleaned them up. Common miss: improving one passage while leaving a second version live with different facts. A tool can group similar pages and flag canonical signals. A human must pick the survivor and decide what happens to the others.

16–18: Make the facts agree

  1. Compare the facts everywhere they appear. Pass: prices, specifications, hours, and names agree across the landing page, JSON-LD, Google Business Profile, and the third-party profiles you rely on. Treat the comparison as a truth check, not just a string-matching exercise; a matching stale price is still stale. Common miss: fixing the page but leaving a contradictory listing or structured value untouched. A tool can surface differences. Someone who owns the offer must declare the correct fact and update the rest.
  2. Keep entity IDs and declarations consistent. Pass: the intended Organization > Product > Offer relationship has stable @id and sameAs links, and the markup is checked after each deploy. Common miss: two plugins outputting two Organizations with different names, even though each block validates on its own. Inspect the combined output on the live page, not only the settings screen of the plugin you remember installing. A tool can find duplicate declarations; a human has to decide which entity record the page should keep.
  3. Look for an older page contradicting this one. Pass: a site search for the price, name, or specification does not surface an old PDF or test page as the apparent answer instead of the intended URL. Common miss: correcting today’s landing page and forgetting the document that still states yesterday’s fact. Search for the exact value, identify every page that repeats it, and choose the canonical source before removing or correcting conflicts. A tool can collect the matches. It cannot decide which fact is true.

19–22: Keep a passing page from quietly failing

  1. Assign one owner to the URL and its edit log. Pass: CMS history shows who changed copy, price, or schema during the last 30 days, and one person is responsible for reviewing those changes. Common miss: recording the edit without giving anyone responsibility for its effect on the fetched answer. Keep the log close to the URL, not buried in a general release report. A tool can timestamp a change; a human has to decide who may approve it and who checks the page afterward.
  2. Watch for URL and canonical changes. Pass: logs and Search Console show the intended URL serving a stable 200, without an unexplained move, redirect, or recanonicalization over the last 90 days. Common miss: a redesign creates a trailing-slash variant, or a tracking URL becomes canonical, while the team continues checking the old address. Compare the current URL and canonical with the versions you recorded before the change. A tool can flag the difference. Resolve it before treating a citation drop as a writing problem.
  3. Diff the answer block as a bot receives it every week. Pass: stored fetched HTML and the live bot response contain the same intended answer, allowing for ordinary page changes. Common miss: opening the page in a browser while the bot receives stale cached text or a JavaScript shell. Diff the passage, not just the page title, and inspect changes before they become a monthly mystery. A tool can run that comparison and flag drift; keep your robots rules in the same watchlist.
  4. Re-run checks 1–18 monthly and tie failures to the change log. Pass: each failure has a date, a URL, and an owner; when citations drop, you check recent deploys, edits, and blocks before commissioning new copy. This is the item most often skipped. A one-time audit cannot catch the redirect, price mismatch, or quiet CMS edit that arrives afterward. Skip the re-run and you pay for the confusion twice: once for a tool that reports a symptom, then in weeks spent rewriting an answer the bot could not use.

Frequently asked questions

Does blocking Google-Extended stop my pages from being cited in AI Overviews?

No. Google-Extended concerns training use, and blocking it does not block Google Search or AI Overview eligibility. Blocking Googlebot is a separate decision with consequences for Search access, so treating unchanged visibility after a Google-Extended block as proof that a page needs a rewrite is a common mistake.

If I allow GPTBot in robots.txt, can ChatGPT search also cite my pages?

Not necessarily. GPTBot and OAI-SearchBot serve different purposes, and allowing one does not mean you allowed the other. If you want pages available for ChatGPT search citations, check OAI-SearchBot's access separately rather than assuming a GPTBot rule settles it.

Can a firewall block AI crawlers even if robots.txt allows them?

Yes. Robots.txt can welcome a bot while Cloudflare or AWS WAF turns it away with a 403 at the edge. Record the status code for each bot you care about, and never infer one bot's access from another's successful response.

Why can't AI crawlers read the answer on my React page?

A bot fetch may return an empty app shell and a pile of scripts instead of the answer text, even though the page looks fine in your browser. Compare a relevant bot fetch with the browser version, and if the answer sentence is absent from the fetched HTML, run a curl and CDN audit before rewriting anything.

How should a landing page section open so AI Overviews can use the answer?

The H2 should state the buyer's question, and the next sentence should answer it in roughly 40 to 60 words without relying on a previous paragraph for context. Read the section opening on its own: if the passage does not make sense when lifted out of the page, it will not work as a citation.

Should I optimize every landing page for AI Overview citations?

No. Informational queries trigger AI Overviews more often than transactional or branded ones, so a coupon-page query may not offer the citation opportunity you are chasing. Record what the search result actually shows for the target query, then decide whether citation is the right objective for that URL.

What should I check about prices and facts before blaming AI visibility?

Check that prices, specifications, hours, and names agree across the landing page, JSON-LD, Google Business Profile, and the third-party profiles you rely on. Treat the comparison as a truth check, because a matching stale price is still stale, and have someone who owns the offer declare the correct fact and update the rest.

How often should I re-run these landing page checks for AI visibility?

Re-run the checks monthly and tie each failure to a date, a URL, and an owner in the change log. A one-time audit cannot catch the redirect, price mismatch, or quiet CMS edit that arrives afterward, and skipping the re-run means paying twice: once for a tool that reports a symptom, then in weeks spent rewriting an answer the bot could not use.