Author Page Examples SEO: What an Automated E-E-A-T Check Verifies

What we found

On 2026-08-25, we tested three TrustGrowth URLs with HTTP GET requests. /about returned 200; /authors returned 404; and /authors/ravi-yadav returned 404. On the successful /about response, the Person JSON-LD node contained name and url. We observed no jobTitle, description, or sameAs fields on that node. We repeated the three requests on 2026-10-06 and got the same status codes. On that date the Person node contained name, url, and mainEntityOfPage, and still no jobTitle, description, or sameAs.

This is a dated test of three URLs, not a census of trustgrowth.ai. It reports current-state fetch and markup observations. It does not report ranking, traffic, or conversion outcomes.

The result illustrates two separate author-page problems: a page can be readable to a person while exposing few usable fields to a checker, and a page can be unavailable before a checker evaluates any fields. This article shows how to keep those findings separate.

What “passing” means: reads well vs. verifies well

An author page can satisfy a human reader without satisfying a field-level inspection.

A visitor might read: “Jane Lee has eight years of technical SEO experience.” That sentence may communicate useful context to a person. Unless the relevant information is also available in fields a checker parses, the scanner may record only the structured values it can retrieve. The visible sentence and the machine-readable field are not automatically equivalent.

The second failure mode is reachability. If the intended author URL returns 404, times out, is blocked by robots.txt, or is marked noindex, the checker may never reach the page’s Person data. RFC 9110 distinguishes a successful representation, such as 200, from a missing resource, such as 404.

This is a current-state explainer of what an automated E-E-A-T check can inspect. E-E-A-T means Experience, Expertise, Authoritativeness, and Trustworthiness. A checker can record fields and access conditions; it cannot establish from markup alone that an experience claim is true or that a page will rank, attract traffic, or convert visitors. For the boundary between quantifiable fields and human judgment, read How to measure an E-E-A-T score: what you can quantify vs. what still requires human judgment.

The seven fields an automated expertise check looks for

The seven field groups below cover the concrete author-page information discussed in this article. Experience is treated as part of the description or bio field rather than as a separate schema property. Byline association is included because an author page is useful only when a checker can connect it to an article.

Table: Seven field groups and illustrative Jane Lee values. The examples are not observations of the TrustGrowth URLs; the observed results are listed separately above and below.

The gap between copy and markup matters because a scanner does not interpret a page exactly as a person does. A role can be present in prose but absent from jobTitle. A detailed bio can be visible but absent from description. A social profile can be linked from the page but absent from sameAs. A checker may therefore report a missing signal even when the page feels complete to a reader.

A generic implementation example might look like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Example author name",
  "url": "https://example.com/authors/example-author",
  "jobTitle": "Example role",
  "description": "Example first-person or verifiable experience statement.",
  "sameAs": [
    "https://example.com/external-profile"
  ]
}
</script>

These are implementation examples, not claims about the live /about page. The 2026-08-25 observation was narrower: its Person node had name and url, with no observed jobTitle, description, or sameAs fields.

How a checker finds the page: crawl path and internal linking

A checker may follow this discovery chain:

1. An article contains a byline.
2. The byline contains an anchor with an href.
3. The href points to an author-page URL.
4. The author URL appears in a sitemap, where one exists.
5. robots.txt does not disallow the URL.
6. The fetch returns a response the checker can inspect.

A working byline link looks like this:

<a href="/authors/jane-lee" rel="author">Jane Lee</a>

A plain-text byline does not provide the same traversal path:

<span class="byline">Jane Lee</span>

On the TrustGrowth sibling article, the byline is Person microdata with a name span and no href or rel="author". The article JSON-LD sets author.url to https://trustgrowth.ai/about. Those are separate observations: the structured article data identifies a URL, while the visible byline does not provide an anchor for a crawler to follow.

Sitemap inclusion gives a checker another possible discovery route. Internal link count and anchor patterns can also be recorded: how many article pages point to the author URL, and whether those links consistently use the same destination. These are discoverability observations. They do not prove authoritativeness or a search outcome.

Use the GSC audit playbook to check whether a URL appears in the coverage or index data available to you. That evidence is separate from the HTML fields parsed from the author page.

Missing signal, measured zero, and unreachable fetch

Keep these three findings distinct:

Table: Three different findings in the current-state audit model, last measured 2026-10-06.

