Auditoría SEO antes y después: cómo compararla bien

Una auditoría SEO antes y después pone una junto a otra dos auditorías del mismo sitio: la primera se hace antes de aplicar las correcciones y la segunda, después. Cada problema recibe una de cuatro etiquetas: corregido, mejorado, sin resolver o nuevo. Si la comparación está bien hecha, sabrás si el trabajo se hizo de verdad, si algo se rompió por el camino y qué queda pendiente. Una puntuación que sube o baja no te dice nada de eso.

Esta guía explica cómo preparar una comparación fiable y cómo interpretar los resultados. También repasa las comprobaciones posteriores en Google Search Console que confirman que Google ha visto los cambios.

¿Qué es una comparación de auditoría SEO antes y después?

Es una segunda auditoría del mismo sitio con el mismo alcance, en la que cada hallazgo se empareja con su equivalente de la primera auditoría. El resultado es una lista de cambios por problema y por URL, mucho más útil que dos informes por separado, porque muestra qué pasó con cada problema que había que corregir.

Los rankings y el tráfico son lo que realmente buscas, pero son resultados. Se mueven por motivos ajenos a tu trabajo, como la estacionalidad, la competencia o las actualizaciones del algoritmo. La comparación de auditorías mide algo que controlas directamente: el estado del sitio. ¿Se arreglaron los enlaces rotos? ¿Se quitó el noindex de las páginas de categoría? ¿Se acortaron las cadenas de redirecciones?

Trátalos como dos tareas distintas:

• Comparación de auditorías: ¿corregimos lo que dijimos que íbamos a corregir? ¿Creamos problemas nuevos?
• Medición del rendimiento: ¿esas correcciones cambiaron las impresiones, los clics y las conversiones? Eso tiene su propio método, que explicamos en cómo saber si los cambios SEO están funcionando.

¿Por qué no basta con comparar la puntuación SEO global?

Una puntuación puede subir mientras empeoran problemas importantes, y puede bajar mientras el sitio mejora. La mayoría de las puntuaciones de auditoría son medias ponderadas de muchas comprobaciones. Corregir 300 textos alternativos que faltaban puede subir el número aunque tu principal página de aterrizaje siga teniendo una etiqueta noindex. La puntuación va en el resumen, no en el veredicto.

Estas son tres situaciones habituales en las que la puntuación engaña:

1. Cambió el alcance del rastreo. Si el segundo rastreo encontró 2.000 URL más, quizá porque se abrió un filtro o un calendario, todos los recuentos suben, incluso los de problemas que sí corregiste.
2. Las métricas de laboratorio son ruidosas. La documentación de Lighthouse de Google indica que gran parte de la variabilidad de la puntuación de rendimiento no se debe al propio Lighthouse. Viene de cosas como tests A/B, cambios en los anuncios, el enrutamiento de red, diferencias entre dispositivos y extensiones del navegador. También recomienda tratar el rendimiento como una distribución de puntuaciones y no como un único número.
3. Las correcciones fáciles tapan las difíciles. Una puntuación que mejora gracias a decenas de arreglos menores puede ocultar que el único problema crítico sigue ahí.

Así que compara problemas y las URL afectadas. La puntuación ocupa una línea en el resumen.

¿Cómo se prepara una comparación justa antes y después?

Prepárala de forma que lo único que cambie entre las dos auditorías sea el trabajo que hiciste. Eso significa las mismas URL de inicio, los mismos límites de rastreo, el mismo user agent, la misma configuración de renderizado de JavaScript, el mismo tratamiento del robots.txt y el mismo perfil de dispositivo. Guarda la primera auditoría como línea base fija antes de que nadie toque nada y anota la fecha de cada publicación intermedia.

Usa esta lista antes de repetir la auditoría:

• Congela la línea base. Exporta la primera auditoría con las listas completas de URL de cada problema, no solo el resumen. No puedes comparar con un informe que solo guardó los recuentos.
• Mantén idéntica la configuración del rastreo. Incluido si se renderiza JavaScript. Un rastreo renderizado encuentra enlaces y contenido que un rastreo de HTML sin renderizar no ve.
• Lleva un registro de cambios. Apunta cada despliegue, actualización de plugin, cambio de plantilla y lote de contenido entre las auditorías, con fechas. Cuando aparece un problema nuevo, el registro de cambios suele explicar por qué.
• Mapea las URL que cambiaron. Si cambiaste la estructura de URL, por ejemplo añadiendo o quitando barras finales o reorganizando una carpeta, hay que emparejar las URL antiguas con las nuevas. Si no, todas las páginas aparecerán como "desaparecidas" y luego como "nuevas". La comparación de rastreos de Screaming Frog tiene una función de URL Mapping que usa expresiones regulares para esto.
• Revisa los datos de campo por separado. Las Core Web Vitals de usuarios reales tardan en ponerse al día (más abajo lo explicamos).

