Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Cuando aparece el mensaje XAMPP error 404 no encontrado en Apache, la causa casi siempre está en uno de dos sitios: el archivo .htaccess que reescribe rutas, o la directiva DocumentRoot que decide qué carpeta se sirve. Comparar estas dos opciones no es un capricho teórico: en la práctica, una de las dos explica la mayoría de los casos, y saber cuál toca ahorra horas.
He visto este fallo en proyectos de Laravel que funcionaban en local con el servidor embebido de PHP y morían al pasar a XAMPP. El motivo no era el código: era un .htaccess con reglas de reescritura que Apache interpretaba distinto, o una carpeta public que quedaba fuera del DocumentRoot. Ese detalle cambia por completo el diagnóstico.
Qué hace realmente cada opción
El DocumentRoot es la raíz física desde la que Apache lee los archivos. Si apunta a htdocs y tu proyecto vive en htdocs/miapp/public, la URL localhost/miapp no resolverá el index correcto y verás el 404. El .htaccess, en cambio, actúa sobre la URL ya resuelta: reescribe, redirige o bloquea. Un RewriteRule mal escrito puede convertir una ruta válida en un 404 silencioso, sin tocar el sistema de archivos.
La diferencia importa porque el error de XAMPP no encontrado se manifiesta igual en ambos escenarios: la página de Apache con el aviso. Sin revisar el log de errores, es imposible distinguir si el fallo es de ruta física o de reescritura.
Por qué gana revisar el DocumentRoot primero
Mi recomendación es clara: empieza por el DocumentRoot. La razón es práctica. Comprobar la ruta en httpd.conf o en el archivo de vhosts lleva un minuto y descarta la causa más frecuente. Si la carpeta servida no contiene el index.php o el index.html, ningún ajuste en el .htaccess arreglará el 404.
Un caso típico: proyectos que usan un subdirectorio como raíz pública. Apache no adivina esa estructura. Sin un VirtualHost que apunte a public, la petición busca un archivo que no existe en la raíz y devuelve el error de XAMPP no encontrado. Cambiar la directiva resuelve el problema de golpe.
Cuándo el .htaccess es el verdadero culpable
Hay escenarios donde el DocumentRoot está perfecto y el 404 persiste. Ahí entra el .htaccess. Si el archivo tiene RewriteEngine On pero le falta RewriteBase, o si las condiciones no contemplan subcarpetas, las rutas amigables se rompen. También ocurre cuando se copia un .htaccess de producción con reglas de HTTPS o dominios que en local nunca coinciden.
Esto no funciona para todos los casos: si tu proyecto no usa reescritura de URLs ni frameworks con rutas limpias, tocar el .htaccess es perder el tiempo. Y si el AllowOverride está en None, Apache ignora el archivo por completo, así que editar reglas no tendrá efecto visible.
Cómo decidir sin dar palos de ciego
El log de errores de Apache es la fuente más fiable. Ahí se ve si la petición buscó un archivo inexistente (problema de raíz) o si la reescritura derivó en una ruta inválida. La documentación oficial de Apache sobre DocumentRoot y sobre mod_rewrite explica el comportamiento de cada pieza sin ambigüedades.
En mi experiencia, el orden correcto es: verificar la carpeta servida, comprobar que existe el archivo index, y solo después revisar reglas de reescritura. Invertir el orden genera frustración porque se depura código cuando el fallo estaba en la configuración del servidor.
Veredicto
Entre las dos opciones, el DocumentRoot gana como primer punto de revisión del XAMPP error 404 no encontrado. No porque el .htaccess sea irrelevante, sino porque la causa física es más común y más rápida de confirmar. El .htaccess queda como segunda vía, decisiva en frameworks y en proyectos con URLs limpias. Ninguna de las dos garantiza solución inmediata en todos los entornos; el log de Apache sigue siendo el árbitro final.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
