Habis deploy update copy di sebuah situs booking WordPress yang saya bangun, saya melakukan hal yang saya selalu lakukan: cek hasilnya dari terminal sebelum percaya screenshot. Buka browser itu lambat, curl itu instan. Jadi saya jalankan:
curl https://old-site.com/listings/ | head -n 40Yang muncul bikin saya mengerutkan dahi. Bukan markup yang saya harapkan, tapi kerangka kosong: div pembungkus tanpa isi, beberapa atribut data- yang aneh, dan placeholder di tempat yang seharusnya ada teks hero, daftar listing, dan deskripsi. Di mata terminal, halaman itu terlihat rusak total. Konten yang baru saja saya deploy seolah hilang.
Refleks pertama saya jelek: saya pikir deploy-nya gagal, atau ada PHP fatal yang men-strip output. Saya cek error_log, bersih. Saya buka halaman yang sama di browser asli, dan semuanya tampil sempurna. Teks hero ada, semua listing ada, deskripsinya ada. Jadi halaman itu baik-baik saja untuk manusia, tapi bohong di terminal. Itu kombinasi yang khas, dan begitu saya ingat situs ini pakai WP Rocket, teka-tekinya langsung terurai.
Kenapa ini terjadi
WP Rocket punya beberapa optimasi yang menunda kerja sampai halaman benar-benar dipakai di browser: lazy-render dan delay JavaScript. Idenya bagus untuk performa. Alih-alih mengirim seluruh DOM dan langsung mengeksekusi semua skrip, WP Rocket menyajikan payload yang lebih ramping dan membiarkan browser meng-hidrasi sisanya begitu ada interaksi atau begitu elemen masuk viewport. Yang penting di sini: keputusan apa yang akan dikirim itu sebagian bergantung pada user-agent.
curl polos mengirim user-agent seperti curl/8.4.0. Buat WP Rocket, itu UA asing yang tidak dikenali, bukan browser. Jadi yang saya terima adalah versi reduced dari halaman: konten yang seharusnya di-hidrasi belakangan ditunda, dan yang tersisa hanya kerangka placeholder. Bukan deploy yang gagal, bukan PHP fatal. Saya cuma memprobe situs yang teroptimasi dengan alat yang tidak menyamar sebagai pengunjung asli, lalu menyimpulkan dari payload yang memang sengaja dibuat tidak lengkap.
Begitu cara berpikirnya klik, semuanya masuk akal. Browser dapat versi lengkap karena dia memang browser. curl dapat versi tulang karena dia bukan. Tidak ada satu pun yang "rusak". Yang rusak cuma asumsi saya bahwa curl melihat apa yang dilihat pengunjung.
Perbaikannya
Solusinya bukan mematikan WP Rocket. Solusinya adalah memprobe situs dengan cara yang melihat apa yang pengunjung dan Google benar-benar terima. Ada beberapa jalan.
Yang paling cepat: tetap pakai curl, tapi kirim user-agent yang dikenali. Saya paling sering pakai UA Googlebot, karena yang ingin saya tahu adalah apa yang dilihat crawler:
curl -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' https://old-site.com/listings/Dengan UA itu, payload yang balik langsung berisi markup penuh: teks hero, semua listing, deskripsinya. Persis seperti di browser. Sekarang saya bisa percaya grep saya lagi.
Kalau saya butuh kepastian seperti apa yang user betulan lihat, saya pakai browser asli, biasanya lewat headless atau Playwright. Itu menjalankan JavaScript, men-trigger hidrasi, dan memberi DOM final yang sesungguhnya, bukan cuma respons mentah server.
Ada juga trik diagnostik yang berguna untuk membedakan masalah WP Rocket dari masalah konten asli. Tambahkan ?nowprocket di URL untuk melewati WP Rocket sepenuhnya untuk request itu:
curl 'https://old-site.com/listings/?nowprocket'Kalau dengan ?nowprocket halaman tampil penuh tapi tanpa flag tampil kosong, sudah pasti pelakunya WP Rocket, bukan PHP atau template kamu.
Jebakan bonus: cache HTML tidak ikut purge
Saat menelusuri ini, saya kena satu jebakan lagi yang patut dicatat. Saya kira menaikkan ?ver= di asset yang berubah sudah cukup untuk memaksa konten baru tampil. Itu salah. Menaikkan query string ?ver= di sebuah asset tidak mem-purge cache halaman HTML milik WP Rocket. ?ver= cuma cache-bust file CSS atau JS itu sendiri; HTML yang dirender server tetap disajikan dari cache lama.
Jadi setiap kali saya deploy perubahan yang menyentuh copy yang dirender server, saya purge cache WP Rocket secara manual setelahnya. Kalau tidak, pengunjung, dan saya yang sedang verifikasi, akan terus melihat HTML lama meskipun PHP-nya sudah menghasilkan yang baru.
Pelajaran
curl polos itu probe yang menyesatkan di situs WordPress yang teroptimasi. Dia tidak berbohong soal byte yang dikirim server, tapi byte itu sengaja berbeda untuk user-agent asing. Kalau kamu ingin melihat apa yang pengunjung dan Google betul-betul dapat, samakan user-agent dengan yang asli, idealnya Googlebot, atau langsung pakai browser sungguhan. Dan ingat bahwa cache di WordPress berlapis: cache-bust asset dan cache halaman HTML itu dua hal terpisah, jadi purge HTML secara eksplisit setelah deploy yang mengubah copy server-rendered. Sejak itu, saya berhenti panik melihat terminal kosong dan mulai bertanya dulu: siapa yang sedang saya pura-purakan?