Cómo crear una web para negocio local con IA, optimizada y que convierta

Nos ha pasado a todos los que montamos web.

Hablamos con un posible cliente, que tiene un negocio local -de esos que los clientes van a sus oficinas o que ofrecen servicio en un radio limitado de kilómetros- y te suelta eso de “Una web sencillita, para que puedan llamarme o escribirme un WhatsApp”.

Sencillita. Ya.

Obviamente un ecommerce con miles de productos o un SaaS son mucho más complejos, pero si un negocio quiere conseguir clientes vía web (y generalmente gastándose poco o nada en publi) ya te digo que sencillito, sencillito no es.

Porque antes de empezar a hacer nada hay que entender qué ofrece la empresa, averiguar cómo buscan esto los clientes, decidir qué páginas necesita, redactar textos, escoger imágenes, construir formularios, medir leads y comprobar que todo funciona en un móvil.

Si además quieres publicarla en varios idiomas, el número de decisiones se multiplica.

Yo he hecho unas cuantas. Y todas, todas, todas, absolutamente todas han superado los objetivos y conseguido más leads de los estipulados en un principio. Por eso sé de lo que hablo.

Hasta ahora tenía un sistema, que incluía su marketing imprescindible y que prácticamente siempre se implementaba en WordPress, por motivos obvios.

Pero ahora ha llegado la IA. Y facilita cosas que antes llevaban mucho tiempo o eran directamente inmanejables o no compensaba. Ahora sí. Y por eso, la última web que he montado, la de la empresa de transporte Rondabus, la he creado sin CMS, usando un framework de desarrollo, Astro, que no conocía pero que, explicándole a ChatGPT lo que quería, me lo recomendó.

Y creo que ha sido todo un acierto, ya que se enfoca en algo que yo siempre he pensado: para páginas web corporativas, que apenas se tocan en meses y que no se usan para generar contenido nuevo, el HTML estático tres ventajas claras:

1. Más rápido.
2. Más seguro.
3. No requieren un hosting de pago.

Luego cuando hable del stack tecnológico entraré más en detalle, por si la tercera te ha sorprendido.

Y es que, tener una web corporativa con todo lo necesario para generar leads (formulario, email, teléfono y WhatsApp) pagando solo los aproximadamente entre 3 y 10€ al año que cuesta el dominio suena muy bonito.

Y lo es.

En esta guía te cuento el paso a paso para que tú mismo lo puedas replicarlo. Sólo necesitas, aparte del dominio, una cuenta de pago de ChatGPT para analizar, estructurar, escribir, traducir y revisar, mientras Codex trabajaba sobre el código.

Por supuesto puedes sustituir la herramienta por otras. Lo digo sobre todo por si estás pagando Claude también, ya que la combinación de ChatGPT como analista y Claude como desarrollador es todavía mejor.

Aclaradas las necesidades, vamos con el paso a paso.

1. Entiende el proyecto y define todo antes de empezar

Lo primero es que el cliente te explique:

1. En qué consiste el negocio.
2. Qué servicios ofrece.
3. A quién se dirige.
4. En qué zonas da servicio realmente.
5. Quién es su competencia.
6. Qué le diferencia de ellos.
7. Qué pruebas puede mostrar.
8. Qué acciones quieres que haga una persona al entrar en la web. Es decir, cómo le va a aportar negocio el canal digital a su empresa.

Acompañando a esta información, se definirá (tú, el cliente o ambos):

• El dominio.
• Canales de contacto (teléfono, WhatsApp, email, formulario…)
• Idiomas previstos.
• Redacción de los textos.
• Fotografías o imágenes.
• Si se va a crear contenido recurrente o no.

Todo esto lo vais a necesitar la IA y tú.

Aquí distinguimos tres tipos de decisiones:

1. Las de negocio determinan qué se vende y a quién.
2. Las de contenido y diseño determinan qué se cuenta y cómo se presenta.
3. Las técnicas determinan cómo se implementa, publica y mantiene la web.

Una vez tengas todo esto definido, guarda esas decisiones en un brief y en un documento de requisitos (PRD) antes de empezar a construir páginas. Al pasárselos a ChatGPT en un documento evitamos tener que explicarle en cada conversación qué dominio era el correcto, qué páginas estaban aprobadas o de dónde salían el teléfono y el correo.

