4 Required Fields for Local Business Schema, Copy Ready for UK SMEs

What is a local business schema and which subtype fits you?

A LocalBusiness schema is a block of structured data, written in JSON-LD, that tells search engines and AI assistants the concrete facts about a physical business: its name, address, phone number, hours, and price range. It sits inside your page's HTML but isn't visible to visitors. Google, Bing and AI crawlers read it instead, and use it to build knowledge panels, rich results, and increasingly, the direct answers tools like ChatGPT or Perplexity give when someone asks "is this dentist open on Saturdays?"

Schema treats LocalBusiness as a broad parent type, but it also defines dozens of specific subtypes: Restaurant, Dentist, Plumber, HairSalon, AutoRepair, and many more. Using the specific subtype instead of the generic one matters more than most site owners assume. A generic LocalBusiness tag tells a search engine "this is a physical business somewhere." A Dentist tag tells it "this is a dental practice," which unlocks category-specific rich result eligibility and better matches how people actually search.

The rule of thumb is straightforward: if customers physically visit you, or you visit them at a fixed service area, use LocalBusiness or its closest subtype. That covers:

Two situations call for something other than LocalBusiness. If your business has no physical address customers ever interact with, purely a remote consultancy or an online-only shop, Organization is the more accurate type. And if you want to describe a specific offering rather than the business as a whole, a bookkeeping package, a boiler service, a wedding photography package, Service schema paired with a provider link back to your business often communicates more useful detail to AI systems than cramming everything into one LocalBusiness block. Service schema doesn't currently generate its own visible rich result in Google's testing tools, but it still gives AI agents structured service names and categories they can cite or recommend.

Picking the wrong type isn't fatal, Google is fairly forgiving of imperfect markup, but it does waste an opportunity. Specificity is free. It costs nothing extra to write "@type": "Electrician" instead of "@type": "LocalBusiness", and it tells the crawler considerably more about you.

• 01Shops, clinics, salons and restaurants with a visitable premises
• 02Tradespeople such as plumbers or electricians who serve a defined area from a base address
• 03Multi-location chains, each location getting its own subtype tag

Required and recommended properties, and where people get them wrong

Google's own documentation on LocalBusiness structured data is unambiguous about which fields actually matter. Four properties are required for Google to treat the markup as valid at all:

Beyond the required four, several recommended properties do most of the heavy lifting for how rich your listing looks and how well AI tools understand you:

Field-level notes worth getting right the first time. Phone numbers should always include the country code and use consistent formatting across every page and every directory listing you control. Currency-related properties like priceRange or currenciesAccepted should follow ISO 4217 currency codes rather than symbols alone when precision matters, particularly if you serve international customers. Opening hours need the ISO 8601 time format (08:00, not 8am), and each day needs its own dayOfWeek entry rather than a range string schema.org can't parse reliably.

Geo coordinates deserve particular care. Schema.org's own guidance recommends at least five decimal places of precision for latitude and longitude, roughly metre-level accuracy. Pulling coordinates from a quick Google Maps right-click usually gives you enough precision; rounding them to two or three decimal places, which some templates do by default, can place your pin streets away from your actual door.

Pro Tip: *Copy your latitude and longitude directly from Google Maps rather than a third-party geocoding tool. Right-click your exact location pin, select the coordinates that appear, and paste them in full. Truncating them "to keep things tidy" is the single most common geo error we see.*

The pitfalls that do the most damage share a theme: inconsistency and invention. A mismatch between your schema's address and your Google Business Profile's address, even a missing suite number, creates confusion that both search engines and AI assistants pick up on. Inventing an aggregateRating or fabricated review markup when you have no genuine reviews attached is worse: it violates Google's structured data guidelines outright and can trigger a manual action. If you don't have real review data flowing into your schema, leave the property out entirely.

• 01name: your exact trading name, matching your signage and Google Business Profile
• 02address: structured as a PostalAddress object, with streetAddress, addressLocality, postalCode and addressCountry as separate fields, never a single flattened string
• 03telephone: written in full international format, e.g. +44 141 496 0000, not a local-format number with no country code
• 04url: the canonical URL of the page the schema sits on, or your homepage if this is your primary business listing
• 05openingHoursSpecification: structured day-and-time objects rather than a plain-text string like "Mon-Fri 9-5"
• 06geo: latitude and longitude as a GeoCoordinates object
• 07image: at least one representative photo, ideally your logo or storefront
• 08priceRange: a simple indicator like "£$$" or "££", useful for restaurants and retail especially
• 09sameAs: an array linking to your verified social profiles and directory listings
• 10areaServed: relevant for tradespeople and mobile services who cover a region rather than a single point

