Voice Search and Assistants: The One-Answer Rule

Behind the wheel, half past seven in the evening. Someone with an aching molar asks their phone: "Is there a dentist open near me right now?" The assistant says one name, reads out the address, and adds, "Would you like me to call?" There is no second name. There is no third. A list may well have opened on the screen, but the user is not looking at the screen; both hands are on the wheel.

The technical side of voice search has been discussed at length: speech recognition, natural language processing, long-tail queries. All of it is true, but that is not where the real difference sits. The real difference is in the shape of the result. With ten links on a screen, third place still meant something; the user scanned the list, compared, and chose. In voice there is no list. There is one answer. Ranking stops being a continuous scale and turns into a binary outcome: either you are the answer or you are not.

This article is about which data has to be machine-readable if you want that binary outcome to fall your way. One boundary up front: statistics of the "X percent of all searches are voice" kind are in circulation, but most of them have no verifiable source. We will not repeat those numbers here. Voice queries are also not reported as a separate row in any analytics dashboard; what that does to measurement gets its own section at the end.

Where a spoken query differs in shape from a typed one

A person at a keyboard economises. A person speaking does not. When you type, you shorten the query to fit a search box; when you speak, you build a full sentence as if someone were sitting across from you. The difference falls under four headings.

Full sentences. In a spoken query the subject and the verb stay where they belong. What arrives is a grammatical structure, not a pile of keywords.

Question patterns. "Is there", "how", "how much", "where", "are you open" — patterns like these are almost a standard component of a spoken query. That turns having your answer structured as question and answer into an advantage.

Everyday wording. In writing it is "fee"; out loud it is "how much does it cost". In writing it is "appointment"; out loud it is "can you fit me in". If your page text is written only in corporate vocabulary, it will not overlap with the sentence the user actually says.

Embedded context. We left the most critical difference for last: a spoken query usually carries a time and a location constraint. "Right now", "this evening", "near me", "nearest". These are not adjectives, they are filters. The assistant applies that filter from structured data, not from prose. This distinction sits right in the middle of the difference between local SEO and GEO: one resolves the location, the other resolves the answer, and voice search asks for both at once.

The single-answer problem: an assistant does not list, it picks

Being third on a screen is something. It earns clicks, your brand name is seen, the user weighs you up while comparing. Being third in voice is nothing. The assistant reads one name and stops.

This has three concrete effects on competition.

First, there is no longer a position called "slightly better". In classic search, moving from sixth to fourth produced a measurable gain. In voice there is no practical difference between sixth and twentieth; both are zero.

Second, the winner keeps winning for a long time. Once an assistant picks a business, the user calls it, goes there, has an experience. That experience comes back as a review, and reviews strengthen the signal. Visibility feeds itself.

Third — and this is the one most often missed — the assistant has a third option: not answering at all. If the data is missing, contradictory, or does not clear its confidence threshold, the assistant says "here is what I found on the web" and throws the ball back to the screen. A user in a car does not look at that screen. So you can lose without ever losing to a competitor. In voice search the target is not only to get ahead of the competition; it is to present data clean enough that the assistant does not hesitate.

The data behind "near me" and "are you open right now"

Do not leave the assistant to read your opening hours out of a sentence like "We are at your service weekdays 09:00-18:00". That sentence was written for a human; it has to be written separately for a machine.

For a spoken query with local intent to be answerable, four pieces of data have to exist in structured form: location, opening hours, phone number, and an action URL. The LocalBusiness schema carries all of them.

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Example Oral and Dental Health Clinic",
  "telephone": "+90-216-000-00-00",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1 Example Street",
    "addressLocality": "Kadıköy",
    "addressRegion": "Istanbul",
    "postalCode": "34710",
    "addressCountry": "TR"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": 40.99, "longitude": 29.03 },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "09:00",
      "closes": "21:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "10:00",
      "closes": "17:00"
    }
  ]
}

Three details in that block are the ones that carry weight in voice search.

openingHoursSpecification has to be genuinely per-day. If Saturday opens at a different time, it gets its own block. Covering the whole week with a single "weekdays" line leaves "are you open on Saturday" unanswered.

Use specialOpeningHoursSpecification for holidays and exception days. If you are closed on a public holiday and you announced it only on social media, the assistant will assume you are open and send the user to a locked door. That experience, once it happens, costs more than the visibility you gained.

The geo field is the foundation of the "near me" query. Even when the address text is correct, without coordinates the distance calculation is left to whether the map service matches you correctly.

For the general logic of writing schema, how to choose fields and how that connects to trust signals, see the article where we take schema markup and E-E-A-T together.

Content written the way people speak: finish the answer in the first sentence

A voice assistant does not read a paragraph from start to finish. It finds the answer, shortens it, and reads it out. That makes the structure of your text more decisive than its tone.

Ask the question on the page word for word. Write FAQ blocks not under headings like "Pricing" but in the sentence the user actually says: "How long does implant treatment take?" The question itself is the matching surface.

Finish the answer in the first sentence. Inverted pyramid. The first sentence has to make sense when it is lifted out and read on its own; context, conditions and detail come in the sentences after it. A paragraph that opens with "the answer to this depends on several variables" does not produce an answer an assistant can read.

One question, one answer. If you answer three questions in a single paragraph, the assistant cannot tell which part to take.

When you give a number, give the condition with it. There is a difference in trust between "usually 3-6 sessions" and "3-6 sessions". Stating the range instead of speaking with certainty raises the odds of being quoted over the long run.

