Page-type targeting
Show on all pages, or an allow-list of page types. A widget with neither renders nowhere, however else it is configured, and an inline widget has no "all pages" mode at all.
An inline widget plays by a stricter rule
This page describes the two floating formats, the chat bubble and the question bar. An inline widget (the button or Starters) has no Show on all pages switch, and renders only on a page whose type your storefront has declared. See An inline widget needs page types.
Show on all pages, at the top of the Display tab, is the switch to reach for when you want a widget everywhere with no exceptions. Turn it on and the widget renders on every page type, full stop. It overrides the checklist below completely: whatever's checked (or not checked) there stops mattering, and even a storefront that declares a page type via iadvize('set', { customData }) can't exclude a page while this is on. Turning it on hides the Show on these page types checklist; turning it back off brings the checklist straight back with whatever page types were selected before you turned "Show on all pages" on. Nothing is cleared by toggling it either way.
Why not just check every box?
Checking every current page type gets you the same result today, but "Show on all pages" also covers a page type added later. A widget with every current box checked won't automatically pick up a future page type; a widget with "Show on all pages" on will.
With Show on all pages off, the Show on these page types checkboxes work as an allow-list, not a simple filter, for both floating formats:
- No page types checked: the widget never renders, anywhere, even if it's active and published. You must explicitly check at least one page type, or turn on Show on all pages, before the widget does anything. A new chat bubble or question bar never starts here: it arrives with Show on all pages already on, so this state is only reached by turning that switch off without checking anything.
- At least one page type checked: the widget renders on every page, unless your storefront has explicitly declared, via
iadvize('set', { customData }), a page type that isn't on the list. If your storefront never calls that API at all, a widget with any page types checked shows on every page: the allow-list only has something to exclude once you're telling it what page type it's on.
For example, checking every type except Checkout shows the widget everywhere except pages where you've called customData: { pageType: 'checkout' }, the common case of keeping a floating bubble or question bar off a payment flow.
Targeting is part of the draft, so a change here reaches shoppers when you publish, not when you save.
Starter questions carry a second page rule
A starter question has its own page scope, and the two rules are applied together: a chip shows on a widget only when the widget is allowed on that page and the question's own scope admits it. Neither overrides the other: a widget that shows on Home and Product carries a Product-scoped question on your product pages only, and a widget the targeting above excludes carries no chips at all.
On a page where your storefront declares no page type, neither rule has anything to match against: the widget renders (its allow-list can only exclude a page type you declare) and it carries every enabled question with text in the shopper's language, capped at three. That is the same thing the panel does there, which is the point: a chip's job is to open the panel, so the two must not offer different questions on the same page.
Check it before publishing
The preview's Page type control simulates the page a shopper is on, including Page type not declared: the position of a storefront that never calls customData, and the common case. When your targeting excludes the simulated page, the scene says the widget is not rendered and names the page types it does target. The verdict comes from the same rule the tag applies, so the two can't disagree.
A widget with no page types looks broken, not off
An empty list with Show on all pages off is a common reason a widget "doesn't work" once you've been editing it a while: it can be active, published, and still render nowhere. It's not the state a new floating widget starts in (that's Show on all pages on), so you'll usually only reach it by turning the switch off without checking anything. The widget's page says so itself while that's the case (see Why a new widget isn't live yet), and the list reports it as Needs setup; if you're looking at a live storefront rather than the dashboard, this is the first thing to check.
Appearance and placement
Colours, size, corners, shadow, icon and text (all inheriting from your site's branding by default), plus offsets, narrow-screen offsets, position and stacking order.
The inline button
A labelled control that sits inside your own content flow instead of a corner of the screen: what you configure, what it inherits, and the rules that differ from a floating widget.