SEO Vibes

Diagnostics

Why Your Vibe-Coded Website Is Not Showing Up on Google

It loads, it looks great, you can send the link to anyone. So why can't Google find it? Because being on the internet and being findable in search are two different technical achievements.

By SEO Vibes9 min read

You shipped a real website. It loads instantly, it looks right on a phone, and you can send the link to anyone. So it is genuinely confusing when, weeks later, searching your own business name barely turns it up — and searching what you actually sell turns up everyone except you.

The reason is almost never “Google hasn’t gotten to it yet.” It is that being on the internet and being findable in search are two different technical achievements, and the tools that made the first one easy do not automatically deliver the second. To fix it you first have to know which of four separate things is failing.

Four stages, not one “SEO”

“Showing up on Google” is the end of a pipeline with four distinct stages. They fail independently, they fail for different reasons, and the fixes are unrelated. Collapsing them into a single idea called “SEO” is the first mistake.

  • Discovery — Google has to learn that a URL exists at all, usually by following a link or reading your sitemap.
  • Crawling — its crawler has to be allowed to request that URL and receive a normal response, not a block or an error.
  • Indexing — Google has to render the page, understand its content, and decide the page is worth storing in its index.
  • Ranking — only then does it weigh your page against every competitor for a given search.

A page can be perfectly discovered and crawled and still never be indexed. A page can be indexed and still rank on page nine. Most people reach for ranking tactics — keywords, content, backlinks — while their actual failure is two stages earlier, at crawling or indexing, where no amount of content will help.

The path to a search result

Your page can fall out at any node

Every page that ranks completed all four stages. A vibe-coded site usually breaks at one of the first three — long before ranking is even on the table.

  1. Discovery
    A link or sitemap tells Google the URL exists. No path in → never discovered.
  2. Crawling
    Googlebot requests the URL. robots.txt blocks or server errors stop it here.
  3. Rendering
    Google runs the page. If content only appears after JavaScript, it may see an empty shell.
  4. Indexing
    The rendered content is understood and stored — unless a noindex or canonical says don't.
  5. Ranking
    Only now does content quality, relevance, and authority decide position.

Diagnose left to right. A ranking problem you fix before an access problem is wasted work.

Where vibe-coded sites actually break

AI builders like Lovable, Replit, Bolt, and v0 produce excellent front-end applications. But the default output of a modern JavaScript app is optimized for a person with a browser, not for a crawler — and that gap shows up at predictable places.

Rendering: the empty-shell problem

Many AI-generated sites are single-page apps. The server sends a nearly empty HTML document and the browser builds the visible page afterward by running JavaScript. A human never notices. But if a crawler reads the initial HTML and finds only a bare mount point, the page’s real content is invisible at the moment that matters most:

<!-- What the crawler receives first -->
<body>
  <div id="root"></div>
  <script src="/assets/app.js"></script>
</body>

<!-- What a human sees a second later, after JS runs -->
<h1>Handmade oak dining tables — built to order</h1>
<p>Delivered across the country in 4–6 weeks…</p>

Google can execute JavaScript, but it does so on its own schedule and not always completely. Depending on server-side rendering to fill that gap is the single most important rendering decision a site makes — and on some platforms it depends on which plan you are on or when the project was created. That is exactly what our platform pages exist to pin down.

Crawlability: blocks you didn’t know were on

A single stray directive can wall off an entire site. A robots.txt that disallows everything, or a leftover noindex tag from a staging template, will keep even a flawless page out of the index entirely:

# robots.txt that blocks the whole site
User-agent: *
Disallow: /

<!-- or, in the page <head> -->
<meta name="robots" content="noindex" />

Discovery: no sitemap, no internal links

If your pages are not linked to one another and there is no sitemap.xml, Google may never find anything past your home page. Interactive navigation that only works through JavaScript click-handlers — rather than real <a href> links — can leave whole sections effectively invisible, a pattern often called orphaned pages.

Indexation signals: canonical and duplicates

A canonical tag tells Google which URL is the real one. When a template hardcodes a single canonical across every page, or points it at a preview domain, you can quietly instruct Google to ignore most of your site. Duplicated boilerplate across many thin pages produces the same effect from the other direction.

Content and authority: real but later

Thin, generic, or templated copy and a brand-new domain with no references from elsewhere both genuinely limit how you rank. But they are ranking problems — they only matter once the page is reliably crawled and indexed. Fixing content while the page renders as an empty shell changes nothing a crawler can see.

Common failure patterns

What we actually find on AI-built sites

These are the recurring reasons a good-looking site stays invisible — ordered the way we check them, from access outward.

Content only exists after JavaScript runs

The initial HTML is a shell. Rendering-dependent content may be indexed late, partially, or not at all. This is a rendering problem, not a content one.

Needs attention
A site-wide block is in place

A Disallow: / in robots.txt or a leftover noindex tag keeps the page out of the index no matter how good it is.

Not detected
No sitemap and no crawlable internal links

Pages beyond the home page are never discovered. JS-only navigation without real <a href> links produces orphaned pages.

Not detected
Canonical points at the wrong URL

A hardcoded or preview-domain canonical tells Google to ignore the page it is on. One template mistake can affect the whole site.

Needs attention
Titles and descriptions are defaults

Every page shares one generic title, or has none. Google can index it, but it competes badly and looks untrustworthy in results.

Needs attention
Content is thin or generic

A real ranking limiter — but only once the page is crawled and indexed. Worth fixing after access is confirmed, not before.

Could not verify

Diagnose in the right order

The order matters as much as the checklist. Work from access outward, because an earlier failure makes every later signal meaningless:

  1. Can it be reached? Response status, redirects, robots.txt, and robots meta tags.
  2. Can it be rendered? Does the real content exist in the HTML a crawler receives, or only after JavaScript?
  3. Can it be indexed cleanly? Canonical, sitemap, titles, descriptions, and duplication.
  4. Can it be found and preferred? Internal links, content depth, and authority.

That order is why a “we need more blog posts” instinct so often fails: it is a step-four fix for a step-two problem.

That first check is exactly what our free visibility scan performs — it reads a public page the way a search engine does and reports what is and isn’t there, with no score and no email gate. When the fix belongs in the codebase rather than in a report, that is what Search Foundation is for.

Keep reading

Related reading and next steps

See it on your own site

Run a free visibility scan

This article explains what search engines need. The scan shows you which of those things your own public page actually delivers today — no score, no email gate.

Run a free visibility scan

This is a narrow technical scan of the public page response. It does not measure rankings, content quality, backlinks, Google index coverage, or business opportunity.