Core update de Google: cómo saber si te afectó con tus propias posiciones

Último core update de Google: fechas, duración y dónde confirmarlo

Esta sección se actualiza cada vez que Google despliega un core update nuevo: cambia el dateModified de este post, no la URL, así que puedes volver a leerla sin buscar otro artículo. Con los datos verificados en el Google Search Status Dashboard el 10 de septiembre de 2026, el despliegue más reciente empezó el 21 de mayo de 2026 y duró 11 días y 21 horas, con fin aproximado el 1-2 de junio (confirma la hora exacta en el dashboard si necesitas precisión al minuto).

Cerca de esos core updates hubo otros despliegues que conviene no confundir con el principal: un spam update el 24 de marzo de 2026 (tres días antes de que empezara el core de ese mes), otro spam update el 24 de junio de 2026 y otro el 18 de agosto de 2026, además de un Discover update en febrero de 2026. Cada uno mueve tráfico por su cuenta, así que si tu ventana de medición cruza cualquiera de estas fechas, la lectura se contamina y hay que correr la ventana.

Para confirmar cualquiera de estas fechas por tu cuenta, entra al Google Search Status Dashboard (status.search.google.com) y busca la sección de incidentes de ranking: ahí Google lista el inicio, el estado (en curso o finalizado) y la duración de cada core update, spam update y Discover update que decide anunciar. Lo que el dashboard no muestra son las actualizaciones principales más chicas y continuas que Google aplica sin anunciar cada una por separado — existen, pero no tienen fecha propia que puedas anotar.

Qué es un core update y qué no es

Según la propia documentación de Google, un core update es un cambio amplio en cómo el buscador evalúa y ordena el contenido en general, varias veces al año. No apunta a un sitio en particular ni corrige un problema puntual: ajusta los sistemas de ranking a gran escala, y como efecto de ese ajuste, sitios enteros pueden subir o bajar sin que hayan cambiado nada. A eso se suman actualizaciones principales más pequeñas y continuas que Google aplica sin anunciar cada una: por eso tu posición nunca está del todo quieta, con o sin core update declarado.

Lo que un core update no es: no es una acción manual (una sanción dirigida específicamente a tu sitio por infringir una política, con motivo y fecha propios) y no es lo mismo que un spam update (otro tipo de despliegue, enfocado en detectar prácticas y contenido de spam concretos). Los tres pueden coincidir en el calendario — de hecho el spam update de marzo 2026 cayó tres días antes del core de ese mes — pero son mecanismos distintos y no se arreglan de la misma forma.

Antes de seguir con cualquier protocolo de medición, descártalo en una línea: entra a Search Console, al informe de Acciones manuales. Si hay algo listado ahí, no es un core update lo que te afectó — es otro problema, con su propio arreglo, y el resto de esta guía no te sirve para ese caso.

Por qué Search Console solo no alcanza para medir un core update

Search Console es la fuente de clics e impresiones y es gratis, pero tiene cuatro límites que lo vuelven insuficiente como única prueba de que un core update te afectó. El primero es que la posición media que reporta promedia todos los países, dispositivos y variantes de la consulta juntos: puedes haber caído fuerte en móvil en Colombia y subido en escritorio en España, y el promedio te muestra un número tibio que no describe ninguno de los dos casos. Si quieres el detalle de por qué esa aritmética falla como línea base, lo desarrollamos aparte en por qué la posición media de Search Console no sirve como línea base.

El segundo límite es el retraso de dos a tres días en los datos: si comparas el día exacto del despliegue, todavía no tienes información completa de ese día. El tercero es que las impresiones mezclan dos causas distintas — cambiaste de posición, o Google cambió los bloques que muestra para esa búsqueda (agregó un resumen con IA, quitó un fragmento destacado) — y Search Console no te dice cuál de las dos pasó.

