Primero confirma que fue una core update cruzando la fecha de tu caída con el Search Status Dashboard de Google y comprobando si el declive afecta a todo el sitio o solo a algunas páginas. La postura de Google es que una caída no significa que algo esté roto. La recuperación, cuando llega, suele hacerlo con una actualización posterior tras mejorar el contenido de verdad.
La primera hora después de una gran caída de rankings es cuando se produce la mayor parte del daño. No por la actualización — por la reacción. Se borran páginas, se reescribe contenido con pánico, se desautorizan enlaces en bloque, y tres meses después nadie sabe qué cambio empeoró las cosas porque todo cambió a la vez.
Así que frena. Este artículo cubre cómo confirmar lo que pasó realmente, cómo distinguir una core update de una acción manual o de un fallo técnico, qué significa en la práctica la guía publicada de Google, y qué aspecto tiene honestamente la recuperación — incluida la parte incómoda: algunos sitios no recuperan lo que perdieron.
¿Cómo confirmas que fue realmente una core update?
Tres comprobaciones: cruza la fecha de tu caída con la lista publicada de actualizaciones de ranking de Google, mira si el declive es de todo el sitio o está limitado a páginas concretas, y abre el informe de Acciones manuales en Search Console. Si las fechas encajan, la caída es amplia y no hay acción manual, una core update es la explicación probable.
Google mantiene un Search Status Dashboard que lista las actualizaciones de ranking con sus fechas de inicio y finalización, y anuncia las broad core updates cuando empiezan a desplegarse. Esa es la fuente autorizada. Los rastreadores de volatilidad de terceros sirven como corroboración, pero miden una muestra de keywords y pueden señalar turbulencias que no tienen nada que ver con una actualización anunciada.
El matiz temporal importa. Las core updates se despliegan a lo largo de días o semanas, no aterrizan de golpe, así que los rankings pueden moverse varias veces durante el despliegue y asentarse en un sitio distinto de donde estaban a mitad de camino. Juzgar tu posición el día tres de un despliegue de dos semanas te va a engañar. Espera a la fecha de finalización antes de sacar conclusiones.
La distinción entre caída sitewide y caída por páginas es la señal individual más diagnóstica. Las core updates suelen reevaluar de forma amplia cómo se valora el contenido de un sitio, así que las caídas tienden a aparecer en muchas páginas y temas a la vez. Un declive confinado a una página o a una plantilla, en una fecha que no coincide con ninguna actualización anunciada, apunta a otra parte completamente distinta.
¿Qué diferencia hay entre una core update, una acción manual y un fallo técnico?
Producen patrones de síntomas distintos, y distinguirlos lleva unos diez minutos. Una acción manual es una decisión humana registrada en Search Console. Un fallo técnico tiene una causa mecánica localizable. Una core update no tiene ni lo uno ni lo otro — solo un cambio amplio en cómo se valora tu contenido.
| Señal | Core update | Acción manual | Problema técnico |
|---|---|---|---|
| Notificación en Search Console | Ninguna | Sí, en el informe de Acciones manuales | Normalmente errores en los informes de Indexación o Experiencia de página |
| Fecha | Coincide con una ventana de despliegue anunciada | Cualquier fecha; suele seguir a un patrón de infracciones | Suele coincidir con un despliegue o una migración |
| Alcance | Amplio, en muchas páginas y temas | Puede ser de todo el sitio o limitado a las URLs afectadas | Suele estar confinado a una plantilla, sección o patrón de URL |
| Estado de indexación | Las páginas siguen indexadas | Las páginas pueden ser retiradas o fuertemente degradadas | Las páginas pueden desaparecer del índice por completo |
| Forma de la caída | Gradual durante el periodo de despliegue | Abrupta y severa | Abrupta, y las impresiones suelen caer casi a cero |
| ¿Hay solicitud de reconsideración? | No | Sí, una vez corregido el problema | No aplica |
| Camino de resolución típico | Mejorar el contenido y esperar a una actualización posterior | Corregir la infracción y pedir reconsideración | Arreglar el fallo; la recuperación suele ser rápida |
Recorre esa tabla antes de tocar nada. La columna técnica es la que conviene descartar primero, porque los fallos técnicos son los más arreglables y los que más se atribuyen mal. Una migración chapucera que pierde las etiquetas canonical parecerá catastrófica y se sentirá algorítmica, y no es ninguna de las dos cosas.
¿Por qué dice Google que no hay nada que arreglar, y qué significa eso en la práctica?
La guía de Google sobre las core updates dice que una caída no indica necesariamente que haya algo mal en tus páginas — la actualización cambió cómo se evalúa el contenido en relación con todo lo demás. En la práctica eso significa que no hay un error que corregir, pero no significa que no haya nada que hacer.
La distinción es entre un fallo y una comparación. Una acción manual dice que rompiste una regla. Una core update dice que otro contenido ahora se valora mejor que el tuyo para las mismas búsquedas. Nada en tu sitio pasó a estar técnicamente mal; el listón se movió, o la competencia mejoró, o el sistema aprendió a reconocer mejor lo que los usuarios querían desde el principio.
El consejo práctico de Google es centrarse en las preguntas de autoevaluación de su guía sobre crear contenido útil, fiable y centrado en las personas — preguntas sobre si el contenido demuestra experiencia de primera mano, si deja al lector con la sensación de haber aprendido lo suficiente, si existe principalmente para atraer tráfico de búsqueda. Esas preguntas son lo bastante vagas para resultar frustrantes y lo bastante concretas para ser útiles si las respondes con honestidad sobre tus veinte peores páginas.
Este es el replanteamiento que más ayuda. Deja de preguntarte “qué hice mal” y empieza a preguntarte “por qué un lector preferiría las páginas que ahora me superan”. Ábrelas. Léelas de verdad. La respuesta suele ser visible en diez minutos, y suele tener que ver con especificidad, conocimiento de primera mano o utilidad genuina, no con nada técnico.
Espera a que el despliegue termine
Los rankings se mueven varias veces durante el despliegue de una core update, a veces recuperándose parcialmente antes de asentarse. Cualquier cambio que hagas a mitad de despliegue se evalúa contra una línea base en movimiento, y nunca sabrás si tu arreglo ayudó o si la actualización simplemente terminó. Espera a la fecha de finalización confirmada, y luego dale una semana más.
¿Qué deberías comprobar antes de cambiar nada?
Ejecuta un diagnóstico completo antes de tocar el contenido. El objetivo es establecer qué cayó exactamente, para qué búsquedas, y si el patrón apunta a un tema, una plantilla o un tipo de página. Saltarse este paso es la forma en que los sitios acaban reescribiendo lo que no era.
- Revisa primero el informe de Acciones manuales en Search Console — descarta o confirma la única causa con solución definida
- Cruza la fecha de la caída con el Search Status Dashboard de Google, anotando inicio y finalización del despliegue
- Compara una ventana de cuatro semanas antes y después, filtrada solo a búsqueda orgánica
- Exporta las búsquedas y páginas que más impresiones perdieron, ordenadas por pérdida absoluta, no por porcentaje
- Busca un patrón — un clúster temático, una plantilla, un tipo de contenido, o genuinamente todo
- Confirma que las páginas caídas siguen indexadas y no han sido retiradas
- Comprueba si algo se desplegó en el sitio en la misma quincena — despliegues, actualizaciones de plugins, cambios de plantilla
- Abre los resultados que ahora te superan en cinco búsquedas perdidas y léelos enteros
- Fíjate en si cambió la propia página de resultados — las nuevas funciones del SERP pueden recortar clics sin ningún cambio de ranking
- Escribe una hipótesis antes de hacer ningún cambio, para poder ponerla a prueba
Ese último punto es la disciplina que separa la recuperación del manoteo. Una hipótesis, un conjunto de cambios, y luego una espera. Si cambias seis cosas a la vez y los rankings vuelven, no has aprendido nada transferible y estarás en la misma posición en la próxima actualización.
¿Qué no deberías hacer tras una caída por core update?
Tres reacciones causan más daño que la propia actualización: borrar contenido en bloque, desautorizar enlaces en masa, y reescribir todo el sitio de golpe. Las tres se sienten decididas. Las tres destruyen tu capacidad de diagnosticar nada.
Borrar contenido con pánico. El consejo de podar páginas de bajo rendimiento se aplica mal constantemente después de las actualizaciones. Las páginas con poco tráfico no son necesariamente dañinas, y eliminarlas puede costarte estructura de enlazado interno, cobertura temática y alguna página que convertía en silencio. Si una página es genuinamente pobre y no sirve a ningún lector, mejórala o fusiónala — el borrado debería ser la última opción, no la primera.
Desautorizar en masa. Google ha dicho repetidamente que la herramienta de desautorización es innecesaria para la gran mayoría de los sitios, y las core updates no son penalizaciones por enlaces. Subir un archivo de desautorización enorme tras una caída algorítmica es un reflejo común y genuinamente arriesgado, porque puedes retirar enlaces que te estaban ayudando. Salvo que tengas una acción manual por enlaces no naturales, o sepas que compraste un gran volumen de enlaces de baja calidad, déjalo en paz. Cubrimos el cálculo de riesgo de los enlaces de pago en nuestro artículo sobre si comprar enlaces es realmente peligroso.
Reescribirlo todo de golpe. Más allá del problema diagnóstico, las reescrituras totales suelen sustituir páginas que estaban bien por páginas que simplemente son distintas. Empieza por las veinte páginas que más impresiones perdieron, mejóralas como es debido, y mira qué pasa antes de tocar el resto.
Hay una cuarta reacción que merece nombre propio: comprar enlaces para arreglar una caída algorítmica. No funciona, porque una core update no devaluó tus enlaces — reevaluó tu contenido. Añadir dominios de referencia a una página que Google ahora considera una respuesta más débil es gastar dinero en el eje equivocado. Si lo que quieres es comprobar si tu perfil actual es un lastre, nuestra guía para evaluar qué enlaces merecen conservarse es mejor punto de partida que un archivo de desautorización.
¿Qué aspecto tiene una recuperación realista?
Recuperarse de una core update generalmente requiere que una core update posterior reevalúe el sitio, lo que significa que el plazo se mide en meses y lo marca el calendario de lanzamientos de Google, no el tuyo. Google ha dicho que los sitios pueden tener que esperar a una actualización posterior, y que las mejoras hechas ahora se evalúan entonces.
Eso es difícil de asumir. Haces mejoras genuinas, y no pasa nada durante semanas o meses, porque el sistema que te degradó no ha vuelto a ejecutarse. Por eso importa tanto la disciplina de la hipótesis única — el ciclo de retroalimentación es tan lento que la experimentación desestructurada no te da nada.
La recuperación parcial es más común que la total. Los sitios que mejoran sustancialmente suelen recuperar una parte significativa de lo que perdieron, no todo, especialmente cuando la actualización reflejó un cambio duradero en lo que los resultados premian. Y algunos sitios no se recuperan, sobre todo cuando el modelo de negocio dependía de posicionar contenido que Google ha decidido que sirve al usuario peor que las alternativas. No es algo cómodo de escribir para una empresa de SEO, pero fingir lo contrario es vender falsas esperanzas.
Los sitios a los que mejor les auguramos son los que tratan la caída como información y no como una herida. Si una core update te dijo que tus páginas comparativas son más pobres que las que ahora las superan, eso también era verdad antes de la actualización. Simplemente no te lo estaban cobrando. Si quieres una lectura externa de qué páginas son genuinamente débiles, una evaluación estructurada de dónde está tu contenido frente a lo que ahora posiciona te llevará ahí más rápido que mirar tus propias páginas.
Ideas clave
- Confirma la causa primero: cruza fechas con el Search Status Dashboard de Google, revisa el alcance y el informe de Acciones manuales.
- Las core updates, las acciones manuales y los fallos técnicos producen patrones de síntomas distintos — descarta lo técnico primero.
- La postura de Google de que nada está roto significa que no hay un fallo que corregir, no que no haya nada que mejorar.
- Espera a que el despliegue termine antes de cambiar nada, y luego formula una hipótesis y ponla a prueba.
- Evita los borrados masivos, las desautorizaciones en masa y las reescrituras totales — las tres destruyen tu capacidad de diagnóstico.
- Comprar enlaces no arregla una reevaluación algorítmica del contenido; es gastar dinero en el eje equivocado.
- La recuperación suele necesitar una core update posterior, a menudo es parcial, y a veces no llega.
¿Cuánto tardan en asentarse los rankings tras una core update?
Google publica las fechas de inicio y finalización de cada despliegue, y la finalización suele llegar entre días y unas pocas semanas después del inicio. Dale una semana más allá de la fecha de finalización publicada antes de dar tus posiciones por definitivas — el movimiento residual es común.
¿Ayuda añadir backlinks después de una core update?
No para la caída en sí. Una core update reevaluó cómo se valora tu contenido, así que la autoridad no es la restricción que cambió. Los enlaces siguen siendo útiles para páginas que compiten con una brecha de autoridad genuina — ese es un problema distinto que casualmente comparte calendario con este.
¿Debería desautorizar enlaces tras una caída algorítmica?
Casi seguro que no. Google ha dicho que la herramienta de desautorización no es necesaria para la mayoría de los sitios, y está pensada para acciones manuales por enlaces no naturales, no para core updates. Desautorizar en bloque puede retirar enlaces que te ayudaban, lo que convierte un mal trimestre en uno peor.