Google gaat websites straffen in zoekmachine voor 'kapen terug-knop'

De Google-zoekmachine gaat sites lager waarderen als die gebruik maken van scripts die ervoor zorgen dat gebruikers met een druk op de terug-knop in de browser niet op de vorige pagina komen. Voortaan ziet Google dit als kwaadaardige praktijk.

Websites hebben twee maanden om wijzigingen te maken voor de Google-zoekmachine gaat zorgen dat die sites lager komen in zoekresultaten, meldt het bedrijf. Google ziet dat de praktijk om de terug-knop te kapen vaker voorkomt dan voorheen en hoopt met deze actie dat een halt toe te roepen.

Als sites met een script van zichzelf of een adverteerder de terug-knop kapen, dan komt de gebruiker niet terug op de vorige pagina, maar blijft die op de huidige pagina of ziet op een andere manier een advertentie. Omdat er niet gebeurt wat de gebruiker mag verwachten van een actie, ziet Google dat vanaf juni als kwaadaardige praktijk. "Wij vinden dat de gebruikerservaring voorop staat. Het kapen van de terugknop verstoort de functionaliteit van de browser, onderbreekt de verwachte gebruikerservaring en leidt tot frustratie bij de gebruiker."

Veel sites zijn voor een groot deel van hun verkeer afhankelijk van de zoekmachine van Google en als dat terugloopt, dan zullen zij vermoedelijk geneigd zijn om hun scripts aan te passen. Het kapen van de terug-knop in de browser bestaat al jaren op internet. Google is er ook al jaren mee bezig.

Terugknop in de browser

Door Arnoud Wokke

Redacteur Tweakers

14-04-2026 • 17:13

60

Reacties (60)

Sorteer op:

Weergave:

Is dit vergelijkbaar met wat Tweakers met de pricewatch nu doet, waar de terugknop je naar het vorige kopje stuurt? Of wordt je alleen gestraft als het puur misbruikt wordt om gebruikers op een pagina te houden?
Nee absoluut niet. Hoewel ik het een erg onhandig systeem vind van Tweakers (en via JS juist kunt voorkomen), is dit niet wat Google (terrecht) tegen wilt gaan.

Google heeft het over websites dies door middel van history.pushState(), "nep" entries aan te "go back"-stack toevoegen en de gebruiker dan vaak redirecten, met als doel het verlaten van de site te verhinderen/bemoeilijken.


Normaal gesproken worden de URL waar je op klikt vanzelf toegevoegd aan de sessie geschiedenis, waardoor je door middel van de terug knop terug kan gaan. Websites kunnen echter via JavaScript beheren wat daar daar in staat.
Dit klinkt misschien apart, maar het is vooral handig bij SPA's (Single Page Application). Daarbij navigeer je niet echt naar een nieuwe pagina waneer je rondklikt, maar wordt er d.m.v. JS de pagina "omgebouwd" (en meestal ook nieuwe content ingeladen via AJAX/Fetch). Hierbij hoef er niet steeds voor iedere klik een volledige pagina herlading plaats te vinden.
Omdat je dan niet echt van pagina wisselt zou een terug knop je gelijk naar de vorige URL sturen, terwijl de gebruiker dat meestal niet wilt. Daarom bestaat de optie om "nep" URL visits aan de sessie geschiedenis toe te voegen.

Ik ben er vrij zeker van dat dingen als wat van Tweakers doet hier niet onder vallen omdat alle URL entries 100% door acties van de gebruiker komen (vermoed ik), en niet JavaScript.

[Reactie gewijzigd door DvanRaai89 op 14 april 2026 22:36]

