What to do when an AI answer gets your business facts wrong

1. Save the answer before you try to fix it

An AI answer says your business has an office in a city where you only serve customers remotely. Or it lists a service you stopped offering. My first step would be to preserve the exact wording. Without that record, a later conversation can turn into a debate about what the answer might have said.

Keep the question, any relevant follow-up, product and mode, date and time, language and market setting where available. Record whether search was enabled and save the visible source URLs. A Google AI Overview, a search-enabled assistant and a conversation without web search are different observations.

• Capture the inaccurate sentence and enough surrounding text to understand it.
• Save the source destination, not just the label shown in the answer.
• Record whether the answer appeared in a fresh conversation or after earlier messages.
• Keep a redacted screenshot or permitted private record, with an observation reference.

Do not publish a conversation screenshot containing customer details or account information. I would keep the evidence in a restricted working log and use a redacted extract when asking a publisher to investigate. Our AI visibility measurement guide explains how to record comparable observations; here the goal is to investigate one specific factual error.

2. Decide what kind of error you are looking at

Before blaming a directory or rewriting your website, open the sources and read them. A citation may relate to part of an answer without supporting the sentence you are concerned about. I would not call a cited website the cause until the relevant claim is actually present there.

A confident tone does not make an answer reliable. OpenAI explains that ChatGPT can produce incorrect facts and even fabricated references. That is a reason to verify a claim, not proof of where this particular error came from.

3. Trace the fact back to a reliable business record

I would ask the business owner to confirm the correct fact before approving public changes. For service scope, that may be an approved service description. For an office location, it may be the current public contact record and confirmation that the office genuinely operates there. A social post is not automatically the best source for either.

Check relevant first-party pages first: service pages, the About page, contact information and old announcements that remain public. Then review owned profiles and the specific third-party references implicated by the observation. Keep the review focused; you do not need to edit every online mention because one answer was wrong.

• Identity: are the brand name, domain and public contact details describing the same business?
• Services: does the page distinguish current offers from historic projects or services no longer available?
• Geography: does it separate an operating office from a market served remotely?
• Dates: is an older announcement clearly dated, rather than presented as current information?
• Authority to change: who owns the record, and who can approve the replacement wording?

Where the answer mixes an office with a service area, I would make that distinction explicit on the relevant page. I would not create a fake address or a new location profile to make the invented claim look true. If a record is ambiguous, settle the business fact before trying to optimise its presentation.

4. Correct the source you control, not just the wording you dislike

For your own website, use a clear, approved statement on the page where a customer would expect to find it. “We support clients in this market remotely; we do not have a local office” may resolve a genuine ambiguity. Do not add that sentence everywhere or turn the site into a list of denials.

Keep historic information where it remains useful, but explain its date and current status. If a service has ended, review the page’s purpose and customer next step before deciding to update, retire or redirect it. Sending every outdated page to the homepage can leave visitors without an answer.

Check visible text and structured data together. A profile or schema field should not contradict the page, and it must not claim an address, qualification or service the business does not have. Our structured data guide covers this relationship. Google’s structured data documentation describes how markup helps it understand page information; markup is not a universal command to correct an AI answer.

After an approved edit, check the public page as an ordinary visitor. Verify that the wording is visible, the URL works, relevant links reach the right destination and any related markup agrees. Save the release date and a safe copy of the changed passage. That proves what you changed, not what an answer product has subsequently used.

5. A worked correction log

Hypothetical example only: Example Advisory is a fictional business. No answer product was tested, no publisher was contacted and no correction was accepted. The rows below illustrate the records I would keep, not results from a client engagement.

Assume the owner confirms that the business provides remote consulting, has no office in Bristol and stopped offering hosting support. The observed answer is described only for this example. A correction ticket must distinguish those verified assumptions from a source we have not identified.

For a real ticket, I would also save the observation reference, exact question, product conditions, date, claim wording, source URL if known, approved correction, responsible person and next review date. Add separate fields for source changed, request acknowledged and answer rechecked. “Feedback sent” is not the same as “error resolved”.

6. Ask the right owner for a correction

A publisher request should be narrow and easy to verify. Identify the page, quote the disputed factual statement, explain the correct fact and link to suitable public evidence. Ask for a correction, not a favourable review or a promotional rewrite.

For the fictional directory example, the request could read: “Your profile lists Example Advisory as offering 24-hour support. Our approved service information describes scheduled consulting and does not offer 24-hour support. Please review the profile against the linked service page and correct that statement.” This is example wording, not a request sent to a real publisher.

Do not attach private contracts, client lists or identification documents to a routine correction request. Where a platform requires verification, use its official process and share only what that process genuinely needs. Record its response honestly, including refusals and unanswered requests.

Product feedback is a separate action

For Google AI Overviews, Google’s current instructions describe the thumbs-down control, followed by reporting the problem and adding details. Feedback includes the recent query and its results. Check the current interface and Google’s AI Overview feedback instructions before submitting; the workflow may differ on another surface.

For ChatGPT, inspect the response feedback options available in your interface. OpenAI separately documents reporting for safety, legal and policy concerns; that is not a guaranteed business-fact correction service. Use the route that matches the actual issue and consult OpenAI’s reporting guidance when the concern belongs in that process. Do not label an ordinary service-description error as a legal violation simply to escalate it.

For other products, use their current official help pages rather than assuming Google or ChatGPT instructions apply. Include the observed claim, the supporting public fact and enough test context to locate the issue. A submitted report does not establish that the source, index or model has changed.

7. Recheck the answer and keep unresolved cases visible

First verify whether the source correction is publicly visible. Then repeat the original question under the recorded conditions, preferably in a fresh conversation where relevant. Keep variants in a separate exploratory set rather than quietly changing the question until you receive a favourable answer.

If the next answer is accurate, record that observation and its date. I would not describe one successful retest as a permanent fix, or claim the source edit caused it without further evidence. If the error remains, retain the record and review whether other sources conflict or whether the product still offers no identifiable support for the claim.

Set a review date that fits the issue and the team’s capacity. There is no universal waiting period after which every AI product adopts an updated fact. Repeated tests every few minutes rarely tell you whether the underlying information has changed.

Prioritise errors that could misdirect a customer, create a false service expectation or confuse the business’s identity. Keep them separate from preferences about tone and genuine criticism. If customers encounter an urgent wrong contact detail, correct the public record promptly and communicate through your own established channels while the answer issue remains under investigation.

Common questions