Las entradas de WordPress dan error 404 pero la página de inicio funciona

Si tu página de inicio carga sin problemas pero cada entrada y página individual devuelve un error 404, es que las reglas de reescritura de URL de las que depende WordPress faltan o están dañadas en tu archivo .htaccess. La solución más rápida: ve a Ajustes → Enlaces permanentes en el escritorio de WordPress y pulsa Guardar cambios sin tocar nada. Eso obliga a WordPress a regenerar el bloque de reescritura. Si los 404 persisten, es que tu .htaccess no tiene permisos de escritura para el servidor web, que Apache está configurado para ignorarlo, o que estás en Nginx (que no usa .htaccess en absoluto).

Por qué funciona la página de inicio pero las entradas no

Tu página de inicio funciona porque una petición a / se sirve directamente desde index.php en la raíz del sitio. No hace falta ninguna reescritura.

Una petición a /2026/mi-entrada/ es distinta. Esa ruta no es una carpeta real en el disco. Para que WordPress pueda responderla, Apache tiene que enrutar internamente la petición hacia index.php, y entonces WordPress lee REQUEST_URI, lo compara con las reglas de reescritura almacenadas en la opción rewrite_rules de la base de datos, resuelve las variables de consulta (WP::parse_request()) y carga la entrada correcta.

El traspaso de Apache a index.php es la parte que se rompe. Depende por completo de este bloque del .htaccess:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Las dos líneas RewriteCond dicen: si la ruta solicitada no es un archivo real (!-f) ni un directorio real (!-d), envíala a index.php. Elimina ese bloque y Apache buscará un directorio literal /2026/mi-entrada/, no lo encontrará y devolverá su propio 404, antes de que WordPress llegue siquiera a ver la petición.

Por qué WordPress sobrescribe el .htaccess al guardar los enlaces permanentes

Esta es la parte que la mayoría de las guías se saltan. Cuando pulsas Guardar en la pantalla de Enlaces permanentes, WordPress llama a flush_rewrite_rules(). En Apache con un .htaccess con permisos de escritura, eso dispara save_mod_rewrite_rules(), que regenera el bloque de arriba mediante WP_Rewrite::mod_rewrite_rules() y lo vuelve a escribir usando insert_with_markers().

insert_with_markers() solo toca las líneas entre # BEGIN WordPress y # END WordPress. Todo lo que queda fuera de esos marcadores se deja intacto. Todo lo que está dentro se descarta y se reescribe. Las versiones más recientes de WordPress incluso imprimen la advertencia directamente en el archivo:

Any changes to the directives between these markers will be overwritten.

Así que “WordPress sobrescribe mi .htaccess” es cierto, pero con matices: solo reescribe su propio bloque marcado, y solo cuando el archivo tiene permisos de escritura. Si el archivo no tiene permisos de escritura, el guardado no hace nada en el disco, en silencio. WordPress muestra un aviso amarillo en la pantalla de Enlaces permanentes indicándote que pegues las reglas a mano, y si se te pasa ese aviso, tu bloque de reescritura sigue faltando y cada entrada sigue devolviendo 404.

Cómo solucionarlo, paso a paso

1. Vuelve a guardar los enlaces permanentes. Ajustes → Enlaces permanentes → Guardar cambios. No hace falta editar nada. Esto vuelve a ejecutar el flush y reescribe el bloque. Resuelve la mayoría de los casos, incluidas las reglas obsoletas tras una migración.

2. Comprueba que .htaccess existe y tiene permisos de escritura. Está en la misma carpeta que wp-config.php. Es un archivo oculto (dotfile), así que activa “mostrar archivos ocultos” en tu cliente FTP o usa:

ls -la /path/to/wordpress/.htaccess

Si falta, créalo y pega el bloque correcto. Si tu instalación está en un subdirectorio, RewriteBase y el destino final de la reescritura deben coincidir con esa ruta; equivocarse aquí es la razón más habitual de que un bloque pegado a mano siga dando 404. Nuestro generador de .htaccess crea el bloque exacto para la ruta de tu instalación, así no tienes que adivinar.

3. Confirma que Apache tiene permiso para leer el .htaccess. Si el host virtual tiene AllowOverride None, Apache ignora el archivo por completo, sin importar su contenido. Necesitas AllowOverride All (o al menos FileInfo) en el directorio de WordPress. Esto está en la configuración del servidor, no en el .htaccess, así que requiere acceso al servidor:

<Directory /var/www/html>
    AllowOverride All
</Directory>

4. Confirma que mod_rewrite está activado. En Debian/Ubuntu:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. En Nginx no existe el .htaccess. Las reescrituras van en el bloque del servidor:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Diagnóstico rápido: ¿de quién es el 404?

Fíjate en la página del 404. Si es una página de error de Apache o del hosting sin estilos, Apache nunca llegó a WordPress: es un problema de .htaccess o de configuración del servidor (pasos 2–4). Si es el 404 con los estilos de tu tema, WordPress está recibiendo la petición pero no consigue emparejarla: las reglas en la base de datos están obsoletas, y volver a guardar los enlaces permanentes (paso 1) es la solución. Esta única distinción le ahorra a la mayoría de la gente una hora de suposiciones.

Lo que no debes hacer

No desactives todos tus plugins de entrada. Un síntoma puro de “las entradas dan 404, la página de inicio funciona” es un problema de reescritura, no un conflicto de plugins. Desactivar plugins es la respuesta refleja en los foros y casi nunca tiene nada que ver con esto.

No hagas chmod 777 a tu .htaccess. WordPress necesita que el archivo tenga permisos de escritura para el usuario del servidor web, que no es lo mismo que escribible por todo el mundo. 644 con el propietario correcto está bien y es seguro; 777 es un agujero de seguridad que, además, tampoco arreglará el enrutamiento.

No pegues reglas de reescritura personalizadas dentro de los marcadores # BEGIN WordPress / # END WordPress. Se borrarán la próxima vez que alguien guarde los enlaces permanentes. Pon las directivas personalizadas por encima de la línea # BEGIN WordPress.

No reinstales WordPress. Los archivos del núcleo están bien. Esto es un único bloque de texto que falta, no una instalación corrupta.

No le eches la culpa a tu tema. El enrutamiento de los enlaces permanentes es parte del núcleo de WordPress. Un tema no puede provocarlo ni puede solucionarlo.

¿Sigues atascado?

Si has vuelto a guardar los enlaces permanentes, confirmado que el bloque está presente y con permisos de escritura, y establecido AllowOverride All, el sospechoso que queda es un plugin de seguridad o una regla a nivel de hosting que regenera o bloquea el .htaccess a tus espaldas. Comprueba la marca de tiempo de modificación del archivo justo después de guardar los enlaces permanentes: si no cambió, algo está bloqueando la escritura. Regenera un bloque limpio con el generador de .htaccess, pégalo y vuelve a probar con una recarga forzada.