Cuánto tarda Google en indexar una página (y todo lo demás): los tiempos que mostró Google en Barcelona

“¿Y cuándo lo vamos a ver?”

Es la pregunta que aparece en cada proyecto, después de cada cambio. Se cambia un title, se corrige un canonical, se lanza un sitio nuevo, y a los tres días alguien abre Search Console y pregunta por qué no pasó nada todavía. Durante mucho tiempo la respuesta honesta fue “depende”, que es verdad pero no le sirve a nadie para planificar.

La semana pasada Google puso números arriba de la mesa. En el Search Central Live Deep Dive que hizo en Barcelona, Gary Illyes mostró los tiempos internos que tarda cada proceso de la Búsqueda: cuánto demora en descubrir una URL nueva, en indexarla, en reflejar un cambio de title o en terminar de procesar una migración. Para cada uno dio un tiempo típico y el peor caso.

Los datos los publicaron John Campbell en el resumen de We Are Roast y Neil McCarthy en LinkedIn, y Barry Schwartz los ordenó en Search Engine Roundtable. El propio Illyes aclaró después que fue “un ejercicio” para ver si la audiencia se identificaba con los números que habían sacado internamente. O sea que no es una promesa ni un SLA, pero es lo más cerca que estuvimos de saber cómo se ve esto desde adentro.

Vale la pena mirarlos con calma, porque cambian bastante cómo conviene hablar de plazos con un cliente o con un directorio.

Primero, una advertencia que dio el propio Google

Illyes dejó una aclaración que es la clave para leer todo lo que sigue: los procesos están encadenados. Una página no se puede indexar si antes no se rastreó, y no puede aparecer con su title nuevo si no se volvió a procesar. Las demoras no corren en paralelo, se suman.

Esto parece obvio, pero es donde más se equivocan las estimaciones. Cuando alguien dice “Google indexa en una hora y media”, está mirando solo el último tramo. Si la URL todavía no fue descubierta, esa hora y media empieza a contar recién después de que el rastreador llegó, y eso puede tardar días.

Rastreo: de 20 horas a nunca

El rastreo es la puerta de entrada, y es donde aparecen los rangos más amplios. Según los datos que mostró Google:

Hay dos cosas que me parecen importantes acá.

La primera es el “nunca”. Aparece tres veces en la tabla, y en el caso del sitemap Google lo asocia directamente con la calidad. Mandar un sitemap no obliga a Google a procesarlo. Si el sitio no le da motivos, puede tardar dos semanas o directamente no hacerlo. Lo mismo pasa con URLs nuevas: que existan y estén enlazadas no garantiza que se descubran rápido.

La segunda es el número de los 30 días para volver a rastrear una URL que Google ya conoce. Es un promedio, y en un sitio grande hay páginas que se visitan varias veces por día y otras que pasan meses sin una visita. Pero sirve para entender por qué un cambio en una página de bajo tráfico puede tardar semanas en notarse aunque esté perfecto. No es que Google lo haya ignorado, es que todavía no volvió a pasar.

Google también mencionó que la capacidad de rastreo puede caer en segundos si el servidor empieza a responder mal. Recuperarla, en cambio, puede llevar de una a tres semanas. Es una asimetría que conviene tener presente antes de una salida a producción con mucha carga, o cuando se cambia de hosting.

Indexación: por qué una migración puede tardar un año

La hora y media de indexación de punta a punta es el dato que más se va a citar, y también el que más se va a malinterpretar. Google lo aclara: “de punta a punta” significa que todos los procesos críticos terminaron bien. Cuando algo falla, o cuando Google duda de la calidad, el mismo proceso puede llevar meses o no completarse.

El renderizado merece una línea aparte. Renderizar una página lleva segundos, pero la página puede pasar horas esperando en la cola, y en el peor caso días o semanas. Para sitios que dependen de JavaScript para mostrar el contenido principal, esa espera es tiempo en el que Google tiene una versión incompleta de la página.

Para mí, el número más útil de toda la presentación es el del cambio de canonical: de una a tres semanas en el caso típico, meses cuando hay señales en conflicto. Es exactamente lo que pasa cuando el canonical dice una cosa, el sitemap otra y los enlaces internos una tercera. Google no elige rápido cuando le das razones para dudar.

Y después está la mudanza de sitio. Uno a tres meses en el caso típico, de seis meses a más de un año en el peor. Google agregó que una mudanza chica puede resolverse en pocas semanas, pero el rango largo es el que importa en sitios grandes.

Esto coincide con lo que escribí en la metodología de migración SEO enterprise: el proyecto no termina el día del lanzamiento, termina cuando el tráfico vuelve al baseline, y por eso el monitoreo posterior lo pienso en 90 días como mínimo. Ahora hay un número de Google para respaldar esa ventana. Si un proveedor te promete que en dos semanas todo vuelve a la normalidad, está contradiciendo los datos de quien tiene que procesar el cambio.

