Structured Data for Local SEO

Three concepts need to stay separate:

1. Schema.org is a broad vocabulary for describing things such as organisations, places, people, products, services and web pages.
2. Google-supported structured data is the subset of structured-data types and properties that

Google currently documents for particular Search features.

1. Local SEO ranking is a different question. A valid schema type does not automatically create a ranking advantage, and Google does not document "adding schema" as a general direct shortcut to higher local rankings.

What structured data actually is

Normal HTML tells a browser how to display a page. Structured data adds explicit labels that describe what information means.

For example, a page may visibly show:

• a business name;
• telephone number;
• opening hours;
• a breadcrumb trail;
• an article author;
• a product or event, where that is genuinely the subject of the page.

Structured data can describe those facts using a shared vocabulary. JSON-LD is a common implementation format because the data is placed in a script block rather than woven through the visible HTML.

A very small principle-only example looks like this:

{ "@context": "https://schema.org", "@type": "Organization", "name": "Example Business", "url": "https://example.co.uk/" } That code is not a universal Local SEO template. It simply demonstrates the relationship between a visible entity and a machine-readable description.

explicit clues about page content. Google currently recommends JSON-LD in many cases because it is easier to implement and maintain, although supported formats also include Microdata and RDFa.

What structured data can do

Used accurately, structured data can help in several ways.

It can:

• make important page facts more explicit to machines;
• help describe relationships between a page, an organisation and other entities;
• make a page eligible for a Google Search feature when the page, markup and content meet that feature's current requirements;
• provide a maintainable way to keep machine-readable facts consistent with visible information;
• make technical validation easier when the markup follows a known vocabulary.

Google also states that it uses structured data to understand page content and information about entities on the web.

What structured data cannot promise

Structured data does not give you permission to make claims such as:

• "schema boosts local rankings";
• "Google loves schema";
• "adding LocalBusiness markup will push the Business Profile into the Local Pack";
• "passing the Rich Results Test means stars will appear";
• "more schema types are always better".

features. Google explicitly says that correct markup does not guarantee that a rich result will appear.

mere presence of valid Schema.org markup directly improves local rankings. If a ranking change follows a schema deployment, that sequence alone does not establish causation.

Schema.org is broader than Google's Search feature documentation

This distinction prevents a lot of poor implementation.

Schema.org contains many valid types and properties. A property can be perfectly valid Schema.org vocabulary even when Google does not provide a special Search appearance for it.

Google's own structured-data introduction tells publishers to rely on Google Search Central documentation for Google Search behaviour, while acknowledging that Schema.org contains additional vocabulary that may be useful for other systems.

So there are two validation questions:

Question 1: Is this valid Schema.org?

Use the Schema.org vocabulary and Schema Markup Validator to check structure, types and properties.

Question 2: Is this eligible for a specific Google Search feature?

Use Google's current feature documentation and Rich Results Test where that feature is supported.

Passing the first test does not automatically answer the second.

Which structured data should a local business consider?

There is no sensible universal "install these 12 schema types" checklist. The correct markup depends on what the page genuinely contains.

A local-business website commonly needs to think about four layers.

1. The website and organisation identity

The site should have a consistent machine-readable representation of the organisation behind it where appropriate. Core facts may include the organisation's name, canonical URL and other public identity information that is genuinely maintained.

Do not add fields merely because a plugin exposes them. If you cannot keep a property accurate, it may be better omitted than published incorrectly.

2. LocalBusiness where it accurately represents a physical local business

LocalBusiness is a Schema.org subtype that can describe a local business or branch. Google also documents a LocalBusiness structured-data Search feature.

However, the Google Search feature has its own current required and recommended properties. At the time of this draft, Google's LocalBusiness documentation lists a physical address as a required property for that Google feature.

That matters for service-area businesses with hidden home addresses. More on that below.

3. Breadcrumbs

If a page displays a meaningful breadcrumb hierarchy, BreadcrumbList can describe that navigation.

This is often a sensible site-wide pattern for an educational or local-business website with clear hierarchy.

The visible breadcrumb and markup should agree.

4. Page-specific structured data when the actual content supports it

A page may legitimately support another structured-data type because of what it contains. The decision should begin with the page, not with a desire to add more schema.

Examples might include supported product, event, article or other content types when the page genuinely meets the current feature requirements. Do not add Product, Review, FAQPage or any other type simply because an SEO plugin makes it easy.

For the wider relationship between content, navigation and page purpose, see Local Business Website Site Structure.

LocalBusiness markup: the principle matters more than the property list

A detailed property-by-property LocalBusiness implementation belongs in a specialist guide. The important principles here are simpler.

The markup should describe the real business users can verify. That means:

• use the real business name, not a keyword-expanded version invented for schema;
• use the canonical website URL;
• use a legitimate public telephone number if published;
• use current opening hours only where they are meaningful and maintained;
• choose a business subtype that actually fits;
• keep the machine-readable identity consistent with the visible site;
• do not create fictional branches, offices or service locations.

A useful test is: if a customer compared the structured data with the visible website and real business, would the description be honest?

If the answer is no, the implementation is wrong even if a validator accepts the syntax.

Service-area businesses: do not expose a hidden home address for schema

This is a hard privacy and accuracy rule.

A service-area business may legitimately hide its home address from customers in its Google Business Profile because customers are served at their locations rather than at the owner's home. Structured data should not be used to undo that privacy choice.

Google's current LocalBusiness rich-result documentation lists a physical address among the required properties for that specific feature. That does not mean a home-based service-area business should publish a private address just to make a test turn green.

The correct decision can be:

• keep the private address private;
• use only accurate, legitimately public organisation/business information;
• accept that a particular Google LocalBusiness rich-result implementation may not be appropriate for that page/business model;
• document the trade-off rather than fabricating a public location.

