Website online analysieren: der Prüfablauf für eine geordnete Bestandsaufnahme
Erreichbarkeit, Technik, Ladeverhalten, Inhalt: in dieser Reihenfolge gehen Sie Ihre Website durch. So wird aus Befunden eine priorisierte Maßnahmenliste.

Wer die eigene Website analysieren will, öffnet meistens ein Messwerkzeug, schaut auf die erste rote Zahl und beginnt dort zu arbeiten. Das Ergebnis ist eine Liste von Einzelbefunden ohne Rangfolge, und häufig wird an einer Seite optimiert, die Google gar nicht in den Index aufgenommen hat. Eine Bestandsaufnahme wird erst dann belastbar, wenn sie einer festen Reihenfolge folgt: erst die Frage, ob die Website überhaupt erreichbar und indexiert ist, dann die technische Basis, danach das reale Ladeverhalten und zuletzt Inhalt und Sichtbarkeit. Diese Reihenfolge ist keine Geschmacksfrage. Jeder Schritt setzt voraus, dass der vorherige geklärt ist.
Der folgende Ablauf beschreibt eine Sitzung von rund zwei bis drei Stunden für eine kleine bis mittlere Website. Werkzeuge kommen darin nur als Messmittel eines Schritts vor. Welches Werkzeug Sie einsetzen, ändert den Ablauf nicht.
Vorbereitung: Umfang und Befundliste festlegen
Legen Sie vor dem ersten Prüfschritt fest, welche Seiten überhaupt zählen. Üblicherweise sind das die Startseite, die zentralen Leistungs- oder Kategorieseiten, die wichtigsten Ratgeberseiten, die Kontakt- oder Anfragestrecke und je ein typischer Vertreter jeder weiteren Seitenvorlage. Diese Auswahl verhindert, dass Sie sich in Einzel-URLs verlieren, die geschäftlich nichts tragen.
Legen Sie außerdem eine Befundliste mit fünf Spalten an: Befund, betroffene URL oder Vorlage, Einstufung, Maßnahme, Nachweis der Behebung. Vergeben Sie dabei keine Note und keinen Gesamtscore. Eine einzelne Zahl verdeckt genau den Unterschied, auf den es ankommt: ob die Website an einem einzigen Hindernis scheitert oder an vielen kleinen Stellen besser werden könnte.
Schritt 1: Erreichbarkeit und Indexierung
Am Anfang steht die Frage, ob Ihre Seiten für Suchmaschinen existieren. Alles Weitere ist ohne diese Antwort wertlos, denn eine nicht indexierte Seite kann keine Sichtbarkeit verlieren, die sie nie hatte.
Prüfen Sie zuerst, ob die Startseite und die wichtigsten Unterseiten mit dem Statuscode 200 ausgeliefert werden. Verbreitete Befunde sind Weiterleitungsketten über mehrere Stationen, Seiten mit Statuscode 404, die noch intern verlinkt sind, und eine Domain, die unter www und ohne www zwei getrennte Fassungen ausliefert, statt auf eine kanonische Variante weiterzuleiten. Weiterleitungen sind nicht grundsätzlich ein Problem. Ein Befund entsteht, wenn eine wichtige URL zum falschen Ziel führt, mehrere Stationen durchläuft oder in einer Schleife endet.
Für die Indexierung selbst gilt eine wichtige Einschränkung: Die site:-Abfrage in der Google-Suche eignet sich dafür nicht. Google bezeichnet sie ausdrücklich als nicht vollständig und nicht als Diagnosewerkzeug für die Indexierung. Maßgeblich sind der Indexierungsbericht und die URL-Prüfung in der Google Search Console. Wer die Zahl aus der site:-Abfrage als Bestandsaufnahme notiert, misst ein Artefakt.
Vergleichen Sie die Zahl der indexierten Seiten auch nicht mit der Gesamtzahl aller technisch erzeugten URLs. Entscheidend ist, ob die Seiten mit eigenständigem Zweck indexiert sind. Filterkombinationen, interne Suchergebnisse und Duplikate gehören ohnehin nicht in den Index.
Die URL-Prüfung liefert zwei unterschiedliche Auskünfte, die regelmäßig verwechselt werden: den Zustand der zuletzt indexierten Fassung und einen Livetest der aktuell ausgelieferten URL. Weichen beide voneinander ab, ist genau das der Befund. Zeigt der Livetest eine korrigierte Seite, der Index aber noch den alten Zustand, ist die Änderung erreichbar, nur noch nicht verarbeitet. Halten Sie die Abweichung fest, statt daraus einen zweiten Fehler abzuleiten.
Notieren Sie in diesem Schritt drei Zahlen: Wie viele Ihrer Seiten sind indexiert, wie viele sind bekannt aber nicht indexiert, und welche wichtigen Seiten fehlen ganz.
Schritt 2: Die technische Basis
Erst wenn klar ist, welche Seiten im Index sind, lohnt der Blick auf die technischen Anweisungen, die diesen Zustand erzeugen. Vier Punkte tragen hier den größten Teil der Befunde.
Die robots.txt. Lesen Sie die Datei vollständig und wörtlich. Eine zu weit gefasste Regel sperrt schnell ein ganzes Verzeichnis vom Crawling aus, und eine Crawling-Sperre ist nicht dasselbe wie ein Ausschluss aus dem Index. Zwei Details werden zusätzlich oft übersehen. Erstens wertet Google von einer robots.txt nur die ersten 500 Kibibyte aus, alles darüber wird ignoriert. Bei historisch gewachsenen Dateien mit hunderten Ausschlussregeln ist das ein realer Fall. Zweitens unterstützt Google die noindex-Anweisung in der robots.txt seit dem 1. September 2019 nicht mehr. Wer dort noch eine solche Zeile stehen hat, glaubt, eine Seite auszuschließen, während sie tatsächlich weiterhin indexiert werden kann.
Meta-Robots und X-Robots-Tag. Der Ausschluss von der Indexierung läuft heute über das Meta-Robots-Tag im HTML oder über den X-Robots-Tag im HTTP-Header. Prüfen Sie stichprobenartig, ob eine wichtige Seite versehentlich auf noindex steht. Das ist der häufigste einzelne Grund dafür, dass eine fertige Seite ohne erkennbaren Anlass keine Sichtbarkeit aufbaut. Prüfen Sie dabei je Vorlage, nicht je URL: In einer zentralen Vorlage betrifft derselbe Fehler auf einen Schlag alle Seiten, die sie verwenden.
Canonical-Angaben. Zeigt die kanonische URL einer Seite auf sich selbst, oder auf eine andere Seite? Beides kann richtig sein. Falsch ist es, wenn eine ganze Kategorie auf die Startseite kanonisiert wird. Vergleichen Sie bei auffälligen Seiten zusätzlich die von Ihnen gesetzte Canonical-URL mit der Fassung, die Google laut URL-Prüfung tatsächlich gewählt hat.
Auslieferung und Protokoll. Seit Oktober 2023 crawlt Google alle Websites überwiegend mit dem Smartphone-Googlebot. Die mobil ausgelieferte Fassung ist damit die bewertete. Prüfen Sie deshalb die mobile Ansicht, nicht die Desktop-Ansicht, und vergleichen Sie, ob mobil dieselben Inhalte, Überschriften, strukturierten Daten und Links vorhanden sind. Es geht nicht darum, ob das Layout auf einem kleinen Bildschirm ordentlich aussieht, sondern darum, ob es dort vollständig ist. HTTPS gehört in dieselbe Kategorie: Google hat es 2014 als leichtgewichtiges Ranking-Signal bestätigt und stuft es seither als Basisanforderung ein. Eine Seite ohne gültiges Zertifikat oder mit gemischten Inhalten ist kein Optimierungsthema, sondern ein Mangel.
Schritt 3: Ladeverhalten aus Felddaten
Der dritte Schritt hat eine Eigenart, an der viele Bestandsaufnahmen scheitern: Es gibt zwei Datensorten, und nur eine davon beschreibt Ihre Besucher. PageSpeed Insights zeigt beide getrennt an. Labordaten stammen aus einem einzelnen Lighthouse-Testlauf auf einem simulierten Gerät. Felddaten stammen aus dem Chrome User Experience Report und fassen echte Seitenaufrufe über ein rollierendes Fenster von 28 Tagen zusammen.
Für die Bestandsaufnahme zählen die Felddaten. Sie beantworten die Frage, wie Ihre Website tatsächlich erlebt wird. Die Labordaten beantworten die Frage, wie eine Testmaschine sie erlebt hat, und schwanken zwischen zwei Durchläufen teils erheblich.
Google bewertet die Core Web Vitals am 75. Perzentil der Seitenaufrufe. Das bedeutet: Drei von vier Aufrufen müssen den Schwellenwert einhalten, nicht der Durchschnitt. Als gut gelten ein Largest Contentful Paint bis 2,5 Sekunden, ein Interaction to Next Paint bis 200 Millisekunden und ein Cumulative Layout Shift bis 0,1. Interaction to Next Paint hat im März 2024 den früheren First Input Delay als Core Web Vital abgelöst. Wenn Sie eine ältere Auswertung Ihrer Website in der Schublade haben, misst sie an dieser Stelle eine Kennzahl, die es so nicht mehr gibt.
Achten Sie darauf, ob die angezeigten Werte für die gesamte Website oder für die konkrete URL gelten. Ein Gesamtwert kann ein schlechtes Verhalten einzelner Seitentypen verdecken.
Wichtig für die Einordnung: Liegen für Ihre Website keine Felddaten vor, ist das kein schlechtes Ergebnis, sondern gar keines. Kleine Websites erreichen die nötige Datenmenge oft nicht. Notieren Sie in dem Fall „nicht messbar" und stützen Sie sich in diesem Schritt auf nichts weiter. Ein Laborwert ersetzt die fehlende Messung nicht. Was danach käme, also die eigentliche Beschleunigung der Seite, ist eine eigene Aufgabe und gehört nicht in diese Sitzung.
Schritt 4: Inhalt und Sichtbarkeit
Zum Schluss die Frage, wofür Ihre Website tatsächlich gefunden wird. Der Leistungsbericht der Search Console hält Daten der letzten 16 Monate vor. Damit lässt sich in einer Sitzung ein Jahresvergleich ziehen, ohne dass Sie vorher etwas eingerichtet haben müssen.
Gehen Sie drei Auswertungen durch. Erstens die Suchanfragen mit Impressionen, aber ohne oder mit sehr wenigen Klicks: Hier existiert Nachfrage, die Ihre Seite sieht, aber nicht abholt. Zweitens die Seiten, die vor zwölf Monaten Klicks hatten und heute keine mehr: Das ist ein Verlust, keine Momentaufnahme. Drittens die Frage, welche Ihrer Seiten für dieselbe Suchanfrage erscheinen.
Zwei Einschränkungen halten diesen Schritt ehrlich. Eine niedrige Klickzahl allein ist noch kein Fehler, denn Position, Suchabsicht und Ergebnisdarstellung wirken mit. Und mehrere eigene URLs zu einer Suchanfrage konkurrieren nur dann, wenn sie dieselbe Absicht bedienen. Notieren Sie also zuerst den Befund und erst danach eine Vermutung über die Ursache.
Ergänzen Sie das um eine schlichte inhaltliche Sichtung der zehn wichtigsten Seiten: Gibt es genau eine H1, beantwortet der erste Absatz die Frage, die die Überschrift stellt, und steht auf der Seite etwas, das nicht auf drei anderen Seiten Ihrer Website ebenfalls steht.
Befunde einordnen: blockierend oder optimierend
Am Ende der vier Schritte liegt eine Liste vor. Sie wird erst brauchbar, wenn jeder Eintrag genau einer von zwei Klassen zugeordnet wird.
Blockierend ist ein Befund, der verhindert, dass eine Seite überhaupt wirken kann. Beispiele: Die Seite ist nicht indexierbar, sie liefert einen Fehlerstatus aus, eine benötigte Ressource ist per robots.txt gesperrt, sie ist mobil nicht vollständig, oder sie kanonisiert auf eine fremde URL. Solche Befunde haben keine Abstufung. Sie sind entweder behoben oder nicht.
Optimierend ist ein Befund, der die Wirkung einer funktionierenden Seite verbessert. Beispiele: ein LCP von 3,1 Sekunden statt 2,5, ein dünner Einleitungsabschnitt, eine fehlende Zwischenüberschrift. Diese Befunde haben eine Abstufung und lassen sich stufenweise abarbeiten.
Die Trennung ist deshalb wichtig, weil optimierende Arbeit an einer blockierten Seite folgenlos bleibt. Ein perfekter Text auf einer Seite mit noindex ändert nichts.
Aus der Liste wird eine Reihenfolge
Sortieren Sie jetzt in drei Bündeln. Zuerst alle blockierenden Befunde, gewichtet nach drei Fragen: Wie viele wichtige Seiten sind betroffen, welche Rolle spielen diese Seiten, und wie schnell lässt sich der Zustand sicher korrigieren. Ein einzelnes falsches Meta-Robots-Tag auf einer Kategorievorlage betrifft möglicherweise hunderte Seiten und ist in zehn Minuten behoben. Solche Fälle stehen immer ganz oben.
Danach die optimierenden Befunde auf den Seiten, die laut Leistungsbericht bereits Impressionen sammeln. Hier ist die Nachfrage bereits belegt, der Hebel also messbar. Danach die wichtigen Seiten, die noch keine Sichtbarkeit haben. Zuletzt alles Übrige, mit einem Vermerk, warum es nicht dringend ist.
Halten Sie zu jedem Eintrag drei Angaben fest: den Befund, die betroffene URL oder Vorlage, und woran Sie erkennen würden, dass er behoben ist. Der dritte Punkt ist der eigentliche Wert der Sitzung. Statt „Indexierung verbessern" steht dort dann: „noindex aus der Produktvorlage entfernen, danach im Livetest der URL-Prüfung kontrollieren." Das macht aus einer Beobachtung eine überprüfbare Aufgabe und verhindert, dass Sie bei der nächsten Bestandsaufnahme dieselbe Liste noch einmal von vorne erstellen.
Eine sinnvolle Wiederholung liegt bei ein bis zwei Durchläufen im Jahr, zusätzlich nach jedem größeren Eingriff wie einem Relaunch, einem Umzug der Domain oder einer Umstellung der Seitenstruktur. Zwischen den Durchläufen genügt der Blick in den Indexierungsbericht, denn dort zeigt sich ein blockierender Fehler zuerst.
