Schema untuk Entity Hub: Minimal tapi Konsisten

Entity hub sering gagal karena dua alasan yang berlawanan.

Versi pertama terlalu tipis.

Nama.

Logo.

Tiga kalimat.

Selesai.

Versi kedua panik melihat versi pertama lalu memasukkan semua yang bisa ditemukan.

Organization.

Person.

Brand.

Product.

Service.

Review.

FAQ.

Dataset.

Award.

sameAs dua puluh URL.

knowsAbout satu halaman penuh.

Hasilnya bukan entity hub.

Hasilnya lemari yang semua barangnya dimasukkan karena takut ada yang ketinggalan.

Untuk entity hub, schema yang sehat justru cenderung minimal.

Bukan minimal karena malas.

Minimal karena setiap node dan property punya job.

Goal-nya:

Merepresentasikan entity utama dengan jelas.

Menghubungkan relationships yang benar-benar relevan.

Menggunakan canonical IDs yang konsisten.

Dan memastikan markup tetap sinkron dengan page.

Kalau sebuah property tidak membantu menjelaskan identity atau relationship, tidak perlu dipaksakan.

Entity Hub Itu Page Dulu, Schema Belakangan

Sebelum JSON-LD, buka page.

Misalnya entity hub Organization.

Apakah user bisa menjawab:

Siapa organisasi ini?

Nama legal?

Brand publik?

Apa yang dilakukan?

Official domain?

Lokasi?

Siapa yang memimpin, jika relevant?

Produk/service?

Parent/subsidiary?

Evidence?

Official profiles?

Kalau page tidak menjawab, schema tidak boleh menjadi tempat menambahkan cerita rahasia.

Google structured-data guidelines menegaskan markup harus benar-benar merepresentasikan content page dan tidak menandai informasi yang tersembunyi dari user.

Jadi entity hub quality dimulai dari visible information architecture.

Schema follows.

Bukan schema fills the holes.

Minimal Organization Node

Untuk Organization hub, practical baseline bisa sesederhana:

type:
Organization atau subtype yang tepat.

`@id`:
stable canonical Organization identity.

name.

url.

logo jika ada.

legalName jika relevan dan terlihat.

address jika public dan benar.

sameAs yang curated.

Then relationships only if real.

Founder.

parentOrganization.

subOrganization.

Brand relationship.

Contact point.

Tidak semua perlu.

A small consultancy may not need subsidiaries.

University may have departments.

Retail group may have Brands.

The graph should reflect reality.

Not template completeness.

Minimalism bukan property count target.

Minimalism = no decorative facts.

Canonical ID Lebih Penting daripada Menambah 15 Property

Suppose Organization hub perfect.

But Article publisher uses another Organization ID.

Product manufacturer another.

Author worksFor third.

Now entity hub becomes isolated node.

This is why canonical ID matters.

Entity hub should become identity anchor.

Other pages reference same node.

Example conceptual:

Organization:
`https://example.id/#organization`

About page:
main entity → same Organization.

Articles:
publisher → same Organization.

Person:
worksFor → same Organization.

Product:
manufacturer/provider → same Organization where true.

Now graph coherent.

No need repeat every Organization property on every page.

Central definition plus consistent references.

Exact implementation depends stack, but identity contract should be stable.

Entity Hub Bukan Tempat Menandai Semua Halaman Related

A common custom graph pattern:

Organization hub has:

subjectOf:
200 articles.

knowsAbout:
70 concepts.

hasPart:
all site pages.

mentions:
every partner.

Looks impressive.

Maintenance nightmare.

Does Organization actually “have” every article?

Maybe publisher relation already covers.

Does it knowAbout 70 things?

Vague.

Do those relationships help?

Maybe not.

A public entity hub does not need to become sitemap in JSON-LD.

Site navigation and sitemap have their own functions.

Knowledge graph can store richer relationships internally.

Public page schema should stay page-relevant.

Google says structured data should reflect page main focus.

Follow that.

WebPage + Main Entity

Entity hub URL itself can be represented as WebPage or suitable subtype.

The Organization is real-world entity described by page.

Conceptually:

WebPage
→ mainEntity
→ Organization.

Schema.org defines `mainEntity` as primary entity described in a page or other CreativeWork.

Inverse:
`mainEntityOfPage`.

This separation is useful.

The page is not the company.

The page describes the company.

If page URL changes, Organization identity can remain stable depending ID design.

