Google.com/goto: Googles Anti-Scraping-Update erschwert das Extrahieren jedes Ergebnisses

Google hat zwischen Suchergebnissen und Zielseiten eine zusätzliche Anfrage eingefügt und damit einen direkten Konflikt mit Tools geschaffen, die Ergebnis-URLs im großen Maßstab sammeln. Die als google.com/goto: Googles Anti-Scraping-Update bekannte Änderung ersetzt viele direkte organische Links durch undurchsichtige Google-Weiterleitungsadressen.

Für Menschen sieht das Suchergebnis weiterhin vertraut aus. Titel, angezeigte Domain, Favicon und Beschreibung bleiben sichtbar. Der zugrunde liegende Link kann nun jedoch statt auf die Seite des Publishers auf google.com/goto?url=... verweisen.

Dieser Unterschied ist relevant, weil der kodierte Wert die vollständige Ziel-URL nicht offenlegt. Ein Browser kann Google automatisch um die Auflösung bitten. Ein Scraper muss eine weitere Anfrage stellen, die Antwort verarbeiten und vermeiden, Googles Schutzmechanismen auszulösen.

Google beschreibt den Rollout als technische Maßnahme gegen Missbrauch. Die Änderung blockiert automatisiertes Sammeln nicht vollständig. Stattdessen verwandelt sie eine kostengünstige HTML-Parsing-Aufgabe in eine aufwendigere Abfolge von Anfragen, die Google beobachten kann.

Darin liegt der zentrale Konflikt. Suchnutzer benötigen weiterhin verlässliche ausgehende Links, während Google mehr Kontrolle über den automatisierten Zugriff auf seine Ergebnisse gewinnen will. Unternehmen für SERP APIs, SEO-Plattformen, Forschende und AI-Entwickler bewegen sich nun in diesem Spannungsfeld.

Google.com/goto: Googles Anti-Scraping-Update verändert die Link-Ebene

Google hat nicht verändert, was ein organisches Ergebnis anzeigt, aber wie Software das Ziel des Ergebnisses erreicht.

Ein traditionelles Google-Ergebnis platzierte die Zielseite direkt im href-Attribut des Anchor-Elements. Software konnte eine Suchergebnisseite herunterladen, ihr HTML parsen und mehrere vollständige URLs extrahieren.

Die neue Struktur fügt eine von Google kontrollierte Weiterleitung ein. Der Anchor eines Ergebnisses kann auf eine /goto-Adresse verweisen, die einen Wert enthält, der häufig mit CAES beginnt. Dieser Wert repräsentiert das Ziel, ohne es als lesbaren Text zu veröffentlichen.

Wenn eine Person auf das Ergebnis klickt, fordert der Browser die /goto-Adresse an. Google liefert dann eine HTTP-Weiterleitung zurück, die den Browser auf die tatsächliche Seite sendet. Der Übergang erfolgt meist zu schnell, als dass Suchende ihn bemerken.

Google bestätigte den Rollout am 26. August 2026. Ein Sprecher erklärte, das Unternehmen setze regelmäßig technische Maßnahmen gegen sich wandelnden Missbrauch ein, um seine Dienste und Nutzer zu schützen. Die Bestätigung beschrieb die Weiterleitung als eine dieser Maßnahmen.

Das Unternehmen veröffentlichte keine technische Spezifikation für den Token. Es erklärte auch nicht sämtliche Signale, die bestimmen, welche Browser, Regionen oder Sitzungen die umgeschriebenen Links erhalten.

Erste Beobachtungen gab es bereits vor der Bestätigung. Suchspezialisten meldeten das Muster im Juni und Juli, als es noch wie ein begrenzter Test wirkte. Bis Ende August sahen mehrere Datenanbieter eine deutlich breitere Einführung.

Die Rollout-Bestätigung berichtete von nahezu vollständiger Abdeckung bei mehreren Residential-IP-Anbietern. Diese Schätzung stammte von Derek Perkins vom Rank-Tracking-Unternehmen Nozzle, nicht von Google.

Autom, ein Anbieter von Suchdaten-APIs, berichtete von einer ähnlichen Entwicklung. Sein Team stieß zunächst auf /goto bei einem kleinen Anteil der Ergebnisseiten. Später beobachtete es das Format durchgängig in ausgeloggten Sitzungen und privaten Browserfenstern.

