leerer Title-Tag: Erkennen und korrekt beheben

Was hier wirklich geprüft wird

Ein fehlender oder leerer <title> lässt die Seite ohne selbst definierten kurzen Dokumenttitel. Beheben Sie die gemeinsame Template-Ursache und prüfen Sie den finalen Head.

Für „leerer Title-Tag: Erkennen und korrekt beheben“ muss der finale <title> die konkrete Seite beschreiben, natürlich lesbar bleiben und aus genau einem kontrollierten Template-/CMS-Pfad stammen.

Sollverhalten und Entscheidungsgrenze

Sollzustand: Jede indexierbare Seite im Scope liefert im finalen HTML genau einen nicht-leeren <title>, der den konkreten Seitenzweck beschreibt.

Diagnose: welche Evidenz erfassen

Crawlen Sie nicht nur eine Beispielseite. Exportieren Sie pro indexierbarer URL den finalen title-Wert, Template/Page-Type und den Ausgabe-Ursprung. Normalisieren Sie Whitespace, gruppieren Sie Duplikate und vergleichen Sie Raw HTML mit gerendertem DOM, wenn Client-JavaScript den Head verändert.

Für wiederkehrende Fehler ist die wichtige Frage nicht „welche 100 Seiten editieren wir?“, sondern „welche Variable, Component, Plugin- oder CMS-Regel erzeugt diese 100 Seiten?“.

Technische Umsetzung

Für „leerer Title-Tag: Erkennen und korrekt beheben“ muss der finale <title> die konkrete Seite beschreiben, natürlich lesbar bleiben und aus genau einem kontrollierten Template-/CMS-Pfad stammen.

<title></title>

[...document.querySelectorAll('title')].map(x => x.textContent.trim())

Prüfen Sie nicht nur die Zeichenlänge: erfassen Sie Vorhandensein, Eindeutigkeit, Seitenspezifität und Ausgabequelle. Bei wiederkehrenden Abweichungen gehört der Fix in Template/CMS-Schema, nicht in manuelle Einzelbearbeitung.

Konkretes Entscheidungsbeispiel

Vorher: <title></title> weil product.name leer ist.
Fix: Pflichtfeld validieren und einen fachlich sinnvollen Fallback aus der tatsächlichen Page-Entity definieren.
Nachher: <title>Ergonomic Chair S2 | Example</title>; zusätzlich wird ein Fixture mit fehlendem Namen getestet, damit der Fehler nicht zurückkehrt.

Typische Ursachen

Häufige Ursachen: fehlende Pflichtvariable, leerer CMS-Fallback, doppelte Head-Komponenten, SEO-Plugin plus Theme-Ausgabe, alte clientseitige Head-Logik, unzureichend differenzierende Template-Regel oder Editor-Copy/Paste. Der Fix gehört an den gemeinsamen Generator, wenn mehr als einzelne Ausnahmen betroffen sind.

Sonderfälle und Fehlalarme

Kein starres Zeichenlimit als PASS/FAIL verwenden. Ein kurzer Markenname kann vollständig sein, und ein langer wissenschaftlicher/produktbezogener Titel kann notwendig sein. Google kann einen anderen Title-Link erzeugen; das allein beweist keinen technischen Defekt. Prüfen Sie Sprache, Seitentyp und tatsächliche Differenzierung.

Verifikation nach dem Fix

| Check | PASS | FAIL | | --- | --- | --- | | Output | erwartete Regel ist im finalen HTML/HTTP/DOM sichtbar | Backend zeigt korrekt, finale Ausgabe aber nicht | | Scope | repräsentative URLs aller betroffenen Templates getestet | nur eine Beispiel-URL getestet | | Source | gemeinsame Ursache/Owner dokumentiert | manuelle Einzel-Edits ohne Root Cause | | Regression | angrenzende Canonical/Robots/Accessibility/Link-Regeln bleiben korrekt | Fix erzeugt neuen Fehler in derselben Component | | Evidence | Vorher/Nachher-Werte und Testzeitpunkt gespeichert | nur visueller Eindruck oder Screenshot |

Verantwortung und Übergabe

Content/SEO-Owner: definiert den erwarteten Seitenzweck und ob die Abweichung wirklich behoben werden muss.
Developer/Platform: behebt die gemeinsame Template-, Routing-, Header- oder Component-Ursache.
QA: testet repräsentative Edge States und führt einen Re-Crawl/Re-Request nach Deployment aus.
Release Owner: dokumentiert Zeitpunkt, Scope und Rollback-Punkt, damit Monitoring-Signale später eindeutig zugeordnet werden können.

Abnahmekriterien

PASS, wenn der finale technische Zustand auf repräsentativen URLs reproduzierbar ist, die gemeinsame Ursache behoben wurde, erlaubte Ausnahmen dokumentiert sind und Re-Crawl/Re-Request keine neue Regression bei Canonical, Robots, Accessibility, internen/externen Links oder Rendering zeigt.

Operatives Beispiel: Fehler → Fix → Nachweis

Fehlerbild: Der Audit meldet „leerer Title-Tag: Erkennen und korrekt beheben“ auf mehreren URLs.
Root Cause: Die gemeinsame Ausgabe entsteht in einem Template, Component, CMS-Fallback oder Infrastruktur-Layer.
Fix: Ändern Sie diese gemeinsame Quelle statt einzelner Seiten und halten Sie die Änderung so klein wie möglich.
Nachweis: Speichern Sie mindestens eine vorher/nachher URL pro Template, finalen HTTP/HTML/DOM-Output und das Re-Crawl-Ergebnis. Wenn ein Sonderfall bewusst anders bleibt, dokumentieren Sie ihn explizit, damit das Audit ihn nicht später wieder als unbehandelten Fehler interpretiert.

Für produktive Systeme sollte der Fix außerdem eine Regression-Prüfung enthalten: gleiche Locale, Mobile/Desktop falls relevant, leere Datenzustände und eine Seite, die bereits korrekt war. So wird sichtbar, ob der Fix nur den gemeldeten Fall löst oder den Generator insgesamt stabilisiert.

1. Betroffene URL-/Template-Klasse definieren und Expected Behavior schriftlich festlegen.
2. Raw HTTP/HTML erfassen; bei clientseitigen Änderungen zusätzlich den gerenderten DOM prüfen.
3. Output über mehrere URLs gruppieren und Duplikate/Boilerplate nach Template quantifizieren.
4. Den Fehler auf die gemeinsame Schicht zurückführen: DNS/CDN, Routing, Template, Component, CMS-Feld oder Editor-Inhalt.
5. Den kleinsten systemischen Fix umsetzen und vorher einen Rollback-Punkt sichern.
6. Positive Fälle, leere/fehlende Daten und mindestens einen Edge Case testen.
7. Alle betroffenen Templates/URLs erneut crawlen bzw. requesten und Vorher/Nachher-Evidenz speichern.
8. PASS: erwartetes Verhalten ist reproduzierbar, keine angrenzende SEO-/Accessibility-Regel regressiert und der Fix benötigt keine manuellen Einzel-Workarounds.