Short answer
The minimum viable stack is LocalBusiness (correct subtype), Service, FAQPage, AggregateRating and BreadcrumbList, all connected through @id references inside a single @graph rather than floating as separate blocks. The fields parsed most reliably are name, address, telephone, areaServed, priceRange and openingHoursSpecification.
Why schema matters more for AI parsing than for traditional SEO
Traditional search engines can infer a lot from visible page text plus a hundred other ranking signals. AI engines generating a direct answer work under tighter constraints: they need to extract clean, unambiguous facts fast, often while composing a response in real time. Schema markup is the difference between an engine confidently stating your hours and service area versus hedging with "you should check their website" or, worse, citing a competitor whose data is simply easier to parse.
This is also why schema quality has become a competitive lever between businesses that otherwise look identical to a human visitor. Two plumbing companies with nearly the same website content can get cited at very different rates if one has clean, connected schema and the other has none, or has schema that contradicts what the page actually says.
The minimum viable stack
For a local business, five schema types cover the practical need. More is not automatically better; each one should describe something real and current on the page.
- LocalBusiness — using the correct, most specific subtype available: Dentist, LegalService, HomeAndConstructionBusiness, Restaurant, AutoRepair, and so on, rather than the generic LocalBusiness type, since the subtype itself is a signal
- Service — one instance per distinct service you offer, describing what it is, who provides it, and the area it covers
- FAQPage — marking up the actual FAQ content on the page, matched to real visible questions and answers, not hidden or duplicated content
- AggregateRating — reflecting your genuine, current review count and average, sourced from a platform you can actually substantiate if asked
- BreadcrumbList — a small thing, but it helps establish page hierarchy and site structure clearly for any parser walking the site
The fields that get parsed most reliably
Within LocalBusiness specifically, not all fields carry equal weight. Based on what shows up correctly in AI-generated answers versus what gets dropped, prioritize these.
- name and url — the anchor facts everything else is checked against
- telephone — in a consistent, fully formatted version matching every other citation of your business online
- address as a nested PostalAddress object, with addressCountry included even for U.S. businesses, since omitting it is a common source of ambiguity for parsers
- areaServed — listing actual cities or regions rather than a vague radius, since named places are easier for models to match against a user's location query
- priceRange — even an approximate $, $$, $$$ indicator helps the model answer cost-related prompts without guessing
- openingHoursSpecification — structured by day, not as a single freeform string, since freeform hours text is one of the most commonly misparsed fields
- sameAs — an array of URLs to your verified profiles (Google Business Profile, Facebook, Yelp, industry directories), which helps tie your entity together across the sources an AI engine cross-checks
The @id and @graph pattern
A mistake we see constantly is a page with several separate schema blocks, one for LocalBusiness, one for FAQPage, one for BreadcrumbList, each sitting in its own script tag with no relationship to the others. Search engines and AI parsers can still read each block individually, but they cannot confidently tell that the FAQ belongs to that specific business rather than to the page in some generic sense.
The fix is the @graph pattern: a single JSON-LD block containing an array of entities, each with its own @id, referencing each other by that @id where relevant. Your Service entities reference the LocalBusiness @id as their provider, your FAQPage can reference the same business as its publisher, and so on. This turns a set of disconnected facts into one coherent entity a model can reason about confidently, which is exactly the difference between a page that gets cited with specific correct details and one that gets summarized vaguely or skipped.
A complete copyable example
This is a working JSON-LD block for a hypothetical local service business, structured with the @graph pattern described above. Adjust the business type, fields and URLs to match your actual business before using it.
<script type="application/ld+json"> { "@context": "https://schema.org", "@graph": [ { "@type": "HomeAndConstructionBusiness", "@id": "https://tampabayplumbingpros.com/#business", "name": "Tampa Bay Plumbing Pros", "url": "https://tampabayplumbingpros.com/", "telephone": "+1-813-555-0142", "priceRange": "$$", "address": { "@type": "PostalAddress", "streetAddress": "4210 Bay Vista Ave", "addressLocality": "Tampa", "addressRegion": "FL", "postalCode": "33611", "addressCountry": "US" }, "areaServed": ["Tampa", "St. Petersburg", "Clearwater"], "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"], "opens": "07:00", "closes": "18:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Saturday", "Sunday"], "opens": "08:00", "closes": "14:00" } ], "sameAs": [ "https://www.google.com/maps/place/tampa-bay-plumbing-pros", "https://www.facebook.com/tampabayplumbingpros", "https://www.yelp.com/biz/tampa-bay-plumbing-pros" ] }, { "@type": "Service", "@id": "https://tampabayplumbingpros.com/emergency-plumbing/#service", "name": "Emergency Plumbing Repair", "provider": { "@id": "https://tampabayplumbingpros.com/#business" }, "areaServed": ["Tampa", "St. Petersburg", "Clearwater"], "description": "24/7 emergency plumbing repair for burst pipes, major leaks and sewer backups." }, { "@type": "FAQPage", "@id": "https://tampabayplumbingpros.com/faq/#faq", "publisher": { "@id": "https://tampabayplumbingpros.com/#business" }, "mainEntity": [ { "@type": "Question", "name": "Do you offer same-day emergency plumbing service?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, we offer same-day emergency service seven days a week across Tampa, St. Petersburg and Clearwater." } } ] }, { "@type": "AggregateRating", "@id": "https://tampabayplumbingpros.com/#rating", "itemReviewed": { "@id": "https://tampabayplumbingpros.com/#business" }, "ratingValue": "4.8", "reviewCount": "216" } ] } </script>
The errors that undo all of this
Even correct schema fails silently when one of these is also present on the page.
- Contradictory microdata — leftover inline microdata or RDFa attributes from an old theme sitting alongside new JSON-LD, giving parsers two different, conflicting answers for the same fact
- Orphan @graph entries — a Service or FAQPage entity with an @id that nothing else references, which loses most of the benefit of the pattern
- Wrong subtype — using generic LocalBusiness when a specific subtype like Dentist or LegalService exists and is more accurate, or picking a subtype that does not match your actual primary business activity
- Schema that contradicts visible text — marking up hours, pricing or services in schema that do not match what a human reader actually sees on the page, which some engines now flag or discount as unreliable
Related questions
Do I need schema on every page or just the homepage?
Service and location pages benefit most from their own Service and LocalBusiness references. The homepage should carry the primary LocalBusiness entity, and other pages reference it by @id rather than repeating the full business details each time.
How do I check if my schema is valid?
Google's Rich Results Test and the Schema.org validator both check syntax and structure. Neither confirms an AI engine will actually cite it, but they catch the basic errors that guarantee it will not.
Does adding schema guarantee a citation?
No. Schema removes ambiguity and makes citation more likely, but engines still weigh source authority, freshness and competing sources. Clean schema is necessary, not sufficient.
Should I use Organization schema instead of LocalBusiness?
Organization is too generic for a business with a physical location and a defined service area. Use the most specific LocalBusiness subtype available; it carries more useful signal than Organization for local and AI search purposes alike.
What if my website builder does not let me edit JSON-LD directly?
Most modern platforms (WordPress, Shopify, Wix, Squarespace) support custom code injection through a plugin or a header/footer script field, which is enough to insert a JSON-LD block like the example above without a full rebuild.
Want to know if your current schema is actually helping or quietly contradicting itself?
Get your 55-page Pro Audit for $19 — delivered in 48 hours. Shows exactly where you stand in ChatGPT, Perplexity, Google AI Overviews and the Local Pack.
Keep exploring
Related services, industries, cities and resources from Local Visibility AI.