SEO Tool Software beschaffen: Datenherkunft, Betriebsmodell, Datenhoheit und Integration klären

Die schwierige Frage bei SEO Tool Software ist selten, welche Funktionen ein Produkt hat. Schwierig ist die Frage, woher seine Zahlen kommen, wo sie verarbeitet werden, wem sie gehören und wie sie wieder herauskommen. Diese vier Punkte entscheiden darüber, ob ein Werkzeug in eine bestehende Arbeits- und Datenlandschaft passt. Eine Funktionsliste entscheidet das nicht.

Diese Seite ordnet deshalb keine Anbieter, sondern die Beschaffungsentscheidung selbst. Sie beschreibt zuerst, was Einzel-Tool, Software und Suite als Beschaffungsumfänge unterscheidet, und geht dann die vier Achsen durch, die vor jeder Anschaffung geklärt sein sollten. Am Ende steht eine Entscheidungslogik, keine Empfehlung.

Einzel-Tool, Software, Suite: drei Umfänge, keine drei Qualitätsstufen

Ein Einzel-Tool löst eine abgegrenzte Aufgabe: es crawlt, es prüft ein technisches Merkmal, es liefert eine Kennzahl. Seine Ergebnisse müssen exportiert und außerhalb des Werkzeugs mit anderen Daten zusammengeführt werden. Diese Zusammenführung ist Arbeit, die dann bei der eigenen Organisation liegt.

SEO-Software verbindet mehrere Funktionen in einem Produkt. Beschaffungsrelevant ist dabei nicht die Zahl der Funktionen, sondern die Frage, ob Projekte, Benutzerrechte, Historien und Berichte tatsächlich gemeinsam verwaltet werden oder nur gemeinsam angezeigt.

Eine Suite bündelt Module unter einer Oberfläche und meist unter einem Vertrags- und Berechtigungsmodell. Sie garantiert damit weder eine gemeinsame Datenbasis noch vergleichbare Kennzahlen zwischen den Modulen. Auch innerhalb einer Suite stehen gemessene Daten, anbietereigene Indexwerte und Crawl-Ergebnisse in der Regel nebeneinander, mit unterschiedlichen Erhebungszeitpunkten und unterschiedlichen Definitionen.

Die erste Beschaffungsfrage lautet deshalb nicht, welche Lösung am meisten kann. Sie lautet: Welche Aufgaben sollen in einem gemeinsamen System bearbeitet werden, und welche Daten müssen dafür zusammenfließen? Wer das beantwortet, hat den Umfang bestimmt, bevor er Produkte ansieht.

Achse 1: Datenherkunft, oder warum zwei Werkzeuge unterschiedliche Zahlen zeigen

Wenn zwei Werkzeuge für dieselbe Seite verschiedene Zahlen ausweisen, ist das meist kein Fehler. Sie messen unterschiedliche Gegenstände mit unterschiedlichen Methoden. Drei Herkunftsarten sollten sich unterscheiden lassen.

Eigene gemessene Daten

Gemessene Daten entstehen dort, wo ein System reale Vorgänge für eine kontrollierte Property erfasst. Die Google Search Console ist der Standardfall: kostenlos, aber ausschließlich für Properties, deren Inhaberschaft bestätigt wurde, und mit einem Leistungsbericht, der Daten 16 Monate vorhält. Diese 16 Monate sind eine harte Beschaffungsgröße. Wer längere Zeitreihen braucht, muss die Daten selbst wegschreiben, egal welche Software er kauft.

Microsoft stellt mit den Bing Webmaster Tools ein eigenes, ebenfalls kostenloses Pendant für den Bing-Index bereit. Die Werte beider Systeme sind nicht austauschbar, weil sie sich auf verschiedene Suchmaschinen und Datenbestände beziehen.

Gemessene Daten sind belastbar für die eigene Property und blind für alles andere. Sie sagen nichts über Wettbewerber und nichts über Suchanfragen, für die die eigene Seite nie erschienen ist.

Anbietereigene Indizes und Modellwerte

Viele Anbieter bauen eigene Datenbestände auf: sie fragen Suchergebnisse für ausgewählte Keyword-Sets ab, erfassen Verweise zwischen Websites und rechnen daraus Kennzahlen. Das ermöglicht Marktbeobachtung ohne Zugriff auf fremde Systeme, bildet aber nie den vollständigen Bestand einer Suchmaschine ab.

