Google heeft een update doorgevoerd waarbij organische zoekresultaten niet langer direct linken naar de bestemming, maar via google.com/goto. In tegenstelling tot eerdere redirect-wrappers is de nieuwe url-parameter ondoorzichtig, waardoor scrapers de uiteindelijke URL niet meer offline kunnen decoderen. Om de bestemming te achterhalen, is nu een specifiek HTTP-verzoek nodig om de Location-header uit te lezen.
Het doel van deze wijziging is het bestrijden van grootschalige SERP-scraping. Doordat elk resultaat nu een individueel verzoek aan Google vereist, wordt het proces voor scrapers trager en is het voor Google eenvoudiger om bot-gedrag te detecteren. Autom.dev heeft hun pipeline reeds aangepast om deze links automatisch te resolveren voor hun API-klanten.
google.com/goto: De anti-scraping update van Google
Wat er aan de hand is
Google Search herschrijft organische resultaatlinks naar google.com/goto?url=... in plaats van de bestemmings-URL direct in de HTML te tonen.
Wanneer je op een resultaat klikt, wordt je doorgeleid naar de eigenlijke pagina. De url-parameter maakt gebruik van een eigen, Google-specifieke codering; het is geen eenvoudige base64-codering van de doel-URL. In de praktijk lijkt het op een ondoorzichtige referentie naar het indexrecord van Google voor die pagina.
Sinds eind augustus 2026 is dit consequent zichtbaar bij zoekopdrachten wanneer je bent uitgelogd of in de privémodus browst. Het kan nog een experiment zijn, maar het is niet langer beperkt tot een klein deel van de SERP's (Search Engine Result Pages).
Niet hetzelfde als google.com/url
Google heeft eerder redirect-wrappers gebruikt. Het oudere formaat is google.com/url?q=[URL-encoded destination], waarbij de doellink leesbaar is in de query-string.
Het nieuwe 'goto'-formaat is anders:
- De resultaat-href is
/goto, niet de bestemming.
- Je kunt de
url= blob niet offline decoderen.
- De werkelijke URL staat in de
Location-header op /goto. Verzoek die URL, maar volg de redirect niet.
Google heeft de bestemming nog steeds nodig om de SERP te genereren (domein, favicon, attributie), dus kopieën van de URL blijven op de pagina staan. Dat is een apart verhaal ten opzichte van het lezen van de Location. De handleiding hiervoor is te vinden onder: google.com/goto: read Location with HEAD.
Deze verschuiving is van belang voor iedereen die op grote schaal een zoekindex opbouwt op basis van SERP-data.
Waarom Google dit doet
Dit past in de bredere inspanningen van Google tegen het geautomatiseerd oogsten van SERP-data, met name door AI-crawlers en SEO-scrapers die resultaat-URL's in bulk extraheren om hun eigen indexen op te bouwen.
Met platte tekstlinks kon een scraper duizenden URL's uit de HTML parsen zonder Google opnieuw aan te roepen. Met 'goto' is voor elk resultaat een nieuw verzoek aan Google nodig om de bestemming te achterhalen. Je leest de Location zonder de link naar de uiteindelijke pagina te volgen. Dit proces is trager, veroorzaakt meer 'ruis' en geeft Google een duidelijk signaal wanneer dezelfde client honderden links na elkaar resolvert.
In combinatie met eerdere stappen, zoals het verwijderen van &num=100 en het aanscherpen van BotGuard/SearchGuard, verhoogt Google gestaag de kosten voor naïv SERP-scraping.
Wat we zagen bij Autom
We zagen de 'goto'-links voor het eerst op een klein percentage van de SERP's. Op dat niveau was het moeilijk om een betrouwbare oplossing te implementeren zonder de responsen voor andere gebruikers te verstoren.
Sinds eind augustus 2026 is het patroon veel consistenter voor uitgelogde sessies en privémodus. Resultaat-URL's op Google Search zijn onder deze omstandigheden effectief allemaal 'goto'. We hebben de uitrol gemonitord en hierop getest.
Update bij Autom.dev
We hebben onze Google Search-pipeline bijgewerkt om google.com/goto-links te resolveren (lezen van de Location, geen 'follow') en de uiteindelijke bestemmings-URL terug te geven in de API-responsen, in dezelfde gestructureerde velden die klanten al gebruiken.
Als je de Google Search-endpoints van Autom aanroept, blijf je bruikbare bestemmings-URL's ontvangen zonder dat je je integratie hoeft aan te passen. We blijven de uitrol van Google in de gaten houden en passen ons aan als het redirect-formaat opnieuw verandert.
Verdere lectuur
- google.com/goto: read Location with HEAD
- Google killed num=100
- Google sues SerpAPI: What SearchGuard reveals
- Scraping SERP with Google, Bing, and Brave
google.com/goto: De anti-scraping update van Google
Wat er aan de hand is
Google Search herschrijft organische resultaatlinks naar google.com/goto?url=... in plaats van de bestemmings-URL direct in de HTML te tonen.
Wanneer je op een resultaat klikt, wordt je doorgeleid naar de eigenlijke pagina. De url-parameter maakt gebruik van een eigen, Google-specifieke codering; het is geen eenvoudige base64-codering van de doel-URL. In de praktijk lijkt het op een ondoorzichtige referentie naar het indexrecord van Google voor die pagina.
Sinds eind augustus 2026 is dit consequent zichtbaar bij zoekopdrachten wanneer je bent uitgelogd of in de privémodus browst. Het kan nog een experiment zijn, maar het is niet langer beperkt tot een klein deel van de SERP's (Search Engine Result Pages).
Niet hetzelfde als google.com/url
Google heeft eerder redirect-wrappers gebruikt. Het oudere formaat is google.com/url?q=[URL-encoded destination], waarbij de doellink leesbaar is in de query-string.
Het nieuwe 'goto'-formaat is anders:
- De resultaat-href is
/goto, niet de bestemming.
- Je kunt de
url= blob niet offline decoderen.
- De werkelijke URL staat in de
Location-header op /goto. Verzoek die URL, maar volg de redirect niet.
Google heeft de bestemming nog steeds nodig om de SERP te genereren (domein, favicon, attributie), dus kopieën van de URL blijven op de pagina staan. Dat is een apart verhaal ten opzichte van het lezen van de Location. De handleiding hiervoor is te vinden onder: google.com/goto: read Location with HEAD.
Deze verschuiving is van belang voor iedereen die op grote schaal een zoekindex opbouwt op basis van SERP-data.
Waarom Google dit doet
Dit past in de bredere inspanningen van Google tegen het geautomatiseerd oogsten van SERP-data, met name door AI-crawlers en SEO-scrapers die resultaat-URL's in bulk extraheren om hun eigen indexen op te bouwen.
Met platte tekstlinks kon een scraper duizenden URL's uit de HTML parsen zonder Google opnieuw aan te roepen. Met 'goto' is voor elk resultaat een nieuw verzoek aan Google nodig om de bestemming te achterhalen. Je leest de Location zonder de link naar de uiteindelijke pagina te volgen. Dit proces is trager, veroorzaakt meer 'ruis' en geeft Google een duidelijk signaal wanneer dezelfde client honderden links na elkaar resolvert.
In combinatie met eerdere stappen, zoals het verwijderen van &num=100 en het aanscherpen van BotGuard/SearchGuard, verhoogt Google gestaag de kosten voor naïv SERP-scraping.
Wat we zagen bij Autom
We zagen de 'goto'-links voor het eerst op een klein percentage van de SERP's. Op dat niveau was het moeilijk om een betrouwbare oplossing te implementeren zonder de responsen voor andere gebruikers te verstoren.
Sinds eind augustus 2026 is het patroon veel consistenter voor uitgelogde sessies en privémodus. Resultaat-URL's op Google Search zijn onder deze omstandigheden effectief allemaal 'goto'. We hebben de uitrol gemonitord en hierop getest.
Update bij Autom.dev
We hebben onze Google Search-pipeline bijgewerkt om google.com/goto-links te resolveren (lezen van de Location, geen 'follow') en de uiteindelijke bestemmings-URL terug te geven in de API-responsen, in dezelfde gestructureerde velden die klanten al gebruiken.
Als je de Google Search-endpoints van Autom aanroept, blijf je bruikbare bestemmings-URL's ontvangen zonder dat je je integratie hoeft aan te passen. We blijven de uitrol van Google in de gaten houden en passen ons aan als het redirect-formaat opnieuw verandert.
Verdere lectuur
- google.com/goto: read Location with HEAD
- Google killed num=100
- Google sues SerpAPI: What SearchGuard reveals
- Scraping SERP with Google, Bing, and Brave
Groetjes,