A missing jobTitle and an empty jobTitle are not the same implementation state. In the first case, the property is not present. In the second, the property is present but contains no content. A 404 is different again: the checker has not reached a document on which it can assess jobTitle.

The TrustGrowth observations show this distinction. /about returned 200 on 2026-08-21, 2026-08-23, 2026-08-25, and 2026-10-06. The /about Person node exposed name and url, while jobTitle, description, and sameAs were not observed. Both /authors and /authors/ravi-yadav returned 404 on those four dates. The latter result is an unreachable or missing-resource finding, not evidence that the fields on those pages were empty.

For a concrete unreachable author-page example, suppose /authors/jane-lee is absent from the sitemap, has no inbound byline link, and contains a noindex tag. Even if its HTML includes a complete Person block, the audit should report the discovery and access conditions separately. It should not collapse every condition into one generic “failed” label.

Self-testing your author page like a scanner would

Run the following sequence against one author URL and one article that uses that author.

1. Fetch the URL directly

Use view-source or an HTTP fetch. Record the status code. 200 indicates a successful representation; 404 indicates a missing resource under RFC 9110. Record redirects instead of assuming the final URL is the intended author URL.

2. Inspect the Person block

Search the returned HTML for application/ld+json and inspect whether "@type": "Person" is present. Record the literal values for name, jobTitle, description, sameAs, and url. TrustGrowth’s schema check tool can be used for a bounded structured-data check. For fetch and render behavior, use the How AI Sees Your Site tool. For a fast field scan, use the E-E-A-T quick check.

3. Inspect the article byline

Confirm that the byline is an <a> element with an href pointing to the intended author URL. Then inspect the article’s structured data for an author reference. A visible name alone is not the same as a linked article association.

4. Check discovery controls

Search the sitemap for the author URL. Check robots.txt for a matching disallow. Check the page head for noindex. If fetch and render behavior differ, record that difference rather than treating the rendered page as identical to the raw response.

For implementation detail, read How to add author schema markup to every page of your SaaS site. For broader context, see AI trust signals for SaaS.

A 16-item field-level checklist

Record each item as present, missing, zero, or unreachable. This keeps the checklist count consistent with the seven field groups: access and discovery conditions are listed separately, while bio and experience remain one field group.

• The intended author URL returns 200.
• The page is not blocked by robots.txt.
• The page does not carry a noindex directive.
• The URL appears in the sitemap.
• A Person JSON-LD node is present in the fetched HTML.
• The Person node contains a non-empty name string.
• The Person node contains a jobTitle string.
• The Person node contains a populated description.
• The description contains a first-person or verifiable experience statement where appropriate.
• The sameAs value is an array containing external profile URLs.
• The Person node has a fetchable url.
• The article byline has an href to the author URL.
• The article’s author property references the same Person URL.
• Internal links use a consistent author-page destination and anchor pattern.
• The report distinguishes absent, empty, and unreachable values.
• The report records the response date and tested URL.

This checklist describes what a check inspects. It is not a guarantee of ranking, traffic, conversion, or another outcome. Any first-party TrustGrowth figures referenced elsewhere on the site carry their own source and collection date.

The TrustGrowth audit scoring feature is where the site describes scoring 27 E-E-A-T signals in aggregate. That aggregate count is broader than the seven author-page field groups and the 16-item operational checklist used here.

Method and limits

We used HTTP GET requests with curl, without JavaScript execution, on 2026-08-21, 2026-08-23, 2026-08-25, and 2026-10-06. The tested URLs were /about, /authors, and /authors/ravi-yadav. /about returned 200 on each date. /authors and /authors/ravi-yadav returned 404 on each date. We inspected the /about HTML for JSON-LD and the sibling article for its byline markup and article JSON-LD. On 2026-10-06 the sibling byline was still Person microdata with no href, and the article JSON-LD still set author.url to /about.

The first limitation is scope: three URLs over four dates are first-party field observations, not a census or trend. The second is tooling: a curl fetch does not execute JavaScript, so client-side structured data could appear missing under this method. /authors and /authors/ravi-yadav are recorded from dated HTTP GETs of three TrustGrowth URLs as missing resources, not as live pages to follow. We also did not retain a public archived HTML snapshot; the live URLs are the artifacts.

Last measured: 2026-10-06. Dataset: dated HTTP GETs of three TrustGrowth URLs (/about, /authors, /authors/ravi-yadav), plus the sibling article’s byline HTML and article JSON-LD. Next re-run: not scheduled.