«Nos ha pillado un core update» es la explicación por defecto cuando el tráfico cae. A veces es verdad. Muchas veces es lo que queda cuando no se ha comprobado lo demás, y tiene un problema serio: de un core update no se sale revirtiendo nada, así que darlo por bueno equivale a decidir que no hay nada que hacer.
Este es el orden de descarte que seguimos, con un caso real resuelto y con dos errores propios contados por el camino.
Primero: mira la forma de la curva, no la cifra
Antes de investigar nada, mira el dibujo:
- Escalón brusco de un día para otro → algo cambió en tu web o en tu servidor. Un despliegue, una redirección retirada, un
noindexmal puesto. - Deslizamiento progresivo de dos a seis semanas y luego meseta → eso es la firma de una actualización de algoritmo, que Google despliega por fases.
En un proyecto dimos por hipótesis principal «un cambio técnico desplegado en abril». El cliente preguntó si no sería un core update. Tenía razón, y la prueba estaba en el mismo gráfico que llevábamos mirando una semana: la caída había sido un deslizamiento de cinco semanas, no un escalón. Teníamos el dato y no habíamos leído la forma.
Y el aviso que sale de otro caso: el agregado mensual esconde el escalón. Una «caída del 24% en abril» resultó ser, al bajar a datos diarios filtrados por la página afectada, un escalón brutal el 19 y 20 de marzo. El promedio de marzo mezclaba diecinueve días buenos con once malos y por eso el golpe «aparecía» en abril. Antes de fechar una caída, baja a granularidad diaria. No te fíes ni del agregado semanal.
Segundo: el calendario oficial, buscado, no recordado
Hay exactamente dos páginas donde se comprueba esto:
- El historial de actualizaciones de Google (core updates y spam updates).
- La página de anomalías de datos de Search Console.
La segunda pesa tanto como la primera y casi nadie la abre. Si el contador con el que estás midiendo está roto, la forma de la curva no significa lo que parece. Y ojo con los blogs del sector: en un caso, el «core update de abril de 2026» que citaban varios artículos no existía en el registro de Google. Compara el día exacto de tu escalón contra el día exacto del update, no el mes.
En el caso del escalón del 19 de marzo, el calendario lo desmontó solo: el core update de aquel mes empezó el 27, y el spam update el 24. Los dos después. La causa real era otra —una redirección que se había retirado— y estaba tapada por una fecha aproximada en el registro de cambios: el cliente la recordaba como «hace dos o tres meses». Los datos la fechaban con precisión de un día, porque la página había estado a cero impresiones todo febrero y reaparecía de golpe.
La lección: cuando una fecha de tu registro de cambios es aproximada y el diagnóstico depende de ella, fíchala con los datos antes de concluir nada.
Tercero: ¿cayó tu sitio, o cayó esa página?
Este es el control que separa un diagnóstico de una corazonada, y se hace en dos minutos: mide la misma ventana en varias páginas del sitio.
En un proyecto de infraestructura tecnológica, un artículo perdió el 86% de sus impresiones y once puestos y medio. Parecía un golpe algorítmico. Pero en la misma ventana:
| Variación | |
|---|---|
| El artículo investigado | −86 % de impresiones |
| El sitio completo | −20 % |
| Otras dos páginas del sitio | Sin movimiento |
| Una cuarta página | +155 % |
Un algoritmo mueve el sitio. Cuando una página se hunde y sus vecinas no se mueven, o suben, la causa no es general: es de esa consulta o de esa página.
Cuarto: descarta lo aburrido antes de lo interesante
Con el caso anterior sobre la mesa, y sin poder fiarnos de las impresiones ni de la posición —caían dentro de un tramo en el que el contador de Google estaba roto—, el descarte fue este:
- ¿Se tocó la página? El campo
modifiedde la API del gestor de contenidos: última modificación, el día siguiente a publicarla. No se tocó. - ¿Hay un problema técnico? La API de inspección de URL de Search Console da el veredicto de Google, no tu deducción: «Enviada e indexada», canónica correcta, rastreada hace días. No lo hay.
- ¿Perdió una consulta o todas? Los clics por consulta —el único dato que no estaba contaminado— pasaron de ocho consultas con clic a una. El clúster entero a la vez.
- ¿Sigue posicionando? Sí, en el puesto 19 para su término principal. No es una desindexación.
- ¿Quién ocupa ahora su sitio? La búsqueda en vivo: dos fabricantes globales de tecnología, dos operadoras de telecomunicaciones y un diccionario de referencia.
En esta categoría entra también el miedo más repetido: un ataque de enlaces. Antes de tocar el archivo de desautorización, conviene ver el caso en que 81.273 backlinks de spam no movieron nada.
Y el control que cierra el caso
El quinto paso solo demuestra algo si le pones un contraste. Miramos las consultas que esa misma web conservaba: ahí quien competía eran sitios pequeños y especializados, y el cliente seguía en posiciones 3 y 5.
Conclusión: la actualización de algoritmo había reordenado las consultas informativas genéricas hacia dominios de mucha más autoridad. El sitio pierde donde compiten los gigantes y mantiene donde no están. Cinco comprobaciones independientes apuntando a lo mismo y ninguna en contra.
Eso cambia la estrategia entera, y en una dirección que no es «escribir más»: dejar de competir en informativo genérico y concentrarse en las consultas técnicas de nicho y en las comerciales con «empresa», «instaladora» o ciudad.
Si el descarte apunta a una sola página y no al sitio entero, el paso siguiente es comprobar si esa página sigue existiendo o solo cambió de URL, que son dos problemas distintos con soluciones opuestas. Y para separar tu trabajo del ruido del sitio, hay que medir cada cambio contra el control del sitio.
¿Tu web ha perdido posiciones y no sabes por qué?
Pasamos este mismo descarte de cinco pasos con tus datos y te decimos si hay pérdida real o es un problema de medición.
Auditar mi web gratisLa honestidad del dato
Cinco comprobaciones coincidentes siguen siendo correlación, no causa demostrada. No podemos abrir el algoritmo de Google. Lo que sí podemos decir es que no queda ninguna hipótesis alternativa en pie, y eso es bastante mejor que la explicación que dimos al principio.
Porque en este caso nos equivocamos dos veces antes de acertar. La pista buena la dio el cliente en la primera frase: «pasó a segunda página con páginas muy grandes en la primera». Tardamos dos intentos en comprobar precisamente eso.
Y hay un límite estructural que conviene saber: Search Console solo guarda dieciséis meses. Si la caída que investigas es anterior, ese lado de la comparación no se puede verificar de forma independiente, ni por interfaz ni por API. Dilo en el informe en vez de rellenarlo con una estimación.
Preguntas frecuentes
¿Cómo sé si me ha afectado un core update?
Compara el día exacto en que empieza tu caída con las fechas oficiales del historial de actualizaciones de Google, y mira la forma: un core update produce un deslizamiento de varias semanas, no un escalón de un día. Después comprueba si cayó todo el sitio o solo una página; un algoritmo mueve el conjunto.
Han bajado mis impresiones pero los clics siguen igual, ¿qué pasa?
Sospecha del contador antes que del algoritmo. Consulta la página de anomalías de datos de Search Console para esas fechas: ha habido periodos con errores de registro reconocidos por Google que afectan a impresiones, CTR y posición media, pero no a los clics.
¿Se puede recuperar el tráfico perdido en un core update?
No revirtiendo cambios, porque no hay nada que revertir. La recuperación llega en la siguiente actualización y depende de haber mejorado lo que esa actualización re-pondera. Cambia el plazo y cambia la prioridad: el trabajo de calidad deja de ser crecimiento y pasa a ser la vía de recuperación.
El dato clave: antes de culpar al algoritmo, mide la misma ventana en > varias páginas de tu web. Si una se hunde un 86% mientras las vecinas están > planas, no ha sido el algoritmo.