Schema markup explained: structured data for small business websites

Schema markup adds a machine readable description of your business, pages and content. Start with accurate identity details and the right type for each page. Then check Schema.org validity and Google's current feature rules. Correct markup supports understanding and eligibility, with no promise of rankings, special search listings or AI citations.

Understand the four concepts

Schema markup sounds technical, but the idea is simple:

Four terms get mixed up a lot:

Google recommends JSON-LD and also supports Microdata and RDFa, two older ways to write the same thing. Google says it uses structured data it finds to understand page content. Search engines can read ordinary text too. Markup adds an explicit description. It can't turn an unsupported business claim into evidence.

So keep three layers apart. The visible content is what people read. The markup describes it. Google decides what, if anything, to display.

You'll see the word entity a lot. An entity is any real thing you describe, such as the business, a person or a service.

Know what markup can support

Markup has three realistic jobs. None of them guarantees an outcome.

Rich results are enhanced search listings, such as product details or review stars. Clearer entities and eligibility for supported features are the realistic gains. Rankings, Maps placement and review stars aren't guaranteed. Knowledge panels, the information boxes Google sometimes shows for a business, aren't either. Nor are AI citations.

Anyone promising a set ranking uplift or payback period from schema is guessing. Google's guidelines say structured data must truly represent visible page content. Even then, a feature isn't guaranteed.

Choose types by page and feature

Schema.org's vocabulary is much bigger than Google's list of search features. So choose types by what each page is actually about. Then check whether Google offers a feature for it.

Google's search gallery listed 25 features when we checked in October 2026. FAQ, HowTo, the sitelinks search box and Service weren't among them. Some markup supports identity rather than a visible card. That's fine.

Don't treat the table as a checklist for every page. A page should describe its main subject and the entities related to it. More types, properties or scripts don't add value on their own.

Two features you may still see recommended have gone:

Google's documentation updates say FAQ rich results stopped appearing from 7 May 2026. Google removed the documentation on 15 June 2026. The sitelinks search box went earlier. Google said farewell to it in October 2024. By 29 November 2024, the updates page listed it as no longer available.

Useful FAQs on the page itself are still worth keeping. A common mistake is still adding SearchAction markup, the code behind that box. It's wasted effort now.

Describe the business and its locations

Organization describes the business as a whole. LocalBusiness is a more specific model for a business with a physical presence. In Schema.org's LocalBusiness type, LocalBusiness sits under both Organization and Place. So a single business can use one stable identity with a suitable subtype. Create separate entities only when they really are separate.

Google's Organization guidance has no required properties. It suggests placing the markup on your home page or a page about the business. For Google's local business feature, the LocalBusiness rules require a name and a physical address. Use the most specific accurate subtype and your real published details.

Markup can't verify or edit a Business Profile. For the profile itself, see our Google Business Profile guide.

Decide what can be public

Everything in your JSON-LD sits in the page source. Nobody needs to see it on screen for it to be public.

Never publish a private home address just to meet a feature requirement. Don't fake one with a service area. An Organization and Service description can still be useful without chasing the local business feature.

For several genuine locations, give each its own identity and matching page. Connect them to the parent business where that's real. Each location's hours, contact route and address need separate upkeep. A shared brand name doesn't make them duplicates.

Give each entity a stable identifier

An identifier, written as @id, names one thing so other parts of the markup can point to it. Each described thing is a node. The connected set of nodes is the graph.

An identifier is separate from the page URL. A fragment such as #business identifies a thing in the graph. The #business fragment isn't a verification code. Nor is it a reason to create a new page. It isn't a canonical tag either, the tag naming a page's preferred URL.

When domains, templates or business identities change, review identifiers and references together. Keep established identifiers where sensible. Change them deliberately when needed. An @id won't prevent migration losses or force Google to merge entities.

Describe services truthfully

Service describes what you do, so put the real scope in the visible page first. Explain the audience, limits and how to get a quote or book.

