Slik fikser du 404-feil etter publisering av nettsiden eller appen

Hvis appen din fungerer lokalt, men sidene gir 404 etter publisering, er den vanligste årsaken manglende single-page-app-ruting (SPA). Serveren leter etter en fil som heter /dashboard, som ikke finnes, fordi ruten bare eksisterer i JavaScript. Løsningen er en fallback-regel som serverer index.html for app-ruter. Andre årsaker er filer som mangler i byggeresultatet, stier som skiller mellom store og små bokstaver, forskjeller i skråstrek på slutten, feil basis-sti, og API-ruter som aldri ble deployet.

Start med å notere nøyaktig hvilken URL som gir 404, og hvordan du kom dit. Mønsteret peker rett på årsaken.

Steg 1: Finn mønsteret

For å se den faktiske statuskoden, åpne utviklerverktøyene (høyreklikk → Inspiser), gå til fanen Nettverk, last siden på nytt og se statusen på den første forespørselen.

Steg 2: Legg til SPA-fallback

Dette er det klassiske tilfellet. I en React-, Vue- eller Svelte-app med én side har serveren bare noen få ekte filer: index.html og noen JavaScript- og CSS-filer. Ruter som /dashboard eller /projects/42 håndteres av en ruter i nettleseren.

• Å klikke på en lenke fungerer: ruteren endrer URL-en og tegner den nye siden uten å spørre serveren.
• Å oppdatere eller åpne en lenke direkte feiler: nettleseren spør serveren etter /dashboard, serveren har ingen slik fil, og svarer 404.

Løsningen er en regel som sier: hvis forespørselen ikke tilsvarer en ekte fil, server index.html med status 200, og la ruteren ta over. Hvordan du legger den til, avhenger av hosten (sjekk hostens oppdaterte dokumentasjon, fordi detaljene endrer seg):

Sørg for at regelen ikke sluker ekte filer: forespørsler til /assets/app.js må fortsatt returnere JavaScript-filen. Hvis de returnerer index.html i stedet, får du en tom side med feilen «Failed to load module script». Se hvordan du fikser en tom hvit side.

Gi også ruteren en fangrute (catch-all), slik at URL-er som ikke matcher noen side viser en vennlig «Siden finnes ikke» i stedet for ingenting.

