For the complete documentation index, see llms.txt. This page is also available as Markdown.

404 Not Found beheben

Ein 404-Fehler bedeutet, dass der Webserver erreichbar ist, die angeforderte Seite oder Datei aber nicht gefunden wurde.

Der Server antwortet also grundsätzlich, kann den aufgerufenen Pfad jedoch nicht ausliefern.

Typische Meldungen sind:

  • 404 Not Found

  • Not Found

  • The requested URL was not found on this server

  • 404 Seite nicht gefunden

  • nginx 404 Not Found

  • Apache 404 Not Found

Was bedeutet 404 Not Found?

Wenn du eine Webseite öffnest, fragt dein Browser eine bestimmte Adresse beim Server an.

Beispiel:

https://deinedomain.de/kontakt

Der Webserver sucht dann nach der passenden Datei, Route oder Anwendung für /kontakt.

Wenn der Webserver dort nichts findet, gibt er den Statuscode 404 Not Found zurück.

Das bedeutet:

  • die Domain zeigt grundsätzlich auf einen Server

  • der Webserver antwortet

  • die angeforderte Seite oder Datei wurde nicht gefunden

Ein 404-Fehler ist daher kein vollständiger Serverausfall.

Häufige Ursachen

Ein 404-Fehler kann mehrere Ursachen haben:

  • falsche URL

  • Datei wurde gelöscht

  • Datei liegt im falschen Ordner

  • Domain zeigt auf den falschen Webroot

  • falsche Virtual-Host-Konfiguration

  • fehlende index.html oder index.php

  • falsche Weiterleitung

  • fehlerhafte .htaccess

  • falsche Nginx-Konfiguration

  • Anwendung hat keine passende Route

  • WordPress-Permalinks sind fehlerhaft

  • Cache zeigt eine alte Adresse

  • Groß- und Kleinschreibung stimmt nicht

Zuerst prüfen

Prüfe zuerst die einfache Ursache: die URL.

Achte besonders auf:

  • Tippfehler

  • falsche Domain

  • falschen Unterordner

  • fehlende Datei-Endung

  • Groß- und Kleinschreibung

  • unnötige Leerzeichen

  • alte Links oder Bookmarks

Beispiel:

/Kontakt ist unter Linux nicht dasselbe wie /kontakt.

Linux-Dateisysteme unterscheiden Groß- und Kleinschreibung. Windows tut das oft nicht.

Prüfen, ob der Webserver erreichbar ist

Wenn du eine 404-Meldung siehst, ist der Webserver grundsätzlich erreichbar.

Trotzdem solltest du prüfen, ob du wirklich den richtigen Server erreichst.

Öffne dazu testweise die Startseite deiner Domain:

https://deinedomain.de

Wenn die Startseite funktioniert, betrifft der Fehler wahrscheinlich nur eine bestimmte Unterseite.

Wenn auch die Startseite nicht funktioniert, liegt möglicherweise ein anderes Problem vor, zum Beispiel DNS, Webserver, SSL oder Firewall.

Datei oder Ordner prüfen

Wenn du eine statische Datei aufrufen möchtest, muss sie im richtigen Ordner liegen.

Beispiel:

Du rufst auf:

https://deinedomain.de/test.html

Dann muss die Datei test.html im Webverzeichnis deiner Domain liegen.

Typische Webverzeichnisse sind zum Beispiel:

Webserver
Häufiges Webverzeichnis

Apache

/var/www/html

Nginx

/var/www/html

Plesk

je nach Domain im Kundenverzeichnis

aaPanel

je nach Website-Pfad

eigene Konfiguration

abhängig von deiner Virtual-Host-Datei

Prüfe per SSH, ob die Datei vorhanden ist.

Beispiel:

ls -la /var/www/html

Wenn die Datei fehlt, lade sie erneut hoch oder lege sie an.

Startdatei prüfen

Wenn du nur die Domain aufrufst, sucht der Webserver nach einer Startdatei.

Beispiel:

https://deinedomain.de

Typische Startdateien sind:

  • index.html

  • index.htm

  • index.php

Wenn keine Startdatei vorhanden ist, kann je nach Konfiguration ein 404-Fehler oder eine andere Meldung erscheinen.

Prüfe deshalb, ob eine Startdatei im Webverzeichnis liegt.

Beispiel:

ls -la /var/www/html/index.*

Webroot prüfen

Der Webroot ist der Ordner, aus dem der Webserver die Webseite ausliefert.

Wenn deine Dateien im falschen Ordner liegen, findet der Webserver sie nicht.

Beispiel:

Deine Webseite liegt hier:

/var/www/meine-webseite

Der Webserver ist aber so eingestellt:

/var/www/html

Dann ruft der Webserver weiterhin /var/www/html auf und findet deine Dateien nicht.

Prüfe deshalb die Webserver-Konfiguration.

Apache Virtual Host prüfen

