We've Seen "AI-Friendly Websites" Before. They Were Called WAP Sites.
We Have Been Here Before
Many people working in SEO and digital today will not have been in the industry long enough to remember WAP sites.
But some of us do.
Before responsive design became normal, websites often had separate mobile versions. They were built for small screens, weak devices, slow connections and browsers that could barely cope with the desktop web. Sometimes they were WAP sites. Sometimes they were m-dot sites. Sometimes they were just thin mobile templates held together with device detection and redirect rules.
The current rush towards LLM optimisation has a familiar shape. We are seeing proposals for AI-friendly website versions, AI-only files, summarised feeds and extra layers designed to help large language models understand content. Some of that work is sensible. Some of it may become useful. But the pattern should make technical SEOs pause.
The practical route is simple: do not build a separate AI version of a poor website. Build a better website that humans, search engines and AI systems can all understand.
The WAP Site Era Was Not Stupid
WAP sites were a reasonable response to a real problem. The desktop web was not built for early mobile devices. Pages were heavy. Layouts were fixed. Navigation was awkward. Connections were slow. Devices had tiny screens and limited browser support.
So the industry created lighter versions of websites. These often had:
- Separate mobile URLs.
- M-dot domains or subdomains.
- Reduced content.
- Simplified navigation.
- Stripped-down templates.
- Device detection.
- Redirect rules.
- Separate QA paths.
- Different content publishing workflows.
That was not irrational. It solved an immediate access problem. If the main website was too heavy or too awkward for mobile users, a lightweight mobile version was better than nothing.
This is the part worth remembering. Transitional solutions often look sensible when the platform is not ready. The mistake is assuming the transitional solution is the destination.
Why Separate Mobile Versions Became Technical Debt
The problems came later. Once a business had a desktop site and a separate mobile version, it had two things to maintain. Content drifted. Templates diverged. Redirects broke. Canonical signals became messy. Analytics split across different URLs and journeys.
Technical SEO became more complicated than it needed to be. Teams had to ask whether Googlebot saw the desktop page, the mobile page, the right canonical, the right redirect and the same content. Developers had more templates to maintain. Content teams had more places to update. QA had more combinations to test.
| Separate mobile problem | What it created |
|---|---|
| Desktop and mobile URLs | Redirect, canonical and indexing complexity |
| Reduced mobile content | Inconsistent user experience and content parity issues |
| Separate templates | More development and QA effort |
| Device detection | Failure points for crawlers and real users |
| Fragmented measurement | Messier reporting and attribution |
The industry eventually realised that maintaining parallel versions was not a strong long-term platform strategy. It was a workaround. Useful for a moment, expensive over time.
What Actually Solved the Mobile Problem
The long-term answer was not a separate mobile web. It was a better web by default.
Responsive design matured. CSS improved. Front-end delivery improved. Networks got faster. Devices got better. CMS platforms and design systems became more flexible. Performance optimisation became part of serious web work. Accessibility became harder to ignore. Mobile-first thinking changed how teams planned pages.
The best websites stopped treating mobile as a bolt-on. They made the core experience work across devices.
That lesson matters for LLM optimisation. The future is unlikely to be a separate version of every website for every AI system. The stronger route is a core website that is fast, structured, accessible, crawlable and useful. If your site architecture is already weak, our guide to site architecture for SEO is a better starting point than another AI-facing file.
The Modern Parallel: LLM Optimisation Layers
The LLM optimisation discussion is now creating its own version of the separate-site problem. We are seeing recommendations around llms.txt, llms-full.txt, ai.txt, schema.txt, AI-specific summaries, separate content feeds and AI-only instructions layered on top of existing websites.
Some of this is worth testing. llms.txt is sensible in principle when it acts as a clear signposting file for important content and usage guidance. We already covered the practical side in our llms.txt technical SEO guide. llms-full.txt may have value in controlled cases, especially for documentation-style sites, but it can quickly become bulky and hard to keep aligned. ai.txt is interesting, but risks becoming another instruction layer with uncertain adoption.
schema.txt is where I become more sceptical. Structured data already has recognised formats and expected locations. It should live on the page, in JSON-LD or another supported format, aligned with visible content. Moving schema into a separate text file because AI is fashionable feels like solving the wrong problem. If structured data is weak, fix the implementation. Our guide to structured data and schema for technical SEO is the more durable route.
The issue is not experimentation. The issue is mistaking extra layers for real optimisation.
What LLMs Actually Need from Websites
Most LLM-friendly principles overlap with good SEO, good UX and good web development. That should not be surprising. Systems that retrieve, parse, summarise or cite web content benefit from the same things search engines and users benefit from.
A useful website for AI systems usually has:
- Clear, accessible HTML.
- Crawlable content.
- Strong internal linking.
- Logical site architecture.
- Consistent entity information.
- Fast page delivery.
- Minimal JavaScript rendering friction.
- Useful structured data.
- Clear authorship and trust signals.
- Content that answers real questions.
- Stable canonical pages.
- Concise summaries where they genuinely help.
LLM-friendly usually means human-friendly and search-friendly. If the content only appears after fragile client-side rendering, if internal links are weak, if the page is slow, or if the main answer is buried under boilerplate, an AI-specific file is not the first fix. The same applies to JavaScript-heavy sites, where rendering pipelines and JavaScript SEO still matter before any GEO layer is added.
Generative engine optimisation is not separate from the rest of technical SEO. It sits on top of it. For the wider strategy, our GEO strategy guide covers how AI visibility depends on clarity, authority and retrievable information.
The Risk of AI-Only Technical Debt
The risk is not that businesses create one useful file. The risk is that every new AI recommendation becomes another asset nobody owns.
Files become outdated. Summaries drift from the real page content. Feeds tell a different story from the canonical page. Product teams forget who maintains the AI layer. Content governance becomes harder. Developers inherit another platform responsibility. Stakeholders are told the AI problem has been solved because a file exists.
That is how technical debt gets a marketing budget.
A weak core website wrapped in AI files is still a weak website. If it is slow, unclear, inaccessible or hard to crawl, an AI-facing file will not fix the underlying problem. It may even hide the problem for a while, which is worse.
This is where performance comes back into the discussion. If pages are bloated, unstable or slow to respond, start with the basics. Our Core Web Vitals guide is not only a UX resource. It is part of building a cleaner, more reliable website for every discovery system.
A Better Approach to LLM Optimisation
The practical position is not anti-AI. It is anti-waste.
Use recognised standards where they add value. Test llms.txt if it helps signpost important material. Keep AI-facing files lightweight, maintained and aligned with the real website. Avoid duplicating large amounts of content unless there is a clear operational reason. Make sure someone owns the asset after launch.
The priority order should be:
- Build the core website properly first.
- Make important content crawlable, indexable and internally linked.
- Improve performance, accessibility and HTML clarity.
- Add structured data where recognised formats support the page.
- Use AI-facing files as signposts, not substitutes.
- Keep every additional layer small, current and accountable.
Think in terms of platform quality, not AI hacks. The future is not about maintaining a separate version of your website for every new discovery platform. That path leads back to the WAP site problem, just with newer file names.
Final Takeaway
WAP sites were useful for a moment because the web had not yet caught up with mobile behaviour.
But they were not the destination.
The destination was responsive, performant, accessible websites that worked well by default.
LLM optimisation may follow the same path. Some AI-specific files and standards may be useful bridges, but the real long-term advantage will come from better websites.
Fast. Clear. Crawlable. Lightweight.
We have seen this pattern before. The technology changes, but the principle does not.
Related Reading
- What is llms.txt?
- GEO strategy guide
- Structured data and schema for technical SEO
- JavaScript SEO rendering pipelines