Structured data
How the schema builder on the Content page works: blocks at site and category level, the connections between them, the variables they need, and why the Publish preview is the one to trust.
Structured data is built from blocks, not written by hand. You pick which schema.org types a page should carry, connect them to each other, and the system assembles one JSON-LD graph per page from the variables it knows about that page. It lives on the Content page, in two places.
Two levels
Whole site, at the top of the navigator, holds the blocks that apply to every URL: the organisation, the website, whatever is true of every page.
A category's Structured Data section holds the blocks for that category's pages. Category blocks add to the site-wide ones; they do not replace them. Site-wide blocks appear in the category's list greyed out with an Inherited badge, and are edited only from Whole site.
Blocks are set at those two levels, the site and the category.
Building blocks
The Building Blocks list is searchable and filterable by category of block. Blocks marked Recommended are the curated set for most sites; the rest are there when you need them. A block that may occur more than once on a page, such as an FAQ item, has a plus for adding another instance, and a gear for binding each instance to its own variables.

A Main entity says what the page is primarily about, the product or the article, so the WebPage container can point at it. Auto-detect leaves that to the assembler.
Connections
Blocks reference each other: an article has an author, an organisation has a logo. The Connections editor lists, for each block you control at this level, the properties another block could fill, and lets you pick which one.
We write exactly the connections you make and never infer one. Adding a block seeds its usual connections for you, and removing one of those stays removed. The suggestions rank the targets that fit the property first, but any block can be connected to any property; the ranking is a hint, not a rule.
The variables the blocks need
Every block reads variables, {org_name} or {article_published}, and the
Variables bar under the list says how many of the ones the selected blocks
need are available. Missing ones are grouped as Essential, Recommended
and advanced. A field whose variable is missing is left out of the output
rather than emitted empty, so an incomplete block still produces valid JSON-LD,
just a thinner one.
Manage opens the variables drawer without leaving the page. Variables explains how a variable gets a value.
Changes here are saved on their own a couple of seconds after you make them, per level.
Preview and what is served
The preview on the Content tab assembles the graph in your browser from what it currently knows. The preview on the Publish tab asks the server, and that graph is byte-for-byte the one that gets served. When the two differ, the Publish tab is right.
The served graph is fixed at publish time and stored with the page. A page whose site and category have no blocks gets no JSON-LD at all. A BreadcrumbList is added automatically unless the site's settings turn it off, and the page's published title and description ride along as the WebPage's name and description.
Customize on a preview row lets you try per-URL changes to the graph, but those changes are not saved anywhere. They are gone on reload, and they never publish.
When the output looks wrong
- A block is missing from the graph. Its variables were probably missing; check the Variables bar. A block whose every field is empty is pruned.
- A connection you made is not there. Both ends have to exist at the level being assembled. A connection to a block that was later removed is ignored, and comes back if the block does.
- The Content-tab preview and the Publish-tab preview disagree. They use different inputs for images and breadcrumbs. The Publish tab is what is served.
Read next
Keywords and cannibalization