Structured data for local businesses: what to add and why

Structured data describes page information in a machine-readable format. For a local business, that can include the organisation, location, opening hours or another supported content type. It should express confirmed facts already represented on the website.

It is not a hidden place to add stronger claims than customers can see, and it does not guarantee rich results or AI recommendations. Start with the information and the relevant feature requirements before choosing a schema type.

Separate vocabulary from search eligibility

Schema.org provides a vocabulary for describing entities and content. Google supports particular types and properties for particular search features. A technically valid vocabulary choice is not automatically eligible for every Google presentation.

Google’s LocalBusiness documentation lists the properties used for that feature, including required name and address information. Read the current requirements for the actual business and location rather than copying another company’s markup.

If the business cannot truthfully provide a required property for a feature, do not invent it to satisfy a test. A valid business website does not need to claim eligibility for every possible rich result.

Establish a source of truth

Create a register of the facts the markup will describe. Include the value, the person responsible for it and the visible page where a visitor can verify it. This makes maintenance much easier when hours or contact details change.

Information	What to verify	Common mistake to avoid
Business name	The actual public identity	Adding service keywords to the name
Location	The genuine relevant physical location	Inventing an office for a target town
Contact details	The current business-controlled route	Leaving an old number in markup
Opening hours	The confirmed operating arrangement	Copying template hours
Service descriptions	The services actually offered	Adding unsupported categories or promises
Reviews	Authenticity and applicable feature rules	Assuming every review can generate stars

The table is a review aid, not a list of properties that every business must publish. Some information may be inappropriate for the business model or the chosen feature.

Keep markup aligned with visible content

Google’s structured-data policies require a truthful representation of the page and warn against misleading or hidden claims. The content and markup should be reviewed together.

An illustrative failure: the website says a workshop opens by appointment, while copied markup lists fixed daily opening hours. The code may parse successfully, but the information is still wrong. A syntactic validator cannot establish the truth of the business’s operating arrangements.

Use one maintained data source where practical. If the opening hours appear in the footer, contact page and structured data, the implementation should make it difficult for those versions to drift apart.

Choose a proportionate implementation

Ask the developer which type is appropriate, which properties are supported by the intended feature and how the markup is generated. Google recommends JSON-LD among its supported formats, but the format does not remove the need for accurate content.

Check whether an existing theme, plugin or shared component already outputs markup. Adding another tool can create conflicting descriptions or duplicate entities. The review should inspect the final rendered page, not only the settings screen of one plugin.

For a multi-location business, represent genuine locations accurately and ensure each relevant page explains that location. Do not create fictional branches to expand a search footprint. Our service-area guide covers the distinction between coverage and location.

Test syntax, requirements and truth separately

Use the relevant validation tools to check whether the markup can be parsed and whether supported feature requirements are met. Then review the actual facts and page context manually. Those are separate checks.

Keep a record of the tested URL, detected types, errors, warnings and the action taken. An optional recommendation may need a judgement rather than fabricated data. Fix genuine errors and document why an inapplicable field is absent.

Google explicitly notes that correct markup does not guarantee a rich result. A successful test establishes something about the implementation; it does not promise how a search result will be displayed.

Understand the limits for AI visibility

Google’s AI guidance does not require special AI schema for inclusion in its generative search features. Structured data should therefore be justified by the information and supported use case, not sold as a guaranteed route into an AI answer.

A page with valid markup but vague service content still leaves a reader with unanswered questions. Invest in clear explanations, genuine evidence and useful internal links alongside the technical description.

If an AI visibility proposal centres entirely on adding markup, ask which customer information will improve and how the claimed outcome will be measured. The AI measurement guide helps separate implementation from observed visibility.

Assign an owner after launch

Review the markup when the business changes its name, hours, location, contact arrangements or services. Include it in the maintenance checklist and verify the final output after relevant template changes.

Good structured data is accurate, consistent and maintainable. It supports a well-explained business rather than compensating for an unclear one. Explore search visibility work when you need the technical review connected to the wider website content.