AI Trust Signals Audit: The Signals That Fail Verification, and How to Fix Them

Last reviewed: 2026-07-27 (UTC) · Author: TrustGrowth Team

What this article is

This is a catalogue of the ways trust signals fail machine verification while still looking correct to a human, plus the exact check and re-verification step for each. It is a method, not an audit report — there is no "we checked N categories and found defects in M" finding to quote.

One check in this list we did run against our own site, and we report it below with its date and result, including the part we fail. Every other section describes how to run the check and what a pass actually proves. For a worked end-to-end example of the full discipline, see a real detect-fix-reverify run on our own site.

Why most 'AI trust signal' checklists skip the hard part

Dozens of published lists tell you which signals matter — author bio, schema markup, HTTPS, reviews — but almost none show how those signals are actually verified by a crawler, Google's Rich Results Test, or a live user-agent request, versus how they merely appear to a human skimming the page. A signal that renders correctly in Chrome DevTools can still 404 for GPTBot, fail structured-data parsing, or point to a reviewer page that was never linked from anywhere. This article is built from that gap: not '19 signals to add,' but which signals fail verification even when they look present.

What 'verified' means in an AI trust signals audit

A signal counts as verified only if it satisfies three conditions: (1) it resolves correctly in structured-data testing, (2) it is fetchable by the exact crawler or user-agent it claims to serve, and (3) it is timestamped and traceable to a source a human or model can independently check without additional context. A signal that meets none, one, or two of these is not verified — it is merely present: code that exists in the DOM but fails at least one of the three checks.

This distinction matters because most on-page audits stop at "present." For the underlying framework behind why these three conditions map to E-E-A-T, see how Google's quality guidelines define these signals.

Failure modes, ordered by how cheap they are to verify

The order below runs from cheapest check (a single request, free tool, under 60 seconds) to most expensive (multi-source cross-referencing). This is a catalogue, not a top-N ranked list, and the costs are approximate manual effort for a single domain.

Failure mode Verification method Cost to check What a pass establishes AI crawler blocked curl -A "<bot>" against robots.txt and a live URL Seconds, 1 request per agent The file and page were served to that agent on that date — reachability only llms.txt absent Fetch /llms.txt Seconds, 1 request The file exists; it does not establish that any assistant reads it Schema inconsistent across templates Rich Results Test per template type ~2 min per URL That template's markup parses; says nothing about other templates Author schema invalid Rich Results Test per author URL ~2 min per URL The Person item validates and its links resolve Timestamp mismatch Sitemap lastmod vs. on-page date diff ~5 min, manual The stated date matches the recorded last modification Orphaned bio page site: search + sitemap + byline link check ~5 min The page is reachable in one click and present in the sitemap Unsourced proof claim Manual click-path check per claim ~1 min per claim A link, a date, and a method sit within one click of the number Missing reviewer artifact Manual search for name, credential, date ~3 min A named reviewer, a credential, and a review date all exist publicly

Units: "cost to check" is approximate manual operator effort per check for a single domain on a single date, measured in minutes and HTTP requests; it is not a benchmark across sites. Source: TrustGrowth's own operator procedure for each check as described in the sections below. The one measured first-party result in this table (AI crawler blocked / llms.txt absent) was run against trustgrowth.ai on 2026-07-27 (UTC) using the curl procedure shown below; all other rows describe method only and carry no first-party finding.

AI crawler access blocked for the exact bots the site claims to court

The defect to check for: robots.txt or a firewall rule blocking GPTBot, Google-Extended, or PerplexityBot while marketing copy claims "AI-visible content" — directly checkable in one request. Run:

curl -A "GPTBot" https://example.com/robots.txt
curl -A "Google-Extended" https://example.com/robots.txt
curl -A "PerplexityBot" https://example.com/robots.txt

Then fetch a live content URL with the same header to confirm the page itself doesn't return 403 to the same agent — a robots.txt allow rule and a live firewall block frequently disagree.

This is the one check in this article we ran against our own site. On trustgrowth.ai, 2026-07-27 (UTC): GPTBot, Google-Extended, PerplexityBot, ClaudeBot, and CCBot each received 200 on both robots.txt and a live article URL — no defect found. One defect did surface on the adjacent check: /llms.txt returns 404. We do not currently publish that file, and our own scorer penalises us for it by exactly 3 points, described below. That is the complete set of first-party findings in this piece.

Source for the two figures above: a first-party run of the curl procedure in this section against trustgrowth.ai on 2026-07-27 (UTC) — five user-agents against https://trustgrowth.ai/robots.txt and a live article URL, plus a single fetch of https://trustgrowth.ai/llms.txt. Anyone can re-run it with the commands shown and should expect a different result if our robots.txt or CDN configuration changes. Our current score and its refresh date are published on our proof page.

How we automated this check. We shipped this measurement into the product on 2026-07-25, and the design decisions are worth stating because they are where this kind of check usually goes wrong:

