Schema markup that AI engines actually use: LocalBusiness, FAQPage, Product, Service

Structured data has a reputation problem. For years it was sold as a way to win rich snippets, Google kept trimming which snippets it showed, and many sites concluded it was not worth the effort. That conclusion is wrong for AI search, for a simple reason: a language model that reads your page has to work out what kind of thing you are, and JSON-LD tells it in a form that cannot be misread.

This post covers the four types that do the most work for businesses, with examples. It does not cover the long tail; BreadcrumbList and Article are fine to add, but they are not where the ambiguity lives.

How AI systems use structured data

Be precise about what is claimed. No major assistant has published a statement that JSON-LD is an input to its answer ranking. What is well established is:

• Google's index, which feeds AI Overviews, AI Mode and Gemini's grounding, parses structured data and uses it to build entity records.
• Retrieval systems extract clean facts (name, address, price, availability) from JSON-LD more reliably than from prose, because there is nothing to interpret.
• Where a page's prose and its structured data disagree, the disagreement itself is a trust problem.

So the goal is not a rich snippet. It is to make the facts about you machine-legible and identical to the facts everywhere else.

1. LocalBusiness (and its subtypes)

Use the most specific subtype schema.org offers: Dentist, Plumber, Electrician, LegalService, AccountingService, Restaurant, HVACBusiness. Fall back to LocalBusiness when nothing fits. Place it on the homepage (and on location pages for multi-site businesses, one per location).

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.example-dental.co.uk/#business",
  "name": "Example Dental Practice",
  "url": "https://www.example-dental.co.uk/",
  "telephone": "+441603123456",
  "email": "[email protected]",
  "image": "https://www.example-dental.co.uk/images/practice.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "4 Market Place",
    "addressLocality": "Norwich",
    "addressRegion": "Norfolk",
    "postalCode": "NR2 1AB",
    "addressCountry": "GB"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": 52.6286, "longitude": 1.2928 },
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday"], "opens": "08:30", "closes": "17:30" },
    { "@type": "OpeningHoursSpecification", "dayOfWeek": "Friday", "opens": "08:30", "closes": "13:00" }
  ],
  "priceRange": "££",
  "areaServed": ["Norwich", "Norfolk"],
  "sameAs": [
    "https://www.facebook.com/exampledental",
    "https://www.google.com/maps?cid=0000000000000000000"
  ]
}

Rules that matter:

• name, telephone and address must match your Google Business Profile and Companies House character for character.
• @id gives the business a stable identifier other pages can reference. Use it.
• sameAs should list the profiles you actually maintain. Do not list a platform you abandoned in 2019.
• Hours in schema must match hours on the page and on Google. A mismatch is exactly the kind of thing an assistant repeats to a customer.

2. FAQPage

FAQPage is the most directly useful type for AI answers because the question-and-answer pairs are already the shape a model wants to lift. It is also the most abused. Google restricted FAQ rich results in 2023 largely because sites were marking up questions nobody asked.

Use it only where the questions and answers are visible on the page and are real. Keep answers to one or two sentences of fact.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do you take new NHS patients?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. We are currently accepting new NHS patients in Norwich. Registration is by phone or through the form on this page, and the first appointment is usually within three weeks."
      }
    },
    {
      "@type": "Question",
      "name": "How much is a private check-up?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A private examination costs £65 and includes two small X-rays where needed. Hygienist appointments are £75 for 30 minutes."
      }
    }
  ]
}

Keep the markup and the visible text identical. If you update a price on the page, update it in the JSON.

3. Product

For e-commerce and for any business selling a defined thing at a defined price. The fields that reduce ambiguity are name, brand, sku or gtin, offers with price and currency, and aggregateRating where you genuinely have reviews.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Cat6a Shielded Patch Panel, 24 Port",
  "brand": { "@type": "Brand", "name": "Example Cabling" },
  "sku": "ECB-PP24-6A",
  "gtin13": "5000000000000",
  "description": "24-port Cat6a shielded patch panel, 1U, with rear cable management bar.",
  "image": "https://www.example-cabling.co.uk/images/ecb-pp24-6a.jpg",
  "offers": {
    "@type": "Offer",
    "url": "https://www.example-cabling.co.uk/products/ecb-pp24-6a/",
    "priceCurrency": "GBP",
    "price": "89.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

Keep price current. Assistants quoting an out-of-date price from your own structured data is a self-inflicted wound. If prices change often, make sure your template generates the JSON from the same source as the visible price.

4. Service

Service is underused and useful for anyone who sells work rather than goods. One block per service page, linking back to the business via provider.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "Office data cabling installation",
  "name": "Structured cabling for offices",
  "description": "Design and installation of Cat6 and Cat6a structured cabling for offices in Leeds and West Yorkshire, including testing and certification.",
  "provider": { "@id": "https://www.example-cabling.co.uk/#business" },
  "areaServed": ["Leeds", "Bradford", "Wakefield"],
  "offers": {
    "@type": "Offer",
    "priceCurrency": "GBP",
    "price": "45.00",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "price": "45.00",
      "priceCurrency": "GBP",
      "unitText": "per outlet, from"
    }
  }
}

Notice provider uses the @id from the LocalBusiness block. That is how you tell a machine that this service and that business are the same entity.

Implementation checklist

[ ] One LocalBusiness (subtype) block on the homepage with @id, NAP, hours, areaServed, sameAs
[ ] One Service block per service page, provider pointing at the business @id
[ ] FAQPage only where real, visible FAQs exist; answers short and factual
[ ] Product blocks generated from the same data as visible prices
[ ] JSON-LD in a <script type="application/ld+json"> tag, not microdata scattered through the template
[ ] Zero errors in the schema.org validator; warnings reviewed
[ ] Facts in schema identical to facts in prose, in Google Business Profile and in directories

What to skip

• Organization and LocalBusiness both on the same page describing the same entity. Pick one.
• Review markup for reviews you wrote yourself or copied from elsewhere.
• HowTo and Speakable unless you have a specific reason; they add weight without removing ambiguity.
• Any markup for content that is not on the page.

Seoptist's audit validates the JSON-LD on every crawled page, flags missing required fields and mismatches against your fact card, and on Growth and above generates corrected blocks you can paste in. Run the free AI Visibility Check to see whether your current markup is being picked up.