Kalau sebuah halaman belum muncul di Google, pekerjaan pertama adalah menemukan tahap yang terhambat. URL yang belum ditemukan, halaman yang gagal dibuka, isi yang tidak selesai dirender, dan halaman yang belum dipilih untuk indeks membutuhkan tindakan berbeda. Menambahkan kata kunci pada semuanya justru membuat diagnosis berputar-putar.
Panduan ini untuk pemilik website dan marketer yang perlu berdiskusi dengan developer tanpa membawa daftar error yang tidak jelas. Kamu tidak harus memperbaiki server sendiri. Hasil yang kita cari adalah satu temuan dengan bukti, dugaan penyebab, dan pemeriksaan sesudah perbaikan.
Pahami hubungan antarproses
Google menjelaskan Search melalui crawling, indexing, dan penyajian hasil. Rendering membantu memproses isi halaman, termasuk JavaScript. Keberhasilan pada satu proses tidak menjamin proses berikutnya selesai atau halaman ditampilkan untuk sebuah pencarian. Penjelasan cara kerja Google Search.
Untuk diagnosis sehari-hari, pecah perjalanan tersebut menjadi pertanyaan yang mudah diamati:
| Pertanyaan | Bukti yang dicari | Kesimpulan yang belum boleh dibuat |
|---|---|---|
| Dari mana URL ditemukan? | Link internal, sitemap, referensi URL | Sitemap berarti sudah diindeks |
| Apakah halaman bisa diambil? | Respons HTTP, aturan akses, log | Terbuka di laptop berarti terbuka untuk crawler |
| Apakah isi utama hadir? | HTML awal, DOM setelah render, resource gagal | Screenshot berarti semua teks terbaca mesin |
| Apakah URL memang layak menjadi versi utama? | Directives, canonical, isi pembanding | Canonical yang ditulis pasti dipilih Google |
| Apa status pemrosesan Google? | URL Inspection beserta tanggal crawl | Live test berarti sudah masuk indeks |
| Untuk query apa halaman ditampilkan? | Search Console dengan filter jelas | Tidak ada klik berarti tidak terindeks |
Tabel ini bukan skor SEO. Ia membantu menentukan bukti berikutnya yang masih kurang.
Mulai dengan satu URL dan satu gejala
Tulis gejala secara sempit. “SEO turun” terlalu luas. “Tiga halaman produk baru tidak terlihat pada laporan Search Console sejak rilis katalog” lebih mudah ditelusuri.
Catat URL lengkap, waktu halaman dibuat atau diubah, template yang dipakai, dan status yang diharapkan. Lalu pilih satu halaman lama yang masih berjalan sebagai pembanding. Kalau keduanya memakai template yang sama tetapi hanya halaman baru bermasalah, dugaan awal berbeda dari kasus seluruh katalog gagal.
Jangan langsung melakukan crawl besar. Satu contoh terdampak dan satu pembanding bisa mengungkap kesalahan template. Setelah mekanismenya jelas, barulah periksa berapa banyak URL yang terkena.
Contoh ilustratif: produk ada, tetapi isi hanya muncul setelah memilih cabang
Misalnya toko alat gambar memiliki halaman /produk/cat-air-24/. Halaman itu tercantum di sitemap dan mengembalikan respons 200. Namun, sebelum pengunjung memilih cabang toko, layar hanya menampilkan pemilih lokasi. Detail produk baru diambil sesudah klik.
Berikut urutan pembuktiannya:
- Buka URL langsung dalam sesi baru. Catat apa yang terlihat sebelum interaksi.
- Periksa HTML respons untuk nama, deskripsi, dan link produk terkait.
- Bandingkan dengan DOM setelah halaman selesai dimuat tanpa klik.
- Pilih cabang, lalu lihat informasi apa yang baru muncul.
- Cocokkan dengan hasil inspeksi halaman oleh Google bila akses properti tersedia.
Temuannya bukan “artikel kurang panjang”. Hipotesis yang lebih tepat adalah informasi utama bergantung pada interaksi. Perbaikan yang diusulkan: tampilkan identitas dan informasi produk umum sejak halaman dibuka, lalu gunakan pilihan cabang untuk memperbarui stok lokal.
Google menyatakan crawler umumnya tidak menjalankan interaksi pengguna seperti menekan tombol untuk memuat daftar berikutnya. Karena itu, jalur penemuan dan isi utama perlu diperiksa terpisah dari fungsi interaktif. Panduan pemuatan konten bertahap.
Ubah temuan menjadi tiket yang bisa dikerjakan
Salin format berikut untuk satu masalah:
| Field | Isi contoh ilustratif |
|---|---|
| URL terdampak | /produk/cat-air-24/ |
| Pembanding | /produk/pensil-12/ |
| Gejala | Detail cat air belum hadir sebelum pilih cabang |
| Bukti | HTML dan DOM tanpa interaksi hanya berisi pemilih lokasi |
| Dugaan penyebab | Pemanggilan data utama berada pada event pilihan cabang |
| Perubahan yang diminta | Informasi umum produk hadir saat URL dibuka langsung |
| Kriteria selesai | Nama, deskripsi, dan link produk terbaca tanpa memilih cabang |
| Pemeriksaan lanjutan | Stok per cabang tetap benar; ulang inspeksi setelah rilis |
Bukti teknis dan dugaan penyebab sengaja dipisahkan. Developer dapat membuktikan dugaan tersebut salah tanpa harus menyangkal gejala yang memang terlihat.
Periksa hasil pada tiga tingkat
Pertama, periksa implementasi: apakah HTML, respons, dan navigasi berubah sesuai kebutuhan? Kedua, periksa fungsi pengguna: apakah pilihan cabang, harga, dan pembelian tetap benar? Ketiga, amati pemrosesan mesin pencari pada waktu berikutnya.
Perbaikan kode yang sudah terpasang tidak langsung menjadi bukti indexing. Sebaliknya, data indeks lama tidak otomatis membatalkan hasil live yang menunjukkan masalah teknis telah diperbaiki. Simpan tanggal masing-masing bukti supaya keduanya tidak tercampur.
Jika akses Search Console belum ada, kamu masih bisa mengumpulkan bukti respons, isi, dan navigasi. Nyatakan status indeks belum diperiksa. Hindari menggantinya dengan hitungan hasil site: seolah itu inventaris lengkap.
Mulai dari satu URL penting yang gejalanya paling jelas. Selesaikan rantai bukti sampai kamu dapat menjelaskan: apa yang terhambat, perubahan apa yang dibutuhkan, dan bukti apa yang akan menunjukkan bahwa pekerjaan tersebut selesai.
