Choosing schema markup for a local business site does not need to be complicated. The real issue is not whether we use one more schema type than another. The issue is whether all our schema entities are connected in a clear, logical way.
For most service pages and supporting location pages, WebPage schema or Article schema works well. Then we use the schema properties to show what the page is about, which service it describes, which business provides it, and which geographic area it targets.
That relationship is what matters. Search engines need a connected story, not a pile of disconnected JSON-LD blocks.
Table of Contents
Start With the Right Homepage Schema
A homepage often represents the business as a whole, so it should use Organization schema or a more specific subtype. For many local companies, Corporation is often a better choice than generic Organization schema.
Why? Most local businesses are for profit companies. A corporation is simply a more accurate description of that kind of entity.
There are also cases where a different Organization subtype fits better. For example, a medical clinic, physician practice, or med spa may be better represented with MedicalOrganization schema. We want to select the most specific schema type that accurately describes the business.
The goal is not to pick a schema type because it sounds fancy. The goal is to help search engines identify the real world entity behind the site.
- General company: Organization or Corporation
- Medical practice or clinic: MedicalOrganization
- Contractor: A relevant local business or construction-related subtype
- Local storefront or service area business: LocalBusiness or a suitable subtype
When the Homepage Is Also a Location Landing Page
A homepage can absolutely be a location landing page. This is common for a business with one primary location, such as a tree contractor serving a city, a local plumbing company, or a small medical practice.
In that case, the page may need to represent both the overall company and the local business location. We do not want to create two isolated schema blocks and hope search engines figure out how they relate.
Instead, we can build one connected schema instance. For example, a tree service company could combine Corporation schema with HomeAndConstructionBusiness schema. Those entities should be properly referenced together within the same structured data graph.
This tells search engines that the corporation and the local service business are part of the same entity structure. It is much cleaner than publishing one block for Organization, another for LocalBusiness, and then leaving them disconnected.
Got SEO Questions? Get answers every week at 4pm ET at Hump Day Hangouts. Ask questions ahead of time, or live – just go to: https://semanticmastery.com/hdho (bookmark this!) 10+ years of insights given every week!
Get your checklist to help get better results with GBPs, faster.
Need DFY services for you Local SEO projects? Head over to Semantic Links.
Why Disconnected Schema Blocks Create Problems
This is where many SEO implementations go wrong. We regularly find pages with multiple disconnected schema instances, such as:
- BreadcrumbList schema
- WebSite schema
- WebPage schema
- Organization schema
- LocalBusiness schema
- Other page-level markup
Using multiple schema types is not the problem. The problem is when each type stands alone with no proper relationship to the others.
Think about what that forces a search engine to do. If there are six separate schema entities on a page, all disconnected, which one is supposed to be the main entity? Which entity should have priority? How does the local business relate to the organization? How does the page relate to the service?
We should not make search engines guess when we can define those relationships ourselves.
When using several schema entities on one page, it is better to nest them into one JSON-LD script block and connect them with proper node references. We can identify the main entity of the page, then show how every other entity supports that main topic.
This is not about adding schema just to increase the amount of markup on a page. It is about creating a connected entity graph that makes sense.
The Best Schema for Service Pages
For a service page, WebPage schema or Article schema is usually the right starting point. Either can work. WebPage schema is often the simple choice because the page is clearly a page describing a service.
The main entity of the page should be the service itself. We can use the mainEntity relationship to make that clear.
A service page structure might communicate the following:
- This page is a WebPage.
- The page's main entity is a specific Service.
- The Service has a name and description.
- The Service is provided by the local business.
- The local business is referenced through its established entity ID.
For example, a roofing contractor's roof repair page should not just contain generic local business markup. The schema should show that the page is about roof repair, and that roof repair is provided by that contractor.
That is the difference between adding markup and using markup with purpose.
Use the Business Entity Reference Consistently
We recommend using a dedicated ID page URL in the @id field for the local business entity. This is often a dedicated cloud page used as the business's entity reference.
Once that ID is established, other pages can reference it. A service page can state that the service is provided by the local business, then point to that business entity using the same ID.
That helps create consistency across the site. Instead of recreating a separate version of the business entity on every page, we use the same reference and maintain a clear relationship between pages, services, and the business.
How to Mark Up Supporting Location Pages
Supporting location pages work much the same way. We can use WebPage schema or Article schema, then make the page strongly about the target location and relevant geographic entities.
For a city page, the page-level schema should make it clear that the content is about the service in that specific location. The page is still connected to the local business, but it also needs geographic context.
On WebPage schema, we can use the about property to reference the geographic focus of the page. This differs from the knowsAbout property, which may be used in Organization or LocalBusiness schema.
That distinction matters:
- knowsAbout: Helps describe topics, services, and entities the organization knows about.
- about: Helps define the subject matter of a webpage, including its geographic topic.
A properly structured location page can connect the page to the service, the local business, and the geographic area it is targeting. Again, the point is to build relationships rather than leave search engines with separate blocks of data.
Article Schema vs. WebPage Schema
There is no need to overthink the choice between Article and WebPage schema for most service and location pages. Both can be used as a catch-all page-level schema type.
What matters more is how we build the schema around that page type.
If we use WebPage schema, we should clearly define:
- The page title and description
- The main entity of the page
- The service being discussed
- The business that provides the service
- The geographic entities relevant to the page
- The author, publisher, and other appropriate page relationships
We may also include references for people, significant links, publishers, and other relevant entities when they belong on the page. The right structure depends on the page and business, but every piece should support a clear entity relationship.
Schema Is a Connected Entity System
The biggest takeaway is simple. Do not treat schema as a set of separate checkboxes.
We do not need one disconnected schema block for the company, another for the local business, another for the page, and another for the service. We can create one connected JSON-LD graph where each entity has a job and each relationship is clear.
For service pages and location pages, start with WebPage or Article schema. Then use it to identify the main entity, connect that entity to the local business through a consistent ID, and add the correct service and geographic context.
That approach gives search engines a much clearer picture of what the page covers, who provides the service, and where that service is relevant.
Frequently Asked Questions
Should service pages use Service schema?
They can. A strong setup often uses WebPage or Article schema for the page itself, with the Service as the main entity of that page. The Service should then reference the local business that provides it.
Can a homepage use both Organization and LocalBusiness schema?
Yes, especially when the homepage also serves as the main location landing page. The entities should be combined in one connected schema graph with proper references, not published as disconnected blocks.
Is Corporation better than Organization schema for local businesses?
Corporation can be more accurate for many for profit local companies. However, we should always choose the most specific type that correctly describes the business, such as MedicalOrganization for a clinic.
What schema should a city location page use?
WebPage or Article schema is a solid choice. The page should reference the business, the service when relevant, and the geographic entities that the page is about.