How to Build a Website for SEO and AI Search
Choosing a website build that Google and AI crawlers can actually read, trust and quote from
The short version
Before you touch positioning, content, or schema, one decision determines whether any of it can be seen at all: how your site turns into HTML.
Guide 1 covered how AI systems decide who to trust, and mentioned in passing that crawlers which don't run JavaScript are a real risk. This guide goes deeper on that point, because it should be one of the first things you check — not a footnote — when you're starting a new site or deciding whether an existing one needs rebuilding. It also covers what a platform needs to offer technically regardless of which one you pick.
Worth checking right now, before you read any further: right-click your homepage, choose "View Page Source" (not "Inspect"), and search the raw HTML for a sentence of your own body copy. If it isn't there, keep reading — this guide explains why that matters and what to do about it.
The rendering risk that decides everything else
(Formal label: client-side rendering vs server-side rendering)
A website can be built two fundamentally different ways under the hood, and the difference is invisible to a human visitor but potentially total to an AI crawler.
Server-rendered (or static) HTML means the words, headings, and links your visitor reads are already present in the file the server sends over. Anyone or anything that fetches that file — a browser, a crawler, a basic command-line request — gets the actual content immediately.
Client-side-rendered HTML means the server sends a mostly empty page plus a bundle of JavaScript, and the JavaScript builds the visible content in the visitor's browser after the page loads. A human in a modern browser doesn't notice any difference — the page still looks complete. But a system that fetches the page and doesn't run that JavaScript gets the empty shell and nothing else.
That second case is the normal situation for most AI crawlers today. GPTBot (ChatGPT), ClaudeBot, and PerplexityBot do not execute JavaScript. They fetch a page, read the raw HTML, and move on. If your content only exists after JavaScript runs, these crawlers see a blank page — there is nothing for them to extract, quote, or cite, no matter how good the writing is or how well the page is structured otherwise.
This is a genuine, checkable technical risk, not a theoretical one. It also cuts across every other technique in this guide series: excellent entity signals, perfect schema, and deep authority content are all worthless to an AI system if the crawler never sees the words in the first place.
One important wrinkle: Googlebot is not a fair test of this. Google runs a rendering service that does execute JavaScript, on a delay, as part of indexing — so a site can rank perfectly well on Google while still being invisible to GPTBot, ClaudeBot, and PerplexityBot. Ranking on Google tells you nothing about whether you pass this test. You have to check it directly.
How to check it yourself
Three ways, in order of ease:
- View source, not Inspect. Right-click the page → "View Page Source." This shows you the raw HTML as delivered, before any JavaScript runs. Search it for a distinctive sentence from your own copy. If it's missing, that content doesn't exist as far as a non-JS crawler is concerned.
- Disable JavaScript and reload. Most browsers let you do this in developer tools (or via an extension). Reload the page. What's left is roughly what a non-JS crawler sees.
- Fetch it from the command line. A basic request (e.g.
curlthe URL) and search the output for your content. This is the closest simulation of what GPTBot actually does.
If your content is missing in all three, an AI crawler almost certainly sees the same blank page you do with JavaScript switched off — regardless of how the site looks to a human visitor.
The three ways to build a site today
There are three broad approaches, and the rendering question above should be one of the deciding factors between them — not an afterthought you check once the site's already built.
| How content typically renders | Who can maintain it | Where the JS risk usually creeps in | Best suited to | |
|---|---|---|---|---|
| WordPress | Server-rendered by default — the core software builds pages on the server | Non-technical users, via a dashboard; large ecosystem of SEO/schema plugins | Specific themes and page-builder plugins can shift content-rendering to the browser, even though the platform itself doesn't require this | Teams who want to edit content directly without a developer, and are willing to check the specific theme/plugin combination against the test above |
| Static site generator | Pages are built to plain HTML files ahead of time — the safest default against the rendering risk | Usually needs a developer, or someone comfortable with basic code, for structural changes | Some frameworks in this category also support optional client-rendered modes or heavy interactive components — the category name describes a default output, not a guarantee | Teams with development resource who want durability and don't need a visual drag-and-drop editor |
| AI website builder | Varies significantly by tool, and changes as the tools update — this is the category to verify most carefully | Fastest route to a working site, no code or developer needed | Highest uncertainty as a category: prompt-to-website tools optimise for a fast, polished visual result, and a lot of tooling in this space (and in the no-code builder space before it) ships output that only renders fully in the browser | Fast prototyping, campaign pages, or genuinely low-stakes sites where AI-crawler visibility is an acceptable trade-off for speed |
A few things worth being direct about:
- "WordPress" isn't automatically safe, and "static site generator" isn't automatically safe either. Both are categories, not guarantees. The platform name tells you the default tendency, not the outcome — the actual theme, plugin, or framework configuration decides it. Run the test above on the specific build, not the category.
- AI website builders are the category with the least verifiable rendering behaviour, precisely because the point of the category is speed and a good-looking result, and rendering approach isn't something these tools typically publish or guarantee. If a site's job is to be found and cited by AI search, that's a real tension worth resolving before you commit content to one — see the test above, and run it on a trial page before you build the whole site on the platform.
- None of this is a verdict against any specific product. It's a reason to test the actual build you're looking at rather than assume the category name settles the question.
The technical foundations every platform needs
(Formal label: entity markup and technical hygiene)
Passing the rendering test gets your content in front of the crawler. These are the things that help the crawler (and Google) understand and trust what it's looking at, once it's there. They're platform-agnostic — WordPress, a static site, or a builder can all support them, though how easy that is varies.
Site-wide entity information. This is your business's identity card in code form — it should be consistent across every page, not re-typed per page.
| Field | Purpose | Example |
|---|---|---|
| Legal name | Registered company name | ShadeHaus Eyewear Ltd |
| Trading name | Client-facing name | ShadeHaus |
| Logo | Logo image, referenced consistently | /assets/logo.svg |
| Founding date | When the business started | 2021 |
| SameAs | Links to your social/profile URLs — ties your identity together across platforms | Instagram, LinkedIn, YouTube |
| Contact points | Email, phone, contact page | hello@example.co.uk, /contact |
| Areas served | Geographic scope | United Kingdom, European Union |
Meta titles and descriptions. Unique per page, plain language, no keyword stuffing. A meta description written in a direct-answer style ("X does Y, here's how it works") tends to double as a reasonable extraction target — the same discipline that helps a Google snippet helps an AI summary.
Performance and accessibility basics. Mobile-friendly, fast-loading, minimal unnecessary scripts, descriptive (not keyword-stuffed) image alt text, a working cookie-consent mechanism if you use cookies. None of this is exotic, and most of it also reduces the odds of accidentally shipping a JS-dependent page in the first place — heavy client-side scripting is usually where both problems come from at once.
A visible freshness signal. A "last reviewed" date, kept genuinely current. Stale content with an old date undermines trust for a human reader and is a weaker candidate for AI systems that weight recency, particularly on anything time-sensitive.
None of these fixes the rendering problem if you have one — they sit on top of it. Get the rendering test right first; these are the layer above it.
Should you rebuild, or fix what's there?
If you're deciding whether an existing site needs a full rebuild rather than incremental fixes, run it through this order:
- Fails the rendering test. This is the strongest rebuild signal in this guide. If your actual content isn't in the raw HTML, no amount of content or schema work fixes that — the underlying build has to change, even if that means migrating the existing content onto a different rendering approach rather than starting from zero.
- Passes the rendering test, but the technical foundations above are patchy or inconsistent. This is a fix-in-place situation, not a rebuild — add the missing entity markup, tidy the meta data, put a freshness date on pages. The site's core is sound.
- Passes both, but the content and structure aren't doing the job. That's not a build problem at all — that's the next guide's territory.
Worth saying plainly: a site can look modern, load fast, and win design awards while still failing step one. Rendering approach and visual quality are unrelated; you have to check the first one directly, the way described above.
Where to go next
This guide covers how to build the technical foundation itself — the platform choice and the rendering question underneath it. Guide 4 covers what to actually build on top of that foundation: the page types, structure, and content that get a site cited once an AI crawler can see it.