Changelog, docs and trust center: pages that date and prove your claims

Which page proves which claim?

Every claim on a software company's marketing pages needs one public page that proves it and a date that says when it was true. The SaaS and software hub lists what a software site has to state; this article is about the pages where those statements are proved. The table pairs each kind of claim with its proof.

A claim with no page behind it can still be repeated, by a salesperson, a reviewer or an answer, but it cannot be checked, and it carries no date when it travels. For software the facts change with every release, so the date matters as much as the claim. A page that pairs the two is citable in the sense this site's glossary uses: it can be quoted and still be true.

The one controlled study this site cites measured changes made to the source itself. On a benchmark of 10,000 queries, Aggarwal and colleagues (KDD 2024) found that adding citations, quotations and statistics raised a source's visibility in generated answers by up to about 40% for the best methods. The paper measured sources in general, not software companies. A proof page is what a citation for a product claim can point at.

A changelog entry for every change, dated, with the plans it applies to

A changelog becomes a record when every entry carries its release date, says what changed in the words a customer uses, and names the plans, platforms and regions it applies to. Entries for removals and deprecations matter as much as launches: they are what a reader checks an old claim against. What to do when an answer keeps repeating a removed feature is a separate job; the entry is where that job starts.

[YYYY-MM-DD]  [Short name of the change]
Type:       New | Changed | Deprecated | Removed | Fixed | Security
Plans:      [the plans it applies to, or "all plans"]
Where:      [web app, API version, iOS or Android version, regions]
What:       [one or two sentences, in the words a customer uses]
Customers:  [anything existing customers must do, or "nothing"]
Docs:       [link to the feature's documentation page]

Give each entry an address that never changes, its own page or a fixed anchor, so a citation points at the entry and not at the top of a page that keeps growing. Date it on the day it shipped, not the day someone wrote it up. When an entry has to be corrected, keep the original date and add a line saying what was edited and when, so the entry stays a record.

If the changelog has an RSS or Atom feed, Google's page on building a sitemap says a feed's URL can be submitted as a sitemap, keeping in mind that a feed carries only recent URLs. The full archive still belongs in your XML sitemap, each entry with its own lastmod.

The product's markup can point at the record too. In the schema.org vocabulary, SoftwareApplication sits under CreativeWork and has softwareVersion and releaseNotes, which schema.org describes as what changed in this version, as text or a URL; releaseNotes can carry the changelog's address. Google's software app documentation lists neither property among those it uses, so treat them as description for any reader of the markup rather than as a search feature.

Documentation anyone can open, one feature and its limits per page

Public documentation proves a feature claim when a reader can open it without an account and find what the feature does, which plans include it, and its limits written as numbers. One page per feature, at an address that stays put. At the top, the plans ("Available on [plan] and [plan]"). In the body, the limits, such as records per account, file size, requests per minute or seats, and what the feature does not do. At the foot, the date the page last changed. Docs written that way are a knowledge base for customers and, at the same time, the fullest description of the product that anyone outside the company can read.

A login wall turns all of it into a sign-in form. Google's software app documentation tells site owners to make sure a page is not blocked by robots.txt, a noindex tag or login requirements, and any fetcher without an account meets the same wall. Keep account-specific help behind the login and put the feature pages in front of it.

A docs site built as a single-page app can serve an empty shell until its scripts run. Google, by its own account in JavaScript SEO basics, renders pages as a later, separate step; the crawler pages of the assistants' operators promise no rendering step, so for their fetchers usually no scripts run. Google's page on AI features lists making important content available in textual form among its practices. Serve the words in the HTML.

Versioned docs label each version in the text at the top, with a link to the current one and the date the old one stopped being current. And if the docs live on a host of their own, such as docs.[your domain], that host serves its own robots.txt, apart from the main site's; the crawler access check reads it token by token like any other.

A trust page that lists only what the company holds

A trust center or security page proves a security claim when it lists only the certifications and reports the company holds, each named the way its issuing body or auditor names it, with its dates and the way a customer can request it. For each one, the page states:

• The exact name, copied from the certificate or the report rather than shortened into a slogan.
• What it covers: the product, the legal entity and, where the document says so, the locations.
• The period an audit report covers, or the dates a certificate is valid from and until.
• Who issued it, as the document names the certification body or the audit firm, and the certificate number where there is one.
• How a customer gets the report: the request form or address, whether an NDA comes first, and who answers.

Nothing goes on the list that has not been issued. If an audit is underway, a separate line can say so, without a date you cannot keep. The page states what the company holds and does; it does not explain what a standard requires or what an auditor's opinion means. Those are questions for your auditor and your counsel, and a paraphrase written by marketing is a claim nobody issued.

A badge is an image, so the name, the scope and the dates go in the text beside it, where a reader, a screen reader and a text fetch can all read them. A security overview published only as a PDF has the same problem as a price list kept in one.

In markup, schema.org has a hasCertification property whose value is a Certification, with issuedBy, certificationIdentification, validFrom, expires and auditDate among its properties. The property's page names Organization, Person, Place, Product and Service as the types that use it. SoftwareApplication, a CreativeWork, is not on that list, so the certification belongs on the company's Organization node. Google's organization documentation does not list the property, so it earns no search feature, and it fits only where the issuer calls the document a certification.

Date the page, and change the date on the day a certificate is renewed or lapses, a new report period begins, or a subprocessor or a data region is added.

A status page that keeps its incident history

A status page proves an availability claim only while it keeps its history: every incident with its date, start and end times with the time zone, the components affected and a short account of the cause. A page that shows today's green lights and nothing else says nothing about the months before.

Keep old incidents and scheduled maintenance on the record rather than letting them expire. If the marketing site publishes an uptime figure, it names the period the figure covers and links to the history it was computed from. That is one case of a wider rule for any number a company publishes about itself: the period and the method go beside the figure, which is the subject of thought leadership a machine can count.

Plan limits written as text on the pricing page

The pricing page proves a price or a limit when every limit is text on the page, per plan, with the currency, the billing period and the date the plans last changed. A limit that appears only in a tooltip drawn by a script, or in an image of a table, gives a text fetch nothing to read.

When plans change, the page says so: "Plans changed on [date]; customers on [old plan] keep [terms]", where that is true. Old pricing addresses redirect to the current page, so a link someone saved a year ago opens today's prices. Your comparison pages cite this page for every price of your own, so when it changes, the dated rows in an alternatives or versus page change with it.

One date, and the four places it appears

A proof page's date is useful only if the date a reader sees, the date in the markup, the date in the sitemap and the date the server sends all agree, and if they move only when the content does:

• On the page: "Last updated [date]", in text, near the top or the foot.
• In the structured data: dateModified, which Google's article documentation defines as the date the article was most recently modified.
• In the sitemap: lastmod, which Google's sitemap page says should reflect the last significant update, such as a change to the main content, the structured data or the links, and not a new copyright year.
• In the HTTP response: the Last-Modified header, which RFC 9110 defines as the time the origin server believes the page was last modified.

The glossary entry on freshness covers how these four fit together. For proof pages the rule to keep is in Google's helpful content guidance, which names changing a page's date to make it seem fresh, when the content has not substantially changed, as a warning sign. Move the date when a certificate, a limit or an incident changes, and at no other time.