Paano Ayusin ang 404 Errors Pagkatapos Mag-deploy ng Website o App

Kung gumagana ang app mo sa local pero nagbabalik ng 404 ang mga page pagkatapos mag-deploy, kadalasang dahilan ay kulang na single-page app (SPA) routing: hinahanap ng server ang file na tinatawag na /dashboard na wala naman, dahil umiiral lang ang route na iyon sa JavaScript. Ang ayos ay isang fallback rule na naghahain ng index.html para sa mga app route. Iba pang sanhi ang mga file na nawawala sa build output, case-sensitive na path, pagkakaiba sa trailing slash, maling base path, at mga API route na hindi kailanman na-deploy.

Simulan sa pagtala kung aling eksaktong URL ang nagbibigay ng 404 at paano ka nakarating doon. Ituturo ng pattern ang sanhi.

Hakbang 1: Hanapin ang pattern

Para makita ang totoong status code, buksan ang developer tools (right-click → Inspect), pumunta sa Network tab, mag-reload, at tingnan ang status ng unang request.

Hakbang 2: Idagdag ang SPA fallback

Ito ang klasikong kaso. Sa React, Vue o Svelte na single-page app, iilang totoong file lang ang meron ang server: index.html at ilang JavaScript at CSS. Ang mga route gaya ng /dashboard o /projects/42 ay hinahawakan ng router sa browser.

• Ang pag-click sa link ay gumagana: pinapalitan ng router ang URL at iginuguhit ang bagong page nang hindi tinatanong ang server.
• Ang pag-refresh o direktang pagbukas ng link ay pumapalya: hinihingi ng browser ang /dashboard sa server, walang ganoong file ang server, at nagbabalik ito ng 404.

Ang ayos ay isang rule na nagsasabing: kung ang request ay hindi tumutugma sa totoong file, ihain ang index.html na may status 200, at hayaang ang router ang humawak. Nakadepende kung paano ito idadagdag sa host (i-check ang kasalukuyang docs ng host, dahil nagbabago ang mga detalye):

Siguruhing hindi nilalamon ng rule ang mga totoong file: ang request para sa /assets/app.js ay dapat pa ring magbalik ng JavaScript file. Kung index.html ang ibinabalik nito, makakakuha ka ng blangkong page na may "Failed to load module script" error. Tingnan ang paano ayusin ang blangkong puting page.

Bigyan din ang router ng catch-all route para ang mga URL na hindi tumutugma sa anumang page ay magpakita ng magiliw na "Page not found" sa halip na wala.

