Schema Validation Lolos tapi Maknanya Salah: Masalah yang Sering Terjadi

Ada jenis bug schema yang bikin tim terlalu cepat lega.

Rich Results Test hijau.

Tidak ada critical error.

JSON-LD valid.

Semua property terbaca.

Lalu kita baca isi markup-nya.

Organization name salah.

Founder sudah bukan founder yang aktif di company.

Product price beda dengan halaman.

Review score tidak pernah terlihat user.

Article author diisi nama publisher.

LocalBusiness menunjuk alamat gudang yang sebenarnya bukan lokasi pelanggan.

Secara teknis lolos.

Secara makna salah.

Ini salah satu problem structured data paling penting di 2026 karena tooling membuat validasi syntax terasa seperti finish line. Padahal Google sendiri secara eksplisit mengatakan structured data bisa salah dengan cara yang tidak dapat ditangkap Rich Results Test. Google juga menegaskan structured data harus merepresentasikan main content, tidak misleading, up-to-date, dan tidak menandai informasi yang tersembunyi dari user.

Jadi green validator adalah bukti bahwa formatnya bisa dibaca.

Bukan bukti bahwa ceritanya benar.

Validator Mengecek Bentuk, Bukan Seluruh Reality

Bayangkan validator seperti petugas yang mengecek formulir.

Nama terisi?

Tanggal format benar?

Kolom wajib ada?

Nomor terlihat valid?

Formulir bisa dinyatakan lengkap.

Tapi petugas itu belum tentu tahu bahwa:

Nama CEO sudah berubah minggu lalu.

Alamat yang ditulis adalah gudang.

Produk sudah discontinue.

Rating dibuat marketing.

Founder page ternyata milik orang lain dengan nama sama.

Structured data validation bekerja mirip.

Tool bisa menangkap banyak error teknis.

Missing required property.

Wrong format.

Invalid enum.

Malformed JSON.

Type yang tidak didukung.

Tetapi semantic truth membutuhkan knowledge tentang dunia nyata dan isi page.

Tool tidak punya full context organisasi Anda.

Di sinilah human review masuk.

Skenario: Organization Schema yang “Sempurna”

JSON-LD:

Organization.

name:
“Nusa Data AI.”

legalName:
“PT Nusa Data Teknologi.”

founder:
“Rama Setia.”

address:
Jakarta Selatan.

sameAs:
LinkedIn.
Instagram.
Wikidata.

Validator:
Hijau.

Masalah:

Rama Setia adalah ex-CEO, bukan founder.

Alamat itu coworking lama.

Wikidata link mengarah company dengan nama mirip di Malaysia.

Instagram adalah product account.

Legal name berubah sejak merger.

Secara syntax mungkin fine.

Secara entity graph, kacau.

Kalau tim hanya menyimpan screenshot “VALID”, masalah ini lolos ke production.

Itulah kenapa semantic QA harus terpisah dari technical QA.

Google Sudah Memperingatkan Hal Ini secara Terang

General Structured Data Guidelines Google menyebut beberapa alasan markup yang valid tetap tidak menghasilkan rich result.

Structured data tidak merepresentasikan main content.

Potentially misleading.

Incorrect in ways Rich Results Test tidak bisa menangkap.

Content yang dirujuk markup hidden dari user.

Google juga menyebut structured data harus menjadi true representation dari page content.

Artinya pendekatan:

“Yang penting validator lolos”

secara resmi memang tidak cukup.

Bahkan markup yang valid bisa bermasalah bila quality guideline gagal.

Ini bukan interpretasi GEO.

Ini platform fact.

Yang menjadi interpretasi GEO:

Kalau structured layer berbeda dari visible reality, external systems punya lebih banyak source conflict untuk direkonsiliasi.

Masuk akal untuk memperbaikinya.

Tetapi jangan langsung klaim bahwa semantic correction pasti menaikkan AI citation.

Itu tetap perlu diukur.

Tiga Level Validasi yang Sering Dicampur

Level 1: Syntax validation.

Apakah JSON valid?

Apakah type/property bisa diparse?

Level 2: Consumer validation.

Apakah markup memenuhi requirement Google Search feature tertentu?

Level 3: Semantic validation.

Apakah isi markup benar, current, relevan, dan sesuai visible page?

Banyak workflow berhenti di Level 2.

Padahal Level 3 yang menentukan apakah graph menceritakan reality.

Contoh Product:

Syntax:
valid.

Google merchant listing:
eligible.

Semantic:
price schema Rp799.000, visible Rp899.000.

Masalah besar.

Example Article:

Syntax:
valid.

Article type:
valid.

Semantic:
author “Redaksi”, tetapi page menampilkan nama Person A.

Conflict.

Example Breadcrumb:

Syntax:
valid.

Positions:
correct.

Semantic:
breadcrumb schema mengklaim halaman ada di “Research”, visible nav menempatkan di “Services”.

