SEO for Vibe-Coded Sites: What Breaks on AI Site Builders and How to Check

What breaks on a vibe-coded site, in short?

The failures that matter are about delivery, not copy: what a crawler receives, which title and canonical each page declares, whether each URL loads on its own, and whether a leftover setting blocks indexing. Screpy, a site-audit vendor, describes a site that looks finished in an AI builder while its live pages have broken routes, repeated titles or no path from the homepage.

• Content that appears only after a script runs may not reach crawlers, according to OceanWP, a claim this page marks as unverified.
• One default title, description or canonical copied across routes makes different pages look identical to a search engine.
• An inner URL that works only when you click through the site can fail when requested directly.
• A noindex or robots rule left over from a preview or staging build can keep public pages out of search.
• Each of these can be checked on the published domain without writing code, using the protocol below.

Did we test the AI builders ourselves?

No, and this page does not claim to. The brief for it asked for hands-on tests across several builders, but the research supplied no test data, no screenshots and no crawl, so none is reported here.

That gap is wider than it looks. Screpy's own worked example uses five fictional URLs and says plainly that its audit record is not a result from any real AI builder.

What this page offers instead is a method: nine checks you can run on any builder's output, with each check labeled by where it comes from. Anything about how a particular builder behaves is left out unless a source states it, and the Lovable section says exactly what that leaves.

Why do AI builders produce these problems at all?

The likeliest reason is that a prompt-to-site flow is judged on what a person sees in a preview, and nothing in that loop checks what a crawler receives. That is an inference from how the tools are described, not a measured finding.

Google's own developer blog shows how the tools are pitched. It says Gemini 3 Pro can turn a high-level idea into an interactive app from a single prompt, and that the build mode in Google AI Studio produces a working app the same way. A site made that way is checked by looking at it.

Screpy makes the related point for site owners: AI-generated sites sometimes inherit one layout's generic metadata across every route. A page can look finished while its title, canonical or routing was never decided by anyone.

looks right in the preview → nobody checked the published page → the crawler gets something else

Can a crawler read your content if a script has to run first?

Google says it should ideally see a page the same way an average user does, which means it needs the same resources as the browser, including CSS and JavaScript. In the SEO Starter Guide, Google warns that hiding those resources can leave its crawler unable to understand pages, so they may not show up or rank for your target terms.

The guide names the tool for the check: the URL Inspection tool in Search Console shows how Google sees a page. Use it on your homepage and one inner page, and confirm the headline, body text and links appear in what Google fetched.

AI crawlers are a separate question, and the evidence here is thin. OceanWP states that OpenAI's GPTBot, Anthropic's ClaudeBot and Perplexity's crawler largely do not execute JavaScript and parse only the raw HTML. OceanWP sells WordPress products and promotes its own Site Booster in the same article, and the research package does not include any crawler operator's documentation on the point, so treat the claim as unverified.

A practical test costs nothing. Open the page in a browser, use view-source, and look for your headline and a sentence of body text in the raw HTML. If they are visible on the page but missing from the source, the content depends on a script, which is Kanso's method for spotting the pattern rather than a step from the sources.

For a wider read on which AI-crawler claims are documented and which are guesswork, see the guide that grades each GEO tactic as official guidance, research, practitioner opinion or unknown: GEO Without the Hype.

Does every page have its own title, description and canonical?

Each distinct page should declare a title that describes it and a canonical that points to itself, and a copied default fails both. Screpy's audit method asks you to open two or three public pages and compare the HTML title, the main heading, the meta description and the opening paragraph.

The question to ask is whether a person could tell why each URL exists. If two routes carry the same hero text and the same title, Screpy says the URL difference is cosmetic, and you must decide whether they should be separate pages at all.

The canonical needs its own look. Google's SEO Starter Guide explains that search engines choose one canonical URL per piece of content, and that Google will try to do it automatically if you do not. Screpy adds that a canonical pointing to the homepage on every distinct page can collapse the site's intended structure, and that a canonical is a preference signal, not a command.

On length, Screpy reads Google's title-link and snippet guidance as setting no universal 60-character title or 160-character description rule, and says to judge clarity and page fit instead. Google can also show different text from the one you wrote.

Is something telling Google not to index your pages?

