← Alle Beiträge
Use Case 5 Min. Lesezeit

SERP-Monitoring at Scale nach num=100

Das Tracking von Google-Rankings at Scale wurde schwieriger, als num=100 wegfiel. So bauen SEO-Engineering-Teams ihre SERP-Monitoring-Infrastruktur für 2026 neu auf.

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

Die Herausforderung

Wenn dein Team Rank-Tracker, SEO-Dashboards oder Competitive-Intelligence-Tools baut, hat das Jahr 2026 deine Unit Economics ruiniert. Google hat dieses Jahr den URL-Parameter num=100 in der Google-Suche stillschweigend eingestellt – den Trick, den jeder SERP-Scraper genutzt hat, um 100 Ergebnisse mit einem einzigen Request abzurufen. Jetzt erfordert die gleiche Abdeckung zehn Requests statt einem.

Das sind die offensichtlichen Kosten. Die versteckten Kosten sind weitaus unangenehmer.

Rank-Tracking funktioniert nur, wenn du die SERP siehst, die ein echter Suchender im richtigen Land, in der richtigen Region und in der richtigen Stadt sehen würde. Ein Keyword, das in London auf Platz 4 rankt, kann in Edinburgh auf Platz 11 und in Belfast auf Platz 19 landen. Lokale 3-Packs, Shopping-Karussells, News-Boxen, Knowledge Panels, AI Overviews. Jedes SERP-Feature verändert sich je nach Geografie und Gerät. (Scrape.do hat gemessen, dass Anfang 2026 in etwa 36 % der Suchanfragen AI-Overview-Texte erschienen.) Wenn dein Scraper über einen Proxy in der falschen Stadt routet, sind deine Ranking-Daten eine selbstbewusst präsentierte Fiktion.

Ein zukunftssicheres SERP-Produkt im Jahr 2026 benötigt daher drei Dinge, die nahtlos zusammenspielen: einen Request, der auf Protokollebene wie ein echter Browser aussieht, einen Proxy, der exakt in der Stadt lokalisiert ist, die du überwachen willst, und die Fähigkeit, JavaScript zu rendern, wenn Google beschließt, die Hälfte der Ergebnisse clientseitig zu laden. Fehlt eine dieser drei Komponenten, verschlechtern sich deine Daten unbemerkt.

Der FourA-Ansatz

Der Flaschenhals beim SERP-Scraping at Scale ist nicht der Request. Es ist das Routing.

Die meisten selbstgebauten Pipelines starten mit einem festen Proxy-Pool und behandeln die Suchanfrage als Variable. Bei Googles geografischem Targeting ist es genau umgekehrt. Die Suchanfrage ist das, was du hast. Den Proxy musst du richtig hinbekommen.

Wir haben beobachtet, wie Teams dies auf Basis von FourA ungefähr so aufbauen:

  1. Proxy Finder verwaltet einen aktiven Pool von Proxys, die durch frische Liveness-Checks validiert und mit Land, Region, Stadt und ASN getaggt sind. Wenn ein Request aus Manchester, Boston oder São Paulo kommen muss, wählt Proxy Finder einen Proxy aus, der tatsächlich dort verortet und beim letzten Check aktiv war. Die Auswahl erfolgt vor dem Fetch, nicht währenddessen. Mehr darüber, warum diese Routing-Ebene so wichtig ist, erfährst du in unserem Artikel über Smart Proxy Routing.

  2. Single übernimmt den eigentlichen SERP-Fetch. Für standardmäßige organische Ergebnisse reicht rohes HTML völlig aus. Setze unblocker: true und der Request durchbricht Anti-Bot-Barrieren auf Handshake-Ebene, ohne dass du wissen musst, welche Signatur Google in dieser Woche prüft. Was dieses Flag auf Protokollebene genau bewirkt, haben wir in unserem Web-Unblocker-Beitrag aufgeschlüsselt.

  3. Browser verarbeitet SERPs, bei denen kritische Inhalte erst nach der Ausführung von JavaScript erscheinen. AI Overviews, erweiterte Shopping-Packs, Knowledge-Panel-Inhalte, persistente lokale 3-Packs. Gleiche URL, gleiches Ziel, der Request läuft einfach über eine vollständige Browser-Session und gibt die fertig gerenderte Seite zurück. (Plus Screenshots, die dir den Tag retten, wenn ein SEO-Lead fragt, warum dein Dashboard Platz 3 anzeigt, sie aber in ihrem Browser Platz 6 sehen.)

