How do you add schema markup to a local business website?
Add schema by marking up the real business details already visible on the relevant page, using JavaScript Object Notation for Linked Data, known as JSON-LD. We gather the facts, choose the closest LocalBusiness type, add the script, test it, then keep it updated when your details change.
Good local business schema markup is a clarification layer. It tells search systems what your page already says about your business in a structured way they can read cleanly. It does not create authority by itself, and it does not guarantee rich results, Maps visibility or AI citations.
A safe implementation follows this order:
- Gather the business details that customers can already see on the page, including name, address or service area, phone number, opening hours and website URL.
- Choose the most accurate LocalBusiness type from Schema.org, rather than using a broad label by default.
- Write the JSON-LD so the code matches the visible content and uses the right properties.
- Place the markup on the page it describes, such as a homepage, contact page or location page.
- Test the page with the Google Rich Results Test before release.
- Check the live page in Google Search Console through the URL Inspection tool.
- Review the schema whenever your business details, pages or services change.
Google’s own process for structured data is build, test, release and maintain. That is a sensible way to brief the work, whether you add schema to your website through your content management system, your developer or a search engine optimisation partner.
SEO professionals reviewing publisher prospects for an authority link campaign
What Is In This Article
- How do you add schema markup to a local business website?
- The business details must be visible first
- The right LocalBusiness type prevents vague markup
- The page placement should match the page
- The JSON-LD should stay lean and accurate
- Why valid schema still needs maintenance
- Common questions about local business schema markup
The business details must be visible first
Marking up what is already on the page is sound schema work, and using code to patch missing business information is where problems start. We always want the page itself to be clear before any local business structured data is added.
Customers and search systems should see the same basic facts. Your business name, visible address where relevant, service area wording, customer phone number, opening hours and main website URL need to agree across your website and your Google Business Profile. If the page says one thing and the code says another, the code has become noise.
At First Place SEO, we look at schema alongside the website, Google Business Profile and local content, rather than as a separate code task. A service-area business, for instance, needs real wording on the page about where it works. The areaServed property can support that information, but it cannot stand in for a thin page that never explains the service coverage to a customer.
Multi-location businesses need the same discipline. Each physical branch needs its own accurate details on the relevant page, because one generic sitewide block will blur information that should be distinct. Search systems do not benefit from a single lump of code that tries to describe several different places at once.
Access matters too. If a page is blocked from Googlebot through robots.txt, a noindex instruction or another access control method, valid markup on that page will not solve the problem. Consistency comes before code.
The right LocalBusiness type prevents vague markup
Schema.org gives us the vocabulary, and JSON-LD gives us a clean format for placing that vocabulary on the page. Those two pieces get mixed up a lot, which is why weak implementations often start with a generic LocalBusiness block and stop there.
Schema.org is the vocabulary
Schema.org defines LocalBusiness as a particular physical business or branch of an organisation. That matters because LocalBusiness schema should describe a real local entity, not a loose brand idea or a list of services with no clear place behind them.
Google recommends using the most specific LocalBusiness subtype that genuinely fits. A broad type is easier to add, but it gives less precise information. If your business falls under a more accurate subtype, that choice helps the markup describe what the business actually is.
At First Place SEO, we usually start by deciding what the business actually is in search terms before writing the JSON-LD. That decision affects the type, the page choice and the details that need to be checked.
JSON-LD is the format
JavaScript Object Notation for Linked Data, known as JSON-LD, is the format Google recommends for structured data. Google also supports Microdata and RDFa, a way of placing structured data in page attributes, but JSON-LD is usually cleaner because it sits as a script rather than being woven through the page text.
Some local businesses have more than one relevant type. In that case, Google says the types should be specified as an array, such as a business that is both an electrician and a locksmith. The additionalType property is not supported for that purpose.
Broad schema is easy to add, but the closest accurate type gives search systems a clearer business entity to read.
Pro Tip: Match the schema to the exact page it sits on, then check the live URL in Google Search Console after release. This helps you catch drift between the page content and the structured data before it becomes a larger issue.
The page placement should match the page
When schema is added sitewide without thought, it often becomes less accurate. The markup should describe the page it sits on, so a homepage, contact page, location page and service page can need different treatment.
This table shows the practical difference between common page types.
| Page type | Suitable schema approach | Common mistake |
|---|---|---|
| Homepage | Use LocalBusiness schema if the page contains clear business details. | Adding a long block that includes details the page never shows. |
| Contact page | Mark up the customer-facing business details shown on that page. | Using old phone, address or opening hour details from a previous version of the site. |
| Location page | Use location-specific LocalBusiness details for that physical branch. | Placing one generic business block across every branch page. |
| Service page | Use service-related markup where it matches the page, and include LocalBusiness only where the page genuinely describes that business location. | Forcing the same LocalBusiness schema onto every service page. |
| Service-area page | Use visible service-area wording and, where useful, areaServed. | Relying on schema to describe coverage that the page itself does not explain. |
Google says LocalBusiness structured data can be added to any page, but it makes more sense on a page that contains information about the business. Its wider structured data guidance also says structured data should be placed on the page it describes, unless a feature says otherwise.
For a single-location local business, the natural home is often the homepage, contact page or main location page. For a multi-location business, each branch page needs its own accurate business details. For a service-area business, page copy and schema need to work together, with areaServed used as a supporting field rather than a shortcut.
Page-specific accuracy beats broad sitewide repetition.
technical seo specialist reviewing website on smartphone by office window
The JSON-LD should stay lean and accurate
Longer schema is not automatically better. We prefer lean JSON-LD local business schema that includes useful, accurate properties and leaves out fields that the page cannot support.
For Google’s LocalBusiness rich result eligibility, the required properties are name and address. The address should include as much of the proper postal address as possible, such as street address, locality, region, postcode and country, where those details are relevant and visible. For a local service business with a customer-facing premises, those fields help remove ambiguity.
Phone and hours need the same care. The telephone property should be the main customer contact number and should include the country code and area code. Opening hours can be expressed through OpeningHoursSpecification, and awkward cases such as seasonal hours need proper date ranges. We do not want a customer seeing one set of hours and a search system reading another.
A compact example looks like this, but it still needs adapting to the visible page:
{ "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Your visible business name", "url": "https://www.example.co.uk/", "telephone": "+44 customer number", "address": { "@type": "PostalAddress", "streetAddress": "Address shown on the page", "addressLocality": "Locality shown on the page", "postalCode": "Postcode shown on the page", "addressCountry": "GB" } }
Review markup deserves caution. Google recommends aggregateRating and review for LocalBusiness only for sites that capture reviews about other local businesses. A local service business should not assume it can mark up its own testimonials to gain review stars.
Generators and plugins can save time, but their output still needs human review against the page and the guidance it is meant to follow.
Pro Tip: Keep the schema tied to real customer facing details, especially address, phone number and opening hours. If those details change on the page or in your Google Business Profile, update the markup at the same time.
Why valid schema still needs maintenance
A page can pass a syntax test and still be weak schema work. Required properties can be missing, the live page can be inaccessible to Googlebot, or the details can drift after a phone number, address, service page or opening schedule changes.
The Google Rich Results Test is useful because it checks whether the markup is valid for supported result features. Passing that test does not mean a rich result will appear. Google is clear that structured data can enable a search feature, but it does not guarantee that the feature will be shown.
After release, we want to know how the live page is being read. Google Search Console gives you the URL Inspection tool for checking how Google sees a page, and the Manual Actions report can flag wider structured data issues where they exist. Submitting a sitemap also helps Google find future changes.
Schema maintenance is a small governance habit. When business details change, the page, the Google Business Profile and the schema need to move together. The same applies when a location closes, a branch page is added or a service page is rewritten.
Once you see schema this way, the question changes. You are no longer asking whether code has been added. You are checking whether your business information is accurate, visible, page-specific, testable and kept in line with the real business.
SEO experts celebrating a new editorial backlink partnership in London
Common questions about local business schema markup
Should LocalBusiness schema go on every page?
No. LocalBusiness schema should sit on pages where it accurately describes the business information shown there, such as a homepage, contact page or location page.
Does LocalBusiness schema help Google Maps rankings?
LocalBusiness schema can make business details clearer for search systems, but it does not guarantee Maps rankings or local pack visibility. Maps performance depends on a wider local SEO picture.
Can we add schema ourselves through WordPress?
Yes, you can add schema through a WordPress plugin or code field if the output is accurate. We still recommend checking the final JSON-LD against the visible page and testing the live URL.
What is the difference between Schema.org and JSON-LD?
Schema.org is the vocabulary that defines types such as LocalBusiness and properties such as address. JSON-LD is the script format used to place that structured data on your page.
Can we use review schema for our own testimonials?
You should be careful. Google recommends LocalBusiness review and aggregate rating properties only for sites that capture reviews about other local businesses, so marking up your own testimonials for stars is not a safe assumption.