AI discoverability, languages and the shopping journey
🎧 Listen to every article back to back
A customer asks an AI assistant for branded gifts for 80 people, delivered to Estonia within two weeks. Does your store provide enough information to answer that request and turn a recommendation into a correct order?
Start improving AI discoverability with your catalogue. Product attributes, prices, availability and delivery terms need to make sense to shoppers and the software using that data. You can then build an assistant that helps clarify requirements and prepare a purchase.
What does AI discoverability mean technically?
AI discoverability describes the possibility that an AI-powered search or answer service finds a company's content and uses it to construct an answer. You may also encounter the abbreviation GEO. Services use different data sources and access rules; guidance for one search engine does not automatically describe every AI assistant.
For Google's AI Overviews and AI Mode, established SEO fundamentals still apply. Google does not require a separate AI schema or a special AI file. Technical eligibility does not guarantee inclusion in an answer. Google's guidance on AI features (opens in a new tab)
In a technical review, we would check whether a product page opens without signing in, returns the correct HTTP status and presents its main content as readable text. We would then review indexing directives, the canonical URL, internal links and the sitemap. Information added through JavaScript also needs checking on the rendered page: a price visible in the browser may be absent from the initial HTML.
Crawler access should be assessed by service and purpose. Reading content for search and collecting data for model training are different uses. A blanket recommendation to allow every bot would be too broad.
Product data needs a consistent meaning across channels
“A practical travel mug” does not tell a buyer whether a product suits a company event. They need its capacity, material, care instructions, branding options, minimum quantity and deadline. Delivery of stock items and production of branded orders must be distinguished.
Product pages can use Product and Offer structured data. Google describes using these to present information such as price, availability and delivery details in search results. The markup must reflect the offer visible on the page. Google's product data guidance (opens in a new tab)
We recommend connecting visible prices, structured data and product feeds to the same catalogue and pricing rules. Each variant needs a stable identifier. Size, colour and quantity tiers should not be inferred solely from a free-text product name.
Some channels accept a separate product feed. OpenAI documents sharing catalogue data to support product discovery in ChatGPT. A store's eligibility and participation requirements need checking before development. OpenAI's product feed documentation (opens in a new tab)
A feed also needs maintenance: when was it last updated, what happens if an export fails, and how are discontinued products removed? An integration created once does not prove that prices will still be correct a month later.
How does language affect discoverability?
Consider language in three places: the customer's question, the page content and the sales terms. An Estonian question may contain an English product name. An English product page may describe an item that cannot be delivered to Estonia. Both language relevance and the actual suitability of the offer need checking.
Google tries to find pages matching the searcher's language and determines a page's language from its visible content. Translating the menu alone is therefore insufficient if product descriptions remain in another language. Google recommends separate URLs for language versions and cautions against relying solely on cookies or browser language to change content. Google's multilingual site guidance (opens in a new tab)
For the Estonian market, our practical recommendation is to write decision-making information in good Estonian. Include a familiar English equivalent beside a specialist term when it helps readers understand the product. Piling up keywords and synonyms is no substitute for a description.
An English version can serve another audience. This does not establish that English automatically provides an advantage in every AI service. An AI service may use sources in another language, but that should not be treated as a guarantee of discoverability for a particular store. Investigate the effect through queries in different languages and record the results separately.
The technical structure of language versions
Estonian and English product pages should have separate stable addresses, such as /et/toode/termokruus and /en/product/travel-mug. They should describe the same product or a clearly defined market-specific offer.
hreflang helps Google understand the relationship between language and regional versions. References must be reciprocal and include the page's own version. et identifies Estonian; add a region code when you need to distinguish markets. This markup is not a universal interface for AI assistants. Google's localized page guidance (opens in a new tab)
A fully translated page intended for separate indexing should generally have a canonical URL pointing to that language version itself. Pointing every translation's canonical link at the Estonian page needs a specific justification. Set the HTML lang attribute correctly too, including for assistive technologies; Google's language detection relies on visible content.
The language switcher should lead to the translation of the same product. Offer a language choice rather than forcing a redirect based on browser language. Check that translations stay current: changes to materials or delivery restrictions need to reach every version.
Technical product attributes can share a product identifier, descriptions can be translated, and market-specific prices and delivery terms can be modelled separately. This helps prevent a translation from accidentally promising delivery to a market the store does not serve.
An AI-assisted shopping journey needs clear interfaces
For the gift order, an assistant could ask for quantity, deadline, destination country and budget. It could then search for matching products and explain the differences. The responsible business system should return prices, stock levels and delivery options.
A language model can turn “80 mugs with a logo” into a structured request. The application must validate quantity, product identifiers and permitted options before calling pricing or cart interfaces. Missing information must remain visibly missing. If the printing deadline requires production approval, a quotation request with a clear pending status is a useful outcome.
In Drupal and Drupal Commerce, we recommend using existing product variants, pricing rules and order workflows. Reading the catalogue, changing a cart and confirming an order need different permissions. A language model's response does not replace server-side permission or price checks.
Recheck price and availability immediately before purchase confirmation. Customers must see the final total and terms. Repeating the same request must not create duplicate orders; prevent this in the order creation logic.
Test different languages with the same shopping task
A useful first test is one bounded task: find a branded gift that can meet a deadline and prepare a quotation request. Use the same requirements in Estonian and English, and add a mixed-language question.
For external AI search, record the service, date, exact question, cited URL and factual accuracy of the answer. A single mention or omission does not establish lasting visibility. For your own store assistant, test catalogue queries, pricing and preservation of selections separately.
In the browser, verify that the chosen product, variant, quantity and additional services reach the quotation request or cart correctly, including after a language change. The journey must work on a phone and with a keyboard. Measure completed enquiries and orders, separated by language and market. Referrer data may not identify every visit originating from AI services.
WebPro recommends starting with a technical catalogue review and one testable shopping task. This reveals whether the next step is correcting product data, improving translations or building an integration.
To review this journey in your store, contact WebPro. Read more about connecting Drupal catalogues and order workflows on our custom development page.
Need Drupal help?
Send the website URL and a short context. We will tell you whether the sensible next step is an audit, maintenance, an upgrade or a migration.