SEO Optimization Software auswählen: Vom Workflow über den Pilot zum belastbaren Stack

Die Frage “Welche SEO Optimization Software kaufen wir?” ist in den meisten Unternehmen die falsche erste Frage. Sie ist eher die vierte. Davor liegen drei Fragen, die niemand außerhalb des eigenen Hauses beantworten kann: Wie läuft unsere SEO-Arbeit heute tatsächlich ab, welche Entscheidungen wollen wir künftig auf Daten stützen, und welche Daten stehen uns dafür überhaupt zur Verfügung? Wer diese drei Fragen überspringt, kauft am Ende Funktionen, die im Alltag niemand öffnet, und vermisst genau die eine Schnittstelle, an der die Arbeit jeden Montagmorgen hängen bleibt.

Diese Seite ist deshalb bewusst kein Anbieterüberblick und keine Kaufempfehlung. Sie ist ein Vorgehen, das Sie in überschaubarer Zeit selbst durchlaufen können: Sie modellieren Ihren SEO-Workflow, leiten daraus Muss- und Kann-Funktionen ab, prüfen die verfügbaren Datenquellen samt ihrer Grenzen, fahren einen zeitlich begrenzten Pilot mit vorher definierten Testfällen und leiten aus messbaren Kriterien einen Software-Stack ab, den Sie gegenüber Geschäftsführung und Einkauf sauber begründen können. Das Ergebnis ist am Ende möglicherweise ein einzelnes Produkt. Häufiger ist es eine Kombination aus zwei oder drei Bausteinen plus den kostenlosen Datenquellen der Suchmaschinen.

Warum Funktionslisten die falsche Auswahlgrundlage sind

Jede Software beschreibt sich über ihre Funktionen. Ein Unternehmen entscheidet aber nicht über Funktionen, sondern über Arbeitsabläufe. Der Unterschied wird an einem Beispiel deutlich: Zwei Systeme bieten beide “Onpage-Analyse”. Das eine liefert eine Liste mit Befunden pro URL. Das andere ordnet Befunde einer verantwortlichen Person zu, führt einen Bearbeitungsstatus mit und meldet, wenn ein behobener Befund erneut auftritt. Auf einer Funktionsliste steht in beiden Zeilen dasselbe Wort. Im Betrieb unterscheiden sich die Systeme fundamental, und zwar entlang der Frage, ob Ihr Team seine Befunde ohnehin schon in einem Ticketsystem führt oder nicht.

Deshalb beginnt eine belastbare Auswahl nicht mit dem Markt, sondern mit dem eigenen Haus. Sie brauchen ein Modell Ihres Workflows, das konkret genug ist, um daraus Anforderungen abzuleiten, und grob genug, um es in ein bis zwei Arbeitstagen zu erstellen.

Was ein Auswahlprozess leisten muss

Ein Auswahlprozess, der diesen Namen verdient, erfüllt vier Bedingungen:

1. Er ist nachvollziehbar. Nach der Entscheidung muss jemand, der nicht dabei war, in zehn Minuten verstehen, warum diese Lösung gewählt wurde und welche Alternative an welchem Kriterium gescheitert ist.
2. Er ist überprüfbar. Die Annahmen der Auswahl werden im Pilot getestet, nicht geglaubt. Eine Zusage aus einem Verkaufsgespräch ist eine Hypothese, kein Befund.
3. Er ist begrenzt. Auswahl darf Wochen dauern, nicht Quartale. Ein Prozess, der sich über sechs Monate zieht, kostet mehr Arbeitszeit als die Lizenz, über die er entscheidet.
4. Er ist umkehrbar. Sie kalkulieren von Anfang an, was ein Wechsel in zwei Jahren kosten würde: Datenexport, Historie, eingearbeitete Prozesse, Vertragsbindung.

Schritt 1: Den SEO-Workflow modellieren

Modellieren heißt hier: aufschreiben, was tatsächlich passiert, nicht was im Prozesshandbuch steht. Nehmen Sie sich die letzten acht bis zwölf Wochen SEO-Arbeit vor und rekonstruieren Sie sie Schritt für Schritt. Für jeden Arbeitsschritt beantworten Sie fünf Fragen.

Auslöser. Was startet den Schritt? Ein Termin (“jeden ersten Montag im Monat”), ein Ereignis (“Traffic auf einer Kategorieseite bricht ein”), eine Anfrage (“das Produktmanagement kündigt eine neue Serie an”) oder ein Systemsignal (“der Crawler meldet neue Fehler”).

