When the machine becomes your first buyer

I run Vizura Studio, a one-person brand studio in Zagreb that works on positioning, identity and websites for B2B technology and AI companies. That is my interest in this subject, and it is also why I will keep my own work to one bounded example later in the piece. Nothing here is paid for, and I have no commercial relationship with any company or tool I link to.

A night of server logs

In September, TrustList published something most writing about AI search lacks: its own logs. In one overnight window of 9.3 hours, from 21:19 UTC on 24 September to 06:39 UTC on 25 September 2026, Googlebot fetched 221 pages from trustlist.uk, while OpenAI's GPTBot fetched 15,285 (TrustList, 25 September 2026). That is roughly 69 GPTBot pages for every Googlebot page. All AI company crawlers together took 27,591 pages in the same window, about ten times what the traditional search engines took between them.

The caveat matters, and TrustList states it plainly in the same article: this is one night on one site, a large UK directory of businesses and software products, and a sample rather than a month. A small B2B company will not see those volumes, and I would not build a forecast on it.

What the sample does show is a change in who reads the web most heavily. Cloudflare, looking across its own network, reported that in July 2025 OpenAI crawled about 1,091 pages for every visitor it referred, Anthropic about 38,066 and Google about 5.4, and that training accounted for nearly 80% of AI crawler activity (Cloudflare, 29 August 2025). The reading and the referring are no longer done by the same organisations in the same proportions.

For a B2B company, the practical question is not how to block or court a specific bot. It is what those machines find when they read you, and whether it is good enough to be repeated to someone who is about to make a shortlist.

Two readers, two jobs

A company website has always had to persuade people. A buyer arrives with a problem, scans for signs that the company understands it, and looks for enough proof to justify a call.

An answer engine reads with a different job. When someone asks ChatGPT, Perplexity, Gemini or Google's AI Mode which suppliers handle a specific problem, the system has to work out what each company is, who it serves, what it actually does and whether there is evidence for any of it. It then compresses that into a sentence or two, often next to competitors. It extracts facts, and where facts are missing it fills the gap with whatever the category usually says.

That second reader is now sitting earlier in the process. Pew Research Center tracked 900 US adults in March 2025 and found that when a Google search showed an AI summary, users clicked a traditional result in 8% of visits, against 15% when there was no summary, and clicked a link inside the summary in 1% of visits (Pew Research Center, 22 July 2025). Google's own position is that total organic clicks have been relatively stable but are shifting between sites (Google, August 2025). Both can be true. Either way, more of the first impression is now formed inside the answer, before the visit.

So I find it useful to think of the machine as a first buyer. It does not sign the contract. It does decide how you are introduced to the person who will, and whether you are mentioned at all.

The two readers need different things, and they conflict more often than teams expect:

• People respond to a sharp line, a confident tone and a well-chosen image. Machines need the plain statement behind the line: what the product is, for whom, in which context.
• People will forgive a vague headline if the rest of the page is good. A machine summarising you may quote the vague headline and stop there.
• People can infer that a logo wall means real customers. A machine needs the claim, the condition and the source in text it can read and cite.

None of this means writing for robots instead of people. It means the facts underneath the persuasion have to exist, in text, in a stable form, on pages a machine can reach.

Discoverability is not the same as being understood

Most of the advice around AI visibility focuses on access: robots.txt rules, whether pages render without JavaScript, sitemaps, structured data, and newer proposals such as an llms.txt file. Access matters: if product pages only exist after a script runs, some crawlers see an empty shell.

But access only gets the machine through the door. Google says directly that there are no additional requirements to appear in AI Overviews or AI Mode, that a page needs to be indexed and eligible for a snippet, and that no special AI text files or schema are required (Google Search Central, AI features and your website). In other words, the technical bar is ordinary. What separates companies is what the machine finds once it is inside.

In my work the usual failure is not that a machine cannot read a B2B site. It is that it reads it perfectly and learns very little. The homepage says the company delivers innovative, scalable solutions for modern teams. The about page says it is a trusted partner. The product page lists features without saying what kind of buyer they are for. A careful reader, human or machine, comes away with a category and an adjective, and the summary that comes out the other end reads exactly like the competitor's.

Research on generative engines points in the same direction. A study from Princeton and collaborators tested ways of changing source content and found that adding citations, quotations and statistics improved how visible a source was in generated answers, by up to 40% in their benchmark (Aggarwal et al., GEO: Generative Engine Optimization, KDD 2024). The specific numbers belong to that benchmark, not to your website. The direction is what matters: specific, checkable material tends to survive summarisation better than general claims.

The source clarity audit

This is the audit I run before touching design or copy. It takes an afternoon for a small company and needs nothing more than a browser, a spreadsheet and the questions below. The aim is to find out what a machine can honestly say about you, using only what you have published.

1. Identity: can it tell who you are?

• Is the company name written the same way everywhere, including legal name, brand name and product names?
• Is there one page that states, in plain sentences, what the company is, where it is based and when it was founded?
• Do your LinkedIn page, your own site and any directory listings describe the same company in compatible terms?
• If you use Organization structured data, does it match the visible text?

