Home » Structured Data for Service Businesses: What to Mark Up

Structured Data for Service Businesses: What to Mark Up

 
 
 

Direct answer: A service-business website can use a small, verified structured-data graph: Organization for the business entity, LocalBusiness for each genuine physical branch, Service for real offerings, BreadcrumbList for meaningful navigation and Article for editorial content. Mark up only facts visible on the site, use stable identifiers, and validate both the vocabulary and Google feature eligibility.

Structured data helps search systems understand entities and may make a page eligible for supported search features, but it does not create authority or guarantee a rich result. Google’s AI features guidance also says no special schema is required for AI Overviews or AI Mode. For SEO and AI visibility, clear page content, accurate entities and crawlable technical implementation still come first.

Map each page to the right entity

Start with a fact sheet approved by the business: official name, canonical homepage, logo, published contact methods, real locations, service areas, official profiles and the services actually offered. Decide which visible page owns each fact before generating JSON-LD.

  • Organization: the business as a whole, usually described on the homepage or one authoritative organisation page.
  • LocalBusiness: one real physical business or branch, using the most specific accurate subtype available.
  • Service: a genuine offering described on a service page.
  • BreadcrumbList: a typical user path through a hierarchical page.
  • Article or BlogPosting: genuine editorial content with an accurate byline and dates.

Do not combine conflicting values from old directories, footers and social profiles. Correct the visible website first. Google’s general structured-data guidelines require markup to represent the page rather than hidden, irrelevant or misleading information.

Use Organization for the business entity

Google recommends placing Organization markup on the homepage or a single page that describes the organisation; it does not need to be repeated on every URL. There are no required Organization properties for Google’s feature, so include only relevant verified values. Common choices are a stable @id, name, canonical url, crawlable logo, telephone, email, a physical or mailing address where applicable, and sameAs links that unambiguously identify official profiles.

Do not use sameAs as a directory-link field. Do not invent registration numbers, awards, locations or affiliations. If contact details differ across templates, resolve that inconsistency before publishing the graph.

Use LocalBusiness only for genuine locations

Google’s LocalBusiness documentation says each actual location should be defined as its own LocalBusiness and use the most specific applicable subtype. For Google Local Business rich-result eligibility, name and the physical address are required; telephone, URL, geo coordinates and opening hours are recommended when accurate. Put the primary phone and email on the LocalBusiness entity before using extra contactPoint values.

A separate canonical page for each real location is a practical implementation pattern because users can verify its details, but it is not a licence to create thin city pages. A service area is not another branch. Use areaServed on Organization or Service only for verified coverage, and never turn a mailbox or hoped-for market into a physical location.

Describe services without promising a rich result

Schema.org Service can describe an offering with properties such as provider, serviceType, areaServed, offers and offer catalogues. Google’s current supported structured-data gallery does not list a generic Service rich-result feature, so use the vocabulary for accurate machine-readable context, not as a promise of enhanced Google presentation.

Avoid the generic ProfessionalService type: Schema.org now marks it deprecated because it was confused with Service. Use Organization for the provider, a valid LocalBusiness subtype for a physical branch and Service for the offering. Never fabricate packages, prices, availability or coverage.

Build breadcrumbs from a real user path

Breadcrumb markup should describe a typical user path through the site rather than merely copy URL folders. A service article might follow Home → Insights → Article, while a commercial page might follow Home → Services → Service name. Google requires at least two ListItem objects for an eligible BreadcrumbList. Each item needs a position and name; the final item may omit its URL.

Use canonical absolute URLs, keep positions in order and update both the navigation and markup when the information architecture changes. Do not insert location keywords as fake hierarchy levels.

Use Article markup for editorial content

Google currently lists no required Article properties, but recommends useful fields such as author, headline, publication and modification dates, and representative crawlable images. The author type, name and identifying URL or sameAs value should agree with the visible byline. Visible dates and structured dates should also agree, including the timezone where supplied.

Change dateModified only after a significant content update, not whenever a template renders. Keep the page canonical consistent and use a real Person or Organization author rather than an invented expert identity.

Connect nodes with stable identifiers

Use consistent absolute @id references so the same organisation is not described as a new entity on every page. An Article publisher can reference the sitewide Organization identifier, while a Service can reference its provider. This is a sound graph-management practice, not a ranking factor.

Prefer one clear schema owner. Two WordPress plugins can otherwise output duplicate Article objects, different logos, HTTP and HTTPS identifiers, or mismatched dates. Audit the rendered source after plugin, theme or template changes.

Handle reviews and FAQs using current rules

Review markup must describe genuine, specific reviews and ratings that users can readily see. Google’s review guidelines say self-serving Organization or LocalBusiness reviews are ineligible for review stars, including reviews embedded through third-party widgets. Do not aggregate ratings copied from other websites or hide an aggregate in JSON-LD.

Google stopped showing FAQ rich results on May 7, 2026 and removed its FAQ feature documentation in June 2026. FAQ vocabulary may still describe visible questions for other consumers, but it no longer creates a Google FAQ rich result. Do not substitute QAPage unless the page contains one question and lets users submit alternative answers.

Implement JSON-LD reliably

Google recommends JSON-LD and accepts it in the document <head> or <body>. It can process JSON-LD added after rendering, but server-side or early output reduces dependencies and is often easier to test. Escape values correctly, use full URLs and generate facts from controlled fields.

If scripts inject markup, verify the rendered result rather than only the original HTML. PAKWM’s guide to JavaScript SEO rendering diagnostics explains how to separate delivery, rendering and indexing checks.

Validate syntax, eligibility and page consistency

  1. Use the Rich Results Test for Google-supported feature eligibility.
  2. Use the Schema Markup Validator for broader Schema.org vocabulary, including Service.
  3. Compare every property with the visible page and its canonical URL.
  4. Inspect the rendered DOM for missing or duplicate JSON-LD objects.
  5. Use URL Inspection to see what Google rendered and detected.
  6. Deploy a few representative pages before a sitewide template release.
  7. Monitor applicable Search Console rich-result reports, Unparsable Structured Data and Manual Actions.

A passing validator confirms syntax and some eligibility rules; it cannot prove that a claim is truthful, a page is indexed or a search enhancement will appear. Track outcomes through a documented SEO measurement workflow rather than treating schema output as the result itself.

Govern the graph after launch

Assign an owner for organisation facts and another for technical output. Review the graph when a phone number, logo, location, hours, author, site structure or schema-generating plugin changes. Keep a versioned fact sheet and a sample URL set for regression testing.

PAKWM’s SEO service can support intent, eligibility and canonical policy, while website development is relevant when templates or plugins need implementation work.

Primary sources

Need a schema plan based on verified business facts? Request a quote from PAKWM with the organisation page, real locations and representative templates.

Author

Let’s Get in Touch

We’re interested in talking
about your business.

Let's Talk!