Schema 2026: Jangan Tambah Markup yang Tidak Didukung Isi Halaman

Ada satu momen yang sering terjadi setelah tim membuka validator schema.

Semua item hijau.

Developer lega.

SEO senyum.

Lalu seseorang bertanya, “Data ini memang ada di halaman?”

Ruangan mendadak lebih sepi.

Karena structured data bisa valid secara syntax tetapi tetap salah secara makna. Kita bisa menulis JSON-LD yang rapi, lolos parser, punya banyak property, bahkan terlihat sangat “AI-ready”, tetapi sebenarnya sedang mendeskripsikan sesuatu yang tidak pernah dilihat user.

Di 2026, masalah ini makin penting karena schema sering dipromosikan sebagai jalan pintas menuju AI search. Ketika hasil generative terasa tidak transparan, tim mencari hal yang bisa dikontrol. Markup terasa konkret. Ada kode, validator, checklist, dan angka coverage.

Akhirnya muncul kebiasaan berbahaya: kalau property tersedia, isi saja.

Padahal aturan yang lebih sehat justru kebalikannya.

Kalau fakta tidak terlihat, tidak relevan, tidak current, atau tidak bisa diverifikasi, jangan masukkan hanya karena schema.org mengizinkan.

Google Search Central secara eksplisit menjelaskan bahwa structured data di sebuah halaman harus mendeskripsikan content halaman tersebut. Google juga melarang markup untuk informasi yang tidak terlihat kepada pembaca dan menegaskan bahwa structured data harus menjadi representasi yang benar dari page content.

Jadi sebelum bertanya “property apa lagi yang bisa ditambah?”, pertanyaan pertama seharusnya:

“Halaman ini sebenarnya mengatakan apa?”

Valid Tidak Sama dengan Benar

Bayangkan halaman About sebuah perusahaan.

Visible content:

“PT Sinar Data menyediakan layanan data engineering untuk perusahaan Indonesia.”

JSON-LD:

Organization.

foundingDate: 2017.

founder: Budi Santoso.

numberOfEmployees: 250.

award: “Best Data Company 2026.”

aggregateRating: 4.9.

Masalahnya:

Halaman tidak menyebut tanggal berdiri.

Founder tidak disebut.

Jumlah karyawan tidak public.

Award tidak punya evidence.

Rating diambil dari internal survey yang tidak dijelaskan.

Parser mungkin tetap bisa membaca JSON-LD.

Tetapi markup telah menjadi alternate reality.

Ini bukan enhancement.

Ini data inconsistency.

Structured data tidak punya lisensi untuk mengatakan lebih banyak daripada halaman hanya karena invisible di browser.

JSON-LD tetap public.

User bisa melihat source.

Crawler bisa membaca.

Competitor bisa membaca.

Auditor bisa membaca.

Kalau fakta tidak layak muncul di visible page, tanya kenapa fakta itu layak diumumkan melalui markup.

Jangan Gunakan Schema sebagai Tempat Menyembunyikan Klaim

Ada mindset lama:

“Kalau copy-nya terlalu panjang, taruh detail di schema.”

Untuk beberapa technical fields, structured representation memang membantu.

Tetapi jangan gunakan markup untuk menyisipkan klaim yang sengaja tidak ditampilkan ke user.

Contoh:

“CEO adalah Person A.”

Kalau halaman Organization tidak pernah menyebut A dan website leadership bahkan mengatakan Person B, menaruh Person A di JSON-LD bukan optimasi.

Itu conflict.

Atau:

Product page visible bilang “mulai Rp1,2 juta”.

Schema Offer bilang Rp899 ribu karena tim ingin snippet terlihat murah.

Problem.

Atau:

Halaman service tidak punya review.

Markup punya AggregateRating 4.9 dari 2.000 reviews.

Serious problem.

Schema bukan stealth marketing layer.

Ia structured expression dari truth yang sudah ada.

Dialog yang Perlu Terjadi Sebelum Deploy

Developer:
“Property `foundingDate` kosong. Mau gue isi dari artikel lama?”

Brand:
“Artikel itu bilang bisnis mulai informal 2015.”

Legal:
“PT berdiri 2018.”

SEO:
“Homepage sekarang bilang sejak 2017.”

Developer:
“Jadi isi apa?”

Jawaban terbaik bukan memilih salah satu secara cepat.

Jawaban terbaik:

“Berhenti dulu. Tentukan definisinya.”

Apakah foundingDate merujuk organisasi legal?

Brand operation?

Project awal?

Jika tidak jelas, jangan deploy property itu.

Selesaikan truth.

Schema akan mengikuti.

Ini contoh mengapa schema governance bukan pekerjaan developer saja.

Developer tahu syntax.

Legal tahu entity.

Brand tahu history.

Editorial tahu visible content.

Data owner tahu source.

Structured data berada di persimpangan semua itu.

Recommended Property Bukan “Harus Diisi”

