Schema.org markup: the complete guide for SMEs

What to look at first

Schema is not a trick; it is a clarity layer. Use it to label articles, services, FAQs, authors, breadcrumbs, and business details so machines can interpret content correctly.

• Map page types before writing schema.
• Add Article and FAQPage to knowledge content.
• Add Service schema to commercial pages.
• Validate markup before publishing.

What the result should be

The goal is cleaner interpretation, richer search eligibility, and stronger signals for AI-answer systems.

Assessing GEO citation readiness

AI search systems do not cite a page because it is long. They cite pages that answer a question clearly, look trustworthy, and can be decomposed into useful answer blocks.

Publishing workflow for AI search

GEO is not a one-time optimization. It is a publishing rhythm: answer specific questions, cluster related topics, link internally, and refresh pages as tools, rules, or market context change.

• Choose one search intent per page.
• Start with a direct answer that can be cited.
• Use tables for comparisons and decisions.
• Link pillar pages to supporting articles.
• Refresh pages when tools, regulation, or market context changes.

Structured data describes visible page content

Schema.org markup gives search engines explicit information about an organisation, author, service, breadcrumb or article. It is not a place to insert extra keywords or invisible claims. Use types that genuinely fit the page and keep required and recommended properties aligned with what visitors can see.

• Use Organization or LocalBusiness for consistent company information.
• Use Article or BlogPosting for editorial knowledge content.
• Add BreadcrumbList when a visible navigation hierarchy supports it.
• Use Service on genuine service pages and FAQPage only where appropriate.

A clean graph for a knowledge article

An Article node can contain the headline, dates, author, publisher, image and canonical URL. The author references a Person node and the publisher references the same Organization node used site-wide. BreadcrumbList describes the path from knowledge base to category and article. Stable @id values connect these elements as related entities instead of isolated JSON fragments.

Implement and validate in stages

Begin with commercially and editorially important templates. Generate markup through shared helpers so names, URLs and logos stay consistent.

• Inventory page templates and select the most specific appropriate type.
• Create stable @id values based on canonical production URLs.
• Include only information that is known and visible.
• Test JSON syntax, Rich Results Test and Schema Markup Validator.
• Inspect rendered HTML and Search Console after deployment.

Check implementation and outcome

Valid markup does not guarantee a rich result. Track technical health while also checking whether search engines understand the intended canonical page and entities.

• Valid and invalid items by schema type.
• Pages with missing or conflicting canonical URLs.
• Impressions and click-through rate for supported result types.
• Consistency of company, author and location data across the site.

More schema is not necessarily better

Do not add Product, Review or AggregateRating without genuine visible products and reviews. Do not mark ordinary navigation as FAQ to chase search space. Excess or misleading markup creates maintenance risk and may trigger manual action. A small, accurate graph is better than a long list of types that do not match the page.

Design the website's entity model first

Useful structured data starts with an inventory of the real entities represented by the website, not a collection of copied snippets. Identify the organisation, people, services, articles, offices and products, then define how they relate. Give each persistent entity a stable `@id` so search systems can recognise the same author or organisation across pages. Visible content remains the source of truth: markup may clarify a claim, but should never introduce information that a visitor cannot verify.

• Give the organisation, website, authors and offices stable absolute `@id` values.
• Connect Article authors and publishers to existing Person and Organization entities.
• Generate BreadcrumbList from the visible hierarchy and canonical URLs.

Use only schema that matches the page

More markup is not automatically better. A service page is not necessarily a Product, and a set of promotional questions does not always qualify as FAQPage content. Define a small schema profile for each template and populate only fields that are maintained reliably. For an article, the headline, description, dates, author and mainEntityOfPage usually matter more than dozens of optional properties. Local details must remain consistent with addresses and contact information shown elsewhere.

• Knowledge content: Article or BlogPosting, BreadcrumbList and publisher details.
• Commercial pages: Service with provider, areaServed and an accurate description.
• Company pages: Organization, contact points, offices and verified sameAs profiles.

Validate syntax and meaning after every release

A passing syntax check proves only that the JSON-LD can be parsed. Also verify canonical URLs, dates, relationships, duplicate entities and agreement with visible content. Test representative templates with Google's Rich Results Test and the Schema.org Validator, then monitor Search Console for new issues. Put these checks into the release process. Hand-maintained markup quickly becomes stale when routes, headings or shared components change.

• Test at least one representative URL for every changed page template.
• Inspect rendered HTML rather than only the TypeScript or CMS source.
• Track errors, warnings and rich-result report changes after releases.