Voice Search Optimization in 2026: A Canadian Business Guide

Not deprecating it. Not reducing its features. Removing it. Google emailed users to say Assistant is being discontinued on compatible Android phones and tablets, with Wear OS devices, headphones, and Android Auto following. The rollout runs over several weeks, and once a device switches, there is no going back. Gemini becomes the assistant experience on Android. Assistant launched in 2016; ten years later, the product that most "voice search optimization" advice was written about is being decommissioned while that advice sits unrevised on hundreds of agency blogs.

This matters more than a product retirement usually would, because Google Assistant was not incidental to voice search SEO. It was the mechanism. The specific technical recommendations that circulated for the better part of a decade — mark up your content with speakable structured data, add FAQPage schema to win the spoken answer, optimise for the featured snippet Assistant reads aloud — were all recommendations about how one product retrieved and read one answer. Two of those three recommendations no longer apply to anyone. The third applies to a product that is being turned off.

So this is a reasonable moment to rebuild the topic from the ground up. What follows is not a refresh of the standard voice search checklist. It is an attempt to establish what is actually true about spoken and conversational search in 2026, what a Canadian business can genuinely act on, what cannot be measured, and where the real constraints sit. Some of those constraints turn out to be in your hosting infrastructure rather than your content, which is not where most of this conversation usually goes.

A warning about the rest of this article: it will contradict a great deal of what you have read on this subject. Where it does, the reasoning and the source are given so you can check.

What "voice search" actually means in 2026

The phrase has always been sloppy, and the sloppiness is the root of most bad advice about it. Three genuinely different things get bundled under one label, and they behave differently enough that treating them as one topic guarantees you optimise for the wrong one.

Path one: voice as a keyboard

Someone taps the microphone icon in the Google app, says "best web hosting for small business in Canada," and gets an ordinary results page. This is the overwhelming majority of what people call voice search.

Google's position on this has been consistent and explicit. John Mueller described it as using voice as a particular kind of keyboard: the query is transcribed, then searched normally. These queries are logged in Search Console exactly like typed ones, in the same way a query entered by swiping a mobile keyboard would be.

The practical implication is large and under-appreciated. For path one, there is no separate voice search ranking system to optimise for. There is no voice index, no voice algorithm, no voice-specific ranking factor. There is a normal web search that happened to be dictated. If you rank well for the query, you rank well when it is spoken. Everything you would do to rank for a long, conversational, question-shaped query is ordinary SEO applied to long, conversational, question-shaped queries.

Path two: assistant-mediated single answer

Someone asks a smart speaker or a hands-free device a question, and the assistant reads back one answer. No results page, no ten blue links, no scrolling. One answer, spoken, sourced from one page.

This is the path that generated all the anxiety, and it deserved some. The mechanics are different because the output is different. A results page distributes attention across many results; a spoken answer concentrates it on exactly one. Being fourth is worth something on a screen and worth nothing out loud.

It is also the path that has just had its primary implementation removed on Android.

Path three: conversational AI retrieval

Someone speaks to Gemini, or uses ChatGPT's voice mode, or asks Siri something that gets routed to a language model. The system synthesises an answer from multiple sources, often cites some of them, and holds context across follow-up questions.

This is where the volume is going, and it is not really search in the older sense. The system is not retrieving a ranked list and reading the top item. It is retrieving material, evaluating it, composing a response, and sometimes attributing it. Optimising for it is closer to what people now call answer engine optimization or AEO: being the source a model reaches for and is willing to name.

Why the taxonomy matters

Almost every piece of voice search advice in circulation conflates these three. That is how you end up with articles recommending speakable schema, which only ever applied to path two, in the same breath as recommending long-tail question keywords, which mostly matter for path one, while promising it will help you get cited by AI, which is path three and works differently again.

Keep the three separate and the picture clarifies considerably. Path one needs good conventional SEO. Path two is shrinking as a distinct surface and was never measurable. Path three is genuinely new, genuinely growing, and rewards a specific kind of content structure that this article covers in detail.

The statistic that broke a decade of voice search advice

Before going further, it is worth dealing with the number you have certainly seen: fifty per cent of all searches will be voice searches by 2020.

It is usually attributed to Comscore. Comscore never published it.

The trail has been walked by several people, most thoroughly by the SEO consultant Brodie Clark, who simply emailed Comscore and asked. Comscore's reply was direct: the "50% by 2020" prediction was not published by them. It originated as a 2014 remark by Andrew Ng, then Chief Scientist at Baidu, in an interview with Fast Company.

What Ng actually said was materially different from what got repeated. He noted that roughly ten per cent of Baidu queries at the time were voice, and predicted that within five years at least half of all searches would be conducted through images or speech. Two changes happened in transmission. The image half was dropped, leaving voice to carry the whole number. And the context, which was Baidu and the Chinese market, was quietly swapped for the North American one. Ng was describing a market with different devices, different input friction, and a writing system where speech input has advantages it does not have in English.

The figure was then popularised in Mary Meeker's Internet Trends 2016 report, which placed it on a voice search timeline against the year 2020, and from there it entered general circulation. Once it was in circulation, publications cited each other in a loop. Chase any given instance and you tend to find a link to another blog post, which links to another, which eventually arrives at a paywall or nothing at all.

I am not raising this to score a point about sourcing hygiene. I am raising it because a decade of technical recommendations was built on top of an urgency that the underlying data never supported, and those recommendations are still being handed to small businesses as current best practice. When you read that you must restructure your site for voice search immediately, the immediacy is downstream of a misquoted remark about Baidu from 2014.

The same pattern applies to two other figures that appear constantly in this space: that seventy-six per cent of local voice searches lead to a business visit within twenty-four hours, and that fifty-eight per cent of consumers use voice search to find local business information. Both circulate widely. Neither has a traceable primary source that survives checking. This article does not use them.

What we can and cannot say about Canada specifically

Here is an honest answer to a question you might reasonably want answered: how much do Canadians actually use voice search?

Nobody publishing openly knows with any precision.

The most-cited Canadian figures come from eMarketer forecasts published in 2018 and 2019, which projected 5.8 million monthly smart speaker users in Canada for 2019 and 6.7 million for 2020. Those were forecasts, they are now six and seven years old, and the market has been through the entire generative AI transition since. Current figures circulating for Canadian smart speaker penetration — around twelve per cent of households is the number that appears most often — come from statistics-aggregator sites rather than from primary research with published methodology.

There is one genuinely interesting and well-sourced Canadian observation from that older eMarketer work, and it has aged well: Canadian adoption was held back partly because mainstream voice devices launched English-first. Google supported Canadian English and French from its June 2017 market entry. Amazon's Alexa did not understand Canadian French until October 2018, nearly a year after the Echo launched here. In a country where roughly a fifth of the population speaks French as a first language, a year of monolingual capability is a meaningful drag on adoption.

