SEO AI Site Builders

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:

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 JavaScript execution and reports, per URL: builder and framework fingerprints, word count in the HTML, title, h1, meta description, canonical, meta robots, crawlable internal links, images, JSON-LD validity, and a verdict of SERVER RENDERED, PARTIAL, SHELL ONLY or ERROR. It exits non-zero if any page fails. Useful flags: --sitemap URL --limit N to sample a real site, --ua-compare to detect a crawler-only prerender layer, --json for a report.

The manual equivalent, when a script cannot run:

# Is a sentence from the page present in the HTML
curl -sL https://example.com/page/ | grep -c "a sentence you can see on the page"

# What the document actually contains
curl -sL https://example.com/page/ | head -50

# As an AI crawler
curl -sL -A "Mozilla/5.0 (compatible; GPTBot/1.2; +https://openai.com/gptbot)" https://example.com/page/ | wc -w

Test five URLs, not one. The homepage is the page platforms prerender first and the one every vendor demo uses. Sample: homepage, a service or product page, a blog post, a dynamic detail route (an item fetched by id or slug), and a filtered or paginated list. Mixed verdicts across that sample are the normal result and they change the recommendation: partial coverage means the prerender layer skips dynamic routes, which is exactly where the long tail lives.

Verdict thresholds used throughout this skill:

Record the numbers. They are the before column of the deliverable and the only honest proof the work changed anything.

Step 2: Read the platform status, then re-verify it

Per-platform detail, native SEO controls and gotchas: references/builder-matrix.md. The short version, as of August 2026:

Two rules attach to that table:

• A platform-side fix disappears with the platform. Treat "SSR on Lovable hosting" and "snapshots on Base44 hosting" as hosting features. Write that down before anyone plans an export.
• Prerendering that is served only to crawlers is dynamic rendering, whatever the vendor calls it. It works, and Google classes it as a workaround rather than a long-term solution (https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering). Accept it as a stage, not a destination.

Step 3: Choose the route

Decision shortcuts:

• Marketing site, portfolio, local business, brochure with a blog: Route B. Nothing on those pages needs a server at request time.
• Product-led app where marketing pages and the app live in one repo: split them. Prerender or migrate the public routes, leave the logged-in app client-rendered. Nobody indexes a dashboard.
• E-commerce, listings, anything with thousands of database-driven URLs: Route C. Build-time prerendering of 10,000 routes that change hourly is a build queue problem in disguise.
• No code export possible: Route D, and price the honest alternative of rebuilding the public pages elsewhere. On Bubble, Softr and Glide the public marketing site is usually 5 to 15 pages, which is a weekend on Astro against a permanent prerendering subscription.

Anti-pattern to name explicitly: shipping Route D while telling the client the site is now server-rendered. Two versions of the truth exist from that day on, and prerender caches fail silently after a deploy. If Route D is chosen, the monitoring in Step 6 is part of the deliverable, not an option.

Concrete configurations for each route, with the code: references/prerender-recipes.md.

Step 4: Specify the HTML each page must serve

Whatever route runs, the target is the same. Every indexable URL returns, in the initial HTML response, before any JavaScript:

Client-side patterns that survive a prerender and still lose the content, with their replacement:

Step 5: Routing, status codes and hosting

Rendering fixes the body. These fix everything around it, and each one has cost real sites their indexation.

