Przejmowanie przycisku Wstecz: nowa zasada Google dotycząca spamu już obowiązuje

Przejmowanie przycisku Wstecz (back button hijacking) jest teraz wprost naruszeniem zasad Google dotyczących spamu. Egzekwowanie zaczęło się 15 czerwca 2026 r. Każdy skrypt, który nie pozwala użytkownikowi wrócić na stronę, z której przyszedł, naraża więc Twoją witrynę w wyszukiwarce. Kto ryzykuje najbardziej? Właściciele, którzy zarabiają na sieciach reklamowych i zewnętrznym kodzie, którego sami nie pisali. Poniżej wyjaśniamy, co mówi zasada, gdzie zwykle kryje się problem oraz jak go wykryć i usunąć.

Czym jest przejmowanie przycisku Wstecz według zasad Google dotyczących spamu?

Witryna zakłóca nawigację w przeglądarce, manipulując historią lub innymi funkcjami, a użytkownik nie może od razu wrócić na stronę, z której przyszedł. Tak właśnie przejmowanie przycisku Wstecz definiują zasady Google dotyczące spamu w wyszukiwarce. Zamiast na poprzednią stronę ludzie trafiają pod adresy, których nigdy nie odwiedzali, dostają niechciane rekomendacje lub reklamy albo po prostu nie mogą normalnie przeglądać sieci.

Praktyka ta należy teraz do zasad dotyczących złośliwych praktyk. I nie jest to tak naprawdę nic nowego: Google zaznacza, że wstawianie zwodniczych lub manipulacyjnych stron do historii użytkownika już wcześniej było sprzeczne z Search Essentials.

Co zmieniło się 13 kwietnia i 15 czerwca 2026 r.?

Google opublikowało zasadę 13 kwietnia 2026 r., a egzekwować ją zaczęło 15 czerwca 2026 r. Właściciele dostali więc dwa miesiące na przygotowanie, o czym mówi komunikat Google o przejmowaniu przycisku Wstecz. Strony, które stosują tę praktykę, mogą zostać objęte ręcznymi działaniami za spam albo automatycznym obniżeniem pozycji.

Wymaganie jest postawione wprost: usuń lub wyłącz każdy skrypt i każdą technikę, która wstawia zwodnicze lub manipulacyjne strony do historii przeglądarki albo je w niej podmienia.

Dlaczego źródłem są zwykle skrypty reklamowe i zewnętrzne biblioteki

Często winny kod nie jest nawet Twój. Google podaje, że część przypadków pochodzi z bibliotek dołączonych do witryny albo z jej platformy reklamowej. Odpowiedzialność nie przechodzi jednak razem z kodem. Za wszystko, co działa na stronie, odpowiadasz Ty, więc to, co skrypty reklamowe robią z przyciskiem Wstecz, wymaga takiego samego przeglądu jak własny JavaScript.

Jeden skrypt wywołuje history.pushState albo replaceState, żeby dodać dodatkowe wpisy. Inny nasłuchuje zdarzenia popstate, które uruchamia się po naciśnięciu przycisku Wstecz, i odsyła użytkownika w inne miejsce.

Czy w takim razie każde użycie History API jest problemem? Nie. Aplikacje jednostronicowe korzystają z niego, żeby zapisywać rzeczywiste stany nawigacji, na przykład otwarty produkt albo zmieniony filtr. Kłopot zaczyna się wtedy, gdy wpis istnieje tylko po to, żeby zatrzymać użytkownika albo pokazać mu treść, o którą nikt nie prosił.

Jak sprawdzić, czy witryna manipuluje historią przeglądarki

Najszybszy test: wejdź na stronę z wyniku wyszukiwania i naciśnij Wstecz jeden raz. Powinieneś znów zobaczyć stronę wyników. Przeprowadź go tak, jak zrobiłby to prawdziwy użytkownik:

1. Otwórz stronę z Google na telefonie i na komputerze.
2. Naciśnij Wstecz od razu po załadowaniu.
3. Powtórz po przewinięciu strony, a potem po użyciu któregoś widżetu.
4. Przejdź przez najważniejsze szablony: artykuł, kategoria, landing page.
5. Przetestuj z ładującymi się reklamami, a potem jeszcze raz w czystym profilu przeglądarki.

Sygnały ostrzegawcze? Konieczność drugiego naciśnięcia, pojawienie się strony z rekomendacjami lub reklamami albo ponowne załadowanie tego samego adresu. Przyjrzyj się też przeskokom między kliknięciem w wyszukiwarce a końcowym adresem na Twoim serwerze źródłowym, bo łańcuchy przekierowań na NGINX mogą zostawiać dodatkowe kroki, przez które droga powrotna wydaje się zepsuta.

Audyt skryptów, reklam pełnoekranowych i widżetów, które dodają wpisy do historii

Znajdź każdy skrypt, który zapisuje coś w historii albo reaguje na zdarzenie cofania, a potem usuń lub wyłącz te, które zatrzymują użytkowników na stronie wbrew ich woli. Robocza lista kontrolna:

• Przeszukaj kod i menedżera tagów pod kątem pushState, replaceState, popstate i zmian lokalizacji.
• Spisz wszystkie tagi reklamowe, widżety rekomendacji i narzędzia typu exit-intent.
• Wyłączaj je po kolei i za każdym razem powtarzaj test przycisku Wstecz.
• Zapytaj sieć reklamową o ustawienie, które wyłącza to zachowanie.
• Zrezygnuj z dostawcy, jeśli takiej opcji nie ma.

Sprawdzenia wymagają też plansze pełnoekranowe zależne od lokalizacji lub urządzenia, bo przekierowywanie użytkowników według IP dodaje przeskok, zanim pojawi się treść. Jeśli przed Twoim obecnym hostingiem stoi reverse proxy NGINX z adresami z UE lub USA, takie jak Jalvo, skrypty nadal znajdują się na serwerze źródłowym i w CMS-ie. Dlatego to tam przeprowadza się audyt.

Co zrobić po ręcznym działaniu za przejmowanie przycisku Wstecz

Usuń lub wyłącz odpowiedzialny kod, a potem potwierdź efekt tym samym testem przycisku Wstecz, zanim skontaktujesz się z Google. Prośba o ponowne rozpatrzenie ma sens dopiero wtedy, gdy strona zachowuje się poprawnie na każdym szablonie.

Zapisz, co zostało usunięte: nazwę skryptu, dostawcę, szablony, których to dotyczyło, i datę. Taki zapis pozwala dokładnie opisać poprawkę i rozpoznać tę samą bibliotekę, jeśli wróci po cichu przez inny tag.

Unikanie przejmowania przycisku Wstecz to po prostu rutyna: testuj wejście z wyszukiwarki, sprawdzaj zewnętrzny kod i powtarzaj test po każdej zmianie w zestawie narzędzi reklamowych.

FAQ