Static-first website architecture: fast, cheap and readable by AI search

What static-first means

Pages are rendered once, at build time, and served as files from a CDN. Interactivity is added only where a page needs it, and a server runs only for the few things that truly need one: forms, sign-in, payments. Everything else is HTML that is already there when the request arrives.

Three layers

1. Content — Markdown, a headless CMS or plain HTML, versioned in git where possible.
2. Build — a generator turns content into pages: Astro, Next.js static export, Eleventy, Hugo, or a short script. It also produces the sitemap, the RSS feed, translations and AI-facing files, and fails on broken links.
3. Edge — a CDN with redirects, cache and security headers, plus a handful of serverless functions.

content/ ──► build ──► dist/ ──► CDN
             ├─ render pages (one per language)
             ├─ sitemap.xml, feed.xml
             ├─ llms.txt, llms-full.txt
             └─ check links, image sizes, page weight

Where the dynamic parts go

• Forms — a serverless endpoint or a form service; the page itself stays static.
• Search — an index built at build time (Pagefind, for example) and queried in the browser.
• Prices, stock, availability — rebuild on change, revalidate on a timer, or fetch that one block on the client.
• Personalisation — after the page has loaded, or in edge middleware; never by making the whole page dynamic.

Why it matters for AI search

Many crawlers behind ChatGPT, Perplexity and other assistants read the initial HTML and do not run your JavaScript. If your content appears only after hydration, for them it doesn't exist. A static-first site gives them:

• the full text in the first response;
• structured data (JSON-LD) for the organisation, people, services and articles;
• a separate pre-rendered URL per language, linked with hreflang;
• llms.txt and a full-text llms-full.txt that summarise the site for assistants.

This site works that way: plain HTML, a small build script that pre-renders the Ukrainian and Czech versions, the sitemap and llms-full.txt, and nothing that needs a server except the contact form.

A performance budget you can keep

• Core Web Vitals: LCP under 2.5 s, INP under 200 ms, CLS under 0.1.
• Self-host and preload the one or two fonts you use; give every image its dimensions.
• No render-blocking third-party scripts; load analytics only after consent.
• Check page weight in the build, so it fails before a heavy page ships.

When not to go static

Dashboards, logged-in products and real-time tools are applications, and should be built as such. Even then, keep the public pages static and separate — www for the site, app for the product — so marketing changes never wait on an app release and the app never slows the site down.