Sådan retter du 404-fejl efter deployment af din hjemmeside eller app

Hvis din app virker lokalt, men sider giver 404 efter deployment, er den hyppigste årsag manglende single-page app-routing (SPA): serveren leder efter en fil ved navn /dashboard, der ikke findes, fordi ruten kun eksisterer i JavaScript. Løsningen er en fallback-regel, der serverer index.html for app-ruterne. Andre årsager er filer, der mangler i build-outputtet, stier med store og små bogstaver, forskelle i skråstreg til sidst, en forkert base-sti og API-ruter, der aldrig blev deployet.

Start med at notere præcis hvilken URL, der giver 404, og hvordan du kom dertil. Mønsteret peger direkte på årsagen.

Trin 1: Find mønsteret

For at se den faktiske statuskode, åbn udviklerværktøjerne (højreklik → Inspicér), gå til fanen Network, genindlæs, og se på statussen for den første forespørgsel.

Trin 2: Tilføj SPA-fallback

Dette er det klassiske. I en React-, Vue- eller Svelte-single-page app har serveren kun få rigtige filer: index.html og nogle JavaScript- og CSS-filer. Ruter som /dashboard eller /projects/42 håndteres af en router i browseren.

• Når du klikker på et link, virker det: routeren ændrer URL'en og tegner den nye side uden at spørge serveren.
• Når du opdaterer eller åbner et link direkte, fejler det: browseren beder serveren om /dashboard, serveren har ingen sådan fil, og den returnerer 404.

Løsningen er en regel, der siger: hvis forespørgslen ikke matcher en rigtig fil, så server index.html med status 200, og lad routeren tage over. Hvordan du tilføjer den, afhænger af hosten (tjek din hosts aktuelle dokumentation, da detaljerne ændrer sig):

Sørg for, at reglen ikke sluger rigtige filer: forespørgsler til /assets/app.js skal stadig returnere JavaScript-filen. Hvis de returnerer index.html i stedet, får du en tom side med fejlen "Failed to load module script". Se sådan retter du en blank hvid side.

Giv også routeren en catch-all-rute, så URL'er, der ikke matcher nogen side, viser en venlig "Siden blev ikke fundet" i stedet for ingenting.

