Kako odpraviti napake 404 po objavi spletnega mesta ali aplikacije

Če vaša aplikacija deluje lokalno, strani pa po objavi vračajo 404, je najpogostejši vzrok manjkajoče usmerjanje za aplikacije z eno stranjo (SPA): strežnik išče datoteko /dashboard, ki ne obstaja, ker ta pot obstaja samo v JavaScriptu. Popravek je pravilo za rezervo, ki za poti aplikacije vrne index.html. Drugi vzroki so datoteke, ki manjkajo v izhodni mapi gradnje, poti z razlikami v velikosti črk, razlike pri končni poševnici, napačna osnovna pot in API poti, ki sploh niso bile objavljene.

Začnite tako, da zapišete točen URL, ki vrača 404, in kako ste nanj prišli. Vzorec neposredno kaže na vzrok.

1. korak: poiščite vzorec

Za pravo statusno kodo odprite orodja za razvijalce (desni klik → Preglej), pojdite na zavihek Omrežje, osvežite stran in preverite statusno kodo prve zahteve.

2. korak: dodajte rezervo za SPA

To je klasičen primer. V aplikaciji React, Vue ali Svelte z eno stranjo ima strežnik le nekaj pravih datotek: index.html in nekaj JavaScript in CSS datotek. Poti kot /dashboard ali /projects/42 obdeluje usmerjevalnik v brskalniku.

• Klik na povezavo deluje: usmerjevalnik spremeni URL in nariše novo stran brez vprašanja strežnika.
• Osvežitev ali neposredno odpiranje povezave ne uspe: brskalnik zahteva od strežnika /dashboard, strežnik nima take datoteke in vrne 404.

Popravek je pravilo, ki pravi: če zahteva ne ustreza pravi datoteki, vrnite index.html s statusom 200 in prepustite usmerjevalniku. Kako ga dodate, je odvisno od gostitelja (preverite trenutno dokumentacijo svojega gostitelja, ker se podrobnosti spreminjajo):

Poskrbite, da pravilo ne pogoltne pravih datotek: zahteve za /assets/app.js morajo še vedno vrniti datoteko JavaScript. Če vrnejo index.html, dobite prazno stran z napako »Failed to load module script«. Glejte kako odpraviti prazno belo stran.

Dajte usmerjevalniku tudi zajemno pot, da URL-ji, ki se ne ujemajo z nobeno stranjo, pokažejo prijazno sporočilo »Stran ni najdena« in ne nič.