Eingaben. Welche Daten und Dokumente braucht der Schritt? Suchanfragen und Klickdaten, ein Crawl-Ergebnis, eine Preisliste, ein Redaktionsplan, ein Backlog aus dem Ticketsystem.

Tätigkeit. Was tut die Person konkret? “Analysieren” ist keine Tätigkeit. “Klick- und Impressionsdaten der letzten 28 Tage mit dem Vorzeitraum vergleichen und alle URLs mit einem Rückgang über einem Schwellenwert markieren” ist eine.

Ausgabe. Was verlässt den Schritt in einer Form, die jemand anders weiterverwenden kann? Ein Ticket, ein Briefing, eine Freigabe, ein Report, eine geänderte Datei im Repository.

Übergabe. An wen geht die Ausgabe, in welchem System, und woran erkennt der Empfänger, dass sie angekommen ist?

Wenn Sie diese fünf Fragen für jeden Schritt beantworten, entsteht typischerweise eine Kette aus acht bis fünfzehn Schritten. Für viele Unternehmen sieht sie in etwa so aus: Nachfrage erheben, Themen priorisieren, Seiten planen, Inhalte erstellen, technisch prüfen, veröffentlichen, Indexierung kontrollieren, Wirkung messen, nachbessern. Ihre Kette wird anders aussehen, und genau diese Unterschiede sind der Grund, warum kein generischer Vergleich Ihre Entscheidung abnehmen kann.

Die Übergaben sind der eigentliche Befund

Interessant an diesem Modell sind nicht die Schritte, sondern die Übergaben. Genau dort entstehen die Kosten, die im Alltag niemand als Softwareproblem erkennt: Ein Report wird als Tabelle exportiert, per Mail verschickt, von Hand in ein Ticket übertragen, dort um eine Priorität ergänzt und zwei Wochen später aus einem anderen Werkzeug erneut nachgeschlagen, weil niemand weiß, ob der Befund noch aktuell ist.

Markieren Sie jede Übergabe, die heute manuell erfolgt, und schätzen Sie den Aufwand pro Monat. Diese Liste ist später Ihre wichtigste Anforderungsquelle, denn sie beschreibt Arbeit, die Software übernehmen kann. Funktionen, die keine Übergabe verbessern und keine Entscheidung ermöglichen, sind für Ihre Auswahl nachrangig, egal wie beeindruckend sie in der Demo aussehen.

Rollen und Mengengerüst festhalten

Zwei Zahlen brauchen Sie, bevor Sie mit Anbietern sprechen, weil sie fast jede Lizenz- und Architekturfrage beeinflussen:

• Wie viele Personen arbeiten in welcher Rolle mit dem System? Unterscheiden Sie mindestens drei Gruppen: Personen, die konfigurieren und auswerten, Personen, die Aufgaben abarbeiten, und Personen, die nur lesen wollen, etwa Geschäftsführung, Vertrieb oder Kunden.
• Wie groß ist der zu betreuende Bestand? Anzahl Domains und Subdomains, Sprachversionen, ungefähre Anzahl indexierbarer URLs, Anzahl relevanter Suchanfragen, Anzahl Standorte bei lokalem Geschäft.

Ein Unternehmen mit einer Domain, 400 URLs und zwei Personen im Marketing braucht eine andere Lösung als eines mit zwölf Länderdomains, sechsstelliger URL-Zahl und einer eigenen Entwicklungsabteilung. Diese Unterscheidung trifft kein Vergleichstest für Sie, aber sie entscheidet über Lizenzstufen, Limits und Betriebsmodell.

Schritt 2: Anforderungen als Muss, Kann und Ausschluss formulieren

Aus dem Workflow-Modell werden Anforderungen. Formulieren Sie jede Anforderung als Satz, der einen Arbeitsschritt nennt und ein überprüfbares Ergebnis fordert. Gute Anforderungen klingen langweilig und konkret:

“Das System muss für eine Liste von bis zu 500 URLs täglich melden, ob die URL in der Google-Suche indexiert ist, und die Änderung gegenüber dem Vortag ausweisen.”

“Das System muss Klick- und Impressionsdaten pro URL und Suchanfrage für mindestens 16 Monate rückwirkend exportierbar bereitstellen, im CSV-Format oder über eine Schnittstelle.”

Schlechte Anforderungen klingen wie Marketing: “Das System soll leistungsfähige Analysen bieten.” Solche Sätze lassen sich im Pilot nicht prüfen und sind damit für die Auswahl wertlos.

Die drei Kategorien

