What Is a Website For When People Stop Visiting It for Information?

Question: What is a website for when people increasingly get information from AI answers instead of visiting the original pages?

A useful website is becoming more than a collection of pages people visit. It’s becoming the source of truth underneath search results, AI answers and agent actions: a place that owns the facts, proves where they came from and, in the strongest cases, holds the data and workflows needed to do something useful. The front end still matters, but the information, structure, proof and working system underneath it may matter more.

This is part one of a two-part series about websites, AI answers and the value of original information. Part two asks who should pay for the information behind AI answers.

I don’t visit websites for information like I used to

I’ve been thinking about website traffic, partly because I can’t remember the last time I visited a site just to find a straightforward piece of information.

I still visit sites when I want to buy something, use a tool, check a source, read somebody whose judgement I trust, or understand the full story behind an answer. But for the ordinary questions that used to send me through Google and into three or four websites, I’ll often ask ChatGPT or Claude first.

That’s not a small change in browsing habits. It changes what a page view means, how useful information moves around the web, and what a site like Old Stack Journal needs to become.

The old model was easy to understand. A publisher made a page. A search engine indexed it. Somebody searched for the subject, clicked the result, visited the website and perhaps read another page, joined a mailing list, clicked an advert or bought something.

That journey hasn’t vanished, but it’s no longer the only journey. The answer may now be assembled somewhere else. A search result can summarise it. An AI assistant can explain it. An agent may eventually act on it without the person opening the original website at all.

The information still had to come from somewhere. The visit didn’t.

The website is becoming the source underneath the answer

Joost de Valk recently wrote about the future of the website. His argument is that the website becomes the verified, machine-readable home base of a business: one source of truth that can feed several human and machine interfaces.

That matches something I keep coming back to. A website is no longer just the pages people see. It’s also the information an AI system extracts, the structured details a search engine understands, the evidence an agent checks, and the system an outside tool may need to interact with.

The durable idea isn’t that every small site suddenly needs to bolt on every new AI protocol. We’ve been through enough technical fashions to know how that ends. The durable idea is that one trustworthy system should be able to present its information in the forms that matter without maintaining several conflicting versions of the truth.

The human page is one view of that system. An API might be another. Structured data is another. A feed, downloadable file or machine-readable response could be another. The exact interfaces will change. The need for a dependable source underneath them won’t.

That also makes the basics more important, not less. Dates need to be clear. Authors need to exist. Claims need evidence. Product information needs to be current. Pages need meaningful structure. Updates need to replace stale facts instead of leaving five competing versions around the site.

I’ve already written about why GEO is mostly an extension of sensible search work rather than a completely new discipline. Clear answers, crawlable pages, first-hand examples and good internal links still matter. The difference here is that the website’s job is expanding beyond winning a click.

Source, proof and system

The model that makes the most sense to me has three parts: source, proof and system.

A source owns the information. It has the original test, record, explanation, measurement, experience or maintained set of facts. Other people may repeat or summarise it, but there’s somewhere authoritative to return to.

Proof shows why the source deserves to be trusted. That might include the author, publication date, update history, screenshots, data, methodology, customer evidence, public project history or links from other credible places. An AI can generate a confident paragraph very cheaply. It’s much harder to generate a genuine trail of work that holds together when somebody checks it.

A system stores state and carries out work. It holds the data, rules, permissions and history needed to do something rather than merely describe it.

Most traditional content websites have concentrated on the first part, and sometimes not very strongly. They publish pages containing information, but they don’t necessarily own unique information, show much evidence or operate a useful system beneath the article.

That’s the part of the web that looks most exposed.

The useful website probably isn’t disappearing

I don’t think the useful website is disappearing. The commodity information website might be.

There’s a difference between a page that repeats a familiar answer and a site that has something real underneath it. If twenty websites explain the same general topic using the same public facts, an AI answer can compress most of that material into one response. The individual pages become harder to justify unless one of them is clearer, more trustworthy, more current or based on genuine experience.

That doesn’t mean every article needs a database, a laboratory or a piece of software attached. A useful explanation can still be valuable. Good judgement can still be original. A person who has done the work can spot tradeoffs that a general summary misses.

But we should be honest about the pressure. Publishing another competent answer to a question that has already been answered a hundred times is less defensible than it used to be. The reader can often get the acceptable middle of those hundred pages without visiting any of them.

The stronger material is harder to flatten completely:

• original tests with a method and result;
• real build notes showing decisions and failures;
• maintained datasets or directories;
• useful tools and calculators;
• templates that solve a real task;
• detailed comparisons based on actual use;
• records that change over time;
• a recognisable person with judgement readers trust.

An AI can still summarise those things. It can’t become the original test, maintain the tool, own the records or replace the person’s history of making decisions in the real project.

Niche software should be safer for longer than niche content

