We’re Building Websites Backwards: An Information-First Architecture for the AI Web

We’re Building Websites Backwards: An Information-First Architecture for the AI Web

Most websites begin with a sitemap. Someone decides the company needs a homepage, product pages, an About page, perhaps some integrations, documentation, case studies and a blog. Designers turn those requirements into interfaces, developers turn the interfaces into components, and a CMS provides somewhere to store everything.

Only later do we begin describing what all of those pages actually mean. We add structured data so search engines can identify products, organisations and people. We create internal links to establish relationships between documents. APIs expose particular pieces of functionality. Search engines crawl the resulting site and reconstruct some understanding of the organisation from its pages. AI retrieval systems are increasingly expected to do the same.

I've started to think this process is backwards. The problem isn't that pages are the wrong way to present information to people; they're extremely good at that. The problem is treating the page as the canonical object and then repeatedly attempting to reconstruct the information underneath it for every other consumer.

A product is not a product page. A person is not an author page. A service is not a service page, and an integration is not an integration page. Those pages are representations of things that exist independently of the interface.

This distinction isn't entirely new. The W3C's Architecture of the World Wide Web has long distinguished between resources and their representations, as well as the separation of content, presentation and interaction. What is changing is the number and sophistication of systems attempting to understand those resources.

A modern organisation may now need to represent the same underlying information to humans, search engines, applications, AI retrieval systems and eventually autonomous agents. Instead of beginning with pages and translating them repeatedly, there is a useful case for beginning one level lower: with the organisation's information model.

I'll call the approach Information-First Web Architecture, or IFWA. It isn't a new protocol, framework or replacement for existing web standards. It is simply a rule for deciding what should be canonical before deciding how it should be presented.

The Website Usually Contains a Hidden Graph

Imagine a SaaS company with the following sitemap:

```text id="qk71nm"
/
├── /product
├── /features
├── /integrations
├── /pricing
├── /customers
├── /docs
└── /about

From a browser's perspective, this is perfectly reasonable. It describes where a visitor can go. But it doesn't describe what the business actually knows.

Underneath those URLs is something closer to this:



```text id="n5w2pt"
Organisation
│
├── develops → Product
│                │
│                ├── contains → Feature
│                ├── integrates_with → Integration
│                └── available_through → Plan
│                                           │
│                                           └── has_price → Price
│
├── serves → Customer
├── publishes → Documentation
└── employs → Person

The sitemap describes documents. The second model describes information.

Humans are extremely good at reconstructing these relationships from interfaces. If I visit a product page and see a link labelled "Slack Integration", I understand that the product integrates with Slack. If a case study is associated with a particular service, I can infer that the project demonstrates some capability related to that service.

Search engines have historically performed their own version of this reconstruction by crawling links, analysing documents and combining signals across a website. AI systems make the inefficiency more obvious because their objective can extend beyond deciding which document should rank. They may be attempting to determine what an organisation is, what it provides, how its products relate to particular problems and whether claims made across different documents refer to the same underlying thing.

We already knew that meaning and presentation were different concepts. MDN's explanation of semantic HTML makes essentially this distinction at the markup level: semantic elements communicate what something represents rather than merely how it should look.

IFWA takes that principle further up the stack. Instead of only asking whether the markup communicates meaning, it asks whether the underlying system knows what the thing actually is before we turn it into markup.

The Round-Trip Problem

Take a pricing plan. Somewhere inside the business, it might already exist as structured information:

```json id="f4g8dz"
{
"id": "pro",
"name": "Pro",
"price": 79,
"currency": "USD",
"billingPeriod": "month",
"features": [
"API access",
"Advanced reporting",
"10 team members"
]
}

The frontend converts that object into a pricing card. It adds typography, layout, explanatory copy, feature comparisons and a call to action. That transformation is useful because people don't want to inspect JSON objects while evaluating software.

Now imagine an AI system receives a question asking which plan costs less than $100 per month and includes API access. It retrieves the pricing page, identifies the relevant section, removes information it doesn't need and attempts to reconstruct something remarkably similar to the original object.

The architecture has effectively completed a round trip:



```text id="c0w8rq"
Canonical data
     ↓
Application
     ↓
Components
     ↓
HTML
     ↓
Machine extraction
     ↓
