When prices, features or service terms conflict across pages, buyers struggle to identify the current version. A fact page gives important information a clear, verifiable official source. This guide connects inventory, conflict resolution, writing and maintenance.
A reusable fact inventory
These five categories and twenty items are an inventory structure, not a quota. Include only verifiable information that can be published. Record the current statement, conditions, effective date, source, owner and publication permission. Leave unsupported items blank.
| Category | Facts to check |
|---|---|
| Pricing and contracts | Pricing model、Free/basic scope、Advanced-tier differences、Contract terms |
| Product and technology | Product names and versions、Feature list、Deployment options、Integrations and compatibility |
| Service boundaries | Response-time commitments、Support scope、Regions and languages、SLA and compensation |
| Customers and cases | Customer count and definition、Retention/satisfaction definition、Publishable cases and permission、Industry scope |
| Company and credentials | Legal name and positioning、Founding and funding、Certifications and scope、Locations and team definition |
Fact pages and the idea of a single source of truth
When a model generates an answer, it may mix training data, media articles, e-commerce pages, third-party reviews, and the official site. When the same price or spec exists in several conflicting versions online, no one can guarantee which one the AI will pick. A fact page fixes the current official wording at one crawlable, citable, timestamped URL for people to check and models to quote.
One boundary matters: being crawled, being indexed, being cited in an answer, and being recommended as a brand are four different layers. A fact page lowers the chance of conflict, but it does not guarantee indexing, and it does not guarantee citation. Google states that AI search features follow existing SEO fundamentals and do not require a dedicated Markdown or llms file; see https://developers.google.com/search/docs/appearance/ai-features .
How to write it: seven operational steps
-
One assertion cluster per page. For example, "which models are monitored", "which deployment modes are supported", and "contact and support boundaries" belong to different slugs. Do not put all marketing copy on one page, or the AI may quote a fragment out of context.
-
Open with one quotable definition sentence. The first paragraph should say "X is Y, currently includes A/B/C, and applies to...". Keep product and model names in their original English form to avoid retrieval ambiguity.
-
State What is / What is not. Define boundaries to reduce over-inference. Example: a fact page says "initial signals are for directional observation and do not constitute a baseline"; it does not say "using this will necessarily raise AI recommendation rates".
-
Provide verifiable fields. Label each fact with source, owner, version, effective date, and public permissions. When price or specs change, update the
updatedfield and version number instead of only editing the body. -
Link internally to the canonical page. Other marketing pages and blog posts should quote the fact page's short sentences, not rewrite key numbers or capability boundaries. Changing once and syncing site-wide is the basic action to avoid channel conflict.
-
Add structured data. Choose Organization / SoftwareApplication / FAQPage / HowTo as appropriate, and keep markup consistent with visible text. Example (example only, not this site's current configuration):
{"@context":"https://schema.org","@type":"Organization","name":"Example brand","url":"https://www.example.com/"}
- Retest under the same conditions after publishing. Fix the question set, model, and conditions, then record whether answers cite that URL or become more accurate. Without a real monitoring record, do not claim that a given channel "has cited your brand".
Suggested page list (example)
The following is an example structure; companies should trim it to their own information environment:
- What the brand is / is not
- Flagship product specs and price (with validity period)
- Service regions and channel policy
- FAQ and comparison notes (each reason verifiable)
- Contact and support boundaries
Common failures and diagnosis
| Symptom | Possible root cause | Actionable step |
|---|---|---|
| The same price differs across blog, e-commerce, and PDF | No canonical pricing page | Create one authoritative pricing page and update each channel; redirect only superseded pages serving the same purpose |
| The fact page is all adjectives | No quotable short sentence | Rewrite each opening sentence as "X is..." and add numbers and dates |
| The AI describes a feature removed two years ago | Old product pages are still retrievable | Redirect old pages; consolidate the product matrix into one page |
| Nothing changes after editing | No same-condition retest | Fix the question set and model, keep before/after records, then judge |
Diagnostic boundary: the above is a suggested troubleshooting order, not a causal guarantee. Being crawled does not equal being indexed, and being indexed does not equal being cited in an answer.
FAQ
Q: Should a fact page be in Chinese or English? A: Prepare it for the target model and user language. Bilingual or per-language canonicals with mutual alt-language declarations are recommended.
Q: How many assertions can one fact page hold? A: One assertion cluster per page. Too many makes quoted snippets lose context and makes validity tracking hard.
Q: Should it include marketing copy? A: Fact pages should focus on verifiable statements. Keep marketing copy on marketing pages; fact pages quote but do not rewrite key numbers and boundaries.
For crawler configuration details, see the AI crawler guide.