Hierarchy conflict.

Tool tidak selalu tahu mana yang seharusnya benar.

Visible Content Adalah Audit Partner

Cara termudah melakukan semantic check:

Buka page seperti manusia.

Baca.

Lalu baca JSON-LD.

Bandingkan.

Siapa entity utama?

Sama?

Nama?

Sama?

Author?

Sama?

Tanggal?

Sama?

Price?

Sama?

Availability?

Sama?

Address?

Sama?

Product?

Sama?

Relationship?

Sama?

Kalau beda, jangan langsung edit schema.

Cari source-of-truth.

Mungkin page yang salah.

Mungkin schema yang salah.

Mungkin keduanya.

Semantic validation bukan selalu “markup harus mengikuti HTML yang ada.”

Yang benar:
page dan markup harus mengikuti truth yang sama.

Dialog yang Sering Membongkar Error

SEO:
“Schema valid kok.”

Operations:
“Alamat ini sudah nggak dipakai.”

Developer:
“Tapi value-nya dari theme option.”

Brand:
“About page sudah update.”

SEO:
“Kenapa schema nggak ikut?”

Developer:
“Karena source beda.”

Itu root cause.

Structured data sering drift karena duplication of data source.

Visible page mengambil CMS field A.

JSON-LD mengambil global setting B.

Business Profile mengambil spreadsheet C.

Merchant feed mengambil ERP D.

Jika perubahan hanya masuk satu system, internet melihat beberapa versions.

Validasi syntax tidak menyelesaikan architecture ini.

Source-of-Truth Lebih Penting daripada Property Count

Ideal:

Organization data punya central config.

name.

legalName.

logo.

official URL.

address.

public contact.

sameAs.

Visible About memakai config yang sama.

Structured data memakai config sama.

Press kit maybe generates from same registry.

Sekarang perubahan satu source menyebar.

Untuk Product:

PIM/commerce database.

Price.

SKU.

GTIN.

availability.

brand.

variants.

Page dan Product JSON-LD membaca same source.

Merchant feed juga sinkron.

Semantic consistency meningkat.

Structured data governance sebenarnya data governance.

Bukan sekadar SEO plugin setting.

Fake Review adalah Contoh Semantic Error yang Validator Sulit “Mengerti”

Marketing menaruh:

aggregateRating:
4.9
ratingCount:
500

Page punya lima testimonial.

Tidak ada 500 reviews.

No methodology.

Syntax valid.

Property valid.

Meaning questionable.

Google guideline secara eksplisit melarang misleading content termasuk fake reviews.

Jadi validator green tidak melindungi.

Human must ask:

Dari mana angka?

Apakah genuine user rating?

Apakah visible?

Apakah entity scope benar?

Apakah rating product, branch, atau organization?

Schema carries claim.

Claim needs provenance.

review markup tanpa provenance = risk.

Author Schema juga Bisa Valid tapi Salah Orang

Article byline:
Nadia Putri.

Schema:
author Organization “GEO.or.id”.

Technically allowed because Google Article author accepts Person or Organization.

But semantically wrong if Nadia actually authored.

Atau kebalikannya.

Article institutional unsigned.

Schema invents CEO as author.

No.

Author markup best practice Google asks sites to include authors presented as authors on the page and use fields that help identify them.

Goal:
describe actual authorship.

Not manufacture Person entity.

Semantic validation needs editorial truth.

SameAs Paling Mudah Lolos Syntax dan Gagal Meaning

sameAs expects URL.

Any valid URL:
parser happy.

But does it identify the same entity?

Validator cannot reliably decide.

Founder profile.

Product listing.

News article.

Different company with same name.

All syntactically valid.

Semantically false.

This is why sameAs audit must be human.

Same sentence test:

“Entity A adalah entity yang sama dengan halaman URL B.”

If yes:
candidate.

If not:
wrong property.

Simple.

Powerful.

LocalBusiness Bisa Salah Role

Address is real.

Place exists.

Schema valid.

But branch page actually describes service area, not office.

Now markup says physical business branch exists there.

User might travel.

This is high-impact semantic error.

Same with:

Warehouse.

Registered address.

Virtual office.

Temporary event.

Dealer.

Franchise.

HQ.

All places.

Different roles.

Schema type should reflect actual operational entity.

Don't let address validity stand in for business truth.

Data Type Correct, Business Meaning Wrong

This is pattern.

Date:
valid ISO date.

But datePublished is actually last modified date.

Number:
valid.

But employee count is outdated.

URL:
valid.

But sameAs wrong entity.

Person:
valid.

But reviewer actually editor.

Product:
valid.

But page is category.

Organization:
valid.

But node is Brand.

Schema debugging must go beyond types.

Technical types can be right while business semantics wrong.

Human QA Checklist

For every node:

What real-world thing is this?

Who says?

Where visible?

What source?

Current?

What page?

What type?

What relationship?

