json-ld · definition
JSON-LD: how a page states its facts in machine-readable form
A block of JSON in the page that tells search engines and assistants what the page is: the product, the article, the author, the questions. What it does, which types earn anything, and where it goes wrong.
JSON-LD (JavaScript Object Notation for Linked Data) is a W3C format that embeds structured data in a page as a JSON block, telling search engines and assistants what the content represents — a product, an article, an FAQ.
reviewed 2026-09-02 · by the IT Master editorial team · how we check facts
What JSON-LD is in practice
JSON-LD stands for JavaScript Object Notation for Linked Data. On a web page it is a script block — <script type="application/ld+json"> — holding one JSON object: a @context pointing at Schema.org, a @type naming what the thing is, and properties describing it.
Two things separate it from the older microdata and RDFa approaches. It sits apart from the visible HTML instead of being woven through it as attributes, so one template can emit it and a plugin can rewrite it without anyone touching the layout. And it is linked data: nodes carry an @id and reference each other, so an Article node can point at its author, its publisher and its hero image as separate nodes inside a single @graph.
A typical article declares five or six types — Organization, WebSite, Person, Article or BlogPosting, ImageObject, often FAQPage and BreadcrumbList. A product page declares Product with an offer, a price, availability and a GTIN or MPN. A branch page declares LocalBusiness with opening hours.
One rule overrides the rest: the markup must describe what a visitor can actually see. Schema claiming a review, a price or an FAQ the page does not show is a manual-action risk, not a shortcut.
JSON-LD (JavaScript Object Notation for Linked Data) is a W3C format that embeds structured data in a page as a JSON block, telling search engines and assistants what the content represents — a product, an article, an FAQ.
Why JSON-LD matters in 2026
Structured data does not rank a page. It decides how the page can be shown, and how confidently a machine can quote it.
On Google's side, most enhanced results are gated on markup: price and availability on a product, breadcrumbs under the title, article dates, event and recipe panels, review snippets where they are still permitted. Google narrowed FAQ rich results to a small set of well-known health and government sites in 2023, so FAQPage markup rarely draws anything visible in the results for anyone else. It still describes the page correctly for everything else that reads it.
That everything else is the newer reason to care. Assistants assemble answers from passages, and a page that names its author, its dates, its product identifiers and its question-and-answer pairs in a fixed vocabulary leaves nothing to infer. Nobody outside those companies can prove a citation weighting for schema, and we will not claim one. The defensible version: markup removes ambiguity, and ambiguity is what gets a source dropped in favour of a clearer one.
The same argument runs through answer engine optimisation and LLM SEO. Structured data is the cheapest part of it, and the part most often left half-built.
How this engine ships JSON-LD
Every article the engine publishes arrives with its JSON-LD already written: the article itself, its author and its dates, the hero image, and the FAQ block that appears on the page. Nothing has to be bolted on afterwards, and the markup describes what a reader can actually see, because it is generated from the same article.
The schema travels with the article on every delivery route, so it does not depend on your stack. The WordPress plugin publishes the post and fills the Yoast or Rank Math fields. The Next.js SDK and the REST pull feed return the schema alongside the body for you to render as it stands. A signed webhook posts the same payload to any endpoint you nominate. Shopify and Webflow we set up on request; Wix and Squarespace get a copy-paste queue.
Two honest limits. Markup is only as accurate as the article under it, which is why every draft goes through cross-model validation first: fact-check, novelty and E-E-A-T critique run by models from a different vendor than the writer. And correct markup is table stakes rather than a lever. To see what a URL declares today, the free AEO checker scores whether it carries Article and FAQ schema.
Common misunderstandings
"Adding schema lifts rankings." It does not. It changes what a result is eligible to display and removes guesswork for anything parsing the page. Traffic that arrives after a schema fix usually came from a better-looking result, not a better position.
"More types is better." Declaring types the page does not support gets the markup ignored at best and earns a structured-data manual action at worst. Mark up what is on the page.
"It has to be in the head." Either works. Google reads JSON-LD wherever it sits in the document, including blocks injected by JavaScript, though server-rendered markup is the safer bet on a page that renders slowly or partially.
"Valid means eligible." A syntax validator and the Rich Results Test answer different questions. Markup can be perfectly valid while a required property — an image, a date, an offer price — is missing, and the enhancement never appears.
"One page, one block." Several blocks are legal and search engines merge them. A single @graph with @id references is tidier and makes the relationships explicit.
"Schema replaces on-page structure." It describes the page; headings, a plain answer near the top and readable prose are still what gets lifted into an answer.
questions people ask
Does JSON-LD improve my rankings?
Not directly. Structured data is not a ranking factor in itself. What it does is make a page eligible for enhanced results such as breadcrumbs, product price and availability or review snippets, and state facts in a form nothing has to infer. The traffic gains people attribute to schema usually come from a better-looking result rather than a better position. Treat it as a display and clarity mechanism you get right once and then leave alone, and spend the effort you save on the content itself.
Where should the JSON-LD script go on the page?
Either the head or the body works, and Google reads blocks injected by JavaScript too, provided the page renders far enough for the crawler to see them. Server-rendered markup in the head is the safest default: it survives a partial render, it does not depend on a client script, and you can check it in view-source. If a page carries several blocks that is legal, since search engines merge them, although a single graph whose nodes reference each other by identifier is easier to keep consistent.
Which schema types are actually worth adding?
Start with the types that match the page and have a documented rich result behind them: Article or BlogPosting with an author and dates, BreadcrumbList, Product with an offer and a GTIN or MPN, LocalBusiness, Event, Recipe. Organization and WebSite belong on every page as the trust anchors the other nodes point at. FAQPage rarely produces a visible enhancement since Google restricted it in 2023, but it still states the page's questions cleanly for anything else reading them. Skip anything the page does not support.
How do I test my JSON-LD?
Three checks, in order. Paste the URL into Google's Rich Results Test to see which enhancements it qualifies for and what is missing. Run the Schema Markup Validator as well, because it checks Schema.org syntax rather than eligibility and the two tools answer different questions. Then watch the enhancement reports in Search Console over the following weeks, since those reflect what Google parsed on the live page rather than on a single test fetch. The free AEO checker on this site also flags a page missing an Article or FAQ schema block.
See what search engines and AI assistants find on your site
Free, no account. Type your address and we show you what is missing and what we would write first.