Guides / Prompting and shipping

SEO for AI-Built Websites: What Actually Matters

Why AI-built single-page apps can struggle in search, and how to fix it: prerendering, titles and meta tags, sitemaps, structured data, speed and content.

Mythex Team · 2026-09-29 · 8 min read

An AI-built website can rank as well as any other: search engines judge what the page contains and how well it serves the visitor, not which tool wrote the code. The catch is technical. Many AI builders produce single-page apps that send the browser an almost empty HTML file and draw the content with JavaScript, which makes each page harder for crawlers to read and share. Fix that with prerendering or server rendering, give every page its own title, description and URL, add a sitemap, keep it fast, and then do the part no tool does for you — write content people are searching for.

Why single-page apps can struggle in search

A traditional website sends the full text of each page in its HTML. A single-page app (SPA) — the default output of many AI builders, typically React with a tool like Vite — sends a small HTML shell, something like an empty <div id="root">, plus a JavaScript bundle. The browser runs the JavaScript, which then builds the page.

That matters for search in three ways:

1. Rendering is an extra step. Google describes three phases for JavaScript pages: crawl the HTML, render it in a headless Chromium browser, then index the rendered result. Google's own guidance says server-side rendering or prerendering is still a good idea because it is faster for users and crawlers, and because not all bots can run JavaScript.
2. Other readers of your page do not render at all. Link previews in chat apps and social networks, and many other crawlers, typically read only the initial HTML. If your title and preview image are set by JavaScript after load, those previews show the empty shell's defaults — often the same title on every page.
3. Everything shares one HTML file. Unless the app updates it, every URL has the same <title> and description, which tells search engines little about each page.

None of this means an SPA cannot be indexed. It means you are relying on the crawler to do more work, and you lose control of what non-rendering readers see.

Choose a rendering approach

There are four common ways to get real HTML to crawlers. In rough order of how much they change your app:

A practical rule: the public, searchable part of your site should be static or prerendered; the logged-in app behind it can stay a normal SPA. Search engines should not be indexing dashboards anyway.

If you are starting from scratch and SEO matters, say so in the first prompt so the AI picks a suitable setup:

Build a marketing site for a physiotherapy clinic with pages for Home, Services (one page per service), About, Pricing and Contact. SEO matters: each page must ship its full content and its own title and meta description in the initial HTML — use a static or prerendered setup, not a client-only single-page app.

If you already have a Vite SPA, ask for prerendering of the public routes:

Keep this React app as it is, but prerender the public routes (/, /pricing, /about, /blog and each /blog/:slug) to static HTML at build time, each with its own title, meta description, canonical URL and Open Graph tags. The logged-in /app routes can stay client-rendered.

Afterwards, check the result yourself: open a page, choose View page source (not the dev tools Elements panel, which shows the rendered page) and confirm the text and title are in the raw HTML.

Get the on-page basics right

These apply whatever the rendering approach.

Titles and meta descriptions

• One unique <title> per page, with the page's main topic first. Around 50–60 characters is a common guideline because longer titles tend to be cut off in results.
• One unique meta description per page — a sentence a person would want to click, not a keyword list. Google may rewrite it, but a good one is often used.
• Skip meta keywords. Google says the tag has no effect on indexing or ranking.

URLs, headings and links

• Real URLs for real pages. Each piece of content needs its own path (/services/sports-massage), not a tab or modal that only exists after a click. Avoid # fragment routing for content you want indexed.
• One h1 per page, then a sensible h2/h3 outline. AI-generated designs sometimes use headings for styling; ask for semantic headings.
• Crawlable links. Use real <a href> links for navigation. Buttons that change the page with JavaScript are invisible to crawlers that follow links.
• Canonical tags that point each page at its preferred URL, so ?utm= variants and trailing-slash duplicates do not compete.
• Descriptive alt text on meaningful images.

Social previews

Add Open Graph tags (og:title, og:description, og:image, og:url) to every public page, in the initial HTML. This is the part SPAs most often get wrong, because link preview bots do not run JavaScript.