El cuarto son dos ventanas de datos con anomalías conocidas que conviene no usar como base sin ajustar: un error de registro infló impresiones, CTR y posición media del 13 de mayo de 2025 al 27 de abril de 2026 (los clics no se vieron afectados), y desde el 7 de mayo de 2026 Google dejó de mostrar el resultado de FAQ en la mayoría de las búsquedas — justo en la fecha base del core update de mayo. Ninguna de las dos invalida Search Console, pero si tu ventana de comparación cae ahí, la lectura queda torcida. Vamos a dedicarle un post aparte a cada quiebre de este tipo; por ahora, con la fecha en la mano, ya sabes cuándo desconfiar.

Por eso la comparación de un core update necesita una segunda fuente: un rank tracker con chequeo diario e historial de competidores te da tu propia serie de posiciones, sin promediar países entre sí y sin depender de que Google decida mostrar o no un bloque adicional en la SERP.

Cómo saber si te afectó un core update: el protocolo de 14 días contra 14

Antes de aplicar cualquiera de estos pasos, un filtro previo que vale la pena hacer primero: si todavía no tienes claro que bajaste de verdad y no es solo el vaivén normal de un día, conviene separar el ruido de una caída real antes de gastar tiempo comparando ventanas de un core update que quizás ni te tocó.

Con eso descartado, este es el protocolo completo, pensado para correrlo tú mismo con tu propio historial de posiciones y contrastarlo después con Search Console.

1. Paso 1 · Confirma inicio y fin del despliegue

   En el Google Search Status Dashboard, anota la fecha exacta de inicio y fin (por ejemplo, mayo 2026: del 21-may al ~2-jun, 11 días y 21 horas). Sin esas dos fechas no puedes fijar ninguna ventana.

2. Paso 2 · Revisa qué más cae cerca

   Spam updates, Discover updates, anomalías conocidas de Search Console, temporadas comerciales y tus propios despliegues (rediseño, migración, cambio de plantilla). Si algo pisa tu ventana, córrela para el lado que quede libre.

3. Paso 3 · Fija la ventana base

   Los 14 días que terminan el día antes de que empiece el despliegue. Es tu punto de comparación limpio, sin ningún ajuste de Google todavía aplicado.

4. Paso 4 · Fija la ventana posterior

   Los 14 días que empiezan el día después del fin. Nunca midas ni compares mientras el despliegue sigue en curso: las posiciones oscilan porque Google todavía está probando.

5. Paso 5 · Compara la mediana, no el promedio

   Por keyword, calcula la mediana de posición de cada ventana y el porcentaje de keywords en top 3 y en top 10. La mediana no se deja arrastrar por un día suelto con una posición rara.

6. Paso 6 · Segmenta

   Por tipo de página, intención, dispositivo y ciudad o país. Un promedio general esconde que el update te pegó solo en un segmento concreto.

7. Paso 7 · Compara contra tu ruido de fondo

   Marca un segmento como afectado solo si el cambio se sostiene toda la ventana posterior y supera la variación que ya tenías entre dos quincenas normales anteriores al update. Sin ese punto de comparación, cualquier oscilación parece un efecto del core update.

8. Paso 8 · Cruza con el top 10 histórico

   Por cada keyword que cayó, revisa quién entró o subió en tu top 10 y qué tipo de página es. Te dice qué premió Google esta vez, no solo que a ti te fue peor.

9. Paso 9 · Contrasta con Search Console

   Con las mismas ventanas, mismo filtro de país y tipo de búsqueda, revisa clics reales y anota cualquier anomalía. Es el paso donde conviene cruzar Search Console con tus posiciones diarias en lugar de mirar cada fuente por separado.

10. Paso 10 · Decide y anota la fecha

    Esperar, corregir algo técnico o reescribir. Sea cual sea la decisión, anota la fecha en la que la tomaste: la vas a necesitar para medir su efecto más adelante.

¿Por qué 14 días y no la semana completa que sugiere la documentación de Google? Porque una sola semana arrastra el efecto día de la semana (tus keywords transaccionales se mueven distinto un lunes que un domingo) y el ruido normal de siete mediciones es demasiado alto para separarlo de un cambio real. Catorce días cubren dos ciclos semanales completos en cada ventana, lo que diluye ese sesgo sin alargar la espera de forma poco práctica.

Core update de marzo y mayo de 2026: las ventanas ya calculadas

