Ihr Positions-Tracker: Kostenberechnung für 1000 Schlüssel

SEO-Agenturen und interne Marketer stellen sich früher oder später die gleiche Frage: Warum für ein Abonnement eines Positions-Trackers bezahlen, wenn man einen eigenen Parser für die Suchergebnisse erstellen kann? Die Antwort ist nicht so einfach, wie sie scheint – die Kosten für das eigenständige Monitoring setzen sich nicht nur aus Servern zusammen, sondern auch aus Proxys, Captchas und der Zeit für die Unterstützung der Skripte. In diesem Artikel werden wir die tatsächliche Mathematik am Beispiel der Überprüfung von 1000 Schlüsselphrasen pro Tag untersuchen.

Warum Agenturen ihren eigenen Positions-Tracker erstellen

Fertige Dienste wie Topvisor, Serpstat, SE Ranking oder Rush Analytics sind bequem: Man muss sich keine Gedanken über Proxys, Captchas und Server machen – man gibt einfach die Schlüssel ein und erhält einen Bericht. Aber für diese Bequemlichkeit gibt es einen Preis, der proportional zur Anzahl der überprüften Phrasen und Regionen steigt. Wenn eine Agentur 15-20 Kunden betreut und jeder 500-2000 Schlüssel hat, erreicht die Rechnung für das Abonnement schnell eine Summe, die mit dem Gehalt eines Junior-Spezialisten vergleichbar ist.

Ein weiterer Grund ist die Flexibilität. In einem fertigen Dienst können Sie die Überprüfungsfrequenz für einzelne Schlüssel nicht ändern, keine benutzerdefinierte Logik hinzufügen (zum Beispiel nicht nur die Position, sondern auch den Snippet, das Vorhandensein von Schnelllinks oder Bewertungen verfolgen) und keine Rohdaten in Ihr BI-System exportieren. Ein eigener Tracker löst diese Aufgaben, erfordert jedoch Infrastruktur: Server, Datenbank, Parsing-Skripte und vor allem Proxys, um den Schutz der Suchmaschinen vor automatisierten Anfragen zu umgehen.

Der dritte Grund ist die Kontrolle über die Daten. Agenturen, die mit großen Kunden unter NDA arbeiten, sind nicht immer bereit, die Liste der Schlüsselanfragen und Domains an externe Cloud-Dienste weiterzugeben. Ein eigener Tracker ermöglicht es, alles in der eigenen Infrastruktur zu speichern.

Wie sich die Kosten für die Positionsüberprüfung zusammensetzen

Bevor man Geld zählt, muss man die Mechanik verstehen: Um die Position einer Website für eine Schlüsselanfrage zu erfahren, muss der Parser eine Anfrage an die Suchergebnisse von Yandex oder Google senden, die HTML-Seite der Ergebnisse abrufen und die benötigte Domain darin finden. Für 1000 Schlüssel pro Tag sind das mindestens 1000 Anfragen, und wenn Sie beide Suchmaschinen und mehrere Regionen überprüfen, vervielfacht sich die Zahl um das 2-4-fache.

Suchmaschinen blockieren automatisierte Anfragen von einer IP aggressiv: Nach 20-50 aufeinanderfolgenden Anfragen von einer Adresse beginnt Yandex, Captchas anzuzeigen, und Google sperrt die IP vorübergehend für mehrere Stunden. Daher muss jede Anfrage über einen separaten oder häufig wechselnden Proxy erfolgen. Daraus ergibt sich der Hauptkostenfaktor – nicht der Server oder das Skript, sondern die Proxy-Infrastruktur.

Die vollständige Kostenstruktur sieht folgendermaßen aus:

Proxys zur IP-Rotation – der Hauptkostenfaktor, abhängig vom Anfragevolumen
Server oder VPS zur Ausführung von Skripten nach Zeitplan – eine feste, geringe Summe
Captcha-Lösung (Anti-Captcha-Dienste) – zusätzliche Kosten, wenn die Proxys nicht von ausreichender Qualität sind
Entwicklerzeit für das Schreiben und die Unterstützung des Parsers – einmalige und periodische Kosten
Speicherung und Visualisierung von Daten – Datenbank, Dashboard, in der Regel minimale Ausgaben

