Article, FAQ and Breadcrumb Schema: Copy-Ready JSON-LD Examples
Copy-ready JSON-LD for Article, FAQPage and BreadcrumbList schema, with every property explained, the mistakes to avoid and a…
A plain-English introduction to schema markup: what structured data is, why JSON-LD is the format to use, how a block is built, where to add it and how to check it works.

Schema markup is a small block of code that tells search engines exactly what a page is about: an article with an author and a date, a local business with opening hours, a product with a price. Search engines can often work this out from your text, but schema markup removes the guesswork. This guide explains structured data in plain English, shows you how a JSON-LD block is put together, and walks you through adding and testing your first one.
This guide is part of our complete website SEO audit guide, which walks through every step of auditing a small site.
Schema markup is structured data written using the shared vocabulary published at schema.org. That vocabulary was created jointly by the major search engines so that everyone describes things the same way. It defines hundreds of types (Article, Organization, Product, Event, Recipe, LocalBusiness and so on) and, for each type, a list of properties (headline, author, datePublished, address, priceā¦).
When you add schema markup to a page, you are not changing what visitors see. You are adding a machine-readable summary alongside the visible content. A person reads “Published 4 September by the Editorial Team”; a search engine reads "datePublished": "2026-09-04" and "author": {"@type": "Organization", "name": "Editorial Team"}. Same facts, but in a format that cannot be misread.
Three things structured data is not:
There are three ways to write schema markup: Microdata, RDFa and JSON-LD. Microdata and RDFa weave attributes into your existing HTML tags, which means the markup breaks whenever someone edits the layout. JSON-LD sits in its own <script> tag, completely separate from the visible HTML.
| Format | Where it lives | Ease of maintenance |
|---|---|---|
| JSON-LD | A single script block, usually in the <head> | Easy: edit one block without touching the design |
| Microdata | Attributes on visible HTML elements | Fragile: template changes can break it |
| RDFa | Attributes on visible HTML elements | Fragile, and less common in SEO plugins |
Google’s introduction to structured data recommends JSON-LD where your setup allows it, and almost every WordPress SEO plugin outputs it. Unless you inherit an old theme full of Microdata, use JSON-LD.
Here is a complete, minimal block for a blog post:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Schema Markup Guide: JSON-LD Explained for Beginners",
"datePublished": "2026-09-04T09:00:00+00:00",
"dateModified": "2026-09-04T09:00:00+00:00",
"author": {
"@type": "Organization",
"name": "Editorial Team"
},
"image": "https://example.com/images/schema-guide.webp"
}
</script>Reading it line by line:
https://schema.org.BlogPosting works, blogposting does not.headline and datePublished hold the values. Dates use ISO 8601 format.@type and properties inside curly braces.JSON is strict. Keys and text values need straight double quotes, items are separated by commas, and there must be no comma after the last item in an object. Most broken JSON-LD comes down to one of those three rules.
As your markup grows you will also see @graph and @id in plugin output. A @graph is simply a list that holds several objects in one block, such as an Organization, a WebSite and an Article. An @id is a unique label (usually a URL with a fragment like #organization) that lets one object refer to another, so the Article can point to the Organization as its publisher without repeating every detail. You do not need either for your first hand-written block, but recognising them makes plugin output much easier to read.
Quick tip: Write and edit JSON-LD in a code editor, never in a word processor. Word processors silently swap straight quotes for curly ones, and a single curly quote makes the whole block invalid.
You do not need dozens of types. Most small sites are well served by four or five, matched to page templates:
| Page | Schema type | Key properties |
|---|---|---|
| Home page | Organization or LocalBusiness, plus WebSite | name, url, logo, address, telephone |
| Blog posts and guides | Article or BlogPosting | headline, author, datePublished, image |
| Every inner page | BreadcrumbList | itemListElement with position, name, item |
| Product pages | Product with Offer | name, image, offers.price, offers.priceCurrency |
| Events | Event | name, startDate, location |
Be realistic about rich results. Google has narrowed or retired several enhancements over the years. FAQ rich results, for example, are now limited to well-known government and health sites, and HowTo rich results have been removed. The markup is still valid and still describes your content, but check Google’s Search Gallery before you invest time in a type purely for a visual enhancement. For copy-ready code, see our Article, FAQ and Breadcrumb JSON-LD examples.
There are three common routes. Pick the one that matches how your site is built.
On WordPress, plugins such as Rank Math or Yoast generate Article, Organization, WebSite and BreadcrumbList markup automatically. Your job is to fill in the settings correctly: organisation name, logo, social profiles and default schema type for posts. This covers the basics for most blogs.
For types a plugin does not cover, paste a JSON-LD block into the page’s head section or into a custom HTML area. Keep a master copy of each block in a text file so you can update it later.
Developers can output JSON-LD from page templates, pulling values like the title and date straight from the database. This keeps markup in sync with content automatically, which is the most reliable option on larger sites.
Whichever route you choose, follow these steps:
Never assume markup is correct because a plugin says it is enabled. Test it:
For quick spot checks while browsing, the free LiteScroll SEO Inspector Chrome extension lets you review the schema markup on any page you visit, alongside its metadata and heading structure. That makes it easy to compare your pages with a competitor’s or confirm that a plugin change actually reached the live page.
If a test flags problems, our guide to testing and fixing schema markup errors walks through the most common messages and their fixes.
url, image and logo values.Structured data also works best on pages that are already well structured. A clear title, a single descriptive heading and a strong meta description matter more than any snippet of code; our guide to page titles and meta descriptions covers that groundwork.
To check which schema types a live page already outputs before you edit anything, use the LiteScroll SEO Inspector Chrome extension, then validate the markup with a dedicated testing tool.
For more practical, lightweight SEO guides and tools, visit LiteScroll.com.
Written by
Editorial Team
The LiteScroll Editorial Team researches, tests and writes every guide on LiteScroll.com. We run each fix through our own SEO Crawler and SEO Inspector before we recommend it, and we update guides when search engines change the rules.
Our editorial policy
Copy-ready JSON-LD for Article, FAQPage and BreadcrumbList schema, with every property explained, the mistakes to avoid and a…

A step-by-step workflow for finding and fixing schema markup errors and warnings: which testing tools to use, what…

A complete website SEO audit guide for small sites: plan your pages, check indexability, canonicals, titles, headings, images…