How to Get a Local Service Site Cited by AI: A JSON-LD Schema Graph Walkthrough

Most articles about Generative Engine Optimization (GEO) tell you to "add structured data" and stop there. This one shows the actual graph structure we build for local service businesses, node by node, and explains why each piece matters for getting pulled into an AI-generated answer.

This is a build walkthrough, not a theory piece. We'll use a plumbing company as the worked example, but the structure transfers to any local service business — swap the service type and you're done.

The short version

The approach is a connected JSON-LD schema graph: a single structured-data block where entities reference each other instead of sitting in isolation. The goal isn't a Google rich snippet. The goal is to make the site machine-readable enough that an AI model can understand who the business is, what it does, where it operates, and trust it enough to cite.

The core lesson: AI engines cite entities they can resolve, not pages they can rank. A connected graph resolves the entity. A pile of disconnected schema tags does not.

Why schema matters more for AI than for Google

Traditional SEO treats schema as a bonus — a way to earn a star rating or an FAQ dropdown. GEO treats schema as the primary language you speak to the model.

When someone asks an AI assistant "who's a reliable plumber near me for an emergency leak," the model isn't ranking ten blue links. It's assembling an answer from sources it can parse, verify, and trust. Research on AI ecommerce optimization found that pages with complete Product schema are several times more likely to be cited than pages without it. The same logic applies to local service businesses through LocalBusiness and Service schema.

A description written purely for human persuasion — "premium quality, industry-leading comfort solutions" — gives a model nothing to extract. A structured graph that states the service area, the services offered, the hours, the credentials, and how they connect gives the model everything.

The graph, explained node by node

Here's the structure. Each node has an @id so other nodes can reference it — that referencing is what turns a list of tags into a graph.

1. Organization (the anchor)

The root entity. Legal name, logo, founding date, and sameAs links to every profile the business controls (Google Business Profile, Facebook, LinkedIn, Yelp). The sameAs array is how a model cross-references the entity against third-party sources to confirm it's real.

2. LocalBusiness (specific subtype)

Use the most specific subtype available — Plumber for a plumbing company, HVACBusiness for HVAC, Electrician for an electrician, and so on — rather than generic LocalBusiness. Specificity helps the model classify the entity correctly. This node references the Organization via @id.

3. Service area (GeoCircle)

Instead of vaguely claiming "serving the metro and surrounding areas," define a GeoCircle with a center point and radius. A model answering "do they cover the next town over?" can now reason about it instead of guessing.

4–9. Individual Service nodes

One node per core service. For a plumber that's drain cleaning, water heater installation, leak repair, sewer line service, fixture installation, and emergency callouts. Each Service node names the service, links to the provider (the LocalBusiness @id), and describes what it includes. This is what lets a model answer "do they do emergency leak repair at night" with a yes instead of a shrug.

10. OpeningHoursSpecification

Explicit hours, including the distinction between standard hours and 24/7 emergency availability. Critical for "are they open now" style queries.

11. AggregateRating + 12–13. Review nodes

Real review data only. Link to verifiable review sources rather than inventing a score. Fabricated ratings are the fastest way to get an entity distrusted — models cross-check, and so do humans.

14. WebSite + SearchAction

Declares the site as an entity and exposes site search. Minor for citation, but it completes the graph.

15. BreadcrumbList

Site structure made explicit, so the model understands page hierarchy.

The detail most people miss: connect the nodes

The difference between a schema pile and a schema graph is the @id references. In a proper build, the LocalBusiness references the Organization, every Service references the LocalBusiness as its provider, the AggregateRating attaches to the LocalBusiness, and the reviews attach to the rating.

When the model parses one connected block, it can answer a compound question — "is there a plumber near me that does 24/7 emergency leak repair and has good reviews?" — because every fact in that sentence lives in one resolvable entity. Disconnected tags force the model to do the joining itself, and it often won't.

Don't forget the crawler permissions

Schema is useless if the AI crawlers can't read it. Alongside the graph, set explicit permissions in robots.txt for the AI user agents (GPTBot, PerplexityBot, Google-Extended, ClaudeBot, and others), so the engines that assemble answers are actually allowed to fetch the page. A lot of sites quietly block these without realizing it.

What to measure

GEO doesn't show up cleanly in your old analytics. Track it directly:

• Citation checks: periodically ask ChatGPT, Perplexity, and Google AI Mode the questions a customer would ask, and note whether the brand appears.
• AI-referred sessions: segment traffic arriving from AI assistants and measure add-to-action lift, not just last-click.
• Baseline now: most brands track none of this yet. Building a baseline today gives you a long head start before the channel gets crowded.

A copy-this checklist for local service GEO

1. Use the most specific LocalBusiness subtype that fits.
2. Build one connected graph with @id references, not scattered tags.
3. Define service area geometrically (GeoCircle), not in prose.
4. Give every core service its own Service node linked to the provider.
5. State hours explicitly, including emergency availability.
6. Use only real, verifiable ratings and reviews.
7. Add sameAs links to every profile you control.
8. Open robots.txt to the AI crawlers.
9. Test by asking real AI assistants real customer questions.

FAQ

Is JSON-LD better than Microdata for GEO? Yes. JSON-LD keeps structured data in one block separate from your visible markup, which is easier for both you to maintain and for engines to parse. It's Google's recommended format and works well for AI extraction.

Will this rank me on Google too? It helps, but that's not the point of this work. Schema supports traditional rich results, but the graph approach here is aimed at AI citation specifically. Treat Google rankings as a side benefit.

How long until an AI engine cites the site? There's no fixed timeline — it depends on how often the engines recrawl and how much corroborating signal exists elsewhere (real reviews, real mentions). Schema makes you eligible to be cited; off-site trust signals make it likely.

Can I do this for a non-local business? Yes — swap LocalBusiness/Service nodes for Product/Offer (ecommerce) or Organization/Service (B2B). The connected-graph principle is the same.

We build GEO-ready sites and schema graphs for local service businesses and the agencies that serve them. If you want your site readable by the engines your customers now ask, get in touch.