ChatGPT has wrong business information. Now what?

Search for “ChatGPT wrong business information” after an assistant quotes a price you stopped charging, and most advice begins with updating your website. Fine, if your website is wrong. Less useful if the pricing page is already correct and the answer cites an old partner listing, confuses two plans, or attaches your name to another company's product.

The first task is to locate the claim, not rewrite the homepage. Save the answer. Open the evidence. Check exactly which statement is false and which fact would make it correct. The fix belongs where that evidence points, which may be a page you own, a page you do not own, or an explanation the assistant inferred without visible support.

Visibility reporting can miss this problem completely. Your company appears in the answer, so the mention count rises. The sentence says your product lacks a capability it actually has, so the buyer rules you out. A better number and a worse recommendation can describe the same event.

What follows is a repair workflow for ordinary product facts: pricing, features, company identity and availability. The workflow is our proposed way to investigate a saved answer. It is not a platform correction service, and it cannot promise when an assistant will adopt a change.

A screenshot of the wrong sentence is a useful alarm. It is a poor investigation record on its own. Keep the full response and the prompt that produced it, including relevant earlier messages. A question that already contains an old price can produce a different failure from a neutral question asking for current pricing.

Write the error as one testable statement. “The assistant misrepresented us” is too broad. “The answer says the entry plan has no exports, but the current plan includes CSV exports” gives someone a fact to verify. Name the plan, the type of export and the effective date of the capability.

• Save the exact prompt, complete answer, date, assistant and visible model or mode.
• Record the language and any region or account context that could affect the question.
• Copy the cited URLs and the sentence each one appears to support.
• Write the correct fact with its evidence and the person who can confirm it.
• Describe the buyer consequence: wrong budget, rejected shortlist or unsuitable expectation.

Keep private customer details out of anything you publish or send to an external platform. You can preserve the original internally while using a redacted reproduction for a correction request. The useful part is usually the product fact and its context, not the prospect's name or the contents of their account.

Open the actual cited page and find the passage. Does it say the wrong thing, or does the assistant say something the page never says? Those require different actions. Asking a publisher to correct a sentence it did not write wastes time and leaves the original failure unexplained.

Treat citations as evidence to inspect, not a complete account of how the answer was assembled. OpenAI's web-search API documentation distinguishes inline citations from the larger set of consulted URLs available through its sources field. That is an API capability, not a promise that a consumer chat exposes a full retrieval record.

The practical consequence is restraint. A visible citation is a lead. No visible citation leaves the provenance uncertain. You cannot establish from missing links alone that an answer came entirely from training data, or that changing a public page could never affect a future answer. Record what the interface actually shows.

Search the exact erroneous phrase together with your product name. Look for the same number, plan label or discontinued feature across your own site and the cited sources. If a likely origin appears, mark it as a candidate until the evidence supports the connection. Similar wording is useful; it is not a trace of the model's internal reasoning.

The page is out of date

An old help article still describes the retired plan. The answer repeats that article accurately but presents it as current. Fix the dated source or make its historical scope unmistakable, then link to the current product information. A new blog post elsewhere leaves the old source available to be found again.

The answer dropped a condition

The source says exports are included on an annual plan. The answer says exports are included, full stop. This may be an extraction problem rather than an incorrect source. Check whether the condition is separated from the feature in a footnote, a tab or a distant section. Bring the condition into the statement a reader is likely to reuse.

The answer merged two businesses

The name matches, but the industry, domain or product does not. Record the identity mismatch explicitly. A pricing correction for your company cannot repair an answer about a different company with the same name. The relevant evidence is the relationship between the brand, its website and the product being discussed.

You cannot find support for the claim

The response states a fact that none of the visible sources supports. Call it an unsupported claim in your record. Do not invent a source to make the investigation feel finished. Publish a clear answer where that information belongs if it is missing, and keep the cause unresolved until you have stronger evidence.

There is a fifth outcome worth allowing: the answer is correct and the team dislikes it. A product that does not support the requested workflow should not be described as supporting it. Correct AI answers can still be commercially inconvenient. The owner of the capability needs to settle the fact before marketing settles the wording.

