Monitorización de cambios de código: detecta el deploy que rompió tu SEO

Monitorizar los cambios de código de un sitio significa vigilar su HTML publicado en busca de las modificaciones de las que dependen los buscadores y la analítica, y recibir una alerta cuando aparece una. Un desarrollador despliega, ningún ticket menciona el SEO, y un title reescrito, un canonical movido o un tag de GA4 que falta se quedan en producción hasta que alguien se pone a buscar.

Las agencias ven alguna versión de esto con regularidad. Las posiciones bajan durante un mes, alguien investiga y la causa resulta ser un cambio de plantilla que llegó con una release rutinaria. El equipo de desarrollo no hizo nada mal según sus propios criterios: la página se ve, los tests pasan, el cliente aprobó el diseño. Lo que cambió es la parte del markup que solo leen los rastreadores y los scripts de tracking.

Qué cambios de código conviene monitorizar

La mayor parte del código de una página puede cambiar sin consecuencias para el SEO. Un pequeño grupo de elementos, no.

Elemento	Cómo suele romperse	Efecto
<meta name="robots"> y X-Robots-Tag	Un ajuste de staging o una variable de entorno que llega a producción	Páginas retiradas del índice
<link rel="canonical">	Una plantilla nueva lo construye con la URL equivocada o apunta a un host de staging	Google indexa otra URL o ignora la página
<title> y meta description	Restablecimiento del plugin SEO o una plantilla que sobrescribe los campos de cada página	Menos CTR y, a veces, menos relevancia
<h1>	Un rediseño convierte el titular en un <div> con estilos, o el logo pasa a ser un segundo H1	Una señal temática más débil en la página
Snippets de GA4, GTM y Meta Pixel	Una build nueva elimina el contenedor del layout	Se detienen el reporting y la atribución de anuncios
Banner de consentimiento de cookies	Se cambia o se elimina el CMP	Tags bloqueados, o disparándose sin consentimiento

El robots.txt no forma parte del HTML de la página, pero cambia en las mismas releases y merece la misma atención. Un Disallow: / que se quedó de un entorno de staging hace más daño que todos los elementos de la tabla juntos.

HTML fuente frente a HTML renderizado

En un sitio renderizado en servidor, lo que importa es el HTML que devuelve el servidor. En sitios hechos con React, Vue o frameworks similares, las etiquetas del head pueden fijarse con JavaScript después de cargar la página, así que el código fuente y el DOM renderizado pueden no coincidir. Google renderiza JavaScript, pero un canonical que solo existe después del renderizado, o que es distinto en la versión fuente y en la renderizada, es una fuente habitual de confusión. Cuando investigues un cambio, compara view-source: con el panel Elements de DevTools, y usa la herramienta Inspección de URLs de Search Console para ver el HTML renderizado que registró Google.

Por qué las señales habituales llegan tarde

Lo más probable es que tu equipo no reciba los avisos de despliegue del cliente. Search Console informa de las consecuencias, no de las causas: las páginas pasan a "Excluida por la etiqueta 'noindex'" en el informe Indexación de páginas solo después de que Google las haya vuelto a rastrear, y el informe se actualiza con retraso. Los rank trackers muestran la caída cuando ya ha ocurrido. Y nadie abre el código fuente de una página que en el navegador se ve bien.

En ese margen es donde hacen su daño los cambios SEO silenciosos, y la respuesta es una comparación que se ejecuta tanto si alguien se acordó de mirar como si no.

Qué debe contarte una buena detección de cambios

Compara en lugar de limitarse a comprobar que algo existe. Saber que hay un title vale poco; saber que ayer ponía "Zapatillas de running para hombre | Marca" y hoy pone "Colección" es algo con lo que puedes actuar. Trabaja por URL, porque los cambios de plantilla suelen afectar a una sección y no a la home. Y la alerta incluye la URL, el valor anterior, el valor nuevo y la fecha, que es exactamente lo que necesitas enviarle al cliente.

Qué hacer cuando llega la alerta

Carga la página en una ventana privada para descartar la caché. Decide si el cambio fue intencionado: un title mejorado por un redactor no requiere nada, mientras que un canonical que apunta a un host de staging hay que arreglarlo hoy. Envía las pruebas al cliente y pregunta qué se publicó ese día. Si resulta que el cambio forma parte de un rediseño o de un cambio de plataforma, deja de arreglar URLs una a una y trabaja con la checklist SEO para la migración de un sitio.

Qué compara Deltio y qué no

Deltio lee una vez al día el sitemap y las páginas de cada sitio y compara el resultado con la comprobación anterior. En cada página revisa noindex, canonical, title, meta description y H1, señala los valores que faltan, están duplicados o se salen del rango recomendado, y avisa cuando cambian. También revisa el robots.txt, las URLs que entran o salen del sitemap, GA4, GTM y el Meta Pixel, y el banner de consentimiento de cookies. Las alertas llegan por Slack y email, sitio a sitio. Después de una release de la que tienes noticia, puedes lanzar un escaneo SEO manual en lugar de esperar a la siguiente comprobación diaria, y los planes Professional y Enterprise permiten exportar los resultados a CSV.

No hace comparaciones visuales ni capturas de pantalla, y no compara código arbitrario como scripts o CSS. Se centra en los elementos de arriba. Además funciona a diario, así que no sustituye a los tests de un pipeline de despliegue. La monitorización de tags de marketing trata la parte del tracking con más detalle.