Der Sistrix Sichtbarkeitsindex ist ein gutes Beispiel für diese Klasse: eine anbietereigene Kennzahl auf Basis eines festen, regelmäßig abgefragten Keyword-Sets, die ausdrücklich keine absolute Besucherzahl abbildet. Andere Anbieter verwenden andere Sets, Gewichtungen und Modelle. Zwei Sichtbarkeitswerte sind daher genauso wenig vergleichbar wie zwei Schulnoten aus verschiedenen Fächern.

Bezeichnungen können dabei täuschen. Google hat die öffentliche Anzeige des Toolbar-PageRank 2016 endgültig eingestellt. Wenn eine heutige Software weiterhin einen PageRank-Wert ausweist, zeigt sie eine Ersatzmetrik des jeweiligen Anbieters, nicht den früher öffentlich sichtbaren Google-Wert. Für die Beschaffung heißt das: ein vertrauter Metrikname ist kein Beleg für eine vertraute Datenquelle.

Auch die Genauigkeit einer Quelle kann von den eigenen Vertragsverhältnissen abhängen. Der Google Keyword-Planer gibt Suchvolumen für Konten ohne ausreichende Anzeigenaktivität nur als grobe Spanne statt als exakten Wert aus. Dieselbe Quelle liefert also je nach Konto unterschiedlich scharfe Zahlen, und Werkzeuge, die darauf aufsetzen, erben diese Unschärfe.

Daten aus einem eigenen Crawl

Ein Crawler ruft erreichbare URLs nach vorgegebenen Regeln ab und erfasst Statuscodes, Weiterleitungen, Überschriften, interne Verlinkung und weitere technische Merkmale. Das Ergebnis beschreibt exakt das, was dieser Lauf unter diesen Regeln sehen konnte. Start-URLs, Crawl-Tiefe, Ausschlussregeln, JavaScript-Verarbeitung, Authentifizierung und Serverantworten bestimmen das Ergebnis mit. Ein Crawl ist damit weder ein Abbild des Suchmaschinenindex noch ein Nachweis, dass eine URL gesucht oder besucht wurde.

Crawls laufen häufig lokal. Der Screaming Frog SEO Spider ist eine lokal installierte Desktop-Anwendung; die kostenlose Version crawlt bis zu 500 URLs pro Crawl, die Lizenz hebt dieses Limit auf. Diese Grenze ist eine Produkteigenschaft, keine Aussage über Datenqualität, und sie ist genau die Art Detail, die bei der Dimensionierung eines Einsatzes vorher bekannt sein muss.

Selbst eine Quelle kann zwei Zahlen haben

Der Unterschied liegt nicht immer zwischen zwei Werkzeugen. PageSpeed Insights kombiniert Labordaten aus Lighthouse mit Felddaten echter Nutzer aus dem Chrome UX Report, und beide Werte können deshalb voneinander abweichen. Wer nur einen der beiden in ein Reporting übernimmt, dokumentiert damit stillschweigend eine Methodenentscheidung. Genau solche Entscheidungen sollten sichtbar sein.

Das Herkunftsetikett

Bevor eine Kennzahl in einen Bericht oder eine Entscheidung eingeht, sollten fünf Angaben festgehalten sein:

1. Welches Objekt wird gemessen: eine Property, ein Keyword-Set, eine Liste erreichbarer URLs?
2. Aus welcher Quelle stammt der Wert?
3. Auf welchen Zeitraum bezieht er sich, und wann wurde er erhoben?
4. Welche Filter, Hochrechnungen oder Gewichtungen liegen darunter?
5. Ist es ein Messwert, eine Beobachtung oder eine Schätzung?

Eine Abweichung zwischen zwei Systemen ist zunächst ein Hinweis auf zwei Definitionen, nicht auf einen Defekt.

Achse 2: Betriebsmodell

Das Betriebsmodell verteilt vier Lasten: Infrastruktur, Aktualisierung, Zugriffssicherung und Datenhaltung. Vier Grundformen sind zu unterscheiden.

