E-E-A-T: Google's quality framework explained

Originally published at thatdevpro.com. Part of ThatDevPro's open SEO + AI framework library. ThatDevPro is an SDVOSB-certified veteran-owned web + AI engineering studio. Open-source AI citation toolkit: github.com/Janady13/aio-surfaces.

Experience · Expertise · Authoritativeness · Trustworthiness

A comprehensive installation and audit reference for implementing Google's E-E-A-T framework on any website to a world-class standard. This document is dual-purpose: it serves as both an installation manual (for Claude Code CLI or a human developer building the framework into a site) and an audit document (for evaluating an existing site against the framework with pass/fail scoring).

Cross-stack implementation note: the code samples in this framework are written in plain HTML for clarity. For React, Vue, Svelte, Next.js, Nuxt, SvelteKit, Astro, Hugo, 11ty, Remix, WordPress, Shopify, and Webflow equivalents of every pattern below, see framework-cross-stack-implementation.md. For pure client-rendered SPAs (no SSR/SSG) see framework-react.md. For Tailwind-specific concerns (purge, dynamic classes, dark-mode CLS, focus accessibility) see framework-tailwind.md.

1. Document Purpose & How to Use This Document

1.1 What This Document Is

This is the canonical reference for installing E-E-A-T signals across a website to a level Google's algorithms and human Search Quality Raters will recognize as world-class. Every signal Google looks for is documented here. Every code block needed to demonstrate that signal is included. Every validation criterion is specified.

1.2 Three Operating Modes

This document supports three modes of use. Choose the mode before starting work.

Mode A — Install Mode: Building E-E-A-T into a new or existing site from scratch. Follow Sections 2 → 17 in order. Each section is a buildable phase. Generate the implementation report at the end (Section 17).

Mode B — Audit Mode: Evaluating an existing site against the framework. Skip directly to Section 12 (Audit Mode). Use the scoring rubric to score each pillar. Generate the audit report at the end. Then if remediation is needed, return to Install Mode for the failing items.

Mode C — Hybrid Mode: Auditing then installing. Run Mode B first to baseline the site. Then run Mode A only for the items that scored below threshold. Generate both reports.

1.3 How Claude Code CLI Should Consume This Document

When this document is provided to Claude Code CLI:

1. Read Section 2 first — collect all client variables. Do not begin any installation work until the variables intake is complete.
2. Detect existing state — before installing any new schema, code, or page, check whether equivalent already exists. Use the conflict resolution rules (Section 1.5) to decide whether to skip, merge, or replace.
3. Follow phases in order — site-wide infrastructure (Section 5) before per-page work (Section 6). Per-author infrastructure (Section 7) before per-content-type work (Section 8).
4. Validate after each phase — run the validation protocol (Section 11) at the end of each major phase, not only at the end.
5. Generate the report — at completion, generate the structured implementation or audit report (Section 17).

1.4 How a Human Developer Should Consume This Document

If reading as a human:

1. Read Section 3 (What E-E-A-T Is) to understand the framework.
2. Read Section 4 (The Four Pillars) to understand what signals each pillar requires.
3. Use Section 2 as your client intake form — fill it in for the project.
4. Use Sections 5-9 as your build checklist, working through phases in order.
5. Use Section 11 to validate. Use Section 12 if auditing instead.
6. Use Section 16 (Code Library) as a quick reference appendix during build.

1.5 Conflict Resolution Rules

When installing into an existing site, conflicts will arise (existing schema, existing author pages, existing canonical tags). Apply these rules in priority order:

When in doubt, flag for manual review rather than overwriting. The implementation report (Section 17) must list every flagged item.

1.6 Required Tools & Validators

Have these available before starting:

• Google Rich Results Test — https://search.google.com/test/rich-results
• Schema.org Validator — https://validator.schema.org/
• PageSpeed Insights — https://pagespeed.web.dev/
• Google Search Console — must have site verified
• Whitespark / BrightLocal / Moz Local — for citation consistency audit (Authoritativeness pillar)
• Wayback Machine — for historical content audit
• Originality.ai or similar — for AI content disclosure validation
• A modern browser with DevTools — for manual rendering and accessibility checks
• curl or httpie — for header inspection and bot user-agent simulation

2. Client Variables Intake

Before beginning any installation or audit, gather every variable below. Do not proceed until the intake is complete. Variables marked REQUIRED block all work. Variables marked RECOMMENDED block specific sections only.

# ============================================
# E-E-A-T FRAMEWORK CLIENT VARIABLES
# ============================================

# --- Business Identity (REQUIRED) ---
business_name: ""                    # Exact legal/branded name. Used in all schema name fields.
business_alternate_names: []         # Common abbreviations, alternate spellings, DBA names.
business_type: ""                    # Schema.org type. Examples: "ProfessionalService",
                                     # "LocalBusiness", "MedicalBusiness", "FinancialService",
                                     # "LegalService", "Restaurant", "Store", "Organization".
business_subtype: ""                 # More specific subtype if applicable. Example: "WebDesignAgency".
business_founded_year: ""            # Four-digit year. Example: "2020".
business_description_short: ""       # 50-160 characters. Used in meta descriptions, schema description.
business_description_long: ""        # 300-500 words. Used on About page, /entity/ hub, llms.txt.

# --- Contact & Location (REQUIRED) ---
business_address_street: ""
business_address_city: ""
business_address_region: ""          # State/province/region (full name, not abbreviation in schema).
business_address_postal: ""
business_address_country: "US"       # ISO 3166-1 alpha-2 code.
business_geo_latitude: ""            # Decimal degrees. Example: "36.6770".
business_geo_longitude: ""           # Decimal degrees. Example: "-93.8730".
business_phone: ""                   # E.164 format. Example: "+15055123662".
business_phone_display: ""           # Human-readable. Example: "(505) 512-3662".
business_email: ""

# --- Hours of Operation (REQUIRED for LocalBusiness types) ---
business_hours:
  monday: "09:00-18:00"
  tuesday: "09:00-18:00"
  wednesday: "09:00-18:00"
  thursday: "09:00-18:00"
  friday: "09:00-18:00"
  saturday: "closed"
  sunday: "closed"
business_timezone: ""                # IANA timezone. Example: "America/Chicago".

# --- Web Properties (REQUIRED) ---
primary_domain: ""                   # Example: "thatdeveloperguy.com" (no protocol, no trailing slash).
canonical_protocol: "https"
canonical_www: false                 # true if canonical includes www, false if not.
canonical_trailing_slash: true       # Site-wide trailing slash policy.

# --- Founder/Owner Identity (REQUIRED for E-E-A-T) ---
founder_full_name: ""
founder_first_name: ""
founder_last_name: ""
founder_title: ""                    # Example: "Founder & Lead Developer".
founder_bio_short: ""                # 50-100 words. Used in author boxes.
founder_bio_long: ""                 # 200-400 words. Used on author page.
founder_photo_url: ""                # High-resolution professional photo, square crop preferred.
founder_email: ""

# --- Founder Credentials (REQUIRED for Expertise pillar) ---
founder_credentials:
  - type: "EducationalOccupationalCredential"
    name: ""                         # Example: "BA Computer Engineering".
    issued_by: ""                    # Example: "Colorado State University".
    year: ""
  - type: "EducationalOccupationalCredential"
    name: ""
    issued_by: ""
    year: ""
founder_certifications: []           # Industry certifications, licenses, accreditations.
founder_years_experience: ""         # Numeric. Example: "12".
founder_topical_expertise: []        # Array of topic strings. Example: ["Web Development", "SEO", "AI"].
founder_external_publications: []    # Array of URLs to articles authored on third-party sites.
founder_speaking_history: []         # Array of conference/podcast appearances with URLs.

# --- Founder External Profiles (REQUIRED for Authoritativeness via sameAs) ---
founder_wikidata_qid: ""             # Format: "Q138610626". Leave blank if no Wikidata entry yet.
founder_linkedin_url: ""
founder_x_url: ""                    # X/Twitter profile URL.
founder_github_url: ""
founder_huggingface_url: ""
founder_orcid: ""                    # If applicable for academic/research credibility.
founder_personal_site_url: ""        # If founder maintains a personal domain separate from business.
founder_other_profiles: []           # Any additional verified profiles.

# --- Additional Authors (RECOMMENDED for multi-author sites) ---
additional_authors:
  - full_name: ""
    title: ""
    bio_short: ""
    bio_long: ""
    photo_url: ""
    credentials: []
    sameAs: []
    knowsAbout: []

# --- Topical Pillars (REQUIRED for Expertise demonstration) ---
primary_topical_pillars: []          # 3-7 topics this site is the authority on.
                                     # Example: ["AI Search Optimization", "SEO", "Web Development"].

# --- YMYL Classification (REQUIRED for Trust pillar weighting) ---
ymyl_classification: false           # Set true if site covers Your Money or Your Life topics.
ymyl_categories: []                  # If true, list applicable categories:
                                     # "health", "finance", "legal", "civic", "safety", "shopping".

# --- AI Content Disclosure (REQUIRED for Trust pillar) ---
uses_ai_in_content: false            # Set true if any content is AI-assisted or AI-generated.
ai_disclosure_policy: ""             # If true, the disclosure statement to display.
ai_review_process: ""                # If true, describe human review process.

# --- Trust & Compliance (REQUIRED) ---
has_privacy_policy: false
has_terms_of_service: false
has_accessibility_statement: false
has_cookie_consent: false
gdpr_applicable: false
ccpa_applicable: false
state_privacy_laws_applicable: []    # Example: ["CA", "CO", "CT", "VA", "UT", "TX"].

# --- Reviews & Social Proof (RECOMMENDED) ---
google_business_profile_url: ""
google_business_profile_id: ""
existing_review_count: 0
existing_average_rating: 0.0
review_platforms: []                 # ["Google", "Trustpilot", "Clutch", "BBB", "Yelp"].
trust_certifications: []             # ["BBB Accredited", "SDVOSB Certified", "ISO 27001"].

# --- Earned Media (RECOMMENDED for Authoritativeness) ---
featured_in_publications: []         # Array of {name, url, date, quote} objects.
external_backlink_count: 0           # Approximate, from Ahrefs/Semrush.
domain_rating: 0                     # Ahrefs DR or equivalent.

# --- Tech Stack (REQUIRED for stack-specific install) ---
tech_stack: ""                       # One of: "wordpress", "nextjs", "astro", "hugo",
                                     # "vanilla-html", "vanilla-php", "shopify", "webflow", "other".
cms_admin_access: false              # Whether the implementer has CMS access.
git_repository_url: ""               # If applicable.
deployment_method: ""                # "git-push", "ftp", "cms-publish", "ci-cd", "manual".

# --- Existing State Detection (filled during install/audit) ---
existing_organization_schema: false
existing_author_pages: []
existing_canonical_strategy: ""
existing_robots_txt: false
existing_llms_txt: false
existing_sitemap: false
existing_ssl: false
existing_hsts: false
existing_csp: false

After variables are gathered, save them as eeat-variables.yml in the project root. All install code in this document references these variable names.

3. What E-E-A-T Is

E-E-A-T stands for Experience, Expertise, Authoritativeness, and Trustworthiness. It is Google's published framework for evaluating content quality, embedded in the Search Quality Rater Guidelines (last updated September 11, 2025, 182 pages). The framework was originally introduced as E-A-T in 2014. The fourth pillar — Experience — was added in December 2022 to better evaluate first-hand involvement with topics in the era of AI-generated content.

E-E-A-T is not a direct ranking factor. Google does not assign an E-E-A-T score to pages or sites. Instead, E-E-A-T is the framework Google's human Search Quality Raters use to evaluate whether the algorithm is surfacing genuinely helpful content. Google then uses signals correlated with E-E-A-T to train and refine the ranking algorithms themselves. The practical effect: sites that demonstrate strong E-E-A-T signals consistently outrank sites that don't, especially after core updates.

In 2026, E-E-A-T's importance has compounded. The March 2026 Core Update reinforced entity-based ranking, expertise demonstration, and trust signals as primary differentiators. AI engines (ChatGPT, Perplexity, Claude, Gemini, Copilot) use overlapping signals to decide which sources to cite. Strong E-E-A-T implementation simultaneously improves Google rankings, AI citation rate, and brand authority — making it the highest-leverage framework in modern SEO.

Trust is the most important pillar. Google's own guidelines state: "Untrustworthy pages have low E-E-A-T no matter how Experienced, Expert, or Authoritative they may seem." Experience, Expertise, and Authoritativeness all support and reinforce Trust. Without Trust, the other three are worthless.

E-E-A-T applies to all content but is held to higher standards on YMYL (Your Money or Your Life) topics — health, finance, legal, civic information, safety, and government. The September 2025 Search Quality Rater Guidelines update expanded YMYL to explicitly include elections and civic trust. If a site covers any YMYL topic, every signal in this framework must be implemented to a higher bar.

4. The Four Pillars — Deep Dive

Each pillar gets the same treatment: definition, the signals Google looks for, the specific elements you must install on the website to demonstrate that signal, and the audit criteria for scoring an existing site.

4.1 Experience (First "E")

What Experience Means

Experience asks: does the content reflect first-hand, lived involvement with the topic? Has the author actually used the product, visited the place, performed the procedure, run the campaign, lived through the situation? Or is the content compiled from secondary sources without direct involvement?

Experience was added in December 2022 specifically to counterbalance AI-generated content. AI can synthesize information at scale but cannot produce genuine experience. Pages that demonstrate experience get a quality boost relative to pages that merely aggregate information.

Signals Google Looks For (Experience)

• First-person narrative — "I used this," "we tested," "in my experience"
• Original photos and videos of the author actually doing the thing being written about
• Specific dates and version numbers that prove temporal involvement ("As of March 2026, using version 14.2")
• Failure stories and edge cases — generic content covers happy paths, experienced content covers what breaks
• Original measurements, screenshots, results that couldn't have been generated without doing the work
• Author credentials specific to the experience — "Joseph has personally implemented this framework on 130+ client sites"
• Process documentation — step-by-step accounts of work actually performed
• Timestamps and changelog entries showing iterative engagement with the topic
• Specific named tools, software versions, and environments used
• Quotable failures — admitting what didn't work, what was harder than expected