Genoeg SPA's die het navigeren doen door de ankers in de url te veranderen. Dat zou dan gewoon netjes moeten werken met de vorige en volgende knoppen
Dat is een goede vraag, Google stelt het eerst heel stellig dat het gaat om het verwachte gedrag:
Terug naar de vorige pagina, maar geeft daarna voorbeelden die niet dit soort navigatie omvat maar echt voorkomt dat je weg kan navigeren.
When a user clicks the "back" button in the browser, they have a clear expectation: they want to return to the previous page. Back button hijacking breaks this fundamental expectation. It occurs when a site interferes with a user's browser navigation and prevents them from using their back button to immediately get back to the page they came from. Instead, users might be sent to pages they never visited before, be presented with unsolicited recommendations or ads, or are otherwise just prevented from normally browsing the web.
Wat Tweakers doet is valt een beetje in een grijs gebied met deze informatie. Het zorgt er uiteindelijk niet voor dat je niet terug naar een vorige pagina kan gaan maar het voegt wel een navigatie stap toe als je ergens op geklikt hebt.
Dit valt naar mijn mening niet onder wat google bedoeld. Je gaat immers een soort van pagina terug en komt uiteindelijk ook echt op de vorige pagina. Bij de methode die google beschrijft, kom je nooit terug op een vorige pagina, al klik je een miljoen keer op de terug knop.

Soms lukt het om heel snel achter elkaar op de terugknop te klikken, maar zelfs dat werkt niet altijd.
Wat natuurlijk wél werkt is om meerdere pagina's in één keer terug te gaan. Bij firefox (en vast ook andere browsers) kan dat simpelweg via een rechtermuisklik op de terug-knop.
Back button hijacking is wel echt anders - bij anchor links kan je vaak zelfs nog 2x klikken om toch terug te gaan. De echte "hijacking" gaat zo;

Google -> click -> A -> force-redirect naar B -> B

Als de gebruiker dan op "terug" klikt komt ie op A en die forceert je weer terug naar B. Dit gaat vaak zelfs met Javascript dus vrijwel direct, op deze manier "kan je niet meer terug".

Wat tweakers toepast is wel echt iets anders.
Bedoel je wanneer je een verkoper aanklikt? Want die paginas openen in een nieuw tablad bij mij, en dat is eigenlijk de juiste manier om naar andere websites te linken.
Nee als je klikt op Pricewatch en je selecteerd bijvoorbeeld een andere categorie in het overzicht wat je voor je krijgt voegt dit #highlightCat:<id> toe aan je URL.

Je history word dus bij elke klik op een categorie voorzien van een nieuwe url met navigatie naar een kop.
Als je op terug klikt ga je dus naar de vorige highlight in plaats van de vorige pagina.

Dit gebeurt overigens op meer sites en volgens mij ook op meer plekken binnen Tweakers. Vaak als je op een inhoudsopgave klikt en je browser scrolt naar de kop, en ga je met terug dus naar de index terug en niet een andere pagina.
Dit is op desktop overigens, mobiel weet ik niet.

[Reactie gewijzigd door LOTG op 14 april 2026 17:35]

Dat zijn anchor/jump links, meestal een fijne toevoeging, soms wat irritant, maar dat valt bij deze niet onder kapen, net zoals bij Wikipedia (en andere index gebruikende sites).

[Reactie gewijzigd door dakka op 14 april 2026 17:41]

Dat is de vraag, ik zie namelijk geen uitzondering hier voor en het voldoet aan de stelling van Google.
If you're currently using any script or technique that inserts or replaces deceptive or manipulative pages into a user's browser history that prevents them from using their back button to immediately get back to the page they came from, you are expected to remove or disable it.
Ik ben het er mee eens dat de functie handig is maar het doet exact wat Google niet wil.

Het woordje 'onmiddellijk" is wat mij aan het twijfelen brengt, want dat is exact wat dit dus voorkomt.
Het zal dan ook van de intentie afhangen, als jouw pagina gewoon normaal gebruik maakt hiervan dan is er niks aan de hand, maar als je een pagina hebt met een javascriptje die je navigation history vol gooit met troep dan zal hun crawler daar wel wat van vinden.

