Structured Data and Rich Results: How to Earn the Extra Detail in Google

Search one company and you get a plain blue link. Search another and you get star ratings, opening hours, a trail of breadcrumbs above the title, and questions you can expand without ever leaving the results page. Same search engine, wildly different amounts of screen space. The difference is usually structured data: a short block of code stating, in a format a machine cannot misread, what the page is actually about. It is one of the few genuinely worthwhile technical jobs on a small business website, and also one of the most oversold.

This guide covers what structured data is, what rich results are, and the relationship between them, which is where nearly everyone gets confused. It also covers the types a small business needs, where the code goes, how to test it, and the rules that get sites penalised.

Who this guide is for

This is for the owner or manager of a small business website who keeps hearing the word schema and wants to know whether it matters. You do not need to write code to follow it, but you do need to be able to tell somebody clearly what should be added and what should not.

It applies whether your site runs on WordPress, Shopify, Squarespace or something custom. The platform changes how you add the markup, not what it should say. If you use WordPress with an SEO plugin, much of this is generated already, which makes auditing the useful part.

It is less relevant if you run a large catalogue, where structured data becomes a feed management problem with daily price changes. For a site of five to a few hundred pages, all of this is an afternoon of work plus a follow-up a month later.

One caveat. If your site is slow, blocked from indexing or missing basic page titles, fix that first. Structured data is a refinement on a page that already works, and our guide to what technical SEO actually covers runs through those foundations.

What structured data is, and what a rich result is

Structured data is a description of your page written for machines. Your page might say "Open until 5.30 today" next to a clock icon, which a human reads instantly. A search engine has to work out whether that is your opening hours, a customer quote or a photo caption. Structured data removes the guessing by stating it as a fact in a fixed vocabulary.

That vocabulary comes from Schema.org, a standard Google, Microsoft, Yahoo and Yandex agreed on years ago. You are not writing something bespoke for Google. You are describing your page in a language several systems already understand, which is why the same markup increasingly gets read by AI assistants too.

The label on the box

Picture a box with contents: a business name, an address, a price, a set of questions. Structured data is the label on the outside stating exactly what is inside. Nothing about the label changes what is in the box, which is the bit people trip over. Adding schema will not improve your copy or make a slow page fast.

The extra detail under a listing

A rich result is what Google may display when it decides your description is worth surfacing. You have seen all of them without knowing they had names. The star rating under a product. The grey trail reading Home, Services, Boiler repair where the URL used to sit. The opening hours in the panel on the right.

Eligibility is not a guarantee

Here is the part worth reading twice. You can write perfect markup, pass every test, see a green tick in Search Console and still never be granted a rich result. Google treats structured data as an input to a decision, not an instruction it has to obey.

That decision depends on things you do not control: how much Google trusts the site, whether the query looks like one where extra detail helps, what device the searcher is on, and whether the feature is live in your country at all. The same page can show breadcrumbs one week and not the next.

Correct markup buys you a ticket to the draw. It does not buy you the prize. Anyone selling schema on the promise of guaranteed stars in the search results is selling something they cannot deliver.

What you can honestly expect from rich results

Better click-through, not better rankings

The honest position is this: rich results mainly affect whether somebody clicks you, not where you sit in the list. A listing carrying breadcrumbs, an image and expandable questions takes up more space and gives more reasons to choose it. That advantage is real.

It is not a ranking factor. Google has been consistent for years that structured data helps it understand a page and makes it eligible for features, but markup alone does not move you up the results. There is a second-order argument that better click-through helps over time, but nobody can promise a number for it.

How long before anything shows

Set your expectations accordingly. If you sit on page four for everything, markup will not rescue you, because nobody sees page four however well described it is. If you already rank on page one, richer listings are a cheap way to take a larger share of those clicks.

Timing matters too. Google has to recrawl the page before it sees the markup at all, which on a small site can take weeks. Give it a month, and check the enhancement reports rather than refreshing a search each morning.

The schema types worth your attention

