Antes de que una página pueda posicionar tiene que pasar por dos procesos distintos que se confunden constantemente: el rastreo (crawling), que es la visita de un bot a una URL para descargar su contenido, y la indexación, que es la decisión posterior de guardar esa URL en la base de datos que Google usa para responder búsquedas. Una página puede rastrearse y no indexarse, y en sitios grandes esto pasa constantemente sin que nadie se dé cuenta hasta que faltan visitas.
Esta guía va al detalle técnico de ambos procesos: qué controla cuánto rastrea Google tu web, cómo leer robots.txt y sitemaps como lo hace un rastreador, y cómo diagnosticar con datos reales (no con suposiciones) por qué una URL concreta no está en el índice.
Qué es el crawl budget y por qué no es infinito
El crawl budget (presupuesto de rastreo) es el número de URLs que Googlebot está dispuesto a rastrear en tu dominio dentro de un periodo de tiempo. No es un concepto que afecte a todos los sitios por igual: Google reparte más presupuesto a los dominios que percibe como más importantes o que cambian con más frecuencia, y lo calcula combinando dos factores independientes.
El primero es el crawl rate limit (límite de velocidad de rastreo): cuántas peticiones simultáneas y con qué separación entre ellas puede hacer Googlebot sin degradar el rendimiento de tu servidor. Si tu hosting empieza a responder más lento o con errores 5xx, Google baja este límite automáticamente, y tarda en volver a subirlo aunque el problema ya esté resuelto. El segundo es el crawl demand (demanda de rastreo): el interés real que Google tiene en revisar tus URLs, que sube si el contenido cambia a menudo, si la página recibe enlaces y tráfico, o si Google detecta que una sección se actualiza con regularidad.
En sitios pequeños (unos pocos cientos de URLs) el crawl budget casi nunca es el cuello de botella: Google puede rastrear todo el sitio varias veces por semana sin esfuerzo. El problema aparece en sitios con miles o decenas de miles de URLs, sobre todo si una parte relevante de ellas son de bajo valor: páginas de filtros combinados en un ecommerce, calendarios infinitos, parámetros de sesión o de tracking que generan URLs distintas para el mismo contenido. Cada una de esas URLs de bajo valor compite por el mismo presupuesto que las páginas que sí quieres posicionar.
robots.txt: la primera puerta, no la única
El archivo /robots.txt es lo primero que un rastreador que respeta el protocolo de exclusión (Googlebot, Bingbot y la mayoría de bots legítimos) consulta antes de rastrear ningún otro recurso del dominio. Define qué rutas puede visitar cada user-agent, pero es importante entender sus límites: es una directiva de rastreo, no de indexación. Bloquear una URL en robots.txt impide que Googlebot la visite, pero si esa URL ya tiene enlaces externos apuntando a ella, puede seguir apareciendo en resultados de búsqueda (normalmente sin descripción, solo con la URL), porque Google la indexa a partir de las señales externas sin necesidad de haberla rastreado.
La sintaxis básica combina bloques de User-agent con directivas Disallow/Allow, y admite comodines * y anclaje de final de ruta con $:
User-agent: *
Disallow: /carrito/
Disallow: /*?sessionid=
Disallow: /*.pdf$
Allow: /wp-content/uploads/
Sitemap: https://www.tudominio.com/sitemap.xmlErrores habituales que se ven en auditorías reales: bloquear por accidente carpetas de recursos que el propio renderizado necesita (CSS o JS dentro de /wp-content/ o /assets/, que si están bloqueados impiden que Google vea la página como la ve un usuario); dejar un Disallow: / heredado de un entorno de pruebas cuando el sitio pasa a producción, que bloquea el dominio entero de un plumazo; y confundir robots.txt con una herramienta de privacidad, cuando en realidad no impide el acceso a nadie que decida ignorarlo (no es una medida de seguridad, es una petición de buena fe).
Sitemaps XML: el mapa que ayuda pero no obliga
Un sitemap XML es una lista de URLs que le dices a Google que consideras relevantes, junto con metadatos opcionales como la fecha de última modificación. No garantiza indexación (Google puede ignorar URLs del sitemap si las considera de baja calidad o duplicadas) pero sí acelera el descubrimiento, especialmente en sitios nuevos o con secciones que cambian a menudo.
Reglas prácticas que marcan la diferencia en sitios grandes: un sitemap no puede superar 50.000 URLs ni 50 MB sin comprimir, así que a partir de ese volumen hace falta un sitemap index que apunte a varios sitemaps hijos, normalmente divididos por tipo de contenido (productos, categorías, blog); el campo <lastmod> solo aporta valor si es preciso, si se actualiza automáticamente cada vez que se toque el contenido real y no con la fecha del día en que se regeneró el sitemap por rutina, porque Google detecta y penaliza en confianza los sitemaps que mienten sistemáticamente en esta fecha; y el sitemap solo debe incluir URLs canónicas, indexables y que devuelvan 200, nunca URLs redirigidas, con noindex o que devuelvan error, porque cada una de esas inconsistencias se reporta como "excluida" en Search Console y erosiona la confianza de Google en el archivo completo.
Meta robots y X-Robots-Tag: dos formas de decir lo mismo
Una vez que Googlebot rastrea una página, decide si indexarla en función de las directivas que encuentra. La más conocida es la etiqueta <meta name="robots"> en el <head> del HTML:
<meta name="robots" content="noindex, follow">Esta combinación es la correcta cuando quieres sacar una página del índice pero sigues queriendo que Google rastree los enlaces que contiene (por ejemplo, una página de paginación intermedia). El error más común es usar noindex, nofollow por defecto sin pensarlo, lo que corta también el flujo de rastreo hacia lo que enlaza esa página.
Cuando el recurso no es HTML (un PDF, una imagen, una respuesta JSON), la meta etiqueta no sirve porque no hay <head> donde ponerla; ahí se usa la cabecera HTTP equivalente, X-Robots-Tag, que se configura a nivel de servidor y admite exactamente los mismos valores:
Header set X-Robots-Tag "noindex, nofollow"Una contradicción frecuente en sitios con mucho tiempo de vida: una URL bloqueada en robots.txt que además lleva un noindex en el HTML. Como está bloqueada, Google nunca llega a ver esa etiqueta, así que si la URL ya estaba indexada por señales externas, el noindex no sirve de nada hasta que se desbloquea el rastreo el tiempo suficiente para que Google la vuelva a visitar y procese la directiva.
Análisis de logs de servidor: ver el rastreo real, no el estimado
Search Console muestra una muestra agregada del rastreo, útil pero limitada. Los logs del servidor (los registros de acceso en crudo, normalmente en formato Apache o Nginx) muestran cada petición real que ha hecho cualquier bot, con su user-agent, la URL exacta, el código de respuesta y la marca de tiempo. Es la única fuente que permite responder con certeza preguntas como "¿cuánto de mi crawl budget se está yendo en URLs que no me interesan?".
El proceso básico de un análisis de logs: filtrar las líneas cuyo user-agent corresponda a Googlebot (verificando además por IP inversa, porque el user-agent se puede falsificar fácilmente), agrupar por ruta o patrón de URL, y cruzar el volumen de peticiones con el valor real de cada grupo de páginas. Es habitual descubrir que un porcentaje enorme de las visitas de Googlebot (a veces más de la mitad en ecommerce con filtros mal gestionados) se concentra en combinaciones de parámetros que nunca deberían haberse rastreado, mientras páginas de producto nuevas tardan días en recibir su primera visita.
Errores que más presupuesto de rastreo desperdician
En orden de frecuencia con la que aparecen en auditorías reales: la navegación facetada sin control (filtros de color, talla o precio en ecommerce que generan una URL nueva por cada combinación, multiplicando el número de páginas rastreables sin multiplicar el contenido único); las cadenas de redirección, donde cada salto adicional consume una petición de rastreo sin aportar nada nuevo; los soft 404, páginas que devuelven código 200 pero muestran contenido de "no encontrado", que Google sigue rastreando repetidamente intentando encontrarles sentido; y los parámetros de sesión o de tracking (?sessionid=, ?utm_source=) que generan URLs técnicamente distintas para contenido idéntico si no se canonicalizan o excluyen correctamente.
Cómo priorizar el rastreo hacia lo que importa
La combinación que mejor funciona en la práctica no es una sola herramienta sino tres capas trabajando juntas: robots.txt para bloquear de raíz rutas que nunca deberían rastrearse (páginas de resultados de búsqueda interna, carritos, áreas de usuario), canonical y parámetros gestionados en Search Console para las variantes que sí deben rastrearse ocasionalmente pero consolidarse en una sola URL indexable, y una arquitectura de enlazado interno que dirija el máximo peso hacia las páginas de mayor valor, porque Google prioriza el rastreo de URLs que recibe más enlaces internos desde páginas ya indexadas y con autoridad.
Preguntas frecuentes
¿Cuánto tarda Google en indexar una página nueva?
No hay un plazo fijo: puede ser cuestión de horas en dominios con mucha autoridad y rastreo frecuente, o de semanas en sitios nuevos con poco enlazado externo. Enviar la URL manualmente desde Search Console y enlazarla desde páginas ya indexadas acelera el proceso, pero no lo garantiza en un plazo concreto.
¿Bloquear una URL en robots.txt la saca del índice de Google?
No necesariamente. Si esa URL ya tenía enlaces externos, puede seguir indexada (sin descripción, solo con la URL) porque Google la indexa por señales externas sin necesidad de rastrearla. Para sacar de forma fiable una URL del índice hay que permitir su rastreo y usar noindex, o pedir su eliminación temporal desde Search Console mientras se aplica el noindex.
¿El crawl budget afecta a sitios pequeños?
En la inmensa mayoría de sitios de menos de mil páginas, no de forma perceptible: Google tiene margen de sobra para rastrearlo todo con frecuencia. Es un problema real a partir de varios miles de URLs, especialmente si una parte grande son de bajo valor (filtros, parámetros, paginación mal gestionada).
¿Sirve de algo enviar el sitemap manualmente si ya está en robots.txt?
Sí: declarar el sitemap en robots.txt lo hace descubrible para cualquier rastreador que respete el protocolo, pero enviarlo también manualmente en Search Console permite ver directamente cuántas URLs se han indexado de las enviadas y detectar antes los problemas.
¿Qué diferencia hay entre "noindex" y quitar una página del sitemap?
Son señales distintas y no equivalentes. Quitar una URL del sitemap solo dice "no la destaco especialmente", pero Google puede seguir rastreándola e indexándola por otras vías (enlaces internos o externos). El noindex es la única directiva que le dice explícitamente a Google que no debe guardarla en el índice, con independencia de cómo la haya descubierto.