Si të rregulloni gabimet 404 pas publikimit të faqes ose aplikacionit tuaj

Nëse aplikacioni juaj funksionon lokalisht, por faqet japin 404 pas publikimit, shkaku më i zakonshëm është mungesa e rrugëzimit të aplikacionit me një faqe (SPA): serveri kërkon një skedar të quajtur /dashboard që nuk ekziston, sepse ajo rrugë ekziston vetëm në JavaScript. Zgjidhja është një rregull rezervë që shërben index.html për rrugët e aplikacionit. Shkaqe të tjera janë skedarët që mungojnë nga daljen e ndërtimit, shkronjat e mëdha/të vogla në rrugë, dallimet me shenjën e fundit /, një rrugë bazë e gabuar, dhe rrugët API që nuk u publikuan kurrë.

Filloni duke shënuar saktësisht cilën URL jep 404 dhe si arritët tek ajo. Modeli tregon drejt e shkakun.

Hapi 1: Gjeni modelin

Për të parë kodin real të statusit, hapni mjetet e zhvilluesit (klikoni me të djathtën → Inspect), shkoni te skeda Network, rifreskoni, dhe shikoni statusin e kërkesës së parë.

Hapi 2: Shtoni rezervën SPA

Ky është rasti klasik. Në një aplikacion me një faqe në React, Vue ose Svelte, serveri ka vetëm disa skedarë reale: index.html dhe disa JavaScript dhe CSS. Rrugë si /dashboard ose /projects/42 trajtohen nga një ruter në shfletues.

• Klikimi i një lidhjeje funksionon: ruteri ndryshon URL-në dhe vizaton faqen e re pa e pyetur serverin.
• Rifreskimi ose hapja e drejtpërdrejtë e një lidhjeje dështon: shfletuesi i kërkon serverit /dashboard, serveri nuk ka një skedar të tillë, dhe kthen 404.

Zgjidhja është një rregull që thotë: nëse kërkesa nuk përputhet me një skedar real, shërbe index.html me status 200, dhe lëre ruterin të marrë kontrollin. Si e shtoni varet nga hosti (kontrolloni dokumentacionin aktual, sepse detajet ndryshojnë):

Sigurohuni që rregulli nuk gllabëron skedarët reale: kërkesat për /assets/app.js duhet të kthejnë ende skedarin JavaScript. Nëse kthejnë index.html, do të merrni një faqe bosh me gabimin "Failed to load module script". Shihni si të rregulloni një faqe të bardhë bosh.

Gjithashtu i jepni ruterit një rrugë catch-all, që URL-të që nuk përputhen me asnjë faqe të shfaqin një "Faqja nuk u gjet" miqësore në vend të asgjëje.

