Matt Canty

Sun Aug 23

Schema markup is structured data, usually written in JSON‑LD, that you add to a web page so search engines and AI systems can understand exactly what the content means, not just what it says. It uses a shared vocabulary from Schema to label things like products, recipes, events, and reviews in a format machines can parse instantly.

Here’s the one fact that matters most before anything else: schema makes your page eligible for rich results (star ratings, recipe cards, FAQ dropdowns) in Google Search. It does not guarantee them. Google still weighs page quality, relevance, and dozens of other signals before deciding whether to show that enhanced result.

Three formats can carry schema:

JSON‑LD — a script block separate from your HTML, the format Google Search Central recommends for most modern sites
Microdata — inline HTML attributes woven directly into your existing markup
RDFa — another inline approach, more common in older or highly customised builds

For nearly everyone reading this, JSON‑LD is the answer. It’s easier to write, easier to maintain, and doesn’t force you to touch your page’s visual HTML at all.

What is schema markup made of? Vocabulary, formats, and how crawlers read it
Which schema types actually matter for most websites?
How do you add schema markup to a page? A step-by-step walkthrough
How do you test and validate schema markup?
What can schema markup actually do for SEO, and what can’t it do?
What mistakes should you avoid with schema markup?
CantyDigital’s experience with structured data implementation
Get your schema markup implementation right the first time
Where to go for authoritative schema markup guidance
An editorial take on doing schema properly
Frequently asked questions about schema markup
Sources

What is schema markup made of? Vocabulary, formats, and how crawlers read it

Schema markup has two separate ingredients: a vocabulary that defines what things are called, and a format that determines how you write it into a page. People often confuse the two, which is where a lot of implementation mistakes start.

Hands typing JSON-LD code on laptop keyboard

The vocabulary comes from Schema.org, a collaborative project backed by Google, Microsoft, Yahoo, and Yandex. It defines thousands of “types” (Article, Product, Event, LocalBusiness) and the “properties” that belong to each one (an Article has a headline, an author, a datePublished). Think of Schema.org as the dictionary and grammar rules; the format is just how you physically write the sentence.

That’s where the three formats come in, and they’re not interchangeable in practice:

JSON‑LD sits in a <script type="application/ld+json"> block, usually in the page’s <head>. It’s detached from your visible HTML, so you can add, edit, or remove it without touching your design. Google explicitly recommends it in its structured data documentation, and it’s the format used across almost every current CMS plugin and tutorial.
Microdata embeds itemscope, itemtype, and itemprop attributes directly inside your HTML tags. It works, but it clutters your markup and breaks more easily during redesigns because the schema is physically tangled up with your layout.
RDFa works similarly to Microdata but uses attributes like vocab and typeof, and shows up more often in publishing platforms with legacy templates.

Once the markup is live, a crawler reads your rendered page, finds the structured data block, and cross-checks it against the visible content. If your JSON‑LD says a product costs $49 but the page displays $69, that mismatch is a real problem. Google’s own guidance is blunt about this: structured data has to reflect what a visitor actually sees, or it risks being flagged as misleading.

Pro Tip: If your site is built with a JavaScript framework that renders content client-side, check that your JSON‑LD is present in the page source Google actually crawls, not just what appears after the browser finishes rendering. Server-side rendering or prerendering solves this cleanly.

Which schema types actually matter for most websites?

You don’t need to learn all of Schema.org’s thousands of types. Nine cover almost every real-world use case, and picking the right one for each page type is most of the battle.

Article — for blog posts and news content. Prioritise headline, author, and datePublished; Google uses these to understand freshness and authorship.
WebSite / WebPage — establishes your site’s identity and can enable the sitelinks search box in results.
Organization — defines your business as an entity: name, logo, social profiles, and contact details.
LocalBusiness — an extension of Organization built for physical or service-area businesses, adding address, opening hours, and phone number.
Product — for ecommerce listings, built around name, price, availability, and image.
Review (and the related AggregateRating) — captures star ratings and review counts, often paired with Product or LocalBusiness.
Event — covers startDate, location, and offers for anything ticketed or scheduled.
Recipe — one of the most detailed types in the vocabulary, with fields for prepTime, cookTime, nutrition, and recipeIngredient. Schema.org’s own Recipe reference lists dozens of optional properties, but only a handful are worth the effort for most cooking blogs.
BreadcrumbList — shows the page’s position in your site hierarchy, which often replaces a plain URL with a breadcrumb trail in the search snippet.

A few of these do most of the heavy lifting. If you run a service business, Organization and LocalBusiness will matter more than Recipe ever will. If you publish content regularly, Article and BreadcrumbList are the pair to nail first. Full copy-paste JSON‑LD examples for the two most commonly requested types, Article and Product, are in the next section.

How do you add schema markup to a page? A step-by-step walkthrough

Adding schema isn’t complicated once you’ve done it twice. The process is the same regardless of platform: pick the type, write the JSON‑LD, place it correctly, then validate before you publish.

