¿Qué es Googlebot? Cómo rastrea, renderiza e indexa tu sitio web

TL;DR. Googlebot es el nombre paraguas para los rastreadores que Google utiliza para descubrir, renderizar e indexar contenido web. No es un solo robot, es una familia. El miembro más importante es Googlebot Smartphone, que rastrea la versión móvil de tu sitio con un Chromium sin interfaz gráfica que sigue la última versión estable de Chrome. El rastreo, la renderización y la indexación son tres fases separadas que pueden ocurrir con horas o días de diferencia. La mayoría de los problemas de “Googlebot no puede ver mi página” provienen de JavaScript que falla silenciosamente en la fase de renderizado, no en la de rastreo. El resto de esta guía cubre la familia de bots, el pipeline de tres fases, cómo verificar que una petición sea realmente de Googlebot, las preguntas habituales sobre robots.txt y presupuesto de rastreo, y cómo se compara Googlebot hoy con Bingbot, GPTBot, PerplexityBot y ClaudeBot.

Qué es realmente Googlebot (en palabras sencillas)

Googlebot es el programa que Google usa para obtener páginas web y añadirlas a su índice. Cuando publicas una nueva entrada de blog y finalmente aparece en los resultados de búsqueda, ese viaje empieza con Googlebot solicitando la URL, descargando el HTML, ejecutando el JavaScript y pasando el resultado al sistema de indexación de Google. Sin Googlebot, tus páginas no existen para la búsqueda de Google.

Hay dos matices que conviene aclarar de entrada. Primero, “Googlebot” se usa a veces de forma laxa para referirse a “cualquier rastreador de Google”. Estrictamente hablando, Googlebot es el rastreador que obtiene páginas para el índice principal de búsqueda. Existen otros rastreadores de Google (AdsBot para la calidad de páginas de destino, Storebot para fichas de Shopping, Google-Extended para exclusiones de entrenamiento de IA), pero son bots distintos con objetivos y reglas diferentes. Sé específico sobre cuál te refieres cuando depuras.

Segundo, Googlebot no es un scraper. Un scraper toma lo que puede de tu página sin permiso y usa los datos como quiere. Googlebot lee tu archivo robots.txt antes de cada rastreo, respeta las metaetiquetas noindex, se auto-limita cuando tu servidor se ralentiza e identifica su agente de usuario en las cabeceras para que puedas verificar que la petición viene realmente de Google. Si ves un hit de “Googlebot” en tus logs y está machacando tu origen sin retroceder, casi seguro no es Googlebot real. Es alguien suplantando el user-agent.

Googlebot es en realidad una familia de rastreadores

El bot que más debes tener en mente es Googlebot Smartphone, que rastrea por defecto la versión móvil de tu sitio desde que Google finalizó el indexado mobile-first a mediados de 2023. Los rastreos de escritorio siguen existiendo, pero ahora son secundarios. Aquí está el árbol familiar con las cadenas de agente de usuario exactas que publica Google:

El marcador W.X.Y.Z en los agentes de Smartphone y Desktop no es literal. Google sustituye la versión real de Chromium en tiempo de petición, y esa versión avanza siguiendo la última estable de Chrome. A fecha de hoy, eso significa que el motor de renderizado de Googlebot está a pocas semanas de lo que Chrome envía al público. Si tu sitio usa una característica de JavaScript que requiere Chrome 130+, probablemente Googlebot la soporte. Si depende de algo aún no lanzado, Googlebot no. Esta es la clave que muchos debates sobre “¿mi JS es demasiado moderno para Googlebot?” pasan por alto: el renderizador del bot está actualizado, no congelado en Chrome 41 como hace años.

El pipeline de tres fases: Rastreo, Renderizado, Indexado

El trabajo de Googlebot se divide en tres fases distintas. No ocurren al mismo tiempo, y un retraso o fallo en cualquiera de ellas puede dejar tu página fuera de los resultados. La propia documentación de Google lo resume así: “Google procesa las apps web JavaScript en tres fases principales: 1. Rastreo 2. Renderizado 3. Indexación.” Comprender los límites entre estas fases es lo que separa a los SEOs que depuran problemas de indexado de quienes adivinan.

Fase 1: Rastreo

Googlebot coge una URL de su cola, envía una petición HTTP y recibe la respuesta HTML en bruto. Y ahí acaba esta fase. Aún no se ejecuta JavaScript ni se examina contenido renderizado. El rastreador lee el código de estado, las cabeceras (incluidas las de caché, X-Robots-Tag y redirecciones) y el cuerpo HTML sin procesar. Las URLs provienen de un conjunto que Google genera a partir de sitemaps XML, enlaces internos de páginas ya indexadas, enlaces externos y envíos directos mediante la herramienta de Inspección de URL.

