UK Local Business Schema: Copy Ready JSON LD and 5 Pre Launch Checks

Use LocalBusiness schema implemented as JSON-LD on the page that represents your business. It helps search engines understand your business and makes you eligible for richer results. That means adding core properties and an @id to your canonical page, then validating with the Rich Results Test and keeping an eye on Search Console for eligibility issues.

TL;DR:

• Proper implementation of JSON-LD LocalBusiness schema requires setting a specific subtype and ensuring the @id matches the canonical URL without redirects.
• Including only essential properties like name, address, telephone, URL, and hours boosts eligibility for rich results without risking errors.
• Multi-location organizations should use @graph to link individual local entities to a parent organization, with each having its own @id and address.
• Validation should be a continuous process, run before and after changes using Google’s Rich Results Test and Search Console to prevent markup drift or errors.
• Schema data must always reflect visible page content, with consistent NAP details and reviews only marked up if they are actually displayed on the website.

Table of Contents

• How do you build and place JSON-LD LocalBusiness markup?
• What properties do you need, and what should you add?
• Copy-ready JSON-LD examples for common business types
• Modelling multi-location businesses and service offerings correctly
• How do you validate the markup and fix common errors?
• Policy notes and keeping schema accurate over time
• A practical audit checklist before you go live
• Where schema fits into a wider local SEO approach
• How Hook Digital can help you get this right
• Sources
• FAQ

How do you build and place JSON-LD LocalBusiness markup?

Getting the markup right starts with structure, not content. Every JSON-LD script begins with two declarations that tell search engines what vocabulary you are using and what kind of entity you are describing.

Start with @context set to https://schema.org and @type set to LocalBusiness or, better still, a more specific subtype. Schema offers dozens of subtypes, such as Restaurant, DaySpa or HealthClub, and choosing one that matches your business gives search engines a sharper signal than the generic type alone. If none of the subtypes fit precisely, LocalBusiness itself is a safe, valid choice.

Your @id matters more than most business owners realise. It should be the canonical URL of the page the markup describes, often with a fragment such as #business appended so other markup on the same page can reference it without ambiguity. Industry guidance on structured data implementation recommends using the canonical homepage or location URL as the entity’s identifying URL, making sure that URL is trawlable, and keeping the markup on the exact page it describes rather than a shared template that serves unrelated content.

Here is the build sequence most practitioners follow:

1. Confirm the canonical URL for the page you are marking up, and check it resolves without redirects.
2. Write the JSON-LD script with @context, @type and @id first, then add the core properties covered in the next section.
3. Insert the script into the page’s <head> or immediately before the closing </body> tag, depending on what your CMS supports.
4. Test the markup on a staging copy of the page before it goes live.
5. Publish, then re-test the live URL with the Rich Results Test.

Placement inside a content management system depends on what access you have. WordPress sites can usually add JSON-LD through a theme’s header.php file, a dedicated custom field plugin or a template partial that loads on the relevant page type only. Shopify and other hosted platforms often require a theme file edit or a dedicated app. Whichever route you take, the safest pattern is a single template partial that every location or service page inherits, rather than copying and pasting the script into individual pages. Duplicated scripts are the most common source of markup drifting out of sync when a business updates its opening hours or phone number in one place but not another.

For businesses with more than one entity to describe on a page, such as an organisation and its individual departments, @graph lets you bundle multiple related types into a single script. Each entity gets its own @id, and you connect them by referencing that @id from a property such as parentOrganization or department. This avoids the need for several separate <script> tags and keeps the relationships between entities explicit rather than implied. A @graph structure is particularly useful for multi-location businesses, which we cover in more detail later in this guide.

One CMS trap worth flagging early: template regressions. If a developer edits a shared header file for an unrelated reason, it is easy to accidentally break or duplicate the schema script across every page that inherits it. Keeping schema in its own clearly labelled partial, separate from analytics tags and other head scripts, makes it easier to spot and fix when something goes wrong.

