Floating vs Inline Voice Widget: Which Placement Wins?

You have decided to put a voice assistant on your site. Good. Now comes the question that quietly decides whether anyone actually uses it: where does it go? A floating button pinned to the corner of every page, or an inline block embedded into the flow of a specific page?

This is not a cosmetic choice. Placement changes who notices the widget, when they engage, and what they do next. Get it right and the assistant becomes a natural extension of the page. Get it wrong and it either gets ignored (too buried) or resented (too intrusive). The good news is that the decision follows a fairly clean set of rules based on what the page is for.

This post breaks down floating vs inline voice widget placement: how each behaves, when each wins, what changes on mobile, position best practices, and how to target the right pages so the widget shows up exactly where it helps.

Placement is a setting, not a rebuild. With the AI Voice Agent Widget you control floating vs inline, corner position, and launcher style from configuration — the same one-line script adapts. You can preview options in the free Voice Widget Generator before you commit.

Quick verdict (TL;DR)

• Floating (a persistent corner button that opens a voice panel) is the default winner for support and general availability. It follows the visitor everywhere without taking layout space.
• Inline (the voice assistant embedded into the page body) wins when voice is the point of a specific page — a landing-page CTA, a "talk to us" hero, or a pricing page where you want the conversation front and center.
• Most sites want both: floating everywhere as a safety net, inline on the one or two pages where you want to actively drive a voice conversation.
• On mobile, floating must respect thumb zones and never cover sticky checkout bars; inline often works better on mobile because it sits in the scroll flow instead of hovering over content.

What "floating" and "inline" actually mean

A floating widget is the pattern everyone recognizes: a launcher button anchored to a bottom corner of the viewport that stays put as the visitor scrolls. Click it and a voice panel opens; the visitor allows the microphone and starts talking. It is global — one embed, present on every page you choose, hovering above your content without consuming layout space.

An inline widget is embedded into the page itself, in the normal document flow — a block in your hero, a card in the middle of a pricing page, a section that says "ask our assistant anything." It scrolls with the page like any other content. It is local — it belongs to the page it is placed on and is impossible to miss when the visitor reaches it.

Both run the same underlying experience: WebRTC (LiveKit) real-time audio in the browser, rendered inside a Shadow DOM so your site's CSS never collides with the widget. The difference is purely where it lives on the page and therefore how visitors encounter it. For the technical side of the in-browser audio, see WebRTC browser calls.

Visibility and conversion: the real trade-off

The core tension is ambient availability vs deliberate emphasis.

Floating buttons maximize reach. They are on every page, so no matter where a visitor lands, help is one click away. But because they are always-on and always-in-the-corner, any single page treats them as background furniture. Visitors learn to tune out the corner. That is fine for support — you want it available, not shouted — but it is weak when you actually want to drive a voice conversation as the primary action.

Inline blocks maximize intent. When a visitor scrolls to an inline voice CTA that says "Not sure which plan? Ask our assistant," they cannot pretend they did not see it, and the context primes them to engage. The cost is reach: an inline widget only exists where you place it, and only works if the visitor scrolls that far.

A useful way to think about it: floating answers "I have a question," inline answers "you should ask a question." The first is reactive support. The second is proactive conversion.

When each placement fits

Use floating for support and always-on help

If the job is "let anyone, anywhere on the site, reach the assistant," floating is correct. Documentation, help centers, blog posts, account pages, general marketing pages — the visitor's need is unpredictable, so you keep help persistently within reach and out of the way. This is also the right default for a small site that only wants one placement decision: put a floating widget everywhere and move on.

Use inline for landing pages and campaign CTAs

On a landing page, the whole page has one job. If you want voice to be the conversion action — "talk to our AI to see if we are a fit" — bury it in the corner and most visitors will never trigger it. Embed it inline, near or as the primary CTA, and it becomes the thing they do. Campaign and paid-traffic pages, where every visitor arrived with intent, are the strongest case for inline.

Use inline on pricing and product pages

Pricing pages generate the most "but which one is right for me?" hesitation. An inline voice block placed right beside the plans catches that hesitation at the exact moment it happens, instead of hoping the visitor spots a corner button. Product and feature pages benefit the same way when there is a specific question the page tends to provoke.

Use both on most real sites

The pragmatic answer for most businesses is floating everywhere + inline on your two or three highest-intent pages. The floating widget is your always-available safety net; the inline blocks are your deliberate conversion moments. They share the same agent and knowledge base, so there is no extra setup cost to running both.

Do not make placement a code project. Because it is configuration on the AI Voice Agent Widget, you can run floating site-wide and drop an inline embed on your pricing page without touching your build. Test one against the other and keep what converts.

Mobile considerations

Mobile is where placement mistakes get expensive, because the viewport is small and the bottom of the screen is prime real estate.

• Respect the thumb zone. A floating button in the bottom corner is easy to reach — that is the point — but make sure it does not sit directly over primary navigation or a sticky action bar.
• Never cover a sticky checkout or "buy" bar. On commerce and mobile app-style layouts, the bottom often already holds a sticky CTA. A floating widget that overlaps it will either get misclicked or block the purchase. Either reposition the launcher or hide it on those pages (see page-targeting below).
• Inline often wins on mobile. Because an inline widget lives in the scroll flow, it never hovers over content or fights the sticky bar. On long mobile landing pages, an inline voice CTA can outperform a floating button that visitors' thumbs keep grazing by accident.
• Keep the launcher compact. On mobile, a small icon launcher usually beats a wide label pill that eats horizontal space.