What to Install on the Website (Experience)

4.1.1 First-person bylines on every article

Every article must have an author credit displayed at the top with first-person framing. The author must be a real person with a corresponding author page (see Section 7).

<header class="article-header">
  <h1>{{ARTICLE_TITLE}}</h1>
  <div class="article-byline">
    <img src="{{AUTHOR_PHOTO}}" alt="{{AUTHOR_NAME}}" width="48" height="48" loading="lazy">
    <div class="byline-meta">
      <p>By <a href="/authors/{{AUTHOR_SLUG}}/" rel="author">{{AUTHOR_NAME}}</a></p>
      <p class="byline-context">{{AUTHOR_TITLE}} · {{YEARS_EXPERIENCE}} years experience</p>
    </div>
    <time datetime="{{PUBLISH_DATE_ISO}}">Published {{PUBLISH_DATE_HUMAN}}</time>
    <time datetime="{{UPDATED_DATE_ISO}}">Updated {{UPDATED_DATE_HUMAN}}</time>
  </div>
</header>

4.1.2 "How I tested / what I built" sidebar on practical content

For practical/tutorial/review content, include a callout box explicitly documenting the author's experience with the subject.

<aside class="experience-callout" aria-label="About this article">
  <h2>How I Know This Works</h2>
  <ul>
    <li>I have implemented this framework on <strong>{{CLIENT_COUNT}}+ client sites</strong> since {{START_YEAR}}.</li>
    <li>This article documents the process I use today, last revised {{LAST_REVISION}}.</li>
    <li>All screenshots are from real client implementations (anonymized where applicable).</li>
    <li>Failure cases and edge cases are included in the relevant sections below.</li>
  </ul>
</aside>

4.1.3 Original imagery and screenshots

Every article that documents a process must include original imagery — screenshots, photos, diagrams created by the author. Stock photos and AI-generated images do not count toward Experience signal. Add creator and dateCreated metadata to every image.

<figure>
  <img
    src="/images/articles/{{ARTICLE_SLUG}}/{{IMAGE_NAME}}.webp"
    alt="{{DESCRIPTIVE_ALT_TEXT}}"
    width="1200"
    height="800"
    loading="lazy">
  <figcaption>
    {{CAPTION_TEXT}}
    <small>Screenshot taken {{SCREENSHOT_DATE}} on {{SCREENSHOT_CONTEXT}}.</small>
  </figcaption>
</figure>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://{{PRIMARY_DOMAIN}}/images/articles/{{ARTICLE_SLUG}}/{{IMAGE_NAME}}.webp",
  "creator": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{AUTHOR_SLUG}}/#person"},
  "dateCreated": "{{IMAGE_CREATION_DATE}}",
  "caption": "{{CAPTION_TEXT}}",
  "creditText": "{{AUTHOR_NAME}}"
}
</script>

4.1.4 Specific dates, versions, and environment notes

Within article body content, every claim that depends on tooling, version, or temporal context must be explicitly date-stamped and version-specific.

Pattern to follow in body content:

"As of {{MONTH_YEAR}}, using {{TOOL_NAME}} version {{VERSION_NUMBER}} on {{PLATFORM}}, the configuration that produces the best result is..."

4.1.5 Failure and edge-case sections

Every long-form practical article must include a section explicitly documenting what doesn't work, common failures, or edge cases the author has encountered. This is one of the strongest possible Experience signals because it cannot be faked from secondary sources.

<section class="failures-section">
  <h2>What Doesn't Work (Things I've Tried)</h2>
  <ul>
    <li><strong>{{FAILED_APPROACH_1}}:</strong> {{WHY_IT_FAILED_AND_WHAT_TO_DO_INSTEAD}}.</li>
    <li><strong>{{FAILED_APPROACH_2}}:</strong> {{WHY_IT_FAILED_AND_WHAT_TO_DO_INSTEAD}}.</li>
    <li><strong>{{FAILED_APPROACH_3}}:</strong> {{WHY_IT_FAILED_AND_WHAT_TO_DO_INSTEAD}}.</li>
  </ul>
</section>

4.1.6 Process documentation with timestamps

For service or case-study content, document the actual timeline of work performed.

<section class="process-timeline">
  <h2>Project Timeline</h2>
  <ol>
    <li><time datetime="{{DATE_1}}">{{DATE_1_HUMAN}}</time> — {{MILESTONE_1}}</li>
    <li><time datetime="{{DATE_2}}">{{DATE_2_HUMAN}}</time> — {{MILESTONE_2}}</li>
    <li><time datetime="{{DATE_3}}">{{DATE_3_HUMAN}}</time> — {{MILESTONE_3}}</li>
  </ol>
</section>

Audit Criteria (Experience)

Score each item Pass / Partial / Fail / Not Applicable.

Pillar score: Pass = 2 points, Partial = 1 point, Fail = 0 points. Maximum 20 points. Threshold for "world-class" Experience: 17+/20 with zero Critical fails.

4.2 Expertise (Second "E")

What Expertise Means

Expertise asks: does the author have the depth and accuracy of knowledge required for the topic? This is distinct from Experience — Experience is about doing, Expertise is about knowing. A person can have Experience without formal Expertise (someone who has been raising chickens for 30 years has experience but may not have credentialed expertise) and vice versa (a credentialed PhD who has never personally implemented the thing they wrote about has expertise but no experience).

For YMYL topics — health, finance, legal advice, safety — Google holds Expertise to a high formal standard (degrees, licenses, board certifications, peer-reviewed publications). For non-YMYL topics, Google values "everyday expertise" — demonstrated knowledge and breadth, even without formal credentials.

Signals Google Looks For (Expertise)

• Credentials displayed prominently — degrees, licenses, certifications, professional memberships
• Coverage of edge cases — what breaks, what's the exception to the rule, when standard advice fails
• Correct technical vocabulary used naturally — without over-explanation or avoidance
• Internal consistency across content — an expert covers the topic comprehensively across many articles, not just one
• Cross-references to authoritative sources — an expert knows the literature
• Original analysis — synthesis that goes beyond aggregating others' work
• Depth of coverage on related topics — topical authority across an entire domain
• Industry recognition — speaking, publications on third-party sites, peer citations
• Specificity — generic content covers main scenarios; expert content covers nuance
• Predictive accuracy — expert content holds up when validated against future events

What to Install on the Website (Expertise)

4.2.1 Credentials displayed in author box (every article)

Every author byline must show the author's relevant credentials inline.

<div class="author-box">
  <img src="{{AUTHOR_PHOTO}}" alt="{{AUTHOR_NAME}}" width="80" height="80">
  <div class="author-meta">
    <h3><a href="/authors/{{AUTHOR_SLUG}}/" rel="author">{{AUTHOR_NAME}}</a></h3>
    <p class="author-title">{{AUTHOR_TITLE}}</p>
    <ul class="author-credentials">
      <li>{{CREDENTIAL_1}}</li>
      <li>{{CREDENTIAL_2}}</li>
      <li>{{YEARS_EXPERIENCE}} years experience</li>
    </ul>
    <p class="author-bio-short">{{AUTHOR_BIO_SHORT}}</p>
  </div>
</div>

4.2.2 Person schema with hasCredential and knowsAbout

Every author page must include detailed Person schema declaring credentials and topical expertise.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://{{PRIMARY_DOMAIN}}/authors/{{AUTHOR_SLUG}}/#person",
  "name": "{{FOUNDER_FULL_NAME}}",
  "givenName": "{{FOUNDER_FIRST_NAME}}",
  "familyName": "{{FOUNDER_LAST_NAME}}",
  "jobTitle": "{{FOUNDER_TITLE}}",
  "url": "https://{{PRIMARY_DOMAIN}}/authors/{{AUTHOR_SLUG}}/",
  "image": "{{FOUNDER_PHOTO_URL}}",
  "email": "{{FOUNDER_EMAIL}}",
  "description": "{{FOUNDER_BIO_SHORT}}",
  "knowsAbout": {{FOUNDER_TOPICAL_EXPERTISE}},
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "name": "{{CREDENTIAL_1_NAME}}",
      "credentialCategory": "degree",
      "recognizedBy": {
        "@type": "EducationalOrganization",
        "name": "{{CREDENTIAL_1_ISSUER}}"
      },
      "dateCreated": "{{CREDENTIAL_1_YEAR}}"
    },
    {
      "@type": "EducationalOccupationalCredential",
      "name": "{{CREDENTIAL_2_NAME}}",
      "credentialCategory": "degree",
      "recognizedBy": {
        "@type": "EducationalOrganization",
        "name": "{{CREDENTIAL_2_ISSUER}}"
      },
      "dateCreated": "{{CREDENTIAL_2_YEAR}}"
    }
  ],
  "alumniOf": [
    {
      "@type": "EducationalOrganization",
      "name": "{{CREDENTIAL_1_ISSUER}}"
    }
  ],
  "sameAs": [
    "https://www.wikidata.org/wiki/{{FOUNDER_WIKIDATA_QID}}",
    "{{FOUNDER_LINKEDIN_URL}}",
    "{{FOUNDER_X_URL}}",
    "{{FOUNDER_GITHUB_URL}}",
    "{{FOUNDER_HUGGINGFACE_URL}}"
  ],
  "worksFor": {
    "@id": "https://{{PRIMARY_DOMAIN}}/#organization"
  }
}
</script>

4.2.3 Topical hub pages

Every primary topical pillar (from primary_topical_pillars) gets a dedicated hub page that demonstrates depth of coverage. Build at /topics/{{TOPIC_SLUG}}/.

The hub page must:

• Have an H1 matching the topic name
• Open with a 200-400 word definitional paragraph written by the author
• List all articles published on this topic, organized by sub-topic
• Include CollectionPage schema declaring this is the topical authority page
• Cross-link to related hubs

<article class="topical-hub" itemscope itemtype="https://schema.org/CollectionPage">
  <h1 itemprop="name">{{TOPIC_NAME}}</h1>

  <section class="hub-introduction" itemprop="description">
    <p>{{200_400_WORD_AUTHORITATIVE_INTRODUCTION}}</p>
  </section>

  <section class="hub-content-list">
    <h2>Articles on This Topic</h2>
    {{LIST_OF_ARTICLES_GROUPED_BY_SUBTOPIC}}
  </section>

  <section class="hub-related-topics">
    <h2>Related Topics</h2>
    {{LIST_OF_RELATED_HUB_PAGES}}
  </section>
</article>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "CollectionPage",
  "name": "{{TOPIC_NAME}} — Complete Coverage",
  "url": "https://{{PRIMARY_DOMAIN}}/topics/{{TOPIC_SLUG}}/",
  "about": {
    "@type": "Thing",
    "name": "{{TOPIC_NAME}}"
  },
  "author": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{AUTHOR_SLUG}}/#person"},
  "publisher": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"}
}
</script>

4.2.4 Edge-case and "advanced" content

For every primary topic, publish content explicitly addressing edge cases, advanced scenarios, and what breaks. Suggested URL pattern: /topics/{{TOPIC_SLUG}}/advanced/ or /guides/{{TOPIC_SLUG}}-edge-cases/.

These pages signal expertise because they require knowledge that can only be built through extensive engagement with the topic.

4.2.5 Reference list / citations on every article

Every article must include a sources/references section at the bottom listing primary sources cited. Use citation property in Article schema.

<section class="article-references">
  <h2>References</h2>
  <ol>
    <li id="ref-1">
      {{AUTHOR_NAME_OR_ORG}}. ({{YEAR}}). <em>{{TITLE}}</em>.
      Retrieved from <a href="{{URL}}" rel="noopener">{{SHORT_URL}}</a>.
      <small>Accessed {{ACCESS_DATE}}.</small>
    </li>
    <li id="ref-2">
      {{REFERENCE_2}}.
    </li>
  </ol>
</section>

In the Article schema:

"citation": [
  {
    "@type": "CreativeWork",
    "name": "{{REFERENCE_1_TITLE}}",
    "url": "{{REFERENCE_1_URL}}",
    "author": "{{REFERENCE_1_AUTHOR}}"
  }
]

4.2.6 External publications and speaking history

The author page must list external publications and speaking history. This signals industry recognition of expertise.

<section class="author-publications">
  <h2>Published Externally</h2>
  <ul>
    {{LIST_OF_EXTERNAL_PUBLICATIONS_WITH_LINKS}}
  </ul>
</section>

<section class="author-speaking">
  <h2>Conference & Podcast Appearances</h2>
  <ul>
    {{LIST_OF_SPEAKING_ENGAGEMENTS_WITH_LINKS}}
  </ul>
</section>

Audit Criteria (Expertise)

Pillar score: Maximum 24 points (12 × 2). Threshold for world-class: 20+/24 with zero Critical fails. YMYL sites: 22+/24.

4.3 Authoritativeness (A)

What Authoritativeness Means

Authoritativeness asks: is this person/site recognized as a go-to source by others in the field? It's the social-proof dimension of E-E-A-T. Experience and Expertise are about the creator. Authoritativeness is about whether the rest of the world acknowledges the creator.

Authoritativeness is built externally and demonstrated internally. The external work happens through earned media, backlinks, citations, speaking engagements, and Wikipedia/Wikidata presence. The internal work is making sure the website surfaces those external signals visibly and via structured data so Google's algorithms can connect the entity to the recognition.

For YMYL topics, Authoritativeness requires recognition from established institutions in the relevant field (medical journals, bar associations, regulatory bodies, academic institutions). For non-YMYL topics, recognition can come from industry publications, communities, peer creators, and earned media in trade publications.

Signals Google Looks For (Authoritativeness)

