A roofer in Leeds adds seven schema types to his homepage and nothing changes in search. That's expected. Schema markup is a shared vocabulary, machine-readable labels that describe what a page contains, and most of the value sits in five types. The rest is context, not a ticket to a richer result.
For most small business sites, the five that matter are LocalBusiness, Organization, WebSite, BreadcrumbList and one content type that matches the page (Product, Article or FAQPage). Add those and stop. Below: what each one does, when to skip it, and a JSON-LD snippet you can copy.
Schema markup tells machines what a page is, and that's all it does
Schema markup is structured data written in a shared vocabulary (schema.org) that labels what a page or entity is. It doesn't change rankings by itself. It changes how machines read your page, which affects how they label, group and sometimes display it.
The plumbing matters. A crawler fetches the page, the parser pulls out the JSON-LD block, and the entity goes into an index. Later, a retrieval system picks candidate pages and cites one. Schema doesn't force that citation. It cuts the chance of being misread along the way.
Google's own documentation (developers.google.com/search/docs/appearance/structured-data) says structured data helps it understand page content and can make a page eligible for rich results. Eligible is the key word. Eligibility is a gate, not a promise.
Long type lists sell well and help little
Most of the extra types either don't apply to a small site or only add context. Each one you add is another place for an error.
The myth: more schema equals more visibility. The correction: a page with five correct types beats a page with fifteen half-filled ones. Google's structured data guidelines (same URL above) say markup that misrepresents the page can be treated as spam.
There's a second myth worth killing. Schema doesn't need to describe everything on the site. It needs to describe the page it sits on, accurately. That's the whole rule.
Five types cover most small sites
The first four describe who you are and how the site is built. The fifth describes what the page is.
| Type | One-line purpose | Where it goes | Earns a rich result? |
|---|---|---|---|
| LocalBusiness | Tells machines your name, address, phone and opening hours | Homepage or contact page, one per location | No direct rich result; feeds the knowledge panel and maps |
| Organization | Names the company as an entity, with logo and social profiles | Homepage | No direct rich result; supports entity understanding |
| WebSite | Identifies the site and enables the sitelinks search box | Homepage only | Yes, sitelinks search box (where Google chooses to show it) |
| BreadcrumbList | Shows the page's position in the site hierarchy | Every page below the homepage | Yes, breadcrumb trail in results |
| Product, Article or FAQPage | Describes what the page is: a product, an article, or a Q&A page | The matching page type | Yes, for Product and FAQPage; Article mainly supports context |
One caveat on the table. Google's rich result support changes over time, and the current in-force version of its structured data documentation prevails. FAQ rich results have been restricted to authoritative government and health sites since 2023, per Google's FAQPage documentation. The markup is still valid and still useful for machines. The visible rich result is not.
Each snippet is a minimal, valid JSON-LD block
Replace the placeholder values with your own. Keep them in one <script type="application/ld+json"> block per page where practical.
LocalBusiness describes a physical business. Use the most specific subtype you can, such as Plumber or HardwareStore, from the schema.org vocabulary.
{"@context":"https://schema.org","@type":"LocalBusiness","name":"Example Roofing Ltd","address":{"@type":"PostalAddress","streetAddress":"1 Sample Street","addressLocality":"Leeds","postalCode":"LS1 1AA","addressCountry":"GB"},"telephone":"+44-113-000-0000","openingHours":"Mo-Fr 08:00-17:00","url":"https://example.co.uk"}
Organization is broader than LocalBusiness and works for online-only firms. It carries the logo and sameAs links, which are the URLs of your profiles elsewhere.
{"@context":"https://schema.org","@type":"Organization","name":"Example Roofing Ltd","url":"https://example.co.uk","logo":"https://example.co.uk/logo.png","sameAs":["https://www.linkedin.com/company/example"]}
WebSite goes on the homepage only. The potentialAction block tells Google the site has an internal search, which is what powers the sitelinks search box.
{"@context":"https://schema.org","@type":"WebSite","name":"Example Roofing","url":"https://example.co.uk","potentialAction":{"@type":"SearchAction","target":"https://example.co.uk/search?q={search_term_string}","query-input":"required name=search_term_string"}}
BreadcrumbList mirrors the visible breadcrumb trail. Each item needs a position, a name and an item URL.
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://example.co.uk/"},{"@type":"ListItem","position":2,"name":"Services","item":"https://example.co.uk/services"}]}
Product is for items with a price and availability. Google's Product structured data documentation lists offers, price and priceCurrency as required for merchant listings.
{"@context":"https://schema.org","@type":"Product","name":"Sample Roof Tile","offers":{"@type":"Offer","price":"12.50","priceCurrency":"GBP","availability":"https://schema.org/InStock"}}
Article fits blog posts and guides. The date fields matter because retrieval systems use them to judge freshness.
{"@context":"https://schema.org","@type":"Article","headline":"How to Choose a Roof Tile","datePublished":"2026-09-01","dateModified":"2026-09-29","author":{"@type":"Person","name":"Sam Example"}}
FAQPage wraps question and answer pairs. The text must match what users see on the page.
{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Do you offer free quotes?","acceptedAnswer":{"@type":"Answer","text":"Yes, within 20 miles of Leeds."}}]}
Stacking several types on one page is normal and usually right
A homepage often carries LocalBusiness, Organization and WebSite together. A product page can carry Product and BreadcrumbList. People call this schema stacking: several types on one page, each describing a different slice of it.
Two ways to do it. Use a single @graph array with an @id for each node and reference them, or use separate script blocks. Separate blocks are easier to debug on a small site. The @graph approach is cleaner when entities reference each other, for example when the Product's brand points to the Organization.
Keep the rule: one entity, one definition. Don't declare two LocalBusiness blocks for the same address with different phone numbers. That kind of contradiction gets markup ignored.
Skip Review, AggregateRating and HowTo unless the page truly contains them
Google's review snippet documentation is explicit that self-serving reviews about your own business aren't eligible, and its HowTo rich result was retired. Marking those up adds risk, not value.
Skip Event unless you run events with real dates. Skip Person unless the page is about a person. Skip anything you can't fill accurately, because an empty or placeholder field is worse than no field.
There's a fair question about whether schema helps AI answer engines cite you. There's no public figure for this. The reasonable position: clean, accurate markup makes a page easier to parse, and parsing comes before citation. It's a supporting signal, not a switch.
Write it, then check it with two tools and Search Console
Three routes. A plugin such as Yoast or Rank Math handles the basics on WordPress. A generator like Google's Structured Data Markup Helper produces a starting block. Or hand-write it and paste it into the page template. Hand-writing gives the most control and the fewest surprises.
Checking matters more than writing. Run each URL through Google's Rich Results Test (search.google.com/test/rich-results), then through the Schema Markup Validator (validator.schema.org) to catch vocabulary errors the first tool ignores. Then watch the Enhancements reports in Search Console for the next few weeks.
One more check: open the page and read the visible content. If the markup says a price of £12.50 and the page shows £15.00, fix it. A mismatch between markup and visible content is the most common reason markup gets ignored.
Key Facts at a Glance
- Five types cover most small sites: LocalBusiness, Organization, WebSite, BreadcrumbList, and one content type.
- Schema markup is a vocabulary, not a ranking lever; Google's docs describe it as making pages eligible for rich results.
- Only WebSite, BreadcrumbList, Product and FAQPage on this list can produce a visible rich result, and FAQ visibility is now restricted.
- Stack types on one page when the page genuinely contains several entities, but never declare the same entity twice with conflicting values.
- Validate with the Rich Results Test and the Schema Markup Validator before watching Search Console Enhancements.
- Markup must match visible content; a mismatch is the fastest way to get it ignored.
Which schema type should a small business add first?
Start with LocalBusiness if you have a physical address and WebSite if you have a homepage with internal search. Those two cover the widest ground for the least effort.
Does schema markup improve Google rankings?
Not directly. Google's documentation frames structured data as a way to help it understand content and become eligible for rich results. Rankings depend on other signals.
Can I add multiple schema types to one page?
Yes. Use separate JSON-LD blocks or a single @graph array. Keep each entity defined once, with consistent values.
How do I add schema markup without a developer?
A CMS plugin such as Yoast or Rank Math handles the common types. For custom pages, paste a JSON-LD block into the page template or a header/footer injection field.
Does schema markup help with AI Overviews and ChatGPT?
There's no public figure for this. Clean markup makes a page easier to parse, and parsing comes before citation. Treat it as a supporting signal, not a promise.
If your site is a single-location service business, start with LocalBusiness, Organization and WebSite on the homepage, then BreadcrumbList on every subpage. If you sell products, add Product to each item page and skip the rest. If you publish guides, use Article with accurate dates. If you run a Q&A page that genuinely answers questions, FAQPage is valid even where the rich result isn't shown. If you can't fill a field accurately, leave it out. That's the whole decision tree.