Ein einziger Aufruf gegen die proxy-geroutete API:

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

Das sind drei sauber getrennte Aufgabenbereiche: geografisch korrekte Proxy-Auswahl (Proxy Finder), der Request selbst (Single) und JavaScript-Rendering bei Bedarf (Browser). Dein Code enthält keine Logik zur Proxy-Integrität und muss nicht raten, welche IP um 3 Uhr morgens noch aktiv ist. Das ist die Sorge von jemand anderem.

Speichere zudem jede Response ab, indiziert nach (keyword, location, device, timestamp). Das ist die tatsächliche Single Source of Truth für das Rank-Tracking. Nicht "wir haben heute für dieses Keyword hier gerankt", sondern "wir haben für dieses Keyword aus dieser Stadt auf diesem Gerät zu dieser Minute hier gerankt". Ohne diese Detailtiefe bei der Zuordnung können sich die Daten zweier Tage unbemerkt widersprechen, und du hast keine Möglichkeit herauszufinden, welche korrekt waren. SEO-Teams, die geschützte Verticals überwachen, arbeiten bereits damit. Wir haben auch darüber geschrieben, wie Bot-Detection verhaltensbasiert wurde, was eine vierte Achse (Session-Kontinuität) für Websites hinzufügt, die eher auf Request-Sequenzierung als auf Signale pro Request achten.

Ergebnisse

Ein Rank-Tracker, der 5.000 Keywords in 12 Städten zweimal täglich überwacht, verursachte unter der alten num=100-Regelung etwa 120.000 Requests pro Tag. Jetzt sind es durch einfache Paginierungsrechnung eher 1,2 Millionen (illustratives Szenario basierend auf Branchen-Benchmarks).

Teams, die diese Struktur auf einen Stack aus drei Produkten übertragen haben, berichten meist von:

  • 40-60 % Reduzierung der Kosten pro Request im Vergleich zum Betrieb eines eigenen Proxy-Pools, hauptsächlich weil sie nicht mehr für Proxy-Churn, tote IPs und die Entwicklerstunden zur Pflege der Rotation zahlen müssen.
  • Standortgenauigkeit auf Stadtebene steigt von ~70 % auf über 95 %, weil Proxy Finder nach Städten filtert und die Liveness beim letzten Check vor der Übergabe des Proxys verifiziert.
  • Kein Sonderpfad für AI Overviews. Ein Keyword, das über Single abgerufen wird, kann ohne Umschreiben der Pipeline auf Browser hochgestuft werden. Der Kontrakt ist identisch: URL rein, Response raus.

Für zehn Keywords und einen Laptop brauchst du das alles nicht. Aber du brauchst es, sobald die Pipeline Zehntausende Keywords über Ländergrenzen hinweg überwacht, deine Kunden am Montagmorgen um 9 Uhr das Dashboard aktualisieren und die Rankings echt sein müssen.

Fazit

Der schwierige Teil des SERP-Monitorings ist schon lange nicht mehr der Request. Es ist das Routing. Aus welcher Stadt rufst du ab? Ist diese IP aktiv? Hat Google das Layout zurückgegeben, das ein echter Suchender an diesem Standort tatsächlich sehen würde, oder das leere Layout, das ausgespielt wird, wenn sie einen Scraper wittern?

Wenn du ein SEO-Team bist, das Rank-Tracking auf einem selbstgebauten Stack betreibt, stellt sich für 2026 nicht die Frage, ob du Google scrapest. Das tust du bereits. Die Frage ist, ob deine Infrastruktur weiterhin vertrauenswürdige Rankings liefern kann, wenn sich die Regeln ohne Vorwarnung ändern, und wie viel Kapazität deines Engineering-Teams du opfern willst, um diesen Zustand aufrechtzuerhalten.