Copy Ready Local Schema Markup for SMBs + Google Validation

The fastest path to local search visibility is JSON-LD LocalBusiness markup (or a more specific subtype like Restaurant or ProfessionalService) placed on each location page, with the essential fields, name, address, and phone number, filled in accurately and visibly on the page. Skip the generic templates you find in random tutorials. Once it’s live, run it through Google’s Rich Results Test before you consider the job done. That single check catches most of the errors that keep businesses out of enhanced local results.

TL;DR:

• Using specific LocalBusiness subtypes like Restaurant or Dentist improves category clarity and unlocks relevant properties such as menu or servesCuisine.
• The three essential required fields are the exact business name, structured address components, and a properly formatted international phone number, which must match your Google Business Profile.
• Including opening hours, geo coordinates with at least five decimal places, and high-quality images significantly enhances your chances of earning richer local search features.
• Each location should have its own complete, validated JSON-LD schema, placed on its dedicated page, to ensure proper eligibility and avoid site-wide conflicts.
• Regularly test your markup with Google’s Rich Results Test before publishing and monitor Search Console reports afterward to prevent eligibility issues.

Table of Contents

• What Is Local Schema Markup and Why It Matters for Local SEO
• Required LocalBusiness Properties to Include
• Recommended Properties and When to Use a Specific Subtype
• Copy-Ready JSON-LD Examples for Common Scenarios
• How to Add Schema Markup to Your Website
• Testing and Validating Your Schema Markup
• The Implementation Mistakes That Cost You Eligibility
• How Tatem Web Design Approaches Local Schema for Clients
• What SMBs Should Actually Prioritize First
• Get Your Local Schema Built and Verified
• Where to Verify the Details Yourself
• Sources
• FAQ

What Is Local Schema Markup and Why It Matters for Local SEO

Local schema markup is structured code, typically JSON-LD, that sits on a business’s web page and translates plain content into a format search engines can parse directly. Instead of Google guessing your business hours from a paragraph of text, the markup states them explicitly: name, address, phone, hours, category. That clarity is what makes a page eligible for enhanced Google features like knowledge panel details, including hours, directions, and business attributes shown directly in search results.

Here’s the part business owners often get wrong: structured data is not a ranking signal. Google has never claimed that adding schema pushes you above a competitor in rankings. What it does is improve eligibility for rich results and sharpen how your listing appears once it does rank, which tends to lift click-through rate because your result simply looks more complete and trustworthy next to plain blue links.

Specificity matters more than most guides admit. A generic LocalBusiness type works, but Schema.org offers dozens of subtypes, Restaurant, Dentist, Attorney, HealthAndBeautyBusiness, and using the closest match helps search engines categorize your business correctly for relevant local queries.

Why this matters in practice:

• A dental practice marked up as Dentist rather than generic LocalBusiness gives Google a clearer category signal for “dentist near me” queries.
• A restaurant marked up as Restaurant unlocks properties like servesCuisine and menu that a generic business type doesn’t support.
• Multi-location businesses benefit from consistent subtype use across every location page, not a mix of generic and specific types.

Choosing the right type is a five-minute decision that pays off every time your page gets crawled.

Required LocalBusiness Properties to Include

Google’s documentation is specific about what counts as required versus optional, and skipping a required field is the single most common reason a page never becomes eligible for local rich results. Three properties form the non-negotiable core.

Name. Use the exact legal or trading name as it appears on your Google Business Profile and other citations. Mismatched names between your schema and your listings create confusion that Google has to resolve, which may not always be in your favor.

Address, structured as a PostalAddress object rather than a single string. That means breaking the address into its component fields:

• streetAddress — the street number and name
• addressLocality — the city or town
• addressRegion — the state or province
• postalCode — the ZIP or postal code
• addressCountry — the two-letter country code (US, CA, etc.)

Telephone, formatted with the country code included (+1-772-555-0100 rather than a bare local number). This matters more than it sounds. Google’s local business documentation treats the phone field as part of the identity match it uses to connect your schema data to your Google Business Profile, and an inconsistent format can weaken that match.

Pro Tip: Copy your NAP (name, address, phone) directly from your Google Business Profile into your schema, field for field. Retyping it from memory is how small formatting mismatches creep in.

Two rules sit underneath these required fields and trip up more sites than the fields themselves.

