AI Optimization Bukan Tambah Schema Sebanyak Mungkin

Ada pola yang mulai sering muncul ketika sebuah tim merasa harus “siap untuk AI”.

Developer diminta menambahkan Organization schema. Lalu Service. Lalu Product. Lalu Person. Lalu Article. Lalu FAQ. Lalu Review. Setelah itu muncul ide membuat entity graph sebanyak mungkin karena katanya AI akan lebih mudah memahami website.

Seminggu kemudian JSON-LD halaman bisa lebih panjang daripada isi artikelnya.

Secara visual, tidak ada yang berubah. Secara internal, semua orang merasa sudah melakukan AI Optimization.

Padahal belum tentu.

Schema memang berguna. Structured data membantu mesin memahami informasi yang ada di halaman dalam format yang lebih standar. Google secara resmi menjelaskan bahwa structured data dapat dipakai untuk memahami konten halaman dan mendukung eligible rich result. Tetapi ada jarak besar antara “membantu memberi struktur” dan “semakin banyak schema semakin tinggi peluang dikutip AI”.

Jarak itulah yang sering diisi asumsi.

Di 2026, saat GEO, AEO, AI Search, dan generative visibility menjadi topik panas, kita perlu lebih disiplin. Jangan mengubah schema menjadi versi baru dari keyword stuffing.

Masalahnya bukan kurang markup. Sering kali masalahnya justru fakta dasarnya belum beres.

Mari ambil contoh sederhana.

Sebuah agency menulis di halaman About bahwa sudah berdiri sejak 2017. Organization schema menyebut foundingDate 2018. Profil LinkedIn mengatakan 2016. Artikel wawancara founder menyebut bisnis mulai informal pada 2015 dan baru berbadan hukum 2018.

Mana yang benar?

Secara teknis kita bisa menambahkan foundingDate ke JSON-LD dalam 30 detik. Tetapi kalau definisinya tidak disepakati, markup hanya membuat konflik terlihat lebih formal.

Ini inti masalah yang sering dilewatkan: structured data tidak memperbaiki fakta. Ia hanya menstrukturkan fakta yang kita berikan.

Schema harus mengikuti kenyataan yang terlihat

Google punya prinsip yang cukup straightforward dalam structured data guidelines: markup harus merepresentasikan konten halaman dan mengikuti aturan kualitas yang berlaku. Structured data bukan tempat menyisipkan informasi rahasia atau narasi berbeda dari apa yang terlihat oleh user.

Ini seharusnya jadi rule pertama AI Optimization.

Kalau kita ingin memberi tahu mesin bahwa seseorang adalah founder, halaman sebaiknya memang menjelaskan hubungan itu.
Kalau produk punya harga, harga pada structured data harus konsisten dengan halaman.
Kalau artikel punya author, identitas author harus nyata dan dapat dipahami.
Kalau sebuah organisasi punya logo, URL, atau detail tertentu, jangan menambahkan properti hanya karena tool validator mengizinkan.

Valid tidak sama dengan benar.

Rich Results Test bisa memberi tahu apakah markup memenuhi format tertentu. Ia tidak bisa menjamin klaim bisnisnya benar, up-to-date, atau tidak menyesatkan.

Dan bahkan markup yang valid tidak menjamin rich result akan ditampilkan. Google menyebut eligibility, bukan entitlement.

AI Search memperbesar godaan over-markup

Kenapa masalah ini makin besar sekarang?

Karena AI terasa opaque.

Kalau halaman ranking turun di search tradisional, kita masih punya banyak indikator: query, position, indexing, crawl, links, content, intent. Pada generative answers, brand kadang muncul hari ini, hilang besok, lalu muncul lagi untuk variasi query yang hampir sama.

Ketidakpastian membuat manusia mencari sesuatu yang bisa dikontrol.

Schema terasa enak karena konkret.
Ada kode.
Ada validator.
Ada green check.
Ada checklist.

Akhirnya tim mengoptimasi hal yang paling mudah diukur, bukan yang paling penting.

Padahal Google dalam panduan resmi generative AI search sekarang justru menegaskan bahwa tidak ada kebutuhan untuk membuat markup khusus atau file khusus agar bisa tampil dalam fitur generatif Google Search. Fondasi SEO, konten yang berguna, struktur teknis yang sehat, dan informasi yang dapat dipercaya tetap menjadi pekerjaan utama.

