Vibe coding is what happens when someone opens a chat with an AI on a Tuesday afternoon, types "build me a website for my company" and by teatime already has something live. No developer, no ticket, no waiting for the next sprint. Wonderful (I mean it).
Now, my take after several audits is less romantic: vibe coding makes it easier to build a website and it also makes it easier to break the SEO of one that already works. It reinvents rules that CMSs had already solved, like URLs, canonicals, redirects or the sitemap, and very often nobody reviews the code that generates them. In this guide I explain what it is, how it works, which tools people use and what I would check before letting a site built this way replace the one that already brings you customers.
What is vibe coding?
Vibe coding is a way of creating software where you describe what you want in natural language and the AI (one of the language models that also power ChatGPT) writes the code for you. You say "I want a page with a contact form that sends me an email", look at what came out, ask for changes and look again.
The difference from pasting a question into ChatGPT and copying the answer is context. In vibe coding, the artificial intelligence has access to the whole project: it can edit several files at once, run the code, see whether it works and fix itself. You barely see the code. You see the result on screen and judge it by how it looks.
That is exactly what makes it so attractive to marketing teams, founders and anyone who has ever waited three weeks to change a button. And it is also the part that worries me when what you are building is a website that Google has to crawl, understand and index (because Google does not look at the site the way you see it on your screen).
Where does the term come from?
The name comes from Andrej Karpathy, former OpenAI researcher and former head of AI at Tesla, in February 2025. In a post on X he described a way of making software where you "fully give in to the vibes" and forget that the code even exists.
The term spread fast. In November 2025 Collins Dictionary picked "vibe coding" as its word of the year for 2025.
How does vibe coding work in practice?
A typical vibe coding workflow has four steps that repeat in a loop, and I would add a fifth one that tutorials tend to skip:
- Describe the goal. You write a prompt with the result you want, not with the code: "a landing page for our audit service with three sections and a form".
- Generate and review. The tool generates the code and shows you a preview. You don't need to read it, you need to decide whether what you see does what you asked for.
- Iterate in natural language. "The title is too big", "add a FAQ section", "change the button color". Every tweak is a new prompt.
- Fix errors. When something breaks, you copy the error message, paste it to the AI and ask it to fix it. It often solves it on its own. When it doesn't, you find out who has technical judgment and who doesn't.
- Publish. Hitting the publish button is where the part Google cares about begins: what HTML a crawler receives, which URLs exist, where the links point. That step hardly ever shows up in the loop, and it is the one I end up reviewing the most.
The loop is fun and addictive. The problem is that every iteration can change things you were not looking at. You ask it to change a title and the AI rewrites the whole template, canonical tag included.
Which vibe coding tools are most used?
There are tools for very different profiles. Some are built for people who have never made software and others for developers who want to go faster. For a website, the question I would add to the comparison is how each one publishes, because that decides what Google sees.
| Tool | Best for | What I would check for SEO |
|---|---|---|
| Lovable | Full apps and websites with a database, from the browser | Whether the project renders on the server or in the browser (it depends on when it was created) |
| Bolt | Full-stack prototypes from the browser | What HTML arrives before JavaScript runs |
| Replit | Prototypes, scripts and apps in a browser environment | Domain, redirects and test URLs that went live |
| v0 (Vercel) | Web interfaces and components from a description | That links are real links and not buttons |
| Cursor | AI code editor for people who already code | The same as any development: review before publishing |
| Claude and ChatGPT | Generating and iterating code by chatting | That whatever gets pasted into the site does not duplicate tags |
Copilot and Windsurf round out the group of AI editors.
What are the advantages and risks of vibe coding?
The advantages are real, which is why the term became so popular. So are the problems, and most guides boil them down to security and code quality.
| Advantages | What to watch |
|---|---|
| Prototypes in hours instead of weeks | Hidden bugs that show up as the project grows |
| People without technical training can build their own solutions | Security: validations and data handling nobody reviewed |
| Less repetitive code for developers | Technical debt: patches on patches, hard to maintain |
| Testing ideas before investing in development | Loss of control: nobody really knows what each part does |
Security is the best known one. An app that handles personal data, payments or access needs someone to review the generated code before putting it into production. Quality problems show up later: as the project grows, the AI loses coherence, adds a feature that breaks another one and contradicts earlier decisions. What worked with 200 lines becomes fragile with 2,000.
There is a case that went around a lot in 2025: a founder posted on X that his SaaS was built with Cursor "with zero handwritten code". Days later he wrote that users were bypassing the subscription and that he could not fix it because he was not technical. He ended up shutting the app down.
What guides don't usually mention is a third risk, a quieter one: the organic channel. A security bug gets noticed fast. A site that the search engine understands worse gets noticed when traffic has already dropped, and that can take months.
How is it different from traditional programming?
In traditional software development you write every line in a programming language and you understand what it does. In vibe coding you chat, and the AI decides how to implement it. You gain speed and accessibility. You lose control over quality and, above all, the ability to explain why something works.
Addy Osmani, an engineer on Google Chrome, summed it up in what he called the 70% problem: AI helps experienced developers more than beginners, because they know when to correct what the AI suggests. AI speeds things up, but what keeps code maintainable is the judgment of whoever reviews it.
With SEO the same thing happens to a website. If someone on the team knows what a canonical is, vibe coding is a fantastic accelerator. If nobody does, the AI makes the technical decisions and nobody reviews them before publishing.
What can vibe coding do to your site's SEO?
Changing a page's URL used to go through a developer, someone who knew the CMS and, with luck, someone from SEO. Now a prompt is enough. That is good for speed and a real risk for a site that already ranks.
When I audit sites built or rebuilt prompt by prompt, these are the problems that come up most often:
- Content that does not render for crawlers. The page looks perfect in the browser, but the initial HTML is nearly empty and everything depends on JavaScript.
- Duplicate or contradictory canonicals. I have seen the canonical tag repeated 18 times on a single page, each one pointing to a different URL.
- Links to staging URLs or to old versions left in the code.
- URLs nobody knew existed, generated by the platform, and old URLs deleted without a redirect.
- Hreflang tags that don't match across languages or countries.
- A sitemap that does not reflect the real site.
Google's JavaScript documentation explains why this matters. Googlebot only discovers links that are <a> elements with an href attribute, so a button that navigates with JavaScript can leave pages undiscovered. Google recommends server-side rendering or pre-rendering because not every bot runs JavaScript (an analysis by Vercel from December 2024 found that the main AI crawlers, like GPTBot and ClaudeBot, don't execute it). And if the canonical is injected with JavaScript, it has to be the only one on the page: two contradictory tags give results nobody controls.
The good news is that the tools are fixing part of this. According to its own documentation, Lovable projects created since May 13, 2026 render pages on the server. Older ones render in the browser, and Lovable serves pre-rendered copies to verified search engines and AI crawlers. In other words, the same platform behaves differently depending on when your project started, and it is worth knowing which one you are on.
Technical SEO has known these problems for years. With vibe coding they show up faster, and very often the person who made the change has no way of seeing them. If your site already gets organic traffic, a redesign with vibe coding is a migration, and it should be treated as one. Here is this checklist to redesign a website without destroying your rankings as a starting point.
When should you use vibe coding and when not?
I would use it without fear for:
- Prototypes and proofs of concept before investing in development.
- Internal tools: calculators, dashboards with business data, forms for the team.
- Campaign landing pages that do not depend on organic traffic.
- New sites, as long as someone reviews the technical side before publishing.
And I would think twice for:
- Rebuilding a site that already brings organic traffic and customers, without a URL map.
- Production projects with sensitive data, payments or security requirements.
- Large sites with thousands of URLs, filters or several countries.
Disclosure: this site is built on a vibe coding platform. I love the speed, and that is exactly why I think the technical review before publishing is the part you should not skip.
How do you review a vibe coded site before publishing it?
None of these steps requires knowing how to code. They take an afternoon and some method:
- List what works today. Export from Search Console the data for pages with clicks over the last 16 months (that is all it keeps) and add the URLs that have links from other sites. That is the list of what you cannot lose.
- Map every old URL to its new URL, one by one, before publishing. Anything that changes address gets a 301 redirect. In this guide on migrations and SEO (in Spanish) I explain how to size the risk.
- Look at the HTML that arrives, not the page you see. Open the page source (not the inspector) and look for the title, the main text and the links. If they are not there, a crawler does not see them either.
- Count the canonicals. Search for "canonical" in the source code of your main templates. There should be one per page and it should point to the right URL.
- Check links and the sitemap. Make sure the menu uses real links, that no staging URLs are left and that the sitemap has the URLs you want indexed.
- Use Search Console's URL inspection on your most important pages after publishing, to see the version Google rendered. If something is missing, check how to index a page on Google and what is failing.
On large sites I would add a log review to see which URLs Googlebot is actually visiting, because URLs generated by accident tend to eat up crawling (more on that in crawl budget).
Frequently asked questions about vibe coding
Is vibe coding bad for SEO? Not by definition. A vibe coded site can rank well if the HTML Google receives includes the content, links are real links and URLs, canonicals and redirects are under control. The problem appears when nobody reviews those decisions.
Can Google read a site built with Lovable? It depends on when the project was created. According to Lovable's documentation, new projects render on the server and older ones serve pre-rendered copies to verified search engines. The way to find out is Search Console's URL inspection.
Do I need to know how to code to do vibe coding? To build a prototype, no. To publish something with real users, data or organic traffic, it is worth having someone with technical judgment review the code first, even if they did not write it.
If you are about to publish something built with vibe coding, my recommendation is to block an afternoon before hitting the button: the list of URLs that bring clicks today, the redirect map and a look at the source code of your three main templates. It is a small amount of time compared with what it costs to recover a site the search engine stopped understanding. And if you want to start with the basics, how to create a website step by step covers what cannot be missing from day one.