Resultados: el title cambia en dos días, un core update en seis meses

Acá hay una pequeña buena noticia y una mala.

La buena: los cambios de title y de snippet, cuando la página ya está indexada y se rastrea con frecuencia, se ven en uno o dos días. Es lo más rápido que hay después de una eliminación manual desde Search Console. Sirve para pruebas de CTR, y también para corregir rápido un error que llegó a la página de resultados. Si alguna vez se te coló un “Copilot said” en la meta description, ya sabés cuánto tarda en desaparecer.

La mala es la recuperación de un core update: entre tres y seis meses en el caso típico, y hasta un año si hay que esperar al siguiente. Google lo viene diciendo de distintas formas hace tiempo, pero verlo en una tabla interna le saca cualquier ambigüedad. No hay arreglo de una semana para una caída por core update. Lo que hacés hoy se evalúa, en el mejor de los casos, dentro de varios meses.

Sobre los spam updates hay un matiz que conviene leer bien. Google dijo que un spam update se despliega en uno o dos días y que el efecto de los cambios se ve en una a dos semanas de forma continua, o en meses cuando depende de refrescos por lotes. El spam update de septiembre de 2026 fue la excepción a esa regla, porque Google avisó desde el principio que su despliegue podía llevar hasta dos semanas.

Cómo usaría estos tiempos para fijar expectativas

Lo primero que cambiaría es la forma de responder el “¿cuándo lo vamos a ver?”. En lugar de “depende”, se puede decir algo mucho más concreto: este cambio pasa por estos procesos, cada uno tarda esto en el caso normal, y si algo falla puede llevar esto otro. Es la misma honestidad de siempre, pero con un rango que se puede poner en un plan.

En la práctica, sumaría los tramos según el tipo de cambio:

• Un title nuevo en una página que se rastrea seguido: uno o dos días.
• Una página nueva en un sitio con buena salud de rastreo: alrededor de un día para que la descubra, más el tiempo de indexación. Si el sitio tiene problemas de calidad, puede no pasar.
• Un cambio de canonical: de una a tres semanas, siempre que el resto de las señales digan lo mismo.
• Una migración: de uno a tres meses para un sitio mediano, y una ventana bastante más larga para un sitio grande. Por eso conviene presupuestar el monitoreo como parte del proyecto, no como un extra.
• La recuperación de un core update: no menos de tres meses, y hay que avisarlo antes de empezar a trabajar.

Lo segundo es dejar de leer las primeras 48 horas como un veredicto. Una caída o una suba el día después de un cambio grande dice muy poco, porque la mayoría de los procesos todavía no terminaron. Esto vale sobre todo para migraciones y cambios de arquitectura, donde la ansiedad de los primeros días suele empujar a revertir cosas que estaban bien.

Lo tercero es mirar dónde aparece la palabra “calidad” en las tablas. Está en el sitemap, en la indexación de punta a punta y en los datos estructurados, siempre del lado del “nunca”. Google no lo dice con estas palabras, pero el mensaje es claro: la velocidad técnica sirve de poco si el sitio no le da motivos para procesar lo que publica. Es el mismo argumento de la guía de crawl budget para sitios grandes. Antes de pedirle a Google que rastree más, conviene darle menos páginas que no valen la pena.

Lo que la tabla no dice

Los números son promedios internos de Google, presentados como un ejercicio. No hablan de un sitio en particular, y Illyes no dio detalles de cómo se calcularon. Un medio de noticias con millones de URLs y un sitio institucional de veinte páginas viven en realidades distintas, y es esperable que los dos estén lejos del promedio.

Tampoco dicen nada de los buscadores con IA. Los AI Overviews y AI Mode toman información del índice de Google, así que heredan sus tiempos. Pero ChatGPT, Perplexity y el resto tienen sus propios rastreadores y sus propios ciclos, y nadie publicó una tabla parecida. Si tu objetivo es aparecer citado en esos asistentes, estos plazos son un piso, no una referencia completa.

Y no reemplazan la medición propia. La tabla de Google sirve para fijar expectativas razonables y para cortar promesas que no se pueden cumplir. Lo que realmente pasa en un sitio se sigue viendo en Search Console, en los logs del servidor y en el seguimiento de las URLs que importan.

Con todo eso, me quedo con lo más valioso de la presentación: por primera vez, la respuesta a “¿cuándo lo vamos a ver?” tiene un rango que viene de Google. Ya no es la intuición del consultor contra la urgencia del cliente.

Fuentes

• Search Engine Roundtable, “Google Search Data On Crawling, Indexing & Serving Timelines” (5 de octubre de 2026): https://www.seroundtable.com/google-crawling-indexing-serving-data-42225.html
• We Are Roast, resumen del día 3 del Google Search Central Live Deep Dive en Barcelona: https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-3-recap/
• Google Search Central, cambios de sitio con cambio de URL: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Google Search Central, cómo funciona la Búsqueda: https://developers.google.com/search/docs/fundamentals/how-search-works