How to add JSON-LD to your website step by step

Adding LocalBusiness schema isn't a design job, it's a data-accuracy job. Most of the effort goes into getting the facts right before you touch any code.

Pro Tip: *Bookmark your Rich Results Test result page for each location. When you update opening hours seasonally, re-test in under two minutes rather than assuming the change propagated correctly.*

Most CMS platforms, WordPress plugins in particular, will generate a baseline LocalBusiness block automatically from your site settings. That baseline is rarely wrong, but it's also rarely optimised: it typically skips geo coordinates, sameAs links and a specific subtype, defaulting to the generic LocalBusiness type instead. Treat the auto-generated version as a first draft, not the finished article.

• 01Decide which pages need markup. Your homepage always gets one LocalBusiness block. If you operate from more than one address, every location gets its own dedicated page and its own block, never one combined block listing several addresses.
• 02Gather your canonical facts first. Pull your business name, address, phone number and hours directly from your live Google Business Profile, not from memory or an old print advert. This becomes your single source of truth.
• 03Choose your @id pattern. Give each business entity a stable, unique identifier, typically your page URL with a #business fragment, so search engines can reliably connect the schema to the correct page even if other markup references it later.
• 04Generate the JSON-LD. You can write it by hand using schema.org's property tables as a reference, use a CMS plugin, or run Google's Structured Data Markup Helper to scaffold the basic structure before you refine it.
• 05Include only what's true and visible. Every fact in the schema should also appear somewhere on the visible page. Don't add a priceRange or service list that customers can't independently verify by reading the page itself.
• 06Wrap it in a single script block. Place <script type="application/ld+json"> containing your JSON object in the page's <head>, or just before the closing </body> tag if your CMS makes head-editing awkward.
• 07Test before you publish. Paste the code into Google's Rich Results Test on a staging version of the page, or use the code snippet mode if the page isn't live yet.
• 08Deploy and revalidate. Publish the live page, then re-run the test against the public URL to confirm nothing changed during deployment, template caching sometimes strips or duplicates script tags unexpectedly.
• 09Set a review trigger. Treat any change to your hours, address, or phone number as a trigger to update the schema at the same time you update your Google Business Profile, not weeks later.

Copy-ready JSON-LD examples for two common setups

A single-location business and a service provider without a public-facing shopfront need slightly different structures. Here's how the key fields differ between the two patterns.

Field Single-location example Service-provider example @type Specific subtype (e.g. "Dentist") "Service" with a linked "provider" object Core identity name, address, telephone on the LocalBusiness node itself name, address, telephone on the nested provider node Location data Full geo object with latitude/longitude Often omitted if no visitable address Offerings priceRange as a simple indicator hasOfferCatalog listing individual services with names and descriptions Best suited to Shops, clinics, restaurants, salons Consultants, mobile tradespeople, B2B service firms

For a single dental practice, the block would nest a PostalAddress and GeoCoordinates object directly under Dentist, along with openingHoursSpecification as an array of day objects and a telephone field in full international format.

For a service business, structure it the other way round: the top-level @type is Service, with a serviceType describing what's offered, and a provider property nesting the LocalBusiness details underneath. Add a hasOfferCatalog array listing each distinct service by name if you offer several, this is where AI tools pull the granular detail they need to answer "does this plumber do boiler installs" rather than just "is this a plumber."

A few practical notes apply to both patterns. Keep your @id consistent between your homepage's Organization node and any location or service block that references it, using fragment identifiers like #organization and #localbusiness. Reference booking pages or menus using the hasMenu or potentialAction properties rather than burying the URL only in body text. And keep image properties pointing to a properly sized, publicly accessible file, a broken or password-protected image reference is a common reason Rich Results Test flags a warning even when the rest of the markup validates cleanly.

Handling multiple locations without duplicating your data

Multi-location businesses run into one recurring temptation: combining every branch into a single JSON-LD block with an array of addresses. Resist it. The safest and most widely supported pattern is one dedicated URL and one JSON-LD block per physical location, according to practical implementation guidance built around exactly this scenario. Each location page carries its own name, address, phone number and hours, tagged with the specific subtype that applies to that branch.

Your corporate homepage plays a different role. Rather than repeating every branch's details, mark it up as a parent Organization node, then connect it to each location through sameAs links or matching @id references. This tells crawlers and knowledge panels that the branches all roll up under one brand, without forcing a single page to describe five different addresses at once.

