Cómo mejorar una web existente con ChatGPT: del análisis al cambio publicado

01

Editar una web con ChatGPT no significa copiar y pegar código a ciegas

La forma más frágil de trabajar con IA es pedir un bloque de código, pegarlo en producción y esperar que funcione. Puede servir para una prueba pequeña, pero no crea un sistema de mantenimiento confiable.

En una web existente primero hay que entender qué problema queremos resolver. Puede ser que un servicio esté escondido, que una página no convierta, que el SEO técnico tenga fallas o que un cambio repetitivo siga dependiendo de una persona. ChatGPT puede ayudar a traducir esa necesidad en trabajo técnico, siempre que tenga acceso al contexto correcto.

La diferencia está en el circuito: observar, localizar el código, proponer el cambio, modificar, probar, revisar, publicar y comprobar. La IA participa en varias etapas; Git, los tests, el hosting y la decisión humana ponen límites alrededor de esa participación.

02

El sistema de trabajo: ChatGPT en el centro, pero no trabajando solo

Una conversación puede convertirse en la interfaz desde la que una persona dirige el trabajo. Desde ahí se puede revisar la web pública, consultar documentación, acceder a un repositorio autorizado y organizar una tarea de desarrollo. Pero la conversación no reemplaza las demás capas.

La web publicada muestra lo que ve el usuario. GitHub conserva el código y el historial. Las pruebas revisan reglas que no queremos romper. El hosting convierte una versión aprobada en producción. Search Console y Analytics ayudan después a observar qué cambió en visibilidad o comportamiento.

Este reparto importa porque evita una falsa sensación de autonomía. Si ChatGPT no tiene una fuente, un permiso o una herramienta disponible, debe pedir contexto o detenerse. El proceso es más robusto cuando cada sistema cumple una función concreta.

• ChatGPT: análisis, coordinación y lenguaje natural.
• Repositorio Git: código, versiones, historial y reversión.
• Tests y QA: reglas que deben seguir cumpliéndose.
• Hosting: preview, build y publicación.
• Datos: Search Console, Analytics y señales comerciales.

03

Primero miramos la web publicada como la miraría un cliente

Antes de abrir el repositorio conviene inspeccionar producción. La pregunta inicial no es qué archivo tocar, sino qué está ocurriendo en la experiencia real: qué se entiende en la primera pantalla, cómo se navega, qué páginas existen, qué enlaces llevan a una consulta y qué información podría estar escondida.

Esta revisión también permite formular una tarea concreta. “Mejorar la web” es demasiado amplio. “Hacer visibles cuatro servicios desde la portada sin duplicar contenido ni romper la navegación móvil” ya define un problema que puede comprobarse.

Guardar el estado inicial ayuda a cerrar el ciclo después. Si conocemos el menú anterior, las rutas existentes, el contenido visible y la intención de la modificación, podemos volver a producción y verificar exactamente qué cambió.

1. 01

   Abrir la página pública y recorrerla desde desktop y móvil.

2. 02

   Identificar el problema desde la perspectiva del usuario o del negocio.

3. 03

   Convertir la observación en un cambio pequeño y verificable.

4. 04

   Definir qué no debe romperse durante la implementación.

04

Después entramos al repositorio: la diferencia entre ver la web y entenderla

Una URL permite analizar el resultado, pero no explica por sí sola cómo fue construido. El repositorio contiene templates, estilos, contenido, scripts, rutas, tests y configuración. Ahí aparece la arquitectura que determina qué archivo conviene cambiar y qué efectos secundarios puede tener.

OpenAI documenta que, cuando GitHub está conectado, ChatGPT puede recuperar contenido autorizado del repositorio bajo demanda, incluidos archivos de código y documentación. La disponibilidad exacta depende del plan, el workspace y la superficie del producto, por lo que los permisos deben verificarse antes de diseñar el flujo alrededor de una integración específica.

El principio es más importante que el proveedor: el modelo debe trabajar sobre la versión correcta del código y no sobre una copia vieja pegada en un chat. También debe quedar claro qué repositorios puede leer o modificar y cuáles quedan fuera de alcance.

