20 điểm bởi GN⁺ 9 ngày trước | 5 bình luận | Chia sẻ qua WhatsApp
  • Hành vi khiến người dùng không thể quay lại trang trước đó bằng nút quay lại của trình duyệt hoặc bị chuyển tới trang quảng cáo/đề xuất không mong muốn khi nhấn nút này
  • Google đã bổ sung rõ ràng hành vi “chiếm quyền nút quay lại” này thành một mục vi phạm mới trong chính sách spam
  • Chính sách này dự kiến có hiệu lực từ ngày 15 tháng 6 năm 2026, và nếu vi phạm có thể bị áp dụng biện pháp xử lý spam thủ công hoặc tự động hạ thứ hạng
  • Google cho rằng hành vi này làm tổn hại trải nghiệm người dùng và cản trở luồng điều hướng, nên đã xếp nó là vi phạm rõ ràng của chính sách về hành vi độc hại
  • Quản trị viên website cần loại bỏ mã hoặc script bên ngoài thao túng lịch sử điều hướng của trình duyệt, và khi cần có thể khôi phục thông qua yêu cầu xem xét lại trên Search Console

Khái niệm về chiếm quyền nút quay lại

  • Là hành vi cản trở thao tác quay về trang trước khi người dùng nhấn nút “quay lại” của trình duyệt
    • Website thao túng chức năng điều hướng của trình duyệt để người dùng không thể lập tức quay về trang trước
    • Thay vào đó, người dùng bị chuyển tới các trang chưa từng truy cập, hiển thị trang đề xuất/quảng cáo không mong muốn, hoặc bị chặn điều hướng bình thường

Bối cảnh siết chặt chính sách và các biện pháp dành cho quản trị viên

  • Nhằm ưu tiên hàng đầu cho việc bảo vệ trải nghiệm người dùng
    • Chiếm quyền nút quay lại làm cản trở chức năng của trình duyệt, phá vỡ luồng điều hướng dự kiến và khiến người dùng có cảm giác bực bội và bị thao túng
    • Hành vi này cũng trở thành một yếu tố khiến người dùng ngại truy cập các website lạ
  • Trước đây Google cũng đã coi việc chèn trang mang tính lừa dối hoặc thao túng là vi phạm chính sách Search Essentials,
    và gần đây khi các hành vi như vậy gia tăng, Google đã chỉ định đây là vi phạm rõ ràng của chính sách “hành vi độc hại (malicious practices)”
  • Quản trị viên website cần loại bỏ mã hoặc script thao túng lịch sử điều hướng của trình duyệt của người dùng
    • Vấn đề có thể phát sinh từ thư viện bên ngoài hoặc nền tảng quảng cáo, nên cần kiểm tra và loại bỏ mã, import và cấu hình liên quan
  • Nếu khả năng hiển thị trên tìm kiếm bị hạn chế do biện pháp xử lý thủ công, có thể khôi phục sau khi khắc phục vấn đề bằng cách gửi yêu cầu xem xét lại (reconsideration request) trong Search Console
  • Có thể gửi câu hỏi hoặc phản hồiเพิ่มเติม qua trang Google Search Central trên LinkedIn hoặc cộng đồng hỗ trợ

5 bình luận

 

A, cuối cùng cũng vậy!!! Mấy cơ quan báo chí từng làm trò này đều phải bị trừng trị thích đáng.

 
lazydonkey456 9 ngày trước

Có lẽ trước hết Google Ads nên xử lý đám quảng cáo NSFW thì hơn chứ -_-?

 

Tôi cũng từng vào trang Microsoft QnA, mà cứ bấm quay lại là bị lặp vô hạn, thật sự mong những trang như thế này được sửa cho đỡ phiền.

Dù có redirect hay không thì từ góc độ người dùng, bấm quay lại là phải thoát ra được chứ.
Những trang kiểu này lúc nào cũng bắt phải nhấn giữ nút quay lại để thoát ra hơn 2 cấp.

 