Da igual ahora mismo la tecnología. Esta metodología sirve con WordPress, Astro o cualquier otro sistema: mantén un lugar claro para las decisiones y otra fuente para los datos del negocio.

Entregable

Un brief corto y un PRD completo, con aprobaciones, decisiones pendientes, objetivos de conversión, materiales disponibles y responsables.

Cuando cambie una decisión, actualiza tú mismo el PRD o solicítaselo a Codex que lo haga por ti.

2. Crea mockups para decidir el diseño

Antes de pedir a Codex que programe nada, es mejor preparar dos o tres propuestas que permitan comparar enfoques. No tienen que ser tres webs terminadas, generalmente basta con la Home o alguna página de servicio de cada propuesta para hacerte una idea del look& feel general del proyecto.

Eso sí, lo suyo es enseñar también la versión móvil para que no haya sorpresas.

Eso es lo primero que le vamos a pedir a Codex.

Como punto de partida, exploramos tres conceptos para una página de servicio. Pueden ser claros u oscuros, o cambiar colores y estilos. Lo que creas que puede venir bien al proyecto, pero pide tres. Dos es poco y cuatro o cinco empieza a ser demasiado.

Una vez que tienes las alternativas juntas fíjate en si la propuesta contiene los módulos necesarios, si los textos son correctos (tuyos o generados por ChatGPT), si muestra el teléfono o WhatsApp como debe, si el formulario pide solo lo necesario, si las imágenes representan bien el servicio, etc. Es decir, si cumple con los imprescindibles del CRO.

Cuando hayas hecho las iteraciones necesarias para ajustar lo imprescindible, puedes enseñárselo a cliente para conseguir su opinión y explicarle cuál te parece a ti la mejor de las tres. Eso sí, fíjate que en lo que le muestres sea lo más aproximado al diseño final, no aproximados. El cliente no tiene por qué estar acostumbrado al mismo nivel de abstracción a la hora de hacer webs que tú.

Entregable

Mockup con dirección visual aprobada, versiones de escritorio y móvil, lista de patrones comunes (header, footer, iconos, hero con formulario…) y una lista de detalles que deben respetarse durante la implementación.

3. Haz un análisis de mercado de guerrilla

No necesitas un estudio de cien páginas para decidir la estructura inicial de una web local. Necesitas los datos suficientes para no elegir las páginas por intuición. Por la tuya o, peor, por la de tu cliente. El análisis tiene dos partes: demanda y competencia.

Análisis de demanda: qué, cuánto y dónde buscan los usuarios

Lo primero que hay que averiguar es si lo que ofrece tu cliente tiene demanda o hay que crearla. Y, sobre todo si hablamos de negocios locales, cuánta tiene en su área de servicio.

Para ello aquí tienes un artículo completo paso a paso del estudio de demanda para ecommerce, pero te lo resumo y adapto para una web de negocio local a continuación.

Haz una lista inicial de servicios con las palabras que usaría un cliente. Añade variantes, necesidades y modificadores geográficos. Ejemplo de mi caso:

• Alquiler de autobuses.
• Alquiler de autobuses Ronda.
• Transporte para bodas.
• Bus boda Ronda.
• …

Se entiende, ¿verdad?

Después comprueba qué consultas muestran intención de contratar, cuáles buscan información y cuáles mezclan servicios que deben compartir página. Por ejemplo, “alquiler de autobús para bodas”, “autocar para invitados de boda” y “transporte para una celebración” responden a una necesidad parecida. No hacen falta tres páginas por aparecer tres formulaciones. En cambio, “transporte escolar” y “traslado a un aeropuerto” implican públicos, condiciones y dudas suficientemente diferentes para merecer páginas propias.

En este primer momento y de cara a crear la estructura de la web, quédate solo con las de intención comercial. El resto, para el blog, si es que lo hay en algún momento.

Usa el Planificador de Palabras Clave de Google Ads para las estimaciones, delimitando el área geográfica. Esto nos dará una idea del volumen de tráfico que podemos alcanzar, sabiendo que un rango de búsquedas no es igual al total de visitas orgánicas que recibiremos, sino una parte. Y con ello y un ratio de conversión estimado, el número de leads que podremos captar menusalmente.

