Schema Markup for Service Businesses: The 6 Types That Actually Matter

Schema markup — structured data added to a page in a format machines can read — is one of the most over-recommended and under-executed parts of technical SEO. Plugins bolt on a dozen types nobody asked for; agencies list "schema implementation" as a deliverable and ship an Organization block with the wrong logo. Meanwhile the six types that actually change how a service business is understood are often missing or wrong.

This is a guide to those six, written for businesses that sell services rather than products: agencies, consultancies, clinics, contractors, professional firms. What each type does, what to put in it, and the mistakes that get it ignored.

Why it matters more in 2026

Structured data was originally about rich results — stars, FAQs and breadcrumbs in the search listing. That still applies. But the bigger reason now is entity understanding. Google's AI Overviews and assistants like ChatGPT and Perplexity decide whether to cite a source partly on how well they can identify the entity behind it: is this a real organisation, what does it do, who wrote this, is the information consistent with what the rest of the web says? Schema is the most direct way to answer those questions in a form a machine trusts, and it is the subject of our guide to getting cited in AI Overviews.

Use JSON-LD, in the <head>, generated from your templates so it cannot drift from the visible page. Everything below assumes that.

1. Organization — who you are

The foundation. One Organization node, identical on every page, with a stable @id (for example https://yourdomain.com/#organization) that every other type can reference.

Include: name, url, logo (a real, square-ish image at a stable URL), description, email and/or telephone, foundingDate, numberOfEmployees if you are comfortable publishing it, areaServed, a contactPoint, and sameAs — an array of your official profiles (LinkedIn, Google Business Profile, X, industry directories). knowsAbout is worth adding: a list of the topics you are genuinely an authority on, which helps answer engines associate the entity with a subject area.

Mistakes: different names or descriptions on different pages; a logo URL that 404s; sameAs pointing at profiles that do not exist; using LocalBusiness when you have no physical premises customers visit (use Organization or ProfessionalService instead — and if you do have premises, use the specific LocalBusiness subtype with a real address and opening hours).

2. WebSite — the site as a thing

Small but useful: names the site, links it to the Organization as publisher, and can declare a SearchAction if you have internal search. Its main job is to give every WebPage node something to be isPartOf.

3. Service — what you sell

The one service businesses skip most often, and the one that maps most directly onto commercial queries. One Service node per service page, with name, serviceType, description, url, provider referencing the Organization @id, and areaServed.

Two additions do real work. hasOfferCatalog lists the components of the service as named Offers — "Core Web Vitals audit", "LCP remediation" — which tells a machine the scope, not just the label. offers with a priceSpecification (a minPrice and maxPrice in a currency) is what allows a search engine or an assistant to quote a real range for you rather than for a competitor who published one.

Mistakes: one generic Service on the homepage instead of one per page; prices in the markup that do not appear on the page; provider as a fresh, inconsistent Organization object instead of a reference to the canonical one.

4. FAQPage — the questions you answer

FAQ markup earns rich results less often than it did (Google restricted them in 2023 to authoritative sites for most queries), but it remains one of the most valuable types for a different reason: it presents question-and-answer pairs in exactly the form answer engines retrieve. Every service page and every substantive article should have a visible FAQ section and a matching FAQPage node.

Rules: the questions and answers must be visible on the page and must match the markup; answers should be complete and self-contained (this is what gets quoted); keep to the questions genuinely asked about that page's topic rather than padding.

5. Article / BlogPosting — what you know, and who said it

For every article: headline, description, datePublished and dateModified (real dates — Google notices when every page claims today), image, publisher referencing the Organization, mainEntityOfPage, and — the part that matters for trust — an author.

Make the author a Person with a name, a jobTitle, a url to a page that describes them, and worksFor referencing the Organization. Named, credentialed authorship is one of the clearest signals that content comes from experience rather than a content farm, and it is the "E" and the "A" in E-E-A-T made machine-readable. An Organization as author is acceptable for editorial pieces; it is weaker.

6. BreadcrumbList — where the page sits

Unglamorous and worth doing on every page. Breadcrumbs tell search engines the site's hierarchy, replace the URL in the listing with a readable path, and help a retriever understand that a page about GoHighLevel snapshots belongs to a GoHighLevel service belongs to an agency's services. Generate it from the same data as the visible breadcrumb trail so the two cannot disagree.

Types that usually are not worth it for a service business

• Review and AggregateRating on your own services — Google ignores self-serving reviews markup for organisations and it can attract a manual action. Earn ratings on third-party platforms instead.
• HowTo — rich results were retired in 2023; the visible numbered list does the work.
• Product — unless you genuinely sell packaged products with SKUs. Service packages are Services with Offers.
• Speakable, Event, Course — only if the content is literally that.
• Everything a plugin adds by default. Audit it. Duplicate Organization nodes with different data are worse than none.

Implementation checklist

1. One canonical Organization with an @id, emitted identically on every page from a single template function.
2. WebSite and WebPage nodes referencing it; BreadcrumbList on every page below the homepage.
3. One Service node per service page with hasOfferCatalog and, where prices are public, offers.
4. FAQPage wherever there is a visible FAQ; Article with a Person author on every post.
5. Validate with the Rich Results Test and the Schema.org validator; then watch Search Console's Enhancements reports for errors and impressions.
6. Re-check after any redesign — schema is one of the first things a rebuild silently drops. See how to redesign without losing rankings.

Schema is not a ranking trick. It is how you tell machines, unambiguously, who you are, what you sell, what you know and who said it — and in a search landscape increasingly mediated by machines that quote rather than list, that is worth getting exactly right.

Every page we build ships with this set — Organization, WebSite, WebPage, Breadcrumb, Service or Article, and FAQ where there is one — generated from the page's own data so it cannot drift. It is part of every web build and the first fix in most SEO and AI-visibility engagements.