Schema Governance untuk Website dengan Ratusan Halaman

Website punya 12 halaman.

Schema bisa diurus manual.

Website punya 800 halaman.

Manual mulai bocor.

Website punya 20.000 URL, lima template, tiga plugin, dua languages, Product, Article, Person, Organization, Report, Dataset, dan LocalBusiness.

Schema bukan lagi “SEO markup”.

Ia sudah menjadi production data system.

Di scale seperti itu, pertanyaan terpenting bukan:

“Schema apa yang harus ditambah?”

Pertanyaannya:

“Siapa yang menjaga semua structured data ini tetap benar setelah tiga tahun, lima plugin update, dua rebrand, 400 author changes, dan ribuan content edits?”

Itu schema governance.

Governance bukan document 70 halaman yang tidak dibaca.

Governance adalah rule sederhana yang menentukan:

Siapa owner.

Source mana yang dipercaya.

Type mana dipakai.

ID mana canonical.

Kapan update.

Bagaimana validate.

Bagaimana rollback.

Apa yang dilakukan saat platform support berubah.

Tanpa governance, website besar hampir pasti mengalami schema drift.

Scale Mengubah Nature of Error

Di site kecil:

Satu page salah price.

Di site besar:

Satu template salah price di 20.000 products.

Di site kecil:

Author ID duplicate 3 pages.

Di publisher:

Duplicate Person nodes di 50.000 articles.

Di site kecil:

Breadcrumb conflict satu URL.

Di large site:

Taxonomy generator salah sitewide.

Error impact becomes multiplicative.

Therefore:
manual spot-check isn't enough.

Need rules + automation + sampled human semantic review.

Not either/or.

Both.

Schema Registry adalah Starting Point

Create inventory.

Types used:

Organization.

WebSite.

WebPage.

Article.

BlogPosting.

Person.

ProfilePage.

BreadcrumbList.

Product.

ProductGroup.

Offer.

LocalBusiness.

Report.

Dataset.

FAQPage if applicable.

Review.

Each row:

Purpose.

Templates.

Owner.

Generator.

Source.

Canonical ID rule.

Google Search support.

Schema.org status.

Review cadence.

Version.

Example:

Organization.
Owner: Corporate data.
Generator: Core runtime.
Source: entity registry.
ID: `/#organization`.
Consumer: Google Organization + general semantics.
Review: event-triggered.

Article.
Owner: Editorial platform.
Generator: CMS.
Source: post metadata.
ID: URL#article.
Review: per template release.

Now schema ecosystem visible.

Without inventory:
hidden outputs.

Plugin surprise.

No accountability.

One Type, One Semantic Owner

This rule is gold.

Not necessarily one script.

One owner.

Organization:
Corporate identity team/runtime.

Product:
Commerce/PIM.

Article:
Editorial CMS.

Person:
People/editorial registry.

LocalBusiness:
Location master.

Dataset:
Research/data team.

Breadcrumb:
Information architecture.

Why?

If SEO owns product price:
bad.

If developer invents legalName:
bad.

If editor changes store address:
bad.

Schema value should come from domain owner.

SEO/structured-data team maps semantics and consumer requirements.

But facts belong business source.

This is governance.

Canonical ID Policy

Define globally.

Organization:
stable.

Brand:
stable.

Person:
stable profile URI.

Product:
stable product ID/URI.

LocalBusiness:
store ID.

Article:
canonical URL.

Dataset:
versioned ID.

Don't let plugins generate random duplicate identifiers.

A canonical ID policy lets:

Article publisher reference Organization.

Person worksFor same Organization.

Product manufacturer same.

Cross-domain.

Multi-language.

Graph stays connected.

If entity rebrands:
ID continuity policy.

If real entity changes:
new ID.

Document.

This is core.

Source-of-Truth Matrix

Critical fields:

Field | Source

Organization legalName:
corporate registry/internal legal master.

Brand name:
brand registry.

Product price:
commerce system.

Product GTIN:
PIM.

Author:
CMS contribution record.

Reviewer:
review workflow.

Store hours:
location system.

Dataset version:
research registry.

Report date:
publication system.

Do not hardcode duplicates.

Structured data generator consumes.

Visible page also consumes where possible.

This alignment reduces semantic conflicts.

If page and schema draw same source:
less drift.

Governance is data lineage.

Template Contract

For each template, define expected nodes.

Article page:

WebPage.

Article.

Author Person/Organization.

Publisher Organization.

Breadcrumb.

Maybe ImageObject.

Not:
Product unless real product main item.

Not:
LocalBusiness because footer address.

Product page:

WebPage.