Competencia: contra quién te juegas los cuartos

De nuevo, aquí tienes un artículo donde te explico en detalle cómo hacer un análisis de la competencia en ecommerce. Aunque tiene tiempo y hay cosas que han cambiado, la base no varía.

Adaptado a un negocio local, lo que tienes que hacer es buscar como buscaría un cliente desde las zonas relevantes y registra qué negocios aparecen en resultados orgánicos y locales. Observa sus:

• Servicios.
• Copies, CTAs y contenido.
• Estructura de la web.
• Cobertura geográfica.
• Llamadas a la acción.
• Métodos de contacto.
• Reputación online (nota en directorios como Google Maps o Trustpilot).
• Lead magnet si tienen (normalmente no, ya que no harán email marketing).
• Precios.

No se trata de copiar al primero de la lista. La comparación debe ayudarte a detectar preguntas sin responder en tus contenidos, a aclarar tu(s) propuesta(s) de valor y oportunidades que tu negocio pueda cubrir de verdad.

Si no tienes acceso a datos económicos de un competidor, no los inventes, pregúntale a ChatGPT, quizá con un Deep research.

Entregable

Doble:

Una tabla con las keywords, agrupadas por URL de destino tentativa (home y páginas de servicio, generalemnet), ámbito geográfico si procede, prioridad comercial, competidores visibles y conclusiones. Su propósito es tomar decisiones sobre la web, sobre su estructura y los contenidos (encabezados principalmente) que irán en cada una de ellas.

Además, acompañaremos a esto con un documento con todas las buenas ideas de los competidores aplicables a mi negocio y a la web.

4. Define la estructura web y de cada URL a partir de la demanda

Ahora convierte los grupos de keywords tentativos en un mapa de páginas real. Para cada URL propuesta apunta:

• Qué necesidad resuelve, a quién va dirigida y qué servicio representa.
• Qué acción debe conseguir (formulario, clic en teléfono o WhatsApp, registro de cita…).
• Qué contenidos necesita.
• Si puedo conseguir testimonios reales o no.
• Desde dónde recibirá enlaces internos.
• A qué área geográfica irá enfocada (igual es solo a una, pero igual es conveniente repetir la página de servicio porque consigo clientes en dos países o ciudades distintas).

Decide también qué páginas se deben indexar. O más bien al revés: cuáles no se deben indexar. Ejemplo: las legales y las que dupliquen contenido (quien soy y home).

También es importante de cara al contenido cosas como que, si el negocio tiene un Perfil de Empresa en Google, los datos que allí aparezcan (nombre, servicios, contacto, horarios y zonas reales) sean exactamente iguales que los de la web.

Entregable

Mapa con:

• URL.
• Keywords que la atacan.
• Decisiones particulares sobre el contenido de la página.
• Indexación si o no.

5. Cierra requisitos y elige la tecnología adecuada

Antes de desarrollar nada, es necesario transformar todas las decisiones que hemos ido tomando en un documento de trabajo, una versión nueva y completa de nuestro PRD inicial. El documento debe permitir que otra persona -o la IA en este caso- entienda qué debe construir y cómo sabremos que ha terminado.

Generalmente será más cómodo tener toda esta información en un proyecto de ChatGPT y pedirle que te redacte un borrador, preguntándote cualquier dato que necesite saber y no esté incluido. Una vez terminado sólo tendrás que revisarlo y editarlo. Es mucho más rápido.

Una vez que tenemos toda esta información es el momento de elegir la tecnología. Para este caso de webs te propongo que valores dos sistemas: el framework Astro (aquí sus ventajas y desventajas) o WordPress. En este artículo tienes un cara a cara entre ambos, para que veas por qué, a fecha de hoy, me decanto yo por Astro en estos proyectos.

La combinación ganadora es la que uso yo y es la que voy a seguir en este tutorial:

• Astro para generar la web.
• GitHub como repositorio de código.
• Cloudflare para publicar (no es imprescindible, pero es más fácil si tienes el dominio comprado ahí también)
• Zoho Mail para el email corporativo y API para formulario.

