There’s a conversation we keep having. A company pays for a beautiful, modern website, everything works smoothly, visitors like it — then someone types “who is the best [trade] in [city]” into ChatGPT, and the company isn’t in the answer. Worse: ask the model about the company by name and it can barely say anything, even though it’s all on the site.
The model isn’t the one failing. The site is almost empty to a machine.
Mistake one: what happens when content only appears after JavaScript?
Client-side rendering is the most serious of the four mistakes, and the most expensive sites get it wrong. Most modern frameworks assemble the page in the browser: the server sends a near-empty shell, and the text only lands in it after the code runs. aiseo42 therefore builds every website with server-side rendering.
A significant share of AI crawlers do not execute JavaScript, or only do so partially. Whatever isn’t in the raw HTML doesn’t exist for them.
A one-minute test: disable JavaScript in your browser and reload your own site. Roughly what you see is what a crawler sees. If you get an empty shell, you have your answer.
This isn’t a setting. It’s architecture: either the system renders on the server, or it doesn’t.
Mistake two: why does hand-maintained structured data drift?
Structured data is the machine layer that states, as data rather than prose, what a page represents: a product with a price and stock level, a company with an address and opening hours, an article with an author and a date.
The problem is that on many sites this is filled in by a plugin or a person, separately from the visible content. Then the price changes on the page — and not in the declared data. From that moment the site tells the machine something different from what it tells the human, and search engines specifically penalise that.
The right answer isn’t “have some schema”. It’s that the schema is generated from the same source as the visible content. Then it cannot drift, because it is the same data.
Mistake three: why do you need a machine-readable version?
The missing machine-readable mirror is the third common mistake. A language model doesn’t like noise: menus, cookie banners, footers and design markup are all content it has to chew through to reach the substance, and every such layer is another chance to misread. aiseo42 produces a plain-text version alongside every page — this page is available that way too.
There are two cheap and very effective answers:
- A per-page content mirror: the same text, without markup, in clean form, reachable at the same path and declared in the HTML head.
llms.txtand a full content dump: a concise list of facts and pages with dates, plus the entire content in a single file. A few kilobytes from which a model understands the whole company in one request.
This is the best value item on the whole list, and it’s the one most often missing.
Mistake four: what makes a text citable?
Models don’t rank pages, they lift paragraphs. That requires sentences that stand on their own.
| Not citable | Citable |
|---|---|
| “With years of experience, we are at our clients’ disposal.” | “A custom online store takes 6–10 weeks to build, and the source code stays with the client.” |
| “We build fast, modern websites.” | “TTFB 0.065 s, measured from our own server, 14 August 2026.” |
| “Our clients are satisfied.” | “192 indexed URLs, zero structured data errors (Google Search Console).” |
The rule is simple: a subject-verb factual statement, with a number, a source and a date. Two other things help a lot: a 40–70 word self-contained summary at the top of every page, and headings that are the questions people actually search for.
What exactly does an AI-ready build contain?
- Server-rendered output — content is real text in the raw HTML.
- Structured data generated from the actual content — not by hand, not from a separate source.
- A machine-readable content mirror for every page, declared in the head.
llms.txtand a full content dump — facts, page list, dates.- A citable structure — summary up front, question headings, sourced numbers.
- A permissive
robots.txt— GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended and the rest, by name. - Speed, measured — not as a promise but as a report, so there’s something to compare against later.
- A visible update date written by the system, not by a person.
Seven of these eight can only be done cheaply at build time. All of them are solvable afterwards somehow — but “somehow” here means more expensive and more fragile.
What should you do now if this applies to you?
If you have a site: run the JavaScript test and check your structured data with Google’s Rich Results Test. If both are fine, you don’t need to build — you need content and visibility, which is what the GEO/AEO program is for.
If the site itself is the problem, or there is no site yet: it’s worth building AI-ready from the start, because those eight items then cost nothing extra. That’s what we do — the full service description is on the website development page.
Development is also carried out by the same workshop under the RootCR name (rootcr.com), where the complete technical breakdown — and live, measured client examples — can be found on the AI search visibility page and under case studies.
The point in one sentence: AI visibility isn’t a package you can add to a finished website — it’s the way that website gets built. That is why aiseo42 treats the eight items above as part of the build, not as an upsell afterwards.