Practical structured data guide
LocalBusiness Schema Markup: a complete, accurate example
LocalBusiness structured data should make a real business easier to understand, not create a fictional location. Start with the public identity and contact details that customers can verify on the page.
Quick answer
Use the most specific applicable LocalBusiness type, provide accurate business identity and address data, and keep phone numbers, hours and URLs consistent with the visible page and other official profiles.
The data customers need
A local business page should make the name, address, telephone, hours and services clear even without markup. JSON-LD reinforces those facts for machines; it should not be the only place where they exist.
Avoiding identity errors
Do not combine details from multiple branches into one entity. If a business has separate locations, model each page and address accurately. Do not add a review, rating or service area simply because it might look more complete.
Keeping local data current
Opening hours and telephone numbers change. Treat them as operational data with an owner and a review date. A post-deployment monitor can catch changes, but it cannot decide whether a new value is factually correct.
Copy-ready JSON-LD example
Replace every placeholder with facts that are true and visible on your own page. Do not publish the sample identity, URL or values unchanged.
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Northside Dental",
"url": "https://example.com/",
"telephone": "+1-555-0100",
"address": {
"@type": "PostalAddress",
"streetAddress": "10 Main Street",
"addressLocality": "Austin",
"addressRegion": "TX",
"postalCode": "78701",
"addressCountry": "US"
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday"
],
"opens": "09:00",
"closes": "17:00"
}
]
}What fails
The markup uses a branch address or hours that are not visible or are no longer current. That creates a trust and data-quality problem.
What works better
Use one real business identity per page, keep NAP details consistent and update hours when the business changes them.
Publishing checklist
- Name and location are visible and unambiguous.
- Address and phone are public and current.
- Opening hours use the correct days and local context.
- The page does not merge multiple branches.
- Reviews and ratings are added only when policy and facts support them.
A reliable workflow
Generate or edit the markup, validate the exact code, compare important properties with the visible page, publish it, then inspect the live URL. For critical pages, save a baseline and monitor for field changes after releases. A valid object can still be inaccurate if its data becomes stale.