Schema.org's Service type has properties such as provider, serviceType and areaServed. Offers can add useful detail. It's descriptive vocabulary, not a ranking technique. A business, a service and the page explaining it can each have an identifier, linked to each other. A service page shouldn't pretend each service has its own address or company.

Product isn't automatically wrong on a service page. Schema.org defines Product as any offered product or service. Google's product features are a separate question, with their own rules. So pick the model that truthfully fits, then check the feature rules. Calling a service a product won't make business reviews eligible for stars.

Priorities differ by business type:

For industry detail, see SEO for trade businesses and local SEO for restaurants. Practices can see our professional services and healthcare SEO pages. Online stores should start with ecommerce SEO.

For health businesses, MedicalSpecialty is an enumeration, a fixed list of values. It describes a clinic's or practitioner's specialty. It isn't the clinic's identity or a Google feature. Schema can't certify credentials, so real registration details belong in supported relationships.

Keep review and authorship claims precise

Review stars and author markup attract the most wishful thinking. Both have clear rules.

Apply review rules correctly

Reviews a business controls about itself aren't eligible for review stars on LocalBusiness or Organization markup. That includes embedded third party widgets. Showing truthful testimonials on your site is still fine. It just won't earn stars.

Genuine product reviews on a product page can still qualify under Google's product rules. Not every review a shop displays qualifies automatically, though. And never copy made up ratings or reviewer names into live code. Before asking clients for reviews, read up on getting Google reviews legally.

Connect authors and qualify AI claims

Article markup should name the real author and publisher, with truthful dates. Google's Article guidance describes the author URL as a page that uniquely identifies the author. It needn't be a new page on your site.

Don't add a profile page just to tick a checklist, or invent credentials. Name any expert reviewer separately from the writer and publisher. Only do that if the role is real.

A modified date should reflect a real update. Strong authorship rests on real evidence. See experience and trust through E-E-A-T.

For Google's AI features, normal Search principles apply and no special AI schema is needed. That doesn't mean every other AI system reads markup the same way. For the wider topic, see generative engine optimisation explained.

Read a connected JSON-LD example

Here's a complete example for a fictional mobile service business and one service page. The example.com domain, name and service are teaching placeholders, so don't paste it unchanged into a live site.

<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#business",
"name": "Example Mobile Services",
"url": "https://example.com/"
},
{
"@type": "Service",
"@id": "https://example.com/tap-repairs/#service",
"name": "Tap repairs",
"serviceType": "Tap repair service",
"provider": {"@id": "https://example.com/#business"},
"areaServed": {"@type": "City", "name": "Melbourne"},
"url": "https://example.com/tap-repairs/"
},
{
"@type": "WebPage",
"@id": "https://example.com/tap-repairs/#webpage",
"url": "https://example.com/tap-repairs/",
"name": "Tap repairs in Melbourne",
"mainEntity": {
"@id": "https://example.com/tap-repairs/#service"
}
}
]
}
</script>

It uses Organization, Service and WebPage. It deliberately leaves out a street address, reviews, prices and credentials. It's a minimal relationship example, not a complete specification or a Google approved implementation.

Trace the two references. The WebPage's mainEntity matches the Service's @id. The Service's provider matches the Organization's @id. In JSON-LD, reusing an identifier points to the same node. Matching display names alone don't create that link.

We checked on our own machine that this JSON parses and both references resolve. That isn't a live Google test.

Swap in your own facts, URLs and identifiers only after inspecting your existing output. If a plugin already defines your business, reuse its identifier instead of adding a second identity. JSON needs straight double quotes, with no trailing commas or comments. Values from your content management system (CMS) need safe encoding, especially quotes, line breaks and empty fields.

The script can sit in the body or the head, the hidden top section of the page code. Google can also read JSON-LD injected after the page loads. Check what actually publishes.

Find conflicting schema output

Many sites have more than one source of structured data. List every possible producer:

• the theme, page builder and custom code

• SEO, local business and review plugins or apps

• the ecommerce platform and tag manager

Record which page types and entities each one actually produces. A plugin's settings screen may not describe everything on the rendered page.