Verder zal de SEO tool van menig developer wel oppikken of hun navigatie gedrag wel voldoet aan de richtlijnen, maar een harde lijst van wat wel en wat niet, zal Google waarschijnlijk niet publiceren.

[Reactie gewijzigd door dakka op 14 april 2026 17:54]

Google heeft geen mogelijkheid om de werkelijke intentie te controleren. En zo te lezen vragen ze er ook niet om. Hun eis lijkt dus om binnen de komende weken te gaan voldoen of anders de gevolgen te ondervinden. Ongeacht of je als websitebouwer goede intenties hebt.
maar anchors zijn "back to where you came from"

bv een hoofdstuk indeling waar je naar de hoofdstuk zelf kunt springen

dan is back terug naar de indeling (voor een gebruiker zou dat zelfs lijken op een andere pagina)
Ik vind de uitleg van google inderdaad niet voldoende. Ze zeggen "back to the page they came from" waarbij het springen tussen anchors op dezelfde pagina dus tot probleem gemaakt wordt.

Het grote probleem met het kapen van de terug-knop is wanneer partijen niet netjes een recent history stack aflopen, maar de pagina waar je van weg wilt terug op die stack blijven pushen. Daar zou het onderscheid in moeten zitten. Die stack moet uitsluitend bestaan uit expliciete navigatiehandelingen van de gebruiker en niet door de website gemanipuleerd worden.

[Reactie gewijzigd door ZinloosGeweldig op 14 april 2026 18:34]

Ik ga er van uit dat de sleutelwoorden "inserts or replaces" zijn. In het geval van anchor links pas je de historie niet aan dus dat zal geen effect hebben op de score. Zou opzich ook wel heel vreemd zijn als ze van een algemene standaard een probleem maken.
-snip- comment als reactie op juiste post gemaakt

[Reactie gewijzigd door DdeM op 14 april 2026 19:56]

Nee, dat is niet vergelijkbaar. Tweakers gebruikt gewoon anchor links naar elementen (Pricewatch categorieen) op dezelfde pagina, dat is onschuldig.

Waar Google het over heeft zijn pure blackhat methoden om de gebruiker bewust te benadelen door het link gedrag van de browser d.m.v. JavaScript op misleidende en bewust wijze negatief te beinvloeden. Dus denk aan back button hijacking en reverse tabnabbing, waarbij de gebruiker niet meer terug kan naar de oorspronkelijke pagina/site.

Sites waar veel links op voorkomen, kunnen rel="noopener" gebruik om zich te beschermen, maar moderne browsers hebben dit tegenwoordig mogelijk standaard al ingebakken. Sites als Reddit hebben dit dan ook extra hard nodig. Hetzelfde zou je verwachten bij GoT, maar die heeft dat weer niet, maar Tweakers frontpage heeft het weer wel voor de reacties.
Dat vind ik nog eens een goede vooruitgang. Het gebeurd niet vaak bij me, en vaak kan je er alsnog omheen door met je rechter muisknop op de terug te drukken en daar terug te gaan, maar het is erg schofterig om zoiets moedwillig in te bouwen.
De knop voor vorige via context menu is overal beschikbaar, daar hoef je niet voor op de back pijl te klikken. ;) Al krijg je in sommige browsers wel weer een context menu met vorig geopende pagina's, dus kan je zelfs meerdere sprongen in 1x maken.

[Reactie gewijzigd door CH4OS op 14 april 2026 17:20]