• Elegir el repositorio correcto y la rama correcta.
• No exponer claves, secretos ni credenciales en archivos de contexto.
• Revisar README, estructura y reglas del proyecto antes de modificar.
• Limitar permisos al repositorio y a las acciones necesarias.

Referencia: OpenAI · Conectar GitHub a ChatGPT

05

De una necesidad comercial a un diff concreto

Una vez localizada la arquitectura, la tarea se convierte en archivos y cambios. Si el problema es que nuevos servicios no se encuentran desde la portada, el análisis puede señalar el template de home, la navegación, las rutas y los tests relacionados. En lugar de reescribir el sitio completo, se intervienen las piezas necesarias.

Codex puede trabajar con repositorios conectados en entornos de desarrollo y preparar cambios de código. El flujo útil no es “hacé lo que quieras”, sino una misión acotada: qué problema resolver, qué archivos tocar si corresponde, qué reglas conservar y qué evidencia debe quedar al final.

El diff cumple una función comercial además de técnica: vuelve visible el trabajo. Permite revisar qué se eliminó, qué se agregó y por qué, antes de convertir la propuesta en una nueva versión del sitio.

Una instrucción amplia produce incertidumbre. Un cambio acotado, revisable y reversible produce un sistema de trabajo.

Referencia: OpenAI · Codex cloud

06

QA antes de publicar: la parte que separa una demo de una operación

Que el código se haya modificado no significa que el trabajo terminó. Antes de producción hay que comprobar que el sitio todavía construye, que las rutas responden, que la navegación sigue funcionando y que las reglas SEO o de seguridad relevantes no se rompieron.

GitHub Actions permite automatizar workflows frente a eventos del repositorio. En una web esto puede utilizarse para ejecutar tests, builds, verificaciones de HTML, chequeos de canonical, robots, sitemap o cualquier regla que el proyecto pueda expresar de forma automática.

No todo puede comprobarse con tests. El QA visual y editorial sigue siendo importante: títulos, jerarquía, móvil, espaciado, contenido y el recorrido real de una consulta necesitan revisión. Automatizamos lo repetible y dejamos visible lo que requiere criterio.

• Build reproducible.
• Tests automáticos.
• Rutas y enlaces críticos.
• Metadata y reglas SEO.
• Revisión visual y móvil.
• Aprobación antes de producción.

Referencia: GitHub Docs · GitHub Actions

07

Deploy controlado: del commit aprobado a la web pública

Cuando el repositorio está conectado a una plataforma de hosting, un cambio aprobado puede activar un build y un deploy sin subir archivos manualmente. Cloudflare Pages, por ejemplo, documenta integración con repositorios Git para desplegar proyectos a partir de commits y ramas configuradas.

Conviene separar preview de producción. El preview sirve para revisar una versión antes de que sea pública; producción debe apuntar a la rama y configuración acordadas. Esta frontera reduce el riesgo de publicar una prueba, un noindex o una versión que todavía no fue aceptada.

Después del deploy volvemos a mirar la URL pública. No damos por hecho que el commit equivale al resultado: comprobamos el menú, las páginas, los enlaces, la metadata y cualquier condición definida al inicio.

1. 01

   Commit o pull request con un cambio revisable.

2. 02

   Build y QA automáticos.

3. 03

   Preview cuando el cambio necesita inspección humana.

4. 04

   Deploy de la versión aprobada.

5. 05

   Verificación sobre la URL pública.

Referencia: Cloudflare Docs · Integración Git en Pages

08

Qué permisos damos y cuáles no

La forma más segura de usar IA en una web es separar capacidad de autoridad. El sistema puede analizar más de lo que puede modificar y puede preparar más de lo que puede publicar. Esa diferencia permite aprovechar velocidad sin convertir cada conexión en una llave maestra.

