Schema playbook (Org/LocalBusiness/Service/FAQ)

If you’re hoping schema will magically “rank you in AI,” you’ll be disappointed. If you want machines to stop guessing who you are, what you do, and where you do it, you’ll love it.

This playbook is built for service businesses: agencies, professional services, multi-location brands, and B2B companies selling expertise.

What schema does (and doesn’t do)

• Schema helps machines interpret and connect information (entities, services, locations).
• Schema can make pages eligible for certain Google search features (rich results), but it’s not guaranteed.
• Schema must match the user-visible content on the page. If it doesn’t, you’re feeding machines lies.

The 4 schemas that matter most for service businesses

Before you write schema: the 3 rules that prevent 80% of problems

Rule 1: Use stable entity IDs (@id) and reuse them everywhere

If your Organization schema is an island, machines treat it like a rumor. Give it an @id and reuse that @id in every Service and LocalBusiness block so your site becomes a connected graph.

Example entity IDs:
Organization: https://example.com/#org
Location:      https://example.com/locations/new-york/#localbusiness
Service:       https://example.com/services/seo-for-ai/#service

Rule 2: Schema must reflect visible content

Google’s structured data policies are clear: structured data should represent the content that users can see on the page. Don’t mark up invisible content.

Rule 3: Don’t block the pages you’re marking up

If the page can’t be crawled, the structured data can’t be processed. Keep important pages crawlable and indexable.

Organization schema (the brand anchor)

Use Organization schema on your homepage. It’s your entity root. Google’s documentation notes that adding a logo property can help it understand which logo to show (including in knowledge panels).

Recommended Organization properties (minimum viable)

• name (exact legal or brand name)
• url (canonical homepage URL)
• logo (representative logo URL)
• sameAs (official identity profiles, not random social links)
• contactPoint (sales/support contact info)
• @id (stable entity ID used across schema)

Organization JSON-LD template

<script type=”application/ld+json”>
{
  “@context”: “https://schema.org”,
  “@type”: “Organization”,
  “@id”: “https://example.com/#org”,
  “name”: “Example Company”,
  “url”: “https://example.com/”,
  “logo”: “https://example.com/assets/logo.png”,
  “sameAs”: [
    “https://www.linkedin.com/company/example”,
    “https://www.youtube.com/@example”
  ],
  “contactPoint”: [{
    “@type”: “ContactPoint”,
    “contactType”: “sales”,
    “email”: “[email protected]”,
    “telephone”: “+1-555-555-5555”
  }]
}
</script>

Implementation notes:

• Keep the url and @id stable. Don’t point @id at staging domains.
• Use sameAs only for official profiles you control or authoritative references.
• Don’t invent data. If it’s not true, it shouldn’t be in your schema.

LocalBusiness schema (the location anchor)

If you have real locations, each one should have its own page and its own LocalBusiness entity. Google notes that Local Business structured data can tell Google about business hours and more, and that search results may display a knowledge panel for matched businesses.

Recommended LocalBusiness properties (minimum viable)

• name (include location identifier if needed)
• address (PostalAddress with street/city/region/postal code/country)
• telephone
• openingHoursSpecification (when relevant)
• url (canonical location page)
• @id (stable per-location ID)

LocalBusiness JSON-LD template

<script type=”application/ld+json”>
{
  “@context”: “https://schema.org”,
  “@type”: “LocalBusiness”,
  “@id”: “https://example.com/locations/new-york/#localbusiness”,
  “name”: “Example Company – New York”,
  “url”: “https://example.com/locations/new-york/”,
  “telephone”: “+1-212-555-0101”,
  “address”: {
    “@type”: “PostalAddress”,
    “streetAddress”: “32 East 57th Street, 8th Floor”,
    “addressLocality”: “New York”,
    “addressRegion”: “NY”,
    “postalCode”: “10022”,
    “addressCountry”: “US”
  },
  “openingHoursSpecification”: [{
    “@type”: “OpeningHoursSpecification”,
    “dayOfWeek”: [“Monday”,”Tuesday”,”Wednesday”,”Thursday”,”Friday”],
    “opens”: “09:00”,
    “closes”: “17:00”
  }]
}
</script>

Implementation notes:

• If you’re a professional services firm, consider using a more specific subtype (like ProfessionalService) when appropriate, but keep the basics consistent.
• Match NAP (name/address/phone) to what you show on the page and across the web.
• If you do not have a real location customers can reach, don’t fake one.

Service schema (the offering anchor)

Service schema is how you tell machines: “This page describes a service, and here’s who provides it.”

Schema.org defines Service as a service provided by an organization, and the provider property describes the service provider.

Recommended Service properties (minimum viable)

• name (human-readable service name)
• serviceType (short description of the service category)
• provider (reference your Organization @id)
• areaServed (optional but useful)
• url (canonical service page URL)
• @id (stable per-service ID)