If entity hub is canonical page, URL may be part of identity URI, but model still distinguishes web document from real-world entity.

This matters for graph audits.

AboutPage Can Be Useful, but Don't Obsess

Schema.org has AboutPage as WebPage subtype.

If page is specifically an About page:
reasonable.

But Google Search doesn't owe special rich result because you changed WebPage to AboutPage.

Semantic type is useful for general graph meaning.

Don't oversell.

Could model:

AboutPage mainEntity Organization.

Simple.

No need:
AboutPage + ProfilePage + CollectionPage + Article.

Choose the most applicable.

Specificity with truth.

Brand Hub Is Different from Organization Hub

Brand page:

Brand entity.

Owner/operator Organization.

Products.

Official profiles.

Market.

Visual identity.

Do not force Brand into Organization because Google Organization docs are familiar.

If legal company and public Brand use same name, content should clarify.

Entity type depends reality.

Minimal graph might have:

WebPage.

Brand.

Organization owner.

Selected Product relationships.

That's enough.

Don't mark founder as Brand.

Don't use sameAs between Brand and Organization unless truly same entity, which often they are not conceptually.

Entity separation reduces ambiguity.

Person Hub Needs Privacy Restraint

Profile page for founder/expert:

Person.

name.

role/jobTitle if current.

worksFor.

url.

sameAs official profiles.

Selected works.

Maybe image.

No home address.

No private phone.

No birth date unless relevant/public purpose.

No family enrichment.

Entity hub doesn't mean full data.

Minimalism protects privacy.

A strong Person node can be built from professional identity.

More data isn't automatically better machine understanding.

Precise data is.

Product Hub Needs Product Truth

Product page/hub:

Product or ProductGroup.

Brand.

Manufacturer/provider where true.

Identifiers.

Offer if sellable/current.

Variant relation.

Don't add Organization founder here just because company context.

Page main focus product.

Supporting Organization references enough.

Entity hub schema should respect page focus.

This keeps graph readable.

Dataset hub:
Dataset.

Report hub:
Report.

No one universal template.

“Entity hub” is architecture role, not one Schema.org type.

sameAs Harus Sangat Sedikit dan Sangat Benar

Entity hub is where sameAs makes most sense.

It's identity page.

But don't use quantity target.

Official LinkedIn.

Wikidata.

Wikipedia if legitimate.

Industry/regulatory profile if truly same entity.

Maybe official social.

Each URL:
same entity?

current?

authoritative?

accessible?

If yes.

Founder article:
no.

Product page:
no.

Partner news:
no.

A clean sameAs list is more defensible than a huge one.

Entity hub is identity anchor.

sameAs are identity references.

Evidence Goes in Content, Not All as sameAs

Case study.

Certification.

Media profile.

Research.

Award.

Partner.

These can support trust.

But relation differs.

Entity hub can have visible “Evidence” section.

Links.

Descriptions.

Maybe structured relationships where vocabulary fits.

Don't make everything sameAs.

Don't turn all links into schema edges.

Internal graph can model claim-to-evidence with greater precision.

Public structured data should only express relationships supported by standard vocabulary and page context.

No custom ontology theater.

Schema Minimalism Needs a “Why” Test

For every property:

Why is it here?

`name`:
identity.

`url`:
official web presence.

`logo`:
organization identity.

`legalName`:
legal disambiguation.

`sameAs`:
equivalent identity reference.

`parentOrganization`:
corporate structure.

`founder`:
founding relationship.

If answer:

“SEO plugin recommends.”

Not enough.

If:

“Competitor has it.”

Not enough.

If:

“Maybe AI likes it.”

Not enough.

Property needs semantic job.

Consumer support can be extra reason, but not replace meaning.

Schema.org Vocabulary Lebih Luas daripada Google Search Features

Entity hub often needs semantics not tied to rich result.

Organization.

Person.

Brand.

AboutPage.

mainEntity.

sameAs.

These can help structured representation.

But Google Search features support selected structured data types.

Don't confuse valid graph with guaranteed Search appearance.

Google Organization structured data documentation says markup can help Google understand administrative details and disambiguate organization.

Good.

That's the supported framing.

Not:
“Entity hub schema creates Knowledge Panel.”

Not guaranteed.

Not:
“Entity hub makes AI cite.”

Also not guaranteed.

Separate benefits.

Consistency Across Page Types

Entity hub only works if other templates share rules.

