Websites need an agent policy before agents become customers
Search Engine Journal’s Slobodan Manic points at the missing layer in AI commerce: sites cannot treat agents differently until they can identify them, authenticate intent, and decide what actions they are allowed to take.
TL;DR: The practical AI-agent problem for businesses is not “Should we allow agents?”, it is “Can we reliably identify them and decide what they may do?”
Can your website tell an agent from a customer?
Search Engine Journal’s “Businesses Treat Your AI Agent 3 Different Ways” by Slobodan Manic makes a simple point that is easy to skip past: if a website cannot tell an AI agent from the customer, it cannot treat the agent differently.
That is the whole ballgame.
Most websites still assume visitors are one of three things: a human, a search crawler, or a bot to block. Agents do not fit cleanly into that model. An agent might browse like a user, compare products like a researcher, fill a cart like a buyer, or scrape pages like a bad bot. Same HTTP requests. Very different intent.
So the first operating question is identity, not conversion.
A user-agent string is not enough. It can be spoofed. IP allowlists help for known crawlers, but agents will often act through browsers, apps, cloud runners, consumer devices, or delegated sessions. Login helps, but only after the agent is inside an account. The real need is a chain of trust: who sent this agent, what permission did it get, what action is it trying to perform, and what risk does that action create?
This matters for SEO too. I run Lucky Domains, where website builds and search visibility work often come down to making a site understandable to both search systems and real buyers: AI agents add a third audience, software acting with user intent.
What should businesses decide before agent traffic arrives?
Manic’s framing is useful because it pushes the issue before the flood. The wrong move is waiting until agent traffic is already mixed into analytics, checkout logs, fraud systems, and support queues.
I would split the prep into three decisions.
First, observation. Can you see likely agent behavior in logs without pretending you know every agent by name? Repeated comparison flows, rapid page-to-page checks, cart creation without completion, support queries that look templated, these may be signals. Not proof. Signals.
Second, permissions. Reading a product page is not the same as booking a flight, changing an address, canceling a subscription, or buying 300 units of something. A good policy should separate low-risk information access from account access and irreversible actions.
Third, user experience. If an agent is acting for a customer, the site may need clearer product data, cleaner policies, and structured answers. Not because “AI SEO” is magic. Because agents are brittle when pages hide key details behind popups, inconsistent copy, or vague terms.
The catch: businesses will be tempted to solve this with a banner or a blocklist. That is not a strategy. Blocking all unknown automation may protect resources, but it can also block legitimate delegated buying. Allowing everything may boost short-term reach, but it invites abuse, inventory gaming, price scraping, and account risk.
This is a policy layer, not just a bot problem
The agent web needs something between robots.txt and full human login. Robots.txt is advisory and crawler-focused. Login is user-focused. Agents need delegated authority with limits.
That may eventually mean signed agent requests, permission scopes, agent-readable terms, and checkout flows that confirm high-risk actions with the human. Today, most teams can still start smaller: update bot detection assumptions, separate analytics for suspicious automation, document which actions require human confirmation, and make key commercial facts easier to parse.
Do not overbuild for science fiction agents. Do not underbuild for the agents already browsing, comparing, summarizing, and filling forms.
Practitioner’s take: if you run a commercial site, pick one high-value flow, product discovery, lead capture, booking, or checkout, and map what an AI agent should be allowed to do inside it. Then add logging around that flow and define the actions that require human confirmation. The missed catch is that “agent-friendly” does not mean “agent-trusting.” It means the site can tell the difference.