Local Schema Markup: ServiceArea & LocalBusiness Done Right

Correct ServiceArea and LocalBusiness schema tells search engines where you work, what you offer, and how customers can contact you.

A website leaves gaps. Search engines still need to identify your address, hours, services, and coverage area from the page. Structured data puts those details into a format machines can read more consistently. Our take: schema is useful housekeeping, not a magic ranking lever. This article explains how ServiceArea and LocalBusiness schema work, where they differ, and which mistakes can make markup useless or misleading.

The examples cover basic fields, service regions, hybrid businesses, validation, voice search, and related SEO work. They use real schema properties, so you can adapt them to your own business instead of pasting a generic code block and hoping it works. That shortcut usually fails.

What is local schema markup and why does it matter for local businesses?

Local schema markup is structured data added to a website’s HTML. It gives search engines details such as a business name, address, phone number, opening hours, services, and service area. Search engines can use that information in local results, maps, knowledge panels, and other search features.

Defining local schema markup: structured data for local search

Local schema markup uses the Schema.org vocabulary. Most websites add it with JSON-LD, although Microdata is also supported. The code gives search engines machine-readable facts about a business instead of forcing them to infer those facts from ordinary page text.

For example, the markup can say, “This is a LocalBusiness,” “Its name is Smith’s Plumbing,” “Its address is 123 Main St, Anytown, USA,” and “Its phone number is +1-555-123-4567.” That reduces the chance that a search engine mistakes a phone number for an order number or a street address for a service description.

Common local types include LocalBusiness, Organization, and narrower types such as Restaurant, Dentist, AutomotiveRepair, and ProfessionalService. Each type has properties that describe the entity.

A LocalBusiness usually includes name, address, telephone, url, openingHoursSpecification, geo, and sometimes priceRange. The address normally contains a nested PostalAddress with fields such as streetAddress, addressLocality, addressRegion, and postalCode. A business that travels to customers can also describe its coverage with areaServed or serviceArea, using types such as Place or AdministrativeArea.

Imagine a bakery. Without schema, Google may see the phrase “Best Croissants in Town” and guess that the page belongs to a bakery. With schema, the site can state the facts directly:

"@type": "Bakery"
"name": "The Daily Crumb"
"address": { "@type": "PostalAddress", "streetAddress": "456 Oak Ave" }

The slogan is marketing copy. The schema identifies the business. It works.

The SEO benefit: how schema improves visibility and trust

Correct schema can make a local listing easier for search engines to interpret. It may help Google connect a business with the right address, category, hours, services, and review information. Most guides imply that adding schema improves rankings. That’s only half right. It does not guarantee a higher ranking, and schema will not repair a weak business profile or poor page content.

Suppose someone searches for “plumber near us.” One listing may show a phone button, opening hours, and review information, while another shows only a name and address. The first gives the searcher more useful information before they visit the site. That can lead to more clicks, especially on a phone.

Schema can also reduce uncertainty. Is this overkill? For a 50-page site, no. A customer can see whether the business is open, whether it serves the right area, and how to contact it. If the site includes valid rating data such as "ratingValue": "4.8" and "reviewCount": "125", Google may use that information in eligible search features. The reviews must be genuine, visible, and supported by Google’s rules.

Voice assistants and answer systems also need clear facts. When someone asks, “What time does the nearest Italian restaurant close?” the system needs a reliable business name, location, cuisine, and schedule. Schema can provide those fields, although the assistant may also use Google Business Profile data and other sources.

Think of schema as a label attached to information already on the page. It makes that information easier to read. It does not turn an unknown business into the best result in town. Honestly, the boring accuracy work matters more than clever markup.

How do ServiceArea and LocalBusiness schema differ, and when should each be used?

LocalBusiness describes a business, especially one with a location where customers can visit. A restaurant, shop, clinic, or salon would normally use it. A service area describes the places a business serves. Plumbers, electricians, cleaners, and mobile detailers often need both a business type and a defined service region.

Understanding LocalBusiness schema: physical locations and direct customer contact