¿Cuándo conviene hacer la auditoría "después"?

Hazla cuando las correcciones estén desplegadas y el sitio lleve un tiempo estable. Entre 30 y 60 días después de la primera auditoría suele ser lo adecuado para sitios pequeños y medianos: tiempo suficiente para publicar las correcciones prioritarias y lo bastante pronto como para recordar qué cambió. Para la frecuencia a largo plazo, consulta cada cuánto deberías auditar tu web.

¿Cómo se interpreta la comparación: corregido, mejorado, sin resolver, nuevo?

Coloca cada problema de cualquiera de las dos auditorías en uno de cuatro grupos y revisa las URL de cada uno. "Corregido" significa que el problema ha desaparecido de todas las URL. "Mejorado" significa que afecta a menos URL. "Sin resolver" significa que no ha cambiado. "Nuevo" significa que no existía en la línea base. El grupo de nuevos merece la revisión más atenta, porque ahí es donde aparecen las regresiones.

¿Por qué hay problemas que aparecen como "mejorados" y no como "corregidos"?

Casi siempre porque la corrección se aplicó en una plantilla y no en otra. Piensa en una tienda online que arregló los H1 que faltaban en las fichas de producto. Las páginas de colección, que usan otra plantilla, siguen mostrando el problema. El número de URL afectadas baja, pero no llega a cero. Agrupa las URL restantes por ruta o plantilla y la causa suele verse en pocos minutos.

¿Qué significan "added", "removed", "new" y "missing" en las herramientas de comparación de rastreos?

Los rastreadores de escritorio usan sus propias etiquetas, que no coinciden exactamente con los cuatro estados anteriores. En la comparación de rastreos de Screaming Frog:

• Added (añadidas): URL que estaban en el rastreo anterior y ahora han entrado en un filtro de problema.
• New (nuevas): URL que no estaban en el rastreo anterior y ahora están en el filtro.
• Removed (eliminadas): URL que estaban en el filtro antes y ahora no lo están.
• Missing (desaparecidas): URL que estaban en el filtro antes y no se encontraron en el rastreo actual.

La diferencia entre "removed" y "missing" importa. Una URL que salió del filtro "404" porque ahora devuelve un 200 está corregida. Una URL que desapareció porque ya nada enlaza a ella no está corregida: simplemente ya no se ve. Comprueba que las del segundo tipo se quitaron a propósito. La misma documentación indica que la comparación requiere el modo de almacenamiento en base de datos y una licencia de pago.

¿Cómo confirmas que Google ha visto las correcciones?

Una auditoría muestra el estado actual de tu sitio. Search Console muestra si Google lo ha vuelto a rastrear y ha aceptado el cambio. Cuando hayas confirmado una corrección en tu propia comparación, usa las herramientas de validación de Search Console. Cuenta con semanas, no días.

Problemas de indexación de páginas. Después de corregir algo como un error de servidor o un noindex no deseado, haz clic en "Validar corrección" en el informe de indexación de páginas. La página de ayuda de Google dice que la validación suele tardar unas dos semanas como máximo, aunque puede tardar mucho más. Los estados posibles son iniciada, con buen aspecto, superada y fallida; fallida significa que cierto número de páginas sigue teniendo el problema. La misma página aclara que las nuevas instancias detectadas durante el rastreo normal se cuentan como instancias adicionales del problema existente. Es decir, una regresión puede reactivar un problema "superado". Para correcciones concretas, consulta cómo solucionar problemas de indexación de tu web.

Core Web Vitals. Los datos de campo van por detrás de tus despliegues. El informe de Core Web Vitals usa datos de los últimos 28 días, e "Iniciar seguimiento" abre un periodo de supervisión de 28 días. El problema solo cuenta como corregido si no aparece en ninguna URL durante ese periodo. Si tu auditoría "después" se hace una semana después de una mejora de velocidad, los números de laboratorio pueden verse mejor mientras los datos de campo aún muestran el estado anterior. Anótalo en la comparación en lugar de darlo por fallido.