• Backlinks from authoritative domains in the same topic space
• Brand mentions (linked and unlinked) across the web
• Wikipedia and Wikidata entries for the entity
• Knowledge Graph presence in Google search results
• Citations of original research by other sites
• Featured/quoted in established publications (Forbes, NYT, industry-specific tier-1 sites)
• Conference speaking and panel invitations
• Awards and recognition from established bodies
• Peer references — other recognized experts cite or link to the source
• Social proof — verified accounts, follower counts on professional platforms (LinkedIn for B2B)
• Years of consistent presence — domain age, Wayback Machine history, sustained publishing
• Industry membership / accreditation

What to Install on the Website (Authoritativeness)

4.3.1 Organization schema with sameAs linking to all authority profiles

The site-wide Organization schema must declare every external profile that establishes authority via sameAs. This is the structural signal that connects the entity to its external recognition.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "{{BUSINESS_TYPE}}",
  "@id": "https://{{PRIMARY_DOMAIN}}/#organization",
  "name": "{{BUSINESS_NAME}}",
  "alternateName": {{BUSINESS_ALTERNATE_NAMES}},
  "url": "https://{{PRIMARY_DOMAIN}}",
  "logo": "https://{{PRIMARY_DOMAIN}}/logo.png",
  "founder": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{FOUNDER_SLUG}}/#person"},
  "foundingDate": "{{BUSINESS_FOUNDED_YEAR}}",
  "description": "{{BUSINESS_DESCRIPTION_SHORT}}",
  "sameAs": [
    "https://www.wikidata.org/wiki/{{BUSINESS_WIKIDATA_QID}}",
    "https://en.wikipedia.org/wiki/{{BUSINESS_WIKIPEDIA_SLUG}}",
    "{{LINKEDIN_COMPANY_URL}}",
    "{{X_COMPANY_URL}}",
    "{{FACEBOOK_PAGE_URL}}",
    "{{GITHUB_ORG_URL}}",
    "{{CRUNCHBASE_URL}}",
    "{{BBB_PROFILE_URL}}",
    "{{CHAMBER_OF_COMMERCE_LISTING_URL}}",
    "{{INDUSTRY_DIRECTORY_URLS}}"
  ]
}
</script>

4.3.2 "Featured In" / "As Seen In" section on homepage and About page

Every site must surface earned media visibly. Build a /press/ or /featured-in/ page. Display logos with links on the homepage and About page.

<section class="featured-in" aria-label="Press coverage">
  <h2>Featured In</h2>
  <ul class="featured-in-logos">
    <li>
      <a href="{{COVERAGE_URL_1}}" rel="noopener">
        <img src="/logos/{{PUBLICATION_1_LOGO}}.svg" alt="{{PUBLICATION_1_NAME}}" width="120" height="40" loading="lazy">
      </a>
    </li>
    <li>
      <a href="{{COVERAGE_URL_2}}" rel="noopener">
        <img src="/logos/{{PUBLICATION_2_LOGO}}.svg" alt="{{PUBLICATION_2_NAME}}" width="120" height="40" loading="lazy">
      </a>
    </li>
    {{MORE_PUBLICATIONS}}
  </ul>
  <p><a href="/press/">See all coverage →</a></p>
</section>

4.3.3 Quotation schema for cited expert commentary

When the founder/site is quoted in earned media, add Quotation schema to the relevant page on the site that surfaces the quote.

<blockquote cite="{{COVERAGE_URL}}">
  "{{EXACT_QUOTE_FROM_FOUNDER}}"
  <footer>
    — {{FOUNDER_NAME}}, quoted in
    <cite><a href="{{COVERAGE_URL}}" rel="noopener">{{PUBLICATION_NAME}}</a></cite>,
    {{PUBLICATION_DATE}}
  </footer>
</blockquote>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Quotation",
  "text": "{{EXACT_QUOTE_FROM_FOUNDER}}",
  "spokenByCharacter": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{FOUNDER_SLUG}}/#person"},
  "isPartOf": {
    "@type": "NewsArticle",
    "url": "{{COVERAGE_URL}}",
    "publisher": {
      "@type": "Organization",
      "name": "{{PUBLICATION_NAME}}"
    },
    "datePublished": "{{PUBLICATION_DATE_ISO}}"
  }
}
</script>

4.3.4 Wikidata entry and reference

Every business and every founder should have a Wikidata entry. Wikidata has a lower notability bar than Wikipedia and is the foundation Google's Knowledge Graph and AI training data both pull from. Reference the Wikidata QID in sameAs of both Organization and Person schema (already shown above).

If a Wikidata entry doesn't exist:

1. Confirm notability (multiple independent published references about the entity)
2. Create the entry at https://www.wikidata.org/wiki/Special:NewItem
3. Populate properties: instance of, founded by, founding date, official website, headquarters, industry, sameAs links to authoritative profiles
4. Once approved and stable, capture the QID for use in schema

If a Wikipedia article exists, also add it to sameAs.

4.3.5 Awards, certifications, and accreditations

Every legitimate award, certification, or accreditation gets its own visible display element on the site (footer, About page, dedicated /credentials/ page) and is referenced via schema.

<section class="credentials-display">
  <h2>Credentials & Recognition</h2>
  <ul class="credentials-list">
    <li>
      <img src="/badges/sdvosb.svg" alt="SDVOSB Certified" width="80" height="80">
      <div>
        <strong>Service-Disabled Veteran-Owned Small Business</strong>
        <p>Certified by the U.S. Small Business Administration since {{CERT_YEAR}}.</p>
        <a href="{{VERIFICATION_URL}}" rel="noopener">Verify</a>
      </div>
    </li>
    {{MORE_CREDENTIALS}}
  </ul>
</section>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "EducationalOccupationalCredential",
  "name": "Service-Disabled Veteran-Owned Small Business",
  "credentialCategory": "certification",
  "recognizedBy": {
    "@type": "GovernmentOrganization",
    "name": "U.S. Small Business Administration"
  },
  "url": "{{VERIFICATION_URL}}"
}
</script>

4.3.6 Backlink-earning assets ("Cite this" buttons)

To earn the backlinks that build authoritativeness, the site must publish citation-worthy assets and make them easy to cite.

On every research page, original data page, or flagship guide:

<aside class="cite-this">
  <h3>Cite This Research</h3>
  <p>If this research was useful in your work, please cite it as:</p>

  <div class="citation-formats">
    <details>
      <summary>APA Format</summary>
      <pre id="citation-apa">{{LASTNAME}}, {{FIRST_INITIAL}}. ({{YEAR}}). <em>{{TITLE}}</em>. {{BUSINESS_NAME}}. {{CANONICAL_URL}}</pre>
      <button onclick="copyToClipboard('citation-apa')">Copy APA</button>
    </details>

    <details>
      <summary>MLA Format</summary>
      <pre id="citation-mla">{{LASTNAME}}, {{FIRSTNAME}}. "{{TITLE}}." <em>{{BUSINESS_NAME}}</em>, {{DATE}}, {{CANONICAL_URL}}.</pre>
      <button onclick="copyToClipboard('citation-mla')">Copy MLA</button>
    </details>

    <details>
      <summary>BibTeX</summary>
      <pre id="citation-bibtex">@misc{ {{CITATION_KEY}},
  author = "{{LASTNAME}}, {{FIRSTNAME}}",
  title = "{{TITLE}}",
  year = "{{YEAR}}",
  url = "{{CANONICAL_URL}}"
}</pre>
      <button onclick="copyToClipboard('citation-bibtex')">Copy BibTeX</button>
    </details>
  </div>
</aside>

<script>
function copyToClipboard(elementId) {
  const text = document.getElementById(elementId).textContent;
  navigator.clipboard.writeText(text);
}
</script>

4.3.7 Founder personal entity site

For maximum Authoritativeness, the founder maintains a personal site at a separate domain (e.g., josephanady.com) with reciprocal sameAs linking to the business and to all external profiles. This builds the founder as an entity independent of the business, which compounds authority and protects against business-name disputes.

The personal site at minimum needs:

• Person schema mirroring the business site's Person schema
• Bidirectional sameAs links to all profiles
• Bio with credentials matching the business site
• Selected work / portfolio
• Contact information

Audit Criteria (Authoritativeness)

Pillar score: Maximum 30 points (15 × 2). Threshold for world-class: 25+/30 with zero Critical fails.

4.4 Trustworthiness (T)

What Trustworthiness Means

Trustworthiness asks: is the page accurate, honest, safe, and reliable? It's the most important pillar — Google's guidelines explicitly state that "untrustworthy pages have low E-E-A-T no matter how Experienced, Expert, or Authoritative they may seem."

Trustworthiness is the synthesis pillar. Every other E-E-A-T signal supports Trust. A site can have demonstrated Experience (real photos, first-person narrative), strong Expertise (credentials, depth), and external Authoritativeness (backlinks, recognition) — but if any single trust violation exists (deceptive practices, factual errors left unfixed, missing privacy policy on a site collecting data, expired SSL), the entire E-E-A-T evaluation collapses.

For YMYL sites, Trust is non-negotiable. A finance site missing clear advertising disclosure, a health site without medical-reviewer credentials, or a legal site without proper disclaimers will rank worse than thin content from a competitor with proper trust signals.

Signals Google Looks For (Trustworthiness)

• Accurate information — claims supported by sources, factual errors corrected promptly
• Transparent ownership — who owns the site, who created the content, how to contact them
• Clear advertising disclosure — affiliate links, sponsored content, ads disclosed per FTC guidelines
• Functional security — HTTPS, valid SSL, no mixed content, no security warnings
• Privacy policy and terms of service — clearly accessible
• Contact information — real, verifiable, responsive
• Consistent business information — NAP matches across the web
• Reviews and ratings — visible, real, responded to (positive and negative)
• Functional pages — no broken links, no soft-404s, no expired content presented as current
• Content freshness — dateModified is meaningful, stale content gets refreshed or retired
• Honesty about limitations — content acknowledges what it doesn't cover
• AI content disclosure — when applicable, transparent about AI use
• YMYL-specific trust — medical reviewer for health content, licensed professional for legal/finance

What to Install on the Website (Trustworthiness)

4.4.1 Required policy pages

Every site must have these policy pages, accessible from every page footer:

• /privacy/ — Privacy policy covering data collected, purpose, retention, third parties, user rights, contact for data requests
• /terms/ — Terms of service / use
• /accessibility/ — WCAG conformance level statement and contact for accessibility issues
• /cookie-policy/ — If using non-essential cookies (separate from privacy or section within)
• /disclosure/ — Affiliate, sponsored content, AI use disclosures

For YMYL sites, additionally:

• /medical-disclaimer/ (health sites)
• /financial-disclaimer/ (finance sites)
• /legal-disclaimer/ (legal sites)
• /editorial-policy/ — How content is created, reviewed, fact-checked, corrected
• /corrections-policy/ — How factual errors are handled and corrected

Footer template:

<footer class="site-footer" role="contentinfo">
  <div class="footer-trust-block">
    <nav aria-label="Policies">
      <ul class="policy-links">
        <li><a href="/privacy/">Privacy Policy</a></li>
        <li><a href="/terms/">Terms of Service</a></li>
        <li><a href="/accessibility/">Accessibility</a></li>
        <li><a href="/cookie-policy/">Cookie Policy</a></li>
        <li><a href="/disclosure/">Disclosures</a></li>
        <li><a href="/contact/">Contact</a></li>
        {{IF_YMYL_HEALTH}}<li><a href="/medical-disclaimer/">Medical Disclaimer</a></li>{{/IF}}
        {{IF_YMYL_FINANCE}}<li><a href="/financial-disclaimer/">Financial Disclaimer</a></li>{{/IF}}
        {{IF_YMYL_LEGAL}}<li><a href="/legal-disclaimer/">Legal Disclaimer</a></li>{{/IF}}
        {{IF_YMYL_ANY}}<li><a href="/editorial-policy/">Editorial Policy</a></li>{{/IF}}
        {{IF_YMYL_ANY}}<li><a href="/corrections-policy/">Corrections</a></li>{{/IF}}
      </ul>
    </nav>

    <address class="footer-nap">
      <strong>{{BUSINESS_NAME}}</strong><br>
      {{BUSINESS_ADDRESS_STREET}}<br>
      {{BUSINESS_ADDRESS_CITY}}, {{BUSINESS_ADDRESS_REGION}} {{BUSINESS_ADDRESS_POSTAL}}<br>
      Phone: <a href="tel:{{BUSINESS_PHONE}}">{{BUSINESS_PHONE_DISPLAY}}</a><br>
      Email: <a href="mailto:{{BUSINESS_EMAIL}}">{{BUSINESS_EMAIL}}</a>
    </address>

    <div class="footer-trust-badges">
      {{TRUST_BADGES_HTML}}
    </div>

    <p class="footer-copyright">
      © {{CURRENT_YEAR}} {{BUSINESS_NAME}}. All rights reserved.
    </p>

    {{IF_US_PRIVACY_LAWS}}
    <p class="footer-privacy-rights">
      <a href="/privacy/your-rights/">Your Privacy Choices</a>
    </p>
    {{/IF}}
  </div>
</footer>

4.4.2 HTTPS, HSTS, and security headers

Every site must enforce HTTPS sitewide with proper security headers. This is non-negotiable in 2026.

Required server configuration (nginx example, adapt for other servers):

server {
  listen 443 ssl http2;
  server_name {{PRIMARY_DOMAIN}};

  # SSL configuration
  ssl_certificate /path/to/fullchain.pem;
  ssl_certificate_key /path/to/privkey.pem;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers on;

  # OCSP stapling
  ssl_stapling on;
  ssl_stapling_verify on;

  # HSTS — enforce HTTPS for 1 year, including subdomains, preload eligible
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

  # Security headers
  add_header X-Content-Type-Options "nosniff" always;
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
  add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https://www.google-analytics.com;" always;

  # Hide server signature
  server_tokens off;

  # ... rest of server config
}

# Redirect HTTP to HTTPS
server {
  listen 80;
  server_name {{PRIMARY_DOMAIN}};
  return 301 https://$server_name$request_uri;
}

After deployment, submit the domain to the HSTS preload list at https://hstspreload.org/.

4.4.3 Last-updated banner on every article