Google Organization structured data documentation menyarankan menambahkan recommended properties yang memang berlaku pada halaman. Tidak semua property wajib.

Ini penting.

Validator warning sering membuat tim panik.

“Missing recommended field.”

Lalu field diisi dengan data setengah pasti.

Lebih baik property hilang daripada property salah.

Completeness memang punya value ketika datanya benar dan relevan.

Tetapi semantic correctness lebih fundamental.

Sebuah Organization schema minimal dengan:

name.

url.

logo.

legalName jika appropriate.

address jika public dan benar.

sameAs yang curated.

bisa jauh lebih sehat daripada graph besar dengan 30 property yang separuhnya stale.

Markup maximalism bukan maturity.

Data discipline adalah maturity.

Schema.org Lebih Luas daripada Google Search Support

Hal lain yang sering membingungkan.

Schema.org adalah vocabulary yang sangat luas.

Google Search mendukung subset tertentu untuk Search features.

Jadi:

“Valid menurut schema.org”

tidak otomatis berarti:

“Dipakai Google untuk rich result.”

Dan lebih jauh lagi, tidak berarti:

“Memberi benefit khusus untuk AI Mode.”

Google pada 2026 secara resmi mengatakan tidak ada special schema.org markup yang perlu ditambahkan untuk tampil di AI Overviews atau AI Mode.

Structured data tetap useful dalam fungsi normalnya.

Memberikan explicit clues.

Mendukung Search features yang terdokumentasi.

Membantu consistency.

Tetapi jangan menciptakan property hanya untuk “AI”.

Kalau ada consultant bilang:

“Tambahkan custom schema ini supaya AI pasti cite,”

tanya:

Platform mana?

Dokumentasi mana?

Test mana?

Sample mana?

Apakah effect causal?

Jangan menerima “karena machine-readable” sebagai bukti.

Markup Harus Mengikuti Main Content

Misalnya page utama adalah artikel tentang schema.

Boleh ada:

Article.

WebPage.

Breadcrumb.

Publisher Organization.

Author Person.

Mungkin VideoObject jika memang ada video.

Tetapi jangan menambah Product hanya karena artikel menyebut product sekali.

Jangan menambah LocalBusiness karena ada nama kantor di author bio.

Jangan menambah FAQPage kalau page tidak benar-benar punya FAQ yang memenuhi use case.

Google structured-data guidelines bahkan menekankan bahwa main type harus merefleksikan main focus page ketika ada multiple items.

Itu logis.

Schema bukan permainan mengumpulkan type.

Ia representasi struktur content.

More type bukan more authority.

More type bisa berarti more maintenance.

Visibility Rule Harus Dipahami secara Semantik

“Content visible” tidak berarti semua property harus ditulis mentah satu per satu dalam body.

Contoh Organization logo jelas terlihat.

Alamat bisa ada di contact section.

Author bisa terlihat di byline.

DatePublished di header.

Breadcrumb di navigation.

Product price di commerce UI.

Informasi bisa tersebar dalam page interface.

Yang penting markup merepresentasikan apa yang benar-benar tersedia bagi user dan tidak menyelundupkan informasi berbeda.

Untuk halaman interaktif, pastikan user memang dapat mengakses state yang dimarkup.

Jangan markup stok “InStock” sementara halaman menunjukkan sold out.

Data freshness lebih penting daripada sekadar presence.

Schema Drift adalah Musuh Besar

Website berubah.

Schema tidak.

CEO ganti.

Alamat pindah.

Product discontinue.

Harga berubah.

Review bertambah.

Company rebrand.

Jika JSON-LD hardcoded, drift cepat terjadi.

Misalnya footer mengambil alamat baru dari CMS.

Structured data masih alamat lama di theme.

Visible page benar.

Machine-readable layer salah.

Ini alasan source-of-truth architecture penting.

Ideal:

Satu data source mengisi visible content dan structured data.

Product price dari commerce database.

Organization name dari central config.

Author dari profile.

Breadcrumb dari actual hierarchy.

Kalau tidak bisa satu source, buat validation.

Schema audit harus mencari mismatch, bukan cuma error.

Satu green validator tidak mendeteksi bahwa CEO sudah salah enam bulan.

Quality Assurance Harus Membandingkan Dua Dunia

Dunia A:
Visible page.

Dunia B:
Structured data.

Audit setiap template:

Apa H1?

Apa entity utama?

Apa facts terlihat?

Apa schema type?

Apa property?

Apa source?

Apa timestamp?

Apakah sama?

Example Product:

Visible:
Price Rp1.499.000.
Availability in stock.
Brand X.
SKU A123.

Markup:
Price Rp1.299.000.
OutOfStock.
Brand Y.
SKU A123-old.

Parser valid.

Business data rusak.

This is the real schema error.

Dan error seperti ini bisa punya customer consequence.

Jangan Markup Halaman Tipis untuk Membuatnya Terlihat Kaya

Ada temptation:

