LocalBusiness Schema: Copy-Paste Code for Service Companies

What LocalBusiness schema actually is

LocalBusiness schema is a vocabulary from schema.org, the shared standard that Google, Bing, and other search engines use to read structured data on web pages. It's written in JSON-LD — a block of JSON embedded in your page's HTML — and it tells search engines, in a format they can parse without guessing, basic facts about your business: your name, address, phone number, hours, service area, and price range.

You don't need this schema to show up in Google at all. Search engines can and do read your visible page text. But structured data removes the ambiguity. Instead of Google trying to infer your business hours from a sentence buried in your footer, LocalBusiness schema states them explicitly, in a format built for machines. That matters most for local service businesses, where a single wrong detail — an old phone number, incorrect hours — can cost you a job.

Why it's worth your time

A few concrete reasons to actually do this, not just read about it:

• Consistency checks. Search engines cross-reference your schema against your Google Business Profile, directory listings, and citations. Matching data reinforces trust in your listing.
• Rich result eligibility. Review stars, business hours, and other enhanced listing features are built on top of structured data. Schema is a prerequisite, not a guarantee — but without it, those features aren't on the table.
• Clarity for every crawler. AI answer engines and voice assistants pulling business facts also lean on structured data because it's unambiguous. A paragraph of marketing copy is harder to parse than a JSON field called telephone.
• It's cheap to implement. This isn't a redesign. It's one script tag, and most CMS platforms let you drop it into a header or template once and reuse it site-wide.

None of this requires a developer budget or a redesign sprint. You're adding one block of code, once, and revisiting it only when something about your business actually changes. For a solo operator or a two-person shop, that's a far better return on an afternoon than almost anything else on the local SEO checklist.

Finding the right subtype for your trade

Schema.org maintains a long list of LocalBusiness subtypes, and picking a specific one gives search engines a clearer signal than the generic fallback. A few common ones for service businesses:

• Plumber, Electrician, HVACBusiness, RoofingContractor, HousePainter — home services trades
• Locksmith, MovingCompany, LandscapingService — related home and property services
• Dentist, Physician, VeterinaryCare — healthcare-adjacent local practices
• AutoRepair, AutoBodyShop — automotive services
• LegalService, AccountingService, InsuranceAgency — professional services with a physical office

If you genuinely can't find a subtype that matches — say, you run a niche service that doesn't map cleanly to the list — LocalBusiness on its own is still valid and still gets you all the same benefits. Don't force a bad fit just to use a more specific label; an accurate generic type beats an inaccurate specific one.

Where the code goes on your site

JSON-LD lives inside a <script> tag with type="application/ld+json". It's invisible to visitors — it does nothing to your page's look or layout. The most common placement is:

• In the <head> of your homepage, and on every location or contact page if you have multiple locations.
• Injected via your CMS's "custom code" or "header scripts" field if you're on WordPress, Webflow, Squarespace, or similar.
• Hardcoded into your template if you're hand-building the site or working with a developer.

One schema block per business location is the standard approach. If you have three locations, you want three LocalBusiness blocks, each with its own address and phone number — not one block trying to represent all three.

The copy-paste code

Here's a complete, valid LocalBusiness example for a fictional HVAC company. Swap in your own business details — name, address, phone, hours, coordinates, price range — and this is ready to go.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HVACBusiness",
  "name": "Example HVAC Co",
  "image": "https://www.examplehvacco.com/images/storefront.jpg",
  "url": "https://www.examplehvacco.com",
  "telephone": "+1-555-867-5309",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "412 Maple Avenue",
    "addressLocality": "Springfield",
    "addressRegion": "IL",
    "postalCode": "62704",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.7817,
    "longitude": -89.6501
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "18:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:00",
      "closes": "14:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/examplehvacco",
    "https://www.instagram.com/examplehvacco"
  ]
}
</script>

That's a complete, functional block. No placeholders left dangling, no properties that require explanation outside the code itself.

Breaking down the fields

• @type — Use the most specific type available. HVACBusiness, Plumber, Electrician, Dentist, Locksmith, and dozens of others exist as subtypes of LocalBusiness. If nothing fits your trade exactly, LocalBusiness itself is a safe fallback.
• address — Always a nested PostalAddress object, not a flat string. Each component (street, city, region, postal code, country) goes in its own field.
• telephone — Use a single consistent format across your website, Google Business Profile, and directory citations. Pick one (with or without country code) and stick to it everywhere.
• openingHoursSpecification — The more precise option; it supports different hours per day and even seasonal overrides. The simpler openingHours property (a shorthand string like "Mo-Fr 08:00-18:00") also works if your hours are simple and uniform.
• priceRange — A rough indicator like $, $$, or $$$. Don't overthink this; it's meant to set expectations, not itemize your rate card.
• geo — Latitude and longitude as a GeoCoordinates object. You can pull these from Google Maps by right-clicking your business location and copying the coordinates shown.
• sameAs — Links to your official social profiles and other authoritative mentions of your business. Optional, but it helps tie your identity together across the web.