Hvis du ikke kan ændre serverindstillinger, undgår hash-routing (URL'er som /#/dashboard) problemet, fordi delen efter # aldrig sendes til serveren. Det er en workaround, ikke et førstevalg: URL'erne er mindre pæne og mindre venlige for søgemaskiner.

Frameworks, der renderer sider på serveren eller genererer dem ved build-tid (Next.js, Astro og lignende), har typisk rigtige filer eller serverruter for hver side, så dette specifikke problem er mindre hyppigt der. Deres tilsvarende problem er en side, der aldrig blev genereret ved build-tid.

Trin 3: Tjek hvad der faktisk blev deployet

Hvis alt giver 404, serverer serveren sandsynligvis ikke din byggede app.

• Den rigtige mappe. Hosten skal publicere build-outputtet (typisk dist for Vite, build for Create React App, out for en statisk Next.js-eksport), ikke projektroden.
• Build'et kørte. Læs deploy-loggen. Hvis build'et fejlede, har hosten måske ikke deployet noget, eller en gammel version.
• index.html ligger på øverste niveau i den publicerede mappe, ikke i en undermappe.
• Base-stien passer. Hvis appen serveres fra example.com/app/, skal den bygges med den base (Vites base, React Routers basename), ellers misser alle ruter og aktiver.

Trin 4: Ret manglende filer og forkerte stier

Når sider indlæses, men aktiver giver 404:

• Store og små bogstaver. macOS og Windows behandler typisk Logo.png og logo.png som den samme fil. De fleste Linux-servere gør ikke. Gør hver reference identisk med det rigtige filnavn.
• Filer uden for build'et. I Vite kopieres filer i public/ uændret og refereres fra roden (/logo.png). Filer importeret i kode bliver bundtet. En fil et andet sted i projektet bliver muligvis slet ikke deployet.
• Relative stier. images/photo.jpg løses i forhold til den aktuelle URL, så den bryder på /blog/post-1. Brug /images/photo.jpg.
• Uploadede filer gemt på lokal disk. Hvis brugeres uploads blev skrevet til serverens egen mappe, forsvinder de, når en ny version deployes. Brug ordentlig filopbevaring.

Trin 5: Håndtér skråstreg til sidst konsekvent

/about og /about/ er forskellige URL'er. Hosts adskiller sig i, om de tilføjer eller fjerner skråstregen, og en uoverensstemmelse med dine links eller din router kan give 404 eller redirect-løkker. Vælg én stil, få dine links til at bruge den, og konfigurér hosten til at redirecte den anden form til den. Konsistens hjælper også søgemaskiner, der ellers kan se to kopier af hver side.

Trin 6: Ret API-ruter, der giver 404

Hvis siden indlæses, men Network-fanen viser /api/...-forespørgsler, der returnerer 404:

• Backend'en er ikke deployet. En statisk host serverer kun filer; en backend skal køre et sted.
• Stien routes forskelligt i produktion. I udvikling kan en proxy have sendt /api videre til en separat server. I produktion skal hosten have en tilsvarende rewrite, eller frontend'en skal kalde API'ens rigtige adresse.
• SPA-fallbacken fangede den. En API-forespørgsel, der returnerer index.html med status 200, betyder, at fallback-reglen er for bred. Udeluk /api/* fra den.

De publicerede appens forespørgsler til /api/orders returnerer 404, men de virker i preview. Tjek hvordan /api er routet i preview vs. den publicerede app, og gør så den publicerede frontend når backend'en på samme måde.

Trin 7: Redirect gamle URL'er

Hvis du er flyttet fra et andet site eller har omstruktureret, vil gamle URL'er, som folk og søgemaskiner stadig bruger, give 404. Tilføj en 301 (permanent) redirect fra hver gammel URL til dens nye placering. Hold en liste, og test en stikprøve efter lancering. Vores guide til migrering af et WordPress-site dækker, hvordan du bygger den liste.

Trin 8: Tjek domænet

Hvis appen virker på hostens adresse, men giver 404 på dit eget domæne, kan domænet pege på det forkerte projekt, eller hosten har muligvis ikke tilknyttet domænet til dit site endnu. Tjek DNS-posterne og hostens domæneindstillinger. Se sådan forbinder du et eget domæne.

Gør din rigtige 404-side brugbar

Nogle 404'er er korrekte: nogen har tastet en URL forkert. Gør siden hjælpsom:

• En kort besked og et link til forsiden og de vigtigste sektioner
• Et søgefelt, hvis siden har søgning
• Samme header og navigation som resten af siden

Hvor din opsætning tillader det, skal du returnere en rigtig 404-status for sider, der ikke findes. En "ikke fundet"-besked returneret med status 200 er det, søgemaskiner kalder en blød 404, og den kan spilde deres crawl-tid og forvirre indekseringen.

Almindelige fejl

• Kun at teste ved at klikke. Test altid ved at indsætte dybe URL'er i en ny fane og opdatere.
• En fallback, der fanger alt. Aktiver og API-ruter returnerer index.html, hvilket giver tomme sider og forvirrende API-fejl.
• Forkert brug af store og små bogstaver, der kun bryder på serveren.
• At deploye kildemappen i stedet for build-outputtet.
• At omstrukturere URL'er uden redirects. Hvert gammelt link bliver til en 404.

404'er i Mythex

I Mythex publicerer du fra workspacet, og statiske frontends deployes som statiske sites. Hvis en publiceret side giver 404, så giv agenten den præcise URL, om det sker ved opdatering eller ved klik, og hvad Network-fanen viser, og bed den tjekke routingen. Publicér igen efter rettelsen, for den live app er et øjebliksbillede, indtil du publicerer igen. Hvis du for nylig har ændret projektet, og det live site ser gammelt ud, så publicér igen og lav en hård opdatering. Brug Ret med AI i publiceringsdialogen, hvis build'et fejler. Se Sådan publicerer du og Fejlfinding ved publicering i dokumentationen, og vores guide til fejlfinding af en AI-bygget app.

404-tjekliste

• Noteret præcis hvilke URL'er der giver 404, og om det sker ved klik, opdatering eller begge dele
• SPA-fallback serverer index.html for app-ruter, med status 200
• Fallback udelader rigtige filer og /api/*
• Routeren har en catch-all "ikke fundet"-rute
• Build-outputmappen er det, der publiceres, og build'et lykkedes
• Base-stien passer til, hvor appen serveres
• Store og små bogstaver i filnavne matcher hver reference
• Aktivstier starter med /
• Konsistent stil for skråstreg til sidst
• API-ruter deployet og routet i produktion
• 301-redirects for gamle URL'er
• Dybe links testet ved at indsætte dem i en ny fane

Spørgsmål