.htaccess por defecto de WordPress: código y restauración

El archivo .htaccess por defecto de WordPress es el bloque corto de RewriteEngine que el software escribe en el .htaccess de la raíz de tu sitio para que enlaces permanentes como /2026/10/post-name/ funcionen en lugar de devolver un 404. Tiene este aspecto:

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

Estas reglas salen del código que WordPress usa para generar el bloque y coinciden con la guía de .htaccess de WordPress. WordPress también escribe tres líneas de comentario justo después de # BEGIN WordPress, que avisan de que se sobrescribirá lo que edites entre los marcadores. No cambian cómo funcionan las reglas.

En una instalación en una subcarpeta, WordPress pone la ruta de la subcarpeta en RewriteBase y en la última regla, por ejemplo RewriteBase /blog/ y RewriteRule . /blog/index.php [L]. Las redes multisitio usan un bloque diferente, y WordPress no escribe este archivo automáticamente para ellas.

Lo esencial

• WordPress genera este bloque en Apache y LiteSpeed cuando tiene permiso de escritura y los enlaces permanentes bonitos están activos. Basta con abrir Ajustes > Enlaces permanentes.
• Si el archivo falta o está dañado, los enlaces permanentes dan 404 mientras la portada sigue cargando, porque la portada no necesita las reglas de reescritura.
• Pon lo que añadas tú o un plugin encima de # BEGIN WordPress, nunca dentro de los marcadores. WordPress reemplaza todo lo que hay entre ellos al actualizar el archivo.

Qué hace cada línea

RewriteEngine On activa el módulo mod_rewrite de Apache para este directorio; sin esta línea, las reglas de reescritura de abajo no hacen nada.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] deja la URL como está (eso significa el -) y copia la cabecera Authorization de la petición en una variable del servidor. WordPress lee esa variable para obtener un usuario y una contraseña enviados en la cabecera, como una contraseña de aplicación.

RewriteBase / define el prefijo de ruta que Apache usa para las URL reescritas. WordPress lo ajusta al lugar donde está el sitio, así que una instalación en una subcarpeta recibe RewriteBase /blog/.

RewriteRule ^index\.php$ - [L] es una protección: si la petición ya es index.php, deja de reescribir y la 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 cosas deben cumplirse para que se active la regla final, de modo que una imagen, un archivo 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. Todo lo que cumple esas dos condiciones se envía a index.php, y WordPress decide a qué entrada, página o archivo se refiere la URL.

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

WordPress vacía sus reglas de reescritura cada vez que se carga la pantalla Ajustes > Enlaces permanentes, así que basta con abrirla y no hace falta pulsar Guardar cambios. Si falta el .htaccess, WordPress lo crea siempre que la carpeta tenga permisos de escritura y los enlaces permanentes bonitos estén activos. Si el archivo existe y se puede escribir, WordPress reemplaza el bloque entre los marcadores.

Eso no resuelve el problema en estos casos:

• El archivo o su carpeta no tienen permisos de escritura para el usuario con el que se ejecuta PHP. La pantalla muestra un error que indica que no se puede escribir en el archivo .htaccess, junto con las reglas que debes pegar. En algunos hostings PHP se ejecuta con un usuario del sistema distinto del dueño de tus subidas por FTP, por lo que unos permisos que parecen correctos en un cliente FTP pueden seguir bloqueando a WordPress.
• Usas nginx. La guía de nginx de WordPress explica que nginx no tiene un archivo de configuración por directorio como .htaccess y que WordPress no puede cambiar la configuración del servidor. El enrutamiento equivalente es una directiva try_files en la configuración del servidor, que debe editar un administrador.
• AllowOverride está en None para el directorio de tu sitio en la configuración principal de Apache. La documentación de Apache dice: “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” Es decir, los archivos .htaccess se ignoran por completo salvo que los habilites expresamente para un directorio. WordPress puede escribir un archivo perfecto y aun así no hará nada. Las reglas de reescritura necesitan AllowOverride FileInfo (o All), algo que quizá tenga que cambiar tu hosting.
• Tus enlaces permanentes están en Simple (Plain). Las URL simples no necesitan reglas de reescritura, así que WordPress no crea el archivo para ellas.

Cómo restaurarlo a mano

Si las entradas y páginas dan 404 mientras la portada funciona, lo primero que debes revisar es si el .htaccess falta o está roto. Arréglalo en dos pasos.

1. Prueba primero el arreglo de un clic. Abre Ajustes > Enlaces permanentes en wp-admin y pulsa Guardar cambios sin tocar nada. Si WordPress puede escribir el archivo, esto lo regenera. Si no puede, la pantalla muestra el error y las reglas que necesitas.

