En entornos WordPress y WooCommerce con tráfico real, el problema no es únicamente el ataque directo, sino el consumo inútil de recursos causado por crawlers agresivos, scrapers, librerías HTTP automatizadas, navegadores headless y agentes falsificados. Una estrategia sólida en .htaccess permite detener buena parte de ese tráfico antes de que cargue WordPress, PHP o MySQL.
La lógica correcta no consiste en bloquear “bots” de forma genérica. Consiste en construir una secuencia técnica con cuatro objetivos:
- rechazar automatización hostil evidente,
- permitir bots legítimos necesarios para indexación y previews,
- endurecer rutas y archivos sensibles del CMS,
- reducir superficie de exposición a nivel Apache.
1. Bloqueo inmediato de user-agents automatizados
La primera capa debe ejecutarse al inicio del archivo y cortar solicitudes primitivas o abiertamente automatizadas. Esto reduce carga antes de que el sitio procese la petición.
<IfModule mod_rewrite.c>
RewriteEngine On
# User-Agent vacío o sospechoso
RewriteCond %{HTTP_USER_AGENT} ^-?$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^$ [NC,OR]
# Librerías HTTP y herramientas automatizadas
RewriteCond %{HTTP_USER_AGENT} ^python-requests [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^python-urllib [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^curl/ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^wget/ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-http-client [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^node-fetch [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^axios [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Scrapy [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^HeadlessChrome [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^PhantomJS [NC]
RewriteRule .* - [F,L]
</IfModule>Este bloque corta una gran porción de tráfico no humano que normalmente no aporta valor comercial al sitio. Técnicamente, su ventaja es que niega antes de que el CMS inicialice sesiones, rutas internas, plugins o consultas a base de datos.
Qué protege esta sección
- scraping automatizado de catálogo,
- enumeración masiva de URLs,
- pruebas ofensivas básicas,
- consumo innecesario de CPU y procesos PHP.
2. Whitelist explícita para bots legítimos
Un error común es permitir tráfico amplio usando cadenas genéricas como Mozilla. Eso no es una validación confiable. Lo correcto es definir una whitelist explícita de bots y servicios útiles.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} Googlebot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} AdsBot-Google [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Googlebot-Image [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Google-InspectionTool [NC,OR]
RewriteCond %{HTTP_USER_AGENT} bingbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Applebot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} facebookexternalhit [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Twitterbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} LinkedInBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} WhatsApp [NC,OR]
RewriteCond %{HTTP_USER_AGENT} UptimeRobot [NC]
RewriteRule .* - [L]
</IfModule>Esta sección permite indexación orgánica, revisión técnica, anuncios, previews sociales y monitoreo, sin dejar abierta la puerta a cualquier agente que simplemente se autodenomine navegador.
Qué protege esta decisión
- evita falsos positivos contra SEO legítimo,
- conserva previews en WhatsApp, Facebook, X y LinkedIn,
- mantiene rastreo funcional para buscadores reales.
3. Bloqueo de métodos HTTP innecesarios
Muchos ataques, pruebas de reconocimiento o debugging remoto utilizan métodos HTTP que un sitio comercial no necesita exponer públicamente. Negarlos es una medida simple y efectiva.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|DEBUG|CONNECT) [NC]
RewriteRule .* - [F,L]
</IfModule>Esto reduce superficie de ataque y corta interacciones anómalas que no deberían formar parte del tráfico normal de un WordPress o WooCommerce público.
4. Endurecimiento específico de WordPress
Una protección seria debe entender el CMS que está defendiendo. WordPress expone rutas y archivos históricamente abusados. El objetivo no es romper el core, sino cerrar acceso a zonas que no deben ser accesibles desde fuera.
Bloqueo de xmlrpc.php
<Files "xmlrpc.php">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order allow,deny
Deny from all
</IfModule>
</Files>Este punto es importante porque xmlrpc.php sigue siendo un vector clásico para fuerza bruta, amplificación y abuso automatizado.
Protección de rutas internas del core
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>La lógica aquí es impedir que archivos internos o rutas auxiliares sean invocados directamente desde el exterior.
Bloqueo de ejecución de PHP en uploads
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/uploads/.*\.(php|php\.[0-9]+|phtml|phar)$ - [F,L,NC]
</IfModule>Esta regla es crítica en instalaciones donde existe riesgo de subida maliciosa de archivos. El directorio uploads debe almacenar contenido, no ejecutar código.
5. Protección contextual para WooCommerce y plugins
No todos los abusos buscan comprometer el servidor; muchos buscan disparar funciones del negocio de forma automatizada. WooCommerce y extensiones de wishlist suelen ser un blanco frecuente.
Ejemplo: bloquear una acción sensible por GET
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} add_to_wishlist [NC]
RewriteCond %{REQUEST_METHOD} GET
RewriteRule .* - [F,L]
</IfModule>Este enfoque obliga a que ciertas acciones ocurran en flujos más controlados, normalmente AJAX o POST, y evita invocaciones masivas desde bots que ejecutan enlaces directos.
Ejemplo: bloquear combinaciones anómalas de parámetros
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} add_to_wishlist=.*add-to-cart= [NC]
RewriteCond %{HTTP_USER_AGENT} !(Mozilla|Chrome|Safari|Firefox) [NC]
RewriteRule .* - [F,L]
</IfModule>La idea aquí es identificar combinaciones impropias de parámetros que suelen delatar automatización no deseada o pruebas masivas sobre flujos del eCommerce.
6. Detección de suplantación de agentes conocidos
Un bot malicioso no siempre llega con identidad honesta. Muchos intentan suplantar servicios legítimos, especialmente agentes de previsualización social. Por ello, no basta con confiar en el nombre declarado en el User-Agent; también debe revisarse el origen.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} meta-externalagent [NC]
RewriteCond %{REMOTE_ADDR} !^66\.220\. [NC]
RewriteCond %{REMOTE_ADDR} !^69\.63\. [NC]
RewriteCond %{REMOTE_ADDR} !^69\.171\. [NC]
RewriteCond %{REMOTE_ADDR} !^157\.240\. [NC]
RewriteCond %{REMOTE_ADDR} !^173\.252\. [NC]
RewriteCond %{REMOTE_ADDR} !^31\.13\. [NC]
RewriteRule .* - [F,L]
</IfModule>La protección aquí no depende de lo que el cliente afirma ser, sino de si su origen técnico es coherente con esa identidad. Esta técnica es particularmente útil contra falsificación de agentes de vista previa.
7. Protección de archivos ocultos y extensiones sensibles
Los bots agresivos prueban rutas previsibles buscando archivos de entorno, respaldos, configuraciones, logs o residuos de despliegue. Ese acceso debe negarse explícitamente.
Bloqueo de dot files
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule "(^|/)\.(?!well-known/)" - [F,L]
</IfModule>Esta regla evita la exposición de archivos ocultos, salvo la excepción necesaria para .well-known cuando se utilizan validaciones o certificados.
Bloqueo de extensiones sensibles
<FilesMatch "\.(env|log|ini|bak|sql|sh|git|svn|htpasswd|DS_Store)$">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order allow,deny
Deny from all
</IfModule>
</FilesMatch>Esto evita exposición accidental de artefactos operativos o credenciales indirectas.
8. Headers de seguridad a nivel Apache
Una estrategia bien construida en .htaccess no solo bloquea tráfico; también le dice al navegador cómo debe comportarse frente al sitio.
<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 X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always unset X-Powered-By
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>Este bloque endurece la respuesta HTTP y reduce exposición innecesaria. No detiene crawlers por sí mismo, pero sí forma parte de una postura de seguridad madura.
9. El orden de las reglas importa
Uno de los puntos más importantes es la secuencia de ejecución. Un .htaccess defensivo debe seguir una jerarquía lógica:
- bloqueo inmediato de automatización evidente,
- whitelist controlada para bots útiles,
- restricción de métodos HTTP,
- endurecimiento específico del CMS,
- protección de archivos sensibles,
- headers de seguridad.
Si el orden se altera, es fácil generar falsos positivos, romper tráfico legítimo o dejar huecos por prioridad incorrecta entre condiciones.
10. Qué se logra técnicamente con este enfoque
- menos carga sobre Apache, PHP-FPM y MySQL,
- menos ruido en logs y métricas,
- menor exposición de rutas internas de WordPress,
- reducción de scraping automatizado y crawlers agresivos,
- preservación de SEO, previews sociales y monitoreo legítimo.
Conclusión técnica
Un .htaccess bien diseñado no sustituye al hardening del servidor, al monitoreo ni a la actualización del CMS. Pero sí cumple una función decisiva: filtra tráfico hostil en la capa más temprana posible. En instalaciones WordPress y WooCommerce con exposición pública, esa diferencia se traduce en menos consumo, menos superficie de abuso y mayor control operativo.
La clave no está en bloquear “todo”, sino en clasificar con precisión: qué debe entrar, qué debe salir de inmediato, qué rutas jamás deben responder y qué señales técnicas delatan automatización maliciosa.