Si la respuesta HTML ya contiene todo lo que debe indexarse (el caso clásico SSR), Googlebot tiene suficiente para continuar. Si el HTML bruto está casi vacío y el contenido lo inyecta JavaScript después, la página pasará a la fase de renderizado. Aquí es también donde Googlebot lee el archivo robots.txt antes de cualquier rastreo. Si una URL está desautorizada, Googlebot ni siquiera la solicita.

Fase 2: Renderizado

Si la página necesita JavaScript para mostrar su contenido, Googlebot entrega la URL al Web Rendering Service (WRS). El WRS es un Chromium sin UI que carga la página en un entorno similar a un navegador, ejecuta los scripts y produce el HTML final renderizado. La documentación lo explica con frialdad: “Cuando los recursos de Google lo permiten, un Chromium headless renderiza la página y ejecuta el JavaScript.”

La frase “cuando los recursos de Google lo permiten” hace mucho trabajo. Renderizar es caro (navegador completo, JS arbitrario, peticiones de red), así que Google lo agrupa en lotes y lo pone en cola. Las páginas pueden permanecer ahí segundos, horas o, en el peor caso, días. La guía oficial es deliberadamente vaga: “La página puede estar en esta cola unos segundos, pero puede tardar más que eso.”

Este retraso de renderizado es el mayor problema práctico con sitios renderizados vía JS. Tu post puede rastrearse en minutos tras publicarse pero no renderizarse hasta 24 horas después; tu contenido no aparece en búsquedas hasta el día siguiente aunque Google haya “visto” la URL. Las páginas puramente SSR se saltan esta cola.

Fase 3: Indexación

Una vez que Googlebot tiene el HTML final (directo del rastreo o del WRS), el sistema de indexación analiza el documento, extrae texto, clasifica el contenido, evalúa señales de ranking y lo almacena en el índice. Desde aquí la página puede aparecer en resultados. La indexación tampoco es instantánea; puede tomar minutos u horas adicionales tras el renderizado, pero en este punto la labor de Googlebot sobre esa URL ha terminado y el resto depende de los algoritmos de ranking.

Qué rompe la renderización de JavaScript (y cómo detectarlo)

La mayoría de los problemas de “Googlebot no ve mi contenido” son de renderizado, no de rastreo. El rastreo casi siempre funciona; la página simplemente no se renderiza como esperaba el desarrollador. Estos seis fallos son los que más veo en clientes de SEOJuice, en orden aproximado de frecuencia.

1. Contenido que requiere interacción del usuario para cargarse

Si hacer clic en “Mostrar más” es la única forma de revelar una sección, Googlebot no la verá. El WRS ejecuta JS pero no hace clic ni se desplaza. Lo importante debe estar en el DOM al cargar, aunque esté oculto con CSS. Es el fallo más común y suele aparecer en librerías que montan perezosamente paneles de pestañas, acordeones y feeds de “cargar más”.

2. Lazy-loading sin señales adecuadas

Las imágenes y bloques lazy deben usar loading="lazy" o un Intersection Observer que el WRS pueda resolver. Librerías personalizadas que esperan eventos de scroll suelen fallar porque no hay scroll. Usa loading="lazy" en imágenes; para componentes, asegúrate de que se rendericen en el servidor o con un framework con SSR/hidratación adecuada.

3. Errores de JavaScript en ejecución

Si un script superior lanza una excepción sin capturar, los siguientes pueden no ejecutarse y dejar la página vacía. El WRS verá lo que se haya renderizado antes del error. Usa la herramienta de Inspección de URL y “Ver página probada” para ver exactamente lo que vio Googlebot, incluido el HTML renderizado y una captura.

4. Reglas de WAF y protección anti-bots

CAPTCHAs, Cloudflare Bot Fight Mode demasiado agresivo y bloqueos geográficos pueden devolver 403 o un challenge a las IPs de Googlebot. Lista blanca los rangos de IP verificados (publicados como googlebot.json) antes de activar cualquier “bloquear bots”. Compruébalo con Search Console al cambiar reglas de WAF.

5. Recursos bloqueados en robots.txt

Si tu robots.txt impide rastrear /static/ o /assets/, el WRS no puede obtener los bundles JS y CSS y la página se renderiza sin estilos o con JS roto. Permite a Googlebot rastrear rutas de assets aunque bloquees otras.

6. Contenido tras autenticación o cookies

Googlebot no inicia sesión, no acepta cookies de forma significativa ni mantiene sesión. Nada tras un login se indexará. Usa la API de indexación o datos estructurados para contenido de pago y especifica claramente qué está restringido.

Cómo verificar que una petición es realmente de Googlebot

La cadena de agente de usuario de Googlebot es trivial de falsificar. Cualquiera puede enviar una petición que diga ser Googlebot. Las peticiones reales provienen de rangos de IP propiedad de Google, y la única forma fiable de verificarlas es un reverse DNS seguido de un forward DNS. La doc oficial lo explica, pero la versión práctica es corta:

