What SEO Proof Has to Get Right: Inside a Public Register of Scored Sites

What SEO Proof Has to Get Right: Inside a Public Register of Scored Sites

Published SEO and credibility numbers are everywhere. Moz's Domain Authority, Ahrefs' Domain Rating, "trust scores," AI-visibility scores: you see a number, a color, sometimes a badge. What you almost never see is how the number was produced or whether you, a stranger to the company that published it, can check it yourself.

That's the actual question a practitioner should be asking about any public score: not "is this number high," but "can I verify this at all, right now, without asking permission." This piece uses a live example, the public register at trustgrowth.ai/proofs, to walk through a four-part test you can apply to any SEO proof claim, including this one.

What counts as proof, not just a score

A score becomes SEO proof only when a third party can independently check how it was generated, not just what it says. Four properties separate a checkable record from a marketing graphic:

1. Permanent record IDs. The identifier assigned to a subject never gets reassigned to a different subject later.
2. First-party data only. The underlying numbers come from a source the subject owns and controls, not a scrape or a third-party crawl index standing in for owner data.
3. Visible weak spots. Unresolved issues stay on the public record instead of being quietly dropped once they're inconvenient.
4. Machine-readable records. The same facts a person reads on the page are available in a structured format a script can query.

Google Search Console's site-ownership verification is the industry-standard example of what a first-party check looks like in practice: an owner proves control of a property via DNS record, HTML file, meta tag, or Google Analytics/Tag Manager linkage, and Google's own systems attest to that ownership (Google, Search Console Help: Verify your site ownership). Nobody has to trust a claim of ownership; the verification mechanism is inspectable. That's the bar the rest of this piece measures against.

A number that never gets reused

At the time of writing, the public register at trustgrowth.ai/proofs lists six entries, numbered TG-0001 through TG-0006. Each number is minted once, at the site's first entry into the register, and is never reassigned to a different site afterward.

The reason this rule matters more than it sounds: if an ID could be reassigned, a new and completely unrelated site could inherit the history, and by extension the credibility, implicitly attached to an old number. That would break the one property that makes a numbered record useful in the first place — that the number and the subject stay linked forever. A record ID with a floating referent isn't a record; it's a label that can be moved around.

The closest real-world analogy is Certificate Transparency logs, which append entries to a public, cryptographically verifiable log and never recycle a log entry's position (IETF, RFC 6962, Certificate Transparency). The comparison is structural, not cryptographic (TrustGrowth's register doesn't use a Merkle tree), but the underlying discipline is the same: append-only, no silent reassignment.

