A new study gives multilingual websites a useful warning: adding English pages does not create an automatic advantage across every AI search platform. However, live page fetches used while ChatGPT builds an answer appear to lean strongly toward English. Findings from Copilot and Google's AI surfaces are more balanced and show smaller effects.
The research, conducted by OMcollective and published by Search Engine Land, does not combine unlike datasets into one score. It examines hundreds of Bing Webmaster Tools properties for Copilot, a panel of multilingual European sites for Google AI visibility, and server logs for ChatGPT. The result is not a recipe that says “publish English and AI visibility will rise.” The more useful conclusion is that discovery and answer-generation systems differ by platform. Language architecture should therefore reflect platform behaviour, market demand, and content purpose together.
For brands expanding from Türkiye into several markets, this is an operational question. An English folder is not merely a translation area. When it is built well, it becomes a separate entry point for international queries about products, services, and expertise. When it is built poorly, it becomes a duplicated layer that is expensive to maintain, hard to measure, and weaker than the local-language experience.
What did the research find?
The most striking finding concerns requests identified as ChatGPT-User, the user-triggered fetches made at answer time. Across the server logs examined, 65% to 79% of those requests went to English pages. English content was represented between 1.9 and 6.5 times more often than its actual share of the sites, with a median over-representation of roughly 2.6. The same pattern did not appear in GPTBot training-crawler activity.
That distinction matters. OpenAI's official crawler documentation also separates controls for search visibility, model training, and user-triggered page access. Blocking training crawl does not necessarily mean a page can never be retrieved for a live user request. Conversely, seeing a bot request in a log does not guarantee that the page will be cited in an answer.
For Copilot, the aggregate English representation index across 272 Bing properties was 1.07, which is close to neutral. In a page-level comparison of 31 sites with an /en folder, English pages received 892 citations per 10,000 impressions versus 585 for non-English pages. That is a 52% aggregate difference, but the sample is small and site structures vary, so it should not be treated as a universal platform rule.
The Google AI panel showed a 28% aggregate lift. Once outliers were reduced, the median site-level difference fell to 9%. English presence may help some sites, but a few strong properties materially influence the combined number.
The illustration separates two retrieval paths from the same multilingual content pool. The heavy path represents the observed ChatGPT preference for English pages, while the dashed path represents the more balanced distribution in other platforms.
How should the result not be interpreted?
The first mistake would be to present correlation as a ranking factor. The research does not prove that adding English pages causes visibility to rise. Sites with English sections may also have stronger international links, broader topical coverage, better technical infrastructure, or higher brand awareness.
The second mistake is treating the three platform measurements as one metric. Copilot uses Bing Webmaster Tools citation data, the Google panel measures AI visibility, and the ChatGPT analysis reads server requests. Citation, visibility, and fetch volume are related but not interchangeable. They can indicate direction, yet they cannot be stacked as a single performance report.
The third mistake is applying “English performs better” to local intent. A Turkish user looking for a service in Türkiye may receive greater value from a Turkish page that reflects local pricing, rules, examples, and vocabulary. English can extend international discovery without replacing the local-language page.
Who is affected?
Export brands, hospitality and tourism businesses, technology companies, B2B service providers, international education and healthcare organizations, and teams generating demand across several countries are the clearest audience. When English content already answers a commercial need, potential AI visibility is an additional benefit rather than the sole justification.
For a business serving only the Turkish market with no verified foreign-language demand, translating hundreds of pages merely to attract ChatGPT requests makes little sense. Weak translation, stale details, and broken canonical or hreflang relationships can reduce the quality of the whole site.
SEO, content, and web teams must also share ownership. Creating a language directory is an editorial decision and a routing, sitemap, canonical, hreflang, internal-linking, and measurement decision. When the project is left to translation alone, the meaning and equivalence between language versions are usually the first things to break.
What should brands in Türkiye do now?
1. Validate real demand. Use Search Console, paid-search terms, sales calls, and site search to identify where demand exists and which language people use. A language investment should begin with user and revenue needs, not bot traffic.
2. Start with critical pages. Prioritize the homepage, service or product pages, case studies, pricing or lead flows, and high-intent guides. Do not bulk-publish a low-value archive through machine translation.
3. Define a localization standard. Currency, delivery, legal copy, examples, units, contact channels, and calls to action should fit the target market. English should represent the international buyer journey, not mirror Turkish sentences word for word.
4. Audit technical pairing. Every language version needs its own URL, self-referencing canonical, and correct hreflang partners. Language detection should not force users or crawlers into one version. XML sitemaps and internal links should make both languages discoverable.
5. Separate server-log agents. Do not group GPTBot, OAI-SearchBot, and user-triggered requests under one “AI bot” label. Report user agent, URL language, response status, and change over time separately. Because user-agent names can be spoofed, validate against published IP ranges when practical.
6. Separate citation from business outcomes. Read fetch and citation counts beside leads, forms, branded search, and qualified sessions. If visibility rises without the right market signal, reconsider the content portfolio.
7. Predefine the experiment. Choose a baseline before publishing new English pages. Compare them with their own historical purpose rather than an unrelated Turkish page. Record seasonality and campaign influence.
This framework connects demand validation, localized production, and platform-specific measurement. English content is managed as a testable growth hypothesis, not as the goal itself.
Where should teams wait?
Do not use the reported percentages as a universal forecast for every category. The ChatGPT log panel covered 26 sites, and the cleaner 30-day comparison narrowed to five. User-agent classification, proxies, and spoofing can also affect what server logs record.
Platform behaviour is not permanent. Retrieval infrastructure, models, search partnerships, and interfaces can change the language mix. A report built today should not be treated as an evergreen rule. Review bot logs, citations, and organic outcomes together every quarter.
Fark Studio interpretation: an English section is not an “AI SEO hack.” For brands with genuine international demand, accessible, well-structured, original English content can serve users, conventional search, and some AI retrieval systems at the same time. Translation volume with no commercial purpose becomes unmeasured maintenance debt.
If you want to assess multilingual information architecture across technical SEO, corporate web, and content production, contact Fark Studio.
Sources
Search Engine Land, Should multilingual websites add English pages for AI visibility?, August 5, 2026. The main report describing the OMcollective method, platform comparisons, and limitations.
OpenAI Developers, Overview of OpenAI Crawlers, live documentation as of August 5, 2026. Official source distinguishing the purposes of OAI-SearchBot, GPTBot, and user-triggered retrieval.
