Mulai dari halaman dan fitur yang didukung
Jangan mulai dengan menambahkan setiap tipe schema.org yang terdengar relevan dengan bisnis Anda. Schema.org adalah kosakata bersama yang luas, sementara Search Gallery Google mendokumentasikan fitur hasil kaya yang didukungnya dan properti yang dibutuhkan. Halaman produk, acara, atau artikel harus berguna terlebih dahulu tanpa markup.
Untuk setiap template, namai subjek utama dan fakta pendukung yang terlihat. Kemudian baca panduan Google saat ini untuk fitur yang sesuai. Product, Recipe, Article, Breadcrumb, Event, Organization, Local business, dan Video adalah contoh. Suatu tipe kosakata saja tidak menciptakan fitur Google; properti yang diperlukan oleh fitur itulah yang menentukan kelayakan.
Buat item terlihat utama sebagai markup utama.
Gunakan panduan Google untuk perilaku fitur dan schema.org untuk kosakata.
Jadikan halaman yang terlihat sebagai sumber kebenaran
Markup harus merepresentasikan konten utama halaman, bukan materi tersembunyi, tidak relevan, atau menyesatkan. Jika markup menyatakan seorang pemeran tampil, halaman perlu mendeskripsikan pemeran itu. Jika menandai rating agregat, pengunjung harus dapat melihat rating tersebut. Ini mencegah template mengambang menjadi ringkasan yang menyesatkan.
Bangun salinan halaman dan markup dari catatan yang sama yang disetujui. Feed produk, sistem acara, atau CMS dapat memasok keduanya, tetapi nilai harus ditinjau sebelum publikasi. Jangan menyalin harga, status stok, tanggal, atau total ulasan ke bidang yang hanya muncul di markup yang bisa terlupakan. Perbarui atau hapus markup ketika informasi yang terlihat berubah.
Jaga nama, tanggal, harga, ketersediaan, dan peringkat tetap selaras dengan halaman.
Jangan pernah mengisi properti dengan nilai tebak-tebakan atau kadaluarsa.
Gunakan JSON-LD sebagai lapisan data yang mudah dipelihara
JSON-LD adalah format linked-data berbasis JSON yang ditempatkan dalam dokumen HTML. Google mendukung JSON-LD, Microdata, dan RDFa, dan mengatakan JSON-LD umumnya paling mudah diimplementasikan dan dipelihara dalam skala besar. Pemisahannya dari markup yang terlihat dapat membuat pemodelan informasi bersarang menjadi lebih mudah.
Gunakan satu objek data yang jelas untuk setiap item nyata, dengan tipe schema.org yang sesuai dan properti didukung yang akurat. Untuk setiap template, dokumentasikan panduan fitur, bidang sumber, perilaku bidang yang wajib, dan pemiliknya. Inspeksi juga output yang dirender: plug-in atau komponen dapat menambahkan markup duplikat atau konflik.
Pilih format yang tim Anda dapat pelihara secara konsisten.
Jangan menciptakan nilai wajib ketika data sumber tidak ada.
Validasi kode dan halaman yang dapat diakses
Validasi menjawab dua pertanyaan. Pertama, apakah markup cukup lengkap untuk fitur yang didukung? Rich Results Test menerima kode yang ditempel atau URL publik yang dapat diakses dan melaporkan hasil kaya yang dapat dihasilkan dari data terstruktur. Uji contoh representatif untuk setiap template, bukan satu halaman yang sangat lengkap.
Kedua, dapatkah Google mengakses halaman dan sumber daya yang dirilis? Jangan blokir halaman yang diberi markup dengan robots.txt, noindex, atau kontrol akses. Periksa URL gambar terkait. Tes bukan jaminan kualitas: masalah konten terlihat atau kebijakan masih dapat mencegah tampilan.
Uji kode dulu, lalu uji URL publik yang dapat diakses.
Bandingkan halaman ter-render, source, dan hasil tes ketika tooling menambahkan markup.
Potensi tampilan bukan janji bahwa tampilan akan terjadi.
Rilis seperti perubahan template yang menghadap pengguna
Data terstruktur sering bergantung pada template, feed, dan aturan publikasi. Redesain, perubahan integrasi inventaris, pembaruan lokalisasi, atau komponen yang dihapus dapat merusak banyak item. Tambahkan pemeriksaan markup representatif ke tinjauan pra-rilis yang biasa Anda gunakan untuk tag kanonik, judul, dan gambar. Catat template, contoh halaman, bidang sumber, dan tanggal rilis.
Ketika sebuah template menerbitkan markup yang salah, koreksi sumber bersama atau template, validasi sampel kecil, terapkan perubahan paling sempit yang aman, dan uji ulang URL yang terdampak. Jika perbaikan berperilaku tidak terduga, gunakan proses rollback normal Anda. Tujuannya adalah remediasi berbasis bukti atas kemampuan web yang menurun, bukan alert gangguan.
Periksa set halaman representatif, bukan satu URL tunggal.
Catat perubahan dan komponen markup sebelum perbaikan lanjutan.
Pelihara, ukur, dan terima batas tampilan
Setelah penerapan, gunakan laporan hasil kaya terkait di Search Console untuk menyelidiki masalah dan memastikan perbaikan. Laporan adalah sampel daripada inventaris lengkap, dan hitungan merujuk pada item, bukan halaman. Periksa URL spesifik bila diperlukan.
Ukur dengan hati-hati. Google menyarankan perbandingan sebelum-dan-sesudah pada halaman yang stabil dan cukup dibaca selama beberapa bulan di Search Console. Catat tanggal rilis dan perubahan halaman lain. Koreksi markup hanya memungkinkan kelayakan; Google menentukan presentasi pencarian.
Periksa ulang setelah pembaruan CMS, template, feed, kebijakan, atau model konten.
Hindari perbandingan ketika perubahan besar lain pada halaman berbeda.