Several scripts can add compatible data. A page can also describe several legitimate entities. Counting script tags tells you little.

The real problems are repeated identities with conflicting names or addresses. Wrong main subjects and stale references count too. A common mistake is switching off a plugin to fix duplicates and losing valid product data with it.

Before switching off a producer, check which useful properties it supplies. A review widget may produce visible content and unwanted markup together. Don't delete customer facing information just to change schema. Record a rollback before you change anything.

Keep one controlled source for each fact. The same business can be referenced from many page types. One service or product shouldn't be repeated blindly on unrelated pages, though. After plugin, theme or cache changes, check the final page again for leftover or reintroduced output. When you change supplier or plugin, keep established identifiers where sensible.

Add markup through the existing platform

The goal is a maintainable setup using your real content and current systems. Check what you already have before buying anything new.

On WordPress, configure the plugin that owns your schema. Or have a developer extend its graph through supported integration points. On Shopify, the structured_data filter converts product and article objects into Schema.org data. Use the right template and inspect the result before adding another block. Leave variant and merchant detail to your ecommerce setup.

Webflow's schema field sits in page settings, including on Collection pages. It needs a paid Site plan or Workspace. Its output appears in the head when you publish. Bind CMS fields so each item gets its own data, and test several items. Existing custom code schema keeps working, so don't add a second copy in the new field.

Our schema markup generator can help you prepare code. It isn't a source of business truth. It won't publish or validate anything for you either.

AI generated schema needs the same checks as anything handwritten. Look for unsupported types, made up fields and ratings that don't belong. A platform's claims about AI visibility aren't evidence of a citation.

Never drop one service page's script into a sitewide template without checking its scope. Keep staging URLs, private information and dummy values out of production. Match the published domain and canonical setup.

Test syntax, meaning and the live page

Testing has four layers. No tool replaces a human check of the facts.

The Schema Markup Validator extracts JSON-LD, RDFa and Microdata, and flags syntax mistakes. The Rich Results Test shows which supported Google features it found. It tests a listed set of feature types. And Google doesn't guarantee a page will appear as its preview shows.

Different results mean different things:

No eligible items for a Service example can be the expected result. So first decide which feature you expected, then judge the result. A missing required property can block the related feature. A missing recommended one may not matter, so don't invent data to clear a warning. Valid code can still describe something inaccurate or ineligible.

Test representative templates and edge cases, such as:

• a normal page

• a page with optional fields empty

• a different location

• a page with quoted text

Check the live page after clearing caches. A saved editor field doesn't prove the script reached the page.

In URL Inspection, compare the indexed snapshot with the live test. A live test proves access. It can't prove indexing or predict Google's chosen canonical. Request recrawling where it helps, without expecting instant indexing or display.

Measure what actually changed

Note the starting figures before release. Then log each change for an honest review later.

Where Search Console has a report for the feature, monitor its validity and search appearance data. Keep implementation success separate from changes in clicks or enquiries. Rich results come and go with rankings, seasonality and Google's own presentation changes.

A before and after movement doesn't prove schema caused it. Nobody can promise a click lift. Our SEO audit checklist puts schema in the context of a broader review.

Keep structured data current

Review your markup when the business or site changes. Common triggers:

• new hours, services, prices or staff

• a new or closed location

• template, plugin or domain changes

After a schema producer is updated or removed, check the generated output. Name a business owner for the facts and an implementation owner for the code. Keep the previous setup ready to roll back. Remove false or sensitive information straight away, even if a valid feature count falls.

Run a short first pass audit

A 15 minute check is a first pass, not a certification. Review your homepage, a priority service page and one article. Use both the vocabulary validator and the feature test, then record each issue with an owner. The Rich Results Test alone won't inventory Service or every business relationship.

Plan the first 30 days

Treat the first month as a controlled pilot.

These are example work windows, not a Google timeline. They don't promise recrawling or display. Our website implementation help is there if your platform or rebuild needs a hand.

What we recommend at Elev8d

Frequently asked questions

Next steps

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.