Para ahorrarte el paso 2 y 3 del protocolo en los dos updates más recientes de 2026, estas son las ventanas ya ajustadas por los eventos cercanos que encontramos al revisar el calendario.

En marzo, la ventana base corre del 10 al 23, cortando justo antes del spam update del 24 de marzo para que esos tres días no se mezclen con el efecto del core que empezó el 27. En mayo, la ventana base (7-20 de mayo) coincide en Search Console con el fin del resultado de FAQ del 7 de mayo: si vas a contrastar impresiones de ese periodo en GSC, recuerda que parte de la caída de impresiones ahí puede venir de ese cambio de SERP y no del core update en sí — con tu propio historial de posiciones ese ruido no aplica, porque mide posición, no impresiones.

Fuente de las fechas de inicio y fin: Google Search Status Dashboard, consultado el 10 de septiembre de 2026.

Leer por segmentos: tipo de página, intención y dispositivo

Un core update casi nunca pega parejo en todo un sitio. Es habitual que una categoría de páginas suba mientras otra baja, que móvil se mueva distinto que escritorio, o que un país reaccione distinto a otro con la misma keyword exacta. Si te quedas con el número global, esos movimientos se cancelan entre sí y terminas leyendo "no pasó nada" cuando en realidad pasaron dos cosas opuestas al mismo tiempo.

El desglose que da mejor señal, en este orden: primero por tipo de página (home, categoría, producto, guía de blog — cada una compite contra una SERP distinta); después por intención (informacional contra transaccional, porque Google suele ajustar estos dos grupos con pesos distintos en un core update); y por último por dispositivo (móvil contra escritorio). Si vendes en más de un país, agrega también país o ciudad: con cobertura en 19 países y 52 ciudades, es habitual ver que un core update golpee la SERP de una ciudad y deje intacta la de otra con exactamente la misma keyword.

Para cada segmento, compara la mediana de posición de la ventana base contra la posterior, igual que en el paso 5 del protocolo, pero calculada solo con las keywords de ese grupo. Y aplica el mismo filtro del paso 7: un segmento cuenta como afectado solo si el cambio se sostiene los 14 días completos y supera la variación que ese mismo grupo ya tenía entre dos quincenas normales anteriores al update — esa variación es tu ruido de fondo, y cada sitio tiene el suyo.

Este criterio de segmentación es propio, no una recomendación oficial de Google: lo compartimos porque es el que nos ha dado lecturas más claras, pero no hay una fórmula publicada por Google que diga "así se mide un core update por segmento". Ajusta los grupos al tamaño y la estructura real de tu sitio.

Quién ganó lo que perdiste: cruzar con el top 10 histórico

Saber que bajaste es la mitad de la información. La otra mitad está en leer el historial de competidores de cada keyword afectada: qué dominio entró al top 10 que no estaba antes del despliegue, o qué dominio que ya estaba subió varios puestos en la misma ventana. Ese dato es el que convierte "bajé" en información accionable.

Lo que importa no es solo el nombre del dominio ganador, sino qué tipo de página es: un foro, un medio de noticias, un marketplace, un sitio oficial de marca, una guía independiente. Si en cinco de tus keywords caídas el que sube es sistemáticamente el mismo tipo de página — digamos, foros y comunidades — eso te dice algo concreto sobre qué formato está premiando Google en este update para esa intención de búsqueda, más allá de cualquier ajuste que hagas en tu propio contenido.

Este cruce también sirve para descartar una lectura equivocada: si el dominio que te desplazó es el mismo en todas tus keywords y es un competidor grande que viene subiendo desde antes del core update, es probable que lo que estés viendo no sea el efecto del update sino una tendencia que ya traía y que el update simplemente aceleró. Mirar el historial completo, no solo las dos ventanas de 14 días, evita que le atribuyas al core update algo que ya venía pasando.

La trampa de la línea base (y los impactos positivos)

Todo este protocolo asume que tenías una ventana base con datos: 14 días de historial propio antes de que empezara el despliegue. Si empezaste a medir una keyword después del core update, esa ventana simplemente no existe y no hay comparación posible con datos propios, por más que quieras forzarla. Es la trampa más común y la más silenciosa: se nota semanas después, cuando ya es tarde para el update que acaba de pasar pero todavía a tiempo para el próximo.

