Så åtgärdar du 404-fel efter att du deployat din webbplats eller app

Om din app fungerar lokalt men sidor ger 404 efter deploy är den vanligaste orsaken att SPA-routingen (single-page app) saknas: servern letar efter en fil som heter /dashboard som inte finns, eftersom rutten bara existerar i JavaScript. Lösningen är en fallback-regel som serverar index.html för appens rutter. Andra orsaker är filer som saknas i byggresultatet, sökvägar som är skiftlägeskänsliga, skillnader i avslutande snedstreck, fel base path och API-rutter som aldrig deployades.

Börja med att notera exakt vilken URL som ger 404 och hur du kom dit. Mönstret pekar direkt på orsaken.

Steg 1: Hitta mönstret

För att se den riktiga statuskoden, öppna utvecklarverktygen (högerklicka → Inspektera), gå till fliken Nätverk, ladda om och titta på statusen för första begäran.

Steg 2: Lägg till SPA-fallback

Det här är det klassiska fallet. I en React-, Vue- eller Svelte-app med en sida har servern bara ett fåtal riktiga filer: index.html och några JavaScript- och CSS-filer. Rutter som /dashboard eller /projects/42 hanteras av en router i webbläsaren.

• Att klicka på en länk fungerar: routern ändrar URL:en och ritar den nya sidan utan att fråga servern.
• Att uppdatera eller öppna en länk direkt misslyckas: webbläsaren frågar servern efter /dashboard, servern har ingen sådan fil och returnerar 404.

Lösningen är en regel som säger: om begäran inte matchar en riktig fil, servera index.html med status 200 och låt routern ta över. Hur du lägger till den beror på hosten (kontrollera din hostings aktuella dokumentation, eftersom detaljerna ändras):

Se till att regeln inte sväljer riktiga filer: begäran om /assets/app.js ska fortfarande returnera JavaScript-filen. Om den returnerar index.html i stället får du en vit sida med felet ”Failed to load module script”. Se så åtgärdar du en vit sida.

Ge också routern en catch-all-rutt så att URL:er som inte matchar någon sida visar en vänlig ”Sidan hittades inte” i stället för ingenting.

