# JSON-LD schema that matters: the types worth adding and how to link them

> Which schema.org types are worth your time, how to connect them into one @id graph, why markup must match what the page shows, and how to validate it.

Canonical page: https://aispeedforce.com/blog/json-ld-schema-that-matters/

Last updated: 2026-09-23

A short list of schema.org types covers most business sites. Link them into one graph with @id, keep them true to the visible page, and validate before you ship.

[SEO](https://aispeedforce.com/blog/category/seo/) Published 23 September 2026 5 min read By AI SpeedForce

A handful of schema.org types, written as JSON-LD and linked into one graph, covers what most business websites need. Organization and WebSite on the home page, WebPage and BreadcrumbList on every page, and a specific type where the content calls for it: BlogPosting, Product, Service or FAQPage. The rest is keeping it accurate.

Structured data used to be mostly about rich results in search. It now does a second job: it gives AI assistants and agents facts about your business in a form they do not have to guess from layout. A crawler reading your page can see that a name is your organization, that a date is the publish date, and that a list of questions is an FAQ. That is worth getting right.

## The short list of types

You do not need dozens of types. You need the right one in the right place.

| Type | Where it goes | What it states |
|---|---|---|
| Organization | Home page | Who runs the site |
| WebSite | Home page | The site as a whole |
| WebPage | Every page | This page and what it is about |
| BreadcrumbList | Every inner page | Where the page sits |
| BlogPosting | Each article | Headline, dates, author |
| Product, Service, FAQPage | Where the content is | The offer or the questions |

Which type goes where

- **Organization**: your business name, logo, URL and a short description. Put it on the home page. It is the entity every other page is "about".
- **WebSite**: the site itself, with its name and publisher. Also on the home page.
- **WebPage**: on every page, with the page's name, description and URL.
- **BreadcrumbList**: on every inner page, matching the breadcrumb a visitor sees.
- **BlogPosting** or **Article**: for each article, with headline, dates, author and image.
- **Product**: for items you sell, with name, image, price and availability as shown on the page.
- **Service**: for service pages, with a description and provider.
- **FAQPage**: only where the page actually shows questions and answers.

The full vocabulary lives at [schema.org](https://schema.org/). Google's [search gallery](https://developers.google.com/search/docs/appearance/structured-data/search-gallery) lists which types can produce rich results, and it changes, so check it rather than relying on older guides.

## Link everything into one graph with @id

The most common weakness we see is not a missing type. It is disconnected blocks. Each page declares its own Organization with slightly different details, and nothing says they are the same business.

The fix is `@id`. Give each entity a stable identifier, usually your URL plus a fragment, define it fully once, and refer to it everywhere else:

`{"@context": "https://schema.org", "@graph": [ {"@type": "Organization", "@id": "https://example.com/#org", "name": "Example Co", "url": "https://example.com/"}, {"@type": "WebSite", "@id": "https://example.com/#site", "publisher": {"@id": "https://example.com/#org"}}, {"@type": "WebPage", "@id": "https://example.com/pricing/#webpage", "isPartOf": {"@id": "https://example.com/#site"}, "about": {"@id": "https://example.com/#org"}} ]}`

One graph, linked by @id

Now every page points back to one organization and one site. A reader, human or machine, can follow the references instead of reconciling near-duplicates. This site works the same way: the home page defines `#org` and `#site`, and every other page references them.

## Keep it matching the visible page

Structured data is a description of the page, not a second, better version of it. Google's structured data guidelines are explicit that markup should reflect content visible to users. In practice:

- **FAQ answers must match the visible answers.** If you edit a question on the page, edit the JSON-LD in the same change. We generate both from one source so they cannot drift.
- **Prices and availability must match what a shopper sees.** Stale Product data is worse than none.
- **Do not mark up reviews or ratings you do not show,** and do not invent them. The same goes for dates: `dateModified` should change when the content changes, not on every deploy.

This matters more now that AI assistants read the markup. If your JSON-LD says one thing and the page says another, you have told the machine something the human cannot check. Our guide to [FAQ and structured data for answer engines](https://aispeedforce.com/blog/faq-and-structured-data-for-answer-engines/) goes deeper on the question-and-answer case.

## Validate before you ship

Two free tools cover it:

- The [Schema Markup Validator](https://validator.schema.org/) checks that your JSON-LD is valid schema.org, for any type.
- Google's [Rich Results Test](https://search.google.com/test/rich-results) checks whether a page is eligible for the rich results Google supports, and shows errors and warnings.

Run both after any template change. A single stray character can make a whole block unreadable, and nothing on the visible page will tell you.

Before you ship structured data

## Common mistakes

- **Several Organization blocks with different names** across pages. Define it once and reference it.
- **FAQPage on pages without a visible FAQ**, added only for the search appearance.
- **Copying markup from a plugin and never checking it.** Plugins often output types that do not match the page, or duplicate what your theme already emits.
- **Escaping problems**: a quote or a closing script tag inside a value can break the block. Serialize with a proper JSON encoder rather than string concatenation.

## Where it fits with the rest

JSON-LD is one of several signals an agent reads. It sits alongside [llms.txt](https://aispeedforce.com/blog/llms-txt-explained/), which points assistants to your important pages, and [Markdown on request](https://aispeedforce.com/blog/markdown-for-agents-content-negotiation/), which gives them the page text without the layout. Together they make your site easy to read correctly. If you build on a platform, the [platform pages](https://aispeedforce.com/platforms/) describe where the markup usually comes from on each one.

## What you can skip

schema.org has hundreds of types, and it is tempting to mark up everything. Resist it. Markup that describes nothing a visitor can see, or that no search engine or agent uses, adds maintenance without benefit. Start with the short list above, get it correct and connected, and add a new type only when a page genuinely contains that kind of thing: an event with a date and place, a job posting, a recipe. One accurate block is worth more than five speculative ones.

## Next step

Run the free [agent-readiness scan](https://aispeedforce.com/agent-ready/). It reports which JSON-LD types your home page declares and whether each block parses, next to the other files agents look for. If you want the structured data, templates and generation done for you, [our SEO work](https://aispeedforce.com/services/seo/) covers it.

## Questions about this topic

### Is JSON-LD better than Microdata?

Search engines read all common formats, but JSON-LD is the easiest to maintain because it sits in one block instead of being woven through the HTML. Google recommends it where possible.

### Will structured data always get me a rich result?

No. It makes a page eligible. Whether a rich result is shown is up to the search engine, and eligibility rules change over time.

### Should I mark up content that is not on the page?

No. Structured data should describe what a visitor can see. Marking up hidden or different content breaks the guidelines and can remove eligibility for rich results.

## Related posts

- [robots.txt for AI crawlers: GPTBot, ClaudeBot and the rest](https://aispeedforce.com/blog/robots-txt-for-ai-crawlers/): SEO 23 September 2026. AI providers run separate crawlers for training, for search and for fetching a page a user asked about. robots.txt lets you treat each one differently. Here is who is who and how to write the rules.
- [llms.txt explained: what it is and how to write one](https://aispeedforce.com/blog/llms-txt-explained/): SEO 23 September 2026. llms.txt is a short Markdown file at your site root that tells language models what your site is and where the important pages are. It is a proposal, not a standard, and it is cheap to publish.
- [Lighthouse's agentic browsing audit: what it checks and how to pass](https://aispeedforce.com/blog/lighthouse-agentic-browsing-audit/): SEO 23 September 2026. Recent Lighthouse versions add an Agentic Browsing category that checks how well AI agents can read and use a page. Here is what it looks at and how to fix what it finds.
- [All posts](https://aispeedforce.com/blog/)
- [More on SEO](https://aispeedforce.com/blog/category/seo/)
- [Agent-readiness scan](https://aispeedforce.com/agent-ready/)

## See how your own site scores

The free agent-readiness scan checks the files, headers and endpoints this blog writes about, and tells you what to fix first.