Short answer
Structured data is machine-readable markup that states what a page's content means — the business, its services, an article, a product, a set of questions. It enables rich results and helps systems understand entities and relationships, but it does not directly raise rankings and must describe content that is genuinely on the page.
Key takeaways
- JSON-LD is the recommended format and the easiest to maintain.
- Markup must match visible content — describing things that are not there is a policy violation.
- Its real value is entity clarity, which matters more as answers are synthesised.
- Validate on deploy; broken markup usually fails silently.
A web page is written for humans and inferred by machines. Structured data removes the inference step. Instead of a system guessing that a block of text is an address, you state that it is an address, belonging to this organisation, with these opening hours.
What it does and does not do
It makes rich results possible — review stars, FAQ expansions, breadcrumb trails, event details. It clarifies entities and their relationships. What it does not do is act as a ranking boost you can apply to a weak page.
The types most businesses need
- Organization — who you are, your logo, your official profiles.
- LocalBusiness — physical location, hours, service area, contact details.
- Service — what you offer, described individually rather than as one blob.
- Article — for editorial content, with author, published and modified dates.
- BreadcrumbList — where a page sits in the site hierarchy.
- FAQPage — where you genuinely publish questions and answers.
A minimal, correct example
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Example Roofing Co.",
"url": "https://example.com",
"telephone": "+44-20-0000-0000",
"address": {
"@type": "PostalAddress",
"streetAddress": "12 Example Street",
"addressLocality": "London",
"postalCode": "SW1A 1AA",
"addressCountry": "GB"
},
"areaServed": [{ "@type": "City", "name": "London" }],
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "08:00",
"closes": "17:00"
}]
}Connecting entities
The step most implementations skip is linking things together. Use stable identifiers so your organisation on the homepage is understood to be the same organisation publishing your articles and offering your services, rather than three unrelated mentions of a similar name.
{
"@type": "Article",
"headline": "What Structured Data Actually Does",
"publisher": { "@id": "https://example.com/#organization" },
"isPartOf": { "@id": "https://example.com/#website" }
}Keeping it honest over time
Structured data drifts. Hours change, services are renamed, a template is refactored and a field quietly disappears. Validate on every deploy, monitor enhancement reports in Search Console, and treat markup as production code rather than a one-off marketing task.
Related questions
- Does structured data improve rankings?
- Not directly. It enables rich results and improves how clearly your content is understood, both of which can affect visibility and click-through. It is not a ranking factor you can apply to weak content.
- JSON-LD, Microdata or RDFa?
- JSON-LD. It is the recommended format, sits separately from your markup, and is far easier to generate and maintain from a component-based codebase.
- Can we mark up FAQs we do not display?
- No. The content must be visible on the page. Marking up hidden or non-existent content is a guidelines violation and typically results in the rich result being withdrawn.
Sources
Want this applied to your business?
We'll look at where you stand today and what the highest-impact next move actually is.
