/seo-ai-site-builders

name: seo-ai-site-builders
description: "Turn a JavaScript-only site built by an AI website generator into indexable HTML. Input: a site made with Lovable, Base44, Bolt, v0, Replit, Firebase Studio, Framer, Wix, Durable, Softr, Bubble, Glide or any similar tool. Output: proof of what crawlers actually receive (bundled zero-dependency script), the right conversion route (native SSR, build-time prerendering or SSG, framework migration, or crawler-only prerendering as a last resort), the HTML each page must serve, and the routing, status code and hosting config that goes with it. Use when a vibe-coded or AI-generated site is not indexed, shows an empty page in view-source, has meta tags that only appear after JavaScript runs, is invisible to ChatGPT and Perplexity, or when picking a builder before starting."
license: MIT
metadata:
  author: "Sorank (https://sorank.com)"
  version: "1.0.0"

AI-generated sites: rewrite the JavaScript into HTML

AI website generators produce a working site in minutes and, by default, most of them produce a client-rendered single page app: the server returns an almost empty HTML document plus a JavaScript bundle, and the browser builds the page afterwards. That is fine for a logged-in app and disqualifying for anything meant to be found.

The fix is never an SEO plugin or a meta tag component. It is changing what the server returns. This skill establishes what crawlers currently receive, picks the cheapest route to real HTML, and specifies the HTML those pages must serve.

One warning that shapes the whole workflow: the platforms move fast and their status changes. Lovable shipped server-side rendering for new apps in May 2026, Base44 started serving prerendered snapshots to crawlers in mid-2026. Never answer from a platform's reputation or from a blog post; fetch the URL and read the response. Step 1 exists for that reason.

Company knowledge first (Obsidian)

If the working environment contains an Obsidian vault or any local knowledge base (a folder of .md notes, often with a .obsidian directory), read the relevant notes before acting: brand and product facts, the stack already in use, past migration decisions, and the SEO action log of what was already tried. Ground every recommendation in that context instead of asking the user for facts the vault already holds. At the end of the session, append the actions taken to the vault's SEO action log so the next session starts informed. Vault structure, read-first and write-back protocols: the obsidian-brain skill.

When to use this skill

Use it for:

• A site built with Lovable, Base44, Bolt, v0, Replit, Firebase Studio, Rocket, Create, Mocha, Emergent, Dyad, Hostinger Horizons, Figma Make, Softr, Bubble, Glide, Durable, Dora, Wix, Framer or any similar generator
• "My site is live but Google only indexed the homepage"
• view-source shows an empty div and nothing else
• Page titles and descriptions that are correct in the browser tab and absent from the HTML
• Link previews (WhatsApp, Slack, LinkedIn, X) that render blank for every URL but the homepage
• ChatGPT, Claude or Perplexity answering "I cannot access that page" or describing the wrong content
• Choosing which builder to start with when the site has to rank

Hand off neighboring problems:

• Full technical audit, robots.txt, sitemaps, Core Web Vitals, the canonical AI crawler table: the seo-technical skill
• Which blocks a page is missing once it does serve HTML: the seo-page-sections skill
• JSON-LD templates: the seo-schema-markup skill
• Writing passages engines will quote: the geo-visibility skill
• Measuring the recovery in AI traffic and citations: the geo-tracking skill

The fact that decides everything

Googlebot renders JavaScript, on a deferred second pass. No AI crawler does. The Vercel and MERJ analysis of 500M+ crawler fetches found GPTBot, ClaudeBot and PerplexityBot download JavaScript files and execute none of them (https://vercel.com/blog/the-rise-of-the-ai-crawler).

So a client-rendered page is not "slightly weaker in search". It is:

| Surface | What it sees | |---|---| | Googlebot, AI Overviews, AI Mode, Gemini grounding | The rendered page, after a render queue delay | | ChatGPT (search and training) | The empty shell, permanently | | Claude, Perplexity | The empty shell, permanently | | Bing and Copilot | Deferred and inconsistent rendering, treat as the empty shell | | Social and chat link previews | The shell, so previews break |

A site can therefore rank acceptably on Google and be structurally absent from every AI answer. That gap is the reason this work is worth doing in 2026 and was not in 2019.

Workflow

Step 0: Establish builder, hosting and code ownership

Three questions, in this order. The second one matters more than users expect.

1. Which generator produced the site. Fingerprints are in the bundled script and in references/builder-matrix.md. 2. Where it is served from: the platform subdomain (project.lovable.app, project.base44.app), the platform with a custom domain attached, or an exported repository hosted elsewhere (Vercel, Netlify, Cloudflare Pages, a VPS, a bucket). 3. Whether the code is exportable and exported (GitHub connection, ZIP download), and who can deploy it.

Why question 2 decides the plan: platform-side rendering is a property of the host, not of the code. A Lovable or Base44 project that gets server-rendered HTML while hosted on the platform becomes a bare client-side app again the moment the same repository is exported and dropped on a static host. Teams that "took control of their stack" by moving to a static bucket routinely lose indexing this way and blame the migration for something the hosting change caused.

Step 1: Prove what crawlers receive

Never trust a dashboard, an SEO tab, or a "we support SEO" claim. Fetch the URL.

python3 scripts/render_check.py https://example.com/ https://example.com/pricing --soft404

The script fetches raw HTML with no JavaS