JSON-LD Structured Data: A Complete Guide for 2026

JSON-LD (JavaScript Object Notation for Linked Data) is the small block of markup you put in your page’s HTML to tell Google what that page is: a blog post, a product with a price and a currency, an event on a date, the company behind the site. It is Google’s recommended structured-data format, and it is often the difference between a flat blue link and a rich result with a price, a star rating, a video thumbnail or a breadcrumb trail. Here is what to add in 2026, the exact JSON-LD to copy, how to test it, the errors that break it, and how to keep it correct on a site with thousands of pages.

What JSON-LD is and why Google reads it

Google describes structured data as “a standardized format for providing information about a page and classifying the page content”. JSON-LD is one of three formats Google accepts, alongside Microdata and RDFa, and the one it recommends: a single <script type="application/ld+json"> block, kept apart from the visible text, so nested values (the country inside an address inside a venue) stay easy to express. Every block opens with "@context": "https://schema.org" for the vocabulary and "@type" for what the page is, followed by the properties.

Google uses that markup for two things: to understand the individual page, and to gather information about the web in general, “such as information about the people, books, or companies that are included in the markup”. That second part is why one Organization block on your homepage feeds the knowledge panel next to your name.

The payoff is measurable, and Google’s own case studies make the case: Rotten Tomatoes marked up 100,000 pages and measured a 25% higher click-through rate, Nestlé pages that appear as rich results see 82% higher CTR than pages that do not, and the Food Network converted 80% of its pages to search features and saw a 35% increase in visits.

What changed in 2026: the types that are still worth it

Before you write markup, know which Google features still exist. Google’s documentation changelog is blunt on three of them:

• FAQ rich results are dead. Google added a deprecation notice on May 8, 2026, stating the FAQ rich result would no longer appear in Search starting May 7, 2026, and removed the documentation the following month. FAQPage markup still validates as schema.org, but do not build it expecting a Google feature.
• HowTo rich results are gone. Google removed the How-to documentation in 2023, noting the rich result “is no longer shown in search results, on both desktop and mobile devices”. HowTo markup is not worth maintaining for Google today.
• Breadcrumbs narrowed. The current breadcrumb documentation states the feature is available on desktop only.

One thing has not been replaced by AI: Google’s generative AI features (AI Overviews and AI Mode) are built on the same core ranking and quality systems, retrieving pages through search. And Google has explicitly debunked the idea that AI needs new markup: “Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add”, per its official AI optimization guide. Keep using JSON-LD because it earns rich-result eligibility, not because an LLM asked for it.

Serpstat’s two-minute primer covers exactly this: what JSON-LD is, why it produces those eye-catching rich results, and how to implement it.

The schema.org types a real site needs

One JSON-LD block per URL, describing only what is on that page. Google’s general structured data guidelines are blunt: do not add structured data about information that is not visible to the user, even if it is accurate.

Article and BlogPosting (blogs, news, documentation)

BlogPosting is the blog subclass of Article. Google currently lists no hard required properties for the article feature and instead recommends the set that shapes how your article is shown: headline, image, author, datePublished, dateModified. The author must be a Person (or Organization) with a name, and must be visible on the page.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "JSON-LD Structured Data: A Complete Guide for 2026",
  "image": "https://example.com/cover.jpg",
  "datePublished": "2026-08-28T08:00:00+02:00",
  "dateModified": "2026-08-28T08:00:00+02:00",
  "author": {"@type": "Person", "name": "Jane Doe", "url": "https://example.com/about"},
  "publisher": {"@type": "Organization", "name": "Example Co", "logo": {"@type": "ImageObject", "url": "https://example.com/logo.png"}}
}

Product with Offer (stores and marketplaces)

A product page pairs Product with an Offer that states the price, the currency and the availability together: a price with no priceCurrency tells Google nothing, and an offer with no availability cannot qualify for merchant listings. Add aggregateRating only when the page genuinely displays that rating and count.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Executive Anvil",
  "image": "https://example.com/anvil.jpg",
  "description": "Sleeker than the Classic Anvil, the Executive Anvil is perfect for the business traveler who needs to drop something from a height.",
  "brand": {"@type": "Brand", "name": "ACME"},
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/anvil",
    "price": "119.99",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Organization (every site, on the homepage)

There are no required properties, but the recommended set, name, url, logo, sameAs and contactPoint, influences which logo and knowledge panel Google attaches to you. It belongs on your homepage and about page. The SEOEdgeAI homepage is a working example of the pattern: one @graph block carrying Organization, WebSite, SoftwareApplication with a free Offer, a VideoObject and FAQPage side by side.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Corporation",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/logo.png",
  "sameAs": ["https://www.linkedin.com/company/example"],
  "contactPoint": {"@type": "ContactPoint", "contactType": "customer service", "email": "[email protected]", "availableLanguage": ["en", "fr"]}
}

BreadcrumbList (interior pages)

