The Bulletin Schema

No. 026

How to add LocalBusiness schema to a website

The code itself is short. What actually trips people up is where it goes, what has to match, and how to check it's working at all.

Adding schema to a website is a small amount of code and a larger amount of getting the details right. Here's the mechanical part: where it goes, what it has to match, and how to confirm it's actually working, once you already know which type to use.

If you haven't picked your specific business type yet, start with LocalBusiness schema for contractors: which type to use, which covers the type list and a working example. This article picks up from there.

Where the code actually goes

Google recommends JSON-LD over the older microdata and RDFa formats, and it's a single self-contained block: a <script type="application/ld+json"> tag that can sit in the page's <head> or anywhere in its <body>. It doesn't need to be woven into your visible HTML the way older formats did. A page can carry more than one of these blocks; a services page, for instance, might have one for Service and a separate one for BreadcrumbList.

The one rule that causes the most problems

Google's structured data guidelines are direct about this: "Don't mark up content that is not visible to readers of the page." Whatever your schema claims, your visible page has to say the same thing. If your JSON-LD lists a phone number, that number should also appear somewhere a visitor can actually see it. This is the single most common way schema goes wrong, not a typo in the code, but a fact in the markup that doesn't match the page around it.

A basic checklist for adding it

  1. Pick the specific type for your trade, not generic LocalBusiness.
  2. Include name and address, which Google lists as the only two properties that are strictly required.
  3. Add what you can verify is accurate: telephone, openingHoursSpecification, url. Google notes that if you include a url, it "must be a working link."
  4. Match it to your Google Business Profile. Same hours, same phone number, same address (or hidden address, if you're a service-area business).
  5. Place the script tag in the head or body of every page where it applies, most often the homepage and contact page for business-level information.

How to test it before you trust it

Don't assume the code works just because it validates. Two free tools check different things:

What happens if something's wrong

If your structured data violates Google's guidelines, most commonly by not matching the visible page, the consequence is a manual action, and it's narrower than people expect: Google's own documentation states that "a structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search." A schema mistake costs you a feature, not your ranking. That's a reason to fix it, not a reason to panic if you find one.

Keep it current

Schema isn't something you add once and forget. If your hours change, your schema needs to change with them, on the same day. A block of code that still claims your old hours a year later is worse than no schema at all, since it's an inaccurate factual claim search engines and AI assistants can check against your Google Business Profile and notice the mismatch.

Questions

Do I need a different script tag on every page?

Business-level information (name, address, hours) is usually enough once, on the homepage and contact page. Individual service pages are better served by adding Service schema specific to that page.

Will adding schema improve my ranking?

Not directly. It helps search engines and AI assistants understand your pages accurately, which supports everything else you're doing, but it isn't a ranking factor on its own.

How do I know if my schema is already broken?

Run a page through the Rich Results Test, and check Search Console's structured data reports for any pages Google has flagged.

Sources

Want a site that launches with answers already written?

Start a project