Tool SEO Analysis: SEO-Probleme systematisch diagnostizieren

Die schlechteste Art, eine SEO-Analyse zu beginnen, ist die Frage „Welches Tool prüft meine Website?". Sie führt zu einer Liste von Auffälligkeiten, aber nicht zu einer Entscheidung. Die bessere Reihenfolge lautet: erst die Untersuchungsfrage, dann die Datenquelle, dann die Validierung, dann die Priorisierung.

Ein Werkzeug ist in dieser Kette ein Messinstrument, kein Gutachter. Es beantwortet exakt die Frage, für die es gebaut wurde, und zwar unter seinen eigenen Bedingungen. Wer diese Bedingungen nicht kennt, hält Eigenschaften des Prüfverfahrens für Eigenschaften der Website.

Dieser Text beschreibt einen wiederholbaren Diagnoseablauf: wie aus einem Symptom eine prüfbare Frage wird, welche Primärdatenquelle sie beantwortet, wie sich eine Tool-Ausgabe gegenprüfen lässt und wie aus dem Befund eine begründete Maßnahme entsteht.

Warum eine Tool-Meldung noch kein Befund ist

SEO-Werkzeuge liefern Beobachtungen: eine nicht indexierte URL, einen fehlenden Canonical-Verweis, eine langsame Ladezeit, gesunkene organische Klicks, interne Links auf Weiterleitungen, doppelte Seitentitel, blockierte Ressourcen.

Jede dieser Meldungen ist wahr und trotzdem noch keine Diagnose. Ein fehlender Canonical-Verweis ist bei einer eindeutigen URL-Struktur oft folgenlos. Eine schlechte Labormessung sagt nichts darüber, was reale Nutzer erleben. Ein Klickverlust kann aus schlechteren Positionen entstehen, aus gesunkener Nachfrage oder aus einer veränderten Darstellung der Suchergebnisseite.

Eine belastbare Analyse trennt deshalb vier Ebenen sauber voneinander:

1. Symptom: Was wurde beobachtet, auf welcher URL, in welchem Zeitraum?
2. Diagnosefrage: Welche konkrete Unsicherheit soll geklärt werden?
3. Primärdatenquelle: Welche Quelle beantwortet genau diese Frage am direktesten?
4. Maßnahme: Welche Änderung ist durch den Befund ausreichend gedeckt?

Wer die Ebenen vermischt, produziert lange Fehlerlisten mit unklarem Nutzen. Wer sie trennt, kann am Ende in einem Satz begründen, warum etwas geändert wird.

Schritt 1: Das Problem als Untersuchungsfrage formulieren

„Der Traffic ist eingebrochen" und „Die Seite rankt nicht" sind keine Fragen, sondern Sammelbegriffe. Sie enthalten mehrere mögliche Probleme, die jeweils andere Daten verlangen.

Aus „Die Seite rankt nicht" lassen sich unter anderem diese Fragen ableiten:

• Kennt Google die URL überhaupt?
• Ist sie indexiert, und entspricht die indexierte Version dem aktuellen Stand?
• Darf Google sie crawlen und indexieren?
• Wählt Google eine andere URL als kanonische Version?
• Erzielt die URL Impressionen, aber nur auf niedrigen Positionen?
• Rankt sie für andere Suchanfragen als beabsichtigt?
• Ist die Nachfrage nach dem Thema gesunken?
• Verliert sie Klicks bei stabiler Sichtbarkeit?

Eine brauchbare Diagnosefrage ist so eng, dass Daten sie beantworten können. Sie benennt möglichst eine URL oder ein klar abgegrenztes Segment, einen Zeitraum und eine Kennzahl.

Brauchbar:

Ist die überarbeitete Produktseite seit dem Relaunch indexiert, und wird sie für die vorgesehenen Suchanfragen weiterhin ausgespielt?

Nicht brauchbar:

Ist die Produktseite SEO-optimiert?

