Structured Data & JSON-LD: How to Explain Your Content to Search Engines and AI

April 17, 2026 #JSON-LD#Schema.org#Structured Data#SEO#AEO

Structured data is a machine-readable dataset you embed in your page alongside the visible content — usually as a JSON-LD script block in the <head>. It tells search engines and AI systems explicitly what a piece of content is: Is this a company, a product, an article, an FAQ? Schema.org provides the shared vocabulary, JSON-LD the format. Together, they are the most reliable way today to earn rich results in Google and get cited correctly by answer engines.

TL;DR

JSON-LD is Google’s preferred format for structured data — separate from the HTML, easy to maintain.
The most important types for most websites: Organization, WebSite, Service, Article, FAQPage, BreadcrumbList.
@graph cleanly connects multiple entities via @id references into a knowledge graph instead of isolated snippets.
Markup must reflect the visible content — otherwise you risk a manual penalty instead of a ranking.

Why structured data is no longer a nice-to-have in 2026

For a long time, structured data was seen as a bonus exercise for SEO nerds. A few star ratings in the search results, maybe an FAQ accordion — nice, but expendable. That has changed, and significantly so.

The reason lies in how AI systems process content. ChatGPT, Perplexity, Google AI Overviews, and Gemini don’t read web pages the way a human does. They break content down into entities and relationships — and that’s exactly what structured markup hands them on a plate. If your Organization schema clearly states that Rocket-Monkeys is an agency in Munich, with this URL, this logo, and these services, no model has to guess. It has the facts in black and white.

We see this in practice on every project: pages with consistent, correct schema get cited more reliably and with the right attributes. It’s not a magic ranking boost — Google itself says structured data is not a direct ranking factor. But it’s the gateway to rich results, and it removes the ambiguity that otherwise trips up AI systems. Less ambiguity means you’re more likely to be understood correctly.

JSON-LD vs. Microdata vs. RDFa — which one to use?

There are three syntaxes for marking up Schema.org data. The short version: use JSON-LD.

Format	Where it lives	Maintainability	Google’s recommendation
JSON-LD	Separate `<script>` block	High — separate from the HTML	Yes, explicitly
Microdata	Inline in HTML attributes	Low — mixed into the markup	Supported
RDFa	Inline in HTML attributes	Low	Supported

Microdata and RDFa attach attributes like itemprop directly to the HTML. That sounds practical at first — the data sits right next to the visible element. In reality, it quickly becomes unmaintainable, because any layout change can break your markup. JSON-LD lives in its own block, ideally generated server-side. You can maintain, test, and version it centrally without touching the template. That’s exactly why Google recommends it, and exactly why it’s the only approach we use.

The Schema.org types you actually need

Schema.org has hundreds of types. You’ll never need most of them. For a typical company or agency site, a handful is enough — as long as they’re done right.

Organization (and LocalBusiness)

The foundation. Organization describes who is behind the website. For local providers, LocalBusiness (a subtype) is often the better choice, because it lets you include an address, opening hours, and geo coordinates. It belongs on the site exactly once — ideally on the homepage, or referenced globally via @id.

WebSite

Describes the website as a whole and can include a SearchAction — the prerequisite for the sitelinks search box in Google. Small but effective.

Service

Worth its weight in gold for service providers. Every offering — in our case web development, AI integration, AEO — can be marked up as a Service, linked to the provider (your Organization). That way, machines don’t just understand that you exist, but what you offer.

Article (or BlogPosting)

For every blog post. Provides headline, author, datePublished, image, and publisher. This very article carries a BlogPosting schema. Without it, an answer engine has a harder time recognizing an article as a standalone, dateable piece of content.

FAQPage

Structures question-and-answer pairs. A word of caution: Google has heavily restricted the rich-result display for FAQs and now shows it only for selected authoritative sites. Even so, FAQPage remains useful for AI systems — they extract clean, citable answers from it. One condition: the questions and answers must be visible on the page. Hidden FAQ markup violates the guidelines.

BreadcrumbList

Maps your navigation hierarchy. It’s what gives you those tidy breadcrumb trails in the search results instead of a bare URL — and it helps crawlers grasp your site structure.

@graph: From snippets to a knowledge graph

This is where solid markup parts ways with superficial markup. Many sites scatter three or four isolated JSON-LD blocks across a page — one for the Organization, one for the article, one for the breadcrumbs. It works, but each block lives in isolation. The machine sees no connection between them.

@graph solves that. You put all entities into a single array and link them via @id references. The Organization gets a fixed @id such as https://rocket-monkeys.com/#organization. The article then points to it via publisher: { "@id": "...#organization" } — instead of duplicating the Organization data. The result is a connected graph that mirrors exactly the kind of relationship structure AI systems build internally anyway.

