Google ने "back button hijacking" को spam के रूप में चिह्नित किया

 (developers.google.com)
20 पॉइंट द्वारा GN⁺ 2026-04-15 | 7 टिप्पणियां | WhatsApp पर शेयर करें
  • जब उपयोगकर्ता ब्राउज़र का back button दबाता है, तो उसे मूल पेज पर लौटने से रोकना, या उसे अनचाहे विज्ञापन/सिफारिश पेजों पर भेज देना
  • ऐसे ‘back button hijacking’ को स्पष्ट रूप से प्रतिबंधित करने वाले नए spam policy violation के रूप में जोड़ा गया है
  • यह नीति 15 जून 2026 से लागू होने वाली है, और उल्लंघन होने पर manual spam action या automatic ranking demotion लागू हो सकते हैं
  • Google का कहना है कि ऐसे व्यवहार user experience को नुकसान पहुंचाते हैं और navigation flow में बाधा डालते हैं, इसलिए इसे malicious practices policy का स्पष्ट उल्लंघन माना गया है
  • साइट ऑपरेटर ब्राउज़र navigation history को manipulate करने वाले code या external scripts को हटाएं, और जरूरत पड़ने पर Search Console reconsideration request के जरिए रिकवरी कर सकते हैं

back button hijacking की अवधारणा

  • जब उपयोगकर्ता ब्राउज़र का ‘back button’ दबाता है, तो मूल पेज पर लौटने की क्रिया में बाधा डालने वाला व्यवहार
    • साइट ब्राउज़र के navigation function को manipulate करती है, जिससे उपयोगकर्ता तुरंत पिछले पेज पर वापस नहीं जा पाता
    • इसके बजाय, उसे ऐसे पेज पर भेजा जाता है जिसे उसने देखा ही नहीं था, या अनचाहे recommendation/advertising pages दिखाए जाते हैं, या सामान्य navigation को ब्लॉक किया जाता है

नीति सख्त करने की पृष्ठभूमि और ऑपरेटरों के लिए कदम

  • user experience की सुरक्षा को सर्वोच्च प्राथमिकता देने के लिए
    • back button hijacking ब्राउज़र functionality में बाधा डालता है, अपेक्षित navigation flow को तोड़ता है, और उपयोगकर्ता को हताशा और manipulate किए जाने का एहसास देता है
    • ऐसा व्यवहार उपयोगकर्ताओं को अनजान साइटों पर जाने से हिचकाने वाला कारक बनता है
  • Google पहले से ही deceptive या manipulative page insertion को Search Essentials policy का उल्लंघन बताता रहा है,
    और हाल में ऐसे मामलों के बढ़ने के कारण इसे ‘malicious practices’ policy का स्पष्ट उल्लंघन घोषित किया गया है
  • साइट ऑपरेटरों को उपयोगकर्ता की ब्राउज़र navigation history को manipulate करने वाले code या scripts हटाने चाहिए
    • यह external libraries या ad platforms से भी आ सकता है, इसलिए संबंधित code, imports और settings की जांच करके उन्हें हटाना जरूरी है
  • अगर manual action के कारण search visibility सीमित हो गई हो, तो समस्या ठीक करने के बाद Search Console की reconsideration request के जरिए रिकवरी संभव है
  • अतिरिक्त सवाल या feedback के लिए LinkedIn पर Google Search Central page या support community का उपयोग किया जा सकता है

संबंधित पढ़ाई

7 टिप्पणियां

 
xguru 2026-04-15

आह, आखिरकार!!! ऐसा करने वाले सभी मीडिया आउटलेट्स पर सख्त कार्रवाई होनी चाहिए
 
roxie 2026-05-13

यह एक-दो दिन की समस्या तो नहीं थी, लेकिन काफ़ी... काफ़ी ज़्यादा समय लग गया।
 
lazydonkey456 2026-04-15

Google ads में NSFW ads से तो पहले कुछ निपटना चाहिए, है ना -_-?
 
crawler 2026-04-15

Microsoft QnA साइट भी ऐसी ही है; उसमें चले जाएँ और फिर back दबाएँ तो वह अनंत loop में फँसा देती है। काश ऐसे sites को ज़रा ठीक किया जाए।

redirect हो या न हो, user के नज़रिए से back दबाने पर बाहर निकल जाना चाहिए।
ऐसी sites में तो हमेशा back button को लंबा दबाकर 2 depth से ज़्यादा पीछे जाना पड़ता है।
 
roxie 2026-05-13

यह मुद्दा सच में इतना बेवकूफ़ाना लगता है कि और कुछ कहा ही नहीं जा सकता। मैंने भी इसका सामना किया है।
 
eoeoe 2026-04-15

