Cómo arreglar errores 404 tras publicar tu web o app

Si tu app funciona en local pero las páginas devuelven 404 tras publicarla, la causa más habitual es que falta el enrutamiento de aplicación de una sola página (SPA): el servidor busca un archivo llamado /dashboard que no existe, porque esa ruta solo existe en JavaScript. La solución es una regla de respaldo que sirva index.html para las rutas de la app. Otras causas son archivos que faltan en la salida de compilación, rutas sensibles a mayúsculas, diferencias en las barras finales, una ruta base incorrecta y rutas de API que nunca se desplegaron.

Empieza por anotar exactamente qué URL da 404 y cómo llegaste a ella. El patrón apunta directamente a la causa.

Paso 1: identifica el patrón

Lo que ves	Causa más probable	Ve a
La página de inicio funciona; los enlaces funcionan; al recargar o al abrir un enlace directo da 404	No hay fallback SPA	Paso 2
Todas las páginas dan 404, incluida la de inicio	Se publica la carpeta equivocada, o la compilación no se desplegó	Paso 3
Las páginas cargan, pero imágenes, fuentes o scripts dan 404	Archivos que faltan en la compilación, o rutas incorrectas	Paso 4
Funciona con `/about/`, falla con `/about` (o al revés)	Gestión de la barra final	Paso 5
`/About` falla pero `/about` funciona	Servidor sensible a mayúsculas	Paso 4
La página carga, pero las peticiones de datos a `/api/...` dan 404	La API no está desplegada o no tiene ruta	Paso 6
Las URL antiguas de un sitio anterior dan 404	Faltan redirecciones	Paso 7
Solo en un dominio propio	Configuración de DNS o del dominio	Paso 8

Para ver el código de estado real, abre las herramientas para desarrolladores (clic derecho → Inspeccionar), ve a la pestaña Red (Network), recarga y mira el estado de la primera petición.

Paso 2: añade el fallback SPA

Este es el caso clásico. En una aplicación de una sola página con React, Vue o Svelte, el servidor solo tiene unos pocos archivos reales: index.html y algunos archivos JavaScript y CSS. Rutas como /dashboard o /projects/42 las gestiona un router en el navegador.

Hacer clic en un enlace funciona: el router cambia la URL y dibuja la nueva página sin pedírsela al servidor.
Recargar o abrir un enlace directamente falla: el navegador pide al servidor /dashboard, el servidor no tiene ese archivo y devuelve 404.

La solución es una regla que diga: si la petición no coincide con un archivo real, sirve index.html con estado 200 y deja que el router tome el control. Cómo lo añades depende del hosting (consulta la documentación actual, porque los detalles cambian):

Hosting	Regla de fallback habitual
Netlify	Un archivo `_redirects` en la carpeta publicada con `/* /index.html 200`
Vercel	Una reescritura en `vercel.json` desde todas las rutas hacia `/index.html` (los presets de framework suelen encargarse de esto)
Cloudflare Pages	Sirve un fallback de estilo SPA por defecto cuando no hay un `404.html` en la raíz
Nginx	`try_files $uri $uri/ /index.html;` en el bloque `location /`
Apache	Una regla de reescritura en `.htaccess` que envía las peticiones que no son archivos a `index.html`
GitHub Pages	No tiene reescrituras en el servidor; los parches habituales son el enrutamiento por hash o un `404.html` que redirige

Asegúrate de que la regla no se trague los archivos reales: las peticiones a /assets/app.js deben seguir devolviendo el archivo JavaScript. Si devuelven index.html, obtienes una página en blanco con un error «Failed to load module script». Consulta cómo arreglar una página en blanco.

Dale también al router una ruta comodín para que las URL que no coinciden con ninguna página muestren una página amable de «Página no encontrada» en lugar de nada.