The required structure is itemListElement, each ListItem carrying a position and a name, with the item URL recommended. Keep the trail identical to the breadcrumbs a visitor actually sees, and keep the numbers sequential.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type": "ListItem", "position": 1, "name": "Blog", "item": "https://example.com/blog"},
    {"@type": "ListItem", "position": 2, "name": "Technical SEO", "item": "https://example.com/blog/technical-seo"}
  ]
}

Event (events, ticketing, webinars)

Google requires name, startDate and a location (a Place with an address). Add an offers block with price and priceCurrency to make the event eligible for the ticketing experience, which is where the feature pays: Google cites Eventbrite’s 100% increase in typical year-over-year traffic growth from Search. If an event is canceled or rescheduled, update eventStatus too.

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "The Adventures of Kira and Morrison",
  "startDate": "2026-09-12T19:00-05:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "location": {
    "@type": "Place",
    "name": "Snickerpark Stadium",
    "address": {"@type": "PostalAddress", "addressLocality": "Snickertown", "addressRegion": "PA", "addressCountry": "US"}
  },
  "image": "https://example.com/poster.jpg",
  "offers": {"@type": "Offer", "url": "https://example.com/buy-tickets", "price": "30", "priceCurrency": "USD", "availability": "https://schema.org/InStock"}
}

VideoObject (video pages)

Google requires name, description, thumbnailUrl, uploadDate and either contentUrl or embedUrl. Put it on the page where the video actually plays; correct video markup can unlock video results with key moments, the chapters that link viewers straight into the middle of a video.

{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "How to fix a lawn full of weeds",
  "description": "A step-by-step guide to clearing a weedy lawn without harsh chemicals.",
  "thumbnailUrl": "https://example.com/thumb.jpg",
  "uploadDate": "2026-08-01T08:00:00+08:00",
  "duration": "PT10M20S",
  "contentUrl": "https://example.com/video/123.mp4",
  "embedUrl": "https://example.com/embed/123"
}

FAQPage (optional, with a caveat)

Valid schema.org and still useful as structured data for other consumers, but since May 7, 2026 it no longer produces a Google FAQ rich result. Add it only if you already show real questions and answers on the page. Same goes for HowTo: skip it.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Do I really only need Cloudflare?",
    "acceptedAnswer": {"@type": "Answer", "text": "Yes. We deploy a Cloudflare Worker in front of your site for you, so you connect your account, pick the site, and you are live in about two seconds."}
  }]
}

How to validate JSON-LD

Three tools catch almost everything:

• Google’s Rich Results Test. Paste a URL or raw code and it lists critical errors plus the rich-result features your markup makes you eligible for. Validate during development, not after release.
• schema.org’s Schema Markup Validator. Checks your JSON-LD against the schema.org vocabulary itself.
• Search Console after launch. The Rich results report shows which pages Google accepted and which lost eligibility, and the URL Inspection tool shows how Google actually renders the page. Google warns that validation is not a one-time task: rich results “might break after deployment due to templating or serving issues”, so re-check after every template change.

The errors that break JSON-LD, and the reasoning that fixes them

• Missing required fields. An Offer without priceCurrency, a ListItem without position: Google drops the incomplete object and you get no rich result at all.
• Markup that contradicts the page. A page that shows $49 marked up as $0, or an availability that says InStock while the page says OutOfStock. Google’s guidelines are explicit that markup must match what the user sees; mismatches cost trust faster than any rich result is worth.
• Conflicting or duplicate types. Two blocks claiming the same page is both Article and Product, or a plugin and an edge rewrite emitting different values, leave Google guessing which one you meant. Keep one coherent description per URL.
• The wrong level of specificity. WebPage or Thing says far less than BlogPosting, Product, Event or VideoObject. Use the most specific type that is true.

Keeping structured data correct at scale: inject it at the edge

On one page, hand-written JSON-LD is easy. On ten thousand pages it is where structured data dies: a new template, a product line with no price field, a CMS plugin that emits the same JSON-LD for every page type. The fix is to stop generating markup in the CMS and compute it per URL at the edge. A Cloudflare Worker sits in front of your site, forwards the request, reads the response, and injects the correct JSON-LD for that URL’s page type before returning it: a product template always emits Product, a post emits BlogPosting, an event emits Event, with fresh prices, dates and availability drawn from the same data that renders the page. One place to update, applied per request, no plugin and no release. Google explicitly supports the approach: JSON-LD is read even when it is dynamically injected into the page’s contents by JavaScript.

That is the pattern SEOEdgeAI runs: connect Cloudflare, and a Worker injects or repairs your structured data in front of every search-engine request. For the wider picture, our technical SEO automation post covers generating and testing structured data alongside canonicals and redirects, and the Cloudflare Workers examples article includes a copyable worker that injects JSON-LD by URL pattern.

Which types pay for themselves, by site type

The rule that survives every Google change: one honest, specific JSON-LD block per page, validated before it ships, re-validated after every template change, and on a large site generated per URL instead of pasted from a plugin.