Otra fuente de contaminación que conviene descartar antes de atribuirle todo al core update: en varios países de LATAM, mayo y junio traen temporadas comerciales fuertes (Hot Sale, CyberDay, entre otras según el país) que mueven volumen de búsqueda e intención de forma independiente del algoritmo — confirma las fechas exactas de 2026 en tu mercado antes de descartarlas como variable. Lo mismo con tus propios cambios: si lanzaste una migración, un rediseño o cambiaste títulos en fechas cercanas al despliegue, esa variable se mezcla con el efecto del core update y el protocolo por sí solo no las distingue.

Y si el resultado fue positivo, aplica el mismo rigor antes de celebrar: confirma la subida con el mismo protocolo de 14 contra 14, revisa que se sostenga en la ventana completa y no solo en un par de días sueltos, y verifica que no coincida con una de las temporadas comerciales o un cambio propio que también pudo explicarla. Una subida real que confirmas con datos vale más que una que asumes.

Sobre el chequeo con el que sostienes todo esto: el chequeo diario del plan Pro es el que te da la resolución para fechar el cambio con precisión; el chequeo semanal de Free sirve para ver que hubo una tendencia, pero no para decir en qué día empezó. Y aun con chequeo diario, la gráfica de Evolución de cada keyword en la app muestra hasta tus últimas 180 mediciones: para un análisis de años hacia atrás, esa ventana también tiene un límite.

Si te afectó: cuándo esperar al próximo core update y cuándo tocar el sitio

Esta sección responde solo una pregunta — esperar o actuar — y deliberadamente no entra en tácticas para recuperar posiciones: eso merece su propio desarrollo y ya lo cubrimos aparte en la guía de cómo subir de las posiciones 11-20 a la primera página. Aquí el objetivo es más chico: decidir qué hacer con la información que ya reuniste con el protocolo.

Espera si, después de segmentar y cruzar con el top 10 histórico, la caída es leve o se reparte entre varios competidores sin que encuentres ningún fallo técnico de tu lado. Google mismo lo dice en su documentación: no hace falta esperar al próximo core update específico, porque hay actualizaciones principales más chicas y continuas que también pueden mover algo a tu favor sin que anuncien ninguna fecha.

Actúa si el cruce con el protocolo revela un error técnico concreto (una plantilla entera que perdió indexación, un bloque que dejó de renderizar, un cambio accidental de canonical) o si una categoría completa de tu sitio cayó de forma pareja mientras el resto se mantuvo — eso sugiere un problema propio, no solo el reajuste general del algoritmo.

En cualquiera de los dos casos, ten presente lo que Google no promete: no hay garantía de recuperación, ni un plazo fijo, ni una acción específica que revierta el efecto. Lo único que puedes controlar es medir con rigor para tomar la decisión correcta con la información que sí tienes.

Qué dejar listo hoy para el próximo core update

El próximo core update llega sin aviso previo: Google no publica un calendario. Lo único que controla qué tan rápido y con qué claridad vas a poder leerlo es lo que dejes armado hoy, no lo que armes cuando ya esté en curso.

Cuatro cosas concretas: una muestra de keywords representativa por segmento (tipo de página, intención, dispositivo, y país o ciudad si vendes en más de uno), etiquetada desde ya para no tener que reconstruir esos grupos a mano dentro de tres meses; un chequeo diario activo, porque la resolución de días es la que separa "se estabilizó" de "tuvo suerte el día de la medición"; alertas activas para no depender de entrar a revisar todos los días; y Search Console conectado, para tener el contraste de clics e impresiones cuando llegue el momento del paso 9 del protocolo.

Ninguna de estas cuatro cosas te dice qué hacer si el próximo core update te afecta. Lo que hacen es asegurarte de tener, ese día, exactamente lo que le faltó a la mayoría de los sitios en el despliegue de mayo: una línea base propia y limpia. Es cómo guarda Rankiamos tu línea base y el top 10 de cada palabra clave, listo antes de que Google avise nada.