1. Toma la IP del log de acceso.
2. Haz un reverse DNS. El hostname debe acabar en .googlebot.com o .google.com.
3. Haz un forward DNS sobre ese hostname. Debe resolver a la misma IP.
4. Si ambas pasan, es Googlebot real. Si falla alguna, es spoof.

En consola: host 66.249.66.1 seguido de host crawl-66-249-66-1.googlebot.com. Si operas un sitio con mucho tráfico, automatiza esto; te sorprenderá cuántas veces un “pico de rastreo de Googlebot” es en realidad un scraper de terceros con el user-agent falsificado.

robots.txt y presupuesto de rastreo: las dudas tácticas de siempre

¿Cuánto rastreará Googlebot mi sitio?

Google lo llama presupuesto de rastreo. En sitios de menos de ~10 000 URLs casi nunca limita. Googlebot rastreará todo lo importante en un plazo razonable. Se vuelve crítico solo en sitios grandes con millones de URLs, e-commerce con facetas o donde Googlebot malgasta rastreos en duplicados o URLs de baja calidad. Los factores que Google publica son velocidad de rastreo (qué tan rápido responde tu servidor sin errores) y demanda de rastreo (popularidad y frecuencia de cambio de la URL).

¿Debo bloquear URLs de poco valor?

Sí, si consumen presupuesto en sitios grandes. Patrón típico: bloquear URLs de facetas, resultados de búsqueda interna, paginaciones más allá de la página 5, variantes con IDs de sesión y endpoints de administración. Usa robots.txt para bloquear en rastreo y meta noindex para bloquear en indexado. Hacen cosas distintas. Robots impide el rastreo; noindex permite rastrear pero no indexar.

¿Cómo acelero la indexación de una página nueva?

Envíala con la herramienta de Inspección de URL en Search Console. Lanza un rastreo fuera de la cola habitual (usa Google-InspectionTool, no Googlebot) y es más rápido que esperar. Además enlaza la nueva página desde una página con autoridad ya indexada para que el siguiente rastreo regular la descubra por el grafo de enlaces.

¿Por qué Googlebot rastrea mi entorno de desarrollo?

Porque en algún momento una URL de tu dominio staging o dev se filtró a la web pública (un enlace accidental, un resultado de búsqueda, un issue tracker abierto) y Googlebot sigue el grafo. Bloquea todo el dominio staging en robots.txt con Disallow: / y añade autenticación básica si el contenido es sensible.

Depuración de “Googlebot no puede ver esta página”

La versión sistemática de esta depuración hace cuatro comprobaciones, en orden, hasta que una devuelva respuesta clara.

Comprobación 1, Inspección de URL en Search Console. Pega la URL. La herramienta indica si Google la rastreó e indexó, y cuándo, y permite “Ver página probada” para ver el HTML renderizado y un screenshot. Si falta tu contenido, el problema es de renderizado. Si la página devuelve un estado distinto de 200, el problema es de rastreo. Esta sola prueba resuelve ~70 % de las investigaciones.

Comprobación 2, curl con el user-agent de Googlebot. Ejecuta curl -A "Mozilla/5.0 ... Googlebot/2.1 ..." https://tusitio.com/ruta. Si tu servidor devuelve contenido distinto para Googlebot que para un navegador normal, lo verás aquí. El cloaking (intencionado o no) es causa común de problemas misteriosos.

Comprobación 3, auditoría de robots.txt y metaetiquetas. Visita https://tusitio.com/robots.txt. Confirma que la URL no esté bloqueada. Luego revisa el código fuente y busca noindex. Sorprende cuántos casos son una etiqueta noindex que quedó tras un despliegue de staging.

Comprobación 4, análisis de logs del servidor. Filtra los accesos de Googlebot verificado en los últimos 30 días. Si la URL nunca aparece, es un problema de descubrimiento: Googlebot no sabe que existe. Añádela al sitemap y enlázala. Si aparece pero siempre devuelve 4xx o 5xx, corrige el error antes de reintentar. SEOJuice realiza este análisis de logs en cada sitio conectado y avisa la primera vez que una URL clave deja de recibir tráfico de Googlebot real, lo que suele detectar problemas antes de que afecten al ranking.

Googlebot vs Bingbot vs los rastreadores de IA

Googlebot solía ser el único rastreador en el que la mayoría pensaba; eso cambió. Así se comparan los principales rastreadores web en 2026:

