JSON-LD for business GEO, connecting a company to its services

A business may have a company profile, several service pages and versions in different languages. Before adding structured data to each page, establish which company and service the page describes, then express the relationship between them.

Schema.org's provider property gives this work a specific starting point by describing the service provider. Represent the page with WebPage, the particular service with Service, and the company with Organization. The service can then point to the company that provides it. Schema.org's provider definition

This implementation helps machines read an explicit business relationship. Google also requires structured data to match content visible to readers. Engineers can reduce inconsistent names and conflicting fields; whether an AI answer cites the website remains a separate observation. Google's general structured data guidelines

Verify the business facts on the page

Before writing JSON-LD, open the service page and confirm the company and service names. Check whether the content explains the offering and the company's role in delivering it. For a service the company itself provides, identify that company as the provider. If the page describes a third-party service, provider should identify the actual provider; owning the webpage is not sufficient reason to name the publisher as the provider. Schema.org's description of the provider role

Use the business information already published on the page as the source of the service description. If the content does not yet explain the intended customers and use cases, improve the page first. Structured fields cannot replace the explanation readers need, and should not conceal promises that the page does not publicly state.

The example below uses example.com and "Example Company" to demonstrate the structure. The company, URLs and service description are teaching placeholders. Replace and verify all of them before use.

Connect the company, page and service in one graph

JSON-LD's @id can identify a node so that other nodes can refer to it. @graph can organize multiple nodes. A business website can use these features to maintain a stable company identifier and separate identifiers for a particular service and webpage. W3C's JSON-LD 1.1 standard

Here is a basic example for a service page. It demonstrates relationships, and does not establish compliance with all requirements for a particular Google rich result.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Company",
      "url": "https://example.com/"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/services/ai-visibility/#webpage",
      "url": "https://example.com/services/ai-visibility/",
      "name": "AI visibility analysis for business websites",
      "mainEntity": {
        "@id": "https://example.com/services/ai-visibility/#service"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/ai-visibility/#service",
      "name": "AI visibility analysis for business websites",
      "url": "https://example.com/services/ai-visibility/",
      "description": "Analyze a business website's service descriptions and presentation in AI search, with recommendations for specific pages.",
      "provider": {
        "@id": "https://example.com/#organization"
      }
    }
  ]
}
</script>

Here, mainEntity points to the service that is the page's main subject, and provider points to the service provider. publisher identifies the company publishing the page. The three nodes have their own types and identifiers; using the same URL for the webpage and the service does not make them the same object. Schema.org mainEntity, publisher and Service

The fragments #organization, #webpage and #service are identifier naming choices for this example. You do not need to create a new webpage for each fragment. Keep the company identifier consistent across pages describing the same company. Each webpage has its own page identifier, while a service identifier follows the identity of the actual service. Avoid making every service page refer to one generic Service node.

Generate the company name, service text and JSON-LD from the same business data where possible. For instance, an updated service description should update both the visible content and description. This reduces the chance of an old template field remaining after an editor has changed the page.

Add fields supported by verified information

Once the basic relationships are stable, decide whether additional fields are useful.

The definition of sameAs concerns entity identity. A news article merely mentioning a company, or a page belonging to a business partner, cannot be treated as an identity reference solely because it links to the company. Check an actual official profile or corresponding knowledge-base entry individually. Omit the field when no suitable reference can be confirmed. Schema.org's sameAs definition

areaServed accepts geographic objects such as places and administrative areas, as well as text. Use the service's real geographic coverage. Having a Chinese-language page does not automatically mean the service covers all of China; verify coverage from the business facts. Schema.org's areaServed definition

More fields do not automatically improve the implementation. For a business service page, get the provider and service description right first, then add verified geographic and identity information. That produces a structure the team can maintain.

Check syntax, consistency and search display separately

During development, paste the complete example into the Schema.org Validator to check the types and fields. After placing it on a test page, validate the URL as well to confirm that the page actually outputs the expected JSON-LD. Checking a code sample in an editor alone does not verify the deployed page.

Open the visible page content and compare the names, service description and geographic coverage field by field. Check whether CMS plugins, the theme and custom code all output structured data. If they use different names or outdated contact details for the same company, unify the data source and check again.

Google's Rich Results Test checks the rich results Google supports. Schema.org has a broader vocabulary. Correct vocabulary use, Google's support for a display feature, and that feature actually appearing in search results must therefore be verified separately. A basic Service node does not establish that Google will display a service card. Google's structured data introduction and supported scope

For GEO, keep records of actual AI answers too. Google explicitly states that AI Overviews and AI Mode do not require special Schema.org markup. Accept this technical change by verifying that the company-to-service relationship is output correctly and matches the visible content; observe citation changes in subsequent real answers. Google's technical requirements for AI features

When adding another service page, reuse the company identifier, create the relevant service node, and check the page's main subject. Update the structured fields when the business team changes the offering. Include this work in routine publishing checks so that visible text and machine-readable information continue to describe the same service.

For the visible service description itself, the B2B service page guide explains how to answer customers' business questions on the page.

Key references

• W3C JSON-LD 1.1 standard
• Schema.org Service type
• Google's general structured data guidelines

Sources checked on October 8, 2026.