Schema markup for AI search: which types matter

Most of the argument about whether structured data helps AI search misses a simpler point. A model reading a page has to work out what your business is. Prose makes it guess. Schema tells it.

That is the whole case. Everything below is about doing it properly.

Use the most specific type available

Schema.org is a hierarchy. LocalBusiness has children, and the children carry more meaning.

Using LocalBusiness when CafeOrCoffeeShop exists throws away information for no reason.

The core block

Here is a Restaurant entity with the fields that carry the most weight. Every field here is something a query might filter on.

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/#restaurant",
  "name": "The Corner Room",
  "description": "A twenty-four cover neighbourhood restaurant in Fitzroy, Melbourne, serving a daily-changing seasonal menu.",
  "url": "https://example.com/",
  "priceRange": "₹₹₹",
  "servesCuisine": ["Modern Australian"],
  "acceptsReservations": "https://example.com/book",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Gertrude Street, Fitzroy",
    "addressLocality": "Fitzroy",
    "addressRegion": "Victoria",
    "postalCode": "403001"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": 15.4989, "longitude": 73.8278 },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Wednesday","Thursday","Friday","Saturday","Sunday"],
    "opens": "19:00", "closes": "23:00"
  }],
  "hasMenu": "https://example.com/menu",
  "sameAs": [
    "https://www.google.com/maps/place/...",
    "https://www.instagram.com/..."
  ]
}

The fields that do the most work

@id. A stable identifier for the entity. It lets you reference the same business from multiple pages without a model treating them as different businesses. Skipping this is the most common structural mistake.

sameAs. Links to your listings elsewhere: Google Maps, Instagram, review platforms, directories. This is how you tell a model that these scattered records describe one entity. For corroboration it is the highest-value field on the page.

openingHoursSpecification. Real hours as data, including seasonal exceptions with validFrom and validThrough. Queries constrain on time constantly.

priceRange. Coarse, and still used, because "affordable" and "upmarket" are extremely common query modifiers.

servesCuisine, amenityFeature, petsAllowed, smokingAllowed, publicAccess. The filterable attributes. Each one you omit is a query family you drop out of.

geo. Coordinates remove ambiguity for anything phrased as "near."

FAQPage is worth more than it looks

If a page has genuine questions and answers on it, mark them up.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Do you take walk-ins?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Bar seats are walk-in only and tables are by reservation. We hold six bar seats back each evening."
    }
  }]
}

The reason this performs is that the format matches the shape of the task. A model answering a question is looking for a question-answer pair, and you have handed it one, pre-extracted, unambiguous, with no surrounding prose to misinterpret.

Mistakes that make markup worthless

Marking up content that is not on the page. Against the guidelines, and it creates the contradictions that damage entity trust.

Different facts in schema and in the visible page. Hours in the markup that disagree with hours in the footer is worse than having neither.

Copying a competitor's block and missing a field. Leftover name or address values from a template are common and catastrophic.

One-off deployment. Hours change, prices change, menus change. Markup that is not maintained turns into a confidently wrong source.

Skipping validation. Run every block through Google's Rich Results Test and the Schema Markup Validator before it ships. Both are free.

A sensible deployment order

1. Organization or LocalBusiness subtype on the homepage, with @id and sameAs.
2. PostalAddress, geo and openingHoursSpecification inside it.
3. FAQPage on any page that genuinely answers questions.
4. Menu or OfferCatalog if you sell a list of defined things.
5. BreadcrumbList across the site for structure.
6. Article or BlogPosting on editorial content, with author and dateModified.

That order front-loads the fields that answer "what is this business," which is the question every retrieval step depends on.