Dos implicaciones prácticas. Primero: los rastreadores de IA renderizan JavaScript peor que Googlebot. Si tu contenido depende de renderizado en cliente, quizá posiciones bien en Google pero seas invisible para ChatGPT, Perplexity y Claude: verán una página vacía. La solución es la misma que necesita Googlebot: renderizar en servidor o prerenderizar lo esencial. Nuestro verificador de visibilidad en IA gratuito te dice en un minuto si los principales motores de IA ven tu contenido. Segundo: cada rastreador de IA tiene sus propias directivas en robots.txt. User-agent: GPTBot bloquea el crawler de OpenAI, User-agent: Google-Extended bloquea el de Gemini, User-agent: Googlebot sigue controlando la búsqueda normal. Si quieres aparecer en Google Search pero no en entrenamientos de IA, define reglas separadas.

Preguntas frecuentes

¿Qué es Googlebot?

Googlebot es el rastreador web que Google usa para descubrir y descargar páginas para indexarlas y mostrarlas en resultados. Es una familia de rastreadores (Smartphone, Desktop, Image, Video, News) con cadenas de agente y propósitos distintos, pero la mayoría de debates sobre “Googlebot” se refieren a Googlebot Smartphone, rastreador principal desde que Google completó el indexado mobile-first en 2023.

¿Googlebot ejecuta JavaScript?

Sí. El Web Rendering Service (WRS) es un Chromium sin interfaz que ejecuta JS en las páginas que lo necesitan. La versión de Chromium sigue las estables recientes, por lo que las funciones modernas suelen funcionar. El problema es la cola de renderizado: incluso cuando JS se ejecuta bien, puede ocurrir segundos, horas o días después del rastreo inicial. Las páginas SSR se saltan la cola.

¿Cómo verifico si una petición es realmente de Googlebot?

Haz un reverse DNS a la IP. Los hits reales resuelven a hostnames que terminan en .googlebot.com o .google.com. Luego haz un forward DNS a ese hostname; debe devolver la misma IP. Si falla algún paso, es user-agent falsificado. La cabecera UA sola no prueba nada.

¿Puedo bloquear Googlebot?

Sí. Añade User-agent: Googlebot seguido de Disallow: / en tu robots.txt. Esto bloquea el rastreo, por lo que la página no se indexará ni aparecerá en Google. Para control granular, usa meta noindex en páginas individuales (permite rastrear pero no indexar) o bloquea rutas concretas en robots.txt. No bloquees a Googlebot el acceso a tus bundles CSS y JS: el servicio de renderizado los necesita.

¿Googlebot es lo mismo que GPTBot o PerplexityBot?

No. Son rastreadores distintos, de compañías diferentes y con objetivos distintos. Googlebot indexa la web para Google Search. GPTBot recolecta datos para ChatGPT. PerplexityBot recupera contenido para el motor de respuestas de Perplexity. Cada uno tiene su propio user-agent y obedece (o no) sus directivas de robots.txt. Puedes permitir Googlebot y bloquear GPTBot, o cualquier combinación, definiendo reglas separadas.

¿Por qué Googlebot aún no indexa mi página nueva?

Las causas más comunes, en orden: la página no está enlazada desde ninguna URL indexada (Googlebot no la conoce), devuelve un código distinto de 200, tiene meta noindex, está bloqueada por robots.txt o su contenido depende de JS que el servicio de renderizado aún no procesó. Usa la herramienta de Inspección de URL para comprobarlo; “Ver página probada” muestra exactamente lo que vio Googlebot y es la forma más rápida de diagnosticar. Las páginas nuevas suelen tardar de horas a días en indexarse, más si tu sitio tiene baja frecuencia de rastreo.

¿Puede Googlebot leer contenido dentro de iframes?

Sí, pero se trata por separado de la página padre. El contenido dentro de un iframe se asocia a la URL del iframe, no a la página que lo embebe. Si pones tu contenido principal en un iframe, repartes la señal de indexado en dos URLs y debilitas ambas. No lo hagas para contenido que deba asociarse a la página principal.

La conclusión sobre Googlebot

Si solo recuerdas tres cosas de Googlebot, que sean estas. Primero, es una familia de rastreadores y Googlebot Smartphone es el que importa para casi todos los sitios desde el mobile-first. Segundo, el pipeline tiene tres fases (rastreo, renderizado, indexado) y la mayoría de problemas viven en la fase de renderizado, no en la de rastreo; por eso “Ver página probada” en Search Console es la superficie de depuración más útil. Tercero, los rastreadores de IA (GPTBot, PerplexityBot, ClaudeBot) renderizan JS peor que Googlebot, así que optimizar para el renderizador de Googlebot también hace visible tu contenido en la búsqueda de IA, pero no siempre al revés. La solución a “los motores de IA no me citan” suele ser la misma que a “Googlebot no ve mi contenido”: renderizar en servidor, incluir lo crítico en el HTML inicial y no esconderlo tras JS que falla en silencio.

Relacionado: SEO para Single Page Applications • Answer Engine Optimization (AEO) • Herramienta gratuita de auditoría SEO • Comprobador gratuito de visibilidad en IA