Eso sí, en un negocio cuyo equipo necesite editar con frecuencia muchos contenidos desde un panel, WordPress puede ser mejor punto de partida.

Además de elegir la tecnología, es el momento de organizar también las fuentes. Para ello crea una carpeta en tu PC que contenga distintas subcarpetas, por ejemplo:

• Materiales originales del cliente.
• Material tuyo (estudio de demanda, mockups, PSD, textos…)
• Código.
• Activos finales que necesita la web (lo que se subirá a Cloudflare: HTML, CSS, JS e imágenes, principalemnte).
• Secretos (passwords) de producción.

No todo este material se subirá al repositorio, sino solo lo imprescindible para reconstruir la web, sin contraseñas ni documentos originales enormes que solo se guardan como fuente para trabajar nosotros.

Una vez montada esta estructura es el momento de crear un proyecto en Codex, que no es el mismo que tenemos creado en ChatGPT. Son dos proyectos distintos, que compartirán materiales como el PRD. A partir de este momento tienes que pensar que tienes dos personas trabajando para ti:

1. ChatGPT: el analista, el que diseñará el sistema de acuerdo a tus especificaciones y te propondrá soluciones.
2. Codex: el desarrollador. El que construirá la web en base a las instrucciones que le proponga el analista.

Para crear el proyecto en Codex, no tienes más que:

1. Crear uno nuevo en la aplicación.
2. Darle nombre.
3. Compartirle la carpeta raíz del proyecto que hemos creado en nuestro PC.
4. Explícale dónde está el PRD y que evalúe todo antes de comenzar.

Para acabar este paso, solo falta definir los últimos aspectos previos al desarrollo:

• Cómo se revisan los cambios antes de publicarlos (¿quieres que lo haga Codex o prefieres hacerlo tú manualmente?)
• Cómo se publica (¿hace commit Codex a Github y de ahí a Cloudflare o lo haces tú manualmente)
• Si la web va a ir en varios idiomas y por cuál vamos a empezar.

Una vez lo tengas claro, pídele que añada estas decisiones al PRD. Como tiene permisos para escribir en la carpeta, realizará los cambios pertinentes en el documento. Para ello, a partir de ahora, el sistema de trabajo que vamos a seguir es el siguiente:

1. Tú piensas lo que necesitas. Eres el dueño (owner) del proyecto.
2. Se lo transmites a ChatGPT y valoráis juntos cada punto y las dudas que pueda haber.
3. Una vez aclarado, le pides a ChatGPT que te prepare el prompt para Codex.
4. Se lo pegas a Codex que lo ejecutará.
5. Evalúas lo hecho por Codex e iteras si es necesario.
6. Pasas al siguiente punto de desarrollo.

Desde este momento, tu trabajo en exclusiva es pensar, decidir y definir. Entre tu analista y tu desarrollador son los que montarán la web.

Entregables

• PRD previo al desarrollo aprobado (igual sufre cambios conforme desarrollemos el proyecto).
• Carpeta con estructura del repositorio.
• Plan de publicación y pruebas.

6. Escribe los textos

Si no lo has hecho antes, ahora que tienes ya la estructura de la web y el proyecto montado toca comenzar con los contenidos de cada URL.

La Home debe explicar la oferta general y llevar a los servicios. Cada página de servicio necesita describir qué se ofrece, para quién, en qué situaciones, qué dudas suele tener el cliente y cómo contactar. Aquí, los textos SEO no sustituyen a los textos útiles para personas: cuando ambos están bien planteados, trabajan juntos.

Usa la IA para preparar borradores con contexto. Explícale:

• El servicio.
• Tu propuesta de valor única.
• Público.
• Zona geográfica.
• Tono.
• Preguntas frecuentes reales.
• Testimonios que se tengan. Si existe una página de empresa de Google, es posible que podamos recoger buenas opiniones de ahí.

Itera y edita lo que te devuelva hasta que tengas algo publicable. Una vez lo tengas, piensa cómo distribuirlo en distintos módulos o pídele a ChatGPT que te haga propuestas. Es posible que aparezcan módulos que se repiten en toda la web (un formulario, un mapa, ventajas generales). No te preocupes todavía de ello, en el siguiente paso lo tendremos en cuenta.

