Service Schema vs. LocalBusiness: What Really Belongs in Your Structured Data?

At a glance

Service schema and LocalBusiness schema are often confused, but they serve different purposes. Schema.org defines a Service as something an organization provides, such as delivery or printing, with key properties including provider, serviceType, areaServed, and hasOfferCatalog. Schema.org defines a LocalBusiness as a specific physical business or branch, such as a restaurant, bank branch, or medical practice. For a service page tied to one physical location, you will usually use both: LocalBusiness for the location and Service for what you provide there.

Key takeaways

• LocalBusiness requires, at minimum, a name and address: Google only accepts markup with these fields for local business rich results.
• Every location needs its own markup: if you have multiple locations, define each physical branch separately as a LocalBusiness type, according to Google.
• Service describes what you offer, not where you are: use serviceType and areaServed to clarify what you provide and where you provide it, independently of your business address.
• Reviews are not mandatory: aggregateRating within LocalBusiness is only recommended for sites that collect reviews of other local businesses, not for every company with customer testimonials of its own (Google).
• Rich results are never guaranteed: Google explicitly confirms that valid structured data does not guarantee an enhanced visual result in search.

Why is Google not recognizing my service page as a local business?

A plumbing company publishes a page with its address, opening hours, and a list of services, yet no business panel or star rating appears in search results. The information is on the page, but search engines do not interpret it as business data. That is the difference between content written for people and structured data built for machines (service pages that answer what buyers ask).

The issue is rarely the page copy itself. More often, it is missing schema markup or using the wrong type of markup. Without JSON-LD or microdata, Google sees plain text and has to guess whether an address such as "12 High Street, Bristol" is a business address, a footnote, or simply part of a paragraph. Structured data removes that guesswork by clearly identifying what each piece of information represents.

The difference between a business card and a menu

Think of LocalBusiness as your company’s business card: name, address, phone number, and opening hours. Service is the menu: what you offer, who it is for, and where it is available. A page with LocalBusiness markup alone tells search engines where you are, but not necessarily what you do. A page with only Service markup explains what you provide, but not where customers can find you. Most service businesses with a physical location need both.

What happens if you choose the wrong type?

Using LocalBusiness for a service delivered entirely online or remotely suggests that customers can visit a physical location when they cannot. On the other hand, using only Service markup for a shop or clinic with a permanent location can mean missing out on a business listing with map visibility, opening hours, and directions. In both cases, you may lose visibility that the right markup could have supported.

Which schema is right for your type of service?

The choice between Service, LocalBusiness, or a combination depends on how customers access your service.

LocalBusiness only is suitable when the location itself is central to the customer experience, such as a restaurant, gym, or retail store. Customers come to you, and the service happens on site.

Service only is a better fit for providers without a customer-facing location, or for services delivered wherever the customer is, such as a freelance copywriter, a nationwide cleaning company, or an IT consultant working remotely. In these cases, areaServed matters more than a street address.

Service nested within LocalBusiness works for most small and medium-sized service businesses: an installation company with a local office and service area, a law firm, or a physiotherapy clinic that also offers home visits. Define the location as a LocalBusiness, then add the individual services as Service objects through the makesOffer or hasOfferCatalog property.

A practical example of the fields you need

For a plumbing company with one location and a service area covering three towns, a basic and valid setup could include:

• @type: LocalBusiness or a more specific subtype such as Plumber
• name, address, telephone, openingHours
• areaServed listing the towns you serve
• hasOfferCatalog containing one or more Service objects, each with its own serviceType

This structure gives search engines and AI assistants a clear, complete picture of who you are, where you are based, and exactly what you do.

Here is how to approach it:

• First, determine whether your service is tied to a physical location or can be delivered anywhere
• Choose LocalBusiness, or a more specific subtype, when the location matters to customers
• Add Service objects through hasOfferCatalog for every distinct service you offer
• Always include your name and address, as these are Google’s minimum requirements for rich results
• Test the markup with the Rich Results Test before publishing

What does correct markup look like for a business with multiple locations?

Picture a regional physiotherapy practice with three locations in different cities. Each one has different opening hours, its own team, and a mix of shared and location-specific services.

Practical example: a hypothetical small or medium-sized service business with multiple locations

If that practice uses one generic LocalBusiness markup block for all three locations, using only the head office address, search engines receive a muddled signal. Which location is relevant to a nearby customer’s search? When businesses split this into three separate LocalBusiness objects, each with its own address, phone number, opening hours, and locally available Service objects, they often see a noticeable improvement in how frequently the relevant location appears for local searches. Exact results vary by industry and situation, but the underlying principle set out by Google is clear: define every location separately.