Schema.org defines hundreds of types and almost all are irrelevant to you. A small business needs three to six, and the discipline is in resisting the urge to add more. Every extra type is another thing to keep accurate, and inaccurate markup is worse than none.

The table below covers the ones that earn their place. Read the third column carefully, because the gap between helping Google understand a page and producing a visible feature is where the disappointment lives. Several of these show you nothing and are still worth adding.

Start with these three

If you do nothing else, do LocalBusiness or Organization on the homepage, BreadcrumbList across the site, and Service on each service page. Those describe the basic facts of your business and how the site is organised, and they are the ones most often missing.

LocalBusiness has subtypes worth using where they exist. An electrician can use Electrician, a dentist Dentist, a restaurant Restaurant. The subtype inherits everything the parent has and adds specificity, which is free precision.

Add these when they genuinely apply

Article markup belongs on blog posts and guides, not service pages. FAQPage belongs where questions and answers are visible to a reader. Product belongs where somebody can buy a specific thing at a specific price, not on a page describing a category of things you might sell. The test never changes: if the thing you are about to describe is not visibly on the page, leave it alone.

The ones to leave alone

Event markup is a trap unless you genuinely run events with dates and venues. HowTo lost its rich result in most cases, and Job posting only makes sense with a real vacancy page. The correct amount of markup is exactly as much as your site truthfully supports.

JSON-LD in practice: LocalBusiness and Organization

There are three formats you can write structured data in. Microdata and RDFa sprinkle attributes through your HTML, which tangles the description up with the layout: change the design, break the markup. JSON-LD keeps the whole description in one self-contained block, and it is the format Google recommends.

Where the block goes

The block sits inside a script tag with its type set to application ld plus json. Conventionally it goes in the head, though Google reads it perfectly well from the body. What matters is that it reaches the crawler in the HTML.

That catches out sites built with heavy JavaScript frameworks. If the markup only appears after the page loads in the browser, Google may or may not see it. Server-rendered output is the safe answer. If you are unsure, view the page source and search for ld+json.

The fields that do the work

A LocalBusiness block does not need to be long. Name, URL, telephone, address and opening hours cover most of the value, with a price range and a sameAs link to your Business Profile as the next layer. Beyond that you are adding maintenance for little return.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Electrician",
  "name": "Your Business Name Ltd",
  "url": "https://example.co.uk/",
  "telephone": "+441245000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1 Example Road",
    "addressLocality": "Chelmsford",
    "postalCode": "CM1 1AA",
    "addressCountry": "GB"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "08:00",
    "closes": "17:30"
  }]
}
</script>

Organization is the sibling type for the business as an entity rather than a place. It carries the legal name, logo, official website and sameAs links to your profiles. With no premises and no service area, Organization alone is right. Otherwise a LocalBusiness subtype does both jobs.

Keeping it consistent with everything else

The name, address and phone number in your markup must match the page, your Google Business Profile and your invoices. Three slightly different versions of one address is a classic small business problem, usually caused by a move or a second phone line.

Inconsistency does real damage, because it undermines the one thing markup is meant to provide, which is certainty. If it says one number and the footer says another, you have handed the search engine a reason to distrust both.

FAQ, breadcrumb, article and product markup

Once the business level markup is in place, the rest is page level. A blog post gets Article, a category path gets BreadcrumbList, a page with visible questions gets FAQPage. Nothing gets a type that describes a different page.

Do this template by template rather than page by page. Most small sites have four or five: homepage, service page, blog post, contact, perhaps a product. Get it right once per template and every page built on it inherits the fix.

FAQPage, and the strings attached

FAQPage is the most abused type on the internet and the one Google has clamped down on hardest. The rules are simple enough. Questions and answers must be visible on the page, they must be genuine, and the page must be about answering them rather than a sales page with three questions bolted underneath.

Google has also narrowed which sites get FAQ rich results at all, favouring well known authoritative and government sites. That does not make the markup pointless, since it still helps a search engine understand what the page answers, but do not build a content plan around those dropdowns.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Do you charge for a quote?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "No. Quotes are free and there is no obligation to book."
    }
  }]
}
</script>

