Por qué Google no me indexa: bots y crawl budget (2026)

Publicas una página nueva. Pasa una semana. Dos. Cuatro. Sigues sin verla en Google.

Le echas la culpa a “el algoritmo”, a la calidad del contenido, a un supuesto castigo. Casi siempre no es nada de eso. Es que Googlebot ni siquiera ha pasado a leerla. Y si pasó, lo hizo con prisa y se fue.

Vamos a desmontar por qué.

El dato que casi nadie te enseña

Según el informe Bad Bot Report 2025 de Imperva, en 2024 el 49,6 % de todo el tráfico web mundial fue bot. La mitad de internet, robots. Y de ese 49,6 %, más del 60 % fue bot malicioso (scrapers, vuln scanners, fakers de stats, crawlers de IA fuera de control).

Traducido: si tu hosting recibe 10.000 peticiones al día, 5.000 son robots. De esas 5.000, unas 3.000 son robots que no te traen ni un visitante humano. Solo consumen CPU, RAM, conexiones SQL y bandwidth.

¿Quién paga la cuenta? Tu hosting. Y tu PHP. Y tu base de datos.

Cómo afecta esto a Google

Google tiene un concepto técnico llamado Crawl Budget (documentación oficial desde 2017). Lo resumido:

Googlebot mide cuánto puede pedirte sin hundir tu servidor. Si tu servidor responde rápido, Googlebot pide más. Si tu servidor responde lento o devuelve errores 5xx, Googlebot reduce automáticamente la frecuencia con la que vuelve.

Es decir: Google no te castiga por ir lento. Pero deja de venir tanto. Y si no viene tanto, no indexa páginas nuevas. Y si no indexa páginas nuevas, no rankeas. Y si no rankeas, no hay tráfico.

¿Cuál es el resultado típico para una web pequeña-mediana con hosting compartido y sin filtro de bots?

Google Search Console muestra “Detectada — no indexada” en el 40-70 % de las URLs nuevas
“Tiempo medio de respuesta del servidor” en GSC: 1,5-4 segundos (Google quiere < 600 ms)
Páginas que tarda 6-12 semanas en indexar, si lo hace

Y todo eso, mientras Bing — que tiene un crawl budget más generoso y soporta IndexNow para forzar indexación bajo demanda — sí está indexando las mismas URLs en horas.

(De ahí que en nuestros 8 sitios el 74,5 % del tráfico SEO venga de Bing y no de Google.)

Quién se está comiendo tu crawl budget

No todos los bots son iguales. Hay 4 categorías que vemos repetidas en cada hosting que auditamos:

1. Scrapers de contenido

Webs que copian tu contenido para republicarlo en sitios afiliados, agregadores fake o competidores directos. Suelen venir de IPs residenciales rotativas para que no los identifiques fácilmente. Pueden hacer cientos de peticiones por minuto durante horas.

2. Vulnerability scanners

Bots que buscan agujeros conocidos: /wp-admin/, /.env, /wp-login.php?action=lostpassword, /xmlrpc.php, /wp-config.php.bak. Pegan a tu web miles de URLs inexistentes esperando colarse por alguna. Generan errores 404 masivos que también consumen recursos.

3. AI crawlers desbocados

Algunos crawlers de IA (no los oficiales como GPTBot o ClaudeBot, que respetan robots.txt) van a saco: GPTBot-clones, scrapers de datasets, crawlers de “investigación” sin agente legítimo. Pueden hacer 20-50 requests por segundo durante minutos.

4. Ad-stat inflators

Bots que simulan clicks o impresiones en anuncios para hinchar artificialmente las stats de redes publicitarias o competidores. Son los más sigilosos porque imitan user-agents de navegador real.

Suma los 4 → tienes tu hosting saturado el 50-80 % del día sirviendo basura.

Síntomas que indican que tienes el problema

Si te suena alguno de estos, casi seguro tienes bots comiéndote el crawl budget:

🚨 Páginas nuevas tardan más de 2 semanas en aparecer en Google
🚨 GSC muestra “Detectada — no indexada” o “Rastreada — no indexada” en muchas URLs
🚨 El “Tiempo medio de respuesta del servidor” en GSC > 800 ms
🚨 Tu cPanel / panel de hosting reporta picos de CPU sin que tú entiendas por qué
🚨 Tu factura de hosting va subiendo aunque el tráfico humano no
🚨 Tu base de datos (MySQL/MariaDB) supera 80 % de carga sin estar en hora pico
🚨 Visitas en tu plugin de stats (Jetpack, Plausible, etc.) NO cuadran con las requests del servidor
🚨 Tu CDN/Cloudflare marca un porcentaje brutal de cache MISS

