We Ran Our Own E-E-A-T Audit. Our Authoritativeness Scored 33.

Prerequisites

• A TrustGrowth account connected to Google Search Console for the domain under audit.
• Familiarity with the distinction between a scored signal set (the subset of signals TrustGrowth uses to calculate the published percentage) and a raw signal inventory (a larger, unweighted list of signals detected on the site, some of which are excluded from scoring). We define both below.
• Comfort reading JSON responses. All figures in this piece come directly from two endpoints: GET /api/v1/sites/trustgrowth/score and GET /api/v1/sites/trustgrowth/eeat.
• No remediation work performed on trustgrowth.ai between the audit run (2026-07-26) and publication — this is a precondition for the single-run framing below, not a general requirement for readers running their own audits.

1. What We Did and Why Publishing It Is Uncomfortable

On 2026-07-26, TrustGrowth ran its own E-E-A-T audit against trustgrowth.ai using our own product, calling GET /api/v1/sites/trustgrowth/score. We are publishing that run in full, including the pillar where the site scored worst: authoritativeness, at 33.33%.

We didn't rerun the audit after seeing the number. We didn't fix the gaps first and then write this up as a success story. The run you're reading about is the run that happened. If a second, dated run against the same scored signal set changes the picture, that will be a separate piece with its own date and its own endpoint call — not an edit to this one.

2. The Headline Number and What It Actually Means

The report score for trustgrowth.ai, run 2026-07-26, GET /api/v1/sites/trustgrowth/score, is 67. Here is the arithmetic behind that 67, so you can re-derive it from the same endpoint rather than take it on faith:

report_score = (trustworthiness_pct + expertise_pct + experience_pct + authoritativeness_pct) / 4

Plugging in the four pillar percentages from the same run:

{
  "run_date": "2026-07-26",
  "endpoint": "GET /api/v1/sites/trustgrowth/score",
  "pillars": {
    "trustworthiness_pct": 85.71,
    "expertise_pct": 80.95,
    "experience_pct": 68.00,
    "authoritativeness_pct": 33.33
  },
  "report_score": 67.00
}

(85.71 + 80.95 + 68.00 + 33.33) / 4 = 67.00.

That 67 is an unweighted mean of four percentages. It is not a point total, and it is not a fraction of anything. Do not write it as "67/97" — that fraction doesn't exist in this calculation, and conflating it with a different denominator produces a wrong number that merely looks plausible.

Now the part that trips people up. TrustGrowth exposes two distinct signal sets, and they must be kept apart.

(a) The scored set produces the published score above. It covers 25 signals worth 76 points total. trustgrowth.ai holds 55 of those 76 points. 55/76 = 72.4%. That 72.4% is not the published 67. It's a raw point ratio across the scored set, and it isn't the number TrustGrowth reports as the score, because the score is a mean of four pillar percentages, not a single global ratio.

(b) A separate legacy signal inventory, returned by GET /api/v1/sites/trustgrowth/eeat, covers a larger set of signals — 97 points possible, 67 earned. This inventory includes signals the scored set deliberately excludes (more on why in Section 4).

Here's the coincidence, stated plainly so nobody gets misled by cross-checking both endpoints: the legacy inventory's 67 earned points and the published score of 67 are two different quantities that happen to share a numeral. One is a raw point count out of 97. The other is a mean of four percentages. They are not the same measurement, and the overlap is arithmetic coincidence, not a hidden identity.

Why does a mean-of-pillars design matter here? A weak pillar is expensive under this formula in a way it wouldn't be under a flat point total. If authoritativeness were folded into one big 76-point bucket instead of averaged as its own percentage, a low score there would get diluted by the other points sitting in stronger pillars. Averaging four percentages means each pillar carries equal weight regardless of its underlying point count — so a pillar sitting at 33.33% pulls the mean down by roughly 8.4 points relative to a pillar at 100%, no matter how small that pillar's point count is.

3. Our Worst Pillar: Authoritativeness at 33.33

Authoritativeness is the lowest of the four pillars, at 33.33%. The precise math: 3 of 9 scored points — not 7 of 22. The authoritativeness pillar's scored denominator is 9 points, drawn from exactly three signals worth 3 points each:

{
  "pillar": "authoritativeness",
  "pillar_pct": 33.33,
  "scored_points_earned": 3,
  "scored_points_possible": 9,
  "signals": [
    { "signal": "has_guest_contributions", "points": 3, "status": "present" },
    { "signal": "has_media_coverage", "points": 3, "status": "absent" },
    { "signal": "has_industry_partnerships", "points": 3, "status": "absent" }
  ]
}