Service JSON-LD template

<script type=”application/ld+json”>
{
  “@context”: “https://schema.org”,
  “@type”: “Service”,
  “@id”: “https://example.com/services/seo-for-ai/#service”,
  “name”: “SEO for AI Services (GEO)”,
  “serviceType”: “Technical SEO + AI visibility optimization”,
  “provider”: { “@type”: “Organization”, “@id”: “https://example.com/#org” },
  “areaServed”: [“United States”, “Canada”],
  “url”: “https://example.com/services/seo-for-ai/”
}
</script>

Implementation notes:

• The provider should reference your Organization @id (not duplicate the org object everywhere).
• Keep service names consistent across your navigation, page title, and schema.
• If you have multiple locations providing the same service, consider connecting via provider as LocalBusiness for location pages and Organization for the general service.

FAQPage schema (the Q&A anchor)

FAQ schema used to be a SERP real-estate cheat code. It isn’t anymore. Google now limits FAQ rich results primarily to well-known, authoritative government and health sites.

So why still use FAQPage schema? Because AI readability is not the same as SERP bling.

• It expresses question-answer pairs in a predictable machine-readable format.
• It reduces ambiguity about scope, deliverables, and process.
• It helps your page stand on its own when summarized.

FAQPage JSON-LD template (only if Q&A is visible)

<script type=”application/ld+json”>
{
  “@context”: “https://schema.org”,
  “@type”: “FAQPage”,
  “@id”: “https://example.com/services/seo-for-ai/#faq”,
  “mainEntity”: [
    {
      “@type”: “Question”,
      “name”: “Does schema affect AI answers?”,
      “acceptedAnswer”: {
        “@type”: “Answer”,
        “text”: “Schema helps machines interpret and attribute your content, but it doesn’t guarantee visibility. It reduces ambiguity.”
      }
    }
  ]
}
</script>

Important: Don’t mark up invisible Q&A. If the question and answer aren’t on the page for users, don’t include them in the schema.

Validation workflow (ship it like code, not like a blog edit)

Step 1: Syntax validation

• Use the Schema Markup Validator to check schema correctness (especially for types not tied to a rich result).
• Use Google’s Rich Results Test to check parsing and eligibility for supported features.

Step 2: Policy validation

Google’s structured data policies exist for a reason. If you misuse schema, you can lose eligibility for rich results. Treat policy as a release requirement.

Step 3: Template consistency

• Ensure schema appears on both desktop and mobile versions (mobile-first indexing).
• Make sure the URLs inside schema are correct for the version being crawled.
• Reuse @id values consistently across templates.

The five schema mistakes that cause the most chaos

• Multiple Organization schemas with different names/logos across the site.
• Using different @id values for the same entity on different pages.
• Marking up content that doesn’t exist on the page (especially FAQs).
• Location pages missing address details in schema or using inconsistent phone numbers.
• Schema present on desktop templates but missing on mobile templates.

Implementation checklist (copy/paste into a ticket)

• Create Organization schema on the homepage with stable @id and canonical url.
• Create LocalBusiness schema for each location page (stable @id, full address, phone, hours).
• Create Service schema for each service page (stable @id, provider references Organization @id).
• Add FAQPage schema only where Q&A is visible on-page.
• Validate with Rich Results Test and Schema Markup Validator.
• Confirm mobile parity for content and schema.
• Add canonical URLs to sitemaps and standardize internal links.

Next Module: Crawl and Index Readiness Checklist

Sources

[1] Google Search Central. General Structured Data Guidelines. Accessed January 11, 2026.

[2] Google Search Central. Introduction to structured data markup in Google Search. Accessed January 11, 2026.

[3] Google Search Central. Organization structured data. Accessed January 11, 2026.

[4] Google Search Central. Local Business structured data. Accessed January 11, 2026.

[5] Google Search Central. FAQPage structured data. Accessed January 11, 2026.

[6] Google Search Central Blog. Changes to HowTo and FAQ rich results (Aug 2023). Accessed January 11, 2026.

[7] Google Search Central. Mobile-first indexing best practices. Accessed January 11, 2026.

[8] Schema.org. Service (Type). Accessed January 11, 2026.

[9] Schema.org. provider (Property). Accessed January 11, 2026.

[10] Google. Rich Results Test. Accessed January 11, 2026.

[11] Schema.org. Schema Markup Validator. Accessed January 11, 2026.

About The Author

Dave Burnett

I help people make more money online.

Over the years I’ve had lots of fun working with thousands of brands and helping them distribute millions of promotional products and implement multinational rewards and incentive programs.

Now I’m helping great marketers turn their products and services into sustainable online businesses.

How can I help you?

See author's posts