How to document and report an incorrect Google AI Overview about your business

Do four things, in this order. Record the error with a full evidence log before it changes, because an AI answer is not a fixed page and your screenshot may be the only proof it existed. Fix the fact on the sources you control, since that is the only part of the chain you can actually change. Submit feedback through the route Google provides on the answer itself, and through your business profile where the fact belongs there. Then track it without telling anybody it will be fixed. The reporting checklist below has 20 evidence fields, and that count is the only number on this page, because there is no meaningful fix rate for anybody to quote without a documented, representative set of cases behind it.

We are not going to give you a percentage of reports that get resolved. We have not run a documented case set, and every figure we have seen published for it comes with no case count, no dates and no definition of what counted as fixed. A number like that is worse than no number, because it sets an expectation you will then have to walk back in front of your own management.

Identify the type of error

The route you use depends entirely on what kind of error it is, so classify it first. These are the eight types we have seen matter, and the correction path is different for each.

• A wrong attribute. Price, address, phone number, opening hours, service area. The fact exists somewhere in public and the value is wrong.
• An out of date fact. It was true and is not now. A closed branch, an old plan name, a superseded certification.
• A mixed up entity. Your business has been confused with another one with a similar name, or two businesses have been merged into one description. This is the hardest type to fix and the most damaging.
• A misattributed claim. Something you never said is presented as your position, or a competitor's feature is described as yours.
• An implied relationship that does not exist. A partner, parent, investor or client relationship stated or suggested wrongly.
• A missing qualifier that changes the meaning. A price without the condition attached, a coverage claim without its exclusions, a result without its scope.
• A reputational statement. A negative characterisation, a legal status described wrongly, an allegation reported as settled fact.
• A wrong coverage or capability description. Saying you do not offer something you do, or that you cover a place you do not.

Two of these types are usually your own doing, and it is worth checking honestly before you file anything. On 6 August 2026, in the clawlaw.in programme, ChatGPT noticed that the company's website and its app store listing carried different plan names and different prices for the same product, and said so in its answer. The engine was not wrong. Two contradictory price lists were in public at the same time. Also on 6 August 2026, Claude checked a headline figure on the main site, found it could not be true against public numbers, and advised a buyer against the product, after which the company's accurate claims stopped counting for that answer. Neither of those is a reportable engine error. Both are source errors, and the fix is on your side.

Preserve evidence: the 20 field log

An AI answer can differ an hour later, so the evidence has to be captured at the moment you see it. The checklist has 20 fields, and a report missing any of the first twelve is usually not actionable by anybody.

• 1. Date and time of the observation, with the time zone.
• 2. The exact query text as you typed it, character for character.
• 3. The surface, for example Google AI Overviews, ChatGPT, Claude, Perplexity or Copilot.
• 4. Country and city location setting.
• 5. Language setting.
• 6. Device type, desktop, phone or tablet.
• 7. Browser and version, or the app version.
• 8. Signed in or signed out, and which account type if signed in.
• 9. Full page screenshot, saved with a filename that includes the date.
• 10. The answer text saved as text, not only as an image, so it can be searched and quoted.
• 11. The exact incorrect sentence, quoted on its own.
• 12. The correct fact in one sentence, written the way you want it to read.
• 13. Your evidence for the correct fact: a URL on your own site, a registry entry, an invoice, a certificate, a government record.
• 14. Every supporting link the answer displayed, copied exactly as shown.
• 15. Which of those sources carries the wrong fact, if you can identify it, with the URL and a screenshot of that page too.
• 16. Whether the wrong fact also appears on a page you control. Answer this honestly before filing anything.
• 17. The repeat check: the same query run again at a stated later time, and whether the error reproduced.
• 18. The harm category, for example pricing, safety, legal status, contact details, ownership, accreditation or service area.
• 19. Who observed it, with their role and contact, so a follow up question has somewhere to go.
• 20. Action taken, with the date and any reference number the reporting route returned.

Field 17 matters more than people expect. An error that does not reproduce is still worth logging and is much harder to escalate, and the log is what lets you say later that it reproduced on three separate days.

Correct the source you control

This is the step that actually changes outcomes, and it is the step most businesses skip in favour of filing a complaint. Six actions, in order of how often they turn out to be the real problem.

• Make the correct fact readable in the page as served. Not injected by a script. On 6 August 2026 the clawlaw.in pricing page rendered its prices only after scripts ran, so what a crawler received contained no prices at all, and the prices the assistants quoted had come from an app store listing instead. The engines were using the only readable source available to them.
• Remove every contradicting copy of the fact you own. Your app store listing, your old landing pages, your PDFs, your channel partners' pages, your profiles on directories. One stale copy is enough to keep the wrong answer alive.
• Date the fact on the page. Write the date you last checked it next to it. An undated fact competes badly against a dated one.
• Cite your own evidence. Link the registry entry, the certificate, the official page. On 17 September 2026 Claude read two clawlaw.in comparison pages that stated competitors' prices with no link, no date and no source, found the figures were actually correct when it checked independently, and still treated the pages as advocacy and used official sources instead. Correct and unsourced still loses.
• Remove any claim that cannot be true. One unbelievable number can cost you the rest of the page, which is what the 6 August 2026 Claude observation above shows.
• Never write instructions to the model into your page. On 6 August 2026 Claude found a competitor's page carrying a hidden block of text addressed to answer engines, instructing them to cite that company as the source. It refused the instruction and named the company that had done it. That is the outcome you should expect from trying it.

