Síntomas
Tras varias semanas conviviendo con bots agresivos (de IA, scrapers, etc.) o tras un endurecimiento del rate limit del servidor, una web puede empezar a perder visibilidad en Google de forma repentina:
Search Console empieza a mostrar errores al rastrear URLs (timeouts, accesos denegados, "no se puede acceder al sitio").
Google Ads desactiva los anuncios al no poder validar la página de destino, normalmente con avisos del tipo "Página de destino no disponible", "Google-InspectionTool no puede acceder" o errores similares.
Google Merchant Center rechaza productos porque
Google-Shopping-Feedsno descarga el feed.Caída brusca de tráfico orgánico y de conversiones, sin que el cliente haya tocado nada en su web.
El servidor responde con normalidad para usuarios normales: el problema solo afecta a los bots de Google.
Por qué ocurre
Para protegerse de la oleada actual de bots y scrapers de IA, los servidores aplican un rate limit por IP a nivel de kernel. Si una misma IP supera un número de peticiones por segundo (en TropicalServer el límite por defecto está en torno a 20 visitas/segundo), el kernel la bloquea automáticamente.
El problema es que los bots oficiales de Google (Googlebot, Google-InspectionTool, Google-Shopping-Feeds, AdsBot-Google, etc.) son muy agresivos cuando rastrean tiendas grandes o sitios con muchas URLs y suelen sobrepasar ese límite. Al activarse el rate limit:
El bloqueo es a nivel de kernel, no de Imunify360 ni de Mod Security, por lo que no aparece CAPTCHA ni log típico en cPanel.
El bloqueo solo se libera reiniciando el servidor o añadiendo la IP/red a la lista blanca del rate limit.
Diagnóstico
Indicios que confirman que el problema es el rate limit y no otra cosa:
La web carga perfectamente desde un navegador o desde el móvil con datos.
Los logs de Apache/LiteSpeed dejan de recibir peticiones de las IPs de Google a partir de cierto momento (no aparecen errores 4xx/5xx, simplemente desaparecen).
Search Console o el panel de Ads muestran errores justo desde el día en que se aplicó el rate limit o desde que el bot empezó a aumentar peticiones.
Otros bots legítimos (Bing, Yandex) pueden tener el mismo problema.
Solución: añadir las IPs oficiales de Google a la lista blanca del rate limit
La defensa por rate limit solo se puede aplicar a partir de IPs/CIDR; no funciona con DNS inverso ni por User-Agent. Lo correcto es añadir a la lista blanca los rangos publicados oficialmente por Google.
Google mantiene dos listas en formato JSON que se actualizan periódicamente:
Rangos generales de Google: https://www.gstatic.com/ipranges/goog.json
Rangos específicos de rastreadores (Googlebot, AdsBot, etc.): https://developers.google.com/static/crawling/ipranges/common-crawlers.json
El procedimiento que aplica nuestro equipo es:
Descargar las dos listas y extraer los bloques CIDR (IPv4 e IPv6).
Añadirlos a la lista de excepciones del rate limit, junto con los User-Agents conocidos (
Google-InspectionTool,Google-Shopping-Feeds,AdsBot-Google) cuando el sistema lo permite.Reiniciar el servidor para liberar los bloqueos vigentes a nivel de kernel.
Verificar en Search Console (URL Inspection) que el bot vuelve a acceder, y en Google Ads que los anuncios pasan de nuevo a estado activo (suele tardar entre minutos y unas horas en revalidarse).
Lo que NO recomendamos
Quitar el rate limit por completo: dejaría el servidor expuesto a los bots de IA agresivos y volverían los problemas de lentitud y consumo de recursos.
Whitelistear solo por User-Agent o por DNS inverso: el bloqueo del kernel es por IP, no se aplica a esos criterios.
Añadir IPs sueltas que se vean en logs: los rangos de Google cambian y aparecen IPs nuevas; hay que usar siempre los rangos oficiales completos.
Medidas adicionales recomendadas
Cloudflare delante del dominio: ayuda a frenar bots maliciosos antes de que lleguen al servidor y permite reglas personalizadas (challenge a bots, geobloqueo, etc.). Reduce la presión sobre el rate limit.
Bloqueo por
.htaccesso reglas WAF de los User-Agents claramente abusivos (GeedoShopProductFinder, ByteSpider y similares), tal como ya cubrimos en otros artículos sobre lentitud por bots.Revisar Search Console y Google Ads tras la intervención para confirmar que las URLs vuelven a rastrearse y los anuncios se aprueban.
Solicitar la actuación al soporte
Esta intervención (añadir las IPs y reiniciar) la realiza nuestro equipo de soporte. Para abrir el caso necesitamos:
Dominio o dominios afectados.
Capturas de Search Console o de Google Ads donde se vean los errores.
Confirmación del cliente para añadir los rangos oficiales de Google a la lista blanca del rate limit y reiniciar el servidor en una ventana acordada.
Importante: estos bloqueos no son culpa del hosting ni de la web del cliente, sino de la combinación entre la agresividad creciente de los bots de Google y las medidas de protección frente a bots de IA que se aplican en los servidores. La solución pasa por equilibrar ambos lados con la lista blanca oficial.