← 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 baut, hat 2026 deine Unit-Economics zerstört. Google hat dieses Jahr den URL-Parameter num=100 auf Google Search klammheimlich in Rente geschickt, den Trick, den jeder SERP-Scraper nutzte, um 100 Ergebnisse in einem Request zu ziehen. Jetzt erfordert die gleiche Abdeckung zehn Requests statt einem.

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

Rank-Tracking funktioniert nur, wenn du die SERP so siehst, wie ein echter Suchender im richtigen Land, der richtigen Region und Stadt sie sehen würde. Ein Keyword, das in London auf #4 rankt, könnte in Edinburgh auf #11 und in Belfast auf #19 ranken. Lokale 3-Packs, Shopping-Karussells, News-Boxen, Knowledge-Panels, AI-Overviews. Jedes SERP-Feature ändert sich mit Geografie und Gerät. (Scrape.do hat gemessen, dass Anfang 2026 in etwa 36 % der Suchanfragen AI-Overview-Texte erschienen.) Wenn dein Scraper durch einen Proxy in der falschen Stadt routet, sind deine Ranking-Daten frei erfunden, auch wenn sie selbstbewusst präsentiert werden.

Ein belastbares SERP-Produkt benötigt in 2026 also drei Dinge, die zusammenarbeiten: einen Request, der auf Wire-Ebene wie ein echter Browser aussieht, einen Proxy, der genau in der Stadt sitzt, die du überwachen willst, und die Fähigkeit, JavaScript zu rendern, wenn Google entscheidet, die halben Ergebnisse clientseitig zu laden. Fehlt eins der drei, verschlechtern sich deine Daten unmerklich.

Der FourA-Ansatz

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

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

Wir haben beobachtet, wie Teams dieses Muster über FourA grob so aufbauen:

  1. Proxy Finder hält einen funktionierenden Proxy-Pool vor, validiert durch aktuelle Liveness-Checks und getaggt mit Land, Region, Stadt und ASN. Wenn ein Request aus Manchester oder Boston oder São Paulo kommen muss, wählt Proxy Finder einen aus, der dort tatsächlich sitzt und beim letzten Check am Leben war. Die Auswahl passiert vor dem Fetch, nicht währenddessen. Für mehr Infos, warum dieser Routing-Layer wichtig ist, lies unseren Beitrag über Smart Proxy Routing.

  2. Single kümmert sich um den SERP-Fetch selbst. Für normale organische Ergebnisse reicht reines HTML völlig. Setze unblocker: true und der Request kommt durch Anti-Bot-Wände auf Handshake-Ebene, ohne dass du wissen musst, welche Signatur Google diese Woche prüft. Wir haben analysiert, was das Flag auf der Wire-Ebene macht, in unserem Web Unblocker Beitrag.

  3. Browser verarbeitet SERPs, bei denen kritischer Content erst nach JavaScript-Ausführung erscheint. AI-Overviews, erweiterte Shopping-Packs, Knowledge-Panel-Content, klebrige lokale 3-Packs. Selbe URL, selbes Target, der Request läuft einfach durch eine volle Browser-Session und liefert die komplett gerenderte Seite zurück. (Plus Screenshots, die dir den Tag retten, wenn ein SEO-Lead fragt, warum dein Dashboard #3 sagt, sie in ihrem Browser aber #6 sehen.)

Ein einziger Call 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 Zuständigkeiten: geo-korrekte Proxy-Arbeit (Proxy Finder), der Request selbst (Single), JavaScript-Rendering wenn nötig (Browser). Dein Code trägt keine Proxy-Health-Logik und rät nicht, welche IP um 3 Uhr nachts noch am Leben ist. Das ist das Problem von jemand anderem.

Und speichere jede Response geschlüsselt nach (keyword, location, device, timestamp). Das ist die eigentliche Einheit der Wahrheit für Rank-Tracking. Nicht "wir rankten hier heute für dieses Keyword", sondern "wir rankten hier für dieses Keyword, aus dieser Stadt, auf diesem Gerät, in dieser Minute". Ohne diese Detailtiefe bei der Attribuierung können sich zwei Tage an Daten leise widersprechen und du wirst nicht sagen können, welcher recht hatte. SEO-Teams, die geschützte Branchen überwachen, leben bereits damit. Wir haben auch darüber geschrieben, wie Bot-Detection verhaltensbasiert wurde, was eine vierte Achse (Session-Kontinuität) für Sites hinzufügt, die auf Request-Sequenzierung statt auf per-Request-Signale schauen.

Ergebnisse

Ein Rank-Tracker, der 5.000 Keywords in 12 Städten zweimal täglich überwacht, lag im alten num=100-System bei rund 120.000 Requests pro Tag. Jetzt sind es eher 1,2 Millionen, nach simpler Pagination-Mathematik (illustratives Szenario basierend auf Branchen-Benchmarks).

Teams, die dieses Modell auf einen Stack aus drei Produkten portiert haben, berichten meist:

  • 40-60 % Reduktion der Kosten pro Request im Vergleich zum Betrieb eines eigenen Proxy-Pools, vor allem, weil sie nicht mehr für Proxy-Churn, tote IPs und die Engineering-Stunden für die Wartung der Rotation zahlen.
  • Location-Genauigkeit auf Stadt-Ebene steigt von ~70 % auf über 95 %, weil Proxy Finder nach Stadt filtert und die Liveness beim letzten Check verifiziert, bevor der Proxy übergeben wird.
  • Kein spezieller Pfad für AI-Overviews. Ein Keyword, das über Single gefetcht wird, kann zu Browser befördert werden, ohne die Pipeline umzuschreiben. Der Vertrag ist identisch: URL rein, Response raus.

Du brauchst nichts davon für zehn Keywords und einen Laptop. Aber du brauchst es, sobald die Pipeline zehntausende Keywords über Länder hinweg überwacht, deine Kunden das Dashboard am Montag um 9 Uhr aktualisieren und die Rankings echt sein müssen.

Key Takeaway

Der harte Teil beim SERP-Monitoring ist schon lange nicht mehr der Request. Es ist das Routing. Aus wessen Stadt fetchst du? Ist die IP am Leben? Hat Google das Layout zurückgegeben, das ein echter Suchender an diesem Ort tatsächlich sehen würde, oder das leere, das sie ausliefern, wenn sie einen Scraper riechen?

Wenn du ein SEO-Team bist, das Rank-Tracking auf einem selbstgebauten Stack betreibt, ist die Frage für 2026 nicht, ob du Google scrapest. Das tust du bereits. Die Frage ist, ob deine Infrastruktur weiterhin vertrauenswürdige Rankings produzieren kann, wenn sich die Regeln ohne Vorwarnung ändern, und wie viel deines Engineering-Teams du bereit bist zu investieren, damit das so bleibt.