SEO Analyse Tools: Vom Werkzeugkasten zum belastbaren Analyse-Workflow

SEO Analyse Tools liefern Crawling-Daten, Ladezeiten, Indexierungsstatus, Textmerkmale und Verlinkungsmuster. Was sie nicht liefern, ist die Analyse selbst. Die entsteht erst, wenn eine konkrete Frage gestellt wird, mehrere Datenquellen dieselbe Sache aus verschiedenen Blickwinkeln beschreiben und die Abweichungen zwischen ihnen erklärt werden. Ein Export ist ein Rohstoff, kein Ergebnis.

Der Grund dafür ist strukturell: Kein Werkzeug sieht die vollständige Website. Ein Crawler folgt Links so, wie es sein eigener Renderer erlaubt, und nicht so, wie Google es tut. Ein Labortest misst unter festen Bedingungen, die kein echtes Endgerät exakt reproduziert. Eine Backlink-Datenbank kennt nur den Teil des Webs, den ihr eigener Crawler erfasst hat. Jede Quelle hat also einen blinden Fleck, und die Kunst besteht darin, die blinden Flecken gegeneinander zu legen, statt einer Quelle blind zu vertrauen.

Fünf Analysephasen und die passenden Werkzeugtypen

Ein tragfähiger Workflow ordnet Werkzeuge nicht nach Anbieter, sondern nach der Frage, die sie beantworten sollen.

Die Phasen überschneiden sich, und das ist erwünscht. Ein Crawl kann eine Seite als sauber indexierbar ausweisen, während die Google Search Console zeigt, dass Google sie nicht im Index führt. Dieser Widerspruch ist kein Datenfehler, sondern der eigentliche Startpunkt der Untersuchung.

Schritt 1: Frage, Umfang und Segmente festlegen

Vor der Werkzeugauswahl steht die Entscheidung, die die Analyse stützen soll. Ein Audit ohne Fragestellung produziert eine Mängelliste, aber keine Reihenfolge. Typische Anlässe sind Indexierungsprobleme, ein Relaunch mit Sichtbarkeitsverlust, ein Seitentyp mit auffällig schlechter Leistung, thematische Überschneidungen zwischen eigenen Seiten oder die Planung der nächsten Entwicklungszyklen.

Der Umfang gehört zur Frage dazu. Eine vollständige Domainanalyse stellt andere Anforderungen als die Prüfung eines Verzeichnisses oder einer Stichprobe. Bei großen Websites ist die Kombination meist am wirtschaftlichsten: ein breiter Crawl für strukturelle Muster, danach eine vertiefte Prüfung weniger, gezielt ausgewählter URLs.

Der wichtigste Vorbereitungsschritt wird am häufigsten übersprungen: die Segmentierung. Bevor Daten erhoben werden, sollten die Seitengruppen benannt sein, etwa Kategorien, Produktdetailseiten, Ratgeberinhalte, Standortseiten, Filterergebnisse und Archive. Erst diese Zuordnung macht Befunde vergleichbar. Derselbe fehlende Canonical wiegt auf zwanzig umsatztragenden Kategorien anders als auf zweihundert Archivseiten, die ohnehin niemand aufruft.

Schritt 2: Technik mit mehreren Datenquellen absichern

Ein Website-Crawler bildet nach, wie ein Bot Links verfolgt und Dokumente abruft. Der Screaming Frog SEO Spider etwa crawlt Websites und erfasst dabei technische Elemente wie Statuscodes, Weiterleitungen, Seitentitel, Meta Descriptions, Überschriften und Canonicals. Damit lassen sich Muster über viele URLs hinweg sichtbar machen, die an einer Einzelseite unauffällig wären.

Ein Crawl sollte mindestens diese Fragen beantworten:

• Sind wichtige Seiten überhaupt über interne Links erreichbar?
• Welche URLs liefern Fehlercodes oder vermeidbare Weiterleitungen?
• Existieren Weiterleitungsketten oder Schleifen?
• Zeigen Canonicals auf erreichbare und indexierbare Ziele?
• Trägt eine relevante Seite versehentlich ein noindex?
• Erzeugen Parameter, Filter oder uneinheitliche Verlinkung URL-Varianten?
• Welche Seiten liegen unnötig tief in der Klickstruktur?
• Gibt es verwaiste Seiten, die nur in anderen Quellen auftauchen?

Was der Crawl nicht zeigt, ist Googles Verarbeitung. Dafür kommt die Google Search Console hinzu: Sie zeigt unter anderem, wie Google eine Website crawlt, indexiert und in den Suchergebnissen ausspielt, ersetzt aber keinen vollständigen technischen Website-Crawl. Beide Quellen sind also unvollständig, und zwar auf unterschiedliche Weise.

