El 2 y 3 de octubre de 2026, Google celebró en Barcelona la tercera edición europea de su Search Central Live Deep Dive, el evento técnico más cerrado de la compañía para profesionales SEO.
En la tercera jornada, Gary Illyes, analista de Google, dedicó una sesión completa a desgranar cuánto tardan de verdad los distintos procesos internos de la Búsqueda, desde que un rastreador descubre una URL nueva hasta que un cambio tras una core update se refleja en los resultados.
La información no estaba publicada en la documentación oficial de Google antes del evento. Llegó por tres canales distintos, el recap del día 3 publicado por We Are Roast, una publicación de LinkedIn de Neil McCarthy y la cobertura de Barry Schwartz en Search Engine Roundtable el 5 de octubre.
En los días siguientes, Jake Ward preparó una infografía resumen que circuló por LinkedIn y que es, probablemente, el formato con el que más profesionales del sector han visto estos números.
Estos datos son estimaciones internas que Google maneja de forma habitual y no deben tratarse de promesas comerciales ni garantías contractuales.
Lo más importante es que son tiempos de proceso individual, no tiempos de resultado completo. Para que un cambio en una URL llegue a cambiar lo que ve el usuario en la SERP, Google tiene que encadenar varios de estos procesos y los retrasos se acumulan.
Los 23 procesos con sus tiempos, la tabla completa
Para nosotros, deberíamos imprimir y pegar en la pared esta referencia, los tiempos están tal como los presentó Illyes y como los recoge el recap oficial del evento. La columna “típico” describe el escenario habitual, la columna “más lento” describe el peor caso realista.
6 procesos para rastreo (crawling)
Que una URL ya conocida tarde en promedio 30 días en ser revisitada explica por qué cuando se actualiza un artículo el lunes, el viernes el fragmento sigue mostrando el texto anterior en Google.
Si además la URL no tiene enlazado interno fuerte, ese recrawl puede estirarse semanas más.
Proceso | Tiempo típico | Peor caso realista |
|---|---|---|
Descubrir una URL nueva | Aproximadamente 20 horas | Semanas o nunca |
Volver a rastrear una URL conocida | Aproximadamente 30 días | Semanas o nunca |
Procesar un sitemap | Aproximadamente 24 horas | Hasta 14 días o nunca (por calidad) |
Procesar un cambio en robots.txt | Aproximadamente 24 horas | Hasta 25 horas |
Ajustar la capacidad de rastreo | De 4 horas a entre 1 y 2 semanas | De 1 a 3 semanas en modo recuperación |
Ajustar la demanda de rastreo | Aproximadamente 20 horas | De semanas a meses |
10 procesos de Indexación (indexing)
Aquí hay dos sorpresas, la primera es que el proceso de anotaciones de enlaces internos pueda estirarse de minutos a tres semanas en el escenario típico, lo que da una base técnica a lo que llevamos años observando en auditorías, el impacto de una nueva campaña de enlazado no se mide a los dos días.
La segunda es que una migración de sitio puede llegar a tardar más de un año en estabilizarse por completo. Si tu equipo de producto está planteando una migración y te pide proyecciones a tres meses, estos números son tu mejor argumento para pedir prudencia.
Proceso | Tiempo típico | Peor caso realista |
|---|---|---|
Renderizar una página | Segundos para renderizar, horas en cola | De días a semanas |
Procesar anotaciones de metadatos | De 45 a 90 minutos | De 1 a 4 días |
Procesar anotaciones de enlaces | De minutos a entre 1 y 3 semanas | Meses |
Completar la indexación de principio a fin | Aproximadamente 1,5 horas | Meses o nunca (por calidad) |
Eliminar una página del índice | De 1 a 3 semanas | Meses |
Procesar un cambio de canonical | De 1 a 3 semanas | Meses, si hay señales contradictorias |
Procesar una migración de sitio | De 1 a 3 meses | De 6 meses a más de un año |
Procesar cambios en datos estructurados | De horas a entre 1 y 2 semanas | Semanas o nunca (por calidad) |
Procesar imágenes | De horas a días | De semanas a meses |
Procesar vídeos | De horas a días | De semanas a meses, análisis profundo incluido |
7 procesos de servicio de resultados (serving)
La cifra más dura de todas es la de recuperación tras core update, de 3 a 6 meses en el escenario típico y hasta un año entero en el peor caso. Pero también es cierto que puede verse recuperación en 6 semanas.
Si tu sitio recibió un golpe en una core update, el calendario realista para ver el resultado de tus mejoras es trimestral o semestral, aunque debemos estar revisando mensual.
Proceso | Tiempo típico | Peor caso realista |
|---|---|---|
Ocultar un resultado desde Search Console (herramienta de eliminación) | Aproximadamente 2 horas | Hasta 24 horas |
Actualizar el fragmento (snippet) de un resultado | De 1 a 2 días | De varias semanas a meses |
Actualizar el título de un resultado | De 1 a 2 días | De varias semanas a meses |
Actualizar la imagen de un resultado de texto | De 1 a 2 semanas | De varias semanas a meses |
Levantar una acción manual tras reconsideración aprobada | De 1 a 2 semanas | De 4 a 6 semanas, mucho más en sitios inactivos |
Reflejar cambios tras una core update (recuperación) | De 3 a 6 meses | De 6 meses a 1 año, hasta la siguiente core update |
Reflejar cambios de una spam update | De 1 a 2 semanas (continuo) | Meses, en despliegues por lotes |
Por qué todo con Google tarda más de lo que crees
Illyes insistió en Barcelona en un punto que suele perderse cuando los tiempos se miran por separado. Los procesos están encadenados, no son independientes.
Una página no puede indexarse antes de ser rastreada, un snippet no puede actualizarse antes de que la indexación procese el nuevo contenido y una recuperación de core update no se produce si entre medias no hay recrawl.
Pongamos un ejemplo: actualizas el título de un artículo para captar más clics, el proceso de actualización del título en los resultados tarda típicamente de 1 a 2 días, pero esos días cuentan a partir de que Google haya rastreado la URL de nuevo y haya procesado los metadatos.
Si tu URL es poco visitada por Googlebot y el recrawl típico de una URL conocida es de 30 días, el calendario real desde que publicas el cambio hasta que lo ves en la SERP es de 30 días más 1 a 2 días adicionales. En el peor caso, meses.
Hay otro escenario técnico importante que Illyes dejó caer y es que la capacidad de rastreo que Google asigna a un sitio puede desplomarse en segundos si detecta problemas en el servidor, por ejemplo una ola de errores 500 o tiempos de respuesta por encima del umbral.
Recuperarla, en cambio, puede tardar semanas, lo que explica muchas caídas de visibilidad tras incidencias técnicas que a priori parecían resueltas en el mismo día.
La palabra que más repitió Illyes fue "calidad"
Varios de los tiempos de las tablas llevan en la columna de peor caso el añadido "o nunca, por calidad"; está en descubrir una URL nueva, en procesar un sitemap, en completar la indexación y en procesar cambios en datos estructurados.
Esta coletilla es la confirmación oficial de algo que la industria sospechaba, Google puede decidir no procesar en absoluto una URL si no considera que merece estar en el índice, por mucho que la hayas enviado por sitemap o por el inspector de URL.
Si llevas semanas enviando una URL a indexar y Google la ignora de forma consistente, probablemente no tienes un problema de rastreo, tienes un problema de calidad de contenido.
Arreglar el sitemap no va a solucionar nada si el buscador considera que la página no aporta nada que no exista mejor en otro sitio.
Qué hacer con estos tiempos esta misma semana
Lo que de verdad vale es qué cambias en tu rutina cuando interiorizas estos tiempos y tratamos de explicarlo por los roles que intervienen en un proceso de SEO.
Para el responsable SEO técnico. Antes de reportar que una optimización "no funcionó", confirma en el inspector de URL de Search Console cuándo fue el último rastreo.
Si Googlebot no ha vuelto, el cambio no se ha evaluado todavía, independientemente de lo bien que esté implementado y para proyectos de migración, planifica el calendario a doce meses, no a tres.
Para el editor o director de contenido. Los cambios de títulos y metadescripciones tardan de 1 a 2 días en reflejarse si la URL es rastreada con frecuencia y hasta meses si no lo es. Si tienes un lote de 300 URLs antiguas con metadata vieja, prioriza las que ya reciben tráfico sumando las que más impactan al negocio.
Para el responsable de analítica. Define bandas de observación distintas según la métrica, las caídas tras un cambio técnico se pueden evaluar en 2 a 4 semanas; las caídas tras una core update necesitan 3 a 6 meses para interpretarse y las caídas tras una migración, hasta un año. Comparar manzanas con manzanas pasa por respetar estos plazos.
Para dirección general. El SEO sigue teniendo el mejor coste por conversión en la mayoría de sectores, pero la curva de resultados es -para muchos casos- lenta. Si tu negocio necesita resultados en 60 días, la estrategia de SEO debe estar planteada como un embudo de marketing donde la dificultad y la cantidad no siempre conversan.
Estos números de Google no son una camisa de fuerza, son estimaciones
Ya estamos viendo circular estos datos como si fueran garantías contractuales y ¡no lo son! Illyes dejó varias advertencias explícitas
Son estimaciones internas. Google puede tardar menos o más en cualquier caso individual, la tabla describe lo que es habitual en el agregado, no lo que te va a pasar a ti seguro.
El peor caso realista existe de verdad y es más frecuente de lo que uno quisiera. La columna de “meses o nunca” no es un ejercicio hipotético sino lo que de verdad ocurre con sitios que tienen problemas estructurales de calidad de contenido.
Los procesos se encadenan. Nunca mires un tiempo aislado, siempre suma todos los procesos que tienen que ocurrir entre tu cambio y la visibilidad real en resultados.
La capacidad de rastreo puede caer en segundos. Un incidente técnico de servidor puede desplomar la frecuencia con la que Googlebot visita tu sitio y recuperarla cuesta semanas de rastreo progresivo.
Nada de esto cambia que SEO funciona. Lo que cambia es cómo se mide y cómo se comunica a stakeholders, la disciplina del dato aquí separa a los que saben de los que no.
Cómo cruzar estos datos con tu propio Search Console
Antes de abrir cualquier debate sobre el impacto de un cambio reciente, ejecuta estos tres chequeos.
1En el inspector de URL de Search Console, revisa cuándo fue el último rastreo de la URL afectada. Si la fecha es anterior al cambio que estás evaluando, el proceso ni siquiera ha empezado.
En el informe de rendimiento, compara la ventana de los 28 días posteriores al cambio con la ventana equivalente anterior, filtrando por la URL concreta y no por el total del sitio. El agregado esconde demasiada información útil.
En Analytics 4, revisa la cohorte de usuarios que entró por esa URL durante la ventana de evaluación. Si cambió el título o el snippet y el CTR se mueve, debería notarse ahí antes que en ningún otro sitio.
Si no ves nada en Google Search Console, te recomiendanos que el equipo de tecnología revise con urgencia los tiempos y procesos en el servidor.
Si tuviéramos que condensar las cuatro horas de contenido técnico que Illyes compartió en Barcelona en una sola idea, sería que el SEO funciona en ciclos de semanas y meses.
La buena noticia es que ahora, con estos tiempos públicos y verificables, nadie puede volver a decirte que no sabía ☕.
