Website WordPress Kena Spam Obat, tetapi Homepage Normal: Cara Menyelidiki

Anda mencari nama domain sendiri, lalu melihat URL yang memuat istilah obat, resep, atau apotek yang tidak pernah dibuat. Ketika membuka homepage, website tampak normal. Ini dapat terjadi karena spam disisipkan ke halaman baru atau database, tersembunyi di halaman lain, atau ditampilkan hanya pada kondisi tertentu. Menghapus URL dari Google tanpa mengetahui sumbernya dapat membuat halaman yang sama muncul kembali.

Jawaban singkat: jangan menganggap homepage normal sebagai bukti tidak ada kompromi. Catat contoh URL, status, waktu, serta laporan Search Console; jangan membuka halaman yang mungkin phishing atau mengunduh file berbahaya. Lalu bedakan spam komentar/user-generated dari injeksi oleh penyerang, inventarisasi konten dan akun WordPress, periksa file/redirect/cron/database serta log, dan cari proses yang membuat spam. Bersihkan sumber dan celah lebih dulu; urus index serta review setelah situs benar-benar diverifikasi.

Mengapa homepage bisa terlihat normal?

Spam farmasi bisa ditempatkan pada post/page baru, custom post type, attachment, komentar, opsi database, file template, script, atau URL yang dibentuk oleh rewrite rule. Penyerang mungkin menyajikan konten hanya ketika request datang dari mesin pencari, referrer tertentu, mobile browser, atau pengguna yang belum login. Google menjelaskan hacked content dapat berupa halaman spam baru, konten tersembunyi, injeksi pada halaman existing, atau redirect yang kondisinya bergantung pada referrer, user-agent, dan perangkat (Google Spam policies). Karena itu, tampilan homepage dari akun admin hanya mewakili satu request, bukan seluruh website.

Istilah “spam obat” juga perlu konteks. Toko farmasi atau klinik dapat memiliki konten yang sah; tidak semua halaman berisi kata obat merupakan kompromi. Cari tanda yang lebih kuat: URL atau judul yang tidak dikenal, akun yang membuatnya bukan pemilik konten, redirect asing, link tersembunyi, post dibuat massal, kode yang tidak sesuai, atau Search Console yang mengidentifikasi masalah keamanan. Jangan hapus halaman sah hanya karena istilahnya muncul di hasil pencarian.

Simpan bukti dan batasi risiko pengunjung

Sebelum cleanup, ekspor contoh URL dari Search Console atau laporan pelanggan, catat tanggal dan jam, status halaman, sumber temuan, serta pola URL. Simpan salinan log, database, file, dan konfigurasi yang relevan di lokasi privat. Samarkan data pelanggan, token, cookie, dan alamat email. Jika ada redirect ke situs obat ilegal, phishing, atau malware, minta hosting membatasi akses; jangan meminta pelanggan mengklik URL untuk membuktikannya.

Gunakan browser bersih dan profil tanpa login hanya jika perlu memeriksa URL aman. Jangan mengikuti redirect secara otomatis atau memasukkan kredensial ke halaman asing. Jika laporan menunjukkan risiko transaksi, data pribadi, atau akses administrator hilang, hubungi host dan tim keamanan segera. Simpan snapshot sebelum mengubah .htaccess, plugin, theme, atau database; perubahan yang tidak dicatat membuat akar masalah lebih sulit ditelusuri.

Bedakan user-generated spam dari website yang diretas

1. Periksa tipe kontennya. Spam hanya di komentar dapat berasal dari form publik yang perlu moderasi atau anti-abuse. Post/page baru, akun asing, script tersembunyi, dan redirect lebih kuat mengarah ke kompromi atau akses yang disalahgunakan.
2. Lihat siapa yang membuat objek. Catat post author, user ID, tanggal, status, tipe post, slug, revisi, serta perubahan role. Akun lama pun bisa dibajak; nama yang dikenal bukan bukti aktivitas sah.
3. Bandingkan dengan kanal yang memang boleh menerima konten. Form submission, marketplace, membership, dan integrasi dapat membuat custom post type. Minta pemilik bisnis mengonfirmasi sebelum menghapus data.
4. Periksa semua locale, domain, dan subdomain. Spam dapat muncul di path yang jarang dikunjungi, halaman lama, subdomain campaign, atau versi mobile. Jangan berhenti setelah satu hasil site: menghilang.
5. Tautkan temuan ke log dan akses. Cari request, login, upload, perubahan plugin, cron, atau deploy yang sejalan dengan waktu pembuatan. Jika bukti hanya menunjukkan user-generated content, tangani validasi/moderasi; jika ada indikator akses tidak sah, jalankan respons kompromi.