2. Si no se soluciona, crea el archivo a mano. Conéctate por FTP/SFTP o con el administrador de archivos de tu hosting y ve a la carpeta raíz de tu sitio, que normalmente es la que contiene wp-admin. Comprueba si existe .htaccess. Su nombre empieza por un punto, así que algunos administradores de archivos lo ocultan por defecto; activa “mostrar archivos ocultos”.

• Si falta, crea un archivo nuevo llamado exactamente .htaccess (sin .txt ni nada antes del punto).
• Pega las reglas que te mostró WordPress o el bloque por defecto del principio de esta guía. En una instalación en subcarpeta, ajusta RewriteBase y la última regla.
• Guarda y recarga el enlace permanente de una entrada para confirmar que funciona.

Si sigue dando 404, puede que se esté ignorando el .htaccess. Consulta AllowOverride con tu hosting, porque Apache ignora incluso un archivo correcto cuando está desactivado.

Tus propias reglas frente al bloque de WordPress

Un plugin o una edición manual pueden añadir reglas propias, como redirecciones, protección contra hotlinking o cabeceras de caché. Mantenlas fuera del bloque de WordPress, y encima de él para que se ejecuten antes de su regla general:

# 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
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Lo que pongas entre # BEGIN WordPress y # END WordPress se pierde la próxima vez que WordPress actualice el archivo, y basta con cargar la pantalla de enlaces permanentes para que ocurra. Las líneas antes y después de los marcadores se conservan. Para las redirecciones en concreto, consulta Reglas de redirección de WordPress en .htaccess bien hechas, que explica dónde van y cómo evitar bucles.

Un 500 Internal Server Error justo después de editar el archivo apunta a lo que acabas de cambiar. La documentación de Apache indica que el registro de errores probablemente nombrará una directiva no permitida o un error de sintaxis. Las reglas copiadas de un tutorial antiguo pueden provocarlo: Order es un comando no válido en Apache 2.4 salvo que esté cargado mod_access_compat. Deshaz la edición para recuperar el sitio y luego lee el registro de errores.

Más allá del bloque por defecto

El bloque por defecto solo se ocupa del enrutamiento de los enlaces permanentes y de la cabecera Authorization. Para proteger el acceso a archivos sensibles, como bloquear la ejecución de PHP en /uploads o denegar las peticiones directas a wp-config.php, consulta Reglas de seguridad de .htaccess para WordPress que de verdad ayudan. Si los enlaces permanentes dan 404 por otro motivo, como una estructura incorrecta, una capa de caché que sirve reglas obsoletas o un conflicto de subdirectorios en multisitio, Los enlaces permanentes de WordPress no funcionan repasa las demás causas.

Preguntas frecuentes

¿Qué es el archivo .htaccess por defecto de WordPress? Es el bloque RewriteEngine que WordPress escribe entre # BEGIN WordPress y # END WordPress en el .htaccess de la raíz de tu sitio. Pasa la cabecera Authorization a PHP y envía a index.php cualquier petición que no sea un archivo o una carpeta reales.

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

¿Por qué todas mis entradas dan 404 excepto la portada? Un archivo .htaccess ausente o dañado en Apache produce este patrón. El servidor puede encontrar la portada sin reglas de reescritura. Cualquier otro enlace permanente necesita esas reglas para llegar a index.php, así que sin ellas Apache busca un archivo que no existe y devuelve un 404.

¿WordPress recrea el .htaccess automáticamente? Sí, en Apache o LiteSpeed con mod_rewrite, si los enlaces permanentes bonitos están activos y WordPress puede escribir ahí. Basta con abrir Ajustes > Enlaces permanentes. Si falta el archivo, la carpeta debe tener permisos de escritura, y si ya existe, debe tenerlos el propio archivo. Si no, la pantalla muestra un error, junto con las reglas que debes pegar a mano.

¿Por qué nginx no tiene un archivo .htaccess de WordPress? nginx no tiene un archivo de configuración por directorio como el .htaccess de Apache. El mismo enrutamiento se escribe como una regla try_files en la configuración del servidor nginx, que debe editar un administrador porque WordPress no puede cambiarla.

¿Por qué se rompió mi .htaccess al guardar los enlaces permanentes? Comprueba si se colocó una regla personalizada dentro de los marcadores # BEGIN WordPress y # END WordPress. WordPress reemplaza todo lo que hay entre ellos al actualizar el archivo, así que esa regla se pierde. Mantén las reglas personalizadas encima de los marcadores.

Fuentes

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• Código fuente de WordPress: class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4: .htaccess files, mod_rewrite, Upgrading to 2.4

---

Crea un .htaccess limpio y correcto, con el bloque por defecto de enlaces permanentes y las reglas de seguridad o redirección que de verdad necesites, usando el generador gratuito de .htaccess para WordPress.