Reconstructed data

The problem isn't the transformation into HTML. That's what the website is for. The questionable part is requiring every machine consumer to use the human representation as its authoritative source when a more precise representation may already exist underneath it.

This is the central principle behind Information-First Web Architecture: model the fact once, decide who owns it, and allow different interfaces to represent it.

One Fact Should Be Able to Produce Multiple Representations

Consider a company offering a technical consultancy service. Instead of beginning with the assumption that /services/technical-consulting is the thing we're creating, begin with the entity itself:

```json id="z9kt2j"
{
"id": "service:technical-consulting",
"type": "Service",
"name": "Technical Consulting",
"provider": "organisation:example-studio",
"available": true,
"serviceAreas": [
"London",
"Surrey"
]
}

The object doesn't need to look exactly like this in production. The important distinction is that the service exists independently of whichever interface displays it.

A website can transform the entity into a rich service page containing explanations, examples, evidence and a contact form. A search layer can represent relevant properties through HTML and structured metadata. An internal search engine might index another representation. A retrieval system might expose selected facts, while an authenticated agent could eventually receive access to an action for requesting a quote.

The architecture is therefore not a website with separate SEO and AI versions bolted onto it. It is closer to this:



```text id="e3m1hx"
                 CANONICAL INFORMATION MODEL
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
           HUMAN        SEARCH       MACHINE
         INTERFACE       LAYER        LAYER
              │            │            │
           HTML/UI      HTML +       API/data
                        metadata
              │            │            │
              └────────────┼────────────┘
                           │
                     Same entities
                     Same facts
                     Same evidence

This resembles how well-designed applications already work. We don't normally design an interface and then infer the database schema from screenshots of the finished application. Domain objects exist independently of the UI.

Websites frequently behave surprisingly close to the opposite.

The Missing Concept Is Fact Ownership

The architecture becomes much more useful when information changes.

Imagine a SaaS product originally costs £39 per month. Six months later, the company increases the price to £49. The billing system now says £49 and the main pricing page is updated correctly, but an old comparison article still says £39. Metadata generated by an abandoned integration still contains the previous price. Documentation contains another reference to £39, while an API correctly returns £49.

Which value is true?

A person can probably infer that the live pricing page is more trustworthy. A machine sees several representations of what appears to be the same fact.

This isn't fundamentally an SEO problem or an AI problem. It's a fact ownership problem.

One of the rules I'd attach to IFWA is that every consequential fact should have an identifiable canonical owner.

Information	Canonical owner	Human representation	Machine representation
Product price	Billing/product system	Pricing page	API / metadata
Product capability	Product model	Feature page	Entity relationship
Employee	People/CMS model	About/author page	Person entity
Service	Service model	Service page	Service entity
Location	Location model	Location page	Location data
Integration	Product database	Integration page	API / relationship
Case study result	Evidence record	Case study	Claim + provenance

The pricing page doesn't own the price. The API doesn't own the price, and neither does the metadata. They're representations. The billing or product system owns the fact, and those representations consume it.

That sounds like an obvious software-engineering principle, yet websites violate it constantly because most content systems are organised around documents rather than facts. The same information gets typed into multiple text fields until the organisation gradually acquires several slightly different versions of reality.

AI doesn't create this problem. It makes it considerably easier to detect because machines can consume those contradictions across thousands of documents.

Internal Links Can Represent Real Relationships

The same model changes how internal linking looks. Most SEO discussions describe internal links as connections between URLs. That's technically correct, but it misses some of what a useful link communicates.

A product page linking to an integration page isn't merely URL A → URL B. Conceptually, it represents Product → integrates_with → Integration. A case study linking to a service might represent Project → demonstrates → Capability, while an author page linking to an article represents Person → authored → Article.

Once the underlying relationship is explicit, the internal link becomes one representation of that relationship rather than the relationship itself.

This produces a different way of thinking about internal linking as part of website architecture. Instead of asking which pages should be connected because they contain overlapping keywords, we can ask which entities actually have meaningful relationships and whether the website accurately represents those connections.

That distinction matters because text similarity isn't the same as semantic relevance. Two documents can contain almost identical vocabulary while having little reason to be connected. Two others can share relatively little vocabulary while representing an extremely important relationship within the business.

