We have rewritten this article. In the previous version, the first line was "50% of searches in 2026 will be voice", and then there were percentages of growth that no one measured. Let's start with where the number itself came from.
A ten-year forecast that is passed off as a measurement
The claim about half of voice searches appeared in the mid-2010s as an analyst forecast and has been floating around from article to article ever since. This is an assumption about the future, made before smart speakers in every kitchen and AI search modes appeared. There's no such figure in Google's documentation—we looked in Search Central and couldn't find it, or any official percentage of voice queries.
A forecast does not become a measure of being quoted a thousand times. Therefore, there will be no percentage increase in the text: there will be the mechanics of how the assistant gets the answer, our own measurements on live sites and a list of checks that you will do yourself.
What the voice actually changes
On the screen, there are ten links, and the person himself decides where to click. The column reads one answer. The phone with the assistant shows a short card and one or two sources below it. The difference is not that the requests have become longer. The difference is that the seventh position, which on the screen still brings clicks, simply does not exist in the voice response.
The second is wording. With the keyboard, they write "kiev shoes", in their voice they say "where near to buy winter boots of size 43". A longer query means more precise intent and less competition for a specific question. It also means that a page gathered under two words does not answer such a question.
And the third, the least obvious. The voice assistant and the AI search mode are different technologies, but they read the site in the same way: through their own agent that walks over HTTP and retrieves HTML.
The agent comes to you as a bot that doesn't wait for JavaScript
Assistants and AI search modes go to the site with their own crawlers, and most of them do not run JavaScript. They read what is given in HTML immediately. If the site is a SPA shell that collects content on the client, the agent will see a blank page and quote someone else. The earning mechanism here is the same as in classic SEO, just the showcase is different: if the assistant's answer mentioned a competitor, the contact went to the competitor.
Our measure: a site that gives another document to a bot
Clinic of plastic surgery, external dimension 07/31/2026 via curl, without a browser. The site gives different answers depending on the User-Agent. The browser gets a 3.0 KB SPA shell — no H1, no meta description, all content is collected on the client from JS bundles. The search bot gets a fully pre-rendered HTML of 126 KB, that's 24 KB in gzip: 145 ms to the first byte, 178 ms to the last. There are ten JSON-LD types in this HTML, including MedicalClinic, Physician, and BreadcrumbList.
Nearby is the 22,810-byte llms.txt, a compressed sitemap for agents. And robots.txt with a separate policy: crawlers that collect data for training (GPTBot, ClaudeBot, CCBot, Google-Extended, Bytespider, Meta-ExternalAgent, Applebot-Extended) are closed; those that do a live link in the reply (ChatGPT-User, OAI-SearchBot, PerplexityBot, DuckAssistBot, YouBot, MistralAI-User) are omitted.
We did not invent the division of crawlers into training and search ones. OpenAI itself documents the difference between GPTBot and ChatGPT-User / OAI-SearchBot in the help for developers (platform.openai.com/docs/bots) — that is, access control via robots.txt is technically provided by the vendor.
Of all the sites we measured that week, there was exactly one such robots.txt.
