Placement
How Sledge decides where on the page your widgets land, how to move them, and how to run several offers at once on different surfaces.
The surface decides whether a widget shows up at all. This page is about where on the page it lands.
Resolution order
For each widget on each surface, Sledge resolves a position by taking the first of these that exists:
An explicit selector
If you set a placement selector on the widget in the Sledge dashboard, that wins. Sledge finds the element matching your CSS selector and inserts relative to it.
A placed block
If you added an app block in the theme editor, the widget renders exactly where that block sits.
The theme default
Sledge's template for your theme knows where the product form, the grid and the description sit, and inserts there. This is why widgets often appear correctly with no placement work at all.
If none resolves, the widget does not render. That is deliberate — it is better than injecting into an unpredictable position.
Position within the target
Alongside the selector, each surface has a position: insert at the top of the matched element, or at the bottom. For most widgets top and bottom are the only sensible options; a selector plus a position covers nearly every layout.
Preview before you publish
You do not have to guess how an offer will look, and you do not have to publish it to find out.
Every offer can be previewed on every surface it is enabled for, before it goes live. Turn a surface on, preview it, and see the bundle sitting in the search results or the collection grid exactly as a shopper would — then publish when it looks right.
This is the fastest way to answer "will this land in the right place on my theme?" without experimenting on live traffic.
Once it is live, A/B testing takes over: run a variant alongside it, split the traffic, and compare revenue per variant before choosing a winner.
Multiple instances
Bundle, recommendation and promotion widgets support multi-instance placement: several configured items can render at once, on different surfaces, each with its own position.
A store might run a volume-discount bundle on product pages, a free-gift bundle in the cart drawer, and a build-your-own-bundle on a dedicated page — all simultaneously, each placed independently.
Each configured item carries its own per-surface settings, so enabling one on a new surface never disturbs the others.
Choosing a good selector
If you do set an explicit selector, prefer one that survives theme updates:
- Good — a stable structural class your theme has had for a long time, or an id.
- Risky — generated class names, deeply nested descendant chains,
nth-childpositions.
A selector that stops matching does not break the page; the widget simply falls back to nothing rendering there. If a widget disappears after a theme update, an over-specific selector is the first thing to check.
When placement is not enough
If the widget lands in the right place but does not look right, that is a styling problem rather than a placement one. See Styling, and Custom Components if you need to replace the markup entirely.
Last updated on
App blocks
Put a Sledge widget exactly where you want it — a search bar in your header, reviews under the product description, filters beside your collection grid.
Customize
Make Sledge match your store exactly — colors and fonts, your own CSS and JavaScript, or replace a widget's markup with your theme's own.