Citing a Spec: Footnote Sources for Every Claim

A specification without a source is an assertion. A specification with a source is evidence. The difference is a few characters of markup and a few minutes of discipline, and it changes how a page is read by customers, by reviewers and by the assistants that now summarise product pages for people who never visit them.

This guide shows how to attach checkable sources to the claims on a product page, what kinds of source are strong or weak, how to format footnotes on the web so that everyone, including people using screen readers, can follow them, and how to prevent the footnotes themselves from decaying.

Why footnote a spec

Three reasons stand out.

Readers can check. A reader who doubts "supports single sign-on on all paid plans" can follow the footnote to the documentation page and see the statement in context. Most will not click, but their confidence rises because they could.

Reviewers can quote accurately. Comparison writers and journalists work to deadlines. If your page links each fact to a primary source, they are more likely to repeat it correctly and less likely to rely on a stale third-party summary.

You can maintain it. A footnote is a reminder of where the fact comes from. When the source changes, you know which sentence to update. An unsourced claim has no such anchor.

Google's guidance on creating helpful content asks authors to consider whether a page makes clear who wrote it, how the information was produced and why. Visible sourcing is a direct answer to the "how do you know" question and an easy way to show experience and care.

Primary and secondary sources

Not all sources carry equal weight.

Primary sources are the original documents: your own documentation, your changelog, your contract, your audit report, your status history, the standard you claim to follow. They are best because they are authoritative and you control them.

Secondary sources describe the primary ones: reviews, articles, analyst notes. They can be useful context but they age, they may be wrong and they are not under your control. Label them as opinion or commentary and avoid using them to support hard facts such as limits and prices.

Self-referential sources are the weakest: a marketing page citing another marketing page. If the only source for a technical claim is a blog post that repeats it, the claim is not really sourced.

When you need a source and have none, treat that as a finding. Either create the primary document, for example by documenting the limit in the reference pages, or soften the claim until you can.

What a good citation contains

A web footnote does not need an academic format. It does need four things:

1. What the source is. A title in the reader's words: "API reference, rate limits".
2. Where it is. A working link, preferably to a specific section rather than a site's home page.
3. When it was checked. A date. Sources change, and the date tells the reader how fresh the verification is.
4. Who is responsible. Optionally, initials or a role, so internal readers know whom to ask.

A citation is a pointer, and its job is to make the claim verifiable by someone who has never met you.

Formatting footnotes on a web page

The standard pattern is a superscript number next to the claim, linking to a numbered list of notes at the bottom of the page, with a back-link from each note to the claim. A few practical points make this work well.

• Use real links and real lists. An ordered list of notes with anchor links is understood by browsers, crawlers and assistive technology. Avoid images of notes.
• Make the marker accessible. A bare superscript digit is a poor link label for screen reader users, who often navigate by listing links. Add visually hidden text such as "Note 3" or an accessible name that describes the destination. The Web Content Accessibility Guidelines include requirements on link purpose and on text alternatives that apply here.
• Keep the target visible. When a reader follows a marker, the note should be visible without extensive scrolling and should be highlighted so the eye can find it.
• Provide a way back. A return link beside each note lets readers resume where they were.
• Avoid hover-only notes. Notes that appear only on mouse hover are unavailable to keyboard and touch users.

For long pages, consider placing a short source list under each section rather than one list at the end, so that readers do not need to jump far.

Wording claims so a footnote can support them

A source supports a claim only if the claim is no stronger than the source. Compare:

• Weak match: "Fast, reliable performance.¹" The source is a performance chart; the claim is vague.
• Strong match: "Median response time for the primary interface was within a stated figure in the last measured month.¹" The source is the status page's published statistics.

Rewrite the claim until it fits the evidence. This often leads to more precise, more useful text.

A related discipline concerns dates. If the source says "as of the spring", the claim should say so too, rather than presenting a snapshot as a permanent truth.

Structured data and visible citations

If you add structured data to your page, for example with schema.org's SoftwareApplication vocabulary, keep it consistent with the visible content. Structured data helps systems understand a page but it should describe what readers can see. Where a property such as a version or a category is stated in markup, the same fact should appear in the visible spec table with the same source.

Preventing footnote rot

Links decay. Pages are moved, documents are replaced and sites are redesigned. A footnote that points to a dead page is worse than none, because it signals that nobody is maintaining the page.

• Check links on a schedule. An automated link checker run monthly catches most breakage.
• Prefer stable addresses. Link to permanent documentation paths and avoid addresses that include session identifiers or temporary tokens.
• Keep a source register. A simple table listing each claim, its source, its checked date and its owner lets you review systematically.
• Version your own documents. When you update a policy or a report, keep older versions available at stable addresses and cite the version.
• Archive important sources. For documents you do not control, keep a dated copy for your own records.
• Retire claims, not just links. If a source goes and there is no replacement, the claim goes too.

A source register template

For each footnoted claim, keep a row with:

• The claim, in the exact words on the page.
• The page and position where it appears.
• The source title and link.
• The date last checked and by whom.
• The next review date.
• Notes on how to re-verify, for instance "run the export and check the formats".

A register of fifty rows is a day's work to create and an hour a quarter to maintain. It is the quietest, most effective quality tool a specification page can have.

A worked example: footnoting a security row

Take a row from a fictional product's security block: "Independent audit report held: yes." On its own that is an assertion. Here is how it becomes a footnoted fact.

First, make the claim precise: "An independent audit report covering the production application was issued for the twelve-month period ending in spring.⁴" Second, find the primary source: the report's cover page and the page on the vendor's own site that explains how customers can request it. Third, write the note: "4. Security page, section on audit reports; request process described there; checked on a stated date by the security lead." Fourth, add the review date to the register.

Now the claim can be checked, can be updated when a new report arrives and cannot quietly outlive its evidence. If the report lapses without renewal, the row has a visible reason to change. Without the footnote, the row would have stayed on the page for years, saying "yes" about something that had stopped being true.

Tone: footnotes are quiet

Footnotes work best when they do not draw attention to themselves. Keep note text short and neutral: the title of the source, where to find it, the date. Do not use notes for argument or for marketing. If a thought deserves a sentence of explanation, it belongs in the body of the page, where readers will see it. The aim of the notes is to let the careful reader verify, and let the casual reader carry on undisturbed.

Summary

Attach a primary source to every contestable claim; word the claim no more strongly than the source supports; show the source, link and checked date in visible, accessible footnotes; and keep a register so that you notice when sources move. A page built this way is simpler to defend, simpler to quote and simpler to keep true, which is what a reference page is for.