El archivo .htaccess de WordPress es un fichero pequeño, oculto y con más poder sobre tu web del que aparenta: controla cómo el servidor Apache interpreta las URL, gestiona redirecciones, bloquea accesos y puede activar la compresión y la caché del navegador. Cuando funciona, nadie se acuerda de él; cuando se corrompe o alguien pega un fragmento equivocado, la web entera devuelve un error 500. Entender el htaccess de WordPress —dónde está, qué contiene por defecto y qué fragmentos merece la pena añadir— te da un control fino del servidor sin tocar su configuración global, algo especialmente valioso en hosting compartido, donde es el único punto de ajuste al que tienes acceso. En esta guía práctica veremos el bloque estándar que WordPress escribe, cómo editarlo sin jugarte la web, y una colección de fragmentos útiles y probados para redirecciones, seguridad y rendimiento.
Qué es el archivo .htaccess y qué pinta en WordPress
这个 .htaccess (hypertext access) es un archivo de configuración por directorio del servidor web Apache: las directivas que contiene se aplican a la carpeta donde está y a todas sus subcarpetas, sin necesidad de tocar la configuración principal del servidor ni reiniciarlo. La documentación oficial de Apache lo describe en detalle en su guía sobre archivos .htaccess.
WordPress lo utiliza para una cosa concreta: las URL amigables. Sin .htaccess, tus entradas se verían como ?p=123; con él, Apache redirige internamente cualquier ruta bonita (/mi-articulo/) hacia index.php, y WordPress decide qué mostrar. Cada vez que guardas los enlaces permanentes, WordPress intenta reescribir su bloque en este archivo.
Dos aclaraciones importantes: el punto inicial del nombre lo convierte en archivo oculto en sistemas Unix, así que tendrás que activar “mostrar archivos ocultos” para verlo. Y solo aplica a servidores Apache o LiteSpeed: si tu hosting usa Nginx, no existe .htaccess y estos ajustes se hacen en la configuración del servidor.
Dónde está y cómo editarlo sin romper la web
Vive en la carpeta raíz de tu instalación, junto a wp-config.php e index.php. Para editarlo tienes tres vías:
- Gestor de archivos del hosting: cPanel o Plesk lo muestran activando los archivos ocultos. Es la vía más cómoda.
- FTP/SFTP: con FileZilla, forzando “mostrar archivos ocultos” en el menú Servidor.
- Desde WordPress: plugins como Yoast SEO (Herramientas → Editor de archivos) o gestores de fragmentos permiten editarlo sin salir del panel.
La regla de seguridad es una y no se negocia: descarga una copia del archivo antes de tocarlo. Un solo carácter fuera de sitio en el .htaccess tumba la web con un error 500 inmediato. Con la copia a mano, recuperarse es cuestión de volver a subirla. Si el archivo no existe (pasa en instalaciones nuevas con permalinks simples), créalo como archivo de texto plano llamado exactamente .htaccess, sin extensión .txt.
El código por defecto de WordPress
Este es el bloque estándar que WordPress escribe en una instalación normal (sin multisitio):
# 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
Traducido: si la URL pedida no corresponde a un archivo real (!-f) ni a una carpeta real (!-d), la petición se envía a index.php para que WordPress la resuelva. Así funcionan todas las URL amigables.
Detalle crucial: todo lo que está entre # BEGIN WordPress y # END WordPress es territorio de WordPress, que puede reescribirlo cuando guardas los enlaces permanentes. Tus fragmentos personalizados van siempre fuera de esas marcas, preferiblemente encima del bloque, porque Apache procesa el archivo de arriba abajo y las redirecciones conviene que se evalúen antes que la regla general.
Si tu web da error 404 en todas las páginas menos la portada, este bloque falta o está dañado: ve a Ajustes → Enlaces permanentes y pulsa “Guardar cambios” para regenerarlo, o pégalo a mano tal cual.
Redirecciones útiles
El .htaccess es el lugar más eficiente para las redirecciones permanentes, porque se resuelven antes de que WordPress llegue a cargar:
# Redirigir una URL antigua a la nueva
Redirect 301 /pagina-antigua/ https://tudominio.com/pagina-nueva/
# Redirigir un dominio antiguo completo al nuevo
RewriteEngine On
RewriteCond %{HTTP_HOST} ^dominioantiguo\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.dominioantiguo\.com$
RewriteRule ^(.*)$ https://dominionuevo.com/$1 [R=301,L]
# Forzar HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
El código 301 indica redirección permanente y transfiere la autoridad SEO de la URL vieja a la nueva. Para pruebas temporales usa 302. Si solo necesitas un puñado de redirecciones y no quieres tocar el archivo, un plugin como Redirection hace lo mismo desde el panel, a cambio de un pelín de rendimiento.
Fragmentos de seguridad
El .htaccess permite cerrar varias puertas que los atacantes prueban a diario. Estos fragmentos son complementarios a las medidas que repasamos en 7 个增强 WordPress 安全性的技巧:
# Proteger wp-config.php
<Files wp-config.php>
Require all denied
</Files>
# Proteger el propio .htaccess
<Files .htaccess>
Require all denied
</Files>
# Bloquear xmlrpc.php (si no usas Jetpack ni la app movil)
<Files xmlrpc.php>
Require all denied
</Files>
# Desactivar el listado de directorios
Options -Indexes
# Impedir la ejecucion de PHP en la carpeta de subidas
# (guardar en wp-content/uploads/.htaccess)
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
Notas: la sintaxis Require all denied corresponde a Apache 2.4, la que usan los hostings actuales (en Apache 2.2 era Deny from all). El bloqueo de xmlrpc.php corta uno de los vectores de fuerza bruta más usados, pero compruébalo antes si usas Jetpack, la app móvil de WordPress o algún servicio que publique en remoto. Y el fragmento de la carpeta de subidas es de los más rentables: aunque un atacante consiga colar un archivo PHP en uploads, el servidor se negará a ejecutarlo. Si tu web ya ha sido comprometida, esto no basta: sigue la 被攻击的WordPress清理指南.
Caché del navegador y compresión
Dos bloques clásicos de rendimiento. El primero activa la compresión de texto (HTML, CSS, JavaScript) con mod_deflate:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml
AddOutputFilterByType DEFLATE application/javascript application/json
AddOutputFilterByType DEFLATE application/rss+xml image/svg+xml
</IfModule>
El segundo indica al navegador cuánto tiempo puede conservar cada tipo de archivo sin volver a pedirlo:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresDefault "access plus 1 week"
</IfModule>
Ambos van envueltos en IfModule, de modo que si el módulo no está disponible en tu servidor el bloque se ignora sin romper nada. Ten en cuenta que si usas un plugin de caché completo, probablemente ya escriba estas reglas por ti: en nuestro análisis de WP Rocket explicamos cómo gestiona exactamente esta capa. No dupliques directivas: revisa el archivo antes de pegar.
Otros ajustes prácticos: hotlinking y unificar www
Dos fragmentos más que resuelven molestias frecuentes. El primero evita el hotlinking, es decir, que otras webs muestren tus imágenes cargándolas desde tu servidor y gastando tu ancho de banda:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?tudominio\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC]
El segundo unifica la versión con y sin www del dominio, importante para no repartir la autoridad SEO entre dos URL idénticas. Esta variante fuerza la versión sin www:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.tudominio\.com$ [NC]
RewriteRule ^(.*)$ https://tudominio.com/$1 [R=301,L]
Elige una versión canónica (con o sin www), configúrala igual en Ajustes → Generales de WordPress y deja que esta regla se encargue de los visitantes que lleguen por la otra.
Errores comunes al editar el .htaccess
- Error 500 tras guardar: hay una errata o una directiva no soportada. Restaura tu copia y aplica los cambios de uno en uno hasta localizar el conflicto.
- Pegar fragmentos dentro del bloque de WordPress: desaparecerán en cuanto WordPress regenere sus reglas. Siempre fuera de las marcas BEGIN/END.
- Directivas de Apache 2.2 en servidores 2.4:
Order Allow,Denyy compañía provocan error en configuraciones modernas. Usa la sintaxisRequire. - Duplicar reglas de plugins: plugins de caché y seguridad escriben sus propios bloques marcados. Dos copias de la misma regla dan resultados imprevisibles.
- Editar sin copia previa: el clásico. Treinta segundos de precaución contra una web caída.
- Olvidar que estás en Nginx: si tus cambios no surten ningún efecto, quizá tu hosting no usa Apache. Pregunta al soporte antes de seguir peleando.
Un truco de flujo de trabajo: haz los cambios primero en un entorno de pruebas si lo tienes, y valida la web tras cada bloque añadido (portada, una entrada, el wp-admin). Si prefieres minimizar riesgos, gestores como WPCode permiten insertar parte de estos ajustes desde el panel con validación previa.
常见问题
No encuentro el archivo .htaccess en mi instalación, ¿es normal?
Sí, por dos motivos posibles: está oculto (activa “mostrar archivos ocultos” en tu FTP o gestor de archivos) o aún no existe porque nunca se han guardado enlaces permanentes amigables. Ve a Ajustes → Enlaces permanentes, guarda, y WordPress lo creará si tiene permisos de escritura.
He editado el .htaccess y ahora toda la web da error 500, ¿qué hago?
Restaura la copia previa del archivo y la web volverá al instante. Si no la hiciste, renombra el archivo actual a htaccess-roto, crea uno nuevo solo con el bloque por defecto de WordPress de esta guía y vuelve a añadir tus fragmentos de uno en uno hasta dar con el culpable.
¿El .htaccess sirve para acelerar WordPress?
Contribuye: la compresión y la caché del navegador reducen el peso transferido y las visitas repetidas cargan mucho más rápido. Pero es una pieza más del rendimiento, no la principal: el hosting, la caché de página y las imágenes optimizadas mueven más la aguja.
¿Qué pasa con el .htaccess si mi hosting usa Nginx?
Nginx no lee archivos .htaccess: su configuración es centralizada y la gestiona el proveedor. Los hostings con Nginx suelen aplicar por defecto los equivalentes (compresión, caché de estáticos, bloqueo de PHP en uploads) o darte un panel para activarlos. Consulta su documentación antes de buscar soluciones de Apache.
结论
El htaccess de WordPress es la navaja suiza del servidor: cuatro líneas hacen posibles las URL amigables, y unos pocos bloques bien elegidos añaden redirecciones limpias, varias capas de seguridad y una mejora tangible de rendimiento con compresión y caché del navegador. Las reglas del juego son simples: copia de seguridad antes de cada edición, fragmentos personalizados siempre fuera del bloque BEGIN/END de WordPress, sintaxis moderna de Apache 2.4 y cambios de uno en uno con verificación después de cada paso. Con esa disciplina, el archivo más temido de WordPress se convierte en una herramienta rutinaria más. Y si un día algo sale mal, ya conoces la salida de emergencia: restaurar la copia, regenerar los enlaces permanentes y seguir adelante.