Para un primer flujo solemos limitar el alcance al repositorio concreto, evitar secretos en el código, revisar cualquier cambio sensible y mantener producción detrás de tests o aprobación. Un sistema que puede escribir código no debería recibir automáticamente acceso a dominios, DNS, facturación, bases de datos o credenciales si la tarea no lo requiere.

También hay que distinguir lectura de escritura. Para auditar una arquitectura, leer puede ser suficiente. Para implementar, puede habilitarse escritura sobre una rama o un workflow específico. El nivel de permiso debería aumentar solo cuando el proceso ya demostró que se puede revisar y recuperar.

El objetivo no es darle a la IA acceso total. Es darle el acceso mínimo que necesita para completar una tarea verificable.

09

Después del cambio viene la medición: SEO, comportamiento y negocio

Una web técnicalmente correcta todavía puede no resolver el problema que motivó la intervención. Si el objetivo era mejorar descubrimiento, conviene observar páginas, consultas, impresiones y clics. Si era mejorar conversión, hay que mirar intentos de contacto, consultas recibidas y calidad de esas consultas.

Search Console permite analizar rendimiento de búsqueda por consultas, páginas y períodos. Esa información ayuda a priorizar mejoras, pero no convierte una variación en prueba causal. Un cambio de título, estructura o enlazado interno debe compararse con una línea base y con otras condiciones que también pudieron cambiar.

La misma lógica aplica al mantenimiento continuo. No elegimos la siguiente tarea solo porque la IA pueda hacerla. Elegimos la siguiente tarea porque existe una fricción observable y podemos describir qué señal debería moverse si la intervención aporta valor.

• Visibilidad: impresiones, consultas y páginas.
• Entrada: clics y CTR cuando corresponda.
• Experiencia: navegación, errores y recorrido de contacto.
• Negocio: consultas calificadas, propuestas o la señal acordada.

Referencia: Google Search Console · Informe de rendimiento

10

Ejemplo: hacer visibles nuevos servicios sin rehacer toda la web

Imaginemos una empresa que acaba de publicar cuatro páginas comerciales. Las páginas existen y pueden indexarse, pero desde la portada cuesta encontrarlas. La necesidad de negocio es simple: que un visitante entienda los servicios y pueda llegar a ellos sin conocer las URLs.

El flujo empieza revisando la home y la navegación. Después se identifica en el repositorio qué template construye esas áreas y qué tests protegen su estructura. Se prepara un cambio pequeño: renombrar una entrada de navegación si aporta claridad, añadir cuatro enlaces visibles y preservar las rutas existentes.

El cambio se prueba. Si un test detecta que la home superó un límite, rompió una regla o dejó una ruta fuera, se corrige antes del deploy. Una vez que QA queda verde, se publica y se vuelve a revisar producción. El resultado verificable no es “la IA mejoró la empresa”: es que los servicios ahora son accesibles desde las superficies acordadas y el sitio sigue cumpliendo sus controles.

1. 01

   Problema: páginas comerciales poco visibles.

2. 02

   Diagnóstico: home y navegación no las exponen con suficiente claridad.

3. 03

   Cambio: enlaces directos y ajuste de navegación.

4. 04

   Control: build, tests, SEO y revisión visual.

5. 05

   Evidencia: producción muestra las nuevas rutas sin romper las existentes.

11

El objetivo final es un ciclo de mejora continua, no una colección de prompts

Cuando el proceso queda armado, la siguiente mejora empieza con más contexto que la anterior. El repositorio conserva historial, los tests recuerdan reglas, la web pública muestra el estado real y los datos ayudan a decidir dónde existe una oportunidad.

ChatGPT puede convertirse en una interfaz muy cómoda para dirigir ese ciclo: explicar una fricción, investigar, localizar el código, preparar una solución y volver a verificar. Pero la ventaja durable está debajo de la conversación: fuentes confiables, permisos, Git, QA, deployment y medición.

Ese es el enfoque que recomendamos para una empresa que quiere trabajar más rápido sin perder trazabilidad. No automatizar todo de una vez; convertir una mejora concreta en un circuito que pueda repetirse.