Redirect Malware WordPress Hanya Muncul di Mobile: Cara Memeriksa

Pelanggan melaporkan bahwa halaman WordPress tertentu membuka domain asing dari ponsel, sementara Anda mengujinya dari laptop dan tidak melihat apa-apa. Mengulang klik dari akun admin yang sama hanya memberi hasil normal. Karena redirect dapat bergantung pada user-agent, referrer, sesi, cache, atau lokasi edge, satu browser desktop bukan tes yang cukup. Namun, tampilan mobile yang berbeda juga tidak otomatis berarti malware; kampanye iklan atau rule yang disengaja dapat berperan.

Jawaban singkat: simpan URL, waktu, perangkat, jaringan, status awal, dan header Location; bandingkan permintaan desktop dengan mobile pada staging atau situs yang Anda kelola, ubah satu variabel dalam satu waktu, dan jangan mengikuti destination mencurigakan. Jika perilaku tidak disetujui bisnis, telusuri .htaccess/Nginx, CDN, plugin, theme, script iklan, service worker, dan log sebelum menghapus kode. Google mencantumkan redirect berbasis perangkat sebagai salah satu pola hacked redirect, tetapi juga menyarankan pemeriksaan komponen pihak ketiga bila situs tidak menunjukkan kompromi (Google Search spam policies, panduan manual action).

Panduan ini membahas cabang berdasarkan perangkat, bukan semua jenis redirect. Jika Anda juga menemukan perubahan yang bergantung pada referrer atau beberapa halaman terdampak, catat kondisi itu sebagai jalur uji terpisah dan gunakan panduan respons website yang diretas untuk memperluas investigasi. Bila ada file, akun, atau konten lain yang mencurigakan, periksa juga tanda website terkena malware.

Pastikan laporan cukup spesifik untuk diuji

Minta pelapor menyampaikan URL halaman awal, bukan link tujuan yang berbahaya. Catat apakah redirect terjadi saat membuka URL langsung, klik hasil pencarian, klik dari aplikasi sosial, atau mengikuti tautan internal; perangkat dan sistem operasi; browser; waktu; apakah tab baru terbuka; dan apakah pengguna sudah login. Jangan meminta password, cookie, screenshot yang menampilkan informasi pribadi, atau pengunjung mengulangi tindakan yang mengunduh file.

Buat matriks uji kecil. Misalnya: URL sama, jaringan sama, satu tes desktop dan satu mobile; kemudian bandingkan akses langsung dengan referrer yang diketahui. Jangan mengubah user-agent, referrer, IP, dan status login sekaligus karena Anda tidak akan tahu variabel mana yang memengaruhi hasil. Ulangi beberapa kali pada jendela privat setelah mencatat bahwa CDN atau browser cache dapat membuat hasil tidak konsisten. Semua pengujian harus dilakukan pada situs yang Anda miliki atau berwenang audit.

Jika destination mengarah ke phishing, malware, perjudian ilegal, atau meminta data sensitif, jangan buka. Simpan domain dan header, gunakan lingkungan analisis aman bila tim keamanan mengizinkan, serta minta host membatasi paparan pengunjung jika risikonya nyata. Jangan meneruskan link ke pelanggan atau kanal publik.

Bandingkan request tanpa mengikuti redirect

Mulailah dengan GET biasa agar Anda dapat melihat respons pertama tanpa menjalankan JavaScript. Curl tidak mengikuti redirect secara default; jangan menambahkan -L atau --location saat tujuannya belum aman. Di staging yang Anda kontrol, contoh pembandingnya:

curl -sS -D - -o /dev/null 'https://staging.example.test/path-yang-diuji/'
curl -sS -A 'Mozilla/5.0 (Linux; Android 14; Mobile)' -D - -o /dev/null 'https://staging.example.test/path-yang-diuji/'

Ganti URL contoh hanya dengan domain yang Anda kelola. Bandingkan kode status seperti 200, 301, 302, atau 307, header Location, Cache-Control, dan header perantara yang disetujui untuk dilihat. Jangan menyalin token atau cookie ke laporan. Tes curl -I saja dapat berbeda dari GET karena server/plugin dapat menangani HEAD secara berbeda; bila reproduksi gagal, gunakan browser devtools dan access log.