Der technische Bericht des Anbieters besagt, dass sich der undurchsichtige Parameter durch gewöhnliche lokale Dekodierung nicht in das Ziel umwandeln lässt. Die Zieladresse wird stattdessen über die Weiterleitungsantwort bereitgestellt.

Dieses Format unterscheidet sich von Googles älterem /url-Wrapper. Dieser enthielt in seinem Query-String häufig ein lesbares, URL-kodiertes Ziel. Software konnte diesen Wert extrahieren, ohne Google erneut zu kontaktieren.

Mit /goto werden das sichtbare Suchergebnis und das nutzbare Ziel zu getrennten Datenelementen. Google zeigt weiterhin genug Informationen an, damit eine Person das Ergebnis bewerten kann. Der Seitenquelltext garantiert jedoch keine wiederverwendbare ausgehende URL mehr.

Das ist die wesentliche Veränderung. Google hat die Zielauflösung aus statischem HTML in eine Interaktion mit dem eigenen Server verlagert.

Warum eine zusätzliche Weiterleitung Suchdatenanbieter unter Druck setzt

Die Weiterleitung verursacht Grenzkosten für jedes aufgelöste Ergebnis, und diese Kosten summieren sich in Systemen mit hohem Sammelvolumen.

Ein einfacher Scraper benötigte früher eine Anfrage, um mehrere organische Ziele von einer Suchergebnisseite zu sammeln. Im neuen Format kann er die ursprüngliche Anfrage plus eine Auflösungsanfrage für jeden eindeutigen /goto-Token benötigen.

Betrachten wir einen Dienst, der viele Suchanfragen über Standorte, Geräte und Sprachen hinweg überwacht. Er kann für jede Anfrage mehrere Seiten erfassen und diese Erfassung im Tagesverlauf wiederholen. Eine zusätzliche Anfrage pro Ergebnis wird schnell zu erheblichem Infrastrukturaufwand.

Die Kosten beschränken sich nicht auf Bandbreite. Jede Auflösung erhöht Latenz, Verbindungsmanagement und Retry-Logik und schafft eine weitere Möglichkeit für Fehler. Sie erzeugt zudem einen erkennbaren Strom von Anfragen an Googles Weiterleitungs-Endpunkt.

Google kann beobachten, wie schnell ein einzelner Client Links auflöst. Das Unternehmen kann diese Anfragen mit Cookies, Netzwerkidentitäten, Browsermerkmalen und früheren Suchaktivitäten vergleichen. Welche Signale Google hierbei nutzt, hat das Unternehmen nicht offengelegt.

Damit ist das Update mehr als ein neues Parsing-Format. Es schafft einen serverseitigen Kontrollpunkt zwischen dem Abruf der Ergebnisseite und dem Ermitteln jedes exakten Ziels.

Traditionelles Rank Tracking verdeutlicht diesen Druck. Ein Positionstracker muss erkennen, welche Seite für eine Suchanfrage rankt, und nicht nur, welche Domain erscheint. Exakte Pfade sind wichtig, wenn mehrere Seiten einer Website um dasselbe Thema konkurrieren.

Ein Tool, das statt der Publisher-URL die Google-Weiterleitung speichert, kann irreführende Datensätze erzeugen. Es könnte fehlende Ergebnisse melden, unterschiedliche Seiten zusammenführen oder Änderungen an Landingpages wie Ranking-Änderungen erscheinen lassen.

Such-APIs stehen vor einem ähnlichen Problem. Ihre Kunden erwarten saubere, strukturierte Ziel-URLs. Diese Kunden sollten weder Googles aktuellen Link-Wrapper verstehen noch ihre Integrationen bei jeder Formatänderung umschreiben müssen.

Autom erklärt, seine Pipeline so angepasst zu haben, dass /goto-Links aufgelöst werden und die bestehenden Antwortfelder erhalten bleiben. Dieser Ansatz verlagert die Kompatibilitätslast von API-Kunden auf den Datenanbieter.

