Service Schema for AI Search

TL;DR

Mark up service pages with JSON-LD @type: Service (or its subtypes ProfessionalService, FinancialService). Always include name, description, serviceType, provider (linked to your Organization schema by @id), and areaServed. Add offers for pricing and aggregateRating if you have third-party reviews. Validate with the Schema.org Validator and Google Rich Results Test. Do not expect a rich result — the value is in AI citation grounding, not SERP visuals.

Definition

Service is a Schema.org type representing "a service provided by an organization, e.g., delivery service, print services, etc." It sits under Intangible in the type hierarchy, with subtypes including BroadcastService, CableOrSatelliteService, FinancialService, FoodService, GovernmentService, TaxiService, and WebAPI. For B2B and professional services, the more specific subtype is ProfessionalService, which inherits from both Service and LocalBusiness.

All Service properties are technically optional from Google's perspective — there is no rich result for Service, so Google does not enforce a required-property checklist. AI search engines use the schema as an entity-grounding signal, which is more about clarity and completeness than meeting a required floor.

Why Service schema matters for AI search

AI search engines treat Service schema as a high-trust source of structured facts about an offering. Three concrete benefits:

1. Entity disambiguation. AI models use provider.@id to link a Service back to your canonical Organization entity, reducing the chance of mixing your service with a competitor's.
2. Geography matching. areaServed lets AI engines match "plumber near me" or "law firm in Boston" to your service when the user query includes location intent. Without it, the AI must infer geography from address, which is unreliable.
3. Service-type taxonomy. serviceType is a free-text field that lets you anchor your offering to industry vocabulary. AI models normalize this against their training data to match service queries.

Note: Schema markup is not a guaranteed AI citation lever. Recent OtterlyAI testing showed schema changes alone did not measurably move citation rates across most AI platforms. Treat Service schema as one component of an entity-clarity strategy, not a silver bullet.

Required and recommended properties

Because no Google rich result enforces required properties, the table below combines the Schema.org definition with practitioner recommendations for AI search.

Canonical example: B2B agency

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example.com/services/geo-consulting#service",
  "name": "Generative Engine Optimization (GEO) Consulting",
  "description": "End-to-end GEO consulting: technical infrastructure (llms.txt, schema, sitemaps), content rewriting for AI citation, and reporting on AI search visibility across ChatGPT, Claude, and Perplexity.",
  "serviceType": "Generative Engine Optimization",
  "category": "AI Search Marketing",
  "url": "https://example.com/services/geo-consulting",
  "image": "https://example.com/images/geo-consulting.jpg",
  "provider": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example GEO Agency",
    "url": "https://example.com",
    "logo": "https://example.com/logo.png"
  },
  "areaServed": [
    {
      "@type": "AdministrativeArea",
      "name": "United States"
    },
    {
      "@type": "AdministrativeArea",
      "name": "Canada"
    }
  ],
  "audience": {
    "@type": "Audience",
    "audienceType": "B2B SaaS marketing teams"
  },
  "offers": {
    "@type": "Offer",
    "price": "15000",
    "priceCurrency": "USD",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "price": "15000",
      "priceCurrency": "USD",
      "unitText": "per engagement"
    },
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "42"
  }
}
</script>

Canonical example: local professional service with radius

Use ProfessionalService (subtype of both Service and LocalBusiness) when the service is delivered from a physical location with hours.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "@id": "https://example.com/services/tax-preparation#service",
  "name": "Tax Preparation Services",
  "description": "Personal and small-business tax preparation by licensed CPAs in Boston metro.",
  "serviceType": "Tax preparation",
  "url": "https://example.com/services/tax-preparation",
  "provider": {
    "@type": "AccountingService",
    "@id": "https://example.com/#localbusiness",
    "name": "Example CPA Group",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "123 Main St",
      "addressLocality": "Boston",
      "addressRegion": "MA",
      "postalCode": "02108",
      "addressCountry": "US"
    },
    "telephone": "+1-617-555-0100"
  },
  "areaServed": {
    "@type": "GeoShape",
    "@id": "https://example.com/areas/boston-metro",
    "name": "Boston metropolitan area, 25-mile radius",
    "geoMidpoint": {
      "@type": "GeoCoordinates",
      "latitude": 42.3601,
      "longitude": -71.0589
    },
    "geoRadius": "40000"
  },
  "hoursAvailable": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "09:00",
    "closes": "18:00"
  }
}
</script>

Entity linking via @id

The single highest-leverage technique with Service schema is to give every entity a stable @id URL and reuse those IDs across pages. AI models follow @id references to build a graph of related entities, which improves disambiguation.

Pattern:

• Organization lives at https://example.com/#organization.
• Each Service references the Organization by @id, not by inlining a full Organization block.
• Cross-page references use the same @id URL throughout the site.

Incorrect (no @id linkage):

{
  "@type": "Service",
  "provider": {
    "@type": "Organization",
    "name": "Example Agency"
  }
}

Correct (linked by @id):

{
  "@type": "Service",
  "provider": { "@id": "https://example.com/#organization" }
}

This works because the Organization block elsewhere on the same site (e.g., in the homepage ) defines the Organization fully. The Service references it without redefining.

areaServed: text vs AdministrativeArea vs GeoShape

Three levels of precision:

1. Text ("United States"): Coarse, easy. Use when the service is national or the geography is loose.
2. AdministrativeArea ({ "@type": "AdministrativeArea", "name": "California" }): Medium precision. Better than text because the type is unambiguous.
3. GeoShape with geoRadius: Highest precision. Use for delivery zones, service radii, or polygon coverage.

For B2B services delivered remotely, Text is sufficient. For local services with travel limits, GeoShape is best. AI engines use the most specific type available.

Multiple services on one page