The correct posture, then, is this: voice and conversational query volume in Canada is real, growing, and unmeasured. That is not a reason to ignore it. It is a reason to refuse to size your investment based on numbers nobody can substantiate, and instead to invest in the things that pay off across every retrieval path at once. Fortunately, most of them do.

Why there is no voice search ranking factor

This is the single most useful thing to internalise, so it gets its own section.

For dictated queries, Google transcribes the audio and runs a normal search. Nothing downstream of the transcription is different. There is no separate scoring pass, no voice-specific weighting, no distinct index.

For assistant-mediated answers, the assistant is selecting from results that were already ranked by the ordinary system. It is not running a different competition. It is reading the winner of the same competition, usually the featured snippet or a comparable extracted answer.

Both facts point the same direction. Voice search optimization is not a separate discipline with its own ranking factors. It is conventional SEO, evaluated under a harsher constraint.

The harsher constraint is what makes it feel like something new. Consider what changes when the output is spoken rather than displayed:

• Position one is the only position. On a results page, ranking third still earns clicks. In a spoken answer, ranking third earns nothing. The distribution is winner-take-all.
• Extraction quality becomes decisive. The system must be able to lift a coherent, self-contained, correct answer out of your page. A page that ranks well but whose answer is spread across four paragraphs and a table cannot be read aloud.
• Ambiguity is fatal. A screen reader can display a result and let the human resolve ambiguity. A spoken answer cannot. If it is unclear which city your business serves or what your hours are, the system will pick a source where it is clear.
• There is no second impression. A displayed result the user ignores still registered. A spoken answer that went to a competitor never existed as far as you are concerned.

So the work is not "optimise for voice." The work is: rank for conversational queries, make your answers cleanly extractable, and remove ambiguity. Those three things also happen to be exactly what improves your odds of being cited by an AI answer engine, which is the direction the volume is actually moving. That convergence is the strategic good news in this whole topic.

The measurement problem nobody wants to mention

Now the bad news, and it is worse than most articles admit.

You cannot measure assistant-mediated voice visibility. Not partially. Not with a workaround. Not at all.

Google's own explanation, from Mueller, is specific. When Google Assistant answers a question by reading a snippet of text from a page, Google sends the page URL to the user's phone so they can visit it, but the impressions for those queries are not logged in Search Console. A featured snippet viewed on a screen produces an impression. The same snippet read aloud by an assistant produces nothing in your reporting.

Dictated queries, path one, are logged normally. They are simply indistinguishable from typed ones. Google has discussed adding a voice segment to Search Console since at least 2016 and has never shipped it. Mueller later suggested he did not think the distinction was especially useful information, on the grounds that it amounts to entering the same keywords a different way. He also flagged a genuine technical obstacle: voice queries tend to be long, sentence-shaped, and individually low-volume, which means Search Console's own filtering would often suppress them from reports anyway.

Add it up and the measurement position in 2026 is:

What you want to measure	Can you?	What you get instead
Dictated queries as a segment	No	Aggregated with typed queries, undifferentiated
Assistant-read snippet impressions	No	Nothing. Not logged
Which pages win spoken answers	No	No reporting surface exists
Long conversational query performance	Partially	Query data, subject to low-volume filtering
AI assistant citations of your site	Partially	Third-party AI visibility tools; early, inconsistent, no ground truth

You will encounter advice recommending you isolate voice traffic by filtering Search Console for queries above six or seven words. Be clear about what that is. It is a proxy for query length, which correlates loosely with conversational phrasing. It is not a voice filter. Plenty of long queries are typed, and plenty of dictated queries are short. Used as a rough signal of how your question-shaped content performs, the filter is genuinely useful. Presented as voice search reporting, it is fiction.

The honest conclusion: treat voice as unmeasurable and invest accordingly. Do not build a business case that depends on demonstrating voice-specific ROI, because you will not be able to demonstrate it. Build instead on the overlapping fundamentals that show up in reporting you can see: rankings for conversational queries, featured snippet capture, local pack visibility, Google Business Profile interactions, page performance metrics, and increasingly AI citation tracking. Every one of those improves your voice position as a side effect, and every one of them is observable.

That is not a compromise. It is the correct strategy given the available information.

What actually determines whether you are the answer

If there is no voice ranking factor and no voice reporting, what governs whether your page is the one read aloud or cited?

Four gates, in sequence. A page has to pass all four.

Gate one: eligibility. You have to be in the candidate set, which in practice means ranking in the top handful of results for the query. Nothing else in this article matters if you fail here. This is ordinary competitive SEO: relevance, content quality, topical authority, links, technical health.

Gate two: extractability. The system has to be able to lift a clean answer out of your page. This is a structural property of your content, and it is where most otherwise-good pages lose. A well-ranked page with a buried, hedged, or fragmented answer is not extractable.

Gate three: retrievability. The page has to be fetched, rendered where necessary, and parsed, quickly and reliably. This is an infrastructure property, and it is the gate almost nobody writes about. It is covered in depth in the next section.

Gate four: unambiguity. The extracted answer has to be unambiguous about the entity it concerns — which business, which location, which service, which hours. Ambiguity gets resolved by choosing a different source.

Notice that only gate two is a content problem in the way voice search advice usually assumes. Gate one is general SEO. Gate three is hosting and engineering. Gate four is data hygiene and structured data. Any strategy that treats this as purely a content exercise is working on a quarter of the problem.

Gate three: the infrastructure layer

Here is the part of this topic that gets skipped, and it is the part with the clearest cause-and-effect relationship.

Single-answer retrieval is unusually intolerant of slow infrastructure. Understanding why requires thinking about what the system is actually doing rather than what the user experiences.

When a query arrives that a system intends to answer directly, it is working against a latency budget. The user has asked a question out loud and is waiting in silence. There is no loading spinner to look at, no partial page to start reading, nothing to occupy the wait. Silence is expensive in a way that a progress bar is not. Systems built for this scenario are conservative: they favour sources that respond fast and consistently, because a source that occasionally takes four seconds to serve is a source that occasionally produces dead air.

This is compounded by the fact that the retrieval and the answer are decoupled in time. The crawl that gathered your content happened days or weeks ago. If your server was slow, unreliable, or timing out during those crawls, the content that should have been your answer may not be in the index in usable form at all. The performance problem does not show up as a slow answer. It shows up as no answer.

So the infrastructure layer is not a nice-to-have adjacent to your content strategy. It is a precondition for it.

Time to first byte, and why it is the metric that matters most here

Time to first byte measures the interval between a request arriving and the first byte of the response leaving. It is almost entirely a server-side property: how fast your host's hardware is, how much of it you actually get, how far the request has to travel, how efficiently your application and database respond, and whether anything is cached.

