Contradictions across your own pages

The short answer: Contradictions across your own pages are places where two URLs on your site state different facts, and the engine answering a question has no way to know which one you meant. It does not call you to ask. What we can see from outside is the answer, not the choice behind it: sometimes one of your values, sometimes a hedge, sometimes a competitor whose story holds together. The cost is not a penalty. The cost is that your own site becomes an unreliable witness for you.
Nobody plans this. It arrives the way technical debt arrives: a pricing change that touched four of the nine places price appears, a careers page that still says founded in 2019 when the about page says 2018, a schema block generated from a database field the marketing team stopped updating.
Why a retrieval system cannot resolve it for you
A classic search engine was allowed to be vague. It returned ten links and let a human sort out the mess. An answer engine has to commit to a sentence, and to commit it needs one value for price, one founding year, one description of what you sell.
Retrieval works on passages, not whole pages. Google's documentation on AI features says that AI Overviews and AI Mode may use a query fan-out technique, issuing multiple related searches across subtopics and data sources to develop a response. Two of those sub-queries can land on two different pages of your site, and those two pages can disagree. At that point the model is holding evidence that conflicts with itself. What happens next is not documented by Google or by any other engine we have read, and it is not visible from outside: in the engine documentation we have read, none publishes a rule that makes one of your passages more canonical than another. We cannot tell you what decides it. We can only tell you that your intent is not part of the input.
This is a different failure from not being retrieved at all. If you are unsure which one you have, why AI never mentions your brand separates the two, and slow pages get dropped before they get read covers the case where your page never reaches the model in the first place.
What the research says about conflicting evidence
There is measured work here, though none of it is about websites. ClashEval, a benchmark first posted in April 2024 and revised in February 2025, curated over 1,200 questions across six domains, including drug dosages, Olympic records and locations, then perturbed the retrieved documents so they disagreed with what the model already knew. Benchmarking six models, including GPT-4o, the authors found the models adopted the incorrect retrieved content over their own correct prior knowledge more than 60 percent of the time. Those are six models on one dataset of general-knowledge facts, not a measurement of how any shipping answer engine treats your pricing page. We are reading it as the nearest evidence available, not as a result about brands.
Two details from that paper are worth carrying over, as hypotheses rather than findings. The first is the paper's report that the more unrealistic the retrieved content was, the less likely a model was to adopt it. If that gradient holds for commercial facts, a price wrong by an order of magnitude is the kind of error that gets resisted and a mildly stale price is not, which is unfortunate, because mildly stale is what a forgotten pricing page looks like. The second is the paper's finding that the less confident a model was in its initial answer, measured by token probabilities, the more likely it was to adopt the retrieved content. We would expect most brands to be entities a model has no strong prior about. We have not tested either expectation.
The broader literature calls this inter-context conflict, one of the three categories in the 2024 survey on knowledge conflicts for language models, alongside context-memory and intra-memory conflict. That survey reviews available solutions rather than naming a settled one. Treat that as the state of play, not a problem your content team can wait out.
The six fields that break most often
These six are the fields we have found ourselves correcting most often in the audits we have run. We have not counted them systematically, so read this as the shape of our own casework as of October 2026, not a measured ranking, and not a claim about sites in general. They are boring facts:
- Price and plan names. Pricing page, a comparison page, an old launch post, the FAQ,
- Founding year and headcount. About page, careers page, press kit, LinkedIn-style
- What the product actually is. The home page says platform, the docs say API, the
- Who it is for. Enterprise on one page, small teams on another, because two campaigns
- Location and entity name. Legal name in the footer, trading name in the title tag,
- Numbers you quote about yourself. Customer counts and uptime figures that were true
and whatever a Product or Offer schema block still carries.
boilerplate pasted into partner directories.
case study says service. All three are defensible. Together they are noise.
shipped two landing pages and neither was retired.
a third spelling in the schema name field.
when written and have never been dated.
Schema deserves its own line, because it is the quietest offender. Google's general structured data guidelines say markup must be a true representation of the page content and tell you not to mark up content that is not visible to readers, and Google's AI features page repeats the point in its list of what helps: make sure your structured data matches the visible text on the page. Both are Google's rules for Google surfaces; other engines publish nothing comparable that we have found. A JSON-LD block carrying last year's price while the visible page shows this year's is still a contradiction you cannot see by reading the page.
A check you can run this week
This takes an afternoon and needs no tooling beyond a crawler and a spreadsheet.
- List the facts, not the pages. Write down the ten things about your company that a
- **Crawl your own site and extract, per URL, every sentence containing a candidate
- Sort by fact and read down the column. Disagreements jump out visually in a way
- Ask the engines the matching question several times. Note which value comes back
- Check the archived versions. A page you fixed in March may still be cached, quoted
buyer might ask an engine. Price, founding year, what it does, who it is for, where you are, what you integrate with. Ten rows.
value.** Regex for currency symbols, for four-digit years, for the words *founded*, *since*, *starts at*, *per month*. Include the JSON-LD, parsed, as a separate column.
they never do while browsing. Expect a first pass to surface some: the point of the column is that it makes them visible, not that the count means anything.
and which URL is cited. Two runs of the same prompt returning two of your values is a signal worth chasing, though a handful of runs cannot separate a live contradiction from ordinary sampling variance.
in an old press release or mirrored on a syndication partner. The fix is incomplete until the copies agree.
Step four is where people get it wrong, because one run proves nothing. Running your own AI search study sets out how many runs you need before a difference means anything, and the self-audit checklist for AI visibility folds this fact table into a wider sweep. If you want a worked example of how findings and evidence are written up, the sample audit report shows the shape.
Fixing it without a rewrite
Pick one canonical page per fact and say so out loud, in markup and in prose. Price lives on the pricing page. Founding year lives on the about page. Every other mention either links to the canonical page or, better, gets cut.
Then date the volatile facts. A sentence that reads "as of October 2026, plans start at" is self-limiting: when it goes stale, it says so, and a model reading it can see the staleness instead of asserting the number flatly. Undated numbers age badly and silently.
Retire rather than update where you can. A 2022 launch post with old pricing is not an asset. Either strip the number out of it, or redirect it. Keeping a page alive out of sentiment is how the fourth version of your price stays in circulation.
Last, make the fact table part of release. If price changes, the table names the URLs and schema blocks that change with it. That turns a recurring failure into a checklist item, which is the only durable fix we have seen.
What we are still measuring
We cannot tell you how long a corrected fact takes to propagate. We have watched a fixed page get quoted correctly within a crawl cycle on one engine and keep returning the old value for weeks on another, and we do not have enough paired observations to publish a distribution. Nor can we separate the effect of fixing contradictions from the effect of everything else a team ships in the same month. The harder gap is the one under the whole post: the only quantified evidence we can cite is a benchmark on general-knowledge facts, and we have not run a study that puts two contradictory pages of a real site in front of the engines and counts which one is quoted. The ranking of the six fields above is our impression from our own casework, not a count. If someone offers you a clean number for any of this, ask how they isolated it.
FAQ
Is a contradiction on my site a ranking penalty? None of the engine documentation we have read describes one, and we have seen no evidence of one in our own audits. The damage we can observe is upstream of ranking: when your own pages disagree, the answer you get back is as likely to carry the version you least wanted as the one you meant.
Which page wins when two of mine disagree? We have found no published rule, and we cannot see the step that decides it. What we can say is that retrieval operates on passages, so there is no documented mechanism by which your pricing page outranks a forgotten blog post simply for being the page you consider canonical. Assume the wrong one can win and act accordingly.
Does structured data override the visible text? It should not, and Google's documentation asks that the two match. Marking up a value the page does not show is against Google's general structured data guidelines, and complying with those guidelines is stated as a condition of rich result eligibility. That is Google's rule. We know of no equivalent published by the other engines.
How many contradictions is normal? We have no distribution to quote, and we would not trust one that did not say how the sites were sampled. In our own casework, a first pass over a site of a few hundred pages usually surfaces several, which we read as ordinary rather than alarming. The ones worth fixing first are price, what the product is, and anything a buyer would use to disqualify you.
Sources
- Google Search Central, general structured data guidelines, last updated 10 July 2026, checked 12 October 2026: developers.google.com/search/docs/appearance/structured-data/sd-policies
- Google Search Central, AI features and your website, last updated 10 December 2025, checked 12 October 2026: developers.google.com/search/docs/appearance/ai-features
- Wu, Wu and Zou, ClashEval: Quantifying the tug-of-war between an LLM's internal prior and external evidence, arXiv 2404.10198, submitted 16 April 2024, v3 of 7 February 2025, checked 12 October 2026: arxiv.org/abs/2404.10198
- Xu, Qi, Guo, Wang, Wang, Zhang and Xu, Knowledge Conflicts for LLMs: A Survey, arXiv 2403.08319, submitted 13 March 2024, checked 12 October 2026: arxiv.org/abs/2403.08319