An information model can know the difference before either document is rendered.

The Consistency Problem Gets Worse as Representations Multiply

This raises an obvious objection: isn't all of this massive overengineering for most websites?

Yes.

A five-page website for a plumber probably doesn't need a canonical entity graph, event-driven content updates and an agent API. If the business has six services, one address and a phone number, a conventional CMS with sensible markup is likely a better engineering decision.

The value of information-first architecture increases as the information environment becomes more complicated.

A rough way I've started thinking about that complexity is:

```text id="s1vx6a"
Consistency Pressure ≈ F × R × C

where `F` is the number of consequential facts, `R` is the number of representations of those facts, and `C` is the frequency with which they change.

This isn't intended as a literal engineering formula. It is a mental model for understanding where information inconsistency comes from.

Suppose a small company has twenty important facts, almost all of which appear in one place and rarely change. Its consistency pressure is tiny. A straightforward CMS is probably ideal.

Now imagine a SaaS platform with thousands of product facts represented across its marketing site, application, API, documentation, mobile app, help centre, structured metadata and AI interfaces. Features, prices, integrations and personnel change every week. Maintaining reality independently across all of those surfaces becomes a genuine engineering problem.

AI effectively adds another `R`.

It doesn't necessarily demand an entirely new architecture. It increases the cost of an existing weakness.

## Structured Content Is More Interesting Than More Content

One implication is that the CMS gradually becomes something more than a page factory.

Instead of storing only a sentence saying that Product A integrates with Slack, the underlying system could know the relationship:



```json id="m5y8wc"
{
  "subject": "product:a",
  "relationship": "integrates_with",
  "object": "software:slack"
}

That relationship could power an integration directory, appear on the product page, contribute to machine-readable metadata, feed internal search and become available to other authorised systems. If the integration is discontinued, the relationship changes once.

This isn't a new technological invention. Structured content, knowledge graphs and headless content architectures have existed for years. The change is the number of consumers that benefit from the information being modelled independently from presentation.

Historically, structured content was valuable because organisations wanted to reuse material across websites and applications. AI adds another reason: the organisation increasingly needs a coherent information model that non-human consumers can interpret without independently reconstructing reality from hundreds of documents.

The CMS starts moving from managing pages toward managing knowledge.

This is also why I think topical authority can be viewed as something deeper than publishing volume. Fifty loosely related articles might create fifty additional URLs, but they don't necessarily create a coherent information system. A smaller collection of clearly defined concepts, evidence and meaningful relationships may describe a subject far more completely.

In an environment where generating another page is becoming extraordinarily cheap, the structure and originality of the information underneath the page become more interesting.

Facts Aren't Enough Without Provenance

There is another limitation to an information-first approach that matters enormously for AI systems: a perfectly structured lie is still a lie.

If businesses discover that AI systems prefer explicit machine-readable capabilities, every consultancy will eventually specialise in everything. If geographic coverage affects recommendations, businesses will declare every profitable location. If an "expertise" property materially influences discovery, everybody becomes an expert.

The web has already run versions of this experiment. Keywords were manipulated, links were manipulated, and reviews are routinely manipulated. Any structured attribute that materially affects visibility will eventually attract optimisation.

An information model therefore needs to distinguish between what an organisation claims and what can actually be supported.

Consider the difference between a company stating that its platform achieved 99.99% uptime and an independent monitoring service recording 99.99% uptime over a defined six-month period. The first tells us what the company says. The second provides an observation, a source and a measurement period.

A useful information architecture should preserve that distinction.

This doesn't require a universal truth engine. Provenance can be mundane: source, author, observation period, methodology, verification status and whether evidence is first-party or independent. The important part is avoiding the flattening of every statement into an equally authoritative fact.

For AI systems making recommendations or decisions, provenance may eventually become as important as the entity model itself.

Agents Push the Model Beyond Information

So far this architecture mostly concerns understanding. Autonomous agents introduce another layer because they can potentially perform actions.

An AI system could identify several suitable suppliers, compare their services and request quotes. A travel agent could identify a hotel, verify availability and make a booking. A shopping agent could compare products against a set of constraints and complete a transaction.

