Näin korjaat 404-virheet julkaisun jälkeen

Jos sovelluksesi toimii paikallisesti mutta sivut antavat 404:n julkaisun jälkeen, yleisin syy on puuttuva yhden sivun sovelluksen (SPA) reititys: palvelin etsii tiedostoa nimeltä /dashboard, jota ei ole, koska reitti on olemassa vain JavaScriptissä. Korjaus on varasääntö, joka palauttaa index.html-tiedoston sovelluksen reiteille. Muita syitä ovat build-tuloksesta puuttuvat tiedostot, kirjainkokoherkät polut, perässä olevan kauttaviivan erot, väärä base-polku ja API-reitit, joita ei koskaan julkaistu.

Aloita kirjaamalla ylös tarkalleen, mikä URL antaa 404:n ja miten pääsit sinne. Kuvio osoittaa suoraan syyhyn.

Vaihe 1: Tunnista kuvio

Nähdäksesi todellisen tilakoodin, avaa kehittäjätyökalut (oikea klikkaus → Tarkista), siirry Network-välilehdelle, päivitä sivu ja katso ensimmäisen pyynnön tila.

Vaihe 2: Lisää SPA-varasääntö

Tämä on klassinen. React-, Vue- tai Svelte-yhden sivun sovelluksessa palvelimella on vain muutama oikea tiedosto: index.html ja joitakin JavaScript- ja CSS-tiedostoja. Reitit kuten /dashboard tai /projects/42 hoitaa selaimessa oleva reititin.

• Linkin klikkaus toimii: reititin vaihtaa URL-osoitteen ja piirtää uuden sivun kysymättä palvelimelta.
• Päivitys tai suora linkki epäonnistuu: selain pyytää palvelimelta /dashboard, palvelimella ei ole sellaista tiedostoa, ja se palauttaa 404:n.

Korjaus on sääntö, joka sanoo: jos pyyntö ei vastaa oikeaa tiedostoa, palauta index.html tilalla 200 ja anna reitittimen hoitaa loput. Tapa riippuu hostista (tarkista hostin nykyinen dokumentaatio, koska yksityiskohdat muuttuvat):

Varmista, ettei sääntö nielaise oikeita tiedostoja: pyyntöjen /assets/app.js pitää yhä palauttaa JavaScript-tiedosto. Jos ne palauttavat index.html-tiedoston, saat tyhjän sivun ja virheen ”Failed to load module script”. Katso tyhjän valkoisen sivun korjaaminen.

Anna reitittimelle myös catch-all-reitti, jotta URL-osoitteet, jotka eivät vastaa mitään sivua, näyttävät ystävällisen ”Sivua ei löytynyt” -viestin eivätkä tyhjää sivua.

