Schema Markup untuk AI Search: Yang Perlu dan yang Tidak

Schema markup tidak diperlukan untuk muncul di fitur AI Google Search. Google menyatakan structured data tidak diperlukan untuk generative AI search dan tidak ada markup schema.org khusus yang perlu ditambahkan, walaupun markup tetap berguna sebagai bagian dari SEO karena membantu halaman memenuhi syarat untuk rich result.

Pernyataan itu penting karena banyak tawaran jasa sekarang menjual "schema untuk AI" seolah-olah markup tertentu bisa membuat brand dikutip ChatGPT atau AI Overviews. Kenyataannya lebih sederhana. Structured data yang valid dan jujur membantu mesin pencari membaca fakta halaman dengan lebih jelas, dan sebagian tipe membuat halaman layak tampil dengan tampilan khusus di Google. Markup tidak menjamin tampilan itu muncul, dan tidak ada bukti terdokumentasi bahwa markup tertentu menghasilkan citation AI. Bagian berikut memisahkan tiga hal yang sering tercampur, yaitu markup yang valid, fitur pencarian yang didukung, dan klaim citation yang belum terbukti, lalu membantu Anda memilih pekerjaan schema yang layak diprioritaskan.

Apa itu schema markup dan JSON-LD?

Schema markup adalah informasi terstruktur yang ditambahkan ke halaman untuk menjelaskan isinya kepada mesin, seperti siapa penulis artikel, berapa harga produk, atau di mana alamat cabang. Kosakatanya berasal dari Schema.org, yang menyediakan tipe seperti Organization, Article, dan Product beserta properti untuk masing-masing tipe.

JSON-LD adalah salah satu cara menuliskan informasi tersebut. Bentuknya berupa blok kode di dalam tag script yang terpisah dari teks halaman, sehingga lebih mudah dikelola developer. Panduan structured data Google menyebut Google mendukung tiga format, yaitu JSON-LD, Microdata, dan RDFa. Google merekomendasikan format yang paling mudah diterapkan dan dirawat, yang dalam banyak kasus adalah JSON-LD, dan menyebut ketiganya sama baiknya selama valid.

Ada satu catatan dari panduan yang sama. Sebagian besar structured data untuk Google Search memakai kosakata schema.org, tetapi dokumentasi Google Search Central adalah acuan yang menentukan perilaku Google Search. Sebuah properti bisa ada di schema.org tanpa dipakai Google untuk fitur apa pun.

Perbedaan antara teks dan markup bisa dilihat dari contoh sederhana. Di halaman, kalimat "tersedia mulai Rp250.000" mudah dipahami manusia. Di markup, informasi yang sama dipecah menjadi properti terpisah untuk harga, mata uang, dan ketersediaan. Mesin tidak perlu menafsirkan kalimat, karena setiap nilai sudah diberi label. Isi keduanya harus sama persis, dan markup hanya mengubah cara fakta itu disampaikan.

Apakah schema diperlukan untuk muncul di jawaban AI?

Untuk fitur AI di Google Search, schema tidak diperlukan. Panduan optimasi fitur AI Google Search menyebut structured data tidak diperlukan untuk generative AI search, tidak ada markup schema.org khusus yang perlu ditambahkan, dan tetap disarankan memakainya sebagai bagian dari strategi SEO karena membantu kelayakan rich result.

Panduan yang sama menyebut bahwa untuk Google Search, pemilik situs bisa mengabaikan taktik seperti memecah konten menjadi potongan khusus, membuat file teks AI yang tidak perlu seperti llms.txt, atau mengejar mention yang tidak autentik. Daftar ini relevan karena banyak rekomendasi "optimasi AI" berasal dari kelompok taktik yang sama dengan schema khusus AI.

Isi dokumen ini berlaku untuk Google. ChatGPT, Perplexity, dan asisten lain tidak terikat pada panduan Google, dan dokumentasi publik mereka yang kami baca tidak menjelaskan peran structured data dalam pemilihan sumber. Karena itu klaim bahwa schema membantu atau tidak membantu di produk-produk tersebut perlu diperlakukan sebagai dugaan sampai ada dokumentasi atau pengujian yang bisa diperiksa.

Apa manfaat yang realistis?

Manfaat realistis schema ada tiga, yaitu menyatakan fakta halaman secara eksplisit, membuat halaman layak untuk fitur pencarian yang didukung, dan memudahkan integrasi dengan sistem lain. Ketiganya berbeda dan perlu dinilai terpisah.