LocalBusiness fits a business that operates from a fixed address. Examples include a retail store, restaurant, doctor’s office, or hair salon. Its markup can describe the address, coordinates, phone number, website, opening hours, and products or services available at that location.

The main fields include address, geo, openingHoursSpecification, telephone, and url. The address should use a PostalAddress object with separate fields for the street, city, region, postal code, and country.

A coffee shop in downtown Seattle might list its exact address, latitude and longitude, and hours from 6:00 AM to 7:00 PM. That gives search engines enough information to place it on a map, offer directions, and show whether it is open. The point is simple: customers visit the business at that address.

Using ServiceArea schema for businesses that travel to customers

A service business often works differently. The customer does not visit a storefront. The plumber goes to the house. The cleaner goes to the office. The mobile detailer drives to the customer’s driveway.

ServiceArea describes the region where those services are available. It can appear within a LocalBusiness or Organization entity. The region may be a city, county, group of postal codes, radius, or irregular boundary.

A plumbing company based in Phoenix might serve customers within 50 miles of its office. It could also name cities such as Scottsdale, Tempe, and Mesa. That tells search engines that the office is in Phoenix while the service extends beyond the office address.

Counter to the usual advice, the most detailed geometry is not always the best implementation. The exact properties depend on the implementation. A business might use a GeoCircle for a radius, a GeoShape for a polygon or bounding box, or a named Place or AdministrativeArea. The service area should match reality. If the company does not send technicians to a city, it should not claim that city in its markup.

What properties belong in a LocalBusiness schema implementation?

Start with the business name, address, phone number, and official URL. Add hours, coordinates, reviews, departments, and service information when those details are accurate and visible on the site. More fields do not automatically make the markup better. Empty, outdated, or invented properties create noise.

Core LocalBusiness properties: name, address, phone, and website

The name property should use the business’s real name. It should match the name on the sign, official documents, Google Business Profile, and other important listings. If the legal name is “Smith’s Plumbing & Heating LLC,” do not switch between that name, “Smith Plumbing,” and “Smith’s Plumbers” without a good reason.

The address property should use PostalAddress. Break the address into its parts:

streetAddress: “123 Main St”
addressLocality: “Anytown”
addressRegion: “CA”
postalCode: “90210”
addressCountry: “US”

Check those values against the Google Business Profile. A wrong postal code can place the business in the wrong area. A business with several branches should give each branch its own LocalBusiness entity and address.

The telephone property should contain a public business number, preferably in international format such as +1-555-123-4567. The url should point to the official website. For a multi-location business, use the location’s own landing page when one exists.

Name, address, phone, and URL identify the business. The rest of the schema builds on those facts. Skip this step.

Adding reviews, opening hours, and department information

The aggregateRating property can describe an average rating and review count. For example, "ratingValue": "4.8" and "reviewCount": "150" may help Google understand the rating shown on the page. Use current data from a legitimate source. Do not copy ratings from another site or mark up reviews that visitors cannot see.

openingHoursSpecification describes the weekly schedule. A typical object might include:

"dayOfWeek": "Monday"
"opens": "09:00"
"closes": "17:00"

You can add separate entries for weekends, holidays, and split shifts. A restaurant that closes for lunch, for example, needs more than one interval on the affected day. Accurate hours keep a customer from arriving at a locked door after trusting the listing.

The department property is useful for larger businesses with separate units. A hospital might describe a pharmacy with its own phone number and 24-hour schedule. A department store might list its pharmacy or auto service department separately. Each department should represent a real part of the business with information that appears on the site.

How can ServiceArea schema define a service region?

A service region can be described with a named place, a geographic shape, or a radius around a point. Choose the format that matches how the business actually works. A neat-looking radius is not useful if the company skips half the area because of travel time or local restrictions.

Specifying service areas with GeoShape, GeoCircle, and GeoMidpoint

A business covering a city or county can use GeoShape. The box property describes a rectangle, while polygon can follow a less regular boundary.

A plumbing company serving San Diego County might name the county and include bounding coordinates such as 32.5341,-117.2897 33.5072,-116.0829. A box is easy to create, but it may include places the company does not serve. A polygon takes more work and can follow actual neighborhood or municipal borders.