Diese Lösung hängt weiterhin davon ab, dass Googles Weiterleitungsdienst für den Collector erreichbar bleibt. Sie setzt außerdem voraus, dass das aktuelle Antwortverhalten stabil bleibt. Google hat sich zu keiner der beiden Bedingungen verpflichtet.

AI-Such- und Forschungsprodukte stehen unter einer weiteren Art von Druck. Einige Systeme nutzen kommerzielle Such-APIs, andere sammeln Ergebnisseiten über ihre eigene Infrastruktur. Beide Ansätze hängen von vorhersehbarem Zugriff auf Quell-URLs ab.

Die Weiterleitung hindert ein Modell nicht daran, ein Ziel zu lesen, nachdem es bereitgestellt wurde. Sie beeinflusst den vorgelagerten Discovery-Prozess, der Quellen findet, einordnet und abruft, bevor die Analyse beginnt.

Wissensarbeiter könnten die Auswirkungen indirekt spüren. Ein Rechercheassistent kann Quellen übersehen, wenn sein Such-Connector Weiterleitungs-URLs falsch verarbeitet. Er kann auch Google-Wrapper speichern, wo Nutzer stabile Publisher-Links erwarten.

Dadurch wird die Herkunft von Informationen schwerer prüfbar. Ein vertrauenswürdiger Recherchebestand sollte die Seite bewahren, die eine Behauptung stützt, und nicht eine temporäre Routing-Adresse der Suchmaschine.

Teams, die interne Recherche-Systeme entwickeln, sollten daher die Quellenidentität von Discovery-Metadaten trennen. Eine durchsuchbare AI knowledge base bleibt nur dann nützlich, wenn ihre Zitate auf dauerhafte Dokumente verweisen.

Der unmittelbare Druck trifft Suchdatenvermittler. Das nachgelagerte Risiko betrifft jedes Produkt, das deren Ausgabe als verlässliche Quelleninfrastruktur behandelt.

Der eigentliche Wettbewerb lautet offene Ergebnisse gegen kontrollierte Auflösung

Google veröffentlicht weiterhin eine lesbare Ergebnisseite, kontrolliert aber zunehmend die Aktionen, die nötig sind, um diese Seite in wiederverwendbare Daten umzuwandeln.

Dabei geht es nicht einfach um Google gegen ein einzelnes Scraping-Unternehmen. Der zentrale Wettbewerb besteht zwischen zwei technischen Modellen für den Zugriff auf öffentlich sichtbare Suchergebnisse.

Das erste Modell behandelt eine Ergebnisseite als Dokument. Ein Client lädt sie herunter, liest die im HTML eingebetteten Links und entscheidet, was als Nächstes geschehen soll. Ein großer Teil des frühen Webs funktionierte nach diesem einfachen Muster.

Das zweite Modell behandelt Ergebnisse als interaktiven Dienst. Was der Nutzer sieht, bleibt zugänglich, wichtige Werte werden jedoch erst über zusätzliche, von der Plattform gesteuerte Anfragen verfügbar.

Der /goto-Rollout verschiebt Google Search in Richtung des zweiten Modells. Dies geschieht, ohne organische Ergebnisse zu entfernen oder gewöhnliche Nutzer zu einem neuen Ablauf zu zwingen.

Diese Nuance ist wichtig. Die Änderung als Scraping-Verbot zu bezeichnen, übertreibt ihre Wirkung. Die Links lassen sich weiterhin auflösen, und unabhängige Tests zeigen, dass Entwickler ihre Ziele noch immer ermitteln können.

ScrapingBee testete /goto über Browser, automatisierte Sitzungen und Netzwerkkonfigurationen hinweg. Seine Weiterleitungs-Experimente ergaben, dass sich der Token strukturell dekodieren, jedoch nicht lokal in die ursprüngliche URL umwandeln ließ.

Das Unternehmen berichtete, dass eine HTTP-GET-Anfrage mit deaktivierten automatischen Weiterleitungen eine 302-Antwort und einen Location-Header zurückgab. Dieser Header enthielt die Zieladresse.

Die Tests ergaben zudem, dass sich HEAD-Anfragen anders verhielten. Sie lieferten 200-Antworten ohne den erforderlichen Location-Header, sodass Collector für eine verlässliche Auflösung GET verwenden mussten.