User-agent string meniru sebagian identitas browser, bukan seluruh perilaku ponsel. Ia tidak mensimulasikan viewport, touch, JavaScript, cookie, IP operator seluler, geolokasi, cache, atau aplikasi pembuka link. Gunakan perangkat uji yang disetujui atau emulator browser untuk memeriksa tahap rendering. Catat hasil sebagai “desktop 200 tanpa Location” atau “mobile 302 ke domain asing”, bukan “hack pasti” sebelum sumber diverifikasi.

Bandingkan juga apakah redirect ada pada respons HTTP awal atau muncul setelah halaman selesai dimuat. Bila header pertama sudah mengandung status 3xx, sumber mungkin berada di web server, proxy/CDN, plugin, atau PHP sebelum template selesai. Bila respons awal 200 dan browser berpindah kemudian, periksa JavaScript, meta refresh, service worker, tag manager, iklan, dan script pihak ketiga. Periksa Network panel dengan Preserve log agar request pertama dan script pemicu tidak hilang setelah navigasi.

Periksa laporan Google tanpa menyamakan dua jenis masalah

Buka Search Console Security Issues untuk melihat apakah Google melaporkan halaman yang disusupi atau berbahaya; periksa Manual Actions secara terpisah bila ada pesan mengenai kebijakan, misalnya sneaky mobile redirects. Laporan dapat memberi contoh tetapi bukan seluruh inventory. URL Inspection menampilkan status index/live test dan hasil render, namun live test mengikuti redirect yang diterapkan halaman sebelum memeriksa tujuan. Catat batas itu ketika membandingkan hasil dengan log server.

Jika Manual Actions menampilkan masalah, ikuti instruksi pada jenis action tersebut. Google menyarankan pemilik yang tidak sengaja memiliki mobile redirect memeriksa apakah situs diretas dan mengaudit script atau elemen pihak ketiga, lalu melepas elemen yang tidak dikendalikan satu per satu pada halaman terkait dan menguji ulang. Jangan menghapus semua tag analytics, chat, iklan, atau widget pada produksi secara serentak; tentukan owner, ambil snapshot, dan gunakan staging agar fungsi bisnis tidak hilang tanpa bukti.

Telusuri sumber dari lapisan luar ke dalam

CDN, proxy, dan konfigurasi web server

Periksa redirect rules, page rules, worker, transform, cache, WAF, load balancer, konfigurasi Apache/Nginx/LiteSpeed, serta .htaccess bila server membacanya. Cari kondisi yang membaca User-Agent, device class, referer, cookie, IP, country, atau first-visit flag. Bandingkan log edge dengan origin jika host menyediakan keduanya. Jangan mengedit .htaccess atau Nginx live hanya berdasarkan satu baris; backup konfigurasi, minta owner hosting, dan uji aturan satu per satu.

WordPress, plugin, dan theme

Inventarisasi plugin redirect, SEO, security, cache, consent, banner, popup, ad, dan affiliate. Periksa perubahan terakhir, rule yang mencocokkan path, plugin yang menjalankan conditional hook, theme header/footer, mu-plugin, drop-in, custom code, serta script yang ditempel melalui page builder. Jika perlu menonaktifkan komponen untuk diagnosis, lakukan pada staging atau dalam maintenance window yang disetujui; simpan konfigurasi dan uji fungsi yang bergantung padanya.

JavaScript dan elemen pihak ketiga

Gunakan Network/Console browser untuk menemukan request atau script yang memulai perpindahan. Catat origin script, versi, tag pemuat, waktu, halaman pemicu, dan request yang gagal/berhasil. Script dapat dimuat lewat tag manager atau plugin tanpa berada di file theme, jadi cocokkan rantai pemuat. Bila vendor mengelola script, minta mereka mengonfirmasi versi dan perubahan; jangan mengirim mereka rahasia sesi atau data pelanggan.

Database, akun, dan persistence

Jika rule yang jelas tidak ditemukan, audit konten, options, custom fields, akun, Application Password, cron, dan file. Bandingkan perubahan dengan log, jangan menghapus data berdasarkan kata kunci umum. Cari sumber yang bisa menulis ulang aturan setelah Anda membersihkan; URL yang kembali menunjukkan persistence atau deployment yang belum dipahami. Bila ada beberapa indikator kompromi, simpan bukti dan gunakan panduan pemulihan website diretas sebagai alur insiden.

Perbaiki kondisi yang memicu redirect

