What is the difference between a business location and a service area?
A business location describes where the organization operates. A service area describes where a particular service is available. Keep those facts separate in your HubSpot page content and structured data, especially when you serve customers remotely or operate across several markets.
A company based in one city can serve customers nationally without maintaining an office in every city. Publishing a delivery area does not establish a local branch. The right model begins with the actual operating arrangement, not a list of geographic keywords.
Separate the questions a buyer is asking
“Where are you based?” and “Can you help a company in my market?” need different answers. A third question, “Can I visit you?”, may have a different answer again.
| Buyer question | Fact to establish | Relevant modeling concept |
|---|---|---|
| Who is providing the service? | Organization or person responsible | Service provider |
| Where does the business operate? | Real office, branch or other location | Organization location, as appropriate |
| Where is this service available? | Approved delivery geography | Service areaServed |
| How do we access the service? | Online, telephone or physical channel | Service availableChannel, where relevant |
| Is this a separate company? | Actual legal or organizational relationship | Separate entity and appropriate relationship |
These concepts are not mandatory fields for every page. Use them when they help describe the real arrangement. A street address should not be invented to make a remote service appear local.
Write the geography in ordinary language first
For a fictional example, Northbridge Operations is based in Toronto and provides remote HubSpot onboarding to Canadian businesses. Its service page could say: “We deliver this onboarding service remotely for businesses in Canada. Our team is based in Toronto; this service does not include on-site delivery.”
That description distinguishes the team's base, customer eligibility and delivery method. If an office does not receive visitors, do not imply that it is a walk-in location. If on-site work is available only by separate agreement, explain that condition beside the service.
Check each service independently. A company may provide remote consulting nationally but on-site training only in a defined area. Copying a company-wide coverage claim into every service can erase that distinction.
Model the service area without creating a fictional branch
Schema.org's areaServed property describes the geography served. It can use a relevant place or administrative area. For the fictional service, a small example is:
{
"@context": "https://schema.org",
"@type": "Service",
"@id": "https://example.com/services/onboarding#service",
"name": "Remote HubSpot onboarding",
"provider": {
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Northbridge Operations"
},
"areaServed": {"@type": "Country", "name": "Canada"},
"description": "Remote onboarding for Canadian businesses. On-site delivery is not included."
}
The code expresses service coverage. It does not assert an office in every Canadian city. Replace all fictional values and keep the public page consistent with the markup. See the Service schema guide for a fuller description of the service itself.
Add the office as a Place, not as the service area
Suppose the fictional company also publishes an accurate statement that its office is in Toronto. Keep that office separate from the Canadian service coverage. The following is an excerpt to merge into the existing graph, not a second competing company record:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Northbridge Operations",
"location": {"@id": "https://example.com/#toronto-office"}
},
{
"@type": "Place",
"@id": "https://example.com/#toronto-office",
"name": "Northbridge Operations Toronto office",
"address": {
"@type": "PostalAddress",
"addressLocality": "Toronto",
"addressCountry": "CA"
}
}
]
}
Combined with the Service example, the model says: the organization has a Toronto location; that organization provides the service; and the service is available in Canada. It does not create a Canadian network of branches or promise walk-in access. The location is a Place, so it does not need parentOrganization. The abbreviated address illustrates locality only; it is not a complete LocalBusiness rich-result example.
Replace the fictional facts and confirm the visible office information before using the pattern. Follow the schema-validation workflow to check syntax, relationships, page agreement and applicable search-feature requirements separately.
Decide whether a location needs its own entity
For a real local branch, record the name, address, contact route, opening information where applicable and relationship to the organization. Choose a specific LocalBusiness subtype only when it accurately describes the business. A local branch and a separately incorporated subsidiary may need different models.
Do not automatically assign parentOrganization to a building. That property describes a relationship between organizations. A physical place can be a location without being a separate company. Schema.org's location and parentOrganization definitions help distinguish these roles.
The business graph guide shows how to give distinct entities stable identities. Keep a note explaining why each location or organization exists in the model so future editors do not merge them by name alone.
Give location pages a distinct job
Create a dedicated page when a location or market has distinct information of its own: a real branch, different delivery conditions, local contact details or other substantial facts. Do not create dozens of near-identical pages simply by swapping city names.
When several pages discuss the same service, identify which page owns the general scope and which explains the location-specific conditions. Link between them. Keep the shared service facts consistent while making genuine differences clear.
For a HubSpot site, check whether location content comes from shared modules, page fields or a data-driven template. A copied page can retain an old phone number or office description even after its heading changes. Review the full output, including schema and contact links.
Verify the customer journey for each location
Ask someone to use the live page to determine eligibility, delivery method and the next contact step. Confirm that the contact destination serves the location or service described. Review third-party profiles where they affect the same buying decision, following the business-fact consistency guide.
After a move, closure or coverage change, update the affected pages and markup together. Record unresolved external corrections. Technical validity cannot establish that an office is real or that a service is available in a market; those facts need an accountable owner.