3/9 = 33.33%. That's the whole calculation for this pillar.

Worth naming plainly: 9 points is a small denominator. A single 3-point signal swings the percentage by roughly 33 points. That's not a flaw in the audit — it's a property of small-N pillars that any practitioner reading pillar breakdowns needs to hold in mind before treating a percentage-point move as meaningful.

4. What Does NOT Explain That 33 — the Counter-Intuitive Part

Here's where it's tempting to reach for an intuitive explanation and get it wrong.

trustgrowth.ai's domain rank, per DataForSEO, is 0. Its backlink profile is 6 backlinks from 1 referring domain. Both numbers look like obvious culprits for a low authoritativeness score.

They aren't part of the calculation. domain_authority and has_backlinks_quality are excluded from the scored signal set entirely. Neither field feeds the authoritativeness percentage. Stating otherwise — "the 33 is low because domain rank is 0" — would be a causal claim the data doesn't support, so we're not making it.

The design reason for the exclusion matters more than the exclusion itself: a signal that TrustGrowth can't independently measure, or that a third-party provider blocks or rate-limits, must never be rendered as a measured zero. Scoring an unmeasured signal as a 0 would understate the site unfairly and misrepresent the audit as more complete than it is. Exclusion is the honest choice.

The clearest example is has_brand_mentions. It's not failed. It's UNMEASURED, pending a Moz integration slated for Phase 3b. Reporting it as a zero would imply TrustGrowth checked for brand mentions and found none — that's not what happened. TrustGrowth hasn't checked yet.

The same exclusion logic runs the other direction, too. has_ssl, has_regular_updates, and has_citations are all present on trustgrowth.ai — but they're also excluded from scoring. That means the raw 97-point legacy inventory flatters the site slightly relative to the 76-point scored set, because it counts signals the score itself deliberately ignores. Read only the eeat endpoint and skip the score endpoint, and you'll see a rosier picture than the one TrustGrowth actually publishes.

5. The Six Gaps We Actually Have

21 of 76 scored points are unearned on trustgrowth.ai. Here they are, with the product's own recommendation strings quoted verbatim — no paraphrasing, because a paraphrase can soften a null result into something that reads like progress:

• has_case_studies — 0/5 points. "No case study URLs or H2 headings found."
• has_product_screenshots — 0/3 points. "No product screenshot images detected."
• has_author_pages — 0/4 points. "No author, team, or about pages found."
• has_about_page — 0/3 points. "No about page found or linked."
• has_media_coverage — 0/3 points. "No press pages or news domain links found."
• has_industry_partnerships — 0/3 points. "No partner pages, logo grids, or 'trusted by' sections found."

5 + 3 + 4 + 3 + 3 + 3 = 21. That's the full gap, no rounding.

One of these is self-referential and worth naming instead of quietly stepping around: has_case_studies is absent — and this article is, structurally, a case study. Publishing it doesn't retroactively fill that signal, because the audit looks for dedicated case study URLs or H2-level case study headings across the site, not a single blog post making a claim about itself.

6. What We Are Not Claiming

We're not presenting a before/after comparison. This is one run. The eeat_score delta over the trailing 7 days is 0 — the numbers have not moved since 2026-07-26, because nothing has changed on the site and no second run has executed.

We are not claiming any ranking effect. We are not claiming any traffic effect. We haven't measured either, so neither appears here as a result, hinted or otherwise.

No causal claim appears anywhere in this piece. Domain rank being 0 does not "cause" the 33.33% authoritativeness score — we said that plainly in Section 4 and we're repeating it here because it's the claim most likely to get inserted by a reader's own pattern-matching if we don't block it explicitly.

What would license a before/after piece: a second, dated run against the same scored signal set (the 76-point, 25-signal set from GET /api/v1/sites/trustgrowth/score), taken after specific remediation work on the six gaps above. That run hasn't happened. We haven't earned the comparison yet.

7. How a Reader Reproduces This on Their Own Site

The steps, in the order we performed them:

1. Run the audit against your own domain.

curl -s -X GET \
  "https://api.trustgrowth.ai/v1/sites/YOUR_SITE_ID/score" \
  -H "Authorization: Bearer $TRUSTGROWTH_API_KEY" \
  | jq '.pillars, .report_score'

