Google is not indexing your pages because it either cannot reach them, cannot read them, or has decided they are not worth keeping. Those are the only three categories, and the Pages report in Google Search Console tells you which one you are in. The nine reasons below cover almost every site I have audited this year, listed in the order they show up on sites built with Lovable, Bolt, v0, Cursor, and Replit. For each one I give the status Search Console shows, the check that proves it, and the fix. At the end there is the step almost everyone skips, which is forcing Google to come back after the fix.
Read the report before you touch anything
Open Search Console, choose your property, click Pages under Indexing in the left menu. The chart at the top shows two lines: indexed and not indexed. Below it, a table headed Why pages are not indexed lists every reason Google has, with a count and a trend arrow. Click any row to see the URLs behind it. Compare the indexed count against the number of URLs in your sitemap. Forty URLs submitted and six indexed is a structural problem, not a patience problem.
The report lags by a few days, so a fix made this morning will not show yet. For a single page right now, use URL Inspection: paste the full URL into the search bar at the top of Search Console. It tells you whether the page is on Google, when it was last crawled, what canonical you declared, and what canonical Google chose. Those two canonical lines answer more questions than any other field in the tool.
1. Only the homepage exists as HTML
On an older client-side React build, the server returns the same index.html for every route and the content arrives later through JavaScript. Google can render JavaScript, but it does so in a second pass that may come days later, and by then the page has often already been filed under a different reason. On a young domain the second pass sometimes never comes.
The check is View Page Source on any sub-page. If the body is one empty div, this is your problem. A faster version from the command line:
curl -s https://yourdomain.com/about | grep -c "<h1"Zero means no heading in the HTML. Lovable projects created after 13 May 2026 render on the server and do not have this. Older ones do, and the fix is the upgrade described in Is Lovable good for SEO?. No amount of content work helps until the words are in the file.
2. Every page carries the homepage canonical
This one is worse than an empty page, because it is an instruction. A canonical tag tells Google which URL is the original. When the builder writes one canonical into the shared HTML file, every sub-page tells Google it is a copy of the homepage, and Google believes it. In Search Console this shows as Duplicate, Google chose different canonical than user. Open URL Inspection on a sub-page and read the two lines: User-declared canonical and Google-selected canonical. If either one is the homepage, you have found it.
The fix has two halves and most people do only the first. Half one: each page gets its own absolute canonical, pointing at itself. Half two: request indexing on each affected page, because Google will not revisit a URL it has already consolidated. I wrote the full recovery in What does Duplicate without user-selected canonical mean?, including how to prove when the problem started.
3. Discovered, currently not indexed
Google knows the URL exists, usually from your sitemap, and has not crawled it yet. That is a queue, not a verdict. It happens on new domains with little authority and on sites where the only path to a page is the sitemap. Internal links from pages Google already visits move a URL up that queue faster than anything else. Check whether the page is linked from your homepage or navigation with a real anchor tag. If the only place it appears is the sitemap, that is the fix. The full walkthrough, including what does nothing, is in What does Discovered, currently not indexed mean?.
4. Crawled, currently not indexed
Google fetched the page, read it, and passed. On vibe coded sites the usual cause is that the page looked like every other page: same template, a paragraph of generic copy, no distinct answer to any question. Sometimes it is the rendered shell from reason one, which means Google read an empty page and recorded it as worthless. Open URL Inspection, click View Crawled Page, read the HTML tab. If your content is there, the problem is the content. If it is not, go back to reason one. The diagnosis for the content case is in What does Crawled, currently not indexed mean?.
5. Excluded by noindex tag
A builder that ran in preview mode, or a template that shipped with noindex on, leaves a meta robots tag telling Google to stay out. It can also arrive as an HTTP header, which the page source will not show. Check both:
curl -s https://yourdomain.com/services | grep -i "noindex"
curl -sI https://yourdomain.com/services | grep -i "x-robots-tag"Either command printing anything is the answer. Remove the tag or the header, redeploy, and request indexing. This is a two-minute fix and it is embarrassingly common, especially on sites that were password-protected or on a staging URL before launch and kept the setting.
6. Blocked by robots.txt
Two versions of this. The obvious one disallows a folder your pages live in. The sneaky one disallows the JavaScript or CSS folder, which means Google can fetch the HTML but cannot render it, so on a client-side build it sees nothing. Open yourdomain.com/robots.txt and read every Disallow line. Then open URL Inspection, click Test Live URL, and look at the rendered screenshot. A blank screenshot with a 200 status is a blocked asset. A robots file that lets everything in and points at the sitemap is two lines long:
User-agent: *
Allow: /
Sitemap: https://yourdomain.com/sitemap.xml7. The sitemap points at the wrong hostname
Lovable projects start on a lovable.app subdomain. Bolt, v0, and Replit have their own equivalents. If you submitted a sitemap while you were still on that hostname and later connected your own domain, Search Console may still be reading the old file, and the URLs inside it may still say lovable.app. Google then sees a sitemap full of URLs that redirect, and files them under Page with redirect. Open the sitemap in a browser and read the loc values. Every one must be your real domain, with the same www and trailing-slash convention as your canonicals. Generate a fresh file, remove the old submission in the Sitemaps report, and resubmit.
8. Soft 404s from a catch-all route
Many builders return HTTP 200 for every URL, including ones that do not exist, and show a Not Found message only after JavaScript runs. Google records these as soft 404s and, worse, treats the unlimited supply of them as duplicates of your homepage. Test it with a path you made up:
curl -s -o /dev/null -w "%{http_code}\n" https://yourdomain.com/made-up-pageThe number must be 404. If it is 200, your server has to return a real 404 status for unknown paths. On the Cloudflare and Netlify style hosts most builders deploy to, that is a config change or a catch-all route, not a rewrite of the site.
9. Nothing links to the page
If the only place a URL appears is your sitemap, Google has no reason to think it matters. Every page on a small site should be reachable from the navigation or from at least two other pages through a real anchor tag with an href. Buttons with click handlers do not count; crawlers cannot follow them. View Page Source on your homepage and search for the path of the page that is stuck. If the string is not there, the page is an orphan. This is the most common reason a Lovable blog post stays unindexed for months while the homepage does fine.
If it is only the blog posts
The question I get most often is a variant: the pages are indexed but the blog posts are not. Three causes cover it. The blog index page uses a load-more button instead of links, so older posts are unreachable. The posts were generated from one prompt and share most of their sentences, so Google keeps one and drops the rest under Crawled, currently not indexed. Or the posts have no date and no author, sit at a URL nothing links to, and were added to the sitemap without a lastmod change, so they sit in Discovered. Check those three in that order. On my own site every post is linked from the blog index with a plain anchor, from at least two related posts, and from the sitemap with a lastmod date. That is the minimum.
Want me to read your Pages report with you?
Send me your URL and a screenshot of the Why pages are not indexed table. I will tell you which of the nine you have and what to change first.
After the fix, force the recrawl
Fixing the build does not fix the index. Google records its decision about a URL and drops that URL to the bottom of the crawl queue, and on a young domain it may not revisit for months. After every fix, open URL Inspection, paste the page, and click Request Indexing. Then update the lastmod date for that URL in your sitemap and resubmit it. Do it page by page for your most important URLs, most important first, because the button is rate limited.
The Indexing API does not help here; Google only honors it for job postings and live broadcast pages. IndexNow is read by Bing and Yandex and Google does not read it at all. Paid indexing services are bots that click the same Request Indexing button you can click yourself. The sitemap and the inspection tool are the levers you have, and they work. A new site launched with all nine reasons already handled indexed in its first week and reached 481 clicks and 211,000 impressions inside three months.
Questions people also ask
Why is Google not indexing my site at all?
If not even the homepage is indexed, check for noindex first, then robots.txt, then whether the domain has a manual action under Security and Manual Actions in Search Console. A brand new domain with nothing linking to it can also take a couple of weeks for the homepage alone. Submit the sitemap and request indexing on the homepage once.
Why is Google not indexing all my pages?
Homepage in, everything else out is the signature of reason one or two: an empty JavaScript shell, or a homepage canonical on every route. Read the two canonical lines in URL Inspection for one sub-page and you will know within a minute.
How long should I wait before worrying?
A crawlable page with a sitemap entry and a homepage link should be indexed within two to four weeks. Past a month with no change in the Pages report, the wait is not the problem. Work through the nine reasons.
Does requesting indexing many times help?
No. The first request puts the URL in a priority queue. Repeating it does nothing and the tool limits you. Change something on the page, update lastmod, and request once more.
Will an SEO plugin or tool fix this?
Not on a vibe coded site. Plugins fix WordPress. On Lovable, Bolt, and similar builders the fixes are in the prompt, the routes, and two static files. The plugin does not exist, and the work is smaller than people expect.
If every check above passes and the pages are indexed but still not appearing, that is a different problem with a different report. It is covered in Why is my website indexed but not showing on Google?.
