Com arreglar els errors 404 després de publicar la teva web o app

Si la teva app funciona en local però les pàgines retornen 404 després de publicar, la causa més habitual és que falta l’encaminament d’una aplicació d’una sola pàgina (SPA): el servidor busca un fitxer anomenat /dashboard que no existeix, perquè aquesta ruta només existeix en JavaScript. L’arranjament és una regla de fallback que serveix index.html per a les rutes de l’app. Altres causes són fitxers que falten a la sortida de compilació, rutes sensibles a majúscules, diferències amb la barra final, una ruta base incorrecta i rutes d’API que mai no s’han desplegat.

Comença per anotar exactament quina URL dona 404 i com hi has arribat. El patró apunta directament a la causa.

Pas 1: troba el patró

Per veure el codi d’estat real, obre les eines de desenvolupador (clic dret → Inspecciona), ves a la pestanya Xarxa, refresca i mira l’estat de la primera petició.

Pas 2: afegeix el fallback SPA

Aquest és el clàssic. En una aplicació d’una sola pàgina en React, Vue o Svelte, el servidor només té uns quants fitxers reals: index.html i alguns fitxers JavaScript i CSS. Rutes com /dashboard o /projects/42 les gestiona un router al navegador.

• Fer clic en un enllaç funciona: el router canvia la URL i dibuixa la nova pàgina sense demanar-ho al servidor.
• Refrescar o obrir un enllaç directament falla: el navegador demana al servidor /dashboard, el servidor no té aquest fitxer i retorna 404.

L’arranjament és una regla que diu: si la petició no coincideix amb un fitxer real, serveix index.html amb estat 200 i deixa que el router prengui el control. Com ho afegeixes depèn de l’allotjament (consulta la documentació actual del teu allotjament, perquè els detalls canvien):

Assegura’t que la regla no s’engoleixi els fitxers reals: les peticions a /assets/app.js han de seguir retornant el fitxer JavaScript. Si retornen index.html, tindràs una pàgina en blanc amb l’error «Failed to load module script». Consulta com arreglar una pàgina en blanc.

També dona al router una ruta comodí perquè les URL que no coincideixen amb cap pàgina mostrin una pàgina «No s’ha trobat» amigable en lloc de no mostrar res.

