Local Business Schema Markup: What Still Earns Its Keep

Structured data on a local business site still earns two specific things in 2026: eligibility for rich results in Google Search, and a machine-readable statement of who the business is, where it operates and what it sells. What it is not is a documented requirement for Google's AI features — Google says so directly — and one of the types many audit templates still score for stopped producing anything on May 7, 2026. This guide separates the three, because the difference decides where an agency spends implementation hours.

What does structured data still earn?

Rich result eligibility, and nothing more automatic than that. Google's structured data gallery lists dozens of feature types, and eligibility means a page can be considered for a feature — not that it will receive one.

For a typical local service business the list that actually applies is short. Everything else in the gallery belongs to verticals that business is not in.

Which types belong on a local business site?

LocalBusiness is the base. Google documents exactly two required properties: name and address. Two rules from Google's own guidance are worth writing into your implementation standard:

• Use the most specific LocalBusiness sub-type available. Google's own examples are Restaurant, DaySpa and HealthClub. A dentist marked up as a generic LocalBusiness is technically valid and less informative than one marked up as a Dentist.
• Because LocalBusiness is a sub-type of Organization, follow the fields for Organization as well. Skipping it leaves out the logo, the legal name and the contact details that Organization carries.

Beyond the two required properties, Google lists recommended ones that map onto what a local customer actually wants to know: telephone, url, geo, openingHoursSpecification, priceRange, and — where the site genuinely captures them — aggregateRating and review.

BreadcrumbList is the second type worth the effort on almost any local site. It is still a supported feature in Google's gallery, its marginal cost is low once your templates already render breadcrumbs, and it describes the site's own hierarchy rather than making a claim about the business.

After those two, stop and check the gallery against the client's actual vertical rather than against a generic checklist. A restaurant, a clinic and a law firm do not need the same markup, and adding types that do not apply is work with no upside.

What did Google retire, and what do you do about markup you already shipped?

FAQ rich results are gone, and they went in two steps that are worth keeping apart because each has its own source. Google first restricted them in 2023, so that they were shown only for well-known, authoritative government and health websites. Then its Search Central changelog gave the end date: the FAQ rich result feature would no longer appear in Google Search starting May 7, 2026, and a later changelog entry removed the feature's documentation on the grounds that it is no longer shown at all.

Two consequences, and they point in different directions:

• Stop scoring sites on it. An audit row that awards points for FAQ markup is measuring a site against a feature the search engine retired. If your agency's checklist still has that row, it is producing findings nobody can act on.
• Do not go on a deletion campaign. Google states there is no need to proactively remove FAQ structured data, and that structured data which is not being used does not cause problems for Search. Billing a client for removal work is worse than leaving it alone.

This is the general shape of structured data maintenance, not a one-off: features get added and retired, and a checklist that is never re-checked against Google's gallery slowly turns into a list of things that used to matter.

Is structured data required to show up in AI answers?

Not for Google's, and Google is unusually blunt about it. In its guide to optimizing for generative AI features, under a section explicitly about myths, Google writes that structured data is not required for generative AI search and that there is no special schema.org markup you need to add. The same passage adds that it is still a good idea to keep using structured data as part of your overall SEO strategy, because it helps with rich result eligibility.

Two boundaries are worth stating plainly, because both get lost in summaries. First, not required is not the same as does not help: Google is saying you do not need it to be eligible, not that it can never be used. Second, this describes Google Search. Other assistants publish their own guidance or none at all, and a claim about any of them needs its own source rather than this one.

Read the two Google sentences together, because most of the advice circulating right now quotes only the second. Structured data is worth doing for rich result eligibility and for entity clarity. What it is not is a documented route into Google's AI features — so an agency selling it as one is making a claim Google has already contradicted in writing.

A note on our own practice, since it would be strange not to say it: the page you are reading embeds FAQPage markup. It will not produce a rich result, and we have no evidence that it changes anything in any AI assistant. We keep it because it is valid, because Google states there is no need to remove markup like it, and because how non-Google assistants treat page markup is not something we can observe. It is not free: it has to be written, kept in sync with the visible FAQ, and re-checked whenever the page changes — on this site that check is automated, which is exactly why we know it is not zero. It is cheap relative to that list. That is a judgment call about a low-cost thing — not a technique, and not a recommendation to go add it.

