JSON-LD Schema Markup Guide for Metro Vancouver Local Businesses

When I started Get First Position, one of the very first technical fixes I made for local clients was adding proper schema markup, and years later it remains one of the highest leverage changes I can make on a website. This guide walks through everything I teach my own team, from the basic properties every Metro Vancouver business needs to the newer strategies for showing up inside AI generated answers.

I wrote this for business owners and marketers across Vancouver, Burnaby, Surrey, Richmond, Coquitlam, and North Vancouver who want a clear, practical path rather than a theoretical overview. By the end, you will know exactly which schema type fits your business, how to generate the code without hiring a developer, and how to prove the results once it is live.

What Is Local Business Schema Markup?

At Get First Position, I explain local business schema markup to clients as a translation layer between how a business describes itself in plain language and how search engines and AI systems actually read that information. It is a piece of structured code you add to a webpage that tells Google, Bing, ChatGPT, and other systems exactly what your business name is, where it is located, when it is open, and how customers can reach it. Instead of asking a machine to guess these details from paragraphs of marketing copy, schema markup states them directly in a format built for machines to parse.

The reason I always separate this from generic Organization schema comes down to intent. Organization schema is meant for any entity, a nonprofit, a media company, a software brand, and it does not assume the business serves people from a physical location. LocalBusiness schema, and its many subtypes, are built specifically for businesses that operate from a real address and serve a local market. When I audit a client's site, whether it is a dental practice in Kitsilano or a brewery in Burnaby, and I see generic Organization schema in place, I know we are leaving visibility on the table, because search engines cannot infer local relevance from a schema type that was never designed to carry that signal.

JSON-LD vs. Microdata vs. RDFa (Which Format to Use in 2026)

Once a client understands what schema is, the next question I get is which format to actually use, and there are three real options, JSON LD, Microdata, and RDFa. JSON LD is a block of code placed in the head or body of a page that lives independently from the visible content. Microdata and RDFa work differently, they are woven directly into the HTML tags that already display information on the page, which means the schema and the visible text are tied together in the same markup.

In my experience running audits for agency clients across the Lower Mainland, JSON LD has become the practical standard, and Google has said as much for years. It is easier to generate, easier to update without touching the visible design of a page, and far easier to validate, since the entire block can be copied, tested, and swapped without risking a broken layout. Microdata and RDFa still work and Google still supports them, but they require a developer to edit live HTML every time a phone number or an opening hour changes, which slows teams down and increases the chance of human error.

Heading into 2026, I recommend JSON LD to every client without exception, especially now that AI systems like ChatGPT and Google's AI Overviews are pulling structured data to generate answers. These systems favor clean, isolated data blocks over markup that is tangled inside design elements, and JSON LD gives us that clean separation. My advice is simple, unless you have a very specific legacy reason to keep Microdata or RDFa in place, migrate to JSON LD and standardize every location page on that single format.

Why Metro Vancouver Businesses Need Schema Markup in 2026

I tell every client the same thing, schema markup used to be a nice to have for local businesses, but in 2026 it has become a baseline requirement, and that is especially true in a market as dense and competitive as Metro Vancouver. The way people find businesses has split into two paths, traditional search and AI assisted search, and schema markup is the one asset that strengthens your position in both at the same time.

Winning Rich Results in Google Search

When I run a technical audit and find a client with no schema in place, the first fix I make is always local business markup, because it directly feeds star ratings, price ranges, and opening hours into the search results page. Those extra details pull the eye away from competitors and they raise click through rates without spending a single dollar on ads, which matters a great deal when a search for something like "plumber near me" in Vancouver returns a dozen nearly identical listings.

Google has also tightened the requirements for rich results over the past year, and pages without valid structured data are simply excluded from many of these enhanced listings. I have watched clients move up in perceived prominence purely from adding accurate schema, even when their actual ranking position stayed the same, because a listing with stars and hours just looks more trustworthy than a plain blue link, especially to someone comparing several options across Vancouver and Burnaby in the same search.

