Kalau kamu menerima notifikasi Manual Actions atau Security Issues, buka laporan yang bersangkutan dan catat masalah yang benar-benar dinyatakan. Mengganti judul halaman, mengirim sitemap berulang, atau meminta indexing belum tentu menjawab notifikasi tersebut.
Saya memisahkan pekerjaan menjadi klasifikasi laporan, penanganan penyebab, pembuktian perbaikan, lalu pengajuan review. Urutan ini membantu pemilik website mengoordinasikan pekerjaan tanpa mengambil alih tugas teknis yang belum dikuasainya.
Pastikan laporan dan properti yang sedang ditangani
Masuk melalui alamat Search Console yang kamu kenal, pilih properti yang sesuai, lalu buka Manual Actions dan Security Issues. Simpan jenis masalah, tanggal laporan, pola URL atau contoh yang diberikan, serta status pengajuan review sebelumnya.
Jangan menyamakan subdomain, versi host, atau properti situs lain. Catatan dari properti yang salah akan membuat tim memeriksa URL yang tidak menjelaskan notifikasi. Simpan pula pesan asli supaya istilah laporan tidak berubah menjadi dugaan selama diteruskan ke tim.
Manual action berasal dari penilaian manusia di Google terhadap pelanggaran kebijakan, umumnya berkaitan dengan spam. Dampaknya dapat berupa penurunan peringkat atau penghilangan halaman dari hasil pencarian. Penurunan trafik saja tidak membuktikan adanya manual action. Penjelasan Manual Actions Google.
Pilih jalur berdasarkan masalahnya
| Keadaan laporan | Jalur kerja utama | Hasil yang perlu disiapkan |
|---|---|---|
| Manual Actions berisi pelanggaran | Perbaikan sesuai kebijakan yang disebut | Bukti pelanggaran telah ditangani pada cakupan terkait |
| Security Issues berisi temuan | Penanganan keamanan sesuai jenis temuan | Bukti pembersihan, perbaikan penyebab dan pengujian |
| Kedua laporan berisi temuan | Dua jalur yang dikoordinasikan | Bukti serta status review masing-masing |
| Laporan kosong, tetapi perilaku mencurigakan masih terjadi | Investigasi teknis dan keamanan | Konfirmasi masalah melalui bukti tambahan |
Security Issues melaporkan indikasi peretasan atau perilaku yang dapat membahayakan pengunjung, seperti phishing dan malware. Sebagian temuan dapat memunculkan peringatan di pencarian atau browser. Contoh URL yang diberikan merupakan sampel; tidak adanya contoh pada suatu temuan bukan berarti tidak ada halaman terdampak. Dokumentasi Security Issues.
Tabel ini bukan cara menentukan sendiri bahwa sebuah situs diretas. Lonjakan URL asing, perubahan bahasa yang tidak dikenal, atau redirect aneh perlu diperiksa. Satu gejala belum menjelaskan penyebab, dan laporan kosong bukan pengganti pemeriksaan keamanan.
Tentukan siapa menangani bagian apa
Pemilik website menyiapkan akses yang sesuai, menetapkan penanggung jawab, dan memastikan keputusan operasional tercatat. Tim SEO membantu memahami laporan, memetakan URL, memeriksa dampak pada halaman publik, serta mengumpulkan bukti untuk review.
Developer, pengelola hosting, atau spesialis keamanan menangani kode yang disusupi, akun yang disalahgunakan, kerentanan, dan pemulihan sistem. Jika ada dugaan pengunjung masih berisiko, koordinasikan pembatasan bagian yang terdampak dengan tim tersebut. Jangan menunda penanganan risiko hanya untuk mempertahankan trafik.
Google menyarankan melibatkan host dan bantuan profesional ketika kemampuan membaca kode atau konfigurasi server belum memadai. Panduan membangun tim pemulihan. Untuk dugaan infeksi, hindari membuka halaman berbahaya langsung di browser kerja; gunakan proses pemeriksaan yang ditangani tim teknis. Panduan diagnosis pada Security Issues.
Perbaiki pola penyebab, bukan hanya URL contoh
Bayangkan kasus ilustratif pertama: laporan Manual Actions menunjukkan spam buatan pengguna pada forum. Tim menemukan komentar promosi yang tidak relevan pada beberapa URL contoh. Pekerjaan belum selesai hanya dengan menghapus komentar itu jika pola yang sama masih ada di bagian forum lain.
Tim perlu memeriksa cakupan yang terkait, memperbaiki materi yang melanggar, dan meninjau proses moderasinya. Google meminta penyelesaian masalah pada seluruh halaman terdampak serta seluruh manual action yang tercantum sebelum pengajuan review. Langkah penanganan manual action.
Kasus ilustratif kedua: Security Issues menunjukkan URL injection pada halaman yang tidak pernah dibuat pemilik. Tim keamanan mengonfirmasi sumber pembentukan URL, membersihkan perubahan tidak sah, dan memperbaiki celahnya. Tim SEO kemudian memeriksa pemisahan antara halaman sah yang dipulihkan dan URL spam baru yang dihapus.
Memulihkan backup tanpa memperbaiki penyebab dapat meninggalkan peluang masalah berulang. Panduan pemulihan Google mencakup pemeriksaan backup yang bersih, penghapusan konten penyerang, dan perbaikan kerentanan. Pembersihan dan pemeliharaan situs.
Gunakan log remediasi yang bisa diperiksa
Simpan bukti dalam ruang kerja dengan akses terbatas. Hindari menaruh kredensial, data pelanggan, atau salinan berbahaya pada dokumen publik. Untuk setiap kelompok masalah, gunakan kolom berikut:
| Kolom | Isi yang dibutuhkan |
|---|---|
| Identitas temuan | Laporan, kategori, tanggal, pola atau sampel URL |
| Cakupan | Bagian yang sudah diperiksa dan bagian yang masih belum jelas |
| Penyebab | Temuan terkonfirmasi, dipisahkan dari dugaan |
| Perubahan | Apa yang dilakukan, kapan, dan oleh siapa |
| Bukti sesudahnya | Hasil uji yang sesuai jenis masalah |
| Pencegahan | Perbaikan proses atau sistem yang relevan |
| Status review | Belum diajukan, sedang ditinjau, atau keputusan diterima |
Contoh catatan yang terlalu lemah adalah “plugin sudah diperbarui, situs aman”. Catatan yang lebih berguna menjelaskan komponen yang diperbaiki, kaitannya dengan temuan, ruang yang diperiksa ulang, dan keterbatasan pemeriksaan. Gunakan bukti yang benar-benar tersedia; jangan mengisi penyebab hanya agar tabel terlihat lengkap.
Periksa kesiapan sebelum meminta review
Pastikan semua kategori laporan sudah ditangani. Periksa ulang URL contoh dan pola yang lebih luas. Untuk halaman sah yang ingin dipertahankan, pastikan konten serta aksesnya sudah sesuai. Pisahkan URL spam yang dihapus dari halaman sah yang sebelumnya disusupi.
Dalam kasus manual action, Google perlu dapat memeriksa halaman terkait setelah perbaikan. Jangan menyembunyikan pelanggaran yang masih ada hanya dengan memblokir akses. Persiapan review Manual Actions.
Susun ringkasan pengajuan dari log: masalah yang ditemukan, cakupan pemeriksaan, tindakan yang selesai, dan hasil pengujiannya. Contoh permintaan review yang baik adalah laporan perbaikan yang dapat dinilai. Ia tidak membutuhkan cerita keberhasilan, alasan panjang, atau janji yang belum dikerjakan.
Ajukan melalui laporan yang sesuai setelah perbaikan teruji. Jika kedua laporan aktif, pantau keduanya. Pengajuan untuk satu jalur tidak menjadi bukti bahwa temuan pada jalur lain sudah ditangani.
Pantau keputusan dan kondisi situs secara terpisah
Simpan konfirmasi pengajuan, lalu tunggu keputusan atas permintaan yang masih aktif sebelum mengirim ulang. Google menjelaskan bahwa proses review dapat memerlukan waktu; status diterima untuk ditinjau belum berarti masalah sudah dinyatakan selesai. Proses review Manual Actions, proses review Security Issues.
Jika permintaan ditolak, baca temuan yang masih disebut dan perbarui log berdasarkan pemeriksaan baru. Jangan mengirim teks yang sama tanpa perubahan bukti. Jika diterima, lanjutkan pemantauan agar pola yang telah diperbaiki tidak muncul kembali.
Catat tiga hasil berbeda: implementasi perbaikan, keputusan laporan, dan perkembangan pencarian setelahnya. Ketiganya memiliki bukti serta waktu pengamatan masing-masing. Hilangnya notifikasi tidak otomatis membuktikan semua peringkat kembali, sebagaimana angka trafik belum dapat menggantikan verifikasi bahwa penyebab masalah sudah ditangani.