BreadcrumbList

Breadcrumbs are the easiest win in this guide. The markup describes the path from your homepage down to the current page, and Google shows that path in place of the raw URL. It costs almost nothing and is granted more readily than most features.

The path should match navigation a visitor can actually follow. If your markup claims a Services parent page, that page needs to exist and link onward. Invented hierarchies are invented content, just less obvious.

Article, Service and Product

Article markup wants a headline, an author, a published date, a modified date and an image. The dates matter most, since a visible date tells a searcher whether the advice is current. Keep the modified date honest.

Service markup describes what you do, the area you serve and who provides it. It produces no visible feature, so hardly anyone bothers, which is why it is a quiet advantage.

Product markup needs a real price, real availability and a real currency. A page listing the six types of flooring you install is not a product page, and marking it up as one produces the mismatch that gets you flagged.

Testing what you have added

Never assume markup works because you added it. A missing comma silently invalidates the whole block, a plugin can strip it out, and a cache can serve a version from before your change. Testing takes two minutes, and it separates having structured data from believing you have.

Two tools answer two questions. The Rich Results Test tells you whether a page is eligible right now. The enhancement reports in Search Console tell you how the whole site is doing over time. Use both, in that order.

The Rich Results Test

Paste in a URL, or a block of code, and the tool lists which rich result types the page is eligible for, with any errors and warnings. Errors mean the item is disqualified. Warnings mean a recommended field is missing, which you can usually live with.

Test one page per template rather than every page, and test the live URL after your cache has cleared. We have lost more time than we care to admit debugging markup that was fine and simply had not been served yet.

The enhancement reports in Search Console

Search Console groups your structured data into enhancement reports, one per detected type, showing valid items, warnings and errors over time. This is where you find the problem you did not know you had, because it covers the whole site.

The shape of the graph tells you a lot. A sudden cliff usually means a plugin update or template change broke something. A flat line at zero for a type you added means Google has not seen it. Treat errors as urgent and warnings as a tidy-up, and put the check in a calendar, because nothing here will email you.

What "valid" does and does not mean

A green valid status means your markup parses correctly and contains the required fields. That is all. It is a syntax check rather than a truth check, and it will happily validate a block claiming you are open around the clock when you close at five. It also does not mean a rich result will appear.

To find out whether a feature is actually appearing, search a distinctive phrase from the page in a private window and look at your own listing. That is the only test that reflects what a customer sees.

The rules that get sites in trouble

Structured data has a policy attached and, unlike most SEO advice, breaking it has a defined consequence: a manual action. The markup stops being used, the rich results disappear, and you get a notice in Search Console. Recovery means fixing it and requesting a review.

The rules are not obscure and they reduce to one principle: describe the page as it is, for the visitor as well as the crawler. Everything that gets sites penalised is a version of describing a page that does not exist.

Three violations account for almost all of the trouble we see, and none are malicious. They happen because a plugin offered a tick box, or somebody read a post promising stars.

Marking up content nobody can see

If the markup describes it, the visitor must be able to see it. No hidden blocks of questions, no opening hours that are not published on the page, no author names that appear nowhere. Content collapsed behind an accordion is fine, because a visitor can expand it. Content set to display none purely to feed the crawler is not.

This is the rule people break by accident most often, usually via a plugin that stores FAQ content in its settings and outputs only the markup. It looks harmless, and it is what the policy forbids.

Review markup about yourself

You cannot mark up reviews of your own business on your own website and expect stars. Self-serving review markup, meaning review content about an entity the site itself controls, is disallowed for local business and organisation pages. Aggregate ratings you calculate from your own testimonials fall squarely into that.

Reviews of specific products you sell are allowed, provided they are genuine and visible. The distinction is between what customers said about this particular kettle and your own five star average as a company.

FAQ markup on a page with no FAQs