Franchise structures benefit particularly from branchCode. If you operate as "Sparkle Cleaning, Glasgow" and "Sparkle Cleaning, Edinburgh" under one franchisor, giving each branch a distinct code alongside its address prevents search engines from merging or confusing the two listings, a real risk when branch names are nearly identical. For a deeper walkthrough of scaling this across a growing branch network, Project-pixel's multi-location SEO playbook covers the branch-page templates and internal linking structure that tend to work best.

• 01One URL, one LocalBusiness block, per physical branch, no exceptions
• 02Corporate homepage uses Organization, not LocalBusiness, when it has no single visitable address itself
• 03Link branches to the parent using sameAs or shared @id fragments so the relationship is machine-readable
• 04Use branchCode on each location's schema when locations share a brand name but need a distinct internal identifier, useful for franchises with numbered outlets or departments that need separate tracking
• 05Represent departments (a pharmacy inside a supermarket, a car servicing bay attached to a dealership) as a department property nesting a further LocalBusiness node inside the parent

Validating your markup and fixing the errors that actually appear

Two tools do almost all the work here. Google's Rich Results Test checks whether your markup is eligible for enhanced search features and flags syntax or missing-property errors immediately. Search Console's structured data enhancement reports then track this at scale across your whole site, useful once you've got more than a handful of pages carrying schema. A general-purpose schema validator, run separately, checks broader vocabulary correctness, confirming you haven't misspelled a property name or nested an object where schema.org expects a string.

The errors that come up most often have straightforward fixes:

Pro Tip: *Run your validation checklist after every deployment, not just once at launch. Template updates and plugin changes are the most common cause of previously valid schema silently breaking.*

A short post-deployment checklist covers most of what matters: confirm the script tag renders in your page's live HTML (not just the CMS editor preview), run Rich Results Test against the public URL, cross-check every address and phone number field against your current Google Business Profile, and check Search Console a few days later for any new enhancement errors. A dedicated schema checker tool is useful for a quick second opinion, particularly when you're debugging why a specific property isn't validating as expected.

• 01Invalid JSON syntax: a missing comma or unclosed bracket breaks the entire block. Paste your code into a JSON linter before it ever reaches your CMS.
• 02NAP mismatches: your schema's address or phone number doesn't match your Google Business Profile exactly, right down to abbreviations like "St." versus "Street." Fix by copying the GBP listing verbatim rather than retyping it.
• 03Malformed openingHoursSpecification: using a plain string instead of structured day objects, or 12-hour time instead of ISO 8601 format, both trigger warnings.
• 04Invented review markup: adding aggregateRating or review properties without genuine review data attached is flagged and can trigger manual review from Google.
• 05Missing required fields: leaving out telephone or url entirely means the whole block may be ignored rather than partially processed.

Best practices that keep your schema credible long after launch

The businesses that get real value from LocalBusiness schema treat it as a living document, not a one-off task ticked off at launch. A few practices separate markup that holds up over time from markup that quietly rots.

Google's documentation is explicit that schema should mirror your Google Business Profile rather than compete with it. Treat GBP as your primary record of truth, and update both together whenever your hours or address change. Schema reinforces the identity signals search engines and AI tools already gather elsewhere; it doesn't override them, and one guide's analysis is blunt that accurate, consistent markup supports entity clarity and citation accuracy without acting as a direct ranking lever on its own.

• 01Keep schema identical to what's visible on the page. Every fact in your JSON-LD, hours, price range, services, should also be readable by a human visitor on that same page. Divergence between the two is one of the fastest ways to lose trust with search engines.
• 02Use the most specific subtype available. Dentist beats MedicalBusiness, which beats generic LocalBusiness. Check schema.org's type hierarchy before defaulting to the broadest option.
• 03Never invent aggregateRating or review data. If you don't have a genuine review feed integrated, leave those properties out entirely rather than guessing at plausible-looking numbers.
• 04Don't duplicate identical LocalBusiness blocks across unrelated pages. A blog post doesn't need the same schema as your contact page; reserve full LocalBusiness markup for pages that actually represent a location or the business as a whole.
• 05Assign clear ownership. Someone on your team, or your web developer, should own schema updates the same way someone owns your Google Business Profile. Add a schema review step to your release checklist whenever site content changes.

How Project-pixel approaches schema for client sites

Every website Project-pixel builds for an established service business starts with the same fact-gathering step: pulling name, address, phone number and hours directly from the client's Google Business Profile before a single line of markup gets written. That canonical data then drives both the schema and the visible page content, so the two never drift apart.

From there, the process runs through JSON-LD generation matched to the correct subtype, Rich Results testing before launch, and Search Console monitoring set up as part of ongoing site management, not a one-off task left behind after handover. For multi-location clients, this extends into the branch-page and branchCode patterns covered earlier, applied consistently across every location added to the site.

