Schema Markup for Small Businesses: The Complete Guide
What schema actually is, and what it isn't
Schema markup is a vocabulary published by schema.org and adopted by every major search engine. You add a small block of JSON to your page, and it tells the engine, in a structured form, what the page is about: who runs the business, where it is, what it sells, what hours it keeps, what questions it answers.
It is not a ranking trick. It does not, on its own, push you up the results. What it does is make you eligible for rich results: the star ratings, the FAQ accordions, the local pack details, the breadcrumb trails. Eligibility, not entitlement.
That is a useful distinction to keep in mind, because most "schema will boost your CTR by X percent" claims float around the web with no source. Treat schema as plumbing. Plumbing doesn't sell the house, but a house with broken plumbing doesn't sell either.
The two pieces of markup most small businesses actually need
Every small business should have, at minimum, a LocalBusiness block on the home page (or a dedicated contact page) and an FAQPage block on any page that has visible Q&A content.
LocalBusiness JSON-LD
Drop this in the <head> of your home page, inside a <script type="application/ld+json"> tag. Replace the values with your real ones, and pick the most specific subtype your business has (Plumber, Restaurant, Dentist, MedicalBusiness). The full list is on schema.org under LocalBusiness.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Plumber",
"name": "Riverside Plumbing",
"image": "https://example.co.uk/storefront.jpg",
"@id": "https://example.co.uk/#business",
"url": "https://example.co.uk",
"telephone": "+44-161-555-0142",
"priceRange": "££",
"address": {
"@type": "PostalAddress",
"streetAddress": "14 Deansgate",
"addressLocality": "Manchester",
"postalCode": "M3 2BW",
"addressCountry": "GB"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 53.4794,
"longitude": -2.2453
},
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "08:00",
"closes": "18:00"
}],
"areaServed": "Greater Manchester",
"sameAs": [
"https://www.facebook.com/riversideplumbing",
"https://www.instagram.com/riversideplumbing"
]
}
</script>
The @id is worth a note. It gives your business a stable identifier across pages, so you can reference it from other markup (a Service block, a Review block) without redeclaring everything.
FAQPage JSON-LD
Use this only on pages where the questions and answers are actually visible to the user. Marking up invisible FAQs is a quick way to get a manual action from Google.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Do you offer emergency call-outs?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. We cover Greater Manchester twenty-four hours a day, every day of the year. Call-out fees are listed on our pricing page."
}
},
{
"@type": "Question",
"name": "Are your engineers Gas Safe registered?",
"acceptedAnswer": {
"@type": "Answer",
"text": "All our heating engineers are Gas Safe registered. Their registration numbers are listed on the team page."
}
}
]
}
</script>
The answer text in the JSON should match, near enough, what the page actually says. Google explicitly checks for this.
Where to put it and how to test it
Either inside the <head> or just before </body> works; the engines don't care. Inline application/ld+json is the format every major engine prefers. Avoid Microdata and RDFa for new builds; they're harder to maintain and the rich-results coverage is the same.
Validate with two tools, in this order:
- ›Schema Markup Validator at validator.schema.org. This checks that your JSON is structurally correct against the schema.org vocabulary. It flags missing required fields and type errors.
- ›Google's Rich Results Test at search.google.com/test/rich-results. This is stricter. It tells you which Google rich-result types your page is actually eligible for, and it'll warn you about things schema.org won't, like FAQPage entries on pages without visible FAQs.
Run both. They catch different mistakes.
What not to mark up
This is where most schema deployments quietly damage rankings instead of helping them.
- ›Content that isn't visible on the page. If your FAQ answers are only in the JSON, that's spam in Google's view. The text has to be on the rendered page.
- ›Reviews you wrote yourself. Self-serving review markup gets manual actions. Reviews need to come from genuine third parties and should be displayed on the page in a way users can read.
- ›Aggregate ratings without enough actual ratings. If you have three reviews and you're publishing an aggregate rating in markup, Google will eventually catch up.
- ›Stale data. Schema that says you're open until 6 pm when you closed the shop at 5 pm three months ago will erode trust with both users and the engines. Treat schema like any other content: maintained, not set-and-forget.
- ›Conflicting LocalBusiness blocks across pages. Pick one canonical declaration with a stable
@idand reference it elsewhere.
The mistakes that quietly cost you
The single most common one: missing required fields. Each schema type has a list of properties Google requires for rich-result eligibility, and the validators tell you which ones. The next most common: marking up an entire page as FAQPage when only a strip of two questions appears. The third: forgetting to update the markup when you redesign and the visible content changes shape.
There's a more subtle mistake too. Some teams add every schema type they can find. Article, BreadcrumbList, Organization, LocalBusiness, FAQPage, HowTo, Service, all on one page. The result is a page that doesn't clearly say what it is. Pick the schema that matches what the page primarily is. One or two types per page is usually right.
The summary
Schema markup is straightforward, and the tooling is good. Add LocalBusiness on the home page, add FAQPage where you have real FAQs, validate with both Schema Markup Validator and Rich Results Test, keep it in sync with the visible page, and don't mark up things that aren't there. That's most of the practical guide. The rest is keeping it maintained as the business changes.