Check for it directly, because a noindex or a robots.txt rule can sit on a public page without any visible sign. Screpy says to look in both the HTML and the response headers for noindex, then read the relevant robots.txt rules.

Test the final public domain, not the builder's preview. Screpy warns that previews and staging domains can behave differently from the deployed site, so a result from one does not carry over to the other.

Do not strip every restriction to turn an audit green. Screpy gives the example of a deliberate noindex on an account page, which is correct, against the same instruction on a public service page, which deserves investigation. Google's SEO Starter Guide points to its own guidance on ways to keep content out of results for pages you really do want excluded.

If Search Console already reports an exclusion for a page, match the status to the stage that failed. Discovered, Crawled, Indexed, Ranked: How to Find Which Stage Is Broken covers how to read those statuses.

Do inner pages load directly, and do missing pages say so?

An inner URL should return its own page when requested fresh, and a path that does not exist should return a not-found response rather than a copy of the homepage. Screpy tests this by pasting each inner URL into a new tab and refreshing, instead of relying on clicks inside the site.

The reason is order of operations. Screpy says to fix a broken route before rewriting its headline, because Google cannot evaluate the intended content if it receives an error or a different destination.

Redirects belong in the same check. If a URL redirects, record where it ends, and update your own links to point at the chosen public address instead of leaving a chain. Google's SEO Starter Guide takes the same line for duplicates: set up a redirect from non-preferred URLs to the one that best represents the content, and use the canonical element when you cannot redirect.

Are your pages linked together, and does a sitemap matter?

Every important page should be reachable from the homepage through ordinary links, and a sitemap helps but is not required. Google's SEO Starter Guide says Google primarily finds pages through links from pages it already crawled, and that submitting a sitemap is optional.

Screpy's method is to walk the path as a visitor would: homepage, then the use-case page, then the next step such as pricing or contact. It notes that Google favors ordinary crawlable anchors, so a card that reacts only to a script click can work for one visitor and still be a poor route for a crawler or a keyboard user.

Then compare the sitemap with your list. It should include the public pages you want found and leave out private or duplicate routes. Screpy is explicit that a sitemap aids discovery but cannot make a broken page indexable.

Run the same journey on a phone-sized screen, and submit a safe test enquiry if a form is the next step. Screpy treats these as human-review items that a crawl cannot judge, such as whether the offer makes sense or the confirmation message is truthful.

What is the nine-check protocol for any AI builder's site?

The protocol is nine pass/fail checks run in a fixed order on the published domain, ending with a retest after each fix. It was assembled by taking the checks Google's SEO Starter Guide and Screpy's pre-launch method both describe or imply, ordering them so that route failures come before metadata, and labeling the source of each.

To compare two builders, build the same small site on each, publish both, and run all nine checks on both. Use the same pages and the same account of what each page should be, so that a difference in results comes from the builder and not from the brief.

That comparison is the hands-on test this page could not supply, and the protocol is how you can run it yourself. Record every result, including passes, so the two columns are comparable.

1. List five to ten URLs that matter, with the page each should be and whether it should be indexable.
2. Run checks 1 and 2 first, because a broken route makes every later check meaningless.
3. Run checks 3 to 6 on a homepage and two different inner pages.
4. Run checks 7 and 8 across the whole list.
5. Fix one failure type at a time, deploy, and rerun check 9 before moving to the next.

How should you record the results?

Record one row per URL with a pass or fail for each check and a decision, so the next person can see what was tested and what was accepted. The table gives the columns to copy.

Note the tested device, the page and the visible failure next to each fail. Screpy's reasoning is that the coding assistant needs an observable target, and a specific URL and signal is one.

A clean record is not a ranking forecast. Google's SEO Starter Guide says no guidance guarantees that a site will be added to the index, and Screpy frames the goal as an evidence-based pass/fail record, not a perfect tool score or a promise of traffic.

What can be said about Lovable SEO from this research?

Very little about how Lovable behaves, because the research contains no text from Lovable's pages or from any test of a Lovable site. The search results for the query show only that dedicated pages on the question exist.

Those results include a page on lovable.dev titled “SEO and AI search for apps built with AI” and a third-party article whose title frames the issue around two frameworks, Vite and TanStack. This page has not read either, so it does not state what they say. Read Lovable's own page for its current position, and note the date on whatever you read.

