El .htaccess de WordPress sigue siendo, en 2026, una de las herramientas más rápidas para tocar configuración de servidor sin entrar al panel del hosting. Funciona en Apache y en LiteSpeed (que lo lee de forma compatible), pero si tu servidor es Nginx no lo lee y tendrás que pasar las reglas a la configuración del propio Nginx. Antes de copiar y pegar nada conviene saber qué tienes delante.
El archivo se popularizó con Apache y permite definir directivas por directorio sin tocar la configuración global. Eso te ahorra subir al servidor por SSH cada vez que quieres cambiar una redirección o capar una IP. Eso sí, los hostings compartidos suelen tener varias directivas capadas para que un cliente no rompa el rendimiento del resto, así que no te asustes si alguna línea no surte efecto. Si dependes mucho de reglas Apache, una auditoría previa con Site Audit Snapshot te ahorra sorpresas.
El archivo vive en la raíz de la instalación de WordPress, al mismo nivel que wp-config.php. Lo puedes editar de tres formas, depende de cómo tengas montado el sitio:
nano /ruta/public_html/.htaccess y listo. Mucho más cómodo para iterar pruebas.Si no encuentras el archivo, comprueba primero que tu servidor sea Apache o LiteSpeed. Si tu hosting va sobre Nginx puro (algunos cloud y proveedores como Kinsta o Pressable lo usan), no existe ningún .htaccess y nunca lo va a haber, da igual cuántas opciones de «mostrar ocultos» actives.
Una línea mal puesta en este archivo puede dejar la web con error 500 sin previo aviso. La regla básica antes de cambiar nada es duplicar el archivo (renombra el original a .htaccess.bak) y tener un backup completo del WordPress reciente. Si revientas el .htaccess y no puedes acceder al admin para regenerarlo desde Ajustes → Enlaces permanentes, el .bak te salva la vida.
Otra recomendación que ya casi nadie sigue: añade siempre tus reglas después del bloque # END WordPress. WordPress regenera todo lo que haya entre # BEGIN WordPress y # END WordPress cuando guarda los enlaces permanentes, así que cualquier cosa metida ahí dentro se pierde sin avisar.
Cada bloque de código va por separado, copia solo el que te interese. Recuerda probar con tráfico bajo y revisar el log de errores del hosting si algo falla.
Útil para frenar a un visitante pesado o un bot de scraping insistente. La sintaxis depende de la versión de Apache, así que aquí van las dos:
# Apache 2.4 (sintaxis actual)
Require all granted
Require not ip 198.126.7.58
Require not ip 47.81.7.47
# Apache 2.2 (legacy, todavía se ve)
order allow,deny
allow from all
deny from 198.126.7.58
deny from 47.81.7.47Lenguaje del código: CSS (css)Si vas a tocar plugins o migrar y quieres avisar al visitante, crea un mantenimiento.html en la raíz y mete este bloque. Sustituye la IP por la tuya para no quedarte fuera mientras trabajas:
RewriteEngine on
RewriteCond %{REQUEST_URI} !/mantenimiento.html$
RewriteCond %{REMOTE_ADDR} !^123.123.123.123
RewriteRule $ /mantenimiento.html [R=302,L]Ojo: usa 302 (redirección temporal), nunca 301. Si pones un 301 Google la cachea y aunque quites la regla puede tardar días en olvidarla.
En 2026 esto ya viene de fábrica en muchos hostings, pero si migras un WordPress antiguo es la primera regla que necesitas. Forzar HTTPS y elegir entre www o sin www en el mismo bloque evita el doble salto que mata el LCP. Versión con www:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www. [NC]
RewriteRule ^ https://www.tublog.com%{REQUEST_URI} [L,R=301]Lenguaje del código: JavaScript (javascript)Versión sin www (la que recomiendo si arrancas de cero, dominios más cortos y URL más limpias):
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^ https://tublog.com%{REQUEST_URI} [L,R=301]Lenguaje del código: JavaScript (javascript)Para una URL antigua que ya no existe, el 301 le dice a Google que el contenido se ha mudado y traspasa la autoridad SEO. Para casos sueltos basta con .htaccess; si vas a manejar cientos, el plugin Redirection o el módulo de redirecciones de Rank Math te lo deja todo en una interfaz cómoda y registra los 404 para que sepas qué redirigir.
Redirect 301 /antiguo/pagina.html https://www.tublog.com/nuevo/pagina.htmlLenguaje del código: JavaScript (javascript)El truco clásico era apuntar el feed nativo de WordPress hacia FeedBurner. En 2026 el servicio sigue zombi: Google no lo mata del todo, pero llevan años sin tocarlo y nadie nuevo lo monta. Si necesitas estadísticas de feed, mira soluciones modernas como FeedPress o follow.it. Si aun así te interesa el patrón de redirección hacia un dominio externo, este es el código:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner [NC]
RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
RewriteRule ^feed/?([_0-9a-z-]+)?/?$ https://feeds.feedburner.com/tu-feed [R=302,NC,L]
</IfModule>Lenguaje del código: HTML, XML (xml)El bloque clásico de ExpiresActive sigue valiendo, pero hoy lo importante es elegir bien los TTL por tipo de archivo para que el navegador no pida lo mismo dos veces. Esto mejora el LCP en visitas recurrentes y reduce el INP, sobre todo en móvil. Es uno de los ajustes que más se nota en la entrega de imágenes y fuentes:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 month"
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch ".(jpg|jpeg|png|webp|avif|woff2)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>Lenguaje del código: PHP (php)Si ya usas WP Rocket, LiteSpeed Cache o W3 Total Cache estos bloques los gestiona el plugin y no hace falta que los duplicar. Y si vas con LiteSpeed Cache, además te beneficias de HTTP/3 y QUIC sin tocar nada más en el .htaccess.
El spam automatizado contra wp-comments-post.php sigue activo. Esta regla rechaza cualquier POST que no venga referido desde tu propio dominio o que no tenga User-Agent. Es una capa más antes de Akismet o un anti-spam dedicado:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post.php*
RewriteCond %{HTTP_REFERER} !.*tublog.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^https://%{REMOTE_ADDR}/$ [R=301,L]Lenguaje del código: JavaScript (javascript)Si trabajas siempre desde la misma IP fija (oficina o VPN), capar el acceso al área de administración por IP es de las cosas que más reducen los intentos de fuerza bruta contra tu login. Combínalo con los consejos generales de seguridad de WordPress y prácticamente cierras el vector más usado para entrar a un WordPress. Mete este bloque en un .htaccess dentro de la carpeta /wp-admin/:
# Apache 2.4
AuthType Basic
AuthName "WordPress Admin"
<RequireAll>
Require ip 80.40.20.10
</RequireAll>Lenguaje del código: PHP (php)Si tu IP es dinámica o cambias mucho de red (cafeterías, viajes, móvil), olvídate de este truco y tira de plugin de 2FA o de un firewall de aplicación.
Útil si tu hosting deja subidas grandes pero quieres evitar que un editor te suba un MP4 de 500 MB. El valor va en bytes, así que para un tope de 64 MB serían 67108864:
LimitRequestBody 67108864WordPress ya pinta una 404 propia gracias al theme, pero esto cubre los errores que ocurren antes de que arranque PHP (un 500 por .htaccess roto, un 401 de autenticación). Te conviene tener al menos una 500 estática que no dependa de WordPress:
ErrorDocument 401 /err/401.html
ErrorDocument 403 /err/403.html
ErrorDocument 404 /err/404.html
ErrorDocument 500 /err/500.htmlSi por convención quieres que todas tus URLs acaben en barra (mucho SEO local lo prefiere por consistencia con la canonical), este bloque añade el / y hace 301 al instante:
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !#
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ https://tublog.com/$1/ [L,R=301]Lenguaje del código: PHP (php)El bloque original del post hablaba de proteger plugins, pero el patrón realmente útil hoy es bloquear que se ejecuten archivos PHP en la carpeta de subidas. Es la vía más usada para subir backdoors a WordPress. Crea un .htaccess dentro de /wp-content/uploads/ con esto:
<FilesMatch ".(php|phtml|phar)$">
Require all denied
</FilesMatch>Lenguaje del código: HTML, XML (xml)Capa extra para zonas de pruebas, staging o cualquier carpeta que no quieras pública. Genera el .htpasswd con la herramienta de tu hosting (o con el comando htpasswd -c) y referéncialo aquí:
AuthType Basic
AuthName "Zona restringida"
AuthUserFile /usr/local/var/www/html/.htpasswd
Require valid-userLenguaje del código: PHP (php)Cuando el ataque viene de un rango concreto, banearlo entero es más eficaz que ir IP a IP. La sintaxis 2.4 acepta tanto IPs como subredes con CIDR:
<RequireAll>
Require all granted
Require not ip 80.40.20.10
Require not ip 192.168.1.0/24
Require not ip 2001:db8::/32
</RequireAll>Lenguaje del código: PHP (php)Va de la mano con el truco 3, pero es la versión que añade exclusivamente el dominio canónico cuando ya tienes HTTPS resuelto en otra parte (por ejemplo en el panel del hosting):
RewriteEngine On
RewriteCond %{HTTP_HOST} ^tublog.com$ [NC]
RewriteRule ^(.*)$ https://www.tublog.com/$1 [R=301,L]Lenguaje del código: JavaScript (javascript)Esto no estaba en 2015 y hoy es lo primero que mira un auditor de seguridad. Cuatro cabeceras que se añaden en una sola pasada y elevan la nota de tu sitio en herramientas como Mozilla Observatory o Security Headers:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
</IfModule>Lenguaje del código: JavaScript (javascript)Sobre la Content-Security-Policy te recomiendo no copiarla a ciegas. Cada plugin de WordPress carga sus propios scripts y una CSP demasiado estricta tira embebidos de YouTube, formularios y editores. Móntala en modo Content-Security-Policy-Report-Only primero, mira los reportes una semana, y luego pásala a modo activo.
Vale la pena saber qué has dejado de necesitar respecto al post de hace una década. Hay reglas que en su día tenían sentido y hoy te están entorpeciendo:
preload en el HTML o cabeceras 103 Early Hints, que las activa el hosting, no tú.Si arrancas un proyecto nuevo en 2026 con la rama WordPress 7.0, casi todo el .htaccess útil son las reglas de redirección, las cabeceras de cache y las cuatro cabeceras de seguridad. El resto sobra el 90% del tiempo.
Hay un caso en el que no merece la pena entrar al archivo: si tu hosting es gestionado y ya te trae cabeceras de cache, redirección a HTTPS y firewall en el panel, modificar el .htaccess te puede generar conflictos invisibles. Antes de copiar reglas, abre el panel del hosting y revisa qué te están aplicando ya. La regla duplicada no rompe nada normalmente, pero la regla contradictoria sí.
Y si vas a tocar muchas redirecciones, ahórrate el .htaccess y monta un plugin tipo Redirection o tira del módulo nativo de Rank Math: te queda registrado en la base de datos, con buscador, y los 404 se ven en un listado. Para 5 redirecciones el .htaccess es más rápido; para 500, te vas a volver loco.
WordPress lo regenera con las reglas básicas la próxima vez que entres en Ajustes → Enlaces permanentes y pulses guardar. Mientras tanto, las URLs amigables dejan de funcionar y todo el sitio te tira 404. Por eso conviene tener un .bak antes de tocar.
No. Nginx ignora por completo el .htaccess y las reglas hay que pasarlas a su sintaxis propia en el archivo de configuración del servidor. Si tu hosting es Nginx puro, pídele al soporte que te aplique las reglas o usa un plugin de WordPress que actúe a nivel de PHP.
En Core Web Vitals notas mejora sobre todo en la segunda visita, no en la primera. El navegador deja de pedir imágenes, fuentes y CSS cacheados, y el TTFB de las páginas estáticas baja. Si ya usas WP Rocket o LiteSpeed Cache, el plugin pone esas reglas por ti y duplicar las tuyas no aporta.
Como capa extra sí, pero no como única defensa. Combínalo con autenticación en dos factores, contraseñas largas y un plugin que limite intentos de login. Si trabajas con IP dinámica, sáltate la regla de IP y enfoca la defensa en 2FA y firewall.
Sí, sobre todo en hostings compartidos sobre Apache o LiteSpeed. Para redirecciones, cabeceras de seguridad y bloqueos rápidos no hay nada más cómodo. Lo que ha cambiado es el peso: hace diez años era el centro de la optimización; hoy es una pieza más, junto a CDN, plugin de cache y panel del hosting.
La referencia es la guía oficial de htaccess en Apache 2.4. Para reglas específicas de WordPress, tienes plugins de administración que añaden y revierten cambios sin bajar al fichero.
Sebas says:
hola muy buen post. Era justo lo que estaba buscando
me gustaria usar el de limitaar el acceso por IP… pero que pasa cuando cambia mi IP? o sea,, por lo que se las IPs no son siempre las mismas..
No pasa nada con eso o que ?
Gracias.