Oficio y negocio
Cómo se documenta un cambio SEO para que sirva dentro de un año
Cuatro líneas por cambio bastan, y son las que evitan repetir un error o deshacer algo que funcionaba. Qué anotar, dónde ponerlo y qué guardar antes de tocar.
- Lectura 10 min
- Publicado
- Jesús Iturbide consultor SEO
- Cómo reviso estos artículos
En corto
Cuatro líneas por cambio: qué se tocó, cuándo, por qué y qué se esperaba. Con eso, dentro de un año se puede relacionar una subida o una caída con algo concreto en vez de adivinar, y se evita deshacer lo que funcionaba. Sin eso, cada persona que llega al proyecto empieza a ciegas y repite lo que ya se probó.
Una web que lleva dos años trabajándose ha recibido cientos de cambios. Si no están anotados, el día que el tráfico se mueve, hacia arriba o hacia abajo, nadie puede decir por qué, y las decisiones siguientes se toman a ciegas.
Documentar cambios SEO no exige un sistema. Hacen falta cuatro líneas por cambio, y la disciplina de escribirlas en el momento, que es la parte difícil.
Las cuatro líneas
Qué se tocó. La página o el elemento concreto, no «mejoras de SEO». /servicios/reformas-de-bano/: reescrito el título y añadido apartado de precios.
Cuándo. La fecha. Es lo que permite cruzarlo después con la evolución.
Por qué. El motivo, en una frase. «Tenía impresiones y casi ningún clic», «dos páginas competían por la misma consulta», «el cliente pidió quitar el precio».
Qué se esperaba. La expectativa, para poder contrastarla. «Subir el porcentaje de clics», «que deje de competir con la otra». Esta es la que más se salta y la más útil: es lo que convierte el registro en algo que se puede evaluar.
Con eso, dentro de un año alguien abre el fichero, ve una caída en marzo y encuentra que en marzo se fusionaron cuatro páginas. Sin eso, ese alguien va a proponer fusionarlas otra vez.
Un registro que sirve y uno que no
| Registro que no sirve | Registro que sirve | |
|---|---|---|
| Qué | «Mejoras SEO en la web» | «/servicios/reformas-de-bano/: título reescrito y apartado de precios» |
| Cuándo | «Marzo» | «12-03-2026» |
| Por qué | No consta | «Tenía 1.400 impresiones al mes y 9 clics» |
| Qué se esperaba | No consta | «Pasar del 0,6 % al 2 % de clics en ocho semanas» |
| Dónde vive | En el correo de quien lo hizo | En una hoja compartida del cliente |
| Dentro de un año | Nadie sabe qué pasó en marzo | Se lee la gráfica y se sabe |
Dónde ponerlo
Da igual, mientras sea un solo sitio y sobreviva a la persona. Una hoja de cálculo compartida, un documento en la nube, un fichero de texto en el repositorio.
Lo que no funciona: en el correo, en un chat, o en la cabeza de quien lo hizo. Los tres desaparecen en cuanto cambia alguien, y en un proyecto de dos años siempre cambia alguien.
Si el sitio tiene control de versiones, el mensaje de cada cambio ya es medio registro. Falta el «por qué» y el «qué se esperaba», que casi nunca se escriben porque en ese momento parecen obvios. No lo son dentro de un año.
Los cambios que hay que anotar sí o sí
Anotar también lo que no se hizo
Es lo que menos gente hace y lo que más tiempo ahorra. Si se valoró algo y se descartó, la decisión y el motivo valen tanto como el cambio: evita que dentro de seis meses alguien proponga exactamente eso y haya que rehacer el análisis.
«Se valoró cambiar la estructura de direcciones de la tienda. Descartado: el beneficio no compensa el riesgo de migración con el catálogo actual. Revisar si se rehace el catálogo.» Esa nota vale una tarde de trabajo dentro de un año.
Lo mismo con lo que se probó y no funcionó. «Se añadió una sección de preguntas frecuentes a las páginas de servicio esperando fragmentos destacados; en tres meses no apareció ninguno; se deja porque ayuda a quien lee.» Sin esa línea, el siguiente lo propondrá como novedad.
La foto de antes
Antes de un cambio grande, guarda una exportación de Search Console de esa página o sección. Es el único modo de comparar después sin discutir de memoria, y cuesta dos minutos.
Abre el informe de rendimiento en Search Console
Filtra por la página o el grupo de páginas que vas a tocar. Si es un cambio de plantilla, toda la web.
Fija el periodo: las últimas cuatro semanas
Suficiente para tener una base sin que entre la estacionalidad de todo un año. Si el negocio es muy estacional, guarda también el mismo periodo del año anterior.
Exporta consultas, impresiones, clics y posición
El botón de exportar de arriba a la derecha. Una hoja de cálculo con la fecha en el nombre.
Guárdala junto al registro
En la misma carpeta que el fichero de cambios, con el nombre de la página y la fecha. Dentro de ocho semanas se compara con la misma exportación repetida.
Cuando el registro lo lee otra persona
Es también la prueba más sencilla de que alguien está trabajando de verdad en tu web: quien hace cambios puede listarlos con su motivo; quien no, entrega informes.
Qué anotar y qué no
La regla práctica: si dentro de un año podría explicar un movimiento del tráfico, se anota. Si no, no.
Un caso: la caída de marzo
Cómo empezar si llevas dos años sin anotar nada
No hace falta reconstruir el pasado entero. Se reconstruye lo que tiene consecuencias: las direcciones que cambiaron y sus redirecciones, las migraciones y los cambios de plantilla. Eso suele salir del historial del gestor de contenidos, de los ficheros de redirecciones y de preguntar a quien estuvo.
Después, se empieza a anotar desde hoy. Un registro que empieza en la mitad del proyecto vale más que ninguno, y dentro de un año ya cubre lo que importa.
Preguntas frecuentes
¿No basta con el historial del control de versiones?
No. Dice qué cambió en el código, no por qué ni qué se esperaba, que son las dos líneas que valen dentro de un año. Y no recoge nada de lo que se hace fuera del código: la ficha de Google, un cambio de alojamiento, una redirección puesta en el panel o un texto tocado desde el editor.
¿Cuánto tiempo hay que guardarlo?
Mientras exista la web. Ocupa nada, y es lo primero que agradece cualquiera que llegue después, incluido tú mismo dentro de dos años, cuando no recuerdes por qué esa página redirige a aquella otra. Un registro de cinco años es el historial clínico de la web, y no se tira.
¿Esto no es burocracia?
Cuatro líneas por cambio son un minuto, y una tanda de retoques de redacción se anota en una sola línea. La alternativa es media jornada reconstruyendo qué pasó cada vez que el tráfico se mueve, y las veces que no se consigue reconstruir, decidir a ciegas. Es la burocracia más rentable que conozco.
¿Debe llevarlo la agencia o yo?
Quien haga el cambio lo anota, y el fichero es tuyo: vive en tu cuenta, no en la de la agencia. Si cambias de proveedor, el registro se queda contigo y el siguiente empieza sabiendo qué se ha probado. Una agencia que no anota lo que toca en tu web es una agencia a la que conviene pedírselo.
¿Qué hago con los cambios que hizo Google, no yo?
Anótalos también, en la misma hoja y con otra marca: las actualizaciones del algoritmo tienen fecha pública y explican movimientos que no hizo nadie de tu lado. Cuando el tráfico se mueve, lo primero que se mira es si coincide con una de ellas; tenerlas apuntadas evita culpar a un cambio tuyo de algo que no hizo.
Reconstruir lo que se hizo en una web sin registro es una de las partes de una auditoría SEO, y la más lenta. Para leer las cifras con las que se contrasta cada línea, cómo medir si el SEO está funcionando sin engañarte. Si dudas de lo que te han hecho hasta ahora, cómo saber si te han hecho un buen trabajo de SEO y cómo leer un informe SEO sin que te den gato por liebre. Y para arrancar con el registro desde el día uno, qué hacer los primeros 90 días de un proyecto de SEO.
Si te está pasando
La primera llamada no cuesta nada y suele bastar para saber si tiene arreglo. Si tu caso no es para mí, te lo digo.