What properties do you need, and what should you add?

Search engines need a baseline of information before they can do anything useful with your markup, and a shorter list of recommended fields that strengthen how your business appears in richer results.

The following properties are the ones you should treat as non-negotiable:

• name: the exact legal or trading name of the business, matching what appears on the page.
• address: a nested PostalAddress object with streetAddress, addressLocality, postalCode and addressCountry.
• telephone: the number in a consistent, dialable format, matching what is displayed on the page.
• url: the canonical URL of the business or location page.
• openingHoursSpecification or openingHours: the days and hours you are open, using the correct time format.

Google’s documentation on LocalBusiness structured data sets out these fields as the ones Search relies on to understand a business listing, and confirms that structured data helps Search understand content and can make pages eligible for richer features, though it does not itself guarantee a ranking improvement. Implement schema once your visible content and Google Business Profile are accurate, not as a substitute for getting those right first.

Beyond the essentials, a handful of recommended properties round out the picture and can strengthen how your listing appears:

• sameAs: links to your verified social media profiles and other authoritative pages about the business.
• image: a representative photo of the business, logo or premises, hosted at a stable URL.
• priceRange: a simple indicator such as ££ to set customer expectations.
• paymentAccepted: the payment methods you take, such as cash or major card schemes.
• email: a monitored contact address, if you display one publicly.
• geo: latitude and longitude as a GeoCoordinates object, useful for map-based results.
• aggregateRating: only when genuine, visible ratings appear on the same page.

Formatting details trip up more implementations than missing properties do. Currency values should use ISO 4217 codes such as GBP rather than symbols alone. Language tags follow BCP 47, so British English content uses en-GB. Opening hours use 24 hour time and the schema.org convention of 24:00 to represent midnight at the end of a day, written as a range like Mo-Fr 09:00-17:00.

A quarter of local search visibility factors tracked by industry surveys relate directly to structured data and NAP accuracy in schema, according to the Local Search Ranking Factors research referenced across the SEO industry, underlining why getting these fields right is worth the time it takes.

Copy-ready JSON-LD examples for common business types

Three patterns cover almost every local business scenario: a single location, a service provider working across an area, and a multi-location organisation with branches.

A simple single-location listing needs only the core properties nested correctly:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.co.uk/#business",
  "name": "Example Bakery",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 High Street",
    "addressLocality": "Oxford",
    "postalCode": "OX1 1AA",
    "addressCountry": "GB"
  },
  "telephone": "+44 1865 000000",
  "url": "https://example.co.uk",
  "openingHours": "Mo-Sa 08:00-17:00"
}

Service businesses that work across a region rather than serving people at a fixed shopfront need a different pattern. Guidance on modelling services with structured data recommends describing the organisation with LocalBusiness and each significant offering with a separate Service entity, linked by provider, with areaServed set to a place, administrative area or plain text rather than packing service names into the business name itself:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "Boiler repair",
  "provider": {
    "@id": "https://example.co.uk/#business"
  },
  "areaServed": {
    "@type": "AdministrativeArea",
    "name": "Oxfordshire"
  }
}

Multi-location businesses gain the most from @graph. Each branch gets its own LocalBusiness entity with a branchCode, and every branch references the parent through parentOrganization:

The properties that matter most across all three patterns stay consistent:

• Every entity needs its own @id so relationships between them are unambiguous.
• Address fields always use the nested PostalAddress structure, never a single flat string.
• Service entities describe what you do, LocalBusiness entities describe where and who you are.

Copying these templates directly and swapping in your own details is the fastest route to a working implementation, provided you validate the result before publishing.

Modelling multi-location businesses and service offerings correctly

Chains, franchises and multi-department organisations need a slightly different structure from a single shopfront, and getting the relationships wrong creates confusing or duplicate listings.