Google membedakan spam buatan pengguna dari konten yang dipasang tanpa izin akibat kelemahan keamanan. Untuk kasus komentar, lihat juga cara membedakan komentar spam dan kompromi WordPress. Bila tersedia di WP-CLI, perintah read-only seperti wp post list --post_type=any --post_status=any --fields=ID,post_type,post_status,post_title,post_name,post_date dan wp user list --role=administrator dapat membantu inventarisasi; lihat dokumentasi resmi wp post list dan wp user list. Jalankan pada salinan terisolasi dan lindungi output. Jangan langsung menjalankan penghapusan massal.

Audit semua tempat yang dapat menyimpan spam

Konten dan database

Inventarisasi posts, pages, attachments, custom post types, comments, revisions, users, usermeta, options, widgets, menu, dan custom HTML. Cari slug atau judul asing, anchor tersembunyi, script, canonical yang berubah, URL obat yang tidak disetujui, serta konten yang hanya muncul saat template memproses data. Pada database copy, gunakan pencarian yang memahami tabel prefix dan serialized value. Catat ID/field yang cocok; jangan melakukan DELETE umum berdasarkan satu kata karena dapat merusak data sah atau struktur serialization.

File, plugin, dan theme

Bandingkan core dengan checksum resmi melalui wp core verify-checksums dan plugin WordPress.org dengan wp plugin verify-checksums --all bila sesuai. Periksa theme, mu-plugin, drop-in, uploads, file PHP baru/berubah, .htaccess, .user.ini, wp-config.php, serta file pada direktori yang seharusnya hanya berisi media. Checksum tidak mencakup seluruh aplikasi; plugin premium/custom dan database perlu pembanding lain. Untuk file asing di uploads, simpan bukti, jangan buka URL-nya, dan minta host memeriksa apakah path tersebut dapat dieksekusi.

Redirect, cron, dan layanan di luar WordPress

Bandingkan respons langsung dan request dengan konteks yang relevan pada staging; catat header Location tanpa membuka tujuan asing. Periksa CDN/WAF, DNS, server rewrite, service worker, tag manager, scheduled task, WordPress cron, backup job, dan deployment. Gunakan wp cron event list untuk event WordPress, lalu minta host meninjau cron sistem dan log yang tidak dapat Anda akses. Bila redirect muncul hanya dari referrer, jangan membuka tujuan asing; minta hosting meninjau respons pertama dan log edge/origin. Jangan menyimpulkan bahwa seluruh redirect sah hanya karena homepage normal.

Bangun inventaris URL dari beberapa sumber

Mulai dari daftar yang dapat Anda jelaskan: contoh Search Console, sitemap XML, route internal, daftar post/page/custom post type, access log, dan laporan pelanggan. Beri setiap URL status “known-good”, “suspected spam”, “redirect”, atau “not checked”; catat bukti dan pemilik verifikasi. Jangan melakukan crawl agresif pada situs yang sedang overload atau tanpa izin host. Untuk setiap kelompok path, pilih sampel yang berbeda—homepage, URL baru, halaman lama, versi mobile, dan path dengan query—lalu bandingkan response awal tanpa mengikuti tujuan asing.

Perintah inventaris WP-CLI dapat mengeluarkan judul, slug, email, dan ID pengguna. Jalankan hanya oleh operator berwenang di salinan privat, batasi kolom yang dikumpulkan, dan hapus data pribadi dari laporan handoff. Bila konten dibuat oleh integrasi, cocokkan hook, API key, dan pemilik bisnis sebelum menghapus. Jika data tidak cukup untuk membedakan spam dari katalog produk sah, tandai sebagai belum diverifikasi dan minta konfirmasi, bukan menebak.

Hapus spam setelah mekanisme pembuatnya ditutup

Urutan aman biasanya: isolasi URL berbahaya; simpan bukti; cabut akses akun/token/sesi yang tidak sah; perbaiki atau ganti komponen yang menjadi entry point; hilangkan backdoor dan persistence; pulihkan halaman dan option sah dari backup tepercaya; lalu periksa ulang URL dan log. Rotasi password dari perangkat bersih dan jangan lupa kredensial hosting, SSH/SFTP, database, CDN, DNS, serta akun pihak ketiga yang dapat memodifikasi situs.

