The Brand Facts Page: A Ground-Truth Source for AI Search Engines

A brand facts page is a single, canonical URL on a company's own domain that states a small, fixed set of facts about the company — legal name, founding date, headquarters, current leadership, a pricing summary, company size, and official channels — in plain declarative sentences, backed by matching schema.org Organization structured data. Its job is narrow: give AI answer engines, search crawlers, and human researchers one unambiguous place to check a claim when their other sources disagree or go stale.

That's the whole concept. The rest of this piece covers why it's necessary, what evidence exists that AI systems get brand facts wrong, what to put on the page, and what the page can't do for you.

Why this is a real problem, not a hypothetical one

Direct answer: Two documented legal cases show what happens when an AI system states a wrong fact about a company or person and someone relies on it.

In Moffatt v. Air Canada (2024 BCCRT 149), a British Columbia tribunal found Air Canada liable after its website chatbot told a customer he could book a flight at full price and apply for a bereavement discount retroactively — advice that contradicted the airline's own bereavement policy page. Air Canada argued the chatbot was a separate legal entity it wasn't responsible for; the tribunal rejected that, ruling the company "did not take reasonable care to ensure its chatbot was accurate" and ordering it to pay damages (CBC News, Feb. 2024). The tribunal also noted it saw no reason the customer should have had to double-check the chatbot's answer against a different page on the same site — a point that applies directly to brand facts: if a company publishes conflicting information across its own properties, it can't expect an AI system, or a customer, to pick the right one.

In Walters v. OpenAI, a Georgia radio host sued after ChatGPT fabricated a lawsuit and falsely named him as the embezzling treasurer of an unrelated nonprofit, in response to a journalist's query. A Gwinnett County court granted OpenAI summary judgment in May 2025, but not because the output was accurate — because the court found no reasonable reader could have taken the chatbot's answer as a statement of verified fact (Loeb & Loeb legal analysis, May 2025). OpenAI won on a legal technicality about reasonable reliance, not on the accuracy of the output.

The underlying mechanism is well documented too. OpenAI's own research paper, "Why Language Models Hallucinate" (Kalai, Nachum, Vempala, and Zhang, September 2025), argues hallucination isn't a bug that better engineering removes — it's a statistical consequence of how models are trained and scored, since guessing under uncertainty scores better on standard benchmarks than admitting "I don't know" (openai.com). Google has demonstrated the same failure mode from the other direction: in a public demo of its Gemini grounding feature, a model asked who won the 2024 Emmy for best comedy series answered "Ted Lasso" from memory — correct for 2022, wrong for 2024, which "Hacks" actually won — until grounding was switched on and the model retrieved and cited the real result (TechCrunch, October 2024). That's the pattern for brand facts specifically: a model's parametric memory carries a stale fact (an old CEO, a discontinued price, an outdated employee count) forward indefinitely unless something forces it to check a current, retrievable source instead.

What entity-disambiguation guidance already says

None of this is new territory for search systems generally — it's the same problem Google Search has handled for years with entity disambiguation, just applied to generative answers instead of a ten-blue-links result page. Google's structured data documentation recommends marking up organizations with schema.org's Organization type so the properties that "matter for disambiguation" — name, url, and address — are stated unambiguously rather than inferred from body text (Google Search Central, Organization markup). Schema.org's own reference for the sameAs property describes it as "the URL of a reference Web page that unambiguously indicates the item's identity" — the mechanism for telling a crawler that a company's official site, Wikidata entry, and verified social profiles are all the same entity (schema.org/sameAs). Google's general structured data guidelines are blunt about the tradeoff: markup has to accurately represent visible page content and stay current, because "Google won't show a rich result for time-sensitive content that is no longer relevant" (Google, General Structured Data Guidelines). A brand facts page that drifts out of sync with its own JSON-LD defeats the purpose before an AI system ever reaches it.

Wikidata plays a related role, since it's one of the structured sources Google's Knowledge Graph draws from and it has a materially lower bar than Wikipedia — an entry is acceptable if it can be described with "serious and publicly available references," not fame (Wikidata:Notability). Companies can also claim an existing Knowledge Panel directly through Google's own verification flow (Google Knowledge Panel Help). None of these mechanisms are AI-search-specific — they predate the current generation of chatbots — but they're the infrastructure a brand facts page should plug into, not bypass.

What belongs on the page

Keep the pricing row a summary — "three plans, starting at $X/month, billed annually or monthly" — not the live price list. Exact numbers on a facts page become another stale artifact the moment prices change; a summary with a link to the current pricing page ages better.

How to build one, step by step

