Cara Mengatasi Peringatan Hacked Content di Search Console Setelah Website Dibersihkan

Halaman depan sudah kembali normal, URL asing yang sempat terlihat sudah tidak bisa dibuka, tetapi Google Search Console masih menampilkan “Hacked content”. Pada tahap ini banyak pemilik website merasa pembersihan sebelumnya gagal, lalu mengirim review berkali-kali atau justru menghapus sisa bukti yang masih dibutuhkan untuk menemukan sumber masalah. Keduanya bisa memperpanjang pemulihan.

Jawaban singkatnya: jangan ajukan review hanya karena satu halaman tampak bersih. Buka Security issues report, catat semua jenis temuan dan URL contoh, pastikan akar masalah serta persistence sudah ditutup di seluruh situs, uji hasilnya, baru minta satu review yang menjelaskan tindakan dan buktinya. Google sendiri meminta pemilik memperbaiki semua isu yang tercantum pada seluruh halaman yang terdampak dan menjelaskan apa yang diperbaiki serta hasilnya.

Panduan ini khusus membahas tahap setelah cleanup: cara memastikan situs memang siap diperiksa ulang. Jika Anda belum tahu apakah situs diretas atau belum memiliki rencana pembersihan, mulai dari panduan website kena hack dan urutan penanganannya. Jangan menganggap status review sebagai pengganti investigasi teknis.

Pastikan dulu jenis peringatan yang sedang Anda lihat

Istilah “peringatan Google” sering dipakai untuk beberapa hal berbeda. Bedakan sumbernya sebelum memilih tindakan:

• Security issues report di Search Console menunjukkan temuan keamanan yang Google identifikasi, seperti hacked content, malware, atau social engineering. Inilah tempat pemilik properti melihat contoh URL, penjelasan isu, dan—setelah perbaikan—meminta review.
• Peringatan Safe Browsing di browser adalah peringatan yang mungkin tampil saat seseorang membuka URL tertentu. Google menjelaskan bahwa warning Safe Browsing dapat berbeda menurut konteks penjelajahan; pemilik kadang tidak bisa mereproduksinya sendiri. Untuk memeriksa temuan keamanan situs yang dilaporkan, gunakan Security issues report sebagai rujukan utama.
• Manual action adalah laporan terpisah tentang kebijakan Search, bukan sinonim dari hacked content. Periksa halaman Manual actions jika memang ada pemberitahuan di sana; jangan mengirim permintaan dari menu yang salah.
• Page indexing, hasil site:, atau URL yang masih terlihat di Google tidak dengan sendirinya membuktikan bahwa Security issues report masih aktif. Pembersihan server, status keamanan, dan pemrosesan indeks adalah proses berbeda.

Buka Security issues report pada properti Search Console yang tepat. Pastikan Anda memilih domain atau prefix yang mencakup URL terdampak, termasuk subdomain yang digunakan. Jika Anda mengelola beberapa properti, jangan berasumsi report pada satu properti mewakili semua host.

Mengapa peringatan belum hilang setelah cleanup?

Status yang masih muncul tidak selalu berarti tombol review rusak. Ada beberapa kemungkinan yang perlu dibedakan:

1. Cleanup baru menyentuh contoh URL. Google menegaskan daftar URL dalam laporan hanyalah sampel dan tidak selalu lengkap. Ada kemungkinan pola serupa masih aktif di halaman, direktori, atau subdomain lain.
2. Gejala dibuang, tetapi sumbernya masih ada. Menghapus satu post, redirect, atau file belum menutup akun yang membuatnya, plugin rentan, backdoor, task terjadwal, atau aturan server yang menyisipkan ulang konten.
3. Ada lebih dari satu jenis isu. Misalnya, hacked content dan social engineering dapat muncul bersama. Mengatasi satu kategori saja tidak menyelesaikan kategori lainnya.
4. Perbaikan belum diuji dari sisi pengunjung. Halaman mungkin tampak normal bagi administrator yang login tetapi masih memberikan konten, redirect, atau skrip berbahaya kepada pengunjung anonim.
5. Review masih berjalan atau belum menghasilkan keputusan. Search Console memberi konfirmasi saat permintaan diterima dan mengabarkan hasil melalui email. Google menyebut peninjauan dapat memerlukan beberapa hari atau minggu; jangan mengirim ulang sebelum keputusan atas permintaan yang sedang berjalan.
6. Yang tersisa adalah hasil pencarian lama, bukan temuan aktif yang sama. URL atau snippet yang masih terlihat perlu ditangani sebagai persoalan indeks dan respons URL, tidak otomatis dengan mengulang security review.

