Schema markup for a local service business: what you need and how to test it

What schema markup does for a service business, and what it doesn't

Schema markup is a block of code that labels the facts on a page, such as who the business is, what service the page sells and where it sits on the site, so a search engine doesn't have to guess. Google calls it structured data: a standard format for giving information about a page and classifying its content. The labels come from the shared schema.org vocabulary. Google accepts three formats (JSON-LD, Microdata and RDFa) and recommends JSON-LD where your site's setup allows it, because it sits in its own script block instead of being woven through the HTML.

For a plumber, an electrician or a physio clinic, that means the page can state plainly: this is a business called X, at this address, on this phone number, and this page describes its blocked drain service in these areas. A person reading the page gets all that from the words and the layout. Markup hands the same facts to a crawler in a form it can't misread.

The limits matter as much as the benefits, because most schema advice online oversells it. Google's structured data guidelines say it doesn't guarantee your markup will show in search results, even when the markup passes its test. Google's documentation describes structured data as a way to help it understand a page and to make the page eligible for certain search features. It doesn't describe it as a ranking boost, and the same guidelines say a structured data manual action removes eligibility for rich results without changing how the page ranks in web search.

AI answers are the other place people hope schema will help. Google's page on AI features and your website says there's no special schema.org structured data you need to add to appear in AI Overviews or AI Mode, and lists making sure structured data matches the visible text on the page as one of its ordinary SEO recommendations. So treat schema as a way to state facts clearly and consistently. It won't fix thin pages, and it won't put an unknown business into an AI answer on its own.

The minimum schema set for a local service business

A service business needs four kinds of node: the business itself, a Service node on each service page, a BreadcrumbList on inner pages, and a page-type node such as WebPage or Article. Everything else is optional, and a lot of it does nothing for a business of this kind.

The business node is the anchor. Google's local business structured data documentation lists only two required properties, name and address, and recommends telephone, url, geo coordinates (at least five decimal places), opening hours and a few others. The url should be the fully qualified address of that business location's own page, and the telephone should be the number meant to be customers' primary way to reach you.

The Service node describes what a page sells. Schema.org defines Service as a service provided by an organisation, and gives it properties a tradie or clinic can actually fill in honestly: provider (your business), areaServed (the suburbs or region you work in) and serviceType (the kind of work). That's enough. You don't need offers, prices or ratings to describe a service, and leaving price out avoids a figure that dates the moment you change your rates.

Breadcrumbs tell Google where the page sits on the site. Google's breadcrumb documentation asks for a BreadcrumbList with at least two items, and recommends breadcrumbs that show a typical path a person would take to the page, instead of mirroring the URL folders. Google's search gallery still lists breadcrumbs as a supported feature at the time of writing (October 2026).

Here's how the set fits together for a hypothetical Sunshine Coast electrician with a home page, six service pages and a contact page.

• Write the markup in JSON-LD and keep it in one script block per page, so there's a single place to check.
• Mark up only what a visitor can see. Google's guidelines say not to mark up content that isn't visible to readers of the page.
• Put markup on the page it describes. A service page carries its own Service node; it doesn't need copies of every other service.
• Leave out properties you can't keep accurate. An opening-hours block that's wrong over Christmas does more harm than no block.
• Skip types written for other industries. Recipe, Product and Event markup on a trade site only adds noise to check.

Choosing the business type: LocalBusiness or a more specific subtype

Use the most specific type schema.org offers for what you do, and fall back to LocalBusiness when nothing fits. Google's local business documentation says to use the most specific LocalBusiness subtype possible, and its general guidelines repeat the advice for every type and property.

Schema.org defines LocalBusiness as a particular physical business or branch of an organisation. Under it sit groups such as HomeAndConstructionBusiness, MedicalBusiness, LegalService and AutomotiveBusiness, and under those sit trade types. An electrician's full chain on schema.org runs from Thing to Organization to LocalBusiness to HomeAndConstructionBusiness to Electrician. Plumber, HVACBusiness, RoofingContractor and Locksmith are all defined types too.

