Entity SEO and schema markup for service businesses: a working playbook

What an entity is in search

Search engines used to match pages to strings of text. Today they also maintain a model of things and the relationships between them. When someone searches for your business by name, asks an assistant who does roof repair in their town, or reads an AI summary that mentions you, the system is resolving an entity: which business is this, what does it do, where, and which website speaks for it.

Google's own documentation for Organization markup says it helps Google understand an organization's administrative details and disambiguate it from others in search results. Disambiguation is the point. A painting company called “Pro 1” shares its name with many unrelated businesses. Clear, consistent signals are how a search engine works out which one a page is about.

The minimum graph for a service business

Most service-business sites need the same handful of types. What matters is that they are connected: each page-level node points to the site-wide nodes by identifier, so the markup describes one business and one website rather than a pile of unrelated fragments.

Two optional additions earn their place on many sites: ItemList on hub pages that list services or articles, and citation on articles that rely on outside sources, which tells machines exactly which documents back the claims.

Stable @ids: the part most sites get wrong

The @id property gives a node a permanent identifier, usually a URL with a fragment. When every page declares the business with the same @id, and every Service, Article and WebPage refers back to it, the markup describes a single entity. When a plugin emits a fresh, anonymous Organization on each page, or two plugins each emit their own, the markup describes several businesses with the same name.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Plumber",
      "@id": "https://example.com/#org",
      "name": "Example Plumbing",
      "url": "https://example.com/",
      "areaServed": [{ "@type": "City", "name": "Fairhope" }]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#org" }
    },
    {
      "@type": "Service",
      "@id": "https://example.com/water-heaters#service",
      "name": "Water heater repair",
      "provider": { "@id": "https://example.com/#org" }
    }
  ]
}

Three rules keep identifiers useful:

• Never change them. Treat /#org like a database primary key. If a redesign renames it, every reference built up over time points at nothing.
• Restate the business node on every page. Each page should carry the full business node with the same @id, not just a reference to a node that only lives on the homepage.
• Generate markup from the same data as the page. On our builds the service name, FAQ text and breadcrumb trail come from one typed record that renders both the visible page and the JSON-LD, so the two cannot drift apart.

Choosing the most specific type

Google's general structured data guidelines ask for the most specific applicable type. Schema.org has dedicated LocalBusiness subtypes for most trades, and using one tells a search engine far more than a generic LocalBusiness.

Our own site describes Digital Gravity as an Organization for now. We serve clients remotely and publish no street address, and Google's LocalBusiness types expect one, so we will add ProfessionalService only once a public business address exists.

Service-area businesses and addresses

Many trades work at the customer's location and have no storefront. Google Business Profile lets these service-area businesses hide their address, and the website should follow the same logic. Describe where you work with areaServed, listing the cities or counties you actually serve, rather than publishing a home address just to fill a schema field.

We apply that rule to ourselves. The address on our company filing is a private residence, so our markup publishes the city only. A business with a real office or shop should publish the full street address, matching its Business Profile character for character.

Consistency off your site

Your website is one source among many. Search engines cross-check what it says against your Business Profile, directories, social profiles and other sites that mention you. When the name, phone number or address differ between them, the signals compete instead of reinforcing each other.

• Use one exact business name, one primary phone number and one address format everywhere.
• List profiles you control, such as Google Business Profile, LinkedIn, Facebook and industry directories, in the sameAs property of your business node.
• Add a profile to sameAs only once it exists and is complete. Empty or abandoned profiles add noise.
• Fix or remove directory listings with wrong details. Incorrect citations tend to get copied from one directory to the next.

What structured data will not do

Being clear about the limits saves money and prevents the shortcuts that backfire.

• It is not a ranking switch. Markup helps understanding and rich-result eligibility. It does not lift a thin page above a better one.
• FAQ rich results are mostly gone. Since August 2023, Google shows them only for well-known government and health sites. Google said there is no need to remove existing FAQ markup, but it should not be the reason to build a page.
• Invisible markup is a policy problem. Google's guidelines say not to mark up content that readers can't see, and not to mark up misleading content such as fake reviews. A structured data manual action costs a page its rich-result eligibility, though Google says it does not affect web ranking.
• Self-serving ratings don't belong in your markup. Google's review snippet rules exclude reviews a business publishes about itself on its own Organization or LocalBusiness markup, so star ratings in your own schema won't produce stars in results.

Entities and AI search

Google says AI Overviews and AI Mode have no extra technical requirements: a page needs to be indexed and eligible to appear with a snippet, and the usual SEO fundamentals apply. One of the practices Google lists by name is making sure structured data matches the visible text on the page.

In practice, AI assistants describe businesses with whatever facts they can find and reconcile. Consistent entity data across your site and profiles makes it more likely they describe you correctly: the right services, the right area, the right name. Some sites also publish an llms.txt file, a proposed plain-language summary for language models; we publish ours at /llms.txt. It is a convenience for machines, not a substitute for clear pages.

How we validate before and after launch

1. Build the site, then parse every JSON-LD block from the built HTML. A block that doesn't parse fails the build.
2. Check that every @id reference resolves to a node on the same page and that no page declares the business twice.
3. Confirm that breadcrumb, FAQ and service text in the markup matches the visible page.
4. Run representative URLs through Google's Rich Results Test and URL Inspection.
5. After launch, crawl the live sitemap on a schedule and alert on invalid JSON-LD, missing fields or accidental noindex tags.

This is the same process behind the structured data on our client sites and on this one. If you want it done on yours, our local SEO service includes schema and entity work as standard, and you can see the results it has produced on our work page.