Om du inte kan ändra serverinställningar undviker hash-routing (URL:er som /#/dashboard) problemet, eftersom delen efter # aldrig skickas till servern. Det är en lösning, inte första valet: URL:erna är fulare och svårare för sökmotorer.

Ramverk som renderar sidor på servern eller genererar dem vid byggtid (Next.js, Astro och liknande) har oftast riktiga filer eller serverrutter för varje sida, så detta specifika problem är mindre vanligt där. Motsvarigheten är en sida som aldrig genererades vid byggtid.

Steg 3: Kontrollera vad som faktiskt deployades

Om allt ger 404 serverar troligen inte servern din byggda app.

• Rätt mapp. Hosten måste publicera byggresultatet (vanligtvis dist för Vite, build för Create React App, out för en statisk Next.js-export), inte projektets rotmapp.
• Bygget kördes. Läs deploy-loggen. Om bygget misslyckades kan hosten ha deployat ingenting, eller en gammal version.
• index.html ligger på toppnivå i den publicerade mappen, inte i en undermapp.
• Base path stämmer. Om appen serveras från example.com/app/ måste den byggas med den basen (Vites base, React Routers basename), annars missar varje rutt och tillgång.

Steg 4: Åtgärda saknade filer och fel sökvägar

När sidorna laddas men tillgångar ger 404:

• Skiftlägeskänslighet. macOS och Windows behandlar oftast Logo.png och logo.png som samma fil. De flesta Linux-servrar gör inte det. Gör så att varje referens matchar det riktiga filnamnet exakt.
• Filer utanför bygget. I Vite kopieras filer i public/ oförändrade och refereras från roten (/logo.png). Filer som importeras i koden paketeras. En fil som ligger någon annanstans i projektet kanske aldrig deployas.
• Relativa sökvägar. images/photo.jpg löses relativt den aktuella URL:en, så den går sönder på /blog/post-1. Använd /images/photo.jpg.
• Uppladdade filer sparade på lokal disk. Om användarnas uppladdningar skrevs till serverns egen mapp försvinner de när en ny version deployas. Använd riktig filhosting.

Steg 5: Hantera avslutande snedstreck konsekvent

/about och /about/ är olika URL:er. Hostar skiljer sig åt i om de lägger till eller tar bort snedstrecket, och en felmatchning mot dina länkar eller din router kan ge 404 eller redirect-loopar. Välj en stil, låt dina länkar använda den och konfigurera hosten att omdirigera den andra formen till den. Konsekvens hjälper också sökmotorer, som annars kan se två kopior av varje sida.

Steg 6: Åtgärda API-rutter som ger 404

Om sidan laddas men nätverksfliken visar /api/...-begäranden som returnerar 404:

• Backenden är inte deployad. En statisk värd serverar bara filer; en backend måste köras någon annanstans.
• Sökvägen routas annorlunda i produktion. I utveckling kan en proxy ha skickat /api till en separat server. I produktion behöver hosten en motsvarande rewrite, eller så måste frontend anropa API:ts riktiga adress.
• SPA-fallbacken fångade anropet. Ett API-anrop som returnerar index.html med status 200 betyder att fallback-regeln är för bred. Undanta /api/* från den.

Den publicerade appens anrop till /api/orders ger 404, men de fungerar i förhandsvisningen. Kontrollera hur /api routas i förhandsvisningen kontra den publicerade appen, och gör så att den publicerade frontend når backenden på samma sätt.

Steg 7: Omdirigera gamla URL:er

Om du flyttat från en annan webbplats eller omstrukturerat, kommer gamla URL:er som människor och sökmotorer fortfarande använder att ge 404. Lägg till en 301-redirect (permanent) från varje gammal URL till dess nya plats. För en lista och testa ett urval efter lansering. Vår guide om att migrera en WordPress-webbplats täcker hur du bygger den listan.

Steg 8: Kontrollera domänen

Om appen fungerar på hostens adress men ger 404 på din egen domän, kan domänen peka på fel projekt, eller så kanske hosten inte har kopplat domänen till din sida ännu. Kontrollera DNS-posterna och hostens domäninställningar. Se så kopplar du en egen domän.

Gör din riktiga 404-sida användbar

En del 404:or är korrekta: någon skrev fel URL. Gör då sidan hjälpsam:

• Ett kort meddelande och länkar till startsidan och de viktigaste avsnitten
• En sökruta, om sajten har sök
• Samma sidhuvud och navigering som resten av sajten

Där din uppsättning tillåter det, returnera en riktig 404-status för sidor som inte finns. Ett ”hittades inte”-meddelande som returneras med status 200 är vad sökmotorer kallar en mjuk 404, och det kan slösa deras crawlertid och förvirra indexeringen.

Vanliga misstag

• Att bara testa genom att klicka. Testa alltid genom att klistra in djupa URL:er i en ny flik och uppdatera.
• En fallback som fångar allt. Tillgångar och API-rutter returnerar index.html, vilket ger vita sidor och förvirrande API-fel.
• Felaktiga versaler och gemener som bara går sönder på servern.
• Att deploya källmappen i stället för byggresultatet.
• Att strukturera om URL:er utan redirects. Varje gammal länk blir en 404.

404 i Mythex

I Mythex publicerar du från arbetsytan, och statiska frontends deployas som statiska sajter. Om en publicerad sida ger 404, ge agenten den exakta URL:en, om det sker vid uppdatering eller vid klick, och vad nätverksfliken visar, och be den kontrollera routingen. Publicera igen efter åtgärden, eftersom den live-publicerade appen är en ögonblicksbild tills du publicerar på nytt. Om du nyligen ändrat projektet och den live-sajten ser gammal ut, publicera igen och gör en hård uppdatering. Använd Fix with AI i publiceringsdialogen om bygget misslyckas. Se Så publicerar du och Felsökning av publicering i dokumentationen, och vår guide om felsökning av en AI-byggd app.

Checklista för 404

• Noterat exakt vilka URL:er som ger 404 och om det sker vid klick, uppdatering eller båda
• SPA-fallback serverar index.html för appens rutter, med status 200
• Fallbacken undantar riktiga filer och /api/*
• Routern har en catch-all-rutt för ”hittades inte”
• Byggresultatets mapp är den som publiceras, och bygget lyckades
• Base path stämmer med där appen serveras
• Filnamnens versaler och gemener stämmer med varje referens
• Sökvägar till tillgångar börjar med /
• Stilen för avslutande snedstreck är konsekvent
• API-rutter är deployade och routade i produktion
• 301-redirects för gamla URL:er
• Djupa länkar testade genom att klistra in dem i en ny flik

Frågor