← Alle Beiträge
Use Case 5 Min. Lesezeit

SERP-Monitoring im großen Maßstab nach num=100

Das Tracking von Google-Rankings im großen Maßstab wurde schwerer, als num=100 verschwand. So bauen SEO-Engineering-Teams die Infrastruktur für SERP-Monitoring für 2026 um.

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

Die Herausforderung

Wenn dein Team Rank-Tracker, SEO-Dashboards oder Competitive-Intelligence-Tools entwickelt, hat das Jahr 2026 deine Unit Economics zerstört. Google hat dieses Jahr still und leise den URL-Parameter num=100 in der Google-Suche entfernt. Das war der Trick, den jeder SERP-Scraper nutzte, um 100 Ergebnisse mit einem einzigen Request abzurufen. Jetzt erfordert dieselbe Abdeckung zehn Requests statt einem.

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

Rank-Tracking funktioniert nur, wenn du genau die SERP siehst, die ein echter Nutzer im richtigen Land, in der richtigen Region und in der richtigen Stadt sehen würde. Ein Keyword auf Platz 4 in London rankt in Edinburgh vielleicht auf Platz 11 und in Belfast auf Platz 19. Lokale 3-Packs, Shopping-Karussells, News-Boxen, Knowledge Panels, AI Overviews. Jedes SERP-Feature verändert sich je nach Standort und Gerät. (Scrape.do stellte Anfang 2026 fest, dass AI-Overview-Texte bei etwa 36 % der Suchanfragen auftauchten.) Wenn dein Scraper über einen Proxy in der falschen Stadt geroutet wird, sind deine Ranking-Daten reine Fiktion, die du nur selbstbewusst präsentierst.

Ein zukunftssicheres SERP-Produkt benötigt 2026 also drei Dinge im Zusammenspiel: einen Request, der auf Protokollebene wie ein echter Browser aussieht, einen Proxy, der exakt in der Stadt steht, die du überwachen willst, und die Fähigkeit, JavaScript zu rendern, wenn Google die Hälfte des Ergebnisses clientseitig lädt. Fehlt auch nur einer dieser drei Punkte, verschlechtert sich deine Datenqualität schleichend.

Der FourA-Ansatz

Der Engpass beim SERP-Scraping im großen Maßstab ist nicht der Request. Es ist das Routing.

Die meisten selbstgebauten Pipelines beginnen mit einem festen Proxy-Pool und behandeln die Query als Variable. Wegen Googles geografischem Targeting ist es genau umgekehrt. Die Query ist vorgegeben. Der Proxy ist das, was du präzise abstimmen musst.

Wir haben beobachtet, wie Teams dieses Muster auf Basis von FourA in etwa so umsetzen:

  1. Proxy Finder verwaltet einen funktionierenden Proxy-Pool, der durch frische Liveness-Checks validiert und mit Land, Region, Stadt sowie ASN getaggt ist. Wenn ein Request aus Manchester, Boston oder São Paulo kommen muss, wählt Proxy Finder einen Proxy, der sich tatsächlich dort befindet und beim letzten Check aktiv war. Die Auswahl erfolgt vor dem Abruf, nicht währenddessen. Mehr darüber, warum diese Routing-Schicht entscheidend ist, findest du in unserem Beitrag zu Smart Proxy Routing.

  2. Single übernimmt den eigentlichen SERP-Abruf. Für normale organische Ergebnisse reicht reines HTML völlig aus. Setze unblocker: true und der Request nutzt eine aktuelle Browser-Signatur, ohne dass du wissen musst, welche Signatur Google in dieser Woche prüft. Was dieses Flag auf Netzwerkebene genau bewirkt, haben wir in unserem Beitrag zum Web Unblocker detailliert beschrieben.

  3. Browser übernimmt SERPs, bei denen kritische Inhalte erst nach Ausführung von JavaScript sichtbar werden. AI Overviews, erweiterte Shopping-Packs, Knowledge-Panel-Inhalte, fixierte lokale 3-Packs. Dieselbe URL, dasselbe Ziel, nur dass der Request über eine vollständige Browser-Session läuft und die fertig gerenderte Seite zurückliefert. (Zusätzlich gibt es Screenshots, die dir helfen, wenn ein SEO-Lead fragt, warum dein Dashboard Platz 3 meldet, er in seinem Browser aber Platz 6 sieht.)

