Archivo .htaccess por defecto de WordPress: qué contiene y cómo restaurarlo

El archivo .htaccess por defecto de WordPress es el bloque corto de RewriteEngine que el propio software escribe en el .htaccess de la raíz de tu sitio para que enlaces permanentes como /2026/10/nombre-de-entrada/ resuelvan en lugar de dar 404. Tiene este aspecto:

# 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

Ese es el bloque exacto, reproducido de la guía oficial de WordPress sobre Apache HTTP Server y de la lógica de reescritura documentada en la página de HelpHub sobre enlaces permanentes. Si tu RewriteBase no es / — por ejemplo porque WordPress está instalado en una subcarpeta — coincidirá con esa ruta en su lugar, y eso también es correcto: lo genera el propio WordPress.

Lo esencial

• WordPress genera este bloque automáticamente, solo en Apache y LiteSpeed, siempre que el archivo tenga permisos de escritura y guardes Ajustes > Enlaces permanentes.
• Si el archivo falta o está dañado, todos los enlaces permanentes excepto la portada devuelven 404, porque solo la portada puede encontrarse sin las reglas de reescritura.
• Cualquier cosa que añadas tú o un plugin debe ir encima de # BEGIN WordPress, nunca dentro de los marcadores — WordPress sobrescribe todo lo que hay entre ellos cada vez que se guardan los enlaces permanentes.

¿Necesitas reconstruir el archivo con tu ruta real y alguna regla extra incluida? El generador de .htaccess para WordPress monta uno correcto en tu navegador.

Qué hace cada línea

RewriteEngine On activa el módulo mod_rewrite de Apache para este directorio; sin esto, el resto de líneas no hace nada.

RewriteBase / le dice a Apache que las rutas reescritas son relativas a la raíz del sitio. WordPress lo ajusta para que coincida con dónde vive realmente el sitio — una instalación en subdirectorio recibe RewriteBase /blog/, no /.

RewriteRule ^index\.php$ - [L] es una guarda sin efecto: si la petición ya es index.php, se detiene la reescritura y se deja pasar sin cambios.

Las dos líneas RewriteCond son la lógica real. %{REQUEST_FILENAME} !-f y !-d preguntan “¿esta petición NO coincide con un archivo real, y NO coincide con un directorio real?”. Ambas tienen que ser ciertas para que se dispare la regla final — así que una imagen, un CSS o un PDF subido se sirven directamente y nunca pasan por el enrutamiento de WordPress.

RewriteRule . /index.php [L] es lo que hace funcionar los enlaces permanentes: cualquier cosa que sobreviva a las dos condiciones anteriores — es decir, que no sea un archivo o carpeta real — se envía a index.php, y el enrutamiento propio de WordPress (WP_Query, etiquetas de reescritura) decide qué entrada, página o archivo significa realmente esa URL.

Cuándo WordPress recrea este archivo, y cuándo no

WordPress intenta escribir el .htaccess por su cuenta cada vez que abres Ajustes > Enlaces permanentes y pulsas Guardar cambios, aunque no cambies nada en pantalla. Ese guardado dispara flush_rewrite_rules(), que intenta abrir .htaccess para escritura e insertar el bloque actual entre los marcadores.

Ese intento falla en silencio, dejando el archivo ausente o desactualizado, cuando:

• El archivo o su carpeta no tienen permisos de escritura para el usuario con el que corre PHP. En muchos hostings compartidos PHP corre como un usuario del sistema distinto al que subió los archivos por FTP, así que permisos que parecen correctos en un cliente FTP igualmente bloquean la escritura de WordPress.
• Estás en nginx. .htaccess es un mecanismo solo de Apache y LiteSpeed (la propia documentación de Apache sobre AllowOverride explica por qué: nginx no tiene un archivo de configuración por directorio que vuelva a leer en cada petición). El equivalente en nginx es una directiva try_files dentro del bloque server, que solo puede editar quien tenga acceso al servidor; WordPress nunca puede escribirla por ti.
• AllowOverride está en None para el directorio de tu sitio en la configuración principal de Apache. Es el ajuste que permite que un .htaccess anule algo; la documentación de Apache es explícita: con AllowOverride None, “los archivos .htaccess se ignoran por completo” — WordPress puede escribir un archivo perfecto y seguirá sin hacer nada hasta que se cambie esta opción a nivel de servidor.
• El archivo se borró o nunca existió y algo en el guardado no disparó una regeneración — lo más habitual es que los enlaces permanentes ya estuvieran en la misma estructura, así que WordPress no vio ningún cambio que volcar.

Cómo restaurarlo a mano

Si las entradas y páginas dan 404 mientras la portada sigue funcionando, esa es la firma de un .htaccess ausente o roto. Arréglalo en dos pasos.

1. Prueba primero el arreglo de un clic. Ve a Ajustes > Enlaces permanentes en el escritorio de WordPress y pulsa Guardar cambios sin tocar nada. Si el archivo tiene permisos de escritura, esto por sí solo lo regenera y listo.