Kalau gejala awal berupa halaman judi, redirect tersembunyi, akun asing, atau perubahan file, cocokkan temuan dengan tanda website terkena malware judol. Jika yang Anda temukan hanya komentar dari pengguna, bedakan dari kompromi; spam komentar dan post asing di WordPress membahas perbedaan tersebut.

Tahap 1: simpan bukti dan catat cakupan temuan

Sebelum menyentuh server lagi, simpan catatan minimum yang membuat pekerjaan dapat diulang dan diaudit:

• nama properti Search Console, waktu pemeriksaan, kategori temuan, status, tanggal deteksi yang ditampilkan, dan URL contoh;
• tangkapan layar report serta email notifikasi yang berkaitan;
• salinan file dan database pada kondisi saat ini, disimpan terpisah dari server produksi;
• waktu cleanup, backup yang dipakai, komponen yang diubah, akun yang ditinjau, dan hasil tiap pemeriksaan;
• catatan hosting, log web, dan perubahan DNS/CDN yang tersedia sesuai kebijakan penyedia.

Simpan bukti secara aman: backup yang masih terinfeksi jangan dipulihkan ke situs publik dan jangan dibagikan lewat tautan terbuka. Catat zona waktu dan siapa yang melakukan perubahan. Jika Anda sudah menyerahkan cleanup ke developer atau penyedia hosting, minta ringkasan teknis berisi apa yang ditemukan dan apa yang diganti, bukan hanya pesan “situs sudah dibersihkan”.

Jangan menjalankan pemindaian destruktif atau menghapus log secara massal hanya untuk membuat folder tampak bersih. Jika hosting telah mengarantina file, koordinasikan cara mengambil salinannya sebelum karantina dihapus. Panduan backup website dan uji pemulihan membantu menyiapkan salinan yang dapat digunakan tanpa menghapus satu-satunya bukti.

Tahap 2: baca semua isu dan contoh URL, bukan hanya label di atas

Pada Security issues report, perluas setiap kategori. Baca deskripsi resmi dan contoh URL yang diberikan. Buat tabel sederhana dengan kolom: kategori, URL contoh, status HTTP saat diuji, lokasi sumber yang ditemukan, tindakan, dan hasil verifikasi. Daftar Google bersifat contoh, jadi lengkapi sendiri inventarisnya.

Cari pola dari beberapa sumber yang Anda kuasai: sitemap yang dihasilkan situs, log akses, post/page dan custom post type di WordPress, file yang berubah, aturan redirect, serta URL asing yang ditemukan dalam Search Console atau laporan hosting. Pencarian site:domainanda.tld dapat memberi petunjuk, tetapi tidak menampilkan seluruh URL. Jangan menyimpulkan situs aman hanya karena pencarian tersebut kosong.

Untuk tiap URL contoh, pastikan apakah konten memang tidak pernah Anda buat, pernah ada secara sah, atau dibuat pengguna melalui fitur publik. Jika merupakan konten sah yang sempat berubah, pulihkan konten yang benar dari salinan tepercaya. Jika URL tidak pernah sah dan tidak memiliki pengganti yang setara, pastikan server memberi respons yang benar—umumnya 404 atau 410 setelah sumber dihapus. Jangan menutupi halaman dengan robots.txt; crawler yang diblokir mungkin tidak dapat melihat status halaman yang seharusnya.

Tahap 3: buktikan bahwa akar masalah dan persistence ditutup

Pemeriksaan ini bukan sekadar “scan hijau”. Cari bagaimana konten masuk dan apa yang dapat membuatnya kembali:

1. Identitas dan akses: cocokkan seluruh administrator, editor, akun hosting, SFTP/SSH, email pemulihan, akun CDN, serta integrasi API. Cabut yang tidak sah setelah kepemilikannya dipastikan; rotasi akses dari perangkat yang aman.
2. WordPress core, plugin, dan theme: pastikan komponennya berasal dari sumber tepercaya dan versinya didukung. Periksa file yang diubah dan komponen yang tidak dikenal. Checksum core atau plugin resmi berguna sebagai satu sinyal, tetapi tidak memeriksa semua theme kustom, plugin berbayar, database, atau konfigurasi server.
3. File dan konfigurasi: tinjau direktori upload, must-use plugin, theme aktif, wp-config.php, .htaccess atau aturan server setara, dan task terjadwal. Cari perubahan yang tidak dikenal dengan membandingkan salinan bersih; jangan menghapus file hanya karena nama atau satu fungsi terlihat asing.
4. Database dan konten: periksa post, page, draft, opsi, widget, dan redirect yang berkaitan dengan URL terdampak. Untuk query berisiko, gunakan salinan staging atau backup; jangan mengedit database produksi langsung tanpa prosedur rollback.
5. Celah masuk: catat versi atau kredensial yang dipakai penyerang, perbarui komponen rentan, hapus plugin yang tidak digunakan, perbaiki izin akses, dan batasi akun berhak tinggi sesuai kebutuhan.
6. Uji sebagai pengunjung: buka halaman dari sesi anonim dan beberapa jenis perangkat yang relevan. Periksa URL contoh dan pola URL terkait, respons HTTP, redirect, form, serta halaman penting. Uji URL menggunakan URL Inspection untuk melihat fetch dan render Google, tetapi jangan menganggap satu live test sebagai pemindaian keamanan lengkap.

Kalau bukti menunjukkan kredensial bocor, mengganti password WordPress saja tidak cukup. Periksa sesi aktif, application password, token integrasi, email admin, akses hosting, dan rahasia yang disimpan di deployment. Tutup akses lama sebelum mengaktifkan kembali integrasi yang memang diperlukan.

Tahap 4: tentukan kapan situs siap meminta review

Sebelum menekan Request Review, gunakan gate berikut:

• semua kategori keamanan yang tercantum sudah ditangani;
• bukan hanya URL contoh—pola dan kemungkinan salinan di seluruh situs sudah ditelusuri;
• entry point dan persistence yang ditemukan sudah ditutup;
• perubahan sudah diuji dari luar akun administrator;
• URL yang dihapus tidak menyajikan konten phishing atau hacked content melalui cache, subdomain, variasi path, atau redirect;
• bukti perbaikan dan pemantauan pasca-cleanup tersedia;
• pihak yang punya akses—pemilik, developer, host, CDN—menyepakati tidak ada perubahan lain yang dapat mengembalikan konten.

Jika satu butir belum pasti, tahan pengajuan dan lengkapi diagnosis. Tujuannya bukan membuat jawaban terlihat meyakinkan, melainkan mengirim permintaan setelah situs benar-benar diperbaiki. Mengirim review terlalu dini dapat berakhir dengan penolakan dan membuat langkah berikutnya lebih lambat.

Cara menulis permintaan review yang berguna

Ajukan dari Security issues report, bukan dari fitur yang kebetulan juga berlabel “request”. Uraikan tiga hal:

1. Masalah yang dilaporkan: sebut kategori dan bagian situs yang diperiksa; jangan mengklaim seluruh domain bersih jika hanya beberapa URL yang diuji.
2. Perbaikan yang dilakukan: jelaskan sumber yang ditemukan, bagaimana sumber/persistence ditutup, komponen atau kredensial apa yang diperbaiki, dan bagaimana konten terdampak dibersihkan.
3. Hasil yang diverifikasi: sebutkan jenis pengujian yang dilakukan dan bahwa URL terdampak sudah tidak menyajikan konten berbahaya. Hindari mengirim data pelanggan, password, token, atau detail internal yang tidak diminta.

Gunakan pernyataan faktual, bukan klaim “semua aman selamanya”. Jangan menjanjikan tanggal warning hilang. Setelah pengajuan, simpan konfirmasi, pantau email pemilik properti dan report, dan tunggu keputusan sebelum mengirim ulang. Bila permintaan ditolak, baca alasan atau kategori yang masih tercatat, kembali ke diagnosis, lalu ajukan lagi hanya setelah pekerjaan tambahan selesai.

Perlukah memakai Removals agar URL hilang dari Google?

Kadang ada alasan kuat untuk sementara menyembunyikan URL phishing yang sensitif dari hasil Google. Removals tool dapat memblokir hasil secara sementara untuk properti yang Anda miliki, tetapi bukan cara membersihkan server dan bukan pengganti review keamanan. Google menyatakan pemblokiran itu bersifat sementara, kira-kira enam bulan, dan URL dapat muncul lagi jika sumbernya masih tersedia.

Urutannya tetap: hilangkan atau amankan konten di origin, berikan respons URL yang benar, lalu gunakan Removals sebagai langkah darurat indeks bila memang diperlukan. Jangan memblokir seluruh situs atau menggunakan removal untuk menutupi URL aktif yang belum dibersihkan. Untuk warning Safe Browsing, cek juga status situs Google Safe Browsing; jangan menyamakan status ini dengan Security issues report.

