How We Score E-E-A-T from Search Console Data — and How to Check It Yourself

Prerequisites

Before reading further, you should have:

• A Google Search Console (GSC) property already verified for your domain
• A conceptual understanding of the OAuth 2.0 authorization code flow
• Familiarity with the E-E-A-T section of Google's Search Quality Rater Guidelines (most recent public revision)
• Working knowledge of basic statistical terms: sample size, confidence interval, correlation vs. causation

This article documents how TrustGrowth.ai collects data, extracts signals, and publishes scores. Every figure below is attributed to a source and a capture date. Figures re-score daily, so treat dated numbers as snapshots, not constants.

Step 1: What TrustGrowth Is and Isn't

TrustGrowth runs GSC-verified site audits, scores inferred E-E-A-T signals, produces growth diagnostics, generates AI-driven content strategy output, and publishes the resulting snapshot as a public proof page. That is the full scope of the product.

"GSC-verified" has a specific technical meaning. A user authorizes TrustGrowth via the OAuth 2.0 authorization code flow using the webmasters.readonly scope (https://www.googleapis.com/auth/webmasters.readonly). TrustGrowth then calls the Search Console API's sites.list method with the resulting access token. If the authenticated account has a permissionLevel of siteOwner, siteFullUser, or siteRestrictedUser on the property, TrustGrowth treats ownership as confirmed. No credential, screenshot, or self-report substitutes for this call.

from google_auth_oauthlib.flow import InstalledAppFlow
from googleapiclient.discovery import build

SCOPES = ["https://www.googleapis.com/auth/webmasters.readonly"]

flow = InstalledAppFlow.from_client_secrets_file("client_secret.json", SCOPES)
credentials = flow.run_local_server(port=0)

service = build("searchconsole", "v1", credentials=credentials)
sites = service.sites().list().execute()

for site in sites.get("siteEntry", []):
    print(site["siteUrl"], site["permissionLevel"])

Expected output for a verified property looks like https://example.com/ siteOwner. A property absent from this list is not verified, regardless of what a user claims.

TrustGrowth does not guarantee rankings and does not attribute revenue. State that limitation here, next to the claim it qualifies: a GSC-verified audit confirms property ownership and reports historical Search Console metrics; it does not predict future ranking position and does not measure revenue, because GSC exposes neither.

Step 2: Data Collection Method

TrustGrowth pulls data through three Search Console API endpoints: searchanalytics.query, sitemaps.list, and urlInspection.index.inspect.

request_body = {
    "startDate": "2025-04-01",
    "endDate": "2026-07-28",
    "dimensions": ["query", "page"],
    "rowLimit": 25000,
}

response = service.searchanalytics().query(
    siteUrl="https://example.com/", body=request_body
).execute()

for row in response.get("rows", []):
    print(row["keys"], row["clicks"], row["impressions"], row["ctr"], row["position"])

From searchanalytics.query, TrustGrowth pulls clicks, impressions, CTR, and average position. From sitemaps.list, it pulls submitted sitemap paths and indexed-URL counts:

sitemaps = service.sitemaps().list(siteUrl="https://example.com/").execute()
for sitemap in sitemaps.get("sitemap", []):
    print(sitemap["path"], sitemap.get("isPending"), sitemap.get("contents"))

From urlInspection.index.inspect, it pulls per-URL coverage status:

inspection_request = {
    "inspectionUrl": "https://example.com/blog/post",
    "siteUrl": "https://example.com/",
}

inspection = service.urlInspection().index().inspect(body=inspection_request).execute()
print(inspection["inspectionResult"]["indexStatusResult"]["coverageState"])

The date range in the first example, 2025-04-01 to 2026-07-28, spans roughly 16 months — the hard ceiling the Search Console API imposes on historical query data. TrustGrowth cannot pull anything older than that window, and neither can any tool built on the same endpoint. State that limit explicitly rather than implying a longer trend line than the API supports.

On scale: TrustGrowth publishes a small set of figures on its own proof page and machine-readable JSON, each carrying its own capture date — fields such as keyword_count, published_content_count, verified_since, and score_date. We report only what is published there, because those are the only figures a reader can independently re-check. We do not state a customer count, property count, or dataset size anywhere in this article, because no such figure is published, and an internal database export is not something a reader can verify.

Step 3: E-E-A-T Signal Extraction

GSC does not expose an E-E-A-T field. TrustGrowth infers proxies by mapping available signals onto the four Search Quality Rater Guidelines dimensions:

Dimension Inferred proxy input Experience first-person content markers, author byline presence Expertise schema.org/Person markup, cited credentials in page content Authoritativeness referring-domain volume, brand-mention frequency Trustworthiness schema.org/Organization markup, outbound citation density, HTTPS and contact-page presence

On-page checks include presence of author bylines, schema.org Person and Organization JSON-LD, and outbound citation density (count of external links to cited sources per 1,000 words of body content).

Off-page checks fall into two signal categories: referring-domain volume and brand-mention frequency. We name the category, not a specific index or a pull date, because no third-party backlink or mention index used here is one the author of this article has direct, dated access to confirm.

This needs stating plainly: E-E-A-T is a Search Quality Rater Guidelines concept describing how human raters evaluate content, not a field Google exposes through any API. TrustGrowth's E-E-A-T score is a third-party inferred proxy built from GSC and on-page data. It is not a Google-issued score, and no vendor's number is.

Step 4: Scoring Model

The public proof page rolls scores up into eight named dimensions, each rendered 0–100: Content, E-E-A-T, Technical, Growth, Performance, Authority, Visibility, and GEO. Per-dimension weights and the composition formula that produces the overall roll-up are not published. We state that plainly rather than printing a formula we cannot show.

Each dimension name maps to a fixed definition as displayed on the live proof page (verified 2026-07-28):

• Content — depth, freshness, and usefulness of public content
• E-E-A-T — inferred experience, expertise, authoritativeness, and trust signals (pillar-level breakdown is not shown on the page itself; see below)
• Technical — crawl, markup, and structural hygiene
• Growth — whether improvements turn into visible search movement
• Performance — speed and page experience signals
• Authority — backlink strength and referring-domain breadth
• Visibility — the site's verified footprint across search results
• GEO — generative-engine optimization; the page reads "Measures readiness for AI-powered generative search results." This is not a geographic or local-search metric.

On the Authority/E-E-A-T distinction: the Authority panel (19/100 on the current proof page) measures backlink strength and referring-domain breadth. It is a different measurement from the E-E-A-T authoritativeness sub-signal. The 19/100 figure is rendered directly in the proof page HTML. A separate figure, eeat_authoritativeness at 33.33, exists only in the machine-readable proof JSON at https://trustgrowth.ai/api/v1/proofs/trustgrowth (under scores.latest.eeat_authoritativeness, rounding to 33 under scores.eeat_breakdown.authoritativeness). The string "33" does not appear in the proof page HTML. Attribute each number to the surface it actually lives on.

The four E-E-A-T pillar names — Experience, Expertise, Authoritativeness, Trustworthiness — do not appear as broken-out labels on the public proof page itself. A reader cannot inspect pillar-level detail there; the pillar figures exist only inside the JSON, as shown above.

Data Sufficiency

An uncollected or immature dimension does not simply disappear from the page — it renders a number, and that number can look identical to a fully measured one unless the state label is read alongside it. On the live proof page (2026-07-28), the Visibility panel reads "Still maturing" next to a score of 50/100. The public proof JSON for the same snapshot reports visibility_v2 confidence 0.0, missing_reason: visibility_provider_keyword_count_missing, and every underlying visibility metric at zero: visibility_index 0.0, keywords_ranked 0, top3_count 0, top10_count 0.

This is a reader-facing hazard, not a design flaw we're proud of: a "Still maturing" 50 and a "Measured" 50 are not the same evidence. Read the state label next to every dimension score before treating the number as comparable across properties.

Uncertainty Disclosure on the Overall Score

The proof page publishes an uncertainty range on the overall roll-up, not just a point estimate. As of 2026-07-28, the hero block on the live, logged-out proof page reads: Overall score 62/100, range 54–71, state Provisional. The linked machine-readable JSON carries the same figures under scores.evidence: score_state: "provisional", uncertainty.lower: 54, uncertainty.upper: 71, present: 5, total: 8, confidence_weighted_coverage: 82.77.

curl -s https://trustgrowth.ai/api/v1/proofs/trustgrowth | jq '.scores.evidence'

{
  "score_state": "provisional",
  "uncertainty": { "lower": 54, "upper": 71 },
  "present": 5,
  "total": 8,
  "confidence_weighted_coverage": 82.77
}

Per-dimension detail is handled differently and should not be conflated with the overall range above. The JSON does carry per-pillar evidence under scores.pillar_states, but each entry is an object rather than a bare number: a state label, a confidence scalar, and a missing_reason. What it does not carry is a per-dimension lower/upper interval; only the overall score gets a published range. Per-dimension state is therefore a label plus a single confidence value, not a band.

{
  "growth_v3":     { "state": "maturing", "confidence": 0.2764, "missing_reason": "growth_evidence_maturing" },
  "content_v4":    { "state": "maturing", "confidence": 0.9697, "missing_reason": "content_v4_diagnostic_freshness_only" },
  "visibility_v2": { "state": "maturing", "confidence": 0.0,    "missing_reason": "visibility_provider_keyword_count_missing" }
}

The practical takeaway: TrustGrowth publishes its uncertainty rather than hiding it — a provisional label and a 54–71 range on the overall score, and a "Still maturing" marker with a zero-confidence pillar scalar on Visibility in this snapshot. That's a disclosed limitation of current data coverage (5 of 8 dimensions present), not a claim of strength.

One more limitation belongs here, not in a footnote: any observed relationship between these signals and search performance is a correlation, not a demonstrated causation. TrustGrowth has not run a controlled experiment isolating any single signal's causal effect on rankings or traffic. Treat correlation and causation as distinct claims, because they are.

Step 5: Public Leaderboard and Proof Pages

"Verified" on the public leaderboard means property ownership was confirmed through the GSC OAuth flow described in Step 1, and the published snapshot carries a score_date. It does not mean the score was computed the same day verification happened — that timing relationship is not established and we don't claim it.

Staleness is disclosed as a dated capture, not a promised interval. The live page currently reads "Updated July 28, 2026." We do not state a refresh cadence in days, because none is published.

Proof pages are generated by publishing an audit snapshot as-is — including weak or immature numbers like the Visibility panel above — with no added commentary softening the result. As of this writing, proof pages do not link to a separate methodology page: /about, /methodology, and /how-we-score each return HTTP 404 on trustgrowth.ai. This article, not an in-product page, is the methodology reference.

Step 6: Who Built This and Why

TrustGrowth is built by TechWright. The proof narrative on the public leaderboard is published under Ravi Yadav. No further roster or title claims are made here.

Credit-based paid plans exist because deeper research passes and automation runs consume compute — additional API calls, larger content-generation jobs, repeated crawl passes. The credit system prices that compute cost. It is not a gate on the scoring methodology itself, which is documented in this article and reproducible with the code samples above against your own GSC property.

Step 7: Limitations Summary

Four limitations govern every score this system produces, restated together rather than scattered as footnotes:

1. API constraints. The Search Console API enforces both a 16-month historical data window and standard per-project rate limits (quota errors surface as HTTP 429). Any trend analysis is bounded by that window.
2. No access to Google's internal E-E-A-T signals. TrustGrowth's E-E-A-T score is a third-party inferred proxy built from GSC fields, on-page markup, and named off-page signal categories. It is not, and cannot be, Google's own rater assessment.
3. Sample size. Low-traffic or newly verified properties produce thin searchanalytics.query row counts. A property with a handful of clicks per month yields wide statistical uncertainty in any derived metric, independent of the published overall-score range discussed in Step 4.
4. Correlation, not causation. Any relationship this model surfaces between signals and search performance is observational. No controlled experiment underlies it.

Troubleshooting

sites.list returns an empty siteEntry array. The authenticated Google account has no verified GSC property, or authorization used the wrong Google account. Re-run the OAuth flow and confirm the account in the consent screen matches the one that verified the property in Search Console.

searchanalytics.query returns rows with impressions: 0 for a known-ranking query. GSC aggregates and may suppress low-volume query rows for privacy; this is a GSC behavior, not a TrustGrowth collection bug.

Date range requested beyond 16 months returns fewer rows than expected, not an error. The API silently truncates to its available window rather than raising an exception — always check the actual date range in the response, not just the request.

Proof JSON fields differ from what's described here. Re-fetch https://trustgrowth.ai/api/v1/proofs/trustgrowth and check score_date — dimension values and state labels re-score daily, so a field observed last week may have shifted.

Summary and Next Steps

This article documented, in order: how GSC-verification is established via OAuth 2.0 and sites.list; which three Search Console API endpoints feed TrustGrowth's collection layer and the 16-month window bounding them; how on-page and off-page signals are mapped to E-E-A-T proxies; the eight named dimensions on the public scoring model and their exact panel definitions; the published uncertainty range and state labels on the current live snapshot (62/100, 54–71, Provisional, as of 2026-07-28); and the stated limitations of API scope, signal access, sample size, and correlation-versus-causation that apply to every score produced.

A reader can reproduce the collection layer independently using the code samples above and their own GSC-verified property, without TrustGrowth, using only the Search Console API. What TrustGrowth adds is the signal-mapping, scoring, and public-proof-publishing layer on top of that same data.