¿Qué debe incluir un informe de auditoría antes y después?

Un buen informe de comparación responde de un vistazo a cuatro preguntas: qué está hecho, qué está a medias, qué está atascado y qué se rompió. Y lo hace con evidencias a nivel de URL, para que cualquiera pueda comprobarlo. Los totales sin URL detrás son una mala señal: no puedes verificarlos ni pasárselos a un desarrollador.

Busca (o crea) estas partes:

1. Un resumen por estado. Recuentos de problemas corregidos, mejorados, sin resolver y nuevos, ordenados por gravedad, no alfabéticamente.
2. Detalle por problema. Para cada uno: el número de URL antes y después, URL de ejemplo y la corrección prevista.
3. Una sección de regresiones. Los problemas nuevos y empeorados, primero, cada uno con su probable desencadenante según el registro de cambios.
4. Cambios de alcance. Cuántas URL se rastrearon cada vez y por qué cambió esa cifra.
5. El siguiente plan. Lo que sigue sin resolver y lo nuevo pasa a la siguiente lista de prioridades a 30/60/90 días. Si la lista es larga, cómo priorizar las correcciones SEO explica cómo ordenarla.

Puedes ver cómo queda en la práctica en el informe de comparación de ejemplo de SEORecheck, que empareja cada problema de la auditoría anterior y lo marca como corregido, mejorado, sin resolver o nuevo. El informe completo de ejemplo muestra la línea base con la que se compara.

¿La comparación debe incluir también las comprobaciones de búsqueda con IA?

Sí, si tu línea base las incluía. El acceso de los rastreadores de IA en el robots.txt, los controles de fragmentos, el contenido que solo aparece después de ejecutar JavaScript y el marcado Organization son ajustes del sitio, y un despliegue puede cambiarlos sin que nadie se dé cuenta. Por ejemplo, un plugin de seguridad podría añadir un bloqueo general a los bots. Compáralos igual que los demás problemas: ¿cada comprobación se superaba antes y se supera ahora? Las cifras de "visibilidad en IA" con aspecto de puntuación no te dicen qué cambió.

¿Qué errores hacen que una comparación antes y después engañe?

La mayoría de las malas comparaciones se reducen a uno de estos fallos: configuración de rastreo distinta, una línea base sin listas de URL o tomar una caída temporal de una métrica por una regresión. Cada uno te lleva a perseguir un problema que no existe o hace que uno real parezca resuelto.

• Comparar un rastreo renderizado con uno sin renderizar. Los recuentos de enlaces y las comprobaciones de contenido diferirán por motivos que no tienen nada que ver con tu trabajo.
• Usar otra herramienta para la segunda auditoría. Cada herramienta define los problemas y los umbrales a su manera. Mezclarlas convierte la comparación en adivinanzas.
• Ignorar las URL que desaparecieron del rastreo. "Desaparecida" no es lo mismo que "corregida".
• Tomar una sola ejecución de Lighthouse como veredicto. Ejecútalo varias veces o apóyate en los datos de campo de 28 días.
• Dejar la comparación antes y después para cuando caiga el tráfico. Si el tráfico ya ha bajado, diagnostica eso primero con nuestra guía sobre caídas de tráfico web y audita después.

Si nunca guardaste una línea base útil, empieza ahora. Solicita una auditoría gratuita y obtendrás una instantánea fechada de los problemas de rastreo, indexación, on-page, rendimiento y búsqueda con IA de tu sitio, con URL de ejemplo, para compararla más adelante. El precio de la reauditoría depende del sitio y del país y aparece en la página de precios.

Conclusiones clave

• Compara problemas y URL, no puntuaciones globales. Las puntuaciones mezclan muchas comprobaciones y ocultan regresiones.
• Mantén el mismo alcance, la misma configuración de rastreo y la misma herramienta en ambas auditorías, y guarda la línea base con las listas completas de URL.
• Etiqueta cada problema como corregido, mejorado, sin resolver o nuevo (o empeorado) y revisa primero los nuevos.
• Que una URL "desaparezca" del rastreo no significa que esté corregida. Comprueba por qué ya no aparece.
• Confirma las correcciones en Search Console. La validación de indexación suele tardar unas dos semanas como máximo y el seguimiento de Core Web Vitals dura 28 días.
• Mide el tráfico y los rankings por separado, una vez que haya mejorado el estado del sitio.