Si no pots canviar la configuració del servidor, l’encaminament amb hash (URL com /#/dashboard) evita el problema, perquè la part després de # mai no s’envia al servidor. És un recurs alternatiu, no la primera opció: les URL són més lletges i menys amigables per als motors de cerca.

Els frameworks que renderitzen pàgines al servidor o les generen durant la compilació (Next.js, Astro i similars) normalment tenen fitxers reals o rutes de servidor per a cada pàgina, així que aquest problema concret és menys freqüent. El seu equivalent és una pàgina que no es va generar durant la compilació.

Pas 3: comprova què s’ha desplegat realment

Si tot dona 404, probablement el servidor no està servint la teva app compilada.

• La carpeta correcta. L’allotjament ha de publicar la sortida de compilació (habitualment dist per a Vite, build per a Create React App, out per a una exportació estàtica de Next.js), no l’arrel del projecte.
• La compilació s’ha executat. Llegeix el registre del desplegament. Si la compilació ha fallat, és possible que l’allotjament no hagi desplegat res, o que hagi desplegat una versió antiga.
• index.html és al nivell superior de la carpeta publicada, no en una subcarpeta.
• La ruta base coincideix. Si l’app es serveix des de exemple.com/app/, s’ha de compilar amb aquesta base (la base de Vite, el basename de React Router), o cada ruta i recurs fallarà.

Pas 4: arregla els fitxers que falten i les rutes incorrectes

Quan les pàgines es carreguen però els recursos donen 404:

• Sensibilitat a majúscules. macOS i Windows solen tractar Logo.png i logo.png com el mateix fitxer. La majoria de servidors Linux no. Fes que cada referència coincideixi exactament amb el nom real del fitxer.
• Fitxers fora de la compilació. A Vite, els fitxers de public/ es copien tal com són i es referencien des de l’arrel (/logo.png). Els fitxers importats al codi s’empaqueten. Un fitxer situat en un altre lloc del projecte pot no desplegar-se mai.
• Rutes relatives. images/photo.jpg es resol respecte a la URL actual, així que es trenca a /blog/post-1. Fes servir /images/photo.jpg.
• Fitxers pujats desats al disc local. Si les pujades dels usuaris s’han escrit a la carpeta del mateix servidor, desapareixen quan es desplega una nova versió. Fes servir un emmagatzematge de fitxers adequat.

Pas 5: gestiona les barres finals de manera coherent

/about i /about/ són URL diferents. Els allotjaments difereixen en si afegeixen o treuen la barra, i una discrepància amb els teus enllaços o amb el router pot produir 404 o bucles de redirecció. Tria un estil, fes que els enllaços l’utilitzin i configura l’allotjament perquè redirigeixi l’altra forma cap a aquesta. La coherència també ajuda els motors de cerca, que d’una altra manera poden veure dues còpies de cada pàgina.

Pas 6: arregla les rutes d’API que donen 404

Si la pàgina es carrega però la pestanya Xarxa mostra peticions a /api/... que retornen 404:

• El backend no està desplegat. Un allotjament estàtic només serveix fitxers; un backend ha de funcionar en algun lloc.
• La ruta és diferent en producció. En desenvolupament, un proxy pot haver reenviat /api a un servidor separat. En producció, l’allotjament necessita un rewrite equivalent, o el front end ha de cridar l’adreça real de l’API.
• El fallback SPA l’ha capturat. Una petició d’API que retorna index.html amb estat 200 vol dir que la regla de fallback és massa àmplia. Exclou /api/* de la regla.

Les peticions de l’app publicada a /api/orders donen 404, però funcionen a la vista prèvia. Comprova com es gestiona /api a la vista prèvia i a l’app publicada, i fes que el front end publicat arribi al backend de la mateixa manera.

Pas 7: redirigeix les URL antigues

Si t’has mudat des d’un altre lloc o has reestructurat el teu, les URL antigues que encara fan servir la gent i els motors de cerca donaran 404. Afegeix una redirecció 301 (permanent) de cada URL antiga a la seva nova ubicació. Mantén una llista i prova una mostra després del llançament. La nostra guia sobre com migrar un lloc de WordPress explica com construir aquesta llista.

Pas 8: comprova el domini

Si l’app funciona a l’adreça de l’allotjament però dona 404 al teu domini personalitzat, és possible que el domini apunti al projecte equivocat, o que l’allotjament encara no tingui el domini associat al teu lloc. Revisa els registres DNS i la configuració de domini de l’allotjament. Consulta com connectar un domini personalitzat.

Fes que la teva pàgina 404 real sigui útil

Alguns 404 són correctes: algú ha escrit malament una URL. Fes que aquesta pàgina sigui útil:

• Un missatge curt i un enllaç a la pàgina d’inici i a les seccions clau
• Un quadre de cerca, si el lloc en té
• La mateixa capçalera i navegació que la resta del lloc

Quan la configuració ho permet, retorna un estat 404 real per a les pàgines que no existeixen. Un missatge de «no trobat» retornat amb estat 200 és el que els motors de cerca anomenen soft 404, i pot malgastar el seu temps de rastreig i confondre la indexació.

Errors habituals

• Provar només fent clic. Prova sempre enganxant URL profundes en una pestanya nova i refrescant.
• Un fallback que ho captura tot. Els recursos i les rutes d’API retornen index.html, cosa que provoca pàgines en blanc i errors d’API confusos.
• Una majúscula o minúscula diferent que només falla al servidor.
• Desplegar la carpeta del codi font en lloc de la sortida de compilació.
• Reestructurar URL sense redireccions. Cada enllaç antic es converteix en un 404.

404 a Mythex

A Mythex publiques des de l’espai de treball, i els front ends estàtics es despleguen com a llocs estàtics. Si una pàgina publicada dona 404, dona a l’agent la URL exacta, indica si passa en refrescar o en fer clic, i què mostra la pestanya Xarxa, i demana que revisi l’encaminament. Torna a publicar després de l’arranjament, perquè l’app en directe és una instantània fins que la tornis a publicar. Si fa poc que has canviat el projecte i el lloc en directe sembla antic, publica de nou i fes un refresc forçat. Fes servir Arregla amb IA a la finestra de publicació si la compilació falla. Consulta Com publicar i Resolució de problemes de publicació a la documentació, i la nostra guia sobre com depurar una app construïda amb IA.

Llista de verificació de 404

• S’ha anotat exactament quines URL donen 404 i si és en fer clic, en refrescar o en els dos casos
• El fallback SPA serveix index.html per a les rutes de l’app, amb estat 200
• El fallback exclou els fitxers reals i /api/*
• El router té una ruta comodí de «no trobat»
• La carpeta de sortida de compilació és la que es publica, i la compilació ha funcionat
• La ruta base coincideix amb on es serveix l’app
• La majúscula o minúscula dels noms de fitxer coincideix amb cada referència
• Les rutes dels recursos comencen per /
• L’estil de barra final és coherent
• Les rutes d’API estan desplegades i encaminades en producció
• Redireccions 301 per a les URL antigues
• Enllaços profunds provats enganxant-los en una pestanya nova

Preguntes