Japanese SEO Spam di WordPress: Cara Memeriksa Asalnya

Anda mencari domain sendiri lalu menemukan judul atau URL berkarakter Jepang yang tidak pernah diterbitkan. Saat dibuka dari dashboard, halaman depan dan beberapa artikel tampak normal. Perbedaan itu membuat pemilik situs sering langsung menghapus URL di hasil pencarian, mengganti semua file, atau menjalankan query massal tanpa tahu apakah halaman tersebut berasal dari database, rewrite, atau program yang membuatnya kembali.

Jawaban singkat: perlakukan URL berbahasa Jepang yang tidak dikenali sebagai indikator yang perlu diverifikasi, bukan diagnosis final. Simpan contoh dan waktu temuan, periksa Security Issues dan Manual Actions secara terpisah, kumpulkan URL dari beberapa sumber, lalu petakan slug ke objek WordPress dan lapisan server. Cari proses pembuat atau akses yang tidak sah, bersihkan sumber dan persistence secara terukur, uji ulang, baru tangani dampak indeks. Google menyebut halaman baru, konten tersembunyi, injeksi, dan redirect sebagai bentuk hacked content, tetapi langkah teknis harus mengikuti bukti situs Anda sendiri (Google Search spam policies).

Pastikan dulu bahwa teks tersebut memang tidak sah

Istilah “Japanese SEO spam” sering dipakai untuk halaman spam yang memuat teks Jepang, nama produk, atau tautan yang tidak relevan dengan bisnis. Google menyebut salah satu pola yang dikenal sebagai Japanese keyword hack: halaman otomatis berbahasa Jepang dengan direktori acak dan tautan afiliasi. Itu petunjuk untuk pemeriksaan, bukan bukti bahwa setiap kasus memiliki semua tanda tersebut (panduan Google tentang Japanese keyword hack). Situs berbahasa Jepang, toko yang melayani pelanggan Jepang, atau artikel multibahasa juga dapat memiliki konten tersebut secara sah. Cocokkan contoh dengan owner konten, kalender publikasi, katalog, plugin terjemahan, dan kegiatan bisnis sebelum menyimpulkan ada kompromi.

Indikator lebih kuat muncul ketika ada kombinasi yang tidak dapat dijelaskan: slug acak atau massal, post author asing, waktu pembuatan berdekatan, tautan ke domain yang tidak dikenal, halaman yang hanya muncul untuk request tertentu, akun admin baru, atau perubahan file/konfigurasi tanpa tiket kerja. Satu sinyal saja belum tentu cukup. Catat apa yang Anda amati dan bedakan fakta dari dugaan, misalnya “URL ditemukan di hasil pencarian” adalah fakta, sedangkan “plugin tertentu pasti memasangnya” belum terbukti.

Jangan menganggap istilah Jepang sebagai satu kategori teknis. Halaman dapat dibuat sebagai post, page, custom post type, attachment, hasil rewrite dinamis, atau respons yang dibentuk oleh file dan database. Cara pembersihannya berbeda. Jika Anda juga menemukan gejala kompromi lain, gunakan panduan penanganan website yang diretas sebagai kerangka insiden; artikel ini fokus pada pemetaan URL spam ke sumbernya.

Amankan bukti sebelum membersihkan

Buat daftar setiap URL contoh, judul/snippet yang terlihat, waktu dan zona waktu, sumber penemuan, status respons, serta siapa yang memverifikasi bahwa konten itu tidak sah. Simpan tangkapan layar atau ekspor Search Console dan salinan log yang relevan. Catat juga kapan URL mulai terlihat, apakah redirect terjadi, perangkat/browser yang dipakai, dan apakah sesi sedang login. Jangan memasukkan cookie, token, data pelanggan, atau query rahasia ke tiket publik.

Sebelum mengubah tabel, plugin, .htaccess, atau file, minta administrator mengambil salinan file dan database yang aman. Simpan di luar webroot, batasi akses, dan pastikan salinan tidak ikut disinkronkan ke repositori atau folder unduhan publik. Jika server masih melayani pengunjung ke phishing atau malware, hubungi hosting untuk pembatasan sementara yang sesuai. Jangan membuka tujuan redirect asing dan jangan meminta pelanggan mengklik URL berbahaya demi reproduksi.

Buka Security Issues report dan Manual Actions report secara terpisah. Security Issues dapat berisi temuan keamanan dan contoh URL; Manual Actions berhubungan dengan penegakan kebijakan spam. Status salah satu laporan tidak membuktikan status yang lain. Simpan nama properti dan tanggal pemeriksaan agar tim berikutnya bisa mengulang langkah yang sama.

Bangun inventaris URL, bukan hanya satu pencarian Google