Če ne morete spremeniti nastavitev strežnika, se težavi izognete z usmerjanjem z zgoščenko (URL-ji kot /#/dashboard), ker del za # nikoli ne gre na strežnik. Je rešitev, ne prva izbira: URL-ji so manj lepi in manj prijazni za iskalnike.

Ogrodja, ki strani prikazujejo na strežniku ali jih generirajo ob gradnji (Next.js, Astro in podobna), imajo običajno prave datoteke ali strežniške poti za vsako stran, zato je ta težava tam manj pogosta. Njihov ustreznik je stran, ki ni bila generirana ob gradnji.

3. korak: preverite, kaj je bilo dejansko objavljeno

Če vse vrača 404, strežnik verjetno ne streže vaše zgrajene aplikacije.

• Prava mapa. Gostitelj mora objaviti izhodno mapo gradnje (običajno dist za Vite, build za Create React App, out za statični izvoz Next.js), ne korenske mape projekta.
• Gradnja se je izvedla. Preberite dnevnik objave. Če gradnja ni uspela, gostitelj morda ni objavil ničesar ali je objavil staro različico.
• index.html je na najvišji ravni objavljene mape, ne v podmapi.
• Osnovna pot se ujema. Če je aplikacija streženja na example.com/app/, mora biti zgrajena s to osnovno potjo (base v Vite, basename v React Routerju), sicer vsaka pot in sredstvo zgrešita.

4. korak: odpravite manjkajoče datoteke in napačne poti

Ko se strani naložijo, sredstva pa vračajo 404:

• Občutljivost na velike in male črke. macOS in Windows običajno obravnavata Logo.png in logo.png kot isto datoteko. Večina strežnikov Linux ne. Vsaka referenca naj se natančno ujema z dejanskim imenom datoteke.
• Datoteke zunaj gradnje. V Vite se datoteke v public/ kopirajo nespremenjene in so navedene iz korena (/logo.png). Datoteke, uvožene v kodi, so vključene v paket. Datoteka, ki je drugje v projektu, morda sploh ni objavljena.
• Relativne poti. images/photo.jpg se razreši glede na trenutni URL, zato se pokvari na /blog/post-1. Uporabite /images/photo.jpg.
• Naložene datoteke, shranjene na lokalni disk. Če so bile nalaganja uporabnikov zapisana v mapo strežnika, izginejo, ko se objavi nova različica. Uporabite ustrezno shrambo datotek.

5. korak: dosledno obravnavajte končne poševnice

/about in /about/ sta različna URL-ja. Gostitelji se razlikujejo v tem, ali dodajo ali odstranijo poševnico, neujemanje s povezavami ali usmerjevalnikom pa lahko povzroči 404 ali zanke preusmeritev. Izberite en slog, naredite povezave v tej obliki in nastavite gostitelja, da drugo obliko preusmeri nanjo. Doslednost pomaga tudi iskalnikom, ki sicer lahko vidijo dve kopiji vsake strani.

6. korak: odpravite API poti, ki vračajo 404

Če se stran naloži, zavihek Omrežje pa kaže zahteve /api/..., ki vračajo 404:

• Zaledje ni objavljeno. Statični gostitelj streže le datoteke; zaledje mora teči nekje drugje.
• Pot je v produkciji usmerjena drugače. V razvoju je posrednik morda posredoval /api na ločen strežnik. V produkciji mora gostitelj imeti enakovredno prepisovanje ali mora frontend klicati pravi naslov API.
• Rezerva SPA jo je ujela. Če zahteva API vrne index.html s statusom 200, je pravilo za rezervo preširoko. Izključite /api/*.

Zahteve objavljene aplikacije na /api/orders vračajo 404, v predogledu pa delujejo. Preverite, kako je /api usmerjen v predogledu in v objavljeni aplikaciji, ter naredite, da objavljeni frontend doseže zaledje na enak način.

7. korak: preusmerite stare URL-je

Če ste se preselili z drugega mesta ali prestrukturirali, bodo stari URL-ji, ki jih ljudje in iskalniki še vedno uporabljajo, vračali 404. Dodajte trajno preusmeritev 301 z vsakega starega URL-ja na njegov novi naslov. Vodite seznam in po lansiranju preizkusite vzorec. Naš vodnik o selitvi spletnega mesta WordPress pokrije gradnjo tega seznama.

8. korak: preverite domeno

Če aplikacija deluje na naslovu gostitelja, na vaši domeni po meri pa vrača 404, domena morda kaže na napačen projekt ali je gostitelj še ni priključil na vašo spletno mesto. Preverite zapise DNS in nastavitve domene pri gostitelju. Glejte kako povezati domeno po meri.

Naredite pravo stran 404 koristno

Nekateri 404 so pravilni: nekdo se je zatipkal v URL. Naredite to stran koristno:

• Kratko sporočilo in povezavo na domačo stran ter ključne razdelke
• Iskalno polje, če ima spletno mesto iskanje
• Enaka glava in navigacija kot ostali del spletnega mesta

Tam, kjer to dovoljuje vaša nastavitev, za strani, ki ne obstajajo, vrnite pravo statusno kodo 404. Sporočilo »ni najdeno«, vrnjeno s statusom 200, je tisto, kar iskalniki imenujejo mehak 404, in lahko zapravlja njihov čas pregledovanja ter moti indeksiranje.

Pogoste napake

• Testiranje samo s klikanjem. Vedno preizkusite tako, da globoke URL-je prilepite v nov zavihek in osvežite.
• Rezerva, ki zajame vse. Sredstva in API poti vračajo index.html, kar povzroča prazne strani in zmedene napake API.
• Neujemanje velikih in malih črk, ki se pokaže samo na strežniku.
• Objava izvorne mape namesto izhodne mape gradnje.
• Prestrukturiranje URL-jev brez preusmeritev. Vsaka stara povezava postane 404.

404 v Mythex

V Mythex objavljate iz delovnega prostora, statični frontendi pa se namestijo kot statična mesta. Če objavljena stran vrne 404, agentu dajte točen URL, povejte, ali se to zgodi ob osveževanju ali ob kliku, in kaj kaže zavihek Omrežje, ter ga prosite, naj preveri usmerjanje. Po popravku ponovno objavite, ker je živa aplikacija posnetek, dokler je ne objavite znova. Če ste nedavno spremenili projekt in se živo mesto zdi staro, ponovno objavite in osvežite s trdim osveževanjem. Če gradnja ne uspe, uporabite Popravi z AI v pogovornem oknu za objavo. Glejte Kako objaviti in Odpravljanje težav pri objavi v dokumentaciji ter naš vodnik o odpravljanju napak v aplikaciji, zgrajeni z AI.

Kontrolni seznam za 404

• Zapisano, kateri URL-ji vračajo 404 in ali ob kliku, osveževanju ali obojem
• Rezerva SPA vrača index.html za poti aplikacije, s statusom 200
• Rezerva izključuje prave datoteke in /api/*
• Usmerjevalnik ima zajemno pot »ni najdeno«
• Objavljena je izhodna mapa gradnje in gradnja je uspela
• Osnovna pot se ujema z naslovom, kjer aplikacija streže
• Velikost črk v imenih datotek se ujema z vsako referenco
• Poti sredstev se začnejo s /
• Slog končne poševnice je dosleden
• API poti so objavljene in usmerjene v produkciji
• Preusmeritve 301 za stare URL-je
• Globoke povezave preizkušene tako, da so prilepljene v nov zavihek

Vprašanja