The takeaway is less technical than operational. If you treat structured data as something you set up once for the entire company, you miss the very benefit it is designed to deliver.

What are the real benefits of correct Service and LocalBusiness markup?

The value of accurate markup comes in two forms. First, there are the traditional rich results: business listings, opening hours, and directions shown directly in search results. Google is clear on this point: structured data is a requirement for eligibility, not a promise of visibility. Even flawless markup may not generate a rich result because Google decides what to display.

Second, and increasingly just as important, structured data makes your information easier for AI assistants to understand. When someone asks ChatGPT or Perplexity, "Which plumber in Bristol offers emergency repairs?", structured data is often easier to interpret than a few disconnected sentences buried in a paragraph. A Service object with a clear serviceType and areaServed is useful to a language model as well as a search engine, and can be far easier to parse than unstructured copy.

The growing importance of this approach is reflected in how quickly companies are adopting AI in marketing and sales. According to CBS, in 2025 one in six Dutch businesses used AI, double the figure from two years earlier, with marketing and sales named as the most common use case. Businesses that make their service pages machine-readable today are preparing for a search landscape where Google and AI assistants alike rely on structured, clearly labeled information when making recommendations.

What are the most common mistakes in existing markup?

Three issues show up repeatedly when auditing structured data.

Adding reviews without collecting them on your own site

Businesses often add aggregateRating to their LocalBusiness markup even though they do not operate a review system themselves. Google is explicit here: this property is only recommended for sites that genuinely collect reviews of other local businesses. It is not a general-purpose rating field for your own company without a supporting review system.

Using one generic address for multiple locations

As in the example above, using one shared LocalBusiness object for several locations is a common mistake. The result is that none of the locations is properly optimized for local searches because the signals become mixed.

Listing services in plain text only, not in markup

The service page may present a clear list of services for readers, but if that information does not appear as Service objects in the code, it remains unstructured. It is clear to a person, but not available as structured information to a search engine or AI assistant.

Fix these three areas and you will usually have the majority of the technical foundation in place. The rest is ongoing maintenance: keep your markup up to date when opening hours, addresses, or services change.

Frequently asked questions

What is the difference between Service schema and LocalBusiness schema?

LocalBusiness describes a physical location, including its address and opening hours. Service describes what an organization provides, such as a service or treatment. Service providers with a permanent location will often use both: LocalBusiness for the location and Service nested through hasOfferCatalog for the services offered.

Does every page on my website need LocalBusiness markup?

No. Only pages that describe a specific physical location need LocalBusiness markup. For services without a customer-facing location, use a Service object with areaServed instead.

Is an address required in LocalBusiness markup?

Yes. According to Google, a name and address are the minimum requirements for eligibility for local business rich results. Without these fields, the markup is not valid for that feature.

Does correct markup guarantee a rich result in Google?

No. Google explicitly states that it does not guarantee structured data features will appear in search results, even when the implementation is technically correct. Markup can improve eligibility, but it does not guarantee visibility.

How does Launchmind help set up Service and LocalBusiness markup?

Alex, Launchmind’s AI colleague, improves service pages with a direct answer, price guidance, process details, proof, and questions drawn from your own customer conversations, along with the structured data that Google and AI assistants can read. Once you approve it, Alex publishes the page to your own site in one click, including the appropriate Service and LocalBusiness markup for your situation.

Conclusion

Service and LocalBusiness schema are not minor technical details. They influence whether Google and AI assistants can correctly interpret your service page as a business location, an offer, or both. The rule is straightforward: use LocalBusiness for where you are, Service for what you do, and define every location separately if you have more than one. Ignore this, and you may miss out on rich result eligibility and AI visibility that are within reach through relatively small changes.

For more guidance on what a high-converting service page should include, read what belongs on a service page that actually converts. Do not want to dig into the code yourself, but want confidence that your service pages are technically sound and conversion-ready? Book a free consultation to see how Alex can create and publish service pages with the right structured data for you.

About the company

Launchmind is the AI colleague that writes, reviews, and publishes SEO content to your own blog every day, in 8 languages, then improves its work using real Search Console data. Alex also improves service pages with a direct answer, price guidance, process details, proof, and the structured data Google and AI assistants read, for marketing managers, business owners, and marketing leaders at small, medium-sized, and high-growth companies.