LocalBusiness and Service schema template

When one business page describes one service

Copy this starter, then replace or remove every bracketed value.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "[most specific LocalBusiness subtype]",
      "name": "[exact business name as shown on the page]",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "[street address]",
        "addressLocality": "[city]",
        "addressRegion": "[state or region]",
        "postalCode": "[postal code]",
        "addressCountry": "[country]"
      },
      "url": "[fully qualified URL for this location]",
      "telephone": "[primary public telephone number]",
      "geo": {
        "@type": "GeoCoordinates",
        "latitude": "[latitude]",
        "longitude": "[longitude]"
      },
      "openingHoursSpecification": [
        {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": ["[day]"],
          "opens": "[hh:mm:ss]",
          "closes": "[hh:mm:ss]"
        }
      ]
    },
    {
      "@type": "Service",
      "name": "[service name as shown on the page]",
      "serviceType": "[type of service]",
      "provider": {
        "@type": "LocalBusiness",
        "name": "[exact business name as shown on the page]"
      },
      "areaServed": {
        "@type": "AdministrativeArea",
        "name": "[service area, if the page states one]"
      },
      "description": "[visible service description]"
    }
  ]
}

This shape keeps the business identity separate from the service it provides. Keep name and address for the Google LocalBusiness boundary, and use the Service fields only when the page supports them.^1,3

Omit an optional property instead of publishing a bracketed value. For example, remove areaServed when the page does not state a service area, and remove telephone when the page does not show a public phone number.^3,4

When one page describes several services

Use one Service object per separately named offering.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "[most specific LocalBusiness subtype]",
      "name": "[exact business name as shown on the page]",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "[street address]",
        "addressLocality": "[city]",
        "addressRegion": "[state or region]",
        "postalCode": "[postal code]",
        "addressCountry": "[country]"
      }
    },
    {
      "@type": "Service",
      "name": "[first service name as shown on the page]",
      "serviceType": "[first service type]",
      "provider": {
        "@type": "LocalBusiness",
        "name": "[exact business name as shown on the page]"
      },
      "description": "[visible description of the first service]"
    },
    {
      "@type": "Service",
      "name": "[second service name as shown on the page]",
      "serviceType": "[second service type]",
      "provider": {
        "@type": "LocalBusiness",
        "name": "[exact business name as shown on the page]"
      },
      "description": "[visible description of the second service]"
    }
  ]
}

The separate nodes make each offering explicit without turning the business node into a list of invented services. Add another complete Service object only when the page names and describes that service. Schema.org defines provider, serviceType, description, and areaServed as relationships or properties for a service, but these are not additional Google LocalBusiness rich-result requirements.^1,3

When the page shows a service catalog

Use this shape when the page visibly presents a named catalog or grouped list of services.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "[most specific LocalBusiness subtype]",
      "name": "[exact business name as shown on the page]",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "[street address]",
        "addressLocality": "[city]",
        "addressRegion": "[state or region]",
        "postalCode": "[postal code]",
        "addressCountry": "[country]"
      }
    },
    {
      "@type": "Service",
      "name": "[service group or catalog name shown on the page]",
      "provider": {
        "@type": "LocalBusiness",
        "name": "[exact business name as shown on the page]"
      },
      "hasOfferCatalog": {
        "@type": "OfferCatalog",
        "name": "[visible catalog name]",
        "itemListElement": [
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "[first service name]",
              "serviceType": "[first service type]",
              "description": "[visible first-service description]"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "[second service name]",
              "serviceType": "[second service type]",
              "description": "[visible second-service description]"
            }
          }
        ]
      }
    }
  ]
}

Use hasOfferCatalog only when the page actually presents a catalog or grouped list. Schema.org's example uses an OfferCatalog with offered Service items, but its example names and location are illustrative. Replace every entity and description with facts the page shows.³

Which fields are required for Google, and which are conditional?