Auf die zweite Frage antwortet jeder automatische Check mit Dutzenden Hinweisen, von denen keiner das eigentliche Problem berührt. Das ist der häufigste Grund, warum Analysen viel Material und wenig Entscheidung erzeugen.

Schritt 2: Die passende Primärdatenquelle zuordnen

Entscheidend für die Wahl der Quelle ist, wo das zu untersuchende Ereignis stattfindet: in der Google-Suche, auf dem Server, im Browser realer Nutzer oder innerhalb der Website.

Google bezeichnet die Search Console als maßgebliche Datenquelle für die Leistung in der Google-Suche, während Google Analytics das Verhalten der Besucher innerhalb einer Website abbildet. Diese Arbeitsteilung ist keine Formalie, sondern die Grundregel der Zuordnung: Alles, was vor dem Klick passiert, gehört in die Search Console. Alles, was danach passiert, gehört in die Webanalyse.

Daraus folgt ein praktischer Hinweis für den Umgang mit scheinbaren Widersprüchen. Search Console und Google Analytics verwenden unterschiedliche Mess- und Zuordnungslogiken, weshalb Klicks und Sitzungen nicht exakt übereinstimmen müssen. Eine Abweichung ist deshalb erst dann ein Trackingfehler, wenn sie sich nicht durch die bekannten Unterschiede der beiden Systeme erklären lässt. Wer diese Differenz zum Projekt macht, verliert Wochen an einer Frage, die nie ein Rankingproblem war.

Schritt 3: Indexierung auf URL-Ebene klären

Bei einer einzelnen URL beginnt die Diagnose nicht mit einer site:-Abfrage. Der Suchoperator unterliegt Einschränkungen bei Indexierung und Abruf; für die Diagnose einzelner URLs ist das URL-Prüftool der Search Console zuverlässiger. Ein leeres site:-Ergebnis ist ein Hinweis, kein Nachweis.

Die URL-Prüfung sollte folgende Punkte klären:

1. Ist die URL bei Google bekannt?
2. Ist sie indexiert?
3. Welche URL betrachtet Google als kanonisch?
4. Welche Canonical-URL gibt die Website selbst an?
5. War der letzte Abruf erfolgreich?
6. Schränken Regeln oder Seitensignale die Indexierung ein?

Die URL-Prüfung liefert Informationen über die bei Google indexierte Version einer URL; die zugehörige API ermöglicht den programmatischen Zugriff auf diese URL-bezogenen Daten. Das ist der Weg, um einen abgegrenzten Bestand wichtiger URLs regelmäßig zu prüfen, statt einzelne Seiten manuell abzufragen.

Der Statuswert allein genügt allerdings nicht. Er muss gegen den aktuellen technischen Zustand gehalten werden, denn die indexierte Version kann älter sein als die ausgelieferte:

• Welchen HTTP-Status liefert die URL jetzt?
• Existiert ein noindex im HTML oder im HTTP-Header?
• Schränkt robots.txt den Abruf ein?
• Ist der Canonical-Verweis korrekt, absolut und erreichbar?
• Verweisen interne Links auf die untersuchte URL?
• Steht die URL in der XML-Sitemap?
• Unterscheidet sich der gerenderte Inhalt vom ausgelieferten HTML?
• Existieren nahezu identische Alternativ-URLs?

Erst dieser Abgleich zeigt, ob eine Tool-Meldung noch gilt und welche Ursache plausibel ist.

Schritt 4: Sichtbarkeitsverluste in Teilfragen zerlegen

Wenn Klicks sinken, ist die erste Aufgabe nicht die Ursachensuche, sondern die Feststellung, welche Kennzahl sich bewegt hat.

Ein sauberer Ablauf:

1. Zeitraum und Vergleichszeitraum festlegen, inklusive Vorjahresvergleich.
2. Betroffene URLs oder Verzeichnisse eingrenzen.
3. Impressionen, Klicks, Klickrate und Position getrennt betrachten.
4. Nach Suchanfrage, Gerät und Land segmentieren.
5. Markenbezogene von nicht markenbezogenen Anfragen trennen.
6. Einzelne Ausreißer von einem systematischen Muster unterscheiden.

