Vibe Coding and SEO: What Google’s John Mueller Just Confirmed
Vibe coding and SEO have a problem with each other, and on Search Off the Record episode 110, Google’s John Mueller and Martin Splitt finally said it out loud. Sites built by AI tools like Lovable, Bolt.new, v0, Cursor, and Replit AI Studio look great in the editor, ship in days, and routinely fail at the basics of being found on Google. The hosts didn’t say “vibe coded sites can’t rank.” They said something more useful: here are the specific failure modes, here’s why they happen, and here’s what you’d have to tell the AI to avoid them.
Reddit has been saying the same thing in plainer language for months. Threads in r/SEO and r/SaaS from r/EntrepreneurRideAlong-style founders are full of “I built my site on Lovable and Google won’t index it.” This post lines Mueller’s quotes up against what real users are reporting and gives you a concrete fix list.
Key Takeaways
- Mueller said adding SEO via prompt produces “sprinkle some meta tags” output and named the actual technical work that has to happen instead
- Real users on r/SEO report Lovable and v0 sites shipping with an empty HTML shell that crawlers see as
<div id="root"></div>and a script tag - AI-assisted commits leak secrets at roughly twice the human rate, with hardcoded Stripe and OpenAI keys showing up in deployed code rather than environment variables
- The fix is mostly about what you say to the AI before it builds, not what you say after, and a vendor-neutral pre-submit prompt closes most of the gap
What Mueller Actually Said in SOTR 110
Two specific things Mueller said matter most for anyone using a vibe coding tool to build a site they need to rank.
The first is about the “add SEO” prompt. Mueller’s reaction was, in his words, “sprinkle some meta tags and add some structured data?” He said this in the same tone you’d use describing a bad waiter. The point landed: telling an AI to “make it SEO friendly” is a meaningless instruction. The AI has no way to translate that into the technical work that actually has to happen.
The second is what the technical work actually is. Mueller listed it concretely: pages should return content, JavaScript files should not be blocked by robots.txt, the robots.txt itself should be useful rather than copy-pasted, canonical tags should be set, a sitemap should exist, and the build should have pre-submit checks before going live. Splitt added the underlying point: you have to know enough technically to tell the AI what to do, because the AI defaults will not get you there.
That’s the gap. Vibe coding tools optimize for “the site looks good in the browser.” Search engines optimize for something else.
The Empty Shell Problem
The biggest SEO failure of vibe-coded sites is the simplest to describe: the page Google fetches contains nothing. The HTML is a shell that loads JavaScript, and the JavaScript builds the actual content in the browser. Google has a second rendering pass that can sometimes execute the JavaScript, but it’s slow, inconsistent, and other crawlers (Bing, GPTBot, ClaudeBot, PerplexityBot) often don’t run JavaScript at all.
A user testing this on r/SEO summed it up exactly:
I quickly realized everything runs on client-side rendered React. The HTML shell Google receives is basically just
u/Cool-Treat-296, r/SEO, April 2026<div id='root'></div>and a script tag.
That’s not a fringe complaint. The same thread had a top response saying Lovable rankings are “Possible? Yes. Out of the box? Nope,” noting Googlebot’s two-pass rendering “only happens 1 or 2% of the times unless your authority is off the roof.” Another commenter summarized what they keep seeing: “I’ve seen lovable, bubble and react sites where google would only index the home page.”
The most direct version came from a self-described SEO lead at two B2B startups testing the platforms:
It really blows me away how much people talk about the other aspects (meta data, sitemaps, etc.) when Google can’t even see their sites.
u/Unlikely_Mud3771, r/SEO, September 2025
This is what Mueller meant by “sprinkle some meta tags.” Tools and prompts that target meta description, schema, and sitemap are doing real work, but it’s the wrong layer. If the page itself returns no content, none of the rest matters.
Lovable shipped server-side rendering for new projects via TanStack Start on April 20, 2026, which closes part of this gap for sites built after that date. Bolt, v0, and most Replit AI Studio outputs still default to single-page apps. I covered the broader citation mechanics in How to Get Cited by ChatGPT and the indexing implications in the Google AI Mode SEO guide.
“Add Some SEO” Doesn’t Work as a Prompt
The next failure pattern is what happens when users do try to fix the problem after the fact. They prompt the AI with something like “make this SEO friendly” or “add server-side rendering.” Mueller’s mockery of this prompt matches what real users find when they try it.
I tried a few things to fix this, such as brute force prompting it to do SSR or SSG which didn’t work for me. I also tried using Claude code to fix it but still nothing.
u/reeceward, r/SEO, October 2025
The AI cannot retrofit a fundamentally different rendering architecture from a vague prompt. Switching a client-side React app to server-side rendering means changing the framework, the build pipeline, the deploy target, and most of the routing layer. That’s a rebuild, not a tweak. The AI will often pretend to do it (“Done! Your site now uses SSR.”) without actually doing it. Users only catch this when they re-test their indexed page count and see no change.
The fix has to happen before the build, not after. Mueller’s exact framing: “if you have the technical understanding, you can guide it from the beginning.” I pulled that into a concrete prompt template below.
The API Key and Secrets Problem
Both Mueller and Splitt mentioned this in passing on the podcast. The problem is bigger than they let on. GitGuardian’s 2026 State of Secrets Sprawl Report found 28.6 million new secrets exposed in public GitHub commits across 2025, a 34% year-over-year jump. Within that, AI-assisted commits leak secrets at about 3.2%, compared to 1.6% for human-only commits. Roughly double. Of secrets first detected in 2022, 64% were still active and unrevoked three years later.
The reason matters. AI builders abstract environment variables in a way that makes the underlying secret handling invisible to non-technical founders. A consultant who migrates Lovable projects to other infrastructure described what he keeps finding:
Lovable abstracts env vars so well that founders never learn where secrets actually live. I always find hardcoded Stripe keys, OpenAI tokens, or Supabase anon keys buried in Edge Function code. Not in .env files. In the actual deployed code.
u/Affectionate-Olive80, r/SaaS, April 2026
The same thread surfaced a related point: even when secrets are not hardcoded, they end up in logs. A widely-upvoted r/SaaS post about healthtech apps put it bluntly:
Bolt and Lovable and Cursor all generate code that logs request bodies by default. Your Sentry dashboard is capturing every error with the full payload attached. I’ve pulled social security numbers and diagnoses out of a client’s Sentry within ten minutes of starting an engagement.
u/Warm-Reaction-456, r/SaaS, April 2026 (38 upvotes)
The SEO connection here isn’t direct ranking damage. It’s the click-economy version: if your vibe-coded site leaks customer data and gets a public incident attached to your brand, the trust signals AI search relies on (reviews, brand sentiment, citations) all turn against you. Earned trust is harder to rebuild than rankings.
The Pre-Submit Prompt for AI-Built Sites
Mueller’s actionable advice, distilled, is to tell the AI what you want the site to do at the technical level before it generates anything. Most builders only specify the look and the pages. He said add the SEO and security requirements to the same instruction.
This is a vendor-neutral version of that prompt, anchored on the items Mueller named in SOTR 110. Use it as the first message you send to Lovable, Bolt, v0, Cursor, Claude Code, or Gemini CLI. Edit the bracketed parts.
Build a site for [business] with these pages: [list].
Render mode: server-side rendering (SSR) or static site generation (SSG).
Do not use a single-page app architecture. Each route must return
fully-rendered HTML to a non-JavaScript request.
SEO foundations to bake in from the first build:
- Unique title and meta description per page, derived from the page content
- Canonical tag on every page pointing to its own URL
- Open Graph and Twitter card tags
- JSON-LD structured data (Organization on the homepage, Article on
any blog post, Product on any product page)
- robots.txt that allows crawling and lists the sitemap URL
- Do not block JavaScript, CSS, or image files in robots.txt
- A sitemap.xml that updates automatically when pages are added
- Semantic HTML: a single h1 per page, real h2/h3 hierarchy, a real
nav element, real links not buttons-styled-as-links
Secrets handling:
- Read all API keys, tokens, and credentials from environment
variables. Never inline a key in source.
- Add a .env.example with every required variable name listed.
- Refuse to commit any file matching .env*.
Pre-submit checks before the site is considered ready to publish:
- Every URL in the sitemap returns HTTP 200
- The non-JavaScript HTML for the homepage contains the page's
visible text
- The robots.txt resolves and is not blocking critical assets
- No hardcoded API keys exist anywhere in the source
Tech preferences: [Next.js / Astro / Hugo / SvelteKit].
Hosting target: [Vercel / Netlify / Cloudflare Pages / Firebase].Two specifics worth flagging. The “do not use a single-page app architecture” line is the most important sentence in the whole prompt. Without it, every major vibe coding tool will default to client-side React. Static site generators like Hugo and Astro and frameworks like Next.js with SSR are not harder for the AI to produce than a SPA, but they are not the default.
The second is the pre-submit checklist at the bottom. Mueller called this out specifically: “before publishing, make sure that these URLs all return content. Make sure that, I don’t know, none of the JavaScript files are blocked by robots.txt.” That’s a build-time validation step, not a runtime hope.
If Your Vibe-Coded Site Is Already Live and Tanking
Most readers landing here probably already shipped. The first call to make is whether to migrate, prerender, or rebuild.
Migrate to SSR or SSG. If your site was built on Lovable after April 2026, check whether it’s already on TanStack Start with SSR. If yes, the rendering problem is solved at the platform level and you only need the foundations work. If your site is on Bolt, v0, or pre-April Lovable, you can export to GitHub and rebuild the same UI in Next.js or Astro. The AI can do most of the export-and-rewrite work if you give it the framework target. One r/SEO user described the path:
Built the site to my liking on lovable. Connected to github. Exported to vercel. Now the code is yours, and any changes made in lovable will change the code inside vercel also. As you can see alot of hoops to jump through.
u/JonnyBlanka, r/SEO, April 2026
Prerender. Tools like prerender.io and LovableHTML serve a static, crawler-friendly version of your pages to Googlebot and other bots while keeping the SPA experience for human visitors. This is the lowest-friction option but the highest ongoing cost. Reasonable as a stopgap while you plan a rebuild, less reasonable as a permanent strategy.
Rebuild from scratch. The right answer when the site is small (under 20 pages), the SEO depends on it, and the original Lovable/Bolt UI was generic enough that a fresh build won’t lose anything emotional. WordPress, Hugo, or Astro all work for this. For a content site you can have a clean rebuild done in a weekend with the prompt above.
Whichever path you pick, run the four-question diagnostic first. Open your site’s URL in a private window with JavaScript disabled. Does the visible content render? Open Google Search Console’s URL Inspector on three of your top pages. Are they indexed? Run a curl against your homepage with a non-Googlebot user agent. Is it returning real HTML or an empty shell? Search your repo for “sk_live”, “sk-“, “AKIA”, or “Bearer ” strings. Are any keys hardcoded? The combination of those four answers tells you which path is right.
FAQ
Sources & References
- Google Search Relations (2026). “Search Off the Record episode 110: Vibe Coding, Yay or Nay.” https://www.youtube.com/watch?v=SPVA6FNX2rw
- GitGuardian (2026). “State of Secrets Sprawl Report 2026.” https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/
- Truffle Security (2025). “Research finds 12,000 ‘Live’ API Keys and Passwords in DeepSeek’s Training Data.” https://trufflesecurity.com/blog/research-finds-12-000-live-api-keys-and-passwords-in-deepseek-s-training-data
- Wiz (2026). “Hacking Moltbook: AI Social Network Reveals 1.5M API Keys.” https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
- u/Cool-Treat-296 (2026). “Does a Lovable-built site actually rank on Google?” r/SEO. https://www.reddit.com/r/SEO/comments/1sfuh9a/
- u/Unlikely_Mud3771 (2025). “Passable vibe coding apps for a seo-oriented website?” r/SEO. https://www.reddit.com/r/SEO/comments/1nlphpd/
- u/reeceward (2025). “SEO & Vibe Coding problem.” r/SEO. https://www.reddit.com/r/SEO/comments/1ojmdig/
- u/Affectionate-Olive80 (2026). “After migrating MANY Lovable projects to self-hosted Supabase.” r/SaaS. https://www.reddit.com/r/SaaS/comments/1sfwhs1/
- u/Warm-Reaction-456 (2026). “Why your Lovable/Bolt MVP will get you sued in healthcare.” r/SaaS. https://www.reddit.com/r/SaaS/comments/1sue9e4/
- Lovable (2026). “Server-Side Rendering on TanStack Start changelog entry, April 20, 2026.” https://docs.lovable.dev/
See what ChatGPT is really searching
SubSeed captures the hidden Google queries ChatGPT runs behind every answer and enriches them with search volume, CPC, and keyword difficulty.