• Real 404 status. The classic single page app host rewrite (/* -> /index.html 200) answers 200 for every URL that does not exist, so typos, dead links and deleted pages all become soft 404s that dilute the site. Serve a real 404 for unknown routes. The bundled script's --soft404 flag detects this in one call.
• Path routing, never hash routing. URLs of the form example.com/#/pricing are one URL to a crawler. Move to the History API before anything else, since prerendering hash routes is not possible.
• One canonical host. Pick www or apex, 301 the other in one hop, and keep the platform preview subdomain out of the index: the .lovable.app, .base44.app, .vercel.app or .netlify.app copy competes with the production domain for the same content. Serve noindex on the preview host, or canonical it to production.
• Check for a leftover noindex. Preview and staging environments on these platforms often ship X-Robots-Tag: noindex or a meta robots noindex, and it survives the move to the custom domain more often than it should. It is the single most common cause of "we did everything and nothing got indexed".
• Sitemap generated from the same route manifest that drives prerendering. A hand-written sitemap and a generated route list diverge within two deploys. Reference the sitemap in robots.txt, then submit it in Search Console.
• Do not disallow /assets/ or the JS and CSS paths in robots.txt. Googlebot needs them to render, and a blocked stylesheet degrades what it sees.
• Trailing slash consistency. Prerenderers emit /about/index.html, hosts differ on whether that answers at /about or /about/. Pick one, 301 the other, canonical to the winner.

Step 6: Verify, then keep verifying

Immediately after deploying the fix:

1. Re-run the script on the same five URLs and put the before and after word counts side by side. That table is the deliverable's proof.
2. Search Console URL Inspection on two of them, and read the crawled HTML, not the screenshot.
3. Fetch one URL with a GPTBot user agent and confirm the content is there.
4. Confirm unknown routes return 404 and the preview subdomain is out of the index.
5. Resubmit the sitemap and note the indexed to submitted ratio in Search Console so the recovery is measurable.

Then schedule a recurring check, monthly at minimum, and mandatory after every deploy that touches routing or the build. Prerendering and SSR fail quietly: a build config change, a new dynamic route, an expired prerender cache or a platform migration reverts the site to shells without any visible symptom in the browser. Route D setups need this most, since nothing a human sees ever changes.

Recovery timing to set expectations honestly: Google must recrawl before anything moves, so allow weeks rather than days on a site of any size. AI engines are slower still, because a page has to be recrawled, then reselected as a source. Nothing in this work produces a same-week result, and promising one is how these projects lose credibility.

Rules and thresholds

GEO layer

Everything above is doubly true for AI answer engines, and one thing is specific to them.

An engine that cannot fetch content does not fall back to guessing politely: it either omits the brand or reconstructs it from third-party pages (directories, marketplaces, review sites, Reddit threads). So a shell site does not produce silence, it produces answers about the brand written entirely by other people. That is why the recovery in AI citations after this work often outpaces the recovery in Google rankings: the pages become quotable for the first time, in a space where competitors published quotable HTML years ago.

Sequencing that follows: get the HTML served, then apply the geo-visibility skill to make the passages quotable, then the geo-tracking skill to measure. Doing GEO content work on a client-rendered site is writing for an audience of nobody.

Rendering also decides what the model learns about the brand outside of search. Training crawlers read the same empty shell, so a site that spent two years client-rendered contributed nothing to model weights in that period. Fixing the rendering starts that clock; it does not rewind it.

Output format

Deliver a decision, not a lecture on rendering.

# Rendering audit: {domain} ({date})

## What crawlers see today
Table: URL, verdict, words in HTML, title present, h1 present.
One line naming the builder, the host, and whether code export exists.

## Consequence
Which engines can read the site today and which cannot, in one short paragraph.

## Recommended route
Route A, B, C or D with the reason it beats the others here, the effort estimate,
and what it costs to run.

## Changes to make
Ordered list, each with the file or setting it touches and the expected result.
Rendering first, then routing and status codes, then the per-page HTML checklist.

## Verification
The exact commands to re-run, and the before numbers to beat.

## What this will not fix
Named honestly: thin content, no links, no demand for the topic.

Every verdict carries its evidence: the URL fetched and the word count observed. Never report a rendering problem without the number, and never report a fix without the after number.

Common mistakes

Sources

• AI crawlers do not execute JavaScript, 500M+ fetches analyzed: https://vercel.com/blog/the-rise-of-the-ai-crawler
• AI search and JavaScript rendering: https://www.gsqi.com/marketing-blog/ai-search-javascript-rendering/
• Google on dynamic rendering as a workaround, not a long-term solution: https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering
• Google no longer recommends dynamic rendering: https://searchengineland.com/google-no-longer-recommends-using-dynamic-rendering-for-google-search-387054
• Lovable rendering and SSR status: https://docs.lovable.dev/features/upgrade-to-tanstack-start and https://lovable.dev/seo-aeo
• Base44 product changelog (SEO and crawler snapshots): https://docs.base44.com/changelog/product
• Base44 SSR and SSG feature requests, platform status in the open: https://feedback.base44.com/p/add-ssr-server-side-rendering-support
• Static generation for Vite React apps: https://github.com/Daydreamer-riri/vite-react-ssg
• Field heuristics: 115+ agency audits, labeled as such throughout