A template test serves a different page layout to each group, for one kind of page. It is the right answer when the question is genuinely about arrangement — does this product page work better with the reviews above the fold, does the collection need filters at the top — and the wrong answer when it is about wording, which a content test settles without a navigation.
Compared with a theme test it is narrower and therefore faster to conclude: you are changing one page type rather than every page, so the difference you are measuring is the difference you made.
The two figures below are live. Pick a setup, and see what the app and the loader do with it.
Build the template first
In Shopify, open the theme editor and duplicate an existing template. Shopify names the copy something like product.myversion.json. Lay it out, save it, and it becomes available here.
Three requirements that are easy to miss:
- Every template must live in your live theme. This test does not switch themes; it asks your published theme to render a different template. One built in an unpublished theme is invisible to it.
- The control must be the template the page already resolves to. A visitor only enters the test if they land on a page whose default template is the control’s. That is what makes the comparison fair.
- The store must be on the Online Store. A headless storefront has no theme to render
?view=, so a template test is refused at launch there, and the picker marks the type “Not available on headless”.
Which pages it can cover
Products, collections, pages, blogs and blog posts are always offered: they are the five Shopify lets you point a single resource at an alternate template for. The home page and the cart can be tested too, where your theme supports an alternate for them — they are offered once your live theme actually has the file.
- File
- templates/product.v2.json
- Control URL
- /products/linen-overshirt → Shopify renders product.json
- Variant URL
- /products/linen-overshirt?view=v2
Invisible to the test.
A template test doesn't switch themes. It asks your published theme to render a different template, and this file isn't in it.
↳ The file must be in the live theme.
The figure starts on the most common mistake: a lovely template, built in a duplicate theme, that the test cannot see. Move it to the live theme and the verdict turns. Switch the storefront to headless and nothing else matters; that refusal is the app’s own wording.
If you built the template a moment ago and it is not in the picker, the Modifications tab has a Refresh. Themes and templates are re-read when the cached list is more than five minutes old, and manually when you ask.
Comparisons are rows, not per-group settings
This is the one tab in the app laid out across the groups rather than down them. A template comparison is a row: the origin template, then what each group renders in its place.
That is deliberate. Edited group by group you would be holding three separate lists in your head and keeping their order aligned by hand. As a row, the comparison reads as the single thing it is.
A test can hold several comparisons. A product comparison and a collection one, or two product comparisons for different products. Each carries the page type and the origin template it replaces, so the right one applies on the right page and the others stay out of the way.
What a shopper experiences
The loader lands on the page, decides the group, and replaces the URL with one that names the group’s template in ?view=. The page stays hidden across that hop, so there is no flash of the original.
The parameter stays in the address bar. We don’t remove it, so a shopper can copy it and send it to a friend. What makes that safe is what happens when the friend opens it.
- The browser asks for
/products/linen-overshirt?view=reviews-first, and Shopify rendersproduct.reviews-first.json. The page is still hidden. - The loader decides your group: A · Control.
- That isn’t your group’s template, so it replaces the URL with
/products/linen-overshirt, still hidden.
You see A · Control, your own group, whatever link you opened.
The control has no ?view= of its own, so you end on the plain URL.
↳ Every visitor ends on their own group.
Whatever the link says, you end on your own group’s template. A link from group B opened by someone in the control renders B first, because that is what Shopify was asked for — and the loader then moves them to the plain URL while the page is still hidden. The cost is a second page load, not a contaminated result.
A shared link carries a layout. It never carries a group.
The control does not navigate on a plain link, which means the variant arms pay a navigation the control does not. It is small, and it is the honest cost of client-side template switching on a platform that serves storefront HTML from a CDN.
Your own preview links don’t pay it. A preview already knows its group, so the link carries the ?view= itself and loads once.
What to watch
- Check both templates on a phone. A layout that works at desktop widths and collapses on mobile will lose for reasons that have nothing to do with the idea you were testing.
- Run Check setup on the Preview tab. It loads the page with each template named and confirms the template is real, rather than your theme quietly falling back to the default.
- One navigating test at a time. Theme, template and redirect tests all move the visitor. Two on overlapping URLs are refused at Start. Even on different pages, only one of them is served to shoppers at a time, and Check setup tells you when yours is the one left out.
- Content tests under a template test are a warning. Not a refusal — it is a legitimate pair — but selectors written against one layout may match nothing in the other, and that half of the traffic then reads as “no difference” rather than as a failure.
When it wins
Make the winning template the default in your theme, then end the test. Until you do, every visitor in the winning group is being redirected on every page view for a layout you have already decided on.