Jos et voi muuttaa palvelimen asetuksia, hash-reititys (URL-osoitteet kuten /#/dashboard) välttää ongelman, koska osaa #-merkin jälkeen ei lähetetä palvelimelle. Se on kiertotie, ei ensimmäinen valinta: URL-osoitteet ovat rumempia ja hakukoneystävällisyys heikompi.

Kehykset, jotka renderöivät sivut palvelimella tai generoivat ne buildissa (Next.js, Astro ja vastaavat), tarjoavat yleensä oikeat tiedostot tai palvelinreitit jokaiselle sivulle, joten tämä ongelma on niissä harvinaisempi. Niiden vastine on sivu, jota ei koskaan generoitu buildissa.

Vaihe 3: Tarkista, mitä julkaistiin

Jos kaikki antaa 404:n, palvelin ei todennäköisesti tarjoa rakennettua sovellustasi.

• Oikea kansio. Hostin pitää julkaista build-tulos (yleisesti dist Vitelle, build Create React Appille, out staattiselle Next.js-viennille), ei projektin juurta.
• Build ajoi. Lue julkaisun loki. Jos build epäonnistui, host ei ehkä julkaissut mitään tai julkaisi vanhan version.
• index.html on julkaistun kansion ylimmällä tasolla, ei alikansiossa.
• Base-polku täsmää. Jos sovellus on palvelussa kansiossa esimerkki.fi/app/, se pitää rakentaa siltä polulta (Viten base, React Routerin basename), tai jokainen reitti ja resurssi jää väliin.

Vaihe 4: Korjaa puuttuvat tiedostot ja väärät polut

Kun sivut latautuvat mutta resurssit antavat 404:n:

• Kirjainkoko. macOS ja Windows käsittelevät yleensä Logo.png ja logo.png samana tiedostona. Useimmat Linux-palvelimet eivät. Tee jokaisesta viittauksesta täsmälleen oikean tiedoston nimen mukainen.
• Tiedostot buildin ulkopuolella. Vitessä public/-kansion tiedostot kopioidaan sellaisenaan ja viitataan juuresta (/logo.png). Koodissa importatut tiedostot pakataan mukaan. Projektin muualla oleva tiedosto ei ehkä julkaistu lainkaan.
• Suhteelliset polut. images/photo.jpg ratkeaa nykyisen URL-osoitteen suhteen, joten se hajoaa sivulla /blog/post-1. Käytä /images/photo.jpg.
• Ladatut tiedostot tallennettu paikalliselle levylle. Jos käyttäjien lataukset kirjoitettiin palvelimen omaan kansioon, ne katoavat, kun uusi versio julkaistaan. Käytä kunnollista tiedostotallennusta.

Vaihe 5: Käsittele perässä olevat kauttaviivat johdonmukaisesti

/about ja /about/ ovat eri URL-osoitteita. Hostit eroavat siinä, lisäävätkö vai poistavatko ne kauttaviivan, ja ristiriita linkkiesi tai reitittimesi kanssa voi aiheuttaa 404:iä tai uudelleenohjaussilmukoita. Valitse yksi tyyli, tee linkeistäsi sen mukaisia ja määritä host ohjaamaan toinen muoto siihen. Johdonmukaisuus auttaa myös hakukoneita, jotka muuten voisivat nähdä jokaisesta sivusta kaksi kopiota.

Vaihe 6: Korjaa API-reitit, jotka antavat 404:n

Jos sivu latautuu, mutta Network-välilehti näyttää /api/...-pyyntöjen antavan 404:n:

• Takapäätä ei ole julkaistu. Staattinen host palvelee vain tiedostoja; takapään täytyy ajaa jossakin.
• Polku reititetään tuotannossa eri tavalla. Kehityksessä välityspalvelin on saattanut ohjata /api-pyynnöt erilliselle palvelimelle. Tuotannossa hostin pitää tarjota vastaava rewrite, tai käyttöliittymän täytyy kutsua API:n oikeaa osoitetta.
• SPA-varasääntö nappasi pyynnön. Jos API-pyyntö palauttaa index.html-tiedoston tilalla 200, varasääntö on liian laaja. Rajaa /api/* siitä pois.

Julkaistun sovelluksen pyynnöt osoitteeseen /api/orders antavat 404:n, vaikka ne toimivat esikatselussa. Tarkista, miten /api on reititetty esikatselussa ja julkaistussa sovelluksessa, ja tee julkaistusta käyttöliittymästä yhtä hyvin yhteydessä takapäähän.

Vaihe 7: Ohjaa vanhat URL-osoitteet uudelleen

Jos olet siirtynyt toiselta sivustolta tai rakentanut rakennetta uudelleen, vanhat URL-osoitteet, joita ihmiset ja hakukoneet yhä käyttävät, antavat 404:n. Lisää 301-uudelleenohjaus (pysyvä) jokaisesta vanhasta URL-osoitteesta uuteen kotiinsa. Pidä listaa ja testaa otos lanseerauksen jälkeen. Oppaamme WordPress-sivuston siirtämisestä kattaa tuon listan rakentamisen.

Vaihe 8: Tarkista domain

Jos sovellus toimii hostin omassa osoitteessa mutta antaa 404:n omalla domainillasi, domain voi osoittaa väärään projektiin tai host ei ehkä ole vielä liittänyt domainia sivullesi. Tarkista DNS-tietueet ja hostin domain-asetukset. Katso miten yhdistät oman domainin.

Tee oikeasta 404-sivustasi hyödyllinen

Jotkut 404:t ovat oikein: joku kirjoitti URL-osoitteen väärin. Tee tuosta sivusta hyödyllinen:

• Lyhyt viesti ja linkit etusivulle ja tärkeisiin osioihin
• Hakukenttä, jos sivustolla on haku
• Sama yläpalkki ja navigaatio kuin muulla sivustolla

Missä asetuksesi sallivat, palauta oikea 404-tila sivuille, joita ei ole. ”Ei löytynyt” -viesti, joka palautetaan tilalla 200, on sitä, mitä hakukoneet kutsuvat pehmeäksi 404:ksi. Se voi tuhlata niiden indeksointiaikaa ja sekoittaa indeksointia.

Yleisimmät virheet

• Testaat vain klikkaamalla. Testaa aina liittämällä syvät URL-osoitteet uuteen välilehteen ja päivittämällä.
• Varasääntö, joka nappaa kaiken. Tiedostot ja API-reitit palauttavat index.html-tiedoston, mikä aiheuttaa tyhjiä sivuja ja sekavia API-virheitä.
• Kirjainkoon erot, jotka hajoavat vain palvelimella.
• Lähdekansion julkaiseminen build-tuloksen sijaan.
• URL-osoitteiden uudelleenjärjestely ilman uudelleenohjauksia. Jokaisesta vanhasta linkistä tulee 404.

404-virheet Mythexissä

Mythexissa julkaiset työtilasta, ja staattiset käyttöliittymät julkaistaan staattisina sivustoina. Jos julkaistu sivu antaa 404:n, anna agentille tarkka URL, kerro tapahtuuko se päivityksessä vai klikatessa, ja mitä Network-välilehti näyttää, ja pyydä sitä tarkistamaan reititys. Julkaise uudelleen korjauksen jälkeen, koska live-sovellus on kuvaaja siitä, mitä julkaisit, kunnes julkaiset uudelleen. Jos muutit projektia äskettäin ja live-sivusto näyttää vanhalta, julkaise uudelleen ja tee kova päivitys. Käytä Korjaa tekoälyllä -toimintoa julkaisudialogissa, jos build epäonnistuu. Katso Näin julkaiset ja julkaisun vianmääritys dokumentaatiosta sekä oppaamme tekoälyllä rakennetun sovelluksen virheenkorjauksesta.

404-tarkistuslista

• Kirjattu ylös tarkat URL-osoitteet, jotka antavat 404:n, ja se, tapahtuuko se klikatessa, päivittäessä vai molemmissa
• SPA-varasääntö palauttaa index.html sovelluksen reiteille tilalla 200
• Varasääntö jättää oikeat tiedostot ja /api/* ulkopuolelle
• Reitittimessä on catch-all ”ei löytynyt” -reitti
• Build-tuloksen kansio on se, mikä julkaistaan, ja build onnistui
• Base-polku täsmää siihen, missä sovellus on palvelussa
• Tiedostonimien kirjainkoko täsmää jokaiseen viittaukseen
• Resurssipolut alkavat /:llä
• Perässä olevan kauttaviivan tyyli on johdonmukainen
• API-reitit on julkaistu ja reititetty tuotannossa
• 301-uudelleenohjaukset vanhoille URL-osoitteille
• Syvät linkit testattu liittämällä ne uuteen välilehteen

Kysymykset