Why your AI-built site isn't showing up on Google
Almost certainly, nothing is broken. If your site went live in the last month and site:yourdomain.com returns nothing, the overwhelmingly likely reason is that the site is new and nothing links to it. Google's own help page asks you to allow at least a week after submitting a sitemap, and its recrawl documentation says crawling "can take anywhere from a few days to a few weeks" (checked August 2026).
The second possibility - that your single-page app renders to an empty <div> and Google sees nothing - is real but much rarer than the internet tells you. Here is a five-minute test that separates the two, so you stop guessing.
First: stop using site:
It's the wrong instrument, and Google says so in its own search-operator documentation: "The site: operator doesn't necessarily return all the URLs that are indexed under the prefix specified in the query." Search operators are bound by retrieval limits, so the same page tells you to use the URL Inspection tool instead.
A blank site: result on a three-week-old domain is not evidence of a bug. It's evidence of a three-week-old domain.
The five-minute test
Search Console must be verified for the domain. Everything below is free.
1. Look at the raw HTML. In Chrome, open view-source:https://yourdomain.com. On a Vite or Create React App build you'll see a full <head>, a <script type="module" src="/assets/index-xxxx.js">, and this:
<div id="root"></div>Empty. That's normal - don't fix anything yet. It's what every unrendered SPA looks like, including plenty that rank fine.
2. Get Google's verdict. In Search Console, paste the full URL into the Inspect any URL bar at the top. You'll get a verdict, and the exact string matters:
- URL is on Google, or URL is on Google, but has issues - indexed. Your problem is ranking, not indexing.
- URL is not on Google - the one you're here for. Expand Page indexing and read the reason string.
3. Ask Google to render it right now. Click Test live URL. When it finishes, click View tested page and switch to the HTML tab. That is not your source file - it's the DOM after Google's headless Chromium executed your JavaScript, fetched as Google-InspectionTool. Search it for a sentence from your homepage, then check the Screenshot tab and More info → JavaScript console messages.
4. Compare the two. This is the whole diagnosis:
| view-source: | Live test HTML | What you have |
|---|---|---|
| Empty <div id="root"> | Your content is there | Rendering is fine. Your problem is discovery or age. |
| Empty <div id="root"> | Still empty, or a spinner | A genuine rendering failure. Read the console messages tab. |
| Content present | Content present | Already pre-rendered or server-rendered. Not a rendering problem. |
Google documents its pipeline as three separate queues - crawling, rendering, indexing - and says a page "may stay on this queue for a few seconds, but it can take longer than that." So a page can be crawled today and rendered days later. The live test skips that wait and shows you the end state directly.
Decode the reason string
If the verdict was URL is not on Google, Search Console gives a reason. These are Google's exact strings, and what each one usually means when the site came out of an AI builder:
| Reason | What it means here |
|---|---|
| Discovered – currently not indexed | Google knows the URL and hasn't fetched it. Google's stated cause is that crawling "was expected to overload the site" - but on a five-page site that's queue priority, not load. It means: not important enough yet. |
| Crawled – currently not indexed | Google fetched it and chose not to index it. Google says it "may or may not be indexed in the future; no need to resubmit this URL." Resubmitting is the thing everyone does and it does nothing. |
| Page indexed without content | This is the actual empty-SPA symptom, and it's also what you see when a server or CDN blocks Googlebot at a low level. |
| Soft 404 | Your client-side router returns HTTP 200 for a route that has no content. Google's JavaScript troubleshooting docs call this out specifically: SPAs report 200 instead of an error, so error pages get indexed. |
| Not found (404) | Deep routes only. Your host is doing a real 404 for /about because there's no about.html and no rewrite rule. The homepage indexes; nothing else does. |
| URL marked 'noindex' | Something is emitting the tag or the X-Robots-Tag header. See the next section - this is rarely you. |
| Duplicate, Google chose different canonical than user | Your content is on Google. Under a different hostname. Also next section. |
The Soft 404 and Not found rows are worth dwelling on: a site that indexes its homepage and nothing else looks identical, from a site: query, to a site that isn't indexed at all.
Your site may be indexed - under the builder's URL
This is the failure I see most often after "it's just new," and it produces exactly the symptom people describe: you search your brand and get one blank-looking result.
Try this instead of site: - put a distinctive sentence from your homepage in quotes and search for it. If a result comes back on a hostname that isn't your domain, you are indexed. You're just indexed somewhere else.
Lovable. The project's xxx.lovable.app URL serves the same content as your custom domain, and Lovable's documentation states plainly that "currently, there is no way to remove the xxx.lovable.app project URL from your project." Marking your custom domain as primary helps, but only partly: connected domains redirect to the primary with a 302 temporary redirect, and the docs say Lovable hosting "does not support 301 permanent redirects between connected project domains." A 302 tells Google the move is temporary, so it has no reason to consolidate signals onto your domain. Setting up the domain properly in the first place is covered in connecting a custom domain to Lovable.
Vercel and v0. Vercel sets X-Robots-Tag: noindex on Preview Deployments automatically. The trap is the documented exception: if a custom domain is assigned to a non-production branch, "the header X-Robots-Tag: noindex will not be set" - so a staging domain on a preview branch is fully indexable, competing with production. Check with:
curl -sI https://yourdomain.com | grep -i x-robots-tagBolt. Bolt's pre-renderer, SEO Boost, is off by default, requires a paid plan and a connected custom domain, and caches each rendered page for 24 to 48 hours. If your Bolt project is a Next.js App Router project, read Bolt's own SEO page first: it documents a known issue there and currently recommends turning SEO Boost off for Next.js projects. Test what crawlers actually receive:
curl -sA "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
https://yourdomain.com | head -40More on Bolt's hosting and export routes in the Bolt.new deploy guide.
If rendering really is broken
Two of the reason strings above have the same fix: pre-rendering. If the live test comes back empty, or if /about 404s while / indexes, you need real HTML files on disk instead of one index.html and a router.
That's what my plugin does. The Parkstatic GitHub Action runs your build, then walks the result in headless Chromium and writes a static HTML file per route - prerender defaults to true, prerender-routes seeds paths no link reaches, prerender-max-pages caps the crawl at 500. Because each route becomes a file, the deep-route 404 stops being possible: /about is about/index.html, and your WordPress host serves it like any other file. $29.99/year or $89.99 once (checked August 2026), on hosting you already pay for.
Don't buy it to fix an indexing problem. If step 4 of the test showed your content in the live-test HTML, pre-rendering will not change your indexing at all - Google already sees the page. And if your site needs a database, auth, or anything computed per request, a pre-rendered build is the wrong architecture no matter who ships it; static hosting only works for sites that are actually static.
The honest part
Pre-rendering fixes rendering. It does not fix authority.
Google is explicit: "Indexing isn't guaranteed; not every page that Google processes will be indexed." A perfectly pre-rendered five-page site on a domain registered last month, with no inbound links and no sitemap submitted, will still sit at Discovered – currently not indexed for a while. Nothing you can buy shortcuts that.
What moves it: submit a sitemap, request indexing once for the homepage (once - the quota is real and repeat requests don't speed anything up), get one genuine link from somewhere already crawled, and wait the week Google asks you to wait. Then re-run the test above rather than the site: query.
If the test told you rendering is the problem, the deploy guides walk through it builder by builder, and hosting a React app on WordPress is the shortest path from a Vite build to indexed HTML on a domain you already own.