1. Audit what's currently being said about you. Ask ChatGPT, Gemini, Perplexity, and Google's AI Overview basic questions about your company — founding date, CEO, pricing, headquarters — and record where the answers are wrong, outdated, or contradict each other.
2. Find where the bad facts are coming from. Stale claims usually trace back to an old funding-round writeup, a review-site profile nobody updated, or a scraped mirror of your own outdated "About" page. You're not just writing a new page; you're identifying what it needs to out-compete.
3. Draft the canonical fact set in plain sentences. One fact per sentence, no marketing language, no ambiguity ("Founded in 2019 in Austin, Texas" rather than "Since our humble beginnings...").
4. Pick one URL and commit to it. A brand facts page that moves or gets folded into a redesign loses the citations and indexing history pointing to it. If it must move, 301-redirect permanently.
5. Add matching schema.org Organization JSON-LD. The structured data should restate — never contradict or extend beyond — what's written in the visible text on the same page, per Google's own structured data policy.
6. Cross-reference identity with sameAs. Link to your Wikidata entry (create one if you're missing it and meet the notability bar), verified social profiles, and Crunchbase or an equivalent registry, so disparate mentions resolve to one entity.
7. Get the page linked and discoverable, not orphaned. Link to it from your site footer, About page, and press page; submit it for indexing; don't rely on AI crawlers finding an unlinked page on their own.
8. Monitor drift on a schedule. Re-run the same AI-answer audit from step 1 quarterly, and immediately after any leadership change, funding round, rebrand, or pricing change.
9. Timestamp every revision. Update dateModified and keep a short, visible changelog for material facts (leadership, pricing model, ownership) so both crawlers and humans can see what changed and when.

What this doesn't guarantee

Be honest with yourself about the limits before you invest in this. A brand facts page does not guarantee an AI system will retrieve or cite it — that depends on whether the system browses live sources at all for a given query, versus answering from parametric memory it was trained on months or years earlier. Per OpenAI's own hallucination research, a fact already baked into a model's training weights isn't corrected by anything you publish afterward; it's only corrected by the model's next training run or by a retrieval step the model chooses to take (openai.com). It doesn't override outdated or wrong third-party sources that already outrank you — a five-year-old TechCrunch funding article with your old headcount can keep surfacing regardless of what your own page says. It doesn't get you a Google Knowledge Panel, a verified badge, or preferential treatment in any AI product; those are separate, sometimes manual, processes. And it doesn't stop scraped mirrors or aggregator sites from propagating an error after you've fixed the original — correcting the source doesn't retroactively correct every copy of it already indexed elsewhere. Treat the page as raising the odds that accurate information exists and is retrievable, not as a lever that controls what any given AI system will say.

Where nqzai fits

Keeping a brand facts page accurate requires knowing what's currently wrong, which means comparing what your own site says against how AI answer engines are actually describing your company right now — a manual version of that audit is easy to let slip after the first pass. nqzai's AEO/GEO tooling automates that comparison: it checks how current AI systems answer questions about a brand, flags where those answers diverge from the company's own published facts (a former CEO still being cited, a discontinued pricing tier, a wrong founding year), and surfaces exactly what the canonical page needs to correct — so the audit in steps 1 and 8 above is something you can run on a schedule instead of remembering to do it.

FAQ

Direct answer: Does the page need to be a blog post, or can it be a static page?

Static is better. A blog post implies a publish date that ages, and blog templates often bury key facts under narrative framing. A dedicated static page — something like /company or /facts — signals permanence and is easier to keep synced with its structured data.

How is this different from a press kit or "About us" page?

Press kits are written for journalists and often include boilerplate, quotes, and brand assets that aren't structured as discrete facts. About pages are usually narrative and marketing-voiced. A brand facts page is neither — it's a small set of unambiguous, machine-parseable statements, deliberately boring in tone.

Will publishing this page immediately fix wrong answers in ChatGPT or Gemini?

Not immediately, and not guaranteed at all for facts already fixed in a model's training data. It improves your odds for any AI system that browses or retrieves current sources for a given query, and it gives you a clean, linkable source to point to when you request a correction through a provider's feedback mechanism.

Should pricing be exact numbers or a summary?

A summary. Exact current prices belong on your pricing page, which you presumably update when prices change. A facts page with "starting at $X, three tiers" plus a link ages far better than one with numbers that go stale the next time you run a promotion or adjust a tier.

Do we need a Wikidata entry for this to work?

It's not required, but it helps. Wikidata is one of the structured sources feeding Google's Knowledge Graph, and its notability bar for businesses is lower than Wikipedia's — verifiable existence via a registry filing, funding announcement, or trade-press mention is usually enough (Wikidata:Notability).

How often should we update it?

At minimum quarterly, plus immediately after any change to leadership, ownership, pricing model, or company name. Stale facts on the page you built specifically to be the accurate source are worse than not having the page at all.