Structured data basics
Search engines read your visible content, but they also look for structured hints about what a page represents – an article, a product, a local business, a recipe. Here we look at microdata and JSON-LD so you can mark up those relationships honestly and qualify for useful rich results where they apply.
What structured data is for
Structured data is machine-readable metadata embedded in the page. It does not replace good headings, text, and links. It clarifies what those elements mean: ‘this block is the author’, ‘this number is the rating’, ‘this list is a breadcrumb trail’.
Google and other search engines may use that data to show enhanced listings – star ratings, FAQ dropdowns, course carousels, and so on. There is no guarantee. Markup must be accurate, and only types that match the page content are eligible.
Schema.org and vocabulary
Most sites use vocabulary from schema.org – a shared set of types (Article, Organization, Course, etc.) and properties (name, author, datePublished). You do not need to memorise the whole catalogue. Start with the types that fit your content and check Google’s documentation for what they currently support.
Two formats: JSON-LD and microdata
You can express the same facts in more than one syntax. The two you will see most often:
- JSON-LD – a
<script type="application/ld+json">block in the head or body. Keeps metadata separate from your visible markup. Usually the easiest to maintain. - Microdata – attributes on existing HTML elements:
itemscope,itemtype,itemprop. Good when you want metadata tied directly to visible content.
Pick one approach per page section and stay consistent. Do not duplicate the same entity in five formats hoping for a ranking boost – that is more likely to trigger manual review than help.
JSON-LD example: article
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Tables for data - captions, scopes, complex headers",
"author": {
"@type": "Person",
"name": "Dan Slade"
},
"datePublished": "2026-04-15",
"dateModified": "2026-04-20",
"publisher": {
"@type": "Organization",
"name": "Codeskill",
"logo": {
"@type": "ImageObject",
"url": "https://codeskill.co.uk/assets/logo.png"
}
},
"description": "Intermediate HTML tutorial on accessible data tables."
}
</script>JSON-LD sits alongside your content. The visible article should still have a proper <h1>, author byline, and dates where relevant – search engines cross-check.
Microdata example: same article
Here is roughly the same information woven into the HTML:
<article itemscope itemtype="https://schema.org/Article">
<h1 itemprop="headline">Tables for data - captions, scopes, complex headers</h1>
<p>
By <span itemprop="author" itemscope itemtype="https://schema.org/Person">
<span itemprop="name">Dan Slade</span>
</span>
· <time itemprop="datePublished" datetime="2026-04-15">15 April 2026</time>
</p>
<p itemprop="description">Intermediate HTML tutorial on accessible data tables.</p>
<div itemprop="articleBody">
<!-- tutorial content -->
</div>
</article>Microdata attributes do not change how the page looks. They annotate what is already there. That makes them honest by design – if the markup says itemprop="author", there should be a visible author on the page.
BreadcrumbList
Breadcrumbs help users and search engines understand site hierarchy. JSON-LD is common here because breadcrumb nav is often a list of links you do not want to clutter with extra attributes:
<nav aria-label="Breadcrumb">
<ol>
<li><a href="/">Home</a></li>
<li><a href="/html/">HTML</a></li>
<li>Going further with HTML</li>
</ol>
</nav>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://codeskill.co.uk/"
},
{
"@type": "ListItem",
"position": 2,
"name": "HTML",
"item": "https://codeskill.co.uk/html/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Going further with HTML"
}
]
}
</script>Course and organisation markup
For a tutorial site, Course or LearningResource types may be relevant on lesson pages. Keep properties factual:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Course",
"name": "Going further with HTML",
"description": "Intermediate HTML tutorials covering structure, media, and accessibility.",
"provider": {
"@type": "Organization",
"name": "Codeskill",
"url": "https://codeskill.co.uk"
}
}
</script>Rules you should not break
- Tell the truth. Do not mark up reviews you fabricated, prices that are wrong, or FAQ entries that are not on the page.
- Match visible content. Structured data that contradicts the page is worse than none at all.
- Use supported types thoughtfully. Check current rich result guidelines before investing time in obscure vocabulary.
- Validate. Google’s Rich Results Test and Schema Markup Validator catch syntax errors and highlight missing recommended fields.
Testing and maintenance
Structured data rots like anything else on a site. When you rename a course, change URLs, or remove a product, update the JSON-LD or microdata at the same time. A quarterly check on key templates is enough for most small sites.
Rich results are a side effect of clear, honest metadata – not the goal of writing HTML. Get the page right for humans first, then add structured data that describes what is already there.