Recuperar tráfico tras una caída: diagnóstico antes que remedio

Respuesta breve

Ante una caída de tráfico, la primera tarea no es corregir sino delimitar. Hay que saber qué segmento ha bajado, desde cuándo y si el resto se mantiene, antes de tocar nada. La mayoría de las caídas atribuidas a una actualización del algoritmo, como un core update, resultan ser un cambio propio, un fallo técnico o un desplazamiento de la demanda. Y cuando efectivamente coinciden con una actualización, la respuesta útil tampoco es una lista de retoques rápidos.

Puntos clave

• Delimita el alcance antes de formular hipótesis: qué páginas, qué consultas, qué dispositivo, qué país.
• Separa pérdida de posiciones, pérdida de impresiones y pérdida de clics: son diagnósticos distintos.
• Comprueba primero lo que puedes descartar en minutos: medición, indexación, errores de servidor.
• Coincidir con la fecha de una actualización no demuestra que sea la causa.
• Cambia una cosa cada vez y deja tiempo para leer el efecto.
• Sin registro de qué se cambió y cuándo, ninguna conclusión posterior es fiable.

Diagnóstico antes que remedio

1. ¿Es real?Medición y consentimiento antes de nada.
2. DelimitarPáginas, consultas, dispositivo, país y desde cuándo.
3. CronologíaQué se cambió y cuándo.
4. Descartar lo técnicoIndexación y errores de servidor, en minutos.
5. SepararPosiciones, impresiones y clics: tres diagnósticos.
6. IntervenirUna cosa cada vez, con tiempo para leer el efecto.

Antes de diagnosticar, comprueba que la caída es real

Un porcentaje de las caídas no ocurrió nunca en el sitio: ocurrió en la medición. Descartarlo cuesta poco y evita semanas de trabajo sobre un problema inexistente.

• revisa si se ha desplegado un cambio en el contenedor de etiquetas o en la configuración de analítica;
• comprueba si cambió el aviso de consentimiento, porque afecta a qué se registra;
• verifica que la propiedad, el filtro o la vista sean los mismos que antes;
• ten en cuenta el retraso de los informes y la zona horaria;
• contrasta al menos dos fuentes: si el descenso solo aparece en una, empieza por ahí;
• descarta que el periodo comparado incluya una anomalía puntual, como una campaña o una mención.

La lectura ordenada de los informes y las trampas de comparación están desarrolladas en el artículo sobre cómo diagnosticar una caída en Search Console. Aquí interesa el paso siguiente: qué hacer una vez confirmado que la pérdida es real.

Delimitar el alcance

La forma de la caída dice más que su tamaño. Un descenso repartido por todo el sitio apunta a una causa global; uno concentrado en una plantilla apunta a un cambio en esa plantilla. Segmenta y anota dónde se concentra la pérdida.

Formas de la caída, hipótesis inicial para cada una y primera comprobación.

Forma de la caída	Hipótesis inicial	Primera comprobación
Brusca y total, de un día para otro	fallo técnico o de medición	estado del servidor, indexación, etiquetas
Brusca y limitada a un directorio	cambio en esa plantilla	historial de despliegues y HTML actual
Gradual durante semanas	competencia o pérdida de relevancia	resultados actuales para esas consultas
Impresiones estables y clics abajo	cambia lo que rodea al resultado	aspecto del resultado y competidores
Impresiones abajo y posición estable	menos demanda o menos consultas servidas	estacionalidad y volumen de búsquedas
Solo en móvil o solo en un país	problema de plantilla o de entrega	prueba desde ese dispositivo y región

La distinción entre impresiones y clics es la que más veces se salta y la que más ahorra. Si las impresiones se mantienen y los clics bajan, el sitio sigue apareciendo: lo que ha cambiado es el entorno del resultado o lo que lo acompaña. Reescribir el contenido en ese escenario no ataca la causa.

Construir la cronología

El siguiente paso es cruzar la fecha del descenso con todo lo que ocurrió alrededor. Sin este registro, cualquier explicación es una suposición cómoda.

1. despliegues de código, cambios de tema y actualizaciones de plugins;
2. cambios de contenido, retiradas de páginas y reestructuraciones de menú;
3. modificaciones en robots.txt, canonical, sitemaps o etiquetas robots;
4. incidencias del servidor, caídas, lentitud o cambios de alojamiento;
5. cambios en el CDN, en el cortafuegos o en las reglas de bloqueo;
6. actualizaciones del algoritmo con fecha oficial;
7. acciones de la competencia y cambios en la demanda del sector.

