Onpage-Prüfung endet in der Praxis oft bei drei Stichproben und einem guten Gefühl. Das funktioniert, solange eine Website fünf Seiten hat. Danach wird es zur Glückssache, ob man ausgerechnet die Seite anschaut, auf der etwas kaputt ist.
Überblick
Das Wichtigste in Kürze
- Das Skript crawlt die Sitemap und prüft jede Seite gegen dieselbe Liste von Regeln.
- Es trennt Fehler von Hinweisen, damit eine Warnung den Livegang nicht blockiert und ein echter Fehler es sehr wohl tut.
- Inhaltliche Mindestlängen sind ein eigener Schalter, weil sie während des Aufbaus bewusst verletzt werden.
- Die Prüfung ersetzt kein Lektorat, sie sichert nur die Form ab.
Ausgangslage
Warum Stichproben nicht reichen
Beim Relaunch dieser Website standen 28 Seiten an, davon 25 Projektseiten mit sehr ähnlicher Struktur. Genau diese Ähnlichkeit ist tückisch. Wenn 25 Seiten aus derselben Quelle entstehen, sieht die Stichprobe immer gut aus, und ein Fehler im Muster steckt trotzdem in allen 25.
Dazu kommen Regeln, die man beim Lesen schlicht nicht sieht. Ob ein Titel 58 oder 63 Zeichen lang ist, ob eine Überschriftenebene übersprungen wurde, ob strukturierte Daten überhaupt noch gültiges JSON sind — das erkennt kein Auge zuverlässig, und schon gar nicht fünfundzwanzigmal hintereinander.
Umsetzung
Was das Skript prüft
Der Ablauf beginnt bei der Sitemap, holt jede dort genannte Adresse und wertet die Antwort aus. Geprüft wird in einem Durchlauf:
- Erreichbarkeit — Statuscode, Weiterleitungen und die Frage, ob eine Seite ungewollt auf noindex steht.
- Auszeichnung — Titel und Beschreibung nach Länge und Dubletten, dazu die kanonische Adresse und die Sprachverweise.
- Struktur — genau eine erste Überschrift je Seite und keine übersprungene Ebene.
- Inhalt — eigene Wörter im Hauptbereich, getrennt vom Anteil, der aus dem Seitengerüst stammt.
- Strukturierte Daten — jedes JSON-LD-Element muss sich lesen lassen und einen Typ nennen.
- Bilder — Bilder ohne Alternativtext werden namentlich genannt.
- Verlinkung — eingehende interne Links je Seite und Links, die auf eine Weiterleitung statt auf das Ziel zeigen.
- Reste — vergessene Platzhalter und Brotkrumen, die auf einen Anker statt auf eine Seite verweisen.
Der Lauf richtet sich dabei nicht nur gegen die fertige Website. Das Skript nimmt eine Basisadresse entgegen und kann die Adressen aus der Sitemap auf eine lokale Installation umbiegen, samt passendem Hostnamen. Dadurch prüfe ich denselben Bestand vor dem Hochladen und danach noch einmal live, ohne eine zweite Fassung der Regeln zu pflegen.
Entscheidung
Fehler und Hinweise trennen
Die wichtigste Eigenschaft des Skripts ist nicht die Liste der Regeln, sondern ihre Gewichtung. Technische Mängel sind Fehler und setzen den Rückgabewert des Laufs auf eins, wodurch jede weitere Automatisierung stehen bleibt. Alles, was Ermessenssache ist, bleibt ein Hinweis.
Inhaltliche Mindestlängen habe ich bewusst hinter einen eigenen Schalter gelegt. Während des Aufbaus sind kurze Seiten normal, und ein Werkzeug, das täglich grundlos Alarm schlägt, wird nach einer Woche ignoriert. Erst zum Abschluss läuft die strenge Variante, und dann muss sie sauber durchlaufen.
Dieser Lauf stammt vom Abschluss des Seitenausbaus. Er sagt nichts darüber aus, ob die Texte gut sind. Er sagt nur, dass keine Seite mehr an einer Regel scheitert, die sich objektiv prüfen lässt. Das ist eine bescheidene Aussage, aber eine belastbare.
Am häufigsten fängt die Prüfung zwei Dinge ab, die beim Lesen niemandem auffallen. Interne Links, die auf eine Weiterleitung statt auf das endgültige Ziel zeigen, entstehen fast zwangsläufig, sobald Seiten zusammengelegt werden. Und Seiten, auf die keine einzige andere Seite verweist, bemerkt man erst, wenn jemand die eingehenden Verweise zählt. Beides kostet in der Reparatur fast nichts und einiges, wenn es bleibt.
Für die Abstimmung schreibt der Lauf auf Wunsch einen Bericht als Datei. Das ist wichtiger, als es klingt, denn eine Übersicht aller Seiten mit ihren Werten erlaubt eine ganz andere Diskussion als ein Bauchgefühl über drei Stichproben.
Grenzen
Was ein Skript nicht kann
Kein Prüfskript erkennt, ob ein Text etwas zu sagen hat. Es zählt Wörter, es liest sie nicht. Es merkt auch nicht, ob eine Beschreibung zum Inhalt passt, sondern nur, ob sie die richtige Länge hat. Genau deshalb halte ich die Grenze zwischen Form und Qualität sauber.
Der praktische Nutzen liegt woanders. Das Skript nimmt mir die Arbeit ab, die ich ohnehin schlecht mache, nämlich dieselbe Liste fünfundzwanzigmal aufmerksam durchzugehen. Die frei gewordene Aufmerksamkeit geht in die Fragen, bei denen ein Mensch besser ist als eine Regel.
Fragen
Häufige Fragen
Braucht es dafür ein eigenes Skript?
Für einzelne Seiten nicht, dafür gibt es gute Werkzeuge. Sobald Regeln projektspezifisch werden, etwa eine Mindestzahl eingehender interner Links oder ein bestimmter Aufbau der strukturierten Daten, ist ein eigenes Skript schneller geschrieben als jedes Werkzeug passend konfiguriert.
Wie oft läuft die Prüfung?
Vor jedem größeren Livegang und nach jeder Änderung am Seitengerüst. Der Lauf dauert wenige Minuten, das ist billiger als jede nachträgliche Korrektur.
Was passiert bei einem Fehler?
Der Lauf endet mit einem Rückgabewert ungleich null und nennt Seite und Regel. Damit lässt sich die Prüfung in jeden automatisierten Ablauf hängen, ohne dass jemand die Ausgabe lesen muss.
Eine zweite Meinung zur eigenen Website?
Ich schaue mir Struktur, Auszeichnung und interne Verlinkung gern an.




