Kā novērst 404 kļūdas pēc vietnes vai lietotnes izvietošanas

Ja tava lietotne darbojas lokāli, bet pēc izvietošanas lapas atgriež 404, visbiežākais iemesls ir trūkstoša vienas lapas lietotnes (SPA) maršrutēšana: serveris meklē failu ar nosaukumu /dashboard, kas neeksistē, jo šis maršruts pastāv tikai JavaScript. Risinājums ir atkāpes noteikums, kas sniedz index.html lietotnes maršrutiem. Citi iemesli ir faili, kas trūkst būves izvadē, reģistrjutīgi ceļi, atšķirības slīpsvītras galotnē, nepareizs bāzes ceļš un API maršruti, kas nekad netika izvietoti.

Sāc, pierakstot, kurš tieši URL dod 404 un kā tu tur nonāci. Raksturīgais modelis tieši norāda uz cēloni.

1. solis: atrodi modeli

Lai redzētu īsto statusa kodu, atver izstrādātāju rīkus (ar peles labo pogu → Inspect), dodies uz cilni Network, atsvaidzini lapu un apskati pirmā pieprasījuma statusu.

2. solis: pievieno SPA atkāpi

Šis ir klasiskais gadījums. React, Vue vai Svelte vienas lapas lietotnē serverim ir tikai neliels skaits īstu failu: index.html un daži JavaScript un CSS faili. Maršrutus, piemēram, /dashboard vai /projects/42, apstrādā maršrutētājs pārlūkā.

• Uz saites noklikšķinot viss darbojas: maršrutētājs maina URL un zīmē jauno lapu, neprasot serverim.
• Atsvaidzinot vai atverot saiti tieši neizdodas: pārlūks prasa serverim /dashboard, serverim tāda faila nav, un tas atgriež 404.

Risinājums ir noteikums, kas saka: ja pieprasījums neatbilst reālam failam, sniedz index.html ar statusu 200 un ļauj maršrutētājam pārņemt vadību. Kā to pievienot, ir atkarīgs no hostinga (pārbaudi sava hostinga aktuālo dokumentāciju, jo detaļas mainās):

Pārliecinies, ka noteikums neaprij īstos failus: pieprasījumiem uz /assets/app.js joprojām jāatgriež JavaScript fails. Ja tie atgriež index.html, dabūsi tukšu lapu ar kļūdu „Failed to load module script”. Skaties kā novērst tukšu baltu lapu.

Dod maršrutētājam arī visaptverošu maršrutu, lai URL, kas neatbilst nevienai lapai, parāda draudzīgu ziņojumu „Lapa nav atrasta”, nevis neko.