Common mistakes that undercut the schema

A few things that quietly break this, even when the JSON is technically valid:

• Mismatched NAP data. If your schema says one phone number and your Google Business Profile says another, you've created a conflict search engines have to resolve — and they won't always resolve it in your favor. Name, address, and phone number (NAP) should match character-for-character everywhere.
• Stale hours. Holiday closures, seasonal hour changes, and permanent schedule updates need to be reflected in the schema, not just on your Google listing.
• One schema block trying to cover multiple locations. Each physical location needs its own block with its own address and phone number.
• Copy-pasting a competitor's schema wholesale. Beyond the obvious problem of wrong business details slipping through, duplicated identifiers (like a reused @id or URL) can confuse how engines associate the data.
• Forgetting it exists. Schema isn't a one-time task you check off. When you open a second location, change your hours, or rebrand, the schema needs to move with you.

Validating what you've added

After you add the script tag, confirm it actually parses:

1. Use Google's Rich Results Test or Schema.org's own validator — paste your URL or raw JSON-LD and check for errors or warnings.
2. View your page source (not just the rendered page) to confirm the script tag made it into the HTML your CMS actually outputs. Some page builders strip custom scripts unexpectedly.
3. Re-check after any site migration, theme change, or CMS update — these are common moments where structured data silently disappears.

If the validator flags an error, it's almost always one of three things: a missing required field for the type you chose (some subtypes require specific properties), a typo in a property name, or a value in the wrong format — dates and times need to follow ISO 8601 (08:00, not 8am), and the address needs to stay a nested object rather than getting flattened into a single string along the way.

A few questions that come up often

• Does this replace my Google Business Profile? No. They're complementary. Your Business Profile is how you show up on Google Maps and in the local pack; your schema is how your own website communicates the same facts. Keep both, and keep them matching.
• Do I need a developer to add this? Not necessarily. If your CMS has a field for custom header code or embedded HTML, you can paste the script tag yourself. If you're not comfortable touching site code at all, this is a quick, low-risk task to hand to a developer or agency — it's a single static block, not an integration.
• Will this guarantee rich results in search? No. It makes you eligible for certain enhanced listing features, but eligibility and actually getting them depend on other factors too — search engines ultimately decide whether and how to display any given rich result.
• What if I have multiple locations on one page? Use an array of LocalBusiness objects, or better, give each location its own URL and its own schema block pointing to that specific address and phone number.

Reviews belong in this picture too

LocalBusiness schema and review schema often travel together. If you're already collecting customer reviews, you can mark those up too — star ratings and review counts are their own structured data types that can appear alongside your business listing. Rather than hand-writing that JSON from scratch and tracking down the right nesting for aggregateRating and individual Review objects, Tailwind's free Review Schema Generator builds the code for you — and it works for general LocalBusiness-style markup too, not just reviews, so it's a fast way to get a correct starting point without memorizing the spec.

Where this fits in a bigger local SEO picture

Structured data is one piece of a larger local visibility puzzle. It works best alongside a complete, accurate Google Business Profile, consistent citations across directories, genuine customer reviews, and content that actually answers what people in your service area are searching for. None of those replace each other — a perfect schema block on a site with no reviews and an abandoned Google Business Profile won't move the needle much.

If you're trying to figure out which of those pieces matters most for your specific situation — or you just don't have time to audit all of them yourself — Tailwind's local SEO tooling is built for exactly this: finding the gaps in your local search presence and giving you a prioritized list of what to fix first.

A short checklist before you move on

• Pick the most specific @type for your trade.
• Make sure your NAP data matches your Google Business Profile exactly.
• Use PostalAddress and GeoCoordinates as nested objects, not flat strings.
• Validate the code before you consider it done.
• Set a calendar reminder to revisit this whenever your hours, address, or locations change.

None of this is complicated once it's in front of you — it's an afternoon task, not a project. Copy the block above, swap in your real business details, validate it, and move on to the next thing on your list. Structured data doesn't need ongoing attention once it's accurate; it just needs to actually get done.