A lot of older guides tell service businesses to use ProfessionalService. Read the note on schema.org's own ProfessionalService page first: it says the general ProfessionalService type for local businesses was deprecated because people confused it with Service, and lists the types it used to include, among them Dentist, AccountingService, Attorney, Electrician, GeneralContractor, HousePainter, Locksmith, Plumber and RoofingContractor. If one of those describes you, use it directly.

If your business does two distinct things, Google says you can list more than one type as an array, for example an electrician who also installs air conditioning listing Electrician and HVACBusiness. Google also notes that additionalType isn't supported for this, so don't rely on it to carry the second type.

Some common Australian service businesses map like this, based on the types defined on schema.org at the time of writing (version 30.1, September 2026):

• Electrician: Electrician (with HVACBusiness as well if you install and service air conditioning)
• Plumber, gasfitter or drainer: Plumber
• Air conditioning or heating business: HVACBusiness
• Roofer or gutter specialist: RoofingContractor
• Painter: HousePainter
• Builder or renovator: GeneralContractor
• Locksmith: Locksmith
• Dentist: Dentist
• Law firm: LegalService
• Mechanic or auto electrician: a type under AutomotiveBusiness, such as AutoRepair
• Anything without a close match (a pest controller or a cleaner, say): LocalBusiness, with the service named in each Service node's serviceType

One business, one entity: using @id across the whole site

Give your business one permanent identifier, a URL such as your home page address followed by #business, and have every page refer to that same identifier instead of describing the business again. In JSON-LD the identifier goes in the @id property. The W3C's JSON-LD specification describes @id as the way to uniquely identify a node with an IRI (a web address used as a name), and a node that contains only @id is a reference to a node described elsewhere.

Why bother? Because the alternative is drift. A site built page by page, or by three different plugins, often ends up with the business described a dozen times: one copy with the old phone number, one with the trading name, one with a postcode typo. Each copy looks like a separate business to a machine reading the markup. One full description, referenced everywhere, means there's exactly one record to keep right.

Google doesn't publish a rule requiring @id. Its organisation documentation recommends putting your organisation details on your home page or on a single page that describes the business, and says you don't need them on every page. The @id pattern follows from that: describe the business in full in one place, then point to it.

Here's the pattern on a hypothetical Caboolture plumbing business's blocked drains page, written out in plain words instead of code:

1. The home page carries the full business node: type Plumber, @id set to the home page URL plus #business, the registered trading name, street address, phone, url, opening hours, logo, and sameAs links to the business's own social profiles.
2. The blocked drains page carries a Service node with serviceType 'Blocked drain clearing', areaServed listing the suburbs the business works in, and provider containing only the @id of the business node.
3. The same page's WebPage node uses the business @id as its publisher, and its BreadcrumbList runs Home, Plumbing services, Blocked drains.
4. A guide on the same site carries an Article node whose publisher is, again, only the business @id.
5. When the phone number changes, it changes once, in the home page node, and every page that points to the @id is current.

Make the schema match your Google Business Profile, field by field

The name, address, phone and website in your schema should be character-for-character what your Google Business Profile shows and what your site displays. Schema isn't a separate record to fill in creatively; it's a copy of facts the business already publishes.

Google's Business Profile guidelines set the standard the profile is held to, and it's a sensible standard for your markup too. The name should reflect the business's real-world name as used consistently on the storefront, website and stationery. The phone number must connect to the individual business location and be under the business's direct control. The website should represent the individual location. If your profile name, your signage and your schema name disagree, fix the source of the mismatch before you touch the code.

Service-area businesses need extra care. If you hide your address on your Business Profile because customers don't come to you, don't publish that street address in your schema while leaving it off the page, because Google's guidelines say markup should describe what's visible. Describe where you work with areaServed instead. Google lists address as required for its local business feature, so a business that hides its address may not be eligible for that feature; that's a trade-off to accept, not a reason to publish a hidden address in code.