TTFB is not a Core Web Vitals metric and does not appear in Google's ranking-relevant vitals set. Do not let that mislead you about its importance. TTFB is the floor under everything else. Largest Contentful Paint cannot be fast if the first byte was slow, because LCP includes the time you spent waiting for the server. A 1.8-second TTFB makes a good LCP arithmetically impossible no matter how well-optimised your front end is.

For extraction-based retrieval, TTFB matters more than it does for ordinary browsing, because the crawler's experience of your site is almost entirely TTFB plus parse time. A crawler is not waiting for your hero image to fade in. It is requesting HTML and reading it.

Rules of thumb worth holding onto:

• Under 200ms for the initial document is genuinely good.
• 200 to 500ms is acceptable and typical of competently configured shared hosting.
• 500ms to 1s indicates a real problem worth diagnosing.
• Above 1s consistently means either your hosting is underprovisioned, your application is inefficient, or your server is a long way from your visitors. Often all three.

The diagnosis matters because the fixes are completely different. An inefficient application on excellent hardware and an efficient application on oversubscribed hardware produce similar numbers and require opposite interventions.

Core Web Vitals, stated accurately

There is a lot of stale information about these, so for clarity, the current set and thresholds:

Metric	What it measures	Good	Needs work	Poor
Largest Contentful Paint (LCP)	Time until the largest visible element renders	≤ 2.5s	2.5–4.0s	> 4.0s
Interaction to Next Paint (INP)	Responsiveness across all interactions in a visit	≤ 200ms	200–500ms	> 500ms
Cumulative Layout Shift (CLS)	Visual stability during load	≤ 0.1	0.1–0.25	> 0.25

INP replaced First Input Delay in March 2024. If you are working from a document that lists FID, that document predates the change and may be stale in other ways too. Thresholds are assessed at the 75th percentile of real-user data, meaning you need three-quarters of actual visits to hit the mark, not a good score in a lab test on a fast connection.

An important nuance for this topic: Core Web Vitals are a page experience signal, not a retrieval-eligibility gate. Google has been consistent that they are one modest input among many and that genuinely relevant content is not excluded for missing them. They matter for voice and conversational retrieval more indirectly than the alarmist framing suggests, mostly because the underlying causes of bad vitals — a slow server, a bloated render path, JavaScript-dependent content — are the same causes that make a page hard to crawl and extract from. Fix the causes and the vitals improve as a symptom.

Server location and the Canadian latency question

Physical distance imposes a latency floor that no amount of software optimisation can remove. Light in fibre travels at roughly two-thirds of its speed in vacuum, and real network paths are not straight lines. A round trip from Vancouver to a server in Virginia is meaningfully slower than a round trip from Vancouver to a server in Vancouver, every single time, permanently.

For a Canadian business with a Canadian customer base, this is a structural argument for Canadian hosting rather than a marginal one. Choosing a Canadian web hosting provider with facilities in the country your visitors are actually in removes a fixed cost from every request. 4GoodHosting operates from data centres in Vancouver and Toronto, which covers the two ends of the country's population distribution reasonably well: west coast traffic terminates in Vancouver, and the Ontario–Quebec corridor, where the majority of Canadians live, terminates in Toronto.

Two honest qualifications, because this argument gets overstated in hosting marketing:

A CDN changes the calculus for static assets but not for dynamic responses. If your images, CSS, and JavaScript are served from an edge network, their delivery distance is already short regardless of where your origin sits. What a CDN does not fix, unless you are doing full-page edge caching, is the dynamic HTML response — which is precisely the thing a crawler requests and the thing TTFB measures. For a logged-out visitor hitting a cached WordPress page, edge caching helps enormously. For anything genuinely dynamic, origin location still governs.

Distance is a floor, not a ceiling. A well-configured server in Virginia will comfortably outperform a badly configured, oversubscribed server in Toronto for a Toronto visitor. Proximity is one variable among several, and it is not the dominant one when the others are badly handled. The argument for Canadian hosting is that it removes a permanent handicap, not that it substitutes for competent configuration.

HTTPS as an eligibility floor

This is no longer an optimisation. It is a prerequisite, and the reasons have compounded well past the original ranking-signal argument from 2014.

Browsers now mark plain HTTP pages as not secure in ways users notice. Modern browser features and APIs are restricted to secure contexts. Mixed-content warnings break pages in ways that are hard to diagnose. And for the topic at hand, systems that hand answers to users have obvious reasons to prefer sources served over a verified, encrypted connection.

The failure mode worth checking for specifically is partial enforcement: a site that has a valid certificate and serves HTTPS correctly when asked, but has not redirected HTTP to HTTPS at the server level, has not set HSTS, and still has internal links, canonical tags, or sitemap entries pointing at HTTP URLs. This produces two addressable versions of every page. Signals split between them, canonicalisation gets ambiguous, and crawlers waste requests. It is a common and quietly damaging configuration, and it is cheap to fix: force the redirect at the server, update internal links and canonicals to absolute HTTPS URLs, correct the sitemap, and then add HSTS once you have confirmed nothing breaks.

The render path and why JavaScript-dependent content loses

If your answer text is injected into the page by JavaScript after load, you are gambling on the retrieving system executing that JavaScript, doing so successfully, and waiting long enough for the content to appear.

Google's crawler does render JavaScript. It is reasonably good at it. But rendering is a separate, resource-constrained stage that happens after the initial crawl, and it can be delayed, incomplete, or skipped. Meanwhile, the growing set of AI crawlers and retrieval agents fetching pages for conversational systems are considerably less consistent about rendering than Googlebot is. Many of them read the served HTML and nothing more.

The safe rule for anything you want extracted and quoted: it must be present in the HTML the server sends. Not assembled client-side. Not loaded on scroll. Not behind an accordion that populates on click. Not in a tab whose content loads on activation.

This has a specific and common implication for FAQ sections. Collapsible accordions are good design and fine for retrieval if the answer text is in the served HTML and merely hidden with CSS. They are a problem if the text is fetched when the user expands the item. From the outside these look identical. Check the served source, not the rendered page. In your browser, view source rather than inspecting the DOM, or fetch the URL with curl and search the output for your answer text.

Structured data has to be served, and has to match

Same principle, applied to schema markup. JSON-LD injected by a tag manager after page load is markup you are hoping gets seen. JSON-LD in the served document is markup that will be seen.

The second requirement is equally firm and more often violated: structured data must correspond to content visible on the page. Google's guidance on this is unambiguous, and it holds for AI features too — Google's position is that no special schema is needed for AI Overviews or AI Mode, but that any structured data you do use should match what is actually on the page. Marking up an FAQ whose questions and answers do not appear in the visible content, or a business with hours that contradict the hours in your footer, is a spam pattern rather than an optimisation.