Dieses Ergebnis widerspricht Automs ursprünglicher Empfehlung, die Location über HEAD auszulesen. Der Unterschied könnte auf verändertes Verhalten, Testbedingungen oder mehrere Varianten des Rollouts zurückzuführen sein.

Entwickler sollten keine der beiden Methoden als dauerhaften Vertrag behandeln. Eine defensive Implementierung kann das Antwortverhalten testen, mehr als einen Wrapper unterstützen und Fehler protokollieren, ohne gespeicherte URLs zu beschädigen.

ScrapingBee maß bei 50 sequenziell verarbeiteten Auflösungen einen Median von etwa 3,27 Sekunden. Fünf Worker reduzierten den Median in seiner Umgebung auf etwa 1,23 Sekunden.

Diese Werte stammen aus den Tests eines einzelnen Anbieters und sind kein allgemeingültiger Benchmark. Netzwerkstandort, Verbindungswiederverwendung, Google-Antworten und Drosselung können zu anderen Ergebnissen führen.

Dennoch verdeutlicht das Experiment den Zielkonflikt. Das Update erhöht die Reibung, doch moderate Parallelität kann einen Teil davon auffangen. Dadurch ist die Maßnahme eher geeignet, Kostenstrukturen zu verändern, als Scraping vollständig zu beseitigen.

Die Serverinteraktion eröffnet Google zudem Optionen, die statische Links nicht boten. Das Unternehmen kann Antworten anpassen, Token-Formate ändern, Ratenbegrenzungen anwenden oder zwischen Client-Typen unterscheiden.

Google kontrolliert bereits die Suchergebnisseite selbst. Direkte ausgehende URLs begrenzten jedoch die Beteiligung des Unternehmens, nachdem ein Client das HTML erhalten hatte. /goto erweitert diese Beteiligung auf die Zielauflösung.

Die Änderung folgt auf weitere Maßnahmen, die das Sammeln im großen Maßstab erschwert haben. Google hat seine Schutzmechanismen gegen automatisierten Traffic verschärft und Parameter von Ergebnisseiten geändert, die Collector zuvor für größere Ergebnismengen nutzten.

Jede einzelne Anpassung lässt sich technisch umgehen. Zusammen machen sie inoffiziellen Zugriff weniger vorhersehbar und steigern den Wert gepflegter Sammelinfrastruktur.

Dieser Wandel legt zudem eine unbequeme Symmetrie offen. Google baut seinen Index auf, indem es andere Websites crawlt, während es automatisierte Systeme einschränkt, die Googles Darstellung dieses Index sammeln.

Die Aktivitäten sind nicht identisch. Googlebot befolgt die Kontrollmechanismen von Publishern, erstellt ein Suchprodukt und arbeitet innerhalb dokumentierter Crawling-Systeme. SERP-Scraper sammeln von Google erzeugte Ranking-Seiten, häufig außerhalb einer unterstützten API-Beziehung.

Dennoch nehmen Publisher und Entwickler das Ungleichgewicht wahr. Google erwartet, dass das offene Web technisch zugänglich bleibt, während die Wiederverwendung seiner eigenen Aggregationsschicht zunehmend erschwert wird.

Ein intensiv diskutierter Community-Thread spiegelte diesen Konflikt wider. Zum für diese Story bereitgestellten Snapshot erreichte er 472 Punkte und 369 Kommentare.

Einige Teilnehmer hielten das Update für einen angemessenen Schutz des Dienstes. Andere beschrieben es als weitere Einhegung von Informationen, die aus öffentlichen Websites stammen. Mehrere konzentrierten sich auf die praktische technische Herausforderung statt auf das politische Argument.

Die überzeugendste Interpretation liegt zwischen diesen Positionen. Google hat seine Suchergebnisse nicht geschlossen, aber die Wiederverwendung in großem Umfang stärker von Google-kontrollierten Interaktionen abhängig gemacht.

Das Update schafft Reibung, aber keinen vollständigen Scraping-Block

Die größte Unsicherheit besteht darin, ob `/goto` ein handhabbares Redirect-Format bleibt oder zu einer Ebene eines strengeren Durchsetzungssystems wird.

