Why an assistant skips a site, and why nothing tells you

Find this, book that, compare those, order one. The request goes to an AI assistant, and the assistant does the visiting. The visitor arriving at a website is increasingly not a person.

This article is the long version of the argument. If you already accept it and want the state of your own site, run a check; it takes a minute and needs no account.

What goes wrong

Someone asks an assistant to find a supplier, book a table or order a part. The assistant visits four sites that could serve the request. Yours is one of them.

An assistant does not look at a page. It reads it. Where a person would scroll to find a price or a size that is not stated, an assistant does not. It does not ask, and it does not come back. It uses one of the other three.

There is also no second page of results. The assistant returns one answer, and it has already decided.

Nothing about that appears anywhere. No bounce, no failed search, no line in any report. A site that was skipped looks exactly like a site nobody was looking for.

And nothing raises an alarm

An outage is known in minutes. This is not an outage. Pages load. Requests succeed. Dashboards look exactly as they did yesterday.

Every version of this failure looks like success from the inside. Security settings turning an assistant away look like security settings working. A file at the wrong address looks like a redirect somebody set up on purpose.

It can also start without anything on the site changing at all: a platform update, a new version of the standards, a redirect added for a campaign.

The same request, ending differently

Same four sites. This time the assistant reads one of them and finds what it needs stated plainly: what is offered, what is accepted, how to act on it.

It does not have to guess, so it does not move on. It completes the task, and nobody at that site did anything that day.

That site is not doing anything clever. It is doing three small things the other three are not.

The three things

Which of them apply depends on what the site does. Most need one or two, not all three.

A file describing the business. Short, at a fixed address on the domain: what is offered, what is accepted, how to transact. This is UCP, the Universal Commerce Protocol. It is commerce-specific, central to anything that sells and of no use to a site that does not.

Actions it can call. Search, filter, book, add to a basket. Offered to the assistant directly rather than left for it to work out. This is WebMCP, the Web Model Context Protocol. Newer, and it applies to almost any interactive site.

A door that is actually open. Bot rules and rate limits turn assistants away by default more often than not. The most common of the three, and usually a settings change rather than any work on the site.

Which of the three matter varies by sector. A shop that sells online needs the first. A booking system needs the second. Almost everyone needs the third checked, because the default is usually closed.

Why this is hard to see for yourself

You can read your own site and understand it immediately, because you already know what the business does. An assistant arrives with none of that. It has the page, the headers, and whatever files the domain publishes.

The gap between what a site means to a person and what it states to software is the whole problem, and it is invisible from the inside. That is what a check is for: it arrives the way an assistant does and reports what it could and could not work out.

Check a site, or read how agents see your website for what happens on the other side of the request.