Muss. Ohne diese Funktion ist der Workflow nicht durchführbar oder eine Entscheidung nicht möglich. Halten Sie diese Liste kurz. Wenn Sie zwanzig Muss-Kriterien haben, sind einige davon in Wahrheit Kann-Kriterien, und Ihre Auswahl wird künstlich leer, weil kein System alle besteht.

Kann. Nützlich, ersetzt Handarbeit, verbessert Qualität, ist aber überbrückbar. Kann-Kriterien werden gewichtet, nicht als Ausschluss verwendet.

Ausschluss. Bedingungen, unter denen ein System nicht in Frage kommt, unabhängig von seinen Funktionen. Typische Ausschlüsse betreffen Datenverarbeitung und Vertragsgestaltung, das Betriebsmodell (Cloud oder eigener Betrieb), eine fehlende Exportmöglichkeit oder eine fehlende Schnittstelle, wenn Ihre Auswertung ohnehin in einem eigenen Reporting stattfindet.

Anforderungen aus Entscheidungen ableiten, nicht aus Wünschen

Ein wirksamer Test für jede Anforderung: Welche Entscheidung wird durch sie möglich, die heute nicht möglich ist? Wenn die Antwort lautet “keine, aber es wäre schön zu sehen”, gehört die Anforderung in die Kann-Liste oder gar nicht auf die Liste. Dashboards, die niemand zur Entscheidung heranzieht, sind der häufigste Grund, warum Lizenzen nach einem Jahr ungenutzt weiterlaufen.

Sortieren Sie die Muss-Liste danach, welcher Entscheidung sie dient:

Diese Tabelle ist der Kern Ihres Lastenhefts. Alles Weitere ist Ausführung.

Schritt 3: Datenquellen und ihre Grenzen prüfen

Software erzeugt keine Daten, sie verarbeitet welche. Bevor Sie über Werkzeuge entscheiden, sollten Sie wissen, welche Datenquellen Ihnen offenstehen, was sie leisten und wo sie enden. Diese Prüfung verhindert die teuerste Fehlannahme in Auswahlprozessen: dass ein Produkt eine Zahl liefern könne, die es strukturell nicht liefern kann.

Daten der Suchmaschinen selbst

Google Search Console stellt Berichte zu Suchleistung, Indexierung und technischen Problemen einer in Google dargestellten Website bereit. Das ist Ihre einzige Quelle für tatsächliche Klicks und Impressionen aus der Google-Suche für Ihre eigenen Seiten. Kein Drittsystem kann diese Zahlen ersetzen, es kann sie nur abrufen und aufbereiten.

Für die programmatische Weiterverarbeitung existiert die Search Console API, die den Zugriff auf Suchanalyse-, Sitemap- und Property-Daten ermöglicht. Für Ihre Auswahl heißt das: Ein Werkzeug, das Search-Console-Daten anzeigt, greift in der Regel auf dieselbe Schnittstelle zu, die Ihnen selbst offensteht. Der Mehrwert des Werkzeugs liegt also nicht im Zugang zu den Daten, sondern in Historisierung, Verknüpfung, Aggregation und Alarmierung. Genau danach sollten Sie im Pilot fragen.

Google Analytics 4 kann mit einer Search-Console-Property verknüpft werden, damit Search-Console-Berichte in Analytics verfügbar werden. Wenn Ihre Entscheidungsfrage lautet “Wo verlieren wir Nutzer nach dem Klick?”, ist diese Verknüpfung häufig der erste Schritt, und zwar bevor Sie zusätzliche Software kaufen.

Bing Webmaster Tools bietet unter anderem Leistungsberichte, URL-Prüfung, Sitemap-Verwaltung und Site-Scan-Funktionen. Für Unternehmen mit relevantem Anteil an Bing-Traffic oder mit Interesse an einer zweiten unabhängigen Sicht auf die Indexierung lohnt sich die Einrichtung, unabhängig davon, welche kommerzielle Lösung Sie später wählen.

Technische Messung

PageSpeed Insights analysiert eine URL auf Mobil- und Desktopgeräten und verbindet Felddaten mit Labordaten. Der Unterschied zwischen beiden ist für Ihre Anforderungen wesentlich: Labordaten sind reproduzierbar und eignen sich zum Vergleich von Änderungen. Felddaten beschreiben die tatsächliche Nutzererfahrung und reagieren träger. Ein Werkzeug, das nur eine der beiden Sichten zeigt, beantwortet nur die halbe Frage. Klären Sie im Pilot, welche der beiden Quellen ein Kennzahlenfeld speist.