Use parentOrganization together with individual LocalBusiness branches whenever a group operates from more than one address under one brand. Each branch is a separate entity with its own address, phone number and opening hours, connected back to the parent by referencing the parent’s @id. Schema.org’s LocalBusiness documentation supports this pattern through the branchOf and parentOrganization properties, and it mirrors how a store locator typically works on the front end, each location page mapping to one schema entity.

branchCode gives each location a short internal identifier, useful when a business already assigns codes to its branches for logistics or booking systems. It has no direct effect on how a listing displays, but it does help keep multiple branches distinct when a graph contains several similarly named locations.

Services deserve their own entities rather than being folded into the business name or description. A Service type, linked to its provider and using hasOfferCatalog for a structured list of what you offer, gives search engines a much clearer picture than a business name padded with keywords. areaServed then defines the geography that Service covers, whether that is a named region, a radius or a list of towns.

One type to retire from your thinking: ProfessionalService. Schema.org has deprecated it as a catch-all, and the guidance now points toward a specific LocalBusiness subtype or a dedicated Service entity instead. Reaching for the most specific type available, rather than a generic fallback, consistently gives search engines a better signal to work with.

How do you validate the markup and fix common errors?

Validation is not a one-off task. It is a workflow you repeat every time the markup or the page around it changes.

1. Run the live URL through Google’s Rich Results Test before and after any deployment, checking for both syntax errors and eligibility warnings.
2. Open Search Console’s structured data reports for the relevant page type and check for a rise in errors following any template change.
3. Confirm the markup sits on the exact page it describes. Schema placed on a shared template that serves multiple unrelated pages is a frequent cause of mismatched or duplicated entities.
4. Check every required property is present and correctly typed. Missing address fields or a malformed openingHours string are the most common reasons a listing fails eligibility despite valid JSON syntax.
5. If review or rating markup is present, confirm the reviews are genuinely visible on the page. Google’s documentation on local business structured data notes that syntactically valid markup can still fail eligibility when it breaches a policy such as this one.

Mismatched canonical tags and @id values are worth checking specifically. If your canonical URL points to one version of a page and your @id references another, search engines may struggle to connect the two, and eligibility for rich results can suffer as a result. CMS template regressions, where an unrelated edit strips or duplicates the script, are best caught by re-running the Rich Results Test after any development work touching shared templates, not just after schema-specific changes.

Once you have fixed an issue, use Search Console’s URL inspection tool to request re-crawling of the affected page rather than waiting for the next scheduled crawl. This speeds up how quickly Google reflects the correction in its reports, though it does not guarantee an immediate change in how the page displays in results.

Pro Tip: Keep a simple staging environment for schema changes, run the Rich Results Test there first, and only push to production once it passes cleanly. This one habit, similar to the staged approach described in our guide on testing and validating site changes, catches most template regressions before they reach live pages.

Policy notes and keeping schema accurate over time

Schema markup only works in your favour when it matches what a visitor actually sees on the page. Marking up content that is not visible, or content copied from a third-party source, breaches Google’s guidance and risks eligibility issues.

Keep these points in mind as ongoing practice rather than a one-time checklist:

• Match every marked-up field to visible page content: if openingHours says you close at 18:00, the page itself should say the same.
• Never mark up review excerpts pulled from another site or platform; Google’s guidance on review markup limits eligibility to sites that are the actual publisher of the reviews shown.
• Only add aggregateRating when genuine ratings are visibly displayed on the same page, with a rating value and count that match what a visitor can see.
• Keep name, address and phone number synchronised across your website and your Google Business Profile, since inconsistency between the two is one of the more persistent local visibility issues businesses run into.
• Version control your schema templates the same way you would any other code, so a bad rollout can be reverted quickly rather than debugged live.

Schema and accurate NAP data in JSON-LD are named among the notable factors industry surveys tracked in the 2026 Local Search Ranking Factors research, reinforcing that this is maintenance work worth scheduling rather than a task to complete once and forget. Reviews are worth handling with particular care. Our guide to managing reviews well covers the display side of this in more depth, and the same principle applies to schema: only mark up what is genuinely there.

A practical audit checklist before you go live

