Tecof • September 15, 2026
How Voice Search Is Changing E-commerce
In Brief
Voice search is what happens when someone speaks a query instead of typing it, through a phone assistant, a pair of headphones, a car screen, or the microphone button inside a shopping app. For e-commerce the issue is not the voice itself but the fact that a spoken query differs from a typed one: it is longer, more often phrased as a question, closer to everyday speech, and usually expects a single answer. As of 2026 the question is no longer "should we set aside a separate budget for voice search" but "can our pages answer a spoken question correctly in a single paragraph".
Saturday afternoon, 15.20. A user in Ankara, driving, says to their phone "where is the nearest car accessory shop". The assistant reads out one business and lists two more on screen. That evening at home, hunting for the same product, the same person types "brc lpg filter price" into the phone and this time sees ten blue links. In a store's Search Console data the trace of those two behaviours looks like this: of 42,000 total clicks, 2,900 come from queries that open with a question word, those queries average 5.8 words, and typed queries average 2.9.
The real cause is not that voice changes the interface but that it changes the number of answers. On screen there are ten results and the user chooses; in voice one answer is usually read aloud and the device does the choosing. The effect of voice search on e-commerce fits in that one sentence: the source of the traffic does not change, the number of winners does.
How a Spoken Query Differs From a Typed One
It is a mistake to treat voice search as a separate channel. A spoken query goes to the same search engine, hits the same index, and is answered from the same pages. What changes is the query itself, and that change decides which of your pages shows up.
Length and question form
People abbreviate when they type and do not when they speak. Someone who types "red winter coat women" says out loud "how much is a red winter coat for women". The difference is not three words, it is the shape of the sentence: a spoken query is a question, and a question expects an answer. In Turkish the most frequent patterns are well known and can be listed: where: "where is the nearest ...", "where can I buy ...". how much / how many: "how much is ...", "how many days does ... take", "what size should I wear". how: "how do I clean ...", "how do I install ...". can I: "can I return ...", "is ... machine washable".
What these patterns share is that the product page already holds the answer to every one of them. Delivery time, size chart, washing instructions, return terms. The problem is not missing information but information that was never written as an answer. "Our products are carefully packaged and dispatched as soon as possible" is not an answer. "Orders placed before 16.00 ship the same day; delivery inside Istanbul takes 1 business day" is an answer.
The suffix and vowel problem in Turkish
Turkish speech recognition has improved substantially over the last five years, but two problems specific to e-commerce persist. The first is suffixes: the system infers from context whether it heard "montu" or "montun", and when it infers wrong the query changes completely. The second is brand and model names. Brands with English pronunciation get mangled inside Turkish speech; a query for "Xiaomi" can land in text as "şaomi", "siyaomi" or "ksiaomi". The same happens with measurements: "50 ml" is transcribed sometimes as "elli mililitre" and sometimes as "50 mL".
The practical consequence is this: your product and category names need to carry not only the official spelling but the common pronunciation somewhere. That does not mean stuffing the title; it means placing it naturally in the product page copy. Putting a phonetic spelling in brackets next to the brand is overkill; mentioning the brand once more inside a sentence in the description is enough. When you write product descriptions with AI, adding these patterns to the prompt as a rule is cheaper than fixing them in bulk later.
Intent: information, place, purchase
Spoken queries are not all asked for the same reason and they are not all valuable to e-commerce. Three groups is enough. Informational queries: things like "how do I wash cashmere". High volume, low conversion, but they bring traffic to content pages. Place queries: things like "where is the nearest ...". The most valuable group for a business with a physical shop, and nearly worthless for a pure online seller. Transactional queries: things like "order ...", "how much is ...". The lowest volume and the highest value group, and this is where the real share of voice shopping becomes visible: small.
| Property | Typed query | Spoken query | Effect on e-commerce |
|---|---|---|---|
| Average length | 2-3 words | 5-8 words | Long-tail pages come forward |
| Sentence structure | String of keywords | Full question | FAQ and guide content wins |
| Results returned | 10 blue links | 1-3 answers | Second place loses its value |
| Local share | Low | High | Having a shop is an advantage |
| Purchase intent | Medium-high | Low-medium | Limited direct revenue expectation |
The Single Answer Problem and AI Assistants
The real difficulty voice search creates for e-commerce is structural, not technical. In on-screen search even tenth place picks up some clicks. In voice there is no tenth place.
What position zero changes
When the search engine shows the answer to a question in a box above the results, that is a featured snippet, commonly called "position zero". A spoken answer is very often read out of that box. So visibility in voice search comes less from ranking first than from writing the answer in a form the engine can quote. If the page in first place wrote its answer loosely, the page in third gets read.
The shape of a quotable paragraph is well defined and not strange: ask the question verbatim in the heading, give the answer in 40-55 words in the first paragraph beneath it, complete the answer in the first sentence, and leave the reasoning to the sentences after. A paragraph that opens with "the answer to this depends on several factors" never gets read out.
Assistants and the overlap with AEO
Part of the spoken query volume now goes not to a classic search engine but to a language-model assistant. The user asks the phone, the assistant reads out a single answer assembled from several sources, and sometimes names no source at all. That takes voice search out of being a separate discipline and makes it part of the same job as answer engine optimisation (AEO) and generative engine optimisation (GEO). In practice the work is identical: clear definitions, answers with numbers, current dates, quotable sentences.
Honesty is needed here: being named in an assistant's answer may bring you no clicks. What it brings is your brand name staying in the user's head, and that is hard to measure. So voice search and assistant visibility should be budgeted against brand awareness and long-term search share, not against a direct revenue target.
What actually gets read out
The answer an assistant reads usually comes from one of three places: a featured snippet, a field marked up with structured data (price, stock status, opening hours), or information on the business profile. If your product page price is not marked up with structured data, the answer to "how much is it" comes from your competitor's page. This is the most concrete and cheapest improvement available for voice search.
The Technical Base: Schema, Speed, Mobile
There is no separate technical stack for voice search. What there is, is three jobs you should be doing anyway being punished more harshly in voice.
Structured data
Structured data is the method of marking up the information on a page so a machine can read it. For a system trying to produce a spoken answer, that is far more reliable than trying to interpret prose. In e-commerce four schema types cover ninety percent of the work.
| Schema | What it marks | Which spoken question it answers | Priority |
|---|---|---|---|
| Product | Name, price, currency, stock, brand | "how much is ...", "is ... in stock" | High |
| FAQPage | Question and answer pairs | "how do I clean ...", "can I return it" | High |
| LocalBusiness | Address, phone, opening hours | "where is the nearest ...", "what time do they close" | High if you have a shop |
| Organization | Brand name, logo, contact | "whose brand is ...", "customer service number" | Medium |
Two warnings are needed. First, the information in the schema has to match what is visible on the page; showing 1,499 TL on the page and marking 1,299 TL in the schema is grounds for a manual action. Second, the display of FAQPage markup in search results has been narrowed over time; write the question-and-answer block anyway, because the real gain is not the rich result but the fact that the answer is quotable.
Page speed and mobile
The large majority of spoken queries happen on mobile and often on the move. If the user is walking with a phone in hand, they close a page that does not open in three seconds. The target here is not an abstract speed score but two concrete thresholds: the largest content element arriving in under 2.5 seconds, and the page not jumping about as it loads. The voice-search side of the app-versus-site debate is equally clear: assistants read web pages, and in-app content usually never enters those answers. In choosing between a mobile app and a mobile-friendly site, search visibility is a line that counts against the app.
Writing titles and descriptions
A page title written for spoken queries differs slightly from one written for typed queries: it can contain the question. "How Do You Wash a Cashmere Jumper?" matches a spoken query better than "Cashmere Care Guide". The meta description is never read out in a voice answer, but it decides click-through rate, and that indirectly affects ranking. The rules of title tag and meta description optimisation do not change for voice; only the share of question-form titles rises.
Product names you can say out loud
Read your product names aloud. "TX-4471 BLK 44 ERK PNT" is not a product name, it is a stock code, and it matches no spoken query at all. A product name that matches in voice looks like this: "Men's Black Classic Trousers Size 44". Keep the stock code in its own field on the product page; put the name a human would say in the title. This change works not only for voice search but for on-site search and marketplace matching too.
Where It Pays Off and Where It Does Not
Most of what gets written about voice search overstates its share. The honest picture is this: spoken queries take up a non-trivial slice of total search volume, but purchases completed by voice are still a very small proportion. Investment decisions should follow that.
Deciding by category
| Category | Spoken query volume | Buying by voice | Decision |
|---|---|---|---|
| Grocery, everyday consumables | High | Medium | Invest: voice works for repeat orders |
| Local services, retail with shops | High | Low | Invest: place queries turn into visits |
| Spare parts, technical products | Medium | Low | Be selective: write FAQ and fitment content |
| Fashion, apparel | Medium | Very low | Do not invest: visual choice does not happen by voice |
| Jewellery, furniture, high ticket | Low | Very low | Do not invest: long, visual decision process |
The logic in the table is simple: voice works for products where the user already knows what they want and does not need to see it. A kilo of rice gets ordered by voice, a dress does not. So in fashion, budget spent on voice search returns less than the same money spent on improving conversion rate.
The role of local search
For businesses with a physical shop this is where the most concrete return on voice search sits. Combined with the device's location, "where is the nearest ..." works almost like a guaranteed visit. And the work is not on the page, it is on the business profile: address, phone, opening hours, holiday closures and category must be correct and current. A profile with the wrong opening hours sends every visitor you won in voice search to a closed door. Getting that one field right does more than dozens of optimisations on the site.
Voice search inside your own site
Adding a microphone to your own search box is a separate matter and usually unnecessary. On a mobile browser the keyboard opens anyway and the user is used to typing. In-app voice search behaves differently: in apps like Trendyol and Hepsiburada the microphone button sits somewhere visible and gets used, especially by people who do not want to type a long product name. If you have no app of your own, do not make this investment; if you do, look at your on-site search logs before adding a microphone. Where the search box goes unused, voice search goes unused too.
The real investment in on-site search is not voice but synonym handling and typo tolerance. Showing "pantolon" results to someone who typed "pantalon" brings far more orders than a microphone button.
Measurement: Question Queries in Search Console
The basic truth about measuring voice search is this: search engines do not tell you whether a query arrived by voice or by keyboard. So there is no such report as "voice search traffic". What you can measure is proxies, and they are good enough.
The question-pattern filter
Open the query report in Search Console and put these words into the query filter one at a time: how, where, how much, which, can, when. Record the clicks, impressions and average position for each in a table. That total is the closest proxy you have to voice search. Measure once a month; weekly measurement is pure noise.
| Indicator | How to measure | Healthy direction | Frequency |
|---|---|---|---|
| Question query share | Share of question-word queries in the total | Rising | Monthly |
| Query length | Share of queries with 4+ words | Rising | Monthly |
| Average position | Average rank on question queries | Falling into the 1-3 band | Monthly |
| Local queries | Queries containing "near", "where" | Rising if you have shops | Monthly |
| Profile actions | Directions and call clicks | Rising | Monthly |
What cannot be measured, and accepting it
You cannot systematically measure whether your name appears in an assistant's answer. The best available approach is to pick fifteen questions from your own category, ask them by hand once a month, and note who gets mentioned in the answers. That is an observation, not a metric, but done three months running it gives you direction. Automated tracking tools are not yet reliable in this area.
Connecting it to conversion
Traffic from question queries converts noticeably worse than traffic from brand queries, and that is normal; the user is still learning. Measure this traffic by the second visit rather than by the order. Look at whether the person who arrived on a content page came back within thirty days. If they do not, the problem is not the quality of the traffic but the path you built from the content page to the product page.
Getting Ready for Voice Search in Thirty Days
The plan below makes your existing pages answerable without setting up a separate voice search project. Total workload is five hours a week for one person.
Days 1-7: collect the questions
Gather questions from three sources: question-word queries in Search Console, the twenty questions customer service hears most, and the first fifty terms typed into your on-site search box. Put them all in one table and note beside each which page currently holds the answer. The questions with no answer anywhere are the real work of this project.
Days 8-14: make ten pages answerable
Pick the ten pages with the most impressions. Add two or three questions belonging to that page as subheadings, and write the 40-55 word answer directly beneath each. Do not create new pages, fix the existing ones. This week's output is ten pages and twenty-five answers.
Days 15-21: put the structured data in place
Verify Product schema on every product page along with price, currency and stock status. Add FAQPage to the pages where you added a question-and-answer block. If you have shops, review the LocalBusiness data and the business profile; check the opening hours this week without fail. Run everything through the testing tool and clear the errors.
Days 22-30: measure and lock it in
Record the question query share, the share of queries with 4+ words, and the average position on question queries in a table; that table is your baseline. Take the next reading a month later. Also ask an assistant the fifteen questions from your own category and note who gets mentioned. At the end of these four weeks you will not have a new channel; you will have thirty better-written pages and a measurable starting point.
Here is the job for tomorrow morning: read the names of your ten best-selling products out loud and check whether they match what a customer would say into a phone; where they do not, rewrite the product names the way a human would say them and move the stock code into its own field. That single edit shows its effect the same day in both voice search and on-site search. On an e-commerce setup where product data, schema and content structure sit on the same platform, these changes are made in one place and land on every page at once.
Frequently Asked Questions
Does voice search really account for a large share of all searches?
No. Spoken queries take up a meaningful share of total search, but the prediction repeated for years that "half of all searches will be voice" never happened. The more accurate framing is that spoken queries cluster in particular situations (in the car, in the kitchen, while walking) and around particular questions (place, opening hours, price, how-to). Invest against those situations.
Should I create separate pages for voice search?
No. Pages created "for voice search" get judged as thin content stuffed with question phrases, and they do damage. The right path is adding real answers to real questions on your existing product and category pages. A new page is justified only when a question has no answer anywhere.
If I change my product names, will I lose my current rankings?
Making a product name readable does not usually cause a loss, because very few people search by stock code, and keeping the code in its own field preserves that match anyway. Even so, do not change the whole catalogue at once; try fifty products, wait four weeks, and continue based on the result.
FAQPage schema no longer shows rich results. Should I still add it?
Yes. The rich result display was narrowed, but marked-up question and answer pairs are still the cleanest source available to systems that generate answers. The real gain is not the visual but that your answer can be read by a machine without ambiguity.
How do you handle transcription errors in Turkish spoken queries?
There is not much to do on the page side; you cannot fix a speech recognition error. What you can do is make your on-site search typo-tolerant and mention brand names inside a sentence in the product copy at least once. Dumping pronunciation variants onto the page as a list does not work and gets treated as over-optimisation.
Does appearing in assistant answers turn into traffic?
Partly. When the assistant gives the answer the user often does not visit the site, so the click gain stays limited. The visible effect shows up more as a rise in brand queries. So judge assistant visibility by brand search volume rather than by direct revenue.
Should I add voice search to my app?
Only if the search box in your app is heavily used. If search accounts for less than ten percent of sessions, adding a microphone is wasted development. Spending the same development time on a synonym dictionary and better filters brings more orders.
What is the difference between voice search, AEO and GEO?
Voice search is an input method; AEO and GEO are about how the answer is produced. In practice you do the same work: asking the question in the heading and giving a short, numeric answer beneath it pays off in all three. There is no need for a separate budget or a separate team; think of them as three outputs of the same content work.
Does page speed really make a difference in voice search?
The direct ranking effect is limited, but the indirect effect is large. Someone making a spoken query is usually on the move and impatient; they bounce off a slow page, and over time that behaviour feeds back into ranking. Keep the target simple: the largest content element should arrive in under 2.5 seconds.