Google publica el calendario de actualizaciones principales y su documentación sobre caídas de tráfico de búsqueda ordena las causas posibles, que incluyen fallos técnicos, cambios propios, estacionalidad e interés decreciente. Que una fecha coincida con un despliegue publicado no cierra el caso: hay que comprobar que el segmento afectado es compatible con esa causa y no con otra.

Descartar lo técnico primero

Las causas técnicas se comprueban rápido y explican una parte importante de las caídas bruscas. Merece la pena recorrerlas antes de plantear cualquier hipótesis sobre calidad.

• códigos de estado de una muestra de URLs afectadas, incluidas las que antes rendían;
• etiqueta robots y cabecera equivalente en esas plantillas;
• robots.txt actual, comparado con la versión anterior al descenso;
• canonical de las páginas afectadas y hacia dónde apunta;
• presencia en el sitemap y validez del fichero;
• tiempo de respuesta del servidor y errores registrados en esas fechas;
• bloqueos del cortafuegos o del CDN que afecten a rastreadores legítimos;
• contenido presente en el HTML procesado, no solo en el navegador.

El recorrido se hace por capas, desde la respuesta del servidor hacia las etiquetas de la página. Si aparece una causa técnica que explica el segmento y la fecha, se corrige y se espera antes de seguir buscando: superponer cambios impide saber cuál funcionó.

Cuando la causa no es técnica

Descartado lo anterior, quedan explicaciones que exigen más trabajo y dan resultados más lentos. Conviene abordarlas por orden de evidencia disponible.

La demanda ha cambiado. Si las impresiones bajan mientras la posición se mantiene, puede que se busque menos o de otra forma. Es la hipótesis más fácil de comprobar y la que más veces se descarta sin mirarla.

Los resultados han cambiado de intención. Compara lo que aparece hoy para esas consultas con lo que aparecía antes. Si el tipo de página que responde ha cambiado, el problema es de encaje, y la solución pasa por revisar qué tarea resuelve la página y si sigue siendo la que se espera para esa consulta.

Hay canibalización interna. Si varias páginas propias compiten por la misma consulta y la que rankea va cambiando, el problema es de arquitectura. El método para confirmarlo está en el artículo sobre detectar canibalización.

El contenido ha envejecido. Datos desactualizados, ofertas retiradas o un enfoque superado. La decisión entre actualizar, fusionar o retirar se toma con el criterio del artículo sobre actualizar, fusionar o retirar contenido.

Qué hacer si coincide con una actualización

Cuando la caída coincide con una actualización principal confirmada y no hay causa técnica ni de medición, la orientación oficial no ofrece una lista de correcciones. La documentación de Google remite a sus criterios sobre contenido útil y plantea preguntas de autoevaluación sobre originalidad, profundidad y experiencia demostrable.

Esto decepciona a quien busca una lista de tareas, pero es coherente con el mecanismo: una actualización revisa cómo se valoran los contenidos en conjunto, no penaliza un elemento concreto que se pueda arreglar. Por eso los retoques superficiales rara vez cambian nada, y por eso conviene desconfiar de cualquier explicación que prometa revertirlo con un ajuste.

El trabajo que sí tiene sentido es más lento: revisar qué páginas aportan algo que no está en otras, cuáles existen solo para ocupar una consulta, y si el conjunto del sitio sostiene lo que afirma. Ese análisis se hace sobre el inventario completo, no sobre las tres URLs que más han bajado. La documentación oficial también señala que la recuperación, cuando llega, puede tardar y no está garantizada, y que suele asociarse a cambios sustanciales, no a correcciones menores.

Cómo intervenir sin perder la capacidad de medir

El error que más veces impide aprender de una caída no es elegir mal la corrección, sino aplicar diez a la vez. Si se cambian plantillas, contenido, enlazado y configuración en la misma semana, la evolución posterior no se puede atribuir a nada.

1. escribe la hipótesis antes de actuar, con el segmento que debería recuperarse si es cierta;
2. define qué observación la refutaría, para poder descartarla;
3. aplica un cambio reversible cada vez y anota fecha y alcance;
4. deja pasar una ventana suficiente para que se reprocese lo afectado;
5. lee el resultado en el segmento previsto, no en el total del sitio;
6. si no se mueve, descarta la hipótesis en lugar de acumular otra encima;
7. mantén un registro de cambios que sobreviva a la memoria de quien lo hizo.

