Schema for rich results vs schema for being cited
Most schema tutorials you will find are selling one outcome: the shiny stuff in Google's blue links. Star ratings under your listing, an FAQ dropdown, a recipe card, breadcrumbs. That is rich-results schema. It is real and it is fine, but it is a Google-search-result feature, and it is not the same job as getting named inside an AI answer.
Here is the difference that matters. Rich results are about how your entry looks in a list of links. AI citation is about whether an answer engine trusts your facts enough to repeat them and put your name on them. When a homeowner asks ChatGPT "who does tankless water heater installs in my town and are they licensed," the engine is assembling an answer from pages it read. Schema does not force it to pick you. What schema does is make your facts unambiguous, so when the engine is deciding between three shops that all look similar, yours is the one whose service area, trade, and license status are stated in machine-readable form and match the on-page copy exactly.
Think of it as the difference between a hand-lettered sign and a stamped nameplate. The sign (your page copy) is what a person reads. The nameplate (your schema) is the same facts in a format that never gets misread. An AI reading your page can usually infer what you do. But "usually" is where citations get lost. If the engine is 80% sure you serve Cape Coral and 100% sure your competitor does, it names your competitor. Schema closes that gap. It is not a ranking trick and it is not magic. It is you writing your own facts down in the one format a machine cannot misinterpret, so the doubt that keeps you out of the answer goes away.
This guide lives in AI citation, not rich results. Schema for star ratings and blue-link features has its home in classic on-page SEO. Schema built so an answer engine names you is what we are covering here.
The schema types that actually move AI citation
You do not need every type on Schema.org. For a contractor trying to get named in AI answers, a short stack does the work. The rest is noise.
- Your business identity. Use the most specific type that fits your trade (Plumber, HVACBusiness, RoofingContractor, Electrician, or LocalBusiness if no exact subtype exists). This is the single most important block. It states your legal name, phone, address or service area, hours, and the trades you work. It is the fact card an engine reads to decide who you are.
- Service. One block per real service you offer, each tied back to your business, each naming the service and where it is delivered. This is what lets an engine answer "who installs standing-seam metal roofing in my area" and land on you instead of a generic roofer.
- FAQPage. Your on-page FAQ, marked up so each question and answer is a clean, liftable pair. Answer engines love a stated question with a stated answer, because it maps directly onto how a homeowner asks.
- HowTo. Where a page walks through a process ("what to expect during a water heater replacement"), a How-To block hands the engine an ordered, quotable set of steps.
Two supporting types earn their place: BreadcrumbList (so the engine understands where a page sits in your site) and, on your home page, a link from your business identity up to your parent organization so the entity is anchored to a real, older company. On our own builds that parent is Kelly Webmasters and Marketers, founded 2008, which is exactly the kind of corroborated, aged entity an engine reads as trust.
Notice what is not on this list: Product schema, Review schema you write about yourself, Event schema, and the dozen other types agencies pile on to look thorough. Self-authored review markup in particular is a trap. Engines discount ratings a business stamps on its own pages, and Google can penalize it. The corroboration that moves AI citation comes from third parties naming you, not from you marking up your own five stars.
Entity clarity: the real reason AI names one shop over another
The word that matters in AI citation is entity. To an answer engine, your business is an entity: a distinct thing it is trying to identify, understand, and connect to other things it already knows. Every ambiguity about your entity is a reason to name someone clearer instead.
Contractors trip on this constantly, usually without knowing it. The company is "ABC Plumbing" on the website, "ABC Plumbing & Drain" on the Google listing, "ABC Plumbing LLC" on the license, and a slightly different phone number on the Facebook page. To a human, obviously the same shop. To a machine trying to decide if these are one entity or four, it is a mess, and a mess is a reason to leave you out of a confident answer.
Schema is where you settle it. Your business-identity block states the canonical name, the one phone number, the exact service area, and the trade, and it does it in a format that removes the guesswork. When that machine-readable statement matches your on-page copy, your Google Business Profile, and the way third parties refer to you, the engine stops seeing four fuzzy things and starts seeing one solid entity it can name with confidence.
The same clarity extends to what you do. A generic "quality service for your home" tells an engine nothing it can attach to a query. A service block that names the exact job ("tankless water heater installation and repair") in the exact towns you cover gives the engine a fact it can match to a homeowner's question word for word. Trades that get named in AI answers are usually the ones whose services read like the searches customers actually run, stated once in plain copy and once in structured data that agrees with it.
That last part is the catch schema alone cannot fix. Entity clarity is a chain: your schema, your page copy, and the rest of the web all have to agree. If your schema says one thing and your listing says another, you have added a contradiction, not clarity. This is why we treat schema as one link in the citation work, not the whole job. The structured data states your facts cleanly; the corroboration (consistent listings, real mentions in your trade and town) is what makes an engine believe them. Get both aligned and you become the obvious answer. Get schema alone, bolted onto inconsistent facts, and you have written a very tidy version of a confusing story.
What good contractor schema looks like in practice
You do not need to see raw code to judge whether your schema is doing its job. You need to know what facts it should be stating and how tightly they should match everything else. Here is the working checklist.
| Schema element | What it should state | The test that matters |
|---|---|---|
| Business type | The most specific trade subtype (Plumber, Roofer, HVACBusiness), not bare LocalBusiness | An engine can name your trade without reading a word of prose |
| Name and phone | Exactly one canonical name, one phone number | Matches your listing, footer, and license character for character |
| Service area | The real towns you work, named | Matches the service-area pages a homeowner actually finds |
| Services | Each real service as its own block, tied to the business | An engine can answer "who does X in my town" with your name |
| FAQ | Question and answer pairs identical to the visible page | The marked-up answer and the on-page answer read the same |
| Parent org | A link to an older, real parent company where one exists | The entity is anchored to something aged and corroborated |
The column that trips people up is the right-hand one. Schema is not scored on being present. It is scored on agreeing with everything else. Google's own guidance is blunt about it: structured data that does not match the visible page content is a violation, and an engine that catches the mismatch trusts you less, not more. So the working rule is simple. Never mark up a fact your page does not also state plainly to a human. If the schema says you serve nine towns, nine towns had better be on the page.
This is also why we hand-code schema into the page instead of letting a plugin generate it. A plugin bolts a generic block onto whatever it can scrape, and it drifts out of sync the moment your copy changes. Hand-placed schema, kept in step with the copy, in a fast page an engine can read without a fight, is the version that holds up. The markup is the easy part. Keeping it honest against the rest of your site is the work.
Where schema stops, and what has to carry it the rest of the way
Here is the honest limit, because plenty of vendors are about to sell schema as the whole answer to AI visibility. It is not. Schema removes ambiguity about facts that are already true and already on your page. It cannot invent authority you have not earned, and it cannot rescue a page an engine cannot find or read.
Two things have to be in place before schema pays off. First, the page itself has to be citation-worthy: a real page on the real service, fast enough to load under 2 seconds, written clearly enough that a careful reader could summarize what you do and get it right. Schema on a thin, vague page just describes a thin, vague page in a tidier format. Second, the rest of the web has to corroborate you. When other pages, directories, and articles name your business in your trade and town, an engine reads that as a vote, and it weighs those third-party mentions more heavily than anything you stamp on your own site. Schema states your facts; corroboration is what makes them believed.
So the order of operations matters. Get the on-page foundation right, get your listings and mentions consistent, and then schema becomes the clean nameplate that ties it all together. Do it in reverse (schema first, on a slow or thin site with scattered listings) and you have polished the one part that was never the bottleneck.
It is worth naming what sits outside this work entirely, so you know what schema is not doing. Your Google Business Profile, the map pack, and "near me" proximity ranking are their own local-search job. Classic blue-link keyword rankings and backlinks for their own sake are their own SEO job. Both feed the same facts an engine reads, and both should agree with your schema, but neither is the citation layer. Schema for being cited by AI is the piece that lives here, and it only works standing on top of the rest.
How to check your schema and what to do about it
You can find out where you stand without a developer. A few checks tell you whether your schema is present, valid, and honest, and whether it is actually helping you get named.
- See if you have any schema at all. Run your key pages through Google's Rich Results Test and the Schema Markup Validator. If they come back empty, you have no structured data and you are handing engines a harder read than you need to. If they come back with errors, you have schema that is broken enough to be ignored.
- Check that it matches the page. For every fact in the schema (name, phone, service area, services, FAQ answers), confirm the same fact is stated plainly on the visible page. Any fact in the markup but missing from the page is a mismatch to fix, not a win.
- Check that it is specific. Bare LocalBusiness with a generic name is a wasted opportunity. The most specific trade subtype, the exact towns, and one service block per real service are what give an engine something precise to cite.
- Test the real question. Ask ChatGPT, Gemini, and Perplexity the questions your customers ask ("who does emergency AC repair in my town") and see whether you get named. That is the outcome schema is supposed to support, and it is not something your Google rankings will tell you.
If those checks turn up empty pages, broken markup, or a business that no engine names, the fix is not a schema plugin bolted onto the existing site. It is settling the entity: one canonical name and number, the specific trade type, real service and service-area pages, FAQ and How-To content marked up to match, and listings across the web that agree. Schema is the last clean step in that chain, not a shortcut around it.
That is the work this silo does. We audit whether AI engines name your shop, find the ambiguities and gaps that keep you out of the answer, and fix the facts, the pages, and the structured data together so an engine has one solid entity to cite. An audit is delivered in 1-3 business days, and it tells you exactly which of these four checks you are failing.