Before publishing, work through five checks: the canonical URL matches your @id, NAP details are visible on the page and not just in the markup, your Google Business Profile matches what the schema says, your CMS gives you a reliable way to insert or edit the script without breaking other pages, and any review markup reflects reviews that are actually visible.

The most common CMS trap is a shared template that silently duplicates or strips the script during unrelated edits, so a developer sign-off on any template change touching the head or footer is worth building into your process. A straightforward single-location implementation typically takes a competent developer a few hours from writing the JSON-LD to validating it live. Multi-location or service-heavy sites take longer, mainly because of the relationships between entities that need mapping out carefully.

Where schema fits into a wider local SEO approach

We treat schema as one part of a bigger picture, not a standalone fix. When we build a website for a client, we add LocalBusiness markup as standard, checked against the live Rich Results Test and cross-referenced with their Google Business Profile so the two never drift apart. Clients working with us on a full site build or an SEO audit get this validated as part of the deliverable, alongside the on-page fundamentals covered in our guide to targeting local customers online. It is quick to implement well and easy to get quietly wrong, which is why we build the checking step into every project rather than treating it as optional.

— Hook

How Hook Digital can help you get this right

If you would rather have this handled for you than work through templates and validation tools yourself, that is exactly the kind of technical detail we fold into our website and SEO work. We build LocalBusiness schema into every site we develop, check it against your Google Business Profile so your name, address and phone number never fall out of sync, and validate everything before it goes live rather than leaving you to find the errors later.

Depending on where you are starting from, a few of our services map directly onto this work:

• Website Design & Development: a new build or a template fix with schema implemented and validated from the outset.
• SEO & Performance Optimisation: an ongoing programme that keeps your markup, content and Business Profile aligned as things change.
• Full Service Marketing: the whole picture, from branding through to the technical detail covered in this guide, managed by one team.

If you are not sure whether your current site has working schema, or you suspect it has drifted out of date, get in touch and we will take a look. You can start with our Full Service Marketing page or explore Website Design & Development if a rebuild is on the cards.

Sources

For the underlying vocabulary, see Schema.org’s LocalBusiness type. For Google’s own guidance, see its structured data documentation. Validate everything with the Rich Results Test, and for deeper Organisation-versus-LocalBusiness modelling patterns, see this implementation guide.

• Google Developers — Local business (LocalBusiness) structured data
• Schema
• Google Rich Results Test
• Search Engine Journal — Ranking keyword domains (structured data guidance)

FAQ

What is LocalBusiness schema used for?

LocalBusiness schema is structured data that describes a physical business, its address, contact details and opening hours in a format search engines can read directly. It makes a page eligible for richer display features in search results, though Google is clear that it does not guarantee a ranking improvement on its own.

Should you use JSON-LD or Microdata for local business markup?

JSON-LD is the format most practitioners recommend because it sits in a single script block, separate from your visible HTML, making it far easier to maintain and update. Google supports Microdata and RDFa too, but industry guidance consistently points to JSON-LD as the easiest to implement correctly and keep in sync.

Do you need aggregateRating in your schema?

Only include aggregateRating when genuine, visible ratings appear on the same page the markup describes, with a value and count that match exactly what a visitor sees. Fabricated or third-party review data breaches Google’s policy and can put your entire listing’s eligibility at risk.

How do you model a service business that covers a whole region?

Describe the organisation itself with a LocalBusiness entity, then create a separate Service entity for each offering, linked to the business through provider and to its coverage area through areaServed. This keeps your business name clean and gives search engines a much clearer picture than listing services inside the name or description field.

How often should you re-validate your schema?

Re-validate any time you change your template, redesign your site or update core details such as your address or opening hours, using the Rich Results Test followed by a check of Search Console’s structured data reports. A quick validation pass after any development work touching shared templates catches most issues before they affect live pages.

Recommended

• Why local marketing matters for your business
• How to create a small business website in the UK
• How to target local customers online in 2026