Schema Markup Guide: Add and Validate JSON-LD
Schema markup describes a page's content in a structured format. To add it well, choose the type that fits the page, populate it from the same facts readers can see, and validate the rendered result. Start with one maintained template rather than adding every schema type to every URL.
JSON-LD is a convenient way to express that information in a script element. It does not replace useful HTML content or establish that Google will show a particular search feature.
Choose markup for the page you actually have
| Page | Type to investigate | Facts to verify |
|---|---|---|
| An editorial article | Article or BlogPosting | Headline, author, representative image, publication date, material update date |
| A product detail page | Product and relevant offer properties | The product, price, currency, and availability shown to the user |
| A page with a visible navigation hierarchy | BreadcrumbList | The same meaningful path shown in navigation |
| A site's home page | WebSite and relevant organization information | The site's name, URL, and actual publisher identity |
Schema.org defines a broad vocabulary. Google's structured-data documentation describes the search features it supports. A type being valid Schema.org markup does not mean it has a Google rich-result treatment.
Article JSON-LD: an example to adapt
The following is fictional teaching content, not a description of this page. Replace its URLs, publisher, dates, headline, and image with real values from the article you are marking up. The referenced image must exist and represent the article.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://example.com/guides/choosing-a-cms#article",
"mainEntityOfPage": "https://example.com/guides/choosing-a-cms",
"headline": "Choosing a CMS for a Small Editorial Team",
"image": "https://example.com/images/cms-workflow.jpg",
"datePublished": "2026-08-01T09:00:00+02:00",
"dateModified": "2026-09-01T11:30:00+02:00",
"author": {
"@type": "Organization",
"name": "Example Editorial Team",
"url": "https://example.com/about"
},
"publisher": {
"@type": "Organization",
"name": "Example Publisher"
}
}
</script>
The @id gives this article entity a stable identifier. The page URL and author URL serve different purposes: one identifies the content, the other identifies its author. Use an actual person or organization as appropriate; do not invent an author to fill a field. Google's Article documentation explains the supported properties and author guidance.
Install it without creating conflicts
- Inspect what already exists. Search the rendered page for
application/ld+json. A theme or SEO plugin may already produce an Article or Product object. - Choose an owner for each fact. For example, the CMS stores the headline and dates, while one template produces the Article object.
- Generate from the page record. A changed title or price should update both visible content and structured data through the same maintained source.
- Add the script to the page. JSON-LD may be placed in the document head or body. Ensure Google can access the content when it renders the page.
- Check the result after publication. Test the URL as well as the code snippet; an editor, plugin, or rendering step may have changed it.
Multiple objects can describe different entities on one page. The problem is conflicting facts, not the mere presence of more than one script. For example, a plugin reporting an old price alongside a theme reporting the current price needs an ownership fix.
If your WordPress handoff transfers article content only, schema may remain the responsibility of the destination theme or plugin. Verify the final page instead of assuming that markup travels with the draft.
Validate in three passes
| Check | Use | What it does not establish |
|---|---|---|
| Schema.org Validator | Inspect parsed structured data and vocabulary use | Eligibility for every Google search feature |
| Google Rich Results Test | Check supported rich-result types and reported issues | That a rich result will appear for a search |
| Rendered page and Search Console | Compare actual visible facts; inspect Google's page view and relevant reports | A complete report for every Schema.org type |
A valid test result is a reason to continue checking, not to stop maintaining the content. Google's quality guidelines require markup to represent the page accurately.
Troubleshoot the failure you can reproduce
| Symptom | First check | Useful correction |
|---|---|---|
| The validator cannot parse the script | Quotes, commas, and unexpected HTML inside JSON | Serialize valid JSON instead of assembling it with string fragments |
| The code test works but the URL test does not | The published HTML, rendering, and access requirements | Fix the delivery path, then test the live URL again |
| Two objects disagree on a date or price | Theme, plugin, and custom template output | Assign one maintained source for the fact |
| No rich-result type is detected | Whether Google supports a feature for the chosen type | Keep useful valid markup without promising unsupported presentation |
| A field becomes stale after an edit | Whether schema is tied to the edited record | Update the data mapping and recheck a representative page |
A small maintenance checklist
- Use the page's real author, title, dates, and image.
- Match offers and availability to what a shopper sees.
- Recheck schema when templates, plugins, or CMS integrations change.
- Update modification dates for substantive edits, not every deployment.
- Keep a saved example of the expected output for each maintained template.
Use the schema generator to prepare a draft, then validate and adapt it. For a broader diagnostic workflow, continue to the SEO audit page.
Common questions
Should every page have FAQ schema?
No. Add useful questions for readers when they belong on the page. Decide on markup separately using the current requirements for the intended search feature. A question-and-answer section alone is not a reason to promise extra search-result space.
Does valid schema improve rankings or AI citations?
Validation confirms specific technical conditions. It does not prove that a page will rank better or be cited. Treat accurate markup as one part of a useful, accessible, maintained page.
About this article
Methodology
Implementation guide based on Google Search Central and Schema.org documentation, checked 6 September 2026. Code uses fictional example content and must be adapted to the visible page. No rich-result or ranking outcome is promised.
Update note
Reworked the guide with specific choices, original illustrative examples, implementation checks, and current primary sources.
Disclosure
This guide links to Clickcentric tools as optional drafting aids. Validation and factual review remain the publisher's responsibility.
Sources
- Introduction to structured data (accessed 2026-09-06)
- Article structured data (accessed 2026-09-06)
- General structured data guidelines (accessed 2026-09-06)
- Schema.org validator (accessed 2026-09-06)
- Google Rich Results Test (accessed 2026-09-06)
Related Articles
How AI Overviews Are Changing SEO: Impact & Measurement
What Google currently says about AI Overviews, eligibility, Search Console measurement, and the SEO work that still matters.
AI SEO Agency Guide: What AI SEO Services Include & How to Choose in 2026
Compare AI SEO service models, evaluation criteria, workflow boundaries, and the questions to ask before choosing an agency or platform.
Best AI SEO Tools in 2026: Compare by Use Case
Compare Search Console, Screaming Frog, Ahrefs, Semrush and Peec AI by the work they support, then choose a practical research and publishing stack.