The infrastructure audit, in table form

Factor	Why it matters for single-answer retrieval	How to check	Typical fix
TTFB	Sets the floor for every other timing metric; dominates crawler experience	curl -w "%{time_starttransfer}" -o /dev/null -s <url>, run repeatedly; WebPageTest from a Canadian location	Caching layer, better-provisioned plan, PHP and database tuning, move origin closer to visitors
Server proximity	Fixed latency cost on every dynamic request	Compare response times from Canadian and US test locations	Host in Canada if your audience is Canadian
LCP / INP / CLS	Page experience signal; symptoms of the same causes that impair crawling	Search Console Core Web Vitals report (field data), PageSpeed Insights	Depends entirely on which metric fails; diagnose before acting
HTTPS enforcement	Eligibility floor; partial enforcement splits signals	Request http:// version and confirm a 301 to https://; audit internal links, canonicals, sitemap	Server-level redirect, absolute HTTPS internal links, corrected sitemap, then HSTS
Answer text in served HTML	Determines whether the answer can be extracted at all	`curl <url> \	grep -i "<your answer phrase>"`	Server-render it, or move it out of JS-populated components
JSON-LD in served HTML	Same, for structured data	View source and search for application/ld+json	Render server-side rather than injecting via tag manager
Schema matches visible content	Mismatch is a spam signal, not an optimisation	Rich Results Test plus manual comparison against the page	Correct the markup, or add the content it claims
Uptime and response consistency	Intermittent failures during crawls remove content from the index	External monitoring with a short check interval; Search Console crawl stats	Diagnose the intermittency; often resource limits under load
Response under concurrency	Answer-eligible pages get bursty traffic; degradation is invisible in single-request tests	Load test at realistic concurrency	Dedicated resources rather than shared, or a caching layer that absorbs the burst

That last row deserves emphasis because it is the one that catches people out. A site can test beautifully on a single request and collapse at twenty concurrent ones. Shared hosting environments allocate resources across many accounts, and your effective performance depends partly on what your neighbours are doing. If a page becomes the answer to a moderately popular question, the resulting traffic is spiky and poorly predicted by your averages. This is the point at which moving from shared hosting to a VPS with genuinely dedicated CPU and memory stops being a growth aspiration and becomes the thing standing between you and a page that intermittently fails to serve.

The schema advice that expired

This section will contradict most of what you have read, and it is the single most actionable part of this article, because a meaningful number of Canadian businesses are currently paying for implementation work that cannot produce a result.

Speakable structured data: not for you

Speakable markup identifies the sections of a page best suited to being read aloud by text-to-speech. It is recommended constantly, in guides aimed at general small-business audiences, as a core voice search tactic.

Here is its actual status, from Google's own documentation. It is labelled BETA, with the standing disclaimer that requirements and guidelines may change. It is available to news publishers only. It is limited to English-language content for users in the United States. Google has said it hopes to expand to other languages and countries once enough publishers implement it, a condition that has not been met in the eight years since. On the Schema.org side, speakable sits in the pending extension rather than the core vocabulary. And its delivery mechanism is Google Assistant, which is the product currently being switched off.

For a Canadian small business, that is four independent disqualifications. You are not a news publisher, you are not in the United States, a portion of your audience may not be reading in English, and the surface it feeds is being decommissioned.

If someone has recommended speakable markup for your plumbing company, your law firm, or your online shop, they have not read the documentation. Implementing it will cost you time and produce nothing.

FAQPage rich results: gone as of May 2026

This one is more consequential because FAQ schema was recommended almost universally, and the advice was reasonable for a while.

The withdrawal happened in two stages. On 8 August 2023, Google announced it was reducing the visibility of FAQ rich results, stating that going forward they would only be shown for well-known, authoritative government and health websites, and that for all other sites the rich result would no longer be shown regularly. The same announcement limited HowTo rich results to desktop; HowTo was fully deprecated shortly after. From that point on, FAQ rich results were effectively invisible for ordinary commercial sites, and had been for nearly three years before most people noticed.

The second stage closed it entirely. Google's FAQPage documentation now carries a deprecation notice: FAQ rich results stopped appearing in Google Search on 7 May 2026. The Search Console FAQ search-appearance filter, the rich result report, and Rich Results Test support are being removed in June 2026, and Search Console API support for FAQ rich result data in August 2026. The narrow government-and-health eligibility that survived 2023 is gone as well.

What this means in practice:

• FAQPage markup no longer produces a visible search feature for anyone. If your consultant's deliverable was "FAQ rich results," that deliverable no longer exists.
• The markup itself is not deprecated and is not harmful. FAQPage remains a valid Schema.org type. Google has indicated it will continue parsing FAQ markup to understand pages. Leave existing implementations in place; there is no need to strip them out.
• If your reporting pulls FAQ rich result data through the Search Console API, those calls will start returning nothing. Export any historical data you want to keep and update the pipelines.
• The FAQ content on your page still matters enormously. This is the crucial distinction. The rich result is dead. Question-and-answer content that directly answers real questions in extractable form is more valuable than it has ever been, because that is what conversational systems and answer engines consume. What died was the cosmetic SERP treatment, not the underlying content strategy.

There is a useful lesson buried in this. If your FAQ section was underperforming when rich results were live, the deprecation did not cause that; it just removed the decoration that was hiding it. Schema over thin content was never a strategy.

What structured data is still worth implementing

Plenty, and it is mostly the unglamorous types:

• LocalBusiness (or the appropriate subtype) with complete, accurate name, address, phone, geo coordinates, opening hours, and service area. For local voice queries this is the highest-value markup available to a small business, by a wide margin.
• Organization on the homepage, defining the entity, logo, official social profiles via sameAs, and contact points. This is entity-establishment work and it feeds how systems understand who you are.
• Product and Offer for anything you sell, where the fields are genuinely applicable.
• Service for service businesses, tied to the areas you actually serve.
• Article with accurate datePublished and dateModified on editorial content.
• BreadcrumbList, which still produces a visible result and helps systems understand your site's hierarchy.

The rule that governs all of them: mark up what is on the page, accurately, and keep it in sync when the page changes. Stale structured data is worse than none, because it actively misinforms.

Content structure for spoken and synthesised answers

With the expired tactics cleared away, here is what genuinely determines extractability. This is the durable part of voice search optimization, and it has barely changed in a decade because it is grounded in how extraction works rather than in any particular product.

Answer first, then elaborate

The structural pattern that wins extraction is simple and most writers resist it: state the answer immediately, in a self-contained sentence or two, then explain.

Most business writing does the opposite. It establishes context, builds toward the point, and delivers the answer in the third paragraph as a conclusion. That is often better prose. It is much worse for extraction, because the extracting system is looking for a passage that answers the question without requiring the surrounding text.

