Start with the ambiguity you need to resolve
Choose the reference's subject before writing its headline. A company, a product, a free diagnostic, a paid platform and a research report are different things. A page that switches among them can distribute the confusion it was meant to resolve.
Write a one-sentence definition with the subject's name, what it is, who it serves and its practical purpose. Then add the most important distinction: a similarly named product, a former name, or a service the subject does not include.
For a business with several locations, one company reference need not carry every branch's opening hours. Link to the location page that owns those facts. For a software business, link to current pricing and product documentation instead of copying a large plan matrix into a page nobody remembers to update.
Use a separate page when it solves a distinct reader problem. If the About page already supplies a clear, maintainable reference, improve it. A new URL is not a requirement.
Build a small fact register before the public page
The working register is an editorial tool, not a new search standard. Start with the facts a customer or partner needs to distinguish your business and evaluate its offer.
Read each row with its scope and evidence.
| Working field | What to record | What belongs on the public page |
|---|---|---|
| Subject | Exact company, product or location | The name and an unambiguous definition |
| Claim | One statement that can be checked | Plain wording with its important conditions |
| Scope | Product tier, market, location or date | The qualification needed to interpret the claim |
| Evidence | Responsible owner's record and authoritative public URL | A useful public source link; never a private document |
| Review | Who checked it, when, and what was checked | A review date and an honest description of the check |
| Change trigger | A launch, price change, rename or policy update | Updated wording and a short change note when relevant |
Keep private approval details in the working register. Publish an appropriate business contact or correction route; do not expose employees' personal contact details or customer-specific contracts.
Reject claims that the available evidence cannot support. “Connects to our CRM” needs a named integration and its actual conditions. “Industry leading” needs a defensible comparison. A product owner's approval can establish what a product currently offers; it cannot establish that it is the best in a category.
Let dates describe the work that actually happened
A page's last edit date and the date of a product check answer different questions. Changing a link does not retest every feature on the page.
Our own Gist GEO facts page illustrates the distinction. As checked for this article, its reference was created on October 6 and updated on October 29. Its product-description verification date remains October 6. The change note explains that the later revision updated the platform reference and links; it did not run a new scan.
Read each row with its scope and evidence.
| Date on the Gist reference | What it records | What it does not establish |
|---|---|---|
| Created October 6, 2026 | The reference's creation date | A new measurement on each later visit |
| Updated October 29, 2026 | Later reference and link changes | Retesting every product statement |
| Product descriptions verified October 6, 2026 | A check against public product descriptions | A completed customer scan or an AI-comprehension test |
That is a narrower statement than “everything verified October 29.” It also leaves a clear next job: recheck product descriptions when the product changes.
Apply the same distinction to your page. If a human checked a branch's hours against the operations calendar, say that. If a reference was checked only against another public page, do not describe it as independent testing. Keep the previous version privately so a future reviewer can reconstruct what changed.
Make the visible page useful before adding markup
Lead with the definition, a compact fact table, important exclusions and links to fuller documentation. Put the conditions beside the claim. A limit hidden in a footer can leave the main statement misleading.
The Gist example separates a free scan's snapshot from the ongoing platform described on another page. That separation is the useful pattern. It is not evidence that an assistant will read either page, and this article does not independently validate every current Gist commercial entitlement.
If you add structured data, use the type and properties that actually describe the subject. Google's Organization documentation discusses adding organization details to the home page to help it understand and disambiguate an organization. It does not prescribe a separate facts page. A product reference is not permission to invent a legal company identity, affiliation, review score or certification. Organization guidance
Keep structured statements consistent with what visitors can read. Google requires relevant, accurate, up-to-date structured data and does not guarantee a search feature even when markup validates. A technically valid record can still describe the wrong thing. Structured-data policies
Give each changing fact a home
The hardest maintenance problem is often duplication. A price copied into five evergreen articles can outlive the offer it described.
Assign an authoritative editorial source for each fact: the pricing page for current prices, the branch page for local hours, the product documentation for supported exports. The facts page can summarize stable distinctions and link to those details. Where a value must be repeated, record the dependent pages so one approved change reaches them together.
This is an editorial ownership rule, not an instruction to add a canonical tag between unrelated pages. Do not use search canonicalization to merge a company reference with its pricing or product pages.
Give the facts page a named internal owner and a review trigger. A monthly reminder alone will not catch a price change tomorrow. Include it in the relevant product or operations release checklist, and provide a visible correction route for readers.
Check the page then check outcomes separately
Before releasing the reference, have someone unfamiliar with the offer answer three questions from the page: What is this? Which product or location does it describe? Where can I verify the important claim?
Have the technical owner check that the intended public page, its important text and any structured data are accessible under the site's actual policies. Link to it from relevant About or product pages. Keep private portals and internal records protected. Our citation audit covers the separate access and indexing investigation.
Finally, keep two completion states. “Reference published and checked” concerns the website. “An AI answer cited it accurately” requires an actual saved answer, its exact question, date, surface and source link. The first is useful work even when the second has not happened. Combining them would turn a well-maintained facts page into a claim it cannot substantiate.
Sources and scope
This guide combines Google's public documentation with editorial recommendations and a dated inspection of Gist's own public reference. It does not report an AI measurement, ranking experiment or causal uplift. The worked date example describes the page as read on October 31, 2026; later versions may differ. The same evidence and maintenance requirements apply to Gist and other businesses.