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

Based on the provided text, this document serves as a comprehensive installation and audit reference for implementing Google's E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) framework on any website to a world-class standard. It functions as both an installation manual for building the framework into a site and an audit document for evaluating an existing site using a pass/fail scoring system. The framework supports three modes of use: Install Mode, Audit Mode, and Hybrid Mode.

Originally published atPart of ThatDevPro's open SEO + AI framework library. thatdevpro.com . 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 . For pure client-rendered SPAs no SSR/SSG see framework-cross-stack-implementation.md . For Tailwind-specific concerns purge, dynamic classes, dark-mode CLS, focus accessibility see framework-react.md . 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: - Read Section 2 first — collect all client variables. Do not begin any installation work until the variables intake is complete. - 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. - 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 . - Validate after each phase — run the validation protocol Section 11 at the end of each major phase, not only at the end. - 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: - Read Section 3 What E-E-A-T Is to understand the framework. - Read Section 4 The Four Pillars to understand what signals each pillar requires. - Use Section 2 as your client intake form — fill it in for the project. - Use Sections 5-9 as your build checklist, working through phases in order. - Use Section 11 to validate. Use Section 12 if auditing instead. - 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: | Conflict | Rule | |---|---| | Existing canonical tag | Do not overwrite. Verify it points to a valid URL. Flag for manual review if it doesn't match expected canonical structure. | | Existing Organization schema | Merge fields. Add missing fields from this framework. Do not remove existing fields unless they're factually wrong. | | Existing Person schema for an author | Merge. Add sameAs , knowsAbout , hasCredential if missing. Preserve existing values. | | Existing author page | Audit against Section 7 requirements. Add missing elements. Do not rewrite existing bio content. | | Existing trust signal block | Audit. Add missing elements. Preserve verified review widgets and live data feeds. | | Existing CSP header | Audit for compatibility with new schema and trust scripts. Modify only if necessary. Do not weaken CSP. | Existing robots.txt , llms.txt , sitemap.xml | Append, never replace. Add new directives without removing existing ones. | 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 - — for header inspection and bot user-agent simulation curl or httpie 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. | | Criterion | Severity | |---|---|---| | E1 | Every article has a visible author byline linking to an author page | Critical | | E2 | Every article displays both datePublished and dateModified | Critical | | E3 | Every practical/tutorial article has a "how I know this" or "from my experience" section | High | | E4 | At least 50% of images sitewide are original not stock or AI-generated | High | | E5 | Original images include ImageObject schema with creator and dateCreated | Medium | | E6 | Long-form articles 1500 words include a failure/edge-case section | High | | E7 | Practical content references specific tool versions and dates | Medium | | E8 | First-person language is used consistently in author-driven content | Medium | | E9 | Process/case-study content includes a timeline with specific dates | Medium | | E10 | Author credentials are specific to the experience claimed not generic | High | 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 | | Criterion | Severity | |---|---|---| | X1 | Author credentials displayed in every article byline | Critical | | X2 | Person schema with hasCredential populated | Critical | | X3 | Person schema with knowsAbout populated and matching published topics | High | | X4 | Author page exists for every bylined contributor | Critical | | X5 | Topical hub pages exist for each primary pillar | High | | X6 | Each pillar has 10+ pieces of content demonstrating depth | High | | X7 | Edge-case/advanced content exists for top pillars | Medium | | X8 | Articles include reference/citation lists for factual claims | High | | X9 | Article schema includes citation property | Medium | | X10 | External publications listed on author page | Medium | | X11 | Speaking history listed on author page if applicable | Low | | X12 | YMYL sites: credentials match topic regulatory requirements | Critical YMYL only | 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: - Confirm notability multiple independent published references about the entity - Create the entry at https://www.wikidata.org/wiki/Special:NewItem - Populate properties: instance of, founded by, founding date, official website, headquarters, industry, sameAs links to authoritative profiles - 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 | | Criterion | Severity | |---|---|---| | A1 | Organization schema includes complete sameAs array 8+ profiles | Critical | | A2 | Person schema includes complete sameAs array 5+ profiles | Critical | | A3 | Wikidata entry exists for business | High | | A4 | Wikidata entry exists for founder | High | | A5 | Wikidata QID referenced in schema sameAs | Critical | | A6 | "Featured In" section visible on homepage with 5+ logos | High | | A7 | Press/media page exists at /press/ or equivalent | High | | A8 | Quotation schema used for earned media quotes | Medium | | A9 | Awards and certifications displayed with verification links | High | | A10 | Schema for credentials uses EducationalOccupationalCredential with recognizedBy | Medium | | A11 | "Cite this" functionality on research and flagship pages | Medium | | A12 | Founder maintains separate personal entity site B2B/professional services | Medium | | A13 | Domain age 2+ years OR sustained publishing 12+ months | High | | A14 | At least 50 referring domains Ahrefs | High | | A15 | At least 5 backlinks from DR 50+ sources | High | 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 | | Criterion | Severity | |---|---|---| | T1 | HTTPS enforced sitewide with valid SSL | Critical | | T2 | HSTS header present max-age 31536000+ | Critical | | T3 | Domain on HSTS preload list | High | | T4 | All required security headers present CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy | Critical | | T5 | Privacy policy exists and accessible from every page | Critical | | T6 | Terms of service exists | Critical | | T7 | Accessibility statement exists | High | | T8 | NAP visible in footer of every page | Critical | | T9 | NAP consistent across site, schema, GBP, top 50 citations | Critical | | T10 | Author identity transparent real name, photo, bio | Critical | | T11 | Last-updated banner on every article | High | | T12 | Article schema includes both datePublished and dateModified | High | | T13 | Inline citations on every factual claim | High | | T14 | References/sources section on every article with factual content | High | | T15 | AI content disclosure if AI is used | Critical if applicable | | T16 | Affiliate/sponsored disclosures clear and prominent | Critical if applicable | | T17 | Reviews displayed are real and verifiable | Critical | | T18 | Reviews responded to within 48 hours positive and negative | High | | T19 | Custom 404 page returning HTTP 404 | High | | T20 | Zero broken inbound links to high-traffic pages | High | | T21 | Cookie consent implemented if non-essential cookies used | Critical if applicable | | T22 | Consent Mode v2 with proper default-denied states | Critical if applicable | | T23 | Global Privacy Control signal honored | High US | | T24 | YMYL editorial policy page exists | Critical YMYL only | | T25 | YMYL corrections policy page exists | Critical YMYL only | | T26 | YMYL articles include medical/professional reviewer credit | Critical YMYL only | | T27 | YMYL articles include disclaimer at top | Critical YMYL only | | T28 | YMYL articles cite primary literature | High YMYL only | 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: - Schema validates on every page type homepage, About, article, contact - SSL Labs A+ rating: https://www.ssllabs.com/ssltest/analyze.html?d={{PRIMARY DOMAIN}} - securityheaders.com A+ rating: https://securityheaders.com/?q={{PRIMARY DOMAIN}} - PageSpeed Insights "Good" CWV scores - Robots.txt validates: visit https://{{PRIMARY DOMAIN}}/robots.txt and confirm sitemap directive - Sitemap submitted in GSC - All required pages return HTTP 200 - All policy pages accessible from footer - 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: - View source — confirm all required <head elements present - Run page through Google Rich Results Test - Run page through Schema.org validator - Check breadcrumbs render correctly - Verify single H1, proper heading hierarchy - Test on mobile real device or DevTools mobile emulation - Run Lighthouse — Performance, Accessibility, Best Practices, SEO scores - 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: - Person schema validates with zero errors - All sameAs URLs return HTTP 200 - Reciprocal rel="me" linking confirmed on at least 3 external profiles - Author page accessible from /authors/ hub - At least one article links to author page via byline - 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. php 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 : php 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. js // 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. js --- // 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: - Centralize variables in a single config file eeat-variables.yml from Section 2 - Build schema templates that reference variables - Render schema in shared head include / layout / template - Per-page schema rendered by page-specific template, referencing site-wide schema via @id - 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 python 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 - Gather variables Section 2 about the existing business - Crawl the site to inventory pages, schemas, and trust elements - Score each pillar using the audit criteria Sections 4.1-4.4 - Compile findings into the audit report template in Section 17.2 - 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: | Pillar | Items | Max Points | World-Class Threshold | YMYL Threshold | |---|---|---|---|---| | Experience | 10 | 20 | 17 | 19 | | Expertise | 12 | 24 | 20 | 22 | | Authoritativeness | 15 | 30 | 25 | 27 | | Trustworthiness | 28 | 56 | 50 | 54 | Total | 65 | 130 | 112 | 122 | 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: - Document the update in the algorithm update incident log - Review traffic and ranking changes per page - Run full E-E-A-T audit on most-affected pages - Identify common factors among winners and losers - Adjust strategy if patterns emerge - 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: - Trust foundations first Tier 1 SSO, GCO; Section 5 of this doc — required pages, security headers - Author entity infrastructure Tier 2 AAO; Section 7 of this doc - Site-wide schema graph Tier 1 EEA; Section 5.1 of this doc - Per-article trust signals Tier 2 ETO; Section 6.2 of this doc - Wikidata and external entity work Tier 3 WIK - Earned media Tier 4 EAO, DPR, EXO - Original research and thought leadership Tier 4 TLO - 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 https://www.thatdevpro.com/services/engine-optimization/ stack and ships open-source tooling for AI citation engineering. Companion 14-tier Engine Optimization stack each tier is its own article : Tier 1 — Foundation https://www.thatdevpro.com/insights/seo-tier-1-foundation/ Tier 2 — Search Visibility https://www.thatdevpro.com/insights/seo-tier-2-search-visibility/ Tier 3 — AI Domination https://www.thatdevpro.com/insights/seo-tier-3-ai-domination/ Tier 4 — Entity and Authority https://www.thatdevpro.com/insights/seo-tier-4-entity-and-authority/ Tier 5 — Local Domination https://www.thatdevpro.com/insights/seo-tier-5-local-domination/ Tier 6 — Content and Multimedia https://www.thatdevpro.com/insights/seo-tier-6-content-and-multimedia/ Tier 7 — Social and Community https://www.thatdevpro.com/insights/seo-tier-7-social-and-community/ Tier 8 — Data, Analytics, Conversion https://www.thatdevpro.com/insights/seo-tier-8-data-analytics-conversion/ Tier 9 — Monitoring and Intelligence https://www.thatdevpro.com/insights/seo-tier-9-monitoring-and-intelligence/ Tier 10 — Workflow and Operations https://www.thatdevpro.com/insights/seo-tier-10-workflow-and-operations/ Tier 11 — Marketplace and Retail https://www.thatdevpro.com/insights/seo-tier-11-marketplace-and-retail/ Tier 12 — International https://www.thatdevpro.com/insights/seo-tier-12-international/ Tier 14 — Advanced and Immersive https://www.thatdevpro.com/insights/seo-tier-14-advanced-and-immersive/ Need this framework implemented on your site? See the Engine Optimization service https://www.thatdevpro.com/services/engine-optimization/ or hire through ThatDevPro contact https://www.thatdevpro.com/contact/ .