Setelah sumber ditemukan, tentukan apakah rule itu disetujui. Untuk kampanye iklan atau mobile landing page, owner bisnis harus mengonfirmasi destination, batas waktu, dan kelompok pengguna. Untuk rule usang, hapus hanya entri yang tidak lagi diperlukan dan uji URL lama serta canonical. Untuk script pihak ketiga yang disalahgunakan, hentikan akses atau ganti sumber, update konfigurasi, lalu verifikasi vendor. Untuk redirect berbahaya yang ditanam, simpan salinan, isolasi komponen, cabut akses yang tidak sah, patch entry point, dan periksa file/database/cron yang berhubungan.

Jangan mengganti redirect ke halaman aman hanya untuk menyembunyikan gejala. Perbaiki jalur yang menghasilkan keputusan dan catat siapa menyetujui perubahan. Purge cache setelah origin atau rule diperbaiki, bukan sebelum bukti tersimpan. Bila visitor masih terpapar, minta host membatasi URL terdampak, memberi maintenance page yang disetujui, atau menerapkan kontrol containment sementara sesuai arsitektur. Hindari rule universal yang memblokir seluruh mobile traffic; tindakan itu bisa memutus fungsi sah dan meninggalkan malware aktif.

Buktikan perbaikan pada cohort yang sama

Ulangi matriks uji semula: URL sama, desktop/mobile, direct/referrer yang relevan, anonim/login bila memang aman, jaringan dan cache yang dicatat. Pastikan request mobile menerima respons yang diharapkan dan tidak ada header Location yang tidak disetujui; verifikasi konten setelah JavaScript berjalan; cek origin serta CDN; lalu uji beberapa halaman tetangga agar rule tidak memengaruhi area lain. Minta pelapor mengonfirmasi dari perangkatnya tanpa mengunjungi destination mencurigakan.

Periksa Search Console Security Issues dan Manual Actions lagi bila keduanya menunjukkan temuan. Bila laporan meminta review, kirim setelah seluruh masalah selesai dan uraikan perubahan yang dapat diverifikasi. Monitor access log, keluhan pelanggan, perubahan script, dan hasil tes untuk memastikan redirect tidak kembali setelah cache kadaluarsa atau plugin diperbarui. Jika Anda tidak memiliki akses ke log origin, CDN, atau third-party script, eskalasikan ke hosting/vendor; tebak-tebakan dari browser tidak cukup.

Pencegahan

Tinjau redirect dan iklan pihak ketiga melalui daftar owner, tujuan, tanggal berakhir, dan halaman yang boleh dipasangi. Gunakan akses minimum di tag manager dan batasi siapa yang dapat menerbitkan perubahan. Simpan baseline hash/versi script sesuai kebijakan, pantau rule server/CDN, update WordPress serta komponen yang didukung, dan jaga log di lokasi yang tidak dapat ditimpa aplikasi. Uji tampilan mobile dan desktop setelah deploy atau perubahan vendor, bukan hanya homepage saat admin login.

Untuk penguatan umum WordPress dan kontrol akun, lihat panduan mengamankan website WordPress UMKM. Dokumentasikan prosedur report pelanggan, siapa yang menghubungi host, dan cara mengambil respons pertama tanpa membuka destination agar tim dapat bergerak cepat tanpa menyebarkan link berbahaya.

Pertanyaan umum

Apakah redirect mobile-only selalu berarti malware? Tidak. Ia bisa berasal dari rule bisnis, script iklan, plugin, cache, atau pihak ketiga. Bila perilakunya tidak disetujui, perlakukan sebagai risiko dan cari sumbernya sebelum memberi label final.

Apakah mengubah user-agent dengan curl cukup untuk menguji ponsel? Tidak. User-agent hanya satu variabel; browser mobile juga berbeda pada JavaScript, viewport, cookie, IP, dan cache. Kombinasikan dengan emulator/perangkat berwenang, devtools, dan log.

Haruskah saya memakai curl -L untuk melihat tujuan? Tidak jika domain tujuan belum aman. Catat respons pertama dan header Location; jangan mengikuti redirect yang dapat membawa ke phishing, malware, atau unduhan.

Kapan saya perlu minta bantuan hosting? Minta mereka membantu jika redirect berasal dari konfigurasi server/CDN, log origin tidak tersedia, pengunjung masih terpapar, atau perubahan berulang setelah cleanup. Berikan waktu, URL, status, header yang sudah disamarkan, dan matriks uji.

Jika pengunjung mobile masih diarahkan ke domain yang tidak dikenal dan sumbernya belum jelas, minta bantuan Website Darurat untuk mengisolasi rule, script, dan akses yang perlu ditangani tanpa memutus semua layanan.