Seite nicht gefunden — obwohl sie im Seitenbaum steht.

Erst eingrenzen.

Diese Zuordnung spart den größten Teil der Suche. Prüfe außerdem in der Vorschau aus dem Backend heraus: Erscheint die Seite dort, liegt es nicht am Inhalt.

Seiteneigenschaften.

Mehrere Einstellungen können eine Seite unsichtbar machen, ohne dass sie gelöscht wäre: Sie ist deaktiviert, sie liegt außerhalb ihres Veröffentlichungszeitraums, sie ist als Ordner oder Verweis angelegt statt als Standardseite, oder sie ist zwar sichtbar, aber im Menü ausgeblendet — Letzteres führt nicht zu einem 404, wird aber oft verwechselt.

Besonders tückisch ist der Veröffentlichungszeitraum: Ein Enddatum, das einmal für eine Aktion gesetzt wurde, liegt irgendwann in der Vergangenheit, und die Seite verschwindet ohne weitere Meldung. Prüfe das auch bei übergeordneten Seiten — ist ein Elternteil deaktiviert, ist der ganze Zweig weg.

Der Slug.

Seit TYPO3 die Adressen über Slugs bildet, hängt die Erreichbarkeit an diesem Feld in den Seiteneigenschaften. Typische Probleme: Der Slug ist leer, er enthält unerlaubte Zeichen, oder zwei Seiten tragen denselben — dann gewinnt eine, die andere ist nicht erreichbar.

Beim Anlegen erzeugt TYPO3 den Slug aus dem Titel. Wird der Titel später geändert, bleibt der Slug stehen — das ist gewollt, damit Adressen stabil bleiben, führt aber zu Verwirrung. Im Backend lässt sich der Slug neu erzeugen; dabei entsteht eine neue Adresse, und die alte sollte weitergeleitet werden (siehe unten). Nach größeren Umbauten im Seitenbaum lohnt eine Prüfung, ob alle Slugs eindeutig sind.

Site-Konfiguration und Routing.

Die Site-Konfiguration legt fest, welche Domain zu welchem Teil des Seitenbaums gehört, welche Sprachen es gibt und wie Adressen gebildet werden. Sie ist der häufigste Grund dafür, dass nach einem Umzug alle Unterseiten 404 liefern: Dort steht noch die alte Domain, und TYPO3 findet den passenden Einstiegspunkt nicht.

Zu prüfen sind drei Dinge: Stimmt der Einstiegspunkt mit der tatsächlichen Domain überein, inklusive Protokoll und www-Variante? Zeigt die Konfiguration auf die richtige Wurzelseite? Und gibt es für jede genutzte Domain eine eigene Konfiguration? Bei mehreren Websites in einer Installation ist Letzteres eine häufige Lücke. Die Konfiguration liegt als Datei im Projektordner und lässt sich auch ohne Backend prüfen und korrigieren.

Sprachen.

Bei mehrsprachigen Installationen kommt eine Ebene dazu. Eine Seite kann in der Hauptsprache existieren, in einer anderen aber nicht übersetzt sein. Je nach Einstellung liefert TYPO3 dann die Hauptsprache aus, leitet um oder gibt einen 404 zurück — gesteuert über den Umgang mit fehlenden Übersetzungen in der Site-Konfiguration.

Prüfe zusätzlich, ob die Sprache überhaupt aktiv ist und ob ihr Adresspräfix mit dem übereinstimmt, was in den Links verwendet wird. Ein Sprachkürzel, das in der Konfiguration anders geschrieben ist als in alten Links, erzeugt flächendeckend 404 für diese Sprache (Mehrsprachigkeit allgemein).

Zugriffsrechte.

Seiten lassen sich auf bestimmte Benutzergruppen beschränken. Ist das gesetzt, sehen nicht angemeldete Besucher die Seite nicht — je nach Konfiguration mit einer Weiterleitung zur Anmeldung oder mit einem 404. Das ist gewollt, wird aber zum Problem, wenn eine Gruppe versehentlich gesetzt oder eine Gruppe gelöscht wurde, auf die noch verwiesen wird.

Erkennbar ist das daran, dass die Seite im Backend und in der Vorschau erscheint, für Besucher aber nicht. Prüfe die Zugriffseinstellungen der Seite und aller übergeordneten Seiten — Beschränkungen vererben sich nach unten.