Crawler erzeugen ihre Daten selbst, indem sie Ihre Website wie eine Suchmaschine abgehen. Der Screaming Frog SEO Spider ist ein Website-Crawler, der unter Windows, macOS und Linux eingesetzt werden kann. Diese Kategorie ist für die Stack-Frage wichtig, weil sie zwei Betriebsmodelle unterscheidet: Ein Crawler auf dem Arbeitsplatzrechner ist schnell, flexibel und liefert Momentaufnahmen. Ein Crawler als Dienst läuft ohne Anwesenheit, historisiert und kann alarmieren. Viele Unternehmen brauchen beides, aber für unterschiedliche Schritte im Workflow.

Daten von Drittanbietern

Suchvolumina, Sichtbarkeitsindizes, Wettbewerbsdaten und Verlinkungsdaten stammen aus eigenen Erhebungen der jeweiligen Anbieter. Sie sind Schätzungen und Stichproben, keine Messwerte Ihrer Website. Das ist kein Einwand gegen ihre Nutzung, aber eine Anforderung an Ihre Prozesse: Verwenden Sie solche Zahlen für Priorisierung und Richtungsentscheidungen, nicht als Erfolgsnachweis. Für den Erfolgsnachweis nehmen Sie die Daten aus Ihren eigenen Properties.

Prüfen Sie zu jeder Drittquelle drei Punkte, die im Pilot beantwortbar sind:

• Abdeckung. Enthält der Datenbestand Ihre Suchanfragen, Ihre Sprache, Ihre Region, Ihre Nische? Testen Sie mit zwanzig Suchanfragen, die Sie aus der Search Console als real belegt kennen.
• Aktualität. Wie alt sind die Daten im Zweifel, und steht das Datum an der Zahl?
• Stabilität. Ändert sich eine Kennzahl, weil sich Ihre Website geändert hat, oder weil der Anbieter seine Methodik geändert hat? Fragen Sie explizit nach der Änderungshistorie der Berechnung.

Grenzen, die Sie vorher kennen sollten

Notieren Sie zu jeder Quelle, welche Frage sie nicht beantworten kann. Diese Liste ist unbequem und spart später viel Diskussion. Typische Beispiele: Nicht jede Suchanfrage, über die Nutzer kommen, wird in einem Bericht ausgewiesen. Aggregierte Kennzahlen über viele URLs verdecken gegenläufige Entwicklungen einzelner Seiten. Ein Crawl bildet den Zustand zum Zeitpunkt des Crawls ab und nicht den Zustand, den eine Suchmaschine gespeichert hat. Und Daten über Wettbewerber sind immer Außenansicht, nie Einblick in deren Messwerte.

Schritt 4: Zugriff, Rechte und Betriebsfähigkeit klären

Dieser Schritt wird regelmäßig übersprungen und ist regelmäßig der Grund, warum eine Einführung stockt.

Die Search Console beschränkt den Zugriff auf eine Property über unterschiedliche Berechtigungsstufen für Inhaber und Nutzer. Daraus folgen mehrere Anforderungen an Ihre Organisation, unabhängig vom Werkzeug:

• Wer ist Inhaber der Property, und ist das eine Person oder eine Funktion? Wenn die Property an einem persönlichen Konto hängt und diese Person das Unternehmen verlässt, verlieren Sie im ungünstigen Fall die Historie. Klären Sie das vor der Softwareauswahl.
• Welche Stufe braucht das neue Werkzeug? Verlangen Sie die niedrigste Berechtigungsstufe, mit der die benötigten Daten gelesen werden können, und dokumentieren Sie, welcher Zugriff wofür erteilt wurde.
• Wie sieht das Offboarding aus? Halten Sie fest, welche Zugriffe beim Wechsel eines Werkzeugs oder eines Dienstleisters entzogen werden. Ein Auswahlprozess, der einen Wechsel nicht mitdenkt, produziert dauerhaft offene Zugänge.

Dasselbe gilt für Analytics-Konten, Zugänge zum Content-Management-System, zum Ticketsystem und zum Repository, wenn Ihr Team technische Änderungen selbst ausliefert. Erstellen Sie eine kleine Zugriffsmatrix: Zeile gleich System, Spalte gleich Rolle, Zelle gleich benötigte Stufe. Diese Matrix ist zugleich eine Anforderung an die Software, denn sie zeigt, ob Ihre Rollen im Werkzeug überhaupt abbildbar sind.

Schritt 5: Integration und Auswertung planen