The test to apply: could this paragraph be lifted out and read aloud to someone who has not seen the page, and would it answer their question correctly? If it depends on the preceding sentence for its subject, or on a table below it for its numbers, it fails.

Target roughly forty to sixty words

Extracted answers cluster in a fairly narrow length band. Google's own guidance for speakable sections recommends around twenty to thirty seconds of content, or roughly two to three sentences, which is a useful proxy even though the feature itself is not available to you.

Forty to sixty words is the working range. Shorter tends to be too thin to be useful. Much longer gets truncated, often mid-thought, which is worse than not being selected.

This does not mean writing short pages. It means that within a long, thorough page, the direct answer to each question you are targeting should exist as a compact, self-contained block, immediately after the heading that poses the question.

Question-shaped headings

Use the actual question as the heading, phrased the way a person would say it. "How much does web hosting cost in Canada?" outperforms "Hosting Pricing" for this purpose, because it gives the retrieval system an explicit match between the query and a labelled section.

Restraint is required. A page composed entirely of question headings reads like a FAQ dump and serves the reader poorly. Use question headings where the section genuinely answers a question people ask, and ordinary descriptive headings elsewhere.

Plain language, honestly qualified

You will read that the average voice search result is written at a ninth-grade reading level, and that you should therefore write to that level. The figure traces to a 2018 study by Backlinko that analysed a large sample of Google voice search results. It was real research on real data, and it is now eight years old, predates the generative AI transition, and described what results were rather than what Google rewards.

Treat it as a directional observation rather than a target. The defensible version of the advice does not need the statistic: clear, direct sentences with concrete vocabulary are easier to extract, easier to synthesise, and easier for a listener to follow when they cannot re-read. Complex, subordinate-clause-heavy sentences with abstract nouns are hard to lift cleanly out of a page. Write plainly because it works, not because of a number from 2018.

Practical version: shorter sentences on average, one idea per sentence in the answer blocks, concrete nouns over abstractions, and no unexplained jargon in a passage you want extracted.

Conversational and long-tail query patterns

Spoken queries are longer and more natural than typed ones. People type "vps hosting canada price" and say "how much does a VPS in Canada cost per month?" The intent is the same; the surface form differs substantially.

This is where genuine keyword work still pays, and where the shift to conversational AI has actually raised the value rather than lowered it:

• Cover the full question forms: who, what, where, when, why, how, how much, how long, is it, can I, should I, what happens if.
• Mine your actual sources of real language. Support tickets, sales call notes, the questions customers ask on the phone, your Google Business Profile Q&A, site search logs. These beat keyword tools for phrasing because they are transcripts of real speech.
• Include the qualifiers people actually say: near me, open now, cheapest, best for small business, in Canada, in Vancouver, this weekend.
• Answer the follow-up question in the same page. Conversational systems hold context across turns. A page that answers the question and its obvious successor is more useful to that kind of interaction than a page that answers one thing.

Entity clarity

This underpins gate four, and it is mostly unglamorous consistency work. Be unambiguous and consistent about who you are, where you are, what you sell, and when you are open, across your site, your structured data, your Google Business Profile, and every directory listing that mentions you.

Systems that hand a single answer to a user are conservative about ambiguity. If your hours say one thing on your contact page, another in your schema, and a third on your Business Profile, the safe behaviour is to use a source that does not contradict itself. Often that source belongs to a competitor.

Local search: where voice genuinely concentrates

If you strip away the hype, the clearest real-world use case for spoken queries is local and immediate. Someone driving, cooking, or carrying groceries asks whether a place is open, how to get there, or who nearby can help right now. Hands are busy, a screen is inconvenient, and the answer needed is short and factual.

That specific pattern is where a small business's voice exposure actually lives. And the surface that answers it is usually not your website.

Your Google Business Profile is the primary voice surface

For queries about hours, location, phone number, directions, and whether you are open now, the answer generally comes from your Google Business Profile rather than from crawled page content. This reverses the usual priority order. For local voice queries, profile accuracy outranks on-site optimisation.

What matters, in rough order of impact:

• Hours, kept genuinely current, including holiday hours. Statutory holidays vary by province in Canada, which is a real trap: Family Day is not observed in every province, Saint-Jean-Baptiste Day matters in Quebec, and Civic Holiday coverage differs. Wrong holiday hours produce a confidently wrong spoken answer, and the customer who drove to a closed shop blames you rather than the assistant.
• Primary category chosen precisely. The category drives which queries you are considered for. Too broad and you compete with everyone; too narrow and you are invisible for the terms people actually say.
• Service area defined accurately for businesses that travel to customers rather than receiving them.
• Phone number that is answered. Voice queries convert to calls at a high rate for the simple reason that the device is already in the user's hand and calling is the path of least resistance.
• The Q&A section, seeded and owner-answered. This is one of the most neglected fields in local search. Anyone can post a question and anyone can answer it, which means incorrect user-submitted answers sit on your profile unchallenged. Post the questions customers actually ask and answer them yourself, in your own words, accurately.
• Reviews, with responses. Volume and recency both matter, and review content is a source of natural language about your business that you did not have to write.

NAP consistency across the wider web

Name, address, and phone number should be byte-identical everywhere they appear: your site, your schema, your Business Profile, Yelp, Yellow Pages, industry directories, your social profiles.

Canadian specifics worth being deliberate about:

• Postal code formatting. V6B 1A1 with a space is the Canada Post standard. Pick that form and use it consistently.
• Province abbreviations. Choose two-letter codes (BC, ON, QC, AB) and stay consistent rather than mixing them with full names.
• Phone format. Consistent throughout, and in your structured data use +1 international format.
• Suite and unit designations. "Unit 4", "#4", and "Suite 4" are three different strings to a matching system. Choose one.

None of this is interesting work. All of it feeds directly into whether a system trusts your data enough to speak it aloud.

Which local queries you can realistically win

Be honest about the competitive reality. "Near me" queries for competitive categories in Vancouver, Toronto, or Calgary are contested by businesses with more reviews, longer histories, and bigger budgets. The winnable ones are narrower:

• Your specific service plus your specific neighbourhood, rather than the whole city.
• Niche service variants rather than the head category.
• Questions with a factual answer only you have: your hours, your parking situation, whether you do a particular thing.
• Time-qualified queries where availability is the differentiator, such as after-hours or weekend service.

The bilingual dimension, which nobody covers

Canada's two official languages create a voice search situation with no real equivalent in American or British guidance, and it goes almost entirely unaddressed in the material circulating on this topic.

Spoken French is harder for these systems than written French. Text search handles Canadian French reasonably well. Speech recognition has to handle Quebec French phonology, which differs substantially from European French in vowel realisation, affrication, and everyday vocabulary. Recognition quality has improved a great deal but remains uneven, and the recognition step happens before any of your optimisation work becomes relevant. If the transcription is wrong, nothing downstream helps.