Te dejo un prompt orientativo para un borrador de servicio:

Redacta la página de [servicio] para [negocio] en [zona]. Propuesta de Valor Unica [propuesta]. Público: [audiencia]. Intención principal: [necesidad]. Testimonios: [lista]. Dudas habituales: [lista]. CTA: [acción]. Mantén un tono [tono]. Propón estructura, copy, metadatos SEO y schema. Señala cualquier afirmación que necesite prueba y no inventes cifras, reseñas, vehículos ni cobertura.

Crea el contenido de todas las páginas una por una.

Entregable

Fichas de página aprobadas con el contenido: texto, CTA, metadatos, pruebas y materiales visuales. Puedes construir primero la Home y una página de servicio representativa para comprobar si el sistema funciona antes de extenderlo al resto de servicios y contacto.

7. Separa los componentes reutilizables

Con los mockups y las fichas de página delante, marca lo que se repite de verdad: cabecera, navegación, pie, botones, formulario, tarjetas de beneficios, bloques con imagen, CTAs finales y avisos…

El motivo es que usaremos para estos un componente reutilizable, de forma que, si se cambia el teléfono, solo lo cambiemos en el componente y se aplica a todas las URLs. Obviamente, el header y el footer son elementos reultilizables, pero es posible que haya más.

Además, es posible que quieras que todas las páginas de servicio compartan un mismo diseño o estructura. Por ello, separa la estructura de los datos. Ejemplos:

• Una plantilla de página servicio puede montar bloques comunes sin imponer el mismo texto a todas las páginas.
• Siendo más específicos: un componente de beneficios puede conservar la maquetación mientras cambian título, explicación e icono.

Haz una prueba práctica antes de multiplicar el patrón: pídele a ChatGPT que te dé el prompt para que Codex maquete la Home y una página de servicio, compáralas con los mockups y modifica tanto los contenidos individuales como los componentes comunes.

Prueba cómo se ve en Desktop y en Mobile. Cuando todo esté correcto, extiende el sistema al resto.

Entregable

Home y una página de servicios maquetada.

Inventario de componentes, datos que recibe cada uno y páginas que lo utilizan.

8. Prepara las imágenes para producción

Venga, que tras los textos toca definir las imágenes.

Idealmente el cliente te habrá pasado unas decentes que utilizar. En la práctica no suele ser así. Afortunadamente, si no te manejas con Photoshop, ChatGPT es tu amigo y su sistema de creación y edición de imágenes es muy, muy bueno. Así que, al lío.

No te compliques de más, con entre una y tres imágenes como mucho por URL debería ser suficiente. Y, probablemente, algunas se repitan. Lo ideal es que la primera, la de cabecera, sí que sea distinta en cada caso.

Conserva los originales del cliente y, cuando produzcas una imagen nueva, guarda un máster de buena calidad en carpetas que no subiremos al repositorio.

Después le pides a ChatGPT que le pieda Codex que adapte cada imagen a su lugar en la web y que para ello:

• Genere versiones con dimensiones y formatos adecuados, generalmente .webp para fotografías y SVG para iconos.
• Defina tamaños responsive y evite enviar al móvil un archivo pensado para llenar una pantalla grande.
• Reserve su espacio para que la página no salte mientras carga. La imagen principal puede necesitar prioridad de descarga, mientras que una foto muy abajo puede esperar.
• Un texto alternativo útil describe la información de la imagen, si puede meter una keywords que encaje, mejor.

Entregable

Imágenes finales para la web.

9. Crea los iconos

Probablemente el punto más difícil de optimizar en webs que contengan muchos (más de 20 o 30).

Y es que, es difícil generar variantes para todos con un mismo estilo, sobre todo en un mismo tile. Al final acabas yendo uno por uno lo que lleva tiempo.

Y luego, más difícil aún: pasarlos a SVG y que queden bien. Por eso, mi punto aquí es que, si tienes que usar PNG recortados a mano o en un tile generado en Photoshop, pues adelante. No alcanzarás el 100% de optimización posible, pero ahorrar muchísimo tiempo. Te lo digo por experiencia.