Die entstehenden Muster führen zu unterschiedlichen Folgefragen:

Impressionen sinken, Positionen bleiben stabil. Das deutet auf veränderte Nachfrage oder Saisonalität hin, nicht auf ein Problem der Seite.

Impressionen stabil, Klicks sinken. Hier verschiebt sich die Klickrate. Zu prüfen sind Titel, Snippet, Suchintention und die Zusammensetzung der Suchergebnisseite.

Positionen und Klicks sinken gemeinsam. Jetzt kommen Inhaltsänderungen, technische Defekte, veränderte interne Verlinkung oder Wettbewerbsbewegungen infrage.

Nur ein Gerätetyp verliert. Der Verdacht richtet sich auf gerätespezifische Darstellung, Performance oder Ergebnisdarstellung.

Diese Muster sind keine Diagnosen. Sie legen fest, welche Frage als Nächstes gestellt wird und welche Quelle sie beantwortet.

Schritt 5: Performance-Daten richtig lesen

PageSpeed Insights kombiniert reale Nutzungsdaten aus dem Chrome User Experience Report mit Lighthouse-Labordaten, die unter kontrollierten Bedingungen erzeugt werden. Das sind zwei verschiedene Aussagen in einem Bericht, und sie beantworten verschiedene Fragen.

Felddaten bilden reale Nutzung über unterschiedliche Geräte und Verbindungen ab, während Labordaten einen einzelnen simulierten Seitenaufruf unter festgelegten Bedingungen darstellen. Daraus folgt die Arbeitsteilung: Felddaten beantworten die Frage, ob ein Problem existiert und wen es betrifft. Labordaten beantworten die Frage, woran es liegt, weil sie reproduzierbar sind.

Weichen beide voneinander ab, ist das zunächst normal. Typische Gründe:

• unterschiedliche Geräteklassen und Rechenleistung
• verschiedene Netzwerkbedingungen
• geografische Unterschiede
• wiederkehrende Nutzer mit gefülltem Cache
• personalisierte Inhalte, Einwilligungsbanner, Drittanbieter-Skripte
• Unterschiede zwischen Seitentypen innerhalb derselben Domain
• schwankende Serverantwortzeiten

Lighthouse untersucht unter anderem Performance, Barrierefreiheit, Best Practices und grundlegende SEO-Prüfungen; fehlgeschlagene Audits dienen als Hinweise für weitere Untersuchungen. Genau so sind sie zu behandeln: als Ausgangspunkt einer Prüfung, nicht als Aufgabenliste und nicht als Beleg, dass eine Änderung Rankings verbessert.

Für jede Performance-Meldung gilt deshalb dieselbe Prüfkette: Ist das Problem in Felddaten sichtbar? Betrifft es diese URL oder den gesamten Ursprung? Lässt es sich im Labor reproduzieren? Welche Ressource verursacht die Verzögerung? Ist sie überhaupt veränderbar? Wie viele wichtige Seiten und Nutzer sind betroffen?

Schritt 6: Crawl-Ergebnisse gegenprüfen

Ein Crawler zeigt die Website aus der Perspektive seiner eigenen Konfiguration. Er findet, was seine Startpunkte und Regeln ihn finden lassen. Bevor ein Crawl-Ergebnis interpretiert wird, müssen deshalb seine Bedingungen dokumentiert sein: User-Agent, Startpunkte, Crawl-Tiefe, JavaScript-Verarbeitung, Umgang mit robots.txt, zugelassene Subdomains, Parameterbehandlung und Zeitpunkt.

