Fylde-Digital-Logo-Final
Contact us
back to all

Fix LocalBusiness Schema in 5 Steps for Busy Owners

Use JSON-LD LocalBusiness with the most specific subtype available, not the generic version, and validate it before you move on. Add the required properties, name, address as PostalAddress, telephone and url, then test the result. This single step corrects one of the most common gaps in local search visibility, and it takes less time than most business owners expect.

TL;DR:

  • Using a specific subtype of LocalBusiness, such as Dentist or Restaurant, unlocks richer, subtype-specific search results and eligibility for enhanced features.
  • Multi-location businesses must assign each branch a unique @id and tailor their schema for accurate representation and to avoid merging details incorrectly.
  • Regular audits, keeping a change log, and syncing schema with Google Business Profile help prevent schema drift and maintain data accuracy.
  • Plugins simplify setup and maintenance for WordPress sites, while manual JSON-LD offers greater control for custom templates and multi-location setups.
Fyldedigital
Strengthen Your Local Search Presence
Fylde Digital provides SEO, web design and digital marketing solutions for businesses seeking stronger online visibility and tailored support.

Explore digital marketing support

Table of Contents

What LocalBusiness schema is and why it matters

LocalBusiness schema is a structured data format that describes your business to search engines in a language they can parse directly, rather than one they have to infer from your page copy. It tells Google (and increasingly AI-driven search overviews) your business type, address, phone number and opening hours in a consistent, machine-readable structure. That structure feeds knowledge panels, local pack listings and rich results, the boxes and cards that appear above standard blue links when someone searches for a business like yours.

The opportunity here is real. A large share of local businesses still have no structured data on their sites at all, according to Google’s own documentation on LocalBusiness structured data, which leaves a gap that a modest amount of technical work can close. Search engines can often work out your address from page text, but they do it with far less confidence than when the same details sit inside a proper schema block, and low confidence tends to mean your listing sits further down the results.

Two choices affect how well this works. First, format: JSON-LD is the format Google recommends and the one most tools generate by default, because it sits in a single script block without touching your visible page structure. Second, specificity: Schema lists dozens of subtypes, from Restaurant to Dentist to ElectricianShop, and using the exact match rather than the generic LocalBusiness type widens your eligibility for subtype-specific rich results.

What LocalBusiness schema is and why it matters — overview diagram

Before you touch a plugin or write a line of code, get the property list straight. Google’s structured data documentation for LocalBusiness sets out which fields are required and which are recommended, and the difference matters because missing a required field can disqualify the whole block from being read correctly.

The required properties are:

  • @type: the most specific schema.org subtype your business fits, such as Restaurant or Dentist, falling back to LocalBusiness only when nothing closer exists.
  • name: your business’s trading name, written exactly as it appears elsewhere on the page.
  • address: a nested PostalAddress object with streetAddress, addressLocality, addressRegion, postalCode and addressCountry as separate fields, never a single flattened string.
  • telephone: your contact number, ideally in E.164 international format (a plus sign, country code, then the number with no spaces).
  • url: the canonical URL of the page the schema sits on, or your homepage where a business has one primary site.

Beyond those, Google’s LocalBusiness structured data guidance lists recommended properties that strengthen eligibility for richer results without being strictly mandatory:

  • openingHoursSpecification: an array of objects covering days, opening time and closing time, each written in 24-hour format (17:00, not 5pm).
  • geo: latitude and longitude as a GeoCoordinates object, useful for map-based results and typically accurate to five or six decimal places.
  • image: a URL to a representative photo of the premises, product or storefront.
  • priceRange: a short indicator such as ££ or £10 to £30, kept brief since most implementations treat this as a limited-length field.
  • aggregateRating: only included when you have genuine review data to back it, since fabricated ratings are a policy violation and an easy way to lose rich result eligibility entirely.
  • sameAs: links to verified social profiles or your Google Business Profile, helping search engines cross-reference your identity.
  • hasMap: a direct link to your Google Maps listing.

A few formatting rules trip people up more than the property list itself. Phone numbers work best in E.164 format because it removes ambiguity around country codes. Opening hours must use 24-hour time, and each day needs its own entry rather than a single range covering the whole week. Coordinates should be precise enough to pin the correct building, not just the correct postcode. And if you run more than one location, every branch needs its own unique @id value: without it, Google can merge or misattribute details between branches, which causes exactly the kind of confusion this markup is meant to prevent.

How to implement LocalBusiness schema

You have two realistic routes: a plugin, if you run WordPress, or manual JSON-LD inserted directly into your templates. Which one fits depends on how technical your team is and how many locations you manage.

Plugin-based implementation suits most single-location businesses and many multi-location ones too. Tools such as AIOSEO, Rank Math and SEOPress all include schema generators that build LocalBusiness markup from fields you fill in through a standard settings screen, according to coverage of WordPress schema plugins from SEOPress. The typical pattern is:

  1. Install and activate your chosen plugin, then locate its schema or structured data settings.
  2. Set your site-wide LocalBusiness defaults: business type, name, address, phone and opening hours.
  3. For multi-location sites, use the plugin’s per-page override to set unique details, and where possible a unique @id, on each location page.
  4. Save changes and view the page source to confirm the JSON-LD block has rendered.
  5. Run the page through a validator before publishing anything live.