Identify the page’s primary entity. A blog post is an Article. A product listing is a Product. Don’t mark up a page as multiple competing types unless they genuinely nest (a Product can contain a Review, for instance).
Check Google’s required and recommended properties for that type. Google Search Central lists exactly which fields are mandatory for a given rich result to even be considered, and which are optional but helpful.
Write the JSON‑LD block. Here’s a minimal but functional Article example:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "What Is Schema Markup?",
  "author": {
    "@type": "Organization",
    "name": "CantyDigital"
  },
  "datePublished": "2026-01-14"
}

And a Product example with the fields most commonly checked for rich results:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Ceramic Coffee Mug",
  "image": "https://example.com/mug.jpg",
  "offers": {
    "@type": "Offer",
    "price": "24.99",
    "priceCurrency": "AUD",
    "availability": "https://schema.org/InStock"
  }
}

Place the script in the page’s <head>, or immediately before the closing </body> tag if your CMS makes head edits difficult. Either location works; consistency across your templates matters more than which one you pick.
Handle dynamic injection carefully. If your JSON‑LD is added by JavaScript after the initial page load, confirm the rendered HTML still contains it when Google crawls the page. Semrush’s implementation guide recommends server-side rendering or prerendering for any site relying on client-side frameworks.
Use your CMS’s native tools where they exist. WordPress site owners typically use a dedicated SEO or schema plugin rather than hand-coding JSON‑LD into every template; check the plugin’s own documentation for which types it supports natively. Shopify stores generally get basic Product schema automatically through their theme, though it’s worth confirming with a validator. Static HTML sites need the script block added manually to each template file.
Validate before you publish, not after.

Deployment step	What to check
JSON syntax	No trailing commas, matching brackets, valid quote marks
Required properties	Every field Google lists as mandatory for that rich result type is present
Visible content match	Every value in the schema also appears somewhere on the rendered page
Search Console monitoring	Enhancement reports checked weekly for the first month after launch

Structured data rollouts across dozens of pages get messy fast without a system. A simple tracking sheet listing which page templates have which schema type, and when they were last validated, saves hours when you’re auditing a whole site. If you’re managing this across a large site, a structured spreadsheet workflow keeps the rollout from turning into guesswork.

Pro Tip: Build your JSON‑LD into the page template itself, not as a one-off manual edit. That way every new blog post or product automatically inherits correct schema instead of you remembering to add it each time.

How do you test and validate schema markup?

Three tools cover almost every validation need, and using them in the wrong order is the most common rookie mistake.

Validator checks your JSON‑LD against the Schema.org vocabulary itself, confirming the syntax is valid and the properties you’ve used actually exist for that type.
Google’s Rich Results Test checks something narrower and more important for SEO purposes: whether Google specifically will treat your markup as eligible for a rich result feature, not just whether it’s technically valid schema.
Search Console’s enhancement reports show what’s happening after deployment, tracking valid items, warnings, and errors across your whole site over time.

Run through this checklist before calling any rollout finished: confirm the JSON is syntactically valid, confirm every property Google marks as required for your target feature is present, and confirm nothing in the markup describes content that isn’t visible on the page. Warnings usually mean a recommended (not required) property is missing; errors mean the markup won’t be eligible for the feature at all until fixed.

Search Console’s reports take time to populate. Google’s structured data documentation notes that new markup can take days to weeks to be recrawled and reflected in reporting, so check back rather than assuming an absence of errors on day one means success.

What can schema markup actually do for SEO, and what can’t it do?

Schema markup earns you eligibility, not guarantees, and that distinction trips up more site owners than any technical detail in this guide.

The real benefits are concrete:

Rich result eligibility — star ratings, FAQ accordions, recipe cards, and event listings all require structured data as a baseline requirement.
Potential click-through improvements — a listing with a star rating or price visible in the search results tends to stand out more than a plain blue link, though the size of that lift varies by industry and query.
Clearer entity signals for AI and voice systems — structured data helps AI-driven search features surface facts more reliably than parsing unstructured prose, though how any given platform uses that data is up to the platform.

The limits are just as real. Schema is not a ranking factor in the way backlinks or content quality are. Search Engine Land’s guidance is direct about this:

Schema markup makes a page eligible for a rich result. It does not guarantee one. Google still evaluates overall page quality, relevance, and dozens of other signals before deciding what to show in the results.

Treat it as a clarity signal rather than a shortcut. Google still has to decide your content deserves the enhanced treatment before schema does anything visible at all, and pages with thin or low-quality content rarely see a rich result no matter how clean the markup is. That reality holds for AI-driven search too. Structured data can help a language model or voice assistant identify facts on your page more confidently, but it doesn’t force inclusion in any AI-generated answer.

What mistakes should you avoid with schema markup?

Most schema problems come down to one of five habits, and every single one is avoidable with a five-minute check before you hit publish.

Only mark up content that’s actually visible on the page. Google’s own documentation warns that structured data describing content not present on the rendered page can be treated as a quality violation, occasionally triggering a manual action.
Keep the markup current. A Product schema showing an old price or an Event schema with a past date is worse than no schema at all.
Default to JSON‑LD unless you have a specific reason not to. It’s easier to maintain, easier to test, and it’s what Google’s documentation recommends.
Include the properties that matter for the feature you actually want. A Recipe missing prepTime and nutrition won’t qualify for a recipe rich result even if the @type is technically correct.
Never use schema to describe something misleadingly. Marking a mediocre product with five-star reviews it hasn’t earned is the fastest way to attract a manual penalty rather than a rich result.