Product/ProductGroup.

Offer.

Brand.

Organization where relevant.

Breadcrumb.

Maybe Review if real.

Location page:

WebPage.

LocalBusiness.

Organization parent/operator.

Breadcrumb.

These contracts stop schema creep.

When plugin adds surprise type:
test fails.

No one casually adds FAQPage sitewide.

Template semantics become code specification.

Required vs Optional Internal Rules

Google may have required/recommended fields for certain Search features.

Your organization can add internal requirements.

Example Article:

author required.

datePublished required.

dateModified required.

headline required.

publisher required.

image recommended.

Author URL required if named Person.

Not because Google universally requires all.

Because company wants accountability.

Label separately:
platform requirement vs internal governance.

Don't confuse.

If internal rule changes:
version.

This makes discussions clear.

Visibility Alignment Rule

Any material structured data must reflect visible content per platform guidelines.

Operationalize.

For each field:
where visible?

Price:
product price UI.

Author:
byline.

Reviewer:
review badge/profile.

Organization:
About/footer.

Address:
contact/location page.

Dataset license:
dataset landing page.

If no visible representation:
review.

Some machine fields may not need literal visible text in exact format, but underlying fact must be accessible and not misleading.

Set semantic QA.

No hidden alternate reality.

Plugin Governance

Website with multiple plugins needs policy:

Allowed schema plugins.

Types each owns.

Forbidden overlaps.

Update process.

Staging tests.

Changelog review.

Do not install new plugin with schema output directly production.

Before activation:
what JSON-LD appears?

Does it duplicate?

Can disable module?

Does it alter `@id`?

Does it use source-of-truth?

Plugin procurement should include schema impact.

This sounds excessive until one plugin creates 5,000 fake reviews.

Governance prevents.

Custom Runtime Governance

Custom code also risky.

Version.

Repository.

Code review.

Tests.

Rollback.

Feature flags.

Document node ownership.

Do not let random snippet in functions.php become core entity layer.

Schema is invisible to most users, so broken code can survive unnoticed.

Custom runtime should output diagnostic version internally or via audit tool.

Sample.

Checksum if operations require.

Treat as software.

Change Management

Every business event can trigger schema updates.

Rebrand.

CEO change.

Office move.

Product launch.

Product discontinue.

Store closure.

New subsidiary.

Acquisition.

Author leaves.

Reviewer credential change.

Dataset new version.

Return policy.

Create event matrix.

Event:
CEO change.

Affected:
Organization page.
Person profile.
Article references if current bio.
Schema Person/Organization.
Press kit.

Event:
Store closure.
Location page.
LocalBusiness JSON-LD.
Sitemap.
Internal links.
Business Profile.
Merchant/local feed.

Governance connects operations to markup.

Without trigger, schema stale.

Release Pipeline

1. Change data source.

2. Render staging.

3. Unit/schema test.

4. Semantic QA.

5. Rich Results Test where applicable.

6. Crawl sample.

7. Deploy subset if risky.

8. Monitor.

9. Rollout.

10. Search Console/consumer monitoring.

Not every typo needs full ceremony.

Template/schema code changes do.

Risk-based.

A change to Organization generator sitewide:
high risk.

One article author correction:
low.

Scale demands classification.

Automated Tests That Are Actually Useful

Syntax parse.

No duplicate canonical IDs.

No conflicting Organization names.

Required internal fields.

URL canonical consistency.

Price equals visible price.

Availability equals product state.

Author exists.

Author URL valid.

Breadcrumb URLs 200.

No stale LocalBusiness status.

No unsupported/deprecated consumer feature without exception.

No hidden fake rating.

No schema on noindex where irrelevant to intended consumer.

Not all tests can be automated.

But many can.

Human Semantic Sampling

Automation cannot know:

Is Person actual founder?

Is branch really branch?

Is ClaimReview genuine fact-check?

Is Report actually report?

Is sameAs same entity?

Sample by template.

Monthly/quarterly.

High-risk changes.

Have editor/business owner review.

Ask sentence test:
“What is this node claiming?”

If weird:
flag.

Human review catches semantic errors.

Schema Coverage Should Not Be Main KPI

“98% pages have schema.”

Sounds good.

Maybe 98% wrong.

Better KPIs:

Critical template semantic pass rate.

Duplicate entity rate.

Stale field rate.

Broken ID rate.

Price mismatch rate.

Author attribution completeness.

Location freshness.

Consumer eligibility errors.

Schema coverage is supporting.

Quality > quantity.

A page with no unnecessary schema can be healthier than page with wrong schema.

Don't force coverage target.