The same logic applies to city and district pages; we went through how to build them step by step in the article on writing city-level service pages.

Consistency of phone and address data: a contradiction silences the assistant

In how many places is a business phone number written down? Site footer, contact page, JSON-LD schema, Google Business Profile, Apple Business Connect, map applications, industry directories, social media profiles, old campaign pages. Nine sources, nine points of update.

When the number changes and not all of them are updated, a contradiction appears. In classic search this is a weak signal that drags the ranking down. In voice search the outcome is harsher: when the assistant cannot decide which number is correct, most of the time it does not read the number at all. The sentence "Would you like me to call?" never gets said, and the flow breaks there.

A practical checklist:

• Write the address identically everywhere. "Cad." and "Caddesi", the abbreviated and spelled-out Turkish words for avenue, can be read as two different strings.
• Pick a single primary number. Keep campaign numbers as secondary and out of the schema.
• Delete records for closed branches and old addresses from directories; taking them off the site alone is not enough.
• In multi-branch businesses, give every branch its own page and its own LocalBusiness record. Three addresses on one page breaks the assistant's location matching.

The in-car and headphone context: the user's hands are full

A significant share of spoken queries arrive in a situation where the user cannot look at a screen: driving, walking, shopping, in the kitchen. That context has one single design consequence: the answer has to end in an action.

A user at a screen accepts the sentence "fill in the form for detailed information". A user behind the wheel does not. There are three things they can do: call, get directions, leave an appointment request. All three have to be possible in one step.

• The phone number should sit on the page as text and as a tel: link. A number embedded in an image cannot be read by a machine.
• The booking URL should be separate and direct; a modal opened with JavaScript is an answer the assistant cannot give.
• The map link should match the coordinates.
• Contact details should not be obfuscated in the name of bot protection. On this site the email obfuscation feature was deliberately turned off: with the address hidden, browsers that do not run JavaScript could not see the contact details at all.

The context is especially sharp in hospitality; we covered how to set up reservation questions and "are you open right now" questions separately in the article on GEO for hotels, restaurants and cafes.

The limit of measurement: voice queries are not reported separately

This is the point where you have to be honest. There is no "voice query" filter in Search Console. There is no "came from an assistant" source in analytics. A user arriving through voice search most often arrives as a direct phone call and never touches your web analytics at all.

Which means you cannot measure voice search performance; you can only read it indirectly. There are four signals worth looking at.

None of these four isolates voice. Someone who searched by typing also clicks the tel: link. But when the trends move together they give you a direction. The most honest sentence available is this one: most of the improvements aimed at voice search — structured opening hours, consistent NAP, question-headed content, a clickable phone number — are already the general infrastructure of local visibility. Not doing them because you cannot measure them also weakens the things you can measure.

Which businesses should make this a priority, and which can leave it for later

Priority is set at the intersection of two components: a physical location and urgency. Where both are present, voice search is the highest-return job on the list. Where one is missing, it moves down the order.

For the businesses lower down the table this is not a "do not bother", it is a "put it later in the order". A law firm winning a client through voice search is possible but rare; the same effort spent on content depth returns more.

Three jobs are enough to start with: write the LocalBusiness schema together with per-day opening hours, level the phone and address data across all nine sources, and put your ten most-asked questions on the page in the sentence the user actually says, with the answer finished in the first sentence. Once those three are in place, the argument about measurement becomes meaningful. If you want to talk through where to start in your own business, write to us from the contact page.

Frequently Asked Questions

Do I need a separate page or a separate site for voice search?

No, a separate page or subdomain is not needed. Voice search does not use a separate index; it reads the pages you already have. What has to be done is to make the opening hours, location and phone data on those same pages structured, and to write the content in a question-and-answer shape. Creating a dedicated "voice search page" produces no gain beyond the risk of duplicate content.

How many results does an assistant read out in a voice search?

For queries with local intent a single business is usually read out; in some cases two or three options are listed for the user. This is fundamentally different from the ten-result list shown on a screen. The practical consequence is this: in voice search the gap between being first and being sixth is not a difference of degree, it is a difference of existing at all. There are also cases where the assistant finds the data insufficient, reads no name at all and sends the user back to the screen.

What does it take to show up in "near me" queries?

Four pieces of data have to be machine-readable: coordinates, per-day opening hours, phone number and address. These correspond to the geo, openingHoursSpecification, telephone and address fields in the LocalBusiness schema. Writing "open weekdays 09:00-18:00" in the page text is not enough; the assistant applies the time filter from structured data, not from prose. For holidays and exception days, specialOpeningHoursSpecification has to be filled in as well.

Can I measure the traffic that comes from voice search?

You cannot measure it directly. Search Console does not report voice queries separately, there is no traffic source called an assistant in analytics, and the result of a voice search is most often a phone call that never touches the website at all. What you can do is read it indirectly: the share of question-shaped long-tail queries, clicks on the phone link, direction and call requests in the business profile, and how all of these are spread across the hours of the day. These signals do not isolate voice, but they give you a direction on the trend.

Which businesses should prioritise voice search optimisation?

Businesses that have a physical location and an element of urgency in the customer need should make it a priority: emergency dentistry, locksmiths, tow trucks, on-duty pharmacies, vets, auto repair, restaurants, cafes, hotels, car parks. In fields where the decision takes time and the user compares things in writing — law firms, accountancy practices, B2B software, agency services — voice search comes later in the order. For those businesses the same effort spent on content depth delivers a higher return.