Kesalahan yang paling sering mengulang masalah

• Mengajukan review setelah hanya membersihkan homepage. Bot dan pengunjung dapat mengakses URL lain tanpa melewati homepage.
• Menghapus URL di Google, bukan sumbernya. Hasil sementara mungkin hilang, tetapi halaman atau redirect tetap aktif di server.
• Menghapus post tetapi tidak memeriksa akun pembuatnya. Akses penyerang masih dapat membuat konten baru.
• Menganggap daftar URL contoh lengkap. Gunakan sampel sebagai petunjuk, lalu cari pola di file, database, log, sitemap, dan subdomain.
• Memasang scanner tanpa menguji temuan. Tool dapat melewatkan persistence atau menghasilkan false positive; hasilnya perlu ditinjau oleh orang yang memahami situs.
• Mengirim permintaan review berulang saat masih diproses. Tunggu keputusan dan ikuti status yang dikirim Google.
• Mengklaim waktu pemulihan atau posisi pencarian. Review, crawling, dan pemrosesan indeks berada di luar kendali vendor.

Pencegahan setelah warning dicabut

Status report yang bersih adalah satu checkpoint, bukan jaminan tidak akan diserang lagi. Tetapkan pemilik untuk setiap akses administrator; gunakan autentikasi kuat dan MFA bila tersedia; cabut integrasi yang tak dipakai; jadwalkan pembaruan komponen dengan backup serta pengujian; dan simpan backup di lokasi terpisah yang rutin diuji. Pantau akun, file, perubahan DNS, dan pemberitahuan hosting. Pastikan email Search Console dibaca oleh lebih dari satu kontak tepercaya sehingga peringatan tidak terlewat ketika satu PIC tidak aktif.

Buat daftar URL penting dan kondisi normalnya: status HTTP, tujuan redirect, dan halaman yang harus ada. Dengan baseline ini, perubahan tak wajar lebih mudah diketahui. Untuk langkah proteksi WordPress harian, lanjutkan ke panduan mengamankan WordPress untuk bisnis.

Kapan perlu meminta bantuan

Eskalasi sebelum mengajukan review jika Anda tidak memiliki salinan yang aman, akses host dibatasi, perubahan muncul kembali setelah dibersihkan, database atau akun admin menunjukkan pola yang tidak dipahami, atau situs menyajikan phishing/malware kepada pengunjung. Untuk toko online, formulir, atau situs yang memproses data pelanggan, jangan mematikan seluruh sistem atau mengubah data produksi tanpa rencana pemulihan dan pihak yang berwenang.

Rawat Web menyediakan diagnosis awal melalui Bantuan Website Darurat dan Audit Gratis. Kirim URL serta gejala yang terlihat terlebih dahulu; diagnosis awal tidak memerlukan penyerahan akses. Jika pekerjaan diperlukan, cakupan dan biayanya dibicarakan sebelum perubahan. Kami dapat membantu menginventarisasi temuan, membersihkan file/database, menutup celah, dan memeriksa hasil, tetapi tidak menjanjikan kapan Google menyelesaikan review atau kapan hasil pencarian berubah.

Pertanyaan umum

Apakah peringatan hacked content akan hilang otomatis setelah file dihapus?

Belum tentu. Security issues report harus mencerminkan perbaikan dan semua temuan harus ditangani. Periksa seluruh isu dan URL, tutup penyebabnya, lalu gunakan Request Review jika report meminta review. Penghapusan file yang tampak tidak membuktikan tidak ada salinan atau persistence.

Apakah saya harus mengirim Request Review berkali-kali?

Tidak saat permintaan sebelumnya masih berjalan. Simpan konfirmasi dan tunggu hasil melalui email atau Search Console. Jika ditolak, gunakan alasan atau temuan yang masih tersisa untuk menentukan pekerjaan tambahan, baru ajukan kembali setelah perbaikan selesai.

Apakah URL yang masih muncul di Google berarti hack belum dibersihkan?

Tidak selalu. Bisa ada jeda antara kondisi server dan hasil indeks. Verifikasi URL di server dan Security issues report; gunakan URL Inspection atau Removals sesuai tujuan. Jangan menyimpulkan status keamanan hanya dari pencarian site:.

Bolehkah saya memakai Removals sebelum cleanup selesai?

Hanya sebagai tindakan sementara yang memang diperlukan untuk membatasi paparan hasil Google, bukan sebagai perbaikan. Hapus atau amankan sumber di server dan tutup celahnya; pemblokiran Search Console sendiri tidak membersihkan konten.