Ինչպես շտկել 404 սխալները կայքը կամ հավելվածը տեղակայելուց հետո

Եթե ձեր հավելվածը տեղում աշխատում է, բայց տեղակայումից հետո էջերը 404 են տալիս, ամենատարածված պատճառը մեկ էջի հավելվածի (SPA) երթուղավորման բացակայությունն է։ Սերվերը փնտրում է /dashboard անունով ֆայլ, որը գոյություն չունի, քանի որ այդ երթուղին գոյություն ունի միայն JavaScript-ում։ Շտկումը հետադարձման կանոնն է, որը ծառայում է index.html-ը հավելվածի երթուղիների համար։ Մյուս պատճառներն են build-ի արդյունքից բացակայող ֆայլերը, գործի զգայուն ուղիները, սլաշով վերջացող ու չվերջացող URL-երի տարբերությունը, սխալ base path-ը և API երթուղիներ, որոնք երբեք չեն տեղակայվել։

Սկսեք նշելով, թե հենց որ URL-ն է 404 տալիս և ինչպես եք հասել դրան։ Օրինաչափությունը ուղիղ ցույց է տալիս պատճառը։

Քայլ 1. Գտեք օրինաչափությունը

Իրական կարգավիճակի կոդը տեսնելու համար բացեք մշակողի գործիքները (աջ կտտոց → Inspect), գնացեք Network ներդիր, թարմացրեք և նայեք առաջին հարցման կարգավիճակը։

Քայլ 2. Ավելացրեք SPA հետադարձը

Սա դասական պատճառն է։ React, Vue կամ Svelte մեկ էջի հավելվածում սերվերն ունի միայն մի քանի իրական ֆայլ՝ index.html և մի քանի JavaScript ու CSS ֆայլեր։ /dashboard կամ /projects/42 նման երթուղիները մշակվում են բրաուզերում գտնվող երթուղիչի կողմից։

• Հղում սեղմելը աշխատում է․ երթուղիչը փոխում է URL-ը և ցուցադրում նոր էջը՝ առանց սերվերից հարցնելու։
• Թարմացնելը կամ ուղիղ հղումը չի աշխատում․ բրաուզերը սերվերից խնդրում է /dashboard, սերվերը այդպիսի ֆայլ չունի և վերադարձնում է 404։

Շտկումը կանոնն է, որ ասում է՝ եթե հարցումը չի համընկնում իրական ֆայլի հետ, ծառայիր index.html՝ 200 կարգավիճակով, և թող երթուղիչը վերցնի։ Ինչպես ավելացնել այն, կախված է հոսթից (ստուգեք հոսթի ընթացիկ փաստաթղթերը, քանի որ մանրամասները փոխվում են)․

Համոզվեք, որ կանոնը չի ծածկում իրական ֆայլերը․ /assets/app.js հարցումը պետք է դեռ վերադարձնի JavaScript ֆայլը։ Եթե այն վերադարձնում է index.html, կստանաք դատարկ էջ «Failed to load module script» սխալով։ Տես ինչպես շտկել սպիտակ դատարկ էջը։

Այս բանը նույնպես ապահովեք․ երթուղիչին տվեք catch-all երթուղի, որպեսզի այն URL-ները, որոնք որևէ էջի չեն համապատասխանում, ցույց տան բարյացակամ «Էջը չի գտնվել», այլ ոչ թե դատարկություն։