Ese registro es también lo que permite responder con honestidad cuando el tráfico vuelve. Si en el mismo periodo cambió la estacionalidad, se corrigió un fallo técnico y se reescribieron veinte páginas, atribuir la recuperación a lo último que se hizo es una conclusión sin respaldo.

El error que más veces impide aprender de una caída no es elegir mal la corrección, sino aplicar diez a la vez.

En cuatro láminas

1 cambio cada vez. Con tiempo para leer el efecto. Diez a la vez es el error que más veces impide aprender de una caída.

registro: 12-08 despliegue: plantilla de artículo / 14-08 aviso en Search Console / 19-08 actualización pública del buscador / 21-08 caída visible, concentrada en /blog/ / / # la fecha pública no cierra el caso: / # el segmento afectado tiene que ser compatible

Tres diagnósticos distintos. Columnas: Primera comprobación. Posiciones: Primera comprobación → Consultas concretas, antes y después. Impresiones: Primera comprobación → Indexación y segmento afectado. Clics con las mismas impresiones: Primera comprobación → La presentación del resultado

Errores frecuentes

• Empezar a corregir antes de delimitar el segmento afectado.
• Atribuir la caída a una actualización solo porque las fechas coinciden.
• No distinguir entre pérdida de impresiones y pérdida de clics.
• Saltarse la comprobación de medición y consentimiento.
• Aplicar varios cambios a la vez y perder la capacidad de atribuir.
• Reescribir contenido cuando el problema era un noindex desplegado por error.
• Comparar periodos no equivalentes o con anomalías dentro.
• Confiar solo en herramientas de terceros para medir posiciones.
• Descartar la estacionalidad sin haberla mirado.
• Retirar páginas en masa como reacción, sin inventario ni criterio.

Preguntas habituales

La caída coincide con una actualización del algoritmo. ¿Es la causa?

Coincidir en fecha no lo demuestra. La mayoría de las caídas atribuidas a una actualización resultan ser un cambio propio, un fallo técnico o un desajuste de medición desplegado esos mismos días. Antes de aceptar esa explicación conviene descartar en minutos lo que se puede descartar: medición, indexación y errores de servidor.

¿Han bajado las posiciones o los clics?

Son tres diagnósticos distintos y conviene separarlos: perder posiciones, perder impresiones o perder clics con las mismas impresiones. El tercero suele ser un cambio en la presentación del resultado o en el título, no un problema de contenido, y se corrige en otro sitio.

¿Cuánto espero antes de tocar nada?

Lo que haga falta para delimitar el segmento afectado: qué páginas, qué consultas, qué dispositivo, qué país y desde cuándo. Corregir antes de delimitar es lo que convierte una caída en dos problemas, porque los cambios se acumulan sobre un diagnóstico que aún no existe.

¿Puedo aplicar varias correcciones a la vez para ir más rápido?

Se pierde la capacidad de atribuir, y con ella la de revertir con precisión. Un cambio cada vez, con tiempo para leer el efecto y un registro de qué se tocó y cuándo. Sin ese registro, ninguna conclusión posterior es fiable, ni siquiera la de que algo funcionó.

Próximo paso

Antes de proponer ninguna corrección, construye dos cosas: la tabla de segmentos con la pérdida localizada y la cronología de todo lo que cambió alrededor de esa fecha. Con ambas delante, la lista de hipótesis suele reducirse a dos o tres, y una de ellas se comprueba en minutos. Empezar por ahí ahorra el trabajo de arreglar lo que no estaba roto.

Fuentes

• Google Search Central, las actualizaciones principales del algoritmo — documentación oficial.
• Google Search Central, depurar las caídas de tráfico de búsqueda — documentación oficial.
• Google Search Central, crear contenido útil y fiable — documentación oficial.

Servicio y herramienta relacionados

Si esto es lo que te está pasando, recuperar tráfico orgánico es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Y para hacerlo tú: la calculadora de escenarios sirve para poner números a lo que cambiaría, con las fórmulas a la vista y sin convertirlos en promesas. Funciona en tu navegador y no envía tus datos a ningún sitio.

Ver recuperar tráfico orgánico Abrir la calculadora de escenarios