How to get AI to recommend your product, and agents to use it

Two ways to get clients through AI

A driver asks an assistant which brake pads fit their car and where to order them in Poland. A developer asks an agent to add compatible auto-parts lookup to an app.

The first request can end in a purchase. The second can end in the use of a library, API, or service.

These are two routes for product distribution. In one, the assistant recommends the product to a person. In the other, the agent uses it while doing the job.

In both cases, start with three questions: can the system find the product, decide that it fits the task, and use the information or interface you provided?

Make the product findable

Access for search and access for model training are separate mechanisms.

OpenAI distinguishes OAI-SearchBot, used for search in ChatGPT, from GPTBot, which collects material that may be used for training. ChatGPT-User makes separate page requests on behalf of a user.

Anthropic likewise splits Claude-SearchBot, ClaudeBot, and Claude-User.

AI features in Google Search use Google’s search infrastructure. Google-Extended governs separate training and source-use scenarios in Gemini. It is not a separate HTTP crawler and not a ranking signal for Google Search.

Sources:

Check both robots.txt and the site’s actual response. A permitted crawler can still receive a protection check, an error, or a page that lacks the information it needs.

Important attributes should be available as text at stable URLs, connected by internal links. A lighter HTML or Markdown representation can make access easier if it keeps the same facts buyers see.

Give the assistant the facts it needs to match

Consider this request:

“Which pads fit a Passat B8 2.0 TDI with 312 mm discs, and where can I buy them in Poland?”

A generic product description leaves most of the matching unresolved. A useful page names the part, the compatibility conditions, stock, price, and delivery. If the vehicle details are incomplete, it explains what still needs checking.

Build the data around explicit relationships:

Vehicle configuration → compatibility conditions → part → current offer.

Use the same verified records for product pages, compatibility tables, product feeds, and API responses. That reduces contradictions between what the assistant read and what the buyer will see at checkout.

Apply supported Product and Offer markup where it belongs. It must match the visible page content. Google states directly that AI search features do not require special AI markup.

Google guidance on AI features

Case: an auto parts store in Poland

Over six months, a multi-brand auto parts store improved its catalogue and content for AI search and recommendations. The project covered VAG, BMW, Ford, and Stellantis, with a focus on suspension, braking systems, and maintenance.

The catalogue already had a conventional SEO structure. The weak points were crawler access, fragmented compatibility data, and translated descriptions that did not answer specific questions from Polish buyers.

The work combined three strands.

Access and catalogue data

Access rules and page delivery through the edge were set so the required content stayed available without extra load on the backend.

Lighter page representations exposed attributes and compatibility tables without depending on complex in-browser interaction.

A TecDoc integration kept the links between catalogue records, part numbers, and vehicle applicability.

Product pages and purchase terms

Product and offer data were aligned between buyer-facing pages and structured representations.

Prices in PLN, stock, delivery, and returns sat next to compatibility. Information about InPost and BLIK made local purchase terms clear.

These details help a buyer judge the offer. Their presence should not be described as a proven way to get priority in AI recommendations.

Content for specific questions

Polish-language materials and compatibility pages answered specific questions about matching, comparison, and buying parts.

The job was to keep a useful answer next to the relevant products. Verified kits also gave the buyer a direct path from reading about maintenance work to ordering the required components.

Results after six months

Metric	Before	After six months
Mentions in AI answers	<1.5% of queries	19.4% of queries
Share of traffic from AI sources: AIO, ChatGPT, and Perplexity	≈0.8%	14.2%
Average monthly organic sessions in Poland	48,500	89,200
AI traffic conversion to orders	1.1%	3.85%
Average order value from AI traffic	290 PLN	510 PLN
Catalogue pages indexed with rich results	12%	94%

The result was not visibility alone: conversion and average order value also rose during the project.

The practical takeaway is to connect search to a useful destination page. A detailed recommendation should lead somewhere the buyer can check compatibility, understand the terms, and order the matching part or kit.

Prepare libraries and tools for agents

For a software product, a recommendation is only the start. To use the work, an agent has to install or connect it, complete the task, and check the result.

Prepare:

An accurate description of supported tasks and limits.
An unambiguous package name and install instruction.
A complete working example with input and expected output.
Version-specific documentation and upgrade notes.
Types or schemas, error descriptions, and predictable responses.
Test data and a simple verification command.
A clear licence, dependencies, and environment requirements.

For example, an automotive data API should say explicitly that it lacks the information needed to confirm compatibility. The response should list the missing parameters instead of treating an uncertain match as confirmed.

For live data or remote operations, you can provide an API or an MCP integration. Codex, Claude Code, and Gemini CLI support MCP, but the integration has to be connected and available in the user’s environment.

OpenAI Docs MCP

MCP in Claude Code

MCP in Gemini CLI

Publishing an integration does not mean every agent will start using it. Clear documentation, meaningful tool descriptions, and reliable execution give developers a practical reason to connect it.

What to check in OpenAI, Google, and Anthropic

Ecosystem	Recommendation scenario	Agent-use scenario
OpenAI: GPT, ChatGPT, Codex	Does ChatGPT with search find the right page and describe the offer correctly?	Can Codex install or connect the product and complete a typical task?
Google: Gemini	Does Gemini with search find the product? Evaluate Google Search AI features separately.	Can Gemini CLI successfully use the package or connected tool?
Anthropic: Claude	Does Claude with web search find the product and read its attributes correctly?	Can Claude Code use the library or integration and verify the result?

Record the model, interface, search settings, language, and test date. A model answer without search and an assistant that reads live pages are different test conditions.

Measure discovery and successful use separately

To assess recommendations, keep a fixed set of real buyer questions. Track brand mentions, links, product recommendations, and factual accuracy separately. Connect attributable visits to orders and revenue.

For products aimed at developers, run two tests.

First, describe the task without naming your library. Check whether the agent finds and selects it.

Then give the library and the documentation. Check whether the agent can complete the task correctly.

The first test measures product discovery. The second measures usability. If agents find the library but cannot integrate it, installation, documentation, or the interface needs work.

The aim is a complete path from the client’s question to a useful result. For a store, that is the right product and an order. For a software product, it is a working integration that remains part of the client’s product.