Schema Markup for a Service Business: A Connected Implementation Guide

1. Agree the visible facts first

Before generating code, approve the business name, public contact details, services, coverage and people. Decide what evidence supports each claim and where a reader can see it. If two pages disagree about a service area, resolve the business rule before marking up either one.

Google’s structured-data policies require truthful, relevant markup that represents visible page content. Syntactically valid JSON is not enough.

Google: general structured-data guidelines

2. Give the business and its people stable identities

Use a stable @id for the business and reuse it when a service identifies its provider or an article identifies its publisher. Give the founder a separate identity and connect that person with worksFor or founder where accurate.

Choose Organization or an appropriate LocalBusiness subtype based on the real operation. Do not invent a street address or office to satisfy a template. Keep private home-address details out of public markup when they are not intended for publication. A service area is not a branch location.

The entity graph example explains these relationships before the code. Schema.org supplies the vocabulary; JSON-LD supplies a linked-data format.

Schema.org: LocalBusiness

W3C: JSON-LD 1.1

3. Connect each service to its actual provider

A Service can identify its provider and areaServed. Add an Offer only when there is a real offer to describe. A consultation-dependent price should not become a made-up fixed amount in code.

Do not create a new business identity for every town served. Use the same provider and accurate geographic scope. Keep personal identity links on the person, and business identity links on the organization.

Schema.org: Service relationships

Schema.org: sameAs

4. A small connected example

This is an illustrative model for the invented Cedar Window Studio, not a production template to paste unchanged. The business, founder, service and website are connected. A real implementation must use its own supported facts and URLs.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#business",
      "name": "Cedar Window Studio",
      "url": "https://example.com/",
      "founder": {
        "@id": "https://example.com/#maya"
      }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#maya",
      "name": "Maya",
      "worksFor": {
        "@id": "https://example.com/#business"
      }
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/motorized-shades#service",
      "name": "Motorized shade consultation",
      "provider": {
        "@id": "https://example.com/#business"
      },
      "areaServed": {
        "@type": "City",
        "name": "Post Falls"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": {
        "@id": "https://example.com/#business"
      }
    }
  ]
}

5. Describe the page without duplicating the business

An Article has its own identity, author, publisher, publication date and modification date. Its mainEntityOfPage should identify the page containing it. A WebPage can identify the Article as its mainEntity and connect to the WebSite. BreadcrumbList describes the route a reader can follow.

Reuse existing business and person @ids in those references. A reference with just an @id is deliberate: it points to the shared definition. It should not point to an unrelated business or a missing invented entity. A project article can describe the actual work and its creator without implying that the client endorses every claim.

6. Questions should help the reader first

Publish questions that remove a real uncertainty. If you use FAQPage data, each question and answer must match the visible page. Do not generate hidden questions just to increase the amount of markup.

Google’s documentation updates state that FAQ rich results stopped appearing in Search on May 7, 2026. FAQ content can still be useful to readers; adding the type is not a promised display benefit.

Google documentation updates: FAQ rich-result retirement

7. Validate syntax, eligibility and meaning separately

Use the Schema.org validator to inspect vocabulary and syntax. Use Google’s Rich Results Test for Google-supported rich-result checks. Passing either tool is not a ranking or appearance guarantee.

Then read the graph as business claims. Does every Service point to the right provider? Does the personal profile belong to the founder? Does the price match the visible offer? Can the reader follow the URLs? Are modification dates tied to real edits? A technically valid but false relationship is still wrong.

• Check one canonical business definition, with consistent references across pages.
• Compare visible FAQs and structured answers exactly.
• Verify page, breadcrumb and image URLs after any consolidation.
• Keep public locations and service areas distinct.
• Recheck structured data when the source facts change.

8. Describing an action does not execute it

A service description can say how to ask for a consultation. It cannot deliver a message or reserve time by itself. A real form or action endpoint needs implemented rules, appropriate authorization and a result the system can support.

The Luxe request case shows why a request, provider acceptance and inbox delivery are different evidence points. For your own project, include graph checks in the website acceptance brief.