Pernyataan fakta yang eksplisit membantu sistem membaca hal yang di halaman mungkin tersebar atau ambigu. Contohnya tanggal terbit, nama penulis, harga dengan mata uangnya, atau jam buka cabang. Untuk Organization, dokumentasi Google menyebut markup di beranda bisa membantu Google memahami detail administratif organisasi dan membedakannya dari organisasi lain, serta bisa memengaruhi elemen visual seperti logo di hasil pencarian dan knowledge panel. Dokumentasi itu juga menyebut tidak ada properti yang harus diisi untuk Organization, dan menyarankan menambahkan sebanyak mungkin properti yang relevan, seperti nama resmi, logo, alamat, kontak, dan profil resmi di sameAs.

Kelayakan fitur pencarian adalah manfaat yang paling sering dijanjikan dan paling sering dilebih-lebihkan. Markup yang lengkap membuat halaman layak dipertimbangkan untuk rich result tertentu, dengan tampilan akhir tetap ditentukan Google. Pedoman umum structured data Google menyatakan Google tidak menjamin rich result muncul, bahkan dengan markup yang benar.

Integrasi adalah manfaat yang sering terlupakan. Data produk yang rapi di markup bisa dipakai ulang untuk feed, katalog internal, atau tool lain yang membaca halaman. Untuk brand dengan banyak produk atau cabang, manfaat ini kadang lebih terasa daripada tampilan di hasil pencarian.

Schema apa yang relevan untuk halaman Anda?

Schema yang relevan adalah tipe yang sesuai dengan isi halaman yang benar-benar terlihat dan dengan fitur yang didokumentasikan Google. Menambahkan semua tipe yang tersedia tidak membuat halaman lebih kuat, dan bisa melanggar pedoman jika isinya tidak cocok.

Halaman atau entitas	Tipe yang dipertimbangkan	Yang perlu diperhatikan
Identitas organisasi	Organization	Identitas yang akurat dan profil resmi yang benar-benar milik Anda
Artikel editorial	Article atau subtipe yang sesuai	Penulis, tanggal, judul, dan hubungan dengan penerbit
Jejak navigasi	BreadcrumbList	Mengikuti hierarki halaman yang sebenarnya
Halaman produk	Product beserta informasi penawaran yang berlaku	Fakta harus sama dengan informasi produk yang terlihat
Cabang fisik	Subtipe LocalBusiness yang sesuai	Lokasi nyata dan detail bisnis yang terbaru
FAQ yang tidak ada di halaman	Tidak ada	Jangan membuat tanya jawab tersembunyi hanya demi markup

Mulailah dari pertanyaan sederhana untuk setiap template halaman. Apa yang sebenarnya dijelaskan halaman ini? Apakah ada fitur Google yang didokumentasikan untuk jenis halaman ini? Apakah datanya tersedia dan bisa dijaga tetap akurat? Jika jawaban ketiga pertanyaan itu jelas, tipe yang tepat biasanya ikut jelas.

Pilihan subtipe juga perlu teliti. Restoran lebih tepat memakai Restaurant daripada LocalBusiness umum, dan artikel berita bisa memakai NewsArticle jika memang berita. Subtipe yang tepat memberi informasi lebih spesifik tanpa menambah klaim baru.

Untuk website jasa, seperti agensi atau konsultan, pilihannya biasanya lebih sedikit. Organization di beranda, Article di blog, dan BreadcrumbList di seluruh situs sudah mencakup sebagian besar kebutuhan. Tipe seperti Service tersedia di schema.org, tetapi dokumentasi fitur Google yang kami baca tidak mencantumkan rich result untuk tipe tersebut. Tipe itu masih boleh dipakai untuk menyatakan layanan secara eksplisit, dengan ekspektasi yang sesuai.

Bagaimana menghubungkan organisasi, penulis, dan artikel?

Organisasi, penulis, dan artikel dihubungkan dengan memberi setiap entitas identitas yang stabil lewat properti @id, lalu merujuk identitas itu dari entitas lain. Cara ini membuat sistem bisa memahami bahwa penulis artikel adalah orang yang sama dengan yang ada di halaman profil, dan bahwa artikel diterbitkan oleh organisasi yang sama dengan yang ada di beranda.

