A client once swapped a landing page without telling me. The URL stayed put, but the new template loaded more slowly and changed the headline; Quality Score fell, and CPA climbed 30% before anyone checked what had shipped. Pages miss AI citations for the same boring reasons: the answer is buried, a claim has no usable detail, or the page renders blank to a crawler. Verification fails before strategy does. I run this checklist like a pre-launch ad check: establish the question, make the answer easy to lift, confirm a bot can fetch it, then watch what happens. Each item is pass or fail. Do not rewrite the page because a prompt came back empty until you know which gate it reached.

1. Before writing: choose the question and the passage to beat

  1. State one buyer question in the buyer’s words. Test: turn the H1 into a question and ask it in ChatGPT and Perplexity. If the responses are nowhere near the page you intend to write, revise the H1 before drafting. A page trying to answer three loosely related questions gives each answer less room to be clear. Pick the one the buyer would actually type; save the others for another page.
  2. Record the sources each engine cites. Test: ask the same prompt in each engine and write down the three to five cited domains. Open the pages instead of judging their titles from the answer screen. Perplexity uses live web search with numbered sources; Google AI Overviews draw on Google’s existing index. Check the result in the surface you want to win.
  3. Identify the rival passage, not just the rival page. Test: copy the sentence that answers your question from each cited source. Note its number, date and any condition attached to its claim. Your target is a better answer to that question, not a longer article with a more impressive introduction. If the cited passage answers in one sentence, make sure yours can stand on its own in one sentence too.

2. The answer block: make the useful sentence easy to lift

  1. Put the direct answer in the first two or three sentences. Test: read only those sentences, then close the page and repeat the answer. If you cannot, move the answer up and put the explanation after it. The direct-answer-first approach is not a ban on storytelling. It is a ban on making a reader, or an answer engine, wait through six paragraphs to find the point.
  2. Give the answer a specific detail it genuinely needs. Test: highlight its numbers, dates and named steps. If nothing is highlighted, ask whether a price range, timeframe, threshold or procedure would make the answer more useful. Do not manufacture one to satisfy the checklist. Research across roughly 10,000 queries reported visibility lifts of up to 40% for targeted changes, including lifts associated with quotations and statistics; keyword stuffing added nothing.
  3. Make the answer work outside its paragraph. Test: paste the answer sentence into a blank document. If it begins with “it depends” or refers to “this option” without naming the option, it fails. Name the business, product or subject and the condition that makes the claim true. A standalone sentence is easier to quote without changing its meaning than a sentence that needs three lines of setup.
  4. Check that the number supports the claim it sits beside. Test: read the answer without its surrounding explanation and ask what the number measures. A timeframe is not a result, and a price without its condition can mislead. Keep the useful approximation if it tells the reader enough; move the caveat into the answer if removing it would change the claim. The goal is a liftable answer, not a misleadingly tidy one.
  5. Read the answer against the cited rival passages. Test: put yours beside the strongest one from item 3. Can a reader see the answer faster, understand the condition, and tell what the specific detail means? If not, revise the sentence before adding more sections. In one study of 1,000 AI Overviews, an overview averaged 4.2 citations. You are competing for a place beside other passages.

3. Names and headings: remove avoidable ambiguity

  1. Use one name for each business, product and location. Test: search the draft for every variant. If the same product has two names or the business appears under three versions, choose one and make the references consistent. A reader can often work out what you meant; do not make an engine do that work. Keep a different name only when it actually refers to a different thing.
  2. Make each heading promise the answer underneath it. Test: read the H2s aloud as questions a buyer might ask. Replace headings that sound like internal campaign labels with the question or decision the section addresses. Keep one main idea in each short paragraph below it. That gives the engine a clean passage to extract and gives the human reader a reason to keep scrolling. Both matter.

4. Crawl and render: check what ships, not what your browser paints

  1. Find the answer block in raw HTML. Test: use View Page Source, not Inspect, and search for the answer sentence. You can also disable JavaScript and reload. If the sentence is absent, the rendered page is not enough evidence that a crawler received it. Many AI crawlers do not execute JavaScript; a page that relies on client-side rendering can look complete to you and empty to them.
  2. Fix a missing source answer before polishing copy. Test: if item 11 fails, make the content available through prerendering, static site generation or server-side rendering, then repeat the source check. Do not spend the afternoon improving a sentence that appears only after a script runs. Source is a closer check of what a bot can receive than staring at the finished page in a browser.
  3. Check robots.txt for the bots and the URL path. Test: open /robots.txt and check whether rules allow GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended and Bingbot on this path. A rule for one directory is not a verdict on the whole site. Read the path that contains the page. For a fuller bot-path run, use the AI crawlability pre-flight.
  4. Check the CDN or WAF after robots.txt. Test: inspect the rules that handle AI user agents and the page’s path. An allowed robots.txt entry does not help if another layer rejects the request. Cloudflare’s AI crawler blocking can leave a site blocked without anyone noticing from a normal browser visit. Treat the access check as incomplete until the request can reach the page.
  5. Confirm the canonical in Source. Test: find the canonical tag and make sure this page has one self-referencing canonical rather than a pointer to another URL. Do this on the published template, not just in a CMS field. If the page points elsewhere, stop treating this URL as the one you expect an engine to cite. Fix the signal before testing answer wording.
  6. Confirm indexability on the actual URL. Test: check Source for noindex, then check for a Disallow rule covering the path. A good answer cannot appear in an AI Overview if Google cannot index its page. The heading, answer block and schema can all be immaculate while this gate remains shut. Clear it before making content changes and calling them an AI-search test.
  7. Keep schema valid, but do not use it as a substitute for readable content. Test: confirm that markup describes the page you actually published, then return to the visible answer and raw HTML. The same 1,000-overview study found pages with valid schema were cited 2.3 times more often. That observation is worth a check; it is not permission to skip the sentence or the fetch.

