El 14 de febrero de 2023 abrí un correo con un asunto de seis palabras: «hemos perdido el 41% del tráfico». Dentro, un enlace a un documento de 218 filas. Alguien del equipo interno había pasado tres semanas revisando cada punto de una lista de verificación descargada de internet y había marcado en rojo 63 incidencias. Ninguna de las 63 tenía relación con la caída.
¿Sabes qué había pasado en realidad? Un cambio en la plantilla de producto que llevaba diez meses funcionando sin problemas empezó a servir un bloque de contenido crítico por JavaScript después de que el proveedor de CDN modificara su política de caché. Diez minutos de comprobación bien orientada frente a tres semanas de revisión ciega. Esa desproporción es lo que separa una revisión técnica normal de una auditoría SEO forense paso a paso, capaz de llegar a la investigación de causa raíz.
Lo que sigue es el protocolo que usamos internamente cuando entra un caso de pérdida de visibilidad. No es una lista de verificación. Es un método de investigación con cuatro fases, hipótesis que se pueden romper y una regla incómoda: hasta que no tengas la fecha exacta de la ruptura, no toques nada.
¿Por qué una checklist de 200 puntos casi nunca encuentra al culpable?
Porque una lista de verificación está diseñada para medir salud general, no para explicar un evento concreto. Son dos preguntas distintas. «¿Está esta web bien construida?» y «¿qué ocurrió el 9 de noviembre a las 3 de la madrugada?» no se responden con el mismo instrumento, igual que un chequeo médico anual no sustituye a una radiografía de urgencias.
En nuestra cartera hemos revisado 34 informes de este tipo entregados por terceros entre 2021 y 2024. La media de incidencias detectadas fue de 47 por documento. La media de incidencias con relación causal demostrable con la pérdida que motivó el encargo: 1,2. Casi la mitad de esos informes, 16 de 34, no contenían ninguna.
Síntoma, hallazgo y causa raíz: tres cosas que se confunden a diario
El síntoma es lo que duele: caen las impresiones, se hunden las conversiones, desaparecen posiciones en un grupo de consultas. El hallazgo es cualquier anomalía que encuentras al mirar. La causa raíz es la única cosa que, si la eliminas, hace desaparecer el síntoma.
Un ejemplo que uso siempre porque es descarado. Web de servicios, 1.900 URLs. Síntoma: -38% de clics en cinco semanas. Hallazgo: 412 páginas con etiqueta de título duplicada. Corregimos las 412. Resultado a los 45 días: -39%. La duplicación existía desde 2019 y no molestaba a nadie. El origen real era una redirección en cadena introducida al fusionar dos secciones, que pasaba por cuatro saltos y perdía el parámetro de idioma en el tercero.
Un hallazgo verdadero cumple tres condiciones simultáneas: es anterior o simultáneo al síntoma, afecta al conjunto de páginas exactas que perdieron rendimiento, y no afecta a las páginas que se mantuvieron estables. Si falla cualquiera de las tres, tienes una tarea de mantenimiento pendiente, no un sospechoso.
El sesgo del primer error visible (y lo que cuesta corregirlo)
Mira, lo que pasa es que el cerebro humano cierra explicaciones en cuanto encuentra una que encaja de manera aproximada. En criminología lo llaman visión de túnel; en nuestro oficio se traduce en que el primer problema técnico que aparece en el rastreo se convierte automáticamente en el acusado.
Yo tardé años en aceptar esto. Durante mis primeros seis o siete años de profesión abría el rastreador antes que el panel de rendimiento. Aquello me obligó a invertir el orden.
La regla que aplicamos ahora es sencilla y algo antipática: no se abre ninguna herramienta de rastreo hasta que la Fase 1 está cerrada por escrito. Suena rígido. Lo es a propósito. Si has documentado antes qué grupo de páginas y qué fechas estás investigando, el rastreo se convierte en verificación de una hipótesis en lugar de en pesca de arrastre.
Fase 1: reconstruir la cronología del incidente
Una auditoría SEO forense es la investigación de un evento concreto de pérdida de visibilidad orgánica que parte del síntoma medido, fija la fecha exacta en que los datos se rompieron y, mediante hipótesis que pueden descartarse con una prueba, aísla el único factor cuya eliminación devuelve el rendimiento perdido.
- Reconstruir la cronología y fijar la fecha de ruptura.
- Formular hipótesis que puedan romperse con una prueba.
- Recoger evidencia segmentada sin corregir nada todavía.
- Diagnosticar, corregir de una en una y verificar.
Todo lo demás depende de la primera fase. Sin fecha no hay correlación posible, y sin correlación cualquier hipótesis vale lo mismo que cualquier otra. Dedicamos entre el 25% y el 30% de las horas totales del caso a construir una línea temporal defendible, y es el dinero mejor invertido de todo el proceso.
Cómo fijar la fecha exacta de la fractura en los datos
Trabaja con impresiones antes que con clics. Las impresiones reaccionan al día siguiente de un cambio de indexación o de posición; los clics arrastran ruido de estacionalidad, campañas y comportamiento del usuario. Descarga la serie diaria de los 16 meses anteriores, no las vistas agregadas por semana: una agregación semanal puede ocultar una caída brusca convirtiéndola en una pendiente suave.
Después aplica una comparación de medias móviles. Nosotros usamos ventanas de 7 y de 28 días superpuestas; el punto donde la ventana corta cruza la larga hacia abajo y no vuelve a recuperarla en 10 días es la fecha candidata. En 6 de cada 10 casos el corte real está entre 2 y 5 días antes de lo que el cliente creía, porque la percepción suele llegar por el informe de facturación y no por el panel de rendimiento.
Un detalle que cambia el diagnóstico entero: separa las impresiones de marca de las genéricas antes de dibujar la curva. En un proyecto de febrero de 2024 la caída agregada era del 22%; al filtrar consultas con el nombre comercial, la parte genérica había caído un 51% y la de marca había subido un 9%. Dos historias opuestas dentro del mismo gráfico.
Cruzar la línea temporal con despliegues, migraciones y actualizaciones del algoritmo
Una vez tienes la fecha, necesitas el registro de todo lo que ocurrió alrededor de ella. Lo que pedimos siempre, en este orden: histórico de despliegues a producción del repositorio, cambios de configuración en el servidor y en la capa de distribución, altas y bajas de plugins o módulos, modificaciones de plantillas, y cualquier acción de contenido masiva (borrados, fusiones, cambios de estructura de URL).
Vas a encontrar resistencia. El registro de despliegues casi nunca está donde debería y en dos de cada tres proyectos hay que reconstruirlo desde el historial de commits. Merece la pena: en la muestra de 47 casos que revisamos internamente entre 2022 y 2024, el 61% tenía un despliegue a producción dentro de la ventana de ±72 horas respecto a la fractura.
La actualización del algoritmo es la explicación más cómoda y la que más veces se usa mal. Criterio de descarte que aplicamos: si la caída empieza más de 48 horas antes del inicio oficial de un despliegue del buscador, o más de 10 días después de su cierre, esa actualización no es tu problema. Y aunque coincida en fechas, el patrón debe ser selectivo por tipo de consulta o de plantilla; una caída perfectamente uniforme en todas las secciones y todos los países suele delatar algo propio, no un cambio de criterio externo.
Total, que la cronología no sirve para acusar, sirve para eliminar. Cada evento que puedas situar fuera de la ventana temporal es una hipótesis menos que investigar, y en un caso complejo eso ahorra días.
Qué hacer cuando la pérdida es progresiva y no hay una fecha clara
Ocurre en aproximadamente un tercio de los casos y es el escenario más ingrato. No hay acantilado, hay ladera. Aquí la fecha no existe porque el fenómeno no es un evento, es un proceso: caducidad de contenido, entrada progresiva de competidores, degradación acumulada de rendimiento o simple contracción de la demanda.
La técnica que mejor nos funciona es la cohorte por antigüedad de URL. Agrupas las páginas según el trimestre en que fueron publicadas y dibujas la evolución de cada grupo por separado. Si el descenso se concentra en cohortes antiguas mientras las recientes crecen, tienes un problema de obsolescencia. Si cae todo por igual, mira hacia la demanda o hacia la autoridad del dominio.
Fase 2: ¿qué está provocando la pérdida? Formular hipótesis falsables
Una hipótesis útil se puede romper. «El sitio tiene problemas técnicos» no se puede romper con ninguna comprobación, por eso no vale nada. «Las URLs de la plantilla de categoría dejaron de devolver el bloque de enlaces internos a partir del despliegue del 9 de noviembre» se rompe o se confirma en veinte minutos con una captura del HTML renderizado de esa fecha.
Las cinco familias de causa: infraestructura, indexación, contenido, enlaces y demanda
Toda pérdida de visibilidad orgánica cae en una de estas cinco cajas, y conviene recorrerlas en este orden porque está ordenado de menor a mayor coste de comprobación:
- Infraestructura: códigos de respuesta, tiempos de servidor, disponibilidad, capa de caché, reglas de firewall o bloqueos de agentes.
- Indexación: directivas de rastreo, etiquetas de indexación, canónicas, mapas del sitio, cadenas de redirección, parámetros.
- Contenido: bloques que desaparecen, plantillas modificadas, texto adelgazado, canibalización interna, contenido dependiente de scripts.
- Enlaces: pérdida de enlaces entrantes relevantes, cambios en la estructura interna, secciones huérfanas, acciones de la competencia.
- Demanda: volumen de búsqueda del nicho, cambio de intención en las consultas, nuevos elementos en la página de resultados que absorben clics.
El reparto real en nuestra muestra de 47 casos: infraestructura 11%, indexación 34%, contenido 28%, enlaces 13%, demanda 14%. La indexación gana casi siempre, y dentro de ella el subgrupo más frecuente son las redirecciones mal resueltas tras un cambio de estructura.
Cómo descartar una hipótesis con una sola comprobación
Para cada sospechoso, define antes de mirar cuál sería la prueba que lo exonera. Esto es lo que en investigación se llama predicción falsable y es lo que impide que acabes justificando tu intuición inicial.
Tres ejemplos concretos del cuaderno de trabajo. Hipótesis de bloqueo por firewall: si el rastreador del buscador recibiera 403 en las URLs afectadas, aparecerían en los registros del servidor; una consulta de dos minutos sobre el log del día del corte la confirma o la mata. Hipótesis de canibalización: si dos URLs compitieran por la misma consulta, el histórico mostraría alternancia de la página posicionada; si nunca ha alternado, no hay canibalización. Hipótesis de pérdida de enlaces: si desapareciera un enlace determinante, la caída afectaría a la URL enlazada y a su entorno inmediato, no a plantillas sin relación.
¿Funciona siempre este método? Jamás. Hay casos con orígenes múltiples que interactúan, y ahí el proceso se alarga porque tienes que aislar variables una a una. Pero en el 80% aproximado de los expedientes, tres o cuatro comprobaciones bien diseñadas reducen las cinco familias a una sola.
Señales que apuntan a un cambio de intención de búsqueda y no a un fallo propio
Hay un patrón que reconozco casi de inmediato. Las posiciones se mantienen, las impresiones también, y sin embargo los clics se desploman. Si eso pasa, el problema no está en tu servidor: está en cómo se presenta el resultado y en qué compite contra él.
Otra señal, más sutil: cambia el tipo de página que ocupa las primeras posiciones. Si donde antes había artículos explicativos ahora hay fichas de producto o comparadores, el buscador ha reinterpretado la intención de esa consulta y tu contenido dejó de encajar sin haber cambiado una coma.
Aquí ninguna corrección técnica te devolverá nada; hay que reescribir el formato o aceptar la pérdida y buscar el volumen en otro sitio. Antes de seguir conviene tener muy clara esa frontera entre fallo propio y reinterpretación del buscador, porque decide si el expediente se abre o se cierra: nuestra guía sobre qué es una qué es una auditoría forense y cuándo aplicarla desarrolla los criterios de entrada a este tipo de investigación con más ejemplos de cartera.
Fase 3: recoger evidencia sin contaminarla
Aquí es donde la mayoría de procesos se estropean, y no por falta de herramientas. Se estropean porque se corrige mientras se investiga. En cuanto alguien del equipo de desarrollo «arregla algo por si acaso» durante la recogida de datos, pierdes la capacidad de establecer qué causó qué. Congelar cambios es la primera instrucción que damos al abrir esta fase.
Logs de servidor: qué hace Googlebot cuando nadie lo mira
Los registros del servidor son la única fuente que te dice lo que realmente ocurrió, sin muestreo y sin interpretación. Todo lo demás son informes construidos a posteriori. Pide los 90 días anteriores a la fractura y los 30 posteriores, filtra por agente verificado mediante resolución inversa de IP (hay bastante tráfico que se hace pasar por rastreador; en un proyecto de comercio electrónico de 2023 el 19% de las visitas declaradas como buscador eran falsas) y mide cuatro cosas.
Primera, distribución de códigos de respuesta por día. Segunda, número de peticiones únicas por plantilla. Tercera, tiempo medio de respuesta segmentado por tipo de página. Cuarta, profundidad de rastreo, es decir, cuántos niveles de la arquitectura reciben visita real.
El hallazgo que más veces nos ha resuelto un caso: caída del volumen de peticiones a una plantilla concreta entre 5 y 12 días antes de que las impresiones se movieran. Ese desfase es oro, porque explica que la fecha percibida por el cliente casi nunca es la fecha del hecho. El rastreo se degrada primero, la visibilidad se degrada después.
Segmentar por plantilla, país y dispositivo antes de mirar el total
El total agregado miente por diseño. Es una media, y las medias esconden exactamente lo que estás buscando: qué subconjunto se rompió.
Nuestra matriz mínima de segmentación tiene tres ejes cruzados. Tipo de plantilla, porque una caída concentrada en un solo tipo de página señala directamente al código de esa plantilla. País o idioma, porque los problemas de etiquetado internacional producen patrones geográficos muy limpios. Y dispositivo, porque los cambios que solo afectan a móvil suelen venir de la capa de presentación o de un umbral de rendimiento.
En una tienda de 12.000 referencias que revisamos en octubre de 2023, el descenso global era del 17%: aparentemente moderado. Al cruzar los tres ejes salió que las fichas de producto en móvil habían perdido el 58% mientras el escritorio subía un 4%. El resto de secciones, planas. Eso ya no es un diagnóstico pendiente, es una dirección postal.
Renderizado y capturas comparadas: lo que ves frente a lo que se indexa
Si el contenido depende de scripts, tu navegador no es una fuente fiable. Tú tienes conexión rápida, extensiones activas y caché caliente; el rastreador no.
Compara siempre tres versiones del mismo documento: el HTML de origen sin ejecutar nada, el HTML posterior al renderizado, y la copia que el buscador dice tener indexada. Las diferencias entre la primera y la segunda te indican qué depende de la ejecución de código.
Las diferencias entre la segunda y la tercera te dicen si esa ejecución está llegando o no. En el caso que abría este artículo, el bloque descriptivo de producto existía en la versión renderizada de mi navegador y no aparecía en la copia indexada. Ahí se cerró el expediente.
Guarda las capturas con fecha y hora, en carpeta separada y sin editar. Parece burocracia (lo es un poco) hasta el día en que alguien del equipo de desarrollo asegura que aquel bloque siempre estuvo ahí y tú puedes abrir un archivo del 11 de noviembre a las 09:42 que demuestra lo contrario. Esa carpeta ha evitado más discusiones improductivas de las que puedo contar.
Fase 4: diagnóstico, priorización y plan de recuperación
La evidencia sin conclusión escrita no sirve de nada. He visto expedientes con 90 páginas de datos preciosos que no llevaron a ninguna acción porque nadie se atrevió a formular una frase con sujeto y predicado: esto lo causó aquello.
El informe de diagnóstico que cabe en una página
Un folio. Seis apartados. Si no cabe, es que no has terminado de pensar.
- Síntoma medido, con cifra y periodo exactos.
- Fecha de la fractura y método con el que se fijó.
- Causa raíz en una frase, con la evidencia que la sostiene.
- Hipótesis descartadas y la prueba que las descartó.
- Acción correctora, responsable y plazo.
- Método y fecha de verificación posterior.
El cuarto apartado es el que casi todo el mundo se salta y el que más valor tiene a medio plazo. Documentar lo que no era evita que el siguiente incidente empiece desde cero, y en proyectos con equipos que rotan es lo único que impide repetir la misma investigación cada catorce meses.
Qué se corrige primero, qué se documenta y qué se deja quieto
Ordenamos las acciones en tres cajones. En el primero, el causante confirmado: se corrige de forma aislada, sin acompañarlo de nada más. En el segundo, los hallazgos secundarios con impacto probable: se documentan y se programan para después de la verificación. En el tercero, todo lo demás: se deja exactamente donde está.
Y aquí viene lo que más cuesta defender ante un cliente nervioso. Corregir seis cosas a la vez impide saber cuál funcionó. Si el tráfico recupera, no aprendes nada; si no recupera, tampoco. Nosotros aplicamos una ventana de intervención única: una corrección, periodo de observación, y solo entonces la siguiente. En caídas graves esa disciplina se siente como inacción, pero la alternativa es quedarte sin información justo cuando más la necesitas.
Excepción razonable: si el hallazgo secundario es un fallo de disponibilidad o de seguridad, se arregla de inmediato y se anota la fecha para poder separar efectos más adelante. La pureza metodológica no justifica dejar un servidor caído.
Cómo verificar que la corrección funcionó (y en cuánto tiempo)
La verificación tiene dos niveles y suceden con semanas de diferencia. El primero es técnico y casi inmediato: ¿vuelve a devolverse el bloque que faltaba, se resuelve la redirección en un salto, recibe el rastreador código 200 donde antes recibía 403? Esto se comprueba en 24 o 48 horas sobre los registros y sobre la copia indexada de una muestra de 20 o 30 URLs.
El segundo nivel es de rendimiento y exige paciencia. Los plazos medios que manejamos, medidos sobre casos cerrados: recuperación del volumen de rastreo entre 5 y 15 días; retorno de impresiones entre 14 y 40 días; estabilización de clics entre 30 y 75 días. Si a los 45 días no hay ningún movimiento en impresiones sobre el segmento afectado, la hipótesis era incorrecta y hay que volver a la Fase 2 con el resto de familias sobre la mesa.
Define el criterio de éxito antes de corregir, no después. «Recuperar impresiones en la plantilla de categoría hasta el 85% del nivel del 1 de octubre, medido a 45 días» es verificable. «Mejorar el posicionamiento» es una conversación infinita.
Dudas que conviene resolver antes de cerrar el caso
¿En qué se diferencia un análisis forense de una revisión técnica habitual?
La revisión periódica mide salud general y produce una lista de mejoras priorizadas. El diagnóstico forense investiga un evento concreto y produce una única conclusión con su evidencia. La primera responde «qué podría mejorar»; el segundo responde «qué ocurrió y cuándo». Se usan herramientas parecidas, pero el orden de trabajo y el criterio de cierre son distintos.
| Criterio | Revisión técnica habitual | Diagnóstico forense |
|---|---|---|
| Objetivo | Medir salud general del sitio | Explicar un evento concreto de pérdida |
| Punto de partida | Lista de verificación por bloques | Síntoma medido y fecha de ruptura |
| Evidencia usada | Rastreo propio y herramientas de terceros | Logs, histórico de despliegues y capturas comparadas |
| Entregable | Informe con decenas de mejoras priorizadas | Un folio con una conclusión y su prueba |
| Criterio de cierre | Todos los puntos revisados | Recuperación verificada en el segmento afectado |
¿Cuánto tiempo tarda este tipo de diagnóstico?
En nuestros expedientes, entre 12 y 30 horas de trabajo repartidas en 5 a 12 días naturales. Lo que alarga el calendario no es el análisis, es la obtención de los registros del servidor y del histórico de despliegues: ahí se pierden 2 o 3 días en la mayoría de proyectos. Con acceso completo desde el primer momento, un caso de origen único se cierra en 48 horas.
¿Se puede hacer con herramientas gratuitas?
Casi todo, sí. El panel de rendimiento del buscador, una hoja de cálculo para las medias móviles, un procesador de registros por línea de comandos y la comparación manual de HTML cubren el 85% del proceso. Lo que las opciones de pago aportan es velocidad y el histórico de enlaces entrantes, que es difícil de reconstruir sin ellas. El método no depende del presupuesto, depende del orden.
¿Es realmente necesario el análisis de logs en un sitio pequeño o mediano?
No siempre, y conviene decirlo. Por debajo de unas 300 URLs con arquitectura plana, la comparación entre HTML renderizado y copia indexada suele bastar para cerrar el caso. Los registros se vuelven imprescindibles cuando hay plantillas múltiples, paginaciones, filtros o varios idiomas, porque son la única forma de ver qué parte del sitio dejó de recibir visita real y cuándo.
¿Cuál es el precio de este tipo de diagnóstico?
Depende del número de horas, no del tamaño de la web. Con el rango de 12 a 30 horas que manejamos, un caso de origen único queda muy por debajo del coste de un desarrollo correctivo aplicado a ciegas: aquellos 14.000 euros de 2016 pagaban una arquitectura nueva que no arregló nada. Antes de contratar, pide siempre que el entregable incluya las hipótesis descartadas con su prueba.
¿Cada cuánto merece la pena repetirlo?
No es un procedimiento periódico: se activa por síntoma. El disparador que usamos es una caída sostenida superior al 15% durante más de 14 días en un segmento identificable. Lo que sí conviene mantener siempre activo es el registro de despliegues y una alerta sobre impresiones segmentadas por plantilla; con esas dos cosas, la Fase 1 del próximo incidente te llevará dos horas en lugar de dos días.
Conclusión
Volviendo al correo del 14 de febrero: aquel documento de 218 filas no era inútil, era una respuesta a una pregunta que nadie había hecho. El problema de las listas de verificación no es su contenido, es que se aplican como sustituto del razonamiento en lugar de como apoyo.
Si te quedas con una sola idea, que sea esta: fija la fecha antes de abrir cualquier herramienta, formula hipótesis que puedan romperse y corrige de una en una. Con esos tres hábitos, el 80% de las pérdidas de visibilidad se explican en menos de una semana. Sin ellos, puedes revisar 200 puntos y no encontrar a nadie.
