Seratus peringatan dalam laporan crawler tidak selalu berarti seratus kerusakan website. Sebagian temuan mungkin disengaja, sebagian berasal dari batas pengambilan data, dan sebagian memang menghalangi halaman penting.
Saya memperlakukan laporan crawler sebagai daftar calon masalah. Sebelum membuat tiket perbaikan, kita perlu menunjukkan URL yang terdampak, perilaku yang salah, tujuan halaman, dan cara membuktikan bahwa perubahan nantinya berhasil.
Baca arti label alat secara terbatas
Screaming Frog membagi temuannya menjadi issues, warnings, dan opportunities. Prioritas yang ditampilkan memberi petunjuk potensi dampak, tetapi konteks situs tetap menentukan apakah temuan perlu ditindaklanjuti. Penjelasan laporan Issues.
Artinya, label “high” belum menggantikan pemeriksaan manusia. Sebaliknya, temuan yang tampak kecil bisa penting jika muncul pada satu-satunya jalur menuju halaman utama layanan.
Misalnya, 300 gambar dekoratif memiliki alt kosong sementara satu tombol bergambar tidak memiliki nama yang menjelaskan tindakannya. Mengisi seluruh alt kosong dengan nama brand mungkin mengurangi angka laporan, tetapi belum menyelesaikan hambatan tombol tersebut.
Bangun satu kartu bukti per jenis masalah
Ambil satu URL representatif untuk setiap pola sebelum membuka ratusan URL. Jika perilakunya berbeda menurut template atau perangkat, tambah sampel yang mewakili perbedaan itu.
Isi kartu berikut:
| Kolom | Contoh ilustratif |
|---|---|
| Temuan alat | Halaman kategori tidak mempunyai tautan produk |
| URL dan waktu | URL kategori serta waktu crawl |
| Kondisi pengambilan | HTML awal, tanpa render JavaScript |
| Perilaku yang diharapkan | Pengunjung dan crawler dapat mengikuti tautan produk |
| Bukti langsung | Perbandingan HTML awal, hasil render, dan elemen tautan |
| Keputusan | Masalah ekstraksi, masalah implementasi, atau belum jelas |
Kalau kartu tidak memiliki bukti langsung, statusnya masih dugaan. Jangan mengisi kolom keputusan dengan “perbaiki semua” hanya karena jumlah temuan besar.
Bedakan empat pola yang sering tertukar
Tidak ada tautan keluar bukan berarti orphan page. Tautan keluar menjelaskan hubungan dari halaman yang sedang diperiksa. Orphan page berkaitan dengan tidak ditemukannya tautan masuk internal dalam ruang pengamatan tertentu. Periksa arah hubungan dan sumber inventaris URL sebelum menggunakan istilah tersebut.
Canonical berbeda belum tentu salah. URL berparameter mungkin memang menunjuk versi utama. Yang perlu diuji adalah kesetaraan halaman dan konsistensi tujuan canonical, bukan sekadar apakah dua teks URL identik. Canonical membantu menggabungkan sinyal versi duplikat; Google tetap memilih canonical berdasarkan beberapa sinyal. Panduan canonical Google.
Alt kosong belum tentu kurang informasi. Gambar dekoratif dapat menggunakan alt kosong, sedangkan gambar fungsional perlu menyampaikan tujuan tindakannya. Buka halaman dan lihat peran gambar sebelum membuat aturan massal. Keputusan alt dari W3C.
Nilai yang tidak diekstrak belum tentu tidak ada. Periksa apakah fitur ekstraksi aktif, apakah konten dibuat setelah render, dan apakah crawler menerima halaman yang benar. Halaman login yang berhasil dimuat dapat menghasilkan banyak temuan “hilang” yang sebenarnya menjelaskan salahnya keadaan pengambilan.
Kelompokkan berdasarkan akar masalah
Setelah pola pertama terbukti, telusuri cakupannya. Apakah masalah muncul pada seluruh template kategori, hanya halaman dengan stok kosong, atau hanya satu komponen navigasi?
Contoh ilustratif: 120 URL menghasilkan canonical yang menunjuk host staging. Jika semuanya memakai template yang sama, satu perbaikan sumber konfigurasi mungkin menyelesaikan polanya. Membuat 120 tiket manual akan menyembunyikan hubungan tersebut.
Sebaliknya, jangan menggabungkan dua masalah hanya karena labelnya sama. Dua halaman soft 404 bisa memiliki penyebab berbeda: satu kehilangan data produk, satu lagi mengembalikan hasil pencarian kosong. Kelompok perbaikan harus mengikuti perilaku dan sumber kesalahan.
Prioritaskan berdasarkan fungsi yang terganggu
Tanyakan tiga hal: fungsi apa yang rusak, berapa besar ruang yang terbukti terkena, dan apakah perbaikannya dapat diuji dengan jelas? Gunakan jawaban untuk memilih pekerjaan berikutnya.
Urutan ini membantu saat sumber daya terbatas. Halaman layanan penting yang tidak dapat diakses memerlukan perhatian berbeda dari saran panjang judul pada halaman arsip yang memang tidak menjadi tujuan pencarian. Kamu tidak perlu memperkirakan kenaikan trafik yang belum punya bukti untuk menjelaskan prioritas tersebut.
Tuliskan tiket dengan kalimat konkret: “Template kategori menghapus tautan produk dari hasil render pada keadaan filter kosong; pulihkan tautan menuju daftar produk yang tersedia.” Sertakan URL contoh dan hasil yang diharapkan.
Tutup tiket melalui uji yang sama
Ulangi kondisi pengambilan yang mengungkap masalah. Jika perubahan menyentuh template, uji satu sampel terdampak dan satu sampel kontrol yang seharusnya tetap bekerja. Periksa respons, elemen relevan, dan jalur pengguna sesuai tujuan tiket.
Jalankan ulang bagian crawl yang diperlukan, lalu baca peringatan yang masih tersisa. Temuan bisa tetap muncul karena aturan alat tidak menggambarkan keputusan situs, atau karena masalahnya memang belum selesai. Simpan alasannya secara eksplisit.
Laporan akhir yang berguna tidak harus menunjukkan angka nol. Ia perlu menjelaskan apa yang diperbaiki, apa yang sengaja dipertahankan, dan bagian mana yang masih membutuhkan bukti.
