Structured Data SEO Guide: JSON-LD That Actually Works
August 11, 2026 · By Rogier Bruggeman, Founder of KinetixSEO
25+ years of web experience.
Why structured data still matters
Structured data gives search engines and AI systems a direct, unambiguous description of a page instead of forcing them to infer meaning from text and layout. JSON-LD markup — the format Google recommends over Microdata or RDFa — wraps this information in a script tag that describes entities like articles, products, organizations, and questions using the shared vocabulary at schema.org. That shared vocabulary is what lets a search engine confidently show a star rating, a FAQ dropdown, or a breadcrumb trail in results, per Google's structured data guidelines.
AI-powered search and answer engines lean on structured data as a fast, low-ambiguity signal when deciding what to cite. Google's AI Overviews, ChatGPT's browsing mode, and Perplexity all favor pages where the answer is already segmented into clean, labeled entities rather than buried in prose. A page with well-formed Article or FAQPage markup hands these systems a pre-packaged answer they can lift with confidence; a page without it forces the model to parse and guess, which lowers the odds of citation even when the underlying content is strong. Structured data has become an AI-visibility lever as much as a rich-results one — in audits we run for clients, pages with valid FAQPage and Article markup are cited noticeably more often in AI-generated summaries than near-identical pages missing that markup, even when both pages rank similarly in classic search.
The five schema types worth implementing first
Most sites don't need dozens of schema types. Five cover the majority of value: Article, FAQPage, Product, BreadcrumbList, and Organization.
Article
Article schema (or its subtypes, NewsArticle and BlogPosting) identifies headline, author, publish date, and featured image for blog posts and editorial content. This is the backbone of E-E-A-T signaling at the code level — it tells engines who wrote something and when, which matters for freshness and authorship checks. Required fields include headline, image, datePublished, and author. Leaving out dateModified is a common miss that costs freshness signals on updated content.
FAQPage
FAQPage schema marks up question-and-answer pairs so they can appear as expandable results and, increasingly, get lifted directly into AI-generated answers. Each Question needs a name and an acceptedAnswer with text. The format is only worth using when the FAQ content is genuinely visible and answered on the page — Google has explicitly said it won't render the rich result for hidden or decorative FAQ markup, and stuffing pages with FAQPage schema that doesn't match visible text is a fast way to get manual scrutiny.
Product
Product schema powers price, availability, and review-star rich results — some of the highest click-through-rate real estate in ecommerce SERPs. The required fields are name, image, and an offers object with price and priceCurrency, or an aggregateRating/review if you're showing stars. Missing availability or leaving stale prices in the markup is the single most common reason Product rich results get suppressed.
BreadcrumbList
BreadcrumbList schema replaces the raw URL in search results with a readable path (Home > Category > Product), which improves scan-ability and reinforces site hierarchy for crawlers. It requires an ordered itemListElement array, each with a position, name, and item URL. This is low effort, low risk, and worth rolling out sitewide via template rather than page-by-page.
Organization
Organization schema defines your brand entity — name, logo, URL, social profiles via sameAs, and contact information. This is the schema that feeds Knowledge Panels and helps AI systems resolve "who is this company" when your content gets cited without a click-through. It should live once, consistently, ideally on the homepage and referenced elsewhere, rather than being duplicated with slightly different details on every page.
Common validation mistakes that break your markup
Most structured data failures come down to three patterns: missing required fields, deprecated types, and conflicting @id references.
Missing a required field disqualifies the whole rich result, not just weakens it. Every schema type has a set of properties Google treats as required for eligibility, and a larger set it treats as recommended. Skipping a required field — like image on Product, or author on Article — knocks the page out of consideration entirely rather than producing a partial or degraded result. Always check the type-specific requirements in Google's search gallery documentation rather than assuming any valid schema.org property is enough.
Shipping deprecated schema types wastes engineering time on a rich result that will never appear. Google discontinued the HowTo rich result in Search (the type remains valid schema.org vocabulary, but Google no longer renders it), yet plenty of sites keep maintaining HowTo markup expecting a visual result that isn't coming. Before implementing any schema type, confirm in current documentation that it's supported for rich results, not just technically valid — schema.org accepting a type doesn't mean any given search engine will do anything with it.
Duplicate or conflicting @id values make it impossible for engines to tell which version of an entity is authoritative. This happens when multiple schema blocks on a page, or across a site, reuse the same @id for different entities, or describe the same entity with contradictory properties in different blocks. It shows up most often when Organization or WebSite schema is generated by both a theme/plugin and a manual injection, producing two competing blocks. In one site audit we ran, a plugin-generated Organization block and a manually hardcoded one both used the same @id but listed different logo URLs — Google's Rich Results Test passed both individually but flagged the conflict once both were rendered together. Audit for duplicate @id values sitewide, not just per-page, since templated markup tends to repeat the same mistake everywhere it's included.
Testing your markup before and after launch
Test with a live tool that renders the actual page, not a static snippet. Google's Rich Results Test and the Schema Markup Validator both parse rendered JSON-LD and flag missing required fields, but they check syntax and eligibility, not truthfulness — a technically valid Product schema with a price that doesn't match the page will pass validation and still cause problems.
Run three checks on any new markup: does it validate without errors, does it match what's visibly on the page, and does it actually trigger the intended rich result in a live SERP check a few days after deployment (rich results are never guaranteed, only eligible). Set a recurring audit — quarterly for high-change page types like Product, less often for static types like Organization — since template updates, price changes, and content edits drift out of sync with markup silently.
Keeping schema in sync with visible content
Schema that contradicts the page is worse than no schema at all. If your Product markup shows a price or availability status that doesn't match what a visitor actually sees, or your FAQPage markup answers a question the visible page no longer asks, you're not just losing a rich result — you're sending a mismatched signal that can trigger manual action under Google's structured data guidelines and erode trust with AI systems pulling content for citation.
The safest practice is to generate structured data from the same source as the visible content, not as a separate hand-maintained block. If your CMS pulls FAQ text from a field, the schema should pull from that same field. If price updates flow through a product database, the JSON-LD should be templated from that database, not hardcoded. Treat any manually hardcoded schema value as a liability that will eventually drift from the page it describes.
Frequently asked questions
Do I need structured data for every page on my site?
No — prioritize page types where a rich result or AI citation has real value, like product pages, articles, and FAQ sections, and roll out sitewide types like BreadcrumbList and Organization via template rather than manually per page.
Will adding structured data guarantee a rich result?
No, validation passing is a prerequisite, not a promise. Structured data makes a page eligible for a rich result, but Google decides whether and when to render one based on quality, relevance, and search intent, so a technically valid schema block can still never appear as a visual rich result.
Is HowTo schema still worth implementing?
Generally not for Google Search, since Google discontinued the HowTo rich result; the markup remains valid schema.org vocabulary but won't produce the visual result it once did, so effort is better spent on supported types like Article or FAQPage.
What's the fastest way to check if my JSON-LD is broken?
Run the page through a rendering-based validator like Google's Rich Results Test, which parses the actual rendered markup and flags missing required fields or syntax errors immediately.
How often should structured data be audited?
Audit high-change page types like Product on a quarterly cycle and static types like Organization less frequently, and re-audit any time a template, CMS field, or pricing system that feeds the markup changes.
Written by Daniel Reyes, Technical SEO Lead at KinetixSEO. Daniel has spent eight years auditing structured data implementations for ecommerce and publisher sites and holds Google's Structured Data certification. View his full bio and past audits or get in touch with questions about this guide.
Want to check your own site against these same signals? Run the free SEO/GEO checker.