Google's LocalBusiness rich-result table has a narrow required boundary. Recommended properties can add information, but they do not become required just because they appear in a starter.

LocalBusiness identity fields

Service offering fields

The LocalBusiness rows come from Google's feature guidance. The Service rows come from Schema.org's public vocabulary. Keep those authorities separate when you explain the markup to a client or teammate.^1,3

How do I replace the placeholders without inventing facts?

Replace every bracketed value with a fact that is visible and true on the page, or remove the optional property. Do not leave a placeholder in production markup.

1. Choose the most specific applicable LocalBusiness subtype. Use an array only when multiple types genuinely apply.¹
2. Copy the business name exactly as the page presents it.^1,4
3. Use the physical location represented by the page in address. Complete the PostalAddress fields the page supports truthfully.^1,4
4. Add url, telephone, geo, hours, price range, department, menu, cuisine, or review properties only when each one applies to the page.^1,4
5. Add one Service node for each service the page names. Keep description and areaServed aligned with visible text.^3,4
6. Remove review and aggregateRating unless the page captures reviews about other local businesses and meets Google's review-snippet rules.¹

For a broader explanation of the LocalBusiness boundary, see Does LocalBusiness schema help local ranking?. Keep the business facts on the same page as the markup, and keep the Google Business Profile aligned with the facts the business publishes elsewhere.

How do I make sure the markup matches the visible page?

Structured data must describe the page readers can see. Google says not to mark up content that is hidden from readers, misleading, fake, or unrelated to the page focus.⁴

• Put the markup on the page that describes the business location and its services.
• Use the same business name, service names, descriptions, hours, address, and service area in the visible copy and the JSON-LD.
• Do not add a service only because it exists in an internal list or in a template example.
• Do not add fake reviews, ratings, or a service area that the page does not state.
• Make the page and its resources accessible to anonymous users. Check robots.txt, noindex, login requirements, and other access controls before requesting a crawl.^1,4

What should I validate before publishing?

1. Confirm that the JSON-LD uses the most specific applicable types and properties and describes visible page content.^1,4
2. Run the public page URL through Google's Rich Results Test. For an unpublished snippet, choose Code and paste the JSON-LD. The tool also accepts a public URL when the page resources are anonymously accessible.⁵
3. Fix critical errors. Review warnings and suggestions, but do not call a suggestion a Google eligibility requirement unless Google's source does.^1,5
4. Deploy a small number of representative pages. Use Search Console's URL Inspection to confirm how Google sees each page.¹
5. Confirm the inspected page is not blocked by robots.txt, noindex, login requirements, or another access-control method. Request recrawling when the page is ready.^1,4
6. Submit or maintain a sitemap so Google can learn about future changes.¹
7. Recheck the rendered page and structured data after material edits. A passing test does not guarantee that a rich result will appear.^1,4

What should I not do with this template?

FAQ

This starter separates the Google LocalBusiness identity boundary from Schema.org's service relationships. Use the smallest truthful set of properties, then validate the public page and the code together.

Is Service required for Google's LocalBusiness rich result?

No. Google's LocalBusiness guidance lists name and address as the required properties for that rich-result feature. Service is a separate Schema.org type for describing a service provided by an organization. Add it when the page visibly describes the offering, not to satisfy a LocalBusiness requirement.^1,3

Do I need every recommended LocalBusiness property?

No. Add a recommended property only when it applies and the page supports it. A restaurant may have menu and servesCuisine; another business may need only the required identity fields plus applicable contact, URL, hours, or location details.¹

Can I use additionalType for several business types?

Google's LocalBusiness guidance says to use an array when multiple types apply and says additionalType is not supported in that guidance. Choose the most specific applicable subtype, then use an array only when the business genuinely has multiple applicable types.¹

Does a passing Rich Results Test guarantee a rich result?

No. Google says structured data can make a feature eligible, but it does not guarantee that the feature will appear. A passing test is an implementation check, not a promise of a display outcome.⁴