How to choose prompts for an AI search strategy

AI search prompts, retrieval queries and source pages

Keep the customer question, submitted prompt, retrieval query and source evidence separate in your planning document and reporting.

A customer question can be expressed through several prompts. A prompt can lead to several retrieval queries. An answer can draw on multiple pages, and one useful page can support several questions. There is no dependable rule assigning one page to each prompt.

OpenAI documents query rewriting and follow-up searches in ChatGPT. Microsoft describes Copilot constructing a shorter Bing query. Preserve the submitted prompt alongside any exposed query records.^[8][11]

For your initial prompt universe, we recommend choosing the customer decision as the unit of coverage. The exact submitted prompt remains the unit of a repeatable test. A collection containing ten paraphrases of one buying question should not silently count as ten distinct opportunities.

How to choose your first AI search prompts

Start by writing a plain description of the person, their task and the decision they face. Avoid beginning with a list of phrases you hope will produce your brand.

For example: an engineer responsible for a payments integration needs to recover missed events without introducing duplicate charges. That description produces several useful research directions. The engineer may need to understand delivery guarantees, compare managed services with an internal queue, check language support, estimate operating costs, and establish a recovery procedure.

Choose question types for the customer decision

Use these five question types to make your first selection:

Intent labels such as informational, commercial, transactional and navigational can organize a report, but they rarely specify enough to commission a useful page. “Commercial” does not tell a writer whether the missing evidence concerns price, compatibility, reliability or procurement. The categories above add the decision and the evidence needed to resolve it.

Select and qualify prompt candidates

1. Prioritize a decision. Choose questions for which a different answer would change a customer decision or a content investment.
2. Add meaningful constraints. Include an integration, budget, geography, deployment model, accessibility requirement or operating risk when it matters. Leave it out when you cannot explain why a real customer would introduce it. A long prompt with an invented company biography is not automatically more representative than a short question.
3. Record where the question came from. Mark the origin of every prompt candidate, a proposed question you have not yet selected for tracking. A support ticket, interview, sales objection or community discussion is observed evidence of a question in that setting. A question generated by a model or a planning workshop is a hypothesis. Both can be useful; they should not acquire the same label through an export or dashboard.
4. Separate discovery from verification. “Which services support event replay?” tests a shortlist without naming your company. “Does Relay support event replay?” tests a named product. Supplying Relay's documentation address tests whether the system can inspect that material. All three can reveal useful problems, but they answer different measurement questions.

Define the evidence each prompt needs

Create an evidence record for each prompt candidate with these fields:

• Exact prompt: preserve the wording you intend to submit.
• Question origin: identify the support ticket, sales conversation, community post or explicitly labeled planning hypothesis.
• Customer decision: state what the answer must help the person decide.
• Required facts: specify what a useful answer must establish.
• Supporting pages: identify the pages that could support those facts.

Use the record to choose the next action. A missing product limit needs verification; an incomplete procedure needs an edit; a comparison needs evidence for the same criteria across options.

Review related questions together when they share evidence, and preserve the differences that change the answer. The worked example below shows how an approach question, a shortlist, a capability check and a recovery task connect to different page types.

Map prompts to supporting website pages

Once you have selected your initial prompt candidates, inspect the pages that could answer those questions. Include product and pricing pages, integration references, technical documentation, security material, comparisons and support articles. Record the relevant passage, its address, the claim it supports and any qualification that would disappear in a short summary.

Assess coverage at the claim level. A page titled “Reliable webhook delivery” may describe retry behavior but say nothing about retention or replay. A homepage can make a capability discoverable while a documentation page supplies the operating details. A pricing page can resolve an eligibility constraint that an otherwise excellent tutorial cannot answer.

Use three coverage judgments: supported, partial, and unverified. Supported means the supplied evidence answers the requirement within its stated scope. Partial means an important condition or procedure is missing. Unverified means you have not established support; it does not necessarily mean the capability is absent. An incomplete explanation calls for editorial work. A confirmed missing capability calls for a product decision. Ask the responsible owner which problem you have found.

Check access separately. Google distinguishes discovery, crawling, indexing and serving, and says a page can fail to progress between those stages. For its AI search features, supporting-link eligibility requires indexing and eligibility for a Search snippet. Those conditions do not guarantee selection.^[7][15]

