Structured Data for AI Assistants — JSON-LD, LocalBusiness, and FAQ Schema
Structured data gives AI assistants machine-readable business facts — JSON-LD LocalBusiness for entity identity, specialized subtypes for category clarity, and selective FAQPage schema for quotable answers. It improves grounding accuracy and reduces hallucinated hours or phone numbers, but does not replace reviews and listings as primary local recommendation signals.
What structured data does in the AI era
Search engines have consumed structured data for rich results for years. JSON-LD blocks describe entities — businesses, products, events — in vocabulary search systems understand.
AI assistants add a parallel use case. When ChatGPT, Claude, or Perplexity browse or retrieve your site, structured markup reduces ambiguity:
- Is this phone number canonical?
- What is the legal business name versus the DBA?
- Which cities are in the service area?
- What are the stated hours versus holiday exceptions?
Models still blend reviews, directories, and third-party sources. Schema does not override a competitor with 800 reviews and your twelve. It clarifies who you are when you enter the evidence pool.
This guide covers JSON-LD LocalBusiness, specialized subtypes, FAQPage schema for buyer-aligned Q&A, validation, and deployment order for local SMBs pursuing AEO and GEO outcomes — honestly, without implying guaranteed AI placement.
Companion checklist: llms.txt, schema, and robots.
Structured data vs other AI visibility signals
| Signal class | Role | Relative weight for local AI mentions |
|---|---|---|
| Google reviews + themes | Social proof, intent match | High |
| GBP / Apple BC / directories | Entity graph, NAP | High |
| Service pages (HTML) | Crawlable scope + geography | High |
| JSON-LD LocalBusiness | Machine-readable identity | Medium — accuracy multiplier |
| FAQPage schema | Quotable Q&A | Medium — intent alignment |
| llms.txt | Plain-text fact summary | Medium — clarity for LLM crawlers |
| robots.txt hygiene | Crawl access | Gate — errors block retrieval |
Under-investing in reviews while over-investing in schema is a common mis-ordering. Fix universal signals and structured data in parallel, not schema instead of listings.
Prerequisites before markup
Schema with wrong facts scales errors. AI may confidently state the incorrect phone from your @graph block.
Complete this alignment first:
- Single canonical business name — legal entity vs marketing name documented
- NAP match — website footer, contact page, Google Business Profile, Apple Business Connect, Bing Places, Yelp
- Hours policy — regular, seasonal, appointment-only, holiday closures
- Service area truth — cities and radius you actually serve
- Primary category — matches GBP primary category
Apple and Google divergence breaks entity resolution: Apple Business Connect guide.
When facts drift, repair upstream sources before re-validating schema. Wrong AI statements often trace to conflicting listings: AI reputation repair.
JSON-LD LocalBusiness — core fields
Place JSON-LD in a <script type="application/ld+json"> block on your homepage and location pages (if multi-location). Google recommends JSON-LD over microdata for maintainability.
Minimum viable LocalBusiness
{
"@context": "https://schema.org",
"@type": "Plumber",
"@id": "https://www.exampleplumbing.com/#organization",
"name": "Example Plumbing LLC",
"url": "https://www.exampleplumbing.com",
"telephone": "+1-555-010-0200",
"image": "https://www.exampleplumbing.com/images/storefront.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "1200 Main Street",
"addressLocality": "Nashville",
"addressRegion": "TN",
"postalCode": "37203",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 36.1627,
"longitude": -86.7816
},
"areaServed": [
{
"@type": "City",
"name": "Nashville"
},
{
"@type": "City",
"name": "Franklin"
}
],
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "18:00"
}
],
"sameAs": [
"https://www.google.com/maps?cid=YOUR_GBP_CID",
"https://www.yelp.com/biz/example-plumbing-nashville"
]
}
Field-by-field rationale for AI grounding
@type — specialized subtype. Plumber, Dentist, LegalService, HomeAndConstructionBusiness subclasses signal category to parsers faster than generic LocalBusiness. Match reality — misclassified types confuse intent matching when users ask for specialists.
@id — stable identifier. Use a canonical URI fragment (#organization) referenced across pages if you build @graph structures. Stability helps when multiple pages describe the same entity.
name — exact match. Must align with GBP display name policy — no keyword stuffing. Entity resolution systems merge or split records based on name similarity across sources.
telephone — E.164 recommended. One primary customer-facing number. Tracking numbers belong in call analytics, not scattered across schema and GBP unless consistently managed.
address — physical location rules. Service-area businesses with hidden addresses still need honest areaServed. Some categories use address for headquarters; others comply with Google guidelines for service-area representation. Follow GBP rules first — Gemini reads that graph.
areaServed — geography AI quotes. Cities, postal codes, or GeoCircle radius objects clarify where you operate. Vague "greater metro" prose in schema helps less than explicit city objects when models answer "Do they serve Franklin?"
openingHoursSpecification — structured hours. Prefer structured specs over "openingHours": "Mo-Fr 08:00-18:00" alone for complex schedules. AI hallucinates hours frequently when sources conflict — structured agreement reduces variance.
sameAs — corroboration links. Official social profiles, GBP maps URL, authoritative directories. These edges tell knowledge graphs your site entity equals your map entity.
aggregateRating — optional, sensitive. Only include if ratings are directly attributable and updated on a policy you can maintain. Stale aggregateRating worse than omitting.
Multi-location and @graph
Multi-location brands should emit one LocalBusiness node per location plus an Organization parent when appropriate.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.exampledental.com/#org",
"name": "Example Dental Group",
"url": "https://www.exampledental.com"
},
{
"@type": "Dentist",
"@id": "https://www.exampledental.com/locations/downtown/#location",
"name": "Example Dental — Downtown",
"parentOrganization": { "@id": "https://www.exampledental.com/#org" },
"telephone": "+1-555-010-0301",
"address": { "@type": "PostalAddress", "streetAddress": "50 Broadway", "addressLocality": "Nashville", "addressRegion": "TN", "postalCode": "37201", "addressCountry": "US" }
}
]
}
Each location page should reference its own @id, not duplicate homepage markup site-wide. Sitewide identical LocalBusiness blocks are a common multi-location error — they imply one address everywhere.
FAQPage schema — selective, buyer-aligned
FAQ schema marks up question–answer pairs. AI systems use FAQs to match buyer phrasing — "Do you offer emergency service?", "What insurance do you accept?", "How much does a water heater replacement cost?"
When FAQ schema helps
- Service pages with genuine FAQs maintained by staff
- Location pages clarifying parking, access, languages spoken
- Policy pages — financing, warranties, estimates
When FAQ schema hurts
- Identical FAQ blocks duplicated on every URL
- Questions you cannot answer honestly in one paragraph
- Keyword-stuffed fake questions ("best plumber Nashville cheap")
Example FAQPage block
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Do you offer same-day emergency plumbing in Nashville?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. Example Plumbing dispatches licensed technicians for same-day emergency calls in Nashville and Franklin when slots are available. Call +1-555-010-0200 for current availability."
}
},
{
"@type": "Question",
"name": "Are estimates free for water heater replacement?",
"acceptedAnswer": {
"@type": "Answer",
"text": "We provide free in-home estimates for standard water heater replacement in our service area. Tankless conversions may require a diagnostic visit; fees are credited toward installation if you proceed."
}
}
]
}
Mirror buyer-intent prompts from your mention-tracking library. If users ask ChatGPT about same-day service, your FAQ should use that language — not internal jargon.
FAQ content visible on-page must match schema text. Hidden markup-only FAQs violate Google guidelines and erode trust if discovered.
Service catalog markup
Beyond LocalBusiness, Service objects or hasOfferCatalog structures clarify what you do:
{
"@type": "Service",
"serviceType": "Water heater replacement",
"provider": { "@id": "https://www.exampleplumbing.com/#organization" },
"areaServed": { "@type": "City", "name": "Nashville" },
"description": "Removal and installation of tank and tankless water heaters; permits pulled per local code."
}
Service clarity supports query–theme alignment when models match user intent to business capabilities. Thin "we do everything" pages without structured service scope underperform specific competitors.
Deployment order for local SMBs
Follow this sequence to avoid rework:
| Step | Action | Outcome |
|---|---|---|
| 1 | NAP audit vs GBP | Single source of truth |
| 2 | Homepage JSON-LD subtype | Entity anchor |
| 3 | Location pages (if any) | Per-site @id |
| 4 | Core service pages HTML + optional Service schema | Intent coverage |
| 5 | FAQ blocks on top 3 service URLs | Quotable answers |
| 6 | llms.txt at site root | Redundant plain-text facts |
| 7 | robots.txt audit | Crawlers reach public pages |
| 8 | Rich Results Test + Search Console | Validation |
AIrecommend.ai deploys schema and llms.txt through the Entity Profile Growth Engine module from verified intake — not scraped guesses.
Validation and monitoring
Google Rich Results Test — syntax and eligibility for rich result types.
Schema.org validator — broader vocabulary checks.
Search Console — enhancement reports for valid items, warnings, errors.
Manual AI spot checks — monthly, run buyer-intent prompts; when named, verify hours and phone match schema. Method: How to check what ChatGPT says.
Change control — when phone or hours change, update GBP first, directories second, site third, schema fourth — same day if possible.
robots.txt and crawler access
Structured data on blocked pages is useless. Confirm:
User-agent: *
Disallow: /admin/
Allow: /
Audit disallow rules that accidentally block /contact, /locations/, or JavaScript-rendered routes crawlers need. Some AI retrieval systems respect robots; blocking may remove your best facts from the corpus.
Details: llms.txt, schema, and robots checklist.
llms.txt as structured data's plain-text partner
llms.txt is not schema — it is a human- and machine-readable summary at https://yoursite.com/llms.txt with canonical name, services, URLs, contact policy, and key facts.
Schema and llms.txt should agree. Contradictions train systems to distrust both.
Example llms.txt excerpt:
# Example Plumbing LLC
> Licensed plumbing in Nashville and Franklin, TN.
## Services
- Emergency plumbing
- Water heater replacement
- Drain cleaning
## Contact
Phone: +1-555-010-0200
Website: https://www.exampleplumbing.com
Service area: Nashville, Franklin, Brentwood
## Key pages
- /services/water-heater-replacement
- /service-area
LLM SEO programs treat entity clarity as a bundle — schema + llms.txt + factual HTML.
Common mistakes
Sitewide duplicate LocalBusiness. One address on every URL for a multi-state brand.
Stale aggregateRating. Rating from 2019 on a page updated yesterday.
Keyword-stuffed name. "Best Nashville Emergency Plumber 24/7 Example Plumbing" — GBP suspensions and entity noise.
FAQ spam sitewide. Same five questions on 200 URLs.
Schema without visible content. Markup-only answers users never see.
Conflicting telephone values. Site header, schema, GBP, and Yelp all differ.
Ignoring Apple Business Connect. Google-heavy schema while Apple listing remains unclaimed — Gemini is not the only engine.
Structured data and platform behavior
Platforms consume structured facts differently:
Google / Gemini / AI Overviews — strong GBP + schema + on-page agreement influences local synthesis.
ChatGPT — may blend training, browsing, and Bing-adjacent sources; schema on crawled pages helps when browsing is active.
Perplexity — retrieval-forward; clear FAQ and Service pages with schema may appear as citations.
Claude — grounding on provided documents; schema in fetched HTML reduces parse errors.
Cross-platform low overlap means schema fixes may move one engine before others: 11% platform overlap.
Measure with free scan baselines — not assumed universal lift.
What structured data cannot do
- Guarantee mentions in ChatGPT or any third-party product
- Compensate for review deficits versus established competitors
- Replace directory presence and NAP consistency
- Fix hallucinations caused by rogue third-party listings you never claimed
- Substitute for citable data studies on Perplexity-heavy journeys
Honest GEO delivery pairs technical entity work with Review Engine and Listings modules.
Implementation checklist (copy for your dev)
- NAP matches GBP on all location pages
-
@typesubtype matches primary category -
@idstable and unique per location -
areaServedlists real cities -
openingHoursSpecificationmatches live operations -
sameAsincludes GBP maps URL - FAQPage only on pages with visible FAQs
- Service descriptions match staff-verified scope
- llms.txt deployed and consistent
- robots.txt allows key URLs
- Validators pass without errors
- Monthly AI spot check for fact accuracy
Next steps
- Run NAP audit this week
- Deploy homepage JSON-LD subtype
- Add buyer-aligned FAQ schema on top service page
- Publish llms.txt
- Baseline mention rates — AEO guide
- Resample monthly after directory and review work
Structured data is precision instrumentation for how machines read your business — not a shortcut past the hard work of reviews, listings, and citable reputation. Deploy it carefully, keep facts synchronized, and measure AI outcomes with the same rigor you apply to Search Console.
Industry-specific schema notes
Healthcare and dental — Use Physician, Dentist, or MedicalBusiness where valid. Include medicalSpecialty, accepted insurance as FAQ content (not fabricated schema properties). HIPAA-sensitive details stay out of markup; describe policies in plain FAQ answers.
Legal — LegalService with areaServed matching bar admission geography. Attorney bios as Person linked via employee or member only when pages exist and bar rules allow.
Home services — HomeAndConstructionBusiness subclasses (Plumber, Electrician, HVACBusiness) clarify emergency vs specialty intents. hasCredential for license numbers when displayed on-site.
Hospitality and retail — Restaurant, Store types with Menu or OfferCatalog where maintained. Hours accuracy is critical; AI Overviews and Gemini quote hours frequently.
Subtype precision helps query–theme alignment described in how AI assistants choose businesses — generic markup under-specifies what you actually do.
Testing schema impact on mention rates
Schema deployment should trigger a measurement window, not celebration.
Week 0: baseline mention rate and accuracy rate on frozen prompt library.
Week 2–4: resample after Search Console validates markup without errors.
Compare accuracy first (are wrong phones fixed?), then mention rate.
Expect accuracy improvements before mention lifts — models already skipped you may need review and directory movement, not markup alone. Pair Entity Profile work with Review Engine and Listings modules in the same sprint.
Related: How AI assistants choose businesses · Share of AI voice measurement · GEO services.