Is my site invisible to Google?
There is a specific failure that hits AI-built sites more than anything else, produces no error message, and quietly guarantees zero traffic forever. Four tests tell you in about a minute whether it's yours.
The short answer
A large share of AI-generated sites are single-page apps that build their content in the browser. The visitor sees a finished page. A crawler requests the same URL and receives an almost empty document - a title, a script tag, an empty div. There is nothing to index, so nothing gets indexed.
What makes this uniquely nasty is that it fails silently. Your site loads. It looks right. It works on your phone. Nothing anywhere reports an error. You are simply invisible, from the day you launched, and every hour spent on content or channels while it's true is wasted - you're advertising a building with no door.
The builders have been fixing this. Lovable added server-rendering and pre-rendering support around April 2026, and the others have moved the same way. A project you generated last month may be completely fine; a project from last year, or an export you deployed yourself, may not be. Test your live domain instead of trusting either assumption.
The four tests, about a minute
Run these on your real domain, not a preview link, and not on localhost. Do them in order - the first two are the diagnosis, the last two confirm what the search engine actually did with it.
| Test | What to do | What a failure looks like |
|---|---|---|
| View source | Right-click the page, choose "view page source" (not "inspect"), then search that source for a sentence you can see on screen. | Your headline isn't there. You see a near-empty <div id="root"> and script tags. This is the one that matters most. |
| Disable JavaScript | Turn JavaScript off in your browser settings and reload the page. | A blank screen, a spinner, or "you need JavaScript to run this app." Anything a reader can still use here is what a non-rendering crawler gets. |
| The index check | Search Google for site:yourdomain.com. | Zero results means nothing of yours is indexed. A handful of results with wrong or duplicated titles means partial indexing - a different, milder problem. |
| Search Console | Verify your domain, open URL Inspection, test your homepage, then open View crawled page. | The HTML shown there is empty or missing your content. This is the authoritative answer - it's literally what Google fetched. |
If view-source shows your content and site: still returns nothing, you don't have a rendering problem - you have an indexing problem, which is usually a missing sitemap, a very new domain, or a stray noindex. Keep reading; those are in the next section and they're all quick.
What actually causes it
Client-side rendering (the big one)
The generated app ships a near-empty HTML document plus a JavaScript bundle that constructs the page after load. Google can render JavaScript, but rendering happens on a separate, slower queue and is never guaranteed. More importantly for 2026: most AI assistant crawlers, and many social and link-preview fetchers, don't execute JavaScript at all. To them your page is blank. That's not a ranking penalty, it's non-existence.
One title for every page
Client-rendered apps commonly serve the same <title> and meta description on every route, because those are set at build time and never updated per page. Even when indexing works, every page competes as the same page, and search results show a title that describes none of them.
Leftovers from the template or preview
A noindex meta tag from a staging setup, a robots.txt containing Disallow: /, or a canonical tag still pointing at the builder's preview subdomain. Each one alone is enough to erase you, each takes minutes to fix, and none of them announce themselves.
No sitemap, no submission
A brand-new domain has no links pointing at it, so discovery depends on you telling search engines it exists. No sitemap and no verified Search Console property means you're waiting to be found by accident.
Routes that aren't real URLs
If navigating your site never changes the URL, or the URL only changes after a #, then you effectively have one page. Nothing else can be linked to, shared, or ranked separately.
The fixes, ranked by effort
Start at the top. The first three take under an hour combined and solve a surprising share of cases outright.
| Fix | Effort | What it solves |
|---|---|---|
| Remove the blockers | Minutes | Delete any noindex, fix robots.txt, point the canonical at your real domain. Pure erasure, undone in one commit. |
| Titles and descriptions | An hour | A unique, honest title and description per page. Say what the page is, not what your brand is. This is also your search result copy. |
| Sitemap + Search Console | An hour | Discovery, plus the only view you'll ever get of what was actually crawled. Do this even if everything else passes. |
| Static export / pre-render | Half a day | Generate real HTML files at build time. For a marketing site or docs that don't change per visitor, this is the right answer and it's boring in the best way. |
| Server-side rendering | A day or more | The proper fix for anything dynamic. Check first whether your builder now offers it as a setting - several do, and enabling a toggle beats a migration. |
| A separate content site | Varies | Legitimate escape hatch: keep the app as-is and put your marketing pages on a plain static site. Your app was never going to rank; your content pages were. |
One thing worth being blunt about: prerendering only for crawlers is not the move. Serving different content to bots than to people is a rule you don't want to be near, and the modern tooling makes it unnecessary - pre-rendering everything for everyone is faster for humans too.
What to check after you fix it
- Re-run all four tests. Particularly "view crawled page" in Search Console, which needs a fresh inspection - the cached result will happily show you the old broken version and let you celebrate early.
- Request indexing, then wait. Days to a couple of weeks is normal for a new domain. Requesting it four times does not make it four times faster.
- Watch impressions, not clicks. Impressions are the signal that the machine has understood what you're about and started showing you. Clicks lag badly at first and that is not a fault.
- Expect the numbers to look bad, correctly. Across four sites launched in 2026, first-weeks impressions ran from about 2,200 to 16,500 with click-through between 0.1% and 0.6%, at average positions of 12 to 49. Almost nobody clicks position 22. The full dated set is on the receipts page.
- Check the AI surface separately. Being crawlable is the prerequisite for being cited, not the same thing - how citation actually works.
Then invisibility isn't your problem, and it's worth knowing that early - it means the silence is coming from somewhere else, and the fix is a different one entirely. The two-minute diagnostic names which of the five gaps you're actually in, and the post-build guide covers the rest in order.
Things that are not the problem
- Meta keywords. Ignored for roughly two decades. If a tool told you to add them, be suspicious of what else it told you.
- Submitting to hundreds of search engines. A paid service for a problem that doesn't exist. Search Console and Bing Webmaster Tools, both free, cover essentially all of it.
- Your domain being new. A real constraint on ranking, not on indexing. New domains get indexed within days routinely - the four sites above did.
- A sitemap fixing rendering. A sitemap tells a crawler where to look. It cannot make an empty page contain words.
- Page speed, at this stage. It matters eventually. It is completely irrelevant while the page has no content to load.
Want someone to check it properly?
The Launch Roast is a 15-minute recorded teardown of your page, back within 48 hours, scored against a published ten-point rubric - machine readability and crawlability included, alongside whether a stranger can tell what you do in four seconds.