What Is LocalBusiness Schema?

LocalBusiness is a subtype of Organization and Place. It is designed for a business users can associate with a physical location or a genuine local service operation. A restaurant, dental office, repair shop, hotel or retail branch may qualify. A software company with only a registered office and no local customer experience usually belongs under Organization instead.

The markup expresses facts already visible and supportable. It does not create a location, verify a listing, make an address public safely or guarantee local rankings. The page, business records and customer experience should agree before the structured graph is added.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Represent a real customer-facing operation.
• Keep local facts visible and current.
• Use one durable identity per location.

Primary specification: Schema.org definition for LocalBusiness.

LocalBusiness schema is a structured identity for a real local operation, not a shortcut for manufacturing geographic relevance.

A parser reads the type and properties, then evaluates whether they form a coherent local entity. A location page can identify one branch with a stable @id. The main organization can reference that branch as a department or related location, while reviews, offers or services should connect only when the relationship is accurate.

Syntax validation checks the shape of the data, not operational truth. An address can be perfectly formatted yet belong to a mailbox, former tenant or private residence. A phone number may be valid text but route nowhere. Reliable implementation therefore combines graph design, visible page evidence and recurring business-data checks.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Confirm the location is eligible.
2. Choose the most accurate subtype.
3. Map visible facts to properties.
4. Connect the branch to its parent.
5. Validate and monitor changes.

The markup works when one truthful location identity connects consistent page, contact and operating facts.

A national retailer can have one Organization node and hundreds of LocalBusiness nodes. Each store keeps its own ID, URL, hours and telephone while referencing the parent company. Conversely, a remote SaaS company may need only Organization markup even if incorporation records contain an address.

Do not duplicate the parent’s identity at every branch. Legal name, brand and corporate profiles can live on the organization; branch names, local phones and location hours belong on location nodes. When a single-site business is both company and location, the graph may still model the relationships cleanly without inventing two conflicting identities.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Separate corporate and branch identities.
• Attach local facts to the local node.
• Avoid LocalBusiness for virtual presence alone.

Use Organization for the enterprise and LocalBusiness for each genuine customer-facing location or local operation.

Specific types such as Restaurant, Dentist, AutoRepair, Hotel and Store communicate useful category context. A business with several services should select the type that best represents the location rather than stacking unrelated categories for coverage. Additional services can be modeled separately when the page and offering support them.

Type choice should match what customers encounter. A medical clinic is not automatically a pharmacy because it dispenses limited supplies, and a marketing agency is not a store because it sells services. If the business model changes, update both visible content and structured data together.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. List the location’s primary customer activity.
2. Find the closest supported subtype.
3. Check that visible page language agrees.
4. Use additional relationships only for real offerings.

The best subtype is the narrowest accurate description of the location’s real primary business.

Start with identity and contact accuracy. Use PostalAddress fields consistently, including street, locality, region, postal code and country. For US businesses, preserve the real state and ZIP format rather than translating or compressing the address into one ambiguous string.

Add latitude and longitude only after verifying the entrance or service point. Use images, price range, payment details, menus, reservations or departments only when maintained. An optional property that becomes stale can be more harmful to data quality than leaving it out.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Keep address components structured.
• Give every branch its own stable ID.
• Remove optional facts that cannot be maintained.

Prioritize durable identity and customer-critical operating facts before adding optional descriptive properties.

Each regular specification connects days of the week with opening and closing times. Split schedules can use multiple intervals. Overnight hours require careful date and time logic so the closing time belongs to the following day. A 24-hour operation should be expressed consistently with the site’s actual schedule.

Special hours prevent the normal weekly pattern from misrepresenting a known exception. They should use explicit dates and be removed or refreshed after the event. Structured hours must match the location page and operational systems; users lose confidence when search surfaces and the front door disagree.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Document the normal weekly schedule.
2. Model split and overnight periods carefully.
3. Add dated exceptions before they occur.
4. Reconcile every public hours source.

Regular hours establish the weekly pattern, while dated special hours communicate exceptions without corrupting that pattern.

A plumber may travel across several cities from one legitimate base. Those cities can describe service coverage, but they do not become branches without staffed or customer-facing locations. Conversely, a chain with three stores should not merge their addresses, phones and hours into one node merely because they share a brand.

Use areaServed at a practical scale supported by real operations. Nationwide or statewide claims should match licensing, delivery and staffing reality. For multiple locations, create one canonical landing page per meaningful branch and connect each node to the parent Organization described in Organization schema.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Do not turn service coverage into fictional offices.
• Create separate nodes for real branches.
• Connect each branch to the correct parent.

Service areas extend one operation’s reach; real branches remain separate identities with their own verifiable local data.

NAP means name, address and phone. Minor formatting differences are usually less important than factual conflicts, but consistent canonical data reduces ambiguity. The most serious errors are operational: a disconnected number, a moved address, a closed location shown as open or a service area exaggerated for keyword reach.

Another frequent problem is templating one JSON-LD block across every location without replacing all branch fields. This can make dozens of pages claim the same address or ID. Structured-data plugins also may output a second node alongside custom markup. Audit the rendered HTML rather than only the editor.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Inspect rendered structured data.
2. Compare every fact with the live location.
3. Resolve duplicate nodes and IDs.
4. Retest after template or operational changes.

Most failures come from false, stale or duplicated business facts - not from missing optional vocabulary.