Structured Data for Service Businesses

Use Organization to identify the company, LocalBusiness only for a genuine physical business location, and Service to describe a specific service on the page where that service is visibly explained. Connect the entities with stable @id values, keep every claim consistent with the page, and validate both the syntax and the business facts. This creates a clearer entity model; it does not guarantee rankings or a special Google search feature.

Start with the business model, not a schema generator

Structured data should describe the website that already exists. Before writing JSON-LD, identify the real entities and the pages that establish them:

the organisation that owns the website;
each physical location customers can actually visit, if any;
the individual services offered;
the web pages that provide the visible evidence for those facts.

This prevents a common failure: one plugin labels every page as a local business, another creates a different organisation, and a third invents a service catalogue from navigation labels. The result may be valid JSON but an inconsistent description of the business.

Use Organization as the site-wide identity

Google recommends adding Organization data to the home page to help it understand and disambiguate the organisation. The useful properties are the ones the business can verify publicly: name, url, logo, relevant contact details, a postal address when applicable, and authoritative profiles in sameAs.

Create one stable identifier such as https://example.com/#organization and reuse it whenever another entity refers to the same company. A service page can then point its provider to that identifier rather than repeat a slightly different name, URL and address on every page.

Do not add every directory profile you can find to sameAs. Use pages that unambiguously represent the same organisation and that the business controls or recognises. Likewise, do not add an address, award, identifier or social account merely because a schema field exists.

Use LocalBusiness only when locality is real

LocalBusiness is a subtype of Organization intended for a particular physical business or branch. It is appropriate when the page describes a real location with facts such as an address, business type and opening hours. Google advises defining each location separately and choosing the most specific applicable subtype.

A remote consultancy serving clients internationally is not automatically a local business in every target city. Creating location entities for virtual offices, service areas without premises or cities mentioned only for SEO can misrepresent the company. For a business with several genuine branches, give each branch its own URL and @id, publish its visible details, and keep those details consistent with the corresponding Business Profile and other authoritative records.

Service area and physical location are different concepts. Schema.org allows a Service to use areaServed, but the value should describe actual delivery capability. Avoid long keyword lists of countries and cities that the page does not explain.

Describe the offer with Service on the relevant page

Schema.org defines Service as a service provided by an organisation or person. Useful properties include name, description, serviceType, provider, areaServed and, where genuinely applicable, offers or hasOfferCatalog.

Keep one primary service entity aligned with the page’s main subject. A page about international SEO can describe that service and connect it to the organisation that provides it. It should not silently add unrelated development, advertising and photography services just because they appear in the main menu.

Google’s supported structured-data gallery currently lists Organization and LocalBusiness, but not a general Service rich-result feature. Service markup can still provide a machine-readable description using Schema.org. Treat that as semantic clarification, not a promise of stars, an expanded snippet or higher rankings.

Connect entities instead of duplicating them

A small graph is easier to maintain than several disconnected objects. The pattern below is illustrative; replace every placeholder with visible, verified information from the real site:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Visible company name",
      "url": "https://example.com/"
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/example/#service",
      "name": "Visible service name",
      "url": "https://example.com/services/example/",
      "provider": { "@id": "https://example.com/#organization" }
    }
  ]
}

The identifiers are URLs used as stable names for entities; they do not need to be separate pages. Keep them unchanged across templates and releases. If the site already has Organisation data from an SEO plugin, extend or reference that entity rather than creating a competing one with another @id.

Make structured data agree with visible content

Google’s quality guidelines require structured data to represent the page’s main content and prohibit hidden, irrelevant or misleading information. Before deployment, compare the markup with the rendered page:

Does the company name match the header, footer and legal identity used on the site?
Is the service clearly described in ordinary page copy?
Are the address, opening hours and contact methods current and visible where users need them?
Are prices, ratings and reviews real, current and eligible for the chosen type?
Does the canonical URL identify the same page used in the entity graph?

Do not use schema to compensate for thin content. If the service page does not explain scope, audience, delivery area or provider, improve the page first. The markup should summarise the facts, not become the only place where they exist.

Plan multilingual and international implementations carefully

For multilingual sites, each language page should describe the content that users see in that language. Keep stable organisation identity where it is genuinely the same legal entity, but localise service names and descriptions rather than mixing languages in one object. Canonical and hreflang signals should agree with the URL represented by the structured data.

Do not create a different organisation merely because the website has another language folder. Conversely, if separate country operations are legally or operationally distinct, model them from verified business facts instead of forcing them into one global entity. International architecture, visible content and schema should tell the same story.

Validate syntax, eligibility and production output

Validate the graph with the Schema.org validator to catch vocabulary and relationship errors.
Use Google’s Rich Results Test for types and features Google supports.
Inspect the rendered HTML, not only a CMS preview or plugin panel.
Check that only one intended organisation identity is emitted.
Test canonical, robots and language annotations on the same URL.
Deploy to a small page set, then inspect Search Console enhancement reports and URL Inspection where applicable.
Repeat the checks after theme, plugin, address, service or navigation changes.

A page can pass an automated test and still be wrong because the underlying facts are stale or misleading. Google also states that valid structured data does not guarantee a rich result. The release decision therefore needs both technical validation and editorial review.

Common mistakes to remove before launch

marking an online-only company as a physical business in several cities;
creating multiple organisation entities with different names or URLs;
adding services, areas, prices or reviews that are not visible on the page;
using sameAs for ordinary links rather than identity references;
assuming Schema.org validity means Google supports a rich result for that type;
leaving stale JSON-LD after a rebrand, move or service change;
letting several plugins emit overlapping graphs without checking the final HTML.

Structured-data work fits naturally into an international SEO review, where templates, canonicals, hreflang and indexation can be assessed together. It should also be planned during website development and kept accurate through ongoing website maintenance. If the current graph is duplicated or unclear, contact VOWE with the affected URLs and the decision the markup needs to support.

Questions about service structured data and VOWE

Can VOWE audit structured data for a service business?

Yes. VOWE can review the structured data emitted by templates and plugins, compare it with visible business information, identify duplicate or conflicting entities, and check how it aligns with canonicals, language versions and indexable service pages.

What can VOWE include in a structured-data implementation?

The work can include an entity map, appropriate Schema.org types, stable identifiers, JSON-LD implementation, connections between the organisation and its services, production validation and documentation for future content or template changes. The exact scope depends on the website and its existing SEO setup.

When should structured data be reviewed again?

Review it after a redesign, CMS or SEO-plugin change, domain or URL migration, rebrand, new business location, major service change or multilingual expansion. It should also be checked when Search Console reports new structured-data issues.

Service Business Structured Data: Organization, LocalBusiness and Service