First the URL in your markup should point to the specific location page, not your homepage, if you operate more than one location. Second, and this is the rule most template copypastas violate: every piece of marked-up data must be visible somewhere on the page itself. If your schema states a phone number that never appears anywhere in the visible content, that’s flagged as inconsistent structured data, and it can cost you eligibility rather than just get ignored.

Review and aggregateRating properties deserve a caution of their own. You can include them, but only when the ratings come from a legitimate third-party review mechanism, not reviews you collect and host yourself for the purpose of generating a star snippet. Google’s structured data guidelines are explicit that quality and accuracy beat quantity: three accurate, complete required fields outperform ten fields where half are approximate or unverifiable.

Recommended Properties and When to Use a Specific Subtype

Once the required fields are locked in, a handful of recommended properties separate a bare-minimum listing from one that actually earns richer treatment in search results.

openingHoursSpecification is the most valuable addition for most local businesses. Format it as an array of objects, each specifying dayOfWeek, opens, and closes in strict hh:mm:ss time format. If your hours change seasonally, say longer summer hours at a marina or holiday hours at a retail shop, add validFrom and validThrough dates to that specific hours block so Google knows exactly when it applies.

Geo coordinates matter more than most site owners realize, particularly for map-based results. Precision counts here: aim for at least five decimal places on both latitude and longitude to meet the level of accuracy Google’s documentation expects for LocalBusiness geo data. A rounded coordinate can place your pin a block or more off from your actual storefront.

Images deserve real attention if you want to appear in visual features like restaurant carousels. Provide multiple high-resolution images following Google’s recommended aspect ratios; a single low-res logo image is insufficient for image-heavy result types.

priceRange is a short, useful field but easy to get wrong. Keep it concise, using either dollar-sign symbols (like $$) or an explicit numeric range (e.g., $10-30). Don’t write a paragraph explaining your pricing philosophy in this field.

For businesses with departments or multiple locations, structure matters as much as content:

• Each physical location gets its own page and its own complete schema block, not a shared block referencing multiple addresses.
• A business with distinct departments (a hospital with a pharmacy and an ER, for example) can use nested department markup so each unit carries its own hours and contact details.
• Always choose the most specific subtype available. Google’s local business documentation notes that specific subtypes like Restaurant or ProfessionalService help categorize your business more precisely than the generic LocalBusiness type for relevant local queries.

Pro Tip: If you run a multi-location business, build one clean JSON-LD template first, validate it, then duplicate and swap only the location-specific fields. Building each page’s markup from scratch invites inconsistency.

Copy-Ready JSON-LD Examples for Common Scenarios

Seeing the structure in practice clears up more confusion than any explanation. Below are three patterns you can adapt directly, starting with the bare minimum and building up to a full-featured example.

A minimal, required-fields-only listing looks like this:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example Business Name",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Stuart",
    "addressRegion": "FL",
    "postalCode": "34994",
    "addressCountry": "US"
  },
  "telephone": "+1-772-555-0100"
}

That block alone satisfies the required-property floor. A restaurant, by contrast, benefits from the extra properties a specific subtype unlocks:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Example Waterfront Grill",
  "image": [
    "https://example.com/photos/exterior.jpg",
    "https://example.com/photos/interior.jpg"
  ],
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "456 Harbor Drive",
    "addressLocality": "Stuart",
    "addressRegion": "FL",
    "postalCode": "34994",
    "addressCountry": "US"
  },
  "telephone": "+1-772-555-0200",
  "servesCuisine": "Seafood",
  "priceRange": "$$",
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 27.19731,
    "longitude": -80.25314
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "11:00:00",
      "closes": "21:00:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Friday", "Saturday"],
      "opens": "11:00:00",
      "closes": "22:00:00"
    }
  ],
  "menu": "https://example.com/menu"
}

The table below summarizes which properties belong in which scenario, so you can decide how far to build out your own markup.

For multi-location businesses, the pattern that scales best is one canonical JSON-LD block per location page, using the specific subtype, with a unique @id value if you’re linking location pages to a parent organization entity. Resist the temptation to build one giant schema block listing every location on your homepage. It’s harder to validate, harder to maintain, and doesn’t match how Google expects local business data to be structured.

How to Add Schema Markup to Your Website

