Product and Service Schema

Your entity is defined not only by who you are and where you are, but by what you do. Product and Service schema tell Google exactly what your business offers, who provides it, and under what terms. This creates a direct connection between your entity and the commercial intent queries that drive revenue.

For entity authority specifically, Product and Service schema do something else: they establish that your entity is a provider of real things. An entity that offers products and services is more commercially relevant than one that merely exists as a name with an address.

Product vs. Service: Which to Use

Many businesses offer both. A software company sells a Product (the software) and provides a Service (implementation consulting). Each gets its own schema block on the appropriate page.

Product Schema Example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "IndustrialControl Pro",
  "description": "Programmable logic controller software for manufacturing automation, supporting IEC 61131-3 standards.",
  "image": "https://www.example.com/images/product-icp.png",
  "brand": {
    "@type": "Organization",
    "@id": "https://www.example.com/#organization",
    "name": "Example Industries"
  },
  "sku": "ICP-2024",
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.com/products/industrial-control-pro/",
    "priceCurrency": "USD",
    "price": "2400.00",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "seller": {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "89"
  }
}
</script>

Service Schema Example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Industrial Automation Consulting",
  "description": "End-to-end automation system design, implementation, and optimization for manufacturing facilities.",
  "serviceType": "Automation Consulting",
  "provider": {
    "@type": "Organization",
    "@id": "https://www.example.com/#organization",
    "name": "Example Industries"
  },
  "areaServed": {
    "@type": "Country",
    "name": "Indonesia"
  },
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "Consulting Packages",
    "itemListElement": [
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "Baseline Assessment",
          "description": "Facility audit and automation readiness evaluation"
        }
      },
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "Full Implementation",
          "description": "Complete automation system design and deployment"
        }
      }
    ]
  }
}
</script>

The Provider Link

The provider property on Service schema (and brand/seller on Product schema) is the critical connection. It links what you sell back to who you are. Without this link, your Product or Service floats as an isolated object with no entity connection.

Always use the @id pattern to reference your Organization. This tells Google: "the provider of this service is the same entity described in our Organization schema." It is one more strand in the web of connected structured data that builds entity confidence.

Where to Place Product and Service Schema

Product schema belongs on the product page, not the homepage. Each product page should have its own Product schema block describing that specific product. If you have a catalog page listing multiple products, each product can have its own schema, or you can use an ItemList that references individual product pages.

Service schema follows the same logic. Put it on the page that describes the service. If you have a single "Services" page listing everything, include schema for each service. If each service has its own page, each page gets its own Service schema.

Do not put Product or Service schema on the homepage. The homepage should have Organization and WebSite schema. Product and Service schema live on their dedicated pages, each linking back to the Organization via @id.

Multiple Products and the ItemList Pattern

For businesses with many products, the ItemList type organizes them on a catalog page:

{
  "@type": "ItemList",
  "name": "Our Products",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "url": "https://www.example.com/products/product-a/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "url": "https://www.example.com/products/product-b/"
    }
  ]
}

Each URL in the list points to a product page that has its own complete Product schema. The ItemList tells Google about the relationship between the catalog and its members.

Important Properties for Products

• offers: Required for rich results. Must include price, currency, and availability.
• aggregateRating: Only include if you genuinely have reviews. Fabricating ratings violates Google's policies.
• brand: Links the product to your Organization entity.
• sku or gtin: Unique identifiers help Google disambiguate products.
• image: Product images eligible for image search results.

Important Properties for Services

• provider: The organization or person that provides the service.
• serviceType: A short classification of the service.
• areaServed: Geographic coverage. Can be Country, State, City, or GeoShape.
• hasOfferCatalog: For businesses with multiple service tiers or packages.

Further Reading

• Schema.org: Product Type Reference
• Schema.org: Service Type Reference
• Google: Product Structured Data
• Schema.org: Offer Type Reference