Core update: qué es una actualización principal de Google

Google reajusta varias veces al año los sistemas que deciden el orden de los resultados. Esos reajustes se anuncian, reciben un nombre con mes y año, y afectan a la vez a todo tipo de sitios y de consultas. La consecuencia práctica incomoda: una página puede bajar sin que nadie en Google haya mirado esa página.

Conviene separar tres cosas que en las conversaciones de negocio se mezclan casi siempre. Una acción manual es una decisión humana sobre un sitio concreto, se comunica en Search Console y admite una solicitud de revisión. Una actualización antispam mejora los sistemas automáticos que detectan prácticas prohibidas. Una actualización principal no hace ninguna de las dos cosas: reordena, y ya está.

Google explica el efecto con una comparación doméstica. Si alguien reescribe hoy su lista de veinte restaurantes favoritos, los que pierden puestos no se han vuelto malos; simplemente hay candidatos nuevos y criterios nuevos. Perder posiciones tras una actualización principal no demuestra que la página incumpla nada.

Tampoco todas cubren la búsqueda entera. El 5 de febrero de 2026 Google publicó una actualización principal dirigida a Discover, con la misma etiqueta y la misma guía general, pero limitada a esa superficie.

El despliegue no es instantáneo. Google publica la fecha de inicio y la de cierre en su panel de estado de la búsqueda, y entre ambas los resultados se mueven más de lo habitual porque los distintos sistemas se actualizan en momentos distintos. Cuando la actualización toca varios sistemas a la vez, el proceso se alarga: al anunciar la de marzo de 2024, Google avisó de que el despliegue podía durar hasta un mes.

Mientras el despliegue sigue abierto, cualquier lectura de datos es provisional. La recomendación oficial es esperar al menos una semana completa después del cierre y comparar entonces esa semana con una semana anterior al inicio. Comparar contra el propio periodo de despliegue produce cifras que cambian solas.

Después toca medir el tamaño real del movimiento por página y por consulta, no por el total del sitio. Una caída de la posición 2 a la 4 no justifica tocar nada, y Google desaconseja expresamente modificar contenido que ya funciona. Una caída de la posición 4 a la 29 sí pide un análisis a fondo. También ayuda separar web, imágenes, vídeo y noticias, porque un desplome concentrado en una sola superficie apunta a otra causa.

Y aquí llega la parte que la industria suele reescribir. A la pregunta «¿qué hago para recuperarme?», la respuesta oficial no es una lista de arreglos: Google afirma que no hay acciones específicas para recuperarse de una actualización principal y que un impacto negativo puede no significar que haya nada mal en las páginas. Lo que ofrece a cambio es un cuestionario de autoevaluación sobre el sitio entero, más el aviso de que las mejoras pueden tardar meses en notarse y de que ningún cambio garantiza un efecto visible.

La decisión que depende de este concepto es si hay que reaccionar y con qué presupuesto. Una caída que coincide con una actualización principal se parece muchísimo a una caída por un fallo técnico, por un cambio de plantilla o por un competidor que acaba de publicar algo mejor. Confundirlas cuesta dinero: se reescribe lo que estaba bien y se deja intacto lo que estaba roto.

La segunda decisión es de plazos y de promesas. Los cambios de contenido pueden tardar meses en reflejarse, y el propio buscador no garantiza que ninguna modificación produzca un efecto visible. Un plan que prometa la vuelta a la posición anterior para el mes siguiente promete algo que Google no promete.

La tercera es de gobierno interno. Si cada movimiento del ranking se atribuye a la última actualización anunciada, nadie revisa las causas aburridas: una migración a medias, un noindex olvidado, una campaña que terminó, una caída estacional de la demanda. Fechar el episodio y cruzarlo con el calendario oficial convierte una discusión de opiniones en una comprobación.

• Anotar en el calendario analítico la fecha de inicio y de cierre de cada actualización anunciada, para poder cruzarla después con los datos propios.
• Esperar a que el despliegue termine y dejar pasar una semana más antes de sacar conclusiones o presentar cifras a un cliente.
• Comparar la semana posterior con una semana anterior al inicio, y hacerlo por página y por consulta, no solo sobre el total del sitio.
• Descartar primero las causas técnicas y de negocio: rastreo, indexación, cambios de plantilla, estacionalidad, campañas terminadas.
• Aplicar el cuestionario de autoevaluación al sitio completo y pedir además a alguien ajeno al proyecto que lo responda, porque la mirada propia sobre el contenido propio es indulgente.
• Trabajar sobre las páginas más afectadas con mejoras sustanciales de utilidad y tratar el borrado como último recurso.

• Llamar penalización a una bajada posterior a una actualización principal, con lo que se busca un culpable y un formulario de reconsideración que en este caso no existe.
• Medir durante el despliegue y decidir con datos que todavía se están moviendo.
• Aplicar arreglos rápidos aprendidos de oídas, como quitar un elemento de la página porque alguien lo declaró perjudicial.
• Borrar secciones enteras por reflejo. Si la reacción natural es borrar, la pregunta útil es por qué se publicaron esas secciones.
• Atribuir cada oscilación a la última actualización anunciada y no revisar nunca el rastreo, la indexación ni la demanda.