On May 7, 2026, Google fully retired FAQ rich results. Even the last remaining exception — government and health sites — lost the feature. And yet, around the same time, the SEO community has been talking more than ever about getting JSON-LD right. What's going on here? This guide walks through exactly what JSON-LD is, the code you actually need in 2026, and the mistakes that keep breaking it. Every snippet is written so you can copy it, swap in your own domain, and ship it today. (And yes, this article itself is marked up in JSON-LD from head to toe 😄)
What Exactly Is JSON-LD?
JSON-LD stands for "JavaScript Object Notation for Linked Data." The name sounds intimidating, but the idea behind it is simple. It's just regular JSON with an added vocabulary (schema.org) that tells machines what the data actually means. Here's an analogy. When you receive a business card, you instantly know which line is the name, which is the job title, and which is the company — your brain uses layout and convention to sort it out. Computers don't have that intuition. A search engine looking at raw HTML can't reliably tell whether a line of text is the author's name or just another sentence of body copy. JSON-LD is the labeling system that puts sticky notes on that business card for machines.
Technically, it lives inside a dedicated <script type="application/ld+json"> block. It's completely separate from the visible HTML, so no matter how the page design changes, the structured data can be managed on its own. Here's a fun detail: that script block never actually "runs" as JavaScript. Because of the type="application/ld+json" attribute, browsers just skip right over it. Only search engine crawlers and AI crawlers bother to parse it. So you can add it freely without worrying about page load performance or breaking anything visually.
There are two other ways to express the same schema.org vocabulary — Microdata and RDFa — but if you're building something new, there's really no reason to consider them. Microdata bakes meaning directly into HTML attributes (itemscope, itemprop, and so on), which means every time your design changes, your structured data has to change with it. RDFa has similar limitations. Google's own documentation, updated in February 2026, states plainly that JSON-LD is recommended because it's the easiest format for site owners to implement and maintain. All three formats are technically equally valid to Google when implemented correctly, but in practice, JSON-LD is the obvious choice — especially if you're working in React, Vue, or any component-based framework. You just treat structured data as one more data object and render it wherever the component lives.
It's worth zooming out on schema.org itself for a second. schema.org was founded in 2011 as a joint effort by Google, Microsoft, Yahoo, and Yandex. It's a shared agreement on how to describe things like "person," "place," "event," "article," and "product" so that everyone uses the same vocabulary. JSON-LD is the "container" that holds that schema.org vocabulary in JSON syntax; schema.org is the "dictionary" that defines what goes inside the container and how. People sometimes conflate the two and say "JSON-LD has 800-plus types," but more precisely, schema.org defines over 800 types, and JSON-LD is simply one format for expressing them.
The "LD" in JSON-LD stands for "Linked Data," and the concept traces back to the broader "Semantic Web" vision that Tim Berners-Lee, the inventor of the web, began championing in the early 2000s. The core idea is straightforward: just as web pages link to each other through hyperlinks, data should be linked through meaning. An "author" on one site should connect to the "same author" on another; a product on one page should connect to the same product elsewhere. It's genuinely interesting that a vision from nearly two decades ago is only now reaching practical maturity in the age of AI search.
"Structured data isn't something that directly boosts your ranking. It helps search engines understand your content more accurately, which opens the door to richer ways your content can be shown in search results." – paraphrased from Google Search Central's official guidelines
There's an important misconception worth clearing up here. "Add JSON-LD and your rankings go up" simply isn't accurate. Google has repeatedly stated that structured data is not a direct ranking factor. But the indirect effects are real: rich snippets lift click-through rates, clearly identified entities (brands, people, places) reinforce trust signals, and as of 2026, structured data also affects whether you get cited in AI search results. It's not a magic wand for rankings, but skipping it is a real cost — think of it as basic fitness. Foundational conditioning alone won't win you a medal, but no flashy technique survives long without it.
Quick glossary — Entity: a person, brand, or place that search engines recognize as a single, distinct "thing." Knowledge Graph: Google's massive database of entities and the relationships between them. Rich Result: a search result enhanced with stars, images, or dropdowns beyond a plain text link. GEO (Generative Engine Optimization): optimizing not for ranking position, but for being cited in AI-generated answers.
Why It Matters More in 2026: AI Search
JSON-LD used to have basically one job: rich snippets — star ratings, breadcrumbs, FAQ dropdowns, that sort of thing. That's no longer the whole story. Google's AI Overviews and AI Mode, along with generative search tools like ChatGPT, Perplexity, Gemini, and Claude, all have to decide which pages to cite when generating an answer. JSON-LD has become the fastest channel for delivering "this is a trustworthy source" information to those systems.
Different platforms don't all use structured data in exactly the same way. Google's AI Overviews and AI Mode lean heavily on Google's own Knowledge Graph alongside index data, which makes entity links via sameAs especially valuable. ChatGPT's browsing feature fetches and parses pages in real time, and there's a fair amount of anecdotal evidence that it checks structured publish-date and author fields before relying on the body text. Perplexity attaches a source card to every cited answer, so pages with clear publisher and author metadata are more likely to show up looking like a credible source in that card. The platforms differ in mechanics, but the underlying logic is the same: content that helps AI verify "who made this and can it be trusted" climbs the citation priority list faster.
It makes intuitive sense once you think about it. For an AI to cite an article, it needs to quickly confirm who wrote it, who published it, and when. Reading structured author, publisher, and datePublished fields is far faster and more reliable than trying to infer all of that from body text. Adding sameAs links to official social profiles or a Wikipedia entry on your Organization and Person schema helps AI systems connect your brand to the correct entity in the Knowledge Graph instead of confusing it with an unrelated site of the same name. If you happen to share a name with other people online, linking to a verifiably-yours GitHub or LinkedIn profile via sameAs sends a strong signal that "this author is specifically this person, not someone else with the same name."
Let's make this concrete. Imagine a blogger with a common name writing travel posts, and there happens to be a well-known figure in a completely different field who shares that exact name. Without sameAs, an AI system might merge the two into a single entity by mistake. But if the author's sameAs points to their own GitHub, Instagram, or personal site, the system has solid grounds to treat them as two distinct people despite the shared name. That's entity disambiguation in action, and it's one of the concrete problems structured data actually solves.
This whole trend connects naturally to Google's long-standing E-E-A-T concept (Experience, Expertise, Authoritativeness, Trustworthiness). E-E-A-T itself isn't a schema property — it's a content-quality philosophy — but fields like author, publisher, and sameAs are the bridge that turns that philosophy into something machines can read. What used to be a judgment call a human reader made about "who wrote this, and on what authority" is now something structured data lets an AI system arrive at faster.
A word of caution about the statistics floating around on this topic: take them with a grain of salt rather than as gospel. Some SEO blogs claim things like "AI Overviews now appear on more than half of US searches" or "pages with FAQ schema are several times more likely to be cited in AI Overviews." Sources and methodologies vary wildly, so treat the exact numbers skeptically — but the general direction is something the industry broadly agrees on. Pages with structured data do appear to have an edge in AI citation over pages without it. One thing Google has been explicit about, though: there's no special "AI Overview schema" or secret markup that unlocks AI visibility. Clearly structuring the content that's already visible on the page is, in itself, the AI optimization. There's no hidden markup to go hunting for, which is honestly a relief.
This is also where the term GEO (Generative Engine Optimization) has found its footing. Traditional SEO was about getting your link onto page one of search results. GEO is closer to getting an AI system to pick your content as a source when it generates an answer. The two goals aren't opposites, but the priorities shift a bit — clear definitions, direct question-and-answer structure, and trustworthy source metadata all matter more from a GEO lens. JSON-LD happens to be the most efficient way to deliver that third piece: trustworthy source metadata.
Key takeaway
JSON-LD is no longer just "a tool for Google rich snippets." Its role has expanded into a core signal that AI search tools like ChatGPT, Perplexity, and Gemini use to quickly judge a page's source and trustworthiness. The principle that markup must match what's actually visible on the page matters just as much as ever.
Mastering the Basic Syntax
Actual code makes this click much faster. Let's write the most basic BlogPosting schema, using a blog post as the example — in fact, every single post on this blog uses exactly this structure.
Before we get to that, here's a quick reference table for @type, since picking the right one trips people up more than it should.
| Type | Best for | Notes |
|---|---|---|
| Article | Generic written content | A safe default when nothing more specific fits |
| BlogPosting | Personal or company blog posts | The right fit for most blog content, including this one |
| NewsArticle | News and current-events reporting | More closely tied to Google News features |
| TechArticle | Technical docs and tutorials | Supports dedicated properties like dependencies, proficiencyLevel |
For a typical blog post like this one, BlogPosting is the sensible default, and plain Article works fine if you don't feel the need to be more specific. Don't spend too much time agonizing over the exact subtype — it's far more valuable to spend that time making sure whichever type you pick has every required field filled in accurately.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide-en.html"
},
"headline": "The Complete JSON-LD Guide: Why Structured Data Still Matters in 2026",
"description": "Why JSON-LD matters more than ever for SEO and AI search visibility in 2026",
"image": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide.webp",
"author": {
"@type": "Person",
"name": "Gardenee",
"url": "https://agmazon.com/"
},
"publisher": {
"@type": "Organization",
"name": "Gardenee Blog",
"logo": {
"@type": "ImageObject",
"url": "https://agmazon.com/background/jennie.png"
}
},
"datePublished": "2026-06-24T12:00:00+09:00",
"dateModified": "2026-06-24T12:00:00+09:00"
}Let's walk through the fields one by one. @context declares that this document uses the schema.org vocabulary — it's basically a fixed value, so there's nothing to memorize. @type defines what kind of thing this data describes; for written content, pick Article, BlogPosting, or NewsArticle depending on what fits. mainEntityOfPage explicitly ties this structured data to the page it describes, while headline and description need to match what a human reader actually sees on the page — writing something different here is a direct violation of Google's guidelines.
author and publisher are, in the age of AI citation, arguably the most important fields of all. The clearer "who wrote it and who published it" is, the stronger the trust signal. datePublished and dateModified need to follow ISO 8601 format precisely (YYYY-MM-DDTHH:mm:ss+09:00). Sloppy dates, or bumping dateModified to today's date without actually changing anything — a kind of "freshness gaming" — erodes trust over time and is worth avoiding.
To flesh out the author field, it's worth adding sameAs to your Person object. This makes it easier for search engines and AI systems to confirm "this author is the same person who exists elsewhere on the internet."
"author": {
"@type": "Person",
"name": "Gardenee",
"url": "https://agmazon.com/",
"sameAs": [
"https://github.com/unluckysoon"
]
}A couple of practical rules around titles and images are worth knowing too. Keep headline under roughly 110 characters, since longer titles can get truncated in some rich result formats. For image, Google recommends a high-resolution image at least 1200px wide, ideally available in multiple aspect ratios (square, 4:3, 16:9) to fit different result layouts. A single image URL string works, but supplying an array of multiple ratios is also a fine choice.
One last thing before moving on — here's a broken-then-fixed comparison of a mistake that comes up constantly. See if you can spot the difference.
Commonly broken code — { "name": "Gardenee Blog", "url": "https://agmazon.com/", } There's a trailing comma after the last property, and the quotation marks have been auto-converted into curly "smart quotes" by a word processor. Either one alone is enough to make a JSON parser discard the entire block.
Fixed code — { "name": "Gardenee Blog", "url": "https://agmazon.com/" } The trailing comma is gone, and every quotation mark is a plain straight double-quote ("). If you ever draft JSON in Word, Notion, or a notes app instead of a code editor, double-check exactly these two things.
Real Code: Organization, Breadcrumb, @graph
A single blog usually needs several schema types at once — the author (Person), the publishing organization (Organization), and the current location in the site (BreadcrumbList) all tend to live on the same page. Writing each of those as a separate <script> block means the same information gets duplicated across the page, which gets tedious to maintain. This is exactly what @graph is for: it lets you declare multiple entities inside one JSON-LD block and link them together using @id.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://agmazon.com/#organization",
"name": "Gardenee Blog",
"url": "https://agmazon.com/",
"logo": "https://agmazon.com/background/jennie.png",
"sameAs": [
"https://github.com/unluckysoon"
]
},
{
"@type": "WebSite",
"@id": "https://agmazon.com/#website",
"url": "https://agmazon.com/",
"name": "Gardenee Blog",
"publisher": { "@id": "https://agmazon.com/#organization" }
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://agmazon.com/blog/index-en.html" },
{ "@type": "ListItem", "position": 2, "name": "Technology", "item": "https://agmazon.com/blog/categories-en.html" },
{ "@type": "ListItem", "position": 3, "name": "The Complete JSON-LD Guide" }
]
}
]
}The benefit here is straightforward: declare the publisher information exactly once, and every other entity just references it by @id. If your company logo or name ever changes, there's only one place to update it. The cleanest setup is to put site-wide values that don't change — Organization, WebSite, Person — into your shared template (in this blog's case, article-template.html), and only add the page-specific BlogPosting and BreadcrumbList values per article.
It's worth settling on a naming convention for @id values. A common pattern is appending a # and a short label to a URL — things like domain#organization, domain#website, pageURL#webpage, pageURL#blogpost, or domain#person-name. Sticking to a consistent pattern means that even after hundreds of articles, it's never ambiguous what a given @id points to. Conversely, improvising new @id values on every page tends to create a "self-reference tangle," where the same organization ends up with a different @id on every page, raising the risk that search engines treat what should be one entity as several different ones. Whatever naming convention you settle on, write it down somewhere — a shared doc if you work with a team, or just a personal note if you're running a solo blog, so future-you doesn't have to reverse-engineer it months later.
You can also attach a potentialAction to your WebSite schema to wire up search functionality. Doing so makes you eligible for Google to display a small search box beneath your sitelinks in search results. If your site already has a search feature, this is a fairly simple addition. The target field should point at your actual search-results URL pattern, and {search_term_string} gets substituted with whatever the user typed. Whether Google actually decides to display this feature is out of your hands, but having the markup correctly in place costs you nothing.
{
"@type": "WebSite",
"@id": "https://agmazon.com/#website",
"url": "https://agmazon.com/",
"name": "Gardenee Blog",
"potentialAction": {
"@type": "SearchAction",
"target": "https://agmazon.com/blog/articles-en.html?q={search_term_string}",
"query-input": "required name=search_term_string"
}
}If you run an e-commerce site, the Product type is worth implementing; if you have a physical storefront, LocalBusiness is worth a look too. For Product, the four essentials are name, image, offers (price and stock status), and aggregateRating (average rating and review count) — if even one of these is missing, stars or pricing may not appear in search results. LocalBusiness structures your address, hours, and phone number for map-related search features.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Sample Product",
"image": "https://example.com/product.webp",
"offers": {
"@type": "Offer",
"priceCurrency": "USD",
"price": "29.00",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "128"
}
}For a content-focused site like this blog, though, five types cover everything you actually need: Article (or BlogPosting), Organization, Person, BreadcrumbList, and — if you have search — WebSite's SearchAction. Stuffing in unrelated schema types is far less effective than implementing a small set completely and accurately.
If images or video are central to your content, it's worth writing image as an explicit ImageObject instead of a plain URL string. Including width and height lets search engines skip re-downloading the image just to check its dimensions, which speeds up processing. For video content, VideoObject with a thumbnail, upload date, and duration makes you a candidate for video-related rich results.
"image": {
"@type": "ImageObject",
"url": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide.webp",
"width": 1200,
"height": 675
}Let's pull every piece covered so far into one combined @graph example — one that could realistically be dropped into this very article. Seeing Organization, WebSite, Person, BreadcrumbList, and BlogPosting all reference each other via @id inside a single block should make it click how everything explained separately above fits together.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://agmazon.com/#organization",
"name": "Gardenee Blog",
"url": "https://agmazon.com/",
"logo": "https://agmazon.com/background/jennie.png",
"sameAs": ["https://github.com/unluckysoon"]
},
{
"@type": "WebSite",
"@id": "https://agmazon.com/#website",
"url": "https://agmazon.com/",
"name": "Gardenee Blog",
"publisher": { "@id": "https://agmazon.com/#organization" }
},
{
"@type": "Person",
"@id": "https://agmazon.com/#person-gardenee",
"name": "Gardenee",
"url": "https://agmazon.com/",
"sameAs": ["https://github.com/unluckysoon"]
},
{
"@type": "BreadcrumbList",
"@id": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide-en.html#breadcrumb",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://agmazon.com/blog/index-en.html" },
{ "@type": "ListItem", "position": 2, "name": "Technology", "item": "https://agmazon.com/blog/categories-en.html" },
{ "@type": "ListItem", "position": 3, "name": "The Complete JSON-LD Guide" }
]
},
{
"@type": "BlogPosting",
"@id": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide-en.html#blogpost",
"headline": "The Complete JSON-LD Guide: Why Structured Data Still Matters in 2026",
"isPartOf": { "@id": "https://agmazon.com/#website" },
"breadcrumb": { "@id": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide-en.html#breadcrumb" },
"author": { "@id": "https://agmazon.com/#person-gardenee" },
"publisher": { "@id": "https://agmazon.com/#organization" },
"datePublished": "2026-06-24T12:00:00+09:00",
"dateModified": "2026-06-24T12:00:00+09:00"
}
]
}Five entities live in this one block, and not a single piece of information is duplicated. The organization name exists only inside Organization, the author info only inside Person, and everything else is wired together purely through @id references. Build this structure once as a template, and from then on, every new post only needs its BlogPosting and BreadcrumbList values changed. The upfront template work takes a bit of time, but after that, publishing a new post becomes a quick copy-paste job.
The End of FAQ Rich Results — and What Remains
This is actually the specific event that prompted this article. FAQPage schema was, for years, basically the "national schema" of SEO professionals. The expandable question-and-answer dropdown it produced directly under a search listing took up extra screen real estate, and that extra real estate translated into a real click-through rate boost. That golden era is, for all practical purposes, over. Here's the timeline.
Google officially launched FAQ rich results. Sites that added the schema saw their listings take up dramatically more vertical space in search results.
Widespread abuse led Google to restrict FAQ and HowTo rich results to "well-known, authoritative government and health websites." For everyone else, the feature was effectively dead from this point on.
Separately from FAQ, seven additional structured-data types deemed low-usage and low-value were trimmed from Search appearance features — a sign that Google regularly puts its rich result lineup on a diet.
After the March core update, tracking data from multiple sources showed FAQ rich result impressions noticeably declining even for the remaining eligible government and health sites.
Google added a deprecation notice to its official documentation. The last remaining exception — government and health sites — was removed, and FAQ rich results disappeared from search entirely. There was no flashy blog announcement; just a single quiet line added to the top of a developer doc.
Search Console's FAQ report and Rich Results Test support are scheduled to end in June, with Search Console API support following in August.
FAQPage hasn't disappeared entirely. What Google removed is the "rich result feature" — the visual dropdown rendered in search results. The FAQPage schema type itself remains fully valid in schema.org, and Google has officially stated it still reads this markup to understand page content.
So what does this mean in practice? The conclusion is this: adding FAQPage purely to grab more screen real estate in search results no longer makes sense. But if a page has genuine, visible FAQ content, keeping FAQPage markup on that content still has value, for two reasons. First, question-and-answer format is one of the easiest structures for AI search tools to extract and cite. Second, as Google itself confirmed, the markup is still used to understand the page. Just drop any expectation that it'll produce a dropdown in search results like it used to.
If you're wondering why Google went to this much trouble, the backstory makes it click. After FAQ rich results launched in 2019, the feature became an irresistibly attractive way to occupy more search-result real estate. Sites started bolting fake FAQ sections onto pages that had little to no actual question-and-answer content — plain product pages, even ad-heavy landing pages — purely to grab the visual boost. HowTo rich results were restricted to desktop around the same time for similar reasons, and were later phased out as well. The pattern is clear: Google has a track record of periodically cleaning up features that inflate a result's visual footprint regardless of content quality.
It's also worth distinguishing FAQPage from the often-confused QAPage. FAQPage is for a single, official answer written by the site owner; QAPage is for forum-style content where multiple users submit answers. The difference is clearer side by side in code.
// FAQPage: a single official answer from the site owner
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Does JSON-LD directly affect search rankings?",
"acceptedAnswer": {
"@type": "Answer",
"text": "No. Google has officially stated that structured data is not a direct ranking factor."
}
}
]
}QAPage is structurally more complex, since multiple answers can exist per question, each with its own author and acceptance status. Unless you're running a community forum or Q&A service, you'll rarely need QAPage on a regular blog, so we won't go deeper into its code here. What matters is developing the judgment to correctly identify which of the two your content actually is.
The retirement of FAQ rich results is really just one scene in a bigger pattern. Google has quietly retired low-usage or low-value search appearance features before. In January 2026, a deprecation notice for a particular educational content feature was quietly added to the documentation, and Google also clarified — again — that Dataset structured data is used only by Dataset Search, not by Google Search itself. Given this pattern, it's worth periodically checking which Search feature, if any, a given schema type is currently tied to. Features tend to disappear quietly while the markup itself just sits there, unchanged, for far longer than you'd expect.
9 Mistakes That Keep Breaking Your Markup
JSON-LD's syntax is simple, which is exactly why the same mistakes keep showing up over and over. Interestingly, it's not only beginners who trip on these — even sites that have been live for years tend to reintroduce the exact same bug whenever a template changes or a new person takes over maintenance. Here are the patterns that show up most often. Run through them and check whether any apply to your own site.
-
1
Marking up content that isn't actually visible
If the information in your JSON-LD doesn't appear on the actual page, Google can treat it as spam. Mark up five reviews when only three are visible on the page, for example, and you're showing search results a score users never actually see — a clear policy violation. Markup and what's on screen must match 1:1. This often breaks quietly during a redesign, when a section of the visible page gets removed but the corresponding JSON-LD is left behind — so add structured data to your checklist every time you touch the page design.
-
2
Re-declaring Organization schema on every page
Repeating the same organization info on every page raises the odds that something eventually drifts out of sync — a logo URL updated on one page and forgotten everywhere else is a classic example. Declare it once, globally, and reference it everywhere via @id.
-
3
Smart quotes from a word processor
Copying code out of Word or Notion often auto-converts straight quotes (") into curly "smart quotes" (“ ”), which silently breaks JSON parsing. They look almost identical on screen, making this a classic, maddening debugging trap.
-
4
Trailing commas
JSON doesn't allow a trailing comma after the last item in an array or object. JavaScript object literals do allow this, so the habit bleeds over and trips people up constantly.
-
5
Filling in only some required fields
Missing AggregateRating on a Product means no star rating appears; missing author on an Article means no byline shows up. Partial implementation gets you almost no rich result benefit, and on top of that, it can come across as "half-accurate data."
-
6
Dates that don't reflect reality
Bumping dateModified to today's date without actually editing the content — "freshness gaming" — erodes trust signals over the long run. Only update dateModified when you've genuinely revised the content.
-
7
Mixing up FAQPage and QAPage
Whether content is a single official answer from the site owner or a forum-style thread with multiple user answers determines which type is correct. The two types require different structures, and mixing them can get the entire markup ignored.
-
8
Implementing once and never re-validating
A CMS template change or a plugin update can quietly break markup that worked perfectly on launch day. It's genuinely common to find that code which worked fine months ago has silently vanished after a template refresh. Periodic re-validation is necessary.
-
9
Language mismatches on multilingual pages
It's surprisingly common to find an English page with a Korean meta description left over, or vice versa. Each language version's JSON-LD has to match the actual language visible on that specific page. If hreflang and your JSON-LD content point to different languages, that sends a confusing signal to search engines.
The 2026 Validation Workflow
It's worth knowing the history of Google's structured-data testing tools too. The old "Structured Data Testing Tool" was phased out starting in 2020, and its job is now split between two tools: Rich Results Test, which checks eligibility for Google's own search features, and Schema Markup Validator, which checks broader compliance against the schema.org standard. Because they serve different purposes, the standard practice is to use both. Rather than retiring the old tool wholesale, Google split it into a Google-specific validator and a general-purpose schema.org validator — a sensible move, since "is my markup eligible for Google rich results" and "is my markup spec-compliant" are genuinely different questions that deserve separate, more precise answers.
If you're writing JSON-LD for the first time, you don't need to memorize both tools right away — just start with Rich Results Test. Paste in a URL or raw code, and within seconds you'll see which rich result types you're eligible for and which fields are missing, explained in plain language. Once you're comfortable with that, move on to Schema Markup Validator for a more thorough spec-compliance check — it's a gentler learning curve than tackling both at once.
In practice, an efficient sequence looks like this: right after writing new markup, paste the code into Rich Results Test or Schema Markup Validator and get red errors (missing required fields, etc.) down to zero. After deployment, test the live URL again to confirm it renders the way you intended. Then, one to two weeks later, check Search Console's Enhancements report to confirm there are no errors in what Google actually crawled. There's a subtle trap here: the Enhancements report doesn't reflect your markup "right now" — it reflects whatever Google's crawler saw the last time it visited. So an error you already fixed might linger in the report for a few extra days. That's not a bug in the report; it's just crawl lag, and there's no need to panic over it.
It also helps to know what the common warning messages actually mean. "Missing field" shows up in red and blocks rich result eligibility outright — a required property for that schema type is simply absent. A "recommended field is missing" appears as a yellow warning; it won't block eligibility on its own, but filling it in improves the quality of the display. "Invalid value type" appears when the data type itself is wrong — a date written as a number instead of a string, or a single object where an array was expected, for example. The sensible order is: fix every red error first, then circle back to yellow warnings when you have spare time.
Worth noting separately: Rich Results Test has no standalone public API. If you need to check dozens of pages automatically, you'll need the URL Inspection feature inside the Search Console API, or a crawler-based tool. For a blog with hundreds of posts, checking every single one by hand simply isn't realistic. This is why a growing number of teams add a schema-validation step to their build pipeline (GitHub Actions, for example) — walking every URL in the sitemap, parsing the JSON-LD, and blocking deployment if anything violates schema.org rules. A small personal blog doesn't need to go this far, but once you're approaching thousands of posts, it's worth the investment.
Community reactions are interesting too. On r/SEO, you'll occasionally find an informal write-up describing an experiment along these lines: three nearly identical pages, same content, same keyword difficulty, with only the structured data varying — and the one with properly implemented JSON-LD was the only one cited in an AI Overview, and also ranked highest. These experiments are limited to a single case each and can't fully control for every other variable, so the right takeaway isn't to treat the result as proven fact, but rather a reasonable conclusion that "implementing structured data properly is unlikely to hurt, and may genuinely help."
Reactions from the developer community follow a similar thread. One developer wrote about adding JSON-LD to their personal blog for the first time, walking through the actual code, and made a point worth repeating: this block of code is just inert text as far as the browser is concerned, but it means something entirely different to search engines and AI crawlers. Since nothing visibly changes on the page, it's natural to wonder at first whether it's "really doing anything." But that very invisibility is exactly why it's low-risk to experiment with — a mistake here doesn't hurt the user experience, and validation tools let you catch and fix problems immediately, which keeps the cost of getting it wrong refreshingly low.
Wrapping Up: A Practical Checklist
This was a long read, but the conclusion is simple. JSON-LD isn't a flashy trick — it's basic conditioning. Write information that exactly matches what's visible on the page, under the correct schema type, with nothing missing. That's the whole job. It's also worth emphasizing that none of this requires expensive tools or plugins — a text editor and a validator are all you need to get started today. Before the checklist, here are a few questions that tend to come up while doing this work.
Frequently asked questions
Q: My WordPress SEO plugin already adds JSON-LD automatically. Do I still need to pay attention to it?
Most SEO plugins do a reasonably good job with basic Article and Organization schema. But fields plugins often leave blank — author sameAs, correctly sized images, BreadcrumbList — are worth filling in yourself. Check the "Advanced" or "Schema" tab in your plugin's settings; you'll often find blank fields more easily than you'd expect. It's also worth running plugin-generated code through Rich Results Test at least once to put your mind at ease.
Q: How does this work on static-site generators like Jekyll, Hugo, or Astro?
In most cases, you just lean on the templating engine's variable substitution. Put title, date, and author values in each post's front matter, then have your shared layout file plug those values into a JSON-LD template. This blog works on a similar principle — change a few variables in a Python script and the JSON-LD for each post fills in automatically.
Q: For a multilingual site, does each language need its own separate JSON-LD?
Yes — each language page needs its own headline and description that match the content actually visible on that page. That said, if you've already declared language relationships via hreflang, there's no need to duplicate that relationship inside JSON-LD as well. Each page just needs to accurately describe its own content.
Q: Is there a penalty for removing all structured data at once?
No. Google has officially stated that unused structured data doesn't cause problems for Search. That said, since there's almost no downside to keeping it, and there's a genuine upside for AI citation, it's hard to find a good reason to remove it.
Q: Can a single page have multiple JSON-LD <script> blocks?
Yes. Google parses every JSON-LD block on a page regardless of how many there are. For maintainability, though, it's best to group related entities into a single @graph as described above, and only split into separate blocks for genuinely unrelated information — say, site-wide data versus page-specific data.
Q: If I update the JSON-LD on an already-indexed page, does it show up in search right away?
No. Google needs to re-crawl the page and refresh its index before the change is reflected, which can take anywhere from a few days to a few weeks. Requesting reindexing through Search Console's URL Inspection tool can speed that process up a little.
Q: What about HowTo, Recipe, or Event schema, which this article didn't cover?
For content-focused sites like this blog, the five types covered here (Article, Organization, Person, BreadcrumbList, WebSite) are enough. But if you publish recipes, use Recipe; if you list events, use Event; and if step-by-step instructions are central to your content, HowTo is still valid — look it up on the official schema.org docs and apply the same principles covered here: fill in every required field, and keep it matched to what's visible on the page.
Now, here's the checklist to run through when you apply everything in this guide.
- Does your Article/BlogPosting have headline, description, author, publisher, and datePublished all filled in?
- Are Organization and Person declared once site-wide and referenced everywhere via @id, with no duplication?
- Have you added sameAs links to official social profiles to disambiguate your entities?
- Does everything in your markup match 100% with what's actually visible on the page?
- Is FAQPage reserved for genuinely visible Q&A content, with no expectation of a rich result?
- Are you using a consistent @id naming pattern (like domain#organization) site-wide?
- Have you confirmed zero errors in Rich Results Test and Schema Markup Validator before deploying?
- Do you have a plan to re-check Search Console's Enhancements report 1–2 weeks after deployment?
- If your post count grows, do you have a periodic bulk re-validation routine in place?
Every snippet of code in this guide is written so you can copy it, swap in your own domain and details, and ship it as-is. If your site still has FAQPage schema sitting around, now might be a good time to check that it still matches what's actually visible on the page. Structured data is the kind of work that, once properly set up, barely needs touching afterward — a genuinely good return on the time invested. It's the kind of unglamorous task that's easy to keep putting off, but the longer it sits, the more there is to clean up all at once later. Thanks for reading all the way through 🙌