This is where I think niche software has an advantage over niche content, although I’d say safer for longer rather than completely safe.

Take a football club management app. It might hold players, teams, fixtures, availability, subscription payments, documents, permissions and years of club history.

An AI assistant can explain how to run a club. It can draft an email reminding parents about fees. It can answer a question about creating a fixture list. It might even become the main interface a club secretary uses to ask, “Which under-14 players haven’t paid yet?”

But something still has to know the answer.

Something has to hold the player records, know which season they belong to, record the payment, restrict who can see medical details, preserve the fixture history and log the change. The AI can become the interface, but it still needs a system of record behind it.

That’s why it helps to understand the difference between a website and a working web application. The visible screens aren’t the whole product. The value often sits in the database, business rules, permissions, integrations and accumulated history.

The same is true of many small tools. A booking system owns availability. An accounting tool owns transactions and reconciliations. A membership plugin owns accounts and access rules. Automation Receipts keeps a readable history of workflow runs. EVE Profit Routes turns live market data into route decisions rather than merely explaining hauling in general.

An agent may eventually use those systems on somebody’s behalf. That could make the dashboard less important. It doesn’t make the underlying workflow unnecessary.

The interface can change without destroying the product

This is an important distinction for builders.

We’ve spent years treating the user interface as the product because it’s the part people see. In practice, the interface is only one layer. A strong niche application has a model of the real work underneath it.

The football club app knows what a player is, what a team is, how fixtures relate to seasons, who can update a record and what needs to be retained. The screens expose that model to a human. An agent could expose the same model through a conversation.

That doesn’t mean the front end stops mattering. Humans still need somewhere to inspect, correct and understand what’s happening. A chat response is a poor substitute for a proper table when you need to review forty payments. A voice command isn’t the right interface for configuring detailed permissions. People will still want dashboards, forms, reports and audit trails.

The likely change is that the front end stops being the only front door.

That’s good news for small practical software as long as the value isn’t just a thin wrapper around an easily copied prompt. The safer products will own workflow, state, history, trust and a reason for users to keep their data there.

What this means for Old Stack Journal

This argument lands uncomfortably close to home because OSJ is a content site.

I can’t just publish answers and hope people click through. That doesn’t mean I should stop writing articles. Writing is still how I explain the work, connect ideas, document decisions and make the useful parts discoverable. A clear article can save somebody hours. I still want OSJ to be a practical corner of the web for people building useful things.

But the site needs more than pages that can be summarised and forgotten.

For OSJ, the stronger direction is a mixture of:

• real tool tests rather than rewritten feature lists;
• build diaries tied to actual projects;
• useful small apps and WordPress tools;
• templates people can take away and use;
• maintained comparison data;
• search and AI visibility experiments with the results included;
• practical records of what worked, what failed and what I’d change;
• clear source information beneath every factual claim.

That won’t make OSJ immune to AI answers. Nothing public is immune to being summarised. The aim isn’t to hide every useful idea until somebody pays. It’s to make the site valuable in ways that survive the summary.

A reader may get the headline answer from ChatGPT, then come to OSJ for the actual test. An agent may extract a fact, then point back to the maintained source. Somebody may read a build note and then use the tool. A search result may answer the easy part while the site retains the evidence, workflow and deeper judgement.

That feels like a healthier target than trying to win back every informational click from 2019.

Not every site needs to become software

There’s a risk of overcorrecting here.

Not every blog needs an API. Not every local business needs an MCP server. Not every writer needs to build a SaaS product to justify having a website. Sometimes the honest value is still a person thinking carefully, doing the work and writing something worth reading.

The point isn’t that content has no value. The point is that undifferentiated content is easier to replace, while original work and owned systems give the website a stronger role.

A local tradesperson’s website may still be valuable because it proves the business is real, shows recent work, answers local questions and gives customers a dependable way to make contact. A specialist writer’s archive may matter because readers trust their judgement, not because every article contains unique data. A small publisher may build a reputation over years that no single AI answer can reproduce.

The right response depends on what the site is for. The mistake is assuming the old traffic model will carry on unchanged because pages still exist.

The website isn’t dead. The job has changed

The website isn’t disappearing. It’s being pulled underneath more of the internet.

It’s becoming the source that search engines index, the evidence an AI answer cites, the place an agent checks, and the system that owns the real record after the conversation ends. Humans will still visit, but the visit may be only one of several ways the website creates value.

For builders, that means thinking beyond pages. What facts does the site own? What proof supports them? What data changes over time? What workflow does the software carry? What can somebody do here that they can’t get from a generated paragraph?

For OSJ, it means continuing to write, but tying more of the writing to original tests, real builds, maintained tools and useful data. The article still matters. The work underneath it matters more than it used to.

Part two follows the uncomfortable economic question underneath all of this: if AI companies increasingly depend on original web sources while returning fewer visits, who pays for the information behind the answer?