Website tự chuyển hướng trên điện thoại hoặc khi vào từ Google

Website chỉ chuyển hướng trên điện thoại, khi vào từ Google hoặc với khách chưa đăng nhập là kiểu sự cố khó tái hiện. Nguyên nhân có thể là mã độc dùng điều kiện user-agent/referrer/cookie, quảng cáo bị chèn, service worker, DNS/CDN hoặc rule redirect hợp lệ cấu hình sai.

Lập ma trận tái hiện

Thử desktop/mobile, đăng nhập/ẩn danh, truy cập trực tiếp/từ công cụ tìm kiếm, nhiều mạng và trình duyệt. Ghi URL bắt đầu, redirect chain, thời gian, cookie và video màn hình. Không mở trang đích nguy hiểm trên thiết bị chứa tài khoản thật.

Phân biệt redirect máy chủ và JavaScript

Redirect 3xx xuất hiện trong header thường đến từ web server, WordPress, CDN hoặc plugin. Nếu response 200 rồi trình duyệt chuyển trang, kiểm tra JavaScript, meta refresh, iframe, service worker và quảng cáo. DevTools/network hoặc proxy ghi lại chain giúp phân biệt.

Những nơi cần rà

• .htaccess, Nginx, CDN rules và DNS.
• Theme header/footer, plugin redirect/ads, mu-plugin và database options.
• JavaScript chèn trong bài, widget hoặc tag manager.
• Service worker, cache mobile và script từ bên thứ ba.
• Access log với referrer/user-agent của phiên bị ảnh hưởng.

Kiểm tra cloaking từ Google

Dùng URL Inspection để xem Google có thấy nội dung khác không. Google lưu ý website bị hack có thể dùng cloaking để chủ site khó phát hiện. Không chỉ đổi user-agent rồi kết luận; referrer, cookie, IP và tần suất cũng có thể là điều kiện.

Làm sạch và kiểm thử lại

Snapshot, xác định code/rule tạo redirect, thay nguồn sạch, xử lý database và vá điểm vào. Xóa cache theo từng lớp, unregister service worker nếu liên quan và chạy lại toàn bộ ma trận. Theo dõi URL đích cũ trong log để phát hiện tái nhiễm.

“Máy em vào bình thường” là câu nguy hiểm nhất

Redirect độc hại thường cố tình tránh chủ website. Nó chỉ chạy trên điện thoại, lần truy cập đầu, khách chưa có cookie, referrer từ Google hoặc một quốc gia nhất định. Nhân viên đã đăng nhập, dùng Wi-Fi văn phòng và truy cập nhiều lần nên luôn thấy trang sạch.

Khi khách gửi ảnh, đội kỹ thuật thử lại không được và cho rằng điện thoại khách nhiễm quảng cáo. Có trường hợp đúng như vậy, nhưng nếu nhiều phản ánh cùng pattern, cần coi đó là sự cố của website cho đến khi chứng minh ngược lại.

Dựng ma trận tái hiện thay vì bấm thử ngẫu nhiên

Ghi thiết bị, trình duyệt, mạng, quốc gia, trạng thái đăng nhập, cookie, referrer và URL. Thử phiên ẩn danh, xóa storage, đổi user-agent và đi qua kết quả tìm kiếm. Mỗi lần chỉ thay một biến để biết điều kiện nào kích hoạt redirect.

Redirect có thể nằm ở nhiều tầng

• HTTP 301/302 từ CDN, web server, plugin hoặc PHP.
• Response 200 rồi JavaScript đổi location.
• Meta refresh hoặc iframe được chèn vào HTML.
• Service worker/cache trình duyệt giữ mã cũ.
• Quảng cáo hoặc script bên thứ ba chỉ chạy trên mobile.

DevTools, curl và log cần được đọc cùng nhau. Nếu server trả 200 nhưng trình duyệt chuyển trang, hãy tập trung DOM/script; nếu response đầu đã 302, truy vết rule phía trước WordPress.

Giữ bằng chứng trước khi xóa cache

Purge cache có thể làm triệu chứng biến mất tạm thời và mất mẫu cần phân tích. Lưu redirect chain, HTML, script, header, thời gian và IP trước. Sau khi làm sạch, kiểm tra lại bằng chính ma trận ban đầu, không chỉ mở trang chủ một lần.

Ảnh hưởng không chỉ là vài lượt truy cập bị mất

Khách có thể gặp trang lừa đảo, cài ứng dụng độc hại hoặc mất niềm tin vào thương hiệu. Công cụ tìm kiếm có thể gắn cảnh báo. Vì vậy cần cân nhắc thông báo cho người dùng và đối tác nếu phạm vi ảnh hưởng đủ lớn, thay vì âm thầm sửa rồi coi như chưa từng xảy ra.

Nguồn tham khảo chính thức

Tham khảo định nghĩa cloaking/hacked content trong Google spam policies và quy trình ghi nhận triệu chứng của WordPress.org.

Sau khi sửa, hãy nhờ người từng gặp lỗi kiểm tra lại

Môi trường của khách có thể tái hiện điều mà phòng kỹ thuật không thấy. Cung cấp hướng dẫn an toàn, xin URL và thời gian kiểm tra, nhưng không yêu cầu họ truy cập lại khi vẫn có nguy cơ. Xác nhận từ nhiều mạng, thiết bị, tài khoản quảng cáo và kết quả tìm kiếm giúp tránh kết luận dựa trên một máy đã có cookie sạch. Tiếp tục theo dõi redirect chain trong vài ngày sau khi cache hết hạn.