Maintenance is where most sites quietly fail. Build schema into your page templates so every new post or listing inherits it automatically, and re-test after any CMS update or theme change. Plugin updates and theme migrations are the single most common cause of previously-working schema silently breaking.

Pro Tip: Set a recurring calendar reminder to spot-check five random pages through Google’s Rich Results Test every quarter. Templates change more often than anyone remembers to check.

CantyDigital’s experience with structured data implementation

CantyDigital has spent 12 years building websites and running SEO campaigns across small and mid-sized Australian businesses, with a focus on signal-based optimisation that works for both traditional search engines and AI-driven platforms. Structured data sits right at the centre of that work, because it’s one of the clearest, most controllable signals a site owner has.

The pattern shows up consistently across client work: businesses that get their Organization, LocalBusiness, and Article schema right as part of a site rebuild tend to see cleaner indexing and more consistent rich result eligibility than sites bolting schema on as an afterthought. It’s far easier to build correctly from the ground up than to retrofit it across hundreds of legacy pages later.

A few signs tell you when it’s time to bring in help rather than handling it solo:

You’re managing schema across dozens or hundreds of pages and a manual approach isn’t scaling.
Your site uses a JavaScript framework and you’re not confident the rendered schema is actually crawlable.
You want ongoing monitoring rather than a one-off implementation, since Search Console errors tend to reappear after redesigns and plugin updates.

If you’re building or rebuilding a site from scratch, structured data belongs in the template stage, not bolted on after launch. That’s exactly the kind of groundwork CantyDigital’s web design process is built around.

Get your schema markup implementation right the first time

The single most useful action you can take today: pick your three highest-traffic page templates, write JSON‑LD for each using Schema.org’s vocabulary, and validate every one through validator.schema.org before publishing.

Hands holding tablet device preparing validation

Point	Details
Definition	Schema markup is structured data, ideally JSON‑LD, that labels page content so machines can read it accurately.
Format choice	Use JSON‑LD over Microdata or RDFa for most modern sites, per Google’s own recommendation.
Eligibility, not guarantee	Schema qualifies a page for rich results but Google still judges quality and relevance separately.
Validate before and after	Check syntax with validator.schema.org, then track real-world coverage in Search Console’s enhancement reports.
Visible content only	Never mark up content that isn’t shown to visitors; mismatches risk manual action.

If your site needs a technical audit or a rebuild that bakes structured data into every template from day one, CantyDigital’s SEO services cover exactly this kind of implementation work, with no lock-in contracts and a focus on signals that hold up across both traditional search and AI platforms.

Where to go for authoritative schema markup guidance

Three resources cover almost everything you’ll need beyond this guide:

Schema — the full vocabulary reference, including every type and property available, with worked examples for types like Recipe.
Google Search Central — the definitive source for which properties Google actually requires or recommends for each rich result feature.
Validator — the tool to run before you publish anything, checking your JSON‑LD against the vocabulary itself.

Bookmark Google’s documentation specifically. It changes more often than most people expect as new rich result features roll out and older ones get retired.

An editorial take on doing schema properly

Most schema content online is written backwards. It starts with a wall of theory about vocabularies and formats, then maybe gets to an actual code example in the last third of the article, if at all. That ordering serves nobody who’s sitting there with a half-finished template trying to figure out what to paste into their <head> tag.

The conventional advice also oversells the SEO impact. Plenty of guides imply schema is some kind of ranking lever you’re missing out on. It isn’t. What it actually buys you is eligibility and clarity, which matters, but it’s a different pitch than “add this and rank higher.” Readers deserve that honesty rather than a vague promise dressed up as a growth hack.

What actually moves the needle: pick two or three schema types relevant to your business, get the JSON‑LD genuinely correct for those, bake them into your templates so they survive redesigns, and validate on a recurring schedule rather than once. That’s a smaller, less exciting task than most articles suggest, and it’s also the one that actually works.

Frequently asked questions about schema markup

Is schema markup the same as structured data?
Schema markup is a specific implementation of structured data using the Schema.org vocabulary. Structured data is the broader concept; Schema.org is the shared dictionary most sites use to write it.

Does adding schema markup guarantee a rich result in Google?
No. Schema markup makes a page eligible for a rich result, but Google decides based on page quality and relevance whether to actually show one.

Which schema format should I use: JSON‑LD, Microdata, or RDFa?
JSON‑LD, in almost every case. It’s the format Google Search Central recommends, it’s easier to maintain, and it doesn’t require editing your visible HTML.

How do I check if my schema markup is working correctly?
Run it through validator.schema.org for syntax validity, then use Google’s Rich Results Test for feature-specific eligibility, and monitor Search Console’s enhancement reports for ongoing coverage and errors.

Does schema markup help with AI search visibility?
It can help. Structured data gives AI systems clearer entity signals to work with, but each platform decides independently how it uses that data, and inclusion in an AI-generated answer is never guaranteed.