Si no puedes cambiar la configuración del servidor, el enrutamiento por hash (URL como /#/dashboard) evita el problema, porque la parte posterior a # nunca se envía al servidor. Es un parche, no la primera opción: las URL son menos bonitas y menos amigables para los buscadores.

Los frameworks que generan las páginas en el servidor o en la compilación (Next.js, Astro y similares) suelen tener archivos reales o rutas de servidor para cada página, así que este problema concreto es menos habitual en ellos. Su equivalente es una página que nunca se generó en la compilación.

Paso 3: comprueba qué se desplegó realmente

Si todo da 404, lo más probable es que el servidor no esté sirviendo tu app compilada.

La carpeta correcta. El hosting debe publicar la salida de compilación (normalmente dist para Vite, build para Create React App, out para una exportación estática de Next.js), no la raíz del proyecto.
La compilación se ejecutó. Lee el registro del despliegue. Si la compilación falló, el hosting puede no haber desplegado nada, o una versión antigua.
index.html está en el nivel superior de la carpeta publicada, no en una subcarpeta.
La ruta base coincide. Si la app se sirve desde ejemplo.com/app/, debe compilarse con esa base (base de Vite, basename de React Router), o todas las rutas y recursos fallarán.

Paso 4: arregla los archivos que faltan y las rutas incorrectas

Cuando las páginas cargan pero los recursos dan 404:

Distinción entre mayúsculas y minúsculas. macOS y Windows suelen tratar Logo.png y logo.png como el mismo archivo. La mayoría de servidores Linux no. Haz que cada referencia coincida exactamente con el nombre real del archivo.
Archivos fuera de la compilación. En Vite, los archivos de public/ se copian tal cual y se referencian desde la raíz (/logo.png). Los archivos importados en el código se empaquetan. Un archivo que esté en otro lugar del proyecto puede que no se despliegue nunca.
Rutas relativas. images/photo.jpg se resuelve respecto a la URL actual, así que se rompe en /blog/post-1. Usa /images/photo.jpg.
Archivos subidos guardados en el disco local. Si las subidas de los usuarios se escribieron en la carpeta del propio servidor, desaparecen cuando se despliega una nueva versión. Usa un almacenamiento de archivos adecuado.

Paso 5: gestiona las barras finales de forma coherente

/about y /about/ son URL distintas. Los hostings difieren en si añaden o quitan la barra final, y una discrepancia con tus enlaces o con tu router puede producir 404 o bucles de redirección. Elige un estilo, haz que tus enlaces lo usen y configura el hosting para redirigir la otra forma hacia él. La coherencia también ayuda a los buscadores, que de otro modo pueden ver dos copias de cada página.

Paso 6: arregla las rutas de API que dan 404

Si la página carga pero en la pestaña Red aparecen peticiones a /api/... que devuelven 404:

El backend no está desplegado. Un hosting estático solo sirve archivos; un backend debe ejecutarse en algún sitio.
La ruta se enruta de forma distinta en producción. En desarrollo, un proxy puede haber reenviado /api a un servidor separado. En producción, el hosting necesita una reescritura equivalente, o el frontend debe llamar a la dirección real de la API.
El fallback SPA la capturó. Una petición a la API que devuelve index.html con estado 200 significa que la regla de fallback es demasiado amplia. Excluye /api/* de ella.

Las peticiones de la app publicada a /api/orders devuelven 404, pero funcionan en la vista previa. Revisa cómo se enruta /api en la vista previa frente a la app publicada, y haz que el frontend publicado llegue al backend de la misma forma.

Paso 7: redirige las URL antiguas

Si has cambiado de otro sitio o has reestructurado el tuyo, las URL antiguas que la gente y los buscadores siguen usando darán 404. Añade una redirección 301 (permanente) desde cada URL antigua a su nueva ubicación. Mantén una lista y prueba una muestra después del lanzamiento. Nuestra guía sobre migrar un sitio de WordPress explica cómo crear esa lista.

Paso 8: revisa el dominio

Si la app funciona en la dirección del hosting pero da 404 en tu dominio propio, puede que el dominio apunte al proyecto equivocado, o que el hosting todavía no tenga el dominio asociado a tu sitio. Revisa los registros DNS y la configuración de dominios del hosting. Consulta cómo conectar un dominio propio.

Haz útil tu página 404 real

Algunos 404 son correctos: alguien escribió mal una URL. Haz que esa página sea útil:

Un mensaje breve y un enlace a la página de inicio y a las secciones clave
Un cuadro de búsqueda, si el sitio tiene buscador
El mismo encabezado y la misma navegación que el resto del sitio

Cuando tu configuración lo permita, devuelve un estado 404 real para las páginas que no existen. Un mensaje de «no encontrado» devuelto con estado 200 es lo que los buscadores llaman soft 404, y puede desperdiciar su tiempo de rastreo y confundir la indexación.

Errores habituales

Probar solo haciendo clic. Prueba siempre pegando URL profundas en una pestaña nueva y recargando.
Un fallback que lo captura todo. Los recursos y las rutas de API devuelven index.html, lo que provoca páginas en blanco y errores de API confusos.
Mayúsculas y minúsculas incoherentes que solo fallan en el servidor.
Desplegar la carpeta de código fuente en lugar de la salida de compilación.
Reestructurar URL sin redirecciones. Cada enlace antiguo se convierte en un 404.

Los 404 en Mythex

En Mythex publicas desde el espacio de trabajo, y los frontends estáticos se despliegan como sitios estáticos. Si una página publicada da 404, indica al agente la URL exacta, si ocurre al hacer clic o al recargar, y lo que muestra la pestaña Red, y pídele que revise el enrutamiento. Vuelve a publicar después de la corrección, porque la app en vivo es una instantánea hasta que la vuelves a publicar. Si cambiaste el proyecto hace poco y la web en vivo parece antigua, vuelve a publicar y recarga forzando la caché. Usa Arreglar con IA en el diálogo de publicación si la compilación falla. Consulta Cómo publicar y Solución de problemas de publicación en la documentación, y nuestra guía sobre cómo depurar una app creada con IA.

Lista de comprobación de los 404

Anotadas las URL exactas que dan 404 y si ocurre al hacer clic, al recargar o en ambos casos
El fallback SPA sirve index.html para las rutas de la app, con estado 200
El fallback excluye los archivos reales y /api/*
El router tiene una ruta comodín de «no encontrado»
La carpeta de salida de compilación es la que se publica, y la compilación se completó
La ruta base coincide con el lugar donde se sirve la app
Las mayúsculas y minúsculas de los nombres de archivo coinciden en todas las referencias
Las rutas de recursos empiezan por /
Estilo de barra final coherente
Rutas de API desplegadas y enrutadas en producción
Redirecciones 301 para las URL antiguas
Enlaces profundos probados pegándolos en una pestaña nueva

Preguntas

¿Por qué me sale un 404 al recargar una página en mi app de React?

En una aplicación de una sola página, rutas como /dashboard existen solo dentro de JavaScript. Al hacer clic en un enlace funciona porque el router lo gestiona en el navegador, pero al recargar el servidor busca un archivo /dashboard que no existe. La solución es una regla de respaldo que sirva index.html para las rutas de la app.

¿Cómo añado un fallback SPA en Netlify, Vercel o Nginx?

En Netlify, añade un archivo _redirects con /* /index.html 200. En Vercel, añade una reescritura en vercel.json que envíe todas las rutas a /index.html. En Nginx, usa try_files $uri $uri/ /index.html; en el bloque location. Consulta la documentación de tu hosting, porque las reglas cambian.

¿Por qué mis imágenes o archivos dan 404 tras publicar?

Normalmente el archivo no está en la salida de compilación, la ruta no coincide en mayúsculas y minúsculas (los servidores suelen distinguirlas aunque tu portátil no lo haga), o la ruta es relativa cuando debería empezar por una barra.

¿Una página que no existe debe devolver un estado 404 real?

Sí. Muestra una página de no encontrado útil, pero con estado 404 cuando tu configuración lo permita. Los buscadores tratan un mensaje de «no encontrado» devuelto con estado 200 como un soft 404, lo que desperdicia tiempo de rastreo y puede confundir la indexación.