Guides · 2026-10-02 · By VSNARY | Emmanuel Orta · 0 views

LocalBusiness schema for service-area businesses, checked

Google requires two properties. The other ten are where local records break: coordinates with the wrong sign, a name that differs from the listings, two nodes claiming one phone number. How to write the node, and the four checks that read it.

LocalBusiness structured data is the part of a local site that machines read most literally. A person skims past a phone number in the footer; a search engine, a map provider or an answer engine compares it with every other record of the business and decides whether they describe the same company. This guide covers how to write the node for a service-area business such as a contractor, what Google actually requires, and the four ways a node most often contradicts itself or the business's other records.

What Google requires, and what it only recommends #

Google's LocalBusiness documentation lists two required properties: name and address. Everything else is recommended: geo, telephone, url, openingHoursSpecification, priceRange, department and, for sites that review other businesses, aggregateRating and review. Two details in that documentation matter more than they look. Coordinates must carry at least five decimal places, which is roughly one metre. And review markup is meant for sites that collect reviews of other businesses, not a business marking up praise for itself.

Passing Google's Rich Results Test only proves the required properties are present and well formed. It does not compare the node with anything, so a node can pass while carrying a phone number no listing uses or coordinates in another hemisphere.

Writing the node for a service-area business #

Declare the node once in the site template, so every page emits the identical record, and refer to it from page-level nodes by @id rather than redeclaring it. A node redeclared per page with small differences is the usual source of the drift described below.

Failure one: an address with no coordinates #

A PostalAddress without geo forces every consumer to geocode the text itself, and street addresses geocode differently in different systems, particularly rural routes and new developments. ENTITY_NO_COORDINATES fires on 5.7% of scans. Add the coordinates of the address itself, taken from a map, not of the city centre.

Failure two: coordinates that contradict the address #

The commonest form is a missing minus sign. Western-hemisphere longitudes are negative, and a longitude of 104.9903 instead of -104.9903 moves a Denver address to northern China. It passes every syntax check because a positive longitude is legal. We documented a real case in a newsroom that published coordinates in China. GEO_COUNTRY_MISMATCH compares the country the coordinates fall in with the country the address names, and fires on 0.2% of scans.

Failure three: two nodes claiming one identity #

When a page carries two LocalBusiness nodes with the same telephone, the same address or the same @id but different names, a system resolving the business cannot tell which one is real. This usually happens when a theme and an SEO plugin both emit a node. ENTITY_COLLISION fires on 3.5% of scans. Before treating it as two businesses, check that it is not one node parsed twice: two blocks with an identical @id are the same record, which we learned the hard way in two nodes with the same id.

Failure four: a name that drifts from the listings #

The node says one name, the business profile says another, a directory listing carries a third. Small differences such as "LLC", "&" versus "and", or a city appended to the name are enough for record-matching systems to hesitate. NAP_NAME_DRIFT compares the node's name with the names printed on directory listings found under the declared phone number, and fires on 0.7% of scans. Pick one form, use it on the profile, the site and every listing, and change the others to match. The full name, address and phone comparison is in the NAP consistency audit.

One business, several locations #

A business with more than one office or yard should declare one node per location, each with its own @id, address, coordinates and telephone, plus one Organization node for the company that every location points to with parentOrganization. Do not give two locations the same telephone number unless the business really answers both on one line; matching systems treat a shared phone as the strongest sign that two records are one business, which is exactly the collision described above. Put each location's node on that location's own page, and the organisation node on the homepage.

For a business with no public premises, Google's business profile lets the owner hide the address and list service areas instead. The structured data should still carry the real postal address, because the address is a required property and an identity key, but the site does not have to print it for visitors. What should change is areaServed: list the cities you actually work in, not every town within a hundred miles. A long list of places with no matching pages reads as a doorway pattern, and the gap between declared areas and published area pages is something we measured on real sites in schema that lists service areas the sitemap barely covers.

Hours, price range and images #

openingHoursSpecification should match the hours on the business profile exactly, including closed days, because a mismatch is one more disagreement for a record-matching system to resolve. Use priceRange only if it is honest and stable. Add image with a real photograph of the business, its vehicles or its work, not a logo or a stock photo, and a logo property for the logo itself.

Checking your own node #

Fetch the homepage as a crawler would, extract every application/ld+json block, and read the business node as data rather than in a browser. Confirm one node, one @id, the listing name and number, coordinates with five decimals inside the right country, and the cities you serve under areaServed. The entity map validator runs the four checks above on any domain and shows which property each finding came from.

Questions this post answers

Which LocalBusiness properties does Google require?

Only name and address. Google recommends geo, telephone, url, openingHoursSpecification, priceRange and others, but a node with name and a PostalAddress meets the requirement.

How precise must LocalBusiness coordinates be?

Google's documentation says latitude and longitude must have at least five decimal places, which is about one metre.

How does a service-area business show where it works?

With areaServed, listing the cities or regions served as City or AdministrativeArea nodes. The address stays the business's real address even if it is not shown to visitors.

Why do my coordinates put my business in another country?

Usually a missing minus sign. Longitudes west of Greenwich are negative; a positive value moves a North American address to Asia while still passing syntax checks.

What is an entity collision in structured data?

Two business nodes on one page that share a phone number, address or @id but differ elsewhere, so a system cannot tell which describes the real business. Two blocks with the same @id are one node, not a collision.

Should a business mark up its own reviews with aggregateRating?

Google's LocalBusiness guidance recommends review markup for sites that collect reviews about other businesses, not for a business rating itself.

Related findings

Comments

Comments are read before they appear. Nothing is published automatically, and no account is needed.

Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.

All guides · The dataset · How the dataset works