Registro de cambios de la web: cómo anotar cada cambio y saber qué movió tu tráfico

¿Qué es un registro de cambios de la web y en qué se diferencia del changelog de desarrollo?

El registro de cambios de la web es un historial pensado para marketing: todo lo que cambió en el sitio, escrito para que cualquiera que mire un gráfico de tráfico o conversiones pueda unir una fecha con una causa. No es el historial de Git ni el changelog del producto.

El changelog de desarrollo lista commits y versiones. Casi nunca dice que ese despliegue también cambió el H1 de 40 páginas de categoría, quitó un campo del formulario o movió el banner de cookies. Son justo esos detalles los que explican una caída de clics orgánicos o de leads, y es lo que guarda el registro de la web.

Piensa en él como un carril de un registro de cambios de marketing más amplio: la web, junto a las cuentas publicitarias, la medición y el CRM. El sitio suele ser la causa común de cambios que aparecen en varios canales a la vez, porque el tráfico de pago, orgánico y de email llega a las mismas páginas.

¿Qué debe incluir un registro de cambios de la web?

Anota cualquier cambio que pueda alterar cómo se rastrean, posicionan o cargan las páginas, o cómo convierte el visitante. Si dudas, regístralo: una entrada lleva un minuto, una que falta puede costar días de análisis.

Registra también lo que no hiciste tú pero afecta al sitio: una actualización automática de un plugin, una caída del hosting o una actualización de ranking de Google. Compiten con tus cambios como explicación, así que van en la misma línea de tiempo.

¿Cómo se monta un registro de cambios de la web?

Usa siempre los mismos campos, una entrada por cambio, y haz del registro un paso del despliegue, no un ejercicio de memoria a posteriori.

1. Fecha y hora de salida a producción. No la fecha de cierre del ticket. Anota la zona horaria, porque la analítica y el servidor suelen usar zonas distintas.
2. Alcance. Qué URL, plantillas, secciones o mercados se vieron afectados (por ejemplo, "todas las páginas /blog/" o "checkout, solo móvil").
3. Qué cambió, antes → después. "Patrón del title: Producto | Marca → Compra Producto online | Marca" sirve. "Ajustes de SEO" no sirve.
4. Etiqueta de tipo. Despliegue, contenido, redirección, técnico, medición, oferta. Las etiquetas te permiten filtrar después.
5. Responsable. La persona o agencia que hizo el cambio, para saber a quién preguntar.
6. Motivo y efecto esperado. Una línea: qué esperabas y en qué métrica.
7. Enlace. Ticket, pull request, versión de GTM o captura de pantalla.

Para empezar basta una hoja de cálculo compartida; nuestra plantilla de registro de cambios de marketing ya trae las columnas. La regla que importa más que la herramienta: quien publica, registra. Añade un punto "¿registrado?" a la checklist de despliegue para que la entrada se escriba el mismo día y no se reconstruya un mes después.

¿Puedo usar las anotaciones de GA4 o de Search Console en su lugar?

Ambas herramientas permiten marcar fechas en sus gráficos, algo útil para quien trabaja en esos informes. Ninguna sustituye a un registro completo, por sus límites de tamaño y de conservación.

En Search Console no se puede editar una anotación una vez creada, y Google aconseja no incluir datos personales como nombres. GA4 además añade anotaciones del sistema cuando ocurre un evento que afecta a los datos. Usa estas marcas como punteros ("Plantilla de checkout v3 en producción, ver registro") y guarda el detalle, el responsable y el antes/después en tu propio registro. Nuestra guía de anotaciones de GA4 explica la configuración con más calma.

¿Cómo uso el registro para saber qué causó un cambio en el tráfico o las conversiones?

Parte de la fecha en la que se movió la métrica y pon en una sola línea de tiempo todos los cambios de los días anteriores, de todas las fuentes. Después descarta la medición, revisa las causas externas y prueba una hipótesis cada vez.

