A prospect asks Gemini about your company and learns you don’t serve their suburb — you do. ChatGPT tells someone you charge for estimates — you don’t, and the competitor it named as the free-estimate option closed that deal. Perplexity confidently describes services you exited two years ago, cites your address from three offices back, or — the nastier variants — blends you with a similarly named business across the state, attributes their one-star reputation to you, or states you’ve closed. Wrong AI information about a business isn’t hypothetical anymore; it’s a routine finding of any mention audit, and unlike a wrong listing in a directory, it compounds silently — repeated to prospect after prospect, in a voice people instinctively trust, with no notification to you that it’s happening.
The good news is structural: AI systems don’t invent most of their errors — they inherit them. Wrong answers about your business are overwhelmingly downstream of wrong, stale, or ambiguous sources: the old address still live on a directory, the abandoned Yelp listing, the services page you never updated after the pivot, the name collision no source disambiguates, the scraped-and-frozen data in some aggregator feeding everyone else. That inheritance is the lever — because while you mostly can’t edit an AI model, you can absolutely edit the web it reads. The correction discipline is therefore a supply-chain repair job: trace each error to its probable sources, fix the sources, strengthen the authoritative signal so retrieval prefers it, use the platforms’ own feedback channels for what they’re worth, and re-verify on a cadence — with escalation paths for the rare case that’s genuinely defamatory rather than merely stale.
This guide is the protocol: the error taxonomy (stale facts, entity confusion, hallucinated specifics, unfair characterizations — each with a different fix profile), the diagnosis step that turns “the AI is wrong” into a source list, the correction sequence — your owned properties first, the citation supply chain second, the feedback mechanisms third — the disambiguation playbook for name-collision cases, honest timelines (retrieval-backed answers can update in weeks; model-memory errors linger until retraining), and the escalation ladder for the serious cases.
AI systems mostly inherit errors from the web they read — so corrections work upstream. Diagnose first: capture the wrong answer verbatim (screenshot, date, engine, prompt), check the citations when the answer shows them, and classify the error — stale facts (old address/services/hours living on outdated sources), entity confusion (blended with a similarly named business), hallucinated specifics (invented prices, policies, claims with no source), or reputation mischaracterization. Fix in sequence: (1) your owned layer — site pages current, correct, unambiguous, in crawlable HTML with LocalBusiness/Organization schema stating the canonical facts; (2) the citation supply chain — Google Business Profile, the major directories and data aggregators, review platforms, anywhere the audit’s citation column or a brand search finds the stale fact, corrected at each source; (3) platform feedback — the thumbs-down/report mechanisms on wrong answers (low individual power, nonzero in aggregate) and formal correction routes where platforms offer them. Entity confusion gets the disambiguation playbook: explicit differentiators on your about page and profiles (“not affiliated with [X] of [city]” where warranted, distinct naming, consistent NAP). Timelines: search-backed answers (Perplexity, ChatGPT-with-search, AI Overviews) can update within weeks of source fixes; pure model-memory errors persist until retraining — which is why strengthening retrievable truth beats arguing with the model. Re-verify quarterly via the mention audit; escalate genuinely defamatory or persistent-harm cases to formal platform processes and counsel.
Step 1: Diagnose Before Correcting — From “It’s Wrong” to a Source List
- Capture the evidence properly: the exact prompt, the full answer verbatim (screenshot), the engine and mode (search-backed or not — it changes the fix), the date, and the cited sources when shown. Sloppy capture (“ChatGPT said something wrong about our prices last week”) makes every later step guesswork; this is the same rigor as the audit’s scoring sheet, because corrections are usually audit findings.
- Reproduce with variance in mind: re-run the prompt (fresh session) and 2–3 phrasings — a wrong claim appearing once in five runs is low-priority noise; one appearing consistently is an inherited fact with a live source behind it.
- Trace the source: when the answer cites, follow the citations — the wrong fact is usually sitting right there. When it doesn’t, search the claim yourself: the old address in quotes, your brand plus the wrong service — the stale directory entry, forgotten profile, or ancient page that’s feeding it typically ranks findably. No findable source at all + specific invented details = genuine hallucination (a different fix class, below).
- Classify: stale fact / entity confusion / hallucination / mischaracterization — because the four route differently, and misrouting (arguing with a model about a fact a directory is feeding it) wastes the effort.
Step 2: The Owned Layer — Make the Truth Authoritative and Machine-Readable
Before chasing third-party sources, make your own properties an unambiguous statement of the canonical facts — the engines weight the business’s own site heavily when it’s crawlable and consistent, and every gap in it invites inheritance from worse sources:
- The facts page audit: current services (with exited ones affirmatively absent — and ideally a redirect or note where the old service page lived, per the decay treatments), service area stated explicitly, address/phone/hours current everywhere they appear (footer, contact, about, location pages), pricing policies stated if pricing is a recurring error (“free estimates” on the page beats correcting its absence downstream).
- Structured data as sworn testimony: LocalBusiness/Organization schema carrying name, address, phone, URL, service area, hours — the machine-readable layer engines cross-check against — kept in exact agreement with the visible content and delivered server-side. Schema contradicting the page, or old schema surviving a redesign, manufactures exactly the inconsistency corrections are meant to kill.
- Freshness signals: a visibly maintained site (honest dates, current copyright, recent content) reads as a live business to systems deciding which source to trust about whether you’ve, say, closed — the “permanently closed” error class feeds on abandoned-looking footprints.
- An “About / Facts” anchor: one page stating the canonical story — founded when, by whom, serving where, doing what, credentialed how — gives retrieval a single strong document to prefer, and gives every later correction request a URL to point at.
When a specific wrong claim recurs (‘they charge for estimates,’ ‘they don’t serve Plano’), answer it explicitly and affirmatively on the relevant page in plain declarative language — ‘Estimates are free.’ ‘We serve Plano, Frisco, and McKinney.’ — ideally in an FAQ block with matching schema. Retrieval-backed engines assemble answers from retrievable sentences; a clear sentence stating the truth, on an authoritative page, is the single most effective correction instrument you own, because it competes directly with the stale source at answer-assembly time. Vague marketing copy (‘flexible pricing options!’) loses that competition to a directory’s crisp wrong fact.
Step 3: The Citation Supply Chain — Fixing the Web That Feeds the Answers
Work outward from your trace findings and the audit’s citation column, in influence order:
- Google Business Profile: the most-consulted source for local facts — every field current, category correct, the wrong fact’s GBP counterpart (hours, address, service area, attributes) fixed today; suggest edits on any duplicate or rogue listings and pursue removal per the consolidation process.
- The major data aggregators and directories: the handful of platforms that syndicate business data widely (plus your industry’s verticals and the local citations that actually rank for your brand) — correct the stale fact at each; this is the classic NAP-consistency work with a new customer, because the aggregator error you ignored in 2022 is now being read aloud to prospects.
- Review platforms and profiles you abandoned: the unclaimed Yelp with the old address, the Facebook page from the previous owner, the association listing with the exited service — claim, correct, or formally close each; abandoned-but-live profiles are stale-fact reservoirs with platform authority.
- Ranked content repeating the error: a news article, a blog mention, a “best of” list with old facts — polite correction requests with the facts page as evidence work more often than expected, especially with local publishers; where the page won’t change, outranking it for the relevant query becomes the fallback.
- Wikipedia/Wikidata where you have presence: high-weight sources for entity facts — corrections there follow those communities’ rules (sourced, neutral, no promotional editing; conflict-of-interest disclosure via talk pages), and are worth doing properly precisely because so many systems inherit from them.
Step 4: Platform Feedback — Worth Doing, Honestly Weighted
The engines’ own correction channels are the third lever, not the first: in-answer feedback (thumbs-down / report on the specific wrong response, with the correction in the comment where offered) has low individual power but nonzero aggregate effect — make it a standing habit for every documented error, from multiple team members when the error is consequential; AI Overview feedback (the report option on the Overview itself) routes to Google’s quality processes and matters more than people assume for factual errors about entities; formal routes where they exist — platforms have and continue to evolve mechanisms for businesses/individuals to contest information about themselves (and legal-adjacent removal processes for specific categories) — check the current state of each platform’s policy when the case is serious, because this landscape changes quarterly. Log every submission (date, platform, content) — both for the re-verification loop and as the paper trail the escalation ladder needs if it comes to that.
When the AI blends you with a similarly named business (their reviews, their lawsuit, their closure attributed to you), generic fact-fixing underperforms because the problem is disambiguation, not staleness. The playbook: make your identity computationally distinct — consistent exact-form NAP everywhere; an about page that states the differentiators a machine can parse (full legal name, founding year, location, ‘independently owned; not affiliated with [Similar Name] of [Other City]’ where the collision is damaging and the statement is true); schema carrying the disambiguators (address, founding date, the sameAs links to your verified profiles); and strengthened distinct presence on the sources engines cross-check (GBP, the aggregators) so the two entities’ source clusters separate. Timeline honesty for all correction classes: search-backed answers (Perplexity, ChatGPT with browsing, AI Overviews, Copilot) re-read the web continuously — source fixes commonly surface in answers within days to weeks; model-memory answers (no browsing, or the engine answering from training) can repeat corrected errors until the next training refresh, months out, and no amount of source-fixing accelerates that — which is why the strategy is making the retrievable truth so strong and consistent that any engine that checks finds it, while accepting that the non-checking answer modes lag. Set stakeholder expectations accordingly: visible improvement in weeks on some engines, quarters for full convergence, permanent vigilance thereafter.
The Escalation Ladder — for the Cases That Aren’t Just Stale
Most wrong-AI-info cases are hygiene; a minority are harm. The ladder: (1) documented feedback + source fixes (everything above — sufficient for stale facts and most confusion); (2) formal platform processes — where an engine persistently states something false and damaging (you’ve closed; you’re the defendant in the other company’s lawsuit), use the platform’s official contest/complaint mechanisms with your evidence log, not just the thumbs-down; (3) counsel — where the false statements are genuinely defamatory and causing measurable harm, the legal landscape around AI-generated statements about businesses is actively developing; a documented pattern (your evidence log), demonstrated harm, and exhausted platform processes are what a lawyer needs, and the letter that follows gets a different class of platform attention than feedback buttons do. Keep proportion: the ladder exists for the rare severe case; climbing it for a stale suite number wastes everyone’s quarter.
Step 5: Re-Verify on the Audit Cadence
Corrections enter the quarterly mention audit as tracked items: the specific wrong claims re-tested (same prompts, variance rules respected), the fixed sources spot-checked for regression (aggregator re-syndication can resurrect a corrected error — the stale fact you killed in one database reimported from another), and the accuracy column trended. Success looks like the error’s frequency across runs declining engine by engine as each one’s retrieval catches up — and the log of what was fixed when is what turns “it seems better?” into a defensible before/after. Pair with the measurement stack where the error was commercially significant: a corrected “doesn’t serve Plano” claim should eventually show up as Plano leads that stop mysteriously asking “wait, do you cover us?”
5 Common Correction Mistakes
- Arguing with the chatbot. Telling the model it’s wrong corrects that conversation for that user — the next session inherits the same sources; fix upstream.
- Correcting downstream of your own site. Chasing directories while your services page still lists the exited service — the owned layer is step one because everything cross-checks against it.
- One-run panic, one-run relief. Stochastic answers demand the variance discipline — classify by consistency across runs, not by the single screenshot that scared the owner.
- Uncaptured evidence. No screenshots, dates, prompts, or submission log — and therefore no trend, no regression detection, and nothing to escalate with.
- Treating it as a one-time fix. Aggregators re-syndicate, models retrain, new sources appear — accuracy is a standing column in the quarterly audit, not a closed ticket.
Frequently Asked Questions
ChatGPT says my business is permanently closed. What do I do, today?
This is the highest-priority error class — it converts prospects to competitors instantly — and it has a characteristic source profile, so the same-day sequence is well-defined. First, check the usual culprit: your Google Business Profile — a ‘permanently closed’ flag there (from a malicious suggestion, a confused user edit, or a move handled badly) propagates everywhere; if present, correct it immediately via the profile’s reopen process and the reinstatement playbook if the state is stuck. Second, sweep the other closure-signal sources: Yelp and Facebook closure flags, directory entries for a previous location never updated after a move (engines read an old-address listing plus no signal at the new one as ‘closed’), and any ‘closed’ mention ranking for your brand. Third, strengthen the alive signals: current site with visible freshness, active GBP (a post, updated hours, fresh photos), a recent review or two solicited legitimately — the retrievable evidence of operation that outweighs the stale flag. Fourth, submit the in-answer feedback on the wrong response and re-test across engines with variance rules. Expected arc: search-backed engines typically stop asserting closure within days-to-weeks of the source signals flipping; capture the before/after screenshots throughout — if the claim persists across engines and weeks despite a clean source record, you’ve got the documented pattern the formal platform processes (and, for measurable ongoing harm, counsel) are built for.
The AI keeps confusing us with a company that has almost the same name. Whose problem is that and how do we win it?
It’s structurally your problem regardless of fault, because you’re the one bleeding from it — and it’s winnable through disambiguation rather than complaint. Why it happens: entity resolution runs on distinguishing signals, and two businesses with similar names, overlapping categories, or thin footprints give the systems too little to separate — the blending is a signal-scarcity artifact. The playbook, in leverage order: make your identity maximally distinct and consistent — exact-form name, address, phone identical across your site, GBP, and every profile (variance in your own NAP is fuel for the blender); publish the differentiators machine-readably — an about page stating full legal name, founding, ownership, service area, and where the collision is causing real damage and the statement is true, an explicit ‘not affiliated with [Name] of [City]’ line; carry the disambiguators in schema (Organization with address, foundingDate, and sameAs links to your verified profiles — the machine-checkable identity chain); build source-cluster separation — strong distinct presence on the platforms engines cross-check, so retrieval finds two clearly different entities with different addresses, reviews, and histories; and where the confusion is severe, consider the nuclear-but-effective option businesses in chronic collisions eventually take: leaning harder on a distinguishing brand element (‘[Name] of Dallas’) used everywhere consistently. Then re-audit the confusion-prone prompts quarterly (‘tell me about [name]’ from clean sessions) — blending fades as the source clusters separate, typically over a couple of quarters. If the other entity’s conduct is actively trading on the confusion, that’s a trademark conversation beyond this protocol’s scope.
Can I just contact OpenAI or Google and tell them to fix wrong information about my company?
Sometimes — and it’s worth doing on the serious cases — but calibrate expectations about what these channels are and aren’t. What exists: every major platform has in-product feedback on specific answers (low individual weight, real aggregate weight, and the right habit for every documented error); most have formal reporting routes for certain content categories (defamation-adjacent claims, impersonation, privacy issues) whose scope and responsiveness vary by platform and evolve quarterly — check each platform’s current policy pages when you have a case, because summarizing today’s state would mislead you next year; and legally-grounded requests (through counsel, citing specific false statements and demonstrated harm) reliably reach a different tier of review than product feedback does. What none of these channels do: hand-edit the model’s knowledge on request — corrections generally take effect through retrieval (the engine reading updated sources) or through periodic retraining, not through a support ticket flipping a fact. Which is why the sequencing in this protocol holds even for cases where you do contact platforms: the source-level fixes are what make any platform-side action durable, the evidence log (screenshots, dates, prompts, submissions) is what makes your report credible, and the platform contact is the accelerant on top of a repaired record, not a substitute for repairing it. Reserve the formal routes for consequential errors — closure claims, defamation-grade statements, persistent confusion causing measurable loss — and let the routine staleness cases resolve through the supply-chain work they respond to.
The AI is making up specific prices for our services that we've never published anywhere. How do you fix a pure hallucination?
Invented specifics with no findable source are the one class where ‘fix the source’ has no target — so the strategy inverts: instead of correcting a wrong document, you publish the authoritative one the answer should have used. Why it happens: asked a specific question (‘what does [company] charge for X?’) with no retrievable answer, models sometimes fill the gap plausibly — category-typical numbers presented with unearned confidence; the absence of your voice is the vulnerability. The fix: occupy the answer space — a pricing page (or honest pricing-explanation page: ranges, factors, ‘free estimate’ framing if exact pricing genuinely varies) in plain declarative sentences, FAQ blocks with matching schema for the exact questions being asked, delivered crawlably — because retrieval-backed engines prefer an authoritative retrievable answer over generation, and the hallucination typically stops the moment a real answer exists to find. Note what this does and doesn’t require: you don’t have to publish rates you keep private — ‘pricing depends on [factors]; estimates are free and take 24 hours’ is a retrievable, hallucination-displacing answer that discloses nothing competitive; what you can’t do is leave the question answerless and expect the models to stop guessing. Meanwhile: feedback-flag the fabricated answers (invented facts are exactly what those channels exist for), re-test on the audit cadence, and expect the search-backed engines to converge on your published answer within weeks while non-browsing modes lag until retraining — the standard timeline split.
How long until corrections actually show up in AI answers — and how do I prove to my boss it's working?
Two timelines and one measurement discipline. The timelines split by answer mode: retrieval-backed responses (Perplexity, ChatGPT when it searches, Copilot, Google’s AI surfaces) re-read the web, so fixes at the sources they actually consult commonly surface in days to a few weeks — with the lag driven by recrawl of the specific corrected sources (your site updates fastest; sleepy directories slowest) and by which sources a given engine happens to retrieve per run; model-memory responses (no live search, or engines answering from training data) can repeat the corrected error until their next training refresh — months, on schedules platforms don’t publish — and nothing you do upstream accelerates that class except waiting while the retrievable record stays clean for the eventual retrain. So the honest stakeholder framing: partial visible improvement inside the first month, majority convergence over one to two quarters, stragglers thereafter — permanent monitoring, not a completion date. Proving it: the evidence log is the instrument — before-state screenshots (prompt, engine, date, wrong claim), the fix log (which sources corrected when, which feedback submitted when), and quarterly re-tests of the same prompts under the same variance rules, reported as the error’s appearance rate across runs per engine (e.g., ‘closure claim: 4/5 runs in March, 1/5 in June, 0/5 in September across ChatGPT and Perplexity; persists in [engine]’s non-search mode pending retrain’). That appearance-rate trend, engine by engine, next to the dated fix log, is the before/after chart that turns the whole invisible-seeming exercise into an accountable program — and it’s the same sheet the mention audit already maintains, so the marginal reporting cost is zero.
Is an AI quietly telling prospects something false about you?
We’ll trace every wrong claim to its sources, run the full correction sequence — your owned layer, the citation supply chain, the platform channels — and re-verify quarterly with the documented before/after that proves the record got fixed.
Get an AI Accuracy Audit Fix the Local Footprint