Google tarda unas 20 horas en descubrir una URL nueva, según Illyes
Google rara vez pone cifras exactas a sus procesos internos, pero datos recientes de su equipo de Relaciones de la Búsqueda revelan los plazos de su pipeline. El mayor cuello de botella no siempre es técnico: si una página no aporta valor, los procesos pueden alargarse hasta no completarse nunca.
El trabajo de Google con una web se divide en tres fases estrictamente encadenadas: rastreo, indexación y publicación de resultados (serving). Aunque la documentación oficial suele ser vaga respecto a los plazos, Gary Illyes (del equipo de Relaciones de la Búsqueda) expuso los tiempos típicos y los casos más lentos basándose en análisis internos de Google durante el Search Central Live de Barcelona, celebrado a principios de octubre de 2026. A partir de los datos expuestos en el evento y recogidos por John Campbell (agencia ROAST), se confirma que un retraso en la primera fase arrastra irremediablemente a las demás.
Rastreo (Crawling)
Es el tiempo que tarda Google en encontrar una URL, volver a visitarla o ajustar los recursos que destina a un servidor.
| Proceso | Caso típico | Caso más lento |
|---|---|---|
| Descubrir una URL nueva | Unas 20 horas | De semanas a nunca |
| Volver a rastrear una URL conocida | Unos 30 días | De semanas a nunca |
| Procesar un sitemap | Unas 24 horas | Hasta 14 días, o nunca (calidad) |
| Aplicar un cambio en robots.txt | Unas 24 horas | 25 horas |
| Cambio en la capacidad de rastreo | De 4 horas a 1-2 semanas | 1-3 semanas (al recuperarse) |
| Cambio en la demanda de rastreo | Unas 20 horas | De semanas a meses |
La capacidad de rastreo (crawl capacity) puede caer en cuestión de segundos si Google detecta que el servidor no da abasto. Cherry Prommawin, también analista de Google, detalló en el mismo evento que el rastreo se frena drásticamente ante subidas en el tiempo de conexión, incrementos en el tiempo hasta el primer byte (TTFB) o picos de respuestas 429 y 5xx. Por su parte, la demanda de rastreo depende de tres factores: la calidad general del sitio, la frecuencia de actualización de las URL y su popularidad en internet.
Indexación
El tiempo que transcurre desde que se descarga el HTML hasta que se procesan todos los elementos y el resultado final entra en el índice.
| Proceso | Caso típico | Caso más lento |
|---|---|---|
| Renderizado | Segundos para renderizar y horas en cola | De días a semanas |
| Anotaciones de metadatos | 45-90 minutos | 1-4 días |
| Anotaciones de enlaces | De minutos a 1-3 semanas | Meses |
| Indexación de principio a fin | Hora y media | Meses, o nunca (calidad) |
| Retirada del índice (removal) | 1-3 semanas | Meses |
| Cambio de canónica | 1-3 semanas | Meses (señales contradictorias) |
| Migración de un sitio | 1-3 meses | De 6 meses a más de un año |
| Cambios en los datos estructurados | De horas a 1-2 semanas | Semanas, o nunca (calidad) |
| Imágenes | De horas a días | De semanas a meses |
| Vídeos | De horas a días | De semanas a meses (análisis a fondo) |
La indexación de principio a fin solo concluye cuando han terminado con éxito todos los procesos críticos. Como referencia para planificar con clientes, una migración pequeña y bien ejecutada requiere de uno a tres meses para estabilizarse en el índice.
Publicación de resultados (Serving)
El tiempo que transcurre hasta que un cambio indexado se refleja visualmente en la SERP.
| Proceso | Caso típico | Caso más lento |
|---|---|---|
| Retirada desde Search Console | Unas 2 horas | 24 horas |
| Cambio del snippet | 1-2 días | De varias semanas a meses |
| Cambio del title | 1-2 días | De varias semanas a meses |
| Cambio de imagen (resultado de texto) | 1-2 semanas | De varias semanas a meses |
| Levantamiento de una acción manual | 1-2 semanas | 4-6 semanas (o más en webs inactivas) |
| Recuperación de un core update | 3-6 meses | De 6 meses a un año |
| Cambio por un spam update | 1-2 semanas (de forma continua) | Meses (en actualizaciones por lotes) |
Qué significan estos plazos para el SEO
Estos datos no son una promesa de servicio, sino la media típica de todo el índice de Google. Sin embargo, sirven para establecer un umbral de actuación. Si Google no ha descubierto una URL nueva en un par de días, ya va más lenta que el caso típico: es el momento de comprobar el enlazado interno y el sitemap, en lugar de solicitar el rastreo compulsivamente en Search Console.
El patrón más revelador de los datos es la presencia repetida de la palabra «nunca» en la columna de los peores escenarios, atada invariablemente a la calidad del sitio (procesar sitemaps, indexar páginas completas o procesar marcado schema). Si un cambio de canónica no se refleja en tres semanas, el problema son las señales contradictorias en el código. Pero si una página se estanca en la zona del «nunca», el arreglo ya no es técnico: es una pérdida de confianza de Google en el valor global de la web. Arreglar deprisa los aspectos técnicos no forzará la indexación de un contenido que el algoritmo considera prescindible.
