Google ระบุ "การไฮแจ็กปุ่มย้อนกลับ" เป็นสแปม

 (developers.google.com)
20 คะแนน โดย GN⁺ 15 일 전 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • การกระทำที่ทำให้ผู้ใช้ไม่สามารถกลับไปยังหน้าก่อนหน้าเดิมได้เมื่อกด ปุ่มย้อนกลับของเบราว์เซอร์ หรือพาไปยัง หน้าโฆษณา·หน้าแนะนำที่ไม่ต้องการ
  • เพิ่มรายการนี้เป็น ข้อห้ามละเมิดนโยบายสแปมใหม่ ที่ห้าม “การไฮแจ็กปุ่มย้อนกลับ” อย่างชัดเจน
  • นโยบายนี้มีกำหนด เริ่มบังคับใช้วันที่ 15 มิถุนายน 2026 และหากฝ่าฝืนอาจถูก มาตรการสแปมแบบแมนนวลหรือการลดอันดับอัตโนมัติ
  • Google มองว่าพฤติกรรมดังกล่าว ทำลายประสบการณ์ผู้ใช้และรบกวนลำดับการท่องเว็บ จึงกำหนดให้เป็น การละเมิดนโยบายด้านพฤติกรรมที่เป็นอันตราย อย่างชัดแจ้ง
  • ผู้ดูแลเว็บไซต์ควรลบ โค้ดหรือสคริปต์ภายนอกที่จัดการประวัติการท่องเว็บของเบราว์เซอร์ และหากจำเป็นสามารถกู้คืนได้ผ่าน คำขอพิจารณาใหม่ใน Search Console

แนวคิดของการไฮแจ็กปุ่มย้อนกลับ

  • การกระทำที่รบกวนการกลับไปยังหน้าก่อนหน้าตามปกติเมื่อผู้ใช้กด ปุ่ม ‘ย้อนกลับ’ ของเบราว์เซอร์
    • เว็บไซต์จะปรับแต่งการทำงานด้านการนำทางของเบราว์เซอร์ ทำให้ผู้ใช้ไม่สามารถกลับไปยังหน้าก่อนหน้าได้ทันที
    • แทนที่จะเป็นเช่นนั้น อาจพาไปยังหน้าที่ผู้ใช้ไม่เคยเข้าชม แสดง หน้าแนะนำ·หน้าโฆษณา ที่ไม่ต้องการ หรือขัดขวางการท่องเว็บตามปกติ

เหตุผลของการเข้มงวดนโยบายและสิ่งที่ผู้ดูแลควรทำ

  • เพื่อให้ความสำคัญสูงสุดกับ การปกป้องประสบการณ์ผู้ใช้
    • การไฮแจ็กปุ่มย้อนกลับรบกวนการทำงานของเบราว์เซอร์ ทำลายลำดับการนำทางที่คาดหวัง และทำให้ผู้ใช้ รู้สึกหงุดหงิดและเหมือนถูกควบคุม
    • พฤติกรรมลักษณะนี้ยังเป็น ปัจจัยที่ทำให้ผู้ใช้ลังเลจะเข้าเว็บไซต์ที่ไม่คุ้นเคย
  • ก่อนหน้านี้ Google ก็ได้ระบุว่า การแทรกหน้าที่หลอกลวงหรือมีลักษณะชี้นำ เป็นการละเมิดนโยบาย Search Essentials มาโดยตลอด และ
    จากการที่พฤติกรรมดังกล่าวเพิ่มขึ้นในช่วงหลัง จึงกำหนดให้เป็น การละเมิดนโยบาย “พฤติกรรมที่เป็นอันตราย (malicious practices)” อย่างชัดแจ้ง
  • ผู้ดูแลเว็บไซต์ต้องลบ โค้ดหรือสคริปต์ที่จัดการประวัติการท่องเว็บของผู้ใช้ในเบราว์เซอร์
    • เนื่องจากอาจเกิดจากไลบรารีภายนอกหรือแพลตฟอร์มโฆษณา จึงจำเป็นต้องตรวจสอบและลบโค้ด·import·การตั้งค่าที่เกี่ยวข้อง
  • หากการแสดงผลในการค้นหาถูกจำกัดจากมาตรการแบบแมนนวล หลังแก้ไขปัญหาแล้วสามารถกู้คืนได้ผ่าน คำขอพิจารณาใหม่ (reconsideration request) ใน Search Console
  • หากมีคำถามเพิ่มเติมหรือข้อเสนอแนะ สามารถติดต่อผ่าน หน้า Google Search Central บน LinkedIn หรือ ชุมชนช่วยเหลือ