GeoCircle works well when the service has a reasonably consistent radius. A mobile detailing company operating within 20 miles of downtown Austin could specify a geoMidpoint with Austin’s coordinates and a geoRadius of “20 miles.” Use one unit consistently. Do not mix miles and kilometers in the same definition.

GeoMidpoint can describe a central service point, although it does not replace a clearly defined area when the business serves a broad region. A pest control company covering several counties might need multiple shapes. A pizza shop with a delivery zone might use one circle or polygon.

Accuracy matters more than complexity. A false service area can produce irrelevant impressions, poor leads, and annoyed customers.

Combining ServiceArea with LocalBusiness for hybrid businesses

Some businesses have a customer-facing location and also travel to customers. A dental practice may have an office but send staff to nursing homes within 50 miles. In that case, the LocalBusiness entity describes the office. The ServiceArea property describes the mobile service.

An example might look like this:

"serviceArea": { "@type": "ServiceArea", "geo": { "@type": "GeoCircle", "geoMidpoint": { "@type": "GeoCoordinates", "latitude": "30.2672", "longitude": "-97.7431" }, "geoRadius": "50 miles" } }

The address supports searches for a nearby dental office. The service area supports searches for mobile dental care in the surrounding region. Both facts describe the same business, so they should sit within the same entity and agree with the visible page content.

A restaurant with dine-in service and delivery has a similar setup. LocalBusiness describes the restaurant’s address, hours, and contact details. ServiceArea describes the delivery zone, perhaps with a polygon that follows neighborhood boundaries.

Keep the relationship clear in the markup. A delivery area should not suggest that the restaurant delivers 40 miles away if its drivers cover only a few nearby neighborhoods.

What common mistakes should be avoided with local schema markup?

Common problems include keyword stuffing, inaccurate service areas, old schema types, missing fields, and invalid JSON-LD. Search engines may ignore markup that does not match the page. Misleading markup can also create policy problems.

Avoiding schema spam and irrelevant data

Schema spam usually starts with good intentions. A business adds every possible keyword and property, hoping more markup will mean more visibility. It does not work that way.

Do not fill a description with phrases that never appear on the page. Do not mark every word as a Product. Do not hide content from visitors and expose it only through schema. Google’s guidelines require structured data to describe visible, accurate page content.

A plumbing company should not describe itself as a Restaurant or MedicalOrganization. Less obvious problems arise when a contractor lists every service as a separate entity on the homepage even though those services have their own pages. The homepage can describe the main business and perhaps a general service. Individual pages can describe roof repair, deck building, or kitchen remodeling in more detail.

Do not claim services or locations that the company does not provide. A business that marks up a city it does not serve may receive irrelevant traffic, lose trust, or have its markup ignored. Every marked-up fact should be accurate, relevant, and visible on the related page. Yes, this is less exciting than adding twenty properties. It is also safer.

Troubleshooting validation errors

Google’s Rich Results Test is a useful first check. Before using it, run the JSON-LD through a JSON validator. Missing commas, extra brackets, and spelling errors can stop the whole script from being read. A typo such as streetAddresss instead of streetAddress is small but fatal to that property.

Check the type as well as the syntax. An older site may use Organization where LocalBusiness or a more specific type such as Dentist, Restaurant, or AutomotiveRepair would be clearer. Use the most specific valid type that fits the business.

Properties also need the right format. An address should normally be a PostalAddress object, not a single unstructured string. A geo object should contain valid latitude and longitude values.

Missing fields can cause warnings or prevent eligibility for certain search features. Check name, address, telephone, and hours for a physical business. For a service region, define areaServed or the relevant geographic property with a real Place, AdministrativeArea, or GeoShape.

Finally, test every URL used in url, image, and hasMap. A broken link makes the markup less useful and may prevent the associated resource from being connected to the business.

How does local schema affect voice search and AI answer engines?

Structured local data gives voice assistants and answer systems clear fields to use when responding to questions about hours, services, phone numbers, and locations. It can improve the chance of a correct answer, but it does not guarantee that an assistant will choose one business over another.