Si tienes 3 o más de estos: tu crawl budget está siendo asaltado.

Cómo arreglarlo (4 niveles según tu caso)

Nivel 1: Cloudflare gratis (5 minutos)

Lo más fácil que puedes hacer si aún no usas Cloudflare:

Date de alta gratis en cloudflare.com
Apunta tu dominio a sus nameservers
Activa Bot Fight Mode (Security → Bots → ON)
Activa Browser Integrity Check (Security → Settings → ON)

Esto bloquea el 30-40 % del tráfico bot más obvio. Gratis. Sin tocar nada en WordPress.

Nivel 2: WAF gratis básico (20 minutos)

Si Cloudflare ya está pero no te basta:

En Cloudflare Dashboard → WAF → Custom Rules
Crea reglas que bloqueen:
- User-Agent que contenga “scrapy”, “selenium”, “headless”, “puppeteer”, “phantom”
- URLs como /xmlrpc.php, /wp-config.php, /.env, /.git/
- Países donde no tienes audiencia ni clientes (Block desde el editor)
Activa Super Bot Fight Mode si tu plan lo permite ($20/mes Pro)

Esto sube el bloqueo hasta el 60-70 % del bot malicioso.

Nivel 3: SeoNova WPO Toolkit, módulo de seguridad

Aquí ya entra una solución específica para WordPress que va más allá de Cloudflare:

SeoNova WPO Toolkit incluye un módulo de seguridad pensado para actuar como portero en la puerta de tu WordPress: identifica bots maliciosos en la primera línea PHP, antes de que cargue ningún plugin, ningún tema, ninguna query SQL.

Lo que hace en concreto:

Filtra patrones de bot conocidos sin ralentizar a usuarios reales (ni Googlebot ni Bingbot legítimos)
Bloquea inflators de stats publicitarios sin tocar tu inserción de ads
Detiene scrapers que copian tu contenido en masa
Ahorra hasta el 70-80 % de carga inútil en tu PHP/MySQL
Resultado: tu servidor responde rápido a Googlebot → crawl budget recuperado

A diferencia de plugins de seguridad genéricos (Wordfence, iThemes, Sucuri), no carga PHP entero para decidir bloquear: lo decide antes. Por eso no penaliza tu Core Web Vitals.

Sirve para casos donde Cloudflare ya está al máximo pero el servidor sigue saturado, o donde quieres protección sin pagar Cloudflare Enterprise.

Nivel 4: Reverse proxy + WAF dedicado (avanzado)

Para sitios grandes (>500k pageviews/mes), lo serio es:

Nginx o Caddy como reverse proxy delante del WordPress
WAF dedicado: ModSecurity, OWASP CRS, o uno managed (Sucuri, StackPath)
Rate limiting agresivo a nivel de proxy
Fingerprinting de TLS para detectar headless browsers

Esto ya requiere DevOps. Si llegas aquí, contrata a alguien o ponnos un email.

Cómo medir si lo que has hecho funciona

Antes de aplicar cualquier solución, anota estos números:

Google Search Console → Estadísticas de rastreo: solicitudes/día y tiempo medio de respuesta
GSC → Cobertura del índice: URLs “Detectada — no indexada” + “Rastreada — no indexada”
GSC → Páginas → No indexadas: total
Tu panel de hosting: CPU media diaria + transferencia

Aplica la solución. Espera 14 días (Google necesita tiempo para reajustar crawl rate).

Vuelve a mirar los mismos números. Si han bajado los errores y subido las URLs indexadas, ha funcionado.

El cierre

“Google no me indexa” 9 de cada 10 veces NO es Google quien tiene la culpa. Es tu hosting saturado de bots maliciosos hablándole a Googlebot con un servidor que tarda 3 segundos en contestar.

Quita esos bots de en medio, deja tu hosting responder rápido, y Google vuelve. Sin trucos, sin esperar a “que pase la dance”, sin pagar agencia.

Es de los arreglos con mejor ROI técnico que puedes hacer en tu web este año. Hora y media de trabajo, beneficio durante meses.

Si quieres ver cómo está tu hosting de bots ahora mismo y qué módulo de WPO Toolkit te interesa, escríbenos en [email protected] o pásate por seonova.pro/es/optimizacion-wordpress.

Datos de Imperva Bad Bot Report 2025. Documentación de crawl budget: Google Search Central, 2017.

— El equipo de SeoNova

Por qué Google no te indexa: la culpa la tienen los bots (y cómo arreglarlo)

Resumen