FAQ-Überschriften: Praktische Regel und Verifikation

Was hier wirklich geprüft wird

FAQ-Fragen können Überschriften sein, wenn sie echte Abschnitte einleiten. Vermeiden Sie künstliche Level-Sprünge nur wegen der gewünschten Schriftgröße.

Bei „FAQ-Überschriften: Praktische Regel und Verifikation“ zählt die sichtbare Dokumentstruktur: Heading-Level, Text, DOM-Position und Parent/Child-Beziehung müssen den tatsächlichen Seitenaufbau erklären und dürfen nicht nur CSS-Styling abbilden.

Sollverhalten und Entscheidungsgrenze

Sollzustand: Bei „FAQ-Überschriften: Praktische Regel und Verifikation“ zählt die sichtbare Dokumentstruktur: Heading-Level, Text, DOM-Position und Parent/Child-Beziehung müssen den tatsächlichen Seitenaufbau erklären und dürfen nicht nur CSS-Styling abbilden. Die sichtbare Heading-Sequenz bildet den tatsächlichen Dokumentaufbau ab; Level, Text und Parent/Child-Beziehung bleiben auch in wiederverwendbaren Components nachvollziehbar.

Diagnose: welche Evidenz erfassen

Exportieren Sie für jede Test-URL die sichtbare Heading-Sequenz mit Level, Text und DOM-Pfad. Ergänzen Sie Template/Page-Type und prüfen Sie Desktop sowie Mobile, wenn Komponenten responsiv ein-/ausgeblendet werden.

Eine reine Font-Size-Prüfung ist unzureichend: visuell großer Text kann ein div sein, und ein semantisches Heading kann per CSS klein dargestellt werden. Beide Zustände müssen getrennt bewertet werden.

Technische Umsetzung

Bei „FAQ-Überschriften: Praktische Regel und Verifikation“ zählt die sichtbare Dokumentstruktur: Heading-Level, Text, DOM-Position und Parent/Child-Beziehung müssen den tatsächlichen Seitenaufbau erklären und dürfen nicht nur CSS-Styling abbilden.

<h1>Primary page topic</h1>
<h2>Major section</h2>
<h3>Subsection of that section</h3>

[...document.querySelectorAll('h1,h2,h3,h4,h5,h6')]
  .map(h => ({level:h.tagName, text:h.innerText.trim()}))

Exportieren Sie pro URL die sichtbare Heading-Sequenz als H1 > H2 > H3... zusammen mit Text und DOM-Pfad. Prüfen Sie wiederkehrende Muster nach Component/Template; CSS-Schriftgröße ist kein Ersatz für strukturelle Hierarchie.

Konkretes Entscheidungsbeispiel

PASS: H1 Product Name > H2 Specifications > H3 Dimensions
FAIL: H1 Product Name > H4 Specifications > H2 Reviews

Der zweite Fall ist nicht wegen einer „H4-Strafe“ problematisch, sondern weil der DOM-Aufbau die sichtbare Abschnittsbeziehung nicht sauber erklärt. Prüfen Sie den Component-Kontext und nicht nur das einzelne Heading.

Typische Ursachen

Häufige Ursachen: Design-Systeme koppeln Font-Size an Heading-Level, wiederverwendete Komponenten bringen eigene H1 mit, optionale Felder erzeugen leere Headings oder visuell versteckte Varianten bleiben im DOM. Beheben Sie Component-/Schema-Regeln statt Heading-Level manuell je Seite zu verschieben.

Sonderfälle und Fehlalarme

Mehrere H1 sind nicht automatisch ein Ranking-Fehler, und Level-Sprünge sind nicht mit einer simplen SEO-Strafe gleichzusetzen. Entscheidend sind klare Dokumentstruktur, zugängliche Navigation und eindeutiger Haupttitel. Wiederverwendbare Widgets dürfen ihre Heading-Level nicht unabhängig vom Einbaukontext hart codieren.

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.

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. Komplette Heading-Sequenz mit Text und DOM-Pfad exportieren.
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.