Using schema for direct voice answers

Voice assistants such as Google Assistant, Alexa, and Siri need concise facts. When someone asks for the nearest Italian restaurant’s phone number, the system is not likely to read an entire webpage from beginning to end. It looks for signals from structured data, business profiles, maps, and other sources.

A LocalBusiness entity with telephone, openingHoursSpecification, address, and servesCuisine gives the system useful fields to compare. A plumbing company can describe emergency work with serviceType and define its coverage with ServiceArea. That may help with a query such as, “Find an emergency plumber near us.”

Review data can also answer a narrow question. If the page shows a valid aggregateRating with a rating of 4.8 from 150 reviews, an assistant may report those figures. It may still use other sources, so the numbers need to agree across the business profile, website, and review platform.

Why does this matter? Because a customer wants an answer immediately, particularly on a phone. Schema reduces guesswork. It does not control the answer.

Featured snippets and knowledge panels

Structured data can support the information Google displays in rich results, featured snippets, and knowledge panels. It does not guarantee any of them. Google chooses results using many signals, including the page, the business profile, relevance, and user intent.

A service page might use Service schema to describe emergency oil changes, prices, or coverage. If the information is clear and visible, Google has more context for questions such as, “What services does this auto shop offer?” or “How much does an oil change cost?”

Knowledge panels often draw heavily from Google Business Profile data, but website schema can help confirm the business identity. Useful properties may include url, image, logo, sameAs, areaServed, and geo.

A business name search might show an address, phone number, hours, reviews, and map without requiring a visit to the website. That is convenient for the customer, but it also means each field needs regular maintenance. If the business moved last month and the schema still lists the old address, the extra markup creates confusion.

What tools can validate local schema implementations?

Use Google’s Rich Results Test to check eligibility for Google’s supported rich results. Use the Schema Markup Validator to check the broader Schema.org vocabulary and syntax. Larger sites may also use crawlers or SEO platforms to find repeated errors across many pages.

Google’s Rich Results Test and Schema Markup Validator

Google’s Rich Results Test accepts a URL or pasted code. It reports detected structured data, errors, warnings, and possible rich result features. If a LocalBusiness entity lacks a required field for a particular result, the tool usually identifies the problem.

It can also confirm that a service region is being read. The tool will not decide whether a 50-mile radius reflects the real business, but it can show whether the markup parses correctly.

The Schema Markup Validator checks the code against Schema.org. It does not promise that Google will display a rich result. It checks whether the vocabulary and structure make sense. For example, it can verify that openingHoursSpecification contains dayOfWeek, opens, and closes, and that geo contains latitude and longitude.

Use both tools for different jobs. The Rich Results Test checks Google’s supported features. The Schema Markup Validator checks the underlying schema. Our take: run both before publishing, then run them again after a template change.

Third-party tools for larger audits

Third-party tools can help when a site has dozens or thousands of pages. Schema App, Merkle’s Schema Markup Generator, SEMrush, Ahrefs, and Screaming Frog offer different combinations of generation, crawling, validation, and reporting.

Schema App can help build larger schema graphs and find relationships between entities. Screaming Frog can crawl a site, extract markup, and show which pages have missing or invalid fields. That is useful for a chain with many locations, where checking each page by hand would take too long.

Some platforms compare your markup with competitor pages. That can reveal missing information, but copying a competitor is not a strategy. If another company uses hasOfferCatalog or makesOffer, add those properties only when they describe real content on your own site.

Reports and historical checks can show when a template change breaks markup across the site. That kind of monitoring is more useful than adding another decorative property to one page.

How can local schema work with other SEO strategies?

Schema works best when it agrees with the rest of the business information. Keep the name, address, phone number, hours, categories, services, and coverage areas consistent across the website, Google Business Profile, maps, and local directories.

Connecting schema with Google Business Profile

Google Business Profile is usually the main local listing. The website’s LocalBusiness data should match it closely. If the profile says the business is open until 7:00 PM, the website should not say 5:00 PM. If the profile lists Plumbing Services, the page should describe plumbing work rather than quietly switching to another category.

