Tech SEO foundations on AI-built sites

AI scaffolders like Lovable, Bolt, v0, Cursor, and Replit AI Studio ship sites faster than any agency-led build. The foundations that decide whether those sites show up in search are mostly the same foundations every site needs, with a few specific gaps that AI tools tend to leave open.

John Mueller and Martin Splitt spent most of Search Off the Record episode 110 working through those gaps. The coverage since has framed the episode as a warning. The episode itself is more useful as a description of the foundations and the gaps, both of which are tractable if they're addressed early.

Mueller was direct: there's no ranking bonus for server-rendered HTML over client-side React, and Google does render JavaScript before indexing. The scaffolder will give you a site that ranks, eventually. What it won't give you is a sitemap that stays current, canonicals that match the served URLs, redirects that don't strip your existing ranking, or images sized for the viewport they're served into.

A site that goes live with the foundations in place doesn't need rescuing. Without them, the work gets harder the longer the site has been running.

The rendering layer

Open your homepage in a browser. Right-click, view page source. If you see your headline, paragraphs, links, and a populated body in the HTML, the rendering layer is solid. If you see a near-empty body with one div and a script tag, it isn't.

Google will render the JavaScript and index the populated page eventually. The pressing concerns sit elsewhere. The browser has to download and execute the script before content can paint, which is a Core Web Vitals problem. The crawlers behind major LLMs don't run JavaScript at all, which means the site isn't eligible for citations across AI search surfaces if the HTML is empty.

Lovable's April 2026 update moved new projects onto a server-side rendering framework, which addresses the empty-shell problem out of the box. Older Lovable projects, and most outputs from Bolt, v0, Cursor, and Replit AI Studio, still default to client-side React.

Telling the scaffolder to “make it SEO friendly” doesn't help. That was Mueller's main point. The fix sits at the framework layer, and the choices depend on traffic patterns and on how much rebuilding is on the table.

The sitemap

Visit /sitemap.xml on your own site. Look at the pages listed. Look at the last-modified dates.

A sitemap should be a build artefact that reflects your current URL inventory with accurate dates. AI scaffolders often produce a static file at launch and never touch it again. A six-month-old sitemap that doesn't include pages you've added since is teaching the crawler that your site is dormant.

The diagnostic is fast. If the dates haven't moved and pages you've published are missing, the sitemap isn't doing its job.

Canonicals

Every URL you want indexed needs a canonical tag in its HTML head, pointing to itself. The common failure mode isn't a missing canonical. It's a canonical that points to a different URL than the one being served. Trailing slashes and capitalisation create variants that need to be handled deliberately, as do query parameters.

View source on a few pages across your site. Does the canonical tag match the URL in the address bar exactly? If not, the scaffolder is telling Google to index a URL that may not be the one a visitor is on.

Redirect sequencing

This one trips even experienced teams. When you replace an old blog post with a new hub page, the instinct is to 301 the old URL straight to the new one. Don't.

A 301 strips the old page's standalone ranking ability while the new page is still being indexed and still proving itself in Search Console. The handover can cost months of compounding visibility on the old URL. The sequence that protects the traffic is: publish the replacement, confirm it's indexed and holding position, then add the redirect.

Most teams skip the middle step because nobody told them it mattered.

Hero asset and LCP

The biggest visible element above the fold on most pages is a hero image. That's what Largest Contentful Paint measures. AI scaffolders frequently ship an unoptimised hero, often a high-resolution image served into a small mobile viewport. Changing the image doesn't fix it. Changing how the HTML specifies the image does, which covers what the browser fetches and how it's prioritised.

Run a PageSpeed Insights audit on the homepage. If LCP on mobile is over 2.5 seconds, the hero asset is almost always the cause.

Measurement

Core Web Vitals scores come from two places. Lab data is a snapshot from a single synthetic test. Field data is what real visitors experience, measured over a rolling 28-day window. Google ranks on field data.

A site that has just launched has no field data yet. The lab score gives you an early signal, but the picture only sharpens once real traffic accumulates. Optimising aggressively against lab numbers in the first week means working with a proxy.

Why migrate to server-rendered HTML if it doesn't help ranking

Mueller's “no ranking bonus” line gets quoted often. It's incomplete on its own. There are four reasons to move from client-side React to server-rendered or pre-built HTML that aren't about Google rankings.

First, Core Web Vitals improve when content is in the first response. The browser has less work to do before the page is usable.

Second, AI search surfaces. The crawlers behind major LLMs don't execute JavaScript. If your HTML is empty until the browser runs the bundle, the site isn't eligible for citations across AI assistants and Overview-style features.

Third, defence in depth. Single-page app routing on static hosting can produce soft-404s and other indexability edge cases that disappear when each URL has its own pre-rendered HTML.

Fourth, smaller initial JavaScript payloads reduce execution cost on lower-end devices, which is most of the mobile market outside high-income regions.

The migration buys you better user experience, AI surface eligibility, indexability resilience, and lower mobile execution cost. What it doesn't buy is a ranking boost.

How this looks in practice

The London Bladder Clinic site for Mr Jai Seth started on Lovable. It's a specialist urology practice in central London. The work that's been done on the site, and the work that's still in progress, runs through the same foundations described above. The build is part of our portfolio.

What that engagement has shown is that the foundations are tractable. The rendering layer migrated cleanly. The sitemap generates from a single source of truth at build time, with accurate dates. The canonicals match. The redirects are sequenced against the URLs already ranking, not implemented all at once.

The piece of work still in flight is the hero image and LCP. That's a slower fix, because the right answer depends on how the asset is being served, and the measurement window for confirming the result is 28 days of field data.

The conversation worth having

Mueller's underlying point in SOTR 110 wasn't that AI scaffolders ship broken sites. It was that “make it SEO friendly” is a meaningless instruction. The foundations exist whether the build is by hand or by agency, and now by AI scaffolder. The AI scaffolders accelerate the build while skipping the foundations.

If you've shipped on an AI tool and the traffic report a few months in is flat, starting over isn't usually the answer. The question worth asking is which foundations are missing, and in what order they need attention. The diagnostic on each is a few minutes of work. The fixes are slower.

The sites that show up in twelve months are the ones whose foundations got attention before the traffic data came in.

Sources

Google Search Relations (2026). Search Off the Record episode 110: Vibe Coding, Yay or Nay. youtube.com/watch?v=SPVA6FNX2rw

Search Engine Journal (2026). Google's Mueller: vibe coding won't handle your SEO for you. searchenginejournal.com