Bei Apache wird der Webroot meistens in einer Virtual-Host-Datei festgelegt.

Typischer Pfad:

/etc/apache2/sites-available/deinedomain.conf

Suche dort nach:

DocumentRoot

Beispiel:

DocumentRoot /var/www/html

Der angegebene Pfad muss zu dem Ordner passen, in dem deine Webseite liegt.

Nach Änderungen an der Apache-Konfiguration solltest du die Konfiguration prüfen.

Befehl:

apachectl configtest

Wenn die Prüfung erfolgreich ist, Apache neu laden:

systemctl reload apache2

Nginx Server Block prüfen

Bei Nginx wird der Webroot in einem Server Block festgelegt.

Typischer Pfad:

/etc/nginx/sites-available/deinedomain

Suche dort nach:

root

Beispiel:

root /var/www/html;

Der angegebene Pfad muss zu dem Ordner passen, in dem deine Webseite liegt.

Nach Änderungen an der Nginx-Konfiguration solltest du die Konfiguration prüfen.

Befehl:

nginx -t

Wenn die Prüfung erfolgreich ist, Nginx neu laden:

systemctl reload nginx

Dateirechte prüfen

Wenn Dateien vorhanden sind, aber nicht gelesen werden können, kann es je nach Konfiguration ebenfalls zu Fehlern kommen.

Prüfe die Rechte deiner Dateien und Ordner.

Beispiel:

ls -la /var/www/html

Typische Rechte:

  • Ordner: 755

  • Dateien: 644

Beispielbefehle:

find /var/www/html -type d -exec chmod 755 {} \;

find /var/www/html -type f -exec chmod 644 {} \;

Der Webserver-Benutzer muss die Dateien lesen können.

Bei Debian und Ubuntu ist das häufig:

www-data

.htaccess prüfen

Bei Apache kann eine fehlerhafte .htaccess dazu führen, dass Seiten nicht gefunden werden.

Das betrifft besonders:

  • WordPress

  • Laravel

  • Symfony

  • Weiterleitungen

  • Rewrite-Regeln

  • alte CMS-Systeme

Prüfe, ob im Webverzeichnis eine .htaccess vorhanden ist.

Beispiel:

ls -la /var/www/html/.htaccess

Zum Test kannst du die Datei kurz umbenennen:

mv /var/www/html/.htaccess /var/www/html/.htaccess_backup

Danach Webseite erneut aufrufen.

Wenn die Seite danach funktioniert, liegt das Problem wahrscheinlich an einer Rewrite-Regel.

Wichtig: Benenne die Datei nach dem Test wieder zurück oder erstelle eine korrekte neue .htaccess.

Apache Rewrite-Modul prüfen

Viele Anwendungen benötigen das Apache-Modul rewrite.

Prüfe und aktiviere es bei Bedarf.

Befehl:

a2enmod rewrite

Danach Apache neu laden:

systemctl reload apache2

Außerdem muss im Apache Virtual Host häufig AllowOverride All erlaubt sein, damit .htaccess-Regeln greifen.

Beispiel:

AllowOverride All

Wenn AllowOverride None gesetzt ist, werden .htaccess-Regeln ignoriert.

Nginx Rewrite-Regeln prüfen

Bei Nginx wird keine .htaccess verwendet.

Weiterleitungen und Routen müssen direkt in der Nginx-Konfiguration stehen.

Für viele PHP-Anwendungen wird eine Regel wie diese benötigt:

try_files $uri $uri/ /index.php?$query_string;

Wenn diese Regel fehlt, funktionieren Unterseiten oft nicht und zeigen 404.

Das betrifft zum Beispiel:

  • Laravel

  • Symfony

  • viele PHP-Frameworks

  • eigene Anwendungen mit Routing

Nach Änderungen Nginx prüfen und neu laden:

nginx -t

systemctl reload nginx

WordPress 404 beheben

Bei WordPress entstehen 404-Fehler häufig durch fehlerhafte Permalinks.

Typische Anzeichen:

  • Startseite funktioniert

  • Unterseiten zeigen 404

  • Beiträge zeigen 404

  • Adminbereich funktioniert

Lösung:

  1. Melde dich im WordPress-Adminbereich an.

  2. Öffne Einstellungen.

  3. Öffne Permalinks.

  4. Klicke auf Änderungen speichern, ohne etwas zu ändern.

Dadurch werden die Rewrite-Regeln neu geschrieben.

Wenn das nicht hilft, prüfe die .htaccess und das Apache Rewrite-Modul.

CMS oder Framework prüfen

Wenn du ein CMS oder Framework nutzt, kann ein 404 auch aus der Anwendung selbst kommen.

Beispiele:

  • WordPress findet einen Beitrag nicht

  • Laravel findet keine Route

  • Symfony findet keinen Controller

  • Node.js Anwendung kennt den Pfad nicht

  • React/Vue Single Page App wird falsch ausgeliefert