Search access and training access also have different controls. OpenAI distinguishes OAI-SearchBot, GPTBot and user-directed ChatGPT-User requests. Anthropic distinguishes Claude-SearchBot, ClaudeBot and Claude-User. A training crawler request is not proof that an answer retrieved the page, and allowing a search crawler is not proof that a model trained on it.^[16][17] See our ChatGPT crawler guide and Claude crawler guide for the access checks.

Also check the effective Search generative AI setting in Search Console. Google now lets publishers exclude their content and links from AI Overviews, AI Mode and generative Discover features separately from ordinary Search inclusion. A child property can inherit the setting from a parent. This control concerns participation in those features; it does not control AI training.^[25]

Example: map webhook questions to content requirements

Consider a fictional webhook delivery service called Relay. The following prompts, page paths and requirements are illustrative. They describe an editorial exercise, not observed demand, real product capabilities or tests of an engine.

An idempotent event handler is designed so that processing the same event again does not repeat its intended side effect. Amazon's guidance on idempotent application programming interfaces (APIs) explains why safe retries require an explicit contract for identifying repeated requests.^[27]

For the third question, a replay feature must not become a guarantee about downstream payment processing. The draft needs to establish which system prevents duplication, which identifier it uses and what remains the customer's responsibility. If Relay's team cannot supply that evidence, the brief should record the unanswered question before anyone writes a confident product claim.

The four questions share delivery and recovery concepts. They do not all need a comparison article. A recovery task belongs in documentation; a shortlist may need a concise capability explanation; an approach question can justify a resource-center article. Their internal links should help a reader continue the task: the capability page points to the operating procedure, and the procedure points to the relevant limits and safety conditions.

Record topical relationships through the task, entity, constraint or evidence requirement the questions share. The map then explains why pages should be connected and what each must establish. Whether an engine surfaces those pages remains an empirical question, separate from your editorial assessment of relevance.

If this team can review only two question families and its immediate goal is discovery, we would begin with the approach and shortlist questions. Keep the named-product verification question in a separate set of prompts for capability checks. If the priority is reducing support failures, start with the recovery procedure and the duplicate-processing question instead. The same topic produces a different initial prompt universe because the business decision has changed. This allocation is an editorial recommendation for the example, not a research-derived optimum.

Parametric knowledge vs. runtime retrieval

A large language model (LLM) learns numerical parameters during training. Those parameters influence the text it generates: language patterns, relationships, procedures and some factual knowledge. Parametric knowledge refers to information represented in those learned parameters. It does not mean that every answer is copied from a stored page.

Anthropic describes training as learning patterns and connections rather than looking up the original training documents as a database. That description must be read alongside memorization research. Carlini and colleagues demonstrated that studied language models could reproduce some training sequences, with extractability affected by factors including repetition and the supplied prefix. Generalization and memorization can coexist.^[2][5]

Hernandez and colleagues examined a specific mechanism in their 2024 study of relation decoding. The main results use GPT-J and a dataset of 47 relation types; evaluation was restricted to examples the model already answered correctly. For a subset, a relation-specific matrix transformation plus an offset approximated how an internal subject representation became a prediction about an attribute. The authors also changed representations to test causal effects on the next predicted token. Other relations were predicted correctly without a reliable linear approximation. MIT News reports this same study, rather than an independent replication.^[29][30] This is internal decoding, not web retrieval: an encoded fact, its extraction during a request and its appearance in the final answer are different things to test. The experiment offers no publisher control for inserting a fact into a current search engine.

Runtime context is material available for a particular response: the prompt, conversation, system instructions, retrieved passages and permitted tool outputs. A saved product memory may also supply context, as ChatGPT documents for search-query rewriting.^[8] These mechanisms can change an answer without establishing that the model's learned parameters changed. Later use of data in a training process is a separate question from its use to answer a request now.

Retrieval-augmented generation (RAG) combines generation with external retrieved material. The foundational RAG paper by Lewis and colleagues used a pretrained generator alongside a separately searchable Wikipedia index. Its index-swapping experiment demonstrated how retrieved information could change without retraining the generator. Today's deployed products need not follow that paper's exact architecture for the distinction to remain useful.^[1]

