Your Website Has a New Customer: The AI Agent

Most conversion optimisation still assumes the visitor is a person with a browser, a screen, some patience and a willingness to click through the journey you designed.

That is an assumption that is starting to age.

The person still matters, obviously; nobody should build a website as if humans are an inconvenient legacy feature. But acquisition has never stayed still. Early search changed how people found websites. Social feeds changed how discovery could be borrowed and lost. Mobile‑first design changed what a useful landing page had to do in the first few seconds. Featured snippets and local packs changed how much of the journey happened before a visit.

The next shift is that more journeys include a machine somewhere before the website, around the website, or between the website and the decision.

A user asks an assistant to compare options. A browser agent reads several pages. A shopping assistant narrows a shortlist. A research tool summarises services. A corporate buyer uses an internal retrieval system to scan vendors. A customer asks whether a membership includes a pool, parking, family access and a sensible cancellation policy before they ever land on the site.

The journey used to be easy to draw:

User → Search engine → Website → Conversion

Increasingly, it may be:

User → Assistant → Website → Conversion

Or:

User → Assistant → Recommendation → Conversion

Or, in the more awkward version:

Agent → Website → Agent decision → User

Those sketches are crude, but the consequence is real. The website is no longer only a persuasion surface. It is also evidence for something else doing the early evaluation.

That is the commercial version of the visibility layer in the previous article. Being included in the answer is useful. Being included in the shortlist may matter more.

Agents Read Differently from People

A human visitor brings context, tolerance, and inference.

They can skim a page, ignore marketing language, click around, compare nearby pages and make a judgement. They can notice that "clubs" probably means locations, "plans" probably means membership options, and "join now" probably means the pricing information is hiding somewhere with better lighting.

An agent may not be so forgiving.

It has to fetch pages, extract facts, map entities, compare options and produce a decision or recommendation. It may not click through every route. It may not execute the same JavaScript as a normal browser. It may retrieve only selected chunks. It may rely on metadata, structured data, page headings, tables, links, feeds, or snippets. It may decide that a competitor is easier to interpret.

The wrong conclusion is that websites have to be written in a robotic style. They do not. The real issue is that important facts have to be visible, stable, specific, and connected.

Real Acquisition Journeys are Messy

Take a health, fitness and wellness journey.

A user might ask which wellness clubs near them have a pool, which memberships include family access, which locations open before 6am, and which option suits someone who needs classes, parking and occasional guest passes. They may ask about cancellation policy, office proximity, accessibility, guest rules and whether this is more of a gym, a spa, or a place where the word "gym" has been asked to wear linen.

That last one is only half a joke. Category language matters. A human may understand the brand mood. A machine still needs concrete facts.

If the site spreads opening hours across a location page, membership prices behind an interaction, facility data inside image tiles, terms in a PDF, class information in an embedded third‑party widget and cancellation details in a separate help centre, an agent has a harder job than it should.

The same pattern appears in SaaS plan comparisons, local service discovery, restaurant selection, travel research, e‑commerce evaluation, and software consultancy shortlists. The surface changes, but the job is similar: extract facts, compare fit, discard weak options and return a recommendation that looks simple to the user.

Human conversion design often focuses on making a route feel persuasive. Agent‑facing design has to make the underlying facts unambiguous.

A Beautiful Page Can Still Be Hard to Evaluate

Product and marketing teams spend a lot of time on human conversion surfaces: hero copy, call‑to‑action labels, page layout, reviews, forms, experimentation, checkout friction, reassurance messaging, performance, and personalisation.

That work still matters.

But a page can be persuasive to a human and weak for autonomous evaluation. The critical facts may be absent, vague, duplicated or hidden in places that a retrieval system will not use confidently.

This is common on service pages. "We help ambitious teams unlock digital growth" might sound acceptable in a meeting. It is poor material for an automated evaluator trying to decide whether the service is relevant to a user asking for help with JavaScript indexing, a headless CMS migration, or Core Web Vitals after a redesign.

The same applies to product and membership pages. An assistant cannot reliably compare options if the attributes are buried in decorative copy or inconsistent labels. It needs names, prices, eligibility rules, availability, constraints, locations, timings, product data, and proof.

The Agent Needs a Decision Surface

Most websites already have human decision surfaces: pricing pages, product detail pages, location pages, service pages, comparison tables, reviews, case studies, FAQs, and contact journeys.

The agent needs those same surfaces to be machine‑readable enough to use.

That means stable URLs for important entities, clear titles and headings, visible page purpose, structured data that matches the page and canonical attributes for memberships, products, locations, and services. It means internal links between related facts, current dates where freshness matters, prices and availability in crawlable form where they are public, and policy pages that answer real buying questions. It also means no contradictions between pages, feeds, schema, and PDFs.

This is not a separate AI website. It is a better information architecture for the website you already have.

