Sesudah rilis website, sebuah alat memberi peringatan bahwa canonical berubah dan schema hilang. Itu alasan untuk memeriksa halaman, tetapi belum cukup untuk menyatakan rilis merusak SEO. Mungkin canonical memang diperbaiki. Mungkin tangkapan terbaru justru menerima halaman error.

Saya memakai perbandingan snapshot untuk menjawab pertanyaan yang sempit: apa yang berubah pada halaman tertentu, apakah perubahan itu disengaja, dan apakah keadaan sekarang sesuai tujuan halaman? Pertanyaan dampak trafik membutuhkan bukti lain.

Pilih pembanding yang tepat

Snapshot terakhir tidak selalu menjadi pembanding terbaik. Jika tangkapan terakhir dibuat ketika server sedang bermasalah, membandingkan rilis baru dengannya dapat membuat pemulihan terlihat seperti perubahan besar yang mencurigakan.

Catat identitas snapshot, waktu, URL yang diminta, URL akhir, dan status respons. Hubungkan dengan versi rilis yang relevan bila informasi itu tersedia. Jika tidak ada bukti keadaan sebelum perubahan, tulis bahwa perbandingan belum tersedia. Jangan membuat snapshot baru lalu menamainya sebagai kondisi sebelum rilis.

Contoh ilustratif: kamu ingin memeriksa template artikel setelah perubahan komponen metadata. Pilih tangkapan artikel dari sebelum perubahan tersebut, bukan tangkapan homepage yang kebetulan lebih baru.

Samakan kondisi pengamatan

Bandingkan HTML awal dengan HTML awal, serta hasil render dengan hasil render. Bila hanya salah satunya tersedia, jelaskan batasnya. Pada situs JavaScript, data dapat muncul pada tahap render, sehingga tidak ditemukan dalam HTML awal belum berarti hilang dari halaman yang diproses. Dasar JavaScript SEO Google.

Periksa juga sesi login, bahasa, perangkat, viewport, redirect, dan status respons. Halaman kategori berbahasa Indonesia untuk pengguna publik tidak setara dengan halaman login berbahasa Inggris yang diterima alat setelah sesi berakhir.

Sebelum membaca ratusan selisih, pastikan kedua tangkapan memang berisi jenis halaman yang sama. Satu respons error dapat menjelaskan hilangnya judul, heading, gambar, dan schema sekaligus.

Bedakan perubahan teks dari perubahan makna

Canonical relatif /panduan/ dan canonical absolut https://example.com/panduan/ dapat menunjuk tujuan yang sama setelah diselesaikan terhadap URL dasarnya. Perbandingan string akan melihat perbedaan, tetapi diagnosis perlu memeriksa tujuan sebenarnya.

Sebaliknya, perbedaan satu karakter pada host bisa mengarah ke domain staging. Karena itu, jangan menentukan urgensi berdasarkan panjang perubahan. Periksa host, path, status target, dan konsistensinya dengan halaman yang diinginkan. Panduan canonical Google.

Hal serupa berlaku untuk schema. Perubahan urutan properti JSON tidak sama dengan perubahan harga produk. Hash yang berbeda memberi tanda bahwa representasi berubah; kita tetap perlu membaca nilai yang berubah.

Gunakan matriks keputusan yang kecil

Berikut contoh ilustratif untuk satu rilis template artikel:

Elemen Sebelum Sesudah Keputusan pemeriksaan
HTTP 200 200 Lanjut memeriksa isi
Canonical URL publik yang benar Host staging Dugaan salah konfigurasi
Meta robots Tidak ada noindex Ada noindex Cocokkan dengan tujuan publikasi
JSON-LD Penulis lama Penulis yang telah dikoreksi Perubahan disengaja, periksa sumber datanya
HTML hash Nilai A Nilai B Belum menunjukkan masalah tertentu

noindex yang tidak disengaja pada halaman publik perlu ditelusuri di HTML maupun header. Google perlu dapat mengambil halaman untuk membaca arahan noindex. Dokumentasi noindex.

Matriks ini memisahkan perubahan yang benar, dugaan regresi, dan bukti yang belum cukup. Tim dapat membahas masalah spesifik tanpa harus menyetujui penilaian “seluruh rilis gagal”.

Perluas sampel berdasarkan pola template

Setelah menemukan canonical ke staging pada satu artikel, periksa artikel lain yang menggunakan komponen metadata sama. Ambil juga halaman kontrol yang memakai template berbeda. Jika hanya satu pola terkena, batas perbaikannya lebih jelas.

Tambahkan keadaan yang dapat memicu cabang kode berbeda: artikel tanpa gambar, produk tanpa stok, halaman terjemahan, atau kategori kosong, sesuai perubahan yang sedang diperiksa. Daftar sampel harus mengikuti risiko rilis, bukan daftar URL favorit yang selalu sama.

Simpan nilai lama dan baru yang relevan. Screenshot berguna untuk tampilan, tetapi canonical atau header membutuhkan bukti sesuai bentuk datanya. Jangan mengandalkan screenshot halaman untuk membuktikan header HTTP.

Pisahkan temuan teknis dari dampak bisnis

Kalau canonical salah sudah ditemukan pada lima sampel, kamu dapat menyatakan kelima sampel itu memiliki masalah yang sama. Kamu belum dapat menyatakan seluruh situs terdampak atau trafik pasti turun sekian persen.

Demikian juga satu skor Lighthouse yang turun belum membuktikan pengalaman pengguna lapangan memburuk secara berkelanjutan. Catat kondisi pengujian dan gunakan pemeriksaan performa yang sesuai jika rilis menyentuh sumber daya halaman.

Akhiri dengan bukti pemulihan

Tiket perbaikan perlu menyertakan pembanding, nilai yang salah, keadaan yang diharapkan, dan sampel pengujian. Setelah perubahan, ambil bukti baru dengan kondisi yang sesuai dan ulangi pemeriksaan yang sebelumnya gagal.

Jika hasil belum dapat dibandingkan, pertahankan status belum diketahui. Jika semua pemeriksaan yang dipilih sesuai, laporkan ruang yang telah diperiksa. Tidak adanya alarm hanya menjelaskan aturan dan data yang tersedia, bukan sertifikat bahwa seluruh SEO website sudah sempurna.