Shopify Store Templates — Or a Custom Ecommerce Website Design

Shopify store templates are usually the first real decision for a small Swiss shop building an ecommerce website: start from a ready-made theme, or commission a custom design from scratch? The data on the theme market and on platform performance gives a less black-and-white answer than the usual advice — "always invest in a custom design" on one side, "a template is enough for everyone" on the other: a template is a sensible starting point for most small shops, and a custom build starts to pay off once the template genuinely blocks a specific business process or a performance number you can measure. This article covers design and page structure only — Swiss law, platform choice, cost and SEO already have their own, more detailed articles on this site, which we link to here instead of repeating them.

Shopify store templates: what has to be in place before you pick one

Before you touch the homepage layout, three things need to exist no matter what the shop looks like:

• Terms and conditions — they bind the customer only if the customer could read them before ordering, so link them right next to the order button. Their content has a limit too: Switzerland's Unfair Competition Act (UWG, Art. 8) bars terms that create a significant and unjustified imbalance between the parties' rights and obligations to the consumer's detriment.
• Information around the order — the same act (UWG, Art. 3(1)(s), in force since 1 April 2012) requires anyone selling via e-commerce to give clear and complete identity and contact details, including an email address, state the technical steps needed to conclude the contract, provide a way to spot and correct input errors before the order is sent, and confirm the customer's order by email without delay. For physical products, EU sellers rely on the GPSR for a dedicated safety-information duty; whether Swiss product-safety law (the Produktesicherheitsgesetz) imposes an equivalent distance-selling disclosure wasn't confirmed in this research pass, so we're not citing a specific article for it here — treat it as an open question for your own legal check, not a settled fact.
• A returns page — in Switzerland there's no statutory right to return an online order at all (see below), so this page is about your own, voluntary policy rather than a legal minimum: returns and warranty in Switzerland covers the mechanics. Here it's enough that such a page exists and is easy to find from the footer.

There's one more page that's easy to forget when designing a site: a privacy and cookie policy, separate from the terms and conditions, because Switzerland's revised Federal Act on Data Protection (revFADP, SR 235.1, in force since 1 September 2023) requires telling people what personal data the shop collects and why — whether the shop collects data only to fulfil orders or also for analytics and marketing. Its exact content depends on which tracking technologies are actually switched on (Consent Mode, ad pixels) — that's a topic for its own article, not this one.

We cover the full picture of what's needed to set up an online shop in Switzerland in how to set up an online store — this article points there instead of repeating the same obligations. The product page itself carries its own separate set of duties (product identification, photos, pricing during promotions) and deserves its own article, not a subsection here.

Template: what it gives you, and where its limits are

A ready-made theme solves, in a few minutes, what a from-scratch build takes weeks to do: the homepage layout, product cards, cart and checkout, responsiveness, baseline accessibility. The Shopify Theme Store has its own browsable collection of free themes, and the paid themes visible at the time of checking (1 October 2026) sat in a range of roughly $100 to $500 — shown in USD on the Theme Store itself, unlike Shopify's main pricing page, which geo-prices by visitor location. That's one reading of a live marketplace, not an official price list Shopify announces, because a theme marketplace changes its range and assortment all the time. WooCommerce and PrestaShop run on the same mechanism — free themes in the platform's own repository, paid themes in separate marketplaces — but a current, specific price range for those two platforms wasn't part of this research, so we don't give a number for them here.

The template's limit is functional, not just visual: a good theme handles a typical buying process, but if your shop has an unusual one — a product configurator, a complex B2B model with per-customer pricing, an integration the template never anticipated — that's exactly where it starts getting in the way instead of helping. What the whole shop costs, not just the theme, is broken down in ecommerce website cost, and specific platforms and their pricing are compared in our ecommerce platform comparison — if you're still choosing a platform, start there, not here.

Template vs performance: the technical debt you can't see

A universal template has to serve very different shops at once, so it may run a visual page builder, a backward-compatibility layer and room for any number of third-party apps, all at the same time — that's the mechanism through which a template can hurt Core Web Vitals, LCP especially, before you've even added your own content. The HTTP Archive Web Almanac 2025 (the "Ecommerce" chapter, data from July 2025, published January 2026) measures the share of sites with a "good" Core Web Vitals result — LCP, INP and CLS all passing at the 75th percentile — by platform: Shopify 76% on mobile and 76% on desktop, WooCommerce 35% on mobile and 33% on desktop. The chapter calls LCP "the biggest differentiator" between platforms, and for WooCommerce that's exactly where it struggles (45% good results on desktop, 39% on mobile), while INP and CLS come out better (88% and 85% good on mobile; on desktop, INP 99% but CLS only 68%).

Worth keeping next to these numbers: this is global, platform-wide data — every detected site on a given engine, with no country breakdown for Switzerland or anywhere else — not an assessment of any specific theme or installation. A well-configured WooCommerce shop, stripped of unnecessary plugins, can score better than its platform's average, and a neglected Shopify shop loaded with dozens of apps can score worse. The numbers show a gap between platforms, not its cause in any one shop — "the more unconsolidated scripts and plugins on a page, the harder it is to get a good LCP" is our reading of the mechanism, not a measured result, and it isn't a verdict on any specific platform.

The previous edition of the same Web Almanac chapter shows that a weak platform score isn't a permanent verdict — it's a state that changes from edition to edition. The 2024 edition (earlier data, published 2024-11-11) recorded WooCommerce's LCP result at "just 34%" on mobile — lower, even, than the 39% in the 2025 edition — but over the same period other platforms improved sharply (mobile data): Tiendanube went from 28% good LCP results in 2022 to 61% in 2024, and Squarespace from 33% to 60% of sites with a good overall Core Web Vitals result in the same window. The practical takeaway: template performance isn't a fixed trait of an engine forever — a weak LCP score two years ago doesn't mean a weak score today, and the reverse holds too.

