Beberapa waktu lalu ada klien yang menghubungi saya. Situsnya tiba-tiba anjlok dari hasil pencarian dan traffic turun drastis tanpa sebab yang jelas. Tidak ada perubahan konten besar, tidak ada penalti yang terlihat, tapi angkanya terus merosot. Klien memutuskan meminta saya turun tangan untuk audit menyeluruh, baik dari sisi teknikal maupun SEO.

Langkah pertama yang saya lakukan seperti biasa, masuk ke Google Search Console untuk melihat kondisi indeks dan riwayat performa situs. Di situlah saya menemukan sesuatu yang tidak semestinya ada.

Notifikasi yang Bikin Curiga

Saat membuka properti situs klien di Search Console, saya menemukan sebuah pemilik baru sudah ditambahkan ke properti tersebut. Klien memastikan dia tidak pernah menambahkan siapa pun. Alamat email yang tertera juga sama sekali tidak dikenali.

Berikut tampilan notifikasi yang saya temukan waktu itu.

Kenapa Status Pemilik di Search Console Itu Serius

Banyak pemilik situs menganggap Search Console cuma dashboard untuk melihat statistik pencarian. Padahal status pemilik di sana setara akses penuh. Orang yang berhasil terverifikasi sebagai pemilik bisa mengubah setelan penting yang memengaruhi cara Google berinteraksi dengan situs, mulai dari submit sitemap, meminta halaman dihapus dari indeks, mengelola pengguna lain, sampai mengarahkan situs untuk trik black hat SEO tanpa pemilik asli sadar sampai peringkatnya sudah anjlok.

Yang membuat saya waspada, verifikasi kepemilikan di Search Console bisa lewat beberapa jalur berbeda: file HTML di server, meta tag di halaman, DNS TXT record, atau akun Google Analytics dan Tag Manager yang terhubung. Kalau salah satu jalur itu pernah dipasang lalu tidak pernah dibersihkan, atau bocor lewat akses yang tidak seharusnya, orang lain bisa memanfaatkannya untuk memverifikasi diri sebagai pemilik baru tanpa sepengetahuan siapa pun.

Menelusuri Lebih Dalam, Ternyata Ada Backdoor

Saya cabut akses email asing itu dari Search Console, tapi saya tidak berhenti di situ. Munculnya pemilik baru yang tidak dikenal biasanya bukan akar masalah, melainkan gejala dari masalah yang lebih dalam. Saya lanjutkan penelusuran ke seluruh file website lewat file manager hosting dan bandingkan dengan struktur file WordPress yang seharusnya.

Benar saja, saya menemukan backdoor yang sudah disusupkan ke salah satu file di tema aktif. Potongan kode itu berbentuk fungsi yang dieksekusi dari string terenkode, pola klasik yang sering dipakai untuk menyembunyikan perintah jahat dari pemeriksaan sekilas.

grep -r "eval(base64_decode" /path/to/wp-content --include=*.php

Perintah semacam itu saya pakai untuk menyisir seluruh direktori wp-content dan mencari pola mencurigakan yang umum dipakai backdoor PHP, seperti eval, base64_decode, gzinflate, atau shell_exec yang muncul di file yang seharusnya tidak berisi kode semacam itu. Backdoor inilah yang memberi jalur diam-diam bagi orang luar untuk tetap bisa masuk kapan saja, termasuk memverifikasi diri sebagai pemilik baru di Search Console tanpa perlu login resmi ke WordPress.

Bagaimana Backdoor Semacam Ini Biasanya Masuk

Dari pengalaman menangani kasus serupa, ada beberapa jalur yang paling sering jadi pintu masuk. Plugin atau tema nulled yang diunduh dari luar repository resmi sering kali sudah disisipi kode berbahaya sejak awal. Plugin atau tema resmi yang dibiarkan tidak diperbarui dalam waktu lama juga rawan dieksploitasi lewat celah keamanan yang sudah diketahui publik. Kredensial FTP atau cPanel yang lemah, atau pernah dipakai di perangkat yang tidak aman, juga jadi jalur umum. Terakhir, akun admin WordPress dengan password yang mudah ditebak tetap jadi penyebab paling klasik sampai sekarang.

Langkah Audit Menyeluruh yang Saya Lakukan

Setelah backdoor ditemukan, saya tidak berhenti hanya menghapus satu file itu. Backdoor yang sudah bersarang biasanya meninggalkan lebih dari satu jalur akses, jadi audit perlu menyeluruh. Berikut urutan yang saya lakukan untuk situs klien tersebut.

Saya mulai dengan mengganti seluruh kredensial yang berhubungan dengan situs, mulai dari password WordPress, FTP, cPanel, sampai database. Setelah itu saya audit daftar pengguna WordPress dan hapus akun admin yang tidak dikenali. Saya juga memeriksa seluruh plugin dan tema yang terpasang, membandingkan versinya dengan repository resmi, dan menghapus yang tidak terpakai atau berasal dari sumber tidak jelas.

Langkah berikutnya memeriksa cron job di hosting, karena backdoor kadang membuat jadwal otomatis untuk menyisipkan ulang dirinya sendiri meski file utamanya sudah dihapus. Saya juga memeriksa file .htaccess untuk melihat apakah ada redirect mencurigakan yang disisipkan, lalu memeriksa ulang seluruh jalur verifikasi kepemilikan di Search Console, termasuk DNS TXT record dan file verifikasi HTML lama yang sudah tidak terpakai.

Hasilnya

Setelah backdoor dibersihkan dan situs diaudit menyeluruh, traffic klien berangsur pulih dalam beberapa minggu berikutnya. Yang membuat kasus ini penting untuk dibagikan, semuanya bermula dari satu notifikasi kecil yang mudah diabaikan kalau tidak dipantau rutin.

Kalau Situsmu Menunjukkan Tanda Serupa

Kalau kamu mengelola situs sendiri atau situs klien, ada baiknya cek beberapa hal ini secara berkala. Buka Search Console, masuk ke bagian Setelan lalu Pengguna dan Izin, lihat siapa saja yang berstatus pemilik. Periksa juga daftar pengguna WordPress, plugin dan tema yang terpasang, cron job yang berjalan, dan rekam jejak login yang mencurigakan. Notifikasi seperti pemilik baru di Search Console sering cuma gejala, bukan akar masalah, jadi ganti password saja tidak cukup kalau akses tetap terbuka lewat jalur lain.

Audit keamanan website ini sebenarnya bukan pekerjaan sekali jalan lalu selesai. Sama seperti akses admin lainnya, perlu diperiksa rutin. Sekali lengah, celah kecil yang dibiarkan bertahun-tahun bisa jadi jalan masuk paling gampang bagi pihak yang tidak bertanggung jawab.