Periksa apakah konten spam memiliki salinan di cache, CDN, backup, sitemap, feed, search index internal, atau platform lain. Purge cache setelah perbaikan sumber, bukan sebagai pengganti cleanup. Uji beberapa URL dari browser anonim dan perangkat yang berbeda secara terkendali. Jika file atau halaman muncul lagi, cari proses yang membuatnya ulang alih-alih menghapus ulang gejala. Artikel tanda website terkena malware dan cara memulihkan website WordPress yang diretas dapat membantu memperluas respons insiden.

Tangani Google setelah website bersih

Periksa Search Console Security Issues untuk contoh URL dan kategori yang tercatat, serta Manual Actions secara terpisah jika ada notifikasi kebijakan spam. Google menyarankan pemilik menghapus seluruh masalah yang tercantum dan menjelaskan apa yang diperbaiki saat meminta review; review bukan pengganti investigasi (Security Issues report). Jika URL spam masih muncul di hasil pencarian, alat Removals bisa mengurangi visibilitas sementara tetapi tidak menghapus file, post, atau entry point dari website. Setelah sumber bersih, gunakan inspeksi URL, sitemap, dan request indexing sesuai kebutuhan tanpa menjanjikan waktu pemrosesan.

Dokumentasikan jumlah URL yang ditemukan, kategori Search Console, sumber root cause, tanggal patch/restore, kredensial yang dicabut, file/database yang diperiksa, uji redirect, serta temuan yang belum tercakup. Minta review hanya ketika seluruh sampel serta area lain yang berisiko sudah ditangani dan verifikasi dapat diulang. Jika ada temuan baru setelah review, kembali ke penyelidikan; jangan menyembunyikannya dengan removal request.

Pencegahan agar spam tidak terulang

Batasi role dan registrasi publik; wajibkan MFA untuk administrator; hapus akun vendor setelah pekerjaan selesai; update komponen dari sumber resmi; audit plugin/theme yang tidak dipakai; batasi tipe dan izin upload; simpan backup offsite yang rutin diuji; pantau perubahan file dan akun; serta simpan access log di luar folder yang dapat diubah aplikasi. Atur jalur eskalasi hosting dan owner yang dapat menyetujui cleanup. Jika situs menerima komentar atau kiriman publik, gunakan moderasi berbasis risiko dan rate limiting tanpa mematikan fitur bisnis yang sah.

Kesalahan yang sering terjadi

• Menghapus URL Google tetapi membiarkan post, file, redirect, atau akun yang membuat spam tetap aktif.
• Menyimpulkan tidak ada hack karena homepage terlihat normal atau Google tidak menampilkan satu URL tertentu.
• Menghapus semua post yang mengandung istilah farmasi tanpa memastikan konten itu bukan halaman bisnis sah.
• Menganggap setiap komentar spam berarti server diretas, atau sebaliknya menganggap setiap halaman spam sebagai komentar biasa.
• Menjalankan SQL massal pada database live tanpa backup atau pemahaman serialization.
• Meminta review berulang sebelum root cause ditutup, atau menjanjikan kapan indeks akan pulih.

Apakah spam obat di Google membuktikan WordPress diretas? Belum tentu; konten dapat berasal dari kontribusi publik atau sumber sah. Tetapi URL/akun asing, redirect, dan perubahan file/database perlu diperlakukan sebagai indikasi serius sampai diverifikasi.

Mengapa saya tidak melihat spam di homepage? Spam mungkin berada di URL baru, template lain, cache, atau hanya muncul untuk referrer/perangkat tertentu. Homepage adalah satu jalur, bukan inventaris lengkap.

Bolehkah memakai Google Removals dulu? Untuk menahan visibilitas sementara bila sesuai, tetapi bersihkan sumber di website dan tutup celah terlebih dahulu. Removal bukan remediation permanen.

Kapan harus meminta bantuan host? Segera jika ada pengunjung yang dialihkan ke phishing/malware, database atau pembayaran terdampak, file kembali setelah dihapus, atau Anda tidak memiliki akses log dan tidak dapat mengisolasi situs.

Jika halaman farmasi asing muncul sementara homepage tampak normal, minta bantuan Website Darurat untuk memetakan konten, akses, file, dan jalur persistence sebelum melakukan penghapusan massal.