Organization Schema yang Benar untuk Brand dengan Banyak Cabang

“Alamat Organization pakai kantor pusat atau semua cabang?”

Pertanyaan ini terdengar teknis sampai kita melihat bisnis dengan 120 outlet.

Satu brand.

Satu legal company.

Puluhan atau ratusan cabang.

Masing-masing punya alamat, jam buka, nomor telepon, layanan, dan kadang profile Google sendiri.

Kalau seluruh cabang dimasukkan sebagai address di satu Organization node, graph menjadi campur.

Kalau setiap cabang dibuat Organization independen tanpa relationship, brand terpecah.

Kalau semua cabang hanya diberi nama brand tanpa location identity, machine dan user sulit membedakan.

Schema untuk multi-branch business perlu memisahkan tiga hal:

Organization pusat.

Brand identity.

Local business/branch identity.

Relationship.

Bukan sekadar memasukkan sebanyak mungkin address.

Organization dan LocalBusiness Punya Peran Berbeda

Schema.org mendefinisikan Organization sebagai organisasi seperti corporation, school, NGO, club, dan sebagainya.

LocalBusiness adalah physical business atau branch dari Organization.

Contoh Schema.org sendiri termasuk restoran tertentu, branch restoran chain, branch bank, medical practice, dan bisnis fisik lain.

Jadi untuk brand retail atau jasa dengan cabang:

Parent/central organization:
Organization atau subtype yang appropriate.

Each physical branch:
LocalBusiness atau subtype yang paling specific jika memang applicable.

Hubungkan relationship sesuai vocabulary yang current dan benar.

Jangan membuat semua outlet menjadi Organization pusat.

Dan jangan membuat satu Organization node punya 100 alamat tanpa menjelaskan mana branch.

Mulai dari Reality, Bukan Template

Contoh fiktif:

Legal organization:
PT Kopi Langit Indonesia.

Brand:
Kopi Langit.

HQ:
Jakarta.

Branches:
Kemang.
Senopati.
Bandung Dago.
Surabaya Pakuwon.

Each branch has:

Address.

Opening hours.

Phone.

Geo.

Menu maybe.

Reservations.

Store ID.

Now graph:

Organization:
PT Kopi Langit Indonesia.

Brand:
Kopi Langit.

LocalBusiness:
Kopi Langit Kemang.

LocalBusiness:
Kopi Langit Senopati.

And so on.

Visible store page should say:

“Kopi Langit Kemang adalah cabang Kopi Langit di Jakarta Selatan.”

Machine and human get same story.

Cabang Bukan Subsidiary

This is important.

Physical branch is not automatically separate legal company.

If outlet is just branch of same organization, don't model as independent subsidiary.

If franchise is operated by different legal company, story changes.

If branch belongs to regional subsidiary, relationship changes again.

Schema cannot replace corporate structure.

Example:

Brand X Store Bali is operated by PT Bali Retail under franchise license.

Not same as parent Organization.

If website says “our branch” but legal operator different, be careful.

Public wording should be accurate.

Structured data must follow reality.

HQ Address vs Branch Address

Organization page can use headquarters or official administrative address that applies to the organization, depending page purpose and data policy.

Branch page uses branch address.

Do not put branch address into parent Organization just because branch is popular.

Do not use registered legal address as storefront if customers cannot visit.

Role clarity.

This matters because generative answers can repeat address as “office”.

A wrong role becomes physical misinformation.

For institutional site, label:

Headquarters.

Registered office.

Branch.

Store.

Service area.

Warehouse.

Don't collapse into `address` without context in visible content.

LocalBusiness Type Harus Specific Jika Memang Ada

Schema.org has LocalBusiness subtypes.

Restaurant.

Store.

MedicalBusiness-related types.

FinancialService.

And many others.

Google structured-data guidelines generally encourage most specific applicable type.

But don't force.

If business doesn't fit a subtype cleanly, LocalBusiness may be safer than incorrect specificity.

Example:

A coworking branch isn't Restaurant because it has coffee.

A tax consultancy with an office isn't BankOrCreditUnion.

A clinic must use medically appropriate type only if reality matches.

Specificity is good.

False specificity is bad.

Cabang Harus Punya Canonical Identity

Each branch important enough to have page should have stable identifier.

STORE-JKT-KMG-001.

Canonical URL:
/locations/kemang/

Name:
Kopi Langit Kemang.

Parent brand:
Kopi Langit.

Operator:
PT Kopi Langit Indonesia, if true.

Address.

Phone.

Hours.

Geo.

Status.

This internal registry prevents branch duplicates.