What about review and rating markup?

This is an easy place to break Google's guidelines without meaning to, so it is worth stating the rule before the recommendation.

Google supports review snippets for a set of types that includes local business, and it documents a restriction that catches a very common agency pattern: if the entity being reviewed controls the reviews about itself, its pages using LocalBusiness or any other Organization type are ineligible for the star review feature. A testimonials page the client curates is exactly that pattern.

Two more requirements from the same documentation:

• The review content you mark up has to be readily available to users on the marked-up page. Google states it must be immediately obvious that the page has review content — markup describing reviews that a visitor cannot see does not qualify.
• Violating the guidelines can draw a manual action, which then has to be remedied and submitted for reconsideration. This is one of the few structured data mistakes with a downside beyond "it does nothing".

The practical recommendation for a local client is therefore narrow: mark up ratings only where the reviews are genuinely third-party, genuinely visible on the page, and genuinely what the number says. Where they are not, leave aggregateRating out. Omitting a field carries no risk; inventing one puts a false statement into a machine-readable format, and that is the kind of thing that is easy to ship and hard to explain afterwards.

How do you validate it and show the client?

Two tools, both named by Google for this purpose: the Rich Results Test and the URL Inspection tool in Search Console. Run both, and keep the output.

The distinction matters more than it sounds. The Rich Results Test tells you whether the markup on a page is valid and what features it is eligible for. URL Inspection tells you what Google actually saw when it last crawled the page — which is the one that catches markup injected by JavaScript that never made it into the indexed version.

For the client-facing document: paste the validator output. "Schema implemented" is a sentence anyone can type. A dated validator result for a named URL is a fact.

What a minimal implementation looks like

Adapt rather than copy. The sub-type, the fields and the values all have to be true for the business.

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Example Family Dental",
  "url": "https://example.com/",
  "telephone": "+1-555-0100",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "100 Example Street",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "17:00"
    }
  ]
}

Every value above is invented for the example. Marking up hours the business does not keep, or a rating it did not receive, is not an optimization — it is a false statement in a format built to be trusted by machines.

Frequently Asked Questions

Is schema markup a ranking factor?

Not as a direct one, and framing it that way sets up the wrong expectation. What it does is make a page eligible for rich results, and give search systems an unambiguous statement of the entity behind the site.

Should I remove FAQ schema from client sites?

No. Google states there is no need to proactively remove it, and that structured data which is not being used does not cause problems for Search. Stop scoring sites on it; do not bill anyone to strip it out.

Which LocalBusiness sub-type should I use?

The most specific one that is accurate. Google's guidance is to use the most specific sub-type possible, with Restaurant, DaySpa and HealthClub as its own examples. If no sub-type fits the business honestly, the generic LocalBusiness type is the correct answer.

Does adding more schema types help?

Not by volume. Types that do not describe the business add implementation and maintenance cost without adding eligibility for anything. Check the client's vertical against Google's gallery rather than adding types speculatively.

Where should the JSON-LD go on the page?

Anywhere in the HTML that Google can see when it crawls the page. What matters is that it survives into the version Google indexes, which is exactly what the URL Inspection tool lets you confirm.

References

1. Google Search Central. "Local Business (LocalBusiness) Structured Data." developers.google.com
2. Google Search Central. "Structured Data Markup that Google Search Supports." developers.google.com
3. Google Search Central. "Deprecating the FAQ rich result feature" / "Removing documentation for the FAQ rich result feature" (changelog). developers.google.com
4. Google Search Central Blog. "Changes to HowTo and FAQ rich results" (the 2023 restriction to government and health sites). developers.google.com
5. Google Search Central. "Google's Guide to Optimizing for Generative AI Features on Google Search." developers.google.com
6. Google Search Central. "Review Snippet (Review, AggregateRating) Structured Data." developers.google.com
7. Google Search Central. "Intro to How Structured Data Markup Works." developers.google.com
8. Schema.org. "LocalBusiness." schema.org