For the scoring mechanics behind each entry (what's measured, how weights are applied, why a score changes between audits), see how the underlying score is calculated rather than taking this article's word for it.

Where the numbers come from, and what that costs

Every number on the register comes from the site's own connected Google Search Console property, with no scraped traffic estimates and no third-party crawl index substituting for owner data. That rules out the estimator category entirely, including tools such as Semrush and Similarweb that model a site's traffic externally rather than reading an owner's verified property. That constraint is the whole reason the number means anything: a self-reported figure with no data-source rule attached to it can be anything, but a figure tied to a verified Search Console property is at least anchored to a real, owned data source, per Google's own documentation on verification and the Performance report.

That constraint has a direct cost, stated plainly rather than in a footnote: a site cannot appear on the register unless its owner connects that Search Console property. This is a coverage limitation, not a popularity ranking. Six entries out of the millions of indexed sites on the web is not a sample that supports any claim about typical performance: it's a demonstration of a mechanic, on the sites the operator happened to connect.

It also means the register cannot be read as evidence of adoption, demand, or an external user base, since all current entries are the operator's own portfolio. For how an authority dimension gets scored inside that same first-party-only data rule, see how authority is handled inside a first-party-only data rule.

The weak parts stay on the record

The strongest evidence for a proof system isn't a good number — it's an unflattering one that stays public. Entry TG-0005, nferens.com, sits on the public register at a low score, under the operator's own name, viewable directly at TG-0005, nferens.com.

The policy is simple: open audit issues stay listed on a record until a newer audit clears them. The register shows the current baseline, not a curated highlight reel, which means a visitor sees the same unresolved gaps the operator sees.

Honoring that policy against an unflattering number, rather than only when the numbers are flattering, is the difference between a claim and an observable fact. Anyone can promise transparency; publishing a low score under your own name and leaving it up is the version that can be checked.

One field deserves a precise reading rather than an interpretation: some entries on the register display no tier. A missing tier is a promotion-gate sentinel in this system, a marker that a threshold hasn't been crossed yet, not a synonym for "unrated."

Google's own guidance on people-first, helpful content treats disclosed limitations as part of what makes content trustworthy, not as a liability to hide (Google, Creating helpful, reliable, people-first content). A register that leaves unresolved gaps visible is applying the same logic to a score. For the broader argument that a proof system has to show current-state truth before it can function as a marketing asset at all, see why current-state truth matters before a proof becomes a marketing asset.

A record a machine can check without you

Each entry on the register is also served as JSON at trustgrowth.ai/api/v1/proofs/{slug}, verified returning HTTP 200 with an application/json content type. That's a second surface for the same facts shown on the human-readable page: not a summary of them, the same underlying data.

The purpose is straightforward: an agent, script, or crawler can check a record's current state without parsing rendered HTML. That distinction matters more each year as more evaluation of a page happens by software (LLM retrieval, monitoring scripts, third-party audit tools) rather than by a person reading it in a browser.

This follows an established pattern rather than inventing a new one. Google's structured data documentation describes the same principle: expose machine-readable facts (via JSON-LD, for example) alongside the human-readable page so that automated systems don't have to guess at meaning from layout (Google, Understand how structured data works). For the interface itself, the endpoint is documented at the developer documentation.

Check the register yourself

Don't take this article's framing on faith — the point of the exercise is that you don't have to. Go inspect the live register at trustgrowth.ai/proofs and its JSON endpoint yourself, including the low-scoring entry.

Be precise about what "verified" means here, because the word gets overloaded elsewhere: verified means the site's Search Console property is verified, nothing more. It is not an audit certification, and it is not a third-party attestation of the score itself. All six entries currently on the register are the operator's own sites, so the register is best read as a worked example of a proof mechanic, not as evidence of external uptake.

The single testable idea underneath all of this: a number that cannot be checked by someone other than the person who published it is not proof — it's a claim wearing a proof's clothing. Continue inspecting the mechanic at the public leaderboard and on the proof pages feature documentation.

Four-part test at a glance

Check What it requires Where it shows up in this example Permanent record IDs ID assigned once, never reassigned to a new subject TG-0001–TG-0006, minted at first entry First-party data only Numbers sourced from an owned, verified property Search Console-connected property per entry Visible weak spots Unresolved issues stay listed until re-audited TG-0005 (nferens.com) low score, publicly listed Machine-readable records Same facts available as structured data, not just HTML /api/v1/proofs/{slug} returning HTTP 200, application/json

FAQ

What does "verified" mean on a public score register like this one?
It means the site's Google Search Console property has completed Google's ownership verification process. It does not mean an independent audit or third-party certification of the score itself.

Why doesn't a reassigned record ID work as proof?
Because reassignment lets a new, unrelated site inherit the history and credibility implicitly attached to an old number, breaking the link between the ID and its original subject, the one property that makes a numbered record useful.

Does a low score on a public register hurt the register's credibility?
No. Leaving a low score visible under the operator's own name, rather than removing it, is what makes the register checkable rather than promotional. Entry TG-0005 (nferens.com) is the direct example.

Can a third party appear on this register without the operator's involvement?
No. A site can only appear if its owner connects a verified Google Search Console property, which means the current six entries reflect coverage, not adoption or popularity.

Why publish a JSON endpoint alongside the human-readable page?
So that agents, scripts, and crawlers can check a record's current state without parsing rendered HTML, the same rationale behind structured data more broadly, per Google's structured data documentation.

Key takeaways

• A public score register is only SEO proof if a third party can check it directly, not because a company asserts the number is honest.
• Apply four checks to any register: permanent IDs, first-party-only data, visible weak spots, and machine-readable records.
• TrustGrowth's register at trustgrowth.ai/proofs currently has six entries (TG-0001–TG-0006), sourced only from connected Google Search Console properties, with unresolved issues (including a low score on entry TG-0005) left visible rather than removed.
• "Verified" in this context means Search Console ownership verification only, not an audit or external certification.
• All six current entries belong to the operator, so the register demonstrates a mechanic; it is not evidence of external adoption.