How to Build a Brand Facts Page With Schema, Pricing, and a Changelog

Why have a facts page at all?

Assistants build their picture of a company from many sources: your homepage, old press coverage, directories, review sites, comparison articles and their own training data. When those disagree, the answer picks one, often the oldest or most repeated. A facts page gives every system, and every journalist, one current, citable statement of the basics. It also gives you a single place to point to when asking others to correct errors.

It does not replace your homepage, about page or pricing page. It summarises them in a form built for looking things up.

What should the page include?

Write each fact as a complete sentence that names the company, so it makes sense when quoted alone. Put the facts in HTML text and tables, not images or PDFs.

How should the pricing section work?

• State current prices with currency, billing period and whether tax is included.
• Say what each plan includes and its main limits.
• Give the date the prices took effect: "Prices from 1 April 2026."
• Link to the full pricing page, and make sure both say the same thing.
• Record the previous prices in the changelog, so anyone seeing an old figure can tell it is old.

If you do not publish prices, say how pricing works: "Priced per user; most customers with 20 to 50 users pay £400 to £900 a month." Silence leaves answers to guess. How pricing pages should be written for AI is covered in how SaaS pricing pages should be written so AI describes them correctly.

How should the changelog work?

A changelog turns "this used to be true" into a dated fact, which helps both readers and systems resolve conflicts between old and new sources.

• Newest entries first, each with a date.
• Say what changed and what it replaced: "1 April 2026: Starter plan rises from £10 to £12 per month. Existing customers keep £10 until 1 October 2026."
• Cover the changes assistants trip over: prices, plan names, discontinued products, renamed products, new locations, leadership changes, acquisitions.
• Link to the details: the release note, announcement or updated page.
• Keep old entries. Deleting history removes the evidence that an old figure is out of date.

What structured data should the page carry?

Use Organization markup that matches the visible text. Google's Organization documentation lists recommended properties, including name, legalName, alternateName, url, logo, description, foundingDate, address, contactPoint, email, telephone, sameAs, numberOfEmployees, and identifiers such as iso6523Code, leiCode, vatID and duns.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Brenlow",
  "legalName": "Brenlow Ltd",
  "alternateName": ["Brenwick Books"],
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png",
  "description": "Bookkeeping software for UK sole traders and small limited companies.",
  "foundingDate": "2019",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Bristol",
    "addressCountry": "GB"
  },
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://www.wikidata.org/wiki/Q000000"
  ]
}

Use the same @id for your organisation everywhere on the site, and describe products in Product and Offer markup on their own pages. Markup helps systems that parse it. But tests of AI assistants fetching pages found they read visible text and ignored JSON-LD, so the visible facts are what matter most. How stable identifiers tie pages together is covered in how to create knowledge graph pages with unique URIs or IDs for site entities.

How often should companies update machine-readable information when products or pricing change?

On the day of the change, not on a schedule. Every source that states the old fact keeps feeding it into answers until it is updated. So treat a price or product change as a release that includes its public record:

1. Facts page and changelog: add the change with its date.
2. Pricing and product pages: update text and markup together.
3. Product feeds: Merchant Center and any AI shopping feeds.
4. Sitemap: update lastmod for changed pages. Google says it uses lastmod only when it is consistently accurate.
5. Fast indexing: notify Bing and other participating engines through IndexNow.
6. Profiles you control: Business Profile, LinkedIn, review platforms, marketplaces and app stores. Wikidata is community-edited, so if you have an item, propose corrections with sources rather than treating it as yours.
7. Press boilerplate and partner listings.
8. Old content: update or annotate blog posts and help articles that quote the old figure.

Then run a quarterly check of the whole set, because something is always missed. Ask the main assistants the questions on your facts page, and note any answer that still gives old information and the source it cites. How to keep all these sources consistent is covered in how to make a brand's information consistent across AI-visible sources.

Where should the page live?

• At a stable, obvious URL, such as /company or /about/facts.
• Linked from the footer, the about page and the press page.
• One page only. Do not create regional or campaign copies that drift apart.
• Indexable and crawlable by search engines and AI crawlers.

What might an illustrative case look like?

Consider an illustrative bookkeeping software company that had renamed itself, raised prices and dropped a payroll add-on within 18 months. Assistants still used its old name, quoted old prices and said it offered payroll. It published a facts page with a "formerly known as" line, a pricing table dated from the latest rise, a short-answers section stating it no longer offered payroll, and a changelog of the three changes. It updated its review site profiles and Wikidata item to match. Two months later, most answers used the new name and prices. The payroll error persisted in one assistant until an old comparison article was corrected.

What do people ask about brand facts pages?

Is a facts page the same as an about page?

No. The about page tells your story. The facts page lists the facts for quick reference and correction.

Should we add an "updated" date to the page?

Yes. A visible date for the prices and for the page as a whole helps readers judge whether the facts are current.

Will a facts page fix wrong answers on its own?

Not always. It gives answers a correct source, but you may still need to correct the third-party pages they rely on.

What if some facts are confidential?

Leave them out. Only publish what you are happy to see repeated.