Training coverage is also uneven. Kandpal and colleagues found relationships between relevant pretraining documents and fact-based question-answering accuracy, including a controlled retraining experiment. Mallen and colleagues found that retrieval helped studied models with less popular factual knowledge, while low-quality retrieved material could also mislead them.^[3][4] These are findings about particular models, datasets and tasks. They do not establish how many brand mentions a company needs, whether a current commercial engine knows its product, or whether duplicating a claim across websites will improve recommendations.

For a publisher, a document being available to a request and a document influencing training are separate propositions. A citation helps document an observable source relationship; it does not establish training provenance. An answer without visible search might reflect learned information, inference, guessing, supplied context, saved memory or another product capability. Neither a correct brand description nor the model's account of where it learned a fact authenticates a training-data record.

Citation quality introduces another distinction. A source can support a sentence without proving that the source caused the model to generate it. Wallat and colleagues studied this difference between citation correctness and causal faithfulness in a controlled RAG experiment.^[6] For routine monitoring, record the citation and check support. Reserve claims about causal influence for experiments capable of testing them.

When AI assistants search the web

A prompt does not always trigger web search. Depending on the product and available context, a system may answer directly, request clarification, search, fetch a supplied address or use a permitted private tool. When it searches, it constructs queries and receives source pages or passages to consider. It may make further searches, select or filter passages, then generate an answer and source references.

The sequence describes functions a product may perform. Their ordering, search providers, source selection, reranking and citation mechanisms depend on the product; public documentation does not expose a complete implementation for each one.

Search heuristics are the rules or learned decisions used to choose useful actions under these conditions. Freshness is one documented consideration: a current price or recently changed product capability is different from a stable mathematical definition. Specificity also matters operationally because the query needs to identify the subject and requirement. It is unsafe to turn those observations into universal trigger words or a private ranking formula.

Anthropic's API documentation explicitly describes searching for current, changing, product-specific or out-of-training information and direct answers for stable knowledge or supplied-content analysis. It also says system instructions can steer search decisions.^[9] The behavior depends on the request and configuration. Adding “latest” is an experiment with freshness requirements, not a guaranteed switch that makes every engine retrieve your page.

How query fan-out expands a prompt into related searches

Query fan-out means generating multiple related searches to develop an answer. Google says AI Overviews and AI Mode may search across subtopics and data sources this way.^[7] Read our query fan-out guide for the distinction between documented behavior, simulated subqueries and observed results.

Use fan-out as a reason to inspect the evidence around a decision. For the fictional question “Which webhook service fits a small payments team?”, the following are hypothetical research needs, not queries observed in an engine:

A model could formulate different queries, repeat a search or answer without exposed search activity. Record actual subqueries only when a product or instrumented tool trace provides them. A model-generated list of “likely fan-outs” is another planning hypothesis.

Make these evidence relationships useful to a reader:

• Approach page: explain the choice.
• Limits reference: qualify that choice.
• Procedure: show how to act on it.

Several questions may use the same reference. Maintain one authoritative explanation of a limit and link to it from the pages where that condition matters.

How retrieval matches prompts to pages and passages

Distinguish lexical and semantic relevance

There are several different relevance judgments between a question and a cited page. A lexical match concerns words or phrases that occur in both. A semantic match concerns meaning: “recover missed events” and “replay failed webhook deliveries” can describe a related task without repeating the same words. Neither relationship establishes that a particular service has the required retention period.

Google's general Search documentation describes neural matching between concepts in queries and pages, RankBrain's ability to relate words to concepts, and passage ranking that uses sections of a page to understand its relevance. It describes ranking primarily at page level, with site-wide signals contributing. These are descriptions of Search systems, not an execution trace proving that every named system runs in a fixed order for every AI answer.^[23]

For generative Search specifically, Google's current optimization guide describes grounding from its Search index through core ranking systems and model-generated related queries. It also says relevant pages need not exactly match the query wording. A well-explained replay procedure can therefore be a plausible destination for several recovery questions. That is a planning implication of the documented behavior, not evidence that Google selected our example page.^[24]

Separate retrieval, reranking and passage selection

In retrieval engineering, these functions have different jobs:

• Initial retrieval finds source pages or passages to consider.
• Reranking, when used, changes the ordering of those search results using an additional relevance judgment.
• Passage selection chooses material to supply to the answer generator.

The original RAG research demonstrates one architecture with a searchable passage index; it does not disclose the retrieval stack of each commercial engine.^[1] Avoid assuming that every product uses the same embedding model, similarity threshold, number of results or reranker. Those details require product-specific evidence.