If the template is blocking a process or a performance number you're checking with our website speed test, and fixes within the template itself no longer help, the next step is usually not "a different template" but a different architecture — see the next section.

Custom build: when it's worth it

A from-scratch build makes sense when a specific process or a specific performance metric matters more than how fast you can launch — not as the default choice "because it looks better." It's a decision that costs more time and work than configuring a template, so it's worth making on the basis of a specific, named constraint (this configurator doesn't work, this integration doesn't exist, this Core Web Vitals result isn't improving despite optimisation), not on a general feeling that "the template looks too generic."

The most radical form of a custom build is headless — decoupling the front end (built, for example, on Next.js) from the ecommerce platform's engine, which then becomes just a backend for data and orders. That architecture gives full control over what actually reaches the browser — and so over performance — at the cost of some things a theme gave you for free: ready-made integrations with apps from the platform's own marketplace, security updates handled by the engine's vendor, and a simple setup for anyone without their own development team. That trade-off — full control at the cost of convenience and vendor-managed maintenance — is the practical reason headless pays off only once a template genuinely can't keep up, not as a default upgrade. When that step pays off and when it's overkill is covered separately in our article on headless commerce; how to measure and improve the Core Web Vitals metrics themselves — whether you stay on a template or go headless — is in Core Web Vitals for ecommerce.

Homepage and navigation structure

Whether the page is built by a template or a custom project, a few structural elements are worth having in every shop, because they follow from the logic of the buying journey, not from fashion:

• A value proposition visible without scrolling — the customer needs to know right away what they're buying and from whom, with no need to scroll the homepage.
• Visible category navigation — a stable, predictable category structure, available from every subpage, not just the homepage.
• A visible search field — placed in a fixed, obvious spot in the header; what the search itself should do and how to measure it is covered in our article on ecommerce site search.
• Trust signals near the top of the page — information about secure payment (TWINT, cards), the returns policy and real customer reviews, not tucked away in the footer.
• A footer with legal links — terms and conditions, privacy policy, contact details and a returns page, always in the same, predictable place.

This set of sources didn't turn up a specific, named UX study on homepage navigation for online shops — the list above describes a mechanism, not a quote from research, and it's worth treating as a starting point for your own usability tests, not as a closed, verified benchmark. In practice, none of these points is unique to one type of build — a template and a custom project deliver the same list, just with a different cost of change: in a template you reorder sections through the theme editor, in a custom build through code — but the list of requirements itself doesn't change. If the page also has filters and product listings, their UX and their effect on SEO (faceted navigation specifically) are their own, separate topic — the UX side in our article on site search, the technical-SEO side in our ecommerce SEO guide.

Phone vs desktop — two separate measurements, not one

Two different mobile measurements talk about two different things, and shouldn't be added together. StatCounter for Switzerland, September 2026: desktop 51.71%, mobile 46.59%, tablet 1.7% of page views in StatCounter's own panel — that's browsing traffic in general, not shopping specifically, and it's not a census of the full population, only data from one company's own panel.

A second kind of measurement — which device someone actually completes a purchase on, as opposed to which device they browse on in general — asks a different question on a different sample. We don't have a confirmed Swiss figure for it from this research pass, so we're not putting a number next to it here. The practical conclusion holds regardless of the missing number: the shop has to work well on both the phone and the desktop, and "well" doesn't mean "identically" — it's worth checking checkout and the forms specifically on a phone, given how large a share of browsing already happens there.

Accessibility in a template — baseline checks

Switzerland isn't bound by the EU's European Accessibility Act, and this research pass couldn't confirm whether, or to what extent, Swiss disability-equality law (BehiG/LHand) imposes a binding digital-accessibility obligation on a private online shop, or what any such obligation's deadline or supervisory authority would be — treat that as an open legal question, not a settled one, and check it separately before publishing a specific claim (the ecommerce UX hub covers the rest of this section's topics). What's not in question is that accessibility is good practice and a risk-reduction measure regardless of the legal baseline, with WCAG 2.2 functioning as the de facto technical standard most reviewers and tools check against. Here's just the list of baseline things worth checking in the template itself, before you move to a full accessibility audit:

• Text contrast against the background, especially in colour variants of the template that the theme's author never tested for this.
• Semantic HTML — headings in a logical hierarchy, buttons as <button>, not a <div> with a click handler.
• Alt text on product photos, not only on the shop's main hero image.
• Full keyboard support — you can get through navigation, filters and the order form without a mouse.
• A visible focus state on links, buttons and form fields, so someone navigating by keyboard can see where they currently are.
• A label attached to every order-form field, not just a placeholder that disappears the moment you click into the field.

How to choose — a checklist

• You've checked whether a typical, ready-made template actually handles your sales process (configurators, B2B pricing, unusual integrations), instead of assuming it will "adapt somehow."
• You have terms and conditions, the required order information and a returns page visible from every subpage, not only the homepage.
• You've measured the Core Web Vitals of your specific template installation (not the platform average) before deciding to move to a custom build.
• You've tested checkout and forms for real on a phone, not only by resizing a browser window on a desktop.
• Navigation, search and trust signals are visible without scrolling, and the footer has the full set of legal links.
• You've gone through the baseline accessibility checks above before deciding a template "is enough."

If you'd rather make this decision together with someone who'll assess your specific template and your specific installation, not just a platform average, talk to us — that's also one of the items on the ecommerce UX checklist.