Entity hub cuma dua paragraph.

Tambahkan banyak schema supaya “knowledge graph kuat.”

No.

Structured data cannot create information gain that page doesn't have.

If Organization page lacks:

Who it is.

What it does.

Relationship.

Location.

Public facts.

Evidence.

Fix content first.

Schema mirrors.

Same for Person.

If author page hanya nama dan avatar, jangan tambahkan 20 employment/award/education claims hidden in JSON-LD.

Build useful profile if public need exists.

Machine-readable richness should follow human-readable richness.

Case: Branch yang Tidak Ada

Company ingin local visibility.

Mereka membuat LocalBusiness markup untuk 20 kota.

Visible page hanya satu kantor Jakarta.

No physical branches.

Markup invents locations.

This is not optimization.

It is misrepresentation.

Schema.org LocalBusiness represents a particular physical business or branch of an organization.

If no branch, don't create one.

Service area can be expressed in content through appropriate mechanisms, but service area is not office.

Entity truth matters.

AI-era search raises risk because generated answers may repeat false location.

User could physically go wrong place.

Schema choices have real-world consequences.

Case: Review yang Tidak Bisa Diverifikasi

Marketing has testimonial screenshots.

Developer turns them into AggregateRating.

But rating number is calculated manually from selected testimonials.

No visible review system.

No rating methodology.

Don't.

Review markup has specific requirements for Google Search features.

More importantly, the number itself isn't a transparent fact.

If website has genuine user reviews with visible ratings, model accordingly.

If it only has quotes, keep them as testimonials.

Don't transform qualitative praise into quantitative rating because schema property exists.

Different data type.

Different claim.

Case: Founder yang Tidak Mau Dipublikasikan

Internal company record has founder.

Person prefers not to be public.

Should schema include?

No automatic requirement.

Privacy and publication policy first.

If identity fact is necessary for public corporate governance and law requires disclosure, that's a different context.

But schema optimization is not legal basis to expose personal data.

The fact that property exists doesn't create obligation.

Structured data must obey data minimization and organizational policy.

Person is human.

Not SEO field.

Before Adding a Property, Use Four Gates

Gate 1: Is it true?

Verified source.

Gate 2: Is it visible or clearly represented to the user?

No hidden alternate story.

Gate 3: Is it relevant to the page/entity?

No unrelated markup.

Gate 4: Can we keep it current?

Source owner and update process.

If any gate fails, don't add yet.

Maybe fix page.

Maybe fix data.

Maybe skip property.

This simple framework prevents most over-markup.

Green Validator Is Beginning, Not End

Technical tests are necessary.

JSON syntax.

Supported type.

Required/recommended fields.

Crawler access.

Rich Results Test.

Schema Markup Validator.

But after technical validation, do semantic validation.

Ask a human:

“What does this JSON-LD claim?”

Then read page.

“Does page say same thing?”

If not, fail.

This human step catches what tools cannot.

Google itself states that Rich Results Test cannot catch every incorrect or misleading case.

So don't outsource truth to validator.

Schema Governance Checklist

For each template:

Primary entity.

Primary page type.

Allowed secondary types.

Source-of-truth fields.

Owner.

Update trigger.

Validation.

Fallback if data missing.

Do not output empty/default values.

Do not invent.

Example Organization:

If address missing:
omit address.

Don't insert company registered agent office as fake branch.

If sameAs unknown:
omit.

If logo missing:
fix actual logo asset, not random social image.

If foundingDate disputed:
omit until resolved.

Null is okay.

Unknown is okay.

Wrong is not.

2026 Bukan Tahun untuk Schema Stuffing

Keyword stuffing dulu terasa seperti optimasi karena kita bisa mengontrol jumlah kata.

Schema stuffing sekarang punya psikologi mirip.

Add more type.

Add more property.

Add more entity.

Graph bigger.

Feels productive.

But external systems don't owe us visibility for markup volume.

Google explicitly says no special schema is needed for generative AI search.

So schema strategy should mature.

From quantity to correctness.

From hidden claims to visible truth.

From manual copy to source-of-truth data.

From one-time implementation to governance.

From “validator green” to semantic audit.

Kalau markup lebih sedikit setelah cleanup, itu tidak berarti website mundur.

Maybe you removed:

Fake rating.

Stale founder.

Duplicate Organization.

Wrong LocalBusiness.

Unsupported relationships.

Now graph is smaller and more accurate.

That is progress.

Schema yang Baik Terasa Membosankan

Name correct.

URL correct.

Entity type correct.

Author correct.

Price current.

Address real.

Relationships verified.

Visible page agrees.

No magic.

No secret AI tag.

No inflated graph.

Just data discipline.

And that's exactly why it's valuable.

Structured data should make the page easier to interpret, not give the page a second identity hidden in source code.

If the markup says something a careful reader of the page could not reasonably verify, stop.

Don't ask how to hide it better.

Ask why it is there at all.