A buyer asks which fleet-routing platform handles refrigerated, multi-stop delivery with temperature logging. Your business might be a good answer. That does not mean ChatGPT or Perplexity will find the page that proves it.
Getting cited is a retrieval auction you enter one query at a time, not a reputation you earn once. When an engine searches the live web, it can rewrite the buyer’s question into smaller searches, fetch candidate pages, and select passages that answer those smaller questions. If your page misses the search, fails to load as useful text, or buries the answer, your brand never gets its turn. Publishing more thought leadership will not fix a failed fetch.
I think about this in the order the work happens: query, fetch, passage, attribution. Each step depends on the one before it. That order also tells you what to fix first.
First principle: a page has to answer a smaller question
An engine building an answer does not need everything your website says about fleet routing. It may need one piece of it: whether your platform supports multi-stop routes, how temperature logging integrates, or what a buyer can learn about pricing. A useful passage answers one of those questions without requiring the reader to assemble a claim from three parts of the page.
That is where polished product pages can fail. Suppose the multi-stop claim sits in the introduction, the temperature-logging detail appears in a graphic, and the relevant integration information lives inside a table farther down. A passage extracted from any one section may look incomplete, even though a patient human could put the pieces together.
Write the answer where it can stand alone. Name the capability, explain how it works, and keep the relevant qualification nearby. Before you rewrite that passage, though, find out whether the engine can retrieve it at all.
Step 1: One buyer question becomes several searches
The buyer’s prompt is not necessarily the phrase the engine searches. In an analysis of 15,000 ChatGPT search prompts published by OSALDVHA, those prompts expanded into 43,233 distinct search queries and pulled 548,534 candidate pages. The analysis found that 32.9% of cited pages appeared only in results for a fan-out query, not the original prompt. It also found that 85% of retrieved pages were not cited.
For our fleet-routing question, plausible lookups include fleet routing software cold chain, multi-stop route optimization api temperature sensors, and fleet dispatch software comparison pricing. The point is not that every engine will issue those exact searches. It is that a broad page titled “Modern Fleet Solutions” may match none of the specific questions the engine uses to assemble an answer.
This is the first limit of advice to “get cited.” You cannot edit your way into a passage-selection win if your page never becomes a candidate. Start with the buyer’s concrete sub-questions, then check whether a page on your site gives each one a direct answer. That is the first of the five gates a page must clear to get cited.
Step 2: A live fetch has to reach usable text
Not every answer involves a live visit to your site. Onely’s research on ChatGPT retrieval mechanics found live web search on roughly 34.5% of the prompts it examined; the rest relied on the model’s existing knowledge. But when a live search does happen, your server becomes part of the answer-building process.
That distinction matters if you have spent years treating “Google can index it” as the end of the technical conversation. The same research found that only 12% of URLs ChatGPT cited across the prompts ranked in Google’s organic top 10 for the exact same query. A familiar search ranking is not a reliable substitute for checking whether an AI fetcher can reach the page the buyer needs.
What our edge logs can—and cannot—show
Background crawlers and on-demand fetchers do different jobs. GPTBot may crawl content independently of a buyer’s immediate question. A request from ChatGPT-User is an on-demand fetch of a specific page. In groas’s edge logs, we recorded 943 verified ChatGPT-User live requests to our homepage and 144 to one tactical post on AI search ads. Those requests show pages being fetched live; they do not, by themselves, show that the pages were cited.
That is why I look at edge logs before I blame the copy. If a request reaches your site and receives an HTTP 403 response, check the firewall or CDN rules. If it fails to deliver useful page text, check what the server actually sends. ThriveStack’s server-log analysis describes the same practical distinction: a live request is an opportunity to supply evidence, not a citation guarantee.
The page the bot receives may not be the page you see
A human browser can turn client-side JavaScript into a beautiful product page. An AI fetcher may receive only the HTML your server sends before that rendering happens. Network traffic analysis by Vercel and MERJ, reported by Crawlmouse, found that the OpenAI fetch agents and PerplexityBot it examined did not run headless browser engines. If the fleet-routing specifications exist only inside a client-rendered component, the fetcher may not receive the answer you see on screen.
Response time is another gate. EdgeComet’s log experiments describe a five-second timeout for ChatGPT-User requests. Do not turn that observation into a universal rule for every engine or every request. Do treat a slow origin as a problem worth testing. Check your crawler directives, too, rather than assuming your hosting defaults allow the agents you want; our AI crawler rules swipe file is a starting point.
Verify the response the fetcher gets, not the page your browser paints. If the answer never arrives as usable text, better prose cannot rescue it.
Step 3: The answer has to survive passage selection
A fetched page is a candidate, not a winner. The engine still has to choose material that answers the buyer’s question. For our fleet example, a short section that plainly connects refrigerated multi-stop routing with temperature-logging integration gives the engine more to work with than a broad claim about making logistics smarter.
The engines do not all use sources in the same way. Machine Relations’ research on citation mechanics describes Perplexity as drawing on a broader set of citations, averaging 17.7 to 21.8 sources per answer in its analysis, while ChatGPT averaged 3 to 4 and drew more deeply from each cited source. The writing lesson is not to produce separate pages for separate engines. It is to make an individual passage useful whether an engine takes one line or reads several paragraphs.
Put the subject and answer together. If you say the platform supports temperature logging, explain the integration in that section rather than making the engine hunt for it. If a limitation matters, include it near the claim. An answer-first passage should remain accurate when lifted out of its page. That is a stricter test than whether the whole page sounds persuasive.
Step 4: The engine has to connect the passage to your business
Even a useful passage can lose its owner. A comparison page might explain a capability while naming several products nearby. The engine may retrieve the right detail and attach it to the wrong company, or cite the page without recommending the business that supplied it. AuthorityTech’s research on entity resolution describes those attribution failures.
For the fleet-routing page, state plainly which company offers the capability. Keep its name, category, and relevant product detail together; use valid Schema JSON-LD to reinforce that identification. “All-in-one growth acceleration platform” might satisfy a brand workshop, but it does little to tell an engine whether the named business offers refrigerated multi-stop routing.
Make the ownership of the answer unambiguous. A citation to your URL is not much help if the recommendation goes to the competitor in your comparison table.
The Google Ads analogy helps—until it doesn’t
I used to manage accounts where a landing page looked fine in a review meeting and failed the moment it met a specific search term. That is the useful part of the Google Ads analogy here: broad confidence in a brand cannot make an irrelevant page answer a narrow query. In Ads, expected click-through rate, ad relevance, and landing page experience give you concrete ways to examine that mismatch. A larger budget does not make the wrong landing page the right one.
The analogy breaks at visibility and control. In Google Ads, I can inspect search terms and account diagnostics. In AI retrieval, I cannot open a neat report showing every fan-out query, fetch decision, and rejected passage. An edge log shows requests that reached my infrastructure; it does not reveal all the candidate pages an engine considered. Treat the auction as a model for diagnosis, not a claim that you can see the entire auction. Then run a test designed to narrow down where your page disappears.
Test protocol: locate the failure before rewriting the page
Question: For the buyer prompts that matter to you, does your site fail before the fetch, after the fetch, or at attribution?
My expectation is that teams will be tempted to rewrite copy before checking delivery. The mechanism is simple: bad prose is visible to a human reviewer; a blocked or empty response is easy to miss. This test does not prove why an engine made a particular choice, but it tells you where to investigate next.
Set up the runs and keep the controls fixed
- Choose 10 high-intent buyer prompts, not branded questions such as “What is [Your Company]?” Include specific requirements a buyer would evaluate. For the fleet example, ask about refrigerated multi-stop routing and temperature-logging integration rather than “best logistics platform.”
- Run every prompt in ChatGPT Search, Perplexity Pro, and Claude. Repeat each prompt three times in clean browser sessions. Keep the wording the same across runs so you are not testing your own rewrites.
- During the runs, check your edge logs for requests associated with
ChatGPT-User,PerplexityBot, andClaude-User. Note the requested URL, response status, timing, and whether the response contains the relevant text. - For each of the 90 runs (10 prompts × 3 engines × 3 repetitions), record four observations: whether the brand appears, whether a clickable citation appears, which URL it points to, and what passage supports the answer.
Read the results in pipeline order
- No observed fetch: Do not call this a firewall failure yet. The engine may not have searched live, may have selected other candidates, or may have issued a request your logging does not capture. Check how your page addresses the prompt’s likely sub-questions, then verify your logging and crawler access.
- A failed or unusable fetch: If your edge logs show an HTTP 403, inspect security rules. If the response is slow, investigate delivery rather than assuming you hit a particular timeout. If the returned HTML lacks the answer, move the needed text out of client-only rendering.
- A successful fetch without a citation: Inspect the passage. Does one section directly answer the buyer’s narrow question, or does the engine have to piece it together from a graphic, a slogan, and a table? Our five-step page rebuild guide covers the answer-first approach.
- A citation with the wrong attribution: Check whether the passage clearly identifies your product, especially on comparison pages where a competitor appears nearby.
A result in the first two groups changes the work order: fix discovery or delivery before commissioning more copy. A result in the last two points you toward the passage or its attribution. Neither result calls for another dashboard screenshot.
A content gap is an unanswered sub-question
When someone asks me which platform reveals the content gaps keeping a business out of AI answers, they usually expect a visibility dashboard. A mention tracker can tell you that you were absent. It cannot, on its own, tell you whether the engine never found your page, received unusable HTML, or found a passage that did not answer the question.
Return to the fleet buyer. A site may have a long fleet-management article and still say nothing clear about temperature-logging integration. That missing explanation is the content gap. It is not necessarily a missing 3,000-word trend piece. It may be a concise specification the business has not put in retrievable text.
Map content to the sub-question, not the topic label. If the question is about an integration, answer the integration question. Then check that the answer can be fetched and attributed.
Fix fetchability first, passages second, volume last
Now apply the model to a different buyer: someone asks for churn-prediction software for mid-market SaaS and needs to know about webhook latency and segmentation API pricing. The engine may search those technical details separately. A vendor with only a broad “predict churn with AI” page might miss the candidate set. If its specifications sit behind a demo wall or client-rendered interface, a live fetch may still miss the evidence. If a comparison article supplies the details but blurs which vendor offers them, attribution can fail at the final step.
The order of repairs follows the order of failure. Check whether a relevant page can be found for the smaller question. Confirm that a live fetch receives useful HTML. Make the answer self-contained, then make its owner explicit. Only after those checks would I pay for more pages.
That is the part the usual “publish more to get cited” pitch skips. You cannot win passage selection with a page the engine never receives.