• The probe tests 10 tracked AI user-agents — GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, CCBot, Bytespider, Amazonbot, Meta-ExternalAgent. robots.txt and llms.txt are each fetched once, then every one of the 10 agents gets its own live fetch of the site using its own user-agent string: 12 HTTP requests in total. It runs no model inference — it is a deterministic HTTP probe, not a generated assessment.
• The per-agent live fetch is the point. Permission and reachability are different questions: a CDN or WAF can block a bot that robots.txt explicitly welcomes, and checking only the rules file would report that bot as allowed.
• The parsing trap is grouped user-agent lines. A robots.txt that reads User-agent: GPTBot / User-agent: CCBot / Disallow: / applies that disallow to both agents. A parser that tracks only the last-seen agent name reports GPTBot as allowed when it is actually blocked, so consecutive User-agent: lines have to be collected into one rule block before any directive is read.
• Only 200 and 404 are usable answers. 200 means "here are the rules"; 404 means there are none, so nothing is disallowed. A 403, timeout, 5xx, or WAF interstitial that merely looks like a robots.txt is an absence of information — RFC 9309 §2.3.1.4 is explicit that a 5xx must not be read as permission. The failure mode is subtle: all of those return a body that parses to an empty rule set, which reads back as allow-all.
• A failed measurement never renders as a measured zero. When robots.txt cannot be read, the reachability gate is skipped entirely and records a reason code rather than scoring the site as unreachable. Per-agent results are three-valued — allowed, blocked, or partial — and partial (a failed live fetch, such as a transient 503) is treated as an issue, not a permission decision, so it never caps the score.
• The score treats reach as a ceiling, not an averaged component: the GEO score is capped at the measured reachable proportion, so being reachable by 5 of 10 tracked agents caps that pillar at 50 rather than being averaged away against unrelated strengths.
• Missing llms.txt is a flat 3-point deduction, not a fifth scoring group (source: TrustGrowth's GEO scoring implementation, shipped 2026-07-25; the deduction and the reachability ceiling below are fixed constants in that scorer, not estimates). An optional, barely-adopted convention should not command 20% of the GEO pillar — which is exactly why our own 404 above costs us 3 points rather than a fifth of the score.

What this check does and does not establish. It measures reachability, not citation. A 200 for GPTBot means the file and page were served to that agent on that date. It does not mean any assistant read the page, retrieved it, or will cite it, and we make no claim that improving reachability improves how often a site appears in any assistant's answers — we have not measured that link and we are not aware of anyone who has. Reachability is a precondition you can verify cheaply; treat it as a floor to clear, not an outcome to bank.

Structured data present on some templates, missing on others

The defect: Organization or Article schema present on blog posts but absent on solution or pricing page templates. Verification requires running the Rich Results Test against one URL per template type — home, blog post, solution page, pricing page — and comparing pass/fail, not assuming template parity from one sample. Schema is usually added to the template a team ships most often, so the pricing or solution templates are where it silently never landed.

Author schema present in markup, invalid in Rich Results

The defect: Person schema exists syntactically, but sameAs links 404 or jobTitle/url fields are empty strings — a JSON-LD linter will pass on syntax alone while Google's Rich Results Test flags "items detected, issues found." Run every author URL through the Rich Results Test individually; a linter checking syntax is not a substitute, because a sameAs value can be perfectly valid JSON pointing at a dead profile. See the step-by-step author schema fix for the field-by-field procedure.

Timestamps that don't match last-modified reality

The defect: a "last updated" date on a trust or about page predates the actual last content change recorded in the sitemap's lastmod field or version history. Pull lastmod from the XML sitemap and diff it against the on-page date; if no version history exists, cross-check the Wayback Machine's capture history instead. Treat a gap of more than a day as a finding to explain, not an automatic defect — pipelines legitimately stamp the two at different moments.

Orphaned or unlinked author bio pages

The defect: a bio page exists but isn't linked from the article byline or included in the sitemap, so neither crawlers nor readers reach it in fewer than two clicks. Run a site: search for the bio URL and confirm it appears both in the XML sitemap and in at least one byline link.

Proof claims with no traceable source

The defect: a number like "3x organic growth" or a score claim appears with no linked source, date, or stated method within one click. For every quantified claim, confirm a link, a date, and a stated method sit within one click of the number — missing any one fails verification regardless of whether the underlying number is accurate. TrustGrowth applies this standard to its own proof page, which links its score, method, and refresh date directly.

E-E-A-T claims without a corresponding public proof artifact

The defect: an "expert-reviewed" badge or similar claim with no reviewer name, credential, or review date attached anywhere on or linked from the page. Search the page and any linked reviewer page for a name, a credential, and a date; absence of any one fails the check.

Correlation vs. causation — what fixing these signals does and doesn't prove

Fixing a failing signal changes what a verification tool reports, and that is the entire measured effect. Moving a Rich Results Test result from "issues found" to "valid item detected" is a change in tool output, not a demonstrated ranking or traffic change, and this article does not claim otherwise. Any such change would require a separate, dated before/after comparison using the searchanalytics.query endpoint in Search Console, filtered to the affected URLs across a defined date range. If you have not run that, the honest statement is that you fixed a verification failure — not that you improved performance.

The fix-and-reverify sequence

The loop is the same regardless of which signal failed: (1) run the check, (2) log the specific failure mode and the exact tool or method used to find it, (3) apply the fix, (4) re-run the identical check, (5) timestamp the pass. Skipping step 4 or 5 turns a fix into an unverified claim.

1. Run the check with a public or built-in method — Rich Results Test, curl with a named user-agent header, the live XML sitemap, or the Wayback Machine.
2. Record the failure mode in plain language ("sameAs 404", "schema absent on template X") with the tool name and timestamp.
3. Apply the minimal fix that addresses the specific failure, not a broader rewrite.
4. Re-run the identical check against the identical URL.
5. Timestamp the pass in ISO 8601 format with timezone (e.g., 2026-07-27 UTC).

A fix without a re-run and a timestamp is an unverified claim, not a completed fix — the same standard this article applies to itself, which is why only one section above carries a first-party finding.

What this kind of audit still can't verify

Mechanical checks confirm a signal is technically present and machine-readable; they cannot confirm a human reader finds an author credible, or that a case study's reported outcome is accurate. That gap requires editorial or human judgment, not another crawl. For the fuller breakdown of which E-E-A-T components are quantifiable versus which stay judgment-based, see what you can quantify vs. what still needs human judgment.

What to build vs. what to verify

This piece diagnoses what's broken and how to re-verify a fix. It is not a build checklist, and it does not re-answer which signals to add in the first place. If you're starting from zero, use the trust signals checklist for what to build instead — this article picks up after those signals already exist.

Limitations

The failure modes listed are the ones checkable with the tools named. The list is not exhaustive, and nothing here supports a claim about how frequently any of them occur elsewhere — we have not measured frequency and do not report it.

The single first-party measurement above is one domain, one date, one check: AI crawler reachability on trustgrowth.ai on 2026-07-27 (UTC). A robots.txt or CDN change can invalidate it the next day, and it speaks only to reachability. Two catalogued checks — the Rich Results Test and Wayback cross-referencing — depend on third-party surfaces we do not control.

FAQ

What is an AI trust signals audit?
An AI trust signals audit checks whether trust-related signals — schema markup, author attribution, timestamps, AI crawler access, sourced proof claims — pass machine verification (structured-data testing, live fetch by the claimed user-agent, traceable timestamps), not just whether they appear correct to a human viewing the page.

How is 'verified' different from 'present' in this context?
A signal is present if the code exists in the DOM. A signal is verified only if it also resolves in a structured-data test, is fetchable by the exact bot it claims to serve, and is timestamped to a checkable source — a signal can be present and fail all three verification conditions simultaneously.

Which AI crawlers should a site check access for?
At minimum, check GPTBot (OpenAI), Google-Extended (Google's AI training/grounding control), and PerplexityBot (Perplexity), using curl -A "<bot-name>" https://yourdomain.com/robots.txt per agent, then confirming a live content URL doesn't 403 the same agent.

Does fixing a failed trust signal improve search rankings?
Fixing a signal changes what a verification tool reports on re-run; it does not, by itself, demonstrate a ranking or traffic change. Measuring that requires a separate before/after comparison using Search Console's searchanalytics.query data over a defined date range.

Can a schema linter replace the Rich Results Test?
No. A JSON-LD linter checks syntax validity and will pass markup that Google's Rich Results Test flags as "items detected, issues found" — for example, valid JSON with a sameAs field pointing to a 404. Use the Rich Results Test per URL for verification, not a linter alone.

Method note

This article is a methodology catalogue. The verification methods described are public tools — Google's Rich Results Test, curl with named user-agent headers, the live XML sitemap, and the Wayback Machine — and the stated costs are approximate manual effort for a single domain.

It contains exactly one first-party measurement: AI crawler reachability against trustgrowth.ai, run 2026-07-27 (UTC), reported above with its result and its one defect. The product behaviour described alongside it reflects the implementation shipped 2026-07-25. No other section reports a finding about our own site or any other. The score and method behind our own audit are documented on trustgrowth.ai's proof page.

Key takeaways

• Verified means three conditions met at once: passes structured-data testing, fetchable by the claimed user-agent, and timestamped to a checkable source. Present means the code exists but fails at least one.
• Checking the rules file is not checking reachability. robots.txt can welcome a bot that a CDN or WAF then blocks, so the permission check and a live per-agent fetch are two different tests.
• An unreadable robots.txt is missing information, not permission. A 403, timeout or 5xx parses to an empty rule set that reads back as allow-all — treating that as a pass invents evidence.
• Fixing a signal changes verification-tool output and nothing more. A ranking or traffic claim needs a separate dated Search Console comparison.
• The fix-and-reverify loop has five steps: run, log, fix, re-run, timestamp. Skipping the last two turns a fix into an unverified claim.
• Mechanical audits cannot verify human-perceived credibility or the factual accuracy of a case study outcome — that remains editorial judgment.

#ai-trust-signals #eeat #structured-data