Ein einzelner Aufruf der Proxy-gerouteten 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: geokorrektes Proxy-Handling (Proxy Finder), der eigentliche Request (Single) und JavaScript-Rendering bei Bedarf (Browser). Dein Code enthält keine Proxy-Health-Logik und muss nicht raten, welche IP um 3 Uhr morgens noch aktiv ist. Das ist das Problem von jemand anderem.

Speichere außerdem jede Response mit dem Schlüssel (keyword, location, device, timestamp). Das ist die eigentliche Informationseinheit für das Rank-Tracking. Nicht "wir rankten heute hier für dieses Keyword", sondern "wir rankten hier für dieses Keyword, aus dieser Stadt, auf diesem Gerät, in dieser Minute". Ohne diesen Detaillierungsgrad können sich Daten zweier Tage unbemerkt widersprechen, und du kannst nicht feststellen, welche korrekt waren. SEO-Teams, die geschützte Verticals überwachen, kennen das bereits. Wir haben auch darüber geschrieben, wie Bot-Erkennung verhaltensbasiert wurde. Das fügt eine vierte Dimension hinzu (Session-Kontinuität) für Websites, die Request-Sequenzen statt einzelner Request-Signale analysieren.

Ergebnisse

Ein Rank-Tracker, der 5.000 Keywords in 12 Städten zweimal täglich überwacht, benötigte unter dem alten num=100-Modell etwa 120.000 Requests pro Tag. Jetzt sind es durch einfache Paginierungs-Mathematik fast 1,2 Millionen (beispielhaftes Szenario basierend auf Branchen-Benchmarks).

Teams, die dieses Modell auf einen Drei-Produkt-Stack umgestellt haben, berichten typischerweise von:

  • 40 bis 60 % geringeren Kosten pro Request im Vergleich zum Betrieb eines eigenen Proxy-Pools, vor allem weil Kosten für Proxy-Churn, tote IPs und Entwicklerstunden für die Rotation entfallen.
  • Standortgenauigkeit auf Städteebene, die von ca. 70 % auf über 95 % steigt, da Proxy Finder nach Städten filtert und die Verfügbarkeit direkt vor der Übergabe des Proxys prüft.
  • Kein Sonderpfad für AI Overviews. Ein Keyword, das über Single abgerufen wird, kann ohne Pipeline-Umbau auf Browser umgestellt werden. Die Schnittstelle ist identisch: URL rein, Response raus.

Für zehn Keywords auf einem Laptop brauchst du das nicht. Du brauchst es, sobald die Pipeline Zehntausende Keywords über mehrere Länder hinweg überwacht, deine Kunden das Dashboard am Montagmorgen um 9 Uhr aktualisieren und die Rankings stimmen müssen.

Fazit

Der schwierige Teil beim SERP-Monitoring ist schon lange nicht mehr der Request selbst. Es ist das Routing. Aus welcher Stadt rufst du ab? Ist diese IP aktiv? Hat Google das Layout geliefert, das ein echter Nutzer an diesem Ort sehen würde, oder die leere Version, die bei Scraper-Verdacht ausgespielt wird?

Wenn du als SEO-Team Rank-Tracking auf einem selbst gebauten Stack betreibst, lautet die Frage für 2026 nicht, ob du Google scrapest. Das tust du bereits. Die Frage ist, ob deine Infrastruktur weiterhin verlässliche Rankings liefert, wenn sich die Regeln ohne Vorwarnung ändern, und wie viel Entwicklerzeit du investieren willst, um diesen Zustand zu halten.