Docket / Learn / Trust and authorship signals

Trust and authorship signals, and what a crawler can actually see

By Matt Kerr·Published

Google's guidance keeps returning to experience and trust, and a crawler can see neither. What a crawler can see is a much smaller thing: whether your site names a person, and whether the pages that say who you are exist at all. Docket's check for this is content.eeat, "Trust and authorship signals". This page is about the distance between those two sentences, because that distance is the whole answer.

The honest centre, before anything else

A byline is not expertise. Markup is not trust. Docket can see whether a page carries a word that looks like attribution, and whether your site has an About page, a Contact page and a privacy policy. It cannot assess whether the person named knows anything about the subject, whether the About page is true, or whether anybody answers the contact form. No automated tool can do those things, and a tool that implies it can is handing you a number it invented.

So read every finding from this check as a statement about signals rather than about standing. It says a reader arriving on your site has nothing to go on. Supplying something to go on is work only a person can do.

What it actually looks for

The check produces two findings, and they are less related than the name suggests. Most of it is about pages; a smaller and looser part is about authorship.

The three pages

Docket asks three existence questions and reports the ones that fail as a single finding, titled with the missing pages named:

Severity depends on which one is missing. A missing Contact page raises the finding to medium; a missing About page or privacy policy alone leaves it at low. That ordering is deliberate — a site nobody can reach has a bigger problem than a site whose ownership is vague.

The fix text is the check's own, and it is worth reading as written rather than paraphrased:

Add the missing pages with genuine detail — real names, a physical address if you have one, a phone number, and who is behind the business.

"Genuine detail" is doing the work in that sentence. An About page that says the company was founded on a passion for excellence is, as a trust signal, indistinguishable from no About page at all. The crawler cannot tell the difference. Every human reader can.

It asks whether the page exists, not whether it was crawled

This is the part most tools get wrong, and the reason is in the check's own comment. The question is asked against every internal path the crawl saw — links, raw hrefs and sitemap entries — rather than against the pages it fetched. A capped crawl of a large site reads a fraction of it, so asking "did we fetch a privacy policy?" reports a missing privacy policy on a site whose footer links to one from every page. That false positive is worse than a missed finding: it makes the whole report look careless to the one person who knows the site best.

The same finding is also marked as requiring a full crawl, which means it is dropped rather than published when the crawl itself was unreliable. A statement of the form "X is missing from the entire site" is only defensible if the site was actually seen.

The rule that a quote form is a contact page

The Contact half used to match three paths. Measured on a ground-truth fixture: a plumber's site whose enquiry page was /quote.html — a short "tell us what you need" form, linked from the homepage, the services page and the nav — was told at medium severity that no Contact page was found.

The path list is wider now, and more usefully, paths are no longer the only rule: a page carrying an enquiry form is a contact page whatever it is called. A plumber's "Request a callback" and a consultancy's "Work with us" are the same page under different signage. The form has to ask for more than a single field, because site search is the common one-field form and counting it would silence the check on nearly every site — which would be the worse bug of the two.

That was the third check in a single day with the same shape: it knew one form of the thing, and reported the absence of every other form as the absence of the thing. It is worth naming because it is the failure mode of every rule-based audit tool, including this one, and the only defence is measuring against sites that plainly have what they are accused of lacking.

The authorship half, and what it is really testing

The second finding, content.no_author, fires at low severity when a site has three or more pages carrying article markup and no author signal anywhere. An author signal is one of two things: the page's JSON-LD carries an author property naming somebody, or the body text carries a byline phrase — "written by", "posted by", "author:" and a couple of neighbours.

That is the corrected version, and the correction is worth the space. The markup test used to ask the wrong question, and it asked it of the exact snippet the finding itself prints as the remedy:

"author": {"@type": "Person", "name": "YOUR AUTHOR NAME",
           "url": "https://example.com/team/your-author"}

schema.org's author, read on 15 September 2026, is a property; its expected types are Person and Organization. There is no type called "author". The check was reading the list of @type values on a page and looking for "author" in it, so that snippet contributed Article and Person and never the thing being looked for. A site that did precisely what the report told it to do, re-ran the audit, and saw the same finding with the same remedy.

It stayed hidden because the prose half was a bare substring test for the word "author" across a blob joined from a capped sample of pages. A privacy policy offering to delete "content you authored" contains it. So does a cookie notice or a plugin credit. Any one of them silenced the finding sitewide, which is how a broken markup test went unnoticed: sites were being credited by an unrelated word rather than by an attribution.

Both halves now do what their names say. The markup test reads the author property out of your structured data, at any depth, and an empty one or a blank name does not count — the property being present is not the same as somebody being named. The prose test matches byline phrases rather than the word.

One limit survives the fix, and you should know it. A visible byline that reads simply "By Jane Smith", with no structured data behind it, still matches nothing: it is not one of the byline phrases and it is not markup. That is a narrower miss than the one above and it is deliberate — "by" alone appears in ordinary prose constantly — but if your attribution is a bare name under a headline, add the schema rather than expecting the sentence to be read.

What the count on that finding means

One more thing to know before treating the number beside content.no_author as a task list: the author signal is sitewide, so the count is every page carrying article markup, not the pages that lack an attribution. Nothing in the check identifies a specific unattributed page, because nothing in it looks at pages individually.