Every article (especially time-sensitive content) must display when it was last updated.

<div class="last-updated-banner" role="contentinfo">
  <strong>Last updated:</strong>
  <time datetime="{{UPDATED_DATE_ISO}}">{{UPDATED_DATE_HUMAN}}</time>
  · Reviewed by <a href="/authors/{{REVIEWER_SLUG}}/">{{REVIEWER_NAME}}</a>
  {{IF_FACT_CHECKED}}· Fact-checked{{/IF}}
</div>

4.4.4 Inline citations on every factual claim

Every statistic, study reference, or factual claim must have an inline citation linking to the primary source.

<p>
  According to a {{YEAR}} study by {{ORGANIZATION}},
  <a href="{{SOURCE_URL}}" rel="noopener" class="citation">
    {{STATISTIC_OR_CLAIM}}<sup>1</sup>
  </a>.
</p>

4.4.5 Author transparency

Every author has a verifiable identity. Anonymous content erodes trust. The author page must include real name, real photo, bio with verifiable details, contact method, credentials with verification, and external profiles in sameAs.

4.4.6 AI content disclosure

If any content on the site uses AI assistance or generation, disclose it transparently.

Site-wide disclosure on /disclosure/ page:

<section class="ai-disclosure">
  <h2>Our AI Use Policy</h2>

  <p>{{AI_DISCLOSURE_POLICY}}</p>

  <h3>What This Means in Practice</h3>
  <ul>
    <li>{{SPECIFIC_USE_CASE_1}}</li>
    <li>{{SPECIFIC_USE_CASE_2}}</li>
    <li>{{SPECIFIC_USE_CASE_3}}</li>
  </ul>

  <h3>Our Review Process</h3>
  <p>{{AI_REVIEW_PROCESS}}</p>

  <h3>What We Don't Do</h3>
  <ul>
    <li>We do not publish AI-generated content without expert review.</li>
    <li>We do not use AI to fabricate quotes, statistics, or sources.</li>
    <li>We do not present AI-generated images as photographs without disclosure.</li>
  </ul>
</section>

For individual articles using AI assistance:

<aside class="ai-content-disclosure" role="note">
  <strong>About this article:</strong>
  This article was {{AI_USAGE_LEVEL}} and reviewed by {{REVIEWER_NAME}}, {{REVIEWER_CREDENTIALS}}.
  All facts have been verified. <a href="/disclosure/">Read our full AI policy.</a>
</aside>

4.4.7 Affiliate, sponsored, and commercial disclosures

<aside class="commercial-disclosure" role="note">
  <strong>Disclosure:</strong>
  This article contains affiliate links. If you purchase through these links,
  we may earn a commission at no additional cost to you. This does not influence
  our recommendations — we only recommend products we have personally used or thoroughly evaluated.
  <a href="/disclosure/">Read our full disclosure policy.</a>
</aside>

For sponsored content:

<div class="sponsored-banner" role="banner">
  <strong>SPONSORED:</strong>
  This article is sponsored by {{SPONSOR_NAME}}. {{BUSINESS_NAME}} maintains
  editorial independence; sponsorship does not influence our review or analysis.
  <a href="/disclosure/">Learn how we handle sponsored content.</a>
</div>

4.4.8 Reviews and ratings — real and responded-to

Display verified reviews with Review and AggregateRating schema.

<section class="reviews-section" itemscope itemtype="https://schema.org/{{BUSINESS_TYPE}}">
  <meta itemprop="name" content="{{BUSINESS_NAME}}">

  <div class="aggregate-rating" itemprop="aggregateRating" itemscope itemtype="https://schema.org/AggregateRating">
    <span class="rating-value" itemprop="ratingValue">{{AVERAGE_RATING}}</span>
    /
    <span itemprop="bestRating">5</span>
    based on
    <span itemprop="reviewCount">{{REVIEW_COUNT}}</span> verified reviews
  </div>

  {{INDIVIDUAL_REVIEWS}}

  <p>
    <a href="/reviews/">See all reviews</a> ·
    <a href="{{GOOGLE_BUSINESS_REVIEW_URL}}" rel="noopener">Verify on Google</a>
  </p>
</section>

4.4.9 Functional pages — no broken links, no soft-404s

Custom 404 page returning HTTP 404:

<main class="error-404">
  <h1>404 — Page Not Found</h1>
  <p>The page you're looking for doesn't exist. Here are some helpful options:</p>

  <ul class="error-404-options">
    <li><a href="/">Return to homepage</a></li>
    <li><a href="/sitemap.html">Browse all content</a></li>
    <li><a href="/contact/">Contact us</a></li>
  </ul>

  <section class="error-404-search">
    <h2>Search</h2>
    <form action="/search/" method="get">
      <label for="search-q">Search the site:</label>
      <input type="search" id="search-q" name="q" placeholder="What were you looking for?">
      <button type="submit">Search</button>
    </form>
  </section>
</main>

The server must return HTTP 404 for this page, not 200.

4.4.10 NAP consistency

Business Name, Address, Phone (NAP) must be identical across footer, contact page, About page, schema, GBP, and all directory citations. Audit quarterly via Whitespark, BrightLocal, or Moz Local.

4.4.11 Cookie consent

If non-essential cookies are used, implement Google Consent Mode v2:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}

  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'functionality_storage': 'denied',
    'personalization_storage': 'denied',
    'security_storage': 'granted',
    'wait_for_update': 500
  });

  // Honor Global Privacy Control
  if (navigator.globalPrivacyControl) {
    gtag('consent', 'update', {
      'ad_storage': 'denied',
      'ad_user_data': 'denied',
      'ad_personalization': 'denied'
    });
  }
</script>

4.4.12 YMYL-specific trust elements

If ymyl_classification: true, additional trust elements are required:

<header class="article-header ymyl-article">
  <h1>{{TITLE}}</h1>

  <div class="ymyl-meta">
    <p>
      Written by <a href="/authors/{{AUTHOR_SLUG}}/" rel="author">{{AUTHOR_NAME}}</a>,
      <span class="author-credentials">{{AUTHOR_CREDENTIALS}}</span>
    </p>
    <p>
      Medically reviewed by <a href="/authors/{{REVIEWER_SLUG}}/">{{REVIEWER_NAME}}</a>,
      <span class="reviewer-credentials">{{REVIEWER_CREDENTIALS}}</span>
    </p>
    <p>
      <time datetime="{{PUBLISHED_DATE}}">Published {{PUBLISHED_DATE_HUMAN}}</time>
      ·
      <time datetime="{{UPDATED_DATE}}">Last updated {{UPDATED_DATE_HUMAN}}</time>
      ·
      <time datetime="{{REVIEWED_DATE}}">Last medically reviewed {{REVIEWED_DATE_HUMAN}}</time>
    </p>
  </div>

  <aside class="ymyl-disclaimer" role="note">
    <p>
      <strong>This article is for informational purposes only and is not a substitute for professional medical advice.</strong>
      Always consult a qualified healthcare provider for personal medical decisions.
      <a href="/medical-disclaimer/">Read our full medical disclaimer.</a>
    </p>
  </aside>
</header>

Audit Criteria (Trustworthiness)

Pillar score: Maximum 56 points (28 × 2). Threshold for world-class: 50+/56 with zero Critical fails. YMYL: 54+/56 with zero Critical fails.

Trust is the most important pillar. A site with zero Critical Trust fails but moderate scores elsewhere outperforms a site with strong Experience/Expertise/Authoritativeness but a Critical Trust fail. Always remediate Trust failures first.

5. Site-Wide Installation

This section covers the global infrastructure that must exist on every site before per-page or per-author work begins. Execute in the order shown.

5.1 Phase 1: Schema Graph Foundation

Build the central schema graph that every other piece of schema will reference. This goes in the <head> of every page.

File location:

• Vanilla HTML: <head> of every page, ideally via a shared header include
• Next.js: app/layout.tsx head section or a dedicated <SchemaGraph /> component
• WordPress: Theme's header.php, or via a plugin like Yoast/Rank Math with custom JSON-LD support
• Astro: src/layouts/Layout.astro head slot
• Hugo: layouts/partials/head.html
• Plain PHP: Shared header include

Code (insert in every page <head>):

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "{{BUSINESS_TYPE}}",
      "@id": "https://{{PRIMARY_DOMAIN}}/#organization",
      "name": "{{BUSINESS_NAME}}",
      "alternateName": {{BUSINESS_ALTERNATE_NAMES_JSON}},
      "url": "https://{{PRIMARY_DOMAIN}}",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://{{PRIMARY_DOMAIN}}/#logo",
        "url": "https://{{PRIMARY_DOMAIN}}/logo.png",
        "width": 600,
        "height": 600,
        "caption": "{{BUSINESS_NAME}}"
      },
      "image": {"@id": "https://{{PRIMARY_DOMAIN}}/#logo"},
      "description": "{{BUSINESS_DESCRIPTION_SHORT}}",
      "foundingDate": "{{BUSINESS_FOUNDED_YEAR}}",
      "founder": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{FOUNDER_SLUG}}/#person"},
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "{{BUSINESS_ADDRESS_STREET}}",
        "addressLocality": "{{BUSINESS_ADDRESS_CITY}}",
        "addressRegion": "{{BUSINESS_ADDRESS_REGION}}",
        "postalCode": "{{BUSINESS_ADDRESS_POSTAL}}",
        "addressCountry": "{{BUSINESS_ADDRESS_COUNTRY}}"
      },
      "geo": {
        "@type": "GeoCoordinates",
        "latitude": "{{BUSINESS_GEO_LATITUDE}}",
        "longitude": "{{BUSINESS_GEO_LONGITUDE}}"
      },
      "telephone": "{{BUSINESS_PHONE}}",
      "email": "{{BUSINESS_EMAIL}}",
      "openingHoursSpecification": {{BUSINESS_HOURS_SCHEMA_JSON}},
      "areaServed": {{AREA_SERVED_JSON}},
      "sameAs": {{ORGANIZATION_SAMEAS_JSON}},
      "knowsAbout": {{PRIMARY_TOPICAL_PILLARS_JSON}}
    },
    {
      "@type": "WebSite",
      "@id": "https://{{PRIMARY_DOMAIN}}/#website",
      "url": "https://{{PRIMARY_DOMAIN}}",
      "name": "{{BUSINESS_NAME}}",
      "description": "{{BUSINESS_DESCRIPTION_SHORT}}",
      "publisher": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"},
      "inLanguage": "en-US",
      "potentialAction": {
        "@type": "SearchAction",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://{{PRIMARY_DOMAIN}}/search/?q={search_term_string}"
        },
        "query-input": "required name=search_term_string"
      }
    },
    {
      "@type": "Person",
      "@id": "https://{{PRIMARY_DOMAIN}}/authors/{{FOUNDER_SLUG}}/#person",
      "name": "{{FOUNDER_FULL_NAME}}",
      "givenName": "{{FOUNDER_FIRST_NAME}}",
      "familyName": "{{FOUNDER_LAST_NAME}}",
      "jobTitle": "{{FOUNDER_TITLE}}",
      "url": "https://{{PRIMARY_DOMAIN}}/authors/{{FOUNDER_SLUG}}/",
      "image": "{{FOUNDER_PHOTO_URL}}",
      "email": "{{FOUNDER_EMAIL}}",
      "description": "{{FOUNDER_BIO_SHORT}}",
      "knowsAbout": {{FOUNDER_TOPICAL_EXPERTISE_JSON}},
      "hasCredential": {{FOUNDER_CREDENTIALS_SCHEMA_JSON}},
      "alumniOf": {{FOUNDER_ALUMNI_OF_JSON}},
      "sameAs": {{FOUNDER_SAMEAS_JSON}},
      "worksFor": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"}
    }
  ]
}
</script>

Validation step after install: Visit any page on the site, view source, copy the schema, paste into https://validator.schema.org/. Must validate with zero errors.

5.2 Phase 2: Required Pages

Create these pages if they don't exist. Each has minimum content requirements.

5.2.1 About page (/about/)

Required content:

• H1: "About {{BUSINESS_NAME}}"
• 500+ word description of the business, founder, mission, history
• Founder photo and bio
• Credentials and certifications
• Founding date and history
• Service areas
• Team section if applicable
• Contact CTA

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "AboutPage",
  "@id": "https://{{PRIMARY_DOMAIN}}/about/#aboutpage",
  "url": "https://{{PRIMARY_DOMAIN}}/about/",
  "name": "About {{BUSINESS_NAME}}",
  "description": "{{ABOUT_PAGE_DESCRIPTION}}",
  "mainEntity": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"},
  "publisher": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"},
  "isPartOf": {"@id": "https://{{PRIMARY_DOMAIN}}/#website"}
}
</script>

5.2.2 Contact page (/contact/)

Required content:

• H1: "Contact {{BUSINESS_NAME}}"
• Full NAP block
• Contact form with name, email, message minimum
• Phone with tel: link
• Email with mailto: link
• Hours of operation
• Map embed if local business
• Response time expectation

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ContactPage",
  "url": "https://{{PRIMARY_DOMAIN}}/contact/",
  "name": "Contact {{BUSINESS_NAME}}",
  "mainEntity": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"}
}
</script>

5.2.3 Author hub (/authors/)

Required content:

• H1: "Our Authors" or equivalent
• Grid of all authors with photo, name, title, link to individual author page
• Cross-references to most recent content per author

5.2.4 Individual author pages (/authors/{{slug}}/)

See Section 7 for detailed requirements.

5.2.5 Privacy policy (/privacy/)

Required sections:

• What information is collected
• How information is used
• Third-party sharing (analytics, advertising, integrations)
• Data retention period
• User rights (access, deletion, portability)
• Contact for privacy requests
• Last updated date
• State-specific rights (CA, CO, CT, VA, UT, TX, OR, MT — list applicable)
• Children's privacy (COPPA compliance if applicable)
• International data transfers (if applicable)
• Cookie use

5.2.6 Terms of service (/terms/)

Required sections:

• Acceptance of terms
• Description of service
• User responsibilities
• Intellectual property
• Disclaimers
• Limitation of liability
• Termination
• Governing law
• Changes to terms
• Contact

5.2.7 Accessibility statement (/accessibility/)

Required content:

• Conformance level (WCAG 2.1 or 2.2 Level A, AA, or AAA target)
• Known limitations
• Feedback mechanism (email/form to report accessibility issues)
• Date of last accessibility review
• Compatible assistive technologies

5.2.8 Disclosure page (/disclosure/)

Required content:

• Affiliate relationships
• Sponsored content policy
• Advertising disclosures
• Editorial independence statement
• AI use policy (if applicable)
• Reviewer compensation (if applicable)

5.2.9 YMYL-specific pages (if applicable)

• /editorial-policy/ — Content creation, review, fact-checking process
• /corrections-policy/ — How errors are handled
• /medical-disclaimer/ (health)
• /financial-disclaimer/ (finance)
• /legal-disclaimer/ (legal)

5.2.10 Press/Featured-In page (/press/)

Required content:

• "Featured In" logo grid with links to coverage
• Quotes from coverage with attribution
• Press kit downloads (logos, founder photos, fact sheet, bio)
• Journalist contact form
• Recent press releases (if applicable)

5.2.11 Reviews page (/reviews/)

Required content:

• Aggregate rating display
• Recent verified reviews
• Links to review platforms (Google, Trustpilot, Clutch, BBB)
• Response history visible
• "Leave a review" CTA

5.3 Phase 3: Required Files at Domain Root

