Checklist Schema 2026 untuk Website Institusional

Website institusional jarang rusak karena kekurangan schema type.

Lebih sering karena terlalu banyak pihak menyentuh data yang sama.

Theme membuat Organization.

Plugin membuat Organization kedua.

Research team membuat Dataset.

Editorial membuat Article.

Developer menambah Report.

HR membuat Person.

Location page membuat LocalBusiness.

Dua tahun kemudian founder salah, alamat lama, author duplicate, FAQ schema masih dipasang di semua halaman, ClaimReview tetap dianggap rich-result strategy, dan tidak ada yang tahu node mana authoritative.

Karena itu checklist schema 2026 untuk website institusional sebaiknya tidak dimulai dari:

“Sudah pasang JSON-LD belum?”

Mulai dari:

“Apakah kita punya satu realitas yang konsisten untuk diterjemahkan ke structured data?”

Schema adalah output dari governance.

Kalau governance kacau, markup hanya membuat kekacauan lebih terstruktur.

Berikut practical checklist yang bisa dipakai sebagai quality gate sebelum scale.

1. Tentukan Entity Utama Institusi

Siapa organisasi yang sebenarnya?

Brand publik.

Legal name.

Official URL.

Parent organization.

Subsidiaries.

Programs.

Brands.

Locations.

Leaders.

Do not start schema before team agrees.

If website says “GEO.or.id” but legal operator different, explain relationship.

If Brand and Organization distinct:
model distinct.

If program is not legal entity:
don't make Organization automatically.

Core identity must be documented.

2. Tetapkan Canonical Organization ID

One stable `@id`.

Referenced from:

WebSite.

Article publisher.

Person worksFor.

Service provider.

Product/Brand relationships where true.

LocalBusiness parent/operator where true.

Don't allow plugin IDs:

`/#organization`

`/about/#org`

`/#company`

all represent same entity.

Choose.

Document.

Keep stable across redesign.

Schema contract.

3. Pisahkan Page dari Entity

About page is WebPage/AboutPage.

Organization is the entity described.

Person profile is ProfilePage/WebPage describing Person.

Product page describes Product.

Research landing page may describe Report/Dataset.

This avoids type confusion.

Use `mainEntity` or related patterns where semantically appropriate.

Don't call WebPage an Organization.

Don't call Organization page Product because it mentions service.

Page type and entity type have separate jobs.

4. Inventory Semua Schema Generator

Theme.

SEO plugin.

Commerce.

Review plugin.

Page builder.

Custom runtime.

Tag manager.

JavaScript.

External widgets.

List types each outputs.

Duplicate Organization?

Breadcrumb?

Article?

FAQ?

Product?

Assign ownership.

One semantic object should have one authoritative owner.

Multiple scripts are not inherently wrong.

Conflicting definitions are.

5. Compare Visible Content dan JSON-LD

For sample templates:

Name.

Author.

Publisher.

Price.

Stock.

Address.

Hours.

Date.

Review.

Legal name.

FAQ.

Dataset license.

Does structured data say same thing?

Google's general guideline remains clear:
structured data should represent page content and not be misleading/hidden.

Green validator isn't enough.

Semantic QA.

6. Use Google-Supported Types for Google Features, Schema.org for Semantics

Don't conflate.

Google Search supports selected structured-data features.

Schema.org vocabulary is broader.

A Report can be semantically valid Schema.org even if it doesn't create a special Google rich result.

ScholarlyArticle can be valid semantic type.

TechArticle can be semantically useful.

If target is Google Search feature:
follow current Google documentation.

If goal is general entity graph:
use correct Schema.org semantics.

Document consumer.

No “valid schema = Google feature” assumption.

7. Jangan Tambah Special “AI Schema” tanpa Consumer Jelas

Google's 2026 generative AI guidance explicitly says no special Schema.org markup is required for generative AI search.

So if vendor recommends:
AI schema.
LLM schema.
GEO schema.

Ask:

Is it standard Schema.org?

Custom vocabulary?

Which platform consumes?

Official documentation?

What measurable goal?

Custom metadata may have internal value.

Fine.

But label honestly.

Don't pollute production graph with speculative fields presented as universal AI requirement.

8. Organization Schema: Keep It Boring

name.

url.

logo.

legalName if relevant.

address if public/correct.

sameAs curated.

Contact details where useful.

Relationships:
only real.

Founder.

Parent.

Brand.

Don't add employee count if impossible to maintain.

Don't use sameAs for media article.

Don't mark virtual service area as physical branch.

Correct minimum beats maximal stale graph.

9. Article Authorship Harus Nyata

Visible author.

Person or Organization according actual authorship.

