Por qué las correcciones de SEO van en pull requests y no en scripts inyectados
Respuesta corta
Las correcciones de SEO van en pull requests porque una corrección en tu código está en el HTML que reciben los rastreadores, pasa por revisión, se queda si dejas de usar la herramienta y se puede revertir con un commit. Un script inyectado aplica su corrección en tiempo de ejecución, así que que cuente o no depende de qué rastreador ejecute tu JavaScript, y la corrección desaparece al quitar el snippet. Un script sigue siendo la opción práctica cuando no puedes editar el código fuente del sitio, necesitas un cambio en vivo sin desplegar o tu sitio ya se renderiza en el cliente.
Hay dos formas de llevar una corrección de SEO a un sitio web. Puedes cambiar el código que produce la página, o añadir un script que reescribe la página después de cargarla. Las dos terminan con una mejor etiqueta de título. Pero son cosas muy distintas de las que hacerse responsable.
Qué hace realmente un script inyectado
Una herramienta de SEO por inyección de scripts te pide añadir un snippet a tu sitio, normalmente desde tu layout o un gestor de etiquetas. Al cargar la página, el snippet descarga un conjunto de reglas y edita el documento en el navegador: define un título, añade una meta descripción, agrega datos estructurados, reescribe el texto alternativo de una imagen. Nada cambia en tu repositorio. La corrección existe solo en tiempo de ejecución.
Es realmente cómodo. También es el origen de todos los problemas que siguen.
Problema 1: no todos los rastreadores ejecutan tu JavaScript
Los buscadores obtienen primero el HTML sin procesar. Google puede renderizar JavaScript, pero el renderizado es un paso aparte y en cola que puede tardar más que el rastreo inicial. Otros consumidores de tu página leen lo que esta entrega: las vistas previas de enlaces en redes sociales dependen de las metaetiquetas Open Graph del head de la página, y la documentación de rastreadores de OpenAI, Anthropic y Perplexity enumera sus bots sin decir si ejecutan JavaScript. Consulta la documentación actual de cada proveedor, porque esto está cambiando.
Si una corrección solo existe después de que se ejecute JavaScript, que cuente o no depende de quién mire y cuándo. Una corrección en el HTML que entregas no tiene esa incertidumbre.
Problema 2: sin revisión, sin diff
En un pull request, un cambio en el título de tu página de inicio es un diff de dos líneas que un compañero puede leer, cuestionar y aprobar. Con un script inyectado, el cambio es una regla en el panel de otra persona que edita tu página después de que tu propio build y tus propias pruebas hayan terminado. Tu CI nunca lo vio. Tu revisor nunca lo vio.
Eso importa sobre todo cuando el cambio está mal. Una reescritura de título que elimina el nombre de tu marca, o datos estructurados que contradicen la página visible, son el tipo de error que la revisión de código existe para detectar.
Problema 3: la corrección es alquilada
Cuando dejas de usar una herramienta basada en scripts, quitas el snippet y todas las correcciones desaparecen con él. Tus títulos, descripciones y esquemas vuelven a lo que decía el código fuente antes, que es justo la razón por la que necesitabas la herramienta.
Un pull request es lo contrario. El cambio está en tu repositorio, en tu historial, y tu pipeline puede desplegarlo. Cancelar la herramienta no cambia nada del sitio.
Problema 4: revertir se convierte en trabajo de detective
Si un pull request causa un problema, revierte el commit. Si lo causa una regla en tiempo de ejecución, primero tienes que averiguar qué regla cambió qué elemento, en una herramienta que quizá no tengas abierta. El control de versiones te da una línea de tiempo gratis; un panel te da el historial que decidió conservar.
Cuándo un script sigue teniendo sentido
Seamos justos con la categoría. Si no puedes editar el código fuente del sitio, como en algunos constructores alojados, un script puede ser tu única opción. Si necesitas un cambio en vivo en minutos sin desplegar, un script es más rápido que un pipeline de build. Y si tu sitio ya se renderiza en el cliente, la distinción entre HTML y JavaScript importa menos porque nunca hubo un HTML sin procesar útil.
Son restricciones reales. También son restricciones que la mayoría de los equipos con un repositorio de código no tienen.
Qué hace Crawlmend en su lugar
Crawlmend rastrea tu sitio, lee los datos de Search Console y PageSpeed, y propone cada corrección como un diff contra tu repositorio. Ves el archivo, el antes y el después. Si la apruebas, Crawlmend abre un pull request en borrador en una rama nueva. Nunca hace merge. Antes de abrirlo, Crawlmend aplica el cambio en un clon desechable y comprueba que no rompa tu build; consulta cómo se generan las correcciones para ver los detalles y los límites de esa comprobación.
El objetivo no es quitar a las personas de los cambios de SEO. Es lograr que el cambio de SEO se parezca a cualquier otro cambio que tu equipo ya sabe revisar: pequeño, atribuible y reversible.
Una prueba práctica
- Mira el código fuente de una página que corregiste. ¿La corrección está en el HTML sin procesar?
- Pregunta quién aprobó el cambio y dónde puedes ver el diff.
- Imagina cancelar la herramienta mañana. ¿Qué pasa con tus títulos?
- Imagina que la corrección estaba mal. ¿Cuánto tardarías en encontrarla y deshacerla?
Si esas respuestas te incomodan, probablemente la corrección debería ir en un pull request. Puedes leer la comparación completa, o conectar un repositorio y ver tu primer diff.