Content decay: como identificar posts que estan perdiendo trafico
Un proceso de auditoria practico para detectar que posts estan sangrando clics y priorizar las actualizaciones con datos, no con corazonadas.
Hace tres meses un cliente perdio el 38% del trafico organico de un post que rankeaba en primera posicion desde hacia dos anos. Nadie toco la pagina. Google no penalizo nada. Lo que ocurrio fue content decay: ese declive silencioso que ataca al buen contenido mientras tu estas ocupado publicando cosas nuevas. No es algoritmo, no es penalizacion, es entropia. Y casi todo blog con mas de 18 meses tiene entre el 20% y el 40% del catalogo en esa situacion ahora mismo, generando la mitad del trafico que podria. El problema es que nadie audita hasta que el trafico total cae y el CFO pregunta por que.
Lo primero que hago es abrir Search Console y exportar 16 meses de impresiones y clics por URL, segmentado por mes. En Looker Studio comparo el trimestre actual contra el mismo trimestre del ano anterior. Cualquier URL con caida superior al 25% en clics entra en la lista de sospechosos. Despues cruzo con la posicion media: si la posicion bajo mas de 3 puntos, es problema de ranking. Si la posicion se mantuvo pero el CTR se desplomo, normalmente es una SERP feature comiendose el clic. Este split cambia toda la estrategia de reescritura. Para el segundo caso, conviene repasar Title tags que convierten: 7 patrones probados en SERPs reales y Meta description aun importa? Lo que los datos de CTR muestran antes de tocar el cuerpo.
Despues de aislar las URLs en decay, las clasifico en cuatro buckets. Primero: decay por desactualizacion factual, tipico en posts con el ano en el titulo o herramientas que cambiaron. Segundo: decay por intencion migrada, cuando la SERP paso de informacional a comercial o viceversa. Tercero: decay competitivo, cuando alguien publico algo objetivamente mejor. Cuarto: decay tecnico, casi siempre por migraciones mal hechas, canonical incorrecto o problemas de crawl. Cada bucket pide un tratamiento distinto. Mezclar todo en un "update general" es como dar antibiotico para un virus. Para el tercer bucket, Reescribir o rehacer: la decision basada en datos de SERP ayuda a decidir entre cirugia y demolicion.
Para el diagnostico tecnico ejecuto Screaming Frog en la URL, reviso cabeceras, comparo el HTML renderizado con el servido y miro los logs de Googlebot de los ultimos 60 dias. Aqui aparecen cosas absurdas: posts con noindex accidental desde una migracion, canonical apuntando al home, JavaScript que esconde la mitad del contenido en mobile. Cuando Googlebot deja de visitar la pagina, el decay se acelera. Vale combinar con lo que esta en Log file analysis: que esta haciendo realmente Googlebot y Canonical tags: errores comunes que sangran trafico organico. En 4 de cada 10 auditorias el problema es tecnico y no editorial. Reescribir sin chequear esto es desperdicio de horas de redactor.
Cuando el problema si es editorial, uso una matriz de priorizacion simple: clics perdidos en los ultimos 90 dias multiplicados por el valor medio por sesion de la URL (sacado de GA4). Eso me da un ranking de impacto en euros. Tomo los 20 primeros y abro un documento por URL con tres secciones: lo que la SERP actual espera (analisis del top 10), lo que el post entrega hoy y el gap. Aqui tambien cruzo con Intencion de busqueda: 4 tipos y como mapearla en la SERP porque la mitad de los decays que veo son posts informacionales intentando rankear para queries que se volvieron transaccionales. Reescribir el parrafo de apertura no resuelve eso, hace falta un angulo nuevo.
En la ejecucion del refresh mantenemos la URL, actualizamos la fecha de publicacion solo si la reescritura supera el 40% del cuerpo y republicamos con un changelog visible en el pie para senalar frescura al usuario y a Google. Actualizamos title, meta, primer parrafo y agregamos bloques nuevos que respondan a las PAAs actuales. Internamente, redirigimos enlaces desde posts relacionados para reforzar la autoridad interna, algo que detalle en Interlinking inteligente: el mapa de autoridad interna. Monitorizamos durante 6 semanas con alerta de caida en Search Console. De media, el 70% de los posts en decay recupera al menos el 60% del trafico perdido en 90 dias, con un coste de 4 a 8 horas por post.
El takeaway practico: agenda una auditoria de decay trimestral, fija en el calendario, antes de planificar nuevos posts. Reserva el 30% de la capacidad editorial para refresh, no el 5%. Contenido viejo rankeando bien vale mas que contenido nuevo peleando por posicion. Empieza manana exportando 16 meses de GSC, filtrando caidas mayores al 25% y atacando los tres primeros de la matriz de impacto. Vas a recuperar mas trafico en dos semanas que en tres meses publicando novedades.