Author URL/profile.

Publisher separate.

Multiple authors individually represented.

No CEO as fake author.

No “Admin” Person if not real identity.

Reviewer only if review actually happened.

High-stakes content needs real process.

Markup mirrors accountability.

Don't fabricate expertise through schema.

10. Person Profiles: Privacy First

Professional information.

Role.

Organization.

Expertise.

Selected works.

Official profiles.

No private phone.

Home address.

Sensitive personal data.

Birth data unless relevant/public.

Do not enrich Person nodes just for AI.

JSON-LD is public.

Machine-readable doesn't mean confidential.

Person schema needs data minimization.

11. Breadcrumb Should Reflect Real Hierarchy

Visible breadcrumb and JSON-LD agree.

Canonical URL forms consistent.

No three plugins generating different paths.

Use durable section names.

Don't use breadcrumb as keyword stuffing.

Google still documents BreadcrumbList as Search structured-data feature.

But hierarchy quality comes first.

If editorial can't decide parent, schema can't.

12. FAQ: Stop Making It Universal

FAQ content can be useful.

FAQPage schema is no longer a general Google rich-result strategy for most sites.

Google limits FAQ rich results to well-known authoritative government and health sites.

So:

Keep FAQ where user questions are real.

Use markup when there is actual semantic/consumer reason.

Don't force 5 questions at every article.

Don't create hidden FAQ JSON-LD.

Don't tell corporate client it guarantees FAQ rich result.

Update legacy checklist.

13. ClaimReview: Update 2026 Status

Google is phasing out ClaimReview support in Google Search.

Factcheck Explorer still supports it.

If institutional site operates fact-check publication:
consumer analysis needed.

If old SEO checklist says “ClaimReview for rich result”:
update.

Don't delete blindly.

Check dependencies.

But stop promising Search appearance.

This is why schema support registry needs current review.

14. Dataset Hanya untuk Dataset Asli

Not article with table.

Not PDF with numbers.

Need actual structured body of information.

Name.

Description.

Creator.

Coverage.

Method.

Variables.

Version.

License.

Distribution/access.

Limitations.

Google Dataset markup is documented for Dataset Search, not a universal general Search rich result.

Use because institution publishes reusable data.

Not to make research look scientific.

15. Report, Article, TechArticle, ScholarlyArticle: Classify Honestly

Institutional report:
Report.

Editorial piece:
Article.

Technical procedural content:
TechArticle semantically.

Academic scholarly paper:
ScholarlyArticle.

Hub:
WebPage/CollectionPage.

Don't multi-type because unsure.

Don't choose “more serious” label.

Schema describes.

It doesn't confer credibility.

16. Product dan Commerce: One Product Truth

If institution sells products/services or publishes commerce data:

Page.

Product JSON-LD.

Merchant feed.

PIM/commerce database.

Overlapping facts should match.

Price.

Stock.

SKU.

Brand.

Offer.

Product schema is page representation.

Merchant feed is commerce channel.

Don't use SEO custom field as inventory system.

High-frequency data needs operational source.

17. LocalBusiness Only for Real Physical Business/Branch

Service area != branch.

Warehouse != customer office.

Registered address != storefront.

Franchise != parent-owned branch automatically.

Local pages should be useful.

Address.

Hours.

Contact.

Services.

Operator relationship.

Store ID.

Keep current.

Closed location must be retired.

Local schema has real-world consequences.

18. sameAs Harus Curated

same identity.

Not:
founder.
product.
news article.
partner.
review.

One wrong sameAs can merge entity.

No target number.

Three correct URLs fine.

Audit quarterly/event-triggered.

Rebranding needs special care.

Identity equivalence is strong semantic statement.

Use literally.

19. Canonical URL dan Schema IDs Harus Sinkron

One host.

HTTPS.

Trailing slash policy.

No UTM in WebPage identity.

`mainEntityOfPage` points intended canonical.

Breadcrumb last URL compatible.

Sitemap preferred URL.

Internal links use canonical.

Entity IDs have separate stable policy.

Don't use canonical tag to merge different entities.

Canonicalization is URL problem.

Entity relation is graph problem.

20. Version Custom Schema Runtime

Code version.

Output contract.

Changelog.

Fixtures.

Diff tests.

Feature flags.

Rollback.

Cache purge.

Stable IDs.

Don't append runtime version to entity `@id`.

Software changes don't create new Organization.

Treat schema custom like production software.

It is.

21. Build Cross-Page Relationship Audit

Article publisher.

Author profile.

Person worksFor.

Product brand.

Organization parent.

Dataset creator.

Report publisher.

LocalBusiness operator.