Supplying more text also needs evaluation. In the 2023 _Lost in the Middle_ experiments, Liu and colleagues varied the position of relevant information in multi-document question answering and key-value retrieval tasks. Several tested models performed better with relevant material near the beginning or end of the input than in the middle.^[28] This makes context ordering and irrelevant material useful test variables for a team building its own retrieval workflow. The tested input was assembled for the model; its position is different from a paragraph's position on a public web page. The study does not establish that moving copy to the top of a page improves citations in current engines. It demonstrates why retrieving a relevant page and using its evidence successfully require separate evaluation.

Decide whether to consolidate or split pages

Our editorial recommendation is to check two relationships independently: whether a page concerns the task, and whether its evidence answers the requirement. A page can be relevant to webhook delivery while failing to substantiate a seven-day retention claim. A short limits reference may supply that missing fact without being a complete answer to the customer's operating question. Both pages can belong in the same brief, with different jobs.

Google warns against producing separate pages for every possible question or fan-out variation primarily to manipulate rankings or AI responses.^[24] Make the publishing decision according to the task and evidence:

• Consolidate questions when one page can answer them clearly with the same evidence.
• Split the work when the reader's task, required proof or maintenance owner changes.

The split should have a reason a documentation editor can explain without referring to a prompt count.

Compare search behavior across AI engines

Record the product surface and mode with every observation. A consumer assistant, its developer API, and a deep-research workflow can use different models, tools, constraints and source presentation. A shared company name does not make their outputs equivalent.

API responses illustrate why source lists need careful labels. OpenAI's web-search API distinguishes inline citations from a broader list of consulted sources. Perplexity's Agent API advises reading returned addresses from structured search-result metadata rather than trusting addresses reproduced in generated prose.^[12][14] Store the original payload when available. A dashboard that calls every returned address a citation obscures the distinction you are trying to measure.

Group related prompts by intent and evidence

A semantic similarity measure can help suggest that two questions concern the same subject. It does not establish whether a page answers either one, whether a product meets the requirement, or whether an engine retrieves it. Your map should make the relationship understandable without a score.

Use relationship descriptions such as “same recovery task,” “adds a retention constraint,” “requires pricing evidence,” or “uses the same integration reference.” For each connection, a reviewer should be able to explain the shared requirement and the difference that remains. This makes an incorrect grouping easier to challenge than an unexplained relevance percentage.

In the Relay example, the shortlist and verification prompts might share a replay capability page. The verification question requires a more precise answer about duplicate processing than the shortlist does. The recovery procedure also needs permissions and step-by-step operating instructions. Keeping those differences visible prevents a broad capability article from being marked as complete coverage of every related question.

Allow many-to-many relationships. One prompt may need a product page, a pricing qualification and a technical procedure. One reliable technical explanation may support several prompts. Where the same passage resolves several requirements, improving that passage may be more useful than producing one new article for each wording variation. That is a prioritization recommendation, not a promise of additional citations.

Prioritize gaps using business relevance, customer consequence and the cost of obtaining accurate evidence. If a comparison hinges on a limitation the product team has never documented, the immediate task is to verify the limitation. If the answer exists but is difficult to follow, improve the appropriate page. Google likewise asks publishers to assess original value and whether content fulfills its purpose; merely adding attribution does not replace useful work.^[18]

Build internal links between related content

Use the prompt map to plan links as well as content. For each proposed connection, record the source page, destination, reader task and claim or instruction that requires the destination. This makes topical relevance reviewable: sharing a keyword is insufficient if the destination does not help resolve the question.

For the Relay example, we would connect the pages this way:

These are editorial relationships, not a reconstruction of an engine's topic graph. Place each link where the reader needs the qualification or next step, with descriptive anchor text such as “event replay limits.” Keep the main topic page linked from its relevant hub and give supporting pages a route back to the broader task.

Google recommends crawlable anchor elements with an `href`, concise descriptive link text and contextual internal links. Its guidance asks that important pages receive a link from another page on the site; it gives no ideal link count and discourages forced keywords.^[31] Check the rendered links and their destinations, including article content in the initial HTML (Hypertext Markup Language) response. A sitemap entry does not explain the relationship between two pages.

