LocalBusiness schema: telling search engines exactly who and where you are

Everything else in local SEO involves inference. Google reads your pages, your citations, and your reviews, and infers what business you are and where. Structured data is the one channel where you state it directly, in a format built for machines.

That does not make it a ranking factor in the simple sense. LocalBusiness markup does not push you up the map pack on its own. What it does is remove ambiguity - and in a system where confidence drives which listing gets shown, removing ambiguity is worth doing.

Pick the most specific type

Schema.org gives LocalBusiness a deep subtype tree: Dentist, Plumber, Restaurant, AutoRepair, LegalService, and dozens more. Use the most specific type that fits, exactly as you would with a Business Profile category. Falling back to the generic LocalBusiness when a precise subtype exists throws away the clearest relevance statement available to you.

If nothing fits well, use LocalBusiness rather than forcing a bad subtype. A wrong type is worse than a general one.

The properties that carry weight

A minimal but genuinely useful LocalBusiness block covers:

• name - matching your canonical NAP string exactly, and matching your Business Profile.
• address as a nested PostalAddress - street, locality, region, postal code, country as separate properties, never one flat string.
• telephone - the real NAP number, not a tracking number.
• url - the canonical URL of the location page.
• geo as a GeoCoordinates pair - useful for service-area businesses in particular.
• openingHoursSpecification - structured, not prose, and kept in step with your Business Profile.
• sameAs - your Business Profile URL and your primary social and directory listings. This is the property that explicitly ties the entities together.
• priceRange, image, and areaServed where they genuinely apply.

Use JSON-LD in a script tag rather than microdata in the HTML. It is what Google recommends, it survives template edits far better, and it is readable by a human reviewing it six months later.

The mistakes that invalidate the whole block

Structured data fails quietly. The page renders fine, nothing looks broken, and the markup is simply ignored. The common causes:

• Marking up content that is not on the page. Google requires the structured data to reflect visible content. An address in JSON-LD that appears nowhere on the page is a guideline violation.
• The same block on every page. A multi-location site that stamps the head office markup site-wide tells search engines every page is the head office. Each location page needs its own.
• Address as a single string. PostalAddress exists so the components can be parsed. Flattening it defeats the point.
• Self-serving aggregateRating. Marking up your own average review score, from reviews you collected yourself, has been an explicit violation for years. Reviews on your Business Profile are already counted; do not restate them here.
• Drift. Hours change on the Business Profile and nobody updates the JSON-LD. Six months later the two disagree, which is worse than having no markup at all.

Service-area businesses

If you travel to customers and have no public premises, do not publish a full street address you do not want shown. Model it with areaServed - as named places or a GeoCircle around your base - and keep the address minimal or omitted, consistent with how the Business Profile is configured.

The rule is consistency: if the Business Profile hides the address, the schema should not broadcast it.

Validate before and after every deploy

Markup is generated by templates, and templates get edited. A change to a location page component can strip a required property without anyone noticing, and the failure is invisible in the browser.

Validate the rendered output - not the source template - after every deploy that touches a location page, and check a real URL from each location template rather than assuming one sample covers the rest.

Where this pays off next

Structured data is becoming more valuable rather than less, because the systems consuming it have multiplied. AI assistants answering "who does emergency electrical work near me" are pulling from the same entity graph that structured data feeds. An unambiguous, consistent, machine-readable statement of who and where you are is now doing work in places that did not exist a few years ago.

One location is straightforward. The next lesson covers what changes when there are twenty of them.