Search Feature Support Registry

ClaimReview shows why.

Track each Google Search feature status.

Active.

Phasing out.

Deprecated.

Removed.

Other Google product.

Schema.org-only.

Review current docs.

When status changes:
impact.

Documentation.

Code.

Reporting.

Training.

KPI.

Don't keep stale checklists from 2022.

Platform support is dynamic.

Schema governance includes external dependency management.

Multi-Language Governance

Indonesian and English sites.

Same Organization.

Different page URLs.

Same entity ID policy across language/country depending architecture.

Visible names may translate.

Legal name stable.

Article separate per language.

Person same.

Product same or market-specific.

Don't generate duplicate entity just because language.

But don't force same Organization if country subsidiary distinct.

Language architecture needs entity model.

Governance makes rule explicit.

Multi-Domain Governance

Corporate.

Product.

Docs.

Support.

Regional.

Each may emit Organization.

Need shared registry.

Canonical Organization ID.

Brand ID.

Product IDs.

Cross-domain references.

Don't let each CMS invent.

If domains managed separately, publish machine-readable config or shared package internally.

Schema contract.

Otherwise identity fragments.

Privacy and Security Review

Person data.

Internal IDs.

Store private details.

Customer review data.

Dataset metadata.

Agent/tool identities.

Don't publish internal fields accidentally.

Public structured data is public.

JSON-LD invisible visually but accessible.

Create allowlist.

Which internal fields can project.

No employee ID.

No private email.

No CRM ID unless intentionally public identifier.

Schema governance includes security.

Incident Response

What if schema bug deploys?

Wrong price sitewide.

Wrong legal name.

Fake review.

Personal data exposed.

Need:

Disable switch.

Rollback.

Purge cache.

Recrawl strategy.

Search Console monitoring.

Notification owner.

Postmortem.

Schema incident may not break page rendering.

So detection requires monitoring.

Invisible incident still real.

Version Everything Important

Runtime version.

Entity registry version.

Template schema version.

Feed version.

Dataset version.

Plugin version.

When report:
“Error began August 4.”

You can correlate release.

Without version:
guess.

This also helps AI visibility measurement.

If citation changes after schema release, know what changed.

Still no causal proof.

But change log exists.

Documentation Should Be Short Enough to Use

Bad governance:
100-page PDF.

Good:

Type registry.

Ownership matrix.

ID policy.

Template contracts.

Release checklist.

Deprecation register.

Incident playbook.

Examples.

Keep in repository/wiki.

Update.

Train developers/editors.

Governance fails if only SEO lead knows.

Schema touches many teams.

Make accessible.

RACI Model Can Help

Organization facts:
Legal/Brand accountable.

Implementation:
Developer responsible.

Search support:
SEO consulted.

Privacy:
Legal/Security consulted.

Editorial:
informed.

Product:
Commerce accountable.

Author:
Editorial accountable.

No need bureaucratic RACI for every site.

For enterprise, useful.

The question:
who can approve truth?

Not who can edit JSON.

Different.

Governance for 500 Pages Can Start Simple

Don't overengineer.

Spreadsheet registry.

One custom generator.

Five sample tests.

Quarterly audit.

Enough.

For 50,000:
automated pipeline.

Central entity service.

PIM.

CI tests.

Monitoring.

Scale.

Maturity should match size.

The principle same.

One truth.

Clear owner.

Stable ID.

Version.

Validation.

No hidden claims.

AI Search Does Not Change Core Governance

AI makes entity accuracy and machine-readable consistency more visible.

But no special “AI schema governance” needed as separate universe.

Google explicitly says no special schema.org markup is required for AI Overviews/AI Mode.

So governance should remain standards-based.

Use correct structured data.

Good content.

Crawlability.

Evidence.

Then AI measurement separately.

Don't contaminate production graph with speculative fields.

If experimenting:
feature flag.

Track.

Don't call official.

This keeps architecture clean.

A Large Website Needs a Schema Constitution

Not rigid law.

A small set of principles:

Truth before completeness.

Visible content before hidden claims.

Entity IDs stable.

One owner per semantic object.

Source-of-truth defined.

Platform docs checked.

No duplicate ownership.

Changes versioned.

High-risk fields reviewed.

Deprecated features retired intentionally.

AI impact measured, not promised.

If every developer and editor knows these ten principles, structured data scales much better.

Schema governance isn't exciting.

That's why it works.

The goal is not to create a graph that looks impressive on launch day.

The goal is that two years later, after hundreds of new pages and several platform changes, the graph still describes the same reality humans see.

At scale, correctness is not an implementation detail.

It is the product.