What an EEAT Checker Can and Cannot Verify

Abstract

An eeat checker (any automated crawler, API call, or DOM parser that scores E-E-A-T) can only report one of three states per signal: present, absent, or unreachable. It cannot verify that a credential is real, that an experience described in a post actually happened, or that a community genuinely trusts a domain. This article catalogs, pillar by pillar, which E-E-A-T signals an automated fetch can honestly claim to have measured and which it can only approximate through proxies. It describes what any such tool can technically determine, not one product's scoring methodology, and no specific product is named as the subject.

What checking E-E-A-T actually means

Google's E-E-A-T framework (Experience, Expertise, Authoritativeness, Trust) describes quality signals human raters use in the Search Quality Rater Guidelines. If you want the pillar-by-pillar detail on what each of those four terms means, that's covered in what an E-E-A-T score actually measures, and if you want a walkthrough of quantification methods, see how to measure your own site's E-E-A-T score. This article stays narrower: it defines the three-state model that governs what any automated fetch can honestly claim.

The three states are:

1. Measured/present: the signal was fetched successfully and found (e.g., Person schema exists in the page's JSON-LD).
2. Measured zero/absent: the signal was fetched successfully and confirmed not present (schema parsed, no author field).
3. Unreachable/unknown: the fetch itself failed, whether blocked by robots.txt, an auth wall, a timeout, or JS-rendered content that a non-headless crawler never executed.

Collapsing these three into a binary ("has it" versus "doesn't") is the single most common way an automated report misleads a reader. A page blocked by robots.txt and a page with genuinely no author markup produce the same low score in a binary system, even though one is a measurement and the other is a failure to measure. A tool built around a present/absent/unreachable data model, such as the one described in how a present/absent/unreachable data model is built into an audit, reports the fetch failure separately from the zero finding. You can run a bounded free E-E-A-T check to see this distinction on a live URL.

Method

The signal classifications below come from two sources. First, public specifications and vendor documentation: Google's published Search Quality Rater Guidelines, the schema.org Person type definition, Google Search Console's documentation for the Links report and the Manual Actions report, and the Robots Exclusion Protocol (RFC 9309, published 2022-09). Second, our own work building and operating TrustGrowth's audit pipeline, which fetches these signals in production and reports each one in the three-state model above rather than as a binary. Each signal listed below was classified by a single rule: can an automated fetch return a definitive answer about that signal's presence on the page, or only a proxy that correlates with the quality the pillar names?

To keep the examples honest, we ran the pattern on this site itself while writing this article (2026-08-15). We fetched one of our own published posts and parsed its JSON-LD: it returned an Article object whose author field resolves to a Person named Ravi Yadav with a profile URL, plus datePublished (2026-03-22) and dateModified (2026-07-27) timestamps. That is three present findings, each one a fact about markup. The same fetch tells us nothing about whether that person actually wrote the post; the limit this article describes applies to our own pages exactly as it applies to anyone else's.

Experience: what a checker can and cannot see

A crawler can detect the structural markers of first-hand experience but not the experience itself. Machine-checkable signals include: byline presence, dated authorship (datePublished and dateModified in schema.org markup), Person schema on the author entity, first-person content markers (phrasing in which an author reports having tested or measured something directly), and embedded original media with unique filenames or the presence/absence of EXIF metadata.

Two figures that appear in many tool reports are proxies, not proof: bio word count and post-count by the same named author on the domain. A 400-word bio correlates with perceived depth but does not confirm the author wrote it or that it's current.

No automated method can confirm whether the described first-hand experience actually happened, or whether an embedded image is genuine versus AI-generated. A checker can report "unique filename: yes, EXIF: absent." It cannot report "photo is real." That gap is structural, not a limitation of any one implementation.

Expertise: what a checker can and cannot see

A crawler parses text strings and schema fields; it cannot evaluate whether those strings are true. Machine-checkable signals: presence/absence of Person schema fields like jobTitle or alumniOf, presence of credential text strings ("PhD," "CPA," "10 years of experience"), presence of outbound links to external professional profiles (LinkedIn, ORCID, a licensing board), and presence of citations or outbound references in body content.

Proxies here include density of domain-specific terminology and the count of related in-depth articles on the same topic cluster; both correlate with subject depth but neither confirms accuracy. You can check whether author or organization schema is present on a given URL as one bounded, reproducible step in this process.

What no crawler can verify: whether a stated credential is real or current, whether the content is factually correct, or whether the author's actual command of the subject matches the claim. A page can carry a valid Person schema block with jobTitle: "Board-Certified Cardiologist" and no automated fetch can confirm the board certification is active.

Authoritativeness: what a checker can and cannot see

Authoritativeness signals are the ones most often confused with popularity metrics. Machine-checkable signals: presence/absence of inbound links as reported via an index or the Google Search Console API searchanalytics.query and Links reports, sameAs schema linking to verifiable external profiles, domain registration age via WHOIS, and valid HTTPS/TLS certificate status.

Raw backlink or mention counts are frequently used as an authority stand-in. That is a correlation, not a causal measure. A domain showing 5,000 referring domains in a commercial link index (an illustrative figure, not a measured one) is not automatically regarded as authoritative by its topical community; it has simply accumulated links, which a comparison method described in trustgrowth.ai vs Ahrefs vs Semrush on verified data treats as a distinct data class from GSC-verified signals.

No crawler can determine whether a topical community actually regards a site as authoritative, whether its offline reputation matches its online footprint, or whether editorial trust exists that was never expressed as a machine-readable link or mention. Authority that lives only in practitioners' heads, not in link graphs, is invisible to any API.

Trust: what a checker can and cannot see

Trust is the pillar with the most binary-looking machine-checkable fields, and also the pillar most prone to false confidence. Machine-checkable: presence/absence of a contact page, a privacy policy, a terms page, business registration text, a valid certificate chain, and, where an API exposes it, a manual action flag (Google Search Console's Manual Actions report).

Proxies include aggregate review-star markup scraped from AggregateRating schema and uptime/error-rate sampling used as a trust stand-in. A 4.8-star AggregateRating block confirms the markup exists; it does not confirm the underlying reviews are genuine.

No automated fetch can verify whether reviews are authentic, whether a transaction with the business would actually be safe, or whether user sentiment exists that was never captured as structured data. For a checklist of the trust elements covered here, see a practical checklist for the trust signals covered here.

The inference problem: a worked example

A commonly reported "author expertise score" (often shown as a single figure on a 1–10 scale) is usually constructed from three inputs: bio word count, a count of credential keywords ("PhD," "certified," "years of experience"), and the presence of an outbound LinkedIn link. None of those three inputs confirm the credential is true, current, or relevant to the content topic. The score is an inference stacked on proxies, reported with the precision of a measurement.

Compare two statements from the same fetch:

Statement Type What it actually confirms "Author schema present: yes" Fact JSON-LD parsed, Person object found "Expertise: 7/10" Judgment A weighted guess from proxies, no ground truth "Inbound links: 340 (GSC Links report)" Fact 340 links recorded in the index snapshot "Authoritativeness: high" Judgment A label applied to a link count, not a verified reputation

Units: score = 1–10 scale; links = count. Source: illustrative construction, not a specific vendor's output.

The more consequential failure mode: many tools quietly merge "unreachable" (the LinkedIn profile URL returned a 999 status or timed out) with "zero" (no credential keyword found in the bio) into the same low score. That is a measurement error, not a finding about the site. A site whose LinkedIn link is temporarily rate-limited by LinkedIn's own bot defenses should not score identically to a site with genuinely no professional profile linked. For more on how an estimate can misrepresent the underlying fetch, see why an estimated score can misrepresent what was actually measured.

A sound reporting format keeps the three states separate all the way to the output layer, rather than folding them into a composite number before the reader sees the raw fetch result. Public per-signal states, rather than a single opaque verdict, are the model behind public, GSC-verified proof pages: each signal is shown as present, absent, or unreachable before any composite score is derived.

Limitations

This catalog is not exhaustive. It covers the signals most commonly surfaced by automated E-E-A-T tooling, not every signal a crawler could conceivably fetch. The checkable/uncheckable boundary reflects public documentation and crawler behavior as of 2026-08; platforms change what their APIs expose, so a signal listed as unreachable today may become checkable later. The classifications describe what automated fetching can determine in general: this article is not a vendor-by-vendor benchmark, and no individual tool's output was tested for it. Finally, "checkable" means an automated fetch can return a definitive present/absent answer; it does not mean every tool implements the check correctly, and the worked example above shows how a correct fetch can still be reported misleadingly.

Summary: key takeaways

• Any automated eeat checker can only report present, absent, or unreachable per signal, never a fourth state of "true" or "false" about the underlying claim.
• Experience: byline, datePublished, and Person schema are checkable; whether the experience happened is not.
• Expertise: credential text strings and outbound profile links are checkable; whether the credential is current or accurate is not.
• Authoritativeness: inbound links via GSC's Links report and sameAs schema are checkable; community reputation is not.
• Trust: contact pages, privacy policy text, TLS status, and GSC's Manual Actions flag are checkable; review authenticity is not.
• Composite "expertise" or "authority" scores are inferences built on proxies; treat any single-number verdict as a judgment, not a fact, unless the underlying present/absent/unreachable data is shown alongside it.

FAQ

Can an E-E-A-T checker verify that an author's credentials are real?
No. It can confirm whether credential text strings or Person schema fields exist on the page, and whether an outbound link to a professional profile is present; it cannot confirm the credential is current, accurate, or held by the named person.

What does "unreachable" mean in an E-E-A-T audit?
It means the fetch failed (blocked by robots.txt, behind an auth wall, timed out, or dependent on JS rendering the crawler didn't execute), not that the signal is confirmed absent. Treating unreachable the same as absent produces a false negative.

Is a backlink count the same as authoritativeness?
No. A backlink count reported via an index or the GSC API is a correlation with authority, not a causal or definitive measure of it; a topical community's actual regard for a site is not captured in any link graph.

Why do two E-E-A-T tools give the same site different scores?
Because each tool weights proxies differently and handles the unreachable state differently. Some collapse it into "zero," others exclude it from the calculation, producing materially different composite numbers from the same underlying fetch.

Should I trust a single E-E-A-T score without seeing the underlying data?
No. Any published score should link to the rubric and show the per-signal present/absent/unreachable states it was built from; a number without that trail is a judgment presented as a measurement.