For profile configuration and public-versus-hidden business information, keep on-site structured data separate from Google Business Profile settings.

misleading or hidden from users.

a schema example or validator.

Reviews and ratings: be especially careful

Review markup is one of the most abused areas of local-business schema.

Google's current review-snippet documentation is clear that a local business or organisation is ineligible for the star review feature when the entity being reviewed controls the reviews about itself. Google gives the example of the business displaying its own reviews directly or through an embedded third-party review widget.

Google's current LocalBusiness documentation also says aggregateRating is only recommended for sites that capture reviews about other local businesses.

That means a local business should not assume that adding its Google review score to its own LocalBusiness JSON-LD will create review stars in organic Search.

Do not:

• copy a Business Profile rating into aggregateRating and promise stars;
• aggregate ratings from other websites as though they are your site's own review dataset;
• mark up fake or undisclosed incentivised reviews;
• hide review content from users while exposing only the markup;
• treat a Rich Results Test pass as a guarantee of appearance.

A business can still display genuine testimonials or reviews to help users. The separate question is whether those reviews are eligible for a Google review-rich-result feature under current policy.

Implementation: prefer maintainable accuracy

A good structured-data implementation is boring in the best sense: predictable, documented and easy to update.

Where JSON-LD is appropriate, keep the source of truth clear. If the phone number, hours or name changes, the visible page and structured data should change together.

Avoid hand-copying the same business facts into many templates unless there is a reliable process for keeping them synchronised.

A sensible implementation sequence is:

1. identify the visible fact or entity you want to describe;
2. choose the most accurate Schema.org type;
3. check whether Google documents a relevant Search feature;
4. implement only properties you can support accurately;
5. validate the code;
6. inspect the rendered page/source;
7. monitor Search Console where a supported enhancement report exists;
8. re-check after template or business-information changes.

Use the right validator for the right question

Google Rich Results Test

Use the Rich Results Test to check Google-supported rich-result structured data on a publicly accessible URL or code sample. It is useful for identifying supported items and technical errors.

It does not mean:

• the result will definitely appear;
• the page will rank better;
• every Schema.org property on the page is being assessed for all possible consumers;
• the business information is accurate simply because the syntax is valid.

Google's general guidelines explicitly state that even correct structured data may not be shown as a rich result.

Schema Markup Validator

Use the Schema.org validator when you want to inspect the wider Schema.org graph, including vocabulary beyond Google's rich-result feature set.

It can help identify syntax and modelling issues, but it does not certify Google Search eligibility.

Rendered page and source inspection

A validator is not a substitute for looking at the actual page. Check that:

• the markup is present in the rendered HTML;
• the visible information matches it;
• JavaScript or plugins are not creating duplicate/conflicting entities;
• staging code has not leaked into production;
• the canonical URL and identifiers are consistent.

Common structured-data mistakes on local-business sites

Markup contradicts the visible page

The page says one phone number; JSON-LD says another. The visible business name is normal; schema contains keyword stuffing. Opening hours changed months ago but the code was never updated.

These are data-quality failures, not SEO opportunities.

Fictional locations are added

A service-area business adds addresses for towns where it has no premises. This misrepresents the business and creates a wider local-search quality problem.

A plugin chooses the wrong entity type

Plugins are implementation tools, not editorial authorities. If a plugin marks every page as LocalBusiness, Product, Article or FAQPage without regard to the actual content, review the output rather than trusting the preset.

More markup is treated as better markup

Adding every possible property can create inconsistency. Google's own structured-data guidance prioritises complete and accurate relevant information over a larger volume of poor-quality properties.

Validation is confused with ranking

A green validator shows that certain technical requirements are met. It does not establish a ranking improvement.

Measure outcomes responsibly

If you deploy structured data, record:

• the date;
• the URLs/templates changed;
• the schema types added or removed;
• validation results;
• any relevant Search Console enhancement or search-appearance data;
• other SEO changes made at the same time.

If organic impressions, clicks or rankings later change, do not automatically write "schema caused the improvement". Several variables may have changed, and Google may use the markup for understanding without showing a visible rich result.

For LetsBuzzMedia's evidence rules, see the Methodology.

Real Project: McKnight's Flat Pack Assembly

McKnight's Flat Pack Assembly is a real service-area business based in Ballyclare, Northern Ireland. Its public website was reviewed through a live research view on 2 September 2026.

business name, telephone number, services, service areas and booking information. However, the research interface used for this draft did not expose a source-level JSON-LD block or a completed Rich Results Test result. We therefore do not claim that a particular LocalBusiness, Organization, BreadcrumbList or other schema implementation is currently live or absent.

That uncertainty is important. The correct case-study next step is a source-level audit, not an invented implementation.

Before publishing a Flat Pack structured-data example, verify:

• what JSON-LD is actually present in rendered/source HTML;
• whether a plugin or template creates additional entities;
• whether any business address is present and whether it should be public;
• whether visible business information matches the markup;
• whether Google currently recognises any supported rich-result item;
• whether review markup creates a self-serving review-policy issue.

If the audit shows missing or incomplete markup, document the planned change and its date in the McKnight's Flat Pack Assembly case study rather than backfilling a fictional history.

Key takeaway

Structured data should make a truthful page easier for machines to interpret. It is not a place to create facts that do not exist, expose private data, stuff keywords or manufacture a ranking story.

Use Schema.org to model the real entity. Use Google Search Central to understand which structured-data features Google currently supports. Use the Rich Results Test for Google-supported features and the Schema.org validator for the wider vocabulary. Then measure cautiously.

Next step

Audit the markup on one important page against the visible content and current Google documentation.

Fix accuracy first. Add another schema type only when the page genuinely contains the information that type is meant to describe.