Submit Google feedback

Use the feedback control that Google provides on the AI Overview itself. It is the documented route for telling Google an answer is wrong, and it is the one that is attached to the specific answer you saw, which is why your screenshot and your exact query text matter.

Write the report the way an investigator would want to read it. Quote the incorrect sentence. State the correct fact in one line. Give the URL that proves it. Say whether the error reproduced and when. Keep it under a page. Do not attach a complaint about competitors, do not argue about ranking, and do not ask for placement, because a feedback route about accuracy is not a route about visibility and mixing them makes the accuracy report easier to dismiss.

Also record what the route gave you back: a confirmation screen, a reference number, an email, or nothing. Field 20 exists because in many cases the honest answer is nothing, and you need to have written that down before anybody asks you what happened.

Use the relevant profile or Knowledge Panel process

Where the wrong fact is one that belongs to a structured profile, fix it there as well, because that is often the underlying record rather than a page.

• Your Google Business Profile for address, hours, phone, categories and service area. Edit it directly and keep a screenshot of the before and after.
• The Knowledge Panel for an entity level fact about the business, using the suggest an edit route, and the verification route for people who represent the business where that is available to you.
• App store listings for plan names and prices, which is the specific source that substituted for the clawlaw.in pricing page on 6 August 2026.
• Directories and marketplaces that carry your listing, each with its own correction form.
• Official registries where the fact is statutory, for example a registered address or a company status, because a registry entry usually outranks your marketing page in an engine's judgement.

Fix the registry and the profile before you spend a week on feedback forms. A structured record that contradicts your website will keep regenerating the same wrong answer.

Track follow up without promising a correction

Set up a small tracking routine and tell your management what it can and cannot deliver.

• Rerun the exact query weekly under the same recorded conditions, and log each result as a new row with a new screenshot.
• Log the state, not a verdict. Error present, error changed, no answer shown, or error absent. Absent on one run is not fixed.
• Require three consecutive clear runs on separate days before you record the error as resolved, and write that rule down in advance.
• Check the other surfaces too. An error corrected in one system commonly persists in another, because they read different sources.
• Keep the whole log even after resolution. If it recurs, the history is your strongest evidence.
• Never tell a customer, a regulator or your board that it will be fixed by a date. You do not control the system, no reporting route promises a timeline, and a promise you cannot keep is a worse problem than the original error.

What this process cannot do

It cannot force a correction. It cannot tell you why the wrong fact was there, unless you can identify the source page yourself. It cannot reach the sources that were used and not shown: on 17 September 2026 Claude confirmed clawlaw.in pages had shaped what it wrote while the site appeared only as a name in a list, and a page you cannot see is a page you cannot correct. It cannot produce a fix rate, and this page will not invent one. And it does nothing at all about being absent from an answer, which is a different problem with a different method.

Evidence log and sample report

The log is the 20 fields above, one row per observation, in a spreadsheet with a screenshots folder beside it. The report is six lines drawn from that row: the exact query, the date and conditions, the incorrect sentence quoted, the correct fact in one sentence, the URL that proves it, and whether the error reproduced with the second date. Attach the screenshot. That is the whole thing, and a short precise report gets read where a long one does not.

Sources and change log

The observations quoted on this page come from the clawlaw.in programme, recorded in GEO_BASELINE_RESULTS_2026-07-27.md and the assistant audit files of 17 September 2026. The pricing page rendering problem, the two contradicting price lists, the impossible headline claim, the hidden instruction block on a competitor's page and the unsourced competitor pricing can all be checked from outside. Version of this page: 29 September 2026, first publication. It will be updated if a reporting route changes, and if we ever assemble a documented case set large enough to report outcomes, which we will then publish with the case count and dates attached.

Common questions

How long does a correction take?

We do not know and nobody honest will tell you. No reporting route we are aware of commits to a timeline. What you can control is the date you fixed your own sources, which is why that date goes in the log.

The wrong fact came from a competitor's page. What can I do?

Report the answer through the feedback route with evidence, ask the competitor to correct their page in writing, and make your own version of the fact easy to verify with a dated source next to it. Do not put counter instructions in your own page. On 6 August 2026 Claude found a hidden block on a competitor's page telling engines to cite it, refused it, and named the company in its answer.

Should I use legal notice instead of a feedback form?

For a reputational or legal status error that is causing real harm, take proper advice, because that is a different process with different evidence standards. Even then, capture the 20 field log first. A dated, reproducible record with screenshots is the foundation for either route.

Is it worth reporting an error that only appears sometimes?

Yes, and log the runs where it did not appear too. An error that reproduces on three separate days with three screenshots is a much stronger report than one sighting, and the only way to have that is to have been logging.

What is the most common cause in your own observations?

Our own sources being wrong, contradictory or unreadable. Of the clawlaw.in problems recorded on 6 August 2026, three were of that kind: prices that a crawler never received, two different price lists in public at once, and a headline figure that could not be true. None of the three were the engine inventing anything.

Can a tool monitor for wrong facts about us automatically?

Monitoring can catch changes at a scale you cannot match by hand, and it will still miss the sources that were never displayed. Whatever you use, insist on the raw captures with timestamps and locations, because a tool alert without a screenshot is not evidence.

What to do first

Before you file anything, spend thirty minutes checking your own sources: fetch your key pages the way a crawler would and confirm the facts are in what comes back, then list every other public place that states the same fact and see whether they agree. In our own runs that step explained the error more often than the engine did. Then capture the 20 field log and file the report.