Local Business Schema Markup: What It Can and Cannot Do in 2026
LocalBusiness schema makes key facts machine-readable. Learn what it clarifies, how to validate it, and why it cannot guarantee AI visibility.
By Ian Ho, Xomer
Article images are AI-generated illustrations and may include AI-generated people. They do not depict Xomer clients.
TL;DR: LocalBusiness schema labels facts such as your name, services, hours, and service area in a machine-readable format. Valid markup can reduce ambiguity for systems that use it, but providers do not publish a universal AI-selection formula and may ignore the markup. Add it accurately, validate it, and measure actual answers rather than assuming a recommendation.
When one local business turns up in an AI answer and the company next door does not, the answer itself never tells you why. Different sources, different retrieval, different day, different phrasing of the question. Schema markup is one of the few parts of this you actually control: it labels your business facts so every machine reading your page gets the same version.
Schema markup can help machines interpret your business details without changing what a visitor sees.
What schema markup actually is
Schema markup is code sitting in your page's HTML that no visitor ever sees. Crawlers and retrieval systems that support it read it, and the ones that do not simply skip past. Nothing on screen changes either way.
The code follows a standardized vocabulary maintained by Schema.org, a collaborative project founded by Google, Microsoft, Yahoo, and Yandex to create a shared language for describing businesses, events, products, articles, and other entities on the web. When you use schema markup, you're essentially labeling the information on your page in a way that machines can interpret without guesswork.
For a local service business, the relevant type is LocalBusiness (or a specific subtype like Plumber, HVACBusiness, or AutoRepair). A properly implemented LocalBusiness schema block tells any system reading your site:
- The exact legal or trade name of your business
- Your primary business category and service types
- Your physical address and the geographic area you serve
- Your phone number and website URL
- Your hours of operation
- Your price range or pricing signals
- Your aggregate review rating and review count
Structured data states those facts outright. Left in prose, "call us anytime" leaves a machine to work out whether you run a 24-hour service; in schema it goes in a field with one defined meaning. Whether a given system reads that field is a separate question, and no provider publishes the rule for it.
How to evaluate whether a system uses structured data
You can test this yourself in three steps, which is more than anyone can tell you from outside. Validate the markup. Run your queries and save the answers, the sources they cited, and the date. Run the identical queries again after you have changed something real. Assistants mix model knowledge, live web retrieval, search indexes, maps, and third-party sources, and no provider publishes how LocalBusiness schema weighs inside that mix.
Google's documentation on LocalBusiness structured data says the markup can communicate business details and support eligible search features. That documentation does not say schema controls AI recommendations. Treat it as accurate machine-readable publishing, then inspect the actual sources each answer engine exposes.
Total Solar Cleaning, a residential and commercial solar panel cleaning company serving the San Francisco Bay Area, has appeared in dated AI-answer checks for relevant local queries and ranked first organically on Google for "how much does solar panel cleaning cost in the Bay Area." Its site also uses schema alongside other SEO work. That observation does not isolate schema as the cause. Results vary by engine, market, query, and date.
For Tampa's home service and pest control market, heat and hurricane season hand you the obvious questions to test: an HVAC failure in August, storm restoration in September. Save the answer, the sources it cited, and the date, then check what your leads from that week say when you ask how they found you.
Why schema implementation varies
Schema support changes with the platform, the plan, the template, the plugin, and whoever last touched the site. Open the rendered HTML and validate what is actually on the page today. Wix, Squarespace, and GoDaddy sites all ship correct markup in some configurations and nothing at all in others.
WordPress sites and agency builds tell the same story. A site can look expensive and still publish a phone number three years out of date inside its markup. View source, or run the validator. The page itself gives you no clue from the outside.
"Schema is useful because it labels business facts directly. It is still only one input, so validate the markup and measure the answers instead of treating it as a visibility guarantee."
For Detroit's auto detailing and home service businesses, validate the schema first, then compare what your test answers cite against what your own site publishes. Wherever those two disagree, you have found something worth fixing this week.
Core fields to validate
LocalBusiness carries dozens of properties and you need very few of them. Fill in the ones describing what a customer can already see on the page, and that meet the platform's own requirements. No published formula ranks these fields by weight, so accuracy is the entire standard.
Name and type. The name field carries the same business name customers see on the page and on your profiles. For @type, use the most specific one that is true: a plumbing company should be Plumber, and the generic LocalBusiness is the fallback when no subtype fits. The available types are maintained at schema.org/LocalBusiness.
Address and service area. Use address and areaServed when they match what is visible on the page and what the schema guidance allows. A service-area business working out of a home has its own rules here, and getting them wrong is a common way to publish markup that contradicts your own Business Profile.
Contact and hours. The telephone and openingHours fields publish your contact details and availability in a standard format. Keep them identical to the visible page. Those two drift faster than anything else in a schema block, usually after a number change or a seasonal hours update that only got made in one place.
Aggregate rating. Use aggregateRating only when the rating is shown on the page, current, and eligible under the structured-data rules. Marking up a rating that appears nowhere on the page breaks Google's policy, and it is the quickest way to lose rich results across the whole site.
What a correctly implemented schema block looks like
It lives in a <script type="application/ld+json"> tag in the page's <head> or just before the closing </body> tag. It's a single JSON object holding your business data in the schema.org vocabulary, and nothing about it changes how the page looks or how fast it loads. Google's Rich Results Test and the Schema Markup Validator both tell you whether it's correctly implemented.
Structured data requires maintenance and measurement
Schema goes stale like everything else on a website. Update it when your hours, number, or service area change, validate it after any site work, and read it against the visible page once a quarter. If I had to bet on which field is wrong on any given local business site, I would take opening hours. Nothing public supports the idea that leaving the same markup up for longer compounds into more mentions.
The immediate payoff is duller than the pitch: customers and machines end up with the same current facts about you. When visibility does move, write down the date and everything else that changed that month, because schema is almost never the only thing that moved.
In a seasonal market such as Portland's food cart and home services scene, accurate hours and service details matter when demand changes quickly. Measure whether target queries produce current information during the relevant season and correct any source that does not.
For Nashville's short-term rental and home services market, a good audit asks each assistant one question: does it state my service area, hours, and phone number correctly. A wrong answer is a factual gap you can go and fix today, whatever produced it.
The gap between knowing this and fixing it
Doing this properly means picking the right vocabulary, matching it to the facts on the page, validating the output, and keeping it current. Most owners have no idea what their site currently publishes, which is fair enough, because nothing on the page shows it. Go and look.
Builder settings, plugins, and custom code each produce valid markup in some hands and broken markup in others. Validate the rendered JSON-LD, hold it against your current business facts, and correct what is wrong. Being absent from an AI answer is a good reason to check the markup, and on its own it is no evidence the markup caused it.
Every Xomer website includes LocalBusiness structured data as part of the standard build. The markup covers applicable fields and service areas and is maintained with the site. Substantive mismatches between markup and current public details can confuse customers and machines, so Xomer checks names, phone numbers, and other material facts for accuracy. No ranking or recommendation effect is promised.