5.3.1 /robots.txt

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /staging/
Disallow: /*?*sessionid=
Disallow: /*?*utm_

# AI crawlers — adjust per client preference
User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Claude-Web
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot-Extended
Allow: /

User-agent: anthropic-ai
Allow: /

User-agent: ChatGPT-User
Allow: /

Sitemap: https://{{PRIMARY_DOMAIN}}/sitemap.xml

5.3.2 /sitemap.xml

Generated dynamically, listing all indexable pages with lastmod, separated by sub-sitemap if over 50,000 URLs.

5.3.3 /llms.txt

# {{BUSINESS_NAME}}

> {{BUSINESS_DESCRIPTION_SHORT}}

## About
{{BUSINESS_NAME}} ({{PRIMARY_DOMAIN}}) is {{BUSINESS_DESCRIPTION_LONG_FIRST_PARAGRAPH}}.

Founded by {{FOUNDER_FULL_NAME}} ({{FOUNDER_TITLE}}), {{BUSINESS_NAME}} {{BUSINESS_HISTORY_SUMMARY}}.

## Topics
{{BUSINESS_NAME}} publishes authoritative content on:
{{LIST_OF_PRIMARY_TOPICAL_PILLARS_AS_BULLETS}}

## Key Resources
- [About](https://{{PRIMARY_DOMAIN}}/about/)
- [Contact](https://{{PRIMARY_DOMAIN}}/contact/)
- [Founder Bio](https://{{PRIMARY_DOMAIN}}/authors/{{FOUNDER_SLUG}}/)
{{LIST_OF_TOPICAL_HUB_URLS}}
{{LIST_OF_FLAGSHIP_GUIDE_URLS}}

## Entity References
- Wikidata: https://www.wikidata.org/wiki/{{BUSINESS_WIKIDATA_QID}}
- Founder Wikidata: https://www.wikidata.org/wiki/{{FOUNDER_WIKIDATA_QID}}

## Contact
{{BUSINESS_NAME}}
{{BUSINESS_ADDRESS_STREET}}
{{BUSINESS_ADDRESS_CITY}}, {{BUSINESS_ADDRESS_REGION}} {{BUSINESS_ADDRESS_POSTAL}}
Phone: {{BUSINESS_PHONE_DISPLAY}}
Email: {{BUSINESS_EMAIL}}

## Last Updated
{{LLMS_TXT_LAST_UPDATED_DATE}}

5.3.4 /llms-full.txt

Expanded version of llms.txt containing the full markdown content of the most important pages on the site (About, founder bio, primary topical hub pages, flagship guides). This gives AI training systems full context.

5.3.5 /.well-known/security.txt

Contact: mailto:{{SECURITY_CONTACT_EMAIL}}
Expires: {{ONE_YEAR_FROM_NOW_ISO}}
Preferred-Languages: en
Canonical: https://{{PRIMARY_DOMAIN}}/.well-known/security.txt

5.4 Phase 4: Server Configuration

Apply the security headers configuration from Section 4.4.2.

Set proper redirects (one canonical hostname, www-or-not, trailing-slash policy):

# Force HTTPS
server {
  listen 80;
  server_name {{PRIMARY_DOMAIN}} www.{{PRIMARY_DOMAIN}};
  return 301 https://{{PRIMARY_DOMAIN}}$request_uri;
}

# Force non-www (or www if canonical_www: true)
server {
  listen 443 ssl http2;
  server_name www.{{PRIMARY_DOMAIN}};
  return 301 https://{{PRIMARY_DOMAIN}}$request_uri;
}

Enable Brotli/Gzip compression. Set proper Cache-Control headers (1 year for hashed assets, 1 hour for HTML).

5.5 Phase 5: Footer Trust Block

Implement the footer template from Section 4.4.1 on every page. Verify it renders correctly on:

• Homepage
• Service/product pages
• Article pages
• Policy pages
• Contact page
• 404 page

5.6 Phase 6: Header Trust Elements

Header should include:

• Logo linking to homepage
• Primary navigation
• Phone number (clickable on mobile)
• Optional: trust badge strip ("4.9★ 127 reviews", "BBB Accredited", etc.)

5.7 Phase 7: Initial Site-Wide Validation

After completing Phases 1-6, run validation:

1. Schema validates on every page type (homepage, About, article, contact)
2. SSL Labs A+ rating: https://www.ssllabs.com/ssltest/analyze.html?d={{PRIMARY_DOMAIN}}
3. securityheaders.com A+ rating: https://securityheaders.com/?q={{PRIMARY_DOMAIN}}
4. PageSpeed Insights "Good" CWV scores
5. Robots.txt validates: visit https://{{PRIMARY_DOMAIN}}/robots.txt and confirm sitemap directive
6. Sitemap submitted in GSC
7. All required pages return HTTP 200
8. All policy pages accessible from footer
9. NAP consistent in footer, schema, and contact page

If any check fails, remediate before proceeding to Section 6.

6. Per-Page Installation

What every individual page must include, beyond the site-wide infrastructure.

6.1 Universal Per-Page Requirements

Every page on the site (homepage, services, articles, products, contact, etc.) requires:

6.1.1 Required <head> elements

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- Page-specific title and description -->
  <title>{{PAGE_TITLE}} | {{BUSINESS_NAME}}</title>
  <meta name="description" content="{{PAGE_META_DESCRIPTION}}">

  <!-- Canonical -->
  <link rel="canonical" href="{{PAGE_CANONICAL_URL}}">

  <!-- Robots -->
  <meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1">

  <!-- Language -->
  <meta http-equiv="Content-Language" content="en-US">

  <!-- Open Graph -->
  <meta property="og:type" content="{{OG_TYPE}}">
  <meta property="og:title" content="{{PAGE_TITLE}}">
  <meta property="og:description" content="{{PAGE_META_DESCRIPTION}}">
  <meta property="og:url" content="{{PAGE_CANONICAL_URL}}">
  <meta property="og:image" content="{{PAGE_OG_IMAGE_URL}}">
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta property="og:site_name" content="{{BUSINESS_NAME}}">
  <meta property="og:locale" content="en_US">

  <!-- Twitter Card -->
  <meta name="twitter:card" content="summary_large_image">
  <meta name="twitter:site" content="{{BUSINESS_X_HANDLE}}">
  <meta name="twitter:creator" content="{{AUTHOR_X_HANDLE}}">
  <meta name="twitter:title" content="{{PAGE_TITLE}}">
  <meta name="twitter:description" content="{{PAGE_META_DESCRIPTION}}">
  <meta name="twitter:image" content="{{PAGE_OG_IMAGE_URL}}">

  <!-- Theme color -->
  <meta name="theme-color" content="{{BRAND_PRIMARY_COLOR}}">

  <!-- Favicon set -->
  <link rel="icon" type="image/x-icon" href="/favicon.ico">
  <link rel="icon" type="image/png" sizes="32x32" href="/icon-32.png">
  <link rel="apple-touch-icon" href="/apple-touch-icon.png">
  <link rel="manifest" href="/site.webmanifest">

  <!-- Schema graph (from Section 5.1) -->
  {{SCHEMA_GRAPH_HERE}}

  <!-- Page-specific schema (Article, Service, Product, etc.) -->
  {{PAGE_SPECIFIC_SCHEMA_HERE}}

  <!-- Stylesheets -->
  <link rel="stylesheet" href="/css/main.css">
</head>

6.1.2 Breadcrumb navigation

<nav aria-label="Breadcrumb" class="breadcrumbs">
  <ol>
    <li><a href="/">Home</a></li>
    {{INTERMEDIATE_BREADCRUMBS}}
    <li aria-current="page">{{CURRENT_PAGE_NAME}}</li>
  </ol>
</nav>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type": "ListItem", "position": 1, "name": "Home", "item": "https://{{PRIMARY_DOMAIN}}/"},
    {{INTERMEDIATE_BREADCRUMB_LIST_ITEMS}},
    {"@type": "ListItem", "position": {{N}}, "name": "{{CURRENT_PAGE_NAME}}"}
  ]
}
</script>

6.1.3 Skip-to-content link

First focusable element on every page:

<a href="#main-content" class="skip-to-content">Skip to main content</a>

6.1.4 Single H1, semantic structure

Every page has exactly one <h1>. Heading hierarchy descends without skipping levels. Semantic HTML5 elements (<main>, <article>, <section>, <aside>, <nav>, <footer>) used appropriately.

6.2 Article Page Requirements

In addition to universal requirements:

6.2.1 Article schema

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "{{ARTICLE_URL}}#article",
  "headline": "{{ARTICLE_TITLE}}",
  "description": "{{ARTICLE_DESCRIPTION}}",
  "image": [
    "{{ARTICLE_HERO_IMAGE_URL}}"
  ],
  "datePublished": "{{PUBLISHED_DATE_ISO}}",
  "dateModified": "{{UPDATED_DATE_ISO}}",
  "author": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{AUTHOR_SLUG}}/#person"},
  "publisher": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"},
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "{{ARTICLE_URL}}"
  },
  "isPartOf": {"@id": "https://{{PRIMARY_DOMAIN}}/#website"},
  "about": {
    "@type": "Thing",
    "name": "{{ARTICLE_PRIMARY_TOPIC}}"
  },
  "mentions": {{ARTICLE_MENTIONED_ENTITIES_JSON}},
  "keywords": {{ARTICLE_KEYWORDS_JSON}},
  "wordCount": {{ARTICLE_WORD_COUNT}},
  "articleBody": "{{ARTICLE_BODY_PLAIN_TEXT_FIRST_500_CHARS}}",
  "inLanguage": "en-US",
  "citation": {{ARTICLE_CITATIONS_JSON}}
}
</script>

6.2.2 Article structure

<article class="article" itemscope itemtype="https://schema.org/Article">
  <header class="article-header">
    {{LAST_UPDATED_BANNER}}
    <h1 itemprop="headline">{{ARTICLE_TITLE}}</h1>
    {{AUTHOR_BYLINE}}
    {{AI_DISCLOSURE_IF_APPLICABLE}}
    {{COMMERCIAL_DISCLOSURE_IF_APPLICABLE}}
  </header>

  {{IF_LONG_FORM}}
  <nav class="table-of-contents" aria-label="Article sections">
    <h2>On This Page</h2>
    <ol>
      {{TOC_ITEMS}}
    </ol>
  </nav>
  {{/IF}}

  <div class="article-body" itemprop="articleBody">
    {{ARTICLE_CONTENT}}
  </div>

  <footer class="article-footer">
    {{REFERENCES_SECTION}}
    {{AUTHOR_BOX_FULL}}
    {{RELATED_ARTICLES}}
    {{COMMENTS_SECTION_IF_APPLICABLE}}
  </footer>
</article>

6.2.3 Required article elements

• Last-updated banner at top
• Author byline at top with link to author page
• AI disclosure callout if AI was used
• Commercial disclosure if affiliate/sponsored
• Hero image with proper alt text and credit
• Table of contents if article > 1500 words
• Inline citations for every factual claim
• Original imagery throughout (not just stock)
• "How I know this" or experience callout for practical content
• Failures/edge cases section for long-form practical content
• References section at bottom
• Full author box at bottom
• Related articles section

6.3 Service Page Requirements

6.3.1 Service schema

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "{{SERVICE_URL}}#service",
  "name": "{{SERVICE_NAME}}",
  "description": "{{SERVICE_DESCRIPTION}}",
  "provider": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"},
  "serviceType": "{{SERVICE_TYPE}}",
  "areaServed": {{AREA_SERVED_JSON}},
  "audience": {
    "@type": "BusinessAudience",
    "audienceType": "{{TARGET_AUDIENCE}}"
  },
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "{{SERVICE_NAME}} Tiers",
    "itemListElement": {{SERVICE_TIER_OFFERS_JSON}}
  },
  "termsOfService": "https://{{PRIMARY_DOMAIN}}/terms/",
  "url": "{{SERVICE_URL}}"
}
</script>

6.3.2 Service page structure

• H1 = service name
• Above-the-fold value proposition
• Trust signals (review aggregate, certifications, "featured in")
• Detailed service description
• Pricing tiers with structured data
• Process / what to expect
• Case studies or examples
• FAQ section with FAQPage schema
• Author/expert credit (who delivers the service)
• CTA with conversion form
• Related services

6.4 Local/Location Page Requirements

For each physical location or service area:

6.4.1 LocalBusiness schema (specific to this location)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "{{BUSINESS_TYPE}}",
  "@id": "{{LOCATION_URL}}#localbusiness",
  "name": "{{BUSINESS_NAME}} - {{LOCATION_CITY}}",
  "parentOrganization": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"},
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "{{LOCATION_STREET}}",
    "addressLocality": "{{LOCATION_CITY}}",
    "addressRegion": "{{LOCATION_REGION}}",
    "postalCode": "{{LOCATION_POSTAL}}",
    "addressCountry": "{{LOCATION_COUNTRY}}"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": "{{LOCATION_LATITUDE}}",
    "longitude": "{{LOCATION_LONGITUDE}}"
  },
  "telephone": "{{LOCATION_PHONE}}",
  "openingHoursSpecification": {{LOCATION_HOURS_JSON}},
  "areaServed": {{LOCATION_AREA_SERVED_JSON}},
  "url": "{{LOCATION_URL}}"
}
</script>

6.4.2 Location page structure

• H1 with city/location name
• Embedded map
• NAP block matching schema exactly
• Local-specific content (not generic)
• Local testimonials when available
• Local case studies
• Service area description with neighborhoods/cities served
• "Get directions" CTA
• Local phone number (clickable)
• Photos of physical location if applicable

6.5 Product Page Requirements

6.5.1 Product schema

Per Section 4.4.8 + Tier 11 PDO requirements (full Product schema with offers, ratings, returns, shipping).

6.5.2 Product page structure

• H1 = product name
• Multiple high-quality product images
• Price with structured data
• Availability indicator
• Reviews with Review schema
• Aggregate rating display
• Product description with specifications
• Trust signals (returns policy, shipping info, security badges)
• Add-to-cart or buy CTA
• Related products

6.6 Per-Page Validation

After each page is built/updated, validate:

1. View source — confirm all required <head> elements present
2. Run page through Google Rich Results Test
3. Run page through Schema.org validator
4. Check breadcrumbs render correctly
5. Verify single H1, proper heading hierarchy
6. Test on mobile (real device or DevTools mobile emulation)
7. Run Lighthouse — Performance, Accessibility, Best Practices, SEO scores
8. Check Open Graph rendering at https://opengraph.dev/ or https://www.opengraph.xyz/

7. Per-Author Installation

Every contributor to the site needs full author entity infrastructure. This section applies to founder, employees, freelancers, and any other bylined author.

7.1 Author Page Requirements

Build at /authors/{{author-slug}}/. Required content:

7.1.1 Header section

<header class="author-page-header">
  <img
    src="{{AUTHOR_PHOTO_URL}}"
    alt="{{AUTHOR_NAME}}"
    width="240"
    height="240"
    class="author-photo">

  <h1>{{AUTHOR_FULL_NAME}}</h1>
  <p class="author-title">{{AUTHOR_TITLE}}</p>

  <ul class="author-credentials-summary">
    {{LIST_OF_CREDENTIALS}}
  </ul>

  <ul class="author-social-links">
    <li><a href="{{LINKEDIN_URL}}" rel="me noopener">LinkedIn</a></li>
    <li><a href="{{X_URL}}" rel="me noopener">X</a></li>
    <li><a href="{{GITHUB_URL}}" rel="me noopener">GitHub</a></li>
    <li><a href="https://www.wikidata.org/wiki/{{WIKIDATA_QID}}" rel="me noopener">Wikidata</a></li>
  </ul>
</header>

7.1.2 Bio section

200-400 words covering:

• Background and how they came to this work
• Specific experience and achievements
• Topics of expertise (matching knowsAbout in schema)
• Personal touch — what makes their perspective unique
• Why readers should trust their content

7.1.3 Credentials section

Detailed list of:

• Degrees with institution and year
• Professional certifications
• Industry memberships
• Awards and recognition
• Years of experience per topic area

7.1.4 Published externally section

<section class="author-external-publications">
  <h2>Published Externally</h2>
  <ul>
    {{LIST_OF_EXTERNAL_PUBLICATIONS_WITH_LINKS_AND_DATES}}
  </ul>
</section>

7.1.5 Speaking history section

<section class="author-speaking">
  <h2>Conference & Podcast Appearances</h2>
  <ul>
    {{LIST_OF_SPEAKING_ENGAGEMENTS}}
  </ul>
</section>

7.1.6 Recent articles section

Auto-populated list of recent articles by this author with dates and topics.

7.1.7 Contact section

How readers/journalists can contact the author. Email, contact form, LinkedIn, or phone as appropriate.

7.1.8 Person schema

Full Person schema as shown in Section 4.2.2, with all properties populated.

7.2 Author Hub Page

Build at /authors/. Required content:

<article class="authors-hub">
  <h1>Our Authors</h1>
  <p>{{INTRODUCTION_TO_TEAM}}</p>

  <div class="author-grid">
    {{FOR_EACH_AUTHOR}}
    <article class="author-card" itemscope itemtype="https://schema.org/Person">
      <a href="/authors/{{AUTHOR_SLUG}}/">
        <img src="{{AUTHOR_PHOTO}}" alt="{{AUTHOR_NAME}}" width="200" height="200" itemprop="image">
        <h2 itemprop="name">{{AUTHOR_NAME}}</h2>
        <p itemprop="jobTitle">{{AUTHOR_TITLE}}</p>
        <p>{{AUTHOR_SHORT_BIO}}</p>
      </a>
    </article>
    {{/FOR_EACH}}
  </div>
</article>

7.3 Author Cross-Linking Pattern

Every article must link to the author's hub page via rel="author" in the byline.

Every author page must list articles authored by that person.

Every author should be referenced in Article schema via @id, not by re-declaring the Person.

7.4 Author Identity Verification

For maximum trust, verify each author's external profiles via rel="me" reciprocal linking:

• Author's LinkedIn profile lists the website in About section
• Author's X profile lists the website in bio
• Author's GitHub profile lists the website
• Author's Wikidata entry references the website
• Each external profile gets rel="me" from the author page on the site

This creates a verifiable identity web that search engines and AI engines can validate.

7.5 Per-Author Validation

After each author page is built:

1. Person schema validates with zero errors
2. All sameAs URLs return HTTP 200
3. Reciprocal rel="me" linking confirmed on at least 3 external profiles
4. Author page accessible from /authors/ hub
5. At least one article links to author page via byline
6. Wikidata entry exists and is referenced (high-priority for founders)

8. Per-Content-Type Installation

Specific implementation per content type. Each content type gets its own schema, structural requirements, and signals.

8.1 Blog Article / Editorial Content

See Section 6.2.

8.2 Service Pages

See Section 6.3.

8.3 Product Pages

See Section 6.5.

8.4 Local Landing Pages

See Section 6.4.

8.5 Case Studies

Schema: Article with detailed result properties.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "{{CASE_STUDY_TITLE}}",
  "about": [
    {"@type": "Organization", "name": "{{CLIENT_NAME}}"},
    {"@type": "Service", "name": "{{SERVICE_PROVIDED}}"}
  ],
  "mentions": {{SERVICES_MENTIONED_JSON}},
  "datePublished": "{{PUBLISHED_DATE}}",
  "author": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{AUTHOR_SLUG}}/#person"},
  "publisher": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"}
}
</script>

Required structure:

• Client/situation overview
• Challenge or problem
• Approach taken
• Solution implemented
• Quantified results
• Client testimonial
• Service tags linking to relevant service pages

8.6 Tutorial / How-To Content

Schema: HowTo schema with full step-by-step structure.

Required elements:

• Estimated time
• Difficulty level
• Required tools/materials
• Numbered steps with images per step
• Troubleshooting section
• Downloadable resources where applicable

8.7 Research / Original Data

Schema: ScholarlyArticle + Dataset.

Required elements:

• Methodology section
• Sample size and source
• Date range of data collection
• Findings with visualizations
• Downloadable raw data (CSV, JSON)
• Citation block (APA, MLA, BibTeX)
• License (CC-BY recommended)
• Author with credentials

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "name": "{{DATASET_NAME}}",
  "description": "{{DATASET_DESCRIPTION}}",
  "creator": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{AUTHOR_SLUG}}/#person"},
  "publisher": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"},
  "datePublished": "{{PUBLISHED_DATE}}",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "distribution": [
    {
      "@type": "DataDownload",
      "encodingFormat": "text/csv",
      "contentUrl": "{{CSV_URL}}"
    },
    {
      "@type": "DataDownload",
      "encodingFormat": "application/json",
      "contentUrl": "{{JSON_URL}}"
    }
  ]
}
</script>

8.8 Reviews

Schema: Review with detailed evaluation.

Required elements:

• Specific product/service tested
• Testing methodology
• How long the reviewer used the product
• Author credit with relevant experience
• Pros and cons sections (real ones, not marketing fluff)
• Comparison with alternatives
• Disclosure if compensated or received free product
• Original photos of the product in use

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Review",
  "itemReviewed": {
    "@type": "Product",
    "name": "{{PRODUCT_NAME}}"
  },
  "author": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{AUTHOR_SLUG}}/#person"},
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "{{RATING}}",
    "bestRating": "5"
  },
  "datePublished": "{{REVIEW_DATE}}",
  "publisher": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"}
}
</script>

8.9 Tools / Calculators / Interactive Content

Schema: SoftwareApplication or WebApplication.

Required elements:

• Clear "what this does" description above the tool
• Author and methodology behind the tool
• How calculations are performed (transparency)
• Data sources if applicable
• Last-updated date
• Disclaimer about limitations

8.10 Glossary / Definition Pages

Schema: DefinedTerm or DefinedTermSet.

Required elements:

• H1 = term being defined
• Concise definition above the fold
• Detailed explanation
• Related terms cross-linked
• Source citations
• Author credit

8.11 News / Press Release Content

Schema: NewsArticle.

Required elements:

• Dateline (location and date)
• Lead paragraph with 5W summary
• Quotes from named sources
• Background context
• Boilerplate "About" section
• Press contact

9. YMYL Decision Tree & Adjustments

9.1 YMYL Classification Decision Tree

Determine YMYL status using this decision tree:

Does the content cover:
├── Health, medical, fitness advice? → YMYL (health)
├── Financial advice, investing, taxes, banking? → YMYL (finance)
├── Legal advice, court info, government info? → YMYL (legal/civic)
├── Safety information (driving, parenting, occupational)? → YMYL (safety)
├── Major life decisions (career, education, relationships)? → YMYL (significant)
├── News and current events? → YMYL (information integrity)
├── E-commerce / shopping? → YMYL (lite — held to higher standards but not full YMYL)
└── None of the above? → Non-YMYL standard

9.2 YMYL-Specific Requirements

Experience pillar adjustments:

• Document direct involvement with the topic at higher specificity
• "How I tested" sections are non-negotiable
• Original imagery requirements heightened (stock imagery is a red flag for YMYL)

Expertise pillar adjustments:

• Author must hold formal credentials in the relevant field, OR
• Content must be reviewed by a credentialed expert with reviewer credit displayed
• Citations to primary literature only (not secondary aggregators)
• Outdated content is a Trust violation in YMYL — refresh cadence is monthly, not quarterly, for time-sensitive topics

Authoritativeness pillar adjustments:

• Recognition by relevant industry/regulatory bodies required
• Wikipedia presence carries more weight
• Backlinks from authoritative YMYL-niche sources (medical journals, financial publications, legal directories)

Trustworthiness pillar adjustments:

• All standard Trust requirements PLUS:
• Editorial policy page mandatory
• Corrections policy page mandatory
• Medical/professional reviewer credit on every article
• Topic-specific disclaimer on every article
• Disclosure of any conflicts of interest
• Sources from primary literature
• More frequent freshness updates

9.3 YMYL Audit Adjustments

YMYL sites must score 90%+ across all four pillars to be considered compliant. Standard sites can pass at 80%+.

9.4 If You Cannot Meet YMYL Standards

If a site covers YMYL topics but cannot meet credentialing requirements (e.g., a personal finance blog written by someone without a CFP), the honest answer is: don't write that content as definitive advice. Instead, frame it as personal experience ("How I paid off $50k in debt") rather than authoritative guidance ("How to manage debt"). Personal-experience YMYL content is held to lower expertise standards but still requires full Trust compliance.

10. Stack-Specific Implementation Notes

The framework is technology-agnostic at its core, but implementation details vary by stack.

10.1 Vanilla HTML / Server-Rendered HTML / Plain PHP

Where to put schema: In a shared header include (includes/head.php or equivalent) for site-wide schema. Per-page schema in the page template itself.

Where to put trust elements: Footer include for footer trust block. Header include for header trust badges. Per-article templates for article-specific trust elements.

Build authors as: Static pages at /authors/{slug}/index.html or PHP route at /authors.php?slug=....

Sitemap: Generate via build script or PHP cron job, output to /sitemap.xml.

10.2 WordPress

Schema implementation: Use Yoast SEO Premium, Rank Math Pro, or SEOPress with custom JSON-LD support. For complete control, use a custom plugin or functions.php with wp_head hook.

function inject_eeat_schema_graph() {
  $schema = array(/* schema graph from Section 5.1 */);
  echo '<script type="application/ld+json">' . json_encode($schema) . '</script>';
}
add_action('wp_head', 'inject_eeat_schema_graph');

Author pages: Use WordPress's native author archives at /author/{username}/, but enhance them via a custom author template (author.php) that includes all required Person schema and content elements.

Build per-author Person schema:

function inject_author_schema() {
  if (is_author()) {
    $author = get_queried_object();
    $schema = array(
      '@context' => 'https://schema.org',
      '@type' => 'Person',
      'name' => $author->display_name,
      // ... etc
    );
    echo '<script type="application/ld+json">' . json_encode($schema) . '</script>';
  }
}
add_action('wp_head', 'inject_author_schema');

ACF (Advanced Custom Fields) is highly recommended for storing author credentials, sameAs links, knowsAbout topics, and other E-E-A-T metadata in structured form.

10.3 Next.js (App Router)

Schema: Use Next.js metadata API for OG/Twitter tags. For JSON-LD, inject via <script> tag in layouts or page components.

