Vor einem Jahr konnte man die Google-Ausgabe mit einem GET-Request und dem Parameter num=100 abfragen – hundert Ergebnisse kamen als reines HTML. Im Jahr 2026 funktioniert das nicht mehr: Google hat den Zugang ohne JavaScript abgeschaltet, die hundert Ergebnisse pro Seite reduziert und einen Block AI Overviews hinzugefügt, der asynchron gerendert wird und nicht von jeder IP sichtbar ist. Lassen Sie uns untersuchen, wie man SERP unter den neuen Bedingungen sammelt, wo versteckte Fallen lauern und warum die Wahl des Proxy-Typs wichtiger geworden ist als der Parser selbst.
Für wen dieser Leitfaden
Das Parsen von Suchergebnissen (SERP-Scraping) betrifft nicht nur SEO-Positionen. Heute nutzen es:
- SEO-Spezialisten und Agenturen – überwachen organische Ergebnisse, Featured Snippets, „Ähnliche Fragen“, lokale Ausgaben und ob die Website in AI Overviews erscheint.
- Marktanalyse-Analysten – beobachten, wen Google in AI-Blöcken bei kommerziellen Anfragen zitiert und wie sich die erste Seite der Wettbewerber verändert.
- AI- und Daten-Teams – sammeln SERP als Datenquelle für RAG-Systeme, Modelltraining und Faktenprüfung.
Alle eint ein Problem: Google unterscheidet im Jahr 2026 aktiv zwischen automatischem und echtem Traffic, und ohne die richtige Infrastruktur bricht die Datensammlung bei den ersten Dutzend Anfragen zusammen.
Was sich geändert hat: drei Schläge von Google gegen Scraper
Um den Leitfaden ehrlich zu gestalten, beginnen wir mit den Gründen, warum die alten Anleitungen nicht mehr funktionieren.
Januar 2025 – SearchGuard. Google hat ein System von JavaScript-Herausforderungen eingeführt: Eine normale HTTP-Anfrage über requests oder httpx erhält jetzt keine HTML-Seite mehr, sondern eine Challenge-Seite. Ohne die Ausführung von JavaScript kann man die Ausgabe nicht sehen – das direkte Parsen „ins Gesicht“ schlägt sofort fehl.
September 2025 – Ende von num=100. Google hat den Parameter entfernt, der 100 Ergebnisse pro Anfrage lieferte. Jetzt sind die Top-100 zehn separate Anfragen mit Pagination. Für tiefgehendes Monitoring bedeutet das einen zehnfachen Anstieg der Anfragen (und damit der Belastung für Proxys und Budget).
Dezember 2025 – rechtlicher Druck. Am 19. Dezember 2025 reichte Google eine DMCA-Beschwerde gegen SerpApi ein und erklärte, dass SearchGuard ein „technisches Schutzmittel“ (technological protection measure) sei und dessen Umgehung unter die Anti-Umgehungsnormen falle. Der Präzedenzfall ist noch nicht gelöst, aber er setzt einen Ton: Graues Parsen von Google wird sowohl technisch als auch rechtlich teurer.
Besonders erwähnenswert: Die offizielle Custom Search API von Google wird eingestellt – bestehenden Kunden wurde eine Frist zur Migration bis zum 1. Januar 2027 gesetzt. Das bedeutet, dass auch die „legale“ Alternative schwindet.
Die wichtigste Neuerung in der Ausgabe – AI Overviews
AI Overviews (früher SGE) sind eine von KI generierte Zusammenfassung oben in der Ausgabe mit Links zu den Quellen. Für das Scraping ist dies das schwierigste Element des Jahres 2026 aus drei Gründen.
Es gibt viele davon. Laut Ahrefs erscheinen AI Overviews in etwa 30% der Anfragen; spätere Schätzungen (Olostep) geben bis zu 48% aller Anfragen und bis zu 80% der Informationsanfragen an. Dieses Block zu ignorieren bedeutet, ein unvollständiges Bild der Ausgabe zu sammeln.
Sie werden asynchron gerendert. Der Block existiert in drei Zuständen: Er kommt sofort in HTML (am seltensten), wird über JavaScript einige Sekunden nach der Hauptseite nachgeladen (der häufigste Fall) oder erscheint gar nicht. Bei verzögerter Ladezeit enthält die rohe HTTP-Antwort einen leeren Container – der Inhalt wird später nachgeladen, und der Parser muss warten (in der Praxis etwa 8 Sekunden bei browserbasierter Automatisierung).
Sie sind nicht von jeder IP sichtbar. Hier ist der entscheidende Punkt, über den alte Leitfäden schweigen: Google betrachtet mobile Nutzer als priorisierte Zielgruppe für die KI-Suche. In der Praxis bedeutet dies, dass von Datacenter-IP AI Overview oft überhaupt nicht zurückgegeben wird, während dieselbe Anfrage über einen Mobilfunkanbieter den vollständigen Block zurückgibt. Selbst führende Aggregatoren erkennen die Unvollständigkeit an: SerpApi gab zu Beginn des Jahres 2026 etwa 68% erfolgreiche Erkennung von AI Overviews an.
Schritt-für-Schritt-Anleitung: Wie man SERP im Jahr 2026 sammelt
- Bestimmen Sie das Volumen. Bis zu ~100 Anfragen pro Tag können realistisch mit eigener browserbasierter Automatisierung bewältigt werden. Von 100 bis 10.000 – hier wird ein verwalteter Parser oder SERP-API benötigt. Über 10.000 pro Tag kommt man ohne Enterprise-Infrastruktur mit Batches und Webhooks nicht aus. Dies bestimmt den gesamten weiteren Stack.
- Stellen Sie die richtige URL zusammen. Der grundlegende Endpunkt ist /search, die Schlüsselparameter sind: q (Anfrage, URL-Codierung), hl (Sprache der Benutzeroberfläche), gl (Land der Ausgabe), start (Pagination: start=10 – zweite Seite, start=20 – dritte Seite usw.). Denken Sie daran: num=100 funktioniert nicht mehr, die Tiefe wird nur durch Pagination erreicht.
- Verwenden Sie browserbasiertes Rendering. Da es ohne JavaScript keine Ausgabe gibt, ist der grundlegende Stack Playwright oder Selenium mit headless Chromium. Stellen Sie sicher, dass Sie Automatisierungsmarker entfernen (Flag --disable-blink-features=AutomationControlled), sonst erkennt der Anti-Bot den gesteuerten Browser anhand der navigator-Eigenschaften.
- Warten Sie auf AI Overview. Greifen Sie nach dem Laden der Seite nicht sofort auf das DOM zu: Lassen Sie networkidle sich stabilisieren und warten Sie auf das Nachladen des Blocks (Orientierung – bis zu 8 Sekunden). Das Vorhandensein des Blocks lässt sich zuverlässiger anhand des Textes des Titels „AI Overview“ bestimmen, nicht anhand von CSS-Klassen – diese sind bei Google dynamisch und ändern sich (bedingte Kevs9, Y3BBE sind heute die einen, morgen die anderen).
- Parsen Sie nach Struktur, nicht nach Klassen. Nehmen Sie organische Ergebnisse anhand von Überschriftstags (h3) und Semantik und nicht anhand fragiler Klassennamen. Aus der Ausgabe von 2026 sind verfügbar: organische Ergebnisse, Featured Snippets, „Ähnliche Fragen“, verwandte Anfragen, Knowledge Graph, lokales Paket, Werbung und Zitate innerhalb von AI Overview.
- Rotieren Sie IPs und drosseln Sie. Setzen Sie realistische Pausen zwischen den Anfragen (4–12 Sekunden) und ändern Sie die IP etwa alle 5 Minuten, wobei Sie Stadt/Anbieter variieren. Ein zu gleichmäßiger Rhythmus und eine IP sind der schnellste Weg zu einem Captcha.
Unterwasserfallen
- „Leere“ AI Overview. Wenn Sie das DOM sofort nach dem Laden abrufen, wird der verzögerte Block leer sein – und Sie werden denken, dass er nicht existiert. Planen Sie immer eine Wartezeit und eine erneute Überprüfung ein.
- Einmalige Sitzungen zum Nachladen. Bei einigen APIs ist der Sitzungsschlüssel zum Nachladen des verzögerten AI Overview einmalig und lebt etwa 60 Sekunden – rechnen Sie nicht damit, ihn später wiederverwenden zu können.
- Falsche Einsparungen bei Datacenter. Günstige Datacenter-IPs lösen bereits nach 5–10 Anfragen ein Captcha aus und zeigen zudem keine AI Overviews an. Einsparungen führen zu unvollständigen Daten und verlorener Zeit.
- Fragile Selektoren. Wenn Sie sich an die Namen von CSS-Klassen gebunden haben, wird der Parser beim nächsten Redesign der Ausgabe brechen. Halten Sie sich an den Text und die Struktur.
- Gleichmäßiger Fingerabdruck der Anfragen. Gleiche User-Agent, Timings und Header in allen Streams verraten ein Botnetz. Variieren Sie den Fingerabdruck ebenso wie die IP.
Welchen Proxy-Typ wählen
Im Jahr 2026 bestimmen Proxys, nicht der Parser, ob Sie die vollständige Ausgabe sehen. Lassen Sie uns das nach Aufgaben aufschlüsseln.
Mobile Proxys – für AI Overviews und die „schwierigsten“ Anfragen. Da Google AI-Blöcke in erster Linie an mobile Nutzer ausliefert, lösen echte Betreiber-IPs (T-Mobile, Verizon, Vodafone und ähnliche) am stabilsten AI Overview aus und halten deutlich mehr aus – Beobachtungen zufolge 50–200 Anfragen bis zum Auftreten von Reibung im Vergleich zu 5–10 bei Datacentern. Zudem teilt eine mobile CGNAT-IP eine Adresse mit Hunderten von echten Abonnenten, weshalb Google es für riskant hält, sie zu sperren. Wenn Ihre Aufgabe darin besteht, genau AI Overviews zu sammeln oder die am stärksten geschützten SERP zu überwachen, beginnen Sie mit mobilen Proxys.
Residential Proxys – das Arbeitstier für organische Ergebnisse und Volumen. Für das Sammeln von regulären Ausgaben, Positionen, Featured Snippets und lokalen Paketen bieten Residential IPs (Adressen von Heim-Anbietern) das beste Preis-Leistungs-Verhältnis. Sie sind schwer von echten Nutzern zu unterscheiden, und die Rotation ermöglicht es, die Sammlung ohne einen Schuss von einer Adresse zu skalieren. Die optimale Wahl, wenn AI Overview nicht im Fokus steht, sondern Volumen und Geografie wichtig sind, sind Residential Proxys mit Rotation.
Datacenter – nur für Testläufe. Schnell und günstig, aber gegen Google im Jahr 2026 leben nur wenige Anfragen und sehen keine AI-Blöcke. Geeignet für das Debugging der Parser-Logik, nicht für die tatsächliche Datensammlung.
Unsicher, was für eine spezifische Aufgabe zu wählen ist? Beginnen Sie mit der Analyse von Residential vs. Mobile Proxys im Jahr 2026: Dort wird detailliert erklärt, wo welcher Typ Geld spart und wo Daten.
Fazit
Das Parsen von Google im Jahr 2026 ist nicht mehr die Aufgabe „einen Parser zu schreiben“. SearchGuard zwingt zur Ausführung von JavaScript, die Streichung von num=100 hat die Anzahl der Anfragen verzehnfacht, und AI Overviews haben einen Block hinzugefügt, der hauptsächlich von mobilen IPs sichtbar ist und mit Verzögerung nachgeladen wird. Technisch ist alles lösbar: browserbasierte Automatisierung, Parsing nach Struktur, angemessene Pausen und Rotation. Aber das Fundament, auf dem die Vollständigkeit und Stabilität der Sammlung beruht, sind die richtigen Proxys: mobile für AI Overviews und geschützte Anfragen, Residential für organische Ergebnisse und Volumen. Beginnen Sie mit dem Proxy-Typ, der zu Ihrer Aufgabe passt – und der Parser wird nicht mehr über Captchas stolpern.
```