JSON-LD
The format Google recommends for schema markup — a self-contained block of data placed in the page’s code, separate from the visible content. Because it is not tangled into your layout, a redesign cannot silently destroy it.
Short answers, before the detail
What is JSON-LD?
The format Google recommends for schema markup — a self-contained block of data placed in the page’s code, separate from the visible content. Because it is not tangled into your layout, a redesign cannot silently destroy it.
What does JSON-LD look like in practice?
It can also be generated from the same data that renders the page, which means the markup cannot drift out of sync with the hours a visitor actually sees.
Where does JSON-LD fit?
Schema & Structured Data — The machine-readable labels that tell search engines and AI models what a page is actually about.
In practice It can also be generated from the same data that renders the page, which means the markup cannot drift out of sync with the hours a visitor actually sees.
What JSON-LD is
JSON-LD — JavaScript Object Notation for Linked Data — is the format Google recommends for adding schema markup to a page.
Instead of weaving labels through your visible HTML the way microdata does, JSON-LD puts all the structured data in a single self-contained block inside a <script type="application/ld+json"> tag. The visitor never sees it. Machines read it directly.
Why the format choice matters practically
Both formats convey the same information, so the argument is entirely about maintenance:
- Redesigns do not break it. Microdata lives inside your markup, so changing the layout can silently destroy the structured data. A JSON-LD block survives untouched.
- It can be generated. Because it is one contained block, a template can build it from the same data that renders the page — which means the schema cannot drift out of sync with what visitors see.
- It is readable. A non-developer can look at a JSON-LD block and check whether the hours are right. Nobody can do that with attributes scattered through HTML.
- Multiple types coexist cleanly. A page can declare a business, a service, and a breadcrumb trail as separate objects without nesting complications.
What it looks like
A minimal LocalBusiness block:
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Example Marine Service",
"telephone": "+1-252-555-0142",
"address": {
"@type": "PostalAddress",
"streetAddress": "100 Example Road",
"addressLocality": "Morehead City",
"addressRegion": "NC",
"postalCode": "28557"
},
"areaServed": "Carteret County, NC"
}@context says which vocabulary is in use. @type says what kind of thing this is. Everything else is a property of that thing.
Where it goes
Either <head> or <body> works. Google reads both, and it also executes JavaScript, so schema injected client-side is generally picked up — though server-rendered markup is more reliable and avoids depending on rendering to succeed.
One block per logical thing. Do not merge unrelated types into one object to save space.
Glossary-specific note
Schema.org defines two types built precisely for pages like this one: DefinedTerm for an individual entry and DefinedTermSet for the collection it belongs to. DefinedTerm carries name, description, termCode, and inDefinedTermSet, and inherits from Thing > Intangible.
Google does not produce a rich result from either type — there is no glossary-specific search enhancement to earn. They are worth using anyway, because they state unambiguously that a page defines a term, which is exactly the signal a system assembling a definition wants to find.
Common mistakes
- Marking up invisible content. Against Google’s guidelines and a genuine penalty risk.
- Trailing commas or unescaped quotes. JSON is unforgiving; one syntax error voids the whole block silently.
- Hardcoding data that changes. Hours and prices written by hand into schema go stale, and stale structured data is a confident wrong answer.
- Skipping validation. Run the Rich Results Test after every change — a broken block produces no error anywhere a human would see it.
Related terms
Now that you know what it means — should you be paying for it?
Not every term in this glossary is worth money to every business. Tell us what you are being sold and we will tell you straight whether it is worth it for you.