You do not need those pages to find out what your own site does. Publish it, then run the nine checks on the published domain. The result describes your site as it is today, which is what matters for your pages.

How do you compare AI website builders on SEO?

Compare them with the same test on the same site, because the pages that rank for this query do not do it. Several of the results for “ai website builder seo” are pages published by builders themselves, such as Wix and Base44, so treat anything they say about their own SEO support as a vendor claim until you check the output.

Choose criteria before you look at any builder, and do not let the first tool you try set them. The nine checks are a workable set: route behavior, what a crawler receives, per-page titles and canonicals, indexing instructions, links and the sitemap.

Date every result. A builder can change its output at any time, and a result from last month describes last month's build.

How do vibe-coded sites differ from WordPress for SEO?

The difference OceanWP names is that WordPress outputs server-rendered HTML by default, so the content, headings, links and metadata are in the first response. That is a plausible architectural point, but it comes from a company that sells WordPress products and argues the case without a test.

OceanWP reports, citing W3Techs data, that WordPress powers roughly 41.5% of all websites and about 59.3% of the known CMS market as of early 2026. It also states that market share alone does not prove SEO superiority. That caveat is fair, and it means the figure says nothing about a particular site.

The same article raises ownership: it says a site that lives only inside a builder's platform ties you to that provider, and that moving its logic to a standard server is often impossible. Check whether you can export or host the code yourself before you commit.

How do you fix what fails?

Fix one failure type at a time, starting with routes, and verify each fix on the published domain before the next. A prompt to the builder can request the change, but only the retest shows whether it reached the live site.

Order matters. Fix a route that fails before rewriting its headline, repair canonicals before titles, and remove an accidental noindex before anything else, because a blocked page cannot benefit from other work.

Then wait before judging results. Google says some changes take effect in a few hours and others take several months, and suggests waiting a few weeks to assess whether your work helped. Use the retest for the technical question and Search Console for the search question.

The SEO Audit Checklist for Small Sites picks up where this protocol ends, and How to Read Google Search Console as a Founder explains the reports you will use afterwards.

What is documented and what is Kanso's analysis?

The facts below come from named sources and the interpretation is Kanso's own. The lists keep them apart.

• Documented, Google: Google should see a page the way a user does, the URL Inspection tool shows how it sees a page, a sitemap is not required, and Google finds pages mainly through links.
• Documented, Google: search engines pick one canonical URL per piece of content, and redirects or the canonical element consolidate duplicates.
• Documented, Screpy: a pre-launch audit tests direct loads, redirects, indexing instructions, canonicals, sitemap and links, and its worked example is fictional.
• Claimed, OceanWP (unverified here): AI crawlers largely do not run JavaScript, and WordPress serves server-rendered HTML by default.
• Reported, OceanWP citing W3Techs: WordPress holds roughly 41.5% of websites and 59.3% of the known CMS market as of early 2026.

• Analysis: builders are judged on the preview, so nobody checks what a crawler receives. No source measures this.
• Analysis: the view-source step is a reasonable way to spot script-dependent content, but it is not taken from a source.
• Analysis: comparing builders needs the same site built on each, which this page recommends and did not do.
• Not covered: how Lovable or any other named builder behaves, how often these failures occur, and whether fixing them changes rankings.

Where does Kanso fit into this check?

Kanso can run part of the follow-up work, and it does not replace the direct checks above. The SEO Agent audits your site and Search Console data and turns what it finds into recommendations and tracked tasks for your approval.

If your site's code is in a GitHub repository, the Coding Agent prepares title, meta description and canonical fixes as GitHub pull requests you review. It never merges or deploys, and Kanso does not promise rankings. Plans are on the pricing page.

Vibe-coded website SEO: frequently asked questions

Sources

• Search Engine Optimization (SEO) Starter Guide, Google Search Central
• How to Audit a Vibe-Coded Website for SEO Before Launch, Screpy
• Vibe-Coding vs WordPress: Best for SEO in 2026, OceanWP
• A new era of intelligence with Gemini 3, Google (The Keyword)
• Start building with Gemini 3, Google (The Keyword)