Pencarian site:domain.example dapat membantu menemukan beberapa halaman yang sudah tampil, tetapi hasilnya tidak selalu lengkap dan tidak menunjukkan semua halaman yang disimpan server. Gunakan beberapa sumber: contoh di Search Console, sitemap utama dan sitemap yang tidak dikenal, laporan pengunjung, access log, daftar post/page WordPress, route internal, serta file log CDN atau WAF. Ekspor URL ke lembar kerja privat dan beri status “terverifikasi sah”, “suspected spam”, “redirect”, atau “belum diperiksa”. Hindari memberi label “hapus” sebelum ada pemilik yang mengonfirmasi.

Kelompokkan pola slug, bukan hanya jumlah URL. Catat awalan path, akhiran, query string, pola tanggal, bahasa, dan apakah URL menggunakan taxonomy atau pagination. Pola /product/... dapat berasal dari custom post type; pola yang tidak mempunyai post cocok dapat dibentuk oleh rewrite rule atau script. Bandingkan waktu pembuatan dengan log, perubahan file, aktivitas akun, dan event deployment. Jika Search Console menampilkan contoh, URL Inspection dapat membantu melihat hasil terindeks dan melakukan live test, tetapi alat tersebut mengikuti redirect sebelum menguji halaman dan bukan pengganti pemeriksaan server (URL Inspection tool).

Simpan nilai asli URL; jangan hanya menyimpan versi yang sudah di-decode atau dinormalisasi. Karakter Unicode, percent-encoding, garis miring, huruf besar-kecil, trailing slash, dan query dapat membuat dua URL terlihat mirip tetapi memetakan ke handler yang berbeda. Jangan menyalin URL ke browser jika tujuan atau parameternya berisiko. Gunakan log yang sudah disetujui dan staging untuk reproduksi.

Petakan URL ke objek WordPress

Jalankan inventaris hanya dengan akses yang berwenang, sebaiknya pada salinan privat atau staging. wp post list dapat memberi ID, jenis, status, judul, slug, dan tanggal; periksa semua tipe konten yang relevan, bukan hanya post. Batasi kolom karena judul dan isi bisa memuat data pribadi. Contoh awal:

wp post list --post_type=any --post_status=any --fields=ID,post_type,post_status,post_title,post_name,post_date

Dokumentasi resmi menjelaskan opsi --fields pada wp post list. Bandingkan slug dari daftar itu dengan pola URL yang disimpan. Untuk tiap kecocokan, catat ID, post_type, status, author ID, tanggal dibuat/diubah, dan apakah ada revisi yang bisa dipercaya. Custom post type dapat dimiliki plugin bisnis yang sah; konfirmasi ke owner sebelum mengubah atau menghapusnya.

Jika tidak ada post dengan slug tersebut, jangan langsung simpulkan bahwa WordPress bersih. Periksa taxonomy, rewrite rules, plugin yang mendaftarkan route, template, mu-plugin, theme, drop-in, endpoint REST, file PHP asing, dan aturan server/CDN. Untuk menemukan string atau nilai option, mulai dari salinan database dan query baca-saja yang dibatasi. Gunakan prefix tabel aktual dari situs, bukan asumsi wp_; multisite dapat memiliki prefix per site. Jangan mencetak seluruh isi wp_options ke terminal bersama atau tiket karena di sana bisa ada konfigurasi dan rahasia.

Pola URL yang cocok dengan satu baris database belum menjelaskan siapa yang menulisnya. Bandingkan field dan revisi dengan log, timestamp, aktivitas user, perubahan komponen, dan konfigurasi. Bila query pencarian menemukan kode di nilai serialized, simpan nama option dan konteks yang cukup; jangan menimpa serialized data lewat SQL REPLACE() mentah. wp search-replace memahami data serialized untuk operasi pencarian/penggantian tertentu, tetapi bukan alat untuk menebak payload mana yang boleh dihapus.

Cari mekanisme yang membuat halaman atau URL muncul

Periksa akun WordPress, role, Application Password, sesi admin, SSH/SFTP, akun hosting, deployment key, DNS, CDN, dan akses vendor. Log harus dicocokkan dengan waktu pembuatan objek, bukan dibaca terpisah. Audit file inti dengan checksum resmi, lalu periksa plugin/theme aktif dan nonaktif, mu-plugin, drop-in, direktori uploads, konfigurasi server, dan file baru yang tidak sesuai fungsi. Checksum core tidak mencakup semua plugin kustom, database, konfigurasi hosting, atau script pihak ketiga.

Periksa scheduled event WordPress melalui WP-CLI dan minta host meninjau cron sistem atau job yang tidak terlihat dari dashboard. Cari sitemap asing, rule yang membuat route, atau integrasi yang menerbitkan konten otomatis. Jangan menjalankan scanner yang menghapus otomatis sebelum ada salinan dan pemilik yang memahami dampaknya. Jika URL kembali setelah dihapus, hentikan penghapusan berulang dan cari proses penulisnya: cache purge, permalink flush, atau mengubah tampilan saja tidak menutup persistence.

