LocalBusiness structured data is a block of machine-readable information, usually JSON-LD, that describes a physical business: name, URL, phone, address, and similar facts. Search engines may read it. Visitors still need the same facts in visible HTML. Structured data is a parallel copy, not a place to hide a keyword list.
Adding the block does not guarantee rich results, map placement, or rankings. Validate the syntax. Do not promise a star rating or a map pack you do not control.
Properties that should match the page
Use types from Schema.org. LocalBusiness is the general type. A more specific subtype (ProfessionalService, for example) is appropriate only when it is accurate.
Fields teams commonly include, when they are true and visible:
name— the trading name as shown on the pageurl— the canonical page for that locationtelephone— a number you answer, in international form such as+60…address—streetAddress,addressLocality,addressRegion,postalCode, andaddressCountryopeningHours— only if you publish hours and keep them updatedgeo— only if you know the coordinatesimage— a real image URL of the premises or logo you are willing to showpriceRange— only if it is not a fiction
Omit a property you cannot keep true. An old Saturday hour in JSON-LD and a different hour in the footer is a contradiction.
If you have several branches, each location page should describe that branch. Do not mark up every branch on the homepage as if they were one address.
JSON-LD in practice
Place a single script of type application/ld+json in the page, generated from the same content source as the visible address block. Hand-editing JSON in a template while editors change the footer in the CMS guarantees drift. Publishing responsibility is discussed in content publishing workflow.
Check the JSON in a structured-data validator. Fix errors such as a string where an object is required. Warnings are not the same as a promise that a search engine will display anything.
Company registration details that Malaysian sites are expected to show are a visible-content concern. See the article on displaying a registered company name and number. Repeat those details in schema only when they belong to a property you are actually using, and still show them on the page.
Publishing location data twice, consistently
- Write the name, address, and phone in HTML
- Generate JSON-LD from those same values
- Validate the script
- Update hours in both places when they change
- Re-check after a redesign or CMS change
A practical example
A Johor Bahru office page shows the street, postcode, and a +60 phone number. The JSON-LD LocalBusiness node copies those strings and the page URL. Opening hours are left out because the team does not want to maintain them weekly. A second branch in Penang has its own page and its own node. The homepage does not claim both streets as one address. After launch they run the page through a validator and correct a missing comma. They do not add review stars they cannot show on the page.
Key takeaways
- JSON-LD should repeat visible facts, not invent new ones.
- One location per page when the addresses differ.
- Validate syntax, and do not promise rich results.
- Generate the markup from the same source as the footer or contact block.
FAQ
Can we paste an example from a generator and forget it?
Only if you replace every field and connect future edits to that source. Stale generators are a common reason the markup disagrees with the page.
Should blog posts use LocalBusiness?
Use it on the page that represents the business or a branch. Marking every article as the whole company adds noise. Articles can link to the contact page instead.
Does structured data replace a Google Business Profile?
No. A business profile is a separate listing you manage. On-page schema describes the page. Keep the name, address, and phone consistent across them, but they are not the same system.