Zwei Fragen entscheiden darüber, ob Sie eine Suite oder mehrere spezialisierte Bausteine brauchen.

Wo entsteht der Bericht, den Ihre Geschäftsführung liest? Wenn Sie Ihr Reporting ohnehin in einem eigenen Werkzeug bauen, sinkt der Wert eingebauter Dashboards und steigt der Wert offener Schnittstellen. Looker Studio etwa kann Daten aus verschiedenen Quellen über Connectoren in anpassbaren Berichten und Dashboards zusammenführen. Für viele Unternehmen ist das der pragmatische Weg: Datenquellen liefern Rohdaten, eine Berichtsebene führt sie zusammen, und die SEO-Software muss vor allem exportfähig sein.

Wo entsteht die Aufgabe, die jemand abarbeitet? Wenn Ihr Unternehmen bereits ein Ticketsystem betreibt, in dem Entwicklung und Redaktion arbeiten, ist eine zweite Aufgabenverwaltung in der SEO-Software meist ein Nachteil, kein Vorteil. Dann lautet die Anforderung: sauberer Weg vom Befund ins bestehende System, idealerweise mit Rückkanal für den Bearbeitungsstatus.

Aus diesen beiden Fragen ergibt sich die Architekturentscheidung, die Ihre Auswahl stärker prägt als jede Funktionsliste:

Datenhaltung als eigene Anforderung

Wenn Sie Entwicklungen über Jahre vergleichen wollen, brauchen Sie eine Stelle, an der Daten dauerhaft liegen, unabhängig von Vertragslaufzeiten und Aufbewahrungsfristen einzelner Anbieter. Das kann eine Datenbank sein, ein Data Warehouse oder auch nur ein regelmäßiger, versionierter Export. Formulieren Sie diese Anforderung explizit, sonst merken Sie erst beim Anbieterwechsel, dass Ihre Historie am Vertrag hing.

Schritt 6: Den kontrollierten Pilot aufsetzen

Ein Pilot ist kein verlängertes Ausprobieren. Er ist ein Test mit vorher festgelegten Fragen, Testfällen, Verantwortlichen und Abbruchkriterien. Ohne diese vier Elemente entsteht keine Entscheidungsgrundlage, sondern ein Bauchgefühl mit Screenshots.

Umfang und Dauer festlegen

Wählen Sie einen Ausschnitt, der repräsentativ und klein ist: eine Domain, ein Themenbereich, eine überschaubare Menge URLs, eine Menge Suchanfragen, die Sie aus eigenen Daten kennen. Als Dauer bewähren sich vier bis sechs Wochen. Kürzer reicht selten, um wiederkehrende Betriebsroutinen zu erleben. Länger führt dazu, dass der Pilot zum Dauerzustand wird und niemand mehr eine Entscheidung trifft.

Vergleichen Sie höchstens zwei bis drei Kandidaten parallel. Mehr lässt sich in derselben Zeit nicht mit derselben Sorgfalt prüfen, und ungleich geprüfte Kandidaten sind nicht vergleichbar.

Testfälle statt Funktionsdemos

Ein Testfall beschreibt eine echte Aufgabe aus Ihrem Workflow-Modell und ihr erwartetes Ergebnis. Beispiele:

• Bestandsaufnahme: “Erzeuge eine Liste aller indexierbaren URLs des Themenbereichs mit Statuscode, Titel, Vorhandensein der Meta-Description und interner Verlinkungstiefe. Erwartet: Ergebnis liegt in unter zwei Stunden vor und ist als CSV exportierbar.”
• Nachfragebild: “Zeige für zehn definierte Suchanfragen die Klick- und Impressionsentwicklung der letzten 90 Tage gegenüber dem Vorjahreszeitraum. Erwartet: Zahlen stimmen mit dem direkten Export aus der Search Console überein.”
• Wirkungsnachweis: “Wir ändern am Tag X den Titel von fünf URLs. Zeige 28 Tage später die Veränderung von Klicks, Impressionen und durchschnittlicher Position dieser fünf URLs gegenüber einer Vergleichsgruppe. Erwartet: Das Werkzeug kennt das Änderungsdatum oder erlaubt es, den Zeitpunkt zu hinterlegen.”
• Technische Regression: “Wir setzen auf einer Testseite bewusst einen defekten internen Link und eine nicht erreichbare Bilddatei. Erwartet: Beide Befunde erscheinen im nächsten Lauf, sind eindeutig lokalisierbar und verschwinden nach der Korrektur.”
• Übergabe: “Aus einem Befund entsteht eine Aufgabe in unserem Ticketsystem mit Verantwortlichem und Fälligkeit. Erwartet: ohne manuelles Abtippen.”
• Rechte: “Eine Person mit Lesezugriff sieht die Berichte, kann aber keine Property-Einstellungen ändern. Erwartet: Das Rollenmodell bildet unsere Zugriffsmatrix ab.”