Adoption was structurally delayed by language support. As noted earlier, Google supported Canadian English and French from its 2017 market entry, while Alexa did not understand Canadian French until October 2018, almost a year after the Echo launched here. That gap shaped early adoption patterns in Quebec and is part of why Canadian penetration figures lagged comparable markets.

Practical implications if you serve francophone customers:

• Genuinely translated content, not machine output. Extraction quality depends on natural phrasing, and machine translation produces phrasings people do not actually say.
• Correct hreflang implementation between your English and French versions, with self-referencing tags on each.
• French-language structured data on French-language pages, including localised business descriptions.
• Question headings written in the French people actually speak, which for a Quebec audience is not always textbook French.
• Bear in mind that Quebec's language legislation imposes requirements on commercial communications that go beyond SEO considerations. If you operate in Quebec, get advice on compliance rather than treating French as an SEO tactic.

For a business serving both markets, this is a genuine opportunity rather than only a cost. French-language competition for conversational queries in most Canadian verticals is thinner than English-language competition. The pages are easier to win.

Privacy, data residency, and voice interactions

Voice raises privacy questions that text does not, and Canadian businesses operate under a specific framework.

The Personal Information Protection and Electronic Documents Act governs how private-sector organisations in Canada collect, use, and disclose personal information in commercial activity. Where a province has substantially similar legislation, that applies instead: Quebec, British Columbia, and Alberta each have their own regimes, and Quebec's has been substantially strengthened in recent years.

Voice interacts with this in ways worth thinking through:

Voice recordings are biometric-adjacent personal information. A voice recording identifies a person in a way a typed query does not. If you deploy any voice feature that captures audio — a voice search box on your site, a voice-enabled support tool, a call recording system — you are collecting personal information and you need a lawful basis, meaningful consent, a stated purpose, retention limits, and a plan for access requests.

Third-party voice tools move data across borders. Most voice recognition services process audio on infrastructure outside Canada. That is not prohibited, but PIPEDA requires transparency about it, and organisations remain accountable for information transferred to third parties for processing. If you embed a voice feature, know where the audio goes and disclose it.

Data residency is a competitive consideration in some sectors. For businesses serving Canadian healthcare, legal, financial, education, or public-sector clients, where the data physically sits is often a procurement requirement rather than a preference. Hosting on Canadian infrastructure removes a question from the sales process. It is a smaller factor than hosting marketing suggests for a general small business, and a larger one than most general SEO advice acknowledges for regulated sectors.

The performance argument and the privacy argument point the same way for a Canadian audience, which is convenient but worth separating in your own reasoning. Latency is a technical fact. Data residency is a compliance and trust matter. They are both real, and they are not the same argument.

Six Canadian businesses, and how much voice actually matters to each

Generic advice fails here because voice exposure varies enormously by business type. Below are six realistic scenarios with an honest assessment of each. Note that in three of the six, the correct answer is that voice search deserves little of your attention.

A restaurant in Vancouver: high exposure, profile-led

Almost all of the voice queries reaching this business are factual and immediate: are you open, where are you, do you take reservations, do you have vegetarian options. These are answered from the Business Profile, not the website.

Priority: hours accuracy including holidays, menu marked up and current, reservation link functional, Q&A seeded with the questions staff answer on the phone twenty times a day. Website performance matters mainly so the menu loads instantly on a phone with poor signal outside the restaurant.

What not to bother with: long-form content targeting conversational keywords. Nobody asks an assistant a 900-word question about your restaurant.

An emergency plumber in Calgary: high exposure, highest stakes

The archetypal voice use case. Water is coming through the ceiling and the customer's hands are occupied, so they speak the query. Intent is urgent, commercial, and immediate.

Priority: service area precisely defined, 24-hour availability reflected accurately in the profile (and genuinely honoured), a phone number answered at 3am, neighbourhood-level pages that are fast on mobile data, review volume and recency.

Infrastructure note: this is a business where the traffic pattern is genuinely bursty. A cold snap in Calgary produces a spike in burst-pipe searches across the whole city at once. A site on oversubscribed shared hosting that degrades under concurrency will fail precisely when the year's revenue is available. This is a legitimate case for dedicated resources.

A law firm in Toronto: low voice exposure, high AI-answer exposure

People do not select legal representation by asking a smart speaker. They do ask conversational questions — how long do I have to file, what does this term mean, do I need a lawyer for this — and increasingly they ask a language model rather than a search engine.

Priority: authoritative, well-structured answers to genuine legal questions with clear expertise signals. The target is being the source an AI answer engine cites, not being read aloud by a speaker.

What not to bother with: voice-specific tactics of any kind. This is an AEO problem wearing a voice costume.

An e-commerce store: low exposure, with narrow exceptions

Voice commerce forecasts have been consistently overstated for a decade. People do not buy considered purchases by voice, because they want to see the item. The genuine exceptions are reorders of known consumables and order-status queries, both of which happen inside a platform's own ecosystem rather than through open web search.

Priority: ordinary product SEO, accurate Product and Offer structured data, fast product pages. Conversational query targeting for research-stage questions is worthwhile, because "what size furnace filter do I need" is a real question with a real answer that leads to a real purchase.

What not to bother with: voice-specific commerce optimisation. There is no meaningful surface for it in Canada.

A B2B software company: near-zero voice, substantial AI citation value

Nobody procures business software by voice. But their buyers ask language models comparison and evaluation questions constantly, and the material those models draw on is exactly the kind of content this article describes: clear definitions, honest comparisons, specific technical detail, structured answers.

Priority: pure AEO. Definition-first content, comparison tables, specific numbers, clear entity establishment.

What not to bother with: everything else in the voice search playbook.

A physiotherapy clinic in Halifax: moderate exposure, careful territory

Health queries carry particular scrutiny. Location, hours, and booking queries behave like any local business. Clinical questions do not, and should be handled conservatively: accurate, appropriately qualified, clearly attributed to a credentialed author.

Priority: local profile accuracy, functional online booking, careful and well-credentialed clinical content, and privacy handling that reflects the sensitivity of health information under both PIPEDA and provincial health-information legislation.

The pattern

Three of six get meaningful value from voice-specific work. Three should ignore it and invest in either ordinary local SEO or AEO. Any advice that recommends the same voice checklist to all six is not advice.

What to actually spend on, in order

Given finite budget, this is a defensible priority order for a Canadian small business.

First, and cheapest: fix the data. Business Profile hours, categories, service area, NAP consistency, Q&A. This is largely free, takes a few hours, and produces the largest proportional gain in local voice visibility of anything on this list. It is also the thing most often left undone.