บทความที่เกี่ยวข้อง

5 ความคิดเห็น

 
xguru 15 일 전

อา ในที่สุด!!! สื่อพวกที่ชอบทำอะไรแบบนี้ควรโดนลงโทษหนักกันให้หมด
 
lazydonkey456 15 일 전

โฆษณา Google น่าจะต้องจัดการพวกโฆษณา NSFW ก่อนสักหน่อยไหม -_-?
 
crawler 15 일 전

แม้แต่เว็บไซต์ Microsoft QnA ก็เหมือนกัน เข้าไปแล้วพอกดย้อนกลับก็วนลูปไม่รู้จบ อยากให้เว็บแบบนี้ช่วยแก้กันจริง ๆ

ไม่ว่าจะมี redirect หรือไม่ จากมุมผู้ใช้แล้ว ถ้ากดย้อนกลับก็ควรต้องออกไปได้
แต่เว็บพวกนี้ต้องกดปุ่มย้อนกลับค้างไว้ตลอด แล้วออกไปมากกว่า 2 depth ขึ้นไปถึงจะได้
 
eoeoe 15 일 전

กลับสู่ภาวะปกติ!!
 
GN⁺ 15 일 전
ความเห็นจาก Hacker News

  • อยากให้เบราว์เซอร์มีฟีเจอร์ ปิดการทำงานของคีย์ลัดทั้งหมด ของเว็บไซต์ได้
    ใน Brave ฉันตั้ง Ctrl+E ให้เปิดแท็บใหม่ไว้ แต่เว็บอย่าง Discord กลับเอาไปใช้เปิดเมนูอีโมจิ ทำให้ใช้งานลำบาก

    • Ctrl+F ก็เป็นปัญหาเหมือนกัน ฉันไม่ได้อยากเปิด ช่องค้นหาของเว็บเอง แต่อยากค้นหาคำในหน้า
    • อีกตัวอย่างคือมีบางเว็บที่เปลี่ยน ctrl+click จากการเปิดแท็บใหม่ ให้กลายเป็นเปิดในแท็บปัจจุบันแทน โดยเฉพาะ เว็บอีคอมเมิร์ซ
    • ฉันทำ bookmarklet ไว้ตัวหนึ่งเพื่อบล็อกตัวรับฟังการกดคีย์ทั้งหมดไว้กันเรื่องพวกนี้ ถ้าอยากได้ก็แชร์ได้
    • แทนที่จะบล็อกทั้งหมด อยากให้มีระบบที่เว็บไซต์ต้อง ขอสิทธิ์ใช้คีย์ลัด ก่อน อนุญาตเฉพาะเว็บที่ไว้ใจได้ก็พอ
    • บน Firefox ฉันใช้ Vimium เลยยึดคีย์ลัดตามปลั๊กอินเป็นหลัก เช่น กด t เพื่อเปิดแท็บใหม่ และถ้าจะใช้คีย์ลัดของเว็บก็กด i เพื่อเข้า insert mode แบบนี้ก็ดี เพราะปุ่มที่ไม่ชนกันอย่าง ctrl+k เว็บยังใช้ได้อิสระ

  • ทุกวันนี้ฉันไม่ค่อยเข้าใจ นโยบายการจัดทำดัชนี ของ Google แล้ว
    เว็บไซต์ของฉันที่เคยติดดัชนีและถูกค้นเจอมาหลายปี อยู่ๆ ก็หายไปจากดัชนี มันก็เป็นแค่บล็อกโพสต์ธรรมดา ไม่มีโฆษณา เปิด HTTPS และมีเว็บอื่นลิงก์มาอยู่ด้วย
    แต่ช่วงนี้ผลการค้นหาของ Google ยิ่งห่างจาก ข้อมูลที่อยากหา มากขึ้นเรื่อยๆ หวังว่านโยบายใหม่นี้จะช่วยให้ดีขึ้น

    • อาจเป็นเพราะ “ไม่มีโฆษณา” ก็ได้ Google ไม่ได้สนใจจะแสดงหน้าที่ไม่มีโฆษณา
    • อันนี้พูดถึง Chrome ไม่ใช่ Search นะ แต่ Google ในช่วงไม่กี่ปีที่ผ่านมาเริ่ม ตัดเนื้อหาที่มีทราฟฟิกต่ำออก ถ้าเนื้อหาคล้ายกันเยอะก็จะไม่ทำดัชนีให้โดยไม่สนเรื่อง authority ของหน้า ตอนนี้การค้นหากำลังกลายเป็น เหมือน TikTok มากขึ้นเรื่อยๆ ให้ความสำคัญกับ AI สรุป, YouTube, ข่าว, แผนที่ และสินค้าเป็นหลัก เนื้อหาทั่วไปตายหมดแล้ว

  • ใน Firefox สามารถตั้งค่าไม่ให้หน้าเว็บ แก้ไขประวัติการเข้าชม ของเบราว์เซอร์ได้
    ตาม วิธีใน superuser.com ให้ไปที่ about:config แล้วปิด browser.history.allowPushState

    • แต่ส่วนใหญ่ไม่ใช่ pushstate หรอก มักเป็นเพราะหน้าเว็บทำ auto redirect ไว้ เลยต้องกดปุ่มย้อนกลับสองครั้ง
    • SPA ใช้ History API เพื่อจัดการประวัติการนำทางภายใน ถ้าบล็อกสิ่งนี้อาจทำให้ข้อมูลสูญหายได้แทน
    • อนึ่ง ตั้งแต่ Firefox 47 เป็นต้นมา browser.history.allowPushState ถูก deprecated แล้ว ทุกวันนี้ปัญหาเว็บจัดการประวัติแบบนี้แทบไม่ค่อยมี แต่ก็น่าแปลกที่ใน Chrome ยังมี การ hijack ปุ่มย้อนกลับ อยู่ ฉันแก้ด้วย UserScript ที่บล็อก keycode บางตัวบน Firefox

  • ตอนแรกนึกว่าพูดถึง Android
    แอป Android หลายตัวชอบทำ UX hijacking อย่างเช่น “ต้องกดย้อนกลับสองครั้งถึงจะออก” โดยเฉพาะแอปฟีดอย่าง Reddit, TikTok, Instagram

    • ตอนแรกฉันก็นึกว่าพูดถึง Android แล้วสงสัยว่าทำไมในบทความถึงพูดคำว่า “browser” อยู่เรื่อยๆ
    • อยากให้ Google เอานโยบายนี้ไปใช้กับ Android ด้วยจริงๆ ตัวปัญหาหนักสุดคือแอป

  • อยากให้เริ่มใช้นโยบายนี้กับ LinkedIn ก่อนเลย
    เวลากดลิงก์จากอีเมลหรือโพสต์ มันจะพาไปยังโพสต์นั้นก็จริง แต่พอกดย้อนกลับกลับ ย้อนไปหน้าฟีด
    นี่คือการ จัดการ history ด้วยการผสม location.replace(...) กับ history.pushState()

    • Reddit ก็ใช้วิธีเดียวกันในการดักปุ่มย้อนกลับ ไปโพสต์ Reddit จาก Google แล้วพอกดย้อนกลับก็เด้งกลับไปฟีดหลักของ Reddit
    • Gmail ก็มีปัญหา UX คล้ายกัน อีเมลเชิญชวนมีปุ่ม “ยอมรับ” อยู่ในหัวข้อ เลื่อนๆ อยู่เผลอกดได้ง่ายมาก
    • ฉันรับมือกับลิงก์เว็บพวกนี้ด้วยการ เปิดในแท็บใหม่เสมอ การปิดแท็บกลายเป็นปุ่มย้อนกลับอันใหม่ของฉันไปแล้ว แท็บที่ไม่สนใจก็ปิดทิ้งเลย
    • Facebook ก็ทำงานแบบนี้เหมือนกัน ขอบคุณคำอธิบายนี้ที่ช่วยให้เข้าใจกลไก
    • แต่ก็ยังไม่ชัดว่าวิธีนี้ถือว่า ผิดนโยบายใหม่ หรือเปล่า การนำทางแบบอิง hash อาจยังถือว่าใช้ได้ในทางเทคนิค

  • เว็บของ Microsoft ก็มีปัญหา ปุ่มย้อนกลับ แบบนี้หนักเหมือนกัน

    • ตัวอย่างชัดสุดคือ Azure Portal กดย้อนกลับแล้วไม่รู้จะเกิดอะไรขึ้น ให้อารมณ์เหมือนปุ่ม “เสี่ยงดวง” บน Android
    • แต่ของ MS ดูเหมือนจะไม่ใช่พฤติกรรมร้ายแบบ redirect โฆษณา แค่เป็น ปัญหาการออกแบบ JS redirect มากกว่า
    • Epic Store บนมือถือก็ย้อนกลับจากหน้าชำระเงินไม่ได้เหมือนกัน ไม่รู้ตั้งใจหรือเป็นแค่ ความพลาดด้าน UX
    • เมื่อวานฉันก็เพิ่งเจอเว็บแบบนี้ กดย้อนกลับเร็วๆ ก็ไม่ช่วย สุดท้ายต้องปิดแท็บไปเลย

  • มาตรการครั้งนี้เป็นก้าวแรกที่ดี แต่ ยังไม่พอ
    ฉันไม่อยากให้เว็บไซต์ไหนก็ตาม ดักปุ่มย้อนกลับของฉัน
    โดยเฉพาะป๊อปอัปแนว “แน่ใจนะว่าจะออก? คุณยังไม่ได้สมัครจดหมายข่าวเลย” นี่เกลียดที่สุด

    • ใน SPA มีกรณียกเว้นที่จำเป็น เพราะต้อง ติดตามเส้นทางการใช้งาน ของผู้ใช้ในแอปอย่างถูกต้อง แต่หลักการก็คือ “ต้องทำงานตามที่ผู้ใช้คาดหวัง”
    • คำเตือนอย่าง “คุณแน่ใจหรือว่าจะออกโดยไม่บันทึก?” มีประโยชน์นะ แต่ควรมีการตั้งค่า อนุญาตเป็นรายเว็บ ได้
    • ในฐานะคนที่ดูแลแอป SaaS ถ้าผู้ใช้กรอกฟอร์มอยู่แล้วเผลอออก ข้อมูลจะหาย เลยต้องมีคำเตือนแบบนี้ แต่จากมุมผู้ใช้ก็ยังคิดอยู่ว่าแบบไหนดีกว่ากัน
    • การบังคับเปิดแท็บใหม่ก็เป็น การ hijack รูปแบบหนึ่งเหมือนกัน ควรถูกห้ามทั้งหมด และฉันถึงขั้นคิดว่าควรมี บทลงโทษทางกฎหมาย ด้วยซ้ำ

  • บอกว่า “ประสบการณ์ผู้ใช้มาก่อน” นี่มัน น่าขันดี
    บริษัทที่ชอบขึ้นป๊อปอัป “Open in app” ให้สับสนเพื่อพาผู้ใช้ไปแอป กลับมาพูดแบบนี้
    บทความที่เกี่ยวข้อง: Those obnoxious sign-in windows

  • ตอนนี้แหละเป็นจังหวะดีที่จะกลับมาโปรโมต แพตเทิร์น Post/Redirect/Get
    ตาม คำอธิบายในวิกิพีเดีย ถ้าหลังส่งฟอร์มแล้วมีการ redirect ต่อ UX จะลื่นไหลขึ้นมาก

    • ในฐานะนักพัฒนารุ่นเก่า ฉันชอบแพตเทิร์นนี้มาก ดูเหมือนคนยุค React สมัยนี้จะไม่ค่อยรู้จักมันแล้ว
    • วันนี้เพิ่งรู้จักเป็นครั้งแรก นี่เองคือเหตุผลว่าถ้าไม่มีแพตเทิร์นนี้จะมีป๊อปอัป “ต้องการส่งฟอร์มอีกครั้งหรือไม่?” ขึ้นมา ได้รู้แม้กระทั่งชื่อของมัน ถือว่ามีประโยชน์มาก

  • เฟรมเวิร์ก SPA ของ Google อย่าง Angular เอง ถ้าใช้ redirect routes ก็ทำให้เกิด การ hijack ปุ่มย้อนกลับ ได้
    มีอธิบายไว้ใน เอกสารทางการของ Angular

    • แต่การทำ routing ภายในของ SPA หลายครั้งก็เลี่ยงไม่ได้เพื่อ UX ของแอป ในกรณีแบบนี้ควรอนุญาตการ hijack ได้เฉพาะเพื่อ คงการนำทางภายในให้เป็นธรรมชาติ เท่านั้น