Hijacking-ul butonului Back devine încălcare Google: cum îți auditezi site-ul înainte de 15 iunie

Din 15 iunie 2026, Google va trata hijacking-ul butonului Back ca încălcare a politicilor sale privind spamul.

Pe scurt, vorbim despre paginile care împiedică utilizatorul să revină la rezultatele căutării după ce apasă butonul Back. În loc să ajungă înapoi în Google, vizitatorul este redirecționat către altă pagină, rămâne blocat într-o buclă sau trebuie să apese Back de mai multe ori.

Google spune clar că această practică afectează experiența utilizatorului și poate duce la acțiuni manuale, scăderi algoritmice sau eliminarea paginilor din rezultatele căutării.

Termenul este foarte apropiat. De aceea, dacă site-ul folosește scripturi de redirecționare, pop-up-uri agresive, rețele publicitare sau librării terțe pe care nu le-ai verificat recent, merită să faci un audit acum.

Ce este back button hijacking

Back button hijacking apare când un site manipulează istoricul browserului astfel încât butonul Back să nu mai facă ceea ce se așteaptă utilizatorul.

Un scenariu tipic arată așa:

utilizatorul caută ceva pe Google;
intră pe pagina ta;
decide că rezultatul nu îl ajută și apasă Back;
un script îl trimite către alt URL, reîncarcă pagina sau îl păstrează pe site;
utilizatorul trebuie să închidă tab-ul ori să apese Back în mod repetat.

Problema nu este simpla folosire a History API. Multe aplicații web legitime folosesc history.pushState() și history.replaceState() pentru navigare fără reîncărcarea completă a paginii.

Problema apare atunci când implementarea interferează intenționat cu navigarea înapoi sau împiedică revenirea la pagina anterioară.

Ce a anunțat Google

Google a anunțat schimbarea pe 14 aprilie 2026 și a oferit o perioadă de 60 de zile pentru remediere. Aplicarea noii politici începe pe 15 iunie 2026.

Conform anunțului Google Search Central:

hijacking-ul butonului Back intră explicit în politicile Google privind spamul;
site-urile pot fi afectate de acțiuni manuale sau sisteme automate;
paginile pot scădea în ranking sau pot dispărea complet din rezultate;
proprietarul site-ului rămâne responsabil inclusiv când problema este produsă de o librărie terță sau de o platformă publicitară.

Ultimul punct este important. Faptul că nu ai scris personal scriptul nu elimină riscul SEO.

De ce această practică este o problemă reală

Un site bun îi ajută pe oameni să ia o decizie. Nu îi forțează să rămână.

Hijacking-ul butonului Back produce efectul opus:

blochează o acțiune normală a browserului;
distruge încrederea în site;
poate ascunde redirecționări nedorite sau pagini înșelătoare;
afectează mai ales utilizatorii mobili;
poate fi introdus de scripturi compromise sau rețele publicitare agresive;
transformă o problemă de UX într-un risc direct pentru vizibilitatea organică.

Dacă site-ul are deja probleme tehnice, merită să pornești de la un audit SEO pentru site de prezentare și să incluzi testarea navigării în audit.

Cum îți auditezi site-ul înainte de 15 iunie

Auditul trebuie să combine testarea manuală, verificarea codului și analiza scripturilor terțe. Un crawler SEO obișnuit poate să nu observe comportamentul, deoarece problema apare în browser, după interacțiunea utilizatorului.

1. Testează manual paginile importante

Deschide o fereastră incognito și caută pe Google brandul, serviciile sau paginile importante ale site-ului.

Pentru fiecare rezultat:

intră pe pagină din Google;
așteaptă câteva secunde;
derulează pagina și interacționează cu elementele principale;
închide eventualele pop-up-uri;
apasă Back o singură dată.

Ar trebui să revii direct la rezultatele Google. Repetă testul pe desktop și mobil, în mai multe browsere.

Nu testa doar homepage-ul. Verifică:

paginile de servicii;
landing page-urile folosite în reclame;
articolele de blog;
paginile care afișează pop-up-uri;
paginile cu scripturi, widget-uri sau reclame diferite;
paginile cu cel mai mult trafic organic.

2. Verifică istoricul browserului

În Chrome DevTools, deschide consola și rulează:

history.length

Reține valoarea la intrarea pe pagină, apoi repetă comanda după câteva secunde și după interacțiuni. O creștere neașteptată, fără navigare reală, poate indica faptul că un script adaugă intrări artificiale în istoric.

Aceasta nu dovedește singură o încălcare. Este doar un semnal care trebuie investigat.