Der aktuelle Mechanismus hat sichtbare Grenzen. Ein Scraper kann jeden Redirect anfragen und dessen Ziel auslesen. Einige Kopien der zugrunde liegenden URL könnten außerdem an anderer Stelle auf der gerenderten Seite verbleiben.

Google benötigt Zielinformationen, um Domains, Favicons, Breadcrumbs und Quellenangaben anzuzeigen. Abhängig vom Ergebnisformat können Datensammler einen Teil der Identität rekonstruieren, ohne jeden Link aufzulösen.

Das liefert nicht immer die exakte Zielseite. Eine angezeigte Domain kann nicht zwischen einer Produktseite und einem Support-Artikel auf derselben Website unterscheiden. Auch Breadcrumb-Text kann Parameter oder Pfadbestandteile auslassen.

Der Rollout ist ebenfalls nicht einheitlich. ScrapingBee meldete /goto in Chrome, Edge, Playwright und seiner eigenen Sammelumgebung. Brave und LibreWolf lieferten während derselben Tests direkte Links zurück.

Safari gab einen anderen Google-Wrapper statt desselben /goto-Formats zurück. Ein Wechsel des Proxy-Standorts beseitigte den Redirect nicht zuverlässig.

Diese Ergebnisse deuten auf Unterschiede zwischen Clients hin, legen jedoch Googles Auswahlregeln nicht offen. Der Browsertyp kann mit dem Ergebnis korrelieren, ohne es unmittelbar zu verursachen.

Auch die Tokens schienen in den Tests von ScrapingBee übertragbar zu sein. Über eine Verbindung gesammelte Tokens konnten später über einen anderen Client ohne die ursprünglichen Cookies oder den ursprünglichen Proxy aufgelöst werden.

In diesen Experimenten blieben sie länger als 24 Stunden nutzbar. Ihre maximale Gültigkeitsdauer ist unbekannt, und Google könnte Übertragbarkeits- oder Ablaufrichtlinien ohne Vorankündigung ändern.

Diese Unsicherheit sollte technische Entscheidungen prägen. Ein produktiver Collector sollte undurchsichtige Tokens nicht speichern, als wären sie dauerhafte Kennungen. Er sollte Ziele zeitnah zur Sammlung auflösen und validieren.

Er sollte außerdem den ursprünglichen Wrapper zur Diagnose behalten. Das Speichern beider Werte hilft Teams, eine Ranking-Änderung von einem Resolver-Fehler oder einer neuen Google-Antwortvariante zu unterscheiden.

Wiederholungsversuche brauchen sorgfältige Grenzen. Aggressive Auflösung kann das Anfragemuster verstärken, das die Änderung offenbar sichtbar machen soll. Unbegrenzte Retries können bei Teilausfällen zudem höhere Kosten verursachen.

Sammelsysteme sollten identische Tokens vor ihrer Auflösung deduplizieren. ScrapingBee fand auf einigen Ergebnisseiten wiederholte Tokens, wodurch unnötige doppelte Anfragen vermeidbar sind.

Anbieter benötigen außerdem Monitoring an mehreren Grenzen. Sie sollten den Anteil der Ergebnisse mit jedem Wrapper, Erfolgsraten bei der Auflösung, Antwortcodes und Latenzverteilungen verfolgen.

Ein plötzlicher Anstieg von Google-URLs in Kundenausgaben ist ein Parsing-Vorfall, kein Beleg dafür, dass Publisher aus der Suche verschwunden sind. Die Trennung dieser Zustände verhindert falsche Ranking-Alarme.

Analytics-Teams haben eine andere Frage. Sie möchten wissen, ob der Redirect die Referral-Attribution verändert, wenn ein Mensch die Website eines Publishers erreicht.

Ein serverseitiger Redirect kann weiterhin zum erwarteten Ziel führen und zugleich nutzbare Referral-Signale bewahren. Die tatsächliche Attribution hängt vom Browserverhalten, Headern, der Analytics-Konfiguration und Googles Implementierung ab.