Wichtig ist der Abgleich mit einer unabhängigen Referenz. Wo ein Werkzeug Daten aus der Search Console aufbereitet, ziehen Sie denselben Zeitraum direkt aus der Search Console und vergleichen. Abweichungen sind nicht automatisch ein Mangel, aber sie müssen erklärbar sein. Ein Anbieter, der eine Abweichung nicht erklären kann, liefert Ihnen eine Zahl, die Sie nicht verantworten können.

Wer testet, und was wird protokolliert

Jeder Testfall bekommt eine verantwortliche Person aus der Rolle, die später damit arbeitet. Die Person protokolliert vier Dinge: Ergebnis erreicht ja oder nein, benötigte Zeit, Anzahl der Rückfragen an den Support und eine Notiz zu Hindernissen. Diese Protokolle sind Ihre Datengrundlage in Schritt 7. Ohne Zeitmessung fehlt Ihnen später das stärkste Argument, weil eingesparte Arbeitszeit die einzige Größe ist, die sich unmittelbar gegen Lizenzkosten rechnen lässt.

Abbruchkriterien vorher definieren

Legen Sie fest, wann ein Kandidat den Pilot verlässt, bevor die Zeit um ist. Übliche Abbruchkriterien: Ein Muss-Kriterium ist nachweislich nicht erfüllt. Daten weichen ohne Erklärung von der Referenz ab. Der Zugang zu benötigten Daten scheitert an Rechten oder Limits. Oder eine Supportanfrage bleibt über eine vorher vereinbarte Frist unbeantwortet. Ein sauber abgebrochener Pilot ist ein gutes Ergebnis, kein verlorener Aufwand.

Schritt 7: Aus dem Pilot messbare Kriterien machen

Jetzt wird bewertet, und zwar in dieser Reihenfolge: erst Ausschluss, dann Muss, dann Gewichtung.

Ausschlusskriterien werden binär geprüft. Ein Kandidat, der hier scheitert, wird nicht weiter bewertet, egal wie gut er sonst abschneidet. Das klingt hart und schützt vor der häufigsten Fehlentscheidung: Ein System gewinnt auf Punkten und ist im Betrieb trotzdem nicht einsetzbar.

Muss-Kriterien werden ebenfalls binär geprüft, und zwar am Testfall, nicht an der Zusage. “Wird im nächsten Release kommen” gilt als nicht erfüllt.

Kann-Kriterien werden gewichtet. Vergeben Sie pro Kriterium ein Gewicht und eine Bewertung von 0 bis 3, wobei 0 heißt “nicht vorhanden”, 1 “vorhanden, im Test umständlich”, 2 “erfüllt die Aufgabe”, 3 “erfüllt die Aufgabe und ersetzt zusätzliche Handarbeit”. Verzichten Sie auf feinere Skalen. Sie erzeugen Scheingenauigkeit, ohne die Entscheidung zu verbessern.

Ergänzen Sie drei Kriterien, die sich aus dem Pilotprotokoll direkt ergeben und in Verkaufsunterlagen nicht vorkommen:

• Zeit bis zum ersten brauchbaren Ergebnis. Wie lange dauerte es vom Zugang bis zum ersten Testfall, der bestanden war?
• Aufwand pro Routinelauf. Wie viele Minuten kostet die wöchentliche Routine nach der Einrichtung?
• Erklärbarkeit. Konnte die testende Person nachvollziehen und in einem Satz erklären, wie eine zentrale Kennzahl zustande kommt?

Kosten vollständig rechnen

Vergleichen Sie nicht Listenpreise, sondern Gesamtkosten über einen definierten Zeitraum, üblicherweise 24 oder 36 Monate. In die Rechnung gehören: Lizenz- oder Nutzungskosten für die geplante Nutzerzahl und das geplante Mengengerüst, Einrichtungsaufwand in Personentagen, Schulungsaufwand, laufender Betriebsaufwand, Kosten für ergänzende Bausteine, die das System nicht abdeckt, und der geschätzte Aufwand eines Wechsels am Ende des Zeitraums.

