I’ve been thinking about AEO again.
Not just how to structure articles for AI search, how long an answer should be or whether a heading happens to match the exact question somebody typed into Google.
I’ve been thinking about something more fundamental.
Where does the useful information actually come from?
Because we’ve reached the point where almost anybody can ask an AI to write a perfectly competent article about almost anything.
And if everybody can do that, a perfectly competent article suddenly isn’t very special.
Google appears to be thinking about the same problem
Google recently published new guidance specifically around content for generative AI search.
The phrase that jumped out at me was non-commodity content.
That is a wonderfully blunt way of describing the problem.
If an AI can produce essentially the same article from a one-line prompt, why does the internet need another copy of it?
Google talks about unique points of view, first-hand experience and creating something genuinely useful rather than simply recycling information which already exists elsewhere.
That fits rather neatly with the direction I’ve been heading in anyway.
I’ve got absolutely no desire to spend the next few years manufacturing AI wallpaper.
There will be enough of that.
I’ve written before about Answer Engine Optimisation and the opportunity around AI search, but I’m increasingly convinced that AEO isn’t really going to be won by finding some magical formatting trick.
The bigger opportunity is giving AI access to information worth using in the first place.
The website has to know something
That sounds ridiculously obvious when you say it out loud.
But I think it matters.
Anybody can ask ChatGPT to write an article about a company, a product, a book, an industry or practically anything else.
What makes the result interesting is when the website itself possesses something extra.
Its own data.
Its own observations.
Its own history.
Its own experience.
I’ve already started experimenting with this in other projects. I wrote about turning InPlay’s own market data into AEO content.
That is much more interesting to me than simply asking AI to write another generic article about a stock.
The AI can still do plenty of the work.
But the raw material belongs to the website.
That is really why I built the Context API
Over the past few weeks I’ve been building something into Control Room that I call the Context API.
Every website I operate knows different things.
One might have products, ingredients, reviews and guides.
Another might have historical financial data.
Another might know about projects, articles, analytics, rankings or relationships between thousands of records.
The problem is that an AI model doesn’t automatically know any of this.
I could keep stuffing enormous amounts of information into prompts, but that gets ridiculous very quickly.
So instead I built a standard way for an AI system to ask a website what it knows.
It can discover the available types of context, request the particular information it needs, and then use that information while doing the job.
The protocol stays consistent.
The knowledge behind it changes depending on the website.
That has turned out to be one of those ideas that started as a practical solution to an annoying problem and has gradually become much more important to how I think my websites should work.
It also follows on quite naturally from the point where Control Room stopped being just another dashboard and became something I could actually talk to.
Then I finally asked what MCP meant
The other day I kept coming across the letters MCP.
I eventually asked ChatGPT what on earth everybody was talking about.
MCP stands for Model Context Protocol.
It is an open standard for allowing AI applications to connect to external systems, tools and sources of information in a consistent way.
My Context API is not MCP.
I’m not trying to retrofit that claim onto it.
But once I understood MCP, I did find the similarity in the problem being solved quite funny.
How does an AI find out what information exists outside the model?
How does it retrieve what it needs?
How do you avoid manually spoon-feeding it every scrap of context on every request?
Those are exactly the sort of questions I had ended up solving for my own websites.
I hadn’t sat down and decided I was going to implement the latest fashionable AI architecture.
I just needed the bloody thing to work.
There was a brief moment where I felt slightly like Alan Partridge talking into his dictaphone:
“Idea for a website. Artificial intelligence, but with a database. Context API. Back of the net.”
And then, as usual, I carried on building it.
Databases remember facts. They don’t always remember why.
There is one problem with all of this structured information though.
A database can tell me what happened.
It is often much worse at remembering why I thought it mattered.
It doesn’t naturally capture the moment when I notice something unusual.
It doesn’t remember that I tried something and it failed.
It doesn’t remember why I changed my mind.
And it certainly doesn’t remember all the little thoughts I have while actually working on a website.
A surprising amount of valuable business knowledge disappears because nobody thought it was important enough to formally record at the time.
I do this constantly.
I’ll notice something, talk about it, make a decision based on it and then three months later I’ll remember the decision but forget half the reasoning behind it.
Which is why I’ve decided Control Room needs a Journal.
I don’t really want a journal. I want a memory.
I don’t want another WordPress-style editing screen.
I don’t want to have to think of a title.
I don’t want categories, excerpts and a little form asking whether my random thought at 4:17pm should be published.
I just want to talk.
If I’m working on one of my sites and realise something, I want to say it.
The Journal can transcribe it, attach it to the relevant website and save it.
Then that journal becomes another source available through the Context API.
Suddenly the website doesn’t just know the formal data stored in its database.
It also starts remembering the things I’ve learned while running it.
That is much more interesting.
The Journal isn’t really a publishing tool.
It is a way of capturing experience before it disappears.
And this brings me back to Google
If Google wants first-hand experience and non-commodity content, this feels like a rather sensible way of creating the raw material for it.
I’m not asking AI to invent my experience.
I’m giving it access to the experience I’ve already had.
That is a very different thing.
I can talk through what I’ve seen, what I’ve built, what went wrong, what surprised me and why I think something matters.
AI can then help me organise it.
It can find the relevant supporting information.
It can turn a rambling conversation into something another human being might actually want to read.
That doesn’t remove me from the process.
In a strange way, it allows more of me to make it into the finished article.
AI probably needs more humans, not fewer
There is a popular idea that the great advantage of AI is removing humans from the process.
I think that may turn out to be completely backwards.
I’ve been a web developer for more than twenty years. Before AI, I could quite easily lose three hours trying to fix one stupid bug.
Usually the fixing wasn’t the difficult part.
Finding the bloody thing was.
You could know perfectly well that something somewhere in several thousand lines of PHP was wrong and still spend half an afternoon narrowing it down.
Now I can hand AI an entire codebase, or get it to give me the right grep command, and quite often the answer appears in seconds.
That doesn’t make my experience as a developer less valuable.
AI hasn’t just made me faster. It has made me much more willing to try things I would previously have dismissed as outside my capability.
I made a Fire TV app recently. I didn’t really know how to make a Fire TV app, but between my ideas, testing and problem-solving and AI handling the unfamiliar technical work, we got there.
It means I no longer have to spend nearly as much of that experience doing mechanical detective work.
I can spend the time on the bit AI is much worse at.
Deciding what the thing should actually do.
Looking at what has been built and saying, “No. That’s wrong.”
Noticing that something feels awkward.
Seeing two completely separate ideas and wondering what happens if you connect them.
Changing direction halfway through because the thing that looked sensible on paper turns out not to be sensible at all once you can see it working.
That is increasingly how I think about the relationship.
I’m the idea, the judgement and the eyes. AI gives me an extraordinary pair of hands.
Those hands can move ridiculously quickly.
They can search code, restructure information, write functions, analyse data, organise my thoughts and turn a conversation like this one into an article.
But somebody still has to look at the result.
Somebody still has to know what matters.
Somebody still has to say no.
In fact, the faster AI becomes, the more important that human judgement may become.
Without it, AI can produce an enormous amount of perfectly competent stuff which nobody particularly needed.
And without humans having new experiences, noticing new problems, developing opinions and trying slightly odd ideas, eventually there is nothing new for the machines to work with either.
That is why I don’t really see AI as the death of human creativity.
I see it as a way of removing an extraordinary amount of friction between having an idea and finding out whether the idea is any good.
AEO is probably much less mysterious than we want it to be
There will inevitably be entire industries built around AEO tricks.
Someone will tell us answers must be exactly 47 words long.
Someone else will invent a special file every website supposedly needs.
There will be templates, scores, checklists and probably a £99-a-month dashboard which turns everything green.
Some technical things genuinely do matter.
A website should have sensible structure.
Its pages should be crawlable.
Its internal links should make sense.
Its data should be organised properly.
Its content should answer the question it claims to answer.
But none of that can create knowledge that wasn’t there.
The technical structure makes the information easier to understand.
It doesn’t magically make the information worth understanding.
The interesting website is increasingly the one underneath the website
I wrote recently that the website was never really the finished product.
I keep coming back to that.
The public website is increasingly just the visible end of a much bigger system.
Underneath it is the data.
The analytics.
The relationships.
The historical information.
The content that already exists.
The decisions that have been made.
And eventually, through the Journal, the things I’ve noticed while actually building and running it.
The Context API gives AI access to that knowledge.
The Journal keeps feeding new experience into it.
And the website publishes the useful result.
That feels like a much more interesting version of AEO than simply creating another thousand articles designed around search queries.
Perhaps talking to myself isn’t such a stupid idea after all
I’ve already seen AI search send real traffic into one of my websites, so none of this feels entirely theoretical anymore.
What I’m interested in now is building the knowledge layer underneath that discovery.
Not a machine designed to generate as many pages as possible.
A system designed to remember more of what each website actually knows.
Some of that knowledge will come from databases.
Some will come from analytics.
Some will come from things I’ve already published.
And quite a lot of it may eventually come from me wandering around talking into my phone because I’ve just thought of something.
Which does sound faintly ridiculous.
But if the alternative is publishing another article that could have been written for anybody, by anybody, about anything, I know which one I’d rather put on the internet.