SaaS. Der Anbieter stellt die Anwendung über das Web bereit und trägt Betrieb, Updates und Skalierung. Der Zugang für verteilte Teams ist einfach. Im Gegenzug verlassen die Daten die eigene Infrastruktur, und Verfügbarkeit, Benutzerverwaltung, Unterauftragnehmer, Exportwege und Vertragsbedingungen werden zu Auswahlkriterien erster Ordnung.

Lokale Desktop-Anwendung. Sie läuft auf einem Arbeitsplatz oder internen Rechner und eignet sich für rechenintensive Crawls und Projekte, deren Daten das Haus nicht verlassen sollen. Installation, Aktualisierung, Sicherung und Lizenzverteilung liegen dann bei der eigenen Organisation; gemeinsame Nutzung und eine durchgehende Historie müssen separat organisiert werden, weil die Ergebnisse zunächst auf einem einzelnen Gerät liegen.

API-gestützte Eigenauswertung. Ein externer Dienst liefert Daten über eine Schnittstelle, Speicherung und Auswertung passieren in der eigenen Datenplattform. Das ist das flexibelste Modell und das mit dem höchsten Dauerbedarf an technischer Betreuung: Abruflimits, Pagination, Wiederholungslogik, Authentifizierung und Schemaänderungen sind laufende Aufgaben, keine einmalige Einrichtung. Vertraglich zu klären ist zusätzlich, wie lange bezogene Daten gespeichert und wofür sie weiterverwendet werden dürfen.

On-Premise. Die Software läuft in der eigenen Infrastruktur oder einer kontrollierten Hosting-Umgebung. Das unterstützt Anforderungen an Datenhaltung und Netztrennung, beseitigt aber keine Datenschutzfrage automatisch: Updates, Schwachstellenmanagement, Backups und Zugriffskontrolle wandern zur eigenen Organisation, und einzelne Funktionen können weiterhin externe Schnittstellen aufrufen. Die Frage, welche ausgehenden Verbindungen ein On-Premise-Produkt benötigt, gehört in die Ausschreibung.

Die meisten realen Aufbauten mischen. Eine Kombination aus gemessenen Daten über API, einem lokalen Crawler und einer gehosteten Oberfläche ist eher Normalfall als Ausnahme. Wichtig ist, dass die Mischung bewusst entsteht und nicht als Nebenwirkung.

Achse 3: Datenhoheit und DSGVO

Die Datenschutzprüfung beginnt nicht beim ersten Import, sondern bei der Anforderungsanalyse. Zuerst ist zu klären, welche Daten überhaupt verarbeitet werden. Neben aggregierten Kennzahlen sind das häufig URLs, Suchanfragen, Namen in Titeln, Benutzerkonten und Protokolldaten. Besonders URLs und Exporte sollten daraufhin geprüft werden, ob sie Kundennummern, E-Mail-Adressen oder andere Identifikatoren in Parametern tragen.

Verarbeitet ein Cloud-Anbieter personenbezogene Daten im Auftrag, ist nach Art. 28 Abs. 3 DSGVO ein Auftragsverarbeitungsvertrag erforderlich. Er ist die Mindestbedingung, nicht die vollständige Prüfung. Zusätzlich sollten schriftlich vorliegen:

• Speicherort nach Land und konkretem Rechenzentrum, nicht nur nach Region.
• Liste der Unterauftragnehmer und das Verfahren, wie Änderungen daran angekündigt werden.
• Ob und auf welcher Grundlage Übermittlungen in Staaten außerhalb des Europäischen Wirtschaftsraums stattfinden.
• Löschfristen für Projekte, Exporte, Protokolle und Backups.
• Ob Kundendaten für Produktentwicklung oder Modelltraining genutzt werden.
• Ob das System zentrale Benutzerverwaltung, Rollen, Mehrfaktor-Authentifizierung und Audit-Protokolle unterstützt.

Datenhoheit ist dabei mehr als ein Serverstandort. Sie ist die praktische Fähigkeit, Daten vollständig zu exportieren, Zugriffsrechte kurzfristig zu entziehen, Aufbewahrungsfristen durchzusetzen und den Anbieter zu wechseln, ohne die Historie zu verlieren. Ein Standort in der EU ohne brauchbaren Vollexport ist weniger Hoheit als ein sauberer Exportweg.

