Tutorial Audit Halaman 404 dengan Chrome DevTools Tanpa Mengubah Server
Audit halaman 404 dengan Chrome DevTools: siapkan URL pembanding, periksa status dokumen dan aset, lalu catat temuan untuk perbaikan website.
Mengapa tampilan halaman saja belum cukup
Halaman bertuliskan 'tidak ditemukan' dapat terlihat meyakinkan, tetapi tulisan itu belum menjelaskan respons yang dikirim server. Sebaliknya, sebuah halaman yang tampak normal dapat memuat gambar atau berkas tampilan yang hilang. Karena itu, audit 404 perlu membedakan dokumen utama dari sumber daya pendukung. Tutorial ini membantu pengelola website mengumpulkan bukti melalui Chrome DevTools sebelum meminta perubahan kepada pengembang atau penyedia hosting.
MDN menjelaskan bahwa status HTTP 404 berarti sumber daya yang diminta tidak ditemukan. Status tersebut sendiri tidak memastikan apakah keadaan itu sementara atau permanen. Dalam audit berikut, hasil yang dituju ialah daftar URL, status respons, jenis sumber daya, serta tindakan yang perlu ditinjau. Anda tidak perlu mengedit konfigurasi server atau memasang plugin. Mulailah dengan beberapa halaman publik milik sendiri, lalu perluas pemeriksaan berdasarkan temuan yang benar-benar muncul.
Prasyarat: siapkan ruang lingkup dan URL pembanding
Siapkan Chrome versi yang masih didukung, koneksi internet, website yang Anda kelola, dan tempat mencatat hasil. Pilih satu halaman yang seharusnya tersedia, satu alamat lama yang perlu diperiksa, serta satu alamat buatan yang dipastikan tidak pernah digunakan. Untuk alamat buatan, tambahkan jalur unik pada domain sendiri, misalnya /uji-halaman-tidak-ada-november-2026/. Pastikan nama tersebut belum tercatat sebagai halaman atau aturan pengalihan sebelum memakainya sebagai pembanding.
Batasi percobaan pada halaman publik yang tidak mengirim formulir, menjalankan transaksi, atau mengubah data. Jangan memasukkan kata sandi maupun informasi pelanggan dalam alamat pengujian. Bila website memakai aplikasi yang menangani navigasi di browser, catat kondisi itu karena tampilan pesan kesalahan dapat dihasilkan oleh aplikasi setelah dokumen utama diterima. Audit kecil ini bukan pemindaian seluruh situs: hasilnya berlaku pada URL, waktu, dan perjalanan halaman yang benar-benar diperiksa.
Langkah 1: buat lembar pemeriksaan yang dapat ditindaklanjuti
Buat catatan dengan kolom URL awal, harapan, URL akhir, status dokumen, status aset bermasalah, waktu pemeriksaan, dan tindak lanjut. Isikan harapan sebelum membuka halaman. Contohnya, halaman layanan aktif seharusnya menampilkan informasi layanan yang benar; alamat buatan seharusnya memberikan penjelasan bahwa konten tidak ada. Untuk alamat lama, tentukan terlebih dahulu apakah kontennya dipindahkan, dihapus, atau belum diketahui agar Anda tidak menilai semua pengalihan sebagai keberhasilan.
Gunakan satu baris per URL awal agar pemeriksaan mudah diulang. Sebagai contoh hipotetis, halaman /layanan-lama/ mungkin seharusnya menuju halaman layanan baru yang setara, bukan halaman depan tanpa penjelasan. Simpan alasan harapan itu, seperti catatan pemindahan dari pemilik konten. Pisahkan dugaan dari hasil pengamatan. Dengan cara tersebut, orang yang menerima laporan dapat memeriksa alasan bisnisnya sekaligus bukti teknisnya tanpa harus mengulang percakapan dari awal.
Langkah 2: rekam pemuatan lewat panel Network
Buka halaman pembanding yang tersedia, lalu tekan Ctrl+Shift+I pada Windows untuk membuka DevTools dan pilih panel Network. Pastikan perekaman aktif. Aktifkan Preserve log bila ingin mempertahankan rekaman saat halaman berpindah, kemudian muat ulang halaman. Dokumentasi Chrome menyatakan bahwa panel ini merekam permintaan selama DevTools terbuka. Untuk memeriksa jalur jaringan tanpa memakai cache browser, Anda dapat mencentang Disable cache selama pemeriksaan.
Cari permintaan dokumen utama, bukan langsung menyimpulkan dari satu baris berwarna merah. Klik permintaan yang sesuai dengan alamat halaman, buka Headers, lalu periksa Request URL dan Status Code pada bagian General. Catat hasil beserta URL akhir yang terlihat di bilah alamat. Jika ada pengalihan, pertahankan catatan URL awal dan tujuan akhirnya. Pengaturan pencatatan ini membantu membedakan halaman yang langsung tersedia dari halaman yang sampai ke tujuan setelah satu atau beberapa perpindahan.
Langkah 3: uji alamat yang dipastikan tidak ada
Masukkan alamat buatan yang telah disiapkan pada bilah alamat dengan DevTools tetap terbuka. Perhatikan respons dokumen utamanya dan baca isi halaman yang tampil. Hasil yang konsisten untuk kasus sederhana ialah dokumen berstatus 404 dengan penjelasan yang membantu pengunjung melanjutkan pencarian. Catat bila server justru mengirim 200, mengalihkan semuanya ke beranda, atau menghasilkan pesan kesalahan teknis yang tidak sesuai dengan rancangan situs.
Google menjelaskan bahwa konten yang tampak seperti kesalahan tetapi dikirim sebagai respons sukses dapat dikenali sebagai soft 404. Namun, hasil satu pengujian di browser tidak cukup untuk menyatakan bahwa Google telah memberi label tersebut pada situs Anda. Tuliskan temuan secara tepat, misalnya 'URL buatan menerima 200 dan menampilkan pesan tidak ditemukan'. Jika memiliki akses yang sah, penanggung jawab situs dapat mencocokkannya dengan laporan Search Console. Jangan menjanjikan perubahan indeks atau peringkat dari pemeriksaan ini.
Langkah 4: bandingkan halaman aktif dan alamat lama
Kembali ke halaman yang seharusnya tersedia dan cocokkan statusnya dengan isi yang diharapkan. Respons 200 bukan satu-satunya kriteria: judul, isi utama, dan tujuan halaman juga perlu benar. Selanjutnya buka alamat lama yang Anda siapkan. Bila konten memang dipindahkan, periksa apakah tujuan akhirnya merupakan pengganti yang relevan. Jangan membuat aturan pengalihan baru dalam tahap audit; kumpulkan terlebih dahulu pemetaan yang akan disetujui pemilik konten.
Sebagai contoh hipotetis, artikel lama tentang layanan tertentu dapat memiliki pengganti yang membahas layanan sama dengan penjelasan terbaru. Tujuan tersebut lebih mudah dipahami pengunjung dibandingkan halaman umum yang tidak menjawab maksud tautan lama. Jika belum ada pengganti, catat kebutuhan keputusan editorial, bukan menebak alamat tujuan. Dokumentasi Google membedakan respons sukses dan pengalihan serta menegaskan bahwa status sukses tidak menjamin pengindeksan. Gunakan status sebagai bukti perilaku HTTP, lalu nilai kecocokan kontennya secara terpisah.
Langkah 5: pisahkan 404 dokumen dari 404 gambar dan skrip
Pada panel Network, masukkan status-code:404 ke kotak Filter. Chrome mendokumentasikan penyaringan berdasarkan kode status untuk menampilkan permintaan yang cocok. Jika daftar berisi gambar, font, atau skrip, catat URL sumber daya dan halaman yang memanggilnya. Hapus filter ketika ingin melihat kembali permintaan lain. Daftar kosong hanya berarti tidak ada respons 404 dalam rekaman yang sedang dilihat; itu bukan bukti bahwa semua tautan di website sudah diperiksa.
Kelompokkan dampaknya berdasarkan penggunaan halaman. Gambar penjelas yang hilang mungkin membuat instruksi sulit diikuti; skrip yang gagal dimuat mungkin berkaitan dengan tombol yang tidak bekerja; ikon dekoratif memiliki dampak berbeda. Periksa tindakan pengguna secara wajar tanpa mengirim transaksi atau data nyata. Jangan menyebut seluruh website tidak aktif hanya karena satu aset hilang. Laporan yang memisahkan dokumen dan aset akan membantu tim memilih perbaikan dengan alasan yang dapat dijelaskan kepada pemilik website.
Langkah 6: uji ulang setelah perbaikan dilakukan
Serahkan daftar temuan kepada pihak yang berwenang memperbaiki tautan, konten, atau konfigurasi. Setelah mereka menyatakan perbaikan selesai, ulangi URL yang sama dan bandingkan dengan harapan pada lembar pemeriksaan. Untuk halaman aktif, pastikan isi yang dibutuhkan tampil dan aset penting tersedia. Untuk alamat yang memang tidak ada, pastikan situs memberikan respons dan penjelasan yang sesuai. Untuk perpindahan konten, periksa kembali URL awal serta tujuan akhirnya.
Catat waktu pengujian ulang dan status setiap temuan sebagai selesai, masih bermasalah, atau memerlukan keputusan. Bila hasil berbeda antarperangkat, tuliskan perangkat dan kondisi yang digunakan daripada menganggap salah satu pengamat keliru. Pengujian terbatas dengan cache browser dinonaktifkan juga tidak otomatis melewati cache pada semua lapisan lain. Jika aplikasi menggunakan service worker, minta pengembang membantu membedakan respons aplikasi dari respons jaringan sebelum menentukan bahwa sumber masalah berada pada hosting.
Kesalahan umum dan cara menyerahkan laporan
Kesalahan yang sering membuat audit sulit digunakan adalah membuka DevTools setelah kejadian tanpa memuat ulang, membiarkan filter lama menyembunyikan hasil, menyamakan semua baris gagal dengan 404, serta menganggap tulisan pada halaman sebagai status HTTP. Hindari pula mengirim rekaman lengkap yang tidak diperlukan. Untuk laporan sederhana, tulis URL publik, status, waktu, jenis masalah, dan langkah untuk mengulangnya; tangkapan layar sebaiknya hanya memperlihatkan bagian relevan yang sudah diperiksa isinya.
Saat membutuhkan pembahasan layanan, gunakan https://www.jagoweb.com/ untuk mengenali pilihan JagoWeb dan https://www.jagoweb.com/hosting-cpanel untuk informasi hosting cPanel. Bawa laporan konkret agar tim dukungan memahami URL mana yang perlu diperiksa dan hasil apa yang diharapkan. Audit yang baik menghasilkan keputusan perbaikan yang jelas. Ulangi pemeriksaan setelah perubahan alamat besar atau peluncuran bagian situs, lalu simpan hasilnya sebagai acuan pemeliharaan berikutnya tanpa menyatakan bahwa sampel kecil mewakili seluruh website.
Bacaan terkait
Sumber dan referensi