Implementation is where good intentions meet CMS reality. Here’s the sequence that avoids the most common breakages.

1. Choose JSON-LD as your format. Google explicitly recommends JSON-LD over Microdata or RDFa because it’s easier to implement and maintain, especially at scale across multiple pages.
2. Place the script tag correctly. Add <script type="application/ld+json"> containing your markup in the page’s <head>, or in the <body> if your CMS restricts head access. Google reads structured data from either location.
3. Match every field to visible content. Before you publish, read through the visible page and confirm the name, address, phone, and hours in your schema all appear somewhere a human visitor can actually see them. Hidden fields that exist only in the code are a policy violation, not a shortcut.
4. Build one page per physical location. Each location gets its own URL and its own complete schema block. Don’t try to represent three locations inside one page’s markup.
5. Keep organization-level details centralized. Administrative information like your parent company name, founding date, or overall logo belongs on your homepage or a single About page. Google recommends against duplicating organization-level structured data across every page, since repeating it site-wide can create scale errors that are harder to untangle later.
6. Test before you publish, not after. Paste your draft JSON-LD into Google’s Rich Results Test before it goes live on the production page.
7. Roll out gradually if you manage many locations. Publish and validate one location page fully, confirm it’s eligible, then use it as the template for the rest.

Pro Tip: Most WordPress and Shopify site owners can add JSON-LD through a plugin or theme header snippet without touching raw template files, but always test the rendered output in your browser’s view-source, not just the plugin settings screen, since plugin conflicts can silently strip or duplicate the script tag.

If your CMS makes it difficult to edit the <head> directly, check whether your platform supports a global header script injection. Most modern platforms do, but the exact path varies enough that it’s worth confirming before you assume markup is live.

Testing and Validating Your Schema Markup

Two tools serve two different purposes, and mixing them up wastes time. Google’s Rich Results Test checks whether your markup makes the page eligible for enhanced search features. That’s the test that actually answers “will this show up richer in search results?”

Schema.org’s own validators, by contrast, check whether your code follows correct vocabulary and syntax. That’s useful for catching a typo in a property name, but it won’t tell you whether Google will actually treat the page as rich-result eligible. Run both, but treat the Rich Results Test as the one that matters for eligibility.

Common errors worth checking for before you consider a page done:

• Missing required properties, most often address subfields left incomplete or telephone numbers omitted entirely.
• Images referenced in the markup that are blocked from crawling by a robots.txt rule or a noindex tag on the image itself.
• Invalid time formats in openingHoursSpecification, Google expects strict hh:mm:ss formatting, not “9am” or “9:00 AM.”
• Address fields crammed into a single string instead of broken into the proper PostalAddress subfields.

Once markup is live, testing isn’t a one-time task. Check the Structured Data reports inside Google Search Console periodically, especially after any site redesign, CMS migration, or template change, since those are the moments most likely to silently break or strip your schema. A practical cadence for a freshly deployed rollout: re-check the Search Console structured data report weekly for the first four to eight weeks, then fall back to a monthly glance once things stabilize.

The Implementation Mistakes That Cost You Eligibility

Most schema issues are common and repeated mistakes occurring across many small business websites.

The biggest one: marking up content that isn’t visible on the page. If your JSON-LD lists hours or a phone number that doesn’t appear anywhere in the page’s actual content, that’s a direct violation of Google’s structured data policies, and it can get the markup ignored or the page penalized rather than just skipped.

Review snippets are the second trap. Don’t mark up reviews you collect and manage yourself for the purpose of generating a star rating in search results.

Google’s review snippet guidelines are direct on this point: markup for review or rating snippets is disqualified when the reviews are self-serving, meaning the business being reviewed controls or hosts the review content itself. Legitimate third-party review platforms are the appropriate source for aggregateRating markup, not an internal testimonials page dressed up as customer reviews.

Third, inconsistent NAP data across your website, Google Business Profile, and third-party directories creates a trust problem that schema markup alone can’t fix. If your schema says one phone number and your Google Business Profile lists another, that mismatch undermines the very identity match the markup is supposed to reinforce.

Finally, resist the urge to stuff every possible property into your markup just because it exists. Google’s own guidance favors accuracy over volume: five fields that are completely correct beat fifteen fields where three are guessed or outdated. If you don’t have a confirmed price range, leave the field out rather than approximating it.

