SEO / AEO

Schema and Knowledge Graph for Service Businesses

Going beyond local-business schema: how to build a connected entity graph that answer engines cite confidently.

Published 2026-06-10 · By Claire Miller

Local business schema gets a service business into the answer engines' map of the world. A connected entity graph gets it cited confidently. The difference is between "we can find the plumber" and "we know the plumber's parent organization, the cities it serves, the services it offers, the customers it has worked with, the certifications it holds, and the regulatory context within which it operates." The connected graph is what differentiates a citation from a guess.

What a knowledge graph is, for a service business

The knowledge graph for a service business is the set of entities the business represents, the attributes of each entity, and the relationships between them. For a plumber, the graph includes the business itself, the services it offers, the cities it serves, the certifications it holds, the parent organization if any, the customers it has worked with (anonymized), the regulatory bodies that govern its work, the building codes it complies with, and the products it installs or uses.

Each entity is a node. Each relationship is an edge. The graph is the structure the answer engines read when they cite the business. A graph with rich entities and explicit relationships is more citable than a graph with sparse entities and unstated relationships.

Why schema.org is the right format

A service business can build a knowledge graph in many formats. The format that answer engines consume is schema.org JSON-LD. The reasons:

• Schema.org is the W3C-canonical vocabulary for entity types on the web.
• JSON-LD is the format every major search engine parses and indexes.
• Schema.org's type hierarchy covers most of what a service business would represent.

A practical knowledge graph for a service business in 2026 is a collection of JSON-LD blocks distributed across the business's pages. Each block is one node or one edge. The blocks together form the graph.

How to build the graph

For a small services business in 2026, the working approach is:

Step 1: List the entities. The business itself. The services. The service areas. The customer segments. The certifications. The regulations. The partner suppliers. The parent organization if any. This list is the graph's nodes.

Step 2: List the relationships. Each service is offered by the business. Each service is offered in each service area. Each service is constrained by each regulation. Each certification is held by the business. Each parent organization owns the business. The lists together are the graph's edges.

Step 3: Map nodes to schema.org types. Business = Organization or LocalBusiness. Service = Service. Service area = City or AdministrativeArea. Certification = EducationalOccupationalCredential. Regulation = legislation.type variants. Parent organization = Organization. Each mapping is a JSON-LD block.

Step 4: Map edges to schema.org properties. "offered by" = provider. "offered in" = areaServed. "constrained by" = subjectOf or similar (the right properties are not always obvious; consult the schema.org reference). "held by" = credentialCategory. "owned by" = parentOrganization. Each edge property points from one node to another.

Step 5: Distribute the JSON-LD across pages. Organization JSON-LD on the about page. Service JSON-LD on each service page. LocalBusiness JSON-LD on the contact page. FAQ JSON-LD where appropriate. The graph is the union of all of these, not a single page.

The graph does not need a single-file representation; the answer engines crawl and parse each page and assemble the graph themselves.

What this looks like for a service business

For a real plumbing company in 2026, the graph is roughly:

Organization ("Acme Plumbing")
├── LocalBusiness subtype Plumber
│   ├── Service ("Emergency Drain Cleaning")
│   │   ├── areaServed City ("Springfield")
│   │   └── areaServed City ("Decatur")
│   ├── Service ("Water Heater Installation")
│   │   ├── areaServed City ("Springfield")
│   │   └── offers PriceSpecification ("$1200-$3500")
│   ├── Service ("Leak Detection")
│   │   └── areaServed City ("Decatur")
│   ├── serviceArea
│   │   └── AdministrativeArea ("Sangamon County")
│   ├── hasCredential
│   │   └── EducationalOccupationalCredential ("IL State Plumbing License #12345")
│   └── parentOrganization
│       └── Organization ("Acme Holdings")
└── FAQPage
    └── mainEntity Question ("How quickly can you respond?")

That graph, distributed across the website's pages in JSON-LD blocks, is what an answer engine reads. The result is a business that is citable for "emergency drain cleaning in Springfield," "IL state plumbing license verification," "Acme Holdings subsidiaries," and related queries.

What this enables in answer engines

The graph enables:

Confident citation. The answer engine does not have to guess at attributes; the graph provides them.

Multi-query coverage. A graph with rich entities is citable for many specific queries, not just the business name.

Disambiguation. A graph with parent organization, license number, and exact service area distinguishes this plumber from any other plumber with the same name.

Continuity across answer engines. All major answer engines consume schema.org. The graph is portable.

What not to build

Three anti-patterns:

A separate "knowledge graph" page. A page whose only purpose is to host JSON-LD for an answer engine. The engines do not need this; they parse the pages they crawl.

Speculative entities. Entities the business "could" cite but does not have a real connection to. The graph should reflect the business truthfully.

Outdated data. A graph that drifts from the business's actual services and service areas is worse than no graph. The graph is reviewed quarterly.

What to do this quarter

For a small services business in 2026, the practical project is:

• List the entities for the business.
• List the relationships.
• Map each to schema.org.
• Distribute the JSON-LD across the relevant pages.
• Validate each JSON-LD block with Google's Rich Results test.

That is the work. For a small business with 10 services, 3 service areas, and 2 credentials, the project is a single sprint and the graph compounds indefinitely.