Abonnement vs. eigener Tracker: Vergleich der Kostenarten

Um zu bewerten, wann ein eigener Tracker vorteilhafter ist als ein Abonnement, ist es praktisch, die Kostenarten direkt zu vergleichen. Unten finden Sie eine zusammenfassende Tabelle ohne Bezug auf spezifische Tarife, die die Logik der Auswahl zeigt.

Parameter	Fertiger Dienst (Abonnement)	Eigener Positions-Tracker
Kosten für 1000 Schlüssel/Tag	Steigt proportional zum Tarifplan, feste monatliche Summe	Setzt sich aus Proxy-Traffic + Servermiete zusammen, skaliert sanft
Flexibilität der Einstellungen	Durch die Funktionalität des Dienstes begrenzt	Vollständig – jede Frequenz, Region, Tiefe der Ergebnisse
Entwickler erforderlich	Nein	Ja, zu Beginn und regelmäßig zur Unterstützung
Risiko von Sperren/Captchas	Übernimmt der Dienst	Liegt bei Ihnen, wird durch Proxys und Verzögerungen gelöst
Rentabilitätspunkt	—	In der Regel ab 3000-5000 Schlüssel pro Tag und mehr

Die Schlussfolgerung aus der Tabelle ist einfach: Bei einem geringen Volumen an Schlüsseln (bis zu 2000-3000 pro Tag) ist das Abonnement fast immer vorteilhafter, da die Kosten für die Entwicklung und Unterstützung einer eigenen Lösung nicht rentabel sind. Aber bei großen Volumina – von mehreren Tausend Schlüsseln pro Tag, insbesondere wenn sie mehrmals täglich oder in verschiedenen Regionen überprüft werden müssen – beginnt die eigene Infrastruktur, wirtschaftlich zu gewinnen.

Proxy-Berechnung für 1000 Schlüssel pro Tag

Die Hauptfrage bei den Kosten ist, wie viele Proxys für 1000 Anfragen pro Tag ohne Sperren und Captchas benötigt werden. Nehmen wir die durchschnittlichen sicheren Limits, die in der Praxis von Parsing-Tools verwendet werden:

Yandex: 30-50 Anfragen von einer IP pro Tag ohne Risiko von Captchas bei zufälligen Verzögerungen zwischen den Anfragen von 10-30 Sekunden
Google: 15-25 Anfragen von einer IP pro Tag, das System sperrt strenger und schneller

Wenn Sie 1000 Schlüssel nur in Yandex überprüfen, benötigen Sie bei einem Limit von 40 Anfragen pro IP mindestens 25 einzigartige Adressen pro Tag. Berücksichtigen Sie Retrys bei fehlgeschlagenen Anfragen und einen Puffer für vorübergehende Sperren, planen Sie 30-40 IPs ein. Wenn Sie beide Suchmaschinen überprüfen, verdoppelt sich die Zahl – Sie benötigen etwa 60-80 IPs pro Tag.

Ein wichtiger Punkt: Bei der Arbeit über einen IP-Pool mit Rotation pro Anfrage (und nicht pro Sitzung) kann derselbe physische Proxy-Server viel mehr IP-Adressen "schließen", wenn der Anbieter eine dynamische Rotation bereitstellt. In diesem Fall erfolgt die Berechnung nicht nach der Anzahl der Adressen, sondern nach dem Datenvolumen – normalerweise wiegt eine Positionsüberprüfung 50-200 KB HTML, das heißt, 1000 Anfragen pro Tag sind 50-200 MB Datenverkehr, was für selbst den durchschnittlichen Tarif keine kritische Belastung darstellt.

Beispielberechnung für 1000 Schlüssel pro Tag (Yandex + Google):