Bình thường trở lại!!

 
Ý kiến trên Hacker News
  • Tôi ước trình duyệt có tính năng vô hiệu hóa mọi phím tắt của website
    Tôi đã đặt Ctrl+E trên Brave để mở tab mới, nhưng các site như Discord lại đổi nó thành menu emoji nên rất khó chịu

    • Ctrl+F cũng là vấn đề. Tôi không muốn mở ô tìm kiếm riêng của site mà muốn tìm từ trong trang
    • Một ví dụ khác là có những site đổi ctrl+click từ mở tab mới thành mở ngay trong tab hiện tại. Tôi thấy điều này đặc biệt thường xuyên ở các site thương mại điện tử
    • Tôi đã tự làm một bookmarklet để chặn mọi key listener nhằm ngăn chuyện này. Nếu ai muốn thì tôi có thể chia sẻ
    • Thay vì chặn hoàn toàn, tôi muốn có một hệ thống xin quyền để site phải yêu cầu quyền dùng phím tắt. Chỉ cần cho phép với những site đáng tin
    • Tôi dùng Vimium trên Firefox nên các phím tắt mặc định dựa theo plugin. Ví dụ, mở tab mới bằng t, còn nếu muốn dùng phím tắt của website thì nhấn i để vào insert mode. Những phím không xung đột như ctrl+k thì site vẫn có thể tự do dùng, nên khá ổn
  • Chính sách lập chỉ mục của Google dạo này thật khó hiểu
    Website của tôi vốn hiển thị tốt trong nhiều năm thì đột nhiên biến mất khỏi chỉ mục. Chỉ là các bài blog đơn giản, không quảng cáo, có HTTPS, và cũng được các site khác liên kết tới
    Thế nhưng kết quả tìm kiếm Google giờ ngày càng xa rời thông tin tôi muốn tìm. Mong rằng chính sách mới sẽ mang lại cải thiện

    • Có thể là vì “không có quảng cáo”. Google không hứng thú hiển thị những trang không có quảng cáo
    • Đây là chuyện Chrome chứ không phải Search. Trong vài năm gần đây, Google đã bắt đầu loại bỏ nội dung ít traffic. Nếu có nhiều nội dung tương tự thì họ sẽ không lập chỉ mục, bất kể thẩm quyền trang ra sao. Giờ tìm kiếm đang dần thành giống TikTok. Tóm tắt AI, YouTube, tin tức, bản đồ và sản phẩm đều được ưu tiên. Nội dung đã chết
  • Trên Firefox, có thể cấu hình để trang không thể sửa lịch sử của trình duyệt
    Theo cách trên superuser.com, chỉ cần tắt browser.history.allowPushState trong about:config

    • Nhưng trong đa số trường hợp, đó không phải pushstate mà là trang thiết lập tự động chuyển hướng. Vì thế phải bấm quay lại hai lần
    • SPA dùng History API để quản lý lịch sử điều hướng nội bộ. Chặn cái này có thể lại gây mất dữ liệu
    • Nhân tiện, từ Firefox 47 trở đi browser.history.allowPushState đã bị deprecated. Dạo này gần như không còn vấn đề site thao túng lịch sử trên Firefox. Tuy vậy, việc Chrome vẫn còn chiếm dụng nút quay lại thì khá đáng ngạc nhiên. Tôi đã xử lý bằng một UserScript chặn keycode cụ thể trên Firefox
  • Lúc đầu tôi tưởng là đang nói về Android
    Các ứng dụng Android rất hay làm kiểu chiếm dụng UX như “phải nhấn quay lại hai lần mới thoát”. Những app dạng feed như Reddit, TikTok, Instagram là ví dụ điển hình

    • Ban đầu tôi cũng tưởng là chuyện Android và tự hỏi sao bài báo cứ liên tục nhắc đến “browser”
    • Tôi thực sự hy vọng Google cũng áp dụng chính sách này cho Android. Tệ nhất là các app
  • Tôi mong họ áp dụng chính sách này với LinkedIn trước tiên
    Khi bấm vào liên kết trong email hoặc bài đăng, bạn sẽ vào bài viết, nhưng khi bấm quay lại thì lại trở về feed.
    Cách làm là kết hợp location.replace(...) với history.pushState() để thao túng lịch sử

    • Reddit cũng chặn quay lại theo cách tương tự. Từ Google vào một bài Reddit rồi bấm quay lại thì lại quay về feed chính của Reddit
    • Gmail cũng có vấn đề UX tương tự. Trong tiêu đề mail mời có nút “chấp nhận”, nên khi cuộn dễ bấm nhầm
    • Tôi luôn xử lý các link từ những site kiểu này bằng cách mở trong tab mới. Đóng tab giờ là nút quay lại mới của tôi. Tab nào không quan tâm thì cứ đóng luôn
    • Facebook cũng hoạt động theo kiểu này. Nhờ lời giải thích đó mà tôi hiểu được cơ chế
    • Tuy vậy, vẫn chưa rõ cách này có vi phạm chính sách mới hay không. Điều hướng dựa trên hash về mặt kỹ thuật có thể vẫn hợp lệ
  • Các website của Microsoft cũng bị vấn đề quay lại này khá nặng

    • Azure Portal là ví dụ tiêu biểu. Bấm quay lại xong không biết điều gì sẽ xảy ra. Giống kiểu “nút may rủi” trên Android
    • Dù vậy, phía MS có vẻ không phải hành vi xấu như chuyển hướng quảng cáo mà gần hơn với vấn đề thiết kế redirect bằng JS
    • Epic Store trên di động cũng không thể quay lại từ trang thanh toán. Tôi không rõ đó là cố ý hay chỉ là một lỗi UX
    • Hôm qua tôi cũng gặp một site như thế; bấm quay lại thật nhanh vẫn không được, cuối cùng đành đóng tab
  • Động thái này là một bước đầu tốt nhưng vẫn chưa đủ
    Tôi không muốn bất kỳ site nào chiếm nút quay lại của mình.
    Tôi đặc biệt ghét các popup kiểu “Bạn có chắc muốn rời đi không? Bạn còn chưa đăng ký newsletter mà?”

    • Với SPA thì đôi khi đây là ngoại lệ cần thiết. Cần theo dõi đúng lộ trình điều hướng của người dùng trong ứng dụng. Nhưng nguyên tắc vẫn là “phải hoạt động đúng như người dùng mong đợi”
    • Những cảnh báo như “Bạn có muốn thoát mà không lưu không?” thì hữu ích. Chỉ là nên có thiết lập cho phép theo từng site
    • Ở góc độ vận hành một ứng dụng SaaS, chúng tôi dùng kiểu cảnh báo này vì nếu người dùng đang nhập form mà lỡ thoát thì dữ liệu sẽ mất. Nhưng từ góc nhìn người dùng, tôi vẫn đang cân nhắc hành vi nào là tốt hơn
    • Ép mở tab mới cũng là một dạng chiếm dụng. Nên cấm hoàn toàn việc này. Thậm chí tôi còn nghĩ cần có chế tài pháp lý
  • Câu “trải nghiệm người dùng là ưu tiên hàng đầu” nghe thật mỉa mai
    Thật buồn cười khi điều đó đến từ một công ty chuyên hiển thị popup “Open in app” gây rối để lôi người dùng sang app
    Bài liên quan: Those obnoxious sign-in windows

  • Đây là lúc thích hợp để quảng bá lại mẫu Post/Redirect/Get
    Như giải thích trên Wikipedia, nếu chuyển hướng sau khi gửi form thì UX sẽ mượt hơn nhiều

    • Là một lập trình viên lâu năm, tôi thực sự rất thích mẫu này. Có vẻ thế hệ React ngày nay không biết nhiều về nó
    • Hôm nay tôi mới biết đến nó lần đầu. Thì ra đó là lý do popup “Bạn có muốn gửi lại form không?” xuất hiện khi không dùng mẫu này. Biết thêm cả tên của nó nên rất hữu ích
  • Ngay cả framework SPA của Google là Angular cũng có thể gây ra chiếm dụng quay lại khi dùng redirect routes
    Điều này được giải thích trong tài liệu chính thức của Angular

    • Tuy nhiên, routing nội bộ trong SPA thường là điều khó tránh để phục vụ UX của ứng dụng. Trong những trường hợp như vậy, việc chiếm dụng chỉ nên được cho phép để duy trì tự nhiên luồng di chuyển nội bộ