agentleFS
keuperakeupera/seo-skills/skills/eeat-author-pages/SKILL.md

eeat-author-pages

Skill0 starsChanged 2 months agoMITView on GitHub

Build the author, about and trust infrastructure that demonstrates experience, expertise, authoritativeness and trust on a site. Use whenever the user mentions E-E-A-T, EEAT, author pages, author bios, bylines, credentials, about pages, trust signals, YMYL content, medical or legal or financial content review, or asks why a site with good content isn't trusted or ranking. Also use when a site publishes anonymously, or when a core update has affected a content site.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If a site is publishing YMYL content with no credentialed involvement, say so plainly.

    line 114

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Author Pages and Trust Infrastructure

E-E-A-T isn't a ranking factor with a score attached. It's the framework Google's quality raters use to judge whether a page deserves to be trusted, and the systems are built to approximate those judgements. So the practical question isn't "how do I improve my E-E-A-T score". It's whether a stranger reading this page can tell who wrote it, why they'd know, and whether to believe them.

Most sites fail that test in the first two seconds, because the page has no byline.

The first E — experience — is the one added most recently and the one that separates content now. Not just knowing about the subject. Having done the thing.

The minimum viable trust layer

Ordered by effect per hour spent. Most sites are missing all five.

  1. A byline on every article, with a real name linking to a real author page.
  2. An author page per writer that establishes why they'd know.
  3. A substantial about page with the actual story, the actual people, the actual location.
  4. Contact information that reaches a human — an address, a phone number, a real email.
  5. Dates on everything, published and updated, honestly.

Anonymous content has to work much harder to be believed, and on any topic where being wrong costs the reader something, it mostly doesn't get believed at all.

The author page

A line saying "Jane is a content strategist passionate about marketing" establishes nothing. What does:

Photo             A real one. Same across every platform.
Name              Full name as used everywhere else.
Role              Current position and organisation.
Why they know     The specific basis: years doing it, what they've built,
                  what they've run, what they've measured. Concrete.
Credentials       Where genuinely relevant — degrees, licences, certifications.
                  Don't inflate them. Don't list irrelevant ones.
Experience        The first E. What they've actually done, not just studied.
Proof             Links to published work, talks, code, papers, patents,
                  the products they built.
Elsewhere         LinkedIn, X, GitHub, ORCID, personal site.
Contact           A way to reach them.
Their articles    The full list, so the page is a real hub.

The distinction that matters most:

Weak: "Jane is an experienced SEO professional who loves helping brands grow."

Strong: "Jane has run technical SEO for three ecommerce platforms, most recently a 40,000-product catalogue where she cut indexed URLs from 2.1 million to 180,000 over eight months. She writes here about crawl budget and faceted navigation."

The second is specific, checkable and tells a reader exactly when to trust her and when not to.

Author schema

Link the byline to the author page, and the author page to the person as an entity.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/authors/jane-doe#person",
  "name": "Jane Doe",
  "url": "https://example.com/authors/jane-doe",
  "image": "https://example.com/authors/jane-doe.jpg",
  "jobTitle": "Head of Technical SEO",
  "worksFor": { "@id": "https://example.com/#organization" },
  "knowsAbout": ["Technical SEO", "Crawl budget", "Faceted navigation"],
  "sameAs": [
    "https://www.linkedin.com/in/janedoe",
    "https://github.com/janedoe"
  ]
}

Then reference it from every article: "author": { "@id": "https://example.com/authors/jane-doe#person" }.

sameAs is the part that does the work. It's what connects the byline to a person who demonstrably exists elsewhere on the web. A Person block with no sameAs and no author page is an assertion with nothing behind it. See entity-brand-consistency.

Showing experience on the page itself

The author page establishes the credential. The article has to demonstrate it, and this is where most content fails regardless of who's credited.

  • First-hand specifics. "We ran this for six months and here's what broke" is unfalsifiable by a model with no access to that experience, which is precisely why it's valuable.
  • Original data, even small. Forty customer surveys beats another aggregation of the same public statistics.
  • Your own screenshots and photographs. Evidence you touched the thing.
  • Real numbers with the method attached. What was measured, over what period, on what sample.
  • What went wrong. The edge cases, the failure, the thing you'd do differently. Nobody writes this from general knowledge.
  • A position you'll defend. "Most advice says X; here's when X fails."
  • What you don't know, and where the advice stops applying.

The test worth applying to any draft: could a language model produce something equivalent from general knowledge alone, with no access to this person's experience? If yes, the byline is decorative.

Trust signals at site level

  • Editorial policy page — how content is produced, reviewed, corrected and updated.
  • Corrections policy, and visible corrections when things are wrong. Correcting publicly builds more trust than never being wrong.
  • Fact-checking and review process where the topic warrants it.
  • Funding and affiliate disclosure, stated where it's relevant rather than buried.
  • Real business identity — legal entity, registration number where applicable, physical address.
  • Sources cited and linked, preferring primary ones. Original research, official documentation, filings.
  • Dates that are honest. "Updated September 2026" only when it was.

YMYL topics

For health, finance, legal, safety and anything else where being wrong harms someone, the bar rises and this stops being optional.

  • Credentialed authors or credentialed reviewers, named, with verifiable qualifications.
  • A visible review line: "Medically reviewed by Dr. [Name], [credential], on [date]", linking to the reviewer's page.
  • Institutional sources cited — regulators, professional bodies, peer-reviewed research. Not a competitor's blog post.
  • No personalised advice. Explain generally, recommend seeing a qualified professional.
  • Review cycles, because guidance changes and stale medical or legal content is actively harmful.

If a site is publishing YMYL content with no credentialed involvement, say so plainly. It's the finding, and no amount of on-page optimisation substitutes for it.

Diagnosing a site hit by a core update

Core updates re-assess quality across the index. When a content site loses substantially, work through:

  1. Is there a byline? Is there an author page? Does the author demonstrably exist?
  2. Does the content show first-hand experience, or is it a synthesis of what already ranks?
  3. Is there anything on the site that isn't available elsewhere?
  4. Are there hundreds of thin pages dragging down the good ones? Site-level assessment means the weakest content affects everything.
  5. Is the business identity real and findable?
  6. Are claims sourced?

Recovery comes from the site being genuinely better, assessed over months, usually at the next core update. Anyone promising recovery in a fortnight is selling something, and saying so is more useful than agreeing.

Don't do these

  • Don't invent authors. Fabricated bylines with generated headshots are detectable, and when found the damage is to the whole site.
  • Don't inflate credentials. Checkable, and being caught is worse than having none.
  • Don't add an author page and change nothing else. The page establishes who; the content still has to demonstrate what they know.
  • Don't credit "Admin", "Editorial Team" or the brand name on opinion or experience-based content. Fine for factual reference material, weak everywhere else.
  • Don't buy a credentialed reviewer's name for content they didn't read. It's a real practice and it's a real liability.
  • Don't treat E-E-A-T as a checklist. It's a description of what trustworthy content looks like, not a set of tags to add.

Related skills

entity-brand-consistency, best-of-listicle-pages, comparison-alternatives-pages, schema-markup, content-refresh, local-seo

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.