सामान्यीकरण!!
 
GN⁺ 2026-04-15
Hacker News की राय

  • काश ब्राउज़र में ऐसी सुविधा होती जो वेबसाइटों के सभी shortcuts को disable कर सके
    मैंने Brave में Ctrl+E को नया tab खोलने के लिए सेट किया है, लेकिन Discord जैसी साइटें इसे emoji मेन्यू में बदल देती हैं, जो काफ़ी परेशान करता है

    • Ctrl+F भी समस्या है। मैं साइट का अपना search box नहीं, बल्कि पेज के अंदर शब्द खोज करना चाहता हूँ
    • एक और उदाहरण: कुछ साइटें ctrl+click को नया tab खोलने के बजाय उसी मौजूदा tab में खोलने के लिए बदल देती हैं। यह खासकर e-commerce साइटों में अक्सर दिखता है
    • मैंने इसे रोकने के लिए एक bookmarklet बनाया है जो सभी key input listeners को block कर देता है। चाहें तो मैं इसे शेयर कर सकता हूँ
    • इसे पूरी तरह block करने के बजाय, काश ऐसा सिस्टम होता जिसमें साइट को shortcuts इस्तेमाल करने की permission माँगनी पड़ती। तब केवल भरोसेमंद साइटों को अनुमति दी जा सकती थी
    • Firefox में मैं Vimium इस्तेमाल करता हूँ, इसलिए default shortcuts plugin के हिसाब से चलते हैं। उदाहरण के लिए, ‘t’ से नया tab खुलता है, और वेबसाइट shortcuts इस्तेमाल करने के लिए ‘i’ दबाकर insert mode में जाना पड़ता है। ctrl+k जैसे non-conflicting keys साइटें स्वतंत्र रूप से इस्तेमाल कर सकती हैं, यह अच्छा है

  • आजकल Google की indexing policy समझ नहीं आती
    मेरी साइट कई सालों तक ठीक से दिखती रही, फिर अचानक index से गायब हो गई। यह एक साधारण ब्लॉग पोस्ट है, इसमें ads नहीं हैं, HTTPS enabled है, और दूसरी साइटों से इसके links भी हैं
    लेकिन आजकल Google search results धीरे-धीरे मनचाही जानकारी से दूर होते जा रहे हैं। उम्मीद है नई policy से सुधार होगा

    • हो सकता है “क्योंकि ads नहीं हैं”। Google को ad-free pages दिखाने में कोई दिलचस्पी नहीं है
    • यह Chrome की बात है, search की नहीं। Google ने पिछले कुछ सालों में कम traffic वाले content को हटाना शुरू किया है। अगर मिलते-जुलते बहुत से pages हों, तो page authority की परवाह किए बिना indexing नहीं होती। अब search TikTok जैसा होता जा रहा है। AI summaries, YouTube, news, maps और products को पहले रखा जाता है। content मर चुका है

  • Firefox में यह सेट किया जा सकता है कि पेज ब्राउज़र history को modify न कर सकें
    superuser.com का तरीका के अनुसार, about:config में browser.history.allowPushState को off कर दें

    • लेकिन ज़्यादातर मामलों में pushstate नहीं, बल्कि पेज ने automatic redirect लगा रखा होता है। इसलिए back बटन दो बार दबाना पड़ता है
    • SPA, History API का इस्तेमाल करके internal navigation history manage करते हैं। इसे रोकने पर उल्टा data loss हो सकता है
    • जानकारी के लिए, Firefox 47 के बाद browser.history.allowPushState deprecated हो चुका है। आजकल साइटों द्वारा history manipulate करने की समस्या लगभग नहीं के बराबर है। लेकिन Chrome में अभी भी back button hijacking बचा हुआ है, यह हैरानी की बात है। मैंने Firefox में एक खास keycode-blocking UserScript से इसका समाधान किया है

  • पहले मुझे लगा यह Android की बात है
    Android apps अक्सर “बाहर निकलने के लिए back दो बार दबाएँ” जैसी UX hijacking करती हैं। Reddit, TikTok और Instagram जैसी feed apps इसके प्रमुख उदाहरण हैं

    • मुझे भी पहले लगा यह Android की बात है, और मैं सोच रहा था कि लेख में “browser” बार-बार क्यों आ रहा है
    • सच में अच्छा होता अगर Google Android पर भी ऐसी policy लागू करता। सबसे बुरे तो apps ही हैं

  • काश ऐसी policy सबसे पहले LinkedIn पर लागू होती
    जब आप email या post link पर क्लिक करते हैं, तो post खुलती है, लेकिन back दबाने पर feed पर वापस ले जाया जाता है
    यह location.replace(...) और history.pushState() को मिलाकर history manipulation करने का तरीका है

    • Reddit भी इसी तरह back को intercept करता है। Google से Reddit post पर जाएँ और फिर back दबाएँ, तो Reddit की main feed पर लौट आते हैं
    • Gmail में भी ऐसा ही UX issue है। invitation mail के subject में “Accept” बटन होता है, इसलिए scroll करते समय गलती से क्लिक हो सकता है
    • मैं ऐसी साइटों के links हमेशा नए tab में खोलकर संभालता हूँ। tab बंद करना अब मेरा नया back button बन गया है। जिन tabs में रुचि नहीं होती, उन्हें बस बंद कर देता हूँ
    • Facebook भी इसी तरह काम करता है। इस explanation से अब उसकी working समझ में आई
    • लेकिन यह साफ़ नहीं है कि यह तरीका नई policy का violation है या नहीं। hash-based navigation तकनीकी रूप से वैध हो सकती है

  • Microsoft की साइटों में भी यह back button problem बहुत है

    • Azure Portal इसका सबसे अच्छा उदाहरण है। back दबाने पर क्या होगा, कुछ कहा नहीं जा सकता। Android के “lucky button” जैसा एहसास होता है
    • हालांकि MS का मामला ads redirects जैसी malicious हरकतों से ज़्यादा, बस JS redirect design problem के करीब लगता है
    • Epic Store में भी mobile पर checkout page से back जाना संभव नहीं होता। पता नहीं यह जानबूझकर है या सिर्फ़ UX mistake
    • मुझे भी कल ऐसी साइट मिली; जल्दी-जल्दी back दबाने पर भी कुछ नहीं हुआ, तो आखिरकार tab बंद करना पड़ा

  • यह कदम एक अच्छी शुरुआत है, लेकिन अब भी काफ़ी नहीं
    मैं नहीं चाहता कि कोई भी साइट मेरा back button hijack करे।
    खासकर “क्या आप वाकई निकलना चाहते हैं? आपने newsletter subscribe नहीं किया” जैसे popups सबसे खराब लगते हैं

    • SPA में यह अपवादस्वरूप ज़रूरी हो सकता है। क्योंकि app के भीतर user ने जिस रास्ते से navigation किया, उसे सही तरीके से track करना पड़ता है। लेकिन मूल सिद्धांत यही होना चाहिए कि “व्यवहार वैसा हो जैसा user उम्मीद करता है”
    • “बिना save किए बाहर निकलना चाहते हैं?” जैसी warnings उपयोगी हैं। लेकिन ideally साइट-वार allow settings होनी चाहिए
    • SaaS app चलाने वाले के रूप में, अगर form भरते समय user गलती से निकल जाए तो data खो सकता है, इसलिए हम ऐसी warnings दिखाते हैं। लेकिन user के नज़रिए से कौन-सा व्यवहार बेहतर है, इस पर मैं अब भी सोच रहा हूँ
    • जबरन नया tab खोलना भी एक तरह का hijacking है। ऐसी चीज़ों पर पूरी तरह रोक लगनी चाहिए। मुझे तो लगता है कि कानूनी कार्रवाई तक होनी चाहिए

  • “User experience सबसे ऊपर है” कहना, विडंबनापूर्ण है
    app की ओर धकेलने के लिए उलझाने वाले “Open in app” popups दिखाने वाली कंपनियाँ जब यह बात कहती हैं, तो अजीब लगता है
    संबंधित लेख: Those obnoxious sign-in windows

  • अभी Post/Redirect/Get pattern को फिर से लोकप्रिय बनाने का बढ़िया समय है
    Wikipedia की व्याख्या के अनुसार, form submit करने के बाद redirect होने से UX कहीं ज़्यादा smooth हो जाता है

    • एक पुराने developer के रूप में मुझे यह pattern सच में बहुत पसंद है। लगता है आज की React पीढ़ी ऐसी चीज़ों को ज़्यादा नहीं जानती
    • आज पहली बार इसके बारे में जाना। अब समझ आया कि यह pattern न हो तो “क्या आप form फिर से submit करना चाहते हैं?” popup क्यों आता है। इसका नाम भी पता चला, इसलिए काफ़ी उपयोगी लगा

  • Google के SPA framework Angular में भी redirect routes इस्तेमाल करने पर back hijacking हो सकता है
    इसका ज़िक्र Angular के आधिकारिक दस्तावेज़ में है

    • लेकिन SPA के अंदर की routing कई बार app UX के लिए अपरिहार्य होती है। ऐसे मामलों में hijacking केवल internal navigation को स्वाभाविक बनाए रखने के लिए ही स्वीकार्य होनी चाहिए