Here’s a complete, realistic example for a blog page with linked entities:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://rocket-monkeys.com/#organization",
      "name": "Rocket-Monkeys",
      "url": "https://rocket-monkeys.com",
      "logo": {
        "@type": "ImageObject",
        "url": "https://rocket-monkeys.com/logo.svg"
      },
      "areaServed": "DE",
      "knowsAbout": ["Web development", "AI integration", "AEO", "SEO"]
    },
    {
      "@type": "WebSite",
      "@id": "https://rocket-monkeys.com/#website",
      "url": "https://rocket-monkeys.com",
      "name": "Rocket-Monkeys",
      "publisher": { "@id": "https://rocket-monkeys.com/#organization" }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://rocket-monkeys.com/blog/json-ld/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Blog",
          "item": "https://rocket-monkeys.com/blog" },
        { "@type": "ListItem", "position": 2, "name": "Structured Data & JSON-LD" }
      ]
    },
    {
      "@type": "BlogPosting",
      "@id": "https://rocket-monkeys.com/blog/json-ld/#article",
      "headline": "Structured Data & JSON-LD",
      "datePublished": "2026-06-11",
      "author": { "@id": "https://rocket-monkeys.com/#organization" },
      "publisher": { "@id": "https://rocket-monkeys.com/#organization" },
      "isPartOf": { "@id": "https://rocket-monkeys.com/#website" },
      "mainEntityOfPage": "https://rocket-monkeys.com/blog/json-ld/"
    }
  ]
}
</script>

Look at the @id references. The Organization is defined once and referenced three times — as the website’s publisher, as the author, and as the article’s publisher. No duplicates, no contradictions. That’s exactly how it should be.

Common mistakes we see again and again

We regularly audit other people’s sites, and the same pitfalls come up surprisingly often.

Markup that doesn’t match the visible content. The classic. Someone marks up an aggregateRating of 4.9 stars, but there isn’t a single visible review on the page. That’s against Google’s guidelines and can trigger a manual action. The rule: markup describes only what’s actually on the page.

Wrong or broken @id references. You reference an entity via @id that doesn’t exist in the graph — a typo, a missing #fragment, a different URL. The reference points to nothing, and the link never takes effect.

Forgetting required fields. Every type has required and recommended properties. An Article without image or datePublished, an Organization without name — gaps like these cost you the rich result or weaken the signal.

Botching date formats. Dates must be ISO 8601: 2026-06-11, not 11.06.2026. Machines are merciless here.

Multiple contradictory Organizations. Plugins and themes often each generate their own Organization schema, and suddenly your site claims to be two different companies. Consolidate onto a single @id.

Nesting instead of referencing. Fine for small sites, but if you copy the same Organization into every article, you end up with fifty slightly diverging versions. @id references are the clean solution.

Testing tools — and why you should always test

Checking structured data by hand is tedious and error-prone. Use the tools. We never let a schema go live that hasn’t passed through at least two of them.

Schema Markup Validator (validator.schema.org) — validates against the official Schema.org vocabulary. Stricter and more neutral than Google’s tool, ideal for pure syntax and type checking.
Google Rich Results Test (search.google.com/test/rich-results) — shows which rich results Google recognizes in your markup and whether they qualify for display. The tool that really matters if you care about how Google presents you.
Google Search Console — the reality check. Under “Enhancements” you can see which structured data Google has actually found on your live site, including errors and warnings across the entire domain. No other tool replaces this view of real, crawled data.

A workflow that has proven itself: first lock down the structure locally with the Schema Markup Validator, then check Google eligibility with the Rich Results Test, and after deployment keep an eye on Search Console. The errors in the Console are often the most interesting ones, because they reveal problems that never show up in isolated testing.

How we set this up

On our projects, we generate JSON-LD server-side from the same data that produces the visible content — a single source of truth. On an Astro or Next.js site, that means one central helper function that builds the @graph from the frontmatter or CMS record. Title, date, author, breadcrumbs — everything comes from the same source as the HTML. That way, the markup simply can’t drift from the visible content, which is the most common mistake of all.

The effort is modest, the effect lasting. Set it up cleanly once, and every new page carries its correct schema automatically — without anyone having to think about it.

If you’d like to know whether your site already explains clearly to search engines and AI systems who you are and what you offer, we’re happy to take a look in a free, no-obligation intro call. We’ll audit your existing markup, show you the specific gaps, and tell you what’s worth fixing. Just drop us a line at info@rocket-monkeys.com — and we’ll figure out how to get your content understood the way you actually mean it.