So behebst du 404-Fehler nach dem Deployment deiner Website oder App

Wenn deine App lokal funktioniert, nach dem Deployment aber Seiten 404 liefern, ist die häufigste Ursache fehlendes Routing für Single-Page-Apps (SPA): Der Server sucht eine Datei namens /dashboard, die nicht existiert, weil diese Route nur in JavaScript vorhanden ist. Die Lösung ist eine Fallback-Regel, die für App-Routen index.html ausliefert. Weitere Ursachen sind fehlende Dateien im Build-Ergebnis, Groß- und Kleinschreibung bei Pfaden, Unterschiede bei Schrägstrichen am Ende, ein falscher Basispfad und API-Routen, die nie deployt wurden.

Notiere zuerst genau, welche URL einen 404 liefert und wie du dorthin gekommen bist. Das Muster verrät die Ursache.

Schritt 1: Das Muster finden

Um den echten Statuscode zu sehen, öffne die Entwicklertools (Rechtsklick → Untersuchen), wechsle zum Tab Netzwerk, lade neu und schau dir den Status der ersten Anfrage an.

Schritt 2: Den SPA-Fallback einrichten

Das ist der klassische Fall. In einer React-, Vue- oder Svelte-Single-Page-App hat der Server nur wenige echte Dateien: index.html und ein paar JavaScript- und CSS-Dateien. Routen wie /dashboard oder /projects/42 werden vom Router im Browser verarbeitet.

• Ein Klick auf einen Link funktioniert: Der Router ändert die URL und zeichnet die neue Seite, ohne den Server zu fragen.
• Neuladen oder ein direkter Aufruf scheitert: Der Browser fragt den Server nach /dashboard, der Server hat diese Datei nicht und antwortet mit 404.

Die Lösung ist eine Regel, die sagt: Wenn die Anfrage zu keiner echten Datei passt, liefere index.html mit Status 200 aus und überlasse dem Router das Weitere. Wie du das einrichtest, hängt vom Host ab (prüfe dessen aktuelle Doku, denn Details ändern sich):

Achte darauf, dass die Regel keine echten Dateien verschluckt: Anfragen nach /assets/app.js müssen weiterhin die JavaScript-Datei liefern. Liefern sie stattdessen index.html, siehst du eine leere Seite mit dem Fehler „Failed to load module script“. Siehe wie du eine weiße Seite behebst.

Gib dem Router außerdem eine Catch-all-Route, damit URLs ohne passende Seite eine freundliche Meldung „Seite nicht gefunden“ zeigen statt nichts.