Start with the page that owns the fact. Pricing belongs with pricing. An integration limit belongs in the integration documentation. A company rename belongs in an explanation connecting the old name to the current one. Give the reader a place where the answer can remain current without being copied into a dozen unrelated articles.

State the subject and condition together. “CSV exports are included on the monthly Starter plan from August 1” is more useful than “exports now available.” The second version leaves the reader to infer the format, plan and date. Those are exactly the gaps an inaccurate summary can fill incorrectly.

Check the nearby surfaces that repeat the claim. The visible pricing card may be correct while a comparison page, downloadable guide or metadata description still carries the old limit. This is a targeted search for the disputed fact, not permission to rewrite every page that mentions the product. Correct each contradiction you can demonstrate.

Keep historical material recognisable as history. A launch announcement describing a real old offer does not need to pretend the offer never existed. Add a clear note where necessary and point to current terms. A reader researching the old product should still be able to understand what was true then.

If a comparison made the mistake, review the assumption behind the verdict as well as the number. A lower price may no longer be lower under the current workload. Writing comparison pages around explicit buyer constraints makes these corrections easier because the reason for the recommendation is visible.

Prioritise the external pages that actually appear in your saved answers. A directory nobody in the sample used might still matter, but it is a weaker starting point than the partner page beside the false claim. Keep a list of the source, the error, the correction requested and its status.

Where you control a verified business profile, update the relevant field and save the result. Where a publisher owns the copy, prepare a factual request: the page URL, the exact disputed sentence, the corrected statement and a source proving it. A request to replace an old price is much easier to assess than a demand to describe your company more favourably.

Distinguish an error from an old review of an old version. An author may have accurately described the product they tested. Ask for an update note or a link to current information if that is the real issue. Do not ask someone to erase a negative experience or publish a feature claim they have not checked.

If the page cannot be changed, record that limit and strengthen the current source you own. You can publish an accurate, dated explanation and make it easy to find. You cannot force another publisher to update, or promise that an assistant will prefer your explanation on the next run. That uncertainty belongs in the status report.

A correct page behind an access failure is not a completed repair. Check that the URL resolves, the important statement is present in the returned content and your intended search crawlers can reach it. Inspect the public page as well as the preview. A CMS saying published does not establish what an external request receives.

OpenAI's crawler documentation separates OAI-SearchBot, used for ChatGPT search, from GPTBot, used for potential training collection. Those controls are independent. It also distinguishes user-initiated ChatGPT-User requests. Allowing training collection is not a prerequisite for allowing search access.

Inspect the specific rule and the actual response before changing anything. A blocked search crawler, an accidental noindex directive and a firewall challenge are different findings. A development preview may correctly be private. The question is whether the public source you intend to be discoverable is available under the relevant conditions.

Passing an access check only removes one possible obstacle. It does not establish that the corrected page was selected for an answer. Keep access verification in its own column so a successful fetch does not become a claim that the misinformation is fixed.

Use it to describe accurate facts consistently, and be precise about the promise. Google's Organization structured-data documentation says the markup can help Google understand and distinguish organisations. That does not establish that adding Organization markup will correct a particular sentence in ChatGPT.

If two businesses share a name, explain your identity in visible text: the product, the company behind it and the official domain. Keep that explanation consistent with your markup and public profiles. Useful fields describe relationships that actually exist. Adding a competitor's profile as if it were yours would introduce another error.

The same restraint applies to a new machine-readable file. Before shipping a format as a repair, ask which documented consumer reads it and how you will observe the result. Our article on llms.txt examines why publishing a file and demonstrating that it changed citations are different jobs.

A clear product page with maintained facts is a useful asset regardless of the next assistant response. An undocumented correction ritual has to earn its place through evidence. Keep the work focused on the disputed claim and the systems you can actually observe.

There is no single clock. Publishing the correction, making it discoverable, having a system retrieve it and seeing a correct generated answer are separate events. Record their dates separately when you can observe them. Otherwise an update timestamp starts carrying a promise it cannot support.