Es gibt keine verifizierte Grundlage für die Behauptung, dass der Rollout die organische Attribution breitflächig zerstört. Website-Betreiber sollten eigene Landing-Requests und Analytics-Klassifizierungen prüfen, bevor sie diesen Schluss ziehen.

Googles allgemeine Redirect-Richtlinien erläutern, wie der Crawler gängige Redirect-Typen interpretiert. Sie dokumentieren /goto nicht als öffentliche Integrationsschnittstelle für Drittanbieter-Collector.

Dieser Unterschied ist wichtig. Die Dokumentation von Google Search Central erklärt Publishern, wie sie ihre eigenen Seiten weiterleiten. Sie verspricht kein stabiles Verhalten für Googles ausgehende Such-Wrapper.

Nutzer stehen vor einem kleineren, aber realen Kompromiss. Beim Überfahren eines Ergebnisses kann statt des vollständigen Ziels eine Google-Adresse erscheinen. Die angezeigte Domain liefert weiterhin Kontext, doch die Statusvorschau des Browsers wird weniger aussagekräftig.

Das kann eine vertraute Sicherheitsprüfung schwächen. Ein vorsichtiger Nutzer möchte möglicherweise das genaue Ziel prüfen, bevor er es öffnet, besonders wenn mehrere Seiten ähnliche Titel haben.

Google kann argumentieren, dass seine sichtbaren Domain-Labels und Schutzmaßnahmen gegen Missbrauch weiterhin wirksam sind. Kritiker können vernünftigerweise erwidern, dass ein plattformkontrolliertes Label nicht dasselbe ist wie die Prüfung des tatsächlichen Links.

Keine der beiden Sorgen beweist, dass der Rollout den meisten Nutzern schadet. Sie zeigen, dass Anti-Automatisierungsmaßnahmen die Transparenz verändern können, selbst wenn die Klick-Erfahrung unverändert erscheint.

Die derzeitige Evidenz stützt eine enge Schlussfolgerung. /goto erhöht die Kosten der Datensammlung, bricht einfache Parser und erweitert Googles Kontrolle über die Zielauflösung.

Sie stützt nicht die stärkere Behauptung, Google habe das Scraping von Suchergebnissen unmöglich gemacht. Anbieter haben bereits funktionierende Auflösungswege demonstriert, obwohl diese neue operative Risiken mit sich bringen.

Was Googles Anti-Scraping-Update Teams als Nächstes beobachten lässt

Drei Signale werden bestimmen, ob daraus ein routinemäßiges Parser-Update oder eine dauerhafte Veränderung der Ökonomie von Suchdaten wird.

Das erste Signal ist die Abdeckung der Link-Formate. Anbieter sollten messen, wie häufig direkte URLs, /url-Wrapper und /goto-Tokens über Browser, Regionen und Sitzungszustände hinweg auftreten.

Eine stabile Mischung würde die Ansicht stärken, dass Google ein segmentiertes Kontrollsystem betreibt. Eine rasche Entwicklung hin zu universellen /goto-Links würde die Anti-Scraping-Interpretation stärken.

Eine Rückkehr zu direkten Links würde die weitergehende Schlussfolgerung abschwächen. Sie würde nahelegen, dass Kompatibilitätsprobleme, Nutzerbedenken oder experimentelle Ergebnisse die zusätzliche Kontrolle überwogen haben.

Das zweite Signal ist das Verhalten des Resolvers. Teams sollten verfolgen, ob eine einfache GET-Anfrage weiterhin ohne Browser-Sitzung einen nutzbaren 302 Location-Header zurückgibt.

Bleibt dieser Weg verfügbar, können erfahrene Anbieter das Update als zusätzliche Infrastrukturkosten behandeln. Einfache Scraper werden ausfallen, aber gepflegte Systeme können weiterarbeiten.

Neue Authentifizierungsanforderungen, kurze Token-Laufzeiten, strenge Rate Limits oder clientgebundene Tokens würden die Hürde wesentlich erhöhen. Sie würden darauf hindeuten, dass Google den Kontrollpunkt verschärft, statt lediglich Links umzuschreiben.

Auch Änderungen beim Verhalten von HEAD und GET verdienen Aufmerksamkeit. Die widersprüchlichen frühen Berichte zeigen, warum Anbieter direkte Tests brauchen, statt sich auf ein einzelnes Implementierungsrezept zu verlassen.