Por ejemplo, en Rondabus probé varias soluciones porque los primeros dibujos se alejaban de las referencias: algunos eran demasiado simples y otros tenían una escala visual distinta pese a ocupar el mismo cuadro. Llegué a explorar recortes y PNG de las planchas aprobadas, pero la solución que quedó en la versión 2.0 fueron los SVG originales con un tamaño de representación mayor.

Para realizar el proceso:

1. Identifica primero dónde aparece cada icono y qué significa.
2. Agrupa los que se repiten.
3. Conserva un máster por dibujo o tile.
4. Prepara una vista previa en los contextos reales: hero, módulo de tarjeta de servicios, módulo de listado de beneficios, contacto…
5. Ajusta el tamaño óptico sin deformar las formas: dos iconos con el mismo ancho de archivo pueden parecer muy diferentes por los márgenes de su dibujo.
6. Valida una muestra en una página importante (home o servicios) antes de intentar cambiar todas las páginas. Si un intento no reproduce bien el estilo del mockup, vuelve a la referencia y descártalo.
7. Aplica al resto de páginas.
8. El formato de archivo es una decisión de implementación, mientras que la calidad visual y la consistencia son lo que comprobará el usuario. Y es lo más importante.

Entregable

Set de iconos y másteres aprobados

10. Construye la web por etapas

Una vez aprobados la Home y el patrón de servicio, construye el resto de páginas y revísalas individualmente. Que compartan plantilla no significa que todas funcionen visualmente: cambian la longitud de los titulares, las fotografías, el número de beneficios, los textos del botón y las necesidades del público.

Revisa escritorio y varias anchuras móviles y tablets. Ponte las gafas de usuario y compara cada página con el mockup y comprueba lo que un diseño estático no puede mostrar:

• Menú desplegable.
• Enlaces.
• Validación front del formulario.
• Imágenes e iconos que cargan.
• Contenido largo
• Cortes de línea en titulares.
• …

Conviene guardar puntos de control del código cuando se aprueba una etapa con varios cambios. Solicítaselo a ChatGPT mientras pules cosas.

Entregable

Páginas completas en el front end (falta validar el formulario, si lo tienes).

Punto de control de front acabado, web versión V1 (un idioma). Si consideras que tu web está acabada en este punto, salta al epígrafe 17 para publicarla online.

11. Monta un formulario y otras formas de contacto

Si has leído mis artículos sobre Astro tendrás claras dos cosas:

1. Que publicas archivos HTML.
2. A un servidor sin lenguaje de servidor (PHP, Python).

Esto tiene muchas ventajas y una pega: no puedes mandar formularios directamente.

Para ello hay varias soluciones, entre ellas:

• Usar servicios de pago de Cloudflare.
• Usar un proveedor de Email (gratis o de pago) e integrar el servicio vía API.

En mi caso, como en estos proyectos suelo montar también el sistema de correo del proyecto y uso la versión gratuita de Zoho Mail, me decanto por usar este servicio para enviar los correos generados por los formularios, en vez de añadir un proveedor más.

Es un pelín complejo y requiere de varios pasos que tendrás que realizar manualmente, así que pídele a ChatGPT que te vaya guiando paso a paso. Y, sobre todo, no subas los secrets al repositorio de GitHub. Cloudflare tiene un sitio para almacenarlos.

Una vez completo, rellena bien y mal el formulario para comprobar que la validación funciona y que el envío también.

Si no lo has hecho antes, es buen momento para probar también el enlace de teléfono y WhatsApp desde un móvil real, si es que los tienes añadidos, como casi seguro deberías.

Entregable

Formulario probado y funcionando de extremo a extremo.

Punto de control, web versión V1.5 (finalizada con formulario y un idioma).

Con esto y a falta de publicar la web (paso 17) ya tendríamos terminado lo imprescindible para cualquier web de negocio local. Lo que pasa que los siguientes pasos son MUY RECOMENDABLES si queremos captar clientes de verdad.

12. Mide contactos y configura el consentimiento

Empezamos los pasos opcionales con un básico: medir.

¿Qué queremos medir? Pues lo imprescindible:

• Eventos de conversión.
• Tráfico.

