Vibe Coding

## ¿Qué es el vibe coding? El **vibe coding** es la práctica de lanzar aplicaciones **describiendo funcionalidades a herramientas de código con IA**, como Cursor o Claude Code, y dejando que esas herramientas generen gran parte de la implementación. En términos prácticos, un fundador, marketer o creador de producto escribe prompts como “crear una página de precios”, “crear un flujo de onboarding” o “conectar este formulario a una base de datos”, y la IA produce código, estructura y, a menudo, también algo de diseño. Esa definición importa porque el vibe coding no es simplemente “usar IA en el desarrollo”. La idea central es que **la intención en lenguaje natural impulsa gran parte del proceso de construcción**. La persona humana sigue marcando objetivos, revisando resultados, probando el comportamiento y decidiendo qué se publica, pero la IA realiza una gran parte del trabajo de programación. He visto que el mismo patrón se repite una y otra vez en builds en etapas tempranas: la primera versión generada por IA a menudo parece terminada en el navegador mucho antes de que realmente esté lista para el posicionamiento en buscadores. Ese es el vacío práctico que este término intenta nombrar para fundadores y equipos de SEO. La velocidad es real. La limpieza posterior oculta también lo es. Para equipos de SEO y equipos de crecimiento liderados por el fundador, el atractivo es evidente: puedes poner en marcha MVPs, landing pages, herramientas internas y aplicaciones ligeras mucho más rápido que con un flujo de trabajo de ingeniería tradicional. El tradeoff es menos absoluto de lo que algunos resúmenes hacen sonar. **Algunos proyectos generados con IA son amigables para SEO “de fábrica”; otros no.** El resultado depende en gran medida del framework elegido, del prompt y de si alguien revisa el resultado renderizado antes del lanzamiento. Por eso, en un contexto de búsqueda, el vibe coding se entiende mejor como **creación rápida de aplicaciones con ayuda de IA más un refuerzo explícito de SEO**. Si lanzas una app con mucho JavaScript sin renderizado del lado del servidor, sin metadatos indexables y sin rutas de descubrimiento rastreables, los motores de búsqueda pueden entender tu contenido de forma más débil o más lenta. Google puede renderizar JavaScript, pero su propia documentación sigue enfatizando el renderizado, los enlaces y los metadatos como preocupaciones de implementación, en lugar de detalles que se deban ignorar. ## Por qué el vibe coding es popular El vibe coding ha crecido porque reduce la barrera práctica entre una idea y un producto funcionando. Una persona que no es ingeniera a menudo puede llegar a un prototipo describiendo resultados en lugar de escribir manualmente cada función. Un ingeniero con experiencia puede usarlo para acelerar tareas repetitivas, andamiaje (scaffolding), tests, generación de UI y trabajo de integración. Casos de uso comunes incluyen: - MVPs de startups - herramientas internas de SEO - paneles de flujo de trabajo para contenido - microsites de generación de leads - portales de clientes ligeros - páginas de experimentos para validar demanda En la práctica, la mayor ventaja normalmente no es que la IA siempre escriba mejor código. Es que **comprime el tiempo entre planificar y probar**. Los equipos pueden validar ofertas, mensajes y flujos antes. Ese es un beneficio operativo sólido, incluso cuando el código generado todavía requiere limpieza. Desde la perspectiva de un fundador, por eso el vibe coding resulta tan atractivo: convierte “deberíamos probar esto algún día” en “podemos poner algo en producción esta semana”. En mi experiencia, esa compresión de tiempo es el producto real, no la novedad de escribir prompts en sí. ## Dónde aparecen los problemas de SEO en apps con vibe coding El problema de SEO más grande es que muchos proyectos generados con IA pueden terminar pareciéndose a un **SPA renderizado del lado del cliente (client-rendered SPA)**, especialmente cuando el prompt se centra en velocidad, interactividad o una demostración rápida de front-end. Esto no significa que cada herramienta de IA produzca siempre un SPA, ni que todo SPA sea automáticamente invisible para los buscadores. Significa que la salida predeterminada merece inspección. Un SPA renderizado del lado del cliente normalmente carga primero un “shell” de JavaScript y luego inyecta el contenido de la página después de que los scripts se ejecutan. Los motores de búsqueda modernos, especialmente Google, pueden renderizar JavaScript, pero Google también explica que el renderizado de JavaScript puede implicar procesamiento adicional. Por tanto, el riesgo práctico suele ser **menor fiabilidad o interpretación más lenta**, no “los motores de búsqueda nunca pueden leerlo”. El fallo real recurrente en el mundo real es sencillo: un fundador abre la app, hace clic, ve pantallas pulidas y asume que lo técnico básico está cubierto. Luego alguien revisa el HTML en bruto y encuentra un div raíz, metadatos genéricos y cambios de ruta gestionados de forma correcta para usuarios, pero débiles para el descubrimiento. Ese no es un problema exclusivo de la IA, pero la IA puede hacer que ese problema se publique más rápido. Problemas típicos incluyen: ### 1. HTML inicial vacío Si el código fuente de la página contiene poco más que un div raíz y etiquetas de script, los rastreadores pueden no ver inmediatamente el contenido principal. Esto puede ser más frágil en páginas nuevas, en sitios más débiles o en páginas que dependen de fetches del lado del cliente. ### 2. Falta o duplicación de etiquetas de title y meta descriptions Los SPAs construidos con IA a veces omiten metadatos específicos por ruta. Si cada ruta comparte un solo título genérico, los motores de búsqueda reciben señales más débiles de cada página y los usuarios pueden ver snippets deficientes. ### 3. Sin renderizado del lado del servidor ni prerendering Si el contenido solo aparece después de que se ejecuta JavaScript, algunos rastreadores y “scrapers” sociales podrían pasarlo por alto. El SSR, la generación estática o el prerendering suelen dar a bots y usuarios una respuesta más confiable orientada al contenido. ### 4. Enlaces internos rotos Algunas apps generadas usan eventos de JavaScript en lugar de enlaces ancla (anchor) rastreables. Si los bots no pueden seguir rutas fácilmente, el descubrimiento puede verse afectado. ### 5. Falta de sitemaps XML Para sitios generados recientemente con muchas rutas dinámicas, un sitemap puede ayudar a que los motores de búsqueda encuentren URLs con más fiabilidad. ### 6. Manejo débil de canónicas Las herramientas de IA pueden generar rutas duplicadas, variantes con parámetros de consulta o URLs de preview sin tags canonicals adecuados. ## Cómo hacer el vibe coding seguro para SEO El vibe coding no es “anti-SEO”. Solo necesitas una definición más sólida de “listo” (done). Para aplicaciones y sitios orientados a búsqueda, incluye estos requisitos en el prompt, en la arquitectura y en la lista de QA. ### Usa SSR, SSG o prerendering Para contenido que debe posicionar, prefiere: - **SSR** para páginas dinámicas que necesitan datos frescos - **SSG** para páginas de marketing y documentación estables - **prerendering** para rutas de JavaScript que, de otro modo, se publicarían con HTML “fino” (thin) Frameworks como Next.js, Nuxt y stacks similares con capacidad de servidor suelen ser un punto de partida más seguro que configuraciones puramente del lado del cliente. “Más seguro” es la palabra correcta aquí: no garantizan por sí mismos un SEO sólido, pero facilitan producir una salida de buena calidad. ### Genera metadatos únicos por URL Cada página importante debe tener sus propios: - title tag - meta description - URL canónica (canonical URL) - etiquetas sociales, como Open Graph, cuando aplique Si el sitio tiene plantillas, haz que la IA genere reglas de metadatos conectadas al contenido por ruta (route-level content). ### Publica sitemaps XML y mantenlos actualizados Un sitio con vibe coding debería crear y actualizar automáticamente sitemaps XML a medida que cambian las rutas. Esto es especialmente útil para MVPs que evolucionan rápido, donde las páginas se agregan con rapidez. ### Mantén enlaces rastreables Usa enlaces ancla estándar de HTML para la navegación siempre que sea posible. Evita depender por completo de clics en botones y manejadores de JavaScript para rutas importantes de descubrimiento. ### Agrega datos estructurados cuando corresponda Si la página representa claramente un artículo, producto, aplicación de software, organización, FAQ o una ruta de breadcrumb, los datos estructurados pueden ayudar a los motores de búsqueda a interpretar la página de forma más consistente. Schema.org es el vocabulario de referencia más común. ### Prueba HTML renderizado y HTML en bruto No confíes solo en el navegador. Compara: - lo que ven los usuarios - lo que muestra “ver código fuente” (view source) - lo que reportan herramientas de inspección enfocadas en búsqueda Si el origen (source) está mayormente vacío pero el navegador se ve completo, es una señal para revisar la estrategia de renderizado. No es prueba de que la página vaya a fallar, pero sí indica que debes verificar en lugar de asumir. Un hábito práctico que recomiendo es tratar “ver código fuente” como parte del check de lanzamiento, no como una tarea solo para especialistas. No necesitas leer cada línea de código. Solo necesitas confirmar que el contenido importante de la página y los metadatos están presentes de forma razonable. ## Un workflow práctico de vibe coding para fundadores y equipos de SEO Un workflow útil es: 1. **Define el objetivo en lenguaje claro.** Ejemplo: “Crear una landing page y un panel de app para una herramienta de auditoría de contenido SEO.” 2. **Especifica requisitos de SEO en el mismo prompt.** Ejemplo: “Usar SSR, metadatos por ruta, tags canonicals, sitemap XML, robots.txt y HTML semántico.” 3. **Elige un framework preparado para SEO.** Pídele a la IA que use uno que soporte renderizado del lado del servidor o generación estática. 4. **Revisa el código generado por arquitectura, no solo por apariencia.** Las demos rápidas pueden ocultar renderizado débil. 5. **Valida la salida con documentación de búsqueda y herramientas de inspección.** La documentación de Google Search Central es un punto de referencia principal para muchas preguntas de implementación. 6. **Publica, monitorea e itera.** Observa rastreabilidad, indexación, snippets y comportamiento de página. Este workflow mantiene la ventaja de velocidad del vibe coding mientras reduce el modo de fallo común de “se ve bien para humanos, pero no queda claro para la búsqueda”. ## Cuándo el vibe coding funciona mejor El vibe coding es especialmente efectivo cuando: - el alcance del producto es limitado - el equipo necesita un prototipo rápidamente - las páginas siguen plantillas repetibles - quien construye puede revisar prompts y outputs con criterio crítico - los requisitos de SEO se conocen desde temprano Es menos fiable cuando los equipos asumen que el código generado por IA está listo para producción por defecto. La autenticación compleja, la seguridad, el rendimiento y una arquitectura de información a gran escala todavía requieren revisión experta. El caso de uso más sólido, en mi opinión, no es reemplazar la ingeniería. Es acortar el camino hacia una versión testeable, manteniendo a un revisor experimentado en el circuito para cualquier cosa pública, escalable o dependiente de SEO. ## Vibe coding vs desarrollo tradicional El desarrollo tradicional normalmente empieza con arquitectura, especificaciones e implementación manual. El vibe coding empieza más cerca de la **intención y la iteración**. Eso lo hace potente para descubrimiento y MVPs. Pero la velocidad puede desplazar el riesgo hacia etapas posteriores si los equipos omiten la estrategia de renderizado, accesibilidad, pruebas y requisitos de búsqueda. Una forma justa de verlo es esta: el vibe coding puede comprimir el tiempo de desarrollo, pero **no elimina la necesidad de tomar decisiones técnicas**. Solo cambia cuándo y cómo aparecen esas decisiones. ## Conclusión SEO La lección específica para SEO es simple: **una app con vibe coding puede posicionar, pero el posicionamiento depende de la salida, no de que la IA haya ayudado a construirla**. Si tu herramienta de IA crea un SPA cargado del lado del cliente, trata SSR, prerendering, metadatos, datos estructurados y sitemaps como requisitos centrales del producto, en lugar de “detalles” opcionales. Así que la mejor definición para tener en mente es: el vibe coding es una forma rápida de construir software a partir de prompts y, para experiencias orientadas a SEO, el éxito normalmente depende de combinar esa velocidad con **contenido renderizado en el servidor (o de otra forma indexable), metadatos claros y una estructura del sitio rastreable**. Si haces eso, el vibe coding se convierte en una herramienta práctica de crecimiento en lugar de un riesgo de SEO evitable.