El plugin de seguridad que bloqueó a Googlebot · WordPin 006

El directorio llevaba más de un año en producción. Listados de fontaneros, electricistas, abogados, fisioterapeutas: cada ficha con su localidad, sus datos de contacto y su mapa embebido. El tráfico orgánico era estable, con picos lógicos por estacionalidad. Nada llamativo. Nada raro.

El propietario del sitio me llamó por una caída progresiva en impresiones dentro de Google Search Console. No era un desplome brusco, sino una pérdida lenta, semana tras semana. Las visitas directas funcionaban bien. El sitio cargaba. Las fichas se abrían. Todo parecía normal.

Ese tipo de normalidad suele ser la peor. Cuando algo se rompe de forma visible, al menos deja una pista. Cuando falla solo para quien rastrea, el problema se esconde detrás de una fachada demasiado limpia.

La primera señal apareció en el informe de indexación de GSC. Varias URLs que antes estaban indexadas habían pasado a estado excluida, con notas de error de rastreo. Lo extraño era que esas mismas páginas cargaban perfectamente desde el navegador. Ni error visible, ni redirección, ni contenido vacío.

El plugin de seguridad instalado en el sitio era uno de los habituales, con firewall activo y protección anti-bots. Pero en ese momento no era sospechoso. Simplemente estaba ahí, como en miles de instalaciones WordPress.

Algo impedía que el rastreo completara su recorrido, pero el sitio no parecía roto. El síntoma apuntaba a una cosa, pero los datos decían otra.

Plugin de seguridad bajo sospecha: señales que no cuadran

Lo primero fue confirmar que el problema era real y no un retraso de Search Console. Revisé los datos de rastreo de los últimos 90 días. Las solicitudes habían bajado, sí, pero no de forma uniforme. Algunas rutas seguían siendo rastreadas sin problema. Otras, en cambio, mostraban respuestas 403 Forbidden intermitentes.

No eran errores 404 ni 5xx. Eran rechazos limpios: el servidor recibía la petición y la denegaba.

Las fichas de profesionales con parámetros de geolocalización y las páginas de archivo por localidad eran las más afectadas. Las páginas estáticas —inicio, contacto, aviso legal— respondían con 200 OK.

Si el fallo hubiera sido de contenido, habría visto plantillas rotas, títulos vacíos o respuestas inconsistentes. Si hubiera sido de servidor, el error habría sido más amplio. Pero aquello elegía a quién dejar pasar.

Lancé varias peticiones con cURL para comprobar si el comportamiento cambiaba según el user-agent:

curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://ejemplo.com/directorio/fontaneros-madrid/

HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 12 Sep 2025 08:41:22 GMT

curl -I -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://ejemplo.com/directorio/fontaneros-madrid/

HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=UTF-8

La diferencia era clara. El mismo recurso devolvía 200 OK con un user-agent de navegador y 403 Forbidden con el de Googlebot.

No me gustó.

Cuando una URL responde distinto según quién pregunta, dejo de mirar la página y empiezo a mirar las capas que deciden antes que WordPress.

Primera pista falsa: el archivo robots.txt

Un bloqueo selectivo por ruta podía sugerir que el archivo robots.txt estuviera mal configurado. Lo revisé directamente:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://ejemplo.com/sitemap_index.xml

Limpio. Sin directivas que afectaran a /directorio/ ni a ninguna ruta pública del sitio.

Además, robots.txt no genera respuestas 403 por sí mismo. Si Googlebot respetara un Disallow, dejaría de rastrear esa ruta, pero no recibiría una denegación activa. El rechazo venía de otra capa: servidor, CDN, firewall o aplicación.

El robots.txt quedaba descartado.

El falso culpable: hosting, CDN y caché

La segunda hipótesis apuntó al servidor. Algunos hostings aplican rate limiting a nivel de infraestructura para protegerse de picos de tráfico. Si Googlebot estaba haciendo demasiadas peticiones en poco tiempo, el servidor podía estar cortando el acceso antes de llegar a WordPress.

También revisé la capa de CDN. En muchos sitios, una petición atraviesa reglas anti-bots, caché de página, filtros geográficos o configuraciones heredadas que nadie recuerda haber activado.