Article:
publisher ID matches Organization hub.

Author:
worksFor matches.

Service:
provider matches.

Product:
brand/provider matches.

Location:
parent/operator matches.

If entity hub says legalName A but footer B:
fix.

If Organization page logo X but Article publisher logo Y:
maybe legitimate old asset, maybe drift.

Schema audit should cross-template.

Entity consistency is site property.

Not just hub property.

Do Not Put `@id` Version Suffixes

Same rule as versioning article.

Organization doesn't become:
`#organization-v2`
because hub redesigned.

Person doesn't become new node because profile moved.

Stable identity.

Use redirects, alias mapping, internal migration.

If canonical hub URL changes, decide ID migration carefully.

No universal requirement that `@id` equal canonical page URL exactly.

But it should be a stable URI that consistently identifies entity.

Pick policy.

Keep.

Don't improvise per page.

Visible Name vs Legal Name

Entity hub often has brand-facing title:

“Nova.”

Legal company:
PT Nova Digital Indonesia.

Don't make two conflicting Organization nodes just because both names exist.

Use:
name = public Organization name appropriate.

legalName = legal registered name if relation true.

Or model Brand separately if Nova is Brand.

Visible content should explain.

“Nova is operated by PT Nova Digital Indonesia.”

One sentence can resolve more than 10 properties.

Human page first.

Markup mirrors.

Entity Hub Bisa Punya Few High-Value Relationships

Think 5–10 strong edges, not 100 weak.

Organization:
parent.
brand.
founder.
location.
official profiles.

Person:
worksFor.
authorOf selected work.
sameAs.

Brand:
owner.
products.

Dataset:
creator.
publisher.
distribution.
related report.

Report:
author.
publisher.
dataset.

This graph becomes comprehensible.

An auditor can inspect.

A developer can maintain.

A reader recognizes same relationships.

Minimal graph is easier to keep current.

Freshness Should Decide Property Inclusion

A property you cannot maintain may be better omitted.

Example:
employee count.

Changes.

If company doesn't have automated public update process:
why publish?

NumberOfEmployees can be valid Schema.org property.

But if stale, it creates conflict.

Same with:
opening hours.
price.
executive roles.
certification.
offers.

Minimalism reduces decay surface.

Static identity fields:
safer.

Dynamic fields:
only if source-of-truth strong.

This is governance.

Not feature poverty.

A Small Entity Hub Can Be Strong

Example illustrative structure:

H1:
PT Nusa Analitika

Intro:
what organization is.

“Identity”:
legal name.
brand.
official site.
location.

“What we do”:
services.

“Leadership”:
current.

“Evidence”:
research/case studies.

“Official profiles”:
curated.

Schema:
WebPage.
Organization.
Maybe Person leadership references.
Breadcrumb.

That's enough.

No 50-node graph.

If user and machine can clearly understand who, what, where, and relationship:
job done.

When Does Hub Need More?

Complexity triggers:

Multi-brand.

Subsidiaries.

Global/local companies.

Many products.

Research outputs.

Regulatory licenses.

Public datasets.

Author network.

Then graph can expand.

But expansion follows actual entities.

Not arbitrary schema depth.

Use internal knowledge graph for richer model.

Public page remains readable.

This distinction keeps website human.

Entity Hub and AI Search

A clear entity hub may improve the quality of information external systems can retrieve.

It can give canonical brand facts.

Identity relationships.

Current source.

But external AI citation selection is not controlled.

So measurement:

Does wrong entity rate fall?

Do branded queries identify correct legal organization?

Does founder relation improve?

Does citation increasingly point canonical page?

Observe.

Don't promise.

If result flat:
hub still provides user trust and site governance.

That's intrinsic value.

Minimal Schema Can Be More Trustworthy

Imagine two graphs.

Graph A:
8 nodes.
All verified.
Stable IDs.
Current.
Visible.

Graph B:
42 nodes.
6 wrong.
8 stale.
sameAs messy.
Hidden claims.
Duplicate Organization.

Which would you choose?

Graph A.

Machine-readable quantity isn't quality.

This is the core entity-hub principle.

Build only relationships you can defend.

Keep IDs stable.

Keep page useful.

Keep markup aligned.

Minimal doesn't mean incomplete.

It means every field earns its place.

And for an entity hub, that discipline is often more valuable than the extra 30 properties everyone wants to add because the validator still has empty space.