Attribution Gets Even Harder

If an agent shortlists three options and the user later converts, who gets credit?

The landing page might record a direct visit. The CRM might show a branded enquiry. The analytics tool might see a returning user. The server logs might show an assistant or crawler request earlier in the journey, but not connect it to the final person.

That breaks a lot of comfortable reporting.

Marketing teams already know last‑click attribution is flawed. Agentic journeys make the flaw more visible. A site can influence a decision before the user session exists. A comparison can happen outside the site. A recommendation can drive branded demand without an obvious referral.

Measurement is not hopeless, but it becomes less tidy. Assistant user‑agent logs, visible AI referrals, brand search trends, CRM notes, assisted conversion analysis, prompt testing, call‑centre feedback and changes in conversion quality all become fragments of a journey that no longer fits neatly inside one analytics session.

There is no point inventing fake precision. Better to stop pretending a missing UTM parameter means the journey did not happen.

Trust Signals Need to Be Legible

Agents need trust signals too.

For a human, trust can come from design quality, brand familiarity, reviews, photos, useful copy, pricing clarity, case studies, external reputation and the feel of the journey.

For a retrieval system, some of those signals are harder to interpret. It may rely more heavily on explicit evidence: named authorship, dates, review data, third‑party citations, relevant case studies, structured data, consistent entities, clear policies, contact details, support documentation, source links, and visible proof near the claim.

Schema for service pages helps only when it does not overclaim. A service page that visibly explains the problem, shows proof and links supporting material gives structured data something honest to describe. A thin page with ambitious JSON‑LD is just a weak page with extra decoration.

Machine Interpretation is No Longer Accidental

Many sites already depend on machines interpreting their pages.

Search engines interpret pages. Screen readers expose structure. Social platforms use Open Graph. Sitemaps advertise URLs. Product feeds syndicate catalogue data. RSS distributes articles. APIs expose structured facts. Analytics tools infer journeys. Consent tools classify scripts. Crawlers test performance, accessibility, and security.

AI agents are not the first non‑human readers. They are just more capable and more commercially active.

That means machine interpretation has become a product concern. It should not be left to whatever metadata a template happened to emit three years ago.

For a commercial site, the interesting questions are blunt. Who owns the public data model? Which CMS fields are the source of truth? Where do prices, facilities, policies and locations come from? How are old claims retired? Are feeds, APIs, and pages consistent? Do important facts render without fragile client‑side paths? Can agents compare the organisation fairly? Which pages should agents not use?

Those are not only SEO questions. They are acquisition questions.

What Changes in the Build

The implementation work is usually less glamorous than the strategy conversation.

Fix the rendered HTML. Make important content visible without forcing a user or crawler through unnecessary client‑side steps. Use semantic headings and real links. Keep structured data aligned with visible content. Build canonical entity pages for locations, products, services, articles, and resources. Use tables where comparison is the job. Make policy pages answer the questions buyers actually ask.

Improve the CMS. Give editors fields for facts, not just blobs of rich text. Separate facility data from marketing copy. Separate membership options from prose. Store opening hours, prices, eligibility, and related services in consistent shapes. Preview the rendered output before publication. Test schema after release.

Improve measurement. Keep server logs. Tag known AI user agents where appropriate. Compare bot access with visible AI referrals and branded demand. Review search console changes, analytics, CRM notes, and enquiry quality together.

Improve governance. Decide which content is meant to be machine‑readable, which content carries licensing terms, which content is blocked and which content must stay available for discovery.

That is what preparing for agentic acquisition usually looks like: less slogan, more information quality.

Wrapping Up

The website is no longer speaking only to the human who lands on a page.

It is speaking to search engines, answer engines, agents, retrieval systems, feeds, crawlers, browsers, platforms and tools that may influence the user's decision before a normal session begins.

That does not make human conversion optimisation obsolete. It makes the upstream interpretation problem more important.

If an autonomous system cannot work out what you sell, who it is for, what it costs, where it is available, what evidence supports it and how it compares, it may never send the right person to your carefully optimised landing page.

The new customer is not the agent instead of the person. It is the agent before the person.

That is the broader thread running through the series. Websites were historically designed as places humans discovered, read and acted on. Increasingly, they also become evidence surfaces for systems that narrow choices before a human sees the page.

Key Takeaways

• Acquisition journeys increasingly include assistants, agents and retrieval systems before, around or between the website and the conversion.
• Agents need visible, stable, specific facts, not only persuasive human‑facing copy.
• Product, service, location, membership and policy data has to be structured enough to compare.
• Attribution becomes harder because automated evaluators can influence decisions before a user session exists.
• Trust signals need to be legible to both humans and retrieval systems.
• Preparing for agentic acquisition usually means better rendered HTML, CMS fields, schema, internal links, feeds, logs, and governance.