Der produktivste technische Schritt ist deshalb ein Mengenabgleich. Verglichen werden die im Crawl gefundenen URLs, die URLs der XML-Sitemap, die laut Search Console indexierten oder ausgeschlossenen URLs, die URLs mit organischen Impressionen und das Inventar aus dem CMS oder Shopsystem. Jede Differenzmenge ist eine eigene Hypothese. URLs mit Impressionen, die im Crawl fehlen, deuten auf verwaiste Seiten hin. URLs in der Sitemap ohne Indexierung deuten auf Qualitäts-, Duplikats- oder Crawlbudget-Themen hin.

Dabei helfen zwei Präzisierungen. Eine XML-Sitemap unterstützt Suchmaschinen beim Entdecken wichtiger URLs, garantiert aber weder deren Crawling noch deren Indexierung. Eine nicht indexierte Sitemap-URL ist also ein Hinweis, keine Diagnose. Und die robots.txt steuert den Zugriff von Crawlern auf URLs, ist aber kein zuverlässiges Mittel, um eine URL aus dem Google-Index zu entfernen. Wer eine Seite aus dem Index nehmen will und sie zugleich per robots.txt sperrt, verhindert lediglich, dass Google die entsprechende Anweisung überhaupt liest. Crawling-Sperren, Meta-Robots-Angaben, Canonicals, Statuscodes und interne Verlinkung gehören daher immer gemeinsam auf den Tisch.

Schritt 3: Onpage-Signale redaktionell bewerten

Onpage-Reports finden formale Auffälligkeiten zuverlässig und schnell: fehlende oder mehrfach verwendete Titel, leere Hauptüberschriften, sehr kurze Inhalte, identische Meta Descriptions, widersprüchliche Canonicals. Genau hier endet aber die maschinelle Zuständigkeit.

Google empfiehlt beschreibende und prägnante Seitentitel. Automatisierte Analysewerkzeuge können formale Auffälligkeiten erkennen, aber nicht zuverlässig die Suchintention oder die Qualität eines Titels beurteilen. Ein doppelter Titel kann auf paginierten Listen, rechtlichen Dokumenten oder bewusst standardisierten Bereichen völlig unproblematisch sein. Umgekehrt kann ein technisch einwandfreier, einzigartiger Titel die Erwartung der suchenden Person vollständig verfehlen, ohne dass ein Werkzeug das je meldet.

Für die manuelle Gegenprobe genügt eine Stichprobe pro Seitentyp. Bewertet wird:

• Passt der Inhalt zu der Aufgabe, mit der jemand hier ankommt?
• Beantwortet die Seite die zentrale Frage früh und eindeutig?
• Sind Titel, Hauptüberschrift und Inhalt konsistent?
• Hat die Seite einen eigenständigen Zweck oder dupliziert sie eine andere?
• Unterstützt die interne Verlinkung den thematischen Zusammenhang?
• Sind zentrale Aussagen aktuell und nachvollziehbar belegt?

Automatisch gemeldete Wortzahlen und Keyword-Häufigkeiten taugen dabei nicht als Zielgröße. Mehr Text ist nicht hilfreicher, sondern nur länger.

Schritt 4: Performance aus Labor und Feld zusammen lesen

Performance braucht zwei Perspektiven, weil sie zwei verschiedene Fragen beantwortet. Labordaten entstehen unter kontrollierten Bedingungen und eignen sich zur reproduzierbaren Ursachensuche. Felddaten zeigen, wie die Seite bei echten Nutzerinnen und Nutzern auf echten Geräten und Verbindungen funktioniert.

PageSpeed Insights kombiniert Labordaten aus Lighthouse mit realen Nutzungsdaten aus dem Chrome User Experience Report, sofern für die untersuchte URL oder den Ursprung genügend Felddaten vorliegen. Fehlen die Felddaten, ist das keine Entwarnung, sondern nur eine fehlende Datengrundlage. Bei Seiten mit wenig Traffic ist der Rückgriff auf Ursprungsdaten oder eigene Messungen im laufenden Betrieb der ehrlichere Weg.

Zu den Core Web Vitals gehören Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift. Sie beschreiben, wann der Hauptinhalt sichtbar wird, wie reaktionsschnell die Seite auf Eingaben antwortet und wie stabil das Layout währenddessen bleibt. Ergänzend führt Lighthouse automatisierte Prüfungen unter anderem für Performance, Barrierefreiheit, Best Practices und SEO durch. Diese Prüfungen sind Diagnosewerkzeug und nicht Zielvorgabe: Ein einzelner Laborwert schwankt zwischen Testläufen und eignet sich schlecht als Kennzahl in einem Reporting.

Ausgewertet wird nach Templates, nicht nach Einzel-URLs. Wenn zweihundert Produktseiten dieselbe unkomprimierte Bildkomponente einbinden, ist die Ursache eine Komponente und die Lösung ein Ticket, nicht zweihundert.

Schritt 5: Offpage-Daten als Stichprobe lesen