Position and launcher best practices

For floating widgets specifically:

• Bottom-right is the convention for right-to-left reading flow and where most users' eyes and thumbs expect help. Use bottom-left if bottom-right already holds something (a cookie banner, a back-to-top button, another tool) — two things fighting for the same corner is the most common placement bug.
• Give it breathing room. Do not jam the launcher flush into the corner or on top of other floating elements. A little margin makes it feel intentional.
• Choose the launcher style to match emphasis. An icon button is quiet and space-efficient; a label pill ("Talk to us," "Ask a question") is more inviting and gets more clicks, at the cost of footprint. Use the pill when you want the widget noticed, the icon when you want it available but unobtrusive.
• Do not auto-open aggressively. A voice panel that pops open and starts talking unprompted is the fastest way to make a widget feel intrusive. Let the visitor click. A gentle greeting once opened is plenty.
• Set a branded greeting. The first line the agent says frames the whole interaction — make it specific to the page or business, not a generic "How can I help?"

Page-targeting: show it where it helps, hide it where it hurts

The single biggest lever for making placement feel right is showing the widget only where it belongs. General rules that hold up across most sites:

• Show on: pricing, contact, service and product pages, key landing pages, and the homepage — anywhere a visitor is likely to have a question you can answer to move them forward.
• Hide on: checkout, payment, and thank-you/confirmation pages. During checkout you want zero distraction from completing the purchase; a voice launcher there is friction, not help.
• Be deliberate on support docs: floating is usually right, but if a doc page is long, an inline "still stuck? ask the assistant" block near the bottom catches people who scrolled to the end without finding their answer.

How you implement targeting depends on your stack — conditional logic in a snippet manager, is_page()-style conditionals in a CMS template, or route-based rules in a framework. On WordPress specifically, we cover the exact conditionals in the companion guide linked below. And there is a server-side backstop regardless: the widget key is bound to a domain whitelist with rate limiting, so it will not run on domains you did not authorize even if a snippet ends up somewhere unexpected.

Branding: make it feel like your site, not a bolt-on

Placement is only half of "does this feel native." The other half is branding, and it applies to both floating and inline:

• Color the launcher and panel to your brand so it reads as part of the page.
• Logo in the panel header for recognition and trust.
• Greeting written for the specific context — a pricing-page inline widget can open differently from a site-wide floating one.
• Launcher style (icon vs pill) chosen per the emphasis you want.

Because the widget renders in a Shadow DOM, none of this fights your theme: your CSS cannot leak in and break the widget, and the widget cannot leak out and break your layout. So you get full brand control without style collisions, on floating and inline alike. To see the whole platform this plugs into, see AI Voice Agent.

Frequently asked questions

Is a floating or inline voice widget better for conversions?

It depends on the page's job. Floating wins for always-available support because it reaches every page without taking layout space, but any single page treats it as background. Inline wins when voice is the conversion action — landing pages, pricing pages, dedicated "talk to us" sections — because it is impossible to miss and the surrounding context primes the visitor to engage. Most sites get the best result running floating site-wide plus inline on their two or three highest-intent pages.

Where should a floating voice widget be positioned?

Bottom-right is the convention and matches where most users expect help. Switch to bottom-left only if the bottom-right corner is already occupied by something like a cookie banner or back-to-top button — two floating elements in the same corner is the most common placement bug. Give the launcher margin from the edge, avoid covering mobile sticky bars, and don't auto-open it aggressively. You can set position from configuration on the AI Voice Agent Widget.

Should the voice widget show on the checkout page?

Usually not. During checkout you want the visitor focused on completing the purchase, so a voice launcher there tends to be friction rather than help — and on mobile it can overlap the sticky "buy" bar. Hide it on checkout, payment, and confirmation pages, and keep it on pricing, product, and contact pages where pre-purchase questions actually happen. Use your platform's page-targeting or conditional logic to do this.

Does inline placement work on mobile?

Often better than floating. An inline widget sits in the normal scroll flow, so it never hovers over content or collides with a sticky bottom bar the way a floating launcher can. On long mobile landing pages, an inline voice CTA can outperform a corner button that thumbs keep grazing by accident. If you do use floating on mobile, keep it a compact icon and clear of the thumb zone.

Can I run floating and inline at the same time?

Yes, and most real sites should. They share the same agent and knowledge base, so running a floating widget everywhere as a safety net plus inline blocks on high-intent pages costs nothing extra to maintain. Configure both from the same setup and A/B test which drives more voice conversations on the pages that matter.

Conclusion

Floating vs inline is not a winner-take-all fight — it is a matching exercise. Floating gives you ambient, always-available help across the whole site; inline gives you deliberate, impossible-to-miss emphasis where voice is the point. Support and general pages lean floating; landing, pricing, and campaign pages lean inline; and most sites should run both, targeted so the widget appears where it helps and disappears where it distracts. Because placement, position, launcher style, and branding are all configuration, you can test placements without rebuilding anything.

Ready to place your widget the right way? Configure it on the AI Voice Agent Widget page, try layouts in the Voice Widget Generator, or start free.

Related resources

• AI Voice Agent Widget — configure floating vs inline, position, and branding
• WebRTC browser calls — the real-time audio behind the widget
• AI Voice Agent — the full multichannel voice platform
• Voice Widget Generator — free tool to preview placements and copy your snippet
• How to Add a Voice Assistant to WordPress (2026, No Code) — install and page-target the widget on WordPress