What is LocalBusiness schema markup and how does it work?
LocalBusiness schema markup is a standardised vocabulary from schema.org that you embed in your website's HTML to tell search engines precisely what your business is, where it operates, and how customers can reach it. It gives Google a machine-readable description of your business entity rather than forcing the crawler to infer those facts from unstructured page text.
Schema markup is a collaborative vocabulary maintained by Google, Bing, Yahoo, and Yandex. The LocalBusiness type sits within that vocabulary as a subtype of Organisation, which is itself a subtype of Thing. That hierarchy matters: every property you declare at the LocalBusiness level (name, address, telephone, openingHours, geo coordinates, priceRange) inherits the semantic weight of the broader entity graph.
When a search engine crawls a page carrying LocalBusiness markup, it does not simply store a few extra facts. It runs those facts against everything it already knows about the entity from citations, directory listings, and user behaviour signals. Where your on-page declarations match the external record, confidence in the entity rises. Where they conflict, confidence falls and your rankings can stagnate even if your content is excellent.
The markup is typically delivered as JSON-LD embedded in a script tag in the page head. Google's own documentation recommends JSON-LD over Microdata or RDFa because it keeps the structured data separate from the visible HTML, making it easier to maintain and audit.
Here is a minimal but correct LocalBusiness JSON-LD block to illustrate the structure:
“`json
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Kedai Kopi Bangsar",
"address": {
"@type": "PostalAddress",
"streetAddress": "12 Jalan Telawi 3",
"addressLocality": "Bangsar",
"addressRegion": "Kuala Lumpur",
"postalCode": "59100",
"addressCountry": "MY"
},
"telephone": "+60-3-XXXX-XXXX",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "08:00",
"closes": "22:00"
}
],
"url": "https://www.kedaikopibangsar.com.my"
}
“`
Notice that the address block uses its own @type (PostalAddress). Nested types are how schema.org expresses relationships between entities, not just attributes of a single thing. A correctly nested block gives Google a richer graph node than a flat list of text properties ever could.
Key takeaway: LocalBusiness schema markup is the on-page mechanism through which you hand Google a structured, machine-readable entity record. Without it, the engine must guess. With it, you reduce ambiguity and accelerate trust.
What is entity authority and why does it matter for local SEO?
Entity authority is the degree of confidence a search engine places in a named entity (your business) as a distinct, real, and trustworthy subject. The higher that confidence, the more consistently Google surfaces your business in local packs, Knowledge Panels, and AI-generated answers. It is not a single score you can read in Search Console. It is an emergent property of corroborating signals across the web.
The concept traces back to how Google moved from a keyword-matching engine to an entity-understanding engine. The Hummingbird update (2013) and the subsequent integration of the Knowledge Graph shifted Google's core architecture. Today, when someone searches for 'best accountant in Petaling Jaya', Google does not simply match those words. It identifies entities (accountancy firms, their locations, their reputations) and ranks them partly by how well-established each entity is in its knowledge base.
For a local business in Malaysia, entity authority has three practical consequences.
First, disambiguation: Kuala Lumpur alone has dozens of businesses sharing similar trading names. High entity authority tells Google which 'Restoran Sri Melaka' you are, preventing you from bleeding impressions to an unrelated competitor or a defunct listing.
Second, AI citation readiness: generative search tools, including Google's AI Overviews and third-party large language models, pull entity facts when constructing local answers. A business with weak entity authority is simply less likely to be cited, even if its website ranks well for traditional results.
Third, Map Pack stability: businesses with strong entity authority hold their Map Pack positions more consistently across query variants ('open now', 'near me', category-only searches) because Google has enough confidence to generalise their relevance beyond exact-match queries.
Entity authority is built from multiple corroborating sources: your Google Business Profile, citations on directories (Foursquare, Yelp, local Malaysian directories), press mentions, links from topically relevant sites, and the structured data you publish on your own website. That last signal is the one you control most directly, which is why LocalBusiness schema is a foundational step and not an optional add-on.
A useful mental model is what we call the Entity Confidence Stack. At the base sits NAP (name, address, phone number) consistency across the web. On top of that sits structured data, which amplifies and formalises the NAP layer. Above that sit authoritative citations, reviews, and behavioural signals. You cannot skip the lower layers and expect the upper ones to compensate.
Key takeaway: Entity authority is the trust score Google assigns your business as a real-world entity. It directly influences your local pack visibility, your Knowledge Panel, and your chances of being cited in AI-generated answers. Structured data is the layer you own and control.
How does LocalBusiness schema markup signal entity authority to search engines?
LocalBusiness schema signals entity authority by giving search engines a formally structured, corroborable record of your business facts. When those facts match external citations, the engine's confidence in the entity increases. The mechanism is corroboration, not declaration: the markup tells Google what you claim; the wider web tells Google whether to believe you.
Here is the signal chain in plain terms.
Google's crawler ingests the JSON-LD block on your page. The structured data parser extracts the entity's properties: name, address type, geo coordinates, telephone, business category (using the appropriate LocalBusiness subtype such as Restaurant, LegalService, MedicalClinic, and so on).
Those extracted facts are then sent to the entity resolution pipeline. This is the part of Google's infrastructure that asks: 'Do we already have a record for this entity? Does this new data corroborate or contradict what we know?' If the @id property in your JSON-LD matches your Google Business Profile URL or your canonical website URL, entity resolution becomes faster and more confident.
The confidence score attached to your entity node in the Knowledge Graph rises when multiple independent sources report the same facts. Your website's structured data is one source. Your Google Business Profile is another. A citation in a Malaysian business directory is another. Each matching confirmation adds weight; each contradiction subtracts it.
Stronger entity confidence then feeds into local ranking algorithms. The local pack algorithm evaluates three dimensions: relevance, proximity, and prominence. Entity authority is the mechanism behind prominence. A business with a well-confirmed entity record earns a prominence signal advantage that is difficult to replicate through content optimisation alone.
The properties that carry the most disambiguation weight are:
| Property | Why it matters for entity resolution |
|---|---|
| @id (URL or GBP URL) | Creates a stable, machine-resolvable identifier for the entity |
| name | Must match GBP and directory citations exactly |
| address (PostalAddress) | Corroborated against GBP, Maps data, and directory listings |
| geo (GeoCoordinates) | Provides unambiguous spatial anchoring independent of address text |
| telephone | High-value NAP element; mismatches are a common cause of low confidence |
| sameAs (array of profile URLs) | Explicitly links entity to its GBP, Facebook, Waze, and directory profiles |
A general reference breakdown of high-impact LocalBusiness schema properties for entity resolution. Not measured client data.
The sameAs property deserves special attention. When you list your Google Business Profile URL, your Facebook page, your Waze listing, and relevant directory URLs inside a sameAs array, you are explicitly instructing Google's entity resolver to treat all those records as the same real-world entity. This collapses what might otherwise be treated as separate, ambiguous records into a single high-confidence node.
For Malaysian businesses in particular, including a sameAs link to your GBP listing and your listing on platforms like Foursquare or local directories such as Yellow Pages MY strengthens the corroboration chain across the specific sources Google's local algorithm weighs for this market.
Key takeaway: LocalBusiness schema does not rank you by itself. It builds the evidentiary record that local ranking algorithms read when assigning prominence. Your on-page declarations, confirmed by external citations, produce a high-confidence entity node that Google rewards with stable, broad local visibility.
Does LocalBusiness schema markup help with Google Knowledge Graph inclusion?
Yes, correctly implemented LocalBusiness schema is one of the clearest on-page signals that can support Knowledge Graph inclusion for a local business. It does not guarantee a Knowledge Panel, but it materially reduces the friction Google faces when deciding whether your business deserves one.
The Knowledge Graph is Google's internal database of real-world entities: businesses, people, places, and concepts. A Knowledge Panel (the information box that appears in search results for a specific entity query) is a public-facing expression of a Knowledge Graph record. Not every local business gets one, but businesses with strong entity authority, a verified Google Business Profile, and consistent structured data across the web are meaningfully more likely to have one.
Here is how schema specifically helps.
Providing a stable @id: the @id property in your JSON-LD is a URI that uniquely identifies your entity. When Google's Knowledge Graph crawler encounters this ID repeatedly across crawls, it anchors the entity record to that identifier. Without an explicit @id, the engine must attempt to infer the entity's identity from context, which introduces errors.
Bridging to the GBP record: when the URL you use as @id matches your verified Google Business Profile, you are creating a direct bridge between your website's entity declaration and the most authoritative local entity record Google holds. This is the fastest path to Knowledge Graph inclusion for a local business that does not yet have a Wikipedia article or Wikidata entry.
Supporting AI engine citations: a related but distinct benefit is visibility in generative AI tools. Models like Gemini, ChatGPT, and Perplexity all build their knowledge of local businesses partly from the structured, crawlable web. A business with clean LocalBusiness markup is easier for these models to represent accurately in a local recommendation response. This is what we mean at IM Consultant Services when we talk about GEO (generative engine optimisation): structured data is not just a Google-ranking tactic. It is the foundation for how your business appears across all AI-powered answer surfaces.
Publishing markup does not force Google to create a Knowledge Graph entry. Google's inclusion criteria also consider a verified and active Google Business Profile, a meaningful number of external citations from authoritative sources, review volume and recency, and in some cases third-party references from credible publications. Schema markup is a necessary condition for easy inclusion, but not a sufficient one on its own.
Key takeaway: LocalBusiness schema significantly lowers the barrier to Knowledge Graph inclusion by giving Google a stable, machine-readable entity identifier that bridges your website to your GBP record. Pair it with a verified GBP and consistent citations for the strongest result.
What is the difference between LocalBusiness schema and Organisation schema?
Organisation schema describes any group acting as an entity: corporations, non-profits, associations, and brands with no fixed public-facing location. LocalBusiness schema is a subtype of Organisation specifically designed for entities that serve customers at or from a physical location. For any business with a local SEO goal, LocalBusiness (or one of its subtypes) is almost always the correct choice.
The schema.org hierarchy looks like this:
Thing > Organisation > LocalBusiness > [subtype: Restaurant, MedicalClinic, LegalService, AutoRepair, and hundreds more]
Every property available on Organisation is also available on LocalBusiness. But LocalBusiness adds location-specific properties that Organisation does not support: openingHours, openingHoursSpecification, hasMap, branchOf, and the geo property for precise coordinates. These properties are exactly what Google's local algorithm reads when evaluating prominence and relevance for map-based queries.
Using Organisation schema on a page that is targeting local search is a missed signal, not a catastrophic error. But it is a missed signal in a context where every corroborating data point counts.
Choosing the right subtype within LocalBusiness matters even more. A dental clinic in Subang Jaya that marks itself up as LocalBusiness when the Dentist subtype exists is leaving a specificity signal on the table. Google uses the @type to understand what category of business you operate, which directly influences which category-based local queries you are matched to.
| Schema type | Use case | Local SEO support |
|---|---|---|
| Organisation | Brand entities, holding companies, associations, national chains with no single address | Limited: no opening hours, no geo |
| LocalBusiness | Any business serving customers at a location | Full: opening hours, geo, NAP properties |
| LocalBusiness subtype (e.g. Restaurant, Dentist) | Businesses in a defined service category | Maximum: category matching for local queries |
A general reference comparison of schema types. Not measured client data.
For multi-location Malaysian businesses (a chain with outlets in KL, Penang, and JB, for example), the recommended approach is to implement a separate LocalBusiness block on each location's dedicated page, each with its own @id, address, telephone, and geo coordinates. A single Organisation block on the homepage does not serve any individual location's local SEO.
Key takeaway: Use LocalBusiness schema, not Organisation schema, for any entity with a physical service location. Go further and use the most specific subtype available. Specificity is a ranking signal for local queries, and choosing the right @type is a one-time implementation decision with lasting impact.
How do you implement LocalBusiness schema markup correctly for local SEO?
Correct implementation requires four things: the right @type and properties, NAP that is character-for-character identical to your Google Business Profile, a stable @id URI, and a sameAs array pointing to your verified profiles. Place the JSON-LD in the head of your homepage and each location page, then validate with Google's Rich Results Test before pushing to production.
Here is a step-by-step implementation checklist.
Step 1: Choose your @type. Start at schema.org/LocalBusiness and navigate to the most specific subtype that describes your business. If you run a legal firm in Kuala Lumpur, LegalService is more accurate than LocalBusiness. If you run a restaurant in Johor Bahru, use Restaurant. More specific types pass richer category signals to the local algorithm.
Step 2: Nail NAP consistency. Copy your business name, address, and telephone number directly from your Google Business Profile. Do not paraphrase. If your GBP lists 'No. 15, Jalan Ampang', your schema must say 'No. 15, Jalan Ampang', not '15 Jalan Ampang' or '15, Ampang Road'. Character-level mismatches create disambiguation uncertainty.
Step 3: Set a stable @id. Use your canonical website URL (or your GBP URL if you want to create a direct bridge to that record) as the @id value. The same URL should appear consistently across every crawl. Do not use dynamic URLs or session-parameterised URLs as @id values.
Step 4: Add geo coordinates. The GeoCoordinates nested type gives Google a spatial anchor that is independent of how your address text is formatted. Obtain precise latitude and longitude from Google Maps for your exact premises, not just the street.
Step 5: Populate the sameAs array. List every authoritative profile you maintain: your GBP URL, your Facebook business page, Foursquare, Waze, Yellow Pages MY, and any industry-specific directories relevant to your category. Each entry is a corroboration signal.
Step 6: Add openingHoursSpecification. Use the openingHoursSpecification type (not the older openingHours text string) for maximum precision. Specify each day group with opens and closes times. Mark special closures (public holidays) using the validFrom and validThrough properties.
Step 7: Validate and monitor. Run the finished JSON-LD through Google's Rich Results Test (search.google.com/test/rich-results). Confirm zero errors and address any warnings. After deployment, monitor Google Search Console's Enhancements report for structured data health. Revalidate whenever you update business hours, location, or contact details.
Common implementation mistakes that undermine entity authority:
– Using a generic name like 'Home' or 'Main Branch' as the business name in schema while the GBP uses the full trading name.
– Embedding the schema only on the homepage and omitting it from the dedicated contact or location pages that are more likely to rank for location-specific queries.
– Failing to update schema after a change of address or phone number, leaving a contradictory signal that actively damages entity confidence.
– Using the same @id value across multiple location pages for a multi-branch business. Each branch needs its own unique @id.
Key takeaway: Correct LocalBusiness schema implementation is a precision task. The goal is corroboration: every declared property must match your GBP and your citations exactly. One session of careful implementation, validated and kept up to date, delivers a compounding entity authority signal that content optimisation alone cannot replicate.
Does schema markup directly improve local search rankings?
Schema markup is not a direct ranking factor in the way that page speed or backlink authority are. But it is a strong indirect ranking factor because it raises the entity confidence score that feeds the prominence dimension of Google's local ranking algorithm. Businesses with clean, corroborated structured data consistently outperform structurally similar competitors in Map Pack stability and local query coverage.
The honest framing is this: schema markup does not push a ranking lever. It removes friction from the entity resolution process. When Google has high confidence in what your business is, where it is, and what it does, it is more willing to surface you across a broader range of local query variants, not just the exact queries you have optimised pages for. That broadening of coverage is a measurable local SEO outcome, even if it does not show up as a direct ranking boost on a single target keyword.
The practical test is not 'did my ranking for keyword X go up after I added schema?' It is 'did my impressions in local pack results grow across a wider range of related queries?' That second question, answered using Search Console's performance data filtered to map-type results, gives you a far more accurate picture of what structured data is actually doing for your visibility.
For Malaysian businesses competing in categories with dozens of local competitors (law firms in KL, clinics in Subang Jaya, restaurants anywhere in the Klang Valley), entity authority is often the differentiator between businesses that hold Map Pack positions consistently and those that appear only on exact-match queries. Schema markup is the fastest on-site lever for moving that needle.
Key takeaway: Schema markup improves local rankings indirectly by raising entity confidence, which strengthens the prominence signal in Google's local algorithm. Measure the impact through local pack impression breadth in Search Console, not just position changes on a single keyword.
Frequently asked questions
Does schema markup directly improve local search rankings?
Schema markup is not a direct ranking factor, but it is a strong indirect one. It raises entity confidence in Google's Knowledge Graph, which strengthens the prominence signal that local pack rankings depend on. Businesses with clean, corroborated LocalBusiness schema consistently show broader local pack coverage across query variants, even when the markup produces no visible rich result.
What is the difference between LocalBusiness schema and Organisation schema?
Organisation schema describes any group entity, including brands and associations with no fixed public location. LocalBusiness is a subtype of Organisation built specifically for entities that serve customers at a physical address. LocalBusiness adds location-critical properties (openingHours, geo coordinates, hasMap) that Organisation lacks. For any business with a local SEO goal, LocalBusiness or one of its specific subtypes (Restaurant, Dentist, LegalService) is the correct choice.
How does structured data help search engines understand your business entity?
Structured data provides a machine-readable entity record that search engines can parse, store, and cross-reference against external citations. Instead of inferring business facts from unstructured text, Google's entity resolution pipeline reads your declared properties (name, address, geo, telephone) and corroborates them against your Google Business Profile and directory citations. High corroboration produces a high-confidence entity node in the Knowledge Graph.
What is the sameAs property in LocalBusiness schema and why is it important?
The sameAs property is an array of URLs pointing to your business's verified profiles on other platforms: your Google Business Profile, Facebook page, Foursquare, Waze, and relevant directories. Each URL tells Google's entity resolver to treat all those records as the same real-world entity. This collapses fragmented records into a single high-confidence Knowledge Graph node and is one of the fastest ways to strengthen entity authority.
Do I need to add LocalBusiness schema on every page of my website?
You do not need it on every page, but you should add it to your homepage and every dedicated location or contact page. Location pages are more likely to rank for location-specific queries, so they need their own schema block with the correct address and @id for that branch. A homepage-only implementation leaves your location pages without a structured entity signal where it is most needed.
How does LocalBusiness schema support AI-generated local answers (GEO)?
Generative AI tools, including Google's AI Overviews, ChatGPT, and Perplexity, pull entity facts when constructing local recommendation responses. A business with clean LocalBusiness markup is easier for these models to represent accurately because the structured data provides a reliable, parseable fact record. This is the GEO (generative engine optimisation) dimension of structured data: it expands your visibility beyond traditional search results into AI-powered answer surfaces.