Nëse nuk mund të ndryshoni cilësimet e serverit, rrugëzimi me hash (URL si /#/dashboard) e shmang problemin, sepse pjesa pas # nuk i dërgohet kurrë serverit. Është një zgjidhje e përkohshme, jo zgjedhja e parë: URL-të janë më të shëmtuara dhe më pak miqësore për motorët e kërkimit.

Kornizat që i prodhojnë faqet në server ose në kohën e ndërtimit (Next.js, Astro dhe të ngjashme) zakonisht kanë skedarë reale ose rrugë serveri për çdo faqe, prandaj ky problem është më i rrallë atje. Ekuivalenti i tyre është një faqe që nuk u gjenerua kurrë në kohën e ndërtimit.

Hapi 3: Kontrolloni çfarë u publikua vërtet

Nëse çdo gjë jep 404, serveri ndoshta nuk po shërben aplikacionin tuaj të ndërtuar.

• Dosja e duhur. Hosti duhet të publikojë daljen e ndërtimit (zakonisht dist për Vite, build për Create React App, out për një eksport statik Next.js), jo rrënjën e projektit.
• Ndërtimi u krye. Lexoni regjistrin e publikimit. Nëse ndërtimi dështoi, hosti mund të mos ketë publikuar asgjë, ose ka publikuar një version të vjetër.
• index.html është në nivelin e lartë të dosjes së publikuar, jo në një nën-dosje.
• Rruga bazë përputhet. Nëse aplikacioni shërbehet nga example.com/app/, duhet të ndërtohet me atë bazë (opsioni base i Vite, basename i React Router), ose çdo rrugë dhe çdo asset do të humbasë.

Hapi 4: Rregulloni skedarët që mungojnë dhe rrugët e gabuara

Kur faqet hapen, por asetet japin 404:

• Shkronjat e mëdha/të vogla. macOS dhe Windows zakonisht e trajtojnë Logo.png dhe logo.png si skedarin e njëjtë. Shumica e serverave Linux jo. Bëni që çdo referencë të përputhet saktësisht me emrin e skedarit real.
• Skedarët jashtë ndërtimit. Në Vite, skedarët në public/ kopjohen siç janë dhe referencohen nga rrënja (/logo.png). Skedarët e importuar në kod përfshihen në paketë. Një skedar që ndodhet diku tjetër në projekt mund të mos vendoset fare.
• Rrugët relative. images/photo.jpg zgjidhet relativisht me URL-në aktuale, prandaj prishet në /blog/post-1. Përdorni /images/photo.jpg.
• Skedarët e ngarkuar të ruajtur në disk lokal. Nëse ngarkimet e përdoruesve u shkruan në dosjen e serverit, ato zhduken kur publikohet një version i ri. Përdorni depozitim të duhur skedarësh.

Hapi 5: Trajtoni në mënyrë të qëndrueshme shenjën e fundit /

/about dhe /about/ janë URL të ndryshme. Hostet ndryshojnë në atë nëse shtojnë ose heqin shenjën e fundit, dhe një mospërputhje me lidhjet ose me ruterin tuaj mund të prodhojë 404 ose cikle ridrejtimi. Zgjidhni një stil, bëni që lidhjet tuaja ta përdorin, dhe konfiguroni hostin të ridrejtojë formën tjetër drejt tij. Qëndrueshmëria ndihmon edhe motorët e kërkimit, të cilët ndryshe mund të shohin dy kopje të secilës faqe.

Hapi 6: Rregulloni rrugët API që japin 404

Nëse faqja hapet, por në skedën Network shihen kërkesa /api/... që kthejnë 404:

• Back end-i nuk është publikuar. Një host statik shërben vetëm skedarë; një back end duhet të ekzekutohet diku.
• Rruga është e ndryshme në prodhim. Në zhvillim, një proxy mund ta ketë përcjellë /api te një server tjetër. Në prodhim, hosti ka nevojë për një rewrite ekuivalent, ose front end-i duhet të thërrasë adresën reale të API-t.
• Rezerva SPA e kapi. Një kërkesë API që kthen index.html me status 200 do të thotë se rregulli i rezervës është shumë i gjerë. Përjashtoni /api/* nga ai.

Kërkesat e aplikacionit të publikuar te /api/orders kthejnë 404, por funksionojnë në pamjen paraprake. Kontrollo si rrugëzohet /api në pamjen paraprake krahasuar me aplikacionin e publikuar, dhe bëj që front end-i i publikuar ta arrijë back end-in në të njëjtën mënyrë.

Hapi 7: Ridrejtoni URL-të e vjetra

Nëse keni kaluar nga një faqe tjetër ose e keni riorganizuar, URL-të e vjetra që njerëzit dhe motorët e kërkimit ende i përdorin do të japin 404. Shtoni një ridrejtim 301 (të përhershëm) nga çdo URL e vjetër te vendndodhja e re. Mbajeni një listë dhe testoni një mostër pas lançimit. Udhëzuesi ynë për migrimin e një faqeje WordPress mbulon ndërtimin e kësaj liste.

Hapi 8: Kontrolloni domain-in

Nëse aplikacioni funksionon te adresa e hostit, por jep 404 te domain-i juaj i personalizuar, domain-i mund të tregojë te projekti i gabuar, ose hosti mund të mos e ketë ende të lidhur domain-in me sajtin tuaj. Kontrolloni regjistrimet DNS dhe cilësimet e domain-it te hosti. Shihni si të lidhni një domain të personalizuar.

Bëjeni faqen tuaj reale 404 të dobishme

Disa 404 janë të sakta: dikush shkroi gabim një URL. Bëjeni atë faqe të dobishme:

• Një mesazh i shkurtër dhe lidhje për në faqen kryesore dhe seksionet kryesore
• Një kutizë kërkimi, nëse sajti ka kërkim
• E njëjta kokë dhe navigim si pjesa tjetër e sajtit

Aty ku e lejon konfigurimi juaj, kthejeni një status 404 të vërtetë për faqet që nuk ekzistojnë. Një mesazh "nuk u gjet" i kthyer me status 200 është ajo që motorët e kërkimit e quajnë soft 404, dhe mund të harxhojë kohën e tyre të crawl-it dhe të ngatërrojë indeksimin.

Gabimet e zakonshme

• Testimi vetëm me klikime. Testoni gjithmonë duke ngjitur URL të thella në një skedë të re dhe duke rifreskuar.
• Një rezervë që kap çdo gjë. Asetet dhe rrugët API kthejnë index.html, gjë që shkakton faqe boshe dhe gabime API të ngatërruese.
• Shkronja të mëdha/të vogla të papërputhura që prishen vetëm në server.
• Publikimi i dosjes burim në vend të daljes së ndërtimit.
• Riorganizimi i URL-ve pa ridrejtime. Çdo lidhje e vjetër bëhet 404.

404 në Mythex

Në Mythex publikoni nga hapësira e punës, dhe front end-et statike vendosen si sajte statike. Nëse një faqe e publikuar jep 404, jepini agjentit URL-në e saktë, nëse ndodh me rifreskim ose me klikim, dhe çfarë shfaq skeda Network, dhe kërkojini ta kontrollojë rrugëzimin. Publikoni përsëri pas rregullimit, sepse aplikacioni aktiv është një fotografi deri sa ta publikoni përsëri. Nëse keni ndryshuar kohët e fundit projektin dhe sajti aktiv duket i vjetër, publikoni përsëri dhe bëni rifreskim të fortë. Përdorni Fix with AI te dialogu i publikimit nëse ndërtimi dështon. Shihni Si të publikoni dhe Zgjidhja e problemeve të publikimit në dokumentacion, dhe udhëzuesin tonë për si të diagnostikoni një aplikacion të ndërtuar me AI.

Lista e kontrollit për 404

• U shënuan saktësisht URL-të që japin 404 dhe nëse ndodh me klikim, rifreskim ose të dyja
• Rezerva SPA shërben index.html për rrugët e aplikacionit, me status 200
• Rezerva përjashton skedarët reale dhe /api/*
• Ruteri ka një rrugë catch-all "nuk u gjet"
• Dosja e daljes së ndërtimit është ajo që publikohet, dhe ndërtimi u krye
• Rruga bazë përputhet me vendin ku shërbehet aplikacioni
• Shkronjat e mëdha/të vogla në emrat e skedarëve përputhen me çdo referencë
• Rrugët e asseteve fillojnë me /
• Stili i shenjës së fundit / është i qëndrueshëm
• Rrugët API janë publikuar dhe rrugëzohen në prodhim
• Ridrejtime 301 për URL-të e vjetra
• Lidhjet e thella u testuan duke i ngjitur në një skedë të re

Pyetje