Service/Product Pages

Service and product pages on most websites exist to convert visitors. They describe features, list benefits, show pricing, and include calls to action. From an entity perspective, they should do something more fundamental: they should explicitly declare that this entity provides this offering. Without that declaration, Google has to infer the connection between your organization and the services you provide. Inference works sometimes. Explicit declaration works every time.

The key mechanism is the provider property in Schema.org. When you declare a Service with a provider that references your Organization's @id, you create an explicit, machine-readable link between the offering and the entity. This is how Google learns not just that a service exists, but who provides it.

Entity-Offering Connections

Every service or product page should answer two questions for Google: "What is this offering?" and "Who provides it?" The first question is answered by the page content and the Service or Product schema. The second question is answered by the provider (for services) or manufacturer/brand (for products) property.

The diagram shows how an Organization entity connects to multiple services. Each connection is made through the provider property. The services then contribute topical associations (through serviceType) and geographic scope (through areaServed) back to the entity's profile in the Knowledge Graph.

Service Schema Example

Here is a practical Service schema for a service page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Search Engine Optimization",
  "description": "Technical and strategic SEO services for B2B companies targeting enterprise clients.",
  "provider": {
    "@type": "Organization",
    "@id": "https://example.com/#organization"
  },
  "serviceType": "SEO",
  "areaServed": {
    "@type": "Country",
    "name": "United States"
  },
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "SEO Service Tiers",
    "itemListElement": [
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "SEO Audit",
          "description": "Comprehensive technical and on-page SEO audit."
        }
      }
    ]
  }
}
</script>

The critical line is the provider property with the @id reference. This tells Google: "The entity described at /#organization provides this service." If your homepage and about page use the same @id, Google connects all three pages to the same entity.

Page Optimization Checklist

Product Pages: The Brand and Manufacturer Properties

For product pages, the equivalent of provider is brand or manufacturer. These properties tell Google which entity is behind the product. If you sell your own products, the brand should reference your Organization. If you resell products from other manufacturers, the brand should reference the original manufacturer, and your Organization should appear as the seller.

This distinction matters for entity clarity. If you mark your organization as the brand of products you do not manufacture, you create a false entity association. Google may initially accept it, but as conflicting signals accumulate from the actual manufacturer's presence, the false association erodes trust in your entity data.

One Service Per Page

A common mistake is listing all services on a single page. This is convenient for visitors but terrible for entity-offering associations. When five services share a single page, the schema must either declare five separate Service types on one URL (messy and harder for Google to parse) or pick one as the primary service (leaving four without explicit declaration).

The better approach: create a dedicated page for each core service or product. Each page gets its own Service schema with a clean provider link. The services overview page then links to each individual service page, creating a hierarchy that Google can crawl and understand without ambiguity.

This does not mean you need 50 service pages. Group related sub-services under one page. But if two services are fundamentally different (web development and accounting, for example), they deserve separate pages with separate schemas.

Further Reading

• Schema.org: Service Type
• Schema.org: Product Type
• Google: Product Structured Data
• Schema App: Schema Markup for Service Pages