1. Retrieve the pillar breakdown from the same response and identify the lowest of the four pillar percentages — that's your priority pillar, not necessarily the one that feels weakest.

2. Cross-check which signals inside that pillar are part of the scored set versus excluded or unmeasured. Call the legacy inventory endpoint separately to see the full raw list, but don't average it into the score:

curl -s -X GET \
  "https://api.trustgrowth.ai/v1/sites/YOUR_SITE_ID/eeat" \
  -H "Authorization: Bearer $TRUSTGROWTH_API_KEY" \
  | jq '.signals[] | select(.status == "excluded" or .status == "unmeasured")'

1. Read the product's own recommendation string for every unearned signal in the scored set. Don't rewrite them — quote them, the way we did in Section 5. A recommendation string is a diagnosis, and paraphrasing it risks losing the specificity that makes it actionable.

Separately from the E-E-A-T score, we ran an independent crawler-access check on 2026-07-27 UTC, checking robots.txt handling for five known AI crawlers plus a dedicated file:

GPTBot            -> robots.txt: 200
Google-Extended   -> robots.txt: 200
PerplexityBot     -> robots.txt: 200
ClaudeBot         -> robots.txt: 200
CCBot             -> robots.txt: 200
/llms.txt         -> 404

We report this as a separate diagnostic, not folded into the E-E-A-T numbers above, because it's a different measurement, on a different date (2026-07-27 vs. 2026-07-26), against a different target (robots.txt handling, not scored E-E-A-T signals). Merging the two into one narrative would misattribute a crawler-access result to an authoritativeness score, or vice versa.

8. Method Note

Everything in this piece traces to a single run, single domain: trustgrowth.ai, dated 2026-07-26, via GET /api/v1/sites/trustgrowth/score, restricted to the scored signal set (76 points, 25 signals). The legacy inventory figures (67/97) come from GET /api/v1/sites/trustgrowth/eeat, same domain, same date, and are reported as a separate quantity throughout.

The crawler-access check was performed separately, 2026-07-27 UTC, against robots.txt and /llms.txt for five named crawlers.

Every number above carries its run date and source endpoint. We haven't cited any tool version numbers, because none have been independently verified for this run.

Further reading on the underlying framework: How to Build Website Trust Signals: A Practical Checklist for Credibility and Search Readiness.

Troubleshooting

"My pillar percentages don't sum the way I expect." They shouldn't sum — they average. Check the formula in Section 2. If your report_score doesn't match (pillar_a + pillar_b + pillar_c + pillar_d) / 4, verify you're pulling all four pillar_pct fields from the same run_date and the same endpoint response, not mixing a cached response with a fresh one.

"The eeat endpoint and the score endpoint disagree." They're not supposed to agree — they measure different sets (97-point legacy inventory vs. 76-point scored set). If you're trying to reconcile 55/76 or 67/97 against the published report_score, stop: neither ratio is the score. The score is a mean of percentages, not a ratio of points.

"A signal I know is present on my site shows as excluded, not scored." Check the status field in the eeat response. "excluded" means the signal isn't part of the scored set by design (like has_ssl or domain_authority here). "unmeasured" means TrustGrowth hasn't checked yet, often pending a third-party integration (like has_brand_mentions pending Moz). Neither should be read as a failure.

"My robots.txt check returns different results for different crawlers." Confirm you're testing the actual crawler user-agent strings (GPTBot, Google-Extended, PerplexityBot, ClaudeBot, CCBot) against your live robots.txt, and check separately whether /llms.txt exists — a 404 there is a distinct, and increasingly common, null result, not an error in your check.

Summary and Next Steps

We ran one audit, on one date, against one domain, and published the pillar that came out worst: authoritativeness at 33.33%, or 3 of 9 scored points. We showed the formula behind the 67 headline score, separated it explicitly from the 55/76 and 67/97 ratios living in adjacent endpoints, and named six unearned signals with the product's own recommendation strings attached. We didn't explain the low pillar with domain rank or backlink count, because neither is part of the scored calculation — and we said so directly rather than let a plausible-sounding correlation stand in for a causal claim we can't support.

If you're running this on your own site: pull both endpoints, keep the scored set and the legacy inventory separate in your notes, and read the recommendation strings before you start remediation work. A second, dated run — after specific changes to the six gap signals above — is what would let us, or you, publish a legitimate before/after comparison. That run hasn't happened yet.