For Google, the recrawl guidance says crawling can take days to weeks, and a request does not guarantee inclusion. It also says repeated requests do not accelerate the crawl. That is a Google statement about its own process, not a schedule for ChatGPT, Claude or Perplexity.

You can ask a diagnostic question that points directly at the corrected URL. If the assistant reads it correctly, you have evidence that the page can support the answer in that interaction. Keep that test separate from the original buyer prompt. Handing over the source changes the task and removes the discovery problem you were trying to measure.

Check again on a schedule that fits the consequence of the error. A weekly review is a reasonable starting practice for ordinary product facts; a customer-facing mistake actively affecting decisions may deserve earlier checks. Choose the cadence deliberately. Neither cadence creates a deadline that an external assistant has agreed to meet.

Consider a fictional scheduling product called Harbour. The saved answer says Harbour has a ten-seat minimum. The current pricing page says two seats, but an older comparison page still says ten. A citation beside the answer leads to that older comparison. These details establish a concrete inconsistency worth fixing, without proving the full cause of the answer.

The team confirms the effective date with the person who owns pricing, corrects the old comparison and checks other owned pages for the same claim. It keeps a record of the old text, the replacement and the public URLs. An external directory repeating ten seats gets a separate correction request with the current pricing source attached.

For an illustrative baseline, suppose the original prompt produces the wrong minimum in six of ten valid runs. In the later sample, two answers still say ten seats, three correctly say two, and five do not state a minimum. Those are invented counts to demonstrate the reporting, not Beseen customer results.

The wrong-claim count fell from six to two. The correct fact appeared three times. Five answers did not settle the question. Reporting eight correct answers would be wrong because silence does not establish the fact. Report all three outcomes, and keep technical failures outside the set of valid answers with their count shown separately.

That result supports continuing the investigation. It does not establish that the page correction caused the difference, or that future buyers will always see two seats. The guide to testing whether a change moved an AI answer explains why repeat runs and comparisons beyond the changed page matter.

Once you have told an assistant the correct fact, the conversation is no longer a clean test of what a new buyer might see. The correction is now part of the input. A later answer in that conversation can be perfectly accurate without any public source having changed. Save it as a diagnostic result, then start a fresh conversation for the original question.

Keep two prompt sets if necessary. One reproduces the buyer question without supplying the answer. The other deliberately asks the assistant to inspect the corrected source. The first tests what your chosen sample of buying conversations produces. The second helps establish whether the page explains the fact clearly when it is provided. Improvement in one does not establish improvement in the other.

Preserve regional context as well. A price can be right for one currency or market and wrong for another. If the original buyer asked from a particular region, include the same stated region in the repeated question and record any settings you cannot control. Avoid calling a regional difference a stale fact until you have checked the relevant offer.

Decide the counting rule before reviewing the new answers. A correct current price, an incorrect price, an explicit admission of uncertainty and no price at all are four different outcomes. An answer that says it cannot verify the price may be safer for the buyer than a confident error, but it is still not evidence that the current price reached them.

End the review with the next unresolved fact, not another attempt to persuade the assistant. If the direct-source test succeeds and the ordinary prompt keeps failing, investigate discovery and competing sources. If both fail, inspect the page and the interpretation again. That split makes the next hour of work much more specific than asking the same question until a reassuring answer appears.

The source task closes when the intended correction is publicly visible and its dependent statements agree. The answer task needs later evidence: fresh runs of the original question, reviewed for the exact claim. Keeping two statuses prevents a published edit from being reported as a repaired recommendation.

Save what remains unresolved. Perhaps the owned pages are correct but the directory has not responded. Perhaps the direct question is accurate while the comparison still merges two tiers. These are specific next actions. “AI brand accuracy improved” is too vague to tell the next person where to look.

Beseen's a free report gives you observed searches, answers and competing names to inspect. Read the sentences as well as the presence of your brand. The first report is a starting point for finding the wrong claim; it does not certify that every product fact is correct or replace the later check.

Keep the original wrong sentence beside the correction until the evidence lets you close both tasks. Being named matters. Being named for a product you actually sell matters more than a dashboard that simply counted the name.