Eindelijk! Mooi! Ze mogen wat mij betreft wel meer van dat soort anti-patterns bestraffen. Zoals een soort van progressbar bovenaan je scherm die aangeeft waar je ben met lezen (waar the f... is die scrollbar aan de zijkant dan voor). Of die sites die je na een stukje scrollen midden in je beeld een "popup" tonen voor hun nieuwsbrief. Of die halve gare paywall sites die tijdens het laden eerst alle content laten zien en dan bijna alles (client-side!) wegblurren en je eisen je aan te melden. Het zijn al dat soort hufter UI acties die wat mij betreft vrolijk bestraft mogen worden.
Die scrollbar is de hele pagina, de progressbar vaak alleen het artikel dat je leest
Yup, wat ze vaak dan ook gelijk weer om zeep helpen door er een mooie grote vette advertentie on-the-fly in te harken zodra je in het artikel gaat lezen. Die top scrollbar is nutteloos en vaak ook nog afleidend.
Zeer irritant gedrag, voornamelijk te zien bij pagina's met ads, maar moet google, als een van de grootste ads bedrijven hier nu de politieman zijn?
Ja inderdaad. De grandfather van de dark patterns, onbewuste sturing en profiling spreekt zich uit. Erg lachwekkend. Ja, nee, wij zijn nobele browserbouwers en we willen niet dat gebruikers gemanipuleerd worden hoor.

Hou toch op :-)
Daar gaat de Microsoft helpdesk. Onbegrijpelijk dat zo'n groot bedrijf dat doet trouwens.
Die zullen wel niet heel erg malen om seo ranking
Precies, die zien juist liever dat zo min mogelijk mensen contact met hun opneemt.
Contact? Het is gewoon de KB (knowledge base/KennisBank) waar je op terecht komt. Daar komt geen poppetje aan te pas.
Precies. Wat een ergernis is dat zeg.
Microsoft websites hebben er een handje van dat als je terug wilt dat niet meer lukt!
Goede actie
In mijn ervaring hebben ze bij Microsoft al tientallen jaren gewoon onnodig veel redirects, waardoor je met 1x op terug klikken niet ver genoeg terug gaat. Als je dan de terugknop ingedrukt houdt kan je wat stappen overslaan en kom je wel waar je wil zijn. Dat is wat anders dan de volledige geschiedenis herschrijven zodat die terugknop grijs wordt.
Als je netjes 30X redirects gebruikt kun je er 19 achter elkaar chainen en maakt het voor je back-geschiedenis niets uit. En 20 is alleen maar een probleem omdat de meeste browsers dat als arbitraire limiet voor ERR_TOO_MANY_REDIRECTS hebben gekozen. Alleen Microsoft heeft er een handje van om meta refresh redirects te gebruiken, wat nou precies zo'n trucje is waarmee je de terug knop kan kapen.
Hebben ze niet daarom recent hun migratie naar productnaam.cloud.microsoft aangekondigd? Als one domain to rule them all? Uiteraard heb je het XKCD-probleem waarbij er dus nog een domein/standaard bij komt, maar het idee is goed.

https://techcommunity.microsoft.com/blog/microsoft_365blog/introducing-cloud-microsoft-a-unified-domain-for-microsoft-365-apps-and-services/3804961
Weet niet of dat de reden is geweest, maar een redirect is een redirect, of het nu op hetzelfde domein blijft of niet.
Idd bij hun gebeurt mijn het het vaakst
Dit is een mooie ontwikkeling.
Websites die gebruikers pesten moeten ontmoedigd worden. En gezien veel verkeer toch via zoekmachines komt lijkt me dit effectief om te ontmoedigen.
Eindelijk! Zo vervelend altijd en het zorgt er volgens mij juist voor dat bezoekers helemaal weg gaan van zo een site en juist niet meer terugkomen.

Ik wel in ieder geval.

Goed dat Google hier eindelijk iets aan wil doen.
Heel mooi dit, gebeurt mij niet vaak. Maar het is wel rete irritant als wel gebeurt.

Goed even lange druk op terug knop, en dan resultaat aanklikken je terug wil kan ook. Maar zo hoort het gewoon niet te werken.
Ein-de-lijk. Ik heb het hierover ook al eens vaker in de comments gehad, waarop je ge-mint wordt. Laat die terugknop gewoon doen waar hij voor bedoeld is. Veel gebruiksvriendelijker.

Om te kunnen reageren moet je ingelogd zijn