3. Caută implementările care modifică istoricul

În cod și în fișierele JavaScript încărcate de pagină, caută:

history.pushState
history.replaceState
window.onpopstate
addEventListener("popstate"
location.replace
location.href

Aceste funcții au utilizări legitime. Verifică însă ce se întâmplă când utilizatorul apasă Back:

este adăugată imediat o nouă intrare în istoric?
utilizatorul este trimis către o pagină promoțională?
pagina se reîncarcă și îl ține pe același URL?
apare o buclă de navigare?
comportamentul este diferit după ce pagina este deschisă din Google?

Nu șterge automat orice utilizare a History API. Repară logica ce împiedică navigarea normală.

4. Auditează scripturile terțe

Google avertizează explicit că problema poate veni din librării și platforme publicitare terțe.

Inventariază:

tag-urile din Google Tag Manager;
widget-urile de chat;
soluțiile de pop-up și exit intent;
scripturile de afiliere;
rețelele publicitare;
tool-urile de analytics mai puțin cunoscute;
plugin-urile și temele CMS;
scripturile încărcate de pe domenii externe.

În DevTools, fila Network te ajută să vezi domeniile și fișierele încărcate. Dezactivează temporar scripturile suspecte într-un mediu de test și repetă auditul.

Dacă problema dispare după dezactivarea unui furnizor, elimină integrarea sau cere o versiune remediată înainte de a o reactiva.

5. Testează condițiile în care comportamentul poate fi ascuns

Unele implementări nu apar la fiecare vizită. Pot depinde de:

dispozitiv sau browser;
sursa traficului;
țară;
prima vizită;
acceptarea cookie-urilor;
un anumit interval de timp;
o campanie publicitară;
un experiment A/B.

Testează cu și fără consimțământ pentru cookie-uri, pe mobil și desktop, autentificat și neautentificat, precum și din mai multe surse de trafic.

6. Verifică Google Search Console

După 15 iunie, urmărește secțiunea Manual actions din Google Search Console și variațiile neobișnuite ale traficului organic.

Absența unei acțiuni manuale nu înseamnă că totul este în regulă. Google poate aplica și sisteme automate, iar acestea nu vin neapărat cu o notificare individuală.

Pentru monitorizare, compară:

clickurile și impresiile înainte și după 15 iunie;
paginile cu cele mai mari scăderi;
query-urile afectate;
dispozitivele și țările;
modificările recente de cod, tag-uri și plugin-uri.

Ghidul despre ce să faci când scade traficul după un update Google explică cum separi o fluctuație normală de o problemă care necesită intervenție.

Checklist rapid pentru proprietarul site-ului

Înainte de 15 iunie, confirmă că:

o singură apăsare pe Back revine la pagina anterioară;
navigarea funcționează corect pe mobil și desktop;
nu există redirecționări la apăsarea butonului Back;
pop-up-urile și mesajele de exit intent nu blochează navigarea;
scripturile terțe și tag-urile au fost inventariate;
plugin-urile și librăriile sunt actualizate;
History API este folosit doar pentru navigare legitimă;
modificările sunt testate într-un mediu de staging;
Search Console este monitorizat;
există o persoană responsabilă pentru remediere.

Ce trebuie să faci dacă găsești problema

Oprește mai întâi scriptul sau integrarea care produce comportamentul. Nu încerca să maschezi problema doar pentru Googlebot și nu crea excepții în funcție de user-agent. Asta poate introduce alte riscuri și nu repară experiența utilizatorului.

Apoi:

identifică sursa exactă;
elimină sau corectează logica de manipulare a istoricului;
testează toate traseele de navigare;
publică remedierea;
monitorizează Search Console și datele analytics.

Dacă ai primit deja o acțiune manuală, remediază problema pe întregul site și trimite o cerere de reconsiderare din Search Console.

Concluzie

Schimbarea nu interzice aplicațiile web moderne și nici folosirea legitimă a History API. Google vizează comportamentul înșelător care împiedică utilizatorul să plece.

Până pe 15 iunie 2026, verifică mai ales paginile cu scripturi terțe, reclame, pop-up-uri și logică de navigare personalizată. Un test manual de câteva minute poate descoperi o problemă care altfel ar afecta încrederea utilizatorilor și vizibilitatea în Google.

Pentru o analiză tehnică mai largă, vezi serviciul nostru de SEO și prezență online. Putem verifica implementarea, scripturile terțe, indexarea și riscurile tehnice, apoi prioritizăm remedierea. Pentru probleme care cer modificări în site, vezi și serviciul de dezvoltare web sau trimite-ne detaliile proiectului.