Earlier this month, I wrote about rebuilding my website. At the time, making it ready for AI search and agents was still on the list of things to finish.

That work is now live.

"Agent-ready" is one of those phrases that can mean almost anything. Sometimes it means a site is readable by a crawler. Sometimes it means an AI can use the site on somebody's behalf. Those are not the same job.

For this site, I wanted machines to be able to find the content, read it cleanly, understand what it means and, where it is useful, interact with it through defined tools.

That started with ordinary SEO.

SEO is still the foundation

Generative Engine Optimisation, or GEO, is often presented as a new discipline sitting beside SEO. I am not convinced the boundary is that neat.

Google's own guidance says the fundamentals still apply to its AI search features. Pages need to be crawlable and indexable. Important information should be available as text. The site should be fast, accessible and easy to navigate. Structured data should agree with what a person can see on the page.

It also says there is no special AI schema or machine-readable file required to appear in AI Overviews or AI Mode.

That matters. I did not want to fill the site with speculative markup or write articles for machines at the expense of people.

We concentrated on making the same content work for both.

The content is rendered into the HTML, rather than being hidden behind JavaScript. Pages have clear titles, descriptions, canonical URLs and social metadata. The HTML is semantic. Internal links make the structure discoverable. The XML sitemap carries the public pages and their last-modified dates. The whole site is tested for performance, accessibility, markup quality and crawler access.

Pages across the main site also carry JSON-LD structured data. At the base level, that describes me, the website and the page being viewed. Work pages add organisations, roles and creative work. The public knowledge catalogue is identified as a DataFeed, so a system that already understands Schema.org has a familiar way into it.

That is SEO, but it also does most of the useful work people now place under GEO or Answer Engine Optimisation. An answer engine still needs useful information it can find, interpret and support with evidence.

Giving AI cleaner versions of the site

HTML is designed for browsers. It contains navigation, layout, interface controls and other material that a machine may have to strip away before it reaches the words.

So nearly every public page on the site now has a Markdown version. The CV is the deliberate exception. An agent can add .md to another page path, or request the normal page with an Accept: text/markdown header. It gets the same content in a lighter form, with the canonical URL preserved.

There is also an llms.txt file. It acts as a map of the site for language models and agents: who I am, when to use the site, the important pages, the writing, the machine-readable resources and the routes into them.

I treat llms.txt as a useful signpost, not a ranking trick. It is still a proposal, and Google does not require it. An agent arriving at the root of the site gets an edited explanation of what is here instead of having to infer the structure from scratch.

Turning a portfolio into knowledge

A conventional portfolio gives people pages to read. An AI system often needs something more explicit.

The site now publishes two related knowledge sources.

knowledge.json contains the same material used by Digiguru, the assistant on the site. It covers my career, roles, projects, approach and availability, with canonical pages attached to the facts. Nothing Digiguru can say is hidden in a private corpus.

The public knowledge catalogue goes further. At the time of writing it contains 343 published entries covering people, organisations, roles, projects, capabilities, practices, ideas, writing topics, credentials, talks, awards and external evidence. They have stable identifiers and typed relationships, rather than being a pile of disconnected paragraphs.

It also records provenance and uncertainty. Identity, verification and attribution are separate questions. That is important on a personal site because machines are very good at collapsing similarly named people, employers, dates and projects into one confident but incorrect story.

The catalogue records disagreements instead of quietly smoothing them over. It can state that an organisation produced a piece of work during my tenure without pretending that I made it. Making the information machine-readable should not make it less careful.

MCP gives agents a direct route in

The site has a read-only Model Context Protocol server at /mcp, with a public manifest at /.well-known/mcp.

An MCP client can search my writing, retrieve a full article, list or read work, get a profile summary and search the structured knowledge. It does not need to scrape the visual site and hope it has interpreted the interface correctly.

The server is deliberately read-only. My site has no account, checkout or transaction for an agent to complete. It exists to retrieve first-party information and return the canonical page that supports it.

WebMCP brings those tools into the browser

The newest part is WebMCP, a proposed web standard currently available through a Chrome origin trial.

MCP and WebMCP solve related but different problems. The MCP server is a remote endpoint that an external client can connect to. WebMCP allows a page that is already open in a browser to register tools for a visiting browser agent.

Without that interface, an agent has to inspect the page and operate it much as a person would: find controls, click links, type into fields and work out what changed. WebMCP lets the site state what can be done, what inputs are accepted and what will come back.

My site currently exposes two browser tools.

The first searches my public writing, work, career, About content and structured knowledge. It uses the existing MCP search underneath, so there is one index and one set of answers.

The second opens a page on the site. It only accepts a path on craigjamieson.com, and it uses the site's normal page transitions where possible.

That is intentionally narrow. The tools cannot send an email, subscribe somebody to the newsletter or act outside the site. WebMCP is still experimental, so the implementation is a progressive enhancement. Browsers that do not support it simply ignore it and the site carries on working normally.

Crawler access is a policy decision

Being agent-ready does not mean giving every automated system permission to do everything.

The robots.txt file allows search engines, answer engines and user-triggered AI agents to retrieve the public site. It blocks GPTBot, CCBot and Bytespider, which are associated with bulk training or dataset collection.

That separation is deliberate. I want somebody to be able to ask ChatGPT, Claude or Perplexity about my work and have the system read the source. That is different from granting blanket permission to collect the whole site for model training.

The policy will need revisiting as user agents and platform behaviour change. At least it is explicit.

The human site still comes first

None of this replaces the site people see.

The same semantic HTML that helps a crawler also helps a screen reader. The same stable interface that reduces misclicks for an agent makes the site calmer for a person. The same first-party catalogue that gives an answer engine better facts gives me a more honest record of my own work.

Even Digiguru is another view onto the same system. A visitor can ask it a question, while an external agent can query the MCP server, and both are working from knowledge that is published and inspectable.

I do not know which of today's protocols will still matter in five years. WebMCP is a proposal. llms.txt is a proposal. The names SEO, AEO and GEO will probably keep shifting as the industry tries to package the next change.

What should last is the underlying work: useful content in the page, a clear structure, sources and confidence recorded properly, readable versions for machines, and narrow tools where a tool is safer than asking an agent to click around and guess.

That is what being agent-ready means to me.