Stellen Sie dieser Summe die im Pilot gemessene eingesparte Arbeitszeit gegenüber. Wenn eine Übergabe, die heute monatlich vier Stunden kostet, künftig zwanzig Minuten kostet, ist das eine belegte Zahl aus Ihrem eigenen Haus und kein Versprechen aus einem Prospekt.

Die Entscheidung dokumentieren

Halten Sie auf einer Seite fest: gewählte Lösung, ausgeschlossene Kandidaten mit dem jeweils entscheidenden Kriterium, die drei größten bekannten Schwächen der gewählten Lösung und die Annahmen, unter denen die Entscheidung gilt. Der letzte Punkt ist der wertvollste, denn er sagt Ihnen in einem Jahr, ob die Entscheidung noch trägt.

Schritt 8: Vom Bewertungsergebnis zum Stack

Selten gewinnt ein einzelnes Produkt alle Kriterien. Häufiger entsteht ein Stack aus drei Ebenen, und die Auswahl besteht darin, jeder Ebene genau einen Baustein zuzuordnen.

Ebene 1: Messquellen. Die Systeme, die belastbare Daten über Ihre eigene Website liefern. Hier gehören die Properties der Suchmaschinen hin, die Webanalyse und die technische Messung. Diese Ebene ist weitgehend gesetzt und sollte vollständig eingerichtet sein, bevor Sie kommerzielle Software kaufen.

Ebene 2: Erhebung und Prüfung. Crawler, Monitoring von Statuscodes und Indexierung, Erhebung von Nachfrage- und Wettbewerbsdaten. Hier fällt die Entscheidung zwischen Arbeitsplatzwerkzeug, gehostetem Dienst oder beidem, und hier liegt meist der größte Teil der Lizenzkosten.

Ebene 3: Zusammenführung und Steuerung. Berichte, Alarmierung, Aufgaben. Diese Ebene wird entweder von einer Suite übernommen oder von den Systemen, die Ihr Unternehmen ohnehin betreibt.

Eine praktikable Regel für den Zuschnitt: Kaufen Sie auf Ebene 2, integrieren Sie auf Ebene 3, und bauen Sie nur dort selbst, wo eine Anforderung aus Ihrem Workflow-Modell von keinem Baustein erfüllt wird und die betroffene Übergabe messbar teuer ist.

Wann Eigenbau sinnvoll ist

Eigenbau lohnt sich in einer engen Nische: wiederkehrende, exakt definierte Auswertungen auf Daten, die Ihnen über Schnittstellen ohnehin offenstehen, mit einer Logik, die für Ihr Geschäft spezifisch ist. Ein wöchentlicher Abgleich von Search-Console-Daten mit Ihrer Produktdatenbank ist ein solcher Fall. Die Nachbildung eines Crawlers ist es nicht.

Kalkulieren Sie Eigenbau immer mit Betrieb, nicht nur mit Erstellung. Ein Skript, das niemand pflegt, ist nach dem ersten Schnittstellenwechsel eine stille Fehlerquelle in Ihrem Reporting.

Schritt 9: Einführung im Team

Die Einführung entscheidet, ob aus der Auswahl Nutzen wird. Drei Dinge tragen sie.

Eine Routine statt einer Schulung. Definieren Sie die wiederkehrende Arbeit, die das System künftig trägt: Welche Auswertung wird wann von wem angesehen, welche Entscheidung wird daraus abgeleitet, und wo wird sie festgehalten. Eine einstündige Routine, die jede Woche stattfindet, bringt mehr als ein ganztägiger Schulungstermin ohne Anschluss.

Ein definierter Datenstand. Legen Sie fest, welche Zahl aus welchem System die maßgebliche ist, besonders dort, wo zwei Systeme dieselbe Kennzahl unterschiedlich berechnen. Ohne diese Festlegung diskutieren Teams über Zahlen statt über Maßnahmen.

Eine benannte Verantwortung. Eine Person pflegt Konfiguration, Zugriffe und Schwellenwerte. Ohne diese Rolle veralten Alarme, laufen Zugänge weiter und niemand bemerkt, dass ein Crawl seit sechs Wochen abbricht.

Schritt 10: Nachkontrolle und Wiedervorlage

Setzen Sie zwei Termine, sobald die Entscheidung steht.

Nach etwa drei Monaten prüfen Sie die Nutzung: Welche Funktionen werden tatsächlich verwendet, welche Muss-Kriterien haben sich im Alltag als erfüllt erwiesen, welche Übergabe ist noch manuell, und stimmen die im Pilot gemessenen Zeiten? Diese Prüfung deckt zuverlässig auf, ob Sie eine Ebene zu viel gekauft haben.