At that point, the distinction between representation and authority becomes critical. A blog post saying a room is available isn't authoritative availability. A cached pricing page isn't necessarily an authoritative transaction price. A paragraph describing a cancellation policy isn't permission to cancel somebody's account.

Machine interfaces for consequential actions need stronger guarantees than interfaces used for discovery.

This is where developments such as the Model Context Protocol become interesting. MCP provides a standardised way for AI applications to connect to external data sources, tools and workflows. The broader architectural direction matters more to this argument than any individual protocol: machines increasingly don't have to infer every capability by navigating the same interface designed for a person.

A mature information-first architecture could therefore separate presentation, discovery and action:

```text id="m8k4qe"
CANONICAL DOMAIN MODEL
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
PRESENTATION DISCOVERY ACTION
│ │ │
Human UI Search / AI Authorised API
│ │ │
HTML/CSS HTML / metadata Auth / scopes
│ │ │
└──────────────────┼──────────────────┘
│
PROVENANCE LAYER
│
Source / evidence

The website remains important, but it becomes one interface over a larger domain model rather than the canonical representation from which every other consumer must reconstruct reality.

## The Boundary Matters More Than the Architecture

There is a danger with an idea like IFWA that it becomes another reason to overengineer websites. I don't think every sentence should become a database field, every business needs a knowledge graph, or every website needs an agent endpoint.

Human communication isn't reducible to structured facts. Narrative, explanation, persuasion, interpretation and argument belong in documents because their meaning often depends on context.

The useful question is which information is important enough that contradictory versions would create a real problem.

Prices qualify. Product availability probably qualifies. Locations, people, integrations and core product capabilities often qualify. Whether a paragraph in a blog post describes an idea using one adjective or another obviously doesn't.

A simple boundary captures most of the distinction:

**Narrative belongs in documents. Important state belongs in systems.**

The mistake is not building pages. The mistake is allowing the page to accidentally become the authoritative database for information that multiple systems need to consume.

## From Content Strategy to Information Strategy

This also creates a second-order effect for SEO and publishing.

Traditional SEO has spent years operating primarily at the document level: deciding which URL should target a query, whether the page can be crawled, how related documents should link together and what might help a page rank.

Those questions remain important, but machine-mediated discovery introduces another layer. The organisation needs to be understood consistently across many documents and potentially across multiple representations of the same information.

This makes the difference between **content strategy** and **information strategy** more important.

Content strategy asks what should be published, how it should be organised and which audience it should serve. Information strategy asks what the organisation actually knows, which parts of that knowledge are unique, which system owns each important fact, what evidence supports its claims and which representations should be allowed to consume those facts.

That distinction matters because generative AI has dramatically reduced the cost of producing another page.

A thousand-word article summarising existing information and a proprietary benchmark might both technically be URLs, but they're not equivalent information assets. One rearranges knowledge that already exists. The other introduces information that downstream systems may genuinely need to retrieve.

The web doesn't have a shortage of pages. What remains scarce is information worth retrieving and evidence worth trusting.

## The Page Should Be a Representation, Not Reality

The page isn't going away. Humans still need carefully designed interfaces, search engines still discover documents, and writers still need room for arguments and explanations that would make no sense as graph relationships.

What may need to change is our assumption that the page should always be the source from which every other system derives its understanding.

If a company knows that a product costs £49, that fact shouldn't need to be independently rediscovered from a pricing page by every machine that needs it. If an integration exists, the relationship shouldn't have to be inferred repeatedly from marketing copy. If a person authored an article, that relationship can exist independently of the hyperlink displaying their name.

For sufficiently complex websites, this suggests a different order of operations. Identify the important entities before designing every URL around them. Decide which system owns consequential facts before duplicating those facts across templates. Determine which relationships genuinely exist before manufacturing internal links from keyword similarity. Establish where evidence comes from before presenting every claim as equally authoritative.

Then decide how those things should become pages.

For the first few decades of the web, treating the document as the fundamental unit made enormous sense. The browser was the dominant interface, search engines primarily returned documents and most organisations needed one public representation of their information.

We're entering an environment where the same information can be consumed through a browser, a search engine, an AI answer, an API or an autonomous agent.

Building a separately optimised version of reality for every one of those consumers seems increasingly fragile.

A better approach may be to model reality once and treat everything else, including the website, as a representation of it.