Its population is narrower than it sounds, too. "Article pages" here means pages declaring article-family schema and nothing else. A blog with no structured data at all is never asked the question by this check.

What Google publishes about this, in its own words

The panic around E-E-A-T is considerably larger than what Google actually documents, and the documentation is short enough to read. From Google's guidance on creating helpful, reliable, people-first content, read on 15 September 2026:

While E-E-A-T itself isn't a specific ranking factor, using a mix of factors that can identify content with good E-E-A-T is useful.

Search raters have no control over how pages rank. Rater data is not used directly in our ranking algorithms.

So E-E-A-T is a description of what human raters assess when they sanity-check a change to the algorithm. It is not a dial, not a score your page carries, and not something any third-party tool can measure on your behalf. Anyone selling you an E-E-A-T score is selling you their own opinion with a number written on it.

The same page is much more concrete about attribution, and this part is mechanically useful:

Is it self-evident to your visitors who authored your content? … Do pages carry a byline, where one might be expected? Do bylines lead to further information about the author or authors involved, giving background about them and the areas they write about?

Note what those questions are addressed to: your visitors. A byline that leads to a page about the person is useful because a reader can follow it. The markup matters after that, not instead of it.

Google also says, of experience, expertise, authoritativeness and trust, that "of these aspects, trust is most important". Docket's own finding puts the case for trust pages more strongly than that source does — it describes their absence as a negative for any site that transacts, which is a reading of the rater guidelines rather than of the page quoted here. The narrower published wording is the one to act on, and it is the one linked above.

Naming a person is not the same as resolving one

content.eeat does not read sameAs, and nothing in it connects an author's name to an identity anywhere else. Docket does check sameAs, in a separate check in the AI visibility lane, but that one reads the organisation's node — it asks whether the business resolves to something a model already knows about, not whether your writer does. Neither check resolves a named author to a real identity, which is the honest position: what sameAs does and who should declare it is a different question from whether your articles carry a byline.

What to do with a finding from this check

The trust-pages half is genuinely worth clearing, and it is an afternoon's work. Add the three pages. Put real information on them — the name of the person who answers the phone, an address if you have one, what the company actually is. If your enquiry page is called something other than Contact, that is fine and Docket will recognise it, but a visitor searching your nav for the word might not.

The authorship half deserves the weight its severity gives it, which is not much. Do the thing Google's questions describe rather than the thing the check can detect: a byline on articles where a reader would expect one, leading to a page that says who the person is and what they know. Add the schema alongside it, because it is one property and it costs nothing. Just do not expect the markup on its own to change what this particular check reports.

Every check Docket runs, with the reasoning behind each one, is listed on what Docket checks.

How much to trust this finding

The trust-pages half is the reliable one: it asks a question with a factual answer, it asks it against discovered paths rather than crawled ones, and it stands down entirely when the crawl was too thin to support the claim. A finding from it is nearly always real.

The authorship half is a heuristic with a known gap in both directions, described above in detail because a reader deciding whether to act on it needs to know which direction their own site falls in. A clean result there is not evidence that your content is attributed. A finding there is not evidence that it is not.

Download Docket

Common questions

Can a tool measure E-E-A-T?

No. Google's own documentation says E-E-A-T is not a specific ranking factor, and that the human raters who assess it have no control over how pages rank and their data is not used directly in the ranking algorithms. What a tool can measure is a handful of signals that tend to travel with it — whether an About page exists, whether there is a way to make contact, whether a page names an author. Anything presented as an E-E-A-T score is an opinion with a number written on it.

What does Docket's trust and authorship check actually look at?

Two things. Whether your site has an About page, a way to get in touch and a privacy policy, judged against every internal path the crawl saw rather than only the pages it fetched. And whether any author signal appears anywhere on the site, for sites carrying article markup.

My contact page is not called Contact. Will Docket report it as missing?

It should not. The check matches a wide list of paths — quote, enquire, book, appointment, work with us, support and others — and separately counts any page carrying a form that asks for more than a single field as a way to make contact, whatever the path is called. That rule exists because the earlier version told a plumbing firm it had no contact page while its quote form was linked from every page on the site.

Why does a single-field form not count?

Because site search is the common single-field form, and counting it would silence the check on nearly every site. A check that never fires is worse than one that occasionally asks for a page you already have under another name.

Docket says my articles have no visible author, but they have bylines. Why?

Because the author test is narrow. It matches a JSON-LD type whose name contains the word author, or the words 'written by' or 'author' in the body text. A byline reading 'By Jane Smith' matches none of those, and correct schema markup contributes the type Person rather than author, since author is a schema.org property and not a type. Your bylines are fine. The check is reading for something narrower than a byline.

Does adding an author help anything other than this check?

Google's guidance asks whether it is self-evident to your visitors who authored your content, whether pages carry a byline where one would be expected, and whether bylines lead to further information about the author. Those questions are addressed to readers, not crawlers. A byline that leads to a page saying who the person is and what they know is the thing worth having; the markup is worth adding afterwards because it is one property and costs nothing.

Is a missing privacy policy as serious as a missing contact page?

Docket does not treat it that way. A missing contact page raises the finding to medium severity; a missing About page or privacy policy on its own leaves it at low. A site nobody can reach has the bigger problem.