This table is a quick audit. Open your Business Profile, your site's footer or contact page, and your schema output side by side, and check each row.

FAQPage and Review markup: what changed, and what to keep

FAQ rich results are gone from Google Search, and stars from your own reviews were never available to a business marking up itself. Google's Search Central changelog records that FAQ rich results were limited to well-known, authoritative government and health websites from September 2023, and that the feature stopped appearing in Google Search from 7 May 2026. HowTo rich results went in September 2023. At the time of writing (October 2026), FAQ isn't on Google's list of supported structured data features.

So should you delete FAQPage markup? Not necessarily. If your FAQ block is visible on the page and the markup repeats it word for word, it does no harm and describes the page's questions in a standard form other tools can read. What you shouldn't do is add FAQ blocks to pages, or pay for FAQ schema work, expecting a search feature in return. Keep one FAQPage per page at most, and keep it matching what visitors see.

Reviews are stricter. Google's review snippet guidelines say that when the business being reviewed controls the reviews about itself, its pages using LocalBusiness or other Organization markup are ineligible for star review snippets. Since August 2023 Google's local business documentation only recommends review and aggregateRating for sites that capture reviews about other local businesses. A tradie copying Google reviews onto the site and marking them up gets no stars for it.

The same guidelines also say not to include fake or undisclosed incentivised reviews on your page or in your markup, and that any reviews you mark up must be readily available to visitors on that page.

• Keep FAQPage only where a real FAQ block is visible, and only one per page.
• Remove HowTo markup; the feature hasn't been shown since 2023.
• Remove Review and AggregateRating markup about your own business from your own site.
• Show genuine reviews as page content if you like, with a link to your Business Profile for the full set.
• Don't buy schema add-ons sold on the promise of stars or FAQ dropdowns in Google results.

How to test schema markup: the Rich Results Test, the Schema Markup Validator and Search Console

Test every template with two tools, because they check different things: Google's Rich Results Test tells you whether Google can read the markup for its supported features, and the Schema Markup Validator tells you whether the markup is valid schema.org at all. Then confirm in Search Console that Google has actually found it on the live page.

The Rich Results Test takes a live URL or a pasted code snippet, fetches the page with Google's inspection crawler (smartphone by default), and reports the supported rich result types it finds, with errors and warnings. It only reports on features Google supports, so a Service node or a WebPage node won't appear in its results even when it's perfectly valid. Testing a URL needs the page to be publicly reachable; a staging site behind a password won't work, so paste the code instead.

The Schema Markup Validator, at validator.schema.org, grew out of Google's old Structured Data Testing Tool. When Google moved it to the schema.org community it said the tool's main purpose would be to check syntax and compliance of markup with schema.org standards. It shows every node on the page, including the ones the Rich Results Test ignores, which makes it the right tool for checking your @id references and Service nodes.

After launch, use the URL Inspection tool in Search Console to confirm Google has found the structured data on a page, and watch the rich result reports for errors on templates. Google's local business documentation notes it may take several days after publishing for Google to find and crawl a page, so don't panic if a fresh page shows nothing on day one.

1. Pick one example of each template: home, a service page, a location page if you have them, a guide and the contact page.
2. Run each URL through the Rich Results Test and fix any critical errors first.
3. Run the same URLs through the Schema Markup Validator and check every provider, publisher and about value points at the same business @id.
4. Compare the business node's name, address, phone and URL with your Business Profile, one field at a time.
5. Check that every FAQ question and answer in the markup matches the visible text exactly, or remove the FAQPage node.
6. After publishing, inspect one URL per template in Search Console and recheck the rich result reports after Google has recrawled.
7. Repeat the check after any theme, plugin or site migration change, since that's when markup most often breaks.