How Tatem Web Design Approaches Local Schema for Clients

When we build a location page for a Florida business, the process follows a consistent sequence: audit the existing NAP data across the site and Google Business Profile, build JSON-LD for the specific LocalBusiness subtype that matches the business, verify it with Google’s Rich Results Test before launch, then monitor Search Console’s structured data reports in the weeks after.

That sequence matters more for certain business types than others. A single-location dental office can often manage schema with a careful one-time setup. A professional services firm with multiple offices, a healthcare group with several departments, or any business in a compliance-sensitive sector where accuracy carries real weight benefits from a more structured rollout, one that treats each location page as its own project rather than a copy-paste exercise.

That’s the point where bringing in outside help usually pays for itself: not because the code is hard to write, but because verifying accuracy across ten location pages takes real time most business owners don’t have.

What SMBs Should Actually Prioritize First

Start with one location page, done completely, rather than a half-finished rollout across five. Get the required fields exactly right, add openingHoursSpecification and geo coordinates, validate it with the Rich Results Test, and confirm it’s showing up correctly before you touch a second page.

Escalate to outside help when you hit real friction: a CMS that won’t let you edit the head cleanly, a dozen locations that need consistent templating, or a regulated industry where an inaccurate listing carries more than just an SEO cost. Most single-location businesses don’t need that. Most five-plus-location operations do.

— Matt

Get Your Local Schema Built and Verified

This service offers an alternative to guessing your way through JSON-LD templates: auditing your existing site and Google Business Profile data, building the schema for the correct LocalBusiness subtype, and verifying eligibility with Google’s Rich Results Test before deployment, so you’re not left wondering whether the markup actually works.

For businesses juggling more than one location, or industries like healthcare and legal services where accuracy really counts, our Local SEO Services cover the full sequence: audit, implement, validate, and monitor. If you’re also rebuilding or refreshing the site itself, our AI-powered website design work bakes structured data into the build from day one instead of bolting it on afterward. Call 772-224-8118 to schedule a consultation, or start by requesting an audit of your current location pages to see exactly which required and recommended fields are missing.

Where to Verify the Details Yourself

If you want to check any of this against the primary source instead of taking a blog’s word for it, these are the references worth bookmarking:

• Google Search Central’s LocalBusiness structured data documentation for the full list of required and recommended properties.
• Schema for subtype options and PostalAddress field definitions.
• Google’s Rich Results Test for checking whether your specific markup is eligible for enhanced search features.
• Google’s general structured data guidelines for the policies around accuracy, visibility, and review snippets.

Sources

• Local business (LocalBusiness) structured data | Google Search Central
• Schema
• Structured data general guidelines | Google Search Central

FAQ

What Is Schema Markup?

Schema markup is structured code added to a web page that describes its content in a format search engines can read directly, rather than inferring meaning from plain text. For local businesses, it typically covers name, address, phone number, and hours, which can make the page eligible for enhanced search features like knowledge panel details.

Is Schema Markup Still Relevant?

Yes, and arguably more relevant than ever as search results feature richer visual elements like knowledge panels and map listings. It’s not a ranking signal on its own, but it directly affects whether your page qualifies for the enhanced result formats that improve click-through rates.

Can You Provide an Example of Schema Markup?

A minimal example includes the @type, name, address as a nested PostalAddress object, and telephone, all in JSON-LD format. The full example under the copy-ready JSON-LD section above shows both a minimal listing and a fuller restaurant version with hours, geo coordinates, and price range.

How Do I Know if My Website Has Schema Markup?

View your page’s source code and search for application/ld+json, or run the page URL through Google’s Rich Results Test, which will show any structured data it detects along with eligibility results. If nothing appears in either check, no schema is currently implemented on that page.

Does My Business Need a Specific LocalBusiness Subtype?

It helps. Using a specific subtype like Restaurant, Dentist, or ProfessionalService instead of the generic LocalBusiness type gives Google a clearer category signal and unlocks subtype-specific properties, which supports more precise categorization for relevant local search queries.

Recommended

• Scale Multi Location Local SEO for 15–200 Locations, AI Aware Playbook
• Avoid Doorway Penalties: Service Area Pages SEO for Small Businesses
• Google My Business Optimization Guide
• Local Business Digital Marketing Guide for Small Businesses