Contoh berikut memakai organisasi fiktif di domain example.org. Di halaman sungguhan, objek ini diletakkan di dalam tag script bertipe JSON-LD, biasanya dihasilkan otomatis oleh template CMS. Ini contoh implementasi untuk memperlihatkan hubungan antarentitas, dan tidak dimaksudkan sebagai konfigurasi yang menghasilkan citation.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.org/#organization",
      "name": "Contoh Kopi Nusantara",
      "url": "https://example.org/",
      "logo": "https://example.org/logo.png",
      "sameAs": [
        "https://www.linkedin.com/company/contoh-kopi-nusantara"
      ]
    },
    {
      "@type": "Person",
      "@id": "https://example.org/penulis/rina-santoso#person",
      "name": "Rina Santoso",
      "url": "https://example.org/penulis/rina-santoso",
      "worksFor": { "@id": "https://example.org/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://example.org/blog/cara-menyeduh-v60#article",
      "headline": "Cara Menyeduh Kopi dengan V60",
      "datePublished": "2026-10-01",
      "dateModified": "2026-10-20",
      "author": { "@id": "https://example.org/penulis/rina-santoso#person" },
      "publisher": { "@id": "https://example.org/#organization" },
      "mainEntityOfPage": "https://example.org/blog/cara-menyeduh-v60"
    }
  ]
}

Ada beberapa prinsip yang terlihat di contoh tersebut. Nilai @id berupa URL yang tidak berubah, biasanya URL halaman ditambah penanda seperti #organization atau #person. Artikel tidak menulis ulang detail penulis dan organisasi, cukup merujuk ke @id masing-masing. Properti sameAs hanya berisi profil resmi yang benar-benar dimiliki organisasi.

Nama penulis di markup harus sama dengan nama yang tampil di halaman, dan URL penulis sebaiknya mengarah ke halaman profil yang memang ada. Jika satu orang menulis di beberapa situs milik grup yang sama, pakai @id yang sama di semua situs supaya identitasnya konsisten. Minta developer meninjau contoh ini terhadap template CMS Anda sebelum dipakai, karena struktur URL dan properti yang tersedia berbeda di setiap situs.

Bagaimana memasang dan memvalidasinya?

Markup dipasang lewat template CMS atau kode situs, lalu divalidasi sebelum dan sesudah rilis. Validasi memeriksa kode, sedangkan pemeriksaan sesudah rilis memastikan Google benar-benar bisa mengakses halaman dan markup yang Anda kirim.

1. Pastikan markup dibuat dari data yang sama dengan yang tampil di halaman, idealnya langsung dari field CMS, supaya keduanya tidak berbeda.
2. Periksa duplikasi. Tema, plugin SEO, dan kode kustom sering menghasilkan blok markup sendiri-sendiri untuk entitas yang sama.
3. Uji kode dengan Schema Markup Validator untuk sintaks dan kosakata schema.org.
4. Uji halaman dengan Rich Results Test untuk melihat apakah markup memenuhi syarat fitur Google yang didukung.
5. Setelah rilis, periksa halaman dengan URL Inspection di Search Console untuk melihat versi yang diambil Google.
6. Pantau laporan status rich result di Search Console, karena markup bisa rusak setelah perubahan template.

Panduan structured data Google menyarankan memakai Rich Results Test selama pengembangan dan laporan status rich result setelah rilis, karena markup bisa rusak akibat masalah template atau penyajian. Hasil validator yang lolos hanya berarti kodenya terbaca dan memenuhi syarat teknis. Hasil itu tidak membuktikan halaman akan tampil sebagai rich result atau performanya akan naik.

Perhatikan juga cara markup dibuat. Jika markup disisipkan lewat JavaScript, misalnya oleh tag manager, pastikan versi halaman yang dirender Google memuat markup tersebut dengan memeriksanya di URL Inspection. Halaman yang diblokir robots.txt, membutuhkan login, atau gagal dirender tidak bisa dibaca markup-nya oleh sistem mana pun. Cara mengecek apakah crawler bisa membaca halaman Anda dijelaskan di panduan cara cek AI crawler membaca halaman.

Kesalahan apa yang paling sering perlu diperbaiki?

Kesalahan yang paling sering ditemukan adalah markup ganda yang saling bertentangan, tipe entitas yang salah, fakta produk yang tidak akurat, ulasan yang dikarang, tautan identitas yang tidak berhubungan, dan konten yang hanya ada di markup.

Markup ganda muncul ketika dua plugin atau tema membuat blok Organization atau Article sendiri dengan nilai berbeda, misalnya dua nama organisasi atau dua tanggal terbit. Sistem yang membaca halaman harus menebak mana yang benar. Pilih satu sumber markup untuk setiap entitas dan matikan yang lain.

Tipe yang salah terjadi ketika halaman diberi label yang tidak sesuai isinya. Pedoman umum Google memberi contoh situs pertukangan kayu yang melabeli instruksi sebagai resep. Fakta produk yang tidak akurat, seperti harga di markup yang berbeda dari harga di halaman, sering terjadi setelah promo berakhir tetapi markup tidak ikut diperbarui.

