Како да ги поправите грешките 404 откако ќе го објавите вашиот сајт или апликација

Ако вашата апликација работи локално, а страниците враќаат 404 по објавување, најчестата причина е недостасувачко SPA (single-page application) рутирање: серверот бара датотека наречена /dashboard што не постои, бидејќи таа рута постои само во JavaScript. Поправката е правило за резерва што ја служи index.html за рутите на апликацијата. Други причини се датотеки што недостасуваат во излезот од build-от, патеки со разлика во големи и мали букви, разлики во косата црта на крајот, погрешна основна патека и 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-от (вообичаено dist за Vite, build за Create React App, out за статичен Next.js export), а не коренот на проектот.
• Build-от се извршил. Прочитајте го логот од распоредот. Ако build-от не успеал, хостот можеби распоредил ништо или стара верзија.
• index.html е на врвното ниво на објавената папка, а не во под-папка.
• Основната патека се поклопува. Ако апликацијата се служи од example.com/app/, мора да се изгради со таа основа (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: Поправете API рути што даваат 404

Ако страницата се вчитува, но во табот Network се гледаат барања за /api/... со 404:

• Бекендот не е распореден. Статичниот хост служи само датотеки; бекендот мора да работи некаде.
• Патеката е рутирана поинаку во продукција. Во развој, прокси може да ги препраќаше барањата /api кон посебен сервер. Во продукција, хостот треба да има соодветен rewrite, или фронтенд-от мора да ја повика вистинската адреса на API-то.
• SPA резервата го фатила барањето. Барање кон API што враќа index.html со статус 200 значи дека правилото за резерва е премногу широко. Исклучете го /api/* од него.

Објавената апликација бара /api/orders и добива 404, а во прегледот работи. Проверете како е рутиран /api во прегледот наспроти објавената апликација, и направете објавениот фронтенд да стигне до бекендот на ист начин.

Чекор 7: Пренасочете ги старите URL-а

Ако сте се преселиле од друг сајт или сте ја преструктуирале структурата, старите URL-а што луѓето и пребарувачите сè уште ги користат ќе дадат 404. Додајте 301 (трајно) пренасочување од секој стар URL кон неговиот нов дом. Чувајте листа и тестирајте примерок по лансирањето. Нашиот водич за миграција на WordPress сајт ја покрива изработката на таа листа.

Чекор 8: Проверете го доменот

Ако апликацијата работи на адресата на хостот, но дава 404 на вашиот прилагоден домен, доменот можеби покажува кон погрешен проект, или хостот сè уште нема прикачено домен на вашиот сајт. Проверете ги DNS записите и поставките за домени на хостот. Видете како да поврзете прилагоден домен.

Направете ја вашата вистинска страница за 404 корисна

Некои 404 се точни: некој погрешно ја напишал адресата. Направете ја таа страница корисна:

• Кратка порака и линк до почетната страница и клучните делови
• Поле за пребарување, ако сајтот има пребарување
• Истата заглавка и навигација како и останатиот сајт

Каде што дозволува вашата поставка, вратете вистински статус 404 за страниците што не постојат. Порака „не е пронајдено“ вратена со статус 200 е она што пребарувачите го нарекуваат мек 404, и може да им го потроши времето за пребарување и да ја збуни индексацијата.

Чести грешки

• Тестирање само со клик. Секогаш тестирајте со залепување на длабоки URL-а во нов таб и освежување.
• Резерва што фаќа сè. Средствата и API рутите враќаат index.html, што предизвикува празни страници и збунувачки API грешки.
• Несовпаѓање на големи и мали букви што се расипува само на серверот.
• Распоредување на изворната папка наместо излезот од build-от.
• Преструктуирање на URL-а без пренасочувања. Секој стар линк станува 404.

404 во Mythex

Во Mythex објавувате од работниот простор, а статичните фронтенди се распоредуваат како статички сајтови. Ако објавена страница дава 404, дајте му на агентот точниот URL, дали се случува при освежување или при клик, и што покажува табот Network, и побарајте проверка на рутирањето. Објавете повторно по поправката, бидејќи живата апликација е снимка сè додека не објавите повторно. Ако неодамна сте менувале нешто во проектот а живиот сајт изгледа стар, објавете повторно и направете hard refresh. Користете Fix with AI во дијалогот за објавување ако build-от не успее. Видете Како да објавите и Решавање проблеми при објавување во документацијата, и нашиот водич за дебагирање на апликација изградена со AI.

Контролна листа за 404

• Забележано е точно кои URL-а даваат 404 и дали при клик, освежување или и двете
• SPA резервата служи index.html за рутите на апликацијата, со статус 200
• Резервата ги исклучува вистинските датотеки и /api/*
• Рутерот има catch-all рута „не е пронајдено“
• Излезната папка од build-от е онаа што се објавува, а build-от успеал
• Основната патека се поклопува со местото каде што се служи апликацијата
• Големината на буквите во имињата на датотеките се поклопува со секоја референца
• Патеките до средствата почнуваат со /
• Стилот на косата црта на крајот е конзистентен
• API рутите се распоредени и рутирани во продукција
• 301 пренасочувања за старите URL-а
• Длабоките линкови се тестирани со залепување во нов таб

Прашања