Prüfe in diesem Fall:

  • sind die Routen korrekt?

  • wurde die Anwendung richtig gebaut?

  • zeigt der Webserver auf den richtigen public-Ordner?

  • sind Umleitungsregeln korrekt?

  • läuft der Backend-Dienst?

  • stimmen Umgebungsvariablen?

Bei Laravel muss der Webroot normalerweise auf den Ordner public zeigen, nicht auf das Hauptverzeichnis des Projekts.

Single Page Apps prüfen

Bei React, Vue oder ähnlichen Single Page Apps tritt häufig ein 404 auf, wenn eine Unterseite direkt aufgerufen wird.

Beispiel:

https://deinedomain.de/dashboard

Die Anwendung erwartet, dass der Webserver immer die index.html ausliefert und das Routing im Browser übernimmt.

Bei Nginx wird dafür oft benötigt:

try_files $uri /index.html;

Bei Apache wird dafür eine passende Rewrite-Regel in der .htaccess benötigt.

DNS prüfen

Ein 404 kann auch erscheinen, wenn deine Domain auf den falschen Server zeigt.

Das passiert zum Beispiel nach einem Serverwechsel oder einer neuen IP-Adresse.

Prüfe deshalb, ob die Domain auf die richtige IP-Adresse zeigt.

Beispiel:

deinedomain.de muss auf die IP-Adresse deines KVM-Servers zeigen.

Wenn die Domain noch auf einen alten Server zeigt, zeigt dieser möglicherweise eine fremde oder alte 404-Seite an.

DNS-Änderungen können einige Minuten bis mehrere Stunden dauern.

Cache prüfen

Manchmal wird ein alter 404-Fehler zwischengespeichert.

Prüfe:

  • Browsercache

  • CDN-Cache

  • WordPress-Cache

  • Proxy-Cache

  • Nginx-Cache

  • Cloudflare-Cache, falls verwendet

Teste die Seite in einem privaten Browserfenster oder auf einem anderen Gerät.

Logs prüfen

Logs zeigen oft genauer, warum eine Seite nicht gefunden wurde.

Apache Logs

Typische Pfade:

/var/log/apache2/error.log

/var/log/apache2/access.log

Live anzeigen:

tail -f /var/log/apache2/error.log

Nginx Logs

Typische Pfade:

/var/log/nginx/error.log

/var/log/nginx/access.log

Live anzeigen:

tail -f /var/log/nginx/error.log

Achte in den Logs auf den angefragten Pfad und den tatsächlichen Dateipfad.

Unterschied zwischen 404 und anderen Fehlern

Ein 404 bedeutet, dass die Seite nicht gefunden wurde.

Andere Fehler bedeuten etwas anderes:

Fehler
Bedeutung

403 Forbidden

Zugriff verboten

404 Not Found

Seite oder Datei nicht gefunden

500 Internal Server Error

interner Fehler in Anwendung oder Server

502 Bad Gateway

Upstream-Dienst antwortet nicht korrekt

503 Service Unavailable

Dienst nicht verfügbar

DNS-Fehler

Domain zeigt nicht korrekt auf den Server

Wenn du einen anderen Fehler siehst, solltest du den passenden Artikel zu diesem Fehler verwenden.

Checkliste

Prüfe bei einem 404-Fehler der Reihe nach:

  1. Ist die URL korrekt?

  2. Gibt es Tippfehler?

  3. Zeigt die Domain auf den richtigen Server?

  4. Liegt die Datei im richtigen Webverzeichnis?

  5. Gibt es eine index.html oder index.php?

  6. Stimmt der Webroot in Apache oder Nginx?

  7. Sind die Dateirechte korrekt?

  8. Funktioniert die .htaccess?

  9. Ist bei Apache mod_rewrite aktiv?

  10. Sind bei Nginx die try_files-Regeln korrekt?

  11. Sind WordPress-Permalinks neu gespeichert?

  12. Zeigt die Anwendung auf die richtige Route?

  13. Wurde ein Cache geleert?

  14. Was steht in den Webserver-Logs?

Support kontaktieren

Wenn du den 404-Fehler nicht selbst beheben kannst, kontaktiere den Support.

Gib bitte folgende Informationen an:

  • betroffene Domain

  • genaue URL, die den Fehler zeigt

  • verwendeter Webserver: Apache oder Nginx

  • verwendetes System: zum Beispiel WordPress, Laravel, React, eigenes Projekt

  • ob die Startseite funktioniert

  • ob nur Unterseiten betroffen sind

  • wann der Fehler erstmals aufgetreten ist

  • welche Änderungen zuletzt vorgenommen wurden

  • relevante Logauszüge, falls vorhanden

Sicherheit: Sende niemals Passwörter, private SSH-Keys, API-Tokens oder Datenbankzugänge an den Support.

Zuletzt aktualisiert