Ulasan dan rating perlu perhatian khusus. Pedoman Google melarang markup untuk konten yang menyesatkan seperti ulasan palsu, dan menyebut ulasan atau rating yang tidak berasal dari pengguna nyata bisa berujung pada manual action. Jangan pernah menambahkan aggregateRating dari angka yang tidak tampil dan tidak berasal dari ulasan asli. Jika halaman Anda memang memuat ulasan pelanggan yang asli dan terlihat, markup boleh mencerminkan ulasan tersebut sesuai dokumentasi fitur yang berlaku.

Tautan identitas yang tidak berhubungan muncul di properti sameAs, misalnya profil media sosial milik orang lain atau halaman Wikipedia tentang topik umum. Konten yang hanya ada di markup, seperti tanya jawab yang tidak tampil di halaman, melanggar pedoman Google bahwa markup tidak boleh menjelaskan konten yang tidak terlihat oleh pembaca.

Apa yang tidak perlu ditambahkan?

Tidak perlu menambahkan markup khusus AI, karena Google menyatakan tidak ada markup schema.org khusus yang diperlukan untuk fitur AI-nya. Begitu juga dengan markup untuk konten yang tidak ada di halaman.

Contoh yang paling relevan saat ini adalah markup tanya jawab. Banyak situs menambahkan blok pertanyaan dan jawaban di akhir artikel hanya untuk memasang markup FAQ. Menurut catatan pembaruan dokumentasi Google Search, rich result FAQ sudah tidak lagi ditampilkan di Google Search, sebagaimana diumumkan pada Mei 2026, dan dokumentasinya sudah dihapus. Untuk artikel dan halaman layanan biasa, menambahkan blok dan markup semacam itu tidak memberi manfaat tampilan di Google dan menambah konten yang harus dirawat.

Hal yang sama berlaku untuk properti yang tidak dipakai fitur mana pun dan tidak ada datanya. Mengisi puluhan properti dengan nilai seadanya meningkatkan risiko data yang salah. Lebih baik sedikit properti dengan data akurat daripada banyak properti dengan data yang tidak dirawat.

Bagaimana memprioritaskan pekerjaan schema?

Prioritas tertinggi adalah memperbaiki kesalahan fakta yang material dan implementasi fitur yang didukung tetapi rusak. Penambahan tipe baru yang manfaatnya belum jelas berada di urutan paling bawah.

1. Perbaiki fakta yang salah di markup, terutama harga, ketersediaan, alamat, dan jam buka, karena kesalahan ini bisa menyesatkan pembeli.
2. Hapus markup yang melanggar pedoman, seperti ulasan yang tidak asli atau konten tersembunyi.
3. Rapikan markup ganda supaya setiap entitas punya satu sumber.
4. Perbaiki implementasi fitur yang didukung tetapi muncul error di Search Console.
5. Lengkapi Organization dan hubungan penulis serta artikel di template utama.
6. Pertimbangkan tipe tambahan hanya jika ada fitur yang didokumentasikan dan datanya bisa dirawat.

Untuk menemukan masalah di urutan teratas, mulailah dengan memeriksa sampel dari setiap template. Ambil satu atau dua halaman dari setiap template utama, seperti beranda, artikel, kategori, produk, dan cabang, lalu periksa markup-nya dengan validator dan bandingkan nilainya dengan teks yang tampil. Masalah di template biasanya berulang di semua halaman yang memakai template itu, sehingga satu perbaikan bisa menyelesaikan banyak halaman sekaligus. Untuk situs besar, crawler seperti Screaming Frog bisa mengekstrak markup dari seluruh halaman supaya pola kesalahan lebih cepat terlihat.

Tetapkan juga pemilik pemeliharaan. Harga dan ketersediaan biasanya dipegang tim produk atau ecommerce, data penulis dipegang tim konten, dan data organisasi dipegang tim marketing atau legal. Setiap kali ada perubahan, seperti cabang baru, penulis keluar, atau nama produk diganti, pemilik datanya memastikan markup ikut diperbarui.

Cara menyusun konten supaya mudah dipakai sebagai jawaban langsung dibahas di panduan AEO, dan hubungannya dengan pekerjaan SEO yang lebih luas ada di artikel AI SEO. Jika Anda ingin memperbaiki data terstruktur yang memang berguna tanpa mengejar markup khusus AI yang tidak diperlukan, tim AI Search bisa mengaudit fondasi teknis situs Anda lewat audit visibilitas AI gratis.