Wie stark diese Bedingungen wirken, zeigt sich an typischen Meldungen. Eine „verwaiste Seite" bedeutet zunächst nur, dass der Crawler keinen internen Link dorthin gefunden hat; die URL kann Google über Sitemap oder externe Links trotzdem bekannt sein. Eine Weiterleitungskette gehört direkt am Server nachgeprüft, weil Caches und wechselnde Statuscodes das Bild verändern. Bei Canonical-Konflikten zählt am Ende nicht, was die Seite angibt, sondern welche Version Google ausgewählt hat, und das steht in der URL-Prüfung.

Die Leitfrage bei jedem Crawl-Befund lautet:

Zeigt dieser Befund ein reales SEO-Problem oder eine Eigenschaft des Prüfverfahrens?

Schritt 7: Den Befund dokumentieren

Eine kompakte Diagnosematrix verhindert, dass Vermutungen als Tatsachen weitergereicht werden.

Die wichtigste Zeile ist die Trennung zwischen Befund und vermuteter Ursache. „Die Klickrate ist gesunken" ist belegt. „Der Titel ist schuld" bleibt eine Hypothese, bis ein zweiter Hinweis oder ein kontrollierter Vergleich sie stützt.

Maßnahmen nach Wirkung, Sicherheit und Aufwand priorisieren

Nicht jede Auffälligkeit verdient Umsetzung. Drei Dimensionen entscheiden.

Wirkung. Wie viele relevante URLs sind betroffen? Wie hoch sind Sichtbarkeit und Geschäftswert dieser Seiten? Blockiert das Problem Crawling, Indexierung oder Nutzung? Betrifft es ein Template und damit den ganzen Seitentyp?

Sicherheit. Stützt sich der Befund auf eine Primärdatenquelle? Wurde er mit einer zweiten, unabhängigen Methode bestätigt? Ist die Ursache reproduzierbar? Welche Alternativerklärungen bleiben offen?

Aufwand. Wie hoch ist der Entwicklungs- und Redaktionsaufwand? Wirkt die Änderung auf andere Seitentypen? Ist ein Rollback möglich? Wie lange dauert es, bis ein Effekt überhaupt messbar wird?

Daraus ergibt sich eine belastbare Reihenfolge:

1. Hohe Wirkung, hohe Sicherheit, geringer Aufwand: sofort umsetzen.
2. Hohe Wirkung, mittlere Sicherheit: zuerst validieren oder auf einem Teilbestand testen.
3. Hohe Wirkung, geringe Sicherheit: keine flächige Änderung ohne zusätzliche Belege.
4. Geringe Wirkung, hoher Aufwand: zurückstellen, auch wenn ein Werkzeug die Meldung als kritisch markiert.
5. Technisch riskante Änderung: nur mit Testumgebung, Monitoring und Rückfallplan.

Die Dringlichkeitsstufe eines Werkzeugs ist dabei ein Vorschlag, keine Vorgabe. Sie kennt weder das Geschäftsmodell noch die Bedeutung einzelner Seitentypen und gewichtet deshalb systematisch falsch.

Der Ablauf in neun Schritten

1. Symptom mit URL, Segment und Zeitraum beschreiben.
2. Eine konkrete Untersuchungsfrage formulieren.
3. Die Primärdatenquelle bestimmen, die dieses Ereignis direkt misst.
4. Auf der kleinstmöglichen sinnvollen Ebene auswerten.
5. Die Tool-Ausgabe gegen einen direkten Abruf oder eine zweite Quelle prüfen.
6. Befund, Ursache und Hypothese getrennt dokumentieren.
7. Alternative Erklärungen gezielt ausschließen.
8. Nach Wirkung, Sicherheit und Aufwand priorisieren.
9. Erfolgskriterium und Kontrollzeitpunkt vor der Umsetzung festlegen.

Der Qualitätsunterschied zwischen zwei SEO-Analysen liegt nicht in der Zahl der eingesetzten Werkzeuge. Er liegt in der Fähigkeit, eine präzise Frage zu stellen, ihr die richtige Datenquelle zuzuordnen, jeden Befund gegenzuprüfen und nur das umzusetzen, was die Daten wirklich tragen. Alles andere ist eine Liste.