Getting Cited by AI Answer Engines (ChatGPT, Perplexity, AI Overviews)

This is the part of my strategy that most agencies still ignore, and it is exactly why I built this section into every client roadmap. Tools like ChatGPT, Perplexity, and Google AI Overviews pull structured facts to build their answers, and a business with clean schema is simply easier for these systems to quote with confidence, whether someone is asking for the best sushi restaurant in Richmond or a reliable roofer in Coquitlam.

I have started treating schema as the resume a business hands to an AI system, name, address, hours, reviews, all verified and machine readable in one place. Businesses that skip this step are asking these tools to guess their details from unstructured paragraphs, and in my experience that guesswork often favors a competitor across town who did the structured data work first.

Local Pack / Google Business Profile Alignment

I always tell clients that schema markup and their Google Business Profile need to tell the exact same story, matching name, matching address, matching phone number, matching hours. Any mismatch between what is on the website and what is on the profile creates confusion for Google, and confused systems tend to rank businesses lower out of caution.

This matters even more in Metro Vancouver than in most markets, because so many businesses here operate close to a municipal boundary. A business technically located in North Vancouver but marketing itself as "Vancouver" needs its schema and its Google Business Profile to agree on the real, legal address, or Google will struggle to decide which neighbourhood searches it should actually appear in. My teams review this alignment during every audit, because a small inconsistency here can quietly undercut months of other local SEO work.

The Essential Local Business Schema Properties

Whenever I sit down with a client to plan their schema, I start from one simple table, because these ten properties cover the majority of what search engines and AI systems need to understand a local business.

Required vs. Recommended Properties

In every project I lead, I split this list into two tiers, required and recommended, because trying to add all ten properties on day one often stalls a project. The required tier for me is always name, address, telephone, and openingHours, since these four alone unlock most of the visible benefit in search results.

For Metro Vancouver clients specifically, I am strict about the address property following the Canadian format correctly, street address, city (Vancouver, Burnaby, Surrey, Richmond, or whichever municipality applies), the province as "BC", and the postal code in the proper A1A 1A1 format. I have seen valid looking schema quietly underperform simply because the region field was left as a generic string instead of the correct two letter province code Google expects.

The recommended tier, geo, sameAs, priceRange, aggregateRating, review, and hasMap, adds depth once the basics are live and validated. I usually roll these out in a second phase, because they depend on other systems being ready first, a review collection process, verified social profiles, and accurate map pins, before the schema can honestly reflect what those properties promise.

Common Mistakes That Invalidate Your Markup

The single most common mistake I catch in audits is mismatched information, an address in the schema that no longer matches the address on the page or the Google Business Profile. I see this constantly with businesses that have moved locations within Metro Vancouver, say from a starter space in East Vancouver to a larger storefront in Burnaby, and never updated every mention of the old address across the site. Search engines treat this kind of conflict as a trust problem, not a small technical detail, and it can quietly disqualify a page from rich results.

The second mistake I see constantly is fabricated review data, a business adding an aggregateRating property with numbers that were never actually collected from real customers. This is a direct violation of Google's structured data guidelines, and I have seen it trigger manual penalties that took months to recover from, so I never let a client publish review schema until the underlying reviews genuinely exist.

Choosing the Right @type: LocalBusiness Subtypes

One question I get in almost every onboarding call is which schema type to actually use, and my answer is always the same, go as specific as the vocabulary allows.

Restaurant, Dentist, LegalService, HomeAndConstructionBusiness, etc.

Schema.org offers dozens of LocalBusiness subtypes built for exact industries, Restaurant, Dentist, LegalService, HomeAndConstructionBusiness, AutomotiveBusiness, and many more, and Metro Vancouver's economy touches almost all of them, from the craft breweries scattered across East Van and Burnaby to the tech and professional services firms concentrated downtown and in Surrey's growing business core. Each subtype carries its own extra properties, a Restaurant can declare servesCuisine and acceptsReservations, while a LegalService has no use for either of those fields.