2000 Anfragen pro Tag ÷ (30 Anfragen pro IP im Durchschnitt) ≈ 65-70 einzigartige IPs pro Tag. Bei einem durchschnittlichen Gewicht der Suchergebnisse von 100 KB beträgt der gesamte Datenverkehr etwa 200 MB pro Tag, oder etwa 6 GB pro Monat – genau diese Zahl sollten Sie bei der Auswahl eines Tarifs für den Datenverkehr bei Ihrem Proxy-Anbieter einplanen.

Welche Proxys für Yandex und Google benötigt werden

Der Typ des Proxys beeinflusst direkt, wie viele Captchas und Sperren Sie erhalten, und damit die tatsächlichen Kosten der Überprüfung. Lassen Sie uns drei Optionen untersuchen.

Rechenzentrums-Proxys – die günstigste Option hinsichtlich der Kosten für Datenverkehr, aber sie haben einen schlechten Ruf in den Datenbanken der Suchmaschinen: IPs von Rechenzentren werden massenhaft für das Parsen verwendet, weshalb Yandex und Google sie schnell erkennen und bereits nach wenigen Anfragen Captchas anzeigen. Für die Überprüfung von wenigen Schlüsselwörtern mit niedriger Frequenz Rechenzentrums-Proxys können noch verwendet werden, aber bei einem Volumen von 1000+ Anfragen pro Tag wird der Anteil an Captchas zu hoch, und die Einsparungen beim Datenverkehr werden durch die Kosten für Anti-Captchas aufgezehrt.

Residential-Proxys – IP-Adressen echter Haushaltsnutzer, die von den Suchmaschinen als normaler Datenverkehr wahrgenommen werden. Der Anteil an Captchas ist hier um ein Vielfaches niedriger, was bei großen Überprüfungsvolumina entscheidend ist. Für das Parsen von Suchergebnissen mit 1000 und mehr Schlüsselwörtern pro Tag bieten Residential-Proxys in der Regel das beste Verhältnis von Kosten zu Stabilität, insbesondere bei der Arbeit mit Google, das die IPs von Rechenzentren am strengsten sperrt.

Mobile Proxys – verwenden IPs von Mobilfunkanbietern, die sich häufig bei Tausenden von echten Abonnenten ändern (NAT), sodass dieselbe Adresse im Laufe des Tages verschiedenen Nutzern "gehören" kann. Dies bietet maximale Lebensdauer beim aggressiven Parsen, ist jedoch teurer. Mobile Proxys sind gerechtfertigt, wenn Sie die Positionen in den mobilen Suchergebnissen separat von den Desktop-Ergebnissen überprüfen oder mit besonders anspruchsvollen regionalen Anfragen von Yandex arbeiten.

Proxy-Typ	Anteil an Captchas bei 1000 Anfragen	Wann verwenden
Rechenzentrum	Hoch	Bis zu 200-300 Schlüssel pro Tag, niedrige Frequenz
Residential	Niedrig	1000+ Schlüssel pro Tag, Google und Yandex
Mobil	Minimal	Mobile Suchergebnisse, komplexe Regionen

Schritt-für-Schritt-Anleitung zur Einrichtung des eigenen Trackers

Lassen Sie uns den Prozess des Aufbaus eines eigenen Positions-Trackers Schritt für Schritt durchgehen – ohne tiefes Eintauchen in den Code, auf der Ebene der Architektur der Lösung.