Hvis du ikke kan endre serverinnstillinger, unngår hash-ruting (URL-er som /#/dashboard) problemet, fordi delen etter # aldri sendes til serveren. Det er en omvei, ikke et førstevalg: URL-ene er stygge og mindre vennlige for søkemotorer.

Rammeverk som rendrer sider på serveren eller genererer dem under bygging (Next.js, Astro og lignende) har vanligvis ekte filer eller serverruter for hver side, så dette problemet er mindre vanlig der. Tilsvarende problem der er en side som aldri ble generert under bygging.

Steg 3: Sjekk hva som faktisk ble deployet

Hvis alt gir 404, serverer ikke serveren sannsynligvis den bygde appen din.

• Riktig mappe. Hosten må publisere byggeresultatet (vanligvis dist for Vite, build for Create React App, out for en statisk Next.js-eksport), ikke prosjektroten.
• Bygget kjørte. Les deploy-loggen. Hvis bygget feilet, kan hosten ha deployet ingenting, eller en gammel versjon.
• index.html ligger på toppnivå i den publiserte mappen, ikke i en undermappe.
• Basis-stien stemmer. Hvis appen serveres fra eksempel.no/app/, må den bygges med den basen (Vites base, React Routers basename), ellers bommer alle ruter og ressurser.

Steg 4: Fiks manglende filer og feil stier

Når sider lastes, men ressurser gir 404:

• Store og små bokstaver. macOS og Windows behandler vanligvis Logo.png og logo.png som samme fil. De fleste Linux-servere gjør ikke det. Sørg for at hver referanse stemmer nøyaktig med filnavnet.
• Filer utenfor bygget. I Vite kopieres filer i public/ som de er og refereres fra roten (/logo.png). Filer som importeres i koden bundles. En fil et annet sted i prosjektet blir kanskje ikke deployet i det hele tatt.
• Relative stier. images/photo.jpg løses i forhold til gjeldende URL, så den feiler på /blog/post-1. Bruk /images/photo.jpg.
• Opplastede filer lagret på lokal disk. Hvis brukeropplastinger ble skrevet til serverens egen mappe, forsvinner de når en ny versjon deployes. Bruk ordentlig fillagring.

Steg 5: Håndter skråstreker på slutten konsekvent

/about og /about/ er ulike URL-er. Hostene er forskjellige på om de legger til eller fjerner skråstreken, og en uoverensstemmelse med lenkene eller ruteren din kan gi 404-feil eller omdirigeringsløkker. Velg én stil, la lenkene bruke den, og konfigurer hosten til å omdirigere den andre formen til den. Konsistens hjelper også søkemotorer, som ellers kan se to kopier av hver side.

Steg 6: Fiks API-ruter som gir 404

Hvis siden lastes, men fanen Nettverk viser at /api/...-forespørsler gir 404:

• Backenden er ikke deployet. En statisk host serverer bare filer; en backend må kjøre et sted.
• Stien rutes annerledes i produksjon. I utvikling kan en proxy ha sendt /api videre til en egen server. I produksjon trenger hosten en tilsvarende rewrite, eller frontenden må kalle API-ets reelle adresse.
• SPA-fallbacken fanget den. En API-forespørsel som returnerer index.html med status 200 betyr at fallback-regelen er for bred. Ekskluder /api/* fra den.

De publiserte appens forespørsler til /api/orders gir 404, men de fungerer i forhåndsvisningen. Sjekk hvordan /api rutes i forhåndsvisningen kontra den publiserte appen, og gjør at den publiserte frontenden når backenden på samme måte.

Steg 7: Omdiriger gamle URL-er

Hvis du har flyttet fra et annet nettsted eller strukturert om, vil gamle URL-er som folk og søkemotorer fortsatt bruker gi 404. Legg til en 301-omdirigering (permanent) fra hver gammel URL til den nye adressen. Ha en liste og test et utvalg etter lansering. Vår guide om å flytte et WordPress-nettsted dekker hvordan du lager den listen.

Steg 8: Sjekk domenet

Hvis appen fungerer på hostens adresse, men gir 404 på ditt eget domene, kan domenet peke på feil prosjekt, eller hosten har kanskje ikke koblet domenet til nettstedet ditt ennå. Sjekk DNS-postene og domeneinnstillingene hos hosten. Se hvordan du kobler til et eget domene.

Gjør den ekte 404-siden nyttig

Noen 404-feil er riktige: noen skrev en URL feil. Gjør siden hjelpsom:

• En kort melding og lenker til hjemmesiden og nøkkelseksjoner
• Et søkefelt, hvis nettstedet har søk
• Samme header og navigasjon som resten av nettstedet

Der oppsettet ditt tillater det, returner en ekte 404-status for sider som ikke finnes. En «ikke funnet»-melding returnert med status 200 er det søkemotorer kaller en myk 404, og den kan kaste bort crawl-tid og forvirre indekseringen.

Vanlige feil

• Å teste bare ved å klikke. Test alltid ved å lime dype URL-er inn i en ny fane og oppdatere.
• En fallback som fanger alt. Ressurser og API-ruter returnerer index.html, noe som gir tomme sider og forvirrende API-feil.
• Ulik bruk av store og små bokstaver som bare bryter på serveren.
• Å deploye kildemappen i stedet for byggeresultatet.
• Å endre URL-struktur uten omdirigeringer. Hver gammel lenke blir en 404.

404-feil i Mythex

I Mythex publiserer du fra arbeidsområdet, og statiske frontender deployes som statiske sider. Hvis en publisert side gir 404, gi agenten den nøyaktige URL-en, om det skjer ved oppdatering eller ved klikk, og hva fanen Nettverk viser, og be den sjekke rutingen. Publiser på nytt etter rettingen, fordi den levende appen er et øyeblikksbilde til du publiserer på nytt. Hvis du nylig endret prosjektet og den levende siden ser gammel ut, publiser på nytt og hard-oppdater. Bruk Fiks med AI i publiseringsdialogen hvis bygget feiler. Se Slik publiserer du og Feilsøking ved publisering i dokumentasjonen, og vår guide til feilsøking av en AI-bygd app.

Sjekkliste for 404

• Noterte nøyaktig hvilke URL-er som gir 404, og om det skjer ved klikk, oppdatering eller begge deler
• SPA-fallback serverer index.html for app-ruter, med status 200
• Fallback ekskluderer ekte filer og /api/*
• Ruteren har en fangrute for «ikke funnet»
• Byggemappen er det som publiseres, og bygget lyktes
• Basis-stien stemmer med der appen serveres
• Stor/liten-bokstaver i filnavn stemmer med hver referanse
• Ressursstier starter med /
• Stilen for skråstrek på slutten er konsekvent
• API-ruter er deployet og rutet i produksjon
• 301-omdirigeringer for gamle URL-er
• Dype lenker testet ved å lime dem inn i en ny fane

Spørsmål