NotVibesCoded logo

Your vibe-coded site is not indexed. Here is how to find out why.

A new AI-built site can be live, fast and completely invisible to Google. Work through this checklist in order: access, sitemap, canonicals, content, and patience, in that order.

By NotVibesCoded Editorial TeamPublished 6 min read

Your site is live. You can open it in a browser, it loads, it looks finished, and Google acts as if it does not exist. Search for your domain and nothing comes up. Search for a sentence from your homepage and nothing comes up. This is the most common invisible failure of a vibe-coded site, and it is usually fixable in an afternoon, once you stop guessing and check in the right order.

First, understand what "not indexed" actually means

Indexing is not the same as ranking, and it is not the same as being live. A page is indexed when Google has crawled it, understood it, and stored it in a way that lets it appear in results. A page can be live and unindexed, indexed and ranking on page ten, or indexed and ranking well. If your site is new, the most likely story is simpler than you fear: Google has not finished processing it yet. New properties routinely show "Processing data" in Search Console for days, and that is not an error, it is a queue.

Before changing anything, check whether Google knows about the site at all. Open Google Search Console, pick your property, and look at the Performance report. If it shows impressions, even a handful, Google is finding pages. If it shows nothing, and the Pages report says it is still processing data, wait a day and check again before rebuilding anything. Changing URLs, titles and structure while Google is still processing the first version only restarts the clock.

Step 1: can Google reach the site at all?

The fastest check is the robots.txt file. Open yourdomain.com/robots.txt in a browser. If it disallows everything, or disallows the pages you care about, that is your answer, and it is a common vibe-coding accident: a template, a staging configuration or an AI-generated file that blocks crawlers, shipped to production unchanged.

Also check for a noindex tag. Open a page, view its source, and search for "noindex". A noindex meta tag, or an X-Robots-Tag header sending noindex, tells Google to crawl the page and then throw it away. Staging sites use noindex on purpose. Production sites inherit it by accident when the staging configuration is copied over. Remove it from production, and only from production.

If robots.txt and noindex are clean, check that the site actually returns a 200 status for its pages, not a redirect loop, a 404, or a JavaScript-only shell with no content in the HTML. Google renders JavaScript, but a page that only becomes content after a long client-side load is slower to index and easier to misread than a page that ships its content in the HTML.

Step 2: is there a sitemap, and does it match reality?

A sitemap is a list of the pages you want indexed, submitted to Search Console. It does not guarantee indexing, but a missing, stale or wrong sitemap makes Google's job harder, especially for a new site with no links pointing at it.

Check three things. First, that a sitemap exists at yourdomain.com/sitemap.xml and loads without errors. Second, that it was submitted in Search Console and shows a Success status with a recent last-read date. Third, that the URLs in it are the real, canonical URLs: the same host, the same www or non-www choice, the same trailing-slash behaviour as the live pages. A sitemap full of redirected or duplicate URLs teaches Google to distrust it.

If you have both a www and a non-www sitemap, pick one canonical host and stick to it everywhere: canonical tags, sitemap, internal links and the sitemap submitted in Search Console. Mixed canonicals split a new site's authority across two versions of itself before it has any authority to split.

Step 3: are your pages worth indexing?

Google indexes pages it thinks are useful and distinct. A vibe-coded site often fails this test in specific, fixable ways: dozens of near-identical pages generated from a template, thin pages with a paragraph of generic text, or pages that exist only to hold a link or a form. None of these are punished as a site, but none of them are indexed eagerly either.

For each page you want indexed, ask three questions. Does it say something a visitor cannot get from your other pages? Does it have a real title that describes its content, under 60 characters, rather than a brand name repeated on every page? Does it have a meta description that describes the page, rather than a missing or duplicated one? Fix the pages that fail, starting with the ones that already get impressions in Search Console, because Google is already showing interest in those.

Internal linking matters here too. A page with no links pointing at it from your own site is an orphan, and orphans are indexed last, if at all. Every important page should be reachable from your homepage or a main navigation section in a small number of clicks, not only from a sitemap.

Step 4: ask Google to look, then leave it alone

Once access, sitemap, canonicals and content are clean, use Search Console to request indexing on your homepage and a few key pages. This is a request, not a command, and it does not work instantly. After requesting, the unhelpful-sounding advice is the correct one: leave the URLs alone. Changing a URL, a title or a slug after requesting indexing sends Google back to the start for that page.

New domains take time. One to four weeks for proper indexing is normal, and the first impressions often arrive before the first clicks, in the form of low-position appearances for very specific queries. That is progress, not failure. A page appearing at position 40 for an exact phrase is indexed. Ranking it higher is a separate job, and it starts with the content and internal links, not with more indexing requests.

The checklist, in order

  1. Confirm the problem in Search Console, and check whether the Pages report is still processing before changing anything.
  2. Check robots.txt for a blanket block, and check pages for a noindex tag or header.
  3. Confirm pages return 200 and ship their content in the HTML.
  4. Confirm a sitemap exists, is submitted, shows Success, and lists only real canonical URLs.
  5. Fix thin, duplicated and orphaned pages, starting with pages that already get impressions.
  6. Give every page a distinct title under 60 characters and a real meta description.
  7. Request indexing on the homepage and key pages, then stop changing their URLs.
  8. Wait. Check weekly, not hourly, and judge by impressions first, clicks second.

A vibe-coded site is not indexed because it is AI-built. It is unindexed because access is blocked, the sitemap is wrong, the pages are thin, or Google simply has not finished yet. Those are four different problems with four different fixes, and the checklist above tells you which one you have before you start fixing the wrong one.

Share this article

Newsletter

The NotVibesCoded Weekly

One email a week: the newest articles, project teardowns and AI-coding notes. No slop, no spam, unsubscribe anytime.

We will send a confirmation email. Click the link in it to finish subscribing.

Written by

NotVibesCoded Editorial Team

NotVibesCoded is written and reviewed by its editorial team under the standards in the editorial policy. A named author page, with full credentials, replaces this placeholder shortly.

More about the author

Projects mentioned

Developer Tools

uv logouv

An extremely fast Python package and project manager, written in Rust.

uv replaces pip, pip-tools, pipx, poetry, pyenv, and virtualenv with a single binary that resolves and installs Python dependencies 10–100x faster. It's the rare tool that deletes an entire category of workflow friction.

RustPython
Developer Tools

Ruff logoRuff

An extremely fast Python linter and code formatter, written in Rust.

Ruff collapses Flake8, pylint's common rules, isort, and Black into one tool that runs in milliseconds. It proved that developer-experience speed is a feature, not a luxury.

RustPython
Developer Tools

SQLite logoSQLite

A C library that implements a small, fast, self-contained SQL database engine.

The most widely deployed database engine in the world, in every phone, browser, and airplane, maintained by a tiny team with arguably the most rigorous testing culture in software.

C

Related articles