El vibe coding es lo que pasa cuando alguien abre un chat con una IA un martes en la tarde, escribe "hazme un sitio para mi empresa" y a la hora de once ya tiene algo publicado. Sin developer, sin ticket, sin esperar al próximo sprint. Qué maravilla (de verdad).
Ahora, mi lectura después de varias auditorías es menos romántica: el vibe coding hace más fácil construir un sitio y también hace más fácil romper el SEO de uno que ya funciona. Vuelve a inventar reglas que los CMS traían resueltas, como las URLs, los canonicals, las redirecciones o el sitemap, y muchas veces nadie revisa el código que las genera. En esta guía te explico qué es, cómo funciona, qué herramientas se usan y qué revisaría yo antes de dejar que un sitio hecho así reemplace al que ya te trae clientes.
¿Qué es el vibe coding?
El vibe coding es una forma de crear software en la que describes en lenguaje natural lo que quieres y la IA (uno de los modelos de lenguaje que también están detrás de ChatGPT) escribe el código por ti. Le dices "quiero una página con un formulario de contacto que me mande un correo", miras lo que salió, pides cambios y vuelves a mirar.
La diferencia con pegarle una pregunta a ChatGPT y copiar la respuesta es el contexto. En el vibe coding, la inteligencia artificial tiene acceso a todo el proyecto: puede modificar varios archivos a la vez, ejecutar el código, ver si funciona y corregirse sola. Tú casi no ves el código. Ves el resultado en pantalla y lo juzgas por cómo se ve.
Eso es justamente lo que lo hace tan atractivo para equipos de marketing, founders y cualquier persona que alguna vez esperó tres semanas para cambiar un botón. Y también es la parte que me preocupa cuando lo que se construye es un sitio web que Google tiene que rastrear, entender e indexar (porque Google no mira el sitio como lo miras tú en la pantalla).
¿De dónde viene el término?
El nombre lo puso Andrej Karpathy, ex investigador de OpenAI y ex jefe de IA en Tesla, en febrero de 2025. En un post en X describió una forma de hacer software donde "te entregas completamente a las vibras" y te olvidas de que el código existe.
El término se masificó rápido. En noviembre de 2025 el diccionario Collins eligió "vibe coding" como su palabra del año 2025.
¿Cómo funciona el vibe coding en la práctica?
Un flujo típico de vibe coding tiene cuatro pasos que se repiten en ciclo, y yo le agregaría un quinto que los tutoriales suelen saltarse:
- Describir el objetivo. Escribes un prompt con el resultado que quieres, no con el código: "una landing para nuestro servicio de auditoría con tres secciones y un formulario".
- Generar y revisar. La herramienta genera el código y te muestra una vista previa. No necesitas leerlo, necesitas decidir si eso que ves hace lo que pediste.
- Iterar en lenguaje natural. "El título está muy grande", "agrega una sección de preguntas", "cambia el color del botón". Cada ajuste es un prompt nuevo.
- Corregir errores. Cuando algo falla, copias el mensaje de error, se lo pegas a la IA y le pides que lo arregle. Muchas veces lo resuelve sola. Cuando no, se nota quién tiene criterio técnico y quién no.
- Publicar. Apretar el botón de publicar es donde empieza la parte que le importa a Google: qué HTML recibe un rastreador, qué URLs existen, a dónde apuntan los enlaces. Ese paso casi nunca aparece en el ciclo, y es el que más me toca revisar.
El ciclo es entretenido y adictivo. El problema es que cada iteración puede cambiar cosas que no estabas mirando. Le pides cambiar un título y la IA reescribe la plantilla completa, con la etiqueta canonical incluida.
¿Qué herramientas de vibe coding se usan más?
Hay herramientas para perfiles muy distintos. Algunas están pensadas para quien nunca ha hecho software y otras para desarrolladores que quieren ir más rápido. Para un sitio web, la pregunta que yo agregaría a la comparación es cómo publica cada una, porque de eso depende qué ve Google.
| Herramienta | Para qué sirve mejor | Lo que revisaría para SEO |
|---|---|---|
| Lovable | Apps y sitios web completos con base de datos, desde el navegador | Si el proyecto renderiza en servidor o en el navegador (depende de cuándo se creó) |
| Bolt | Prototipos full-stack desde el navegador | Qué HTML llega antes de ejecutar JavaScript |
| Replit | Prototipos, scripts y apps en un entorno en el navegador | Dominio, redirecciones y URLs de prueba publicadas |
| v0 (Vercel) | Interfaces y componentes web a partir de una descripción | Que los enlaces sean enlaces de verdad y no botones |
| Cursor | Editor de código con IA para quien ya programa | Lo mismo que cualquier desarrollo: revisión antes de publicar |
| Claude y ChatGPT | Generar e iterar código conversando | Que lo que se pega en el sitio no duplique etiquetas |
Copilot y Windsurf completan el grupo de editores con IA.
¿Qué ventajas y riesgos tiene el vibe coding?
Las ventajas son reales y por algo el término se volvió tan popular. Los problemas también, y la mayoría de las guías los resume en seguridad y calidad del código.
| Ventajas | Lo que hay que vigilar |
|---|---|
| Prototipos en horas en vez de semanas | Errores ocultos que aparecen cuando el proyecto crece |
| Personas sin formación técnica pueden construir sus propias soluciones | Seguridad: validaciones y manejo de datos que nadie revisó |
| Menos código repetitivo para los desarrolladores | Deuda técnica: parches sobre parches, difíciles de mantener |
| Probar ideas antes de invertir en desarrollo | Pérdida de control: nadie sabe bien qué hace cada parte |
La seguridad es lo más conocido. Una app que maneja datos personales, pagos o accesos necesita a alguien que revise el código generado antes de ponerla en producción. Los problemas de calidad aparecen después: a medida que el proyecto crece, la IA pierde coherencia, agrega una función que rompe otra y contradice decisiones anteriores. Lo que funcionaba con 200 líneas se vuelve frágil con 2.000.
Hay un caso que circuló mucho en 2025: un emprendedor contó en X que su SaaS estaba construido con Cursor "con cero código escrito a mano". Días después escribió que había usuarios saltándose la suscripción y que no podía arreglarlo porque no era técnico. Terminó cerrando la app.
Lo que las guías no suelen mencionar es un tercer riesgo, más silencioso: el del canal orgánico. Un error de seguridad se nota rápido. Un sitio que el buscador entiende peor se nota cuando el tráfico ya bajó, y eso pueden ser meses.
¿En qué se diferencia de programar de la forma tradicional?
En el desarrollo de software tradicional escribes cada línea en un lenguaje de programación y entiendes lo que hace. En vibe coding conversas, y la IA decide cómo implementarlo. Ganas velocidad y accesibilidad. Pierdes control sobre la calidad y, sobre todo, la capacidad de explicar por qué algo funciona.
Addy Osmani, ingeniero de Google Chrome, lo resumió en lo que llamó el problema del 70%: la IA ayuda más a los desarrolladores con experiencia que a los principiantes, porque ellos saben cuándo corregir lo que propone la IA. La IA acelera, pero lo que mantiene el código mantenible es el criterio de quien lo revisa.
Para un sitio pasa lo mismo con el SEO. Si en el equipo hay alguien que sabe qué es un canonical, el vibe coding es un acelerador fantástico. Si no lo hay, las decisiones técnicas las toma la IA y nadie las revisa antes de publicar.
¿Qué le puede hacer el vibe coding al SEO de tu sitio?
Antes, cambiar la URL de una página pasaba por un developer, alguien que sabía del CMS y, con suerte, alguien de SEO. Ahora basta un prompt. Eso es bueno para la velocidad y un riesgo concreto para un sitio que ya posiciona.
Cuando audito sitios hechos o rehechos a punta de prompts, estos son los problemas que más se repiten:
- Contenido que no renderiza para los rastreadores. La página se ve perfecta en el navegador, pero el HTML inicial viene casi vacío y todo depende de JavaScript.
- Canonicals duplicados o contradictorios. Me ha tocado ver la etiqueta canonical repetida 18 veces en una misma página, cada una apuntando a una URL distinta.
- Enlaces a URLs de staging o a versiones antiguas que quedaron en el código.
- URLs que nadie sabía que existían, generadas por la plataforma, y URLs antiguas eliminadas sin redirección.
- Hreflang que no calzan entre idiomas o países.
- Un sitemap que no refleja el sitio real.
La documentación de Google sobre JavaScript explica por qué esto importa. Googlebot solo descubre enlaces que son elementos <a> con atributo href, así que un botón que navega con JavaScript puede dejar páginas sin descubrir. Google recomienda renderizar en servidor o pre-renderizar porque no todos los bots ejecutan JavaScript (un análisis de Vercel de diciembre de 2024 encontró que los principales crawlers de IA, como GPTBot y ClaudeBot, no lo ejecutan). Y si el canonical se inyecta con JavaScript, tiene que ser el único de la página: dos etiquetas contradictorias dan resultados que nadie controla.
La buena noticia es que las herramientas están corrigiendo parte de esto. Según su propia documentación, los proyectos de Lovable creados desde el 13 de mayo de 2026 renderizan las páginas en el servidor. Los más antiguos renderizan en el navegador, y Lovable sirve copias pre-renderizadas a buscadores verificados y a crawlers de IA. O sea, la misma plataforma se comporta distinto según la fecha en que partió tu proyecto, y vale la pena saber en cuál estás.
El SEO técnico conoce estos problemas hace años. Con vibe coding aparecen más rápido, y muchas veces la persona que hizo el cambio no tiene cómo verlos. Si tu sitio ya recibe tráfico orgánico, un rediseño con vibe coding es una migración, y se trata como tal. Te dejo este checklist para rediseñar una web sin destruir tu posicionamiento como punto de partida.
¿Cuándo conviene usar vibe coding y cuándo no?
Yo lo usaría sin miedo para:
- Prototipos y pruebas de concepto antes de invertir en desarrollo.
- Herramientas internas: calculadoras, dashboards con datos del negocio, formularios para el equipo.
- Landings de campañas que no dependen del tráfico orgánico.
- Sitios nuevos, siempre que alguien revise lo técnico antes de publicar.
Y lo pensaría dos veces para:
- Rehacer un sitio que ya trae tráfico orgánico y clientes, sin un mapa de URLs.
- Proyectos en producción con datos sensibles, pagos o exigencias de seguridad.
- Sitios grandes con miles de URLs, filtros o varios países.
Declaración de intereses: este sitio está construido con una plataforma de vibe coding. Me encanta la velocidad, y justamente por eso la revisión técnica antes de publicar me parece la parte que no conviene saltarse.
¿Cómo revisar un sitio hecho con vibe coding antes de publicarlo?
Ninguno de estos pasos requiere saber programar. Requieren una tarde y algo de método:
- Haz la lista de lo que hoy funciona. Exporta de Search Console los datos de las páginas con clics de los últimos 16 meses (es todo lo que guarda) y suma las URLs que tienen enlaces de otros sitios. Esa es la lista de lo que no puedes perder.
- Asigna a cada URL antigua su URL nueva, una por una, antes de publicar. Lo que cambia de dirección lleva redirección 301. En esta guía sobre migraciones y SEO explico cómo dimensionarlo.
- Mira el HTML que llega, no la página que ves. Abre el código fuente de la página (no el inspector) y busca el título, el texto principal y los enlaces. Si no están, un rastreador tampoco los ve.
- Cuenta los canonicals. Busca "canonical" en el código fuente de tus plantillas principales. Tiene que haber uno por página y tiene que apuntar a la URL correcta.
- Revisa los enlaces y el sitemap. Que el menú use enlaces de verdad, que no queden URLs de staging y que el sitemap tenga las URLs que quieres indexar.
- Usa la inspección de URL de Search Console en las páginas más importantes después de publicar, para ver la versión que renderizó Google. Si algo no aparece, revisa cómo indexar una página en Google y qué está fallando.
En sitios grandes sumaría una revisión de logs para ver a qué URLs está yendo Googlebot, porque las URLs generadas sin querer suelen comerse el rastreo (más sobre eso en crawl budget).
Preguntas frecuentes sobre vibe coding
¿El vibe coding es malo para el SEO? No por definición. Un sitio hecho con vibe coding puede posicionar bien si el HTML que recibe Google trae el contenido, los enlaces son enlaces y las URLs, canonicals y redirecciones están bajo control. El problema aparece cuando nadie revisa esas decisiones.
¿Google puede leer un sitio hecho con Lovable? Depende de cuándo se creó el proyecto. Según la documentación de Lovable, los proyectos nuevos renderizan en servidor y los antiguos entregan copias pre-renderizadas a buscadores verificados. La forma de salir de dudas es la inspección de URL de Search Console.
¿Necesito saber programar para hacer vibe coding? Para construir un prototipo, no. Para publicar algo con usuarios reales, datos o tráfico orgánico, conviene que alguien con criterio técnico revise el código antes, aunque no lo haya escrito.
Si estás por publicar algo hecho con vibe coding, mi recomendación es bloquear una tarde antes de apretar el botón: la lista de URLs que hoy traen clics, el mapa de redirecciones y una mirada al código fuente de tus tres plantillas principales. Es poco tiempo al lado de lo que cuesta recuperar un sitio que el buscador dejó de entender. Y si quieres partir por lo básico, en cómo crear una página web paso a paso está lo que no puede faltar desde el día uno.