Organization vs LocalBusiness schema for a Montreal company

LocalBusiness is a subtype of Organization. It is not a stronger version, and choosing it does not make a site more local. It adds properties that only make sense for a business tied to a place: a street address, opening hours, a geographic position. If those facts are true and visible on your site, use it. If they are not, plain Organization (or a service-oriented subtype) describes you more honestly.

The question comes up constantly with Montreal clients, because a lot of the businesses we work with are service-area businesses: they travel, work remotely or operate from a small studio without walk-in traffic. For them, the wrong choice leads straight to the temptation of a made-up address. Here is how we decide.

What schema markup is actually for

Structured data is a label. It tells a machine "this name is a company, this phone number belongs to it, these are the languages it serves" in a format that does not depend on how the page is designed. Google documents what it uses in its structured data guidelines, and the rule that matters most is that markup must describe content that is visible to users on the page.

Three expectations to set early:

• Schema does not guarantee a rich result. Eligibility is not entitlement.
• Schema does not raise rankings by itself. It reduces ambiguity.
• Schema cannot rescue a page that does not make its claims in plain text. That is a writing problem; see claim-complete paragraphs for AI answers.

The decision, in one table

Subtypes are worth using when one fits. A plumber is a Plumber, a law firm a LegalService, an agency a ProfessionalService. A specific subtype is more informative than a generic LocalBusiness. Browse the hierarchy on schema.org rather than guessing.

How a service-area business describes itself

AERVIO is a service-area business. Montreal is the base, Canada is the service area, and we do not publish a street address because customers do not visit. That shapes the markup:

“`json { "@context": "https://schema.org", "@type": "ProfessionalService", "name": "AERVIO", "url": "https://aervio.io/", "email": "hello@aervio.io", "telephone": "+1-438-498-3913", "areaServed": { "@type": "Country", "name": "Canada" }, "availableLanguage": ["en-CA", "fr-CA"], "address": { "@type": "PostalAddress", "addressLocality": "Montreal", "addressRegion": "QC", "addressCountry": "CA" }, "openingHoursSpecification": { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"], "opens": "09:00", "closes": "17:00" } } “`

Note what is absent: no `streetAddress`, no `geo` coordinates, no `hasMap`. We state the city, the region and the country, because that is true. If we invented a street to satisfy a validator, we would be publishing a fact we cannot stand behind, and it would conflict with our hidden-address profile described in Google Business Profile for service-area businesses.

One honest caveat: Google's documentation for local business rich results lists an address among the properties it expects. A service-area company may therefore not be eligible for that specific feature, and that is acceptable. The markup still communicates identity, contact and coverage to any consumer of schema.org data. Check the current local business documentation before you promise a client a feature.

Consistency is the real job

Most schema problems we find are not syntax errors. They are contradictions:

• The footer says one phone number, the JSON-LD says another.
• The profile hides an address, the markup publishes one.
• The site is bilingual, the markup declares a single language.
• The company is "AERVIO" on the site and "Aervio Digital Inc." in the markup.

Pick a canonical set of facts — legal or trade name, phone, email, hours, service area, languages — and make the site copy, footer, Google profile and JSON-LD all read from it. Where we can, we render both the visible footer and the structured data from that same source, so they cannot drift. The wider case for treating site, CRM and search as one system is in one system for site, CRM and search.

Language and the bilingual site

For Quebec sites, markup should reflect both languages honestly. Use `availableLanguage` on the organization, set `inLanguage` on pages, and output the markup on both the FR and EN versions with the correct translated `name` or `description` for each. Pair the pages with reciprocal hreflang, as described in Bill 96 and your website. Markup that is English-only on a French page is a quiet mismatch, and it is trivial to avoid.

Mark up the entity once, and the page for what it is

A clean pattern for most sites:

1. Home page or About page: one Organization (or subtype) block with a stable `@id`, so other markup can reference it.
2. Articles: an Article or BlogPosting with `publisher` pointing at that `@id`, an author, and dates that match what the page shows.
3. Service pages: a Service with `provider` pointing at the same `@id` and an `areaServed`.
4. FAQ blocks: if you include FAQPage markup, be aware that Google now shows FAQ rich results for only a narrow set of sites. We still use FAQ-structured HTML because it gives machines and readers clean question-and-answer pairs, but we do not sell it as a ranking tactic.

Reusing one `@id` for the entity lets everything connect without repeating fields that can go stale.

Validate, then read it back as a stranger

Run the markup through Google's Rich Results Test and the Schema Markup Validator, fix errors, and then do the step most people skip: read the output as a stranger would. Does every value match something on the page? Would you be comfortable if a journalist compared the JSON-LD to your front door? If not, remove what you cannot defend.

What to do this week

• Decide whether you are a storefront, a service-area business or both.
• Write down the one canonical set of facts and compare it to your footer, profile and markup.
• Remove any address, coordinates or hours you do not actually offer.
• Add `areaServed` and `availableLanguage` where they are true.
• Revalidate after every theme or plugin update.

If you want us to audit the structured data on your site, write to hello@aervio.io or call +1 438-498-3913, weekdays 9–17 ET. We will report what is wrong, what is merely untidy, and what to leave alone — without promising rankings, because no one honestly can. For the wider approach, start with SEO and GEO in Montreal.

Questions

Is LocalBusiness better than Organization for local SEO?

Not automatically. LocalBusiness is a subtype of Organization that adds place-based properties such as address and opening hours. It fits a business with a real, staffed location. For a service-area or remote business, a plain Organization or a service subtype with areaServed is often more honest.

Can I use LocalBusiness schema without a street address?

Schema.org allows a partial address, and you can describe the area you serve with areaServed. Google's documentation for local business rich results expects an address, so do not expect that specific feature without one. Never invent a street to satisfy a validator.

Will schema markup improve my rankings?

No promise. Structured data helps machines read what a page says and can make you eligible for some result features, but it does not by itself raise rankings. Treat it as clear labelling of facts already visible on the page.