SEO for sites built with AI app builders: Lovable, Bolt, v0 and Replit

The first cause surprises people most. A site with no links pointing to it may be discovered slowly even with a sitemap. Google has no reason to hurry to a domain nobody mentions. The code can be perfect and the site still takes weeks to appear.

The other four are the builder's defaults meeting the way crawlers read. None of them is specific to one tool, and all of them are quick to check.

Each builder produces a different stack, and the choice changes by project, by template and over time. What follows is the picture in 2026. Check your own project, because it changes.

Two checks tell you what you have, whatever the tool said it would build.

# 1. What the project is built with (run in the project folder)
grep -E '"(next|vite|react-scripts|astro|@tanstack/[a-z-]+|@react-router/[a-z-]+)"' package.json

# 2. What a crawler that does not run JavaScript receives
curl -s https://yourproduct.com/ | grep -i '<title>'
curl -s https://yourproduct.com/ | grep -c 'a sentence from your home page'

If you find vite without a server framework and the second curl prints 0, your pages are built in the browser. The guide on single page applications ranks the fixes; the Lovable guide covers its projects in detail.

Builders publish to their own subdomain before you connect a domain, and many keep serving it afterwards. If Google found the subdomain first, it may index that copy and treat your real domain as the duplicate.

Preview and staging hosts should be noindexed, or redirected to the production domain with a canonical to it. Do one of these, in order of preference:

1. 1

   Redirect the preview host

   If the builder offers it, make the subdomain answer 301 to the same path on yourproduct.com. Google then merges the two.

2. 2

   Add a canonical on every page

   Each page carries a canonical to its URL on your domain, whichever host served it.

3. 3

   Noindex a staging copy

   A staging site that must stay reachable sends a noindex header or tag, and never appears in a sitemap.

<!-- On every page, served from any host -->
<link rel="canonical" href="https://yourproduct.com/pricing">

<!-- On a staging copy only -->
<meta name="robots" content="noindex">

Run these on your production domain. Each row is a command or a click, and each result points to one fix.

for path in / /pricing /about; do
  printf '%-10s ' "$path"
  curl -s "https://yourproduct.com$path" | grep -o '<title>[^<]*</title>'
done
curl -s -o /dev/null -w 'unknown path: %{http_code}\n' https://yourproduct.com/no-such-page
curl -s https://yourproduct.com/robots.txt
curl -s https://yourproduct.com/sitemap.xml | grep -c '<loc>'

1. 1

   Week 1: inspect and request indexing

   Run URL Inspection on your home page and your three most important pages. Use the live test to check the rendered HTML holds your text, then click Request indexing. It asks Google to crawl one URL and has a daily limit, so keep it for pages that matter.

2. 2

   Week 2: three real links

   Post on one launch site, list the product in one directory for your niche, and answer one community question with a link to a page that answers it. Links are how Google finds a new domain and decides it is worth crawling.

3. 3

   Week 3: fix what the Pages report says

   In Search Console, open Pages. Read the reasons pages are not indexed. "Discovered, currently not indexed" is patience and links; "Crawled, currently not indexed" points at the page itself, often thin or close to another page; soft 404 is the status code problem.

4. 4

   Week 4: read the queries

   Open the Performance report. The first impressions show which searches Google tried you on. Improve the page that matches the most of them before writing a new one.

Builders and coding agents fix what you describe precisely. Ask for a report first, then approve the changes one by one, so you know what moved.

Audit this project for search engines and report before changing anything.
For each public route, tell me:
- whether its main text is in the HTML the server sends (not added by JavaScript),
- its <title> and meta description, and whether any other route shares them,
- its canonical URL,
- whether links to other pages are <a href> elements.
Also tell me:
- what status an unknown path such as /no-such-page returns,
- whether /sitemap.xml and /robots.txt exist and what they contain,
- which domains the site is served on, and whether any of them should redirect.
Do not modify any file. Output a table, one row per route.

Then run the curl commands above yourself. An agent's report says what the code intends; curl says what the server actually sends.