Apply the same principle to this guide: the citation-source research guide helps assess published evidence, while the Google AI search measurement guide explains the reporting available for evaluating a fixed set of prompts. Those destinations answer different follow-up questions. Neither promises that adding links will cause a citation.

Measure AI search visibility and citation support

Establish a fixed baseline and retain run evidence

For repeat measurement, select a fixed set of prompts from your prompt universe. Results describe that selected sample; they cannot establish the total distribution of customer demand.

1. Keep the baseline unchanged. Evaluate new questions, constraints and phrasings separately so the comparison continues to use the same prompts.
2. Record the test conditions. For each run, retain the exact prompt, engine, product surface, mode, timestamp, language, location setting and relevant session context.
3. Keep the captured evidence. Save the answer and source addresses. Record tool traces or retrieval queries where the product exposes them, and use “unknown” where it does not.

Adding easier branded questions to a baseline can improve its apparent performance without changing discovery for prospective customers. Lack of a visible trace is weaker evidence than an instrumented record showing what happened.

Before changing content, save the baseline and define what improvement would mean. Keep comparable unchanged topics where practical, document other releases, and repeat the same questions afterward. An increase following publication is an observation worth investigating. It does not isolate the effect of the edit from indexing changes, model updates or other events.

Interpret the metrics separately

Repeat runs and check citation support

Repeat prompts rather than treating the first answer as definitive. A 2026 study comparing Google organic search with several generative systems found variability across executions and time. Its main collection used September 2025 systems and selected English-language workloads, so its measurements should not become a current engine ranking.^[20] Repeat runs and collection dates therefore belong in your protocol.

Report a result as “our page was cited in four of ten runs under these conditions,” with the actual dates and observations. Do not rename that fraction market share, query demand or the probability that every user will see the page. Closely spaced runs may share infrastructure or context, and product changes can affect comparability.

Check the citation against the sentence, especially when the claim determines eligibility or safety. Research on generative-search verifiability separates how comprehensively claims are supported from whether each citation supports its associated statement.^[19] A high citation count can coexist with an incorrect product recommendation. Your reporting should expose that failure instead of rewarding it.

Use Search Console and Bing Webmaster Tools

Use platform data where available. Google's current Search Console generative AI report includes impressions for AI Overviews and AI Mode, with page, country, date and device dimensions. An impression is an exposure measure; it does not explain why a page appeared or reconstruct a complete prompt history.^[21] Our Google AI search measurement guide explains that report in more detail.

Bing Webmaster Tools also reports citations, cited URLs and a sample of grounding keyphrases used to retrieve cited content across supported Microsoft and partner experiences. Bing explicitly distinguishes that activity from ranking or placement within an answer.^[26] Use those phrases to investigate existing page coverage and suggest new questions. They do not, by themselves, establish the complete wording of a customer's original prompt or the reason a source was chosen.

How EarShots tracks prompts and AI search visibility

EarShots' answer engine optimization (AEO) tools connect prompt selection with recorded engine answers. Prompt Universe shows the tracked questions, their run cadence and engine results. Review an exact prompt before interpreting an aggregate visibility metric: it gives the team a specific answer, cited source and content requirement to investigate.

Compare prompt coverage across AI engines

Keep the customer question visible beside the measurement. Compare whether answers mention your product with whether they cite your pages, and inspect each engine separately. A product mention and a citation answer different questions about visibility.

Prompt Universe: questions and engine coverage

Review AI answers, citations and content gaps

Open the answer for a selected prompt and read the cited pages. Check whether their evidence supports the recommendation and whether your own documentation answers the requirement. Use the findings to assign a specific task, such as clarifying a replay limit or adding the missing recovery steps. EarShots' recommendations are work to review; an observed gap does not establish what caused an engine's selection.

Answer review: inspect the prompt, answer and sources

Explore Prompt Universe or read the Prompt Universe documentation for the workflow and available controls.

Agents: read prompt and answer data with the EarShots CLI

Agents can read an authorized workspace through the EarShots command-line interface (CLI). Follow the CLI setup and sign-in instructions, inspect the available tools, then read the stored prompt universe and answers:

earshots tools --json
earshots call aeo_get_prompt_universe '{"limit":10}' --json
earshots answers PROMPT_ID --days 30 --json