Era un sospechoso cómodo. Demasiado cómodo.

Las primeras pruebas no ayudaron. Desde una IP externa, algunas URLs devolvían 200 OK. Desde otra, el patrón acababa en 403 Forbidden. Con user-agent de navegador, todo parecía limpio. Con Googlebot, el comportamiento volvía a torcerse.

Revisé cabeceras, respuestas cacheadas y comportamiento desde varias ubicaciones. No había página de desafío, ni cabeceras claras de bloqueo externo, ni variaciones consistentes entre regiones. Después fui al servidor: logs de acceso, reglas de Nginx y panel del hosting. Las peticiones estaban registradas, pero no había una regla de infraestructura justificando el rechazo.

Eso era lo peor del caso: cada capa parecía culpable durante diez minutos y luego se quedaba corta.

El servidor recibía la petición. La registraba. Y algo, después, decidía cerrarle la puerta.

Demasiado selectivo para ser una caída. Demasiado limpio para ser un error de red. Demasiado constante para ser casualidad.

El firewall que confundió al rastreador con una amenaza

Abrí los logs del plugin de seguridad casi por descarte. Era Wordfence, con el firewall de aplicación web activo en modo extendido.

No era mi primera opción. Si el bloqueo venía de ahí, esperaba encontrar una alerta evidente, una regla marcada como crítica o algún aviso reciente. Pero el panel estaba tranquilo. Demasiado tranquilo.

Entré en el tráfico en tiempo real y filtré por respuestas bloqueadas.

Ahí apareció el golpe.

No una entrada aislada. Decenas de registros con el mismo patrón: IPs que se presentaban como Googlebot, URLs del directorio, respuesta 403 y una regla de firewall aplicándose sin hacer ruido.

No cerré el caso todavía. Un user-agent se puede falsificar en dos segundos. Así que validé varias IPs mediante DNS inverso y resolución directa: primero comprobé que resolvían hacia un hostname legítimo de Google y después que ese hostname volvía a resolver contra la IP original.

# Ejemplo de comprobación simplificada

host 66.249.79.xx
xx.79.249.66.in-addr.arpa domain name pointer crawl-66-249-79-xx.googlebot.com.

host crawl-66-249-79-xx.googlebot.com
crawl-66-249-79-xx.googlebot.com has address 66.249.79.xx

El tráfico no solo decía ser Googlebot. En varios casos, lo era.

Aun así, no todas las entradas eran limpias. Algunas IPs no resolvían con claridad, otras correspondían a bots falsificando el user-agent, y varias peticiones quedaban mezcladas en la misma franja horaria. Separé los registros en dos grupos: bots falsos que solo imitaban la cabecera, y peticiones que superaban la comprobación de origen.

El problema real estaba en el segundo grupo. El firewall no solo bloqueaba impostores. También bloqueaba rastreo legítimo.

El WAF tenía una regla de limitación de velocidad que bloqueaba cualquier agente que superara cierto umbral de peticiones por minuto. Googlebot, al recorrer múltiples fichas del directorio en secuencia, superaba ese límite. Para el plugin de seguridad, un rastreador legítimo y un scraper agresivo se parecían demasiado.

Que un sitio cargue para ti no significa que cargue para quien más importa rastrearlo.

Crucé los timestamps de Wordfence con las caídas de rastreo en Google Search Console. Los períodos coincidían. Cada vez que Googlebot intentaba un rastreo profundo, el firewall le cortaba el paso después de unas pocas decenas de peticiones.

Cómo un plugin de seguridad puede bloquear a Googlebot

[2025-09-11 14:23:07] Firewall block — IP: 66.249.79.xx
  Rule: Rate limit exceeded (>60 hits/min)
  UA: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
  URL: /directorio/electricistas-valencia/
  Response: 403
  Layer: Wordfence WAF

[2025-09-11 14:23:09] Firewall block — IP: 66.249.79.xx
  Rule: Rate limit exceeded (>60 hits/min)
  UA: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
  URL: /directorio/abogados-sevilla/
  Response: 403
  Layer: Wordfence WAF