If one page lists several services (e.g., a service catalog), use an array of Service objects, each with its own @id:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Service",
      "@id": "https://example.com/services/seo#service",
      "name": "SEO Audit",
      "serviceType": "SEO consulting"
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/geo#service",
      "name": "GEO Audit",
      "serviceType": "GEO consulting"
    }
  ]
}

For SaaS products, prefer SoftwareApplication over Service — the type is a better fit and Google does produce SoftwareApplication-related rich results.

Validation pipeline

1. Schema.org Validator (https://validator.schema.org/): Confirms syntax and type correctness.
2. Google Rich Results Test (https://search.google.com/test/rich-results): Detects valid items. Note: Service alone does not produce a rich result; the test will report Service entities but mark them as ineligible for rich results.
3. Manual JSON-LD review: Confirm @id URLs resolve, provider matches your Organization schema, and areaServed is appropriately scoped.
4. Search Console: After deploying, check Enhancements > Structured Data. Service entities will not appear under Rich Results, but errors and warnings still surface.
5. AI search smoke test: Ask each major AI engine (ChatGPT, Claude, Perplexity) a service-intent query that should match your offering. Track citation behavior over 30-60 days.

Common mistakes

• Using Product for a service. Google's Product rich result has strict requirements that do not fit services. Use Service instead.
• Defining the Organization inline in every Service. Wastes bytes and confuses entity graph linking. Use @id references.
• Setting areaServed to "Worldwide". Better to omit it than to set a vague global value. AI engines drop "Worldwide" as low-signal.
• Adding aggregateRating without third-party reviews. Google penalizes self-reported ratings. Only add aggregateRating if you can point to a third-party review platform.
• Listing every service in a single Service object via serviceType. serviceType is a single label, not a list. Use multiple Service objects in a @graph.
• Forgetting provider. Without it, AI engines cannot link the Service to your Organization, which weakens entity grounding.
• Using Service for SaaS subscriptions. Use SoftwareApplication instead; it is more specific and supported by Google's product rich result.

How to apply

1. List every service-page URL on the site.
2. For each, draft a JSON-LD @type: Service block with name, description, serviceType, provider, areaServed, url.
3. Add @id URLs to enable cross-page entity linking.
4. Add offers if pricing is public; otherwise omit.
5. Validate each with Schema.org Validator + Google Rich Results Test.
6. Deploy in the page (preferred) or just before the closing tag.
7. Monitor AI search citation patterns over 30-60 days; do not expect immediate movement.

FAQ

Q: Does Service schema produce a Google rich result?

No. There is no dedicated rich result for Service. The Schema App documentation explicitly notes that Service has no required properties because Google does not enforce a rich-result requirement set.

Q: Should I use Service or LocalBusiness?

Use LocalBusiness (or one of its subtypes) for the business itself. Use Service (or ProfessionalService) for an offering provided by that business. Link them via provider.

Q: Should I use Service for SaaS products?

No. Use SoftwareApplication, which has Google rich-result support and is a better semantic fit for downloadable or web-based software.

Q: How granular should serviceType be?

Use the wording your audience would type into a search engine. "Tax preparation" is better than "Accounting services". "Generative Engine Optimization" is better than "Marketing".

Q: Can I have multiple Service objects on one page?

Yes. Use an array under @graph, each with its own @id. This is preferred over a single Service with multiple serviceTypes.

Q: Will adding Service schema increase AI citations?

It can help by clarifying entities and geography, but it is not a guaranteed lever. OtterlyAI's experiments showed schema alone did not measurably move citation rates. Treat Service schema as part of a broader entity-clarity strategy.

: Schema.org, "Service" type — verified 2026-05-03 — supports canonical type definition. https://schema.org/Service

: Schema.org, "ProfessionalService" type — verified 2026-05-03 — supports dual-inheritance from Service and LocalBusiness. https://schema.org/ProfessionalService

: Schema.org, "serviceType" property — verified 2026-05-03 — supports free-text taxonomy use. https://schema.org/serviceType

: Schema App, "How to Create Service Schema Markup for Businesses" — verified 2026-05-03 — supports no-required-property nature for Google rich results. https://www.schemaapp.com/schema-markup/services-schema-markup-schema-org-services/

: SALT.agency, "A beginner's guide to JSON-LD Schema for SEOs" — verified 2026-05-03 — supports entity-first SEO and @id linking patterns. https://salt.agency/blog/json-ld-structured-data-beginners-guide-for-seos/

: WPRiders, "Schema Markup: 8 Tactics to Boost AI Citations" — verified 2026-05-03 — supports areaServed/provider/serviceOutput descriptions. https://wpriders.com/schema-markup-for-ai-search-types-that-get-you-cited/

: OtterlyAI, "Schema Markup's Real Impact on AI Search" — verified 2026-05-03 — supports schema-not-direct-AI-signal caveat. https://otterly.ai/blog/schema-markup-real-impact-ai-search/

: dBeta, "Schema.org for Businesses: A Practical Implementation Guide" — verified 2026-05-03 — supports clarity-over-volume framing. https://www.dbeta.co.uk/blog/schema-org-for-businesses-practical-implementation-guide.html

: Stack Overflow, "Is there a Schema.org type for SaaS or subscriptions?" — verified 2026-05-03 — supports SoftwareApplication preference over Service for SaaS. https://stackoverflow.com/questions/30596242/is-there-a-schema-org-type-for-saas-or-subscriptions

: Reddit r/TechSEO, "JSON-LD Service rich-results test" — verified 2026-05-03 — supports observation that Rich Results Test detects but does not enable rich results for Service. https://www.reddit.com/r/TechSEO/comments/1m665u4/im_trying_to_implement_a_jsonld_schema_for_each/