Wenn du die Server-Einstellungen nicht ändern kannst, vermeidet Hash-Routing (URLs wie /#/dashboard) das Problem, weil der Teil nach # nie an den Server geschickt wird. Es ist ein Workaround, nicht die erste Wahl: Die URLs sind unschöner und für Suchmaschinen weniger freundlich.

Frameworks, die Seiten auf dem Server rendern oder beim Build erzeugen (Next.js, Astro und ähnliche), haben meist echte Dateien oder Server-Routen für jede Seite, daher tritt dieses Problem dort seltener auf. Ihr Gegenstück ist eine Seite, die beim Build nie erzeugt wurde.

Schritt 3: Prüfen, was tatsächlich deployt wurde

Wenn alles 404 liefert, serviert der Server vermutlich nicht deine gebaute App.

• Der richtige Ordner. Der Host muss das Build-Ergebnis ausliefern (üblich ist dist bei Vite, build bei Create React App, out bei einem statischen Next.js-Export), nicht das Projektverzeichnis.
• Der Build lief. Lies das Deploy-Log. Ist der Build fehlgeschlagen, hat der Host vielleicht nichts oder eine alte Version deployt.
• index.html liegt auf der obersten Ebene des veröffentlichten Ordners, nicht in einem Unterordner.
• Der Basispfad stimmt. Wird die App unter example.com/app/ ausgeliefert, muss sie mit diesem Basispfad gebaut werden (Vites base, basename von React Router), sonst verfehlen alle Routen und Assets ihr Ziel.

Schritt 4: Fehlende Dateien und falsche Pfade beheben

Wenn Seiten laden, aber Assets 404 liefern:

• Groß- und Kleinschreibung. macOS und Windows behandeln Logo.png und logo.png meist als dieselbe Datei. Die meisten Linux-Server nicht. Jede Referenz muss den echten Dateinamen exakt treffen.
• Dateien außerhalb des Builds. In Vite werden Dateien in public/ unverändert kopiert und über die Wurzel referenziert (/logo.png). Im Code importierte Dateien werden gebündelt. Eine Datei irgendwo sonst im Projekt wird unter Umständen gar nicht deployt.
• Relative Pfade. images/photo.jpg wird relativ zur aktuellen URL aufgelöst und bricht daher auf /blog/post-1. Verwende /images/photo.jpg.
• Hochgeladene Dateien auf der lokalen Festplatte gespeichert. Wenn Uploads im eigenen Ordner des Servers landeten, verschwinden sie bei jedem neuen Deployment. Nutze richtigen Dateispeicher.

Schritt 5: Schrägstriche am Ende konsistent behandeln

/about und /about/ sind unterschiedliche URLs. Hosts unterscheiden sich darin, ob sie den Schrägstrich ergänzen oder entfernen, und eine Abweichung zu deinen Links oder zu deinem Router kann 404-Fehler oder Weiterleitungsschleifen verursachen. Wähle eine Schreibweise, lass deine Links sie verwenden und konfiguriere den Host so, dass er die andere Form darauf umleitet. Das hilft auch Suchmaschinen, die sonst zwei Kopien jeder Seite sehen könnten.

Schritt 6: API-Routen beheben, die 404 liefern

Wenn die Seite lädt, der Tab Netzwerk aber /api/...-Anfragen mit 404 zeigt:

• Das Backend ist nicht deployt. Ein statischer Host liefert nur Dateien; ein Backend muss irgendwo laufen.
• Der Pfad wird in der Produktion anders geroutet. In der Entwicklung hat ein Proxy /api an einen separaten Server weitergeleitet. In der Produktion braucht der Host ein gleichwertiges Rewrite, oder das Frontend muss die echte Adresse der API ansprechen.
• Der SPA-Fallback hat es abgefangen. Gibt eine API-Anfrage index.html mit Status 200 zurück, ist die Fallback-Regel zu breit. Schließe /api/* davon aus.

Die veröffentlichte App liefert für /api/orders 404, obwohl es in der Vorschau funktioniert. Prüfe, wie /api in der Vorschau und in der veröffentlichten App geroutet wird, und sorge dafür, dass das veröffentlichte Frontend das Backend auf die gleiche Weise erreicht.

Schritt 7: Alte URLs umleiten

Wenn du von einer anderen Website umgezogen bist oder die Struktur verändert hast, liefern alte URLs, die Menschen und Suchmaschinen noch nutzen, einen 404. Richte von jeder alten URL eine 301-Weiterleitung (dauerhaft) auf ihr neues Ziel ein. Führe eine Liste und teste nach dem Launch eine Stichprobe. Unser Leitfaden zur Migration einer WordPress-Seite zeigt, wie du diese Liste aufbaust.

Schritt 8: Die Domain prüfen

Wenn die App unter der Adresse des Hosts funktioniert, auf deiner eigenen Domain aber 404 liefert, zeigt die Domain möglicherweise auf das falsche Projekt, oder der Host hat die Domain noch nicht an deine Website angehängt. Prüfe die DNS-Einträge und die Domain-Einstellungen des Hosts. Siehe wie du eine eigene Domain verbindest.

Eine hilfreiche 404-Seite gestalten

Manche 404-Fehler sind korrekt: Jemand hat eine URL falsch getippt. Mach diese Seite hilfreich:

• Eine kurze Meldung und Links zur Startseite und zu wichtigen Bereichen
• Ein Suchfeld, falls die Website eine Suche hat
• Derselbe Header und dieselbe Navigation wie im Rest der Website

Gib, wo deine Einrichtung es erlaubt, für nicht existierende Seiten einen echten 404-Statuscode zurück. Eine Meldung „nicht gefunden“ mit Status 200 ist ein sogenannter Soft-404; sie verschwendet die Crawl-Zeit der Suchmaschinen und kann die Indexierung verwirren.

Häufige Fehler

• Nur durch Klicken testen. Teste immer, indem du tiefe URLs in einen neuen Tab einfügst und neu lädst.
• Ein Fallback, der alles abfängt. Assets und API-Routen liefern index.html, was zu leeren Seiten und verwirrenden API-Fehlern führt.
• Abweichende Groß- und Kleinschreibung, die nur auf dem Server bricht.
• Den Quellordner deployen statt des Build-Ergebnisses.
• URLs umbauen, ohne Weiterleitungen. Jeder alte Link wird zu einem 404.

404-Fehler in Mythex

In Mythex veröffentlichst du aus dem Workspace, und statische Frontends werden als statische Seiten ausgeliefert. Wenn eine veröffentlichte Seite 404 liefert, nenne dem Agenten die genaue URL, ob es beim Neuladen oder beim Klicken passiert, und was der Tab Netzwerk zeigt, und bitte ihn, das Routing zu prüfen. Veröffentliche nach der Korrektur erneut, denn die Live-App ist ein Snapshot, bis du neu veröffentlichst. Wenn du das Projekt kürzlich geändert hast und die Live-Seite alt wirkt, veröffentliche erneut und lade hart neu. Nutze Mit KI beheben im Veröffentlichungsdialog, wenn der Build fehlschlägt. Siehe So veröffentlichst du und Fehlerbehebung bei der Veröffentlichung in der Dokumentation sowie unseren Leitfaden zum Debuggen einer KI-gebauten App.

Checkliste für 404-Fehler

• Genau notiert, welche URLs 404 liefern und ob beim Klicken, Neuladen oder bei beidem
• SPA-Fallback liefert index.html für App-Routen mit Status 200
• Der Fallback schließt echte Dateien und /api/* aus
• Der Router hat eine Catch-all-Route für „Nicht gefunden“
• Der Build-Ausgabeordner ist das, was veröffentlicht wird, und der Build war erfolgreich
• Der Basispfad passt zu dem Ort, an dem die App ausgeliefert wird
• Groß- und Kleinschreibung der Dateinamen stimmt mit jeder Referenz überein
• Asset-Pfade beginnen mit /
• Schreibweise der Schrägstriche am Ende ist konsistent
• API-Routen sind deployt und in der Produktion geroutet
• 301-Weiterleitungen für alte URLs
• Tiefe Links getestet, indem sie in einen neuen Tab eingefügt wurden

Fragen