Plugins also handle maintenance more gracefully than hand-coded blocks, since updating a business’s phone number in one settings field updates every page using that template. That said, plugin updates occasionally change how fields are structured, so a quick recheck after any major plugin update is worth building into your routine.

Manual JSON-LD gives you more control and suits developers working outside WordPress, or WordPress sites with custom templates that need schema populated dynamically from a database, such as a directory of locations pulled from a content type. The script block typically sits in the page’s head, or just before the closing body tag, written as a <script type="application/ld+json"> element containing the JSON object. On templated multi-location sites, the values inside that block should be populated server-side from the same fields that drive the visible address and phone number on the page, so the two never drift apart.

Which pages need this markup depends on your setup. A single-location business should add it to the homepage and the contact page at minimum. A multi-location business needs it on every individual location page, with the homepage either omitted or carrying a broader Organisation-level reference rather than a single branch’s details.

Pro Tip: If you’re not sure whether to choose a plugin or manual insertion, default to the plugin unless a developer is already maintaining custom templates. It is faster to set up correctly and far easier to keep accurate over time.

JSON-LD examples for one location and several

A single-location example for a dental practice, using the most specific subtype rather than generic LocalBusiness, looks like this:

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example.com/#dentist",
  "name": "Example Dental Practice",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 High Street",
    "addressLocality": "Blackpool",
    "addressRegion": "Lancashire",
    "postalCode": "FY1 1AA",
    "addressCountry": "GB"
  },
  "telephone": "+441253000000",
  "url": "https://example.com",
  "priceRange": "££",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Monday",
      "opens": "09:00",
      "closes": "17:30"
    }
  ]
}

For a multi-location business, each branch gets its own block with a distinct @id, and each can optionally reference a parent Organisation:

  • Give every branch a unique @id, typically the page URL with a fragment such as #location-blackpool.
  • Keep the parent brand’s details in a separate Organisation entity when locations share a name but operate independently, so search engines don’t conflate one branch’s reviews or hours with another’s.
  • Use each branch’s own priceRange and openingHoursSpecification rather than copying the head office’s defaults.

For readers entering data by hand, postcodes go in the postalCode field exactly as formatted on Royal Mail’s database, and telephone numbers should include the country code (+44 for numbers based in the UK) even when the visible number on the page is written locally.

Validate and test your markup

Never publish schema without testing it, because a single malformed field can invalidate the entire block. Google’s Rich Results Test checks whether your markup is eligible for rich results and flags errors against the required and recommended property list. Search Console’s URL inspection tool and its enhancements reports then show you how Google is actually reading the live page over time, which catches problems a one-off test can miss.

The errors that come up most often are straightforward once you know what to look for:

  • Missing required fields, usually address components entered as a flat string instead of a nested PostalAddress object.
  • Malformed JSON, often a trailing comma or an unescaped quotation mark inside a text field.
  • Incorrect time formats, such as 5:00 PM instead of 17:00 in openingHoursSpecification.
  • Unreachable resources, where an image or sameAs URL returns a 404 rather than the page it’s supposed to point to.

Retest after any site migration, template change or plugin update, since all three can quietly alter how fields render even when nothing looks different on the page itself.

Maintenance checklist to prevent schema drift

Schema markup is not a one-off task. It needs to stay in step with your actual business details, and the gap between what your schema says and what’s true is what the industry calls schema drift, a problem that grows quietly until a customer calls the wrong number or turns up on the wrong day, as SchemaApp’s coverage of schema drift points out.

  1. Set an audit cadence. A monthly spot check suits most single-location businesses; multi-location operators should audit whenever any branch changes hours, address or contact details.
  2. Pick one canonical data source. Decide whether your Google Business Profile or your website content is the master record, then update the other from it every time something changes, rather than editing both independently.
  3. Keep a simple change log. Note the date and what changed each time schema is updated, so a future audit can spot when drift started.
  4. Version control your templates where you can. Developers working with custom JSON-LD templates benefit from tracking changes the same way they would any other code.

Pro Tip: Tie your schema audit to the same calendar reminder you use for checking your Google Business Profile. The two should always move together.

How Fylde Digital handles LocalBusiness schema for clients

We treat schema as part of the technical foundation of a website, not an afterthought bolted on after launch. Our process runs in four stages: audit the existing site for missing or malformed markup, implement the correct subtype and properties for each location, validate every page through Google’s testing tools, and hand over a short report explaining what was changed and why.

For most small business clients, this means JSON-LD on the homepage, contact page and any dedicated location pages, built from the same address and phone data that appears in the visible page content and the client’s Google Business Profile, so the two never disagree. Where a client runs several locations, each gets its own @id and its own set of opening hours and contact details. You can read more on syncing this work with your listings in our Google Business Profile guide.

Impact of schema markup on Google My Business and local pack rankings