Եթե չեք կարող փոխել սերվերի կարգավորումները, hash երթուղավորումը (URL-եր, ինչպիսիք են /#/dashboard) խուսափում է խնդրից, քանի որ #-ից հետո եղած մասը երբեք չի ուղարկվում սերվեր։ Սա շրջանցում է, ոչ առաջին ընտրություն․ URL-երը ավելի վատ են և ավելի քիչ բարեկամական որոնման համակարգերի համար։

Երբ ֆրեյմվորքները էջերը սերվերի վրա են մատուցում կամ build ժամանակ են գեներացնում (Next.js, Astro և նման), սովորաբար յուրաքանչյուր էջի համար ունեն իրական ֆայլեր կամ սերվերային երթուղիներ, ուստի այս խնդիրը այնտեղ ավելի քիչ է հանդիպում։ Նրանց համարժեքը այն էջն է, որը երբեք չի գեներացվել build ժամանակ։

Քայլ 3. Ստուգեք, թե ինչ է իրականում տեղակայվել

Եթե ամեն ինչ 404 է, սերվերը հավանաբար չի սպասարկում ձեր build-ված հավելվածը։

• Ճիշտ թղթապանակ։ Հոսթը պետք է տեղակայի build-ի արդյունքը (սովորաբար dist Vite-ի համար, build Create React App-ի համար, out Next.js-ի ստատիկ արտահանման համար), ոչ թե նախագծի արմատը։
• Build-ը աշխատել է։ Կարդացեք տեղակայման մատյանը։ Եթե build-ը ձախողվել է, հոսթը կարող է ոչինչ չտեղակայել կամ հին տարբերակ տեղակայել։
• index.html-ը վերին մակարդակում է տեղակայված թղթապանակում, ոչ թե ենթաթղթապանակում։
• Base path-ը համընկնում է։ Եթե հավելվածը սպասարկվում է example.com/app/-ում, այն պետք է build-վի այդ base-ով (Vite-ի base, React Router-ի basename), հակառակ դեպքում յուրաքանչյուր երթուղի և ակտիվ կբաց թողնվի։

Քայլ 4. Շտկեք բացակայող ֆայլերը և սխալ ուղիները

Երբ էջերը բեռնվում են, բայց ակտիվները 404 են տալիս․

• Մեծատառերի զգայունություն։ macOS-ը և Windows-ը սովորաբար համարում են Logo.png-ը և logo.png-ը նույն ֆայլը։ Linux սերվերների մեծ մասը՝ ոչ։ Ամեն հղում պետք է ճշգրիտ համապատասխանի իրական ֆայլի անվանը։
• Build-ից դուրս ֆայլեր։ Vite-ում public/ թղթապանակի ֆայլերը պատճենվում են այնպես, ինչպես կան, և հղվում են արմատից (/logo.png)։ Կոդում ներմուծված ֆայլերը փաթեթավորվում են։ Նախագծի մեջ այլուր գտնվող ֆայլը կարող է ընդհանրապես չտեղակայվել։
• Հարաբերական ուղիներ։ images/photo.jpg-ը լուծվում է ընթացիկ URL-ի նկատմամբ, ուստի կոտրվում է /blog/post-1-ի վրա։ Օգտագործեք /images/photo.jpg։
• Վերբեռնված ֆայլեր, որոնք պահված են տեղական սկավառակի վրա։ Եթե օգտատերերի վերբեռնումները գրվել են սերվերի սեփական թղթապանակում, դրանք անհետանում են, երբ նոր տարբերակ է տեղակայվում։ Օգտագործեք պատշաճ ֆայլերի պահոց։

Քայլ 5. Միատեսակ վարվեք սլաշերի հետ

/about-ը և /about/-ը տարբեր URL-եր են։ Հոսթերը տարբերվում են նրանով, որ ավելացնում կամ հեռացնում են սլաշը, և անհամապատասխանությունը ձեր հղումների կամ երթուղիչի հետ կարող է առաջացնել 404 կամ վերահղման անվերջ ցիկլ։ Ընտրեք մեկ ոճ, դարձրեք ձեր հղումները դրան համապատասխան և կարգավորեք հոսթը՝ մյուս ձևը դրան վերահղելու համար։ Միատեսակությունը օգնում է նաև որոնման համակարգերին, որոնք հակառակ դեպքում յուրաքանչյուր էջը կարող են տեսնել երկու օրինակով։

Քայլ 6. Շտկեք 404 տվող API երթուղիները

Երբ էջը բեռնվում է, բայց Network ներդիրը ցույց է տալիս /api/... հարցումներ, որոնք 404 են վերադարձնում․

• Backend-ը տեղակայված չէ։ Ստատիկ հոսթը սպասարկում է միայն ֆայլեր․ backend-ը պետք է աշխատի ինչ-որ տեղ։
• Ուղին տարբեր է երթուղավորված արտադրության մեջ։ Մշակման ժամանակ պրոքսին կարող էր /api-ը ուղարկել առանձին սերվերին։ Արտադրության մեջ հոստին պետք է համարժեք rewrite, կամ ճակատը պետք է կանչի API-ի իրական հասցեն։
• SPA հետադարձը բռնել է այն։ API հարցում, որը վերադարձնում է index.html 200 կարգավիճակով, նշանակում է, որ հետադարձման կանոնը չափազանց լայն է։ Բացառեք /api/*-ը դրանից։

Հրապարակված հավելվածի /api/orders հարցումները 404 են տալիս, բայց նախադիտման մեջ աշխատում են։ Ստուգեք, թե ինչպես է /api-ն երթուղավորված նախադիտման և հրապարակված հավելվածի մեջ, և հրապարակված ճակատը նույն եղանակով հասցրեք backend-ին։

Քայլ 7. Վերահղեք հին URL-երը

Եթե տեղափոխվել եք այլ կայքից կամ վերակառուցել եք, հին URL-երը, որոնք մարդիկ և որոնման համակարգերը դեռ օգտագործում են, 404 կտան։ Յուրաքանչյուր հին URL-ից ավելացրեք 301 (մշտական) վերահղում դեպի նոր տեղը։ Պահեք ցուցակ և փորձարկեք նմուշը գործարկումից հետո։ Մեր ուղեցույցը WordPress կայքը տեղափոխելու մասին ցույց է տալիս այդ ցուցակի կառուցումը։

Քայլ 8. Ստուգեք դոմենը

Եթե հավելվածը աշխատում է հոսթի հասցեում, բայց 404 է տալիս ձեր սեփական դոմենում, դոմենը կարող է ցույց տալ սխալ նախագծի, կամ հոսթը դեռ կարող է չունենալ դոմենը ձեր կայքին միացված։ Ստուգեք DNS գրառումները և հոսթի դոմենի կարգավորումները։ Տես ինչպես միացնել սեփական դոմենը։

Դարձրեք ձեր իրական 404 էջը օգտակար

Որոշ 404-եր ճիշտ են․ մեկը սխալ է գրել URL-ը։ Այդ էջը օգտակար դարձրեք․

• Կարճ հաղորդագրություն և հղումներ դեպի գլխավոր էջ և հիմնական բաժիններ
• Որոնման դաշտ, եթե կայքն ունի որոնում
• Նույն վերնագիրը և նավիգացիան, ինչ մնացած կայքում

Որտեղ ձեր կարգավորումը թույլ է տալիս, գոյություն չունեցող էջերի համար վերադարձրեք իրական 404 կարգավիճակ։ «Չի գտնվել» հաղորդագրությունը, որը վերադարձվում է 200 կարգավիճակով, այն է, ինչ որոնման համակարգերը անվանում են soft 404, և այն կարող է վատնել նրանց սկանավորման ժամանակը և շփոթեցնել ինդեքսավորումը։

Սովորական սխալներ

• Միայն սեղմելով փորձարկելը։ Միշտ փորձարկեք՝ խորը URL-ները տեղադրելով նոր ներդիրում և թարմացնելով։
• Հետադարձ, որը բռնում է ամեն ինչ։ Ակտիվները և API երթուղիները վերադարձնում են index.html, ինչը առաջացնում է դատարկ էջեր և շփոթեցնող API սխալներ։
• Անհամապատասխան մեծատառեր, որոնք կոտրվում են միայն սերվերի վրա։
• Նախագծի սկզբնական թղթապանակը տեղակայելը build-ի արդյունքի փոխարեն։
• URL-երի վերակառուցում առանց վերահղումների։ Յուրաքանչյուր հին հղում դառնում է 404։

404-ները Mythex-ում

Mythex-ում տեղակայում եք աշխատանքային տարածքից, և ստատիկ ճակատները տեղակայվում են որպես ստատիկ կայքեր։ Եթե հրապարակված էջը 404 է տալիս, տվեք գործակալին ճշգրիտ URL-ը, ասեք՝ դա տեղի է ունենում թարմացումից, թե սեղմումից, և ինչ է ցույց տալիս Network ներդիրը, և խնդրեք ստուգել երթուղավորումը։ Շտկումից հետո կրկին հրապարակեք, քանի որ կենդանի հավելվածը մինչև նորից հրապարակելը ստատիկ պատկեր է։ Եթե վերջերս փոխել եք նախագիծը, և կենդանի կայքը հին է թվում, հրապարակեք կրկին և արեք կոշտ թարմացում։ Եթե build-ը ձախողվում է, օգտագործեք հրապարակման երկխոսության Fix with AI կոճակը։ Տես How to publish և Publish troubleshooting փաստաթղթերում, և մեր ուղեցույցը AI-ով կառուցված հավելվածի վրիպազերծման մասին։

404 ստուգաթերթ

• Նշված են այն URL-ները, որ 404 են տալիս, և արդյոք սեղմելիս, թարմացնելիս, թե երկուսում
• SPA հետադարձը ծառայում է index.html հավելվածի երթուղիների համար, 200 կարգավիճակով
• Հետադարձը բացառում է իրական ֆայլերը և /api/*-ը
• Երթուղիչն ունի catch-all «չի գտնվել» երթուղի
• Տեղակայվում է build-ի թղթապանակը, և build-ը հաջող է եղել
• Base path-ը համընկնում է այն վայրի հետ, որտեղ սպասարկվում է հավելվածը
• Ֆայլի անվան մեծատառերը համընկնում են յուրաքանչյուր հղման հետ
• Ակտիվների ուղիները սկսվում են /-ով
• Սլաշերի ոճը հետևողական է
• API երթուղիները տեղակայված և երթուղավորված են արտադրության մեջ
• Հին URL-երի համար 301 վերահղումներ
• Խորը հղումները փորձարկված են՝ տեղադրելով նոր ներդիրում

Հարցեր