¿Para qué?

Pues para saber por dónde nos entran las ventas, sobre todo si pensamos pagar publicidad para obtener los primeros clientes (deberías planteártelo seguro).

Entonces, lo primero es definir el plan de analítica que incluirá los eventos de negocio antes de instalar nada. Que serán muy claros:

• Contacto por teléfono.
• Por WhatsApp.
• Por email.
• Por formulario.
• Cierre de citas en la agenda.
• Suscripción (a newsletter, si acaso).
• Clic a ver dirección en Google Maps.

Y probablemente estos incluyen todos los que necesitas medir en este tipo de web.

Decide cuáles aplican en tu caso y pídele a ChatGPT que te devuelva:

• El nombre del evento según la nomenclatura recomendada de Google, porque te propongo usar Google Analytics 4 para medir esto.
• Condición de disparo del evento.
• Parámetros secundarios (si procede en algún caso).

El sistema es el siguiente:

Usuario web ejecuta un evento > Google Tag Manager lo recoge > GA4 lo almacena para que puedas ver los datos.

Date de alta tanto en GA4, como en GTM con tu cuenta de Google, y ya que te pones, también en GSC, que lo usaremos más adelante para temas de SEO.

Si tu negocio está en la Unión Europea, la medición también depende de las decisiones de privacidad. Por eso, pídele a ChatGPT que implemente el Google Consent Mode v2 avanzado, con una opción para volver a abrir las preferencias. Te creará el típico banner de cookies.

Con todo esto definido, pídele a ChatGPT que Codex te de el archivo JSON con el contenedor a importar en GTM. La IA te pedirá los identificadores correspondientes a tus cuentas de GA4 y GTM y te dará un archivito con todo lo necesario listo para importar.

Ya solo te quedará probar cada uno de los eventos en la vista precia de GTM antes de publicar el contenedor y comenzar a recabar datos reales de tu web.

Entregable

El plan de medición, la implementación de GTM y GA4 funcionales con el consentimiento probado si aplica en tu caso.

13. Cierra el SEO técnico y publica la primera versión

Si estás trabajando el SEO local, cosa que deberías, es momento de lanzar Screaming Frog y comprobar los errores. Pídele a ChatGPT que te los corrija.

Conecta la web con el Perfil de Empresa en Google que tengas. Revisa nombre, categorías, dirección o área de servicio, teléfono, horario, fotos y servicios sin inventar ubicaciones.

Además, dentro de GSC (Google Search Console) sube el sitemap generado. Si no sabes la URL, pídesela a Codex directamente. Tras unos días observa si las páginas importantes se pueden rastrear e indexar.

Entregable

Una web sin errores SEO técnicos, con URLs y sitemap verificados y dominio canónico correcto.

Podríamos llamar a esta versión V2.

14. Decide si merece la pena ampliar la web a otros idiomas

Entramos ya en la última parte del proceso: traducir la web a otros idiomas.

Antes de decidirlo, confirma:

• Qué públicos quieres atraer.
• En qué idioma del atenderás.

No es lo mismo ofrecer un servicio de masaje a un noruego en Málaga sin hablar el idioma que un servicio de abogacía. También puedes atraer a japoneses que busquen un servicio de taxi en Ronda, pero dejar claro que solo les atiendes en inglés.

Además, un idioma nuevo implica traducción de contenidos, menús, formularios, metadatos, schema y futuras actualizaciones, no es solo el botón con una bandera.

Cuando tengas claro qué idiomas quieres en tu web junto con ChatGPT establece:

• El idioma de partida, que es el que ya tienes en tu web pública.
• Los idiomas a traducir.
• Las páginas traducibles, que no son todas (por ejemplo, la de error 404 o las legales)
• La política de URLs. Decide si los slugs se traducen, cómo se conectan las páginas equivalentes y qué ocurre cuando falta una traducción.

La arquitectura debería identificar cada página por un código estable independiente del idioma, así el selector puede llevar a la página equivalente y la web puede generar relaciones hreflang sin tener que adivinar mediante el título visible.

Todo esto es previo a la traducción.

Entregable

Plan de traducción.

15. Separa exportación, traducción e integración

