En la primera parte vimos cómo auditar una web antes de empezar a mejorarla. En la segunda convertimos esa auditoría en un sistema para priorizar los problemas y decidir qué corregir primero.
Falta el paso que decide si todo ese trabajo ha servido para algo: medir el resultado.
La tentación es sencilla. Hacemos cambios, vemos que una gráfica sube y concluimos que hemos acertado. Pero una web recibe tráfico de muchas fuentes, la demanda cambia, hay estacionalidad y los buscadores actualizan constantemente sus resultados. Medir bien significa reducir esa incertidumbre.
Empieza por la línea base, no por el resultado
La medición empieza antes de desplegar.
Para cada mejora importante guarda una referencia previa. Según el objetivo puede incluir:
- impresiones;
- clics;
- posición media;
- sesiones;
- usuarios;
- conversiones;
- tasa de interacción;
- tiempo de carga;
- errores detectados;
- acciones dentro de una herramienta;
- formularios enviados.
No necesitas registrar veinte métricas. Elige las que tengan relación directa con la hipótesis del cambio.
Si has mejorado un formulario, la métrica principal no debería ser el tráfico orgánico. Si has corregido indexación, probablemente te interesan cobertura, impresiones y páginas que empiezan a aparecer.
Escribe qué esperas que ocurra
Antes de mirar datos después del cambio, anota una expectativa.
Por ejemplo:
"Al eliminar este bloqueo de indexación espero que estas páginas vuelvan a generar impresiones durante las próximas semanas."
Otro caso:
"Al simplificar el formulario espero aumentar el porcentaje de usuarios que llegan al envío completado."
Esto parece un detalle menor, pero evita reinterpretar el objetivo después. Si la métrica principal no mejora, no deberíamos sustituirla por otra que sí haya subido para declarar éxito.
Asocia cada cambio con una fecha
Mantén un registro de despliegues o modificaciones relevantes.
Puede ser una tabla sencilla:
| Fecha | URL o área | Cambio | Métrica principal |
| --- | --- | --- | --- |
| 07/10/2026 | Formulario de contacto | Se reduce de 8 a 5 campos | Envíos completados |
| 07/10/2026 | Plantilla de artículos | Corrección de enlaces internos | Errores y navegación |
| 07/10/2026 | Página de servicio | Nuevo título y primer bloque | Impresiones y clics |
Sin estas fechas resulta difícil interpretar después una gráfica.
No necesitas registrar cada corrección ortográfica. Documenta los cambios que razonablemente puedan alterar tráfico, conversión, experiencia o funcionamiento.
Diferencia métricas de visibilidad y de negocio
Una web puede mejorar en Google y no generar más oportunidades. También puede recibir menos visitas y convertir mejor.
Por eso conviene separar dos grupos.
Visibilidad
- impresiones;
- clics orgánicos;
- consultas;
- páginas posicionadas;
- CTR;
- posición media.
Resultado
- formularios;
- llamadas;
- registros;
- compras;
- descargas;
- uso de herramientas;
- acciones que representen valor.
Search Console explica bastante bien la primera capa. GA4 y los eventos propios ayudan con la segunda.
La lectura útil aparece cuando conectas ambas.
Utiliza Search Console para cambios SEO, pero compara periodos razonables
Después de una mejora de SEO no esperes una reacción instantánea.
Comprueba:
- si Google sigue rastreando la URL;
- si la versión indexada refleja el cambio;
- si aparecen nuevas consultas;
- si cambian impresiones y clics;
- si el cambio afecta a una URL o a toda una sección.
Compara periodos equivalentes siempre que puedas. Un lunes frente a un domingo puede introducir diferencias que no tienen nada que ver con tu trabajo.
También evita obsesionarte con la posición media de una única consulta. Una página puede empezar a aparecer para muchas búsquedas nuevas y hacer que la media cambie aunque su visibilidad global esté mejorando.
En GA4 mide acciones, no solo páginas vistas
Las páginas vistas responden a "cuánta actividad hubo". No responden a "qué hizo la gente".
Configura eventos para las acciones que importan:
- enviar formulario;
- abrir una herramienta;
- ejecutar una función;
- copiar un resultado;
- descargar;
- pulsar un CTA;
- llegar al final de un contenido cuando tenga sentido;
- completar un proceso.
Cuanto más específica sea la acción, más fácil será relacionarla con una mejora.
Por ejemplo, si rediseñas una herramienta SEO, medir únicamente sus visitas no te dice si la gente consigue utilizarla. Un evento de uso sí.
Diseña nombres de eventos que puedas mantener
No crees un nombre distinto para cada botón si todos representan el mismo tipo de interacción.
Una estrategia práctica es utilizar un evento común y acompañarlo de parámetros. Por ejemplo, un evento llamado web_interaction puede incluir datos como interaction_name, content_type, content_slug o control_id.
Así puedes analizar todas las interacciones con una estructura estable y añadir contexto mediante parámetros.
La ventaja aparece meses después: no necesitas recordar veinte convenciones diferentes para entender los datos.
Mide el embudo completo cuando exista
Un formulario puede tener estas etapas:
- usuario visita la página;
- empieza a rellenar;
- aparece un error;
- envía;
- llega la confirmación.
Si solo mides la visita y el envío final, sabes cuántos llegaron y cuántos terminaron, pero no dónde abandonaron.
No todos los procesos necesitan instrumentación detallada. Resérvala para acciones importantes o para flujos que estás intentando mejorar.
Comprueba rendimiento antes y después en las mismas condiciones
Si el cambio pretende mejorar velocidad, intenta comparar páginas equivalentes y condiciones similares.
No saques conclusiones por una única prueba.
Combina:
- datos de laboratorio para detectar causas;
- métricas de campo cuando estén disponibles;
- comportamiento real en dispositivos;
- observación de errores y tiempos.
Una mejora pequeña en una puntuación no importa demasiado si el usuario sigue esperando varios segundos para poder interactuar.
En cambio, una reducción clara del peso de imágenes o del JavaScript ejecutado puede tener valor aunque la puntuación global apenas se mueva.
No atribuyas automáticamente una subida al último cambio
Este es uno de los errores más comunes.
Si modificas una página y una semana después recibe más tráfico, puede deberse al cambio, pero también a:
- mayor demanda;
- una noticia;
- estacionalidad;
- enlaces externos;
- cambios de competencia;
- variaciones del buscador;
- una campaña.
Busca señales que refuercen la relación.
Si cambiaste el título de una página para ajustarlo mejor a una intención y después aumenta el CTR en las mismas consultas con impresiones similares, la explicación es más razonable que si simplemente crece todo el tráfico del sitio.
Compara con páginas o secciones que no hayas tocado
Cuando sea posible, utiliza un grupo de referencia.
Si mejoras diez fichas de producto y otras treinta similares quedan sin cambios, comparar ambos grupos puede ayudarte a interpretar el resultado.
No será un experimento científico perfecto, pero da contexto.
Si todo el sitio crece un 20 %, una subida del 18 % en las páginas modificadas no demuestra necesariamente que el cambio haya funcionado. Si las modificadas crecen mucho más que las equivalentes, la señal es más interesante.
Define ventanas de observación distintas según el cambio
No todas las mejoras necesitan el mismo tiempo.
Un formulario roto puede validarse inmediatamente: envía o no envía.
Un cambio de rendimiento se puede comprobar el mismo día y seguir observando datos reales.
Un cambio de SEO puede necesitar más tiempo para rastreo, indexación y acumulación de datos.
Define de antemano cuándo revisar:
- inmediatamente;
- después de unos días;
- después de varias semanas.
Evita mirar una métrica cada hora. Aumenta ruido y facilita tomar decisiones precipitadas.
Registra efectos secundarios
Una mejora puede resolver un problema y crear otro.
Después de desplegar revisa:
- errores 404 nuevos;
- redirecciones;
- navegación;
- eventos de analítica;
- diseño móvil;
- formularios;
- rendimiento;
- páginas relacionadas.
Esto es especialmente importante cuando modificas componentes compartidos.
Si cambias el menú para mejorar accesibilidad y el CTR de navegación sube, perfecto. Pero si el menú deja de funcionar en un navegador concreto, el cambio no puede considerarse terminado.
Decide qué hacer con el resultado
Al finalizar el periodo de observación clasifica cada cambio.
Funcionó
La métrica principal mejora y no aparecen efectos secundarios relevantes. Documenta la decisión y considera aplicarla a casos equivalentes.
No está claro
Los datos son insuficientes o hay demasiadas variables. Mantén el cambio si no perjudica y amplía el periodo de observación.
No funcionó
La hipótesis no se cumple o aparece un efecto negativo. Revisa la causa, ajusta o revierte si tiene sentido.
Funcionó parcialmente
Mejora una parte, pero el objetivo principal sigue bloqueado. Esto suele indicar que has solucionado un síntoma, no toda la causa.
Cierra el ciclo y vuelve a empezar
Auditar, priorizar y medir forman un ciclo.
La secuencia completa queda así:
- Auditar: observar la web antes de cambiarla.
- Priorizar: decidir qué problemas merecen atención primero.
- Implementar: aplicar cambios en lotes controlables.
- Medir: comprobar qué ocurrió.
- Aprender: documentar el resultado.
- Revisar de nuevo: utilizar lo aprendido en el siguiente ciclo.
La mejora continua funciona mejor cuando cada cambio deja información para el siguiente.
No necesitas un sistema enorme. Una web pequeña puede gestionar todo este proceso con una hoja de seguimiento, Search Console, GA4 y unas pocas mediciones técnicas bien elegidas.
Lo importante es abandonar la idea de que "hemos hecho cambios" equivale a "hemos mejorado".
Una mejora empieza con una hipótesis y termina cuando tienes suficiente evidencia para decidir si merece quedarse.
Serie completa: Cómo auditar una web antes de empezar a mejorarla → Cómo priorizar los problemas después de la auditoría → Cómo medir si las mejoras han funcionado.
