Quick Answer: There is no edit button. ChatGPT reflects the sources it retrieves or was trained on, so the only reliable fix is upstream: correct the exact pages and records it reads, strengthen your entity data, force a recrawl, then retest. Retrieval errors often clear within weeks. Trained errors can persist indefinitely.
That is the whole answer. Everything below is the detail behind it. You probably arrived here after asking an assistant about your own company and getting back a closed location, a former partner, a price you have not charged in three years, or a service you do not offer. The instinct is to look for the correction form. There is not one. What exists instead is a supply chain of sources feeding the model, and you can influence it in a specific order, with specific latencies, and a specific set of cases that do not resolve at all. This page sets out that order and marks where evidence stops and inference begins.
On this page
Reading time: 13 minutes
Why no edit button exists
A language model does not store a record of your business the way a directory stores a listing. It has no row to update. The clearest public account of why wrong facts appear comes from the OpenAI researchers behind Why Language Models Hallucinate (Kalai, Nachum, Vempala and Zhang, September 2025), who argue that models produce confident falsehoods because training and evaluation reward guessing over admitting uncertainty. Their phrase for it is an epidemic of penalizing uncertain responses. A model that says it does not know scores worse on the benchmarks the industry optimizes against, so models learned to answer anyway.
That has a direct consequence. The wrong answer about your opening hours is not a corrupted database entry waiting to be repaired. It is a plausible guess assembled from whatever the model absorbed or fetched, so the repair has to change what it absorbs or fetches.
The absence of a rectification path has been tested legally. In April 2024 the European privacy group noyb filed a complaint with the Austrian data protection authority over false personal information generated by ChatGPT. That filing concerns individuals rather than companies, but the substance matters: OpenAI's position was that it could block or filter information attached to a prompt, not rectify the underlying fact. Blocking is not correcting. If a regulator-facing process for personal data stops at filtering, no business-facing process is going to hand you a text field.
Matt Griffin, Formative Digital: "The call always opens the same way. Someone reads a wrong answer out loud and asks who to email to get it taken down. I have to tell them nobody is going to take it down, and that the work is upstream and slower than they want. A pattern we see repeatedly in audits is that the wrong fact is still live on a page the owner forgot they controlled. An old location page nobody deleted."
Diagnosing which layer is wrong
Before you touch anything, establish which layer produced the error. The two layers have different repair paths and different timelines, and getting this wrong is how owners spend three months on work that could never have moved their problem.
OpenAI's crawler documentation is the cleanest evidence that these layers are separate systems. It describes three agents with three jobs: OAI-SearchBot, which crawls so content can appear in search results; GPTBot, whose crawled content may be used for training; and ChatGPT-User, which fetches a page live when a user's question triggers a visit. The documentation states these settings are independent, and gives the example of allowing OAI-SearchBot to appear in search while disallowing GPTBot to stay out of training. Two doors, controlled separately.
You can exploit that separation as a diagnostic without any tooling at all.
The two-minute layer test
Ask the identical question twice: once with web search or browsing enabled, once with it turned off. Then read the difference.
Correct with search on, wrong with search off: the error lives in the trained layer, and live retrieval is already covering for it. Your corrected sources are working. Keep reinforcing them and accept that the weights may not change for a long time, if ever.
Wrong with search on: retrieval is finding a source that carries the wrong fact. This is the good outcome, because it is fixable and propagates comparatively fast. Ask the assistant to list the pages it used, then read them.
Wrong in both: the false claim is both in the trained layer and reinforced by a live source. Fix the live source first. It is the half you can actually reach.
Do this across more than one assistant. The engines sit on different search backends and refresh cycles, so they disagree routinely, and a fact that has flipped in one product may be untouched in another. We keep a longer breakdown in our research on where AI engines actually read from. A correction rarely lands everywhere at once, so one stale answer is not evidence the work failed.
The remediation order, ranked by leverage
Most guidance presents a flat checklist, which quietly implies that submitting feedback in the app and rebuilding your entity data are comparable activities. They are not. Here is the same set of actions ordered by how much each actually moves an answer, with an honest confidence column.
| Action | Which layer it reaches | Effort | How confident we are |
|---|---|---|---|
| 1. Correct the page the model actually cited | Retrieval, directly | Low | High. The mechanism working as documented. |
| 2. Fix contradictions across your own site | Retrieval, and training over time | Low to medium | High. Conflicting self-published facts are the most common root cause. |
| 3. Force a recrawl of the corrected pages | Retrieval speed only | Low | High for the index. Changes latency, not outcome. |
| 4. Align your claimed third-party records | Retrieval and entity resolution | Medium | Medium to high. Widely corroborated, hard to isolate. |
| 5. Strengthen entity markup and disambiguation | Entity resolution | Medium | Medium. Helps machines identify you. Not a correction mechanism by itself. |
| 6. Earn corroboration on sources you do not control | Both, slowly | High | Medium. The only real lever on trained errors, and the slowest. |
| 7. Submit in-product feedback on the wrong answer | Unknown internal review | Trivial | Low. No published timeline, no visible status. Do it anyway. |
Notice the top three rows are cheap and sit inside your own admin panel, while the expensive row is second from the bottom. That ordering is the most useful thing on this page. Owners routinely start at row six, commissioning outreach, while row one sits undone because nobody checked which page the model was quoting.
Tier one: sources you own outright
Start where your authority is absolute and edit access is instant.
Read the pages the model named. If a retrieval-enabled answer cited sources, open every one. In a meaningful share of our audits, at least one cited page belongs to the client and still carries the wrong fact: a legacy service page, an old location page, or a PDF outranking the page the owner has been diligently updating.
Resolve contradictions before adding anything. If your homepage says 2011 and your about page says 2013, a retrieval system has no principled way to choose, and neither does a model. Pick the true version and make every instance agree, including footers, schema, PDFs and the alt text nobody reads. Contradiction is worse than silence: it teaches every downstream system that your site is unreliable on the point.
State the facts in plain, extractable prose. Facts that live only inside an image, a slider or a script-rendered widget are facts a crawler may never see. A short paragraph in ordinary sentences beats a beautifully designed graphic here.
Then force the recrawl. Submit the corrected URLs in Google Search Console and Bing Webmaster Tools, and ping IndexNow, which pushes change notifications to participating engines rather than waiting for a crawler to wander back. This does not change whether you get fixed, only how long you wait, which matters when a wrong price is costing enquiries this month.
Tier two: records you can claim
Your own site establishes what you say about yourself. Third-party records establish whether anything else agrees, and disagreement produces hedged, wrong or averaged answers.
The highest-value record for most local and service businesses is the Google Business Profile, which feeds far more than the map pack, as we set out in our research on Google Business Profile and AI visibility. Correct the categories, hours, service area and description, and make sure the name and address match your site exactly rather than approximately. Then work outward through the records you can claim: industry association listing, LinkedIn company page, chamber of commerce entry, licensing body register.
Underneath this sits the entity question, a different problem from accuracy. Sometimes the model is not wrong about you: it is right about a different company with a similar name, or it has fused two businesses into one. That is identity resolution, fixed with disambiguation rather than corrections: consistent naming, structured data tying your organization to a stable identifier, and enough distinct external references that the two entities stop collapsing. Our guide on getting into the Knowledge Graph walks that process, the work our methodology files under Vector 2, Anchor.
The Ontario version of this problem
Independent Ontario businesses hit a specific variant: decades of real reputation and a thin machine-readable footprint. No Wikipedia entry, few structured citations, a website rebuilt three times with old versions still indexed somewhere. When a model has little solid material, it fills the gap with whatever generic or regional information it has. That is why the fix for a well-known local firm is often not a correction at all. It is supplying a consistent record where almost none existed, leaving less empty space for a guess.
Tier three: the corpus you can only earn
The remaining layer is everything written about you by people who are not you. It is the only lever with real purchase on an error baked into training data, and it is slow, expensive, and where honest expectations matter most.
The mechanism is corroboration rather than correction. You cannot delete the wrong claim from the corpus. You can change the balance of evidence around it, so the accurate version is what retrieval keeps encountering and what a future training pass sees more of. Trade publications, podcast transcripts, conference listings, local press, supplier and partner pages: these shift the weight.
There is at least a quantified signal on what makes a source citable once it reaches a generative engine. The team behind GEO: Generative Engine Optimization (Aggarwal et al., November 2023) tested optimization methods on their GEO-bench benchmark and reported visibility gains of up to 40 percent, with citations, quotations and statistics performing strongly. That study measures how a source is treated once retrieved, not how fast a wrong belief gets displaced, and stretching it into a promise about correction speed would be exactly the overclaim this field runs on. Read it as evidence about what makes your corrected page the one that gets used.
What we can and cannot tell you about timing
Retrieval-layer corrections are bounded by index refresh, which is observable: you can watch a corrected page get recrawled in Search Console and see the answer change. Training-layer corrections are not observable from outside, and no major lab publishes a schedule tying a source change to a weight change. A vendor table of median days-to-correction per platform is a self-reported figure from an unaudited sample, not a documented property of the system. We do not publish one because we cannot verify one.
What Google says you can skip
A remediation market has grown around this problem, and part of it sells work the platform documentation explicitly says does nothing. Google's AI optimization guidance in Search Central is unusually direct, and the substance will save you money.
On llms.txt and similar files: Google states you do not need machine-readable AI text files to appear in Google Search including its generative features, that it ignores them, and that maintaining one will neither harm nor help rankings. On chunking: there is no requirement to break content into tiny pieces for AI, because its systems already understand multiple topics on a page and surface the relevant part. On structured data: it says structured data is not required for generative AI search and there is no special schema markup to add, while still recommending schema as ordinary SEO for rich-result eligibility. The guidance tells site owners to prioritize effective SEO over what it calls AEO and GEO hacks.
Two honest caveats. That guidance governs Google Search and its generative features, not ChatGPT, Perplexity or Claude, which sit on different infrastructure. And schema is still worth implementing for the disambiguation reasons in tier two. The narrower point holds: an llms.txt file is not a remedy for a wrong answer, and the largest player says it ignores them.
The same guidance names a monitoring instrument most articles on this topic never mention: Search Console now carries a generative AI performance report, so visibility inside Google's AI surfaces is partly measurable from a first-party dashboard rather than only inferable from spot-checking prompts by hand.
Want to know which source is feeding the wrong answer?
Send us the business and we will run the prompts across ChatGPT, Perplexity, Gemini, Claude and AI Overviews, then trace each wrong claim back to the page or record producing it. You get the trace and the remediation order either way, and if the fix is four edits you can make yourself this afternoon, we will tell you that instead of quoting you a retainer.
When the wrong answer will not die
Here is the case the rest of the internet skips. You did the work properly. Your site is consistent, your records agree, the pages have been recrawled, and eight weeks later the assistant is still saying it. What now?
The stubborn-answer protocol
- Re-run the layer test first. If the search-on answer is now correct and only the search-off answer is stale, you have not failed. You have moved the half of the system that responds to work and are waiting on the half that does not.
- Hunt for the source you missed. Search the wrong claim as a quoted phrase rather than your business name. This finds the aggregator, scraper, syndicated press release or directory quietly republishing your 2019 details. In a stubborn case there is almost always a surviving source, usually one nobody thought to look for.
- Check whether this is really about identity. Ask the assistant to describe the business including address and founding year. If the details belong to a different company, this was never an accuracy problem and correcting your own pages will not fix it. Go back to disambiguation.
- Request corrections where a human is reachable. Directories, association listings and local publications have people who will amend a documented factual error. Unglamorous, and it works more often than owners expect.
- Publish the correction as content, not just as an edit. A dated page stating the accurate position in the same words people use when they ask gives retrieval something unambiguous to grab. Silent edits are weaker signals than a page that exists to answer the question.
- Decide whether it is worth continuing. Some errors are commercially trivial. A wrong founding year is a bruise; a wrong phone number or a claim you have closed is a bleed. Spend accordingly rather than chasing every inaccuracy equally.
And the part nobody wants in a sales-facing page: some of this does not resolve. If a false claim is embedded in training data and no live source contradicts it strongly enough, you are waiting for a model generation rather than a crawl, and no vendor controls that. Anyone who says otherwise is describing a lever they do not have.
Honest timelines
What we can state with confidence has a narrow scope. Retrieval-layer errors on an established domain typically clear on the timescale of the index refreshing, days to a few weeks. Errors surviving only in trained weights have no timeline anyone outside the labs can quote. Everything between those poles, including how much corroboration flips a contested fact, is inference from observed behaviour rather than documented mechanism, and we mark it that way on purpose.
The broader pattern is that entity work compounds on a slower curve than owners expect, then moves faster than they expect once it does. In one anonymized engagement with an Ontario container dealer, the first year of a sixteen-month window ran at single-digit daily clicks before climbing to seventy-click days with six to nine thousand daily impressions by early summer 2026 (Google Search Console, 16-month window, shared with permission). That is a traffic story rather than a correction story, but the curve has the shape you should expect here: a long flat stretch where the machine-readable record is rebuilt and nothing visible changes, then a step change. Outcomes differ by market, footprint, and how much contradictory material is already out there.
Set expectations in months. Retest on a schedule rather than on impulse, log what each engine says with the date, and treat the log as the deliverable. Checking daily and reacting to noise is how owners talk themselves out of work that was progressing.
A three-question self-check before you spend anything
1. Have I read every source the model cited, including my own? If no, stop and do that. It is free and resolves a large share of cases outright.
2. Does every property I control state the same fact? If no, the model is not the problem yet. Your own record is contradictory, and no external work outranks your own inconsistency.
3. Is the wrong answer costing me money? If a prospect is told you are closed, that is urgent. If your founding year is off by two years, log it and move on. Triage beats completeness.
If all three are handled and the error persists, the remaining work is corroboration and disambiguation, which is where an AI visibility audit earns its keep. If they are not, start there and save the budget.
Frequently asked questions
Can I contact OpenAI to correct wrong information about my business?
There is no business-facing correction desk. OpenAI runs a privacy request process for personal data, and in the Austrian complaint filed by noyb in April 2024 its position was that it could block or filter data attached to a prompt rather than rectify the underlying fact. For company-level errors the in-product feedback control is the only direct channel, and it is a signal to a review queue rather than a ticket.
How long does it take for ChatGPT to update wrong information?
It depends on which layer holds the error, and nobody outside these companies can quote a reliable figure. When the answer comes from live retrieval, the ceiling is how fast the search index recrawls your corrected page, usually days to weeks for an established domain. When the fact sits in model weights, it changes only on retraining or when retrieval overrides it, and no public schedule exists. Vendor tables of median correction days are self-reported and unverifiable.
Why does ChatGPT still get it wrong after I fixed my website?
Three common reasons. The corrected page has not been recrawled yet, so retrieval still serves the old version. The model is not retrieving at all and is answering from training data that predates your fix. Or your site is not the source it trusts, because a directory, an old news item or an aggregator carries the wrong fact with more authority. Run the question with search on, then off, to tell which.
Do I need an llms.txt file to help AI models read my business correctly?
Not for Google. Google's AI optimization guidance states that Google Search ignores llms.txt files and that creating one will neither harm nor help visibility or rankings. The same document says structured data is not required for generative AI search and there is no special schema markup to add, though schema stays worthwhile for rich results. Publishing one is harmless. Just do not treat it as remediation.
What if a competitor or an old news article is the source of the wrong information?
You cannot edit someone else's page, so you work the two levers you have. First, ask the publisher for a correction or update note, which reputable outlets in Ontario and elsewhere will often issue for a documented factual error. Second, build enough corroborating weight elsewhere that the wrong version becomes the outlier rather than the consensus. That second path is slow and genuinely uncertain, which is the honest answer rather than a reassuring one.
Sources
- Kalai, A.T., Nachum, O., Vempala, S.S., & Zhang, E. (2025). "Why Language Models Hallucinate." arXiv preprint arXiv:2509.04664, September 4, 2025. arxiv.org
- OpenAI. "Overview of OpenAI Crawlers." OpenAI Platform Documentation. Describes OAI-SearchBot, GPTBot and ChatGPT-User as independently controllable agents. platform.openai.com
- Google Search Central. "AI Features and Your Website: Google Search Optimization Guide." Statements on llms.txt, content chunking and structured data requirements. developers.google.com
- Aggarwal, P., Murahari, V., Rajpurohit, T., Kalyan, A., Narasimhan, K., & Deshpande, A. (2023). "GEO: Generative Engine Optimization." arXiv preprint arXiv:2311.09735, November 16, 2023. arxiv.org
- noyb. "ChatGPT Provides False Information About People, and OpenAI Can't Correct It." Complaint filed with the Austrian Data Protection Authority, April 29, 2024. noyb.eu
Get your free AI visibility audit
Formative Digital, Brantford, Ontario · 226-450-2065
If an assistant is telling your prospects something untrue, the first job is identifying which source is saying it, and that is a diagnosis rather than a campaign. We will trace the wrong claims to their origins across the major engines and hand you the remediation order. Plenty of these end with a short list of edits and no proposal attached.