Replace PROMPT_ID with a prompt_id returned by the prompt-universe call. These commands read stored workspace data; they do not launch new engine runs or publish content. Keep the exact prompt, engine, capture date and supporting sources in downstream analysis. Agents using a compatible client can also connect through Model Context Protocol (MCP).

Turn prompt coverage gaps into a content brief

Specify the writing requirements

Give the writer a brief containing:

• Target question and origin: preserve the exact prompt and where it came from.
• Customer decision: state what the page must help the reader decide or complete.
• Page type: identify the intended kind of content.
• Evidence requirements: provide confirmed product facts and the source passages supporting them.
• Limitations and open claims: distinguish known limits from claims that remain unverified.
• Related questions: supply context without silently replacing the target question.

For Relay's recovery procedure, acceptance criteria might require a permissions check, the steps to select and resend a delivery, the expected result, and a link to duplicate-processing guidance. A separate approach article needs a fair comparison of operating responsibilities. Asking both writers to “cover webhook reliability comprehensively” would hide the different work each page must do.

Review the material before publishing

1. Check the brief and sources. Review the resulting material against its requirements and supporting evidence, including the technical instructions.
2. Confirm where it belongs. Check that proposed paths are appropriate for the site. A documentation cluster should become useful pages in the website's docs section; a comparison belongs where customers evaluate alternatives.
3. Follow the links. Confirm that they take the reader to the evidence or next task.

Our Prompt Universe documentation explains how prompt coverage fits the EarShots workflow.

EarShots' approach is to build the context map before generating prompts and campaign materials. If you want help connecting customer questions, website evidence and content requirements, contact EarShots about a context map. Bring the questions you have, the pages you can share and the decisions you need the content to support. The first deliverable should make those relationships reviewable before more drafts are commissioned.

FAQ

How many AI search prompts should we track first?

Start with a prompt universe small enough to inspect every answer and its supporting evidence. Cover distinct decisions and consequential constraints before adding paraphrases. The right size depends on your review capacity, engine coverage and repeat-run budget. A larger count has little value if important errors are never read.

Can we tell whether a brand is in a model's training data?

A normal answer or citation does not establish training provenance. A brand description can reflect learned information, inference or supplied context. Verifying training membership or causal influence requires evidence beyond a conversational response. Treat search-disabled checks as behavioral diagnostics with documented conditions.

Does each AI search prompt need its own page?

Map the evidence requirements first. Several prompts may be answered well by one page, while one prompt may need evidence from several pages. Create a distinct page when it serves a distinct reader task and can provide useful, supported material. Do not create separate pages solely to mirror wording variants.

Does a prompt-to-page map predict which pages an engine will cite?

No. It records your assessment of the evidence each question needs and where that evidence belongs. Test those proposed relationships against actual page content and separately recorded engine answers. A plausible page assignment does not establish retrieval, a citation or a recommendation.

Appendix: example data

The Relay workspace, prompts, answers, source addresses and metrics in the product images use dummy data. They illustrate EarShots workflows and do not represent customer results or live engine tests. In the Prompt Universe example, four prompts have one answer from each of four engines: 16 answers, with 12 product mentions (75%) and eight own-site citations (50%).

For a worked example of reviewing product fit and plan conditions, read our analysis of OpenAI Signals and product discovery. It separates changes in message share from the customer evidence needed to prioritize AEO questions.

Sources

1. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Lewis and colleagues, NeurIPS 2020; generator and Wikipedia-index architecture, including index replacement. Foundational research, not a specification for current search products.
2. How Do You Use Personal Data in Model Training?. Anthropic, March 16, 2026; its explanation of learning patterns and the distinction from database lookup. Does not imply that memorization is impossible.
3. Large Language Models Struggle to Learn Long-Tail Knowledge. Kandpal and colleagues, ICML 2023; pretraining coverage and factoid question answering, including controlled retraining. Not a brand-marketing experiment.
4. When Not to Trust Language Models. Mallen and colleagues, ACL 2023; parametric and retrieved factual knowledge in studied models and datasets. Retrieval could help or harm.
5. Quantifying Memorization Across Neural Language Models. Carlini and colleagues, 2022 version; extraction of known training sequences under controlled prompts. Not an audit of current consumer assistants.
6. Correctness Is Not Faithfulness in RAG Attributions. Wallat and colleagues, December 2024; citation support versus causal faithfulness, tested with Command-R+ and modified retrieved passages.
7. AI features and your website. Google Search Central; query fan-out, differences between AI features and supporting-link eligibility. Verified October 24, 2026.
8. Searching the web with ChatGPT. OpenAI; automatic search, query rewriting, follow-up searches, location and saved-memory context. Consumer-product documentation verified October 24, 2026.
9. Web search tool. Anthropic; API routing, iterative search, system-instruction steering and version-dependent filtering. Verified October 24, 2026.
10. Enable and use web search. Anthropic; consumer search, direct page fetching and differences in the new experience. Verified October 24, 2026.
11. Data, privacy, and security for web search in Microsoft Copilot and Microsoft Copilot Chat. Microsoft; generated Bing queries, document context and query visibility for the specified work products. Verified October 24, 2026.
12. Agent API prompt guide. Perplexity; bounded tool loop, input and instruction roles, source metadata. API-specific guidance verified October 24, 2026.
13. Perplexity Search API. Perplexity; ranked results and extracted content, distinct from generated answers. Verified October 24, 2026.
14. Web search. OpenAI; API citations and the broader consulted-sources field. Does not establish consumer-product equivalence. Verified October 24, 2026.
15. In-depth guide to how Google Search works. Google Search Central; discovery, crawling, indexing and serving, with no guarantee of progression. Verified October 24, 2026.
16. Overview of OpenAI crawlers. OpenAI; separate search, potential training and user-directed access purposes. Verified October 24, 2026.
17. Does Anthropic crawl data from the web?. Anthropic, April 7, 2026; ClaudeBot, Claude-SearchBot and Claude-User purposes and controls.
18. Creating helpful, reliable, people-first content. Google Search Central; original value, page purpose and editorial self-assessment. Verified October 24, 2026.
19. Evaluating Verifiability in Generative Search Engines. Liu, Zhang and Liang, EMNLP 2023; citation completeness and support in historical systems. Used for evaluation concepts, not current performance benchmarks.
20. Characterizing Web Search in the Age of Generative AI. Kirsten and colleagues, ACL 2026; main experiments collected in September 2025, selected English queries and systems. Supports repeated measurement, not a present-day ranking formula.
21. Generative AI performance report (Search). Google Search Console Help; AI-feature impressions and reporting dimensions. Verified October 24, 2026.
22. What is Pro Search?. Perplexity Help Center, last modified September 3, 2026. Consumer Pro Search workflow, sources and retained conversation context; not a complete ranking specification.
23. A guide to Google Search ranking systems. Google Search Central. General Search concept matching, passage relevance and page-level ranking; not a disclosed AI execution sequence. Verified October 24, 2026.
24. Optimizing your website for generative AI features on Google Search. Google Search Central, updated July 10, 2026. Grounding, related queries, matching beyond exact wording and scaled-content guidance.
25. Search generative AI control. Google Search Console Help. Inclusion/exclusion, inheritance and separate training controls; worldwide rollout August 31, 2026. Verified October 24, 2026.
26. Introducing AI Performance in Bing Webmaster Tools Public Preview. Microsoft Bing, February 10, 2026. Sampled grounding keyphrases and page citations across supported experiences; not ranking or answer placement.
27. Making retries safe with idempotent APIs. Malcolm Featonby, Amazon Builders' Library. Idempotent requests, retry side effects and explicit repeat-request identifiers; not evidence of the fictional Relay product.
28. Lost in the Middle: How Language Models Use Long Contexts. Liu and colleagues, November 2023 version. Controlled input-position experiments in multi-document question answering and key-value retrieval; not a test of public-page placement or current engine citations.
29. Large language models use a surprisingly simple mechanism to retrieve some stored knowledge. Adam Zewe, MIT News, March 25, 2024. Reporting on the relation-decoding study in source 30, not an independent replication.
30. Linearity of Relation Decoding in Transformer Language Models. Hernandez and colleagues, February 2024 version. Main experiments use GPT-J, 47 relation types and examples the model answered correctly; approximation and intervention results apply to studied relations, not all factual knowledge.
31. Link best practices for Google. Google Search Central. Crawlable anchors, descriptive text and contextual internal links; no ideal link count. Verified October 24, 2026.

Last verified October 24, 2026. The Relay example and the prompt-selection method are illustrative editorial recommendations. Platform descriptions are limited to the documented surfaces cited above.