What is JSON-LD?
Crawl, indexing and structured data
JSON-LD, short for JavaScript Object Notation for Linked Data, is a JSON based format for publishing linked data, the entities, properties and relationships on a page. It is the format most commonly used to add Schema.org structured data, such as Article and BreadcrumbList, which helps machines understand a page. JSON-LD is a W3C standard. It is not a ranking shortcut and valid structured data does not guarantee rich results. The markup must describe content actually visible on the page, and the page must be crawlable and indexable to benefit.
What this means
JSON-LD is a tidy way to describe what a page is about in a form machines can read. Instead of leaving a search engine to infer meaning from the words on screen, you state it directly, for example that this page is an article, with this headline, this author and this publish date.
It helps to separate four ideas that are often muddled. JSON is a general data format. JSON-LD is a specific flavour of JSON for linked data. Schema.org is the shared vocabulary of types and properties, such as Article or Person. Structured data markup is the practice of using a format like JSON-LD to publish that vocabulary on a page. JSON-LD is popular because it sits in a separate block of code rather than being woven through the visible HTML, which makes it easier to add, template and maintain.
Why it matters
Clear machine understanding is a quality of good publishing. When a search engine can reliably read who wrote a page, when it was updated and what it is about, the page is easier to represent accurately and to surface for the right queries. JSON-LD is the format Google recommends for this, although Microdata and RDFa are also supported and treated as equally valid when correctly implemented.
The commercial caution is that structured data is not magic. It does not lift rankings on its own, and correct markup does not guarantee a rich result. Search engines decide what to show based on many factors, and they can ignore or reject markup that is misleading or does not match the visible page. The value comes from accurate, representative markup on pages that are already worth showing, not from marking up thin or hidden content.
How it works
A W3C standard for linked data
JSON-LD is a published W3C standard. It first became a W3C Recommendation in 2014, and the current version, JSON-LD 1.1, became a Recommendation in 2020. It defines a JSON based way to serialise linked data so that the same information can be shared and understood across different systems. On web pages, it is most often used to publish Schema.org vocabulary inside a script block of type application/ld+json.
Common types and fields
For an article, the relevant Schema.org type is Article, or the more specific NewsArticle or BlogPosting. The fields that help a search engine understand the page include the headline, the author with a name and a URL, the date published, the date modified, an image and the canonical reference. A headline is best kept concise, since very long headlines can be truncated, and Google's guidance suggests keeping it within roughly 110 characters. Breadcrumbs are described with BreadcrumbList and its ListItem entries, which set out the position of the page within the site hierarchy.
The rule that markup must represent the page
Structured data must describe the content that is actually on the page and be representative of its main content. Marking up content that is hidden, irrelevant or misleading breaks the guidelines and can cause the markup to be ignored or treated as spam, which is a credibility boundary worth respecting. The markup is a true statement about the page, not an alternative version of it.
Where the markup is generated
JSON-LD can be added server side, through a content management system template, or injected with JavaScript, including through a tag manager. Each method works, but the injected approaches carry more risk. If a page begins with a noindex instruction, a search engine may skip rendering and never run the JavaScript that would have added the markup. Tag manager mismatches can also leave the rendered markup out of step with the page. Server side or template based markup that appears in the initial HTML is the most dependable.
Eligibility and AI features
Valid markup is necessary but not sufficient. A page must be indexable and eligible to show with a snippet before it can be considered for rich results or for generative features such as AI Overviews. Do not block structured data pages with robots.txt or noindex if you want them to be eligible. For Google's AI features specifically, there is no special structured data requirement and no special markup to add. The same foundations apply, namely a crawlable, indexable page that is eligible to appear with a snippet.
The current status of FAQ rich results
Structured data types change over time, and the FAQ feature is a clear recent example. Google's documentation states that, as of 7 May 2026, FAQ rich results are no longer appearing in Google Search. The FAQ search appearance, the rich result report and support in the Rich Results Test are being dropped in June 2026, and support for the FAQ rich result in the Search Console API will be removed in August 2026. FAQPage remains a valid Schema.org type, so the markup itself is not invalid and can stay in place, but it no longer produces that visible search feature. HowTo rich results were similarly deprecated in 2023, and the HowTo documentation has since been removed. The lesson for leaders is that rich result features come and go, while the underlying value of accurate, representative structured data endures.
Examples
A content team maps each page type to a matching Schema.org type, using Article for editorial pieces and BreadcrumbList for navigation context, and confirms the headline, author, publish date and modified date are populated from the correct fields rather than left at template defaults.
A business that previously added FAQ markup to win an expandable search feature reviews its pages after the feature was withdrawn. They keep the FAQ markup where it accurately reflects a real, visible question and answer section, and remove it where the section was thin and added only for the old feature.
A development team moves structured data out of a tag manager and into the page template, after finding that the injected markup sometimes failed to render. They then validate the rendered markup against the visible page using a structured data testing tool before each release.
Common misunderstandings
The most common error is expecting structured data to lift rankings. It helps machines understand a page, but it is not a ranking shortcut and does not guarantee a rich result.
A second is marking up content that is not visible on the page, which breaks the guidelines and can be treated as spam.
A third is assuming valid markup is enough. Structured data can be technically valid yet poor, with stale or wrong values, and correct markup still does not guarantee a rich result.
A fourth is confusing the building blocks. JSON, JSON-LD, Schema.org and structured data markup are distinct, and clarity about which is which prevents implementation mistakes.
Risks and boundaries
Field mapping failures are the most frequent practical risk. A content management system can publish a stale headline, the wrong dates, a default breadcrumb path or the wrong publisher, so the markup quietly misrepresents the page.
Over marking is a second risk, where teams mark up everything in the hope of more features, which adds noise without value.
Lifecycle and template risk is a third. A template change or plugin update can break or alter the markup silently, so it needs to be retested after changes.
The credibility boundary is the firm limit. Search engines can ignore or reject markup that is misleading or does not match the visible page, so the markup must always be a true representation of what a reader sees. Blocking structured data pages with robots.txt or noindex removes the eligibility that the markup was meant to support.
What to do next
Choose Schema.org types that genuinely match each page, and resist marking up content that is not present or not visible.
Align editorial and technical ownership, so the people who write headlines and dates and the people who build templates agree on where each field comes from. Audit your markup with a rich results testing tool, and compare the rendered structured data with the visible page to catch stale or mismatched values. Treat structured data as a durable investment in machine understanding rather than a chase for any single rich result feature, since features such as FAQ and HowTo have been withdrawn while accurate markup keeps its value.
FAQs
What is the difference between Article and BlogPosting?
BlogPosting is a more specific type of Article, intended for blog style posts, while Article suits general written content and NewsArticle suits journalism. Use the most specific type that genuinely fits the page. All three are supported and use similar fields.
Will JSON-LD help my pages appear in AI search?
Indirectly at most. A page must be indexable and eligible to show with a snippet before AI features consider it, and Google states there is no special structured data requirement for its AI features. Accurate markup supports machine understanding, but it is not a guaranteed route to AI visibility.
Is it safe to inject JSON-LD with JavaScript or a tag manager?
It can work, but it carries risk. If a page starts with a noindex instruction the search engine may skip rendering and never run the script, and tag manager setups can fall out of step with the page. Server side or template based markup in the initial HTML is more dependable.
Does valid structured data guarantee a rich result?
No. Correct markup makes a page eligible for a feature, it does not guarantee one. Search engines decide what to show based on many factors and may show a plain result instead.
What are the most common CMS mistakes with JSON-LD?
Stale or wrong field values, such as an old headline, incorrect publish or modified dates, a default breadcrumb path or the wrong publisher. These come from poor field mapping and are caught by comparing the rendered markup with the visible page.
Do FAQ rich results still appear in Google?
No. Google's documentation states that, as of 7 May 2026, FAQ rich results no longer appear in Google Search, with reporting and testing support being removed in June 2026 and Search Console API support in August 2026. FAQPage remains a valid Schema.org type, so the markup is not invalid, it simply no longer produces that feature.
Should I remove my FAQ structured data now?
Not necessarily. Keep it where it accurately describes a real, visible question and answer section, since unused structured data does not cause problems. Remove it where the section was thin or added only to win the old feature.
Which structured data format should I use?
Google recommends JSON-LD for its ease of implementation and maintenance, although Microdata and RDFa are also supported and treated as equally valid when correctly implemented. For most new work, JSON-LD is the practical default.
Is JSON-LD only useful for Google?
No. It is an open W3C standard for linked data used across many systems, and other search engines and tools can read Schema.org markup published in JSON-LD. Its value is general machine understanding, not a single platform.
Sources
JSON-LD 1.1 (W3C). Confirmation that JSON-LD is a W3C Recommendation and a JSON based format for serialising linked data.
JSON-LD 1.1 Specifications are W3C Recommendations (W3C). The date JSON-LD 1.1 became a W3C Recommendation and the description of its purpose.
FAQPage type (Schema.org). Confirmation that FAQPage remains a current, valid Schema.org type that is not deprecated.
Mark Up FAQs with Structured Data (FAQPage) (Google Search Central). The deprecation notice stating FAQ rich results no longer appear as of 7 May 2026, with reporting and Rich Results Test support removed in June 2026 and Search Console API support removed in August 2026.