Lesson 1 of 14

JSON-LD Structured Data

Q: Walk me through why JSON-LD became the standard way to add structured data, and what it does and doesn't guarantee once it's on a page.

A strong answer covers: Explains JSON-LD as a self-contained script block decoupled from the visible DOM, contrasted with microdata/RDFa's inline attributes; States that valid structured data grants eligibility for a rich result, not a guarantee of one; Cites a concrete example of eligibility being narrowed or revoked over time (e.g. FAQ rich results deprecated from Search, HowTo rich results restricted then removed); Mentions that content-level policy (e.g. self-serving review exclusion for Organization/LocalBusiness) sits on top of markup validity.

A <script type="application/ld+json"> block is how a page tells search engines exactly what it contains, in a machine-readable vocabulary, without touching a single visible element. It's also the difference between a plain blue link and a rich result — when the schema is correct, and when it's still eligible at all.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on JSON-LD Structured Data

What interviewers actually ask about this, and what a strong answer has to cover.

Walk me through why JSON-LD became the standard way to add structured data, and what it does and doesn't guarantee once it's on a page.

A strong answer covers

Explains JSON-LD as a self-contained script block decoupled from the visible DOM, contrasted with microdata/RDFa's inline attributes
States that valid structured data grants eligibility for a rich result, not a guarantee of one
Cites a concrete example of eligibility being narrowed or revoked over time (e.g. FAQ rich results deprecated from Search, HowTo rich results restricted then removed)
Mentions that content-level policy (e.g. self-serving review exclusion for Organization/LocalBusiness) sits on top of markup validity

Likely follow-ups

If a client asks you to add FAQPage schema today expecting the old dropdown rich result, what do you tell them?
How would you verify, for a schema type you haven't used before, whether it currently produces a visible rich result at all?

Practice these with the AI interviewer →

The plain-language idea

Search engines can read your rendered HTML and guess what a page is about, but a guess is lossy: is that block of text a price, a rating, a publish date, or just a number? Structured data removes the guessing by explicitly labeling entities and their properties using the shared Schema.org vocabulary — Product, Article, Organization, FAQPage, Review, and hundreds more types, each with defined properties (Product has price, Article has datePublished, and so on).

There have always been three ways to attach this vocabulary to a page: microdata and RDFa embed it inline, as extra attributes (itemscope, itemprop, vocab, typeof) scattered across the actual visible markup — which means your content structure and your SEO structure are welded together, and changing one risks breaking the other. JSON-LD does the opposite: it's a single self-contained <script type="application/ld+json"> block, usually dropped in <head>, that describes the page's entities as plain JSON, completely decoupled from the visible DOM. Google has stated a clear preference for JSON-LD specifically because of that decoupling — a designer can rewrite the entire page's markup and the structured data keeps working untouched, which is why it won over the older inline approaches as the default modern method.

Getting the schema right is also not automatically a visible payoff. Google treats structured data as eligibility, not a guarantee — valid markup can still fail to produce a rich result if the underlying policy around that result type doesn't allow it for your page.

See it in a real thing: an Article with an Organization publisher

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How Structured Data Actually Gets Parsed",
  "image": ["https://example.com/og/article-hero-1200x630.jpg"],
  "datePublished": "2026-09-01T08:00:00+00:00",
  "dateModified": "2026-09-10T14:30:00+00:00",
  "author": {
    "@type": "Person",
    "name": "Adesh Shukla",
    "url": "https://example.com/authors/adesh-shukla"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Praxis",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo-112x112.png"
    }
  }
}
</script>

Every property here maps to something a crawler can act on directly: datePublished/dateModified can surface a freshness signal, author and publisher establish who's accountable for the content (part of Google's E-E-A-T signals), and image gives a candidate thumbnail — all without a single one of these values needing to exist as visible text laid out in a particular DOM position.

Watch out

Valid JSON-LD is necessary, not sufficient, for a rich result. Google layers content and site-level policy on top of the schema: Review/AggregateRating markup for your own Organization or LocalBusiness is explicitly excluded from review rich results when it's "self-serving" — a business marking up reviews about itself, including via an embedded third-party widget like a Google Business or Facebook reviews widget — because Google wants reviews sourced independently of the entity being reviewed.
Rich-result eligibility for a schema type can be revoked or narrowed after you've already shipped it. FAQ and HowTo rich results are the concrete 2023–2026 case: both existed, both got real developer adoption, and both were pulled back (FAQ fully deprecated from Search as of May 2026, HowTo cut down before being removed) — treat "this schema type currently produces a visible result" as a fact to re-verify periodically, not a permanent guarantee.
@id matters once a page describes more than one entity. Without explicit @id values linking related nodes (e.g. an Article's publisher pointing at the same Organization node used elsewhere on the site), search engines can't reliably tell that two mentions refer to the same real-world thing.
A single invalid property can silently drop the whole block, not just that property — parsers commonly ignore an entire JSON-LD script if the JSON itself doesn't parse (a trailing comma, an unescaped quote inside a string) rather than gracefully skipping the bad field. Always validate with Google's Rich Results Test, not just a generic JSON linter.
Multiple <script type="application/ld+json"> blocks on one page are legal — you don't need to cram Article, Organization, and BreadcrumbList into one giant object; separate scripts for separate concerns are normal and easier to maintain.

Why this matters in interviews

"Why does JSON-LD get used over microdata now?" is a real screening question, and "it decouples structured data from the visible DOM so redesigns don't break it" is the answer that shows you understand why, not just which tag to paste. The sharper follow-up — "does adding correct Product or FAQ schema guarantee a rich result?" — is where most candidates who've only copy-pasted a schema generator fall down; knowing that eligibility is a separate, Google-controlled policy layer on top of valid markup (and that it changes — FAQ rich results existing, then not, is recent enough to cite by name) signals you've actually watched this space rather than memorized a checklist from a few years ago.