Structured Data and CMS: A Practical Guide

Structured data has a reputation for being complicated, mostly because plugin-driven implementations bury it behind settings screens. The underlying format is genuinely simple, and most CMS platforms — headless or otherwise — can generate it directly from content that already exists. This is the practical version: what to implement, and how.
Table of Contents
- JSON-LD Is the Format to Use
- The High-ROI Schema Types Worth Prioritizing
- Two Implementation Approaches
- Plugin-Driven (Traditional CMS)
- Template-Driven (Headless or Structured-Content CMS)
- A Real Example: EmDash's page:metadata Hook
- Practical Structured Data Checklist
- Validating What You've Built
- Frequently Asked Questions
- Does the position of the JSON-LD script tag in the page matter?
- Can I have multiple JSON-LD blocks on one page?
- Is structured data itself a direct ranking factor?
- Do I need structured data if my CMS doesn't have a dedicated SEO plugin?
- The Bottom Line
- Sources
JSON-LD Is the Format to Use
JSON-LD is trivial to generate programmatically from a CMS, API, or database, making it the preferred format. Google recommends using JSON-LD for structured data whenever possible.
JSON-LD is a script tag containing a JSON object describing your page's content in a standardized vocabulary (schema.org). Unlike older microdata or RDFa formats, it doesn't need to be woven into your visible HTML — it's a separate block, easy to generate from a template without touching your page's actual markup.
The High-ROI Schema Types Worth Prioritizing
Common high-ROI candidates are Product (e-commerce), LocalBusiness (local), BreadcrumbList (navigation), Article (editorial), and FAQPage or HowTo when the content genuinely fits.
That "genuinely fits" qualifier matters — schema markup that doesn't accurately describe your actual content is a real risk, not just wasted effort. Worth flagging a specific 2026 development here too: Google stopped showing FAQ rich results in search for all sites as of May 2026. The FAQPage schema type itself remains valid and won't cause any issues if it stays on your pages, but don't expect the rich-result visibility boost that used to come with it.
Two Implementation Approaches
Plugin-Driven (Traditional CMS)
On a platform like WordPress, dedicated SEO plugins (Yoast, Rank Math, Schema Pro) automate JSON-LD generation for common types through their own settings UI. This is genuinely convenient for a non-technical team, at the cost of being locked into whatever schema types and customization options that specific plugin supports.
Template-Driven (Headless or Structured-Content CMS)
When your CMS exposes a hook or template variable system that lets you emit structured data directly from content fields, you write the JSON-LD generation once per content type, pulling from fields that already exist — no separate plugin, no settings screen to keep in sync as your content model changes.
A Real Example: EmDash's page:metadata Hook
EmDash is a concrete example of the template-driven approach — its `page:metadata` hook lets a plugin (or, in a simpler setup, logic in your Astro templates) contribute JSON-LD directly from the page's actual content, validated and deduplicated by the platform automatically:
"page:metadata": async (event, ctx) => {
if (event.page.kind !== "content") return null;
return {
kind: "jsonld",
id: `schema:${event.page.content?.collection}:${event.page.content?.id}`,
graph: {
"@context": "https://schema.org",
"@type": "BlogPosting",
headline: event.page.pageTitle ?? event.page.title,
description: event.page.description,
datePublished: event.page.content?.publishedAt,
},
};
},That's the entire implementation for Article/BlogPosting schema across every post — no plugin settings screen, and it stays in sync automatically since it reads the same fields your page already renders.
Practical Structured Data Checklist
- Article/BlogPosting schema on every blog post, pulling headline, description, and publish date from existing fields.
- BreadcrumbList schema on any page with a real navigational hierarchy (category → subcategory → post).
- Organization or LocalBusiness schema site-wide, for brand/entity recognition.
- Product schema on every commerce page, if applicable — one of the highest-ROI types where it fits.
- Person schema on author/byline pages, linking back to their authored content.
- Skip FAQPage purely for the rich-result visibility as of 2026 — implement it only if the content is genuinely FAQ-structured for its own sake.
Validating What You've Built
Google's Rich Results Test checks whether your JSON-LD is correct and what rich results it can actually generate; the independent Schema Markup Validator checks conformance against the schema.org vocabulary itself, regardless of whether Google currently does anything visible with that specific type. Run both — a markup error that Google silently ignores today can still matter for other consumers of structured data (AI systems, other search engines) even without an immediate visible SEO effect.
Frequently Asked Questions
Does the position of the JSON-LD script tag in the page matter?
No — it can go in the head or body, and position doesn't affect how search engines parse it. Most implementations place it in the head purely for code organization, not because it's required there.
Can I have multiple JSON-LD blocks on one page?
Yes — a single page commonly carries several schema types simultaneously (Article plus BreadcrumbList plus Organization, for instance), either as separate script tags or an array within one.
Is structured data itself a direct ranking factor?
Not directly — it doesn't boost rankings on its own. It enables rich results (star ratings, breadcrumbs in search listings, FAQ snippets where still shown) that improve click-through rate, and it helps search engines and AI systems understand your content's meaning more precisely, which is an indirect but real benefit.
Do I need structured data if my CMS doesn't have a dedicated SEO plugin?
You need a way to generate it, whether that's a plugin, a template-level hook like EmDash's `page:metadata`, or hand-written script tags in your page templates — the mechanism matters less than actually having valid, accurate structured data on your key content types.
The Bottom Line
Structured data implementation comes down to picking a mechanism (plugin or template-driven) and prioritizing the schema types that actually match your content — Article, BreadcrumbList, Organization, and Product cover most of the real value. See our guide to optimizing an EmDash site for SEO for the full metadata picture beyond structured data alone.




Comments