Second: fix what is broken in the infrastructure. Not optimise — fix. Force HTTPS properly. Confirm your answer content is in the served HTML. Get TTFB into a sane range. Resolve intermittent availability. These are correctness problems, and correctness problems compound: a page that is not reliably crawlable cannot benefit from any content work you do afterwards.

Third: restructure your existing high-value pages for extraction. Take the pages that already rank and add question headings with compact, self-contained answers. This is cheap relative to writing new content and it works on pages that have already passed gate one.

Fourth: implement the structured data that still functions. LocalBusiness, Organization, Product or Service, Article. Accurately, matching visible content.

Fifth: build new content for genuine question gaps. Only after the above. New content on a slow, badly structured site is money spent on a page that will not be extracted.

Sixth, and only if the above are complete: performance beyond correctness. Getting from a 400ms TTFB to 150ms is real but has a much worse return than any of the preceding items.

The costly mistake is inverting this: commissioning new content while the Business Profile has wrong hours and half the site is reachable over HTTP.

Nine mistakes worth avoiding

Treating voice as a separate channel with a separate strategy. It is a retrieval path over conventional SEO. Separate strategies produce separate budgets, separate reporting, and duplicate content.

Implementing speakable markup. Not available to you. Covered above.

Buying an "FAQ rich results" deliverable. The feature does not exist as of May 2026. Question-and-answer content is valuable; the rich result is not available.

Creating a dedicated "voice search" page. A common and actively harmful pattern. It duplicates your existing topical coverage and competes with your own better pages. This is textbook cannibalisation.

Writing question headings with no answer beneath them. A heading that poses a question and then meanders is worse than a plain descriptive heading, because it promises extractability and does not deliver.

Cramming conversational phrases in unnaturally. "Looking for the best web hosting for small business in Canada near me?" is not how anyone writes or speaks. Stuffed long-tail phrases read as spam to both readers and systems.

Ignoring the server while optimising the content. The most common structural error, and the reason this article spends so long on infrastructure. Content that cannot be reliably fetched and parsed is content that does not exist.

Building a business case on voice-specific metrics. They do not exist and will not be produced. Build on the observable proxies.

Trusting undated statistics. If a figure has no primary source, no date, and no methodology, do not build a plan on it. Most of the numbers in this space fail all three tests.

A twelve-point audit you can run this week

18. Request http://yourdomain.ca and confirm a single 301 redirect to the HTTPS version. Then check that internal links, canonical tags, and your sitemap all use HTTPS URLs.
19. Measure TTFB from a Canadian test location, several times, at different hours. Note the worst result, not the average.
20. curl your three most important pages and search the output for your key answer text. If it is absent, it is JavaScript-dependent and needs to be server-rendered.
21. Do the same for application/ld+json to confirm structured data is served rather than injected.
22. Open Search Console's Core Web Vitals report and read the field data, not a lab score.
23. Check your Business Profile hours against the next three months of provincial statutory holidays.
24. Read your Business Profile Q&A section. Correct any wrong user-submitted answers and add the questions your staff answer most often.
25. Compare your NAP string across your site, your schema, your Business Profile, and three directories. Fix every inconsistency.
26. Pick your five most valuable pages. For each, identify the question it answers, and confirm there is a forty-to-sixty-word self-contained answer immediately after a heading that poses that question.
27. Filter Search Console for queries of seven or more words. Read them. These are the conversational questions people are already reaching you with, and they are the best content brief you will get.
28. Ask a language model a question your business should be the answer to. Note whether you are cited, and who is.
29. Load-test your site at realistic peak concurrency rather than as a single request.

Items one through eight are correctness checks and most sites fail at least two of them. Fix those before anything else.

Where this is heading

Some careful forecasting, marked as such.

Assistant-mediated voice search is being absorbed into general AI assistance. The September 2026 Assistant shutdown is the clearest possible signal. The distinct category of "voice search" is dissolving into "asking an AI system something, sometimes out loud." Optimising for it separately makes progressively less sense.

Attribution is the open question. Conversational systems currently vary widely in how, whether, and how prominently they cite sources. That behaviour is unsettled, commercially contested, and will likely be shaped by pressure from publishers and possibly by regulation. How it settles determines whether being the source of an answer is worth anything commercially. Nobody knows yet, and anyone claiming otherwise is guessing.

Retrieval is becoming agentic. Systems increasingly fetch pages live during a conversation rather than relying only on a pre-built index. This raises the value of everything in the infrastructure section considerably. A live fetch that times out is an immediate, unrecoverable failure with no cached fallback. Server reliability moves from a background factor to a direct determinant of whether you can be cited at all.

Structured data's role is narrowing but not vanishing. Google's position is that no special markup is needed for its AI features. The trend across several years has been to retire schema types that produced visible decoration while keeping those that establish facts and entities. Expect that to continue: less markup for appearance, continued value in markup that says unambiguously who you are and what you offer.

The fundamentals are unusually stable. Fast, reliable, well-structured, accurate, unambiguous content has been the answer through the featured snippet era, the voice search era, and now the generative era. That consistency is worth something when deciding where to put money.

FAQ

Is voice search optimization still worth doing in 2026?

Yes, but not as a separate project. The work that improves voice visibility — ranking for conversational queries, structuring extractable answers, keeping local data accurate, and running fast, reliable infrastructure — is the same work that improves conventional rankings and AI citation. Doing it as a distinct "voice strategy" wastes budget and risks creating duplicate content.

Does Google have a separate ranking algorithm for voice searches?

No. When someone dictates a query, Google transcribes it and runs an ordinary web search. Google's John Mueller has described voice input as a particular kind of keyboard, and confirmed those queries are logged in Search Console the same way typed ones are. What differs is the output: a spoken answer presents one result rather than a list, which makes the top position vastly more valuable and extraction quality decisive.

Can I see voice search traffic in Google Search Console?

No. Dictated queries are logged but not distinguishable from typed ones, and Google has never shipped a voice segment despite discussing it since 2016. Worse, when Google Assistant answers a question by reading a snippet from your page, those impressions are not logged at all. Filtering for queries of seven or more words is a reasonable proxy for conversational phrasing, but it is not a voice filter.

Should I add speakable schema to my website?

Almost certainly not. Speakable structured data is still labelled beta in Google's documentation, is available to news publishers only, works only for English-language content aimed at United States users, and delivers through Google Assistant, which Google began shutting down on 4 September 2026. A Canadian small business fails the eligibility requirements on several counts at once.

Is FAQ schema still useful?

The markup is still valid and harmless; the rich result is gone. Google restricted FAQ rich results to authoritative government and health sites in August 2023, and fully deprecated them on 7 May 2026. Search Console reporting and API support are being removed through mid-2026. Leave existing markup in place — Google continues parsing it to understand pages — but do not expect a visible search feature. The question-and-answer content itself matters more than ever for AI answer engines.