Check across pages.

Individual pages can all validate while site graph conflicts.

Make ID inventory.

Relationship table.

Severity.

Fix high-risk edges first.

Graph quality is network quality.

22. Accessibility Is Separate

Rich Results Test is not accessibility audit.

JSON-LD doesn't make button keyboard accessible.

Schema does not create alt text.

ARIA does not create Organization entity.

Use semantic HTML.

WCAG process.

Accessible names.

Focus.

Forms.

Keyboard.

Structured data separately.

They can share content truth.

Different quality gates.

Do not call site “machine-friendly” based only on JSON-LD.

23. AI Agent Readiness Is More than Schema

Schema can describe Product, Organization, Action, EntryPoint.

But actual agent execution needs:

tools/API.

endpoint.

input/output contract.

authentication.

authorization.

permission.

state.

security.

audit.

Protocols like A2A and MCP address agent discovery/interoperability/tool contexts in ways Schema.org alone does not.

No universal “agent schema” guarantees execution.

Define task.

Build actual capability.

24. Content Provenance: Know Your Layer

Schema:
author/publisher/source relationships.

C2PA:
cryptographically verifiable provenance mechanism around Content Credentials/manifests.

C2PA does not prove content factual truth.

Valid provenance != true claim.

Schema != cryptographic signing.

C2PA != Search ranking factor.

Use each for its actual job.

For research/media institution:
consider layered provenance.

25. Search Feature Status Needs Registry

Create simple table:

Type.

Schema.org status.

Google Search support.

Other Google product.

Internal use.

Owner.

Last checked.

Example:

FAQPage:
Schema.org valid.
Google FAQ rich result restricted.

ClaimReview:
Schema.org valid.
Google Search phasing out.
Factcheck Explorer supported.

Dataset:
Schema.org valid.
Google Dataset Search use.

This prevents old best practices surviving forever.

Review quarterly or after official update.

26. No Schema KPI without Quality Context

Bad KPI:
95% pages have schema.

Better:

0 duplicate Organization IDs.

99% author mapping correct.

0 price mismatch.

0 closed branch active.

100% critical entity pages semantic PASS.

Schema coverage can be useful inventory metric.

Not quality metric.

Don't chase coverage by marking everything.

A correct page with minimal markup is better than a fully “covered” wrong graph.

27. Put Validation in Release Workflow

Before deploy:

Parse JSON.

Check required consumer fields.

Semantic compare.

Check duplicate IDs.

Check visible alignment.

Test edge cases.

After deploy:

Fetch public URL.

Validate.

Purge cache.

Sample crawl.

Monitor Search Console for relevant features.

Check errors.

For custom runtime:
regression suite.

No “we'll audit later.”

At scale, later becomes never.

28. Define Change Triggers

Rebrand.

Leadership.

Address.

Product.

Store.

Pricing.

Policy.

New research dataset.

Article author correction.

Acquisition.

Schema updates should be part of operational event.

Not separate SEO ticket six months later.

Entity drift happens because events don't notify structured-data layer.

Governance connects them.

29. Separate Direct Benefit dari AI Hypothesis

Direct:
Schema correct.

Entity IDs consistent.

Product data aligned.

Search feature eligibility where documented.

Graph auditable.

Hypothesis:
May improve entity interpretation in other machine systems.

Observation:
AI answer accuracy/citation changed.

Do not merge.

No promise:
“Schema makes AI cite.”

Measure.

Report limitations.

GEO credibility depends on causal humility.

30. Final Human Read

This sounds almost too simple.

Open page.

Read.

Open schema.

Translate to sentences.

“This article was written by X.”

“This company is Y.”

“This product costs Z.”

“This branch is here.”

“This dataset was created by A.”

“This person works for B.”

Are they true?

Would legal, operations, editorial, and user agree?

If not:
fix.

That is the final gate no validator can replace.

Website Institusional Butuh Sedikit Lebih Disiplin, Bukan Sedikit Lebih Banyak Markup

A government body.

University.

Research organization.

Association.

Professional institute.

Large corporate.

Publisher.

They publish information that people may reuse as source.

Mistakes propagate.

AI systems can synthesize.

Search can surface.

Journalists cite.

Partners copy.

This makes structured data governance important.

But the answer isn't giant JSON-LD.

The answer is stable identity.

Clear authorship.

Current facts.

Correct relationships.

Accessible pages.

Auditable provenance.

Supported Search features used appropriately.

Platform changes monitored.

No hidden claims.

No fake completeness.

If those are in place, schema becomes what it should be:

A clean, machine-readable projection of an institution that already knows what it is, what it publishes, and who is accountable for keeping that information true.