Schema markup and your Google Business Profile (still commonly called Google My Business by many business owners) work together rather than in competition. Your profile is the primary data source behind the local pack, the block of three map listings that appears for searches with local intent, but the structured data on your own site acts as a corroborating signal that reinforces the same facts.

Schema and profile data consistency comparison

When your website’s schema and your profile agree on name, address, phone number and hours, Google has less reason to question either source. When they disagree, even in a small way such as a different phone number on an old landing page, that inconsistency can undermine the confidence Google places in both. Google’s structured data guidance frames LocalBusiness markup as a way to help confirm business details rather than a ranking factor in its own right, and that framing matters: schema won’t force a business into the local pack on its own, but a poorly aligned or missing set of business signals across your site and profile can hold you back from appearing there consistently.

Rich results, the extra visual details such as opening hours or a price range shown directly in search results, are the more direct benefit. These come from the schema itself and can make a listing more clickable even at the same ranking position, which is a separate but related win alongside any local pack movement.

Best practices for integrating schema with other SEO strategies

Schema markup works best as one part of a wider technical and local SEO setup, not as an isolated fix. It should echo, never contradict, the business details that appear in your visible page content, your Google Business Profile and any directory listings you maintain, since consistency across all of these is what builds the confidence search engines need to trust your data.

Pair your LocalBusiness schema with clear, crawlable contact and location pages rather than hiding address details inside images or PDFs, since schema can only reinforce information that’s genuinely present and readable on the page. If you run any content marketing or blog activity, keep your Organisation or LocalBusiness identity consistent across those pages too, so a blog post and your contact page never describe the business under two different names or addresses.

Technical SEO fundamentals still come first: a slow-loading page or a blocked robots.txt entry will limit how much good schema can do for you, so treat markup as a layer added on top of solid page performance and crawlability rather than a substitute for either. Our local SEO strategy guide covers how to prioritise this work across a wider site.

Common pitfalls when using LocalBusiness schema

The most frequent mistake is using the generic LocalBusiness type when a more specific subtype exists. A dental practice marked up as plain LocalBusiness misses out on eligibility for the richer, subtype-specific results that Restaurant, Dentist or similar entries can unlock.

Flattened addresses cause the second most common problem: entering the whole address as a single text string instead of a nested PostalAddress object with separate fields for street, locality, region, postcode and country. Search engines can’t reliably parse a flat string the way they can parse structured fields.

Fabricated or outdated aggregateRating data is a serious pitfall worth avoiding entirely if you don’t have genuine, current review figures to back it, since Google treats invented ratings as a policy violation that can cost you rich result eligibility altogether. Stale opening hours left over from a previous set of trading hours are almost as damaging, since they erode the trust that makes schema useful in the first place.

Finally, on multi-location sites, reusing the same @id across branches, or omitting it entirely, invites Google to merge details between locations that should stay distinct. Give every branch its own identifier and its own accurate set of properties, and revisit that data every time anything changes on the ground.

The single biggest lever here is specificity: pick the exact schema.org subtype, fill in the required properties properly, and validate before you publish. Everything else, priceRange, aggregateRating, sameAs links, is worth doing but matters less than getting the basics right and keeping them accurate.

If you haven’t checked your site’s schema against your Google Business Profile recently, that’s the fastest audit you can run this week. A short mismatch check often reveals more than a full technical rebuild would.

— tibor

Fylde Digital’s schema implementation service

If you would rather hand this work to someone who does it daily than work through validator errors on a Friday afternoon, that’s exactly the gap our web design and SEO team closes for small business clients. We build LocalBusiness schema into the site itself during development rather than treating it as an afterthought, to keep markup and visible content consistent.

Fyldedigital

A typical engagement covers:

  • A full audit of existing markup, or a build from scratch where none exists.
  • JSON-LD implementation for every location, each with its own required and recommended properties.
  • Validation through Google’s testing tools before anything goes live.
  • An ongoing maintenance check as part of wider SEO support, so drift doesn’t creep back in.

Get in touch through our SEO and technical services page to talk through what your site needs.

Official docs and validator tools

Sources

FAQ

Can you explain schema markup in a simple way?

Schema markup is a small block of code added to a web page that describes the business in a format search engines can read directly, rather than having to guess from ordinary text. It confirms details such as name, address and phone number in a structure both Google and other tools can parse reliably.

Can you provide an example of schema markup?

A basic example is a JSON-LD block naming the business type (such as Dentist or Restaurant), followed by fields for name, address, telephone and url, all wrapped in a script tag on the page. Google’s LocalBusiness documentation shows full sample snippets you can adapt.

What is a local business schema?

LocalBusiness schema is the specific vocabulary from schema.org used to describe a physical business with a location, such as a shop, clinic or restaurant. It covers required details like address and phone number, plus optional ones like opening hours and price range.

Can you give me an example of a Local Business schema?

A minimal example includes "@type": "LocalBusiness" (or a more specific subtype), a name field, a nested PostalAddress object, a telephone number and a url. Adding openingHoursSpecification and geo coordinates strengthens eligibility for richer search results without being strictly required.

Some More Cool Projects