# Blog Schema Markup in 2026: The Complete Guide to Structured Data for AI Search > Blog schema markup tells Google and AI engines what your post is. Every JSON-LD type still worth shipping in 2026, plus the May change you missed. Canonical: https://quillly.com/blogs/blog-schema-markup-2026 Published: 2026-05-17 # Blog Schema Markup in 2026: The Complete Guide to Structured Data for AI Search ![a computer screen with a bunch of code on it](https://images.unsplash.com/photo-1515879218367-8466d910aaa4?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w4OTM1MDJ8MHwxfHNlYXJjaHwxfHxkZXZlbG9wZXIlMjBjb2RlJTIwc3RydWN0dXJlZCUyMGRhdGElMjB0ZXJtaW5hbHxlbnwwfDB8fHwxNzc4OTc4ODMxfDA&ixlib=rb-4.1.0&q=80&w=1080) *Photo by [Chris Ried](https://unsplash.com/@cdr6934?utm_source=quillly&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=quillly&utm_medium=referral)* On May 7, 2026, Google quietly killed FAQ rich results. Ten days later, most SEO advice about blog schema markup still tells you to add FAQPage schema for the SERP boxes that no longer exist. Wrong fix. The right one is to keep the FAQPage schema. Pages that use it earn 3.2x more citations in Google AI Overviews and 67% citation rates in ChatGPT for relevant queries, even after the rich result deprecation. Blog schema markup in 2026 isn't about chasing rich results anymore. It's about feeding AI search engines the structured signals they use to extract, verify, and cite your content. Add the right JSON-LD and you become an AI-citable source. Skip it and you stay invisible to the systems now answering roughly a quarter of search queries through AI Overviews. **Direct answer:** Blog schema markup is JSON-LD structured data embedded in a blog post that tells Google, ChatGPT, Perplexity, and Gemini what the page is. It signals the author, publish date, topic, FAQ pairs, and entity relationships. The right schema lifts AI Overview appearances by up to 40%, still earns rich results for breadcrumbs and authorship, and feeds the citation signals AI engines use to pick sources. This guide covers every schema type still worth shipping in 2026, the 5-Layer Schema Stack to deploy them safely, and what changed in Google's May 2026 update. ## What changed on May 7, 2026 (and what didn't) Google removed FAQ rich results from Search on May 7, 2026. The FAQ search appearance, the rich result report in Search Console, and support in the Rich Results Test are all being phased out through August 2026. That ends a five-year run where blogs with FAQPage schema saw expandable Q&A blocks under their listing. A lot of writers read that announcement as "stop using FAQPage." That's wrong twice over. First, the FAQPage schema itself is still a valid Schema.org type, and Google has stated unused structured data doesn't harm Search. You don't need to rip it out. Second, FAQPage is now arguably *more* valuable than before. Independent research shows pages with FAQPage schema are 3.2 times more likely to appear in Google AI Overviews and hit a 67% citation rate in ChatGPT for question-style queries. ChatGPT Search, Perplexity, and Gemini all parse FAQ structured data as a primary extraction source for Q&A answers. The mental model that actually works in 2026: - **Rich results** = visual SERP features (carousels, breadcrumbs, author cards). Shrinking. - **AI citations** = ChatGPT, Gemini, Perplexity, AI Overviews quoting you as a source. Exploding. - **Schema** = the input that feeds both, weighted increasingly toward the second. Treat schema as AI search infrastructure, not SERP candy. That single reframe drives every decision in this guide. ## The 5-Layer Schema Stack every blog needs in 2026 Most schema guides throw 30 types at you and let you sort it out. That's why most blogs ship broken markup. Here's the lean version: five layers, ordered by leverage. Ship them in this order and stop. 1. **Foundation layer** — `Organization` and `WebSite` schema. Site-wide. Tells Google and AI engines who you are and how to crawl your sitelinks search box. 1. **Article core layer** — `BlogPosting` (or `Article` / `NewsArticle`) with `author` and `publisher` nested. Every published post. This is the single highest-leverage schema for AI citations. 1. **Discovery layer** — `BreadcrumbList` and `WebPage`. Every post. BreadcrumbList survived every deprecation round and still earns rich results. 1. **Rich extras layer** — `FAQPage`, `HowTo`, `VideoObject`, `ImageObject`. Add only when the content genuinely contains those elements. 1. **Audit layer** — Rich Results Test, Schema Markup Validator, and GSC's structured data report. Run before publish, then weekly on your top traffic posts. Skip a layer and you leak citation signal. Add types that don't match content and Google's spam systems flag you for misleading structured data. The order matters because layers 1–2 carry 80% of the SEO impact for blogs. Most teams over-invest in layer 4 and skip layer 5 entirely. Here's what each layer covers across the schemas every blog should actually ship: | Layer | Schema type | Status in 2026 | Leverage | | --- | --- | --- | --- | | Foundation | Organization | Active rich results | High — sitelinks, knowledge panel | | Foundation | WebSite | Active rich results | High — sitelinks search box | | Article core | BlogPosting | Active rich results | Critical — AI citations + Top Stories eligibility | | Article core | Person (author) | Active rich results | High — E-E-A-T signal | | Discovery | BreadcrumbList | Active rich results | High — durable survivor | | Rich extras | FAQPage | Rich results dropped May 7, 2026 | High — AI Overview citations | | Rich extras | HowTo | Rich results dropped 2023 | Medium — AI Overview signal | | Rich extras | VideoObject | Active rich results | High when video present | The leverage column is what most schema guides miss. Two schemas can both be "Active" in Google's docs but mean wildly different things for traffic. ## Article vs BlogPosting vs NewsArticle: pick the most specific type Google's documentation is blunt: "Use the most specific type possible." For blog posts, that means `BlogPosting` over `Article` in almost every case. `BlogPosting` inherits everything from `Article`. Using it tells Google your content is conversational, dated, and authored by a specific person — signals that feed Google Discover eligibility, AI Overview citation patterns, and the "blog" classification in Search. Using generic `Article` schema on a `/blog/` URL is a wasted opportunity for specificity. `NewsArticle` is a separate decision. It signals time-sensitive reporting and is the *only* schema type eligible for the Top Stories carousel in Google Search. Use it for news-style posts under 48 hours old. Use `BlogPosting` for evergreen guides and tutorials. | Schema type | Use it for | Top Stories eligible? | AI citation strength | | --- | --- | --- | --- | | `Article` | Generic, default fallback | No | Medium | | `BlogPosting` | Standard blog posts, tutorials, opinion | No | High | | `NewsArticle` | News, time-sensitive reporting | Yes | High | | `TechArticle` | Deep technical docs, API guides | No | Medium-High | Here's the minimum viable `BlogPosting` JSON-LD every post should ship: ``` { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Blog Schema Markup in 2026: The Complete Guide", "description": "Every JSON-LD type still worth shipping for blogs in 2026.", "image": "https://example.com/featured.jpg", "datePublished": "2026-05-17T08:00:00+00:00", "dateModified": "2026-05-17T08:00:00+00:00", "author": { "@type": "Person", "name": "Jane Founder", "url": "https://example.com/author/jane" }, "publisher": { "@type": "Organization", "name": "Example Inc", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/blog/post-slug" } } ``` Required to actually earn rich results: `headline` (under 110 characters), `image`, `datePublished`, `author` (with `@type: Person` and a `url`), and `publisher` (with logo). Google has technically loosened the "no required properties" stance — but in practice, posts missing any of those five get zero article-style enhancement. One trap to avoid: don't put your site name in `author`. Google flagged "author" as an entity that should resolve to a real person, not the brand. Posts with `"author": {"@type": "Organization"}` see meaningful AI citation drop-off versus posts with named human authors, because authorship signals matter more than at any point in the previous decade. ## FAQPage schema: the contrarian play after the May 2026 deprecation Here's the controversial part. Most schema guides updated in the last 10 days are advising readers to remove FAQPage markup. Don't. The Google deprecation killed the *display feature* — the expandable Q&A under your SERP listing. That feature drove maybe 3-7% of organic CTR for posts that had it. What's left is the markup itself, which is now the highest-signal-density input you can give to AI search engines. Three data points worth sitting with: - Pages with FAQPage schema are **3.2x more likely** to appear in Google AI Overviews than pages without it. - For question-style queries, FAQPage-enriched pages hit a **67% citation rate** in AI responses. - Sites implementing structured data plus FAQ blocks together saw a **44% increase** in AI search citations in a 2025 BrightEdge study. Why? FAQPage gives an LLM pre-segmented Q&A pairs. It's the easiest possible extraction job. When ChatGPT or Perplexity decide which sources to cite for an "is X safe to use" or "how does Y work" query, they preferentially quote pages where they can lift a clean question-answer pair without re-parsing prose. A clean FAQPage JSON-LD block for a blog post looks like this: ``` { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Does FAQPage schema still work in 2026?", "acceptedAnswer": { "@type": "Answer", "text": "FAQ rich results were removed from Google Search on May 7, 2026, but the FAQPage schema markup remains valid and is now a primary input for AI Overview and ChatGPT citations." } }, { "@type": "Question", "name": "Which schema replaces FAQPage for blogs?", "acceptedAnswer": { "@type": "Answer", "text": "Nothing replaces it directly. BlogPosting plus FAQPage together remains the strongest combination for AI search visibility on Q&A content." } } ] } ``` Three rules that determine whether your FAQPage actually earns citations: 1. **Visible parity.** Every Q&A pair in the schema must exist on the rendered page. Google's spam systems flag "schema-only" FAQs as misleading structured data, and AI crawlers ignore Q&A pairs they can't find in the DOM. 1. **Question phrasing.** Use the way readers actually phrase questions out loud. "How do I add schema to a blog post?" outperforms "Schema implementation procedure." Match People Also Ask phrasing where possible. 1. **One FAQPage per page, max.** Multiple FAQPage blocks confuse parsers. Consolidate. Skip FAQPage for product or category pages — Google's structured data guidelines specifically restrict it to genuinely supportive Q&A content. But for blog posts with a real FAQ section? Ship it. ## HowTo schema: dead for SERPs, alive for AI Google deprecated HowTo rich results in September 2023. In 2026, no rich result fires, no SERP visibility carries over, and Google has explicitly said there are no plans to restore it. Many guides recommend removing HowTo entirely. That's also wrong for blogs that genuinely contain procedures. HowTo schema segments your post into discrete steps with names, descriptions, and optional images. That structure is exactly what AI Overviews extract when a searcher asks "how do I do X." Independent testing shows AI engines use HowTo-marked content to synthesize step-by-step answers more reliably than raw prose, even when no rich result appears in classic SERPs. Where to use it: tutorial posts, recipes, configuration walkthroughs, anything where the answer is genuinely a numbered sequence. Where to skip it: opinion posts, comparison posts, anything where "steps" would be marketing-flavored rather than literal. A minimum HowTo JSON-LD for a tutorial post: ``` { "@context": "https://schema.org", "@type": "HowTo", "name": "How to add BlogPosting schema to a blog post", "totalTime": "PT10M", "step": [ { "@type": "HowToStep", "name": "Generate the JSON-LD", "text": "Use a schema generator to create the BlogPosting object with author, publisher, and image." }, { "@type": "HowToStep", "name": "Embed in the page head", "text": "Paste the JSON-LD inside a script tag with type='application/ld+json' in the document head." }, { "@type": "HowToStep", "name": "Validate", "text": "Run the URL through Google's Rich Results Test and Schema Markup Validator." } ] } ``` Same parity rule applies: every step in the markup must appear visibly on the page. Ship HowTo only when your post is genuinely procedural — otherwise it's just noise. ## BreadcrumbList: the boring schema that earned the highest survival rate BreadcrumbList survived every Google deprecation round. It still earns active rich results in 2026, gets parsed by every AI search engine, and helps Google understand your site's category structure for both crawl efficiency and AI Overview source selection. It's also the schema indie hackers most often skip because it doesn't feel important. That's a mistake. A 2026 audit of mid-sized publishers found BreadcrumbList schema correctly implemented on only 60% of blog URLs — meaning roughly 40% of blogs are leaving rich result eligibility on the table for the lowest-effort schema available. For a blog post at `example.com/blog/category/post-slug`, the markup is: ``` { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog" }, { "@type": "ListItem", "position": 3, "name": "Category", "item": "https://example.com/blog/category" }, { "@type": "ListItem", "position": 4, "name": "Post Title" } ] } ``` Three rules: don't include the current page's URL in the final `item` (just the `name`), keep positions sequential starting at 1, and don't break the breadcrumb if a parent category doesn't exist on your site — collapse to two levels instead. ## Author and Organization: powering E-E-A-T signals In 2026, authorship signals matter more than at any point in the previous decade. Google's March 2026 core update explicitly elevated author trust as a ranking factor for blog and informational content. Articles attributed to identifiable humans with verifiable expertise get better treatment than the same content under a generic byline. The schema you need is `Person` nested inside `BlogPosting.author`, with a `url` field pointing to a real bio page, plus `sameAs` links to verified social profiles. The author's bio page should ship its own `Person` schema with their credentials, employment, and `sameAs` array. ``` { "@type": "Person", "name": "Jane Founder", "url": "https://example.com/author/jane", "jobTitle": "Founder, Example Inc", "sameAs": [ "https://twitter.com/janefounder", "https://linkedin.com/in/janefounder", "https://github.com/janefounder" ], "alumniOf": "Stanford University" } ``` The `sameAs` array is the highest-leverage field most blogs skip. It's how Google and AI engines resolve "Jane Founder" to a specific entity in their knowledge graphs. Three to five verified profile URLs is the sweet spot. Skip throwaway profiles and any link to a profile with zero activity. For Organization schema, ship it site-wide (not per-post). The minimum: ``` { "@context": "https://schema.org", "@type": "Organization", "name": "Example Inc", "url": "https://example.com", "logo": "https://example.com/logo.png", "sameAs": [ "https://twitter.com/exampleinc", "https://linkedin.com/company/exampleinc", "https://github.com/exampleinc" ] } ``` Aleyda Solis, one of the most-cited SEO consultants on AI search, puts it bluntly: schema markup is "like adding a roadmap to your website." But she's also flagged that schema *alone* doesn't move AI search visibility — you need crawlability, content structure, and credible mentions across communities working in concert. The schema layer is necessary but not sufficient. ## The content parity rule that gets sites penalized Google's structured data guidelines have one rule that quietly destroys more schema implementations than any other: **every schema property must match content visibly rendered on the page.** If your `headline` field says one thing but your H1 says another, Google can demote the page. If your `FAQPage` Q&A pairs don't appear in the visible DOM, Google flags the markup as "spammy structured data." If you list `author.name: "Jane Founder"` but the byline shows "Editorial Team," the AI crawlers will lose trust in the page. John Mueller of Google has been consistent on this for years: "structured data helps our systems better understand what's on a page, which can help with showing your content in rich results and other special search result features" — but the structured data must directly match the visible content. The 2026 update did not loosen that requirement. It tightened it. The parity issues blogs most often ship by accident: - **FAQPage with answers truncated** in schema versus full text on page. - **Author bylines** that don't match `author.name`. - **datePublished** in the future or before the URL was indexed. - **image** field pointing to a logo or generic stock photo instead of the article's actual hero image. - **headline** longer than the visible H1 (Google caps at 110 characters anyway). Run the parity check manually before publish: open the rendered post, view its JSON-LD via your schema tool, and walk through each property line by line. Or automate it — the next section covers that. ## The 5-Step Schema Audit Loop Pick the right schemas, write clean JSON-LD, ship it. Then audit it on a loop. The audit step is where most blogs leak structured data quality over time. **Step 1 — Generate.** Use a schema generator (or your CMS's built-in JSON-LD output) to produce BlogPosting, FAQPage, BreadcrumbList for the post. Don't hand-write JSON-LD for every post — humans typo `@type` and break parsers. **Step 2 — Embed.** Place each JSON-LD block in a `