When AI gets facts about your business wrong: why, and what fixes it

Why does an assistant state wrong facts about a business?

Because it answers from what it can read, and what it can read about most small businesses disagrees with itself. An AI assistant with retrieval on fetches a handful of pages for the question: your site, a directory listing, a review platform, a news item. If your contact page shows one phone number and your footer another, or a listing still carries the address you left two years ago, nothing on those pages says which is current, and an answer built from them can repeat either, or mix the two.

This is the common case, not the rare one. In our audit of 9,483 small business websites (40 trades, 90 metros, September 2026), 43.1% were inconsistent about who and where they are across their own three main pages. 36.9% published more than one phone number. 34.1% had no postal address a machine could parse. Those figures describe the businesses' own pages. Third-party listings are not in those figures at all, and nobody at the business may have read them since the day they were created.

The second cause sits inside the model. A language model answers partly from training data that stops at a knowledge cutoff. Anything after that date is not in the model unless it fetches it. Asked about a business it half-remembers, with retrieval off or returning nothing useful, it may fill the gap with a plausible sentence: a service you stopped offering, an owner who sold up, a price from a page that no longer exists. That is a hallucination: fluent, confident, and supported by nothing it read. The two causes need telling apart, because the second cannot be fixed by editing a page the model never fetched. It can only be crowded out by making the current fact easy to fetch.

How do you find out what is being said about you?

By asking, the way a buyer would, and keeping the answers. There is no console for this. An assistant's answer is generated once, for one person, and is published nowhere you can search; brand monitoring tools built for news and social platforms cannot see it. The only record is the one you make.

1. Write down the questions your buyers ask on the phone, in their words, ten or so: who you are, where you are, what you charge, whether you do a particular job, whether you are open now, who else does this nearby.
2. Put each one to ChatGPT, Claude, Gemini and Perplexity. Use a fresh conversation for each question, so one answer does not shape the next.
3. Save every answer verbatim, with the assistant, the date and the question. A screenshot is fine; pasted text is better, because you can search it later.
4. Read them for facts, not for tone. Mark every statement about your name, address, phone, hours, prices, services, people and ownership as right, wrong or out of date.
5. Where the assistant cited or linked a source, open it. That page is where the wrong fact lives, and it is what you will fix.
6. Do it again next month with the same questions. Answers vary between runs, so a single run is a snapshot; the second tells you whether anything moved.

Our own measurement is a narrower version of that: a fixed panel of twelve questions, put to one assistant, Claude, once per reading, asked again once the fixes are live and every month with monitoring, with the answers kept verbatim; a person checks each report before it is sent. If you would rather not run the first pass yourself, the free check does a first pass on one site with Claude: a person runs it and sends a written result within 48 hours.

How do you correct a wrong fact?

By correcting the source the assistant read, not by arguing with the assistant. Correcting it in the chat changes that one conversation and nothing else. The next buyer opens a new one, and the assistant fetches the same pages again.

Start with your own site, because it is the one source you control completely and the one an assistant treats as yours. Pick one form of the name, one address, one phone number, one set of hours, and repeat them exactly on the homepage, the contact page, the about page and the footer. Not "Suite 4" here and "#4" there. Not the owner's cell on the contact page and the office line in the footer. One of each, everywhere.

Then say the same thing in markup. Google documents the LocalBusiness properties it reads: name, address, telephone, opening hours, geo coordinates and price range. Write them as JSON-LD, use the specific subtype where one exists (Dentist, Plumber, AutoRepair), and keep the values identical to the visible text, which is what Google's structured data guidelines require. In the audit, 17.8% of sites had no schema markup at all, and most of the rest described the website rather than the business. LocalBusiness markup is the machine's copy of your facts. Without it, the machine guesses from prose.

Then the listings, in the order an assistant is likely to read them: your Google Business Profile first (Google's guidelines ask for the real name, the real address, categories and hours, which is the same discipline), then the review platforms and directories for your trade, then anything else a search for your business name turns up on the first two pages. Change each one to match the site exactly. Where a listing cannot be edited, claim it. Where it cannot be claimed, note it and move on.

What if the false statement comes from a page you cannot edit?

Publish the correct fact where the assistant will read it, with a date, and let the newer statement compete with the older one. You cannot edit a review, a news item or a forum thread. You can make sure that when an assistant fetches your site alongside it, your site states the current fact plainly, in a passage that names the thing the other page gets wrong.

Do it as a dated statement, not a rebuttal. "Since March 2026 the practice is at 40 Main Street; the King Street office is closed" is a sentence an assistant can lift and date. A paragraph about how the old listing is wrong is not. Put it on the page a question about that fact would lead to: the contact page for an address, the service page for a price, the about page for ownership. Where the platform allows an owner's reply, reply with the same dated sentence, because the reply is fetched with the review.

The date matters because two sources disagree and the model has to choose. A dated sentence on the business's own site, matching its markup, is the stronger claim; an undated sentence is one more voice. Freshness can only be judged from what the page says and what the server sends, so the page's modified date and the visible date should agree as well.

Can you ask the assistant's operator to correct it?

Not through any correction form for business facts that we know of. OpenAI, Anthropic, Google and Perplexity publish documentation for their crawlers and their products. None of it, as far as this site has found, offers a way to submit a corrected fact about a business and have the model state it. We would rather say that plainly than point you at a form that does not exist.

What the operators do document is how their systems read the web: which fetcher opens a page when a user asks about it, and that the answer is written from what was fetched (OpenAI and Perplexity both document theirs; Anthropic documents how Claude's web search retrieves pages during a conversation). That is the route in. The correction channel is the page, and there is no other one.

Two things you can do at the operator's end. First, check that its answer-side crawler can reach your site at all. If the crawler access check shows the fetchers blocked, the assistant cannot read your correction, and it will keep answering from whatever listing it can read. Second, most of the products have a feedback control on an answer. It costs nothing to use, and we have no evidence of what it does, so do not count it as a fix.

How long does it take for the answer to change?

It changes when the sources have changed and the assistant fetches them again, and nobody outside the operator can tell you when that is. We do not promise a timeframe, and you should not accept one from anyone else. What can be said is the order of events: the page changes; a crawler refetches it, or a user's question triggers a fresh fetch; the answer written from that fetch reflects the change. Answers written from training data alone change when the model does.

So the honest way to track it is the monthly run from the second section. Same questions, same four assistants, answers kept. The month the wrong fact stops appearing is the month it was fixed; until then, the sources you opened in step five tell you what is still feeding it. This is what a baseline and a second reading are for. A single run cannot tell you whether anything moved.

One more limit. Answers vary between runs of the same question on the same day. A wrong fact that appears in one run of three is neither fixed nor broken; it is a source that is still in the mix. Our own readings ask each question once and are dated, so we judge a wrong fact across the twelve questions, and with monitoring across months, never from one answer.