Wahl der Datenquelle. Bestimmen Sie, ob Sie die Suchergebnisse direkt über HTTP-Anfragen parsen oder einen Headless-Browser (z.B. über Puppeteer/Playwright) verwenden, um einen echten Benutzer zu simulieren. Letzteres ist zuverlässiger gegen Anti-Bot-Schutz, aber langsamer und ressourcenintensiver für den Server.
Einrichtung des Proxy-Pools. Verbinden Sie einen Proxy-Anbieter mit IP-Rotation pro Anfrage oder nach Zeit. Für Yandex und Google ist es besser, unterschiedliche Proxy-Pools zu verwenden, da die Systeme unterschiedliche Sperrgrenzen haben.
Logik der Retrys. Wenn die Anfrage ein Captcha oder einen Fehler zurückgibt, sollte das Skript automatisch die IP wechseln und die Anfrage wiederholen, anstatt einfach den Fehler zu protokollieren.
Parsing des Ergebnisses. Aus dem erhaltenen HTML wird die Position der benötigten Domain in den Ergebnissen extrahiert – normalerweise durch das Suchen nach Link-Tags und den Vergleich mit der Domain des Kunden.
Speicherung der Historie. Die Ergebnisse werden in einer Datenbank mit dem Überprüfungsdatum gespeichert, um Grafiken zur Dynamik der Positionen erstellen zu können.
Zeitplan für die Ausführung. Das Skript wird über Cron oder den Task-Planer einmal täglich (oder häufiger) ausgeführt, wobei die 1000 Anfragen gleichmäßig über die Zeit verteilt werden, um keine Spitzenlast auf den Proxy-Pool zu erzeugen.

Beispielcode zur Positionsüberprüfung in Python

Unten finden Sie ein vereinfachtes Beispiel für die Logik einer Anfrage an die Suchergebnisse über Proxys mit Rotation. Dies ist ein Demonstrationsgerüst, das das Prinzip der Funktionsweise zeigt, und keine fertige Lösung.

import requests
import random
import time

PROXY_LIST = [
    "http://user:[email protected]:8000",
    "http://user:[email protected]:8000",
    # ... Proxy-Pool aus Hunderten von Adressen
]

HEADERS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

def check_position(keyword, domain, search_engine="yandex"):
    proxy = random.choice(PROXY_LIST)
    proxies = {"http": proxy, "https": proxy}

    if search_engine == "yandex":
        url = f"https://yandex.ru/search/?text={keyword}"
    else:
        url = f"https://www.google.com/search?q={keyword}"

    try:
        response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=10)
        if "captcha" in response.text.lower():
            return None  # IP-Rotation und Wiederholung der Anfrage erforderlich
        position = find_domain_position(response.text, domain)
        return position
    except requests.RequestException:
        return None

def find_domain_position(html, domain):
    # vereinfachte Logik zur Suche der Position der Domain in den Ergebnissen
    results = extract_links(html)
    for i, link in enumerate(results, start=1):
        if domain in link:
            return i
    return None

for keyword in keyword_list:
    pos = check_position(keyword, "example.com")
    save_to_db(keyword, pos)
    time.sleep(random.uniform(5, 15))  # zufällige Verzögerung zwischen den Anfragen

In einem realen Projekt wird anstelle des manuellen Parsens von HTML häufig ein Headless-Browser mit User-Agent- und Fingerprint-Änderung verwendet, und der Proxy-Pool wird über einen Anbieter mit automatischer Rotation auf Endpoint-Ebene angeschlossen – dies beseitigt die Notwendigkeit, die Liste der Adressen manuell zu speichern und erleichtert die Skalierung auf mehrere Tausend Anfragen pro Tag.

Wie viel man wirklich sparen kann

Um die Frage der Einsparungen zu beantworten, müssen zwei Modelle der Ausgaben im Zeitverlauf verglichen werden, während das Volumen der Schlüssel wächst.

Bei einem geringen Volumen – bis zu 1000-2000 Schlüssel pro Tag – sind die Kosten für ein Abonnement eines fertigen Trackers in der Regel vergleichbar oder sogar niedriger als die Gesamtkosten für die Entwicklung und Unterstützung einer eigenen Lösung, wenn man die Zeit des Spezialisten berücksichtigt. Die Entwicklung eines minimal lebensfähigen Parsers von Grund auf dauert von mehreren Tagen bis zu ein paar Wochen, plus regelmäßige Unterstützung bei Änderungen im Layout der Suchergebnisse – und Yandex und Google ändern die Struktur der Ergebnisse nicht selten.