1. Fija la fecha. Busca el primer día fuera de lo normal y mira si afecta a todo el sitio o solo a algunas páginas, dispositivos, países o canales.
2. Reúne todo lo de los 7 a 14 días previos. Entradas de la web, publicaciones de etiquetas y GTM, ediciones en las cuentas publicitarias, cambios en el CRM o en formularios. Un despliegue y un cambio de estrategia de puja en la misma semana son sospechosos hasta descartar uno.
3. Descarta primero la medición. Si bajaron las conversiones registradas pero no los pedidos ni los leads del CRM, el problema está en la medición, a menudo una etiqueta, un formulario o el consentimiento. Mira el post sobre el historial de versiones de GTM para fechar cambios de etiquetas.
4. Revisa causas externas. La guía de Google sobre caídas de tráfico de la Búsqueda cita actualizaciones de algoritmo, problemas técnicos, de seguridad y de spam, cambios en el interés de búsqueda y migraciones de sitios. Compara con los últimos 16 meses en el informe de rendimiento para ver patrones estacionales.
5. Cruza alcance con alcance. Una caída solo en las páginas /blog/ apunta a un cambio que tocó /blog/. Un cambio en el checkout no explica menos impresiones orgánicas.
6. Prueba una hipótesis. Revierte o ajusta un cambio, o compara grupos de páginas afectadas y no afectadas, y sigue la métrica durante un periodo razonable.

Cuenta con retrasos: Google indica que, en una migración con cambio de URL, un sitio mediano puede tardar unas semanas en trasladar la mayoría de sus páginas, y la visibilidad puede fluctuar mientras tanto. Para un diagnóstico solo del orgánico, consulta por qué ha bajado mi tráfico orgánico.

Con los despliegues de la web, las publicaciones de GTM y las ediciones publicitarias en una sola línea de tiempo, una caída solo en las páginas de producto aparece junto al despliegue de la plantilla que las tocó. Crea gratis un registro de cambios en Changeline y ten la web y los anuncios en un solo sitio.

Ejemplo: relacionar una caída con el despliegue de una plantilla

Ejemplo ilustrativo, no es un cliente real. Una tienda online ve que las sesiones orgánicas de las fichas de producto caen alrededor de un 20% de una semana a otra, mientras el blog se mantiene estable.

• Línea de tiempo de los 14 días previos: despliegue de la nueva plantilla de producto (martes), publicación en GTM con un evento nuevo (miércoles), subida de presupuesto en Google Ads (jueves).
• Comprobación de medición: también cayeron los clics en Search Console, no solo las sesiones en GA4, así que no es una etiqueta. La publicación en GTM queda descartada.
• Comprobación de alcance: solo bajaron las fichas de producto, justo las de la plantilla. El presupuesto de Google Ads no reduce clics orgánicos.
• Detalle del registro: la entrada antes/después muestra que el despliegue sustituyó el bloque de descripción por una pestaña que solo carga al hacer clic.
• Prueba: el equipo devuelve la descripción al HTML inicial en la mitad de las categorías y compara ambos grupos en las semanas siguientes.

Sin el registro, el equipo habría empezado por una suposición, probablemente el cambio más reciente o más visible.

¿Cómo mantengo los cambios de la web y de publicidad en la misma línea de tiempo?

Reúnelo todo en un solo sitio, porque la pregunta casi nunca es "qué cambió en la web"; es "qué cambió en cualquier parte antes de que se moviera esta métrica".

En Changeline registras cambios de web, medición y CRM por proyecto, con fecha, responsable, etiquetas y motivo, y los cambios de Google Ads se pueden importar automáticamente con una conexión de solo lectura, con valores antes → después. Las integraciones con la web y otras herramientas aún no están disponibles, así que los cambios del sitio los registra el equipo. Las entradas se conservan mientras exista el proyecto, lo que facilita ver qué cambió en las mismas semanas del año anterior.

Uses la herramienta que uses, repasa el registro en el informe mensual: lista los cambios de la web del periodo junto a las métricas que debían mover y anota cuáles funcionaron.