When I assign a subtype to a client, I always search the full schema.org hierarchy first rather than guessing from memory, because new and more precise subtypes get added regularly. Picking the closest match available gives search engines a much richer, more accurate picture of the business than a one size fits all label ever could, whether that business is a Richmond seafood restaurant or a North Vancouver home renovation contractor.

How to Pick the Most Specific Subtype (Why Generic "LocalBusiness" Underperforms)

I treat the generic LocalBusiness type as a last resort, only used when no closer subtype genuinely exists in the vocabulary. Using it by default, out of convenience or unfamiliarity with the options, tells search engines almost nothing about what the business actually does, and that vagueness limits how confidently the business can be matched to relevant local searches, which is a real cost in a market where several nearly identical businesses might sit within a few kilometres of each other.

My rule for every client is simple, walk down the hierarchy as far as it goes. A dental office in Coquitlam should be Dentist, not MedicalBusiness, and definitely not LocalBusiness. The more specific the type, the more relevant properties become available, and the more precisely AI systems and search engines can categorize the business against a real customer intent.

How to Generate Local Business Schema (Step-by-Step)

Once a client agrees on the right subtype and properties, the next step is actually producing the code, and I rely on three methods depending on the size of the project and the technical comfort of the team.

Using Google's Structured Data Markup Helper

For a single location business, I often start with Google's own Structured Data Markup Helper, since it lets you highlight text directly on a live page and tag it as a business name, an address, or a phone number. The tool builds the JSON LD in the background as you tag, and once every field is covered, it generates the finished code block for you to copy.

The limitation I always warn clients about is that this tool can only see what is visible on a single page. If your hours live on one page and your reviews live on another, you end up tagging pieces from multiple sources and stitching them together manually, which adds friction for anything beyond a simple one page business.

Using AI Tools (ChatGPT/Claude) to Generate JSON-LD Faster

My preferred method for most clients today is generating the schema with an AI tool like ChatGPT or Claude, since it skips the manual tagging entirely and handles information scattered across multiple pages without any extra work. I simply describe the business in plain language, its name, address (including the correct BC municipality and postal code), phone number, email, website, hours, and even a sample customer review, and the tool returns a complete JSON LD block ready to paste.

What I like most about this method is how easy it is to refine afterward. I can follow up with a simple request to add social profile links or extra properties, and the tool updates the full block instantly, without me needing to rebuild anything from scratch.

Using WordPress Plugins (Rank Math, Yoast Local SEO, Schema Pro)

For clients who want a code free, ongoing solution built directly into their CMS, I turn to a WordPress plugin, and the three I compare most often are Rank Math, Yoast Local SEO, and Schema Pro.

Multi-Location Businesses: Schema at Scale

This is the section I wish more agencies would write about, because most of the guidance online still assumes a business has one address, and this is exactly the situation I see most often with Metro Vancouver clients who operate one location in Vancouver proper and another in Burnaby, Surrey, or Richmond.

One Schema Block per Location Page (Not One for the Whole Site)

The mistake I correct most often with multi location clients is a single piece of schema sitting on the homepage, trying to represent every branch at once. Search engines cannot separate which address, phone number, or hours belong to which physical location, so the whole effort ends up diluted rather than helpful, and it becomes especially confusing when the locations sit in different municipalities just a few kilometres apart, like a Vancouver and a Burnaby storefront.

My approach is always one dedicated schema block per location page, each carrying its own address, telephone number, and opening hours specific to that branch. This gives every location an equal, independent chance to appear in local results for its own city or neighbourhood, whether that is Kitsilano, Metrotown, or Steveston, instead of competing against its own sibling locations for the same generic markup.

Using @id and sameAs to Link Locations Under One Organization

Once every location has its own schema, I connect them all under a single parent Organization using the @id property, which acts like a permanent anchor that both the location pages and the main brand entity can reference. This tells search engines that these locations are independent branches of one recognized business, rather than unrelated entries that happen to share a name.

I also lean on sameAs at both the location and organization level, linking to verified social profiles, review platforms, and directory listings. This layered structure reinforces trust for the overall brand while still letting each branch, whether in Vancouver or Surrey, build its own distinct local relevance.