Adding FAQPage markup to a page that displays no questions and answers is a policy breach and, given how restricted the feature now is, usually pointless as well. If you want FAQ markup, write real questions on the page and answer them properly. That is more work than ticking a box, which is exactly why it is the version you can leave running for years.

Common mistakes

The errors below turn up repeatedly and most are invisible until somebody looks. There is no alert, no red banner and no email. The markup simply sits there being wrong, or duplicated, or describing a business that moved premises two years ago.

Several are created by tools rather than people. A plugin adds markup, the theme adds its own, a page builder adds a third set. Nobody chose to have three conflicting descriptions of one page, but that is often what gets served.

Go through the list against your own site rather than how you assume it was set up. The gap between the two is where the problem usually lives.

• Two plugins both outputting schema. An SEO plugin and a theme each adding a block gives one page two conflicting descriptions. Pick one source and switch the other off.
• Markup that contradicts the visible page. Hours in the markup that differ from hours in the footer leave the search engine with no reliable answer.
• Copying an example without changing the values. We have found live sites carrying a tutorial's phone number. Search your page source for the word example.
• Only rendering markup in the browser. If JavaScript adds it after load, it may never be seen. Check the raw page source, not the inspector.
• Never rechecking after a redesign. Template changes strip markup routinely, and a rebuild is the likeliest event to remove it silently.
• Treating it as a one-off. Prices change, hours change, staff leave. Stale markup is a worsening description of a business that has moved on.

A realistic plan for getting this done

This is a small project rather than a programme. For a typical site it is an afternoon of work plus a check a month later. The sequence below front-loads the safe, useful parts and leaves the ones with rules attached until last.

Do it template by template. Five templates means five blocks written and five pages tested, after which every page inherits the result. Working page by page turns an afternoon into a fortnight.

Resist adding everything at once. If something breaks you want to know which change did it, and one deployment of eight new types tells you nothing when the report turns red.

1. First, half an hour: audit what is there. Run one page from each template through the Rich Results Test and note what it detects. Most sites have more markup than the owner realises, and some is wrong.
2. Second, twenty minutes: fix your facts. Write down the correct legal name, trading name, address, phone number, hours and price range, then reconcile the site, the footer and your Business Profile.
3. Third, an hour: business level markup. LocalBusiness with the closest subtype, or Organization if you have no location, on the homepage and contact page.
4. Fourth, thirty minutes: breadcrumbs site wide. BreadcrumbList on every template is the cheapest visible win available and rarely goes wrong.
5. Fifth, forty minutes: page level types. Service on service pages, Article on blog posts, Product on genuine product pages, one block per template.
6. Sixth, twenty minutes: test. One live URL per template through the Rich Results Test, after the cache has cleared. Fix errors now, note warnings for later.
7. Seventh, four weeks later: judge it. Open the enhancement reports, compare clicks and impressions in the Performance report, and check your own listings in a private window.

After that it is maintenance. Recheck after any redesign, plugin change, or change to your prices, hours or premises. Twenty minutes a quarter keeps a description accurate that would otherwise drift.

Frequently asked questions

Where this fits

Structured data is a small, unglamorous job with a clear ceiling on what it can do. It will not fix a slow site, rescue thin content or lift you off page four. What it does is make sure a search engine knows exactly what your business is, so that when it decides to show extra detail, the detail is accurate.

That puts it in the foundations category, alongside the technical work nobody sees and everybody benefits from. Our guide to technical SEO for small businesses covers the wider set, and Google Search Console is where you check whether any of it is landing.

If your site is new or being rebuilt, this is the cheapest moment to get it right, because markup written into a template at build time costs nothing extra and lasts as long as the template does. Retrofitting always costs more, which is why our web design work includes it as standard.

If you would rather somebody just checked what you already have, that is short work and we are happy to do it. Our SEO service starts with exactly this sort of audit rather than a monthly report nobody reads. Get in touch and we will tell you honestly whether it is worth doing, including if the answer is that you have bigger problems.