Sitemaps and robots.txt

A sitemap is an XML file listing the URLs you want indexed. It helps search engines find pages, especially on new sites with few inbound links. According to Google's documentation, as of September 2026:

• A single sitemap can hold up to 50,000 URLs or 50 MB uncompressed; split larger sites with a sitemap index.
• Google ignores <priority> and <changefreq>.
• Google uses <lastmod> only if it is consistently accurate, so update it for real content changes, not on every build.

A robots.txt file tells crawlers which paths not to crawl. Use it to keep crawlers out of /app, /admin and API routes, and point to the sitemap from it. Remember that robots.txt stops crawling, not indexing: to keep a page out of results, use a noindex robots meta tag and let it be crawled.

Submit the sitemap in Google Search Console once the site is on its final domain. Search Console also shows which pages are indexed and why others are not — the most useful free SEO tool there is.

Structured data

Structured data is machine-readable markup that describes what a page is: an organisation, a local business, a product, an article, an event. Google recommends the JSON-LD format and is clear on two points:

• It can make pages eligible for rich results but does not guarantee them.
• It must describe information visible on the page. Do not mark up reviews, prices or FAQs that visitors cannot see.

Sensible starting points: Organization or LocalBusiness on the home page, Product on product pages, Article on blog posts, BreadcrumbList on deep pages. Test with Google's Rich Results Test.

Add JSON-LD structured data: LocalBusiness on the home page using the address, phone and opening hours already shown on the page, and Article on each blog post. Do not add ratings or reviews.

Speed and mobile

Google uses page experience signals, including Core Web Vitals, and speed matters to visitors regardless. Google's "good" thresholds, measured at the 75th percentile of page loads, are:

The usual fixes for AI-built sites:

• Images — resize, compress, use modern formats, set width and height (which prevents layout shift), and lazy-load below the fold.
• JavaScript — a large bundle delays everything on an SPA. Prerendering helps; so does splitting code per route.
• Fonts — limit families and weights and preload the one used above the fold.
• Third-party scripts — every chat widget and tracking pixel costs speed. Keep the ones you use.

Test the live URL with PageSpeed Insights or Lighthouse in mobile mode.

Content is still most of it

Technical SEO removes obstacles; it does not create demand. Pages rank because they answer a search better than the alternatives. For most small sites that means:

• One page per topic people search for. A plumber needs a page per service and per area served, not one "Services" page listing everything.
• Specific, original detail — prices, process, photos of real work, answers to the questions customers ask on the phone.
• Updated when things change. Stale hours and old prices lose trust fast.

AI can draft pages quickly, which makes it tempting to publish lots of thin, similar ones. Google's guidance targets content made mainly to rank rather than to help people, however it was produced. Use AI to draft, then add what only you know. Directory-style sites face this most; see how to build a directory website for how to make listing pages worth indexing.

Launch checklist

• Public pages ship full content in the initial HTML (check View page source)
• Unique title, meta description and canonical URL on every page
• Open Graph tags and a share image on every public page
• One h1 per page, real <a href> links, alt text on images
• sitemap.xml with real URLs; robots.txt blocking app and API paths
• Structured data only for visible content, tested
• LCP, INP and CLS in the "good" range on mobile
• Site on its final domain with HTTPS and submitted to Search Console

Moving to your own domain before you start building search traffic avoids redirects later — see how to connect a custom domain. For the wider build process, read how to build a website with AI, and for pages meant to convert visitors, how to build a landing page that converts.

SEO on Mythex

Mythex does not have a separate SEO panel; you improve SEO by changing the app through chat or code. New web apps default to a Vite and React single-page app, so when search matters, ask for a static or prerendered site, or for Next.js, from the start. The docs have a starter prompt for titles, Open Graph tags, sitemap and robots.txt in SEO for your app, and static websites covers content-focused sites. After changes, publish again so the live site picks them up. Custom domains are available on Pro.