Achse 4: Integrationsfähigkeit

Der Hinweis auf eine API trägt eine Architekturentscheidung nicht. Entscheidend ist, welche Daten in welcher Granularität und mit welcher Stabilität herauskommen. Zu prüfen sind:

• Welche Entitäten und Kennzahlen die Schnittstelle liefert und ob Rohdaten abrufbar sind oder nur fertige Aggregate.
• Welche Abruflimits und zeitlichen Beschränkungen gelten und wie sich ein vollständiger Erstabzug darunter ausgeht.
• Ob es stabile Kennungen für Properties, URLs, Projekte und Messläufe gibt, an denen sich Daten über die Zeit verknüpfen lassen.
• Ob historische Werte nachträglich korrigiert werden und ob solche Korrekturen erkennbar sind.
• Wie Änderungen an Endpunkten und Feldern angekündigt werden.
• Ob vollständige Exporte in offenen Formaten möglich sind, unabhängig von der Oberfläche.

Für eigene Reports kommt eine Anforderung hinzu, die kein Anbieter von sich aus stellt: Werte verschiedener Herkunft müssen im Bericht getrennt bleiben. Ein Dashboard sollte erkennen lassen, ob eine Zahl gemessen, modelliert oder gecrawlt ist. Ohne dieses Etikett legen einheitlich aussehende Berichte Vergleiche nahe, die methodisch nicht tragen.

Und der Rückweg zählt genauso: Kann die Software eigene Daten aufnehmen, etwa Seitentypen, Verantwortlichkeiten oder Release-Zeitpunkte? Erst diese Verknüpfung macht Auswertungen möglich, die über Standardberichte hinausgehen, weil sie Veränderungen in den Zahlen mit Ereignissen im eigenen Betrieb zusammenbringen.

Eine Entscheidungslogik

Die vier Achsen ergeben eine Reihenfolge, in der eine Beschaffung abgearbeitet werden kann:

1. Zweck festlegen. Welche wiederkehrende Entscheidung soll das Werkzeug tragen? Ohne diese Antwort ist jede Funktion gleich wichtig.
2. Datenarten bestimmen. Braucht die Entscheidung gemessene Daten der eigenen Property, Marktbeobachtung, technische Crawl-Daten oder eine Kombination?
3. Betriebsgrenzen ziehen. Welche Daten dürfen externe Systeme erreichen, welche nicht? Diese Grenze schließt Betriebsmodelle aus, bevor Produkte geprüft werden.
4. Verantwortung zuordnen. Wer betreibt Schnittstellen, Updates, Konten, Backups und Importe, und mit welcher Kapazität?
5. Integration prüfen. Müssen Rohdaten in ein bestehendes Warehouse oder eigene Reports fließen, oder genügt die mitgelieferte Oberfläche?
6. Ausstieg planen. Der Anbietermarkt konsolidiert. Searchmetrics wurde 2023 von Conductor übernommen und die Marke in dessen Plattform überführt. Zeitreihen, die nur im Werkzeug eines Anbieters liegen, sind an dessen Fortbestand gebunden; eigene Kopien der Rohdaten sind es nicht.
7. Pilot an echten Fällen fahren. Nicht Funktionen abhaken, sondern zwei oder drei reale Arbeitsabläufe durchspielen, inklusive Export und Zusammenführung mit vorhandenen Daten.

Kleine Aufgabenzuschnitte lassen sich bewusst aus mehreren spezialisierten Komponenten bauen. Größere Teams profitieren von gemeinsamen Projekten, Rollen und standardisierten Datenflüssen. Wo eigene Datenmodelle und Berichte den Ausschlag geben, wiegt eine belastbare Schnittstelle schwerer als eine umfangreiche Oberfläche.

Die passende SEO Tool Software folgt damit nicht aus einer Reihung von Produkten, sondern aus der Kombination von Datenherkunft, Betriebsmodell, Datenschutzanforderung und Integrationsbedarf. Wer diese vier Achsen vor der Anschaffung schriftlich festhält, beurteilt Produkte an der eigenen Architektur, statt die eigene Organisation nachträglich an ein Produkt anzupassen.