A business might use serviceType set to “Plumbing” and link hasOfferCatalog to a page that lists its actual services. A service-area business can also align areaServed with the areas shown in its business profile.

Reviews need extra care. Use rating and review markup only when the reviews and ratings are visible on the page and comply with Google’s rules. Do not add review schema simply because the business has reviews somewhere else.

Connecting schema with local content and links

Location pages and service pages can use schema that matches their content. A local event may use Event. A service page may use Service with areaServed. A local article may use Article or BlogPosting.

That context helps search engines understand what a page is about and where it applies. It does not replace useful writing, local evidence, or links from relevant sites.

The sameAs property can connect the business entity to genuine social profiles, business listings, and other official pages. Use it for identity, not for a long collection of unrelated links.

Schema, local content, and links should describe the same business. When they disagree, the inconsistency matters more than any single missing property.

What future changes should local businesses watch?

Local businesses should watch changes to Schema.org, review properties, product types, and the way search systems use structured data. The vocabulary changes over time, while search engines may change which fields they display or support.

New schema types and possible uses in local SEO

Schema.org continues to add and refine types. <Product> and <Offer> are already common, while types such as <ProductGroup> may help businesses describe related products in more detail.

A bakery could describe a wedding cake collection rather than marking up only one cake. The page might explain serving size, number of tiers, price, and customization options. A plumber could use <Service> to describe emergency calls, drain cleaning, or installation packages.

Review markup may also become more detailed. Future tools could describe which part of a business a review discusses, such as customer service, gluten-free food, or outdoor seating. That would help answer more specific questions, provided the review data supports the claim.

Event and job posting markup will remain useful for businesses trying to attract local customers or employees. Follow the current documentation and update the implementation when the vocabulary changes.

AI search, semantic search, and business relationships

Search systems are getting better at understanding relationships between entities. A bookstore is not only a store. It may sell books, host author events, work with local writers, and receive reviews from nearby customers.

Schema can describe some of those connections. The bookstore might link <Book> entities to <Author> entities and use <Event> for signings. A gym might connect its <Service> pages for personal training with <Person> data for its trainers and <Offer> data for memberships.

Those links give an answer system more context for questions such as, “Which gyms near us have certified trainers who specialize in weight loss?” They do not make unsupported claims true. Each relationship still needs to appear in the site’s content and reflect the real business.

<AboutPage> and <ContactPage> can also identify important pages. Keep the structure understandable. Schema should help a system represent the business, not turn the website into a pile of disconnected properties.

Frequently asked questions

How does ServiceArea markup help businesses with multiple locations or service regions?

It tells search engines where the business actually works. A company can describe each branch with its own LocalBusiness entity and use service-area data for the regions covered by that branch. This helps prevent every location from being treated as if it served only the address on its page.

What is the difference between LocalBusiness markup for one location and for several locations?

A single-location business usually needs one entity with one address, phone number, and schedule. A multi-location business should create a separate LocalBusiness entity for each branch, with its own page, address, phone number, and hours. Keep the information consistent, but do not copy one branch’s details onto every other page.

Can incorrect LocalBusiness or ServiceArea markup hurt organic rankings?

It can. Keyword stuffing, fake service areas, hidden content, and incorrect business types may cause search engines to ignore the markup. Misleading information can also produce bad customer experiences. Accurate markup does not guarantee rankings, but inaccurate markup can make the site harder to trust.

Which advanced LocalBusiness properties are most useful?

Useful additions include openingHoursSpecification for detailed schedules, hasMap for a map link, aggregateRating when the rating is supported and visible, and makesOffer for genuine products or services. Add them when the page contains the same information. A shorter, accurate schema is better than a large block filled with guesses.

How should LocalBusiness and ServiceArea markup be tested?

Run the URL or code through Google’s Rich Results Test, then check it with the Schema Markup Validator. Fix syntax errors first, review the warnings, and compare every field with the visible page and business profile. Test again after changing templates, addresses, hours, or service regions.