// app/layout.tsx
import { businessSchemaGraph } from '@/lib/schema/organization';

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <head>
        <script
          type="application/ld+json"
          dangerouslySetInnerHTML={{
            __html: JSON.stringify(businessSchemaGraph)
          }}
        />
      </head>
      <body>{children}</body>
    </html>
  );
}

Authors: Build dynamic routes at app/authors/[slug]/page.tsx. Generate static params for known authors.

Sitemap: Use Next.js built-in app/sitemap.ts:

export default function sitemap() {
  return [
    { url: 'https://example.com', lastModified: new Date() },
    // ... etc
  ];
}

Robots: app/robots.ts.

10.4 Astro

Schema: Inject via <head> slot in the layout component or via a dedicated <SchemaGraph /> component.

---
// src/layouts/Layout.astro
import { schemaGraph } from '../lib/schema';
---
<html lang="en">
  <head>
    <script type="application/ld+json" set:html={JSON.stringify(schemaGraph)} />
    <slot name="head" />
  </head>
  <body>
    <slot />
  </body>
</html>

Authors: Use Astro Content Collections. Create a src/content/authors/ collection with TypeScript schema for required fields.

Sitemap: Use @astrojs/sitemap integration.

10.5 Hugo

Schema: In layouts/partials/head.html, render the schema graph using Hugo template syntax with site/page variables.

Authors: Use Hugo's data files (data/authors/) and dedicated author templates.

Sitemap: Hugo generates automatically. Customize via layouts/sitemap.xml.

10.6 Shopify

Schema: Modify theme.liquid to inject schema graph. Use Shopify's {{ shop }} and {{ product }} Liquid objects to populate variables.

Authors: Use blog author field. Customize article.liquid to include author schema.

Limitations: Shopify themes have less control over server headers and some technical SEO elements. Use Cloudflare in front of Shopify for additional control over headers.

10.7 Webflow

Schema: Use Webflow's "Embed" element to insert JSON-LD scripts. Site-wide schema goes in custom code section of project settings.

Limitations: Webflow's CMS has authoring constraints. For multi-author sites with complex schema needs, consider a different stack.

10.8 Universal Stack-Agnostic Pattern

Regardless of stack:

1. Centralize variables in a single config file (eeat-variables.yml from Section 2)
2. Build schema templates that reference variables
3. Render schema in shared head include / layout / template
4. Per-page schema rendered by page-specific template, referencing site-wide schema via @id
5. Validate continuously as part of CI/CD pipeline

11. Validation Protocol

After installation, verify the framework is correctly installed.

11.1 Automated Validation

11.1.1 Schema validation

for url in $URLS; do
  curl -sL "$url" | python -c "
import sys, re, json
html = sys.stdin.read()
matches = re.findall(r'<script type=\"application/ld\+json\">(.*?)</script>', html, re.DOTALL)
for m in matches:
    try:
        json.loads(m)
        print(f'{url}: schema parses')
    except:
        print(f'{url}: SCHEMA INVALID')
        sys.exit(1)
"
done

Then run each schema through Google's Rich Results Test API or Schema.org validator.

11.1.2 Header validation

curl -sI https://{{PRIMARY_DOMAIN}}/ | grep -E "^(Strict-Transport-Security|Content-Security-Policy|X-Content-Type-Options|X-Frame-Options|Referrer-Policy|Permissions-Policy)"

All required headers must be present.

11.1.3 SSL validation

echo | openssl s_client -servername {{PRIMARY_DOMAIN}} -connect {{PRIMARY_DOMAIN}}:443 2>/dev/null | openssl x509 -noout -dates

Run through SSL Labs API to confirm A+ rating.

11.1.4 Required pages validation

REQUIRED_PAGES=(
  "/about/"
  "/contact/"
  "/authors/"
  "/privacy/"
  "/terms/"
  "/accessibility/"
  "/disclosure/"
  "/press/"
  "/reviews/"
  "/sitemap.xml"
  "/robots.txt"
  "/llms.txt"
)

for page in "${REQUIRED_PAGES[@]}"; do
  status=$(curl -o /dev/null -s -w "%{http_code}" "https://{{PRIMARY_DOMAIN}}$page")
  if [ "$status" != "200" ]; then
    echo "FAIL: $page returned $status"
  else
    echo "PASS: $page"
  fi
done

11.1.5 NAP consistency

Check that footer NAP, schema NAP, and contact page NAP all match exactly. Compare strings.

11.1.6 Author page validation

For each author in the system:

• Page exists at /authors/{slug}/
• Returns HTTP 200
• Contains Person schema
• Contains required content sections
• All sameAs URLs return HTTP 200

11.2 Manual Validation

11.2.1 Content quality checks

• Random-sample articles and verify each has author byline, last-updated banner, citations
• Check that "experience callouts" feel authentic, not boilerplate
• Verify failure/edge-case sections are substantive
• Confirm original imagery isn't actually stock photos with metadata stripped

11.2.2 Brand consistency checks

• Search the brand name in Google. Top 10 results should be 100% owned/favorable.
• Search "{{brand}} reviews" — verify reputation is positive
• Check Knowledge Panel populates correctly (if it appears)

11.2.3 AI engine checks

• Test brand queries in ChatGPT, Perplexity, Claude, Gemini
• Verify accurate description of business
• Check that AI engines cite the site for relevant queries
• Document any inaccuracies for correction

11.2.4 Mobile checks

• Test on real mobile device (iPhone + Android)
• Verify trust signals visible
• Confirm tap targets meet 48px minimum
• Check that schema validators can render mobile pages

11.3 Pre-Launch Checklist

Before declaring the framework installed, all items must pass:

• [ ] Schema graph validates on every page type
• [ ] All required pages exist and return HTTP 200
• [ ] HSTS preload submitted
• [ ] securityheaders.com A+ rating
• [ ] SSL Labs A+ rating
• [ ] Lighthouse Performance score 90+
• [ ] Lighthouse Accessibility score 95+
• [ ] Lighthouse SEO score 100
• [ ] PageSpeed Insights "Good" CWV ratings
• [ ] All author pages built and validated
• [ ] All sameAs URLs return 200
• [ ] Wikidata QID confirmed and referenced (or scheduled for creation)
• [ ] Footer NAP matches schema NAP exactly
• [ ] Top 50 citation sources NAP matches site NAP
• [ ] Cookie consent blocks scripts pre-consent
• [ ] Privacy policy reviewed by qualified legal counsel
• [ ] All policy pages accessible from every page footer
• [ ] If YMYL: editorial policy, corrections policy, reviewer credits all in place
• [ ] AI disclosure published if AI is used in content
• [ ] Implementation report generated (Section 17)

12. Audit Mode

This section is for evaluating an existing site against the framework.

12.1 Audit Workflow

1. Gather variables (Section 2) about the existing business
2. Crawl the site to inventory pages, schemas, and trust elements
3. Score each pillar using the audit criteria (Sections 4.1-4.4)
4. Compile findings into the audit report (template in Section 17.2)
5. Prioritize remediation by severity

12.2 Audit Scoring Rubric

For each criterion in Sections 4.1-4.4:

• Pass (2 points): Fully implemented to world-class standard
• Partial (1 point): Implemented but with gaps or quality issues
• Fail (0 points): Not implemented or implemented incorrectly
• N/A: Genuinely doesn't apply (rare — most criteria apply universally)

Calculate per-pillar scores:

12.3 Critical-Severity Failures

A site cannot be "world-class" if any Critical-severity item fails, regardless of total score. Critical-severity items must be remediated before any other work.

12.4 Audit Output

Generate an audit report following the template in Section 17.2.

13. Maintenance Schedule

E-E-A-T is not "set and forget." Maintain on this cadence:

13.1 Daily

• Monitor brand mentions for new earned media or sentiment shifts
• Respond to new reviews within 24 hours
• Monitor uptime and SSL status
• Triage any GSC manual actions or security warnings immediately

13.2 Weekly

• Review GSC Performance report for ranking changes
• Update one decay-flagged article from refresh queue
• Check for new earned media to add to Featured-In page
• Review AI citation tracking dashboard

13.3 Monthly

• Audit NAP consistency across top 50 citations
• Update Wikipedia and Wikidata if business changes occur
• Refresh top 5 highest-traffic articles with current data
• Run full Lighthouse and PageSpeed audit
• Review and respond to all reviews
• Audit broken links and fix
• Update llms.txt and llms-full.txt with new flagship content
• Generate monthly E-E-A-T report (template in Section 17.3)

13.4 Quarterly

• Full schema validation across all page types
• Author page review — credentials current, sameAs links valid, recent publications added
• Press kit refresh
• Privacy policy review for new state laws / regulatory changes
• AI disclosure policy review
• Backlink audit and disavow if necessary
• Conduct internal E-E-A-T audit using Section 12 framework
• Update 25% of evergreen content
• Re-validate all redirects and broken-link recovery

13.5 Annually

• Comprehensive E-E-A-T audit (full Section 12 evaluation)
• Renew trust badges and certifications
• Refresh all author photos if needed
• Review and update editorial policy
• Strategic review of topical pillars — should any be retired or new ones added?
• Re-architect site structure if topical authority has shifted
• Comprehensive accessibility audit (WCAG)

13.6 On Algorithm Updates

Within 7-14 days of any confirmed Google core update:

1. Document the update in the algorithm update incident log
2. Review traffic and ranking changes per page
3. Run full E-E-A-T audit on most-affected pages
4. Identify common factors among winners and losers
5. Adjust strategy if patterns emerge
6. Generate post-update report (template in Section 17.4)

14. Cross-Reference to the 14-Tier Framework

E-E-A-T is implemented across multiple tiers in the broader framework:

14.1 Tier 1 (Foundation) Items Supporting E-E-A-T

• TSO — Technical SEO supports Trust via clean technical foundation
• SDO — Structured Data Optimization implements Organization/Person schema (Trust + Authoritativeness)
• SSO — Site Security supports Trust pillar (HTTPS, HSTS, CSP)
• GCO — GDPR/Compliance supports Trust pillar (privacy, consent)
• EEA — E-E-A-T Entity Optimization implements core Person schema with sameAs

14.2 Tier 2 (Search Visibility) Items Supporting E-E-A-T

• ETO — E-E-A-T Content Trust Optimization implements per-article trust signals
• AAO — Author Authority Optimization implements Person schema and author pages
• CBO — Content Brief Optimization ensures every article meets E-E-A-T criteria pre-publish

14.3 Tier 3 (AI Domination) Items Supporting E-E-A-T

• EEO — Entity Engine Optimization extends Authoritativeness via entity graph
• KGO — Knowledge Graph Optimization claims Knowledge Panel (Authoritativeness)
• WIK — Wikipedia & Wikidata Optimization is foundational for Authoritativeness
• VCO — Verifiable Claims Optimization is foundational for Trust

14.4 Tier 4 (Entity & Authority) Items Supporting E-E-A-T

• PBO — Personal Brand Optimization extends founder Person entity
• FBO — Founder-Led Content extends Experience and Expertise per article
• REO/RMO — Reputation/Review Management extends Trust
• DPR/EAO/EXO — Earned media extends Authoritativeness
• TLO — Thought Leadership extends Expertise

14.5 Implementation Order When E-E-A-T Is the Priority

If E-E-A-T improvement is the explicit priority for a site, implement in this order:

1. Trust foundations first (Tier 1 SSO, GCO; Section 5 of this doc — required pages, security headers)
2. Author entity infrastructure (Tier 2 AAO; Section 7 of this doc)
3. Site-wide schema graph (Tier 1 EEA; Section 5.1 of this doc)
4. Per-article trust signals (Tier 2 ETO; Section 6.2 of this doc)
5. Wikidata and external entity work (Tier 3 WIK)
6. Earned media (Tier 4 EAO, DPR, EXO)
7. Original research and thought leadership (Tier 4 TLO)
8. Knowledge Panel (Tier 3 KGO)

This order maximizes early Trust gains (which Google weights most heavily) while compounding longer-term Authoritativeness work.

15. Common Mistakes & Anti-Patterns

These are the patterns that look like compliance but actually fail or backfire.

15.1 Schema Without Substance

Anti-pattern: Adding Person schema with hasCredential listing degrees the author doesn't actually have, or knowsAbout topics the author hasn't demonstrably covered.

Why it fails: Google's algorithm increasingly cross-validates schema claims against content evidence. Claiming expertise the content doesn't support is a Trust violation that can trigger manual review.

Fix: Only declare in schema what's genuinely verifiable in content and external profiles.

15.2 Generic Author Pages

Anti-pattern: Author pages with stock photo, generic bio ("John is a writer who loves SEO"), no credentials, no external profiles, no article cross-linking.

Why it fails: This is worse than no author page — it tells Google's algorithm the author is fabricated.

Fix: Real photo, specific bio with verifiable claims, credentials, external profile links, recent article list.

15.3 Stock Photos Everywhere

Anti-pattern: Every image on the site is a stock photo, including author photos and "behind the scenes" content.

Why it fails: Reverse image search reveals stock photo origin, undermining Experience signal and Trust.

Fix: Original imagery for author photos, real product/process shots, original diagrams. Stock photos acceptable only for purely illustrative purposes (clearly not pretending to be original).

15.4 Last-Updated Lying

Anti-pattern: Updating only the date on articles to make them appear fresh, without actually updating content.

Why it fails: Google's algorithm detects this pattern. Updating dateModified without meaningful content changes is a Trust violation.

Fix: Genuine refreshes — new sections, updated stats, new examples, removed outdated information. Document what was updated.

15.5 Fake Reviews

Anti-pattern: Buying reviews, pressuring employees to leave reviews, reviewing competitors negatively, displaying fabricated testimonials.

Why it fails: Detection rate has gone up dramatically. One detection collapses Trust across the entire site. Plus: FTC violations.

Fix: Genuine review acquisition workflow, respond to all reviews, accept that legitimate negative reviews are healthy.

15.6 Hidden Affiliate Disclosure

Anti-pattern: Affiliate disclosure buried in footer, in tiny text, after the affiliate links.

Why it fails: FTC requires "clear and conspicuous" disclosure. Hidden disclosure is Trust violation + legal risk.