2. Position: can it say what you do and for whom?

• Can you find one sentence on the site that names the problem, the type of buyer and the context, without adjectives doing the work?
• Would that sentence still be true if a competitor published it? If yes, it is a category description, not a position.
• Are the industries, company sizes or use cases you serve named anywhere in text, or only implied by logos and images?

3. Proof: what can be verified?

• List every claim on the homepage and main product page. Next to each, write where the evidence lives: a case study, a standard, a certification, a public number, a named customer quote.
• Mark claims whose evidence is only in a PDF, an image, a video or a sales deck. A machine may not reach it, and a person may not bother.
• Mark claims with no evidence at all. These are the ones most likely to be either ignored or repeated without support.

4. Citable pages: which pages could a machine quote?

• Which pages answer a specific question a buyer would ask: pricing logic, integration requirements, security posture, implementation time, what is out of scope?
• Do those pages have stable URLs, clear headings and the answer near the top?
• Is there anything a third party has published about you that states facts more clearly than you do?

5. Test the summary

Finally, ask two or three answer engines the questions a buyer would ask: what does this company do, who is it for, how is it different from a named competitor. Save the answers. Then compare them with your own audit. Where the machine is vague, look for the matching gap on your site before blaming the model. Where it is wrong, look for the page that made the wrong reading reasonable.

A worked example

To show how this works without exposing anyone's data, here is a composite example. It is illustrative, built from patterns I see often, not a real company.

A forty-person software company sells scheduling for field service teams. Its homepage headline is "Smarter operations, happier teams". The product page lists route optimisation, mobile check-ins and reporting. The customer logos are images. The best case study, about a utility contractor that cut missed appointments, is a downloadable PDF. Pricing says "Contact us".

Running the audit:

• Identity is fine. One name, one domain, a clear about page.
• Position fails. Nowhere does the site say "scheduling and dispatch software for field service companies with 20 to 200 technicians". The machine has to infer it, and it infers "operations software".
• Proof is mostly invisible. The strongest result lives in a PDF. The logos cannot be read as text. The one quantified claim on the homepage has no source.
• Citable pages are missing. A buyer asking about integrations or rollout time finds nothing a machine could quote.
• The summary test confirms it. Two answer engines describe the company as "an operations management platform that helps teams work smarter", which is the headline restated, and one places it next to general project management tools it does not compete with.

The fix is not more content. It is four changes to what already exists: one plain positioning sentence on the homepage and about page, the case study turned into an HTML page with the result, the conditions and the customer type in text, customer names written out alongside the logos where permission allows, and one page that answers the integration and rollout questions directly. The headline can stay. The page underneath it now gives a machine something true and specific to repeat.

One example from my own work

The single example of my own work I will mention is a free tool I built, Brand MRI, because it came directly out of running audits like the one above by hand. It checks a site across seven layers, from whether crawlers can reach the pages and read them without executing code, through identity, clarity of the offer and whether proof is machine-readable, to whether a brand system exists that AI tools can work from. It is a starting point, not a replacement for reading your own site with the questions above.

The failure mode: more content, same ambiguity

The most common reaction to AI search I see is to publish more. More blog posts, more landing pages, more FAQ entries, often drafted quickly with the same tools that will later read them.

If the underlying position is vague, this makes the problem worse. Every new page restates the same unclear idea in slightly different words. The machine now has fifty sources that agree you are an innovative platform for modern teams, and none that say what you actually are. Volume increases the weight of the ambiguity rather than resolving it.

Google's guidance on helpful, people-first content warns against content made mainly to attract search visits. That advice was written for classic search, and it applies even more strongly when the reader is a system whose job is to compress you into a sentence. Ten precise pages beat a hundred interchangeable ones.

The order of work I recommend is the reverse of what most teams do. First decide the position and write it in one plain sentence. Then make sure the proof for your main claims sits in text, near the claims. Then make the pages that answer real buyer questions. Only then add volume, and only where it carries new facts.

A decision rule for teams

If I had to reduce this to one rule, it would be this: treat positioning, proof and structured brand context as source material, not as copy.

Copy is written to persuade a person in a moment. Source material is written to be correct, consistent and reusable by anyone who has to describe you, including your own sales team, your partners, a journalist, and the machines that now sit between you and most first impressions. It has an owner. It gets updated when the product changes. It is the same on the website, in the sales deck and in the directory listing.

In practice that means three habits:

• Keep one plain description of the company that everyone uses, and check the public web against it every quarter.
• Put every important claim next to its evidence in text a machine can read, with the condition under which it is true.
• Run the summary test regularly. Ask answer engines what they think you are. When the answer is wrong, find the page that made it reasonable and fix that page.

The crawler logs will keep changing. Bots will be renamed and some of today's advice will date quickly. A company that is easy to describe accurately will stay easy to describe, whichever machine is reading.

Figures were checked against the linked sources on 13 October 2026.

About the author. Vedran Obradović is the founder of Vizura Studio, a one-man brand studio in Zagreb that helps B2B tech and AI companies sharpen their positioning, identity and websites. vizurastudio.hr