Template/Automation Approach for Franchises

For franchise clients with dozens or even hundreds of locations across the Lower Mainland and beyond, I never hand code each schema block individually, since that approach breaks down fast and invites inconsistency. Instead, I build one JSON LD template with placeholder fields for name, address, phone number, and hours, then generate each location's schema from a single spreadsheet of verified data, one row per branch.

This template approach also makes updates painless, since a change to a shared field like a corporate phone number or a new sameAs link can be pushed across every location at once. I treat this as a scalable content operation, not a one time coding task, and it is usually the single biggest efficiency win I bring to multi-location clients expanding across Metro Vancouver.

How to Test and Validate Your Schema

I never consider a schema project finished until it has been tested, because a single typo in the code can silence the entire markup without any visible warning on the page itself.

Google Rich Results Test

This is always my first stop, since it shows me exactly how Google interprets the markup and whether it qualifies for any rich result types. I paste in the live URL, run the test, and review every warning or error the tool flags before I consider the page done.

What I appreciate most about this tool is that it mirrors Google's own eligibility rules, not just generic schema syntax. A block can be perfectly valid code and still fail this test if it is missing a property Google requires for that specific rich result, so I treat this as the real pass or fail moment for any page.

Schema.org Validator

For a broader syntax check that goes beyond Google's own rich result rules, I run the same page through the official Schema.org Validator. This tool checks the markup against the full schema.org vocabulary rather than just the subset Google currently rewards, which helps me catch structural issues early.

I aim for a clean result here, zero errors and zero warnings, before I ever hand a project off to a client as complete. Any flagged issue gets fixed and retested immediately, since a small unresolved warning today often becomes a bigger visibility problem months later.

Site-Wide Audits (Screaming Frog / Semrush Site Audit)

Once individual pages pass, I zoom out and run a full site audit using Screaming Frog or Semrush Site Audit, since these tools reveal patterns a single page test can never show. I can see exactly how many pages carry valid schema, how many are missing it entirely, and which locations have quietly fallen out of compliance.

This site wide view is especially critical for the multi location clients I mentioned earlier, since one broken template can silently invalidate schema across dozens of pages at once, and a franchise spanning Vancouver, Burnaby, and Surrey has that much more surface area for something to quietly break. I schedule these audits on a recurring basis, not as a one time launch task, so any regression gets caught and corrected quickly.

Measuring Impact and Next Steps

Schema work is never something I set and forget, since the real value comes from tracking what changes afterward and adjusting the strategy based on real data.

Tracking Rich Result Impressions in Search Console

Once schema is live, I go straight into Search Console and check the Enhancements section, where Google reports impressions and clicks specifically tied to eligible rich result types. This is the clearest signal I have that the markup is not just valid, but actually being used in the search results people see.

I compare this data monthly against the baseline from before the schema was added, watching for growth in impressions even when overall keyword rankings stay flat. In my experience, this is often where the first real proof of value shows up, since rich results can lift visibility long before a ranking position actually moves.

Monitoring AI Citation Visibility

Checking whether a business is being referenced by AI engines is still a manual process, so I regularly prompt tools like ChatGPT and Perplexity with the exact questions a potential customer might ask, phrased the way a real local searcher would ask them, things like "best family dentist in Burnaby" or "reliable moving company in Richmond BC", then note whether my client's business appears in the answer and whether the details quoted match the schema we published.

I also watch for consistency in these citations over time, since I want to see the same accurate name, address, and hours coming back from the AI tool that we defined in the markup. When the details drift or the business stops appearing altogether, that tells me something in our schema or our underlying data needs a refresh.

CTA: Free Schema Audit — Get First Position

If you have made it this far, there is a good chance your own Metro Vancouver business schema has gaps you have not spotted yet, and that is exactly the kind of review my team runs every day. I invite you to request a free schema audit from Get First Position, where I will personally review your current markup and show you the specific fixes that will move the needle fastest, whether you operate one location in Vancouver or a growing footprint across the Lower Mainland.