Nach Umzug oder Upgrade.

Zwei Klassiker. Nach einem Umzug stimmt die Domain in der Site-Konfiguration nicht mehr, und oft fehlen zusätzlich Serverregeln, die Adressen an TYPO3 weiterreichen. Nach einem Upgrade kann es sein, dass Slugs erst erzeugt werden müssen oder dass eine alte Adressbildung durch eine Extension abgelöst wurde, die nicht mehr aktiv ist.

In beiden Fällen gehört zur Prüfliste: Site-Konfiguration ansehen, Caches vollständig leeren, Datenbankabgleich ausführen und eine Handvoll Unterseiten testen — nicht nur die Startseite (Update-Fehler, Cache leeren).

Alle Seiten betroffen.

Läuft nur die Startseite und sonst nichts, liegt es meist nicht an TYPO3, sondern an der Serverkonfiguration: Die Regeln, die alle Adressen an den Einstiegspunkt weiterreichen, fehlen oder sind beschädigt. Bei Apache steht das in der .htaccess, bei nginx in der Serverkonfiguration, die nur der Hoster ändern kann.

TYPO3 bringt eine Beispielkonfiguration mit, die als Grundlage dient. Wichtig ist, eigene Ergänzungen davon getrennt zu halten, damit ein Update die Datei nicht überschreibt — und vor jeder Änderung eine Kopie zu ziehen, weil ein Tippfehler dort die ganze Website lahmlegt (Serverregeln allgemein).

Alte Adressen weiterleiten.

Wenn sich Adressen ändern — durch einen neuen Slug, eine Umstrukturierung oder einen Umzug —, gehören die alten weitergeleitet. TYPO3 bringt dafür eine eigene Verwaltung mit, und beim Ändern eines Slugs bietet es an, automatisch eine Weiterleitung anzulegen. Diese Funktion sollte eingeschaltet sein; sie verhindert genau die 404, die sonst Monate später auffallen.

Prüfe die Liste gelegentlich: Automatisch erzeugte Weiterleitungen summieren sich, und Ketten aus mehreren Schritten verlangsamen den Aufruf. Zusammenführen, wo möglich, aber nicht löschen — alte Links in Suchergebnissen und Verzeichnissen leben lange.

Eine ordentliche Fehlerseite.

404 lassen sich nie vollständig vermeiden — alte Links, Tippfehler, gelöschte Inhalte. Was du beeinflussen kannst, ist, was der Besucher dort sieht. In der Site-Konfiguration lässt sich festlegen, welche Seite bei einem 404 ausgeliefert wird. Nutze das: eine Seite im Design der Website, mit Suchfeld, den wichtigsten Einstiegen und einem Kontaktweg — statt einer nackten Servermeldung.

Prüfe dabei, dass die Fehlerseite tatsächlich den richtigen Statuscode sendet. Eine „Seite nicht gefunden“ mit dem Code für Erfolg verwirrt Suchmaschinen und sorgt dafür, dass tote Adressen im Index bleiben (Sichtbarkeit bei Google).

Wenn du nicht weiterkommst.

Wenn Unterseiten 404 liefern und du die Ursache nicht findest, schaue ich mir Site-Konfiguration, Slugs und Serverregeln an. Schreib mir mit Domain, TYPO3-Version und einer kurzen Beschreibung — du bekommst eine ehrliche Einschätzung, ob ich der Richtige bin. Den Überblick über alle Themen gibt TYPO3-Fehler beheben. Wenn sich am Ende herausstellt, dass ein Wechsel die bessere Lösung ist: TYPO3 zu WordPress.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Web-Entwickler aus Quakenbrück. Mein Schwerpunkt liegt auf WordPress — an TYPO3-Installationen arbeite ich dort, wo es um Betrieb und Fehlersuche geht: Ausfälle, Serverthemen, Datenbank, Mailversand, Updates und die Frage, wie es mit einer alten Installation weitergehen soll. Das sind die Probleme, bei denen die Ursache meist nicht im System selbst liegt, sondern darunter. Geht es um tiefe Entwicklung in TYPO3 — eigene Extensions, komplexe Mehrsprachigkeit, große Redaktionssysteme —, sage ich dir das offen und empfehle jemanden, der genau das macht. Ehrlich beraten heißt für mich auch, eine Anfrage abzugeben.