Pembeli membuka link botol warna hijau, tetapi halaman selalu menampilkan warna hitam. Harga di markup milik ukuran kecil, sementara tombol beli menambahkan ukuran besar. Masalah varian seperti ini menyentuh URL, keadaan aplikasi, dan data produk sekaligus.
Sebelum memilih canonical atau menulis ProductGroup, petakan identitas produk dan cara varian dibuka. Kita perlu memastikan sebuah link mewakili pilihan yang dapat dipulihkan ketika halaman diakses langsung.
Bedakan grup produk dan varian yang dapat dibeli
Grup menghubungkan produk yang memiliki atribut bersama. Varian menyimpan perbedaan yang relevan, seperti ukuran atau warna, beserta identitas dan penawarannya. Jangan memakai satu SKU untuk seluruh varian jika sistem stok sebenarnya membedakannya.
Google mendokumentasikan ProductGroup, hasVariant, dan hubungan varian untuk pendekatan satu halaman maupun banyak halaman. Persyaratan teknis mencakup identitas grup dan varian yang unik serta URL yang dapat membuka varian terpilih. Panduan product variant structured data.
Mulai dari tabel data, bukan dari kode JSON. Jika identitas di katalog belum jelas, markup juga akan mewarisi ketidakjelasan itu.
Contoh matriks varian
Bayangkan botol seri Bumi dengan dua kapasitas dan dua warna. Berikut contoh ilustratif sebagian variannya:
| SKU | Kapasitas | Warna | URL pilihan | Keadaan contoh |
|---|---|---|---|---|
| BUMI-600-H | 600 ml | Hijau | /botol-bumi/?ukuran=600&warna=hijau |
Tersedia |
| BUMI-600-P | 600 ml | Putih | /botol-bumi/?ukuran=600&warna=putih |
Habis sementara |
| BUMI-900-H | 900 ml | Hijau | /botol-bumi/?ukuran=900&warna=hijau |
Tersedia dengan harga berbeda |
Untuk setiap URL, periksa gambar, harga, stok, label pilihan, dan item yang masuk keranjang. Link yang hanya mengubah teks di address bar tetapi tidak memulihkan pilihan saat reload belum menjalankan fungsi yang dibutuhkan.
Jangan menjadikan contoh parameter di atas aturan wajib. Nama dan bentuk URL mengikuti desain aplikasi, selama identitas serta perilakunya jelas.
Pilih model satu halaman atau banyak halaman secara sadar
Dalam model satu halaman, pilihan varian hidup pada satu halaman utama dengan URL yang dapat memilih keadaan tertentu. Dokumentasi Google menetapkan satu canonical untuk ProductGroup pada pendekatan ini. Untuk model banyak halaman, varian tersebar pada halaman yang memiliki peran masing-masing dan persyaratannya berbeda.
Karena itu, jangan mengirim semua varian ke satu canonical hanya berdasarkan kebiasaan. Periksa arsitektur yang benar-benar dipakai, perbedaan isi, serta fungsi setiap halaman. Jangan pula menjadikan setiap kombinasi parameter sebagai halaman indeks terpisah tanpa alasan yang jelas.
Tuliskan keputusan model dalam spesifikasi. Frontend, katalog, schema, dan sitemap perlu memakai pemahaman yang sama agar perubahan satu komponen tidak bertentangan dengan komponen lain.
Petakan fakta bersama dan fakta khusus
Gunakan data grup untuk informasi bersama seperti nama seri dan brand bila relevan. Gunakan data varian untuk SKU, atribut pembeda, gambar, dan penawaran khusus. Hindari meratakan seluruh stok menjadi satu status yang menutupi perbedaan varian.
variesBy menjelaskan atribut yang membedakan varian. Daftarnya harus cocok dengan data produk. Jika kapasitas sebenarnya tidak bisa dipilih atau merupakan produk yang berbeda, tinjau kembali pengelompokannya.
Untuk implementasi banyak halaman, markup pada sebuah halaman perlu cukup lengkap untuk menjelaskan entitas yang disajikan di sana. Jangan mengandalkan potongan fakta yang hanya tersedia pada halaman lain tanpa mengikuti pola yang didukung.
Uji keadaan langsung dan pergantian pilihan
Gunakan worksheet berikut:
- Buka setiap URL varian pada sesi baru.
- Pastikan pilihan awal, gambar, harga, dan stok sesuai matriks.
- Ganti varian, lalu salin URL dan buka di tab baru.
- Reload halaman dan periksa apakah pilihan tetap benar.
- Periksa Product serta Offer terhadap SKU yang dimaksud.
- Uji kombinasi yang tidak tersedia dan parameter yang tidak sah.
Keadaan tidak sah harus ditangani secara jelas. Jangan diam-diam menampilkan produk lain sambil mempertahankan URL yang menjanjikan kombinasi berbeda. Pilihan fallback perlu dipikirkan bersama pengalaman pembeli dan aturan URL website.
Telusuri mismatch dari sumbernya
Jika schema salah tetapi tampilan benar, periksa generator dan cache markup. Jika tampilan serta schema sama-sama salah, periksa resolusi parameter dan data katalog. Jika hanya keranjang salah, telusuri ID yang dikirim oleh komponen pembelian.
Pisahkan ketiga temuan tersebut dalam tiket. Perbaikan JSON-LD saja tidak akan menyelesaikan pembelian varian yang keliru.
Sesudah perubahan, jalankan ulang matriks pada beberapa grup produk dengan variasi berbeda. Simpan bukti URL, SKU, waktu pengamatan, serta versi template. Dengan identitas yang konsisten, pengelolaan katalog dan diagnosis pencarian menjadi jauh lebih jelas.