Había otra pieza. Una regla WAF personalizada heredada del administrador anterior bloqueaba peticiones sin cabecera Accept-Language, una medida pensada para frenar bots genéricos. Sobre el papel tenía sentido. En producción, no tanto.

Algunos rastreadores legítimos no envían siempre las mismas cabeceras que un navegador humano. Esa regla no bloqueaba Googlebot por llamarse Googlebot. Lo bloqueaba por no comportarse como un usuario de escritorio con navegador completo.

Los falsos culpables habían sido razonables. Robots.txt explicaba un problema de rastreo, pero no una respuesta 403. Hosting y CDN podían justificar un bloqueo por volumen, pero no dejaban huella clara. La causa estaba más cerca: dentro de WordPress, en una capa que llevaba meses funcionando en silencio.

Impacto acumulado en la indexación

El efecto SEO no fue inmediato, pero sí sostenido. Cada ciclo de rastreo interrumpido significaba que Google dejaba de refrescar parte del directorio. Algunas fichas pasaron a estado rastreada, no indexada actualmente. Otras dejaron de aparecer en los resultados.

Para un directorio local de profesionales, perder visibilidad en esas fichas equivalía a perder la razón de existir del proyecto.

Un error parcial suele ser más peligroso que una caída total, porque deja demasiadas cosas funcionando como para activar una alarma.

Ajustar la protección sin dejar la puerta abierta

La primera tentación era desactivar el plugin de seguridad por completo. Con eso el rastreo se habría restaurado al instante. Pero un directorio con cientos de fichas públicas, formularios de contacto y campos de búsqueda abiertos no puede quedarse sin protección ante ataques automatizados.

Quitar el firewall resolvía un problema y creaba otro peor.

Tampoco servía relajar los umbrales hasta un nivel absurdo. Eso habría dejado pasar scrapers reales y ataques que el firewall debía interceptar. No era cuestión de abrir todo, sino de enseñar al sistema a distinguir.

Afinar reglas sin desproteger rutas sensibles

Apliqué un ajuste en tres capas. Primero, configuré la protección teniendo en cuenta la verificación de Googlebot mediante DNS inverso y resolución directa antes de aplicar las excepciones necesarias. No bastaba con que una IP dijera ser Googlebot: tenía que resolver contra un dominio válido de Google y volver a coincidir con la IP de origen.

Segundo, ajusté la configuración de limitación de velocidad para que los rastreadores previamente verificados no quedaran afectados por esa restricción. No una lista blanca basada solo en el user-agent, porque eso es falsificable, sino una excepción aplicada tras verificar el origen del rastreador.

Tercero, ajusté la regla que bloqueaba peticiones sin Accept-Language. No la eliminé sin más: la dejé activa para bots genéricos, pero con bypass para rastreadores verificados.

# Regla WAF personalizada anterior:
# Bloquear peticiones sin Accept-Language
# Acción: block

# Regla WAF corregida:
# Bloquear peticiones sin Accept-Language
# Excepción: bots verificados mediante comprobación real de origen
# Acción: block con bypass para rastreadores legítimos verificados

Después repetí las pruebas con cURL simulando Googlebot. Las URLs del directorio devolvían 200 OK. También revisé los logs durante las siguientes sesiones de rastreo. Esa parte era importante: un problema de rastreo se confirma observando comportamiento repetido, no una respuesta aislada desde terminal.

Un firewall sin supervisión periódica no protege: decide por su cuenta y no siempre acierta.

El paso final fue solicitar una nueva inspección de las URLs afectadas desde Google Search Console y monitorizar los días siguientes. Las primeras 48 horas mostraron un repunte en solicitudes de rastreo aceptadas. En la siguiente semana, varias fichas que habían caído del índice empezaron a reaparecer.

No fue una recuperación instantánea, pero la tendencia era clara: las peticiones ya no se rechazaban, el plugin de seguridad seguía activo y el directorio volvía a ser visible para el rastreo real.

Configuré además alertas en Wordfence para revisar cualquier nuevo bloqueo registrado por el firewall durante los siguientes rastreos. Protección activa, rastreo permitido y una revisión inmediata si algo volvía a cruzarse en el camino.