How fast does my website need to be for voice search?

There is no published threshold, and any specific number you see quoted is someone's inference. The defensible targets are the general ones: time to first byte under 200ms is good and under 500ms is acceptable; Largest Contentful Paint at or under 2.5 seconds; Interaction to Next Paint at or under 200ms; Cumulative Layout Shift at or under 0.1, all measured at the 75th percentile of real visits. Consistency matters as much as the average, because intermittent slowness during crawls can keep content out of the index entirely.

Does it matter whether my site is hosted in Canada?

For a Canadian audience, yes, for two separate reasons. Physical distance imposes a latency floor on every dynamic request that no software optimisation removes, so a server in Vancouver or Toronto responds faster to Canadian visitors than one in the United States. Separately, data residency is a procurement requirement in several regulated sectors. Neither argument means Canadian hosting substitutes for competent configuration — a well-run server far away beats a badly run one nearby.

What is the single highest-value thing I can do this week?

Correct your Google Business Profile. Hours including provincial statutory holidays, precise primary category, accurate service area, and owner-answered entries in the Q&A section. For local spoken queries the answer usually comes from the profile rather than from your website, it costs nothing but time, and it is the item most often left undone.

How is AEO different from voice search optimization?

Answer engine optimization aims at being the source an AI system draws on and cites when composing a response. Voice search optimization, in its older sense, aimed at being the page an assistant read aloud. They have converged: both reward compact, self-contained, extractable answers on fast, reliably served pages with unambiguous entity information. AEO is the more useful frame going forward, because that is where the query volume is moving.

How many Canadians actually use voice search?

Nobody publishing openly knows with confidence. The most-quoted Canadian figures are eMarketer forecasts from 2018 and 2019, which are now badly out of date and predate the generative AI shift entirely. Current penetration figures in circulation come from statistics-aggregator sites without published methodology. The honest position is that usage is real and growing but unmeasured, which is a reason to invest in fundamentals that pay off regardless of the true number rather than to size a budget against an unverifiable one.

What about the statistic that half of all searches would be voice by 2020?

It was never true and was never published by the source it is attributed to. Comscore has confirmed directly that it did not publish it. The figure originated as a 2014 remark by Andrew Ng, then at Baidu, predicting that within five years at least half of searches would be conducted through images or speech — in the Chinese market. The image half was dropped in retelling and the market context was swapped. It was popularised by Mary Meeker's Internet Trends 2016 report and has been repeated ever since.

Key Takeaways

• Google began shutting down Google Assistant on 4 September 2026. The product that most voice search advice was written about is being retired, with Gemini replacing it on Android.
• There is no voice search ranking factor. Dictated queries are transcribed and searched normally. What changes is that a spoken answer has exactly one winner.
• Voice visibility is unmeasurable. Assistant-read snippet impressions are not logged in Search Console at all, and dictated queries are indistinguishable from typed ones. Plan against observable proxies instead.
• Speakable markup does not apply to your business. Beta, news publishers only, US English only, and tied to a product being switched off.
• FAQ rich results were fully deprecated on 7 May 2026. The markup remains valid and is still parsed; the visible feature is gone for everyone. The Q&A content is more valuable than ever.
• Infrastructure is a gate, not a garnish. Single-answer retrieval favours fast, consistently responding sources, and answer content must be present in the served HTML to be extractable at all.
• Answer first, in forty to sixty self-contained words, under a heading that poses the question. This is the durable core of extraction optimisation.
• For local queries, your Google Business Profile matters more than your website. Hours, categories, service area, and owner-answered Q&A.
• Voice exposure varies enormously by business type. For a law firm or a B2B software company the right answer is to ignore voice and invest in AEO.
• Most statistics in this field do not survive checking, including the famous "50% by 2020" figure and the widely quoted local-voice conversion numbers.

Conclusion

The useful thing about a product being switched off is that it forces a reckoning with advice that had stopped being examined.

Voice search optimization spent a decade as a category built on a misattributed statistic, recommending techniques tied to one product's implementation, promising results in a channel that could not be measured. Google Assistant's retirement, arriving four months after FAQ rich results were fully deprecated, removes the last of the specific tactics. What remains, once the expired advice is cleared away, is more coherent than what it replaced.

Spoken and conversational queries reach your business through ordinary search infrastructure. They reward the same things good SEO has always rewarded, judged more harshly because a spoken answer has one winner instead of ten. Rank for the questions people actually ask. Structure the answer so it can be lifted out cleanly and read aloud without context. Keep your factual data unambiguous and consistent everywhere it appears. Serve all of it from infrastructure fast and reliable enough that a system in a hurry does not skip you.

That last requirement is where this topic ends up being an infrastructure question as much as a content one, and it is the part most commonly skipped. A page that cannot be fetched quickly, or whose answer only exists after JavaScript runs, will not be extracted no matter how well written it is. The gate closes before your content is ever considered.

None of this requires predicting how conversational AI settles, which is fortunate, because nobody can. The fundamentals held through the featured snippet era, held through the voice assistant era, and are holding through the generative one. Building on them is the closest thing to a durable position available in search right now.

Start with the audit, not the content.

Most Canadian businesses reading this have two or three correctness problems sitting in front of any content investment: HTTPS enforced partially rather than fully, answer text that only exists after JavaScript runs, a time to first byte that quietly triples under load, or a Business Profile with last year's holiday hours. Those problems make every subsequent dollar of content spend less effective, and they are all cheap to fix once identified.

Two places to begin, depending on where your constraint is:

If the constraint is infrastructure, the fix is usually hosting that is not fighting you. 4GoodHosting runs from data centres in Vancouver and Toronto, which removes the fixed latency cost that comes with serving Canadian visitors from a US facility, and keeps your data on Canadian soil where that matters for procurement. For sites where traffic arrives in bursts — the emergency-service pattern described earlier — VPS hosting with genuinely dedicated CPU and memory is what stops a spike from becoming an outage. If you are running WordPress and would rather not manage the performance layer yourself, managed WordPress hosting handles the caching and update path that most extraction problems trace back to. And if HTTPS is only partially enforced across your site, an SSL certificate plus proper server-level redirection closes that gap in an afternoon.

If the constraint is the search work itself, our search engine optimization services cover the local, technical, and content side of this: profile and NAP correction, extraction restructuring on pages that already rank, structured data that still functions, and answer-engine positioning for the queries your customers are actually asking. We work with Canadian businesses on voice search SEO services in Canada as part of that, not as a separate product, for the reasons this article sets out.

Either way, run the twelve-point audit above first. It costs nothing, it takes an afternoon, and it will tell you which conversation to have.

Questions about where your site currently stands? Get in touch and we will look at it with you.