Ja nevari mainīt servera iestatījumus, hash maršrutēšana (URL kā /#/dashboard) novērš problēmu, jo daļa aiz # nekad netiek nosūtīta serverim. Tas ir risinājums, nevis pirmā izvēle: URL ir neglītāki un mazāk draudzīgi meklētājprogrammām.

Ietvari, kas lapas renderē serverī vai ģenerē būves laikā (Next.js, Astro un līdzīgi), parasti katrai lapai ir reāli faili vai servera maršruti, tāpēc šī konkrētā problēma tur ir retāka. To ekvivalents ir lapa, kas nekad netika ģenerēta būves laikā.

3. solis: pārbaudi, kas tika izvietots

Ja viss dod 404, serveris, visticamāk, nerāda tavu būvēto lietotni.

• Pareizā mape. Hostingam jāpublicē būves izvade (parasti dist Vite, build Create React App, out statiskam Next.js eksportam), nevis projekta sakne.
• Būve tika palaista. Izlasi izvietošanas žurnālu. Ja būve neizdevās, hostings var nebūt izvietojis neko vai vecu versiju.
• index.html ir publicētās mapes augšējā līmenī, nevis apakšmapē.
• Bāzes ceļš sakrīt. Ja lietotne tiek pasniegta no example.com/app/, tā jābūvē ar šo bāzi (Vite base, React Router basename), citādi katrs maršruts un resurss nepareizi.

4. solis: novērs trūkstošus failus un nepareizus ceļus

Kad lapas ielādējas, bet resursi dod 404:

• Reģistrjutība. macOS un Windows parasti uzskata Logo.png un logo.png par vienu un to pašu failu. Lielākajā daļā Linux serveru nē. Katrai atsaucei jāsakrīt ar reālā faila nosaukumu precīzi.
• Faili ārpus būves. Vite failus public/ kopē tādus, kādi tie ir, un atsaucas uz tiem no saknes (/logo.png). Kodā importētie faili tiek iekļauti kopā. Fails, kas atrodas citur projektā, var netikt izvietots vispār.
• Relatīvie ceļi. images/photo.jpg tiek atrisināts attiecībā pret pašreizējo URL, tāpēc tas salūst uz /blog/post-1. Lieto /images/photo.jpg.
• Augšupielādētie faili, kas saglabāti lokālajā diskā. Ja lietotāju augšupielādes tika rakstītas servera mapē, tās pazūd, kad izvietota jauna versija. Lieto pienācīgu failu krātuvi.

5. solis: apstrādā slīpsvītras galotnes konsekventi

/about un /about/ ir dažādi URL. Hostingi atšķiras pēc tā, vai pievieno vai noņem slīpsvītru, un neatbilstība ar tavām saitēm vai maršrutētāju var radīt 404 vai pārvirzīšanas cilpas. Izvēlies vienu stilu, padari saites to izmantojošas un konfigurē hostingu, lai otru formu pārvirzītu uz to. Konsekvence palīdz arī meklētājprogrammām, kas citādi var redzēt divas katras lapas kopijas.

6. solis: labo API maršrutus, kas dod 404

Ja lapa ielādējas, bet tīkla cilnē /api/... pieprasījumi atgriež 404:

• Backend nav izvietots. Statiskais hostings pasniedz tikai failus; backend jādarbina kaut kur citur.
• Ceļš citādi maršrutēts ražošanā. Izstrādes vidē starpniekserveris varēja pārsūtīt /api uz atsevišķu serveri. Ražošanā hostingam vajadzīga līdzvērtīga pārrakstīšana, vai frontendam jāsauc API reālā adrese.
• SPA atkāpe to notvēra. API pieprasījums, kas atgriež index.html ar statusu 200, nozīmē, ka atkāpes noteikums ir par plašu. Izslēdz /api/* no tā.

Publicētās lietotnes pieprasījumi uz /api/orders atgriež 404, bet priekšskatījumā tie darbojas. Pārbaudi, kā /api ir maršrutēts priekšskatījumā un publicētajā lietotnē, un padari publicēto frontendu sasniedzamu backend tādā pašā veidā.

7. solis: pārvirzi vecos URL

Ja esi pārcēlies no citas vietnes vai pārstrukturējis, vecie URL, ko cilvēki un meklētājprogrammas joprojām izmanto, dos 404. Pievieno 301 (pastāvīgu) pārvirzīšanu no katra vecā URL uz tā jauno vietu. Glabā sarakstu un pēc uzsākšanas pārbaudi paraugu. Kā pārcelt WordPress vietni aptver šā saraksta izveidi.

8. solis: pārbaudi domēnu

Ja lietotne darbojas hostinga adresē, bet dod 404 pielāgotajā domēnā, domēns var norādīt uz nepareizu projektu, vai hostingā domēns vēl nav pievienots tavai vietnei. Pārbaudi DNS ierakstus un hostinga domēna iestatījumus. Skaties kā pieslēgt pielāgotu domēnu.

Dari reālo 404 lapu noderīgu

Daži 404 ir pareizi: kāds ir nepareizi uzrakstījis URL. Padari šo lapu noderīgu:

• Īss ziņojums un saite uz sākumlapu un galvenajām sadaļām
• Meklēšanas lauks, ja vietnei ir meklēšana
• Tā pati galvene un navigācija kā pārējā vietnē

Kur iestatījumi to atļauj, atgriez īstu 404 statusu lapām, kas nepastāv. Ziņojums „nav atrasts”, kas atgriezts ar statusu 200, ir tā sauktā mīkstā 404, un tas var izšķiest meklētāju pārmeklēšanas laiku un sajaukt indeksāciju.

Biežākās kļūdas

• Testēt tikai klikšķinot. Vienmēr testē, ielīmējot dziļus URL jaunā cilnē un atsvaidzinot.
• Atkāpe, kas notver visu. Resursi un API maršruti atgriež index.html, kas izraisa tukšas lapas un mulsinošas API kļūdas.
• Nesakrītoša reģistra lietošana, kas salūst tikai serverī.
• Izvietot pirmkoda mapi, nevis būves izvadi.
• Pārstrukturēt URL bez pārvirzīšanām. Katra vecā saite kļūst par 404.

404 Mythex

Mythex tu publicē no darbvietas, un statiskie frontendi tiek izvietoti kā statiskas vietnes. Ja publicēta lapa dod 404, dod aģentam precīzu URL, pasaki, vai tas notiek atsvaidzinot vai uz klikšķa, ko rāda tīkla cilne, un lūdz pārbaudīt maršrutēšanu. Pēc labojuma publicē vēlreiz, jo dzīvā lietotne ir momentuzņēmums, līdz to publicē no jauna. Ja nesen mainīji projektu un dzīvā vietne izskatās vecāka, publicē vēlreiz un veic cieto atsvaidzināšanu. Ja būve neizdodas, izmanto publicēšanas dialoga Fix with AI. Skaties Kā publicēt un Publicēšanas problēmu novēršana dokumentācijā un mūsu ceļvedi kā labot ar AI veidotu lietotni.

404 kontrolsaraksts

• Pierakstīts, kuri URL dod 404 un vai klikšķinot, atsvaidzinot vai abos gadījumos
• SPA atkāpe sniedz index.html lietotnes maršrutiem ar statusu 200
• Atkāpe izslēdz reālos failus un /api/*
• Maršrutētājam ir visaptverošs maršruts „nav atrasts”
• Publicēta būves izvades mape, un būve bija veiksmīga
• Bāzes ceļš sakrīt ar vietu, kur lietotne tiek pasniegta
• Failu nosaukumu reģistrs sakrīt ar katru atsauci
• Resursu ceļi sākas ar /
• Slīpsvītras galotnes stils konsekvents
• API maršruti izvietoti un maršrutēti ražošanā
• 301 pārvirzīšanas vecajiem URL
• Dziļās saites pārbaudītas, ielīmējot tās jaunā cilnē

Jautājumi