Nach etwa zwölf Monaten prüfen Sie die Annahmen aus Ihrer Entscheidungsdokumentation: Ist das Mengengerüst gleich geblieben, sind die Rollen dieselben, hat sich die Berechnung zentraler Kennzahlen geändert, und gibt es Anforderungen aus dem Workflow, die inzwischen entstanden sind? Das Ergebnis ist entweder eine Bestätigung oder ein klar begrenzter neuer Auswahlschritt, nicht ein kompletter Neustart.

Typische Fehler in Auswahl und Einführung

Der Workflow wird nachträglich an die Software angepasst. Wenn ein System eine Arbeitsweise erzwingt, die zu Ihrer Organisation nicht passt, gewinnt langfristig die Organisation, und das System wird umgangen.

Es wird für die Ausnahme gekauft. Eine Funktion, die zweimal im Jahr gebraucht wird, rechtfertigt selten eine Lizenzstufe. Prüfen Sie, ob die Ausnahme mit Handarbeit oder einem einmaligen Dienstleistungsauftrag billiger ist.

Erfolgsnachweis auf Fremddaten. Sichtbarkeitsindizes und geschätzte Suchvolumina eignen sich zur Priorisierung. Für die Frage, ob Ihre Arbeit gewirkt hat, zählen Klicks, Impressionen und Verhalten aus Ihren eigenen Properties.

Kein Änderungsdatum. Wer nicht festhält, wann was geändert wurde, kann Wirkung nicht messen, egal welche Software im Einsatz ist. Diese Anforderung ist trivial und wird ständig übersehen.

Rechte an Personen statt an Funktionen. Properties und Konten, die an persönlichen Zugängen hängen, gefährden Historie und Betrieb.

Zu viele parallele Kandidaten. Drei Piloten gleichzeitig führen dazu, dass keiner ordentlich geprüft wird. Lieber zwei sauber und, falls nötig, eine zweite Runde.

Häufige Fragen

Wie lange dauert ein solcher Auswahlprozess insgesamt? Realistisch sind sechs bis zehn Wochen: ein bis zwei Wochen für Workflow-Modell und Anforderungen, eine Woche für Datenquellen- und Rechteprüfung, vier bis sechs Wochen Pilot, eine Woche Auswertung und Entscheidung. Der Aufwand liegt meist zwischen fünf und zwölf Personentagen, verteilt über diesen Zeitraum.

Brauchen wir überhaupt kommerzielle Software? Das entscheidet Ihr Mengengerüst und Ihr Workflow-Modell. Ein kleiner Bestand, ein Team von zwei Personen und wenige Änderungen pro Monat lassen sich häufig mit den Daten der Suchmaschinen, einem Crawler und einer Berichtsebene abdecken. Sobald Historisierung, Alarmierung und Übergaben zwischen mehreren Rollen dazukommen, verschiebt sich die Rechnung zugunsten kommerzieller Bausteine.

Was, wenn zwei Kandidaten am Ende gleich bewertet sind? Dann entscheiden Sie über die drei Kriterien aus dem Pilotprotokoll: Zeit bis zum ersten Ergebnis, Aufwand pro Routinelauf und Erklärbarkeit der Kennzahlen. Bleibt es gleich, entscheiden Sie über die Wechselkosten und wählen die Lösung, die Sie leichter wieder verlassen können.

Wie gehen wir mit abweichenden Zahlen zwischen zwei Systemen um? Legen Sie eine maßgebliche Quelle pro Kennzahl fest und dokumentieren Sie die erwartete Abweichung der anderen. Abweichungen entstehen regelmäßig durch unterschiedliche Zeitzonen, unterschiedliche Aggregation über Geräte oder Länder und unterschiedliche Definitionen einer Sitzung. Nicht erklärbare Abweichungen sind ein Ausschlussgrund.

Sollen wir eine Suite oder mehrere Spezialwerkzeuge nehmen? Das folgt aus Schritt 5. Ohne eigenes Reporting und ohne etabliertes Ticketsystem reduziert eine Suite die Bruchstellen. Mit beidem im Haus sind spezialisierte Bausteine mit sauberen Schnittstellen meist die günstigere und langlebigere Wahl.

Was ist der wichtigste einzelne Schritt, wenn wir nur wenig Zeit haben? Das Workflow-Modell mit der Markierung der manuellen Übergaben. Aus ihm entstehen Anforderungen, Testfälle und die Wirtschaftlichkeitsrechnung. Alles andere lässt sich verkürzen, dieser Schritt nicht.