Fix: Disclosure at top of article, before any affiliate link, in normal-size text.

15.7 Generic Trust Badges Without Verification

Anti-pattern: Displaying "BBB Accredited" badge when not actually accredited, or trust badges with no verification link.

Why it fails: Easily verified as fraudulent. Catastrophic Trust violation if discovered.

Fix: Only display badges actually held. Always include verification link.

15.8 Boilerplate Disclaimer Walls

Anti-pattern: Long generic disclaimers and policies that are clearly templated, never updated, and don't reflect actual practices.

Why it fails: Privacy policies that don't match actual data collection practices are GDPR/CCPA violations and Trust failures.

Fix: Customized policies reflecting actual practices. Have qualified counsel review.

15.9 NAP Drift

Anti-pattern: Phone number formatted differently in footer vs schema vs Google Business Profile vs Yelp.

Why it fails: Google sees these as potentially-different businesses, fragmenting authority and confusing local rankings.

Fix: One canonical NAP format. Update everywhere when anything changes.

15.10 AI Content Without Disclosure

Anti-pattern: Publishing AI-generated content without review and without disclosure, then claiming it's expert-authored.

Why it fails: Detection is improving. Discovery is reputation-destroying. Plus: it's deceptive.

Fix: Either don't publish unreviewed AI content, or be transparent about AI use and review process.

15.11 Vanity Metrics in Authoritativeness

Anti-pattern: Buying followers, bot likes, engagement pods to inflate social proof signals.

Why it fails: Quality signals have gotten sophisticated. Inflated metrics with no engagement quality undermine authority.

Fix: Earn followers and engagement organically. Quality over quantity.

15.12 Gaming Knowledge Panel

Anti-pattern: Manipulating Wikipedia entries to pad Knowledge Panel data; spamming Wikidata with unverified claims.

Why it fails: Wikipedia editors are vigilant. Wikidata has data quality processes. Discovery results in entry deletion and trust damage.

Fix: Build genuine notability over time. Create Wikidata entries with verifiable references. Let Wikipedia happen organically when notability supports it.

16. Complete Code & Schema Library

Quick-reference appendix. All code blocks from the document, organized for fast lookup.

16.1 Site-Wide Schema Graph

See Section 5.1.

16.2 Article Schema (Standard)

See Section 6.2.1.

16.3 Article Schema (YMYL)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalWebPage",
  "headline": "{{TITLE}}",
  "author": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{AUTHOR_SLUG}}/#person"},
  "reviewedBy": {"@id": "https://{{PRIMARY_DOMAIN}}/authors/{{REVIEWER_SLUG}}/#person"},
  "datePublished": "{{PUBLISHED_DATE}}",
  "dateModified": "{{UPDATED_DATE}}",
  "lastReviewed": "{{LAST_MEDICAL_REVIEW_DATE}}",
  "publisher": {"@id": "https://{{PRIMARY_DOMAIN}}/#organization"},
  "specialty": {
    "@type": "MedicalSpecialty",
    "name": "{{MEDICAL_SPECIALTY}}"
  },
  "audience": {
    "@type": "MedicalAudience",
    "audienceType": "Patient"
  }
}
</script>

16.4 Person Schema (Full)

See Section 4.2.2.

16.5 Organization Schema (Full)

See Section 5.1.

16.6 LocalBusiness Schema

See Section 6.4.1.

16.7 Service Schema

See Section 6.3.1.

16.8 Review and AggregateRating Schema

See Section 4.4.8.

16.9 BreadcrumbList Schema

See Section 6.1.2.

16.10 HowTo Schema

See Tier 6 TCO documentation in tier-six.md.

16.11 FAQPage Schema

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "{{QUESTION_1}}",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "{{ANSWER_1}}"
      }
    },
    {
      "@type": "Question",
      "name": "{{QUESTION_2}}",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "{{ANSWER_2}}"
      }
    }
  ]
}
</script>

16.12 Author Box HTML

See Section 4.2.1.

16.13 Last-Updated Banner HTML

See Section 4.4.3.

16.14 Footer Trust Block HTML

See Section 4.4.1.

16.15 Featured-In Section HTML

See Section 4.3.2.

16.16 Cite-This Section HTML

See Section 4.3.6.

16.17 AI Disclosure Callout HTML

See Section 4.4.6.

16.18 Affiliate Disclosure HTML

See Section 4.4.7.

16.19 YMYL Article Header HTML

See Section 4.4.12.

16.20 Custom 404 Page HTML

See Section 4.4.9.

16.21 Server Configuration (nginx)

See Section 4.4.2.

16.22 robots.txt

See Section 5.3.1.

16.23 llms.txt

See Section 5.3.3.

16.24 Cookie Consent Mode v2

See Section 4.4.11.

17. Implementation/Audit Report Templates

17.1 Implementation Report Template

When installation is complete, generate EEAT-IMPLEMENTATION-REPORT.md in project root:

# E-E-A-T Framework Implementation Report

**Project**: {{BUSINESS_NAME}}
**Domain**: {{PRIMARY_DOMAIN}}
**Tech Stack**: {{TECH_STACK}}
**Implementation Date**: {{TODAY}}
**Implemented By**: {{IMPLEMENTER}}

---

## Summary

- **YMYL Classification**: {{YMYL_STATUS}}
- **Pillars Installed**: Experience, Expertise, Authoritativeness, Trustworthiness
- **Site-Wide Pages Created**: {{COUNT}}
- **Author Pages Created**: {{COUNT}}
- **Schema Types Implemented**: {{LIST}}
- **Validation Status**: {{PASS/PARTIAL/FAIL}}

## Files Modified

{{LIST_OF_FILES_MODIFIED_OR_CREATED}}

## Schema Implementations

| Page Type | Schema Type | Status |
|---|---|---|
{{ROWS}}

## Validation Results

### Automated Checks
{{RESULTS_OF_EACH_AUTOMATED_CHECK}}

### Manual Checks
{{RESULTS_OF_EACH_MANUAL_CHECK}}

## Items Skipped or Flagged for Manual Review

{{LIST_WITH_REASONS}}

## Critical Items Requiring Follow-Up

{{LIST_OF_CRITICAL_PENDING_ITEMS}}

## Next Steps

{{RECOMMENDED_NEXT_STEPS}}

## Maintenance Schedule

The site requires ongoing maintenance per Section 13 of the framework document.
- Weekly tasks: {{LIST}}
- Monthly tasks: {{LIST}}
- Quarterly tasks: {{LIST}}
- Annual tasks: {{LIST}}

## Sign-Off

Implementation complete: {{DATE}}
Implementer: {{NAME}}
Reviewed by: {{REVIEWER}}

17.2 Audit Report Template

When audit is complete, generate EEAT-AUDIT-REPORT.md:

# E-E-A-T Framework Audit Report

**Site Audited**: {{BUSINESS_NAME}}
**Domain**: {{PRIMARY_DOMAIN}}
**Audit Date**: {{TODAY}}
**Auditor**: {{AUDITOR}}
**YMYL Classification**: {{YMYL_STATUS}}

---

## Executive Summary

{{ONE_PARAGRAPH_OVERALL_ASSESSMENT}}

**Overall Score**: {{TOTAL_SCORE}}/130 ({{PERCENTAGE}}%)
**World-Class Threshold**: {{THRESHOLD}} ({{YMYL_OR_STANDARD}})
**Status**: {{WORLD_CLASS / NEAR_WORLD_CLASS / NEEDS_IMPROVEMENT / CRITICAL_GAPS}}

## Pillar-by-Pillar Scores

| Pillar | Score | Max | Threshold | Status |
|---|---|---|---|---|
| Experience | {{X}}/20 | 20 | 17 | {{STATUS}} |
| Expertise | {{X}}/24 | 24 | 20 | {{STATUS}} |
| Authoritativeness | {{X}}/30 | 30 | 25 | {{STATUS}} |
| Trustworthiness | {{X}}/56 | 56 | 50 | {{STATUS}} |
| **Total** | **{{X}}/130** | **130** | **112** | **{{STATUS}}** |

## Critical Failures (Immediate Remediation Required)

{{LIST_WITH_REMEDIATION_STEPS}}

## High-Severity Issues

{{LIST_WITH_REMEDIATION_STEPS}}

## Medium-Severity Issues

{{LIST_WITH_REMEDIATION_STEPS}}

## Low-Severity Issues

{{LIST_WITH_REMEDIATION_STEPS}}

## Strengths

{{ITEMS_THAT_SCORED_PASS}}

## Detailed Findings

### Experience Pillar ({{X}}/20)
{{DETAILED_FINDINGS_PER_CRITERION}}

### Expertise Pillar ({{X}}/24)
{{DETAILED_FINDINGS_PER_CRITERION}}

### Authoritativeness Pillar ({{X}}/30)
{{DETAILED_FINDINGS_PER_CRITERION}}

### Trustworthiness Pillar ({{X}}/56)
{{DETAILED_FINDINGS_PER_CRITERION}}

## Recommended Remediation Order

1. {{HIGHEST_PRIORITY_ITEM}} — Estimated effort: {{HOURS}}
2. {{NEXT_PRIORITY_ITEM}} — Estimated effort: {{HOURS}}

**Total estimated remediation effort**: {{HOURS}}

## Re-Audit Recommendation

Recommended re-audit date: {{DATE_3_MONTHS_OUT}}

## Sign-Off

Audit complete: {{DATE}}
Auditor: {{NAME}}
Reviewed by: {{REVIEWER}}

17.3 Monthly Maintenance Report Template

# E-E-A-T Monthly Maintenance Report — {{MONTH}} {{YEAR}}

**Site**: {{BUSINESS_NAME}}
**Period**: {{START_DATE}} to {{END_DATE}}

## Activity Summary

- Articles refreshed: {{COUNT}}
- New earned media added to Featured-In: {{COUNT}}
- Reviews responded to: {{COUNT}} ({{POSITIVE}} positive, {{NEGATIVE}} negative)
- Broken links fixed: {{COUNT}}
- Schema validations run: {{COUNT}}
- Lighthouse audits run: {{COUNT}}

## Trust Pillar Status

- SSL Labs grade: {{GRADE}}
- Security headers grade: {{GRADE}}
- All policy pages current: {{YES/NO}}
- NAP consistency: {{PERCENTAGE}}%

## Authoritativeness Pillar Status

- Domain Rating: {{X}} (vs {{X}} last month)
- Referring domains: {{X}} (vs {{X}} last month)
- Wikipedia/Wikidata stable: {{YES/NO}}
- Knowledge Panel intact: {{YES/NO}}

## Issues Identified

{{LIST}}

## Issues Remediated

{{LIST}}

## Items Still Open

{{LIST}}

## Next Month Priorities

{{LIST}}

17.4 Post-Algorithm-Update Report Template

# Post-Update Analysis: {{UPDATE_NAME}}

**Update**: {{UPDATE_NAME}}
**Detected**: {{DETECTION_DATE}}
**Confirmed**: {{CONFIRMATION_DATE}}
**Completed**: {{COMPLETION_DATE}}

## Volatility Detected

- Semrush Sensor: {{X}}/10
- Confirmed by: {{SOURCE}}
- Impact assessment date: {{DATE}}

## Site Impact

- Pages with traffic loss > 20%: {{COUNT}}
- Pages with traffic gain > 20%: {{COUNT}}
- Net traffic change: {{PERCENTAGE}}%
- Net ranking change: {{X}} positions average

## Pages Most Affected (Loss)

{{LIST_WITH_PAGE_TYPE_AND_TRAFFIC_DELTA}}

## Pages Most Affected (Gain)

{{LIST_WITH_PAGE_TYPE_AND_TRAFFIC_DELTA}}

## Pattern Analysis

{{COMMON_FACTORS_AMONG_LOSERS}}
{{COMMON_FACTORS_AMONG_WINNERS}}

## Suspected Update Focus

{{HYPOTHESIS}}

## Actions Taken

{{NUMBERED_LIST_OF_REMEDIATION_ACTIONS}}

## Recovery Tracking

{{30_DAY_RECOVERY_DATA}}

## Lessons Learned

{{INSIGHTS_TO_APPLY_FORWARD}}

End of Framework Document

Document version: 1.0
Last updated: 2026-04-29
Maintained by: ThatDeveloperGuy
Companion documents (planned):

• framework-ymyl.md — Your Money or Your Life classification and weighting
• framework-hcs.md — Helpful Content System
• framework-sqrg.md — Search Quality Rater Guidelines
• framework-coreupdates.md — Google Core Updates
• framework-infogain.md — Information Gain
• framework-entitysalience.md — Entity Salience
• framework-knowledgegraph.md — Knowledge Graph
• framework-aicitations.md — AI Citation Theory

This document is the canonical reference for E-E-A-T installation and audit. All 14-tier framework files (tier-one.md through tier-fourteen.md) reference E-E-A-T signals; this document provides the deep implementation specification those tier items rely on.

About this framework library

This article is the Dev.to republish of a framework reference document from ThatDevPro's SEO + AI engineering library. Canonical source: https://www.thatdevpro.com/insights/framework-eeat/

ThatDevPro is an SDVOSB-certified veteran-owned web + AI engineering studio operating from Cassville, Missouri. The studio runs the full 14-tier Engine Optimization stack and ships open-source tooling for AI citation engineering.

Companion 14-tier Engine Optimization stack (each tier is its own article):

1. Tier 1 — Foundation
2. Tier 2 — Search Visibility
3. Tier 3 — AI Domination
4. Tier 4 — Entity and Authority
5. Tier 5 — Local Domination
6. Tier 6 — Content and Multimedia
7. Tier 7 — Social and Community
8. Tier 8 — Data, Analytics, Conversion
9. Tier 9 — Monitoring and Intelligence
10. Tier 10 — Workflow and Operations
11. Tier 11 — Marketplace and Retail
12. Tier 12 — International
13. Tier 14 — Advanced and Immersive

Need this framework implemented on your site? See the Engine Optimization service or hire through ThatDevPro contact.