Das dritte Signal ist die Datenqualität in SEO- und AI-Produkten. Kunden sollten auf fehlende Zielseiten, doppelte Google-URLs, unerklärliche Ranking-Volatilität oder Zitate achten, die bei Redirect-Wrappern enden.

Diese Symptome würden zeigen, dass einige Anbieter sich noch nicht vollständig angepasst haben. Stabile Ausgaben würden nahelegen, dass Anbieter die Änderung aufgenommen haben, ohne einen großen Teil der Belastung auf Kunden zu verlagern.

Käufer von Suchdaten sollten Anbietern konkrete Fragen stellen. Liefert der Dienst das endgültige Ziel zurück? Bewahrt er kanonische Parameter? Wie kennzeichnet er nicht aufgelöste Ergebnisse?

Sie sollten auch fragen, ob sich gemeldete Positionen wegen des Link-Formats geändert haben. Ein Ranking-Tool muss Sammelfehler von tatsächlichen Bewegungen in Googles Sortierung trennen.

AI-Produktteams benötigen ähnliche Prüfungen rund um Zitate. Jede abgerufene Behauptung sollte mit der endgültigen Publisher-URL verbunden sein, wobei Sammelfehler für Betreiber sichtbar bleiben.

Googles nächste öffentliche Stellungnahme ist ebenfalls relevant, auch wenn das Unternehmen möglicherweise kaum weitere Details anbietet. Eine formelle Erklärung zu Nutzerschutz- oder Missbrauchskategorien würde die Debatte über die Absicht eingrenzen.

Die aktuelle Stellungnahme bestätigt, dass /goto eine Schutzmaßnahme ist. Sie sagt nicht, ob AI-Crawler, SEO-Tools, Klickmessung oder eine andere Missbrauchskategorie das Design motiviert haben.

Rechtliche Konflikte könnten weiteren Kontext liefern. Google hat einige Unternehmen angefochten, die Suchergebnisse sammeln und weiterverkaufen, was zeigt, dass technische Kontrollen neben rechtlichem Druck bestehen.

Allerdings betrifft /goto ein breiteres Spektrum von Clients als jeden einzelnen Beklagten. Forscher, Accessibility-Tools, Browser-Erweiterungen und interne Monitoring-Systeme können denselben Wrappern begegnen.

Die nächsten Monate werden zeigen, ob Google zwischen diesen Nutzungen unterscheidet. Einheitliche Beschränkungen würden zentralisierten Datenanbietern zugutekommen, die große Auflösungssysteme betreiben können.

Selektiver Zugang könnte einen anderen Markt hervorbringen. Unterstützte Partner und genehmigte Schnittstellen würden an Bedeutung gewinnen, während inoffizielle Sammlung weniger zuverlässig würde.

Für Entwickler ist die unmittelbare Reaktion einfach. Behandeln Sie Suchergebnis-Links als variable Daten, validieren Sie Ziele, bewahren Sie Diagnosekontext und überwachen Sie Resolver-Fehler getrennt von Ranking-Änderungen.

Für Käufer lautet die Aufgabe: verifizieren. Fragen Sie, ob Ihr Anbieter für SEO, Monitoring oder Recherche sich angepasst hat, bevor Sie einer unerwarteten Verschiebung in seinen Berichten vertrauen.

Für Wissensarbeiter gilt: Prüfen Sie Zitate, wenn ein automatisiertes Recherche-System einen Google-Wrapper zurückgibt. Eine brauchbare Antwort sollte zur zugrunde liegenden Quelle führen und nicht bei der Routing-Schicht der Suchmaschine enden.

Google.com/goto: Googles Anti-Scraping-Update ist daher weder eine vollständige Blockade noch ein kosmetischer Redirect. Es ist eine architektonische Mautstelle an einem wertvollen Punkt der Suchdaten-Pipeline.

Beobachten Sie, ob diese Maut bei einer günstigen Anfrage bleibt. Wenn sie strengere Identitätsprüfungen, kürzer gültige Tokens oder engere Limits erhält, wird aus der heutigen Parser-Reparatur ein größerer Zugangsdisput.