Pesan “valid” dari sebuah alat belum tentu berarti markup sudah benar untuk halamanmu. JSON bisa terbaca tetapi menunjuk penulis yang salah. Sebuah tipe Schema.org bisa sah tetapi tidak memiliki fitur rich result yang sesuai. Bahkan markup yang memenuhi syarat tidak menjamin Google menampilkannya.
Supaya hasil audit berguna, tulis jenis pemeriksaan yang dilakukan. Kita perlu mengetahui apa yang lolos, fakta apa yang sudah dicocokkan, dan hal apa yang belum diuji.
Mulai dari entitas dan pembuat markup
Identifikasi isi utama halaman: artikel, produk, profil, atau sesuatu yang lain. Lalu cari siapa yang menghasilkan markup. Bisa berasal dari tema, plugin, komponen aplikasi, atau script tambahan.
Periksa JSON-LD, Microdata, dan RDFa sesuai format yang dipakai. Simpan bukti apakah yang diperiksa adalah HTML awal, DOM setelah JavaScript, atau potongan kode. Ketiadaan JSON-LD di HTML awal tidak otomatis membuktikan halaman tidak memiliki structured data dalam format lain.
Google menerima beberapa format structured data dan umumnya merekomendasikan JSON-LD untuk kemudahan implementasi. Pilihan format tetap perlu mempertimbangkan sistem yang sudah berjalan. Pengantar structured data Google.
Gunakan empat lapis pemeriksaan
| Lapis | Pertanyaan | Bukti kelulusan yang tepat |
|---|---|---|
| Sintaks | Apakah data bisa diparse? | Hasil parser pada blok yang diperiksa |
| Kosakata | Apakah tipe dan properti sesuai makna? | Pemeriksaan Schema.org dan relasi entitas |
| Fakta | Apakah data cocok dengan isi nyata? | Perbandingan markup, halaman, dan sumber data |
| Fitur | Apakah memenuhi persyaratan konsumen tertentu? | Tes serta dokumentasi fitur yang dipilih |
Pisahkan pula deploy, crawl, indexing, dan tampilan hasil pencarian. Keempatnya adalah keadaan operasional yang berbeda dari validitas kode.
Pedoman Google menuntut data yang menggambarkan isi halaman secara benar dan relevan. Lolos pemeriksaan teknis tidak menghilangkan kebutuhan tersebut, dan kelayakan tidak menjamin rich result tampil. Pedoman structured data.
Contoh: dua plugin memberi harga berbeda
Bayangkan halaman produk menampilkan harga Rp185.000. Plugin toko menghasilkan Offer dengan harga 185000 IDR, tetapi plugin SEO tambahan masih menyimpan 165000 IDR. Kedua blok bisa berupa JSON yang valid.
Masalahnya berada pada fakta dan kepemilikan data, bukan sekadar tanda koma. Menambahkan blok ketiga yang benar hanya membuat halaman semakin sulit dipelihara.
Gunakan tabel temuan seperti ini:
| Node | Pembuat | Fakta yang terlihat | Tindakan |
|---|---|---|---|
| Product utama | Plugin toko | SKU dan harga sesuai | Pertahankan sumber yang benar |
| Product tambahan | Plugin SEO | Harga tertinggal | Perbaiki konfigurasi atau hilangkan keluaran duplikat setelah diuji |
| Breadcrumb | Tema | Jalur kategori sesuai | Verifikasi relasi dan URL |
Contoh tersebut bersifat ilustratif. Di website nyata, temukan pembuat keluaran sebelum menonaktifkan fitur, karena satu plugin mungkin juga mengelola komponen lain yang masih dibutuhkan.
Jangan mengarang data untuk menghilangkan warning
Warning properti yang disarankan bukan izin menambahkan rating, harga, tanggal, atau kredensial fiktif. Jika fakta opsional tidak tersedia, evaluasi apakah properti tersebut memang relevan. Jika fakta wajib bagi fitur belum tersedia, catat sebagai gap kelayakan.
Satu halaman juga tidak perlu diberi semua tipe yang tersedia. Pertanyaan yang lebih berguna adalah: entitas apa yang benar-benar dijelaskan halaman dan siapa yang akan menggunakan data ini?
Jika alat fitur tidak menemukan tipe tertentu, periksa dukungan alat tersebut. Hasil itu tidak otomatis berarti seluruh kosakata Schema.org pada halaman salah.
Susun paket verifikasi kecil
Pilih beberapa halaman dengan keadaan berbeda: data lengkap, properti opsional kosong, nama panjang, serta variasi produk bila relevan. Periksa kode yang benar-benar dihasilkan template, bukan hanya contoh yang diketik manual ke validator.
Catat URL, tanggal, versi template, blok atau ID entitas, hasil parser, hasil pemeriksaan fitur, dan kecocokan dengan halaman. Untuk markup yang dibuat JavaScript, bandingkan HTML awal dan DOM agar asal perbedaan jelas.
Jangan mengunggah data privat ke alat publik. Gunakan sampel tanpa informasi sensitif atau pemeriksaan lokal sesuai kebutuhan.
Tutup audit dengan status yang spesifik
Tulislah “sintaks valid, harga dan SKU cocok dengan sampel halaman, kelayakan fitur diperiksa pada tiga URL”. Hindari kalimat “schema sudah sempurna” karena menyembunyikan cakupan.
Setelah rilis yang diizinkan, periksa kembali halaman publik dan laporan yang relevan. Jika jumlah item valid turun, cari apakah markup hilang, template berubah, atau cakupan laporan berbeda. Dengan disiplin ini, structured data menjadi bagian dari kualitas informasi website, bukan sekadar usaha mengumpulkan tanda hijau.