5. Trust: show who stands behind the claim

  1. Name the author where a reader can find them. Test: can someone opening the page tell who wrote it without hunting through footer fine print? Put the name near the article, not in a place that requires a site-wide search. A clear byline does not rescue a weak answer. It does remove a needless question about who is making the claim.
  2. Show an honest date and keep it honest. Test: put an accurate “Updated Month Year” near the H1, and refresh statistics when you revisit the page quarterly. Do not change the date just to make old copy look new. One analysis found 83% of citations for commercial and evaluation queries came from pages updated in the past 12 months; another found a median cited-page age of 14 months. Date helps readers judge a claim; it does not replace one.
  3. Check whether someone else corroborates the core claim. Test: search the claim in quotes. If only your site says it, look for a legitimate place you do not control where the number, method or review belongs: a directory profile, supplier listing or local press mention. Do not create a second version of a claim merely to pass this item. It has to be the same claim.
  4. Compare your own page with the external pages that already win. Test: note whether an outside source is cited instead of the business it describes. In the 1,000-overview study, the top 1% of domains captured 47% of citations. That is why I check both the page I own and the places describing it. For the choice between those routes, see your blog vs third-party pages.

Pre-flight checklist clipped over a browser page with missing answer text

6. After publishing: find the failed gate before editing

  1. Re-ask the same prompt on day 7 and day 30. Test: keep the wording and account the same, save a screenshot, and record whether your page was cited, a close competitor was cited, or neither appeared. Perplexity searches live; AI Overviews cannot cite a page Google has not indexed. I used to rewrite on day two when nothing moved. That was an edit made before I knew whether the page had been fetched.
  2. Check Search Console before diagnosing the copy. Test: look at the URL’s discovery and indexing status alongside the prompt results. If it is still undiscovered, work on that gate rather than changing the opening sentence. If it is indexed and a rival passage keeps winning, then compare the answers. For the single-page sequence after identifying the gate, use the AI Overviews walkthrough.
  3. Look for actual bot requests in server logs. Test: search for GPTBot, ClaudeBot and PerplexityBot against the relevant page. A robots.txt allowance is not proof of a fetch. Record whether a request arrived and when, then compare that date with your edit and prompt checks. Without the order of events, it is easy to credit a rewritten sentence for a result the engine had not yet had a chance to see.
  4. Record the response code, not just the bot name. Test: distinguish a 200 from a 403 or 429; those codes can point to access or rate-limit problems. No log hit may mean the page was undiscovered or the request was blocked upstream. Do not treat a 200 alone as proof that the answer text was present: pair the log with the raw-HTML check.
  5. Do not wait for a Google-Extended line in the logs. Test: check the relevant Googlebot fetch instead; Google-Extended is not the fetching user agent you expect to see there. This is an easy way to turn a valid log check into a false alarm. Keep the questions separate: was the page indexable, did a bot request it, what response came back, and was the answer in that response?

Server log lines showing AI bot fetches with 200 and 403 status codes

  1. Log one change at a time. Test: write one dated line for each edit: what changed, why it changed, and the citation result before and after. No log, no second edit. I learned that running ads; without a record, you can test the same headline twice and call it a new test. Copy is cheaper than media, which makes this particular waste easier to overlook.
  2. If the page is readable and still uncited at day 30, revise against the passage that won. Test: confirm indexing, Source, bot access and the fetch first. Then compare answer sentences, add a missing legitimate detail, or put the same supported fact on an appropriate external page. Wait another 14 days before judging the change. Change three things at once and you will not know which one mattered.
  3. Give the mechanical checks a repeatable owner. Test: make sure someone, or something, checks Source, robots.txt, canonicals and fetch results while a person owns the buyer question and answer. I run that division inside groas because I used to skip the boring checks when I was busy. A system can keep a log without getting tired; it cannot decide which question a page should own.

Operator holding a printed checklist beside a laptop showing blank page source

7. The last check: read what the bot could read

  1. Run the raw-HTML and fetch checks again before rewriting anything. Test: find the answer sentence in Source, then confirm a bot could request the page and receive it. This is the item I see skipped most. The page looks fine in a browser, so the next three weeks go to rewriting sentences that never reached the engine. A perfect answer that was never fetched loses to a mediocre one that was: no citation, no traffic, no lead, and a month of edits aimed at the wrong gate.