JSON-LD
JSON-LD is the format Google recommends for adding structured data to a page. You write a self-contained block of JavaScript Object Notation that describes your content, drop it into the HTML, and search engines read it without you ever touching your visible markup.
JSON-LD stands for JavaScript Object Notation for Linked Data. The name sounds heavier than the thing actually is. In practice it is a tidy block of code that lives separately from your content and tells the engine what that content means. Because it is decoupled from your visible HTML, you can add it, change it, or remove it without ever risking the layout your users see. That single property, separation from the page, is the reason it became the standard, and once you have worked with it for a week you will understand why nobody who has tried it goes back.
Compare that to the older formats. Microdata and RDFa force you to weave labels into your actual tags, attribute by attribute. One careless edit by a developer who does not know the markup is there, and your structured data quietly breaks with no error message. JSON-LD sits in its own block, usually a script tag, so it survives redesigns, content edits, and template changes far better. When the marketing team rewrites the page copy, your markup does not even notice. That resilience is worth a lot over the life of a site.
So what does a JSON-LD block actually look like under the hood? It is a set of key-value pairs wrapped in curly braces. You declare a context, you declare a type, then you list the properties for that type. A FAQ block lists questions and their answers. An article block lists the headline, the author, and the publish date. You do not need to be a developer to read it once you have seen a few examples, and you do not need to memorize the entire vocabulary because schema.org documents every type and property you might ever want to use, with examples for each one.
Example
An Article block declares "@type": "Article", then names the "headline", the "author" as a nested Person object, the "datePublished", and the "image". Google reads that block and now knows, with certainty, who wrote the piece and when, instead of scraping the byline out of your design and hoping it guessed right. Multiply that certainty across every article on a publication and you have removed a whole category of ambiguity from how Google sees your site.
Where to put it
- Inside a script tag with the type attribute set to application/ld+json.
- Anywhere in the head or the body. Google reads it in either location, though keeping it in the head is cleaner and easier to audit.
- One block per type, or combine related types in a single graph when you want them explicitly linked to each other.
The data in your JSON-LD must match what a human sees on the page, every single time.
lightbulbPRO TIP
Render your JSON-LD server-side or in the initial HTML whenever you can. If it only appears after JavaScript runs, you are betting that Google executes your script before it decides what your page is about. Sometimes it does, sometimes it waits, and you do not want your structured data riding on a gamble.
Decoupled by design
Because the markup lives apart from your content, it is the most maintainable structured data format available. That maintainability is exactly why it is the default I reach for on every build.
targetValidate before you trust it
Paste your JSON-LD into Google's Rich Results Test and the Schema Markup Validator before you ship. A single missing comma or an unclosed brace silently kills the whole block, and the engine will not warn you in plain English, it just quietly ignores you. Test first, deploy second, and check Search Console afterward to confirm Google is reading it the way you intended. My schema markup playbook covers the common errors and how to catch them before they cost you.
RELATED TERMS
Want this handled by someone who has measured search for 20 years?
Work with me