Apabila bukti menunjukkan akun atau komponen yang tidak dikenal, catat dulu ID, waktu, permission, dan log terkait. Cabut akses yang terbukti tidak sah, perbarui atau ganti komponen melalui sumber tepercaya, rotasi kredensial dari perangkat bersih, lalu periksa event dan URL yang sama lagi. Minta penyedia hosting membantu jika Anda tidak dapat membaca access/error log, mengakses konfigurasi server, atau memisahkan request origin dari CDN.

Bersihkan sumber dan verifikasi hasil

Tentukan tindakan untuk setiap kelas temuan: edit konten sah yang disisipi; pulihkan post dari revisi bersih; hapus objek spam yang dikonfirmasi; perbaiki route atau script pembuatnya; atau pulihkan file dari salinan tepercaya. Jangan menghapus seluruh tabel atau semua konten yang berisi huruf Jepang. Perubahan harus dapat dibatalkan: catat file/record, siapa yang menyetujui, backup yang dipakai, dan hasil uji. Jika perlu mengubah database, uji pada staging yang tidak dapat diakses publik, bandingkan konten sebelum/sesudah, lalu minta persetujuan sebelum membawa perbaikan ke produksi.

Sesudah cleanup, ulangi inventaris URL dengan daftar awal yang sama dan tambahkan contoh baru dari log. Uji URL menggunakan browser anonim dan bahasa/perangkat yang relevan, tetapi jangan mengikuti destination berbahaya. Periksa respons, konten yang dirender, sitemap, cache, URL Inspection, login/role, dan Search Console. Pastikan sumber tidak membuat URL ulang setelah cron berjalan atau cache diperbarui. Catat URL yang dihapus beserta status yang diinginkan; jangan menutup semuanya dengan robots.txt karena crawler perlu dapat melihat respons pembersihan.

Setelah sumber benar-benar bersih, gunakan Removals hanya bila Anda membutuhkan penanganan visibilitas sementara. Itu tidak menghapus post, file, rewrite, atau persistence dari server. Jika Security Issues melaporkan masalah, minta review melalui laporan tersebut setelah semua temuan diperbaiki dan uraikan penyebab, langkah, serta hasil yang dapat dibuktikan. Jangan menjanjikan waktu pengindeksan atau mengirim permintaan berulang sebelum keputusan sebelumnya selesai.

Pencegahan agar spam tidak kembali

Batasi akun administrator, aktifkan MFA untuk akses yang mendukungnya, tinjau integrasi yang dapat menerbitkan konten, update komponen yang didukung, dan hapus plugin/theme yang benar-benar tidak dipakai setelah memeriksa dependensinya. Pisahkan kredensial per operator, simpan backup offsite, uji restore, lindungi log dari perubahan oleh aplikasi, serta tetapkan siapa yang boleh mengubah DNS, sitemap, dan Search Console. Pantau URL baru serta perubahan role sebagai sinyal yang ditinjau manusia, bukan alarm otomatis yang menghapus konten.

Buat prosedur respons ringkas yang menyebut kontak hosting, lokasi backup, siapa owner Search Console, siapa menyetujui cleanup, dan cara mengumpulkan log dengan aman. Untuk penguatan menyeluruh WordPress setelah pemulihan, lihat panduan mengamankan website WordPress UMKM. Audit berkala lebih berguna bila hasilnya menyimpan baseline rute, akun, komponen, dan integrasi yang sah; tanpa baseline, perubahan baru lebih sulit dibedakan dari perubahan rutin.

Pertanyaan umum

Apakah tulisan Jepang di hasil Google membuktikan website diretas? Tidak selalu. Situs multibahasa atau konten yang dibuat pemilik bisa sah. URL atau snippet asing yang tidak dikenali perlu dibandingkan dengan konten WordPress, owner, log, dan laporan Search Console sebelum menyimpulkan kompromi.

Apakah pencarian site: menampilkan semua halaman yang terinfeksi? Tidak. Anggap sebagai petunjuk untuk memulai inventaris, bukan daftar lengkap. Cocokkan dengan Search Console, sitemap, route situs, database, log, dan laporan pengguna.

Bolehkah saya menghapus semua URL spam dari database sekaligus? Jangan berdasarkan satu kata atau pola saja. Ekspor database, konfirmasi record dan pemiliknya, uji pada salinan, serta telusuri proses yang membuatnya. Penghapusan tanpa penutupan persistence dapat mengulang masalah atau merusak konten sah.

Kapan harus meminta bantuan hosting atau spesialis? Segera bila redirect membahayakan pengunjung, URL muncul kembali, bukti menunjuk ke akses server/akun yang tak dikenal, atau Anda tidak dapat membedakan data sah dari payload. Simpan bukti dan minta bantuan tanpa membuka link berbahaya.

Jika URL Jepang yang tidak Anda buat sudah muncul di banyak route atau terus terbentuk kembali, minta audit keamanan website agar pemetaan database, file, akun, dan rule dilakukan berurutan sebelum penghapusan massal.