Kung hindi mo mababago ang settings ng server, nakakaiwas sa problema ang hash routing (mga URL na tulad ng /#/dashboard), dahil hindi kailanman ipinapadala sa server ang bahaging nasa likod ng #. Workaround ito, hindi unang pagpipilian: mas pangit ang URL at mas hindi friendly sa search engines.

Ang mga framework na nagre-render ng page sa server o gumagawa ng page habang nagbi-build (Next.js, Astro, at katulad) ay kadalasang may totoong file o server route para sa bawat page, kaya mas bihira rito ang problemang ito. Ang katumbas nila ay page na hindi nabuo noong build.

Hakbang 3: Tingnan kung ano ang aktwal na na-deploy

Kung lahat ay nagbibigay ng 404, malamang hindi naghahain ang server ng built na app mo.

• Tamang folder. Dapat i-publish ng host ang build output (karaniwang dist para sa Vite, build para sa Create React App, out para sa static export ng Next.js), hindi ang root ng project.
• Tumakbo ang build. Basahin ang deploy log. Kung pumalpak ang build, maaaring walang na-deploy ang host, o lumang bersyon lang.
• Nasa top level ng published folder ang index.html, hindi sa sub-folder.
• Tumutugma ang base path. Kung nakahain ang app sa example.com/app/, dapat itong i-build gamit ang ganoong base (ang base ng Vite, ang basename ng React Router), o mawawala ang bawat route at asset.

Hakbang 4: Ayusin ang nawawalang file at maling path

Kapag naglo-load ang mga page pero 404 ang mga asset:

• Case sensitivity. Karaniwang itinuturing ng macOS at Windows na iisang file ang Logo.png at logo.png. Hindi ito ginagawa ng karamihan ng Linux server. Gawing eksaktong tugma ang bawat reference sa totoong pangalan ng file.
• Mga file sa labas ng build. Sa Vite, kinokopya nang diretso ang mga file sa public/ at tinatawag mula sa root (/logo.png). Kasama sa bundle ang mga file na in-import sa code. Maaaring hindi na-deploy ang file na nasa ibang lugar sa project.
• Relative na path. Ang images/photo.jpg ay inaayos batay sa kasalukuyang URL, kaya sumisira ito sa /blog/post-1. Gamitin ang /images/photo.jpg.
• Mga na-upload na file na naka-save sa local disk. Kung isinulat ang upload ng users sa sariling folder ng server, mawawala ang mga ito kapag may bagong bersyong na-deploy. Gumamit ng wastong file storage.

Hakbang 5: Pareho-parehong pangasiwaan ang trailing slash

Magkaibang URL ang /about at /about/. Nagkakaiba ang mga host kung dinadagdag o tinatanggal nila ang slash, at ang hindi pagtutugma sa mga link o sa router ay maaaring magdulot ng 404 o redirect loops. Pumili ng isang estilo, gawing ganoon ang mga link mo, at i-configure ang host na i-redirect ang kabilang anyo papunta roon. Nakakatulong din ito sa search engines, na kung hindi ay maaaring makakita ng dalawang kopya ng bawat page.

Hakbang 6: Ayusin ang mga API route na nagbibigay ng 404

Kung naglo-load ang page pero nagbabalik ng 404 ang mga request sa /api/... sa Network tab:

• Hindi naka-deploy ang backend. Naghahain lang ng file ang static host; kailangang tumakbo ang backend sa isang lugar.
• Iba ang routing sa production. Sa development, maaaring ipinasa ng proxy ang /api sa hiwalay na server. Sa production, kailangan ng host ng katumbas na rewrite, o dapat tawagin ng frontend ang totoong address ng API.
• Nahuli ito ng SPA fallback. Ang API request na nagbabalik ng index.html na may status 200 ay ibig sabihing masyadong malawak ang fallback rule. Ibukod ang /api/* dito.

Nagbabalik ng 404 ang mga request ng na-publish na app sa /api/orders, pero gumagana ang mga ito sa preview. Tingnan kung paano naka-route ang /api sa preview at sa na-publish na app, at gawing maabot ng na-publish na frontend ang backend sa parehong paraan.

Hakbang 7: I-redirect ang mga lumang URL

Kung lumipat ka mula sa ibang site o nag-restructure, mapupunta sa 404 ang mga lumang URL na ginagamit pa rin ng tao at search engines. Magdagdag ng 301 (permanent) redirect mula sa bawat lumang URL papunta sa bagong tirahan nito. Magtago ng listahan at subukan ang sample pagkatapos ng launch. Sakop ng gabay namin sa paglipat ng WordPress site ang pagbuo ng listahang iyon.

Hakbang 8: Suriin ang domain

Kung gumagana ang app sa address ng host pero nagbibigay ng 404 sa custom domain mo, maaaring nakaturo ang domain sa maling project, o hindi pa naidadagdag ng host ang domain sa site mo. I-check ang DNS records at ang domain settings ng host. Tingnan ang paano ikonekta ang custom domain.

Gawing kapaki-pakinabang ang totoong 404 page mo

Tama ang ilang 404: may nag-mistype ng URL. Gawing kapaki-pakinabang ang page na iyon:

• Maikling mensahe at link pabalik sa home page at sa mahahalagang seksyon
• Search box, kung may search ang site
• Parehong header at navigation gaya ng iba pang bahagi ng site

Kung pinapayagan ng setup mo, magbalik ng totoong 404 status para sa mga page na hindi umiiral. Ang "not found" na mensaheng ibinalik na may status 200 ay tinatawag ng search engines na soft 404, at maaari nitong sayangin ang crawl time nila at malituhan ang indexing.

Mga karaniwang pagkakamali

• Pagsubok sa pamamagitan lang ng pag-click. Laging subukan sa pamamagitan ng pag-paste ng malalalim na URL sa bagong tab at pag-refresh.
• Fallback na nahuhuli ang lahat. Ang mga asset at API route ay nagbabalik ng index.html, na nagdudulot ng blangkong page at nakakalitong API error.
• Magkaibang capitalization na sumisira lang sa server.
• Pag-deploy ng source folder sa halip na build output.
• Pag-restructure ng URL nang walang redirects. Nagiging 404 ang bawat lumang link.

404 sa Mythex

Sa Mythex, nag-p-publish ka mula sa workspace, at nade-deploy ang static front ends bilang static sites. Kung nagbibigay ng 404 ang na-publish na page, ibigay sa agent ang eksaktong URL, kung nangyayari ito sa pag-refresh o sa pag-click, at ang nakikita sa Network tab, at hilingin na suriin ang routing. Mag-publish muli pagkatapos ng ayos, dahil snapshot ang live app hanggang i-republish mo ito. Kung kamakailan mong binago ang project at luma pa ang live site, mag-publish muli at mag-hard-refresh. Gamitin ang Fix with AI sa publish dialog kung pumalpak ang build. Tingnan ang How to publish at Publish troubleshooting sa docs, at ang aming gabay sa pag-debug ng app na ginawa ng AI.

Checklist ng 404

• Naitala kung aling eksaktong URL ang nagbibigay ng 404 at kung sa pag-click, pag-refresh o pareho
• Naghahain ang SPA fallback ng index.html para sa mga app route, na may status 200
• Ibinubukod ng fallback ang mga totoong file at /api/*
• May catch-all na "not found" route ang router
• Ang build output folder ang naka-publish, at matagumpay ang build
• Tumutugma ang base path sa lugar kung saan nakahain ang app
• Tumutugma ang capitalization ng pangalan ng file sa bawat reference
• Nagsisimula sa / ang mga asset path
• Pare-pareho ang estilo ng trailing slash
• Naka-deploy at naka-route sa production ang mga API route
• May 301 redirects para sa mga lumang URL
• Nasubukan ang mga malalim na link sa pag-paste sa bagong tab

Mga tanong