Adding structured data to a page is a small, contained task: choose a type, write a block of labeled facts, drop it into the HTML, confirm it parses, and watch how Google reads it after the page ships. A single page can take twenty minutes, and once the pattern is understood it scales across a template. What trips people up is not the syntax but the sequence, and the handful of decisions made before any code gets written.
Structured data is a standardized way to annotate what a page means. The HTML already speaks to a human reader through headings, paragraphs, and images; structured data adds a labeled layer underneath that a search engine, a voice assistant, or an AI system can read without guessing. A recipe page contains prose about ingredients and steps, and its structured data states, in machine-readable form, that this is a Recipe named Chocolate Cake with a twenty-minute prep time. The vocabulary comes from schema.org, a shared project started by Google, Microsoft, Yahoo, and Yandex in 2011 that now defines thousands of types. It is not a ranking signal: a page does not move up the results for carrying JSON-LD. What it earns is eligibility for richer search appearances, and those tend to lift click-through at the same position.
Step 1: Pick the Schema Type That Matches the Page #
Before writing anything, decide which schema.org type actually fits the page. This determines whether the rest of the work pays off, and it is the decision most often rushed.
The rule from Google’s documentation is specificity: use the most specific applicable type, not the parent. A restaurant page should declare Restaurant, not LocalBusiness or Organization, even though a Restaurant is technically a kind of both. The more specific the type, the more relevant properties become available, and the more precisely a search engine understands the page. Most pages land in a small set of common types: Article, NewsArticle, and BlogPosting for written content; Recipe for cooking instructions; Product for e-commerce listings; LocalBusiness and its sub-types for physical locations; Event for scheduled occurrences; FAQPage for question-and-answer content; BreadcrumbList for navigation hierarchy; Organization and Person for the publisher and its people.
The failure to avoid is forcing a type onto a page that does not fit. Marking a “ten best recipes” listicle as a single Recipe misrepresents it, because it is a list, not one recipe. Schema is a contract about what the page contains, and breaking that contract risks a manual action that suppresses rich results across the affected pages. When no specific type fits, the correct answer is no markup. Not every page needs it.
Step 2: Choose a Format, and Why JSON-LD Wins #
Structured data can be written in three formats, all encoding the same schema.org vocabulary. JSON-LD is a block of JavaScript object notation that sits in a script tag, separate from the visible content; Microdata and RDFa are HTML attributes woven directly into the existing markup.
Google treats all three as equally valid when implemented correctly. The practical difference is maintenance. Microdata and RDFa interleave with the content, so every template change risks breaking the markup, while JSON-LD lives in its own block, untouched by content edits and generated cleanly by a CMS plugin or server template. For that reason Google recommends JSON-LD, and it is the right default for nearly every site.
One older format is worth naming only to rule out. Data-vocabulary.org was a Google-specific vocabulary that predated schema.org; Google stopped honoring it for rich results on April 6, 2020, and any page still relying on it should migrate to schema.org.
Step 3: Write the JSON-LD Block #
With the type and format settled, write the block. Three elements anchor every one: @context is https://schema.org, @type names the schema type, and everything after that is properties, which vary by type. Conceptually, a Recipe block looks like this:
{
"@context": "https://schema.org",
"@type": "Recipe",
"name": "Chocolate Cake",
"recipeIngredient": ["2 cups flour", "1 cup cocoa powder"],
"recipeInstructions": [
{ "@type": "HowToStep", "text": "Combine dry ingredients." }
]
}Each type has its own required properties, and only pages that carry them become eligible for the matching rich result. Recipe requires name, image, recipeIngredient, and recipeInstructions; Product requires details like price and availability. The authoritative list for any type lives on its page in Google’s Search Central documentation, which separates required properties from recommended ones. Recommended properties do not block eligibility, but they enrich the result when Google shows it.
A few formatting rules decide whether the block parses. Use valid JSON: double-quoted property names, correct commas, no trailing commas. Use ISO 8601 for dates and durations, so a twenty-minute prep time is PT20M, not “20 minutes”. Nested items take their own object with a type, as each instruction step above becomes a HowToStep rather than a plain string.
The one non-negotiable rule: the facts in the block must match what a reader sees on the page. Google’s guidelines prohibit marking up content that is not visible, so a block claiming a twenty-minute prep time on a page whose text says “about an hour” gets ignored or penalized. Structured data describes the page as it is; it does not invent a different one.
Step 4: Add the Block, Then Validate Before Publishing #
JSON-LD goes inside a script tag with the type set to application/ld+json. The conventional spot is the document head, but Google confirms the body works equally well. What matters is that the tag appears in the HTML the server returns when Googlebot crawls, not only after client-side JavaScript runs. On a CMS this rarely means hand-editing HTML: plugins on WordPress, Shopify, and similar platforms generate the JSON-LD from the page fields and regenerate it whenever content changes. On JavaScript frameworks like React or Vue, server-side rendering is the reliable path, since client-side injection depends on Google’s rendering queue and introduces more failure modes.
Validate before the page goes live and after any change that could touch the markup. The Rich Results Test is Google’s primary check: paste a URL or HTML block, and it reports whether valid structured data was found, which rich results the page is eligible for, and any errors or warnings. Errors block eligibility; warnings flag missing recommended properties without blocking. The Schema Markup Validator is the secondary check, validating against the full schema.org specification rather than only Google’s supported subset, which matters for consumers beyond Google such as Bing and voice assistants.
One point of confusion is worth clearing up: the older Structured Data Testing Tool no longer exists in its original form. Google retired it and migrated it to schema.org as the Schema Markup Validator. Anyone reaching for that legacy tool by name should use the Rich Results Test for Google eligibility and the Schema Markup Validator for general schema.org conformance instead.
Step 5: Monitor What Google Actually Reads in Search Console #
Publishing is not the end. A validation pass confirms the markup is correct today, not that Google keeps reading it correctly after the next template change. The Enhancements section of Search Console lists each rich result type detected across the site, with counts of valid items, errors, and warnings over time. A sudden drop in valid items usually means a template change broke the markup; a spike in errors after a deployment means new code introduced bad markup. The URL Inspection tool drills into a single page, showing whether it was crawled and what structured data Google saw on the latest crawl, which is the first stop when one page is not showing a rich result. These reports lag reality: after a fix the numbers do not update until Google recrawls, which takes days to weeks, though URL Inspection can request a faster recrawl.
Monitoring matters because eligibility is not entitlement. Correct markup makes a page eligible for a rich result; it does not force display, which content quality, query context, and competition all decide. Formats shift too: Google reduced FAQ rich results sharply in 2023 and retired HowTo rich results the same year, so a result that worked at launch can quietly disappear. Structured data is ongoing infrastructure, not a one-time setup, and rechecking it after template changes and algorithm updates is what keeps it working.
Frequently Asked Questions #
Does adding structured data improve my rankings?
Not directly. Structured data is not a ranking factor. It makes a page eligible for rich results and feeds AI extraction systems labeled facts, and the richer appearance often improves click-through at the same ranking position. The position itself does not move because of the markup.
Where should the JSON-LD script go, head or body?
Either works. The conventional placement is the document head, but Google confirms the body is equally valid. The requirement is that the script tag appears in the HTML the server returns during a crawl, not only after client-side JavaScript executes.
Can I put multiple schema types on one page?
Yes. Use nested objects when one item is a property of another, or separate blocks when the items are independent facts about the same page, such as a Recipe, a BreadcrumbList, and an Organization. Larger sites sometimes express these relationships through a single graph structure, but the underlying rules are the same.
The sequence is what carries this work: match the type to the page, write facts that match what readers see, validate before shipping, and watch Search Console afterward. Skip the first step and the markup is valid but useless; skip the last and a template change can break weeks of work unnoticed. Structured data extends what a page already is, which makes the type-matching decision at the start the one worth slowing down for.