El proceso que mejor me funciona es dividir el trabajo.

1. Codex inspecciona el proyecto y prepara un paquete de textos con identificadores estables, texto fuente, contexto, idioma destino, marcadores, enlaces y términos protegidos. Normalmente será un paquete de JSON o XML lo que nos prepara.
2. ChatGPT traduce estos paquetes, revisa los valores y nos devuelve los archivos traducidos.
3. Codex integra estos archivos y validaba las páginas.

Esta división permite cambiar de traductor (incluso hacerlo con un humano) sin pedirle que entienda el código ni obligar al desarrollador a adivinar el sentido de cada frase. Obviamente, la revisión de ChatGPT no sustituye a una revisión lingüística de un traductor jurado.

Prompt para exportar:

Inspecciona el proyecto y prepara un inventario traducible para [idiomas]. Incluye texto visible, navegación, formularios, metadatos y slugs. Para cada unidad proporciona ID estable, texto fuente, contexto, marcadores, enlaces y términos protegidos. No traduzcas ni modifiques todavía las páginas. Informa de cadenas ambiguas y de contenido que no tiene equivalente.

Prompt para traducir:

Traduce únicamente los valores del paquete al [idioma y variante]. Público: [audiencia]. Tono: [tono]. Glosario: [términos]. Conserva IDs, estructura, orden, placeholders, nombres propios, enlaces y código. Señala fuera del paquete las frases que requieran una decisión de negocio o revisión nativa.

Prompt para integrar:

Importa estas traducciones aprobadas en el proyecto. Comprueba IDs, marcadores, términos protegidos, slugs y rutas equivalentes. No publiques un idioma con textos obligatorios ausentes. Ejecuta la auditoría de traducciones, las comprobaciones del proyecto y el build; informa de cualquier diferencia antes de desplegar.

Entregable

Web multiidioma sin revisar.

16. Audita cada idioma como una web completa

Una vez estén integradas las traducciones en la abre las páginas: un archivo válido puede producir un menú que se desborda, una CTA demasiado larga o un aviso que tapa el formulario. Revisa cada URL de cada idioma tanto en escritorio como en móvil.

En la parte SEO, verifica (tú o ChatGPT):

• <html lang>.
• Título.
• Descripción.
• URL localizada.
• Canonical propio.
• Relaciones hreflang entre páginas equivalentes.
• Sitemap de URLs indexables.
• El selector debe mantener la página actual al cambiar de idioma cuando exista equivalente.
• Comprueba también enlaces del pie.
• Formularios y mensajes de error.
• Textos alternativos de las imágenes.
• Datos estructurados que incluyan texto o URLs.

Itera lo necesario hasta tener pulido todo.

Entregable

Web completa multiidioma, versión V3.

17. Publica una versión identificable y verifica producción

Ya sea tras el paso 10 (V1), el 11 (V1.5), el 13 (V2) o el anterior (V3), lo que tenemos es una web montada en un entorno de pruebas. Falta subirla a producción. Y es lo que vamos a hacer aquí.

Aquí vamos a pedirle a ChatGPT que le diga a Codex que nos publique la build en Cloudflare.

Para ello, Codex:

1. Se logará en nuestra cuenta de GitHub.
2. Nos pedirá que seleccionemos o creemos el repositorio adecuado.
3. Se logará en nuestra cuenta de Cloudflare
4. Nos preguntará en qué dominio debería publicar.
5. Publicará la última versión de la web.

Y nosotros sólo tendremos que revisar que todo se ve igual que en nuestra versión de pruebas.

Ya habremos acabado con la web.

Entregable

Versión completa de la web publicada.

18. Convierte el proyecto en un método repetible

Esto es más opcional todavía pero muy recomendable si quieres aplicar el proceso a otra web de otro negocio.

Solo tienes que pedirle a ChatGPT que te cree una Skill con todo el proceso que habéis seguido. De esta forma no tendrás que acordarte de cada paso la última vez o de volver aquí a revisar este tutorial. Tu ChatGPT lo tendrá bien guardado y tu Codex lo tendrá instalado en sus tripas.

Así, la próxima web que crees de otro negocio local será muchísimo más rápido.

Mola, ¿eh?