Backlink-Datenbanken erfassen externe Verweise über eigene Crawler. Keine kennt jeden Link im Web, weshalb abweichende Zahlen zwischen zwei Anbietern normal sind und keine Fehlfunktion belegen. Wer Offpage-Daten wie ein Kontoauszug liest, zieht falsche Schlüsse.

Aussagekräftig sind Muster:

• Welche Inhalte ziehen überhaupt externe Verweise an?
• Stammen die Links aus thematisch nachvollziehbaren Quellen?
• Zeigen viele Verweise auf inzwischen nicht mehr erreichbare URLs?
• Gingen bei einer Migration Linkziele verloren?
• Konzentriert sich die externe Sichtbarkeit auf sehr wenige Seiten?

Proprietäre Autoritätswerte sind Hilfsmetriken der jeweiligen Anbieter und keine von Google bestätigten Rankingsignale. Ein niedriger Wert rechtfertigt weder Linkkäufe noch das Entfernen legitimer Verweise. Der praktisch wertvollste Offpage-Befund ist meist unspektakulär: verlorene Linkziele, die sich per Weiterleitung zurückholen lassen.

Warum ein automatischer Score keine Priorisierung ist

Ein Gesamtscore verdichtet viele Einzelprüfungen zu einer Zahl und verliert dabei genau die Information, die für Entscheidungen nötig wäre. Zehn fehlende Meta Descriptions können den Wert stärker drücken als ein Indexierungsfehler auf der wichtigsten Kategorie, obwohl der zweite Fall Umsatz kostet und der erste kaum.

Automatische Bewertungen stoßen an drei Grenzen: Sie kennen die Geschäftsrelevanz einzelner Seiten nicht, sie erkennen Symptome zuverlässiger als Ursachen, und sie prüfen Regeln, während Suchintention und redaktionelle Qualität eine Einschätzung erfordern. Als Verlaufsbeobachtung eines konstanten Prüfsets sind Scores brauchbar. Als Arbeitsauftrag sind sie es nicht.

Befunde validieren, bevor sie zu Aufgaben werden

Jeder relevante Befund durchläuft vor der Umsetzung denselben kurzen Ablauf:

1. Signal erfassen: Was genau meldet das Werkzeug, in welcher Formulierung?
2. Stichprobe prüfen: Tritt das Problem auf den gemeldeten URLs tatsächlich auf?
3. Quellen abgleichen: Bestätigen Crawl, Search Console oder Seitentest dasselbe Muster?
4. Ursache eingrenzen: Template, CMS, Server, Inhalt oder interne Verlinkung?
5. Wirkung bewerten: Welche Segmente und welche Geschäftsziele sind betroffen?
6. Lösung gegenprüfen: Behebt die Änderung die Ursache, ohne neue Fehler zu erzeugen?

Dieser Ablauf ist der Unterschied zwischen einem Audit und einem exportierten Tabellenblatt.

Aus der Analyse einen Maßnahmenplan machen

Eine Aufgabe, die nur aus einem Fehlernamen besteht, wird nicht umgesetzt. Belastbar wird sie mit Problembeschreibung, betroffener URL-Gruppe oder Template, Beleg aus mindestens einer Datenquelle, vermuteter Ursache, erwarteter Wirkung, empfohlener Lösung, zuständigem Team, geschätztem Aufwand samt Abhängigkeiten und einem Prüfkriterium für die Zeit nach dem Deployment.

Priorisiert wird nach vier Größen: Wirkung, Reichweite über die Segmente, Sicherheit des Befunds und Aufwand. Nach oben rutscht, was viele wichtige Seiten betrifft, Crawling oder Indexierung blockiert und mit vertretbarem Aufwand lösbar ist. Nach unten rutscht Kosmetik auf unbedeutenden URLs, egal wie rot sie im Report leuchtet.

Abgeschlossen ist eine Maßnahme erst nach der Nachmessung: erneuter Crawl oder gezielte Stichprobe, Kontrolle in der Search Console, ob Google die Änderung verarbeitet hat, und ein Blick auf mögliche Nebenwirkungen.

Fazit

SEO Analyse Tools werden dort wertvoll, wo jeder Quelle eine klar umrissene Aufgabe zugewiesen ist: der Crawler beschreibt die Struktur, die Search Console ergänzt Googles Sicht darauf, Labor- und Felddaten zusammen beschreiben die tatsächliche Performance, Backlink-Daten liefern eine Stichprobe der externen Signale. Keine dieser Quellen ist für sich genommen die Wahrheit, und keine Zahl ersetzt die Entscheidung, was zuerst repariert wird. Das Ergebnis eines guten Analyse-Workflows ist deshalb kein besserer Tool-Score, sondern eine kurze, begründete und überprüfbare Liste von Maßnahmen, die Redaktion, Entwicklung und SEO gemeinsam abarbeiten können.