How schema.org's definitions for LocalBusiness keep evolving

Schema.org isn't a static specification frozen at launch. Its vocabulary gets extended and refined regularly, and a few recent directions matter for anyone maintaining LocalBusiness markup rather than just installing it once.

The subtype hierarchy has grown considerably more granular over time. Where early adopters had a handful of broad categories to choose from, the current vocabulary includes highly specific subtypes across food service, healthcare, automotive, and professional trades, giving site owners far more precision than "generic LocalBusiness" ever offered. This trend rewards businesses that revisit their markup periodically rather than setting it up once and forgetting it.

Properties around service description have also matured. The relationship between Service, hasOfferCatalog, and provider has become more standardised as AI-driven search has pushed demand for structured, citable service descriptions rather than just physical-location facts. This matters more now than it did a few years ago, because AI assistants increasingly draw on exactly this kind of structured service data when answering "who does X near me" style queries.

Practically, this means treating your schema as something to revisit annually at minimum: check for new subtypes that better match your business, confirm your properties still align with schema.org's current documentation, and update anything that's drifted from Google's evolving recommendations for required and recommended fields.

When schema is worth prioritising and when it isn't

The businesses that get the most out of LocalBusiness schema are the ones you'd expect: anyone with a physical premises customers actually visit, anyone running multiple locations where consistency is hard to maintain manually, and increasingly, any business that wants AI tools to quote its contact details and hours accurately when a customer asks a voice assistant or chatbot for help. That last group is growing faster than most site owners realise, and it's the strongest argument for getting this right now rather than later.

Where I'd push back on the conventional advice is the assumption that every business needs to treat this as urgent. A consultancy with no public office, selling entirely through referrals and video calls, gains very little from LocalBusiness markup and would be better served by Organization and Service schema instead. Forcing a physical-address type onto a business that doesn't have one doesn't help; it just adds inaccurate data to the web.

For everyone else, the priority order is simple: homepage and location pages first, validation second, and inner-page enhancements like richer service catalogues or event markup only once the fundamentals are confirmed working. Don't let a perfect schema strategy delay getting the basic four required properties live and accurate.

* - Cameron*

Get your schema built properly, without hiring a developer for it

Project-pixel is the alternative to hiring a freelance developer piecemeal for schema markup: every fixed-price website build already includes structured data set up correctly from day one, tested against Google's own validation tools before launch, not bolted on afterwards as an afterthought.

That means your name, address, phone number and hours get pulled straight from your Google Business Profile and mirrored precisely across your new site's markup, the same canonical-data approach covered throughout this guide. For businesses running more than one location, the same multi-location SEO patterns apply automatically, one page and one JSON-LD block per branch, without you needing to brief a developer on the difference between branchCode and a duplicate listing.

If you're rebuilding a site anyway, or your current one has never had proper structured data, Project-pixel's local SEO services package includes the schema setup, validation and ongoing monitoring described in this guide as standard. Get in touch for a fixed-price quote and a clear delivery date.

Where to check your own schema

Cross-check any markup you write against schema.org's LocalBusiness definition for property names and formats, and Google's structured data documentation for what actually earns rich results. Test everything with Google's Rich Results Test and a general schema validator before publishing.

Sources

• 01Schema
• 02Local business (LocalBusiness) structured data
• 03Local Schema Markup: The LocalBusiness JSON-LD Guide | Fokal Guides

FAQ

What is a local business schema?

It's a JSON-LD block of structured data describing a physical business, its name, address, phone number, hours and related facts, that search engines and AI tools read to display accurate information and rich results.

How do I create a local business schema?

Gather your canonical name, address, phone number and hours from your Google Business Profile, write them into a JSON-LD script using the correct LocalBusiness subtype, then validate the code with Google's Rich Results Test before publishing.

What is a business schema?

A business schema is structured data marking up facts about an organisation for machines to read, LocalBusiness covers physical premises specifically, while Organization suits businesses without a visitable address.

What are the four types of schema?

Schema.org defines far more than four types overall, but for local business purposes the four core properties every valid LocalBusiness block needs are name, address, telephone and url, everything else is recommended rather than required.

Does adding schema guarantee a local pack ranking?

No. Schema clarifies your business identity for search engines and AI tools, but Google Business Profile signals and proximity drive local pack rankings, not structured data alone.

Recommended

• 01Multi-location SEO: the UK business playbook for 2026
• 02Google Business Profile optimisation for service businesses
• 03Local SEO for small business: the UK service-business checklist
• 04SEO for tradespeople in the UK: the 2026 playbook for plumbers