Any ambiguity?

Then property:

Does this property describe that node?

Or another node?

Does it have date context?

Is value real?

Can user verify?

Can team maintain?

If not:
review.

Semantic QA can be done in spreadsheet.

No fancy graph database required.

Page-Level Meaning vs Site-Level Meaning

Homepage may describe Organization.

Article describes CreativeWork.

Product page describes Product.

Author page describes Person.

Category page describes Collection.

Don't inject full site entity graph into every page and assume relevance.

Google says main structured data should reflect page focus.

If Article page contains Organization publisher, fine.

But Organization should be supporting node.

Article remains main.

If runtime outputs 20 unrelated entities sitewide, graph noise.

Semantic validation should ask:
“What is this page primarily about?”

Then ensure markup agrees.

Timestamp Matters

Schema can be semantically right when published, wrong six months later.

CEO.

Price.

Availability.

Address.

Certification.

Product status.

Return policy.

Shipping.

Event.

These decay.

Set field-specific review cadence.

Static:
founding date.

Dynamic:
price.

Critical dynamic:
availability.

Event-triggered:
rebrand.

No universal schedule.

Governance needs decay awareness.

Semantic validity is temporal.

“Benar dulu” tidak sama dengan “benar sekarang.”

Versioning Bisa Membantu

Store schema runtime version.

Entity registry version.

Product feed version.

When error found:

Which release?

What changed?

Did plugin overwrite?

Did theme update?

Can rollback?

Without versioning:
“Sejak kapan salah?”

Unknown.

Especially website ratusan pages.

One template bug can spread sitewide.

Semantic testing should be regression test.

Sample pages from every template.

Not random one homepage.

Batch Validation Harus Melihat Edge Cases

Test:

Article normal.

Multiple authors.

No author profile.

Product in stock.

Out of stock.

Variant.

Sale price.

Branch.

Franchise.

Closed location.

Report.

Dataset.

Author page.

Homepage.

If all tests are happy-path, semantic bug hides in unusual cases.

Real websites fail at edges.

Schema governance must test reality diversity.

Rich Results Tidak Tampil Bukan Selalu karena Markup Salah

Google says correct markup does not guarantee rich result display.

Search presentation depends on other variables.

So don't react:

“No rich result → add more schema.”

Could be:
Google chooses not to show feature.

Page not eligible for another reason.

Feature phased out.

Query/device differences.

Content relevance.

Indexing.

Or markup.

Diagnose.

Adding properties blindly can create semantic debt.

Green Validator Tidak Berarti Ranking Benefit

Another misconception.

“Valid schema = ranking boost.”

Google's guidelines explicitly distinguish structured-data manual action from web ranking: structured-data manual action can remove rich-result eligibility without directly affecting ranking in normal web search.

Structured data supports understanding/features.

Do not treat validator as SEO score.

And definitely don't convert validation green into:

“AI visibility ready.”

AI search has additional layers:
crawlability.
indexing.
retrieval.
entity accuracy.
source preference.
citation.
recommendation.

Schema is one layer.

A Practical Semantic Validation Workflow

1. Fetch rendered page.

2. Extract structured data.

3. Identify main node.

4. Map node to visible content.

5. Compare critical properties.

6. Verify source-of-truth.

7. Check date/currentness.

8. Check entity IDs.

9. Check relationships.

10. Check Google consumer requirements separately.

11. Run Rich Results Test.

12. Record semantic pass/fail.

Order matters.

Rich Results Test is step 11.

Not step 1 and done.

Semantic Pass Criteria

PASS:
Markup matches visible current truth.

WARN:
Optional property unclear or stale but not critical.

FAIL:
Wrong entity.

Wrong person.

Wrong price.

Fake rating.

Wrong location role.

Wrong ownership.

Hidden material fact.

Mismatch with visible content.

Misleading relationship.

Then fix fail before production.

This makes schema QA actionable.

GEO Angle: Semantic Accuracy Is More Valuable than Schema Volume

In AI-era publishing, temptation is to generate giant graphs automatically.

But a giant graph multiplies failure surface.

If each node has 1% error probability, at scale you accumulate errors.

Better:
small, relevant, governed.

Canonical IDs.

Correct relations.

Visible alignment.

Fresh data.

Then measure AI outcomes.

Don't promise citation.

But reduce ambiguity.

That's a worthy objective.

The Biggest Schema Error Is Sometimes a Human Sentence

A developer can fix malformed JSON in minutes.

Harder:

“Brand X is owned by Company Y.”

Is it?

“Person A is founder.”

Really?

“Product is available.”

Now?

“Branch exists.”

Operational?

“Dataset is original.”

Method?

Structured data makes claims explicit.

That forces uncomfortable but useful questions.

If team can't answer the sentence, don't encode it.

A good validator tells you code can be read.

A good governance process tells you code should be believed.

Those are different tests.

In 2026, websites need both.