Der Wendepunkt tritt ein, wenn das Überprüfungsvolumen auf mehrere Tausend Schlüssel pro Tag wächst oder wenn die Positionen mehrmals täglich in verschiedenen Regionen und Geräten (Desktop/Mobil) überprüft werden müssen. In diesem Szenario steigen die Kosten für ein fertiges Abonnement linear oder sogar progressiv mit dem Volumen, während die Ausgaben für den eigenen Tracker viel langsamer steigen – der Hauptkostenfaktor (Proxy-Traffic) wird nicht so stark teurer wie die Tarifpläne von SaaS-Diensten beim Wechsel auf die nächste Paketstufe.

Praktische Orientierung für Agenturen: Wenn Sie die Positionen von 5-10 oder mehr Kunden gleichzeitig verfolgen, überschreitet das Gesamtvolumen normalerweise 5000-10000 Schlüsselphrasen pro Tag – genau in diesem Maßstab ist der eigene Tracker fast immer vorteilhafter als jedes fertige Abonnement, vorausgesetzt, es gibt im Team jemanden, der in der Lage ist, den Parser zu unterstützen.

Häufige Fehler beim eigenständigen Parsen

In der Praxis hängen die meisten Probleme mit dem eigenen Positions-Tracker nicht mit dem Code zusammen, sondern mit der Unterschätzung infrastruktureller Nuancen.

Einsparungen bei Proxys. Der Versuch, bei billigen Rechenzentrums-Proxys zu sparen, führt zu massiven Captchas, die über externe Anti-Captcha-Dienste gelöst werden müssen – letztendlich sind die Gesamtkosten höher als bei der Verwendung qualitativ hochwertiger Proxys von Anfang an.
Fehlende Verzögerungen zwischen Anfragen. Zu schnelle aufeinanderfolgende Anfragen von einer IP ziehen sofort die Aufmerksamkeit von Anti-Bot-Systemen auf sich, selbst wenn die IP von hoher Qualität ist.
Ignorieren der Regionalität. Yandex zeigt unterschiedliche Ergebnisse je nach Region des Nutzers an – ohne die richtige Geolokalisierung der Proxys sind die Daten über die Positionen ungenau.
Fehlendes Monitoring der Gesundheit des Parsers. Suchmaschinen ändern gelegentlich das Layout der Suchergebnisseite, und ohne Alarme für den Rückgang der Parsing-Erfolgsquote kann man wochenlang leere oder falsche Daten sammeln, ohne es zu bemerken.
Ignorieren der mobilen Ergebnisse. Desktop- und mobile Ergebnisse unterscheiden sich oft, und wenn dem Kunden die mobile Position wichtig ist, ist ein separater Parsing-Kontur mit entsprechenden User-Agents und idealerweise mobilen IPs erforderlich.

Fazit

Ein eigener Positions-Tracker wird wirtschaftlich sinnvoll, wenn das Überprüfungsvolumen mehrere Tausend Schlüssel pro Tag übersteigt und im Team Ressourcen zur Unterstützung des Parsers vorhanden sind. Bei geringeren Volumina ist ein fertiges Abonnement fast immer günstiger, wenn man die versteckten Kosten für die Entwicklung berücksichtigt. Der Hauptkostenfaktor bei der eigenen Lösung sind nicht der Server und nicht der Code, sondern die Proxy-Infrastruktur, die den Anteil an Captchas und die Stabilität der Daten bestimmt.

Wenn Sie planen, einen Positions-Tracker für 1000 und mehr Schlüssel pro Tag zu erstellen, beginnen Sie mit der Berechnung des Datenverkehrs und einem Test-Pool von Proxys für eine kleine Auswahl von Anfragen. Für stabiles Parsing von Yandex und Google in solchen Volumina ist es sinnvoll, sofort Residential-Proxys einzuplanen – sie bieten einen minimalen Anteil an Captchas bei akzeptablen Kosten für den Datenverkehr und skalieren gut mit der Zunahme der überwachten Kunden.