Cross-border brands often treat a Shopify brand build as a story page and a set of visual comps. The cost shows up later: positioning never reaches the home, collection, product or checkout templates; merchandising cannot change copy without a code edit; a new market is handled by translating the homepage. The working test is more direct. Put the brand into the shopping templates first, then turn narrative into something operations can maintain through reusable sections, theme settings and product fields.
A team can spend two weeks aligning keywords and replace the homepage hero. Shoppers still arrive from an ad, land in All products, and filter only by price and colour. The first screen of the product page is media and add to cart. The selling points sit in a footer block labelled Our story. Checkout remains the platform default. That is not a taste problem. Brand information never entered the storefront system.
Put the brand on shopping templates; keep the story page as a supplement
A Shopify theme is not a poster. The storefront is organised by template: home is index, collection pages are collection, product pages are product, the cart is cart, and about, policy and campaign copy usually sit on page templates. Search, blog, 404 and password templates also exist. Shoppers almost never walk the store in the order of an internal brand book. They arrive from ads, search, email or social and land on one of those templates.
A brand system therefore starts with a different question than “how should the story be written”. What does each template have to answer? The homepage should receive the visitor and send them to the right collection or product. The collection page should use data and filters to help them narrow the choice. The product page should make specifications, fit, price and add to cart clear in one pass. The cart should handle quantity changes, delivery expectations and the move to checkout. An about page can cover craft and origin. It cannot repair a product page that lacks specifications, a collection page that cannot filter, or a checkout where policy is invisible.
Building the brand by stacking modules on the homepage usually produces a complete-looking visual and a purchase path that is still the theme default. Shopify currently allows up to 25 sections on a JSON template, up to 50 blocks in a section, and up to 1,000 JSON templates in a theme. Those are structure limits, not a signal that the store must move to a headless storefront. When categories need different information, the more stable approach is alternate templates: keep one theme, and assign different product or collection templates by category, rather than building a second store. See Shopify’s JSON templates and theme limits.
Put visuals and copy into assets merchandising can edit
Sustainable operations has a concrete test. When seasonal claims change, a new product needs new specifications, or a market needs different wording, merchandising should be able to make the change in admin without editing theme code.
Online Store 2.0 provides sections and blocks, dynamic sources, and metafields on resources such as products, variants, collections and the shop. A compatible setting can connect an admin field to the storefront. Supported field types and connection limits depend on the setting and context; check the dynamic sources documentation when designing the theme.
Category metafields can drive colour swatches and, where Search & Discovery is configured for them, some filter conditions. That only works if the theme actually renders the fields. A metafield that exists in admin but has no corresponding section, block or filter is still invisible to the shopper.
A brand line hard-coded in Liquid cannot be edited by operations. A line that lives only as static copy in one homepage module will drift from the catalogue as soon as SKUs change. Colour, type, buttons and spacing belong in theme settings, not as a separate set of values in every section. If the brand exists only in a design file, day-to-day edits and additional markets will pull it apart after launch.
Home, collection and product each own one job
Do not invent a funnel percentage and then imagine shoppers walking it. Check each template against the question it has to answer. That is closer to how people actually browse.
| Template | Question it must answer | Where the information should come from |
|---|---|---|
| Home | Whose store is this, is it for me, and where do I go next? | Shop metafields, featured collections, campaign pages, brand lines in theme settings |
| Collection | What is here, how do I narrow it, and how does this differ from a neighbouring category? | Collection description, automated collection conditions, Search & Discovery filters, collection metafields |
| Product | Does this item fit, are the specifications enough, and can I add it to cart with confidence? | Product, variant and category metafields, media, variant pickers, policy entry points |
| Cart | Can I change quantity, see delivery expectations, and go to checkout? | Line items, recommendations, cart notices. Do not drop a long brand story here. |
As a structural example, not a client result: if “for sensitive skin” exists only in the brand story, the collection has no skin-type or ingredient filter, and the first screen of the product page has no suitability note, the positioning has not entered the purchase decision.
The collection page’s job is to complete a choice with data and filters, not to retell the founder story. Specifications, usage, compatibility and add to cart belong on the product page. A serum and a set, or an accessory and a host product, can use different fields and a different module order. Handle that with alternate templates. The theme stays the same.
Shopify’s product template is responsible for media, content and the variant add-to-cart path. It can connect to line item properties, the Cart AJAX API and the recommendations API. It does not prescribe the order of brand modules, and it does not promise that any layout will sell better. What can be maintained is whether the facts a shopper needs are present before add to cart, and whether those facts are admin fields rather than a paragraph on a design board.
Turn selling points into product facts
If the narrative lives only in homepage copy, it expires as soon as SKUs change. What can travel with the catalogue is product data.
Decide which facts each category must expose — material, compatible models, skin type, power, certification, pack size — and store them as metafields instead of typing them into rich text for every product. Render variants as swatches or as clear option names so shoppers are not guessing from thumbnails.
Configure Search & Discovery filters around the fields shoppers actually use to narrow their choices. Use supported automated-collection conditions, such as tags, price, inventory or eligible metafields, to group products consistently. This reduces reliance on hand-maintained featured lists. Check which field types are supported before designing the catalogue around them.
The operating benefit is that the homepage can change seasonal tone while product pages and filters still point at the same facts. Narrative stops being a designer paragraph and becomes catalogue data. Reviews, size charts and manual downloads should attach to the product or variant and appear near the decision, not in a distant footer block.
Place trust where the decision happens
Cross-border shoppers ask product-page questions: what is in it, can it clear customs, how does warranty work, who pays shipping and tax, and do these reviews belong to this SKU. Those questions occur around add to cart. They do not occur on the third screen of a brand story.
Legal disclosures, ingredient lists, manuals, compliance files and rating summaries belong in metafields, visible on the product page and, where needed, in the cart. A policy link in the footer is a baseline, not a complete trust design. Reviews should map to a SKU or variant. A generic store-wide review banner does not help a specification decision.
In multiple markets, trust wording also has to match what that market can sell, the price it can show and how tax is displayed. Translating one market’s certification claim into another can become a false promise. That is a content-system problem, not a translation problem.
Do not force brand into checkout from the theme
The theme owns the storefront. Checkout, new customer accounts, abandoned-checkout email and post-purchase status pages have a different editor and a different extension boundary. Treating checkout branding as “move the theme header into checkout” produces rework.
Checkout UI extensions on the information, shipping and payment steps are currently available only on Shopify Plus. Theme app blocks do not render on the checkout page. Legacy checkout.liquid and older thank-you page scripts have been replaced by Shopify’s checkout extension path and should not be used as a routine customisation entry. Thank you and order status extensions, and Shopify Functions, have their own plan and capability boundaries. Do not estimate them as “the theme is done, therefore checkout can be branded”. See Shopify’s checkout technologies.
New customer accounts are independent of the theme. They are managed in the checkout and accounts editor. Accounts can also be placed on a subdomain of the primary domain so the logged-in experience stays visually continuous. A subdomain solves continuity and recognition. It does not create repurchase by itself. Abandoned-checkout recovery runs through checkout email and automation. The tone can be branded; the path is not edited in the Liquid theme.
Post-purchase upsell is not a default module. Compatibility depends on the app, payment method, product type and market. Brand relationship after the order is more often the fulfilment information the order status page can state clearly, and the order and reorder entry points a customer can find in their account.
Multi-market consistency is not a translated homepage
Once a brand sells into more than one country or region, the system boundary stops being “does this look like us” and becomes “can this market place an order, at what price, in which language, and how is tax shown”.
Shopify Markets configures language, pricing, URLs and sellable products by market. Checkout uses the shipping address to determine the final market experience, including currency and that market’s customisations. A language selector on the theme is not evidence that checkout is covered by Markets.
Automatic redirection usually applies only to the first page a customer visits, and it ignores search-engine crawlers. It helps a visitor reach the right market. It is not the whole of international indexing. Shopify documents both points in its Markets localisation guidance.
Each market should show only products that can be sold there. A correctly translated homepage hero with unsellable SKUs still in the catalogue is an empty promise. If price, promotion or tax display disagrees with checkout, the narrative breaks on the payment page. Align the sellable catalogue and price facts before arguing about theme differences and tone.
B2B is no longer a Plus-only wholesale add-on. Shopify’s current matrix makes B2B available on Basic, Grow, Advanced and Plus. Non-Plus stores currently have up to three active catalogues across all B2B markets. Plus has no catalogue cap and can assign a catalogue directly to a company or company location. Deposits, partial payments and payment requests per fulfilment remain Plus-only. Confirm the live split on Shopify’s B2B features by plan page before treating any of those capabilities as an upgrade reason.
Wholesale still has to enter the theme and the account. The operating question is who can see which catalogue, at what price, and how a draft order is placed. It is not a “dealer entrance” button on the homepage.
Build a system you can change, then discuss a plan upgrade
A brand-system build can follow this sequence so the project does not skip a layer:
- Write positioning as the question each template must answer, not as a brand story.
- Divide work across home, collection, product, cart and the necessary page templates. Handle category differences with alternate templates.
- Put visual rules in theme settings. Put selling points, specifications and disclosures in metafields and dynamic sources.
- Make product data filterable, usable in automated collections, and able to drive product-page modules.
- Place trust information at add-to-cart and checkout decision points.
- Implement checkout, customer accounts and abandoned checkout through the official editors and plan boundaries. Do not hack them in the theme.
- Then open markets: sellable products, price, language, URL and tax display, aligned together.
Choose technology by the layer that is actually stuck. Do not use a headless storefront to solve copy that was hard-coded in the theme. Deeper interaction can still live in a Liquid theme, through theme app extensions, Cart AJAX and a modest amount of JavaScript. That is the layer Shopify storefront page design and development usually lands first.
A headless storefront can use a chosen technology stack; Hydrogen is Shopify’s React-based framework. Set up the appropriate storefront channel and API access for the architecture. Review each metafield definition's Storefront API permissions and expose only the fields the public storefront needs. Treat that as an explicit implementation task, not something that happens automatically when moving away from a theme. See Shopify’s Storefront API metafields guidance.
If a single template hits the 25-section limit, split the template, add an alternate template, or put content pages on metaobjects. Do not treat that limit as a requirement to go headless.
Plus addresses specific requirements, including UI extensions on checkout's information, shipping and payment steps, custom apps built with Shopify Functions, and unlimited B2B catalogues with direct company or location assignment. Public apps built with Functions are also available on lower plans. Assess Shopify Plus upgrade and migration against the actual capability required, rather than assuming that any complex project needs Plus. The same applies to B2B and multi-market work.
WESWOO’s work is to turn brand visuals, information architecture and the purchase path into a maintainable Shopify theme and front end, and to implement Plus, headless or multi-market work when the project actually needs it. Fields, filters, alternate templates and checkout extensions will keep changing after launch, so delivery is designed for maintenance rather than as copy written once into a module.
If you are building a brand storefront, or an existing theme has left positioning on the about page, describe the current site, target markets and the blockage — a new build, a redesign, a migration or ongoing maintenance. When you contact WESWOO, include project background and the outcome you need. That is enough to judge whether the next step is template roles and fields, or whether checkout and catalogue boundaries have already been reached.
References: Shopify B2B features by plan, JSON template limits, dynamic sources.