How to Add Schema to HTML in All Three Formats (With Templates)
HTML schema in practice: where JSON-LD, microdata, and RDFa live in your markup, copy-paste templates for priority types, and how to validate each one.
On this page
There are exactly three ways to put schema.org markup in HTML: a JSON-LD script block, microdata attributes on your existing tags, or RDFa attributes on your existing tags. Same vocabulary, three syntaxes, very different maintenance costs. Google supports all three and recommends JSON-LD; Schema.org still opens its getting-started guide with microdata, which is why half the tutorials you find contradict the other half.
This is the implementation guide. If you want the conceptual grounding first, read what schema markup is and come back. Everything below is code, placement, and validation.
The three formats, side by side
Start with the same fact expressed three ways. An organization named EGGKNITE with a URL.
JSON-LD, a script block anywhere in the document:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "EGGKNITE",
"url": "https://www.eggknite.com"
}
</script>
Microdata, attributes woven into visible markup:
<div itemscope itemtype="https://schema.org/Organization">
<span itemprop="name">EGGKNITE</span>
<a itemprop="url" href="https://www.eggknite.com">Home</a>
</div>
RDFa, the same idea with W3C attribute names:
<div vocab="https://schema.org/" typeof="Organization">
<span property="name">EGGKNITE</span>
<a property="url" href="https://www.eggknite.com">Home</a>
</div>
The vocabulary is shared. Organization, name, and url come from the schema.org type hierarchy, which Schema.org organizes as roughly 800 types, each with a property set, arranged under a root Thing. Learn the hierarchy once and it transfers across formats.
The practical difference is coupling. JSON-LD is a self-contained data island; you can generate it server-side, inject it through a tag manager, or template it from your CMS fields without touching layout markup. Microdata and RDFa are stitched into the DOM. Refactor a template, drop a <span>, and your markup silently loses a required property. Nobody notices until rich results disappear.
Validate: paste each snippet into validator.schema.org as a code fragment. All three should return one detected Organization item with two properties. If the microdata version returns zero items, you dropped itemscope; it is the attribute everyone forgets.
Where each format lives in the document
JSON-LD placement rules are loose. Head or body, one block or several, before or after content. Convention: put it in the <head>, one <script> per entity, or a single block using @graph to relate multiple entities:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "Organization", "@id": "https://www.eggknite.com/#org", "name": "EGGKNITE" },
{ "@type": "WebSite", "@id": "https://www.eggknite.com/#site", "publisher": { "@id": "https://www.eggknite.com/#org" } }
]
}
</script>
The @id references are the underrated part. They let entities point at each other across blocks and even across pages, which is how you build a coherent entity graph instead of disconnected fragments. AI search systems reward that coherence; it is a core piece of the work we cover in our AI search playbook.
Microdata and RDFa live wherever the content lives. There is no separate block; the annotated HTML is the markup. That means one hard constraint: you can only mark up facts that appear in the DOM. JSON-LD lets you assert things the visible page never renders (within Google's content-parity guidelines), which matters for properties like sameAs social profile arrays or geo coordinates.
Validate: run the deployed page URL through the Rich Results Test rather than a pasted fragment. Fragment tests miss placement errors like a JSON-LD block accidentally rendered inside a commented-out region or after a malformed tag that terminates parsing.
Copy-paste JSON-LD templates for priority types
These five types cover most rich-result opportunities for a commercial site. Semrush frames schema as code that helps both search engines and AI systems interpret content, and these are the types those systems consume most. For sequencing logic (which type to ship first for your business model), see our priority-order implementation guide; this section is the raw code.
Article (blog posts, news):
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to Add Schema to HTML in All Three Formats",
"datePublished": "2026-07-31",
"dateModified": "2026-07-31",
"author": { "@type": "Person", "name": "Jane Author", "url": "https://example.com/authors/jane" },
"publisher": { "@type": "Organization", "name": "EGGKNITE", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" } },
"image": "https://example.com/hero.jpg"
}
</script>
Product with offer (the highest-leverage type for ecommerce):
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Trail Running Shoe X2",
"image": ["https://example.com/x2.jpg"],
"sku": "X2-441",
"brand": { "@type": "Brand", "name": "Example" },
"offers": {
"@type": "Offer",
"price": "129.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock",
"url": "https://example.com/x2"
},
"aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "212" }
}
</script>
Only include aggregateRating if the reviews exist on the page. Fabricated ratings are the fastest route to a manual action.
FAQPage (questions and answers must match visible content):
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "Do you ship internationally?",
"acceptedAnswer": { "@type": "Answer", "text": "Yes, to 40 countries with tracked delivery." }
}]
}
</script>
BreadcrumbList (cheap to implement, improves how your URLs render in results):
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://example.com/blog" },
{ "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://example.com/blog/guides" }
]
}
</script>
LocalBusiness (physical locations; use the most specific subtype that fits):
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Example Coffee",
"address": { "@type": "PostalAddress", "streetAddress": "1 Main St", "addressLocality": "Austin", "addressRegion": "TX", "postalCode": "78701", "addressCountry": "US" },
"telephone": "+1-512-555-0100",
"openingHours": "Mo-Fr 07:00-18:00"
}
</script>
Swap the placeholder values, or skip the manual editing entirely: our schema generator produces these templates from a form.
Validate: run each template through the Rich Results Test before templating it into your CMS. Fixing a missing required property in one static block takes thirty seconds; fixing it after it has propagated across 4,000 product pages takes a deploy.
When microdata or RDFa is still the right call
Three scenarios, honestly.
First, you inherit it. Legacy Shopify themes, older WordPress themes, and many enterprise CMS templates ship microdata baked into markup. Ripping it out risks regressions; the pragmatic move is to leave it, verify it validates, and add net-new entities in JSON-LD.
Second, strict content parity requirements. Because microdata annotates visible elements, the marked-up data cannot drift from what users see. Some compliance-heavy teams prefer that guarantee by construction.
Third, RDFa specifically: you are already publishing RDF or working in ecosystems (government, academic, library metadata) where W3C semantic web standards are the house style. RDFa interoperates with those toolchains; microdata and JSON-LD do so less directly.
Outside those cases, JSON-LD wins on every axis that matters: injectability, testability, template decoupling, and alignment with where Google publishes all new feature documentation.
Validate: if you run mixed formats, check Search Console's structured data reports for duplicate entity warnings. Two Product entities on one page with mismatched prices is the classic mixed-format failure mode.
The two-validator workflow
One validator is never enough, because the two main tools answer different questions.
Step 1: syntax and vocabulary. The official validator at validator.schema.org checks whether your markup parses and whether every type and property exists in the schema.org vocabulary. It will catch "@type": "Prodcut" typos and unknown properties. It will stay silent on whether Google will show a rich result.
Step 2: Google eligibility. The Rich Results Test checks the subset of schema.org that Google actually uses, including required and recommended properties per feature. Markup can pass step 1 and fail step 2; a Product without offers, review, or aggregateRating is valid schema.org but ineligible for product rich results.
Step 3: production monitoring. Search Console's enhancement reports surface errors at scale after deployment, which is where template-level bugs show up. Pair that with a periodic crawl; our SEO checker flags pages missing expected structured data.
One habit worth stealing from data engineering: treat structured data as a contract, and test it in CI. A ten-line script that extracts JSON-LD blocks from rendered templates and asserts required properties catches regressions before Googlebot does.
Validate: after any template deploy touching structured data, spot-check three live URLs per template in the Rich Results Test within 24 hours. Silent breakage is the norm, and rich results decay weeks before anyone connects the CTR drop to a markup bug.
Schema is now an AI legibility layer
The consumers of your HTML schema are no longer just Google's rich result renderers. AI answer engines parse structured data to resolve entities, and pages with clean entity graphs get quoted and attributed more reliably than pages that make the model guess. The same markup also feeds the ad surfaces emerging inside AI results, which we broke down in our look at ads in AI Overviews. That shifts schema from a nice-to-have SEO chore to the cheapest machine-readability investment on your roadmap, and it is why we treat markup audits as step one in AI search optimization engagements. The formats above are the mechanics. The compounding value comes from doing them consistently, page after page, with validation wired into your release process.