Fix: ship the smallest evidence-supported change
Use Fix after Find has frozen a baseline and identified one supported gap. Choose the smallest existing page, policy, entity description, or source-coverage action that can test the hypothesis; record the exact before state, change, deployment time, and acceptance evidence; and define what would challenge the hypothesis. A fix can remove a verified problem, but it cannot guarantee indexing, ranking, a mention, recommendation, or citation.
What is the Fix stage for?
Fix converts one diagnostic record into one reviewable shipment. The stage is deliberately narrower than a site-wide optimization programme: it names the artifact, changes only what the evidence supports, and preserves enough version and deployment information for a matched re-test.
The diagnosis determines the work. A verified access problem calls for a policy or delivery correction; an extraction problem calls for visible answer structure; an entity problem calls for consistent, supported descriptions; and a third-party source gap calls for a source action. These paths are alternatives, not a checklist to apply indiscriminately.
Which Fix resource should you use?
Select by verified gap, not by tactic popularity. Review visible content and provider-specific boundaries before shipping; structured data must describe the page a person can see, and ordinary eligibility guidance does not become a citation guarantee.
| Verified need | Start with | Acceptance evidence |
|---|---|---|
| Turn a classified gap into a bounded package | /product/fix-engine | Target, before version, proposed artifact, acceptance checks, and proof instruction |
| Correct a documented crawler-policy error | /learn/how-to-allow-ai-crawlers | Served policy, provider role, test URL, response, and change record |
| Make an existing answer easier to inspect | /learn/answer-engine-optimization | Visible answer, headings, supporting sources, rendered HTML, and matching markup |
| Choose owned-page work or a source action | /product/source-intelligence | Prompt-level source mix and the exact owned or third-party target |
| Understand the parts of a bounded fix | /learn/whats-in-a-geo-fix | Artifact scope, owner, acceptance checks, and re-test plan |
| Check claims before publishing | /product/evidence-standard | Claim-to-source mapping, rejected unsupported copy, and reviewer decision |
How do you bound a fix before shipping?
Write the fix as a falsifiable change record. It should connect one observed gap to one artifact, state why that artifact was selected over the alternatives, and name a result that would leave the hypothesis unsupported.
- Reference the Find observation ID, frozen prompt panel, raw evidence, selected hypothesis, and credible alternatives.
- Name the exact existing URL, robots policy, entity description, or third-party source target; never create a plausible-looking path in the record.
- Save the pre-change content, headers or policy response, version identifier, and collection time.
- Describe only the visible text, supported markup, access rule, or source action that will change.
- Define acceptance checks that can pass before any answer-system outcome is measured.
- Record the owner, deployment timestamp, final version or hash, and rollback or correction path.
Illustrative synthetic example: one source gap, one bounded page edit
This example is illustrative and synthetic. It is not customer data, a benchmark, or evidence that the described edit changes any provider outcome.
Find preserves eight observed answers for one fixed comparison prompt. Five cite a third-party roundup that names two competitors but not the example brand. The brand's existing comparison page is reachable, but its opening does not answer the comparison directly. The record keeps source coverage, extraction, and entity clarity as competing explanations.
Fix changes only that existing comparison page: it adds a concise visible comparison answer, names the evaluation basis, cites the underlying product documentation, and updates matching structured data without adding claims that are absent from the page. Acceptance requires the canonical URL to remain stable, the answer and sources to appear in rendered and initial HTML, the markup to match the visible text, and the deployed version and time to be recorded. The expected observation is stated as a hypothesis; no mention or citation is promised.
What is in scope, and what is not?
In scope are corrections to verified access or delivery problems, supported improvements to visible answer structure and entity clarity, truthful structured data that mirrors visible content, internal navigation to relevant existing pages, and specific third-party source work supported by the Find record.
Out of scope are site-wide rewrites without a bounded diagnosis, unsupported comparison or authority claims, hidden or mismatched markup, mass page generation, fabricated sources, new URLs invented to satisfy a recommendation, and promises about crawl frequency, indexing, ranking, impressions, traffic, revenue, mentions, recommendations, or citations. Google documents no special AI file or AI-specific structured data requirement for its generative Search features; provider-specific guidance should not be generalized to every answer product.
What exactly moves from Fix to Prove?
The handoff preserves the Find observation ID and protocol; verbatim prompt and declared surfaces; selected gap and alternatives; exact artifact and canonical target; pre-change version or hash; deployment timestamp and final version; acceptance-test evidence; the expected observable outcome and the result that would challenge the hypothesis; and the proof cadence, exclusion rules, owner, and rollback path.
Prove begins only after the artifact passes its own acceptance checks. A valid deployment is not itself evidence of an answer-system effect, so the proof record must retain the original baseline rather than replacing it with a fresh after-only snapshot.
Where can you move in the workflow?
Return to Find if the evidence does not support one artifact or a pre-change baseline is missing. Stay in Fix until the shipment and acceptance record are complete. Move to Prove when the dated artifact is live and the matched panel can be repeated under the registered rules.
| Stage | Use it when | Route |
|---|---|---|
| Find | The diagnosis, target, or baseline needs more evidence | /resources/find |
| Fix | The bounded artifact is being reviewed or shipped | /resources/fix |
| Prove | The accepted shipment is ready for matched collection | /resources/prove |
Sources reviewed
Provider eligibility and measurement claims below were checked against primary documentation. These records do not establish a universal selection formula, causation, or a guaranteed ranking, impression, recommendation, or citation.
7 claim-level source records
| Claim reviewed | Official source | Review record |
|---|---|---|
| Google says its generative AI Search features use core Search systems. Ordinary Search eligibility remains foundational; no special AI file, content chunking, writing style, or AI-specific structured data is required, and eligibility does not guarantee display. | Google guide to generative AI Search optimization | Checked 2026-09-02 · Google Search guidance updated July 10, 2026 · Primary-source review; Google Search guidance is not generalized into a formula for ChatGPT, Claude, Perplexity, Gemini Apps, or other answer products. · Confidence: High |
| Google documents that AI Overviews and AI Mode use ordinary Search indexing and snippet eligibility. Search preview controls also apply, while Google-Extended is not the control for Google Search inclusion or ranking. | Google Search AI features documentation | Checked 2026-09-02 · Current Google Search AI-feature eligibility and control guidance · Primary-source review; eligibility, selection, presentation, and a supporting link are kept as separate states. · Confidence: High |
| OpenAI documents OAI-SearchBot for ChatGPT search, GPTBot for potential model training, and ChatGPT-User for user-triggered actions. Their purposes and controls are not interchangeable. | OpenAI crawler documentation | Checked 2026-09-02 · Current OAI-SearchBot, GPTBot, and ChatGPT-User documentation · Primary-source review; crawler permission is treated as an access decision, not proof of indexing, ranking, retrieval, or citation. · Confidence: High |
| Anthropic documents ClaudeBot for potential model training, Claude-SearchBot for search indexing, and Claude-User for user-directed retrieval, and says all three honor robots.txt. | Anthropic crawler documentation | Checked 2026-09-02 · Crawler taxonomy updated April 7, 2026 · Primary-source review; provider-specific access roles are not converted into a general AI visibility guarantee. · Confidence: High |
| Perplexity documents PerplexityBot for search discovery and Perplexity-User for user-triggered fetching; it recommends verifying both the user agent and published IP ranges. | Perplexity crawler documentation | Checked 2026-09-02 · Current PerplexityBot and Perplexity-User documentation · Primary-source review; a permitted or verified fetch remains distinct from answer selection and citation. · Confidence: High |
| Google recommends helpful, reliable, people-first content and asks publishers to explain who created content, how it was produced, and why it exists. These quality questions are guidance, not a disclosed ranking formula. | Google helpful content guidance | Checked 2026-09-02 · Current people-first content and authorship guidance · Primary-source review; editorial quality guidance is not represented as a guaranteed Search or generative-AI outcome. · Confidence: High |
| Google's structured-data policies require markup to represent visible page content, include every required property for the applicable feature, and avoid misleading information. | Google structured-data general guidelines | Checked 2026-09-02 · Google Search guidelines last updated 2026-07-10 · Primary-source review; this supports content-markup consistency, not an AI citation mechanism, ranking factor, or display guarantee. · Confidence: High |
Frequently asked questions
It references one Find record, changes one named existing artifact or source action, preserves a before version, defines acceptance checks independent of a provider outcome, records the deployment, and specifies what result would challenge the hypothesis.
No. Access, extraction, entity, source, and prompt-fit gaps require different work. Apply only the change supported by the diagnostic evidence, then preserve the alternatives for Prove.
No. Supported structured data can describe visible content in a machine-readable form, but it does not guarantee indexing, selection, a link, mention, recommendation, or citation. It must match what a person can see on the page.
When the declared policy and delivery problem has been corrected and verified for the exact URL and provider role under review. That acceptance result does not establish indexing, retrieval, or citation.
After the exact artifact is live, acceptance checks pass, the pre-change version and deployment time are preserved, and the original prompt panel and exclusion rules remain available for a matched re-test.