Structured data
A local business schema example—and what to check before using it
Local business schema is a structured description of facts your website already presents. It can help machines interpret those facts, but it cannot turn an unverified address, a made-up review or a vague service claim into reliable information. Start with the business record, then decide whether additional markup is needed.
By AIBizBuild editorial team · · 3 min read
Check whether your site already has a business record
Ask your developer or existing SEO provider to inspect the published page for structured data. A theme, website platform or plugin may already describe the organization. Find out which system owns that record and whether other pages refer to it consistently.
Do not add a second record simply because a generator produced different formatting. Multiple structured-data blocks can be valid, but conflicting names, locations or phone numbers need investigation. The question is whether they describe real entities accurately, not whether the page contains the largest amount of JSON.
Use this as a fictional starting example
The example below illustrates the shape of a public storefront business record. Every business detail is fictional. Replace it only with facts you are authorized to publish, and include the complete set of properties required for your intended implementation. This is not a ready-to-install record for a home-based service-area business.
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://example.com/#business",
"name": "Example Repair Shop",
"url": "https://example.com/",
"telephone": "+1-202-555-0147",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Example Street",
"addressLocality": "Example City",
"addressRegion": "CA",
"postalCode": "90000",
"addressCountry": "US"
}
}Distinguish valid schema from Google eligibility
Google’s LocalBusiness documentation specifies properties and guidelines for its supported search appearance. Passing a syntax check alone does not establish eligibility or guarantee that a rich result will appear. Review the supported business type and property requirements for the real page.
If your business does not publicly display a customer-facing address, do not invent one or expose a private home address just to satisfy a validator. Discuss an accurate representation with your website specialist and accept that some search appearances may not fit your situation.
Validate three things, not just brackets
First, validate the data format. Second, compare the fields with the visible page and approved business facts. Third, test the published URL after the change. A preview of a proposed code block cannot prove that the platform actually saved or served it.
For a practical handoff, ask for the exact page URL, the system that manages the markup, the test result and any unresolved warnings. An optional-property warning may require a different response from an incorrect required field. The person reviewing the change should explain the distinction.
Keep updates connected to normal business changes
When hours, branding or contact details change, include structured data in the update checklist. Otherwise a website can show one phone number to a visitor while presenting a different number in its machine-readable record.
Use a single owner and a short change log. A good entry says what changed, where it was applied and how it was checked. Avoid adding unsupported ratings, awards, certifications or service locations to make the record look more impressive. Accuracy is the useful output.