Jadi kalau ada pitch yang berbunyi “tambahkan schema khusus ini agar AI pasti mengutip brand”, treat it as a claim that needs evidence, bukan fakta platform.

Tiga fungsi schema yang masuk akal

Daripada melihat schema sebagai magic lever, lebih sehat melihatnya dalam tiga fungsi.

Pertama, disambiguation.

Structured data dapat membantu menjelaskan bahwa sebuah nama merujuk ke organisasi, orang, produk, event, atau entity tertentu. Untuk brand dengan nama generik, konteks ini berguna. Tetapi disambiguation tidak hanya datang dari schema. Nama yang konsisten, halaman About yang jelas, profile resmi, dan referensi eksternal juga berperan.

Kedua, explicit attributes.

Format terstruktur memudahkan sistem membaca atribut seperti author, date, price, availability, address, rating tertentu ketika jenis markup dan use case memang didukung. Ini terutama kuat pada domain yang sudah punya ekosistem data matang, seperti product dan local business.

Ketiga, eligibility untuk search features tertentu.

Google mendokumentasikan structured data types yang dapat mendukung rich result atau tampilan khusus. Di sini implementasi schema punya manfaat yang cukup konkret karena ada dokumentasi, required properties, recommended properties, dan testing tools.

Perhatikan apa yang tidak ada dalam tiga fungsi tadi: jaminan ranking dan jaminan citation.

Jangan membuat relationship yang tidak bisa dibuktikan

Salah satu area paling rawan adalah entity relationship.

Karena konsep knowledge graph makin populer, tim sering ingin menghubungkan semuanya.

Brand A sameAs semua profile.
Person B worksFor Brand A.
Brand A knowsAbout topik X, Y, Z.
Service C areaServed seluruh Indonesia.
Organization punya award ini, affiliation itu, founder ini, parentOrganization itu.

Secara teknis, banyak relasi bisa ditulis. Tapi apakah semuanya akurat?

“sameAs” misalnya terdengar sederhana, padahal maknanya kuat. Kita sedang mengatakan dua identifier merujuk pada entity yang sama. Kalau URL yang dimasukkan sebenarnya hanya artikel tentang brand, directory profile tidak resmi, atau halaman yang membahas entity secara sekilas, relasinya tidak tepat.

Begitu juga knowsAbout. Menambahkan ratusan topik karena ingin terlihat authoritative bisa mengubah markup menjadi self-declared expertise list tanpa bukti.

AI Optimization yang sehat lebih konservatif.

Lebih baik lima relationship yang benar daripada lima puluh yang spekulatif.

Schema juga punya biaya maintenance

Ini sering tidak masuk proposal.

Setiap properti yang ditambahkan adalah data yang harus dirawat.

Kalau harga berubah, markup berubah.
Kalau executive berganti, markup berubah.
Kalau alamat pindah, markup berubah.
Kalau product availability berubah, markup berubah.
Kalau article di-update, dateModified perlu mengikuti realitas.
Kalau organisasi rebrand, identifier dan relasi mungkin perlu dievaluasi.

Semakin kompleks schema graph, semakin tinggi maintenance burden.

Untuk website kecil mungkin tidak terasa. Untuk publisher dengan ribuan artikel atau marketplace dengan jutaan product URL, schema yang hard-coded atau berasal dari source berbeda bisa menghasilkan drift besar.

Karena itu desain structured data harus mempertimbangkan lifecycle.

Dari mana field ini diambil?
Siapa owner datanya?
Apakah update otomatis?
Apa fallback ketika value kosong?
Bagaimana mencegah data lama?
Apa yang terjadi kalau CMS field dihapus?
Apakah staging dan production konsisten?
Apakah validator masuk CI atau QA?

Kalau pertanyaan itu belum dijawab, menambah tipe baru mungkin hanya menambah technical debt.

AI Optimization sebaiknya mulai dari information architecture

Kalau tujuan akhirnya adalah agar mesin lebih mudah memahami bisnis, ada pekerjaan yang sering lebih bernilai daripada menambah schema.

Buat service taxonomy yang jelas.
Kurangi duplicate landing pages.
Tentukan canonical page untuk setiap topik bisnis penting.
Perjelas hubungan parent-child antarproduk.
Gunakan internal link yang benar-benar membantu discovery.
Pisahkan halaman definisi, comparison, proof, dan action.
Pastikan author dan reviewer punya identitas yang masuk akal.
Tampilkan tanggal update kalau memang relevan.
Perbaiki content yang saling bertentangan.

Mesin tidak hanya membaca JSON-LD. Search systems membangun pemahaman dari halaman, link, content, dan sumber lain.

Kalau arsitektur informasinya kacau, schema tidak bisa menjadi plester permanen.

Bayangkan restoran dengan menu fisik yang berantakan, harga di kasir berbeda, menu delivery berbeda lagi, lalu pemilik membuat database menu super rapi yang tidak pernah sinkron. Database itu terlihat canggih. Customer tetap bingung.

Website juga begitu.

Kapan schema layak diprioritaskan?

Ada beberapa kondisi yang membuat structured data jelas layak masuk prioritas.

Saat Google atau platform lain memiliki dokumentasi resmi untuk use case yang relevan.
Saat website punya data terstruktur yang memang bisa dihasilkan dari source of truth.
Saat implementasi bisa dijaga konsisten dengan visible content.
Saat bisnis punya skala yang membuat markup manual tidak realistis.
Saat ada monitoring untuk error dan perubahan.
Saat manfaatnya dapat didefinisikan, misalnya eligibility, data consistency, atau machine interpretation yang lebih eksplisit.

Sebaliknya, schema sebaiknya tidak menjadi prioritas pertama ketika website masih punya masalah indexability, canonical conflict, thin content, outdated facts, atau entity ambiguity yang mendasar.

Kita perlu urutan.

Crawl dulu.
Pahami dulu.
Benarkan fakta.
Tentukan halaman authoritative.
Bangun evidence.
Lalu representasikan secara terstruktur.

Bukan sebaliknya.

Bagaimana melakukan schema audit yang tidak sekadar validator audit

Schema audit sering berhenti di error dan warning. Itu terlalu sempit.

Audit yang lebih matang punya empat pertanyaan.

Apakah markup valid?
Apakah markup sesuai visible content?
Apakah datanya benar dan terbaru?
Apakah markup ini memang punya fungsi?

Pertanyaan keempat penting.

Kalau ada 12 schema type di halaman tetapi tim tidak bisa menjelaskan kenapa masing-masing ada, mungkin sudah waktunya simplifying.

Lalu cek source.

Apakah Organization data berasal dari satu central config atau ditulis ulang di setiap template?
Apakah author data terhubung ke profile?
Apakah Product price berasal dari sistem commerce yang sama?
Apakah breadcrumbs mengikuti navigasi aktual?
Apakah canonical URL sama dengan URL entity yang dipakai di markup?

Audit juga perlu sampling lintas template. Jangan hanya test homepage. Test artikel lama, artikel baru, product out-of-stock, pagination, category, service page, profile, dan halaman yang punya edge case.

AI-era website membutuhkan data discipline, bukan markup maximalism

Ada alasan kenapa “tambah schema” tetap menarik. Ia membuat pekerjaan terlihat teknis dan measurable. Kita bisa bilang jumlah entity naik, jumlah property naik, graph makin besar.

Tetapi volume bukan kualitas.

AI Optimization yang serius bertanya lebih jauh:
Apakah mesin menemukan informasi yang benar?
Apakah entity dapat dibedakan?
Apakah bukti klaim tersedia?
Apakah sumber authoritative jelas?
Apakah data konsisten antarhalaman?
Apakah informasi lama cepat dikoreksi?
Apakah konten membantu user mengambil keputusan?
Apakah sistem teknis memungkinkan discovery?

Schema adalah salah satu alat untuk menjawab sebagian pertanyaan itu.

Salah satu, bukan semuanya.

Di banyak proyek, markup yang lebih sedikit tetapi benar, konsisten, dan terhubung ke source of truth justru lebih sehat daripada graph besar yang dibangun dari asumsi.

Dan ada benefit tambahan: tim tidak terjebak mengejar pseudo-progress.

Kalau minggu ini kita menghapus schema yang salah, memperbaiki 20 halaman yang kontradiktif, menyatukan entity naming, dan menghubungkan structured data ke sumber yang selalu update, jumlah markup mungkin turun. Namun kualitas sistem naik.

Itulah mindset yang dibutuhkan.

AI Optimization bukan lomba memenuhi halaman dengan bahasa mesin. Tujuannya adalah membuat informasi bisnis cukup jelas sehingga manusia dan mesin sama-sama mendapat realitas yang konsisten.

Schema membantu ketika ia merepresentasikan realitas tersebut secara akurat.

Kalau realitasnya belum rapi, jangan menambah dekorasi. Rapikan dulu bisnis yang sedang direpresentasikan.