What Is JSON-LD Structured Data? A Plain-English Guide
JSON-LD is a way of writing facts about a web page in a format machines can read without guessing. It stands for JavaScript Object Notation for Linked Data, and in practice it is a small block of structured text that sits inside a page and states plainly what the page is about: this is an article, this is its headline, this organisation published it, this was the date. Google supports three formats for structured data: JSON-LD, Microdata and RDFa, and recommends JSON-LD as the easiest to implement and maintain at scale and the least prone to user error [3]. The vocabulary it expresses comes from schema.org, a shared dictionary of types like Article, Organization and FAQPage [29]. Those two things are constantly confused, and separating them is the single most useful thing this guide can do for you.
The one distinction that clears up everything else
Schema.org is the vocabulary. JSON-LD is the syntax.
Think of schema.org as a dictionary and JSON-LD as handwriting. The dictionary defines what words exist and what they mean: Article, Person, Product, Question. The handwriting is how you get those words onto the page. You could write the same words in a different hand - Microdata or RDFa - and mean exactly the same thing [3].
This matters because most confusion in the field is a category error. "Should I use JSON-LD or schema?" is not a real question; it is like asking whether to use English or a pen. "Should I use JSON-LD or Microdata?" is a real question, and the answer is almost always JSON-LD.
Here is why. Microdata and RDFa are woven into your visible HTML as extra attributes on tags you already have. Your headline becomes <h1 itemprop="headline">, your author becomes a nested <span itemprop="author">, and so on. Every one of those attributes is a dependency between your content structure and your markup. Redesign the template, and the markup silently breaks.
JSON-LD is different. It sits in one self-contained block, separate from the visible HTML, and describes the page from the outside. You can generate it, test it, version it and replace it without touching your layout. That is the practical reason Google recommends it [3], and it is why nearly every modern CMS emits it.
What a JSON-LD block actually looks like
Here is a minimal, valid block describing an article:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "What Is JSON-LD Structured Data? A Plain-English Guide",
"datePublished": "2026-08-31",
"author": {
"@type": "Organization",
"name": "LaunchHappy",
"url": "https://launchhappy.co"
}
}
Three pieces do the work.
@context points at the dictionary. https://schema.org tells any reader that the words which follow should be interpreted using the schema.org vocabulary rather than some other one. This is the "linked data" part of the name, your block is linked to a shared, published definition of what its terms mean.
@type declares what kind of thing you are describing. Article, Organization, Product, Recipe, Event. The type determines which properties are meaningful.
Everything else is properties. headline, datePublished, author. Properties can hold plain values, or they can hold other typed objects. Notice that author above is not a string but a nested Organization. That nesting is how linked data expresses relationships rather than just labels.
The whole block is wrapped in a script tag with type="application/ld+json" and placed in the page. It can go in the head or the body; both work.
Two things about this are worth noticing, because they explain why the format won.
First, it is inert. The block is data, not behaviour. It cannot break your page, slow a render, or interfere with your styling. A malformed block is ignored by readers that cannot parse it, which is a far gentler failure mode than a broken itemprop attribute cascading through a template.
Second, it is self-describing. Because @context points at a published vocabulary, a reader that has never seen your site before can resolve what headline means without any prior agreement with you. That is the whole idea behind linked data: instead of every site inventing private conventions, everyone points at the same dictionary. It is the reason a block written for Google is equally legible to Bing, to an independent crawler, or to a tool nobody has built yet.
Where JSON-LD goes, and why placement can matter
Physically, the block goes anywhere in the HTML document. Practically, one decision matters: whether it arrives in the served HTML or is generated in the browser.
Google processes JavaScript in three separate phases: crawling, rendering and indexing. Rendering is deferred until resources are available [27]. So client-generated JSON-LD does eventually get seen by Google, just later.
Other machine readers are a different matter. Many retrieval crawlers execute far less JavaScript than Googlebot does, or none at all. If your structured data only materialises after hydration, a meaningful share of readers will never see it.
The test is simple and takes thirty seconds: fetch your own page with JavaScript disabled and read what comes back. Whatever is missing is content you are trusting a renderer to supply. Put anything that matters — headings, answer text, your Organization block — in the initial HTML response.
This is worth taking seriously on hosted platforms in particular. Site builders frequently assemble page content client-side, which means the HTML a crawler receives can be dramatically thinner than what a human sees. The markup is only one casualty of that; your actual prose may be too. If a fetch without JavaScript returns a near-empty shell, structured data is the least of the problem and the render path is the thing to fix first.
The rules that actually get enforced
Google's structured data guidelines are short and the enforcement is real. Three rules cause almost all problems [4]:
Mark up only content that is visible on the page. If the JSON-LD describes a performer, the HTML body must describe that same performer. Describing content the reader cannot see is a violation.
Don't mark up misleading or irrelevant content. Fake reviews, invented ratings, properties unrelated to the page's actual focus.
Don't use structured data to deceive. Don't impersonate a person or organisation, or misrepresent ownership, affiliation or purpose.
Google also asks for information that is current, noting it will not show a rich result for time-sensitive content that is no longer relevant, and for original content generated by you or your users [4]. Both are easy to fail passively: an event block left in place after the event, a price that moved six months ago, a copied product description carrying a competitor's specifications.
Google adds a fourth expectation in the AI context that is easy to miss: make sure your structured data matches the visible text on the page [2]. This is the same rule stated again, which suggests it is the one most often broken.
There is a practical consequence worth naming. Plugins that auto-generate markup frequently emit properties your page does not actually support — an aggregateRating on a page with no reviews, an author on a page with no byline. That is not a neutral extra; it is a description of something that does not exist. Audit what your plugin emits rather than assuming it is correct.
Does JSON-LD help you rank?
This is where honest guidance and vendor guidance part company.
Structured data does not directly improve ranking. What it historically did was make a page eligible for rich results — the star ratings, recipe cards, FAQ dropdowns and event listings that occupy more space in a search results page. Google's own framing is that structured data helps it understand the content of the page, and gather information about the people, books, companies and other entities described in the markup [3].
That eligibility is genuinely valuable when the rich result exists. The catch is that rich results are features, and features get withdrawn.
The clearest recent example is FAQ. Google restricted FAQ rich results to well-known authoritative government and health sites in August 2023 [5], then on 7 May 2026 stopped showing them in Google Search entirely, dropping the Search Console report and Rich Results Test support in June 2026 and API support in August 2026 [1]. Sites that had built a business case around the FAQ dropdown watched it disappear with no blog post and no explanation [24].
The lesson is not "structured data is worthless." It is that any single rich result is a rented asset. Build on the vocabulary, not on one feature. We cover exactly what survived that change, and how to implement what remains, in How to Add FAQ Schema to a Website (Step by Step).
Figure 1: Why you build on the vocabulary, not one feature
Does JSON-LD help with AI search?
Here is the part most guides skip, and it is the part a reader deciding where to spend money most needs.
Google has stated a position, and it is explicit. Its AI features documentation says there are no additional requirements to appear in AI Overviews or AI Mode and no other special optimizations necessary, and states directly that there is no special schema.org structured data you need to add. It goes further and says you do not need to create new machine-readable files, AI text files, or markup at all [2]. The only structured-data guidance it offers in that context is the consistency rule: make sure markup matches the visible text [2].
Other engines have not published a comparable statement. OpenAI, Anthropic and Perplexity have not said their retrieval systems use third-party structured data as a citation signal. That silence is not evidence either way. It is an open question, and it should be described as one rather than filled in with optimism.
The best-evidenced independent analysis is not encouraging for markup. In May 2026, Cyrus Shepard of Zyppy published a meta-analysis synthesising 54 experiments, patents and case studies into 23 scored AI-citation factors, weighting each by strength of evidence rather than opinion [10]. The top factors were search rank at 9.4, query fan-out rank at 9.3, preview control at 9.2, and topic-cluster ranking at 8.9 [10]. In the same analysis, llms.txt — the other machine-readable file the industry has been recommending — scored 2.0 out of 10, with the assessment that there is no credible evidence it influences AI citations [10].
And there is a measured null worth reporting. In first-party research by the LaunchHappy GEO Certified program, 49 pages that had genuinely earned citations in AI answers were fully parameterised across every countable dimension. JSON-LD schema was present on zero of the 49 [31]. Those pages were earning citations with no structured data at all.
So the honest position is this. JSON-LD is cheap, valid, stable and harmless. It helps machines parse your claims and it keeps you honest about what your page says. What nobody has yet demonstrated is that it causes an AI citation. Anyone selling markup as an AI-visibility lever is ahead of the published evidence, and you are entitled to ask them what that evidence is. The platform-specific version of this question is examined in Does Schema Markup Help With ChatGPT Visibility?, and the priority order across types is set out in Which Schema Types Matter Most for AI Search?.
What the evidence says actually earns citations
If markup is not the lever, something is. The published research points consistently in one direction: shape and position, not metadata.
The founding academic work is the Princeton-led GEO paper presented at KDD 2024, which introduced GEO-bench — roughly 10,000 queries across nine datasets — and tested nine content modifications. Its headline is that GEO methods can boost visibility in generative engine responses by up to 40% [6]. The important qualifier, routinely dropped when the figure is quoted, is that 40% is a maximum, not an average: the three strongest methods produced 30–40% relative improvement on the Position-Adjusted Word Count metric and 15–30% on Subjective Impression [6]. Those three methods were adding statistics, adding quotations from credible sources, and citing sources [6]. Keyword stuffing performed worse than baseline [6].
Figure 2: What actually moved visibility in the GEO study
That result deserves a counterweight, and there is a good one. C-SEO Bench, the first systematic benchmark of conversational-SEO tactics, found that most such tactics do not help and several actively hurt, while plain source relevance keeps working [7]. Read together, the two say something coherent: substantive improvements to a page — real statistics, real citations, clearer writing — help, and tricks do not.
Position is the other consistent finding. Zyppy and Authoritas found that 44.2% of all LLM citations are extracted from the first 30% of a document [11]. That is a structural instruction, not a stylistic one: answer the question in the opening block or risk never being reached.
Figure 3: Answer in the opening block or be skipped
The LaunchHappy program's own Panel B measurement points the same way. Across 25 frozen questions on four AI platforms with three runs each — 300 measured answers — 2,026 cited references were logged. 86.3% pointed to pages whose title or slug restated the query, and 32.5% were passage-level deep links using the #:~:text= fragment syntax, meaning the assistant was quoting one specific block rather than citing the page as a whole [32].
Figure 4: Shape and position beat metadata
Put plainly: mirror the question in the title, answer it immediately, cite your sources, and write in blocks that survive being lifted out of context. That is what the evidence supports. The full mechanism is unpacked in Why Does AI Cite Some Websites and Not Others?.
How to validate JSON-LD
Validation happens in two stages, and people routinely stop after the first.
Stage one: is the syntax valid? Any JSON-LD validator or the Schema.org validator will parse the block and report malformed structure, unknown types and misplaced properties. Google's Rich Results Test checks eligibility for specific features — though note it no longer covers FAQ, which was removed in June 2026 [1].
Stage two: can the page actually be fetched? This is the step that gets skipped. Google's guidance is to deploy the page and use the URL Inspection tool to check how Google actually sees it, confirming the page is not blocked by robots.txt, a noindex tag, or a login requirement [1]. Perfect markup on an unreachable page is worth nothing.
Allow time. Google notes it may take several days after publishing for a page to be found and crawled [1].
A minimal, defensible starting setup
If you want the version that is cheap, honest and unlikely to age badly:
Organization on your home page or site-wide. Name, canonical URL, logo, description, and sameAs links to your verified profiles [30]. This is the entity-clarity layer — the block that tells a machine unambiguously who is speaking. In program research, the single most-cited page across an entire measured model was an entity-definition page, a plain-language statement of what the brand is and who it belongs to, earning 30 citations on its own [31].
Article on every article. Headline, description, datePublished, author, publisher.
FAQPage on genuine FAQ sections only. Valid, harmless, no longer a rich result [1][29].
Nothing you cannot substantiate on the page. No ratings without reviews, no authors without bylines.
That is perhaps an hour of work for a small site and it will not need revisiting when the next rich result is retired.
What deliberately is not on that list is anything speculative. There is a standing temptation to add every type a plugin offers on the theory that more markup is more signal. The guidelines point the other way: markup must accurately represent the page [4], and properties describing things your page does not contain are violations rather than bonuses. A small, true block beats a large, aspirational one.
The same reasoning applies to the newer machine-readable files. llms.txt — a proposed markdown file at a site's root, introduced by Jeremy Howard of Answer.AI in September 2024 to give language models a curated map of a site [20] — is often recommended alongside schema as an AI-visibility measure. The adoption picture does not support that framing: reporting through 2025 and 2026 indicates no major AI provider has committed to consuming third-party llms.txt files, server-log evidence shows AI crawlers largely do not request them, and roughly 39.6% of the files that do exist are plugin-generated stubs [22][23]. Zyppy's scored analysis put it at 2.0 out of 10 on evidence strength [10]. It is a reasonable documentation exercise and a poor visibility strategy.
Figure 5: llms.txt: low adoption, no measured effect
A short history, and why it explains the present
Structured data on the open web is older than most of the advice about it. Google launched a Structured Data Testing Tool in January 2015 and expanded support for JSON-LD syntax at the same time, alongside new documentation and policy guidelines for features powered by structured data [3]. The pitch then was the pitch now: label your content so machines do not have to infer it.
What has changed is the consumer. For a decade the only consumer that mattered commercially was a search engine deciding whether to draw a card in a results page. That made structured data feel like a lottery ticket — implement the type, hope the feature fires. It also made the whole discipline hostage to product decisions at one company, which is exactly what the FAQ deprecation demonstrated [1][24].
The current moment is genuinely different, and it is different in a way that cuts against the marketing. There are now many machine consumers rather than one — retrieval crawlers, assistants, agents, aggregators — but the dominant one has explicitly said markup is not required for its AI features [2], and the best-evidenced independent analysis scores markup below ranking, fan-out and preview controls [10]. So structured data has simultaneously become more widely readable and less obviously decisive.
The reasonable conclusion is neither of the two loud ones. Structured data is not dead and it is not the key to AI visibility. It is infrastructure: cheap, stable, mildly useful, and worth maintaining correctly for the same reason you maintain accurate page titles. Treat it as hygiene rather than as strategy and you will not be disappointed by it.
Frequently asked questions
What does JSON-LD stand for? JavaScript Object Notation for Linked Data. It is a way of writing structured facts about a page in JSON, linked to a shared vocabulary via the @context field.
Is JSON-LD the same as schema markup? No. Schema.org is the vocabulary — the list of types and properties. JSON-LD is one of three syntaxes for expressing that vocabulary, alongside Microdata and RDFa [3].
Where should JSON-LD go on a page? Inside a script tag with type="application/ld+json", in either the head or the body. What matters more is that it appears in the served HTML rather than being generated in the browser, because rendering is a deferred phase [27] and many non-Google crawlers execute little JavaScript.
Does JSON-LD improve rankings? Not directly. It makes pages eligible for rich results and helps search engines understand page content [3]. Ranking is determined by other signals.
Does JSON-LD help with ChatGPT or AI Overviews? Google states no special schema.org structured data is needed for its AI features [2]. Other providers have published no guidance. Program research found zero of 49 measured cited pages carried JSON-LD [31]. There is currently no strong published evidence that markup causes AI citations.
Can I have more than one JSON-LD block on a page? Yes. Multiple blocks are normal — for example an Article block and an Organization block. There must only be one FAQPage definition per page [1].
Will invalid JSON-LD hurt my site? Invalid markup is generally ignored rather than penalised, and Google has said unused structured data does not cause problems for Search [5]. Markup that misrepresents the page is a different matter and does violate the guidelines [4].
How often should I update it? Whenever the page changes materially. ConvertMate's AI Visibility Study of 80 million citations across more than 10,000 domains reported that content updated within the last 90 days received roughly a 3.2x citation multiplier [18] — a reason to keep the page fresh, with the markup kept in step.
Written by the LaunchHappy GEO team. LaunchHappy measures AI visibility against a frozen question set and reports what changed. See the GEO Report.
References
[1] Google Search Central, FAQ (FAQPage, Question, Answer) structured data, updated 8 May 2026 — https://developers.google.com/search/docs/appearance/structured-data/faqpage [2] Google Search Central, AI features and your website, updated 10 December 2025 — https://developers.google.com/search/docs/appearance/ai-features [3] Google Search Central, Intro to how structured data markup works — https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data [4] Google Search Central, General structured data guidelines, updated 10 July 2026 — https://developers.google.com/search/docs/appearance/structured-data/sd-policies [5] Google Search Central Blog, Changes to HowTo and FAQ rich results, 8 August 2023 — https://developers.google.com/search/blog/2023/08/howto-faq-changes [6] Aggarwal, Murahari, Rajpurohit, Kalyan, Narasimhan & Deshpande, GEO: Generative Engine Optimization, KDD '24, 24 August 2024 — https://dl.acm.org/doi/10.1145/3637528.3671900 [7] Puerto et al., C-SEO Bench, 2025 — https://arxiv.org/pdf/2606.20065 [10] Cyrus Shepard / Zyppy, AI Citation Ranking Factors, 7 May 2026, as reported by PPC Land — https://ppc.land/23-factors-that-actually-get-your-content-cited-by-ai-search-engines/ [11] Zyppy / Authoritas (2025), positional bias in LLM citations, as reported by AI Thinker Lab — https://aithinkerlab.com/generative-engine-optimization-2026/ [18] ConvertMate, AI Visibility Study (80 million citations, 10,000+ domains), as reported by SLT Creative — https://www.sltcreative.com/ai-seo-statistics [20] Jeremy Howard / Answer.AI, llms.txt proposal, 3 September 2024 — https://llmstxt.org [22] PPC Land, llms.txt adoption stalls as major AI platforms ignore proposed standard, 2 July 2025 — https://ppc.land/llms-txt-adoption-stalls-as-major-ai-platforms-ignore-proposed-standard/ [23] Digital Strategy Force, llms.txt adoption analysis, April 2026 — https://digitalstrategyforce.com/journal/does-your-site-need-llms-txt-to-get-cited-by-ai-search-in-2026/ [24] Matt G. Southern, Google Drops FAQ Rich Results From Search, Search Engine Journal, 10 May 2026 — https://www.searchenginejournal.com/google-drops-faq-rich-results-from-search/574429/ [27] Google Search Central, Understand the JavaScript SEO basics — https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics [29] Schema.org, FAQPage — https://schema.org/FAQPage [30] Google Search Central, Organization structured data — https://developers.google.com/search/docs/appearance/structured-data/organization [31] LaunchHappy GEO Certified program research, citation-models.md — first-party measured research, 2026 [32] LaunchHappy Panel B measured baseline, 26 July 2026 (300 measured answers, 2,026 cited references) — first-party