If store moves, same branch ID maybe persists if business treats continuity as same outlet, or new ID if old closes and new opens. Define policy.

Don't let CMS slug be only identity.

URLs change.

Store ID can stay.

Opening Hours Are Dynamic Data

One of the easiest schema drift points.

Ramadan.

Public holiday.

Renovation.

Emergency closure.

Mall hours.

If structured data says open but branch closed, bad.

Multi-branch businesses need source-of-truth for hours.

POS/store management system.

Central location database.

Then visible page and JSON-LD read same data.

If hours are manually copied into WordPress and markup separately, drift inevitable.

Same for phone.

Address.

Menu/service availability.

Data ops matter.

Google Business Profile Consistency

Google AI/Search guidance also reminds businesses to keep Business Profile information current.

For branches, public identity isn't only website.

Business Profile.

Maps.

Directory.

Social.

Mall directory.

Marketplace.

If store hours conflict, user sees inconsistency.

Schema can't override all external sources.

Treat branch data as managed dataset.

Website is one projection.

Google Business Profile another.

Internal registry is source.

This architecture is more important than adding fancy property.

Dialog di Tim Retail

SEO:
“Kita punya 80 cabang, semua mau schema.”

Operations:
“Jam buka berubah sering.”

Developer:
“Sekarang hardcoded per page.”

Marketing:
“Nama store di Maps beda dengan website.”

Legal:
“10 store franchise, bukan company-owned.”

At this moment schema project becomes master-data project.

Good.

Because that is what multi-branch structured data really requires.

Before adding markup, clean store registry.

Otherwise JSON-LD simply formalizes chaos.

Franchise Harus Dipisahkan

Brand relationship vs operator relationship.

Example:

Brand:
Kopi Langit.

Franchise outlet:
Kopi Langit Makassar.

Operator:
PT Sulawesi Coffee Partner.

Brand owner:
PT Kopi Langit Indonesia.

If public/legal reality supports, page can explain.

Do not necessarily expose operator if business/legal policy doesn't require and not relevant, but don't falsely state parent company operates directly if it doesn't.

Graph internal should know.

Public schema should be accurate to visible public data.

Franchise relationship is not sameAs.

Different organizations.

Same brand.

Location Pages Harus Punya Unique Information

Don't generate 100 thin pages:

“Hadir di [city]. Kami memberikan layanan terbaik.”

Then LocalBusiness schema.

Bad.

Branch page should contain actual branch information:

Address.

Hours.

Contact.

Services/products available.

Accessibility info if relevant.

Directions context.

Photos.

Booking/order.

Store-specific notices.

Operator/brand relation.

Page must be useful without schema.

Otherwise this is location-page spam with structured data decoration.

Entity-first principle applies.

One branch = one useful local entity page, when page is warranted.

Service Area Bukan Cabang

A company may serve 20 cities from one office.

Do not create LocalBusiness nodes for every city.

If no physical branch, don't.

Visible page can explain service area.

Potentially use appropriate properties/content patterns for area served.

But LocalBusiness means physical business/branch context.

“Serving Surabaya” does not equal “Surabaya branch.”

This distinction protects user trust.

Google Maps/AI could send someone to non-existent office otherwise.

Organization Node Jangan Diulang dengan ID Berbeda di Semua Branch

Common plugin problem.

Each LocalBusiness page outputs:

Organization:
Brand X.

But every page generates new blank node or page-specific @id.

Now graph appears to have 100 parent Organizations.

Same name.

Different IDs.

Better:

One canonical Organization @id.

Each branch references same parent/operator identity where appropriate.

Internal registry supplies.

This is why graph design matters.

No need one huge JSON-LD script sitewide if system can reference stable IDs.

But IDs must resolve semantically.

Consistency.

Brand Node juga Bisa Terpisah

Legal Organization:
PT ABC Retail.

Consumer Brand:
FreshMart.

Branches are FreshMart stores.

If schema makes Organization name “FreshMart” everywhere while legal company is PT ABC Retail, maybe commercially okay for LocalBusiness branding but Organization relationship should still be clear.

Model:

Brand:
FreshMart.

Organization:
PT ABC Retail.

LocalBusiness:
FreshMart Kemang.

LocalBusiness uses Brand.

Operator Organization relation in internal/public content.

The exact Schema.org properties available should be chosen carefully. Don't invent relationship if vocabulary doesn't support desired nuance.

Natural language fills gaps.

Public visible relationship matters more than forcing ontology.

Branch Name Must Be Stable and Distinct

“FreshMart Jakarta.”

There are 40 Jakarta stores.

Not enough.

Use actual branch naming:

FreshMart Kemang.

FreshMart PIK Avenue.

FreshMart Kota Kasablanka.

If mall/location names are stable and official.

This helps disambiguation.

Phone numbers and addresses still.

Don't stuff city name.

Naming is identity operation.

If Maps uses “FreshMart – Kokas” and website “FreshMart Kota Kasablanka”, aliases can be managed.

Core ID same.

Department Dalam Satu Location

Google Local Business documentation mentions departments within businesses as another layer.

Example hospital departments.

Store pharmacy inside supermarket.

Bank branch inside mall.

But again, only model if real.

Don't create Department nodes for every service category.

A department should be operationally distinct enough.

Otherwise Service relation is better.

Schema richness should follow business structure.

Multi-Branch Reviews Need Scope

Review is for:

Brand overall?

Specific branch?

Specific product?

Specific staff?

Don't aggregate branch reviews onto parent Organization and claim global rating unless methodology/platform allows and representation is accurate.

One branch with 500 reviews cannot magically make all branches 4.9.

Review scope is entity scope.

If page shows branch-specific reviews, markup branch.

If brand-level system aggregates, visible methodology should be clear.

Follow Google review guidelines for Search features.

Do not self-invent rating.

Branch Closure Needs Lifecycle

Store closes.

What happens page?

Do not leave:

Opening hours.

InStock.

Book now.

Current LocalBusiness.

Update status.

Visible closure.

Redirect if replacement location truly serves same intent.

Maybe keep historical info for a period.

Remove from active location directory.

Update Business Profile.

Update schema.

Sitemap.

Internal links.

AI monitoring.

Closed branches are common source of stale generated answers.

Entity drift at local scale.

Reopening/New Location

Store moves across street.

Same branch or new?

Business policy defines.

If same operation moves:
Update address, keep history/notice.

If old store closes and new store opens as distinct outlet:
New ID.

Don't decide based only on URL convenience.

Operational identity first.

Branch structured data should mirror.

Multi-Country Cabang

Global brand.

Local subsidiaries.

Branches.

Now three layers:

Global Organization/Brand.

Country Organization.

LocalBusiness branch.

Example:

Global Brand A.

PT Brand A Indonesia.

Brand A Jakarta Flagship.

Don't point branch straight to global entity if local operator is distinct and relevant.

Country legal structure matters.

Machine answer:

“Who operates Brand A Jakarta?”

Should be correct.

This is especially important for compliance and contact.

Validation Strategy

Don't test one branch.

Sample:

HQ.

Typical branch.

Franchise.

Mall branch.

24-hour branch.

Closed branch.

New branch.

Branch with special hours.

Branch in another country.

Check:

Visible content.

Structured data.

Canonical.

Organization ID.

LocalBusiness ID.

Address.

Phone.

Hours.

Geo.

Brand/operator.

Status.

If template passes only typical case, production will still break.

Edge cases are where schema governance proves itself.

No Guarantee of AI Citation

Organization + LocalBusiness markup can help structured understanding and supported Search experiences.

It does not guarantee AI Mode citation or recommendation.

Google says no special schema is required for AI features.

For other AI systems, exact use of structured data may be undocumented.

So objective:

Correct branch identity.

Good Search eligibility where supported.

Consistent public data.

Reduced ambiguity.

Then measure AI outputs.

Do not sell:
“Branch schema makes ChatGPT recommend stores.”

Not defensible.

AI Audit untuk Branch

Queries:

“Brand X terdekat di Kemang?”

“Alamat Brand X Senopati?”

“Apakah Brand X punya cabang Surabaya?”

“Jam buka Brand X PIK?”

“Cabang mana yang buka hari Minggu?”

Run.

Compare with source truth.

Track:

Correct branch.

Wrong branch.

Closed branch recommended.

Wrong hours.

Wrong phone.

Source.

This turns local schema into measurable business integrity.

A user asking hours doesn't care your JSON-LD is valid.

They care store is open.

The Best Multi-Branch Schema Starts from Store Operations

If branch database is messy, schema will be messy.

If store names conflict, schema conflicts.

If hours stale, markup stale.

If franchise relation unclear, graph unclear.

So first project may not be “schema implementation.”

It may be:

Clean location master.

Assign stable IDs.

Define branch vs franchise.

Define HQ.

Sync hours.

Fix pages.

Then schema.

That sequence feels slower.

Actually it prevents months of rework.

Organization schema for multi-branch brands is not about putting every location into one giant object.

It is about modeling the hierarchy that already exists:

Organization.

Brand.

Physical branch.

Operator.

Location.

And keeping all five honest.