QUAKE MEDIA / THE PRACTICAL GUIDE

Local business structured data: what to add, where it goes and how to check it

Understand LocalBusiness JSON-LD, prepare accurate business details, review an example and test the implementation without promising rankings or rich results.

Explore the guide

By Quake Media · 4 minute read

THE BIG PICTURE

Turn business facts into clear markup.

01Business identity

02Page context

03Validation

A framework for the decisions in this guide.

WRITE THE FACTS BEFORE THE MARKUP

Keep structured data aligned with the page.

JSON-LD describes an entity and its visible facts. Syntax validity, factual accuracy, and search eligibility are separate checks.

BUSINESS FACTS TO CONFIRMName and public URLReal address or service areaTelephone and opening hoursLocation relationshipsUse current, approved source records.

ILLUSTRATIVE SHAPE · REPLACE EVERY VALUE

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example Business",
  "url": "https://example.ca/",
  "telephone": "+1-000-000-0000"
}

CHECK 1 · parses as JSONCHECK 2 · matches visible factsCHECK 3 · validate supported features

The example is fictional placeholder data, not a real business or a promise of search display.

Business identity / EXPLORE THE DETAILS

The starting point

Structured data is a machine-readable description of information on your website. For a local business, that can include its name, location, contact details and opening hours. JSON-LD is one way to express it. The job is to describe the business accurately—not to hide extra sales claims in code.

Visible business facts become structured data, then pass through validation and ongoing review. — The markup should describe the real business information people can find on the page.

This guide is for a business owner preparing an implementation or checking a developer's work. You do not need to become a programmer to supply the right facts, ask useful questions and recognize a misleading promise.

Page context / EXPLORE THE DETAILS

Decide what the page actually represents

Schema.org's LocalBusiness vocabulary describes local businesses and supports more specific business types. Choose a type that accurately describes the entity rather than the type you hope will produce the most prominent search result. A company, a particular branch and a service offered by that company are related concepts, but they are not interchangeable.

Google's Local Business documentation sets out requirements for its supported search feature, including name and address. Schema.org vocabulary and Google feature eligibility are different checks. A valid property in the vocabulary does not mean Google uses it for a particular display.

Validation / EXPLORE THE DETAILS

Prepare the facts before the code

For a service-area business, do not invent a storefront or expose an address you intentionally keep private just to satisfy a feature requirement. Ask the implementer which entity description fits the real business and which Google feature, if any, the implementation is intended to support.

Information	What to confirm	Common mistake
Business identity	Correct name, canonical website and a stable identifier	Using a different name in every template
Location	The real location represented by this page	Inventing an office in each service city
Contact details	A working, appropriate public contact method	Publishing a disconnected or private number
Hours	The actual customer-facing hours	Confusing office hours with round-the-clock availability
Images and profiles	Relevant assets and official identity links	Adding unrelated profiles or inaccessible images

Business identity / EXPLORE THE DETAILS

A small JSON-LD example

The following is a fictional illustration, not markup to paste unchanged. Replace every example value with accurate public information and choose the appropriate type. Your developer would place the JSON inside a script element whose type is application/ld+json.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com/#business",
  "name": "Example Workshop",
  "url": "https://example.com/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Example Street",
    "addressLocality": "Example City",
    "addressRegion": "BC",
    "postalCode": "V0V 0V0",
    "addressCountry": "CA"
  }
}

The identifier connects references to the same entity; it should stay consistent. The example is intentionally small so the relationship between the business and address is clear. It is not a complete specification for every business or a guarantee of search-feature eligibility.

Page context / EXPLORE THE DETAILS

Ask how the markup is generated

A theme, plugin, custom template or another integration may already output structured data. Inventory those sources before adding another block. Multiple descriptions are not automatically wrong, but conflicting business names, addresses or identifiers make maintenance harder.

Prefer a clear source of truth for facts that change. If the phone number is updated in the visible page, the structured version should be updated too. Record where the markup lives and who maintains it so the next redesign does not lose or duplicate the implementation.

Validation / EXPLORE THE DETAILS

Handle multiple locations deliberately

Use a location page to explain a real location: contact details, hours, services and customer access. Have the developer represent the corresponding branch consistently. A list of cities you serve is not evidence that you operate an office in each of them.

Check several locations after a template change. A page can contain syntactically valid JSON while accidentally repeating the first branch's address everywhere. A factual spot check catches a different class of error from a validator.

Business identity / EXPLORE THE DETAILS

Validate syntax, eligibility and accuracy separately

Check the facts: compare the markup with the visible business information.
Check the vocabulary: use the Schema.org validator to inspect types and properties.
Check supported Google features: use the Rich Results Test and read its errors and warnings in context.
Check the delivered page: test the public URL after deployment, not just an isolated code sample.
Monitor changes: review relevant Search Console reports and recheck after template or business-detail updates.

Google's structured-data guidelines require accurate, representative markup. Passing a test does not guarantee a rich result. Do not add fabricated reviews or ratings, and check feature-specific restrictions before marking up testimonials.

Page context / EXPLORE THE DETAILS

When to bring in implementation help

Get help when several plugins output conflicting entities, location templates repeat the wrong facts, or nobody owns the implementation. A useful scope includes an inventory, the chosen entity model, template changes, validation evidence and maintenance instructions.

Quake Media can discuss structured data as part of technical SEO or website development. Send us the page and the problem. For the wider local-search picture, use our Business Profile guide alongside the website work.

FROM READING TO DOING

Make your next
move a clear one.

Bring us your goals and the questions this guide raised. We’ll help you work out what belongs in your plan.

Talk it through with Quake

Keep structured data aligned with the page.

The starting point

Decide what the page actually represents

Prepare the facts before the code

A small JSON-LD example

Ask how the markup is generated

Handle multiple locations deliberately

Validate syntax, eligibility and accuracy separately

When to bring in implementation help

Make your nextmove a clear one.

Make your next
move a clear one.