2. Si no se soluciona, crea el archivo a mano. Conéctate por FTP/SFTP o el administrador de archivos de tu hosting, ve a la carpeta donde está instalado WordPress (la que contiene wp-config.php) y comprueba si existe .htaccess — es un archivo oculto, así que algunos gestores de archivos lo esconden por defecto; activa “mostrar archivos ocultos”.

• Si falta, crea un archivo nuevo llamado exactamente .htaccess (sin .txt, nada antes del punto).
• Pega el bloque por defecto de arriba, ajustando RewriteBase si WordPress vive en una subcarpeta.
• Guarda y recarga el enlace de una entrada para confirmar que funciona.

Si sigue dando 404 después de eso, la causa ya no es “falta el .htaccess” sino “se está ignorando el .htaccess” — pregunta a tu hosting por AllowOverride, porque un archivo correcto en un directorio donde Apache tiene orden de ignorarlo se comporta exactamente igual que si no hubiera archivo.

Tus propias reglas frente al bloque de WordPress

Un plugin o una edición manual pueden añadir reglas propias — redirecciones, protección contra hotlinking, cabeceras de caché. Son un bloque distinto y separado del que genera WordPress, y los dos nunca deberían solaparse:

# Reglas que añadiste tú o un plugin — ENCIMA de los marcadores de WordPress
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # ejemplo: protección contra hotlinking, reglas de caché, etc.
</FilesMatch>

# 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

Todo lo que se coloque entre # BEGIN WordPress y # END WordPress se borra en silencio la próxima vez que alguien guarde la pantalla de Enlaces permanentes, porque WordPress trata todo ese tramo como propio y lo reescribe entero. Es la causa más común de “mi regla personalizada desapareció” — nunca se eliminó a propósito, estaba dentro de un bloque que WordPress considera suyo. Para redirecciones en concreto, mira reglas de redirección .htaccess de WordPress bien hechas para saber dónde van y cómo evitar bucles.

También es la causa más común de un 500 Internal Server Error repentino justo después de editar el archivo: una regla copiada de un foro escrito para otra versión de Apache (sintaxis Order/Deny de 2.2 mezclada con sintaxis Require de 2.4) rompe el análisis de todo el archivo, incluido el bloque de WordPress que viene después, y cae el sitio entero — no solo la parte que tocaste.

Más allá del bloque por defecto

El bloque por defecto solo gestiona el enrutamiento de enlaces permanentes. Si además quieres reforzar el acceso a archivos sensibles o añadir el puñado de reglas .htaccess que realmente reducen la superficie de ataque — bloquear la ejecución de PHP en /uploads, denegar peticiones directas a wp-config.php — mira reglas de seguridad .htaccess de WordPress que sí ayudan. Y si los enlaces permanentes dan 404 por otra razón — estructura de enlaces equivocada, una capa de caché sirviendo reglas antiguas, conflictos de multisitio en subdirectorios — enlaces permanentes de WordPress que no funcionan repasa las demás causas.

Preguntas frecuentes

¿Qué es el archivo .htaccess por defecto de WordPress? Es el bloque de RewriteEngine que WordPress escribe entre # BEGIN WordPress y # END WordPress para que los enlaces permanentes resuelvan en index.php en lugar de dar 404.

¿Cuál es el código exacto del .htaccess por defecto de WordPress? RewriteEngine On, RewriteBase /, una regla de paso para index.php, dos condiciones que comprueban que la petición no es un archivo o directorio real, y una regla final que envía todo lo demás a index.php. El bloque completo está reproducido al inicio de esta guía.

¿Por qué todas mis entradas dan 404 excepto la portada? La portada se puede encontrar sin ninguna regla de reescritura; cualquier otro enlace permanente las necesita. Un .htaccess ausente o dañado en Apache produce exactamente este patrón.

¿WordPress recrea el .htaccess automáticamente? Solo si el archivo tiene permisos de escritura — volver a guardar Ajustes > Enlaces permanentes lo dispara. Si el archivo no tiene permisos, falta en un hosting que no lo autogenera, o AllowOverride está desactivado, WordPress no puede arreglarlo por ti y tienes que crear o corregir el archivo a mano.

¿Por qué nginx no tiene un archivo .htaccess de WordPress? .htaccess solo funciona en Apache y LiteSpeed. nginx no tiene archivo de configuración por directorio e ignora .htaccess por completo; el mismo enrutamiento se escribe como una regla try_files en el bloque server de nginx.

¿Por qué se rompió mi .htaccess al guardar los enlaces permanentes? Se colocó una regla personalizada dentro de los marcadores # BEGIN WordPress / # END WordPress en lugar de encima de ellos, y WordPress sobrescribió todo ese tramo la siguiente vez que se guardaron los enlaces permanentes.

---

Reconstruye un .htaccess limpio y correcto — bloque de enlaces permanentes por defecto más cualquier regla de seguridad o redirección que realmente necesites — con el generador gratuito de .htaccess para WordPress.