# ByteInfy Engineering and product writing from the team behind ByteInfy's apps. ## Apps - [SwipeReel](https://www.swipereel.app/): Turn Instagram Reels, TikTok and UGC into shoppable video feeds on Shopify. Shopify App Store: https://apps.shopify.com/swipereel - [myBillPlease](https://www.mybillplease.com/): GST invoices, e-invoices, credit notes and GSTR filing for Indian businesses. Shopify App Store: https://apps.shopify.com/mybillplease - [COD OTP, Partial Pay & Upsell](https://apps.shopify.com/byteinfy-cod-partial-pay): Block fake COD orders with OTP, RTO scoring and pincode rules. Add COD fees and partial payment. Shopify App Store: https://apps.shopify.com/byteinfy-cod-partial-pay - [Alt Text Bulk Edit](https://apps.shopify.com/byteinfy-alt-text-editor): Bulk-edit product image alt text with templates, automation and quality scoring. Shopify App Store: https://apps.shopify.com/byteinfy-alt-text-editor All apps on the Shopify App Store: https://apps.shopify.com/partners/akway-ecomm-private-limited ## Services - [Shopify Store Development](https://www.byteinfy.com/services/shopify-store-development): Theme customisation, custom sections, checkout extensions, headless storefronts and migrations. (From $2,000) - [Shopify SEO](https://www.byteinfy.com/services/shopify-seo): Technical SEO, structured data and content that ranks and gets cited by AI search. (From $1,000) - [AI Agents & Automation](https://www.byteinfy.com/services/ai-agents-for-shopify): Agents that answer, draft, route and act inside your store, support desk and back office. (From $2,000) - [Shopify App Development](https://www.byteinfy.com/services/shopify-app-development): Custom and public Shopify apps, built to pass App Store review the first time. (From $3,000) All services: https://www.byteinfy.com/services ## Elsewhere - Add as a preferred source on Google: https://www.google.com/preferences/source?q=blog.byteinfy.com - Find us on the Shopify App Store: https://apps.shopify.com/partners/akway-ecomm-private-limited --- --- title: "Shoppable Video on Shopify: The 2026 Guide" description: "Shoppable video works when it removes a specific doubt a shopper has — fit, scale, texture, assembly. Here is how the formats differ, where to place them, and what adding video costs you in page weight." author: "Aashish Kaushik" published: 2026-10-27T13:00:07.513Z updated: 2026-10-27T13:00:07.516Z url: https://blog.byteinfy.com/shoppable-video-shopify-guide --- # Shoppable Video on Shopify: The 2026 Guide ## Key takeaways - Shoppable video earns its place by answering a buying question — fit, scale, texture, use — not by adding motion to a page. - Short wins: 91% of viewers prefer video under two minutes, and product-page clips are trending under 30 seconds. - Video is the heaviest thing you can add to a product page, so it must be lazy-loaded behind a poster image or it costs you the conversions it earns. - Importing existing Reels and TikTok content is usually the fastest start, because the content already exists and has been audience-tested. Video on a product page is easy to justify badly. It looks modern, competitors have it, and every vendor benchmark shows a lift. None of that tells you whether it will work on your catalogue. The useful question is narrower: what does a shopper still not know after looking at your images? If the honest answer is "nothing", video will not move your conversion rate. If the answer is fit, scale, texture, motion, assembly, or how the thing behaves in a real room on a real person — that is exactly the gap video closes, and it closes it better than any amount of copy. This guide covers the formats, where each belongs, the page-weight cost, and how to read the conversion claims you will encounter. > **Scope** > > Written for Shopify merchants adding video to an existing storefront. Live shopping and shoppable video are related but different disciplines; live is covered separately. ## What "shoppable" actually adds Plain video plays. Shoppable video carries product data — a tappable hotspot, a pinned variant, an add-to-cart that does not navigate away. The distinction matters because the value is in not breaking the shopper's attention. A shopper watching a 20-second clip of a jacket is, for those 20 seconds, actively interested. Sending them back to a grid to find the item they just watched costs most of that interest. The measurable difference between video and shoppable video is almost entirely this: the removal of the gap between wanting and buying. That also tells you where shoppable formats are wasted. A brand story on an About page does not need hotspots. A founder explaining sourcing does not need an add-to-cart. Shoppable formats belong where purchase intent is already present. ## The formats, and what each is for ## Format, placement and job | Format | Where it belongs | The job it does | | --- | --- | --- | | Product page clip | Product page, near the gallery | Answers one specific doubt about this item | | Carousel / story reel | Homepage, collection pages | Discovery — surfaces products a shopper had not considered | | Grid or gallery wall | Dedicated shop-the-look page | Browsing by aesthetic rather than category | | Popup / floating widget | Any page, triggered | Recovery and prompting; the most intrusive, use sparingly | | UGC social wall | Homepage, product page lower half | Social proof through visible real-world use | The most common mistake is using one format everywhere. A carousel on a product page competes with the product; a single clip on a homepage does not create discovery. Placement is not decoration — each format does a different job at a different point in the journey. ## Short, and shorter than you think The evidence on length is consistent. Around 91% of viewers prefer video under two minutes, and product-page video in 2026 is trending toward clips under 30 seconds ([Whatmore's 2026 shoppable video guide](https://www.whatmore.ai/blog/the-ultimate-guide-to-shoppable-video-for-2026/), retrieved 2026-09-02). Optimal reported length sits in the 30–60 second band for most commerce contexts. The reason is situational rather than attention-span mythology. Someone on a product page has already committed to considering the product. They are not looking for entertainment; they are resolving one doubt. A 15-second clip that shows the bag being worn by someone of stated height does more than a two-minute brand film, because it answers the actual question. ## What a good product clip contains - One clear question it answers, decided before filming - The product in real use or on a real person, not rotating on white - Scale reference — a hand, a body, a room, a stated measurement - No dependence on audio, since most views are muted - A visible product tag or hotspot so the shopper never has to search ## Reusing what you already have For most stores the fastest path is not new production. It is the Reels and TikToks that already exist, already performed with an audience, and are already sitting in a social account doing nothing for the storefront. The 2026 pattern is explicitly this: brands importing TikTok Shop and Instagram Reels content directly onto Shopify product pages, keeping a consistent look across touchpoints and owning the customer data that social platforms withhold ([Videowise, 8 Shoppable Video Trends for 2026](https://videowise.com/live-commerce/8-shoppable-video-trends-driving-ecommerce-revenue-in-2026), retrieved 2026-09-02). Two cautions. Rights first: a creator who agreed to a social repost has not necessarily agreed to storefront use as commercial material, and that permission should be explicit. Second, social content is made for a feed — vertical, fast, hook-led. Some of it transplants perfectly to a product page; some of it is pure top-of-funnel and will confuse a shopper who is three clicks from checkout. ## Where the video should sit on the page Placement decides whether a video is watched at all, and most stores get it wrong in the same direction: they put video too far down, below the fold and below the description, where it functions as decoration for people who had already decided. The useful principle is that video should sit where the doubt occurs. If the doubt is fit, the video belongs beside or inside the image gallery, before the size selector — because that is the moment a shopper hesitates. If the doubt is assembly or setup, it belongs near the specifications, where someone reading detail will meet it. If the video is social proof rather than product explanation, lower on the page is correct, because proof reinforces a decision rather than informing one. Desktop placement has one further wrinkle worth naming. On wide viewports the gallery and the buy box sit side by side, so a video opened in the gallery plays next to the price and the add-to-cart button. That is the ideal arrangement and it happens by default. On mobile the same video pushes the buy box off screen entirely, which is why a clip that tests well on desktop can flatten on phones — the shopper finishes watching and has lost the thing they were about to press. There is a real tension with the gallery. Putting video into the main image carousel gets it seen, but it competes with the images a shopper uses to evaluate the product, and an autoplaying clip in slot one can actively obstruct someone trying to look at the item. The compromise most stores land on is a video thumbnail in the gallery strip, clearly marked, in position two or three — visible, chosen deliberately, not forced. On mobile, which is where most of this traffic is, vertical format matters more than any of the above. A landscape clip in a vertical viewport wastes most of the screen and reads as repurposed desktop content, which is precisely the impression UGC is supposed to avoid. > **One video, tested properly** > > Resist adding video to the whole catalogue at once. A single format on a single product template, measured against a matched control, tells you more than a store-wide rollout that changes fifty things simultaneously and leaves you unable to attribute any of it. ## The page-speed cost is real and it is yours to manage Video is the heaviest asset you can put on a product page, and this is where video projects quietly fail. A store adds video, conversion does not move, and nobody connects it to the product page now taking a second longer to become interactive. The rule is that nothing video-related should download before a shopper indicates interest. In practice: - A lightweight poster image renders in the video's place, with correct width and height so the layout does not shift when it loads. - The player and the video file load on interaction, not on page load. - The video element never blocks rendering of the page's main content. - Autoplay, where used at all, is muted, short, and limited to a single element on the page. A store that gets this wrong pays twice — once in the Core Web Vitals hit across every product page, and again because the slower page suppresses the conversions the video was added to win. The [storefront and design](/category/storefront-design) archive covers the wider page-weight picture, and app-driven weight in particular. > **Read vendor benchmarks carefully** > > Published lift figures — 25–45% conversion improvements, 30%+ on product pages — come from vendors measuring pages that chose to add video. That is a self-selecting group: stores adding video tend to be stores investing in their product pages generally. The mechanism is real, the direction is consistent, but treat any single percentage as a ceiling rather than a forecast, and measure your own. ## How to test it honestly Video is unusually easy to fool yourself about, because the pages you add it to are usually your best products. A defensible test: 1. Pick a set of products where images genuinely leave a question open. Exclude products where they do not. 2. Add video to half, matched on traffic and baseline conversion rate. 3. Run it long enough to clear the noise — for most stores this is weeks, not days. 4. Measure conversion rate and revenue per visitor on the product page, and check Core Web Vitals on both groups. That last check is the one most stores skip, and it is the one that explains a null result. If the video group got slower, you measured two changes at once. For the app-level view of what is available and how the tools differ, the [Shopify apps](/category/shopify-apps) archive covers the video category specifically, and the [video commerce](/category/video-commerce) archive goes deeper on UGC sourcing and rights. **Want shoppable video that does not cost you page speed?** SwipeReel turns Instagram Reels and TikTok UGC into shoppable feeds on your Shopify storefront — carousels, stories, grids and popups, with tap-to-buy inside the video. [See SwipeReel on the Shopify App Store](https://apps.shopify.com/swipereel) ## FAQ ### Does shoppable video actually increase conversion rate? Reported lifts vary widely and should be read with care — vendor-published benchmarks are measured on pages that opted into video, which is a self-selecting group. ### How long should a product page video be? Short. Roughly 91% of viewers prefer video under two minutes, and the 2026 trend on product pages is toward clips under 30 seconds that make a single point. ### Will adding video slow down my store? It will if you embed it naively. Video is the heaviest asset type you can put on a product page. ### Can I reuse my Instagram Reels and TikToks? Yes, and it is usually the best starting point, because the content already exists and has been tested on a real audience. ### Is UGC better than professionally shot video? They do different jobs. UGC is more credible for demonstrating real-world use, fit and scale, because it visibly is not a studio production. Studio video is better for showing detail, finish and construction. --- --- title: "What to Offer After BFCM So Buyers Come Back" description: "You just acquired a large number of first-time buyers at the highest cost of your year. What happens in the next fortnight decides whether that was worth it." author: "Aashish Kaushik" published: 2026-10-27T05:00:15.799Z updated: 2026-10-27T05:00:15.995Z url: https://blog.byteinfy.com/post-bfcm-retention-offers --- # What to Offer After BFCM So Buyers Come Back ## Key takeaways - The week after Cyber Monday is the highest-return and least-planned period in the entire BFCM calendar. - A discount-acquired buyer becomes a discount-only buyer unless something else gives them a reason to return. - Returns are elevated on discounted purchases, and a good returns experience is one of the few reliable conversion points into repeat custom. - Measure BFCM on cohort behaviour over months, not on period revenue, or you will repeat an expensive mistake annually. Every BFCM plan has a detailed schedule for November and nothing for December. The offers are modelled, the emails are scheduled, the inventory is forecast — and the week after Cyber Monday is a blank space where everyone recovers. That week is the highest-return period in the whole calendar, because you have just acquired a large number of first-time buyers at the highest acquisition cost of your year, and most stores let them go quiet. > **The framing that helps** > > BFCM did not buy revenue. It bought customers, expensively. Whether that was a good purchase is decided in the following weeks, not in the period report. ## Service before selling The first communications should not be commercial, and the reason is specific to this cohort. A BFCM buyer frequently knows nothing about your brand. They saw an offer, they bought, and that is the entire relationship. They have not read your About page, do not know your delivery times, and have no idea what your returns policy is. **Set delivery expectations clearly**, and set them wide. Fulfilment is slower during peak, and a customer told a week and receiving it in a week is satisfied while one told two days is not. **Explain what they bought.** How to use it, set it up, care for it. This reduces returns from people who could not work out how to use something, and it is the first genuinely useful thing your brand has done for them. **Make support reachable.** A visible contact route in the confirmation email prevents a frustrated customer becoming a public review. **Confirm what happens next.** Dispatch, tracking, what to do if something arrives damaged. None of this sells anything, and all of it is what makes the next thing possible. ## A worked example of the first fortnight Abstract advice about sequencing is easy to agree with and hard to schedule. A concrete run of what the first two weeks after Cyber Monday can look like for a single order makes the timing easier to copy. Day zero, the order confirmation, sent automatically, states what was bought and roughly when it will arrive, with fulfilment expectations set generously given the volume the whole industry is processing at once. Day one or two, a dispatch notice with tracking, and if the product needs any setup or care, a short note pointing to that information now rather than waiting for it to be asked for. Around the stated delivery window, a check that the parcel actually arrived is worth more than it seems, particularly for a first-time buyer who has no history with your brand to reassure them if something looks wrong. This does not need to be a separate email if your delivery notifications already confirm it, but someone should be watching for exceptions rather than assuming the courier's system caught everything. A few days after expected delivery, once the customer has plausibly opened and possibly used the product, a message asking whether everything arrived as expected and reminding them how to reach support serves two purposes. It surfaces problems before they become returns or public complaints, and it is the first message in the sequence that is not purely operational, without yet asking for anything. From there, the fortnight is deliberately quiet on the commercial side. No second offer, no reminder that the sale is ending elsewhere, nothing asking for a repeat purchase. The next commercial contact, as covered above, waits until the two-to-four-week mark for most categories, timed to when the customer has actually used what they bought rather than to when your calendar has a free slot. The point of laying it out this way is that the fortnight is not empty, it just is not selling. Four or five short, mostly automated, entirely useful touches happen before the first ask, and that sequence is what makes the eventual ask land as a suggestion rather than as pressure. ## Returns are a retention opportunity Counter-intuitive and well supported by how customers actually behave. Return rates run higher on discounted and gifted purchases. Those returns arrive in December, when everyone is exhausted and the process is under strain. A return handled badly ends the relationship permanently. One handled well — quick, clear, no argument — is one of the few reliable ways to convert a price-driven buyer into someone who trusts you. Customers talk about returns experiences far more than about smooth deliveries. Practically: staff for the volume, make the process obvious, process refunds promptly, and resist the temptation to make returning difficult as a way of suppressing the rate. A slow refund after a discounted purchase produces a permanent non-customer. ## Do not lead with another discount The instinct is to follow BFCM with a December offer, and it teaches exactly the wrong lesson. A customer whose only two interactions with you were both discounted has learned that your prices are negotiable and that waiting is rational. Repeat that and you have built a business that only sells during promotions. ## Reasons to return, and what they teach | Reason offered | What the customer learns | | --- | --- | | Another discount | Wait for the next one | | A genuinely useful product | This works, buy it again | | Good service | This is easy to deal with | | Relevant new product | They understand what I want | | Early access or exclusivity | Being a customer has value | | Educational content | They know what they are doing | Everything below the first row builds something. The first row spends something. ## Time the next commercial contact properly The most common error is contacting too soon. A customer who received a product three days ago has not used it. A message asking them to buy again arrives before they know whether the first purchase was good, and it reads as pressure rather than as a suggestion. Wait until they have received and used it — for most categories two to four weeks. Then the contact can reference their actual experience, and a replenishment or complementary suggestion makes sense rather than feeling arbitrary. The exception is genuinely useful service communication, which should be prompt. ## Segment the cohort Not everyone who bought in BFCM is the same customer, and treating them identically wastes the differences. **Existing customers who bought again** are your best segment and were probably going to buy anyway. Thank them, do not discount them further. **First-time buyers at full price** during the period are unusually promising — they bought without needing the offer. **First-time buyers on the deepest discount** are the least likely to repeat. Worth a reason to return, and worth being realistic about the conversion rate. **People who bought a gift** may not be your customer at all. The recipient might be, which is a different and often overlooked opportunity. That segmentation costs an afternoon and changes what you send to each group. It also changes what you conclude. A store that measures its whole BFCM cohort together will find a mediocre repeat rate and draw a general lesson from it. A store that segments will usually find one group performing well and another barely at all, which is a far more useful finding — it tells you which part of the promotion bought customers and which part bought transactions, and those deserve different budgets next year. ## What a good reason to return looks like If not a discount, then what. The options that work share a property: they give the customer something they would have wanted anyway. **Replenishment timed to actual consumption.** For consumables, a reminder that arrives when they are running low is genuinely useful and converts well. This requires knowing roughly how long the product lasts, which most merchants do and few use. **The complementary product they now need.** Someone who bought the camera needs the card. Someone who bought the boots needs the care kit. This is more useful after the purchase than during it, because the need is now concrete. **Early access rather than early discount.** Letting customers see something before the public costs you nothing and confers status. It also rewards being a customer without teaching that prices are negotiable. **Content that makes the product better.** How to get more from what they bought. This is the most underused option and it builds the relationship rather than spending it. **A genuine loyalty structure**, if you have the volume to justify one. Points that accumulate give a reason to return that is not a one-off. What all of these have in common is that they are worth receiving. The test is whether the customer would be pleased to get the message if they were not intending to buy anything — a discount fails that test, and everything above passes it. ## January is part of the plan The month nobody schedules, and it follows directly from what you do in December. Post-peak is traditionally quiet, and stores respond by discounting again, which compounds the problem. The alternative is to use the quiet period for the things that pay later: fixing what the peak exposed, improving product data, and reaching the cohort you just acquired with something useful. Two practical points. First, expire everything — codes, automatic discounts, banner messaging. Sale messaging still visible in January is a common and damaging error, and a shopper who arrives expecting a discount that ended six weeks ago does not simply shrug. Second, the first commercial contact with your BFCM cohort will frequently land in January, because that is when they have used the product. Plan it as part of the BFCM programme rather than as a separate January campaign, because it is the point where the expensive acquisition either converts into a relationship or does not. ## Measure by cohort, not by period The measurement point that changes next year's plan. Period revenue tells you what you sold. It does not tell you whether you profited, because it excludes returns, elevated support costs, shipping subsidies, and the full-price sales you cannibalised. **Track the BFCM cohort over months.** What proportion bought again, and how quickly, compared with cohorts acquired at other times. **Compare against a normal cohort.** If BFCM buyers repeat at half the rate, that is not necessarily a failure — it is a number that should inform how much you are willing to spend acquiring them next year. **Include the returns.** Net revenue after December returns is the real figure, and it is meaningfully lower than the period number. Do this once and you have something genuinely useful for next year's planning. Skip it, as most stores do, and next November's decisions get made from the same impressions that produced this year's. > **Write it down now, not in January** > > Whatever you learned during the period — what broke, which offer performed, which segment behaved unexpectedly — record it while it is fresh. Everyone is certain they will remember and nobody does. Next year's planning otherwise restarts from memory and repeats the same mistakes. For offer structure and the margin arithmetic, see the [BFCM 2026](/series/bfcm-2026) series. Offer mechanics generally are covered in [promotions and offers](/category/promotions-offers). **Turning peak buyers into repeat customers** ByteInfy builds Shopify offer logic and post-purchase flows — segmentation, replenishment timing and mechanics that do not train customers to wait for a sale. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What should I send customers after BFCM? Not another discount, at least not first. Delivery expectations, how to use what they bought, and how to reach you if something is wrong. ### How do I turn BFCM buyers into repeat customers? Give them a reason to return that is not price. ### When should I contact BFCM customers again? The service communication starts immediately — dispatch, delivery, how to use it. ### Are BFCM customers worth less than other customers? On average they repeat at lower rates, because a share were acquired by price rather than by preference. That is an average, not a rule. ### How should I measure whether BFCM worked? By cohort, over months. Period revenue tells you what you sold and not whether you profited, since it excludes returns, elevated support costs and the full-price sales you cannibalised. --- --- title: "Shopify API Versioning: Staying Ahead of Deprecations" description: "Deprecations are the most predictable failure in the Shopify ecosystem. They are announced, scheduled, and they still take stores by surprise every year." author: "Aashish Kaushik" published: 2026-10-25T13:00:19.970Z updated: 2026-10-25T13:00:20.153Z url: https://blog.byteinfy.com/shopify-api-versioning --- # Shopify API Versioning: Staying Ahead of Deprecations ## Key takeaways - Shopify versions its APIs and retires old ones on a published schedule, so every deprecation is knowable in advance. - The failure is organisational rather than technical — nobody owns watching for changes until something breaks. - Scripts stopping on 30 June 2026 is the recent example, and its failure mode was silence rather than an error. - Quarterly upgrades are far cheaper than annual ones, because each one is small and the alternative is accumulated debt. Shopify deprecations are the most predictable failure in the ecosystem. They are announced in advance, scheduled publicly, and documented thoroughly — and they still take merchants and agencies by surprise every year. That gap between predictable and prevented is not a technical problem. It is that nobody is assigned to watch, so the information arrives through breakage rather than through planning. > **The recent example** > > Legacy Shopify Scripts stopped running on 30 June 2026, on schedule and with long notice. Stores still relying on them did not receive an error — discounts simply stopped applying, and some found out through margin reports weeks later. ## How versioning works, briefly Shopify releases API versions on a regular cadence. Each is supported for a defined window, then retired. Applications and integrations specify which version they call. The consequence is simple and easy to underestimate: **anything that pins a version and is never revisited has a scheduled expiry date.** Not a risk of failure — a date. That applies to public apps, custom apps, middleware, ERP connectors, warehouse integrations, reporting tools, and any script someone wrote three years ago that quietly moves data between systems. ## The failure mode is silence Worth emphasising, because it shapes how you should defend against it. If deprecations produced loud errors, this would be a minor operational annoyance. Frequently they do not. **Data stops syncing** while both systems appear to be running. **A discount stops applying** and orders complete at full price with no error logged. **An integration silently drops records**, and the gap is discovered at reconciliation. **A webhook stops arriving**, so the downstream work it triggers never happens at all, and nothing anywhere reports a failure because nothing failed — something simply never started. In each case the visible signal is absence — something that should have happened did not — and absence is exactly what monitoring is worst at catching unless it was designed to. ## Who owns watching for this The actual fix, and it is organisational. Most stores have no answer to "who reads Shopify's changelog". The developer who built the integration has moved on, the agency's engagement ended, and the merchant does not know the question exists. ## Assign these explicitly - Someone who reads Shopify release notes and changelogs on a schedule - An inventory of every integration and which API version each calls - A named owner for each integration, internal or external - A quarterly slot for upgrades, budgeted rather than improvised - Monitoring on the outcomes each integration produces, not just its uptime - A note of anything seasonal, which will not appear in a mid-year audit The inventory is the highest-value item and the one almost nobody has. A store cannot assess its exposure without knowing what it has connected, and that list is usually longer than anyone expects once middleware, reporting tools and one-off scripts are included. ## Upgrade in small increments The economics here are strongly in favour of frequency. **Version to version is usually small.** Most single-step upgrades involve a handful of changed fields or endpoints, and the work involved is proportionate to that. **Skipping several compounds.** Changes accumulate, the diff widens, and the testing surface grows. An integration three years behind is a project; one a quarter behind is an afternoon. **Forced upgrades happen at the worst time.** Left until a retirement deadline, the work lands when it lands — which may be during your peak trading period, and will certainly not be when you have slack. A quarterly rhythm keeps each upgrade small and puts the work where you choose rather than where the calendar puts it. ## Monitor outcomes, not availability A practical point that follows from the silent failure mode. Uptime monitoring tells you a service is responding. It does not tell you the service is doing the right thing, and deprecation failures usually leave things responding. What catches these: **Volume checks.** If a sync normally processes a few hundred records each day and one morning processes zero, that should raise an alert regardless of whether anything errored. **Outcome checks.** The proportion of orders receiving an expected discount, the count of records reaching a downstream system, the number of webhooks processed. **Reconciliation.** Periodic comparison between what Shopify holds and what your other systems hold. It is slow and unglamorous, and it catches an entire class of problem that nothing else will — the records that were never created at all, which no error log will ever mention because nothing tried and failed. ## Seasonal integrations are the trap Worth a specific mention because it catches experienced teams. An integration that only runs during a particular period — a seasonal feed, a promotional mechanism, a year-end reporting job — is invisible during a mid-year audit and absent when needed. The Scripts deprecation caught several merchants this way: a Script handling a November promotion was not exercised in July, so nobody noticed it had stopped working until the promotion did not. When building your inventory, ask specifically what runs only occasionally. Those are the items to test deliberately rather than assume. ## The categories of exposure Not everything connected to your store carries the same risk, and sorting by exposure tells you where to look first. ## Integration type and how exposed it is | Type | Exposure | Why | | --- | --- | --- | | Public apps you install | Low | The vendor upgrades; their incentive is aligned | | Custom apps built for you | High | Nobody upgrades unless you pay someone to | | Middleware and connectors | High | Often built once, then forgotten entirely | | One-off scripts | Very high | Usually undocumented and unowned | | Theme code calling APIs | Moderate | Survives theme updates and outlives its author | | Reporting and BI pulls | Moderate | Fails quietly, and the gap looks like a slow month | The pattern is that **anything a vendor maintains is comparatively safe, and anything you commissioned is not**. That inverts the usual intuition, which treats bespoke work as more reliable because it was built for you. One-off scripts deserve their own mention. Almost every established store has one — a nightly export, a data cleanup, a sync somebody wrote to solve a problem in an afternoon. They are rarely in any inventory, rarely documented, and they will break exactly like anything else. ## Making it cheap to stay current Two practices that reduce upgrade cost substantially, both worth adopting when an integration is built rather than retrofitted afterwards. **Keep API interaction in one place.** An integration that calls Shopify from a dozen scattered locations is a dozen places to change. One that routes everything through a single client layer is one place. This is ordinary good practice and it pays back specifically at upgrade time. **Write tests against the responses you depend on.** Not exhaustive coverage — just assertions that the fields your logic reads are present and shaped as expected. When a version changes something, those tests fail immediately rather than the behaviour failing silently in production three weeks later. Neither is exotic, and both convert a version upgrade from an investigation into a mechanical task. The stores that find upgrades painful are almost always the ones where the integration reaches into Shopify from everywhere and nothing verifies the shape of what comes back. > **Do not upgrade during peak** > > Version upgrades belong in quiet periods, with observation time afterwards. An upgrade shipped in November has no runway to reveal its problems, and the failures here are the silent kind that take days to surface. If a retirement deadline falls near your peak, do the work early rather than close to it. ## What to do this quarter 1. Build the inventory. Every app, integration, script and connector, and which API version each uses. 2. Assign owners. Each item gets a name, internal or external. 3. Find the oldest version in use. That is your nearest deadline and your first project. 4. Assign someone to the changelog, with a recurring reminder rather than good intentions. 5. Add outcome monitoring to anything whose failure would be silent. 6. Book a quarterly upgrade slot before you need it. None of that is difficult. All of it is the sort of work that never becomes urgent until it becomes an incident, which is exactly why it needs a slot in a calendar rather than a place on a list. There is a reasonable objection here, which is that this is overhead for a risk that may not materialise. It is worth answering directly: the risk always materialises. Every API version currently in use will be retired, without exception, on a date already scheduled. The only question is whether the work happens when you choose or when Shopify chooses, and the second option reliably costs more because it arrives without warning and frequently at the worst moment in the trading year. Framed that way, the quarterly slot is not insurance against something that might happen. It is scheduling work that is already certain. For the app development side, see [Shopify development](/category/shopify-development). The Scripts-to-Functions migration specifically is covered in the same archive. **Integrations you are not sure anyone is watching?** ByteInfy audits and maintains Shopify apps and integrations — version inventories, planned upgrades and monitoring for the failures that arrive silently. [Start a project](https://byteinfy.com/#contact) ## FAQ ### How does Shopify API versioning work? Shopify releases new API versions on a regular cadence and supports each for a defined period before retiring it. Applications specify which version they call. ### How long is a Shopify API version supported? Each version is supported for a defined window announced at release, and the schedule is published. ### What happens if I do not upgrade before a version is retired? Calls against the retired version stop working. ### How do I know when a Shopify API version is being deprecated? Shopify publishes changelogs, release notes and developer communications, and sends notices for apps calling deprecated endpoints. The information is available; the failure is almost always that nobody is assigned to read it. ### How often should I upgrade my Shopify API version? Regularly and in small increments, rather than waiting until forced. Each upgrade from one recent version to the next is usually a small piece of work. --- --- title: "Free or Paid Shopify Apps: What You Give Up" description: "A free app is not free of cost. It costs page weight, a dependency and a ceiling you will meet at the least convenient moment." author: "Aashish Kaushik" published: 2026-10-25T05:00:09.760Z updated: 2026-10-25T05:00:09.800Z url: https://blog.byteinfy.com/free-vs-paid-shopify-apps --- # Free or Paid Shopify Apps: What You Give Up ## Key takeaways - Free tiers are metered on something — orders, views, products, features — and which meter applies decides when you are forced to upgrade. - The subscription is rarely the largest cost; page weight and dependency usually are, and neither appears on an invoice. - A free app that becomes essential is a paid app with a delay, so read the ceiling before building a workflow on it. - Genuinely free apps exist, usually from vendors monetising elsewhere — that is fine, provided you know what the arrangement is. Free apps are the default starting point for most merchants, and the reasoning is sound — try it, see if it helps, pay if it does. The complication is that the subscription is rarely the largest cost, and the costs that matter do not appear on an invoice. A free app that adds half a second to every product page is expensive; it simply bills you in conversion rather than in currency. > **The reframing** > > The question is not free versus paid. It is what each option costs in total, and cost includes weight, dependency and the ceiling you will eventually meet. ## Which meter applies decides everything Every free tier is limited by something, and the choice of meter matters far more than the headline number. **Metered by orders.** You hit the ceiling as the business grows. This is the most predictable meter, and it has the advantage of arriving at the point when you can most easily afford to pay. **Metered by views or impressions.** You hit it when the feature *works*. A popup app limited by impressions becomes expensive precisely because it is being seen, which is an awkward incentive. **Metered by products or items.** You hit it when your catalogue grows, which may be soon and unrelated to revenue. **Metered by feature.** The most common and the most consequential. The free tier does something adjacent to what you need, and the thing you actually want is on the paid plan. ## Meter and when it bites | Limited by | Ceiling arrives when | | --- | --- | | Orders | The business grows | | Views or impressions | The feature succeeds | | Products | The catalogue grows | | Features | Immediately, if you need the paid one | | Locations or users | You expand operationally | | Support level | Something breaks | That last row is worth noting. Some free tiers include no meaningful support, which is fine until you need it — and the moment you need support is the moment you have least patience for discovering you do not have any. ## The costs that are not the subscription **Page weight.** The main one. An app loading JavaScript on every page charges you on every visit whether or not anyone uses its feature. Free apps are not systematically heavier than paid ones, but a merchant who installs freely because the trial costs nothing accumulates weight faster. **Dependency.** Every app is something that can break, change, be discontinued, or start charging. A free app doing something important is a business dependency with no contract behind it. **Uninstall residue.** Apps that write into theme files frequently leave code behind. Trialling several free apps over a year can leave a theme carrying the debris of all of them. **Your attention.** Every app is one more thing to configure, one more thing to understand, and one more candidate to eliminate when something on the store goes wrong. ## A free app that becomes essential is a paid app with a delay The pattern worth anticipating. You install a free app, build a workflow around it, and it becomes part of how the store runs. Then you hit the meter, or the feature you need turns out to be paid, or the vendor changes the free tier. At that point you have no leverage. The alternatives are paying whatever is asked or unpicking a workflow the business now depends on, usually at a moment you did not choose. The prevention is straightforward and rarely done: **before building anything on a free tier, find out where the ceiling is and what happens at it.** If the answer is that you would have to pay, decide now whether that price is acceptable, because you will not be deciding freely later. ## Before adopting a free app - Identify which meter limits the free tier - Work out where your realistic volume lands against that meter - Check whether the feature you actually need is on the free plan - Measure page-speed impact before and after installing - Confirm what happens to your data and theme if you uninstall - Find out what support the free tier includes - Note the date and what you expect the app to achieve ## When paying is straightforwardly better Four situations where the free option is a false economy. **The function is central to how you sell.** A dependency this important should have a support relationship behind it. **You will hit the ceiling imminently.** Building on a tier you are about to outgrow is work you will redo. **The paid app is lighter.** This happens more than expected. A well-built paid app using theme app extensions and loading only where needed can cost you less in conversion than a free one loading globally. **You need support that answers.** For anything touching checkout, payments or inventory, a support relationship is not a luxury — those are the areas where a problem costs you orders while you wait, and free tiers are precisely where support is thinnest. ## A worked example of the actual comparison Take a review app metered by number of monthly orders on its free tier, with a paid tier above that ceiling. The obvious comparison is the monthly fee against zero, and on that comparison free always wins. The fuller comparison looks at what each tier actually loads and what it actually does. Say the free tier displays a basic star rating and loads a script on every product page regardless of whether a review exists yet. The paid tier adds photo reviews, a request-for-review email flow, and loads only on pages that have reviews to show. Now the paid tier is doing two things at once: adding a feature you might want, and reducing page weight on products that have nothing to display. Work through the order-volume side first. If the store processes close to the free tier's ceiling already, the free plan is not really free, it is a paid plan starting next month, and building a workflow around it now means migrating that workflow later regardless of the feature comparison. Then work through the weight side. If DevTools shows the review script loading on every product page including the ones with zero reviews, that is measurable page weight bought for a feature that, on those pages, displays nothing. A merchant with a thousand-product catalogue and a few hundred reviewed products is paying that cost on the majority of pages for no visible benefit. Put the two findings side by side rather than in sequence. A free tier that is about to hit its order ceiling and is also loading unnecessary weight on unreviewed pages is not a marginal case. It is already costing more than the paid tier's monthly fee, just not in a place that shows up on an invoice. A free tier with headroom on its ceiling and a script that only loads where reviews exist is a genuinely different situation, and staying on it is the reasonable choice. The general method transfers to any app category: price the meter against your real trajectory, price the weight against what DevTools actually shows loading, and only then compare that combined figure to the paid tier's fee. Comparing the fee alone answers the wrong question. ## Genuinely free apps exist Worth saying, because the section above is sceptical by design. Some apps are free because the vendor monetises elsewhere — a paid tier aimed at larger merchants, an adjacent product, or the app functioning as an introduction to a service. Others are free because they are small, cheap to run, and built by someone who wanted them to exist. These are legitimate, and some are excellent. The thing worth knowing is which arrangement applies, because it tells you how likely the free tier is to persist. An app that is free as a funnel into a paid product will stay free. An app that is free because nobody has worked out the business model may not. ## Reading a pricing page properly Pricing pages in the App Store are designed to be scanned, and the things that matter are usually not the things emphasised. **Find the meter first, not the price.** The headline figures tell you what each tier costs. What you need is what moves you between them, and that is usually stated less prominently. **Check what happens at the limit.** There are three possibilities and they differ enormously: the feature stops working, the app keeps working but stops counting, or you are automatically upgraded and billed. The third is the one to identify before it happens. **Look for per-unit charges on top of the tier.** Some apps charge a subscription plus a cost per message, per verification, or per order processed. At volume the variable component can exceed the subscription substantially. **Check whether pricing scales with your Shopify plan.** Some apps price by your store's plan rather than by usage, which means an unrelated upgrade increases your app costs. **Look at the gap between tiers.** A jump from a small monthly fee to a much larger one, with nothing in between, means outgrowing the lower tier is a significant cost event rather than a gradual one. **Check the annual commitment terms.** Discounted annual billing is common and reasonable, and it is also a year of commitment to an app you have used for a fortnight. None of this takes long. Five minutes on a pricing page, done properly, prevents the most common app regret — which is not choosing a bad app but choosing a good one on terms that stopped working as the store grew. > **Model your volume in twelve months, not today** > > Every meter should be checked against where you expect to be next year, not where you are now. An app whose free tier comfortably covers your current orders and would be exceeded three times over at your growth target is an app you are adopting on terms that expire. ## A reasonable default Start free where the app is genuinely peripheral and the ceiling is far away. Pay from the outset where the function is central, where support matters, or where the free tier's limitation would force an upgrade within months. And review annually. Free apps accumulate more quietly than paid ones, precisely because nothing bills you for them — which means nothing prompts anyone to ask whether they are still needed. That asymmetry is worth naming plainly, because it inverts the usual instinct. A paid app gets scrutinised every time someone looks at the invoice; a free one is invisible in every financial review a store ever does. The result is that the apps most likely to be sitting unused on a storefront, loading scripts and doing nothing, are almost always the free ones. The practical response is to audit by what loads rather than by what costs. Open a product page in DevTools, look at what third parties appear, and check each against what you can actually point at on the storefront. That list includes the free apps your billing page never mentions, and it is where most of the recoverable page weight on a typical Shopify store turns out to be hiding. For the wider app selection question, see [Shopify apps](/category/shopify-apps). Page weight and its consequences are covered in [storefront and design](/category/storefront-design). **Paying for four apps to do one job?** ByteInfy replaces overlapping Shopify apps with logic you own — lighter, without the conflicts, and with no ceiling to hit. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Are free Shopify apps actually free? Free of subscription, generally not free of cost. They add page weight to templates that convert, create a dependency on a vendor, and frequently carry a ceiling you will eventually hit. ### How are free Shopify app tiers usually limited? By orders processed, by views or impressions, by number of products, or by feature. ### Should I start on a free plan and upgrade later? Often yes, provided you know where the ceiling is and what happens when you reach it. ### Why do some Shopify apps offer a genuinely free tier? Usually because the vendor monetises elsewhere — a paid tier for larger merchants, an adjacent product, or the app is a funnel into a service. ### When is paying for an app clearly worth it? When the function is central to how you sell, when the free tier's ceiling would be hit imminently, when you need support that responds, or when the free alternative costs more in page weight than the paid one. --- --- title: "Shopify Payment Methods for Indian Stores" description: "The payment mix on an Indian store is a commercial decision, not a checkout setting. Each method changes your cost, your cash cycle and your return rate." author: "Aashish Kaushik" published: 2026-10-24T13:00:21.285Z updated: 2026-10-24T13:00:21.295Z url: https://blog.byteinfy.com/shopify-payment-methods-india --- # Shopify Payment Methods for Indian Stores ## Key takeaways - UPI dominates Indian digital payments and behaves differently from cards on cost, settlement and failure modes. - COD is a payment method in name and an unsecured option in practice, with costs that never appear as refunds. - Payment failure is a large and under-measured source of lost orders, and the recovery path matters as much as the method mix. - Offering everything is not a strategy — each method carries cost, reconciliation work and a distinct failure profile. Payment method selection gets treated as a checkout configuration and it is closer to a commercial decision. Each method changes what you pay, when you get paid, how often a transaction fails, and in the case of COD, how many parcels come back. Guides written for other markets are of limited help here, because the Indian payment landscape has its own shape — UPI's dominance, COD's persistence, and a failure profile that differs from card-first markets. > **Verify availability yourself** > > Which gateways, methods and first-party features are available in India changes, and it changes faster than articles are updated. Treat everything here as orientation and confirm the current position with your gateway. ## The methods and what each actually costs you ## Payment methods on an Indian store | Method | Typical cost | Settlement | Main risk | | --- | --- | --- | --- | | UPI | Low | Fast | Failed transactions at bank side | | Cards | Moderate | Standard cycle | Authentication drop-off, declines | | Net banking | Moderate | Standard | Bank-side session failures | | Wallets | Varies | Varies | Fragmented across providers | | BNPL | Higher | Varies | Eligibility friction, cost per order | | COD | Deceptive | On delivery | Return-to-origin, tied-up capital | The COD row deserves the emphasis. It appears cheap because there is no gateway fee, and its real cost — forward shipping, return shipping, packaging, handling, working capital and inventory tied up in transit — never appears as a refund line. It simply is not in the revenue. ## UPI is the default, not an alternative For an Indian consumer store, UPI is not a supplementary method. It is the one a large share of your customers expect, and its absence is conspicuous. Practical points that differ from cards: **The flow leaves your site**, into an app, and comes back. That handoff is a place where sessions break, so the return path needs testing rather than assuming. **Failure is common and usually recoverable.** A failed UPI attempt is frequently a bank-side timeout rather than a decision, and a customer who is offered an obvious retry will often complete. **Settlement is fast**, which matters for the cash cycle considerably more than most merchants tend to model when comparing methods. **Costs are low**, which makes the comparison against COD look even less favourable than it first appears once return-to-origin and the working capital gap are both counted properly. ## COD needs managing, not just enabling Covered in depth elsewhere, but the summary belongs here because it is a payment decision. Not offering COD in most consumer categories costs more revenue than it saves. Offering it without controls costs you in returns. The workable position is offering it with proportionate friction: **OTP verification** removes the largest category of failure — orders placed with a number nobody answers. **Partial prepayment above a threshold** converts a free option into a commitment, which is what changes behaviour at the door. **Pincode and value rules** apply friction where your own delivery data shows the risk actually is, rather than everywhere. The measure throughout is delivered revenue net of RTO cost, never conversion rate. Judging COD controls on conversion guarantees you remove interventions that were working. ## Payment failure is a bigger leak than it looks The under-measured problem, and it is larger in India than in card-first markets. A shopper who reaches payment and fails has demonstrated maximum intent. They are not comparing or browsing — they tried to give you money and something went wrong. Yet most stores treat them identically to someone who abandoned a cart three steps earlier. What helps: **Do not lose the cart.** A failed payment should return the shopper to a checkout that still has everything in it. **Offer an alternative method immediately.** If cards failed, UPI is right there. **Say what happened**, plainly. "Your payment did not go through" with a retry beats a generic error. **Follow up differently.** A payment failure needs a different message from a browsing abandonment. Sending "you left something in your cart" to someone whose card was declined is mildly insulting, and it wastes the most recoverable contact you will make all week. ## Payment setup worth verifying - Complete a real purchase through every method you have enabled - Test the UPI return path, including what happens if the app is slow - Test a deliberately failed card payment and check the recovery route - Confirm COD controls apply, including through accelerated checkouts - Check the mobile experience for each method on a real device - Confirm reconciliation works for every method your finance process handles ## More methods is not automatically better The instinct is to enable everything, and it has costs. **Checkout clutter.** A wall of payment options increases decision time at exactly the wrong moment. **Reconciliation work.** Every method is a settlement stream, a fee structure and a place where finance has to check something. **More failure surface.** Each integration is something that can break, and it will break at a time you did not choose. **Fragmented data.** Working out what is actually happening across nine payment methods is considerably harder than doing it across four. Look at what your customers actually use, cover that properly, and stop there. Adding a method used by two percent of orders is rarely worth the reconciliation overhead and the additional failure surface it creates, and the two percent will almost always use something else you already offer. ## Cash cycle is the consideration nobody models Payment method mix determines not just what you earn but when you have it, and for a growing store that timing can matter more than the fee difference. **UPI settles quickly**, which means the money from a sale is available to buy more stock sooner. **Cards settle on a standard cycle**, which is predictable and slower. **COD is the slowest by a wide margin.** The order ships, the customer pays the courier, the courier remits to you, and that chain takes considerably longer than any digital method. Meanwhile you have already paid for the goods, the packaging and the outbound shipping. For a store growing quickly, this is a real constraint. A high COD share means a large proportion of your revenue is permanently in transit, funding a working capital gap that grows as you grow. Merchants who model only the fee difference between COD and prepaid consistently underestimate this, and it is the mechanism by which a profitable-looking store runs out of money. The practical implication is that shifting even a modest share of orders from COD to prepaid has an effect beyond the RTO saving. It shortens the cash cycle, which is what actually funds the next inventory purchase. ## Displaying methods well A smaller point that affects conversion more than it should. **Show the methods before checkout.** A shopper who does not know you accept UPI may not reach checkout to find out. Payment icons on the product page and in the cart are worth the space. **Order them by what your customers use.** The most-used method should be the most prominent, not the one your gateway lists first. **Do not hide COD behind everything else** if it is a majority preference in your category. Making a popular method hard to find is friction disguised as a nudge, and shoppers notice. **Name them the way customers do.** Regional naming conventions matter, and a method labelled in a way a customer does not recognise is a method they will not select. > **Look at what your customers actually chose** > > Your order data already tells you the payment mix, and it usually differs from what merchants assume. Check it before adding or removing anything — the method you were about to remove may be quietly carrying a segment you did not know you had. ## Accelerated checkout interacts with all of this A structural point that catches merchants out during promotions. Accelerated checkout buttons compress or skip steps, so anything depending on a skipped step does not reach those shoppers. Discount codes need a field the shopper can type into; COD controls implemented by manipulating the cart may not run at all. Test a complete purchase through each accelerated method you have enabled, with your actual COD rules and offers active. This is the single test that most reliably exposes a payment configuration that looks correct and is not. The same applies whenever anything upstream changes. A new discount app, a checkout customisation, a gateway update — each can alter how methods behave without anyone touching the payment settings. Re-running a handful of real purchases after any significant change costs the price of a few orders and catches the class of problem that otherwise surfaces as unexplained conversion loss weeks later. Make it a habit rather than a launch task. The stores that avoid payment incidents are not the ones with better configuration; they are the ones where somebody buys something from their own store regularly enough to notice when it stops working properly. For the COD and RTO picture in full, see [checkout and payments](/category/checkout-payments). POS and retail payment considerations for India are covered in [POS and operations](/category/pos-operations). **COD that does not cost you in returns** ByteInfy's COD & Part Payment app adds OTP verification via SMS or WhatsApp, partial prepayment at checkout, and smart COD blocking by pincode, product or cart value. [See it on the Shopify App Store](https://apps.shopify.com/byteinfy-cod-partial-pay) ## FAQ ### What payment methods should an Indian Shopify store offer? At minimum UPI and cards, because between them they cover most digital payment preferences. COD is close to unavoidable in many categories, though it should be managed rather than simply enabled. ### Is Shopify Payments available in India? Availability and capability differ by market and change over time, which is why Indian merchants commonly use a local payment gateway integrated with Shopify rather than assuming the first-party experience described in guides written for other markets. ### Should I offer COD on my Shopify store in India? In most consumer categories, not offering it costs more revenue than it saves, because COD remains a majority payment preference. ### Why do so many card payments fail in India? Multi-factor authentication steps, bank-side declines, session timeouts and network interruptions all contribute, and the rate is meaningfully higher than in some other markets. ### Does offering more payment methods increase conversion? Up to a point. Covering the methods your customers actually use helps; adding every available option produces a cluttered checkout, more reconciliation work and more failure surface. --- --- title: "GST Invoicing for Shopify Stores in India" description: "Shopify handles tax calculation. It does not produce the invoice format Indian compliance expects, and that gap is a requirement to solve rather than discover." author: "Aashish Kaushik" published: 2026-10-24T05:00:08.744Z updated: 2026-10-24T05:00:08.748Z url: https://blog.byteinfy.com/shopify-gst-invoicing-india --- # GST Invoicing for Shopify Stores in India ## Key takeaways - Shopify calculates GST but does not natively produce the invoice format Indian compliance expects. - The gap is a project requirement, not a surprise — decide the route during implementation, not after the first filing. - Most merchants integrate with the accounting software where filing already happens, rather than adding a standalone app. - B2B orders need the customer's GSTIN captured at checkout, which is not a default field. Merchants setting up a Shopify store in India frequently discover the GST gap after launch, usually at the first filing or the first B2B customer who asks for a proper invoice. The gap is narrow and specific. Shopify calculates tax competently and can be configured with GST rates. What it does not do is produce the invoice document Indian compliance expects, with the fields, structure and numbering that document requires. That is a requirement to solve during implementation rather than a defect to complain about, and treating it as one avoids the scramble. > **Verify against current rules** > > GST requirements change, and the specifics vary by what you sell and where. Everything here is orientation. Confirm the current position with whoever handles your filing before building anything. ## What Shopify does and does not do **It does** calculate tax, support tax rate configuration, apply rates by region, and record what was charged on each order. **It does not** natively produce a compliant tax invoice — HSN or SAC codes per line item, the CGST, SGST and IGST split presented as required, a compliant sequential numbering series, or the supplier and recipient GSTIN details a business customer needs. Those are document requirements rather than calculation requirements, which is why the platform handles one and not the other. Shopify serves a great many jurisdictions and does not implement each country's specific invoice format natively, which is a reasonable design decision that nonetheless leaves Indian merchants with work to do. ## The routes available ## Approaches to GST invoicing on Shopify | Route | What it gives you | What it costs | | --- | --- | --- | | GST invoicing app | Compliant invoices generated from orders | Monthly fee, another dependency | | Integration with accounting software | Orders flow into a system built for Indian compliance | Setup work, sync to maintain | | Custom development | Exactly the document and workflow you need | Build cost and maintenance | | Manual, outside Shopify | Complete control | Not viable beyond very low volume | Most merchants end up on the second, because filing happens in the accounting package regardless. Sending orders there and producing invoices from the system that files them avoids maintaining two sources of truth. A standalone app is a reasonable choice at low volume with straightforward accounting. Custom work makes sense when your requirements are unusual, or when several apps are combining to produce one outcome. ## Capture the GSTIN at checkout The requirement most often missed at launch, and it only surfaces when a business customer asks. A B2B buyer needs your invoice to carry their GSTIN to claim input tax credit. Shopify checkout has no GSTIN field by default, so it must be added — through a checkout UI extension, an app, or a custom field. Points worth settling when you add it: **Make it optional.** Most consumers do not have a GSTIN, and a mandatory field adds friction to every single order in order to serve a small minority of them. **Validate the format.** A mistyped GSTIN produces an invoice the customer cannot use, and they will come back for a corrected one. **Carry it through to the invoice.** Capturing it and not printing it is the worst of both — you added friction and did not deliver the benefit. **Decide what happens retrospectively.** Customers will ask for an invoice carrying their GSTIN after having ordered without entering it. Have an agreed process for reissuing rather than improvising a different answer each time somebody asks. ## Numbering is not cosmetic An easy detail to underestimate. Invoice numbering under GST is expected to follow a sequential series with defined characteristics, and it must be consistent. Shopify's order numbers are not designed as a GST invoice series, and using them directly is usually not appropriate. Whichever route you take, the numbering needs deciding deliberately — the series format, where the sequence lives, and what happens across financial years. This is exactly the sort of thing that is trivial to set up correctly at the start and awkward to correct after a few hundred invoices exist. ## Where it interacts with the rest of the store Three places GST touches things merchants do not initially connect to it. **Returns and refunds.** A refunded order needs a credit note, and that document has its own requirements. Decide how these are produced before your first return, not during it. **Discounts.** Tax is calculated on the discounted value, so how a discount is applied affects the invoice. This matters more with complex mechanics — bundles, tiered thresholds, free gifts — where the value attributed to each line is not obvious. **Shipping charges.** Whether and how tax applies to shipping needs setting correctly, and it is among the most common misconfigurations because it is set once during launch and then never revisited by anyone. ## Before launching in India - Decide your GST invoicing route and cost it into the project - Confirm HSN or SAC codes exist for every product - Set up the invoice numbering series deliberately - Add a GSTIN field at checkout, optional and validated - Confirm tax on shipping is configured correctly - Decide how credit notes are produced for returns - Have your accountant review a real invoice before you rely on it That final item is the highest-value line on the list. One real invoice reviewed by whoever files your returns catches more problems than any amount of reading, it takes them a few minutes, and it converts a set of assumptions into a confirmed position before those assumptions are baked into several hundred documents. ## HSN codes are a catalogue problem The part that takes longest and gets scoped shortest. A compliant invoice needs an HSN or SAC code per line item, which means every product in your catalogue needs one recorded against it. For a store with eight hundred products, that is a data project rather than a configuration setting. Practical points: **Store it as structured data**, in a metafield or a dedicated field, not in the description. Whatever produces your invoices needs to read it programmatically. **Codes vary by product type**, and getting them wrong has consequences beyond an untidy invoice. This is a question for your accountant rather than a guess from a lookup table. **Set a default and flag exceptions.** For catalogues where most products share a code, defaulting by product type and marking the exceptions is far faster than working product by product. **Build it into product creation.** Otherwise new products launch without a code and the gap reopens continuously — the same pattern as alt text, and with the same fix. ## Multi-state and place of supply Worth understanding before configuring anything, because it drives the tax split on every invoice. Whether a supply is intra-state or inter-state determines whether tax appears as CGST plus SGST or as IGST, and that determination rests on place of supply — for goods, generally the delivery address. Two consequences for a Shopify store: **Your registered location matters.** The split is calculated relative to where you are registered, so a merchant registered in one state selling nationally will produce both kinds of invoice routinely. **Multiple registrations complicate it.** A business registered in several states, or operating warehouses in several, has a more involved determination and should not assume a single configuration covers it. This is a genuine reason to involve whoever handles your filing during setup rather than after. The configuration is not difficult once the rules are clear, and it is very difficult to correct retrospectively across a few months of issued invoices. > **Test with a real inter-state order** > > Place one genuine order to a different state and check the resulting invoice end to end — the split, the place of supply, the numbering, the codes. One real order surfaces more than any amount of configuration review, and it costs you the price of one product. ## Plan it during implementation The recurring pattern worth naming: merchants evaluate Shopify on its commerce features, launch, and meet the GST requirement afterwards. Treated as part of the implementation, it is a manageable piece of work with a known cost. Treated as a surprise, it arrives alongside a filing deadline or an annoyed B2B customer, and gets solved under pressure with whatever is quickest. It also belongs in the platform comparison. If you are weighing Shopify against a local ecommerce platform that handles GST natively, the honest comparison includes the cost of closing this gap — and it is a genuine consideration, particularly for merchants whose business is primarily domestic and primarily B2B. For most merchants that comparison still favours Shopify, because the compliance gap is a bounded one-off cost while the platform advantages are ongoing. But it should be a decision made with the number in front of you rather than a gap discovered after committing, and merchants who are overwhelmingly domestic and B2B should genuinely weigh the alternatives rather than assuming. For the wider India-specific picture, see [POS and operations](/category/pos-operations). Payment methods and COD handling for Indian stores are covered in [checkout and payments](/category/checkout-payments). **GST invoicing that works with your filing** ByteInfy builds Shopify integrations for Indian merchants — GST-compliant invoicing, accounting sync and the operational pieces the platform leaves open. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Does Shopify generate GST invoices for India? Shopify calculates tax and can be configured with GST rates, but it does not natively produce the full invoice format Indian compliance expects — HSN codes, the CGST, SGST and IGST split presented as required, a compliant numbering series, and supplier and recipient GSTIN details. ### What does a GST-compliant invoice need to include? Broadly: your GSTIN and the customer's where applicable, a sequential invoice number, invoice date, place of supply, HSN or SAC codes per line, taxable value, and the tax split shown correctly as CGST and SGST for intra-state supply or IGST for inter-state. ### How do I collect a customer's GSTIN on Shopify checkout? Not by default — it needs a custom field, added through a checkout UI extension or an app. ### Should I use a GST app or integrate with my accounting software? Most merchants integrate with the accounting package they already file from, because filing happens there regardless and a second system creates reconciliation work. ### How does GST work for inter-state Shopify orders? Intra-state supply is generally split into CGST and SGST; inter-state supply is generally IGST. Which applies depends on place of supply, which for goods is usually the delivery address. --- --- title: "When a Shopify Storefront Redesign Is Worth It" description: "A redesign that changes fifty things at once cannot tell you which of them helped. That is why so many of them are followed by an argument about the numbers." author: "Aashish Kaushik" published: 2026-10-23T13:00:18.390Z updated: 2026-10-23T13:00:18.393Z url: https://blog.byteinfy.com/shopify-storefront-redesign --- # When a Shopify Storefront Redesign Is Worth It ## Key takeaways - Looking dated" is rarely the actual problem, and a redesign undertaken for that reason usually does not move the numbers. - Changing everything simultaneously makes the result unattributable, which is why redesigns are so often followed by disagreement. - Diagnose first — the funnel, by device, tells you which two or three pages are actually losing money. - Keep URLs, structured data, heading hierarchy and internal links intact, or you will trade design for traffic. Most storefront redesigns are commissioned because someone looked at the store and felt it was dated. That is a real feeling and rarely the actual problem, which is why so many redesigns cost a great deal and change no numbers. The redesigns that work start somewhere else: with a diagnosis of what is specifically losing money, and a scope confined to fixing it. > **The question to answer first** > > Which two or three pages, on which device, are losing you the most? If you cannot answer that, a redesign is a guess with a budget attached. ## Diagnose before you scope The funnel, by device, tells you most of what you need. **Look at the drop between steps**, not the overall conversion rate. The step with the widest gap is where the money is going, and it is frequently not where anyone assumed. **Separate mobile and desktop.** They behave differently enough that an aggregate figure hides the problem. If mobile is dramatically worse, your redesign brief is a mobile brief. **Look at your top templates**, not your whole site. On most stores, product pages and two or three collections carry the overwhelming majority of commercial traffic. **Watch session recordings if you have them.** Rage taps, repeated scrolling and abandonment at a specific field say more than any general critique. Do this and the brief writes itself. Skip it and you get a brief that says "modernise the store", which is unfalsifiable and produces an expensive change nobody can evaluate. ## The common findings are not visual When merchants do run the diagnosis, the results tend to be structural rather than aesthetic. ## Frequent findings and what they actually need | Finding | What fixes it | | --- | --- | | Buy box below the fold on mobile | Template change, not a redesign | | Pages slow on real connections | App audit, font and image work | | Filtered collection URLs eating crawl | Indexation fix | | Thin collection pages | Content and consolidation | | Checkout drop at shipping step | Show shipping earlier | | Product data too thin to decide from | Better photography and specifications | | Navigation nobody can use on a phone | Menu simplification | Every row on that table is cheaper than a redesign and more likely to move the number. A store that fixes all of them and still feels dated at least knows that appearance is now the remaining variable, which makes the subsequent design conversation far more productive because it is no longer carrying the weight of unfixed structural problems. ## When a redesign is genuinely warranted Four situations where a rebuild rather than a repair is the right answer. **The structure prevents what you need.** Not "it looks old" but "we cannot express our product range in this information architecture" or "there is nowhere for the content our category needs". **A brand change.** If the business has repositioned, the storefront should follow. This is a legitimate reason and it should be stated as such rather than dressed up as a conversion project. **Accumulated technical debt.** Years of small changes, several agencies, a theme modified beyond recognition. At some point the cost of working within it exceeds the cost of replacing it. **A platform migration.** Moving to Shopify from another platform entirely, or moving onto a fundamentally different theme architecture such as a block-based system. Notice that only the first and third are about performance, and both are about capability rather than appearance. ## Protect what already works The most preventable damage in any redesign, and the reason some rebuilds trade conversion for aesthetics. ## Audit before and after launch - Every URL resolves as before, or is redirected if it genuinely must change - Structured data present on all key templates, and matching the visible page - Heading hierarchy clean — one H1, no skipped levels - Internal link graph comparable, particularly product-to-collection breadcrumbs - Core Web Vitals no worse, measured on a real phone - Alt text carried over rather than lost in the rebuild - Analytics and conversion tracking still firing The heading and structured data items are the ones most often lost, because they are invisible in a design review. Nobody looks at a beautiful new product page and notices it stopped emitting product schema. The URL item is non-negotiable. Changing URLs during a redesign is the single most damaging thing you can do to a store's organic traffic, it is almost never actually necessary, and it is usually done because a new information architecture made it seem tidy rather than because anything required it. ## When a URL genuinely has to change Sometimes a redesign does force a URL change, most often when moving between fundamentally different information architectures or when a collection genuinely needs restructuring rather than restyling. The rule against changing URLs is not absolute, it is a default that should require a real reason to override, and when that reason exists the redirect work deserves the same rigour as the design itself. Start by exporting a full list of every current URL that receives any organic traffic or backlinks, not just the ones that seem important from memory. Search Console and your analytics both hold this data, and combining the two catches pages that rank for something unexpected but generate little traffic, which are exactly the ones a redesign team overlooks because nobody thought to check. Build the redirect map before the new site launches, not after, mapping every old URL to the single most relevant new one. A redirect to the homepage is barely better than a 404 for anything that had accumulated its own rankings; the destination should be the page that now serves the same intent, which for a discontinued or restructured category is usually the closest surviving collection. Test the redirect map against the live old site before cutover, checking a sample across your highest-traffic and highest-value pages rather than assuming the map is correct because it looks complete in a spreadsheet. A single misconfigured rule, such as a trailing slash mismatch or a redirect chain pointing at another redirect instead of the final destination, can silently break a whole category of URLs at once. After launch, monitor 404s in Search Console daily for the first two weeks rather than waiting for the monthly report, since this is the window when a missed redirect does the most damage: traffic and link equity that would otherwise transfer cleanly instead lands on an error page while nobody is watching closely enough to notice quickly. ## Stage it if you can Big-bang launches are common and they have one serious flaw: when the numbers move, nobody can say why. A staged approach — product template first, then collections, then the homepage — lets you attribute each change and reverse what did not work. It is slower, less satisfying, and considerably more informative. Where a staged rollout is genuinely impossible, at least do not change content and structure at the same time. Ship the design with content held constant, confirm stability, then make content changes as a separate release. ## Briefing it so you get what you need A redesign brief that says "modernise the store" produces a designer's interpretation of modern, which may or may not intersect with your problems. A brief that lists diagnosed problems produces solutions to them. **Lead with the findings, not the feeling.** "Mobile product pages lose people before the buy box" is a brief. "It looks tired" is a mood. **State what must not change.** URLs, structured data, the elements you know are working. Designers cannot protect what they do not know matters. **Name the constraints honestly.** Page weight budget, which apps must keep working, what your team can maintain afterwards. A design that requires capabilities you do not have is not a design you can ship. **Include your actual content.** Real product photography, real descriptions of real length, the product with fourteen variants and the one with a two-word description. Designs built on ideal content break on real catalogues, and the break is discovered during build rather than during design. **Say who the decision-maker is.** Redesigns stall on unresolved opinion more than on any technical problem, and the time to establish who decides is before there is anything to disagree about. ## What it should cost you afterwards The part budgets rarely include. A redesign is not a finished thing. It needs the small corrections that only appear under real traffic, the fixes for the edge cases nobody found in staging, and the ongoing capacity to change what the measurement shows is wrong. Budget for a period after launch — a few weeks at least — where someone is actively watching and adjusting. A redesign delivered, invoiced and abandoned on launch day is a redesign whose problems become permanent, because the moment when everyone understood the new build is also the moment everyone moves on. The same applies to the team afterwards. If the new storefront needs a developer for changes your team used to make themselves, you have improved the design and worsened the operation. Agree what remains editable before the build, not after. > **Keep the old theme** > > Do not delete the previous theme when the new one goes live. Keep it published-but-unpublished for at least a quarter. If something turns out to be badly wrong, having a working store one click away is worth considerably more than the storage it occupies. ## Judge it on the right timescale Redesign results are argued about more than almost anything else in ecommerce, largely because they get judged too early. **The first fortnight measures disruption.** Rankings wobble after structural change, returning customers are briefly disoriented, and analytics may be partially broken while tracking is verified. **Conversion needs several weeks** of reasonably stable traffic before it can be read reliably at all. **Organic traffic needs months** to settle, and a dip in the first month is common even when everything was done correctly. Agree the evaluation window before launch, and agree what would count as success. A redesign with no stated success criterion will be declared a success or a failure according to whoever is most confident, and that argument is entirely avoidable. Write the criterion down somewhere both parties can see it. "Mobile product page conversion improves, measured over six weeks against the same period last year" is checkable. "The store performs better" is not, and the difference matters most when the numbers are ambiguous — which they usually are. > **Beware removing things nobody documented** > > Old storefronts accumulate elements that solve problems nobody wrote down — a reassurance line that reduced support contacts, an unglamorous module that drove a segment of sales. Redesigns remove these because they look untidy. Before deleting anything that has been there a long time, ask why it exists, and treat "nobody remembers" as a reason to investigate rather than to remove. For the theme-versus-custom decision this often prompts, see [storefront and design](/category/storefront-design). The SEO risks are covered in [SEO and AI search](/category/seo-ai-search), and migration specifics in the storefront archive. **A redesign that fixes what is measurably wrong** ByteInfy audits and rebuilds Shopify storefronts — diagnosis first, structure protected, and staged so you can tell what worked. [Start a project](https://byteinfy.com/#contact) ## FAQ ### How do I know if my Shopify store needs a redesign? Look at the funnel by device before looking at the design. If people arrive and leave from one specific step, that step is the problem and fixing it is far cheaper than a redesign. ### Will a redesign improve my conversion rate? Sometimes, and not reliably. A redesign that fixes specific diagnosed problems usually helps. ### Does redesigning a Shopify store hurt SEO? It can, and the risks are predictable and preventable. Changed URLs, lost structured data, broken heading hierarchy and rebuilt internal linking are the usual causes. ### Should I redesign everything at once or in stages? Stages, where you can. A staged approach lets you attribute results and reverse what did not work. ### How long before a redesign shows results? Traffic and rankings need months to settle after any structural change, and conversion needs weeks of stable traffic to read. --- --- title: "Shopify POS in 2026: A Complete Guide for Retailers" description: "Shopify POS stopped being an add-on to an online store some time ago. In 2026 it runs multi-entity businesses, mixed fulfilment and in-store-only discounting from the same catalogue as your storefront." author: "Aashish Kaushik" published: 2026-10-23T05:00:11.008Z updated: 2026-10-23T05:00:11.017Z url: https://blog.byteinfy.com/shopify-pos-guide-2026 --- # Shopify POS in 2026: A Complete Guide for Retailers ## Key takeaways - Shopify POS in 2026 shares one catalogue, one customer record and one inventory pool with your online store — the unification is the product, not a feature of it. - The 2026 releases concentrated on transaction speed, mixed fulfilment across online and in-store, and running multiple legal entities from a single store. - Returns, exchanges and new sales can now be processed in one cart, which removes the most common source of till queues and reconciliation errors. - POS Pro is priced per location, so the real cost question is how many locations you run, not how many staff use it. Shopify POS is easy to misunderstand as a till app that happens to connect to a Shopify store. That description was fair years ago. It is not a useful way to evaluate it in 2026, and evaluating it that way leads retailers to compare it against dedicated POS systems on features that are no longer the point. The proposition now is that retail and online are one system. One catalogue, one customer record, one inventory pool, one set of reports. Everything Shopify has shipped for retail recently follows from that, and the honest assessment of whether POS fits your business depends more on how much you value that unification than on any individual feature. > **Who this is for** > > Retailers evaluating Shopify POS, and existing Shopify merchants considering physical retail. Written platform-neutral where it can be — the limitations section is as detailed as the capabilities one. ## What unification actually buys you The practical difference between a unified system and an integrated one shows up in the situations that go wrong. A customer buys online, comes into the store to return, and wants to exchange for a different size that the store does not have but the warehouse does. On two integrated systems this is three transactions, a manual lookup and a reconciliation entry. On a unified system it is one interaction against one customer record, and the inventory moves correctly without anyone deciding which system is authoritative. Multiply that by every edge case a real shop encounters — gift receipts, partial returns, staff discounts, stock transfers, a customer who exists in one system and not the other — and the difference stops being about convenience and starts being about how much of your week is spent reconciling. That is the thing being sold. Whether it is worth it depends on how much cross-channel activity you actually have. A pure single-location shop with no online presence gets comparatively little from it and should evaluate POS on its merits as a till system, where dedicated retail platforms remain competitive. ## What changed in the 2026 releases Several substantial retail changes landed through 2026, and they cluster around throughput and multi-entity operation rather than new selling surfaces. ## 2026 Shopify retail changes and who they matter to | Change | What it does | Matters most to | | --- | --- | --- | | Rebuilt checkout | Cuts over a minute from transactions involving new customers, added products and cart processing | High-volume stores, queue-limited counters | | Mixed fulfilment | One order combining ship-to-home and in-store pickup items | Stores with a catalogue larger than their floor stock | | Multiple legal entities | Several entities operated from one store rather than one instance each | Groups running retail and online under different companies | | Returns and exchanges in one cart | Refund, exchange and new sale handled as a single workflow | Any store with meaningful return volume | | Built-in cash ledger | Tracking, reconciliation and reason codes handled on the device | Cash-heavy retail, multi-staff tills | | Market-based and in-store-only discounts | Localised and channel-specific promotions rather than one global price | Multi-region retailers, stores protecting online margin | Two of these are worth dwelling on because they resolve long-standing structural annoyances rather than adding features. **Multiple legal entities from one store** removes a genuinely painful workaround. Businesses that operated retail and online under different companies previously ran separate Shopify instances, which meant separate catalogues, separate customer records and manual reconciliation between them — the exact problems the platform otherwise exists to solve. **Returns and exchanges in one cart** sounds minor and is not. The old pattern — refund as one transaction, new sale as another — is the most common source of both till queues and reconciliation errors, because the two halves can succeed and fail independently. ## The cost question is locations, not users POS pricing confuses people because it does not work the way software pricing usually works. POS Lite is included with every Shopify plan. POS Pro is charged **per location**, not per user or per device. That means a single shop with six staff and four devices pays for one location, while a business with four small outlets pays four times regardless of how quiet they are. The practical consequence is that the calculation is entirely about your footprint. Adding staff is free. Adding tills within a location is free. Adding a location is not. Businesses with many small sites — kiosks, concessions, seasonal pop-ups — should model this carefully, because it is where Shopify POS is least price-competitive against systems that charge per terminal or on a flat rate. ## Before committing, verify these for your region - Payment processing — which processors are supported where you operate, and at what rate - Hardware availability — card readers and terminals are not equally available in every market - Tax handling for your jurisdiction, including any local invoicing or fiscal-receipt requirements - Whether POS Pro features you are relying on are available on your plan and in your region - Offline behaviour — what the system does when connectivity drops mid-transaction That last item is the one most often skipped in evaluation and most often discovered on a bad day. ## Hardware, and why it decides more than the software does Software evaluation gets the attention; hardware decides the daily experience. A counter that works is a specific arrangement of devices that talk to each other reliably, and the constraint is what is actually purchasable and supported where you trade. The baseline is a card reader and something to run the app on. Beyond that, a working counter usually wants a receipt printer, a cash drawer that the printer can trigger, and a barcode scanner — because keying SKUs by hand is the single largest drag on throughput in any shop with more than a few hundred products. Shopify has continued widening the supported range, including handheld terminals that scan barcodes and take payments on the floor while doubling as a full terminal when docked. That format matters more than it sounds for two specific cases: pop-ups and markets, where there is no counter at all, and warehouse or stockroom fulfilment, where the person picking is not the person at the till. The questions worth answering before buying anything: - Is the hardware sold in your market, and by whom? Availability is regional and changes. A device widely used in the US may have no supported path in India. - Which devices does your payment path actually support? Card readers are tied to processing arrangements, and this is where regional differences bite hardest. - What happens when a device fails mid-trade? Every counter needs a fallback that does not involve closing the till. - How do devices pair and re-pair? Bluetooth pairing that drops during a Saturday rush is a real and common failure. Buy one complete counter before buying five. The configuration that works is discovered, not specified. ## Staff, permissions and the part that gets skipped The feature most underweighted in POS evaluations is staff management, and it is a substantial part of what separates Pro from Lite. In a shop with employees, you need to know who processed a refund, who applied a discount and who opened the drawer. You need staff to be able to do their job without being able to do everything — a part-time weekend assistant should not have the same capabilities as a manager. And when someone leaves, revoking access needs to be one action, not a password everyone knew. Shopify POS Pro covers this with staff roles and permissions, per-staff attribution on transactions, and manager approval flows for sensitive actions such as discounts above a threshold. None of it is exotic; all of it is the difference between a system you can run a team on and a till app. The operational point is that these settings need deciding before launch, not after an incident. Decide which actions require approval, what discount authority each role has, and how a new starter is onboarded — then configure it once. Retrofitting permissions onto a store where everyone has been using a shared manager login is considerably harder than setting them up correctly on day one. ## Where Shopify POS is genuinely weaker An honest evaluation needs this section, and most POS guides do not have one. **Deep vertical requirements.** Retail sectors with specialised needs — pharmacy dispensing, serialised or regulated goods, complex rentals, service booking with resource scheduling — are generally better served by a system built for that vertical. Shopify POS is broad rather than deep. **Regional maturity varies widely.** The experience in markets where Shopify Payments supports first-party hardware is substantially better than in markets where it does not. Guides written from a US perspective routinely describe a setup that is not straightforwardly available elsewhere, and India is one of the markets where the gap is real. **Complex wholesale or B2B alongside retail.** Possible, but it pulls in Shopify's B2B features and the combination gets intricate. Worth prototyping before committing. **Offline resilience.** There is offline capability, but a store with unreliable connectivity should test it under realistic conditions rather than trusting the feature list. ## How to evaluate it for your business A sequence that produces a defensible answer: 1. Count your locations and model the Pro cost. This is the number that decides most evaluations and it takes ten minutes. 2. Write down your five most common awkward transactions — the returns, exchanges and cross-channel cases your staff currently handle manually. Test each one in a trial. 3. Verify payments and hardware in your actual market, not from documentation written for another one. 4. Check the reporting you need exists, particularly if you currently rely on a specific retail report from another system. 5. Run one location on it before migrating all of them. The unification benefit is real but it changes daily workflow, and staff adoption is a genuine risk. For the inventory side of running retail and online together, see [POS and operations](/category/pos-operations). Stores selling in India will find the tax and invoicing specifics in the same archive, and the wider [Shopify apps](/category/shopify-apps) archive covers the retail app categories that fill the gaps above. **Running retail and online and tired of reconciling them?** ByteInfy builds and integrates Shopify systems end to end — inventory, operations and the custom pieces the platform does not cover. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What is the difference between Shopify POS Lite and POS Pro? POS Lite is included with every Shopify plan and covers basic in-person selling. ### Does Shopify POS work in India? Shopify POS is usable in India, but hardware availability and payment processing differ substantially from the US and UK, where Shopify Payments supports its own card readers directly. ### Does Shopify POS sync inventory with my online store automatically? Yes — that is the central design decision. Retail and online draw on the same inventory records, so a sale in store decrements the same stock your storefront sells from. ### Can I run more than one business from one Shopify store? As of the 2026 releases, yes. ### What hardware do I actually need to start? At minimum, a card reader and a device to run the app. A full counter setup adds a receipt printer, cash drawer and barcode scanner. --- --- title: "How Many Shopify Apps Is Too Many" description: "Apps differ by orders of magnitude in weight, so counting them tells you almost nothing. Measuring what they load tells you everything." author: "Aashish Kaushik" published: 2026-10-22T13:00:16.653Z updated: 2026-10-22T13:00:16.674Z url: https://blog.byteinfy.com/how-many-shopify-apps-is-too-many --- # How Many Shopify Apps Is Too Many ## Key takeaways - App count is a poor proxy for cost, because one badly-built app can outweigh ten well-built ones. - The measure that matters is what your storefront actually requests, which DevTools shows in about ten minutes. - Uninstalled apps frequently leave code behind, so stores carry weight from tools they stopped paying for. - Apps loading globally to support a feature used on a few templates are the most common and most fixable waste. The question gets asked as though there is a number, and there is not. Apps differ by orders of magnitude in what they cost you, so counting them measures the wrong thing entirely. A store with twenty well-built apps using theme app extensions and loading only where needed can be faster than a store with five that inject scripts globally. The count is identical to a merchant and meaningless to a browser. > **The question that replaces it** > > Not "how many apps do I have" but "what does my storefront actually request, and is each of those things earning its cost". ## Find out in ten minutes This is not a project. It is a browser tab. Open a product page in Chrome. Open DevTools, go to the Network tab, disable cache, and reload. Filter to JS and sort by transfer size. You now have a ranked list of every script the page loads and what each costs. Repeat on your homepage and your cart, because they differ. What you are looking for: **Third parties you do not recognise.** Almost always apps, and sometimes apps you no longer use. **Scripts on pages where their feature does not appear.** A review widget on your blog. A popup tool at checkout. This is the most common finding and the most fixable. **Duplicate functionality.** Two analytics tools, two review systems, or two separate things doing popups. **Anything surprisingly large.** A single script over a few hundred kilobytes should have a justification. That list is your audit. Everything else is acting on it. ## Reading what the Network tab actually shows you The list DevTools produces is not self-explanatory the first time you look at it, so it helps to know what a typical row means before deciding what to do about it. Each row shows a filename, usually hosted on a domain that is not yours, for example something ending in a vendor's own domain rather than your store's. The Size column shown by default is the compressed transfer size, which is the number that matters for load time. A script showing 40 KB transferred but 200 KB uncompressed is still costing you the 40 KB on every visit; the larger figure only matters if you are curious how much work the browser does after downloading it. The Time column tells you how long that request took to complete, and Waterfall, the small chart on the right of each row, shows when it started relative to the rest of the page. A script that starts loading only after everything else has finished is deferred, and it is doing less damage than one competing for bandwidth in the first second, even if its file size is identical. Click a row and the Initiator column, visible in the request details, tells you what caused the script to load: often another script, which means one app pulled in a second one you never installed directly, such as an analytics library bundled inside a review app. This is worth tracing, because removing the app you can see does not remove the second script if something else on the page still calls for it. A practical way to work through the list: sort by size, take the top five, and for each one ask what feature it is meant to support and whether that feature actually appears anywhere on the specific page you are looking at. A 150 KB script supporting a feature visible nowhere on this product page is the clearest kind of finding this exercise produces, and it is usually the first thing worth investigating rather than removing outright, since the same script may be doing real work on a different template. ## The three categories of waste Almost all app-related weight falls into one of these. **Apps you no longer use.** Trialled, forgotten, still installed and still loading. Nearly every store has some. Compare your billing against what is actually live on the storefront — the two lists rarely match. **Apps loading globally for a local feature.** The app supports something on product pages and loads on all eight hundred URLs. Some apps let you scope this; many do not, and that constraint should factor into whether you keep them. **Residue from uninstalled apps.** The one merchants never check. Apps that wrote snippets into theme files rather than using theme app extensions frequently leave that code behind. It keeps loading, does nothing, and costs weight indefinitely. ## The audit, in order - List what you pay for, from your Shopify billing - List what is actually live and visibly working on the storefront - Compare the two — the gap is your first cut - Open DevTools on a product page and identify every third party - Search your theme files for references to apps you have removed - Note anything you cannot identify, and find out before deleting it That final item matters. Removing a script you cannot identify is how a store loses its conversion tracking three days before a campaign. ## Weight is not the only cost Worth naming the others, because they influence which apps to remove first. **Conflict.** Two apps touching the cart will eventually disagree. Two doing popups will show a customer two popups. Overlapping apps are a source of bugs nobody attributes correctly, because each vendor points at the other. **Dependency.** Every app is something that can break, change its pricing, or be discontinued. An app doing something central to how you sell is a business dependency. **Cognitive load.** A store with thirty apps is a store nobody fully understands. When something breaks, the diagnosis is longer, and the person who knew why an app was installed has usually left. **Subscription creep.** Individually small, collectively significant, and almost never reviewed once set up. ## What good looks like Rather than a target count, a set of properties: ## Characteristics of a healthy app stack | Property | Why it matters | | --- | --- | | Every app maps to something you can point at | Anything else is unexamined cost | | Nothing loads on templates it does not serve | Weight paid for nothing | | No two apps do the same job | Removes conflicts and duplicate cost | | Storefront apps use theme app extensions | Clean uninstall, no theme injection | | Someone can explain why each is installed | Institutional memory, not archaeology | | Reviewed at least annually | Stops accumulation becoming permanent | A store meeting those can carry a lot of apps comfortably. A store failing them is in trouble at any number. ## When custom work replaces apps There is a threshold, and it is worth knowing rather than reaching accidentally. Custom development starts to make sense when several conditions coincide: you are paying for three or four apps to produce one outcome, those apps conflict with each other, the function is genuinely specific to how you sell, or the combined monthly cost has grown to where a build pays back within a year or two. The trigger most merchants notice first is conflict rather than cost. When two apps fight over the cart and both vendors point elsewhere, replacing both with one piece of logic that does exactly what you need stops feeling expensive. Below that threshold, apps are the cheaper answer and building is over-engineering. ## What to remove first Once you have the list, the order matters — some removals are free and some carry risk. **Start with what is not running anything.** Apps you pay for whose feature is nowhere on the storefront. Zero risk, immediate saving, and it is usually the largest single category. **Then the residue.** Theme code from apps already uninstalled. Nothing depends on it because the app is gone. The only care needed is confirming the snippet genuinely belongs to a removed app before deleting it. **Then duplicates.** Where two apps do the same job, pick one and remove the other properly. Do not leave both installed while you compare — that comparison never concludes and you pay twice indefinitely. **Then the heavy ones you can live without.** This is where judgement enters, because you are trading a feature for speed. Remove one, measure conversion and page speed for a fortnight, and decide on evidence rather than instinct. **Last, the load-bearing ones.** Apps central to how you sell should be replaced rather than removed, and only when you have something ready to take over. The sequencing matters because the first two categories are free wins that build confidence, and they frequently recover enough weight that the harder decisions become unnecessary. > **Remove one thing at a time** > > The temptation after an audit is to clear out six apps in an afternoon. Then conversion moves and you cannot tell which removal caused it. Space them out, note the dates, and you keep the ability to reverse the one that mattered. ## Make it a habit, not a project The reason this recurs is that app stacks accumulate. Every campaign adds one, every trial leaves residue, and nobody removes anything because removal has a small risk and inaction has none. Two practices prevent it: **Audit annually**, in a quiet trading period. An hour with DevTools open and your billing page beside it is the whole exercise. **Note the date when you install something**, and what you expect it to do. Then you can evaluate it later against something other than vague recollection. A short shared document is enough for both. One line per app: what it does, when it was installed, who asked for it, and what it was supposed to achieve. That record is worth more than it sounds, because the most common reason an app survives an audit is that nobody can remember why it is there and nobody wants to be the person who removed something important. ## The cost nobody counts Beyond weight and subscriptions, an app stack has an operational cost that only becomes visible when something goes wrong. When a store breaks — a discount not applying, a page rendering incorrectly, checkout behaving oddly — the diagnosis begins by working out which of your installed apps could be responsible. With five apps that is quick. With thirty it is an afternoon, and it is an afternoon during an incident. The same applies to platform changes. Every Shopify release is a set of things that might interact with what you have installed, and a larger stack means a larger surface for that. Merchants with many apps discover platform changes through breakage rather than through release notes. None of this argues for a minimal stack as a virtue in itself. It argues for every app being deliberate, because the ones that are not deliberate are the ones that make the incidents longer. > **Do not audit before a peak period** > > This work belongs in a quiet month. Removing something load-bearing days before a high-traffic window creates exactly the risk you are trying to eliminate, and there is no time to observe the consequences. Do it in October, not November. For app selection within specific categories, see [Shopify apps](/category/shopify-apps). The performance side is covered in [storefront and design](/category/storefront-design), and the build-versus-buy question in [Shopify development](/category/shopify-development). **Carrying more apps than you can account for?** ByteInfy audits Shopify app stacks and replaces the overlapping ones with logic you own — lighter, cheaper and without the conflicts. [Start a project](https://byteinfy.com/#contact) ## FAQ ### How many apps is too many for a Shopify store? There is no useful number, because apps vary enormously. A store with twenty lightweight, well-built apps can be faster than one with five heavy ones. ### Do Shopify apps slow down my store? Some do, substantially, and some are close to free. The ones that hurt inject JavaScript on every page regardless of whether their feature appears there. ### Does uninstalling an app remove its code? Not always. Apps that write into theme files rather than using theme app extensions frequently leave snippets behind, which keep loading after uninstall. ### How do I audit my Shopify apps? Compare what you pay for against what is live on the storefront, then open DevTools on a product page and see what third parties actually load. ### Should I replace several apps with custom code? Sometimes. When four apps are combining to produce one outcome, conflicting with each other, or costing more monthly than a build would amortise over a year or two, custom work starts to make sense. --- --- title: "Adding Video to Shopify Without Wrecking Page Speed" description: "Most video projects that fail did not fail because the video was bad. They failed because the pages carrying it got slower and nobody connected the two." author: "Aashish Kaushik" published: 2026-10-22T05:00:12.449Z updated: 2026-10-22T05:00:12.455Z url: https://blog.byteinfy.com/video-page-speed-shopify --- # Adding Video to Shopify Without Wrecking Page Speed ## Key takeaways - Nothing video-related should download before a shopper indicates interest — that single rule covers most of the problem. - A poster image with explicit width and height prevents the layout shift that costs you a Core Web Vital. - Video apps frequently load their runtime on pages with no video at all, which is weight paid for nothing. - Measure before and after on a real phone, because a video test that also slowed the page has told you nothing. Video programmes fail in a specific and repeatable way. A store adds video to its product pages, conversion does not move, and the conclusion is that video does not work for this catalogue. Frequently the real cause is that the product pages got slower, and the loss from that cancelled the gain from the video exactly. Nobody measured the second thing, so nobody attributed it. > **The one rule** > > Nothing video-related downloads before a shopper indicates interest. Almost everything below follows from that. ## Why video is the expensive asset A product image is measured in tens of kilobytes. A video is measured in megabytes, and it arrives alongside a player, which is itself JavaScript. Three costs, all landing on templates that convert: **Transfer.** The video file itself, if it happens to load eagerly. **Main thread work.** The player initialising, competing with everything else the page needs to do to become interactive. **Layout instability**, if the space is not reserved before the video arrives. The third is the one merchants miss, and it maps directly to a Core Web Vital. ## Load nothing until they press play The implementation that makes video affordable. **Render a poster image**, sized appropriately, with explicit width and height attributes matching the video's aspect ratio. The browser now knows how much space to hold, so nothing shifts. **Fetch the player and the file on interaction.** When the shopper clicks or taps, not before. This is the single largest saving available, because the substantial majority of visitors never press play. **Do not preload the file.** A `preload` value that fetches the whole video ahead of time defeats the entire purpose of the poster image. **Load nothing on pages with no video.** Obvious, and routinely violated by apps that inject their runtime globally. That last point deserves scrutiny during app evaluation, because it is where the cost hides. An app supporting video on forty products but loading its script on all eight hundred is charging you on pages that gain nothing. ## Verify each of these on a product page - Poster image has explicit width and height attributes - Nothing over a few kilobytes loads before interaction - The player library is not present in the initial page payload - A product page with no video assigned loads no video code at all - Layout does not shift when the video appears - Autoplay, if used, is muted and limited to one element ## A common failure: the poster image that still shifts Merchants frequently add width and height attributes exactly as instructed and still see layout shift, which is confusing because the fix described above appears to have been followed correctly. The usual cause is a mismatch between what those attributes declare and what the responsive layout actually renders. Width and height attributes tell the browser the image's intrinsic aspect ratio, which it uses to reserve space before the file loads, but that reservation only holds if the container the image sits in respects that ratio too. A common setup declares a poster image at, say, 1200 by 800 pixels, then places it inside a responsive container styled with a CSS width of 100% and no matching height rule. The browser reserves space based on the declared ratio, then the actual rendered container resizes to fill the available width, and if any surrounding CSS overrides or ignores that calculated height, the box still jumps once the real dimensions are computed at render time. The fix is to make sure the aspect ratio is enforced in CSS as well as in the HTML attributes, using the `aspect-ratio` property on the container, set to match the poster image and video exactly, rather than relying on the width and height attributes alone to do the work across every screen size the page might render at. This matters more on Shopify than on a fixed layout, because theme sections resize continuously across breakpoints, and an aspect ratio that holds at desktop width can silently stop holding at a tablet breakpoint if the CSS was only tested at one size. The second common cause is a poster image whose actual aspect ratio does not match the video's. If the poster is a square crop of a widescreen video, the browser reserves space for the poster's shape, then the player swaps in at the video's real aspect ratio once it initialises, producing exactly the shift the poster image was meant to prevent. Checking that the poster asset and the video file share the same declared ratio, and testing at more than one breakpoint before calling the fix complete, catches both causes before they reach real traffic. ## Autoplay is usually a bad trade The instinct is that autoplay increases views. It does, and it does so by making every visitor pay for the video whether or not they wanted it. The arithmetic rarely works on a product page. A minority watch; everyone bears the transfer and processing cost, on a template you need to load quickly. Where autoplay is defensible: a short, muted, heavily compressed clip as a hero element on a landing page built around it. Even then, one element per page, and measure it. ## Hosting: your files or theirs Two routes, with a real trade-off. **Shopify's file hosting** works and is simple. It serves one file to every visitor regardless of connection, with no adaptive bitrate, so a shopper on a poor connection gets the same file as one on fibre and waits. **A video app's CDN** generally offers adaptive delivery, serving an appropriate quality for the connection. Better performance, and your library now lives somewhere you do not control. The consequences of the second are worth naming: if the subscription lapses, video may stop rendering across your product pages. If you migrate, you may be able to export only the transcoded versions rather than your originals. Neither is a reason to avoid hosted video — self-hosting's lack of adaptive delivery is a genuine limitation. It is a reason to **keep unedited master files in your own storage**, which costs nothing and removes the worst outcome. ## Formats and compression Less consequential than loading behaviour, but worth getting right once. **Compress properly.** Product clips do not need broadcast quality. A well-compressed file at a sensible resolution is visually indistinguishable on a phone and a fraction of the size. **Match resolution to display size.** Serving a 4K file into a component rendered at 400 pixels wide wastes almost all of it. **Keep it short.** Product-page clips trending under 30 seconds is a conversion finding, and it is also a page-weight finding — a third of the duration is roughly a third of the bytes. **Modern codecs where supported**, with a fallback for browsers that lack them. This is meaningful savings for a fairly small amount of one-time setup work. ## Measure it properly or do not bother The step that separates a video test from a guess. Take Core Web Vitals on the affected templates **before** adding anything. Add video to a subset of products, matched against comparable products without it. Then measure both conversion and Core Web Vitals on both groups. If the video group got slower, the test has told you nothing about video — you changed two things and observed their sum. That is the most common reason these tests return a confusing null result, and it is entirely preventable. Measure on a mid-range phone on a throttled connection, not a desktop on office wifi. The gap between those is where most commerce traffic actually lives. > **Watch the whole template, not just the video** > > Adding video sometimes prompts other changes — a bigger gallery, a new section, an app installed to support it. Each adds weight. When you compare, make sure the only difference between your groups is the video itself, or you are measuring a redesign and calling it a video test. ## Diagnosing a page that is already slow If video is already live and the pages feel heavy, the diagnosis takes about ten minutes and does not require guessing. Open a product page in Chrome DevTools, go to the Network tab, and reload with the cache disabled. Then: **Sort by transfer size.** If a video file appears before you have interacted with anything, it is loading eagerly and that is your answer. **Filter to JS and look for the player.** A video player library in the initial payload means the runtime loads regardless of whether anyone watches. **Check a product page with no video assigned.** If video-related requests appear there, the app is loading globally, and you are paying on every template for a feature used on a few. **Look at the Performance panel for long tasks.** Player initialisation competing with page rendering shows up as main-thread blocking, which is what interaction-to-next-paint measures. **Check for layout shift** in the Performance insights. If the page jumps when the video area resolves, the poster image is missing dimensions. Each of those maps to a specific fix above. The reason to do this before changing anything is that video is frequently blamed for slowness caused by something else entirely — a review widget, a chat app, a tag manager — and removing your video to fix a problem another app is causing is an expensive way to learn nothing. > **Compare against a page with no video** > > The clearest diagnostic is two pages from the same template, one with video and one without. Run both, and the difference is precisely what video costs you. Absolute numbers on a single page tell you the page is slow; the comparison tells you why. ## A sensible sequence 1. Baseline Core Web Vitals on your product template. 2. Add video to a small subset, implemented behind a poster image. 3. Re-measure the same metrics on those pages. 4. If speed held, measure conversion against the control over weeks. 5. If speed dropped, fix the implementation before drawing any conclusion about video. 6. Only then extend to more products. Step five is the one that gets skipped, and skipping it is how a store concludes video does not work when what does not work is how the video was added. It is worth saying that the ceiling here is genuinely high. A properly implemented video — poster image, nothing loaded until interaction, no runtime on pages without video — costs a well-built product page almost nothing measurable. The choice is not between video and speed. It is between a careful implementation and a careless one, and the careless version is what most stores get by default because it is what installing an app and enabling everything produces. That also means a store already carrying a slow video implementation usually does not need to remove video. It needs to change how the video loads, which is a smaller and much less painful project than abandoning the format. For placement and format decisions, see [video commerce and UGC](/category/video-commerce-ugc). The wider page-weight picture is covered in [storefront and design](/category/storefront-design), and app selection in [Shopify apps](/category/shopify-apps). **Shoppable video that loads nothing until someone presses play** SwipeReel adds shoppable video to Shopify storefronts — poster-first loading, tap-to-buy inside the player, and no runtime on pages without video. [See SwipeReel on the Shopify App Store](https://apps.shopify.com/swipereel) ## FAQ ### Does adding video to Shopify slow down my store? It does if the video loads with the page. Done properly — a lightweight poster image, with the player and video file fetched only when someone interacts — the cost is small. ### Should product page videos autoplay? Rarely, and never with sound. Autoplay means the video downloads whether or not anyone watches, which is the expensive case. ### How do I stop video causing layout shift? Reserve the space before the video loads. A poster image with explicit width and height attributes, matching the video's aspect ratio, gives the browser what it needs to hold the box. ### Should I host video on Shopify or use an app? Shopify's own file hosting works for simple cases but has no adaptive bitrate, so one file serves every connection. Video apps generally use a CDN with adaptive delivery, which performs better. ### How do I know whether video hurt my conversion rate? Measure Core Web Vitals alongside conversion, on both the video and control groups. If the video group got slower, you ran two experiments simultaneously and cannot separate them. --- --- title: "Shopify Checkout Components: What Plus Merchants Get" description: "Composing checkout with drag-and-drop blocks moves a category of work out of the development queue. It also moves the risk somewhere nobody was watching." author: "Aashish Kaushik" published: 2026-10-21T13:00:21.171Z updated: 2026-10-21T13:00:21.175Z url: https://blog.byteinfy.com/shopify-checkout-components --- # Shopify Checkout Components: What Plus Merchants Get ## Key takeaways - Checkout Components reached general availability for Plus merchants in 2026, allowing the post-cart flow to be composed with blocks. - It moves layout and arrangement out of development while logic stays in Functions and UI extensions. - The governance question is new — several people can now change the page that takes money, with no review step. - Checkout completion rate, not store-wide conversion, is the number that isolates whether a change helped. Checkout has been the least editable part of a Shopify store for years, and deliberately so. Checkout Components changes that for Plus merchants, allowing the post-cart flow to be composed with drag-and-drop blocks rather than code. The benefit is obvious: a category of work leaves the development queue. The consequence is less discussed, and it is that the page which takes money can now be changed by more people, more easily, with no review step in between. > **Where this sits** > > One of three mechanisms. Components compose the flow, UI extensions add interface elements at supported points, and Functions handle discount, delivery and payment logic. They are complementary rather than alternatives. ## What actually became editable Composition and arrangement. The order of steps, which blocks appear where, how information is grouped, what is emphasised. Combined with checkout branding — colours, typography, logo, all configured in the admin — a merchant can now change how checkout looks and how it is organised without a developer. What remains development work: **Logic.** Anything conditional. Discount behaviour, delivery customisation, payment method rules — all Functions. **Custom fields with behaviour.** Adding a field is one thing; validating it, acting on it, or sending it somewhere is another. **Third-party integration.** Anything that has to talk to a system outside of Shopify itself. **Anything the extension points do not support.** The model is deliberately bounded, and a handful of things simply remain outside it by design. The rough division worth remembering: composition is merchant-editable, and behaviour is not. ## The governance problem is new Worth planning for deliberately, because it is the part that catches teams out. Under the old model, checkout customisation was unambiguously a developer task. Nobody edited `checkout.liquid` casually — it was dangerous, but it had a clear owner and changes went through whatever review the team had. Now several people can rearrange the highest-stakes page on the store, and those changes do not pass through a pull request. The failure mode is not dramatic. It is a conversion drop of a few percent that nobody can explain because nobody recorded what changed that week. ## Governance worth agreeing before you start - Decide who may change checkout, using staff permissions rather than convention - Keep a dated note of every significant change — a shared document is enough - Change one thing at a time, so a drop is attributable - Agree a freeze period before any high-traffic trading window - Establish who reverts a change, and how quickly, if completion falls The dated note is the highest-value item and the one most often skipped. The alternative is an investigation that takes longer than the change did. ## Measure checkout completion, not conversion A specific measurement point, because using the wrong number wastes weeks. Store-wide conversion rate moves for a dozen reasons — traffic mix, campaigns, seasonality, a change three pages upstream. It is too noisy to isolate a checkout change. The number that isolates it is **the proportion of sessions reaching checkout that complete**. If that ratio moves after a change, the change is the cause, and you will know within days rather than after a month of arguing about traffic quality. Watch it by device separately. Mobile and desktop checkout behave differently enough that a change helping one can hurt the other, and an aggregate figure hides that entirely. ## A worked example of testing one change properly Take a concrete case: a merchant wants to move the order summary so it stays visible while scrolling on mobile, instead of collapsing into an expandable line at the top. This is exactly the kind of arrangement change Components makes easy to ship in minutes, which is also what makes it easy to ship carelessly. Before touching anything, pull the current checkout completion rate for the period you plan to compare against, split by device, since a mobile-focused change should be judged mainly on mobile sessions. Note the date and the exact baseline number somewhere durable, not just in a dashboard you will look at again later and half-remember. Make the one change. Not the order summary plus a second unrelated tweak someone suggested while you were in there, since a result that moves cannot then be attributed to either change individually. Record the date and description of the change in the same place as the baseline number, following the governance note above. Where Shopify's native A/B testing for checkout is available, run the new arrangement against the existing one concurrently rather than sequentially. A concurrent test controls for the fact that traffic composition, campaigns and even the day of the week all move completion rates on their own, and a before-and-after comparison across time cannot separate the change from everything else happening at the same time. Let it run long enough to cover a full weekly cycle at minimum, since checkout behaviour differs by day, and stop only once the sample size is large enough that the difference is not plausibly noise. If mobile completion rate moves against the concurrent control, you have a result you can trust. If it does not move, that is also useful. It means the change was cosmetic rather than the improvement it looked like on a demo device, and the effort is better spent on the funnel step that Shopify's own analytics show losing the most people, as the tip below points out. ## Additions cost more than they appear to The consistent finding about checkout, and the reason easy editability is a risk. Everything added to checkout competes with completing the purchase. A survey, a newsletter opt-in, a promotional block, an extra optional field — each is individually defensible and collectively they reduce completions. This is not an argument for a bare checkout. Trust signals, clear delivery information and visible returns terms genuinely help. The distinction is whether an element **reduces a doubt** or **asks for something**. ## Elements and their usual effect | Element | Typical effect | | --- | --- | | Clear delivery estimate | Helps — removes a doubt | | Visible returns terms | Helps — removes a doubt | | Recognised payment logos | Helps modestly | | Order summary that stays visible | Helps | | Newsletter opt-in | Costs completions | | Survey or "how did you hear about us" | Costs completions | | Promotional block for another product | Costs completions | | Extra optional fields | Costs completions | Everything in the lower half has a business reason behind it. The question is whether that reason is worth the completions, and the honest answer is usually that the same information can be collected after purchase, when it costs nothing. The attribution survey is the clearest example. Knowing how customers found you is genuinely valuable, and asking at checkout is the worst possible moment to find out. Ask on the thank-you page instead: the order is banked, the shopper is relaxed, and response rates are frequently better because nothing is at stake for them. ## Test the paths, not the appearance Checkout is where a fault costs the whole order, so verification needs to be more thorough than for other pages. - A complete purchase through every accelerated checkout method you have enabled, not just the standard flow. - Every discount combination a real shopper could reach, including codes still circulating. - A failed payment, confirming the recovery path works. - An international address, if you sell across markets. - Guest checkout, not only logged-in. - A mid-range phone on a slow connection, which is where most traffic actually is. > **Freeze before peak** > > Whatever you build, set a date before any high-traffic period after which checkout does not change. A change needs live traffic afterwards to reveal its problems, and one made two days before a sale has no observation window. Easy editability makes this discipline more necessary, not less. ## Where to actually start Given the ability to change checkout, the useful question is what is worth changing. The answer for most stores is narrower than the capability suggests. **Fix what is missing before adding what is new.** Delivery estimates absent from checkout, returns terms not visible, an order summary that collapses on mobile — these are omissions that cost completions, and closing them is more valuable than any arrangement change. **Reduce steps where you can.** Every field a shopper fills is friction, and friction on a phone is expensive. Remove optional fields you do not use. Confirm autofill works on every field. Do not require an account. **Make the total legible early.** The most common checkout exit is the moment shipping appears and the total changes. Nothing in checkout fixes that properly — the fix is showing shipping cost earlier, in the cart or on the product page — but a checkout that presents the total clearly at least avoids compounding the surprise. **Then consider arrangement.** Grouping, emphasis, order of steps. This is where Components are genuinely useful, and it is worth doing after the substantive problems are closed rather than instead of them. The instinct with a new capability is to use it extensively. Checkout rewards the opposite — the best checkout is usually the one that asks least and explains most, and a merchant with drag-and-drop composition can build a worse checkout considerably faster than before. > **Watch where people actually stop** > > Shopify's analytics show the checkout funnel step by step. Before changing anything, look at which step has the largest drop. That step is your project, and it is frequently not the one anyone assumed — teams routinely redesign the information step while the losses are happening at shipping. ## What this signals about the platform Read alongside the other 2026 releases, the direction is consistent. Horizon moved layout composition into the theme editor. Native A/B testing arrived for themes, checkout and customer accounts. Checkout Components moved the post-cart flow into the admin. The pattern is that surfaces which previously required a developer are becoming merchant-configurable, one at a time. For planning, that means budgeting a Shopify build on the assumption that every layout and variation is a development ticket is probably wrong. It also means the skills that matter on a Shopify team are shifting — less Liquid, more design judgement, measurement, and knowing which of the now-configurable things are worth configuring. And it makes the governance point above more general than checkout. When several surfaces become editable by several people, deciding who changes what, and keeping a record, stops being bureaucracy and becomes the thing that makes a conversion drop diagnosable. There is a reasonable objection to all of this, which is that review processes are exactly the friction merchants were trying to escape. That is fair, and the answer is proportionality rather than process for its own sake. A homepage banner needs no approval. The page that takes payment does. Distinguishing between them by surface rather than applying one policy to everything keeps the speed where speed is harmless and the care where a mistake is expensive. For the wider migration picture, see [checkout and payments](/category/checkout-payments). Functions and the development side are covered in [Shopify development](/category/shopify-development), and Horizon in [storefront and design](/category/storefront-design). **Checkout work that does not cost you completions** ByteInfy builds and audits Shopify checkout — Components, UI extensions and Functions, tested through every path before it reaches real orders. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What are Shopify Checkout Components? A way of customising the post-cart flow using drag-and-drop blocks rather than code, generally available to Plus merchants as of the Summer 2026 release. ### Do Checkout Components replace checkout UI extensions? No, they work together. Components handle how the flow is composed and arranged. UI extensions add custom interface elements at supported points. Functions handle discount, delivery and payment logic. ### Can I customise checkout without a developer now? Layout and arrangement, increasingly yes. Anything involving logic, validation, custom fields with behaviour, or third-party integration still needs development. The split is roughly that composition is merchant-editable and behaviour is not. ### Is Checkout Components available on all Shopify plans? It is a Plus feature. ### Will customising checkout hurt my conversion rate? It can, which is why the ability to change it easily is a risk as well as a benefit. --- --- title: "Does a Shopify Blog Still Drive Sales in 2026" description: "Most Shopify blogs fail before the first post, because nobody decided what the blog was for or where its links should point." author: "Aashish Kaushik" published: 2026-10-21T05:00:18.971Z updated: 2026-10-21T05:00:18.975Z url: https://blog.byteinfy.com/shopify-blog-seo --- # Does a Shopify Blog Still Drive Sales in 2026 ## Key takeaways - A store blog earns its place by winning questions your product and collection pages structurally cannot answer. - The most common structural failure is linking to individual products instead of the collection that should rank for the category. - AI answer surfaces reward content that states specific, attributed, dated claims — which is also what makes content useful to readers. - Publishing sporadically produces almost nothing; a small number of maintained pieces beats a large number of abandoned ones. Most Shopify blogs are abandoned. A store publishes eight posts over three months, sees nothing, and stops. The archive sits there, gradually dating itself. That outcome is usually decided before the first post, by two omissions: nobody established what the blog was for, and nobody worked out where its links should point. > **The prior question** > > What can a blog post do that your product and collection pages structurally cannot? If there is no clear answer, the effort belongs on those pages instead. ## What a store blog is actually for Three jobs, and only the first is unique to a blog. **Answering questions that are not about one product.** How to choose between options. How to care for something. What a term means. Whether an approach suits a particular situation. These do not belong on a product page and cannot live on a collection page without cluttering it. **Capturing search demand upstream of purchase.** Someone researching before they know what to buy. Reaching them early is valuable if — and this is the part usually skipped — you can then route them somewhere useful. **Giving you something to say.** Email, social, and the ordinary business of staying in front of people. What a blog is not for: repeating product descriptions at greater length, announcing company news nobody searched for, or publishing because a content calendar demanded something. ## Collection pages come first The mistake that undermines most Shopify blog programmes, and it is structural rather than editorial. Category queries — "waterproof hiking boots", "gifts for new parents" — are won by collection pages, not blog posts. A store with thin collection pages and an active blog is publishing content that competes with its own commercial pages while those pages remain unable to rank. The order that works: make your commercially important collections genuinely good first, then blog around them. Which leads to the linking rule. ## Link to collections, not products A buying guide about walking boots should link to the walking boots **collection**. Linking to one specific product instead is the most common wasted internal link on Shopify stores. The product page was never going to rank for the category query, the collection might, and the link that could have supported it went elsewhere. Mention specific products by all means — that is often what makes a guide useful. But the primary link, the one carrying the anchor text you care about, should point at the page that should rank. ## Content type and its primary link target | Content | Primary link | | --- | --- | | Buying guide or comparison | The collection | | How-to or care guide | The collection, plus the specific product where relevant | | Glossary or definitional | The collection for the category | | Seasonal or gift content | The relevant collections | | Case study or customer story | The product actually used | ## What AI answer surfaces changed Worth being specific, because the topic attracts a lot of vague assertion. Answer surfaces extract claims. A claim that is specific, attributed and dated can be cited; one that gestures at a trend cannot. "Video is becoming increasingly important for ecommerce" is unusable — no figure, no source, no date. "Around 91% of viewers prefer video under two minutes, according to Whatmore's 2026 guide" is citable, because every element a citation needs is present. This does not require a different kind of writing so much as a stricter one, and it happens to be the same discipline that makes content trustworthy to human readers. Structure helps too: a heading that asks the question a person asks, answered directly in the paragraph beneath, extracts far better than the same information buried mid-section. The practical consequence is that thin, hedge-everything content earns less than it used to, and genuinely informative content earns more. ## Fewer posts, maintained The frequency advice most stores follow is wrong for most stores. Publishing forty thin posts in a burst and abandoning them produces an archive that dates itself and earns nothing. A handful of substantial pieces, kept current, compounds. The reason is that content has a maintenance cost nobody budgets for. A guide referencing a platform feature that changed, prices that moved, or a year that has passed is actively worse than no guide — it signals a store that is not paying attention. Before committing to a publishing schedule, ask who will update these in a year, by name. If the honest answer is nobody, write considerably fewer pieces and keep them good. ## Before starting a blog - Name the questions your buyers ask that product pages cannot answer - Confirm your commercially important collections are already good - Decide where posts will link, and make it collections by default - Establish who writes, and who updates in twelve months - Set a realistic cadence you can sustain, not an aspirational one - Decide how you will know whether it is working ## Measuring it honestly Blog traffic is easy to generate and easy to misread. **Assisted conversions matter more than direct ones.** Someone reading a buying guide rarely purchases in that session. If you judge on last-click, blog content will always look worthless. **Watch which posts drive people into collections.** That is the mechanism working. A post with high traffic and no onward journey is entertaining people, not selling to them. **Track search visibility per post**, not aggregate blog traffic. Aggregate numbers hide the fact that two posts are doing everything and thirty are doing nothing. **Give it time.** Content takes months to rank, and competitive queries take longer than that. Judging the programme at six weeks tells you nothing except that six weeks have passed, and it is the most common reason blogs are abandoned just before they would have started working. ## What to write, once you have decided to Assuming the prior questions are answered, the content that reliably earns its place on a store blog is narrower than a general content strategy suggests. **Buying guides for your categories.** The single most valuable type, because it captures the query your collection is competing for and can support that collection with a link. "How to choose X" is the shape. **Comparisons between options you sell.** Two materials, two sizes, two approaches. Genuinely useful, and it pre-empts the return that comes from choosing wrongly. **Care, use and setup guides.** These earn twice — search traffic before purchase, and reduced support contacts after it. They are also the content most likely to be linked to by other people. **Definitional pieces for your category's jargon.** Every industry has terms buyers half-understand. Explaining one clearly is the sort of content answer surfaces cite, and it costs little. **Original data, if you have any.** Anything you know from operating that nobody else can publish — return rates by size, what customers actually ask, how a material performs over time. This is the only category competitors cannot replicate, and it is almost always under-used. What consistently underperforms: general industry trend pieces, listicles about topics unrelated to what you sell, and anything written primarily because a keyword tool suggested it. Traffic from those does not convert and does not build anything. > **Your support inbox is the content plan** > > The questions your team answers repeatedly are questions people are searching for, phrased the way real buyers phrase them. A blog built from that list will outperform one built from a keyword tool, because every piece answers something you have direct evidence someone wanted to know. ## A worked example, from support ticket to published page The advice to mine the support inbox is easy to agree with and vague to act on, so it helps to walk through what that actually looks like for one question. Say the support team fields a recurring question: which of two fabric weights to choose for a jacket sold in both. Step one is confirming this is genuinely recurring rather than a one-off, by pulling the last few months of tickets or chat logs and counting how often some version of the question appears. A question asked twice a year does not justify a page; one asked weekly does. Step two is writing down the actual answer the support team gives, in their own words, before touching a keyword tool or an outline template. This is the part most guides skip, and it is the part that makes the resulting page genuinely useful rather than generic, because the support team's answer already reflects the real doubts customers have, not the doubts a writer imagines they have. Step three is checking whether the answer depends on something specific enough to make the page decay, such as a fabric that gets discontinued or a fit that changes between collections. If the answer is stable, the page has a long useful life. If it depends on the current catalogue, either write it in a way that survives catalogue changes or accept it will need revisiting and assign that to someone by name, as the earlier checklist requires. Step four is the structure itself: a heading phrased the way the customer actually asks it, a direct answer in the first sentences beneath it, then the reasoning and the exceptions. Link the two fabric options to their respective collections, not to individual products, following the linking rule above. Step five, once published, is closing the loop with the support team. Give them the URL to paste into their own replies. This does two things: it reduces their repeat typing immediately, which is a real time saving they will notice, and it puts a genuine, real-world link into an actual conversation, which is a better test of whether the page answers the question than any traffic number for the first few weeks. ## When not to bother An honest boundary, because "start a blog" is advice given far too freely. **When your collections are weak.** Fix those first — they sit closer to the money, and most of the effort transfers directly. **When there are no real questions.** Some categories genuinely do not generate research behaviour. If nobody is searching for how to choose, a buying guide has no audience. **When you cannot sustain it.** An abandoned blog is worse than none, because it visibly dates your store. **When it is being started for its own sake.** "We should have a blog" is not a reason, and it produces the archives that get abandoned. There is a reasonable middle path worth considering before committing to a blog at all. Much of what a store would put in blog posts belongs on the pages that already exist — selection guidance on the collection page, care instructions on the product page, definitions in a glossary section. Content placed there supports the page directly rather than linking to it, and it does not create a separate archive that needs maintaining. Stores frequently discover that half their planned blog posts are actually collection page content in disguise. Working that out first means the effort lands on commercial pages rather than adjacent to them, which is both cheaper and closer to the money. For the structural work on collections that should come first, see [SEO and AI search](/category/seo-ai-search). Product page fundamentals are covered in the same archive, and the AI citation side alongside them. **Content that supports the pages you sell from** ByteInfy does Shopify SEO as one engagement — collection architecture, product data and the content built to support both. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Is blogging still worth it for a Shopify store? It is worth it when there are genuine questions your buyers ask that a product or collection page cannot answer, and when you can sustain publishing and updating. ### How often should a Shopify store publish blog posts? Less often than most advice suggests, and more consistently. A handful of substantial pieces that are kept current will outperform forty thin posts published in a burst and never touched again. ### Should blog posts link to products or collections? Collections, in most cases. ### Does AI search change whether blogging is worthwhile? It changes what kind of content is worth writing. ### Where should a Shopify blog live? On your own domain, so the authority accrues to you. --- --- title: "Shopify Functions for Discounts: What Replaced Scripts" description: "A Function computes the outcome you intended rather than hoping several discounts cooperate. That single property removes most of the failure modes merchants live with." author: "Aashish Kaushik" published: 2026-10-20T13:00:29.159Z updated: 2026-10-20T13:00:29.163Z url: https://blog.byteinfy.com/shopify-functions-discounts --- # Shopify Functions for Discounts: What Replaced Scripts ## Key takeaways - Functions run server-side at checkout, so a discount cannot be visible in the cart and absent at payment. - They hold through accelerated checkouts, unlike anything implemented by manipulating the cart. - Discount Functions are available beyond Plus, which is a meaningful widening compared with the old Scripts boundary. - Build configuration into the Function from the start, or every future threshold change becomes a deployment. Legacy Shopify Scripts stopped running on 30 June 2026. What replaced them is not a like-for-like substitute, and the difference is worth understanding before scoping any custom discount work. Functions are compiled code running server-side at defined extension points. That architecture is what gives them the property merchants care about most: a discount computed by a Function cannot be visible in the cart and missing at checkout, because it is the same computation. > **The one-line summary** > > Native discounts for standard offers. Apps for standard offers plus storefront messaging. Functions when the outcome you want cannot be expressed by either. ## What a Function actually is Code you write, compiled to WebAssembly, deployed through a Shopify app, and executed by Shopify at a specific point — when discounts are calculated, when delivery options are assembled, when payment methods are presented. Practically, three properties matter: **Server-side execution.** The result is computed by Shopify, not by JavaScript in a browser that may or may not run. **Bounded and fast.** Functions run within clearly defined execution limits, which is why they are predictable in a way that Scripts never were. **Deployed, not edited.** There is no admin text box to type into. The code lives in a repository and reaches production through an actual deployment. That last one is the largest workflow change from Scripts, and the one to plan around. ## Why the cart-versus-checkout problem disappears The failure merchants know best: a discount appears in the cart and vanishes at checkout, or a shopper using Shop Pay pays full price. The cause is implementation. Some apps achieve pricing by manipulating the cart — adding line items, rewriting the cart through the storefront, routing through draft orders. Those approaches work in the normal flow and are bypassed when a shopper takes a path that skips the cart, which accelerated checkout buttons do. A Function applies at the platform level. There is no separate cart computation to diverge from, and nothing for a wallet button to skip past. This is the single strongest practical argument for Functions, and it is worth asking any vendor directly: is the discount applied through Functions, or by modifying the cart? The answer separates the category more reliably than any feature comparison, and a vendor who cannot answer it clearly has told you something useful. ## What Functions express well ## Where Functions earn their cost | Requirement | Native | App | Function | | --- | --- | --- | --- | | Simple percentage or buy X get Y | Yes | — | Unnecessary | | Automatic free gift in cart | No | Usually | Yes | | Conditional on customer tag or history | No | Sometimes | Yes | | Multi-rung tiered thresholds | Awkward | Usually | Yes | | Combined outcome of overlapping offers | No | Rarely | Yes | | Hiding or reordering payment methods | No | Sometimes | Yes | | Hiding or renaming delivery rates | No | Sometimes | Yes | | Storefront offer messaging | No | Yes | Needs theme work | The row worth dwelling on is the combined outcome. Shopify's rules about combining same-type discounts mean two product discounts generally will not stack, and merchants spend a lot of effort trying to make several offers cooperate. A Function sidesteps this entirely. Instead of hoping two discounts resolve correctly, you evaluate the cart once and emit the result you intended. There is no combination setting to get wrong because there is one discount. ## What they do not do Being clear prevents a scoping mistake. **They do not render anything.** A Function computes; it does not put a badge on a product page or a progress indicator in the cart. Storefront messaging is theme work or an app, and for threshold offers that messaging is most of the uplift. **They do not give merchants a settings screen.** Not by default. You build that. **They do not see everything.** A Function receives a defined input at a defined moment. Logic depending on data outside that scope needs it supplied, usually through metafields, and that is often the largest part of the work. **They are not free to maintain.** Compiled code in a repository is code that somebody owns, upgrades against platform changes, and debugs when it misbehaves. ## Build for configuration from the start The most common regret after moving discount logic to Functions, and it is entirely avoidable. Under Scripts, a merchant could adjust a threshold themselves in the admin. Under Functions the logic is compiled, so a hardcoded threshold means every pricing tweak is a development ticket. The fix is to separate logic from parameters. Thresholds, qualifying product sets, gift SKUs and date ranges should be read from metafields, exposed in the admin, and editable by whoever runs promotions. ## Configuration worth exposing - Threshold values, per tier - Qualifying products or collections, as a reference rather than hardcoded ids - The gift or reward product - Start and end dates - Whether the offer is currently active, as a simple switch - Any exclusion list Do this and merchants keep the control that mattered while you keep the version history that was missing. Skip it and you have traded one bottleneck for another. ## Validate the inputs A practical point that causes real incidents. Once configuration lives in metafields, someone will eventually enter a value the Function does not expect — a blank threshold, a deleted product reference, a date in the wrong format, a negative number. Decide explicitly what the Function does with nonsense, because the default behaviour is usually to emit no discount, silently. That is the worst failure mode available: no error, no alert, and orders completing at full price while everyone believes an offer is running. ## Instrument it, because failures are silent Following directly from the above. The characteristic Function failure is not a crash. It is a discount that quietly stops applying because a condition was subtly wrong or a metafield changed. Nothing errors. The only signal is margin that looks slightly too good, which nobody investigates. Monitor the proportion of orders receiving each expected discount, and alert when it moves sharply. This costs an afternoon and is the only reliable defence. Every merchant who lost money to the Scripts deprecation lost it because nothing was watching that number. ## Testing a Function before it touches real money Discount logic is the one place where a bug charges the wrong amount to a real customer, so the testing bar is higher than for most code. **Test with historical carts.** Take twenty genuine past orders that your intended offer would have affected and confirm the Function produces the outcome you expect on each. This catches the edge cases a specification written from memory always misses — the order with a gift card, the one with mixed currencies, the fifty-line wholesale basket. **Test the boundaries explicitly.** One unit below the threshold, exactly at it, one above. Off-by-one errors in discount logic are both common and expensive, and they are invisible in casual testing because nobody shops at exactly the boundary by accident. **Test the combinations.** Every other discount that could be simultaneously active, including codes still circulating from campaigns nobody remembers. **Test through every checkout path.** Standard flow, and a completed order through each accelerated method you have enabled. This is the whole reason to use a Function, so verify it rather than assuming. **Test with an empty and an enormous cart.** Functions run within execution limits, and logic comfortable on a five-item cart may not be on a fifty-item one. The carts that break are disproportionately your largest orders, which is the worst possible selection. > **Watch order-level margin for the first fortnight** > > After deploying, the number to watch is not whether the discount applies but what you earned per order. A Function that over-applies looks like healthy revenue and unhealthy margin, and margin is the only place it shows up early enough to matter. ## When to reach for one **Use native** for straightforward offers. It is free, tested, and holds through every checkout path. **Use an app** for standard mechanics that need storefront messaging. You are mostly paying for the badges, the progress indicator and not having to commission a build. **Use a Function** when the outcome cannot be expressed otherwise, when apps are conflicting over the cart, or when the subscriptions for one outcome have grown past the cost of building it once. These are not exclusive. A common and sensible arrangement is a Function computing the discount and an app or theme section handling the storefront messaging, because each is doing what it is good at. What causes trouble is two things both computing pricing — a Function and a cart-manipulating app active simultaneously will eventually disagree, and the disagreement surfaces at checkout on a real order. If you do migrate from an app to a Function, remove the app rather than leaving it disabled. Disabled apps frequently leave theme code behind that continues loading, and an app that can be re-enabled by someone who does not know about the Function is a genuine risk during a busy period. For discount strategy and what each mechanic does to margin, see [promotions and offers](/category/promotions-offers). The Scripts migration specifically, and the wider development picture, are covered in [Shopify development](/category/shopify-development). **Offer logic that behaves at checkout** ByteInfy builds Shopify discount, delivery and payment logic with Functions — configuration exposed in the admin, and monitoring so silent failures do not stay silent. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What are Shopify Functions? Shopify's supported mechanism for customising platform behaviour with your own code — discounts, delivery options, payment methods, cart validation. ### Do I need Shopify Plus to use Functions? Discount Functions are available beyond Plus, which is a genuine widening compared with legacy Scripts, and it is the main reason smaller merchants can now express logic that used to be enterprise-only. ### When should I use a Function instead of an app? When your offer cannot be expressed by native discounts and no app implements it correctly, when several apps are fighting over the cart, or when app subscriptions for one outcome have grown past what a build would cost. ### Why do Functions hold through Shop Pay when apps sometimes do not? Because they apply at the platform level rather than by modifying the cart. ### Can merchants change a Function's settings themselves? Only if you build for it. The logic is compiled and not editable in the admin, so thresholds, product sets and dates should be read from metafields and exposed in the admin. --- --- title: "Shopify Inventory Sync Across Online and Retail" description: "Shared inventory removes the sync problem and replaces it with an allocation problem. That one is a business decision, not a setting." author: "Aashish Kaushik" published: 2026-10-20T05:00:18.646Z updated: 2026-10-20T05:00:18.650Z url: https://blog.byteinfy.com/shopify-inventory-sync --- # Shopify Inventory Sync Across Online and Retail ## Key takeaways - Shopify shares one inventory pool across channels, so the failure mode is not divergence but competition for the same unit. - Which locations may fulfil online orders is a business decision with real consequences for shop floor staff. - Safety buffers stop the floor selling out from under itself, and almost every multi-location retailer needs them. - Bundles, gifts and buy-X-get-Y consume stock in patterns your forecast does not describe. Merchants moving to Shopify POS expect inventory sync to be the hard part and are usually surprised that it is not. Retail and online share one pool — a sale in the shop decrements the same stock the website sells from, with nothing to synchronise. What replaces the sync problem is an allocation problem, and that one is a business decision rather than a setting. Two channels want the same unit. Which gets it? > **The shape of the problem** > > Separate systems diverge and need reconciling. A shared pool cannot diverge, but it can be competed over. The second problem is better and it is not automatically solved. ## Which locations fulfil online orders The first decision, and it has consequences on the shop floor. Enabling a retail location for online fulfilment makes its stock sellable online. That is often desirable — you have inventory, someone wants it, and shipping from the nearest location is faster. It also means someone in the shop picking and packing during trading hours, competing with walk-in customers for both stock and attention. And it means the last unit on the shelf can be sold to someone in another city while a customer is holding it. The options in practice: **Warehouse only.** The simplest arrangement, and it leaves retail stock entirely untouched. It also wastes availability if your shops hold significant inventory. **Warehouse plus selected shops.** The usual compromise. Larger or quieter locations participate; busy flagship stores do not. **Everything enabled, with buffers.** Maximum availability, and it requires the buffer discipline described below to be workable. ## Safety buffers are not optional at retail A buffer is a quantity held back at a location so that channel does not sell out from under the other. Without one, the failure is specific and bad: a customer in your shop is holding the last unit, an online order takes it, and either the online customer is disappointed or the walk-in customer is. Both outcomes are avoidable. The number is a judgement. It should reflect how fast that location sells the item and how quickly you can replenish. Fast-moving items in busy shops need more; slow-moving items in quiet locations need little. ## Allocation setup - Decide which locations are enabled for online fulfilment - Set buffers at any location that also serves walk-in customers - Set buffers higher on fast-moving items and busy locations - Define priority order for fulfilment, not just eligibility - Decide what happens when only a buffered location has stock - Review buffers seasonally, since sell-through rates change The fifth item is the one most people miss. If every unrestricted location is out and only a buffered one has stock, the system needs a rule — hold the order, notify someone, or release the buffer. Deciding it in advance beats discovering it during a busy week. ## Promotions consume stock unpredictably The most common source of unexpected stockouts, and it is worth treating separately because ordinary forecasting does not describe it. **Free gifts** are consumed by demand for qualifying products, which may be most of your catalogue. If the threshold is easy to hit, every large basket is effectively ordering one. **Bundle components** deplete from two directions when the same product is also sold separately, and neither channel's forecast accounts for the other. **Buy X get Y** drains the Y product at a rate governed by demand for X, and Y is frequently the item nobody is watching precisely because it was chosen for being slow. Before any promotion, set alerts on every gift, component and Y product, and decide in advance what the offer does when one runs out — stops applying, substitutes, or oversells. All three are defensible; discovering which one your setup does mid-campaign is not. ## Continue-selling is a per-product decision Allowing sales at zero stock is right for made-to-order items and where inbound stock is reliable. It is wrong for most physical products. The setting is harmless all year and dangerous during any high-volume period, because volume that would normally arrive over weeks arrives in hours. A product that would have oversold by three units across a fortnight oversells by three hundred over a weekend. Review it product by product before any peak rather than as a global setting, and pay particular attention to anything a supplier has recently been slow on — the products where continue-selling feels safest are usually the ones where your own inbound assumptions are most out of date. ## Stock held during an abandoned checkout A pattern that confuses staff more than any other, and it is worth explaining plainly because the confusion produces bad decisions rather than just curiosity. When a shopper reaches checkout, Shopify reserves the items in their cart for a short window so that two customers cannot both be sold the last unit while one of them is still typing their address. That reservation is temporary and releases automatically if the checkout is abandoned, but for the duration it holds, the stock appears unavailable to everyone else, including a shop assistant looking at the same product on a location enabled for retail. The confusion this causes on the shop floor is specific: a staff member sees a product showing zero available, a customer is standing in front of a shelf with three of that product visible, and the staff member concludes the inventory system is wrong. Usually it is not. Several online checkouts may be holding the remaining units temporarily, and the count will correct itself within the reservation window once those checkouts complete or expire. This matters most during high-traffic periods, when the number of concurrent checkouts against a popular item rises sharply and the reservation effect becomes visible rather than a rare edge case. A product with real stock on the shelf can show as unavailable online, or appear unavailable to staff, for the several minutes it takes abandoned reservations to expire, and repeated during a sale this can look like a sync failure when it is the reservation system working as designed. The practical response is not a setting to change but a piece of staff training worth having before it comes up during a busy weekend: if a product shows unavailable but is visibly on the shelf, the likely explanation is a held online reservation rather than a data error, and it is usually worth waiting a few minutes and checking again before escalating it as a fault. Where this happens often enough to disrupt retail service on a specific fast-moving item, that is itself useful information, and it belongs in the buffer conversation above rather than being treated as a bug to be reported each time. ## Transfers and the in-transit gap Moving stock between locations creates a window where units are neither where they were nor where they are going, and how your system represents that window matters. Two failure modes: stock counted at both ends briefly, which oversells; and stock counted at neither, which suppresses sales you could have made. Get the process right rather than the setting. Transfers should be recorded when they leave and received when they arrive, by people who know that is their job. Most transfer problems are process problems wearing a technical costume, and the tell is that they cluster around particular locations or particular people rather than particular products. ## Multi-location changes what "in stock" means With one location, a product is available or it is not. With several, availability becomes a question with a location attached, and that has consequences for what you show shoppers. **On the storefront**, a shopper generally wants to know whether they can have the thing, not where it is. Showing aggregate availability is usually right. Showing per-location stock is useful only when the shopper cares — click-and-collect, or a category where visiting the shop is normal. **For click-and-collect**, per-location accuracy suddenly matters a great deal. A customer who reserves for pickup at a shop that does not actually have the item has had a worse experience than one who was told it was unavailable. This is where buffer discipline and counting accuracy stop being back-office concerns and become customer-facing. **For staff**, visibility across locations is the feature that changes daily work. A customer asking for a size the shop does not have can be told, immediately, that another location has one — and that conversation converts a lost sale surprisingly often. **For fulfilment**, priority order matters as much as eligibility. Shipping from the nearest location is faster and cheaper, but repeatedly drawing from one shop while others sit on stock creates an imbalance that nobody notices until that shop is empty and the others are overstocked. Worth reviewing periodically rather than setting once: fulfilment patterns drift as your traffic and your locations change, and a priority order that made sense at two locations often does not at five. > **Watch fulfilment distribution, not just totals** > > Look at which locations are actually fulfilling online orders over a month. If one is doing most of the work, your rules are concentrating demand somewhere that may not be able to sustain it, and rebalancing before that location empties is much easier than afterwards. ## Drift is a process problem Inventory counts diverge from reality on every retail operation, and it is worth being clear that no software prevents this. The causes are consistent: shrinkage, receiving errors, returns refunded but never restocked, damaged goods removed from the shelf but not the system, and transfers that happened physically before they happened in software. ## Cause of drift and where the fix lives | Cause | Fix | | --- | --- | | Shrinkage | Process and physical controls | | Receiving errors | Check against the purchase order at receipt | | Returns not restocked | A returns process that includes putting stock back | | Damaged goods | A route for writing off, that staff actually use | | Unrecorded transfers | Recording at both ends, as a habit | | Promotional consumption | Alerts on components and gifts | Cycle counting — checking a subset regularly rather than everything annually — catches drift while it is small. Annual stocktakes find a year of accumulated error at once, by which point the cause is unknowable and the only available response is to write it off and start again. A workable cycle count is less onerous than it sounds. Count your fastest-moving and highest-value items monthly, the middle of your catalogue quarterly, and the long tail annually. That concentrates effort where error is both most likely and most expensive, and it turns stocktaking from an annual shutdown into a routine task that takes an hour a week. The by-product is that when a count is wrong, you find out close enough to the cause to actually fix the process that produced it. > **The report is only as good as the process** > > Unified inventory gives you one number instead of two, which is a genuine improvement. It does not make that number true. A store with excellent configuration and careless receiving has accurate-looking data that is wrong, and the confidence makes it worse than obviously messy data would be. For the wider platform picture, see [POS and operations](/category/pos-operations). Promotional mechanics and their inventory consequences are covered in [promotions and offers](/category/promotions-offers), and peak-period planning in the [BFCM 2026](/series/bfcm-2026) series. **Inventory that behaves across channels** ByteInfy builds Shopify integrations for inventory, fulfilment and the operational reporting the admin does not provide. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Does Shopify sync inventory between my store and my POS? They are not synced so much as shared — retail and online draw on the same inventory records, so a sale in the shop decrements the same stock your website sells from. ### How do I stop my online store selling stock that is in my shop? By controlling which locations are enabled for online fulfilment, and by holding a safety buffer at locations that also serve walk-in customers. ### What is a safety buffer and do I need one? It is a quantity held back at a location so the channel using it does not sell out from under the other. ### Why does my inventory count keep drifting from reality? Usually a combination of untracked shrinkage, receiving errors, unrecorded transfers between locations, and returns that were refunded but never put back into stock. The system reflects what it was told. ### How do bundles affect inventory? Bundles and gift offers consume components at a rate driven by demand for other products, not their own. --- --- title: "Best Shopify Page Builder Apps in 2026" description: "A page builder solves a real bottleneck and creates two new ones. Knowing which trade you are making is most of the decision." author: "Aashish Kaushik" published: 2026-10-19T13:00:29.230Z updated: 2026-10-19T13:00:29.237Z url: https://blog.byteinfy.com/best-shopify-page-builder-apps --- # Best Shopify Page Builder Apps in 2026 ## Key takeaways - Page builders trade developer dependency for page weight and lock-in, and both costs arrive later than the benefit. - Horizon's nested block system narrowed the gap considerably — check what your theme does before buying anything. - The exit question is the important one: what happens to your pages if you uninstall, and can you find out before committing. - Measure output page speed on a real device, because builder-generated markup is frequently heavier than hand-built sections. A page builder solves a real and common bottleneck: the marketing team cannot build a landing page without a developer, and the developer queue is three weeks long. It also creates two new problems that arrive later and are harder to reverse — page weight, and dependency on an app that now owns your content. Whether that trade is worth making depends on questions most merchants do not ask until after fifty pages exist. > **Check the theme first** > > Modern Shopify themes do considerably more than they used to, and Horizon's nested block system widened that again. A builder installed to solve something your theme already handles is pure cost. ## What has changed The case for page builders was strongest when themes were rigid. Sections and blocks existed, blocks lived inside sections, and anything more structured was development work. Horizon changed the ceiling. Blocks can nest inside blocks, up to eight levels, which means containers, grids, cards and repeating patterns can be assembled in the editor. A large share of what merchants installed page builders for is now native. That does not eliminate the category. Builders still offer more layout freedom, more prebuilt templates, and a more forgiving editing experience. But the honest comparison is now against a modern theme rather than against a rigid one, and the gap is narrower than the marketing suggests. ## The two costs **Page weight.** A builder generates markup that has to accommodate every layout its editor permits. That generality means more elements, more nesting and more CSS than a section built for one purpose. Most builders also load their own runtime. The consequence shows up on the pages you most want to convert — landing pages you are paying to send traffic to. A builder page that loads a second slower than an equivalent theme page is costing you on exactly the traffic you bought. **Lock-in.** This is the one that surprises people. Content built in a page builder is frequently stored in the app's own structure and rendered by the app. Remove the app and the page may lose its layout or break entirely. A store with two landing pages can rebuild. A store with a hundred cannot, and that store is now paying the subscription indefinitely regardless of whether the app still serves it. ## What you gain and what you accept | Gain | Cost | | --- | --- | | Non-technical team can build pages | Page weight on your highest-value traffic | | No developer queue | Dependency on the app's continued existence | | Prebuilt templates and layouts | Markup you do not control | | Faster iteration on campaigns | Possible heading and structure problems | | Consistent editing experience | Content that may not survive uninstall | ## Answer the exit question first The single most useful thing you can do before installing, and it takes an afternoon. On a development store: install the builder, create one representative page, then uninstall the app and look at what remains. **Plain content left behind** — acceptable. You would need to rebuild the layout, but the words and images survive. **A broken page** — this is lock-in, and you should know that before building a hundred of them. **Nothing at all** — the content lived entirely inside the app and left with it. Proceed only with your eyes fully open to what that means later. Vendors rarely volunteer this, and it is not usually hidden — it simply does not come up, because nobody asks at the point of installing. The question only becomes urgent at the point of leaving, which is exactly when you have the least leverage and the most pages. ## Before committing to a page builder - Confirm your theme cannot already do what you need - Build one page, uninstall, and inspect what survives - Measure page speed against an equivalent theme page, on a phone - Check heading hierarchy in the generated output - Confirm whether it uses theme app extensions or writes into theme files - Check whether pages can be exported in any usable form - Find out what happens to pages if you downgrade to a cheaper tier That last item catches people out. Some builders restrict the number of published pages by tier, which means downgrading can unpublish content you depend on. ## What to do if you are already locked in Most merchants reading this are not deciding whether to install a builder. They already have one, forty pages deep, and the uninstall test above is not hypothetical curiosity, it is a question about a decision already made. Start by finding out what you are actually dealing with. Duplicate one page on a development store, uninstall the builder there, and read the previous section's three outcomes against your real content. This tells you whether you are migrating markup or rebuilding from a blank page, which changes the size of the project by an order of magnitude. If plain content survives, the work is mechanical. Export or copy the surviving text and images, rebuild the layout in theme sections, and move pages in a batch you can finish in a sitting rather than one at a time over months. A partial migration where half your pages sit in the old builder and half in new sections is harder to maintain than either extreme, because your team now has to remember which system a given page lives in. If nothing survives without the app, prioritise by traffic. Pull the last quarter of analytics and rebuild the ten pages carrying the most sessions first. A landing page from a campaign that ended eighteen months ago can wait, or can be deleted outright rather than migrated, since keeping it live only means one more thing to maintain in the new system. Budget for regression. A rebuilt page rarely matches the original pixel for pixel, and stakeholders who approved the original design will notice small differences before they notice the speed improvement. Show them the page speed numbers alongside the visual comparison, because the improvement is the reason for the work and it is easy to lose that framing once the conversation turns to spacing. Set a deadline for cancelling the subscription. An open-ended migration with the old app still installed tends to stall indefinitely, because nothing forces completion. Pick a date, migrate the highest-traffic pages by then, and accept the smaller ones as an acceptable loss if they are not done in time. ## The SEO problems are specific Not inherent, but recurring enough to check every time. **Heading hierarchy.** Builders let you style text freely, which frequently produces pages with three H1s, or a jump from H2 to H4. Each element was authored independently and nobody looked at the resulting document outline. Crawl a finished page and audit the headings. **Page weight**, which affects both search ranking and on-page conversion. **Content rendering.** Anything that depends on the app's runtime to appear is content that may be less reliably parsed. Check the rendered page source, not the visual result. **Duplicate URLs.** Some builders create their own page routes alongside the native Shopify ones. Confirm you have not quietly published two separate URLs serving the same content. ## Where they genuinely earn their place Being fair to the category, because there are real cases. **Marketing landing pages** created and discarded frequently, by people who cannot write Liquid. This is the strongest case and the original one. **Campaign pages under time pressure**, where waiting for a developer means missing the campaign. **Teams with no development capacity at all**, where the alternative is not a custom section but no page. **Rapid testing**, where the whole point is to try six layouts quickly, keep the one that works, and discard the rest without ceremony. Notice what is absent: your core templates. Product pages, collection pages and the homepage are better served by theme sections, because they carry your most valuable traffic and they change rarely enough that development time is affordable. ## What to look at during a trial Trials in this category get spent admiring templates. A trial that produces a decision looks different. **Rebuild one of your existing pages.** Not a demo, not something new — take a page you already have and reproduce it. This tells you whether the builder can express what you actually make, and how long it takes someone on your team. **Time it honestly.** If reproducing a simple page takes two hours, building a catalogue of them is a project rather than a convenience, and the developer queue you were avoiding may have been cheaper. **Look at the generated source.** Not the visual output — the HTML. Count the wrapper divs, check the heading levels, and see whether the content is present in the source or injected afterwards. **Test on your actual theme.** Builders interact with theme CSS, and a builder page that looks correct on a demo theme can inherit unexpected spacing, typography or colour from yours. **Have the person who will actually use it do the trial.** Developers evaluating a tool for non-developers consistently misjudge it in both directions — they find it limiting where a marketer would find it liberating, and easy where a marketer would find it confusing. **Check mobile output specifically.** Builders default to desktop-first layouts more often than themes do, and a page assembled on a laptop can stack badly on a phone without the person building it ever noticing. > **Pricing is usually metered on published pages** > > Most builders limit how many pages you can publish per tier. Work out where your realistic page count puts you before designing a strategy around a free or entry plan, because discovering the ceiling after building thirty pages leaves you with no good options. ## A reasonable position For most stores with any development support, the sensible arrangement is a hybrid. **Theme sections for core templates.** Lighter, cleaner, owned, and they carry the traffic that matters most. **A builder for campaign and landing pages**, where speed of creation genuinely outweighs the weight cost and where the pages are disposable by design. That confines the lock-in to content you were going to discard anyway, and keeps the pages you cannot afford to lose in a format you control. If you do adopt one, agree conventions early — a maximum nesting depth, named reusable patterns rather than ad-hoc assembly, and someone responsible for checking output weight. Builders sprawl exactly as flexible systems always do, and the discipline is what keeps a store maintainable eighteen months later. It is also worth agreeing what happens to pages when a campaign ends. Builder-created landing pages accumulate silently — a page per promotion, per season, per test — and each one is a live URL that may still be linked, indexed and reachable long after the offer expired. Decide up front whether ended campaign pages are deleted and redirected, or kept and updated, and make that someone's job. A store with forty orphaned campaign pages advertising discounts that no longer exist has a problem no builder feature will solve for it. For what modern themes can express, see [storefront and design](/category/storefront-design). App weight and selection generally are covered in [Shopify apps](/category/shopify-apps). **Custom sections instead of a page builder** ByteInfy builds Shopify theme sections and templates — lighter than generated markup, owned by you, and editable by your team without a subscription. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Do I need a page builder for Shopify? Less often than before. Modern themes support extensive section and block configuration, and Horizon's nested block system widened that further — composition that once required development is now editor work. ### Do page builder apps slow down a Shopify store? Frequently, yes. Builders generate generic markup that has to accommodate every layout their editor allows, which is usually heavier than a section built for one purpose. They also load their own runtime. ### What happens to my pages if I uninstall a page builder? This is the question to answer before installing, not after. Some builders leave plain content behind; others leave pages that break entirely, because the layout depended on the app's runtime. ### Are page builders bad for SEO? Not inherently, but there are recurring problems. Generated markup often has weak heading hierarchy, sometimes producing several H1s on a page. Page weight affects rankings and conversion. ### Should a developer-supported store use a page builder? Usually not for the main templates. A team with development capacity is better served by custom sections, which are lighter, cleaner and owned. --- --- title: "Live Shopping on Shopify: Is It Worth It Yet" description: "Live commerce is enormous in parts of Asia and modest in the West. The difference is not technology — it is whether your audience already watches people sell things." author: "Aashish Kaushik" published: 2026-10-19T05:00:21.662Z updated: 2026-10-19T05:00:21.694Z url: https://blog.byteinfy.com/live-shopping-shopify --- # Live Shopping on Shopify: Is It Worth It Yet ## Key takeaways - Live shopping's success varies enormously by market and category, and Western adoption has not followed the Asian trajectory it was predicted to. - The binding constraint is audience, not technology — a live stream with no one watching converts nothing regardless of production quality. - It is closer to running an event than publishing content, with the recurring effort that implies. - Test with a phone and an existing audience before buying anything; the replay is often worth more than the live event. Live shopping has been described as the future of ecommerce for several years, and the evidence remains split in a way that is worth taking seriously rather than explaining away. In China it is a mature, enormous channel. Across parts of Southeast Asia it is substantial. In Western markets it has grown, but nothing resembling the trajectory that was confidently predicted, and the gap has now persisted long enough to be a fact about the market rather than a lag. That does not make it a bad channel. It makes it a channel with specific preconditions, and the useful question is whether your store meets them. > **The honest framing** > > Live shopping is not a technology you adopt. It is an event format you commit to running repeatedly, and the technology is the least difficult part. ## The constraint is audience, not tooling Every conversation about live shopping starts with platforms and features. Almost every failure is about audience. A live stream is a scheduled event. Someone has to know it is happening and choose to be there at that time. If nobody comes, no amount of shoppable overlay converts anything. That makes the precondition uncomfortable but simple: **you need an audience that already pays attention to you**. An engaged email list, an active social following, a community. Live shopping amplifies an existing relationship; it does not create one. Stores with no audience who try live shopping end up streaming to an empty room, conclude the format does not work, and are half right — it does not work for them yet, and the fix is upstream of anything live shopping can provide. ## Where it works best Patterns are consistent enough to be useful. **Categories where seeing matters.** Beauty, fashion, jewellery, collectibles, anything where colour, fit, scale or authenticity is hard to judge from photographs. **Products with genuine questions.** Live is interactive, and the interaction is the point. If viewers have nothing to ask, you are broadcasting rather than hosting. **Limited or time-sensitive stock.** Drops, one-off pieces, sales. Scarcity gives people a reason to attend at a specific time, which is otherwise the hardest thing to justify. **Where a personality carries it.** A founder, a maker, a genuine expert. Live rewards people who are watchable, and no amount of production budget substitutes for that. ## Fit by store type | Your situation | Live shopping fit | | --- | --- | | Engaged following, visual products | Strong | | Limited drops or one-off items | Strong | | Expert-led or personality-led brand | Strong | | Commodity products, price-driven | Weak | | No existing audience | Not yet — build the audience first | | Broad catalogue, no clear focus | Weak — nothing to structure an event around | ## What it actually costs The recurring cost is time, not money, and it is the part that ends most live programmes. A stream needs planning, promotion, someone presenting, someone handling comments, and follow-up afterwards. Done once it is interesting. Done fortnightly for a year it is a job, and a live shopping programme that runs twice and stops has produced almost nothing — the format rewards regularity, because audiences build across events. Before committing, decide who owns it and whether they can sustain it. That question kills more live shopping plans than any technical consideration, and it is far better to answer it honestly before buying software than to discover it after three events and a subscription. ## Test it cheaply first You do not need a studio or a subscription to find out whether this works for you. ## A first live test - Stream on the platform where your audience already is - Use a phone with decent light and a stable connection - Pick ten to fifteen products with real questions attached to them - Promote it properly — email, social, and a reminder on the day - Have someone handling comments who is not the presenter - Record it, and keep the recording - Measure orders during, and orders in the 48 hours after That last measurement matters more than it looks. Most live shopping revenue arrives after the stream, from people who watched the replay or who watched live and bought later. Judging on live-only sales understates the format substantially and is why some merchants abandon it prematurely. ## The replay is often the real asset The most commonly wasted output. Merchants treat the recording as a byproduct. In practice, more people watch afterwards than during, and the footage is a library of you explaining your products in response to real questions — which is exactly what a product page needs. Cut it into clips. Attach each to the product discussed. You now have shoppable video for a dozen products, produced as a side effect of an event you were running anyway. Approached this way, even a live stream with disappointing attendance produces something durable. That reframing makes the first test much easier to justify, because the downside is not a zero return but a set of product videos you would otherwise have had to commission, shot in a format that reads as genuine because it is. ## Running the event itself The practical mechanics separate a stream that converts from one that is merely watched, and most of them are about structure rather than polish. **Have a running order and abandon it when the comments go somewhere better.** Structure prevents dead air; rigidity prevents the interaction that makes live worth doing. The best moments are almost always answers to questions you did not plan for. **Say what the offer is, repeatedly.** Viewers arrive throughout, not at the start. Anyone joining twenty minutes in should learn within a minute what is being shown and how to buy it. **Show the product properly, for longer than feels necessary.** Presenters rush because holding something up feels awkward on camera. Viewers need time to actually look, and this is the entire advantage of the format over photographs. **Answer questions by name.** It is the closest thing to a shop assistant that ecommerce has, and it is why people watch rather than reading a product page. **Do not sell continuously.** A stream that is one pitch after another loses people. The pattern that holds attention is demonstration and conversation with buying moments inside it. **Have someone on comments.** A presenter trying to talk and read simultaneously does both poorly, and questions going unanswered is the fastest way to lose a live audience. ## When the technology fails, and it will eventually The technology being the least difficult part does not mean it never fails, and knowing the common failure modes before a real audience is watching is worth more than any studio upgrade. The most frequent failure is the connection dropping mid-stream, usually on wifi rather than a wired connection, and usually at the worst possible moment because that is when attention is highest and the platform's own retry logic is competing for the same bandwidth as the video upload. The fix is boring and effective: use a wired connection wherever the venue allows it, and if wifi is the only option, close every other device on the network before going live, since a phone updating apps in the next room is a real and common cause of a stream stuttering. The second is audio dropping out or becoming inaudible while video keeps running. Viewers tolerate a shaky picture far better than they tolerate silence or a muffled voice, because the presenter's speech is carrying the actual selling. A cheap clip-on microphone solves most of this and costs less than a single hour of most people's time, which makes it one of the better returns available in this entire format. The third is the app or platform itself glitching, whether that is a shoppable overlay failing to load a product or the stream restarting the viewer count. When this happens, say so out loud rather than trying to fix it silently while the audience wonders what is going on. Viewers forgive an acknowledged technical problem far more readily than an unexplained gap, and naming it buys the time needed to actually resolve it. The general preparation that covers most of this: run a private test stream, alone or with one colleague watching, using the exact setup you plan to use live, at least once before the first real event. This catches the connection issue, the audio issue and any app configuration problem while nobody is watching, which is precisely when you want to discover them. ## Measuring it properly Live shopping generates flattering vanity metrics and unflattering commercial ones, and merchants tend to look at the wrong set. **Viewer count is close to meaningless.** Fifty engaged existing customers routinely outperform a thousand passive viewers, because intent matters more than reach. **Measure a 48-hour window**, not the stream duration. Most revenue arrives afterwards, from replay viewers and from people who watched live and bought later. **Track the replay separately.** If it outperforms the live event, that is a strategic signal — you may be running a video production with an audience rather than an event. **Count what it cost in hours.** The format's viability depends on whether the revenue justifies the recurring time, and time is the input that runs out. > **Reuse the questions, not just the footage** > > The questions viewers ask during a stream are the best product page brief you will ever get. They are the doubts your existing copy has failed to resolve, stated by real buyers. Even a commercially disappointing stream that produces a list of those has paid for itself. ## Where the apps genuinely help Once you have established the format works for you, tooling adds real things. **Shoppable overlays**, so viewers buy without leaving the stream — the same principle that makes shoppable video work. **Multi-platform streaming**, reaching audiences on several different channels simultaneously. **Replay handling**, turning the recording into shoppable content without manual editing. **Comment and question management**, which becomes genuinely difficult once the audience passes even a modest size. None of these solve the audience problem, which is why buying them first is the wrong order. Establish that people will come; then make it easier for them to buy. There is a related decision about where the stream lives. Social platforms bring an existing audience and remove every barrier to attendance, which addresses the hardest problem — but the relationship, and the data, stay with the platform. Streaming on your own site owns both and requires you to bring the audience yourself. Most stores are better served starting where their people already are and moving on-site only once attendance is reliable. > **Do not judge it on one event** > > A first stream is a rehearsal. The presenter is nervous, the format is unfamiliar, and the audience does not yet have a habit. Live commerce compounds across events, so a single disappointing result tells you very little. Commit to three or decide not to start. For the wider video question and formats that need no scheduling, see [video commerce and UGC](/category/video-commerce-ugc). App selection is covered in [Shopify apps](/category/shopify-apps). **Shoppable video without scheduling an event** SwipeReel turns your existing video — including live replays — into shoppable feeds on your storefront, with tap-to-buy inside the player. [See SwipeReel on the Shopify App Store](https://apps.shopify.com/swipereel) ## FAQ ### Does live shopping work outside Asia? Less well, and the gap has persisted longer than most predictions allowed for. Live commerce is a mature, large channel in China and significant across parts of Southeast Asia. ### What do I need to run a live shopping event on Shopify? Less than vendors suggest for a first attempt. A phone, decent light, a stable connection and an audience who knows it is happening. ### How many people do I need watching for it to be worth doing? Fewer than you would expect, if they are the right people. A live event with fifty engaged existing customers can outperform one with a thousand passive viewers, because purchase intent matters more than reach. ### Is the replay worth anything? Frequently more than the live event. Most people who buy from a live stream watch it afterwards, so treating the recording as a disposable artefact wastes most of the value. ### Should I use a dedicated live shopping app or stream to social? Streaming to social platforms reaches an existing audience with no friction, which addresses the hardest problem. A dedicated app gives you shoppable overlays and owns the customer relationship. --- --- title: "Shopify Mobile CRO: Where the Revenue Actually Leaks" description: "A resized desktop browser is not a phone. It has no address bar eating the viewport, no thumb, no slow connection, and no notification arriving mid-checkout." author: "Aashish Kaushik" published: 2026-10-18T13:00:44.528Z updated: 2026-10-18T13:00:44.537Z url: https://blog.byteinfy.com/shopify-mobile-cro --- # Shopify Mobile CRO: Where the Revenue Actually Leaks ## Key takeaways - The buy box pushed below a tall image gallery is the most common and most expensive mobile leak on Shopify product pages. - Testing in a resized desktop browser misses the address bar, the safe area, real touch targets and real network conditions. - Form friction costs more on mobile than anywhere else, and most of it is fixable through input types and autofill attributes. - Page weight hits mobile hardest, so speed work and conversion work are the same project rather than competing ones. Most Shopify traffic is mobile. Most Shopify testing happens on a desktop with the browser window made narrow. Those two facts explain a great deal of unexplained conversion loss, because a resized desktop browser is missing almost everything that makes mobile hard: the address bar consuming viewport height, a thumb rather than a cursor, a real network, and the constant possibility of an interruption arriving mid-purchase. > **The only test that counts** > > A mid-range phone, on mobile data, completing a real purchase. Everything below is diagnosable that way and largely invisible any other way. ## Running the phone test properly The callout above states the test in one line. Actually running it well takes more care than it sounds, because it is easy to do a version of it that still misses the problems it exists to find. Start with the phone itself. Use a genuinely mid-range device, not the newest model on your team's desk, and if nobody has one, borrow one rather than skip the step. Flagship phones are fast enough to hide problems that a typical customer's phone will not. Turn off wifi and switch to mobile data before starting, ideally somewhere with an ordinary signal rather than sitting next to the router. This single step surfaces more real problems than any other part of the exercise, because most internal testing happens over office wifi, which is faster and more consistent than what most shoppers actually have. Begin at the entry point a real customer would use, which is usually a search result, an ad or a social link rather than typing your homepage address directly. This matters because it loads the actual landing template with cold caches, exactly as a first-time visitor experiences it, rather than a page you have already visited today. Complete an actual purchase, not a walkthrough that stops before payment. Enter a real card in test mode or use a genuinely small order, since the payment and confirmation steps are where some of the worst friction lives and a walkthrough that stops at the cart never reaches them. Pay attention to whether you have to zoom, whether any text is genuinely readable at arm's length, and whether you had to fight the keyboard at any point. Do this quarterly at minimum, and always again after any theme, checkout or major app change, because a fix validated once can regress silently when something unrelated changes six months later. Keep a short note of what you found and the date, in the same place you record other storefront changes, so a new problem is easy to notice against a known baseline rather than rediscovered from scratch each time. ## The buy box below the fold The most common and most expensive leak on Shopify product pages. On desktop, the gallery and the buy box sit side by side. Price, variants and add-to-cart are visible while the shopper looks at images. This happens by default and nobody has to design it. On mobile the layout stacks, and a tall gallery pushes the buy box off screen entirely. The shopper arrives, sees a photograph, scrolls, sees another photograph, and has still not met a price. The fixes are unglamorous: **Constrain gallery height on mobile.** The first image does not need to occupy the entire viewport, and on most phones it should not come close. **Show price near the title**, above the gallery if necessary. Price is a primary decision input rather than a detail to be discovered after scrolling. **Consider a sticky add-to-cart** that appears once the shopper scrolls past the buy box. This is one of the more reliably positive mobile changes available. ## Forms are where mobile loses people Typing on a phone is genuinely unpleasant, and checkout is mostly typing. Most of the friction is fixable with attributes rather than redesign. ## Form fixes that pay for themselves - Correct input types, so the numeric keypad appears for numbers - Autocomplete attributes on every field, so autofill works - Address autocomplete where available for your market - Postcode or pincode lookups that populate city and state - Labels that stay visible when the field is focused - Errors shown inline, next to the field, not in a summary at the top - No forced account creation before purchase The keyboard one is worth emphasising because it is a single attribute and it is wrong on a surprising number of stores. A shopper hunting for numbers on an alphabetic keyboard while entering a card is friction you are creating for free. ## Touch targets and thumbs Interfaces designed with a cursor tend to assume precision that thumbs do not have. **Make interactive elements large enough** to hit reliably. Variant swatches and quantity steppers are the usual offenders. **Space them apart.** Two adjacent small buttons produce mis-taps, and a mis-tap during checkout is expensive. **Put primary actions where a thumb reaches.** The lower portion of the screen is comfortable; the top corners are not. **Do not rely on hover.** Anything revealed by hovering does not exist on a touch device, and this catches out features carried over from desktop-first designs — secondary product images, tooltips explaining a variant, and dropdown menus that open on hover are the usual casualties. ## Speed is conversion work on mobile On desktop, over a good connection, a heavy page is slow. On a mid-range phone over mobile data, a heavy page is a page some people never see. That makes performance and conversion the same project rather than competing priorities. The usual culprits are the same as everywhere — app scripts loading globally, render-blocking fonts, oversized images, video loading eagerly — but the consequences are larger. Measure on a throttled connection on a real device. The gap between that and your office wifi is where most of your traffic actually lives, and it is entirely invisible from a developer machine on a fast connection. ## Accelerated checkouts earn their place here Shop Pay, Apple Pay and Google Pay remove the form filling that is most painful on a phone, and on mobile they typically convert better than the standard flow by a meaningful margin. The caution is structural rather than a reason to avoid them. They compress or skip steps, so anything depending on a skipped step does not reach those shoppers: **Discount codes need a field.** If your campaign runs on a code, wallet-button shoppers may have no opportunity to enter it. Automatic discounts apply at the platform level and survive. **Cart-page upsells are skipped**, so an AOV plan resting on them misses this traffic entirely. **Cart-manipulating apps may not run at all**, which is the strongest practical argument for discount logic implemented through Shopify Functions. Test a complete purchase through each accelerated method you have enabled, with your actual offers active. ## The interruption problem Something desktop testing never surfaces: mobile purchases get interrupted. A call arrives, a notification pulls the shopper away, they switch apps, the screen locks. When they come back, the question is whether your store remembered where they were. **Does the cart persist?** It should, across sessions and app switches. **Does a part-filled checkout survive?** Losing entered details to a backgrounded tab is a lost order. **Does the page restore scroll position**, or dump them at the top of a long collection? Test this deliberately: start a checkout, background the browser for five minutes, open something else, lock the phone, and then come back. Most stores have never done this, and a meaningful share of real mobile purchases involve exactly that sequence. ## Navigation and search on a small screen Two surfaces that behave acceptably on desktop and badly on phones, and both are upstream of everything else — a shopper who cannot find the product never reaches the product page you optimised. **Menus that hide everything behind one tap.** A hamburger containing a deep nested tree is technically complete and practically unusable. Shoppers on phones will not explore three levels to find a category. Surface your most important destinations directly, and accept that a mobile menu is not a place to reproduce your full site structure. **Search that is hard to reach.** On mobile, search often outperforms browsing because typing a product name beats navigating a tree with a thumb. If search is hidden behind a menu, you are pushing people toward the harder path. Make it visible. **Search results that are not usable.** Results with no images, no prices, or no way to filter give a shopper nothing to choose between. Mobile search results need to be scannable, because reading is harder on a small screen than pointing is. **Filters that require too many taps.** Filtering is more valuable on mobile than desktop, because scrolling a long grid on a phone is tedious. A filter panel needing five interactions to apply one filter will not be used. > **Watch what mobile users search for** > > Your site search queries are the clearest statement of what shoppers want and cannot find. If the same term appears repeatedly and returns nothing useful, that is a navigation problem, a naming problem or a gap in your catalogue — and it is costing you on every device, just most visibly on phones. ## Diagnose before redesigning Most stores do not need a mobile redesign. They need to find the two or three specific places where mobile users leave. **Look at the funnel by device.** Shopify's analytics separate mobile and desktop. Compare the drop between steps rather than the overall conversion rate, because the step with the widest gap is your answer. **Watch session recordings if you have them.** Rage taps, repeated scrolling, and abandonment at a specific field tell you more than any general audit. **Check the specific templates** carrying the most mobile traffic. Usually product pages and one or two collections, not the whole site. **Then change one thing and measure it.** A mobile redesign that changes everything simultaneously leaves you unable to attribute any of the result. Be careful comparing mobile and desktop conversion rates directly, too. Some gap is structural rather than a defect — phones carry more early-stage browsing, more research that completes later on a laptop, and more traffic from social sources with weaker intent. A store whose mobile rate is lower than desktop is normal. A store whose mobile rate is a fraction of desktop, or whose gap widens over time, has something specific wrong, and the funnel-by-device comparison will show where. > **Do not fix mobile by simplifying it away** > > The instinct is to strip mobile down — fewer images, less information, shorter descriptions. Mobile shoppers are not less interested; they are on a smaller screen. Removing the information they need to decide does not help them decide, and stores that hide specifications on mobile routinely find the mobile gap widens rather than narrows. For the product page fundamentals this builds on, see [storefront and design](/category/storefront-design). Checkout specifics are covered in [checkout and payments](/category/checkout-payments), and page weight in the storefront archive. **Mobile losing orders you cannot account for?** ByteInfy audits and rebuilds Shopify mobile experiences — the funnel by device, the specific leaks, and the performance work that goes with them. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Why is my Shopify mobile conversion rate lower than desktop? Some gap is normal — mobile carries more browsing and research traffic. ### How do I test my Shopify store on mobile properly? On an actual mid-range phone, on mobile data rather than office wifi, completing a real purchase. ### What is the most common mobile conversion problem on Shopify? The buy box being pushed off screen by a tall image gallery. The shopper arrives, sees a photograph, scrolls through more photographs, and has still not encountered a price or an add-to-cart button. ### Do accelerated checkout buttons help mobile conversion? Generally yes, substantially, because they remove the form filling that is most painful on a phone. ### Should I build a mobile app instead? Almost never as a conversion fix. --- --- title: "How to Cut COD Return-to-Origin on Shopify" description: "Every rejected COD parcel costs you forward shipping, return shipping and the working capital tied up in between — and none of it appears as a refund in your reports." author: "Aashish Kaushik" published: 2026-10-18T05:00:25.923Z updated: 2026-10-18T05:00:26.064Z url: https://blog.byteinfy.com/reduce-cod-rto-shopify --- # How to Cut COD Return-to-Origin on Shopify ## Key takeaways - RTO is decided at checkout, not in transit — the cheapest fix is preventing a bad order from being placed rather than chasing it after dispatch. - OTP verification removes the largest single category of RTO: orders placed with a number that was never reachable. - Partial prepayment converts a free option into a small commitment, and even a token amount changes behaviour sharply. - Blanket COD blocking costs more revenue than it saves; risk rules targeted by pincode, cart value and customer history are the workable version. Cash on delivery is not really a payment method. It is a free option written on your inventory — the customer takes the option at checkout, decides at the door whether to exercise it, and you carry every cost in between either way. That framing explains why RTO resists logistics fixes. Better couriers, more delivery attempts and improved address capture all help at the margin, but they are attempts to rescue an order that should not have been placed in the form it was. The interventions that move the number substantially happen at checkout. > **Scope** > > Written primarily for Indian and other COD-heavy markets, where COD is a majority payment method rather than an edge case. The mechanics generalise; the economics are specific. ## Count the real cost before deciding what to spend on it Most merchants underestimate RTO cost because a rejected parcel never appears as a refund. It leaves no trace in the revenue line — it simply is not there. The actual per-incident cost: ## What one RTO parcel costs you - Forward shipping, paid whether or not anyone accepts the parcel - Return shipping, usually at a similar rate - Packaging, consumed and not recoverable - Handling at both ends, including the labour to receive and re-shelve - Working capital, tied up for the full round trip - Inventory opportunity cost — the unit was unavailable to a buyer who would have paid - Condition risk, since returned goods are not always resaleable Put a real number on that for your own operation before deciding what an intervention is worth. Merchants who do this are usually surprised, and it changes what they are willing to trade in conversion rate to prevent it. ## Verification removes the largest category The single largest bucket of RTO is orders placed with a phone number that was never reachable. Not fraudulent in any dramatic sense — a mistyped digit, a number entered to get past a form, an impulse order the buyer forgot within an hour. OTP verification at checkout addresses this directly. The shopper receives a code by SMS or WhatsApp and enters it before the order is placed. An order that clears this step has a contactable buyer who was present and paying attention at the moment of ordering. The objection is always conversion rate, and it is a real cost. But it is the wrong metric. The question is not how many orders you take, it is how many you deliver and what you earned net of the ones you did not. A checkout that converts a few points worse while cutting RTO substantially is straightforwardly the better checkout — and you can only see that if you are measuring delivered revenue rather than order count. Two implementation details matter more than the decision itself. Keep verification on the same page rather than sending the shopper elsewhere, and make the code arrive fast — a slow OTP is where genuine buyers actually abandon. WhatsApp delivery tends to outperform SMS on both speed and open rate in markets where it is the dominant messaging channel. ## Partial prepayment changes the decision, not the price The second intervention is the most economically elegant: ask for a small amount up front and collect the balance on delivery. The mechanism is not the money. A small prepayment does not meaningfully reduce your exposure on the remaining balance. What it does is convert a free option into a committed decision. A shopper who has paid anything, however little, has made a choice rather than deferred one — and the behavioural difference at the door is large relative to the amount collected. This also solves a problem blanket COD blocking creates. Blocking removes the order and its revenue entirely. Partial payment keeps the order, keeps the customer, and shifts the economics. For most catalogues it is the higher-revenue intervention. Where to set the amount is less important than that one exists. Token fixed amounts work; percentage-of-cart works and scales better across a wide price range. What does not work is an amount high enough that the shopper reasons they may as well prepay in full, at which point you have built a worse prepaid checkout. ## Risk rules, not blanket rules Blocking COD outright is the intervention merchants reach for first and regret. It is indiscriminate: it removes your good COD orders alongside the bad ones, and in a COD-majority market that is most of your revenue. Targeted rules work better because RTO risk is not uniformly distributed. It concentrates: ## Where RTO risk concentrates, and the proportionate response | Signal | Why it correlates with RTO | Proportionate rule | | --- | --- | --- | | High cart value | Larger sums prompt second thoughts at the door | Require partial payment above a threshold | | Unfamiliar pincode | No delivery history, often weaker courier coverage | Require OTP, or prepaid only | | Prior RTO from this customer | The strongest single predictor available to you | Prepaid only for repeat offenders | | Multiple orders, same address, short window | Often duplicate or impulse ordering | Verify before dispatch | | First-time customer, high value | No history and a large exposure at once | Partial payment | | Category with high buyer's remorse | Fashion sizing, impulse categories | Category-level partial payment | The principle is proportionality. Match the friction to the measured risk, and apply it only where your own data supports it. A rule built on someone else's benchmark will remove revenue you could have kept. > **Measure by pincode before you write any rule** > > RTO is intensely geographic, and the pattern is specific to your couriers and your categories. Export your delivery data, compute RTO rate by pincode, and let that decide where rules apply. Almost every merchant who does this finds the problem concentrated far more narrowly than they assumed — which means the fix can be far narrower, and cost far less revenue, than a blanket policy. ## What happens after dispatch still matters Everything above is preventative, and prevention is where the leverage is. But a parcel already moving is not a lost cause, and the window between dispatch and delivery attempt is the cheapest place to convert an RTO into something less costly. **Confirm before dispatch.** A short message asking the buyer to confirm the order, sent within an hour or two of placement, catches impulse orders while the decision is still fresh. A cancellation at this point costs you the picking labour and nothing else — no forward shipping, no return leg, no capital tied up. Merchants consistently find this is the highest-return message they send. **Set the delivery expectation precisely.** A large share of door-step rejections are not really rejections; the buyer is not home, was not expecting the parcel, or does not have cash to hand. Telling someone the delivery window and the exact amount due converts a failed attempt into a successful one, and the cash-amount reminder matters more than merchants expect for COD specifically. **Make the second attempt count.** Most couriers attempt delivery more than once, and the second attempt frequently fails for the same reason as the first because nothing changed in between. A message after a failed attempt, offering a reschedule or an address correction, is worth more than the attempt itself. **Watch for the pattern, not the incident.** One RTO is noise. The same customer, the same pincode, or the same product appearing repeatedly is a signal that belongs in your rules. Feeding delivery outcomes back into the checkout rules is what turns a one-off cleanup into a system that keeps improving. > **The metric to run this on** > > Track delivered contribution margin per session, not conversion rate and not RTO rate alone. Optimising RTO rate in isolation leads to blocking too much; optimising conversion in isolation leads to accepting everything. The single number that captures both is what you actually earned, after shipping both ways, per visitor who arrived. ## The order to implement in 1. Measure. RTO rate by pincode, by cart value band, by category. Without this everything after is guesswork. 2. Add OTP verification. Broadest impact, lowest revenue cost, addresses the largest bucket. 3. Introduce partial payment above a value threshold, set from your own data rather than a default. 4. Add targeted risk rules for the specific pincodes and patterns your measurement exposed. 5. Re-measure on delivered revenue, not order count. This is the step that tells you whether any of it worked. Post-purchase confirmation is worth adding alongside all of the above — a message that lets the buyer confirm or cancel before dispatch converts a future RTO into a cancellation, which costs you nothing but the picking. Expect the first pass to remove more revenue than you are comfortable with, and expect to loosen it. Merchants almost always over-tighten initially, see order count fall, and panic. Hold the change long enough to see delivered revenue rather than gross orders, then relax the rules that are costing you good customers and keep the ones that are not. Tuning towards the right level from a slightly-too-strict starting point is far easier than discovering the right level from a position of taking every order. For the wider checkout picture, see [checkout and payments](/category/checkout-payments). Payment method selection for Indian stores is covered in the same archive, and BFCM-specific checkout readiness lives in the [BFCM 2026](/series/bfcm-2026) series. **Cut RTO without cutting your COD revenue** ByteInfy's COD & Part Payment app adds OTP verification, smart COD blocking by pincode, product or cart value, and partial prepayment at checkout. [See it on the Shopify App Store](https://apps.shopify.com/byteinfy-cod-partial-pay) ## FAQ ### What is a normal RTO rate for COD orders in India? It varies enormously by category, price point and region, and any single benchmark figure should be treated sceptically. ### Does OTP verification annoy customers and cost conversions? It costs some conversions, and that is the point — it removes orders that were never going to be accepted. ### Is it better to block COD or charge for it? Charging is usually better. Blocking removes the order entirely; a COD fee or a partial prepayment keeps the order while shifting the economics and filtering out the least committed buyers. ### How much partial payment should I ask for? Enough to represent a real commitment and little enough not to feel like a prepaid order. Many merchants land somewhere between a token fixed amount and roughly ten to twenty percent of cart value. ### Will reducing RTO reduce my total orders? Yes, and that is usually the correct outcome. The orders removed are disproportionately the ones that would have been rejected at the door. --- --- title: "Tiered Discounts on Shopify: Thresholds That Raise AOV" description: "A threshold set at a round number rewards customers who were already spending that much. Set it from your own distribution and it changes behaviour instead." author: "Aashish Kaushik" published: 2026-10-17T13:00:45.607Z updated: 2026-10-17T13:00:45.610Z url: https://blog.byteinfy.com/shopify-tiered-discounts --- # Tiered Discounts on Shopify: Thresholds That Raise AOV ## Key takeaways - Thresholds should come from your actual order value distribution, not a round number, or you discount behaviour you already had. - The progress indicator is the mechanic — a shopper who cannot see how close they are has no reason to add anything. - Too many tiers reduces response; two or three rungs outperform five in most catalogues. - Measure revenue per visitor, not average order value, because AOV rises whenever a threshold exists regardless of whether you earned anything. A spend threshold is one of the better mechanics available to a Shopify merchant, because it raises order value without reducing unit margin. The customer who was going to spend below it either adds something or does not; the customer above it pays what they were going to pay. It also fails quietly and often, for two reasons that are both fixable: the threshold is set at a number that means nothing, and the shopper cannot see how close they are. > **Why the mechanic is attractive** > > A percentage discount costs you margin on every order. A threshold costs you nothing from shoppers who do not reach it, and costs you a defined amount from those who do — while changing what they buy rather than what they pay per unit. ## Set the threshold from your own data The most common failure is a round number. ₹2,000, ₹5,000, £50. Round numbers are chosen because they look tidy and they bear no relationship to how your customers actually spend. The number you want comes from your order value distribution. Export your orders, and look at where they cluster. **Slightly above the cluster** is where the threshold belongs. If most of your orders land between ₹1,400 and ₹1,800, a threshold at ₹2,000 puts a meaningful share of shoppers within one item of qualifying. That is a reachable step, and reachable steps get taken. **Far above the cluster** and the offer is invisible to most of your traffic. It only rewards customers already spending that much, which is a discount on existing behaviour. **Below the cluster** and almost everyone qualifies without changing anything, which is simply a discount with extra steps. The right threshold usually sits somewhere between ten and thirty percent above your median order value, but the range matters less than the principle: derive it, do not choose it. One refinement worth making if your catalogue spans very different price points. A single threshold that works for your mid-range products may be trivially cleared by anyone buying a premium item and unreachable for anyone buying accessories. Where that gap is large, either set the threshold against the segment that represents most of your orders and accept it does little for the others, or use category-scoped thresholds — which is more work and more explaining, so only worth it when the spread genuinely warrants it. ## A worked example of setting the number The principle above is straightforward to agree with and easy to skip in practice, so it helps to walk through the actual steps on a hypothetical order file. Export the last three months of orders, excluding any period distorted by a major sale, since a threshold planned around discounted-period baskets will sit at the wrong level for the rest of the year. Sort the order values and look at the distribution rather than the average alone, because an average can be pulled upward by a handful of large orders while most customers cluster well below it. A median is usually the more honest single number to start from. Say the median order value comes out around a certain figure and the bulk of orders, the middle band that excludes the smallest and largest tails, cluster in a range running from somewhat below that median to somewhat above it. The threshold candidate sits above that cluster's upper end, not above the median alone, because the goal is a number that a meaningful share of shoppers can reach by adding one more item, not a number only your highest spenders already clear. Cross-check the candidate against your typical single-item price. If the gap between the median order and the proposed threshold is smaller than your cheapest regularly sold item, almost nobody will need to add anything to qualify, which defeats the mechanic entirely. If the gap is larger than your most expensive typical item, reaching it requires adding two or three things, which is a harder ask and will show up as a lower response rate. Once live, the number is not permanent. Revisit it every few months against fresh order data, because product mix, pricing changes and seasonal shifts in what people buy all move the distribution the threshold was built from. A threshold that was well placed in spring can quietly become too easy or too hard to reach by autumn if nobody checks it again. ## The progress indicator is the mechanic This is the part merchants skip, and skipping it is why thresholds underperform. A threshold communicated as a site banner — "Free shipping over ₹2,000" — is a fact the shopper reads once and forgets. At the moment they are deciding whether to add another item, it is not in front of them. What works is distance, shown in the cart, in money, updated as the basket changes: **"You are ₹340 away from free shipping."** That sentence does the work. It is specific to this shopper, it names a small number, and it appears exactly where the decision is being made. The generic banner does not. Native Shopify discounts do not render this — they apply silently until the cart shows the result. Building it is either a theme change or the main reason to use an app in this category, and it is worth being clear that the progress indicator, rather than the discount logic, is what you would be paying an app for. ## Where the threshold needs to be visible - Cart drawer or cart page, showing distance in money - Updated live as items are added or removed - Stated again at checkout, confirming it applied - On product pages for qualifying products, at least as a line - In the announcement bar, as the general fact - Never only in the announcement bar ## Fewer rungs, not more The instinct is to build a ladder — five percent at one level, ten at the next, fifteen above that. The instinct is usually wrong. Every additional tier turns a simple decision into a table to study, and shoppers do not study tables. Response falls as complexity rises. Two or three rungs is the practical range. Often one threshold is enough. A second rung, set at a genuinely aspirational level, catches the customers who would stretch and does no harm. Beyond three, you are managing complexity for no gain and creating more edge cases where offers interact badly. Each additional rung also multiplies the testing burden, since every tier boundary is a place where the reward can apply incorrectly and nobody will notice until a customer does. ## Choose the reward carefully What sits on the other side of the threshold matters as much as where it sits. ## Reward types compared | Reward | Cost to you | How it reads | | --- | --- | --- | | Free shipping | Fixed, known | High perceived value, especially on smaller baskets | | Free gift | Cost of the item | Generous relative to cost; needs inventory planning | | Percentage off | Scales with order value | Costs most where least needed | | Fixed amount off | Fixed | Simple, easy to communicate | | Loyalty points or credit | Deferred | Cheap now, encourages return | Free shipping is usually the strongest option. It is a fixed and known cost, it reads as valuable to shoppers, and it removes a friction that already exists rather than adding a benefit that did not. A percentage is the weakest, because it costs you most on the largest orders — exactly the customers who needed the least persuasion. ## Where it quietly fails Four failure modes worth checking before launch. **Nobody can see it.** Covered above, and by a considerable distance the most common of the four. **The threshold is calculated on the wrong number.** Before or after discounts, including or excluding tax and shipping. Decide, be consistent, and state which — a customer who thought they qualified and did not will contact support, and they will be right to. **It interacts badly with other offers.** A shopper qualifying for both a threshold reward and another discount hits Shopify's combination rules. Test the pairing rather than assuming. **The basket drops below after qualifying.** The reward should be removed when the cart no longer qualifies. If it is not, you are shipping free products or free delivery on unqualified orders, and the pattern gets shared once someone notices. ## Help the shopper close the gap Showing the distance creates the intent. What happens next determines whether it converts, and most stores leave the shopper to work it out alone. A customer told they are ₹340 away now has a small problem: what costs roughly ₹340 and is worth having? If solving that means going back to a collection page and browsing, a good share will not bother. **Suggest something in range.** A small set of products priced near the gap, shown in the cart. This is the single highest-return addition to a threshold mechanic and it is frequently absent. **Price the suggestions slightly above the gap, not below.** Something at ₹380 closes it; something at ₹300 leaves them ₹40 short and mildly annoyed. **Favour genuinely useful additions.** Consumables, accessories, refills — things a customer would plausibly want rather than whatever is nearest the price point. Suggestions that look arbitrary undermine the offer. **Keep it to three or four options.** This is a nudge, not a browsing experience. There is a related decision about what counts toward the threshold. Excluding sale items is defensible and needs saying plainly on the offer, because a shopper who assumed otherwise discovers it at the least convenient moment. Whatever you decide, state it where the offer is stated rather than in a policy page nobody reads. > **Round the gap in the customer's favour** > > If the shopper is ₹7 away, apply the reward. The goodwill from that is worth considerably more than ₹7, and the alternative is a customer who adds a cheap item purely to clear a trivial gap and feels manipulated doing it. ## Measure the right number Average order value will rise. It rises whenever a threshold exists, because qualifying orders are by definition above it. This tells you nothing. The question is whether **revenue per visitor** rose. That captures both what customers spent and whether the offer cost you any conversions. Compare against a period before the threshold, or better, a group of visitors not shown it. And watch return rates, because items added to reach a threshold are chosen with less deliberation than items sought out, and they come back more often. > **Watch what happens when you remove it** > > A threshold offer that runs permanently becomes the expected price. Customers learn the number and shop to it, which is fine while it runs and produces a visible drop when it stops. If you intend it as a permanent mechanic, that is a decision worth making deliberately rather than discovering when you try to end it. For the wider offer strategy and margin arithmetic, see [promotions and offers](/category/promotions-offers). Implementation and combination rules are covered in the same archive, and BFCM-specific structures in the [BFCM 2026](/series/bfcm-2026) series. **Threshold logic that shows the distance** ByteInfy builds Shopify offer mechanics with Functions — tiered thresholds, live progress indicators and stacking rules that hold through checkout. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Where should I set a spend threshold? Slightly above the point where most of your orders currently land, so a meaningful share of shoppers are close enough for one more item to be a reasonable step. ### How many discount tiers should I have? Two or three. Response falls as tiers multiply, because the offer stops being a simple decision and becomes a table to study. ### Do tiered discounts actually raise average order value? They raise it mechanically, since orders that qualify are by definition above the threshold. Whether they raise revenue is a different question and needs a comparison against a period or group without the offer. ### Why is nobody hitting my threshold? Usually because they cannot see it. A threshold communicated only as a banner has no effect at the moment of decision. ### Should the reward be a percentage or free shipping? Free shipping is usually cheaper for you and reads as more valuable to the shopper, particularly on lower-value baskets. --- --- title: "Shopify Abandoned Checkout Recovery That Works" description: "Abandonment is not one behaviour. Someone comparing prices and someone whose card was declined need entirely different messages, and most stores send them the same one." author: "Aashish Kaushik" published: 2026-10-17T05:00:58.888Z updated: 2026-10-17T05:00:58.920Z url: https://blog.byteinfy.com/shopify-abandoned-checkout --- # Shopify Abandoned Checkout Recovery That Works ## Key takeaways - Abandonment has several distinct causes, and a single generic recovery email addresses none of them well. - Shopify recovers abandoned checkouts natively, so the first question is whether you need an app at all. - The first message does most of the work, and sending it promptly matters more than the length of the sequence. - Leading with a discount trains customers to abandon deliberately, which is a habit that costs more than the recovered orders. Abandoned checkout recovery is usually implemented as one email sent to everyone who left, saying roughly "you forgot something". The problem is that abandonment is not one behaviour. Someone comparing prices across three tabs, someone whose card was declined, someone startled by a shipping cost, and someone who got distracted mid-purchase are four different situations with four different remedies. A single generic message addresses none of them well. > **Start with what the platform does** > > Shopify sends abandoned checkout emails natively, with configurable timing and content. For a lot of stores that covers it. Establish whether it does for you before adding an app. ## The causes are different and so are the fixes Worth separating, because the recovery message that works for one is wrong for another. **Interruption.** The most recoverable group by a distance. Someone was buying and something intervened — a phone call, a train stop, a child. They intended to complete. A prompt reminder brings a good share of them back. **Comparison shopping.** Genuinely undecided, checking elsewhere. Recoverable with reassurance — delivery times, returns policy, why you rather than the alternative. **Sticker shock at shipping.** Reached checkout, saw the total, left. The message that helps states the shipping position clearly, and the durable fix is showing shipping cost earlier so the surprise never happens. **Payment failure.** Tried to pay and could not. Highly recoverable and frequently mishandled, because a generic "you left something behind" is insulting to someone who attempted to buy. **Never intended to purchase.** Using the cart to save items, checking a total, browsing. Not recoverable, and a significant share of the volume. ## Cause, recoverability and the right message | Cause | Recoverable | Message that works | | --- | --- | --- | | Interruption | High | Prompt, simple, one click back | | Payment failure | High | Acknowledge it, offer another method | | Shipping surprise | Moderate | State shipping plainly; fix the disclosure | | Comparison shopping | Moderate | Reassurance — returns, delivery, support | | Saving for later | Low | Gentle, low frequency | | Never intended | None | Do not spend messages here | ## The first message does most of the work Recovery is heavily front-loaded, which has a practical implication: get the first message right and out quickly, rather than building an elaborate sequence. **Send it within the first hour.** This captures the interrupted group while the intent is still live. A message arriving the next day reaches someone who has often already bought elsewhere. **Make returning frictionless.** One link that restores the cart exactly as it was. Any additional step loses people who were otherwise ready. **Show what they left.** Product image, name, price. The customer may genuinely not remember which of three tabs this was. **Keep it short.** This is a reminder, not a campaign, and long recovery emails consistently perform worse than brief ones. ## Do not lead with a discount The most common mistake and the most expensive one, because the damage is not confined to the message. Customers learn quickly. A store that reliably emails a discount code after abandonment teaches its regulars to abandon deliberately. Once learned, you are paying a discount on orders that would have completed at full price, and the behaviour spreads through the segment most likely to buy from you again. If you use a discount at all, put it in the second or third message, and only for segments where the evidence supports it. Better still, offer something that is not margin — free shipping over a threshold you already offer, a reassurance about returns, or a genuine answer to a hesitation. ## A recovery sequence that behaves - First message within an hour, no discount, one-click return - Second message at roughly a day, with reassurance rather than price - Optional third at three days, where a discount may be justified - Payment failures handled separately, acknowledging what happened - Suppression for anyone who has since purchased - A frequency cap so repeat abandoners are not messaged endlessly The suppression rule matters more than it sounds. Emailing someone about a cart they have already bought is a small failure that reads as carelessness, and it happens constantly on stores where the recovery tool and the order system are not properly connected. ## Handle payment failures as their own case The highest-value segment and the one most often lumped in with everything else. Someone whose payment failed tried to buy. They are not undecided, not comparing, not browsing. They wanted the thing and the transaction did not complete. A generic "you left something in your cart" is wrong for them, and mildly insulting. What works is acknowledging what happened and making the retry easy: the payment did not go through, here is your cart, here are other ways to pay. This matters more during high-volume periods, when card declines rise as people spend beyond their usual patterns. ## Channels beyond email Email is the default and not always the best fit. **SMS and WhatsApp** have far higher open rates and much lower tolerance for frequency. One message, useful, promptly sent. In markets where WhatsApp dominates messaging, it substantially outperforms email for this specific use — but it is also more intrusive, and abusing it costs you the channel permanently. **On-site**, before they leave. An exit-intent prompt is not recovery so much as prevention, and preventing abandonment is cheaper than recovering it. **Retargeting**, which reaches people who never gave you an email address — a group email-based recovery cannot touch at all. This is usually the largest abandoning segment and the one most stores ignore entirely, because the tools they use for recovery only see the people who identified themselves. The channel choice should follow the cause where you can tell them apart. An interrupted buyer responds well to anything prompt. A comparison shopper needs reassurance, which reads better in email than in a two-line SMS. A payment failure warrants the fastest channel you have, because the intent decays quickly. ## Measuring recovery honestly The reported recovery rate is one of the most inflated numbers in ecommerce tooling, and the inflation is structural rather than dishonest. Most tools attribute any purchase by an abandoner to the recovery message, whether or not the message caused it. A substantial share of those people were coming back regardless — they were interrupted, they finished later, and an email happened to arrive in between. The tool counts it, your dashboard shows a healthy recovery rate, and the actual incremental effect is smaller. Two things make the number meaningful: **Hold out a control group.** Suppress recovery messages for a small random share of abandoners and compare their return rate against those who received them. The difference is your real recovery rate. Most stores have never done this and would be surprised by the gap. **Measure incremental revenue, not attributed revenue.** Attributed revenue answers "how much did people who got an email spend". Incremental revenue answers "how much more did they spend than they would have anyway", which is the only version that justifies the cost. This matters commercially, not just intellectually. Merchants who believe recovery is producing a large share of revenue tend to invest further — longer sequences, deeper discounts, more channels — and each addition is judged by the same inflated measure. A control group is a day of setup and it prevents years of that. > **Watch what recovered customers do next** > > An order recovered with a discount code frequently produces a customer who waits for the next code. Track repeat purchase behaviour of discount-recovered customers separately from the rest. If they return less often, or only when discounted, your recovery programme is buying revenue today at the cost of margin later. ## Fix the causes, not only the symptom Recovery is treating a symptom. The abandonment data tells you what to fix upstream, and that is worth more than any sequence. If shipping cost is the common exit point, show it earlier. If checkout is where people leave on mobile specifically, something in that flow is broken on phones. If payment failures cluster around one method, investigate it. The recovery emails will still be worth sending. But a store that recovers fifteen percent of abandoned checkouts while ignoring why they abandon is optimising the wrong end of the problem. The diagnostic worth running quarterly: look at where in the checkout people actually stop. Shopify's own analytics show the funnel, and the step with the largest drop is your answer. If it is the shipping step, your shipping disclosure is the problem. If it is the payment step on mobile specifically, something about that form is failing on phones. If it is the very first step, people are reaching checkout without intending to buy, which points at your cart or your product pages rather than at checkout at all. Each of those has a fix that is permanent, unlike a recovery email, which addresses the same failure again every day it happens. For checkout mechanics and the wider payment picture, see [checkout and payments](/category/checkout-payments). Peak-period checkout readiness is covered in the [BFCM 2026](/series/bfcm-2026) series. **Checkout that loses fewer people in the first place** ByteInfy audits and builds Shopify checkout flows — where people leave, why, and the fixes that reduce abandonment rather than chasing it. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Does Shopify have built-in abandoned checkout recovery? Yes. Shopify sends abandoned checkout emails natively, with configurable timing and content, and for many stores that is sufficient. Apps add multi-step sequences, SMS or WhatsApp channels, and segmentation. ### How soon should the first recovery message go out? Sooner than most stores send it. Within an hour captures people who were interrupted rather than deterred, and that is the group most likely to return. ### Should I include a discount in abandoned checkout emails? Not in the first one. ### How many recovery emails should I send? Two or three is usually the practical range. The first does most of the work. Beyond three, response falls sharply and unsubscribes rise, and you are spending list health on diminishing returns. ### What abandonment rate is normal? High, across all of ecommerce, and the figure varies enough by category and traffic source that any single benchmark is close to useless. --- --- title: "Fixing Shopify's Duplicate Content Problem" description: "Shopify creates several URLs for the same product, and handles the obvious half itself. The half it does not handle is where your crawl budget goes." author: "Aashish Kaushik" published: 2026-10-16T13:01:05.470Z updated: 2026-10-16T13:01:05.500Z url: https://blog.byteinfy.com/shopify-duplicate-content --- # Fixing Shopify's Duplicate Content Problem ## Key takeaways - Shopify sets canonicals on product URLs reachable through collections, so the most-discussed duplicate problem is already solved by the platform. - The real cost is filtered, sorted and paginated collection URLs, which multiply on large catalogues and consume crawl budget. - Search Console's page indexing report tells you exactly how much of your crawl is going nowhere useful. - Internal links that disagree with the canonical force reconciliation work on every crawl and waste link equity. Shopify duplicate content is one of the most written-about SEO topics in the ecosystem and one of the most consistently overstated. A large share of the advice describes a problem the platform solved years ago, and sells a fix for it. The genuine problems are different, less discussed, and more expensive. They are also diagnosable in about ten minutes. > **Not a penalty** > > Duplicate content on Shopify is not a punishment. It is dilution — signals split across near-identical URLs — and waste, as crawl budget goes to pages that will never rank. The cost is opportunity, which is why nobody notices it. ## What Shopify already handles Start here, because it eliminates the most commonly sold fix. A product on Shopify can be reached at `/products/product-handle` and also at `/collections/collection-handle/products/product-handle`. Same product, different URL. Shopify sets a canonical tag on the collection-scoped version pointing at the bare product URL. That tells Google which version to index, and it works. Any article or app offering to "fix Shopify's duplicate product URLs by adding canonical tags" is offering you something you have. This claim is common, and it works because merchants do not think to view the page source and check for themselves. It takes about thirty seconds to confirm. ## Where the real cost is Four problems the platform does not solve for you. **Filtered and sorted collection URLs.** `?sort_by=`, filter parameters, tag-filtered paths. On a large catalogue these multiply extremely fast, and each is a near-identical page containing a subset of the same products. This is by far the largest contributor on most stores. **Pagination.** Page four of a collection is rarely a useful landing page and is frequently crawled and indexed as though it might be. **Internal links that contradict the canonical.** If your theme and apps link to collection-scoped product URLs while canonicals point elsewhere, every internal link points at a page you have told Google to ignore. The equity still resolves, but you have made reconciliation work happen on every crawl. **Thin auto-generated collections.** Tag-based collections multiply quietly, and each near-empty one is a crawlable page competing for attention it cannot hold. ## Problem, cost and whether Shopify handles it | Issue | Handled by Shopify | Real cost | | --- | --- | --- | | Product reachable via collection path | Yes, canonical set | Minimal | | Filtered collection URLs | No | High on large catalogues | | Sorted collection URLs | No | Moderate | | Pagination beyond page one | Partially | Moderate | | Internal links contradicting canonical | No | Wasted equity | | Thin auto-generated collections | No | Crawl waste, thin pages | ## Diagnose it before fixing anything Ten minutes in Search Console tells you whether any of this applies to your store, and at what scale. Open the **page indexing report** and read two buckets: **"Duplicate, Google chose a different canonical."** Google found these, decided they were duplicates, and picked something else. On Shopify stores these are usually filtered collection variants. **"Crawled — currently not indexed."** Google fetched these and decided not to index them. Some of this is normal. Large volumes of collection variants here means significant crawl budget is going nowhere. The numbers matter more than their presence. A few dozen is background noise. Several thousand on a store with four hundred products means most of your crawl is being spent on pages that will never rank, and the pages you care about are being visited less often as a result. ## Fixing the filtered URLs The general aim is that these URLs remain **crawlable but not indexed**, so products reachable only through a filter stay discoverable while the near-duplicate pages do not compete. Blocking them in robots.txt entirely is the instinct and usually the wrong move — it prevents crawling, which can make filtered-only products undiscoverable, and it does not reliably remove already-indexed URLs. How to achieve crawlable-not-indexed depends on your theme and filter implementation, which is why generic instructions here would be unreliable. What is reliable is the sequence: confirm the scale in Search Console, identify which parameters are generating the volume, implement the fix your theme supports, and re-check the report in several weeks. ## Duplicate content audit - Read the page indexing report and note the volume in each bucket - Identify which URL patterns dominate the duplicate buckets - Count your collections, sorted by product count - Check whether internal links point at canonical product URLs consistently - Check whether pagination beyond page one is being indexed - Confirm variant URLs are not each generating an indexable page ## Internal links are the quiet one The least discussed and among the easiest to fix. If your navigation, collection grids and content link to `/collections/x/products/y` while canonicals point at `/products/y`, every internal link is aimed at a page you have declared non-canonical. This is not catastrophic. Google resolves it. But you are asking it to do reconciliation work on every crawl, and consistency costs nothing once someone decides to enforce it. Crawl your own site, look at where internal links point, and make them consistent with your canonicals. On most stores this is a theme change in one or two places, and it is the sort of fix that stays fixed — unlike content work, nothing erodes it over time except an app that starts generating its own links. ## Consolidate thin collections while you are here Related, and usually the highest-return action available. Auto-generated collections built on tags proliferate silently. A tagging scheme that made sense for merchandising produces a collection per tag, most containing a handful of products, all crawlable. Export the full list, sort by product count, and act: **Two or three products** — merge, noindex or delete and redirect. **Created for a campaign that has ended** — delete it and redirect to the most relevant live collection. **Nobody can explain why it exists** — investigate before removing it, since something elsewhere may still reference it. Check traffic before deleting anything, and check whether a collection is referenced by navigation, an app or a product feed. Removing one that a feed depends on causes problems well outside search, and shopping campaigns are the usual casualty because nobody connects the two events. ## Why crawl budget matters at all Merchants reasonably ask whether this is a real problem or an SEO abstraction, since Google has substantial capacity and a store with four hundred products is not large. It is real, and the mechanism is worth understanding rather than taking on faith. Search engines allocate a finite amount of crawling to each site, informed by how important and how fresh they judge it to be. If a large share of that allocation goes to filtered collection variants, two things follow: **Your important pages are visited less often.** A new product, a price change, or an updated collection description takes longer to be noticed. On a store with frequently changing inventory, that lag has direct commercial consequences — products showing as available when they are not, or new lines taking weeks to appear. **Your site looks lower-quality in aggregate.** A crawler encountering thousands of near-identical thin pages is forming an impression of the site as a whole, not just of those pages. The second effect is harder to demonstrate and is the reason experienced practitioners treat crawl waste as worth fixing even on smaller sites. You are not only losing efficiency; you are describing your site badly. There is a practical threshold worth applying. If your indexed page count is broadly in line with your actual products, collections and content, this is not your problem and effort is better spent elsewhere. If it is several times larger, something is generating pages you did not intend, and finding out what is the highest-value hour available. > **Compare intended pages against indexed pages** > > Count what you meant to publish — products, collections, content pages — and compare it against what Search Console reports as discovered. Most merchants have never made this comparison, and the gap is usually where the answer is. ## What not to worry about Two things that consume attention disproportionately. **Manufacturer product descriptions** shared with other retailers. This makes ranking harder because nothing distinguishes your page, but it is not a duplicate content problem in the technical sense and no canonical tag fixes it. The answer is original detail on the products that matter commercially. **Your own products appearing on marketplaces.** Normal, expected, and not something Google penalises you for. If a marketplace listing outranks your own product page, that is a signal about relative authority rather than a duplication problem, and the response is to strengthen your page rather than to remove the listing. **Tag and vendor archive pages**, unless they exist in real volume. A handful is harmless. Several hundred, most containing one product, is the same thin-page problem as auto-generated collections and should be treated the same way. **HTTP versus HTTPS, and www versus non-www.** Shopify handles these, and articles that raise them are usually recycled from advice written for self-hosted platforms. For the collection-level structural work this connects to, see [SEO and AI search](/category/seo-ai-search). Product page specifics are covered in the same archive. **Crawl budget going nowhere?** ByteInfy audits and fixes Shopify indexation — filtered URL sprawl, collection consolidation and the internal linking that should support them. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Does Shopify have a duplicate content problem? Partly, and less than most articles claim. Shopify serves products through both /products/handle and /collections/x/products/handle, and it sets a canonical tag pointing at the bare product URL, which resolves that case. ### Should I block filtered collection URLs in robots.txt? Usually not by blocking crawling entirely, because products reachable only through filters then become undiscoverable. The general aim is that these URLs are crawlable but not indexed. ### How do I find duplicate content on my Shopify store? Search Console's page indexing report is the fastest route. Look at the "Duplicate, Google chose a different canonical" and "Crawled — currently not indexed" buckets. ### Do product variants create duplicate content? They can, if each variant generates an indexable URL. ### Is duplicate content a Google penalty? No. It is not a penalty so much as a dilution and a waste. Signals split across several near-identical URLs, and crawl budget is spent on pages that will never rank. --- --- title: "UGC or Studio Video: What Sells Better in 2026" description: "The question is not which is better. It is which doubt you are resolving, because credibility and clarity are different problems with different solutions." author: "Aashish Kaushik" published: 2026-10-16T05:01:07.215Z updated: 2026-10-16T05:01:07.228Z url: https://blog.byteinfy.com/ugc-vs-studio-video --- # UGC or Studio Video: What Sells Better in 2026 ## Key takeaways - UGC is credible because it visibly is not a production, which is exactly the property polishing destroys. - Studio video is better at detail, finish and construction — things a phone camera in poor light cannot convey. - Most catalogues want both, placed differently, rather than a decision between them. - Cost comparisons usually ignore the rights, curation and editing work that makes UGC usable, which is not free. The comparison gets framed as a contest and it is not one. UGC and studio video answer different questions, and a store with only one of them has a library that resolves half the doubts its shoppers arrive with. The useful question is which doubt you are resolving. Credibility and clarity are different problems. > **The short version** > > UGC proves. Studio shows. A shopper wondering "is this real and does it work for people like me" needs the first. A shopper wondering "what exactly does the finish look like" needs the second. ## What UGC is actually good at Its value comes from a single property: it visibly is not a production. That produces credibility no amount of production budget can buy, and it makes UGC strong at: **Real-world scale and fit.** Someone of stated height wearing the thing, in an ordinary room, in ordinary light. This is the most common unresolved doubt in most categories and the thing studio photography is worst at. **Proof that ordinary people use it.** A studio shot proves the product exists. A customer video proves someone chose it and kept using it. **Honest limitations.** UGC that mentions a drawback increases trust in everything else it says, and it pre-empts returns from people for whom the product is wrong. **Use cases you did not think of.** Customers frequently show applications your marketing never considered, and those are often the most persuasive content you have. ## What studio video is actually good at The inverse, and it is genuine rather than a consolation. **Detail and finish.** Texture, stitching, material quality, how light behaves on a surface. A phone camera in a kitchen cannot show this, and for products where craftsmanship is the value proposition it is the whole argument. **Controlled demonstration.** Showing exactly how a mechanism works, clearly, with the right angle and the right lighting, without a hand obscuring the important part. **Consistency across a catalogue.** A collection page where every video looks different is visually chaotic and reads as unmanaged. Studio content can be systematic in a way sourced content never quite is. **Anything requiring precision.** Assembly steps, technical explanation, comparison between models. ## Doubt and which format resolves it | The shopper wonders | Better answered by | | --- | --- | | Will this fit or suit someone like me | UGC | | Is it as good as the photos suggest | UGC | | What do real people use it for | UGC | | What does the material actually look like | Studio | | How exactly does it work | Studio | | How does it compare to the other model | Studio | | Is the brand credible | Studio, at brand level | | Is the product credible | UGC | The last two rows are worth reading together. Studio content builds confidence in the brand; UGC builds confidence in the product. Stores frequently invest in the first and wonder why product pages do not convert. ## Placement follows function Because they do different jobs, they belong in different places. **Studio video near the gallery.** The shopper is evaluating the product and wants to see it properly. This is where detail belongs. **UGC lower on the page**, or in a distinct social proof section. It reinforces a decision that is already forming rather than informing the initial evaluation. **UGC on the homepage and collection pages** works well for discovery, because feed-native content catches attention in a way studio content generally does not. Reversing this tends to underperform. UGC in the primary gallery position competes with the clean product images shoppers use to evaluate, and studio content in a social proof section reads as an advert, which is precisely what a social proof section should not be. ## The cost comparison is usually wrong UGC is described as free or cheap. The footage often is. The total frequently is not. What actually costs something: **Sourcing.** Finding the content that already exists, or approaching creators to make some. **Rights.** Explicit permission for commercial storefront use, covering editing, duration and anyone identifiable in the clip. Audio needs separate consideration, because platform music licences do not travel to your website. **Curation.** Most UGC is simply not usable on a product page. Selecting the clips that answer a real question is judgement work. **Editing.** Trimming the scroll-stopping hook, cutting for length, adding captions for muted viewing, choosing a poster frame. None of that is expensive individually. Across fifty products it is a real project, and stores that budget UGC as free are usually the ones whose UGC programme stalls after eight videos. ## Before choosing a route - Name the specific doubt each video will resolve - Check whether existing UGC already exists for your products - Budget for rights, curation and editing, not just footage - Decide who owns the ongoing work, since one batch is not a programme - Confirm you can keep master files, whatever hosts the video - Plan placement per format before commissioning anything ## Do not fake it Studio content produced to look like UGC is a recurring temptation and it tends to produce the worst of both. Shoppers detect it, quickly and largely unconsciously. Content that reads as manufactured authenticity is worse than content that is honestly polished, because it costs trust rather than merely failing to build it. The practical test: if your edited version could plausibly have been made by your marketing team, you have edited too far. Colour-grading to brand palette, adding a logo bug, re-recording audio in brand voice — each moves a clip toward advertising and away from the thing that made it work. If you want the credibility of UGC, use actual UGC and edit it lightly. If you want control, use studio content and let it look like studio content. Both are honest positions, and shoppers respond well to either. What they do not respond well to is a production pretending to be a bedroom. ## Sourcing UGC without waiting for it to appear The passive approach — hoping customers post — produces a trickle. Stores that build a usable library do something more deliberate. **Ask at the right moment.** A request in the delivery confirmation is too early; the customer has not used the product. A request two or three weeks later, when they have formed an opinion, converts far better and produces more useful content. **Ask for something specific.** "Send us a photo" gets little. "Show how it fits — mention your height" gets usable clips, because it tells the customer what would help and removes the burden of deciding what to make. **Make the ask small.** Thirty seconds on a phone, no editing expected. The moment it sounds like a production, most people decline. **Give a reason that is not payment.** Being featured, helping other shoppers decide, or early access to something new all work, and they avoid the credibility problem paid content carries. **Ask people who already posted.** Someone who has publicly praised your product is far more likely to agree to storefront use than a stranger, and the content already exists. > **Rights are not optional and not implied** > > A customer posting publicly has not licensed you to use their video commercially, and tagging your brand is not consent. Get explicit written permission covering storefront use, editing and duration, keep the record somewhere findable in two years, and have a process for taking content down if someone later objects. This is the step most stores skip and the one with actual consequences. ## What most catalogues should do Both, in sequence rather than simultaneously. **Start with what exists.** Search your brand and product names, check tagged mentions, look at what previous campaigns produced. Most stores find more usable UGC than expected, and it is the fastest route to knowing whether video helps your catalogue at all. **Add studio content where UGC cannot answer the question.** Detail shots, mechanism demonstrations, comparisons. Commission narrowly, against specific doubts. **Build the habit of asking.** Customers who post about your products are a renewable source, and a simple, specific request converts far better than a general partnership enquiry. **Measure before expanding.** Add video to a subset of products, matched against comparable products without it, and run it for weeks rather than days. Check Core Web Vitals on both groups at the same time, because video is the heaviest asset you can add to a page and a slower page suppresses the conversions the video was meant to win. A test that moves conversion and page speed simultaneously has told you nothing. The trap at this stage is concluding too fast in either direction. A format that works on your fashion products may do nothing for your accessories, and a single disappointing result on the wrong product category is not evidence that video does not work for your store. Test where images genuinely leave a question open, and exclude products where they do not — otherwise you are measuring video against photography that was already doing the job. For placement and page-weight considerations, see [video commerce and UGC](/category/video-commerce-ugc). App selection is covered in [Shopify apps](/category/shopify-apps). **Both formats, shoppable, on your storefront** SwipeReel turns UGC and studio video into shoppable feeds — carousels, stories, grids and product-page placements with tap-to-buy inside the video. [See SwipeReel on the Shopify App Store](https://apps.shopify.com/swipereel) ## FAQ ### Does UGC convert better than professional video? For demonstrating real-world use, fit and scale, generally yes, because it visibly is not a production and reads as credible. For showing detail, finish and construction, professional video is better. ### Is UGC cheaper than studio video? The footage is, and the total often is not. ### Can I make studio video look like UGC? Rarely convincingly, and the attempt tends to produce the worst of both. Shoppers detect it quickly, and content that reads as fake authenticity is worse than content that is honestly polished. ### Where should each type go on a product page? Studio video near the gallery, where someone is evaluating the product itself and wants detail. ### How much UGC do I need before it is worth doing? Enough to cover your commercially important products, which is usually five to ten clips to start. --- --- title: "The Shopify App Stack a New Store Actually Needs" description: "Every app you install is a monthly cost, a page-weight cost and a dependency. On a new store you have no data to justify any of them yet." author: "Aashish Kaushik" published: 2026-10-15T13:00:56.498Z updated: 2026-10-15T13:00:56.503Z url: https://blog.byteinfy.com/shopify-app-stack-for-new-stores --- # The Shopify App Stack a New Store Actually Needs ## Key takeaways - A new store has no traffic data, so most app decisions at launch are guesses — defer everything that optimises something you cannot yet measure. - Four categories genuinely earn a place on day one; almost everything else can wait until you have real behaviour to act on. - Apps you install and abandon frequently leave code in your theme, so trialling freely has a cost that outlasts the trial. - Shopify covers more natively than most new merchants realise, and the first check should always be whether the platform already does it. The App Store is the first place new merchants go and the easiest place to accumulate cost. Everything looks useful, most have free tiers, and installing is one click. The problem is that a new store has no data. Nearly every app in the optimisation categories exists to improve something you cannot yet measure, and configuring one against assumptions produces a setting you will never know was wrong. > **The default should be no** > > Not because apps are bad, but because on a new store the burden of proof is on installation. If you cannot say what an app is doing and how you will know it worked, defer it. ## What Shopify already does Check this first, every time. It eliminates several categories. Natively, without any app: discounts including buy X get Y and tiered thresholds, basic email marketing and abandoned checkout recovery, gift cards, sitemaps and canonical tags, multi-currency and multi-market selling, product reviews on some plans, and a reasonable analytics baseline. New merchants routinely pay for apps in these categories because the App Store markets them and the platform does not. Look at what you have before adding to it. ## The four that usually earn day one **Email marketing.** The strongest case for installing something immediately. Owning a list is one of the few assets that compounds from day one, and starting late means the customers you acquire in the first months are lost to you. Shopify's own email is adequate to begin. **Whatever your selling mechanic requires.** If your model depends on subscriptions, bundles, or booking, that is not an optimisation — it is the business. Install it. **Shipping or fulfilment**, if your logistics are non-standard. Multiple locations, unusual rates, or a specific carrier integration. **Regional necessities.** COD handling, local payment methods, and tax or invoicing requirements. In markets like India these are not optional, and trying to trade without them is not a lean approach but a broken one. ## Install now, or wait | Category | Day one? | Why | | --- | --- | --- | | Email marketing | Yes | The list compounds; starting late loses customers | | Core selling mechanic | Yes | It is the business, not an optimisation | | Shipping, if non-standard | Yes | Blocks fulfilment otherwise | | Regional compliance | Yes | Not optional where it applies | | Reviews | Wait | You have no customers yet | | Upsell and cross-sell | Wait | Needs order data to recommend well | | Popups | Wait | Optimising traffic you do not have | | Loyalty | Wait | Needs repeat customers to reward | | Analytics add-ons | Wait | Shopify's baseline covers early questions | | Page builders | Maybe | Only if your theme genuinely blocks you | ## Why waiting is not just caution Three concrete reasons, beyond saving money. **You cannot evaluate what you install.** With no baseline, an app's effect is unmeasurable. You will keep it because it seems fine, which is how stores accumulate subscriptions nobody can justify three years later. **Apps configured against assumptions are usually configured wrong.** A recommendation engine with no order history recommends badly. A popup with no traffic data fires at the wrong moment. Both improve once you have data, and neither does anything useful before then. **Every app is weight on pages that convert.** A new store's best asset is speed, because it has nothing installed yet. Spending that advantage on features you cannot measure is a poor trade. ## The uninstall problem The reason casual trialling costs more than it appears. Uninstalling an app does not always remove its code from your theme, particularly for older apps that inject snippets directly rather than using theme app extensions. Stores routinely carry the residue of apps they stopped paying for years ago — scripts still loading, still costing page weight, doing nothing. ## Before installing anything - Confirm Shopify does not already do it - Say out loud what it will do and how you will know it worked - Check whether it uses theme app extensions or injects into theme files - Measure page speed before installing - Note the date, so you remember to evaluate it - Ask what happens to your data and your theme if you uninstall The last item is worth asking explicitly. Some apps store data in their own systems and render it dynamically, which means uninstalling strips content you created. Others write to Shopify's native fields, which persist. That difference determines whether you can leave. ## What to do at three months By then you have data, and the questions become answerable. **Look at what your traffic actually does.** Where people leave, what they do not find, which products get attention. That behaviour tells you which optimisation category to add first, and it will frequently not be the one you assumed. **Add one app at a time**, and measure the result. Two installed simultaneously means neither result is attributable to either. **Audit what you already installed.** Anything you cannot point at should go, and it should go properly — check the theme afterwards. **Check page weight.** Open a product page in DevTools, filter to JS, sort by size, and look at what has accumulated. This takes five minutes and is the single most useful periodic check a Shopify merchant can run. ## Judging an app before you install it Listing pages are marketing. A few checks take minutes and eliminate most poor choices before they touch your store. **Read the recent reviews, not the average.** A four-and-a-half star average built over five years tells you little about the app today. The last twenty reviews tell you whether it still works, whether support responds, and what breaks. **Look at how the developer answers criticism.** Public replies to negative reviews are visible on every listing, and they are the best available signal about what support will be like when you need it. A developer who argues with merchants in public will not be better in private. **Check the update history.** An app last updated two years ago on a platform that ships continuously is an app whose compatibility you are inheriting. **Look at the pricing tiers, and where you will land.** Free tiers are usually metered on something — orders, views, products — and the meter determines when you are forced to upgrade. Work out which tier your realistic volume puts you in before you build a workflow on the free one. **Check what permissions it requests.** An app asking for access far beyond its function is worth questioning. This is a security consideration and also a data one, since you are handing over customer information. > **Trials are for testing the software, not the tactic** > > Seven to fourteen days is enough to evaluate an admin interface and nowhere near enough to know whether a mechanic makes money. Merchants routinely conflate the two, conclude an app "did not work", and switch to a competitor that produces the same result for the same reason. Test the software during the trial; test the tactic over months. ## When a custom build beats an app Not the first answer for a new store, but worth knowing the threshold. Apps make sense when the function is standard and the cost is low relative to building. That covers most needs most of the time. Custom work starts to make sense when several conditions coincide: you are paying for three or four apps to achieve one outcome, the apps conflict with each other, the function is genuinely specific to how you sell, or the monthly cost has grown to where a build pays back within a year or two. The trigger most merchants notice first is conflict rather than cost. When two apps are fighting over the cart and both vendors point at the other, replacing both with one piece of logic that does exactly what you need stops being expensive and starts being obvious. For a new store, none of this applies yet. But it is worth knowing that the app stack is a stage rather than a permanent arrangement, and that accumulating apps indefinitely is not the only path. ## The mistake that costs the most Installing several apps in the same category, or apps whose functions overlap. Two apps both touching the cart will eventually disagree. Two analytics tools will report different numbers and you will not know which to trust. Two apps both injecting popups will show a customer two popups. The failure mode is not usually dramatic. It is a slow accumulation of small conflicts that nobody attributes to anything, until a merchant concludes their store is inexplicably slow and their numbers do not reconcile. One app per job. If a new app overlaps with an existing one, remove the old one before adding the new one, not afterwards. Running both "just while we compare" is how stores end up with two permanently. The comparison never concludes, nobody wants to be the person who removed the wrong one, and a year later you are paying twice for a function you use once. Pick one, remove the other, and accept that you may occasionally choose wrongly — that is cheaper than carrying both. For app selection within specific categories, see [Shopify apps](/category/shopify-apps). The page-weight consequences are covered in [storefront and design](/category/storefront-design). **Building a store rather than assembling one** ByteInfy designs and builds Shopify storefronts and the custom pieces that replace an app stack — with the performance budget kept intact. [Start a project](https://byteinfy.com/#contact) ## FAQ ### How many apps should a new Shopify store have? Fewer than most start with. Four or five covering genuinely necessary functions is a reasonable launch position. ### What apps does every Shopify store need? Very few are universal. Email marketing is close, since owning a list matters from day one. ### Should I install apps before or after launching? Install what is genuinely necessary to trade, launch, and add the rest once you have real behaviour to act on. ### Do free Shopify apps have hidden costs? The subscription is not the only cost. Apps add page weight, create dependencies, and frequently leave code in your theme after uninstall. ### What does Shopify do natively that people install apps for? More than most new merchants realise — discounts including buy X get Y, basic email, abandoned checkout recovery, sitemaps and canonical tags, gift cards, and multi-currency selling. --- --- title: "Unified Commerce on Shopify: Online and Retail as One" description: "Integrated systems exchange data and disagree. A unified system has one record. The difference only becomes obvious when something goes wrong at the counter." author: "Aashish Kaushik" published: 2026-10-15T05:00:54.980Z updated: 2026-10-15T05:00:54.983Z url: https://blog.byteinfy.com/shopify-unified-commerce --- # Unified Commerce on Shopify: Online and Retail as One ## Key takeaways - Integration synchronises separate systems; unification means there is only one record, and only the second removes reconciliation work. - The benefit shows up in the awkward transactions — cross-channel returns, exchanges, and the customer who exists in one system and not the other. - Inventory across several locations is where unified commerce gets genuinely complicated, and it needs deliberate configuration. - It is only worth the switching cost if you have real cross-channel activity; a purely offline shop gets very little from it. Unified commerce is a phrase used loosely enough to mean almost nothing. Used precisely, it describes something specific and worth understanding before evaluating whether you need it. **Integrated** systems remain separate and exchange data. Two sources of truth, a sync between them, and a reconciliation problem whenever they disagree — which is whenever the sync is delayed, partial, or wrong. **Unified** systems have one record. There is nothing to synchronise because there is nothing to synchronise between. That difference sounds academic until something goes wrong at a counter with a customer waiting and a queue behind them. > **Where the difference shows** > > The value is not in the ordinary transaction, which both architectures handle. It is in the awkward ones, which is where integrated systems generate manual work. ## The awkward transactions A customer bought online, comes into the shop to return, and wants a different size that the shop does not have but the warehouse does. On integrated systems: look up the order in one place, process a return in another, check warehouse stock somewhere else, create a new order, and reconcile the payment difference manually. Several steps, several opportunities for divergence, and a queue forming behind them. On a unified system: one interaction, against one customer record, with inventory that moves correctly because there is only one inventory. Multiply that by every edge case real retail produces — gift receipts, partial returns, exchanges across channels, a customer who exists in one system but not the other, stock transfers between locations — and the difference stops being about elegance and becomes about how much of your week is reconciliation. ## What Shopify actually unifies Being specific is useful here, because the marketing is broader than the reality. ## What is genuinely shared, and what is not | Area | Unified | Notes | | --- | --- | --- | | Product catalogue | Yes | One catalogue serves online and retail | | Customer records | Yes | One customer, whichever channel they used | | Inventory | Yes, with configuration | Multi-location needs deliberate rules | | Orders | Yes | One order history across channels | | Discounts | Largely | Some are channel-specific by design | | Reporting | Yes | One set of reports across channels | | External systems | No | Anything outside Shopify reintroduces a boundary | That bottom row matters. A merchant running Shopify for commerce and a separate ERP, accounting package or warehouse system has unified part of the estate and integrated the rest. That is usually the right answer, and it means the reconciliation problem has moved rather than disappeared. ## Inventory is where the complexity actually lives Sharing one inventory pool sounds simple and is the part that needs the most thought. **Which locations can fulfil online orders?** Your shop floor stock is visible to the system, but selling it online means someone picking from the shop, which competes with walk-in customers. **How is stock allocated between channels?** Without rules, an online order can take the last unit of something a customer is holding in a shop. **What is a safety buffer?** Many retailers hold back a quantity at each location so the floor does not sell out from under itself. **How do transfers work?** Moving stock between locations, and what the system shows during the transit. These are business decisions the platform cannot make for you, and they are the ones that determine whether unification feels smooth or produces daily arguments between channels. The argument is always the same one: the shop floor believes online is selling stock they are standing next to, and online believes the shop is hoarding inventory that could be shipped today. Both are sometimes right. Settling the allocation rule explicitly, in advance, with both sides in the room, is worth considerably more than any amount of configuration work afterwards. ## What the 2026 releases added Several retail changes through 2026 strengthened the unified position specifically. **Mixed fulfilment**, letting one order combine ship-to-home and in-store pickup items. This resolves a genuinely common customer request that previously meant two orders. **Multiple legal entities from one store**, so a business operating retail and online under different companies no longer needs a separate Shopify instance for each. That workaround was one of the more common reasons merchants ran parallel stores, with all the reconciliation pain it implied. **Returns and exchanges in one cart**, handling refund, exchange and new sale as a single workflow rather than separate transactions that can succeed and fail independently. **A rebuilt checkout** cutting substantial time from transactions, and a built-in cash ledger handling reconciliation and reason codes on the device. Read together, these address the specific friction points where unified commerce previously still required manual work. ## When it is not worth it The honest boundary. **A purely offline single shop.** The entire benefit is removing friction between channels. With one channel there is no friction to remove, and a POS built for local retail requirements — billing formats, tax handling, regionally available hardware — will fit better. **Deep vertical requirements.** Pharmacy dispensing, serialised goods, complex rentals, service scheduling. Shopify POS is broad rather than deep, and a specialised system will serve those better. **Heavy reliance on an external system that will not move.** If your ERP remains the source of truth for inventory, you have an integration regardless of what the storefront runs on. **Many small locations.** POS Pro is priced per location, so a footprint of kiosks, concessions and seasonal pop-ups compares unfavourably against systems that charge per terminal instead. ## Before committing to unification - Count your genuinely cross-channel transactions — is the friction real? - Decide inventory allocation rules between online and each location - Confirm payments and hardware for every market you operate in - Identify external systems that will remain, and where the boundary sits - Model POS Pro cost against your location count, not your staff count - Plan staff training around the awkward transactions, not the simple ones ## The customer record is the underrated half Inventory gets the attention because it has obvious financial consequences. The customer record is where the day-to-day benefit actually accumulates, and it is discussed far less. In a unified system, the person standing at your counter is the same record as the person who bought online last month. That has consequences that compound: **Staff can see purchase history.** A customer asking about something they bought previously does not have to remember what it was, and staff can answer without a phone call to whoever handles online orders. **Returns do not require proof in the same way.** The order is in the system regardless of where it was placed, which removes a category of dispute entirely. **Marketing stops double-counting.** One customer with a complete history, rather than two partial records that inflate your customer count and fragment your segmentation. **Loyalty works across channels**, which is the point of loyalty and something integrated systems handle poorly. There is a data quality dimension worth planning for. Unification only works if customers are actually recognised, which means staff capturing an identifier at the counter — usually a phone number or email. If they do not, in-store sales accumulate as anonymous transactions and you have unified the architecture without unifying the data. That is a training and incentive question rather than a technical one, and it is the most common reason a unified system produces disappointing customer data in its first year. Decide how staff will ask, make it fast, and give customers a reason to say yes. > **Watch the identified-transaction rate** > > Track what proportion of in-store transactions are attached to a customer record. It is the single best indicator of whether unification is delivering on the customer side, it is available from day one, and a low number tells you the problem is at the counter rather than in the configuration. ## Doing it without breaking the shop If you decide to unify, the sequencing matters more than the configuration. **Run one location first.** The benefit is real and it changes daily workflow, which makes staff adoption a genuine risk rather than a formality. **Write down your five most awkward current transactions** and test each one before committing. Those are what you are buying a fix for, and they are more informative than any feature list. **Set permissions before launch.** Who can discount, refund, or open the drawer. Retrofitting this onto a store where everyone shares a manager login is much harder than doing it once at the start. **Expect a slower first fortnight.** A queue forming while someone learns the interface is how a good system acquires a bad internal reputation, and internal resistance is harder to reverse than a configuration error. **Keep the old system readable for a while.** Not running, but accessible. Historical orders, customer notes and reports that did not migrate will be needed at some point, usually by someone handling a return for a purchase made before the switch. Deciding what to export before you decommission anything is far cheaper than discovering the gap six months later. For the platform detail and pricing, see [POS and operations](/category/pos-operations). Inventory across channels is covered in the same archive, and the India-specific considerations alongside it. **Running retail and online and still reconciling them?** ByteInfy builds Shopify integrations for inventory, fulfilment and the operational reporting the admin does not provide. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What is unified commerce? Running every sales channel from one system with one catalogue, one customer record and one inventory pool, rather than several systems exchanging data. ### How is unified commerce different from integration? Integration keeps two systems and synchronises them, which means two sources of truth that can disagree, a sync that can fail, and reconciliation work when they diverge. Unification means one record exists. ### Does Shopify actually deliver unified commerce? For online and retail, largely yes — the catalogue, customer records and inventory are genuinely shared rather than synchronised. ### Is unified commerce worth it for a small retailer? Only if you sell through more than one channel. ### What breaks when you unify? Usually inventory rules and existing integrations. --- --- title: "Gift With Purchase on Shopify: Setup and Pitfalls" description: "A free gift is easy to promise and awkward to deliver. The gift has to enter the cart itself, at zero cost, without becoming something people can order on its own." author: "Aashish Kaushik" published: 2026-10-14T13:00:57.481Z updated: 2026-10-14T13:00:57.515Z url: https://blog.byteinfy.com/gift-with-purchase-shopify --- # Gift With Purchase on Shopify: Setup and Pitfalls ## Key takeaways - Native Shopify discounts reduce the price of something already in the cart — they do not add a gift, which is why this mechanic usually needs an app or Functions. - The gift must not be independently orderable, or you will ship free products to people who bought nothing. - Inventory is the most common failure: the gift is consumed by demand for other products, at a rate nobody forecast. - Decide in advance what happens when the cart drops below the threshold after qualifying, because shoppers do remove items. Gift with purchase is one of the more effective ways to raise average order value, and one of the more technically demanding to implement properly. The reason is a specific gap in the platform. Shopify's native discounts reduce the price of things already in the cart. A gift is not in the cart — it has to be put there, automatically, at zero cost, without becoming a product anyone can order on its own. That gap is where the implementations live, and where they break. > **Why the mechanic is worth the trouble** > > A gift costs you one item. A percentage discount costs you a share of every order. The perceived generosity is often higher and the margin cost lower, which is why this mechanic survives scrutiny better than most. ## What native discounts can and cannot do Native discounts can reduce the price of a product the shopper has added. So the manual version of this offer is: tell the shopper to add the gift, and configure a discount that makes it free when the threshold is met. That works technically and fails commercially. Most shoppers will not find and add a product to receive it free — the friction is small and the completion rate is poor. Merchants conclude the offer did not resonate, when what actually happened is that the offer was never taken up. Automatic insertion is what makes this mechanic work, and it requires either an app or custom logic through Shopify Functions. ## An app or Shopify Functions: how to decide Both routes solve the automatic-insertion problem. They suit different stores, and the wrong choice tends to surface months later rather than immediately. A gift-with-purchase app is the faster route to live. Configuration happens in an admin screen rather than in code, the threshold and gift product are set through a form, and most of the edge cases in this article, like removing the gift when the cart drops below threshold, are handled by the app rather than something your team has to build and test. The cost is the usual one for any app: it loads its own script on storefront pages, it is a dependency you do not control, and its logic runs alongside checkout in a way you can configure but not inspect line by line. Shopify Functions, run at checkout inside Shopify's own infrastructure, is the route for stores with development capacity and a mechanic complex enough that an app's configuration screen cannot express it cleanly. Tiered gifts, gifts that vary by customer segment, or gift logic that has to interact with other custom discount rules are easier to get exactly right in code you control than to coax out of a generic app interface. Functions also avoid the storefront script weight an app carries, since the logic runs at checkout rather than in the browser. The deciding question is usually not preference but scale and duration. A single seasonal gift offer, run once and retired, rarely justifies custom development, and an app that gets uninstalled afterwards costs little. A gift mechanic that is becoming a permanent fixture of how the store merchandises, running continuously with several variations, is exactly the kind of dependency that is worth owning outright, for the same reason argued elsewhere in this series about apps that become essential: paying for custom logic now is often cheaper than discovering the app's ceiling later, at a point you did not choose. A reasonable middle path for a store unsure which category it is in: launch on an app to validate that the offer works and the threshold is right, then decide whether to move the proven mechanic to Functions once it has run a full season and the business case for owning it is no longer a guess. ## The gift must not be independently orderable The failure that costs actual money, and it is more common than it should be. If the gift exists as a normal product in your catalogue at zero or near-zero price, someone will find it and order it on its own. Then they will tell people. You will ship free products to customers who bought nothing. The approaches that prevent it: **Hide it from navigation and search.** Not in any collection, not surfaced by search, no direct link. Weakest option alone, since the URL still resolves. **Give it a real price** that only the offer logic overrides. If someone orders it directly they pay for it, which removes the incentive entirely. **Use a dedicated variant** that is not exposed publicly and exists only for the offer. Whichever route, test it: try to find and buy the gift on its own before the campaign goes live, using search, direct URL and every collection. This takes two minutes and prevents the most embarrassing version of this failure. ## Inventory is where gift campaigns actually break The gift is consumed by demand for *other* products. If the threshold is easy to hit, every large basket is effectively ordering one. That means the gift depletes at a rate your ordinary forecast does not describe, and because it was never the point of the campaign, nobody is watching it. ## Inventory preparation for a gift offer - Set a stock alert on the gift, at a level that gives you time to react - Decide in advance what the offer does at zero — stops, substitutes, or oversells - Estimate demand from the share of orders likely to exceed the threshold - Over-order deliberately if the gift is cheap, since the asymmetry favours surplus - Confirm the gift is not also being sold or given through another campaign - Name someone responsible for watching it during the campaign The out-of-stock behaviour is the item merchants most often have not decided. All three outcomes are defensible; discovering which one your setup does at 2am during a promotion is not. ## The edge cases that generate support tickets Four scenarios worth testing explicitly, because each produces a confused customer. **The cart drops below the threshold after qualifying.** The shopper qualifies, the gift is added, then they remove an item. The gift should be removed too. If it is not, you are shipping free products with unqualified orders. **The shopper removes the gift.** Some will, either not wanting it or assuming it is a mistake. Decide whether they can add it back, and make that possible. **Two offers qualify at once.** A gift offer and another promotion in the same cart. Shopify's rules about combining discounts apply, and the outcome should be tested rather than assumed. **A partial return.** The customer returns enough that the order no longer qualifies. Do you reclaim the gift, absorb it, or adjust the refund? Decide before the first return arrives, because this question comes up without fail and answering it ad hoc produces inconsistent decisions. That last one is worth writing into your returns policy explicitly. Customers who read it in advance rarely dispute it; customers told after the fact frequently do. ## Choosing the gift The commercial decision, and it is more consequential than the technical one. **Cheap for you, desirable to them.** The gap between cost and perceived value is the entire economics of the mechanic. A sample, a travel size, an accessory that would be bought anyway. **Relevant to what they are buying.** A gift unrelated to the purchase reads as clearing stock, because it usually is. **Not something they would otherwise buy.** Giving away a product with real standalone demand cannibalises it, and you lose the sale you would have had. **Small enough to ship without changing the parcel.** A gift that pushes the order into a higher shipping band eats its own margin. **In genuine supply.** Running out halfway through a campaign is considerably worse than never having run the offer at all. ## Communicating the offer across the store A gift offer nobody notices performs like no offer at all, and native discounts announce nothing until the cart. Where the offer appears is as much of the implementation as the logic. **Product page.** A line on qualifying products stating the offer. This is where the add-to-cart decision happens, and it is the highest-value placement. **Collection pages.** A flag on qualifying products creates discovery while browsing, before the shopper has committed to any single item. **Cart, with distance to the threshold.** The single most important surface for this mechanic, because it converts an abstract offer into a specific, small next step. **The gift line itself.** When the gift is added, it should be visibly free and visibly a gift, not a mysterious zero-value line item. Shoppers who cannot tell what a line is will remove it. **Order confirmation.** Listing the gift explicitly reduces "was my gift included" contacts, which are otherwise a reliable feature of these campaigns. The rule worth following throughout: drive the messaging from the same source as the offer logic — the collection, the metafield, the date range. Offer messaging left visible after a campaign ends is a common and damaging error, and wiring the two to one source makes it impossible. ## Measuring whether it worked Gift campaigns produce flattering reports, because orders containing the gift are by definition orders above the threshold. That number always looks good. The question is whether average order value rose, or whether you gave gifts to people who were already spending that much. Answering it requires a comparison — a matched period before the campaign, or a control group of customers not shown the offer. Two numbers worth watching together. **Average order value** tells you whether baskets grew. **Revenue per visitor** tells you whether that growth was real or whether it came with a conversion cost. A campaign that raises the first and lowers the second has made your orders bigger and your business smaller. Also track the gift's cost as a share of the incremental revenue it generated, not as a share of total revenue on qualifying orders. The second number is meaninglessly flattering; the first tells you whether to run it again. ## Setting the threshold The threshold does the work, so it should come from your data rather than a round number. Look at your current average order value and the distribution around it. A threshold slightly above the point where most orders currently land gives a meaningful share of shoppers a reachable reason to add one more item. A threshold far above it is invisible to most of your traffic and only rewards customers who were already spending that much. The second failure is the more common and the more expensive: a high threshold gives free gifts to your best customers for behaviour they were already exhibiting. > **Show the distance, not the destination** > > "You are ₹400 away from a free gift" outperforms "Spend ₹2,000 for a free gift", because the first is specific to this shopper's current basket. If you build one thing beyond the core mechanic, build the progress indicator — it is where most of this offer's uplift actually comes from. For the wider offer strategy and margin arithmetic, see [promotions and offers](/category/promotions-offers). App selection is covered in [Shopify apps](/category/shopify-apps), and the inventory side in [POS and operations](/category/pos-operations). **Gift logic that behaves at checkout** ByteInfy builds Shopify offer mechanics with Functions — automatic gifts, threshold logic and stacking rules that hold through accelerated checkout. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Can I do gift with purchase on Shopify without an app? Not straightforwardly. Native discounts reduce the price of items already in the cart; they do not insert a product. ### How do I stop people ordering the free gift on its own? The gift should not be a normally purchasable product. ### What happens if a customer removes items after qualifying for the gift? That depends on your implementation, and many merchants have never checked. The gift should be removed automatically when the cart no longer qualifies. ### Does the free gift affect my inventory? It should, and this is where most gift campaigns come unstuck. ### Is gift with purchase better than a discount? Usually for margin, yes. A gift costs you the item, while a percentage discount costs you a share of every order. --- --- title: "Image Alt Text for Shopify SEO, Done at Scale" description: "A store with 800 products has thousands of images. Alt text written one at a time never finishes, and rules applied blindly produce keyword soup." author: "Aashish Kaushik" published: 2026-10-13T13:01:03.086Z updated: 2026-10-13T13:01:03.126Z url: https://blog.byteinfy.com/shopify-image-alt-text-seo --- # Image Alt Text for Shopify SEO, Done at Scale ## Key takeaways - Alt text is a scale problem — most catalogues have several times more images than products, so a per-image workflow never completes. - Good alt text describes what the image shows, which is also what accessibility requires and what machines can use. - Rules-based generation works for the long tail, but the products that matter commercially deserve hand-written descriptions. - Decorative images should have empty alt attributes, not descriptions, and this distinction is routinely got wrong. Alt text advice is usually written as though you have one image. Add descriptive alt text, include your keyword naturally, done. A Shopify store with eight hundred products has several thousand images. At that scale, the advice is not wrong so much as unusable — a per-image workflow never finishes, and it decays continuously as new products arrive without it. Treating this as a bulk problem is the only way it gets solved. > **Two audiences, one job** > > Alt text serves people using screen readers and machines reading your catalogue. Fortunately they want the same thing: an accurate description of what the image actually shows. Writing for accessibility produces the better SEO outcome as a side effect. ## What good alt text says The rule is simple and widely ignored: describe what the image shows. **Useful:** "Navy wool overcoat on a model, showing length at mid-calf." Someone who cannot see it now knows what it depicts. **Useless:** "navy coat mens coat winter coat buy coat online." This is keyword stuffing. It helps no reader, is transparent to search engines, and actively degrades the experience for screen reader users. **Also useless:** "coat.jpg", or "product image", or an empty alt attribute left on a meaningful image. The test worth applying: would someone who cannot see the image understand what it depicts? If yes, it is good alt text, and the relevant terms will appear naturally because you are describing a product that is what it is. ## Different images need different descriptions The failure that automation causes and that hand-writing avoids: giving every image of a product the same alt text. A product with six images has six different pictures. The alt text should differ, because the images differ: ## Image type and what its alt text should say | Image | Alt text should describe | | --- | --- | | Main product shot | The product, plainly, with key visual attributes | | On a model or in use | Who or what is using it, and how it appears | | Scale reference | The reference and what it establishes | | Detail or texture | Which part is shown, and what is visible | | Contents or packaging | What is included and visible | | Colour variant | The specific colour, named as customers name it | Six identical descriptions tell a screen reader user that they have looked at the same photograph six times, which is a worse experience than no alt text at all. ## Decorative images should have empty alt This distinction is routinely got wrong in the direction of over-describing. Background textures, ornamental dividers, spacer images and purely decorative graphics should carry an empty alt attribute — `alt=""`. That tells assistive technology to skip them entirely. Describing decoration is not helpful thoroughness. It forces screen reader users to listen to "decorative gradient background" and similar, which is noise between the things they actually need. The judgement is whether the image conveys information. If removing it would lose the reader something, describe it. If not, empty it. ## Scale: rules for the tail, hands for the head The workable pattern for a large catalogue is to split it. **Hand-written for commercially important products.** Your best sellers, your highest-margin items, anything you are actively promoting. These deserve per-image descriptions, because a rule cannot know that image four shows the interior lining. **Rule-generated for the long tail.** Templates built from product fields — type, colour, vendor, title — produce reasonable descriptions at volume. Not as good as hand-written, considerably better than nothing, and they apply to thousands of images in one operation. **Automatic for new products.** This is the part that stops the problem returning. A rule applied on creation means new products launch with alt text instead of joining the backlog. ## An alt text programme that finishes - Audit how many images currently lack alt text — the number is usually larger than expected - Identify the products that matter commercially and hand-write those - Build rules from product fields for everything else - Preview what a rule produces before applying it across the catalogue - Set the rule to apply to new products automatically - Mark decorative images with empty alt rather than describing them - Re-audit quarterly, since gaps reopen The preview step matters. A rule applied blindly across a catalogue can produce thousands of images described as "Untitled colour variant", and undoing that is more work than doing it properly the first time. ## A worked example of building a rule template Rule-based alt text works by combining product fields into a sentence pattern, and the difference between a usable rule and a poor one is usually in the small joins rather than the fields chosen. A first attempt often looks like this pattern: product title, followed by colour, followed by product type. Applied to a product titled "Classic Overcoat" in the colour "Navy" and type "Coat", that produces "Classic Overcoat Navy Coat", which is readable but repeats information awkwardly when the title already contains a descriptive word close to the type, and it says nothing about which of the six images this particular one is. A better pattern adds a connecting phrase and an image-position element: product title, then "in", then colour, then a phrase describing the image position such as "front view" or "detail" drawn from where the image sits in the product's image list. Applied to the same product, the first image produces "Classic Overcoat in Navy, front view" and the fourth might produce "Classic Overcoat in Navy, detail". This is not as specific as a hand-written description noting that the fourth image shows the interior lining, but it correctly signals that the images differ, which is the main failure the earlier section warns against. The pitfall to check for before applying a rule across a whole catalogue: products whose title already includes the colour, which produces an awkward doubled phrase like "Navy Overcoat in Navy". A rule builder that lets you preview against a sample of products, including a few with unusual titles rather than only the tidy ones, catches this before it repeats across thousands of images. Products with missing or placeholder values in any field the rule references are the other common failure, since a blank colour field produces a sentence with a visible gap, such as "Classic Overcoat in , front view", which reads worse than having no rule at all. The general principle carries beyond this specific example: a rule template is only as good as the data behind it, and the preview step exists specifically to surface the rows where that data is missing or unusual before the rule runs on all of them at once. ## Why this matters more than it used to Alt text has always been an accessibility requirement and a modest image search factor. Two things have increased its practical value. **Product data feeds more channels.** Since Shopify's Summer '26 release, eligible product data syndicates automatically to several AI shopping surfaces. Those systems read fields. An image with no description is one less piece of information about what a product is. **Image-heavy catalogues carry information nowhere else.** Many stores publish material, dimensions and detail primarily through photography. If the images are undescribed, that information exists only visually and is unavailable to every system reading the page. Neither makes alt text a major ranking lever on its own. Both make it part of a data completeness picture that does matter, and that pays across classic search, shopping feeds and AI surfaces at once. ## The accessibility case stands on its own It is worth separating this from the SEO argument, because the SEO argument is modest and the accessibility one is not. People using screen readers navigate a store through its text. On a product page, the images are the product — the colour, the fit, the texture, what it actually looks like. Without descriptions, a shopper using assistive technology reaches a page containing a title, a price and six unlabelled graphics, and has no way to evaluate what they are considering buying. That is a customer who cannot buy from you, and in many jurisdictions it is also a compliance question. Accessibility requirements for commercial websites have tightened in several markets, and image descriptions are among the most basic expectations. The practical consequence for how you approach this: **write for the person, not the crawler.** Every piece of advice above follows from that. Describe what is shown. Differentiate images that differ. Skip decoration. Do not stuff keywords. Each of those is an accessibility rule first, and each produces the better SEO outcome as a by-product. Merchants who approach alt text as an SEO task produce keyword lists that fail both audiences. Merchants who approach it as description produce text that serves shoppers, screen readers, image search and AI systems simultaneously — which is a rare case of one piece of work satisfying every requirement at once. > **Test it the way it is used** > > Turn on VoiceOver or NVDA and navigate one of your product pages without looking at the screen. Ten minutes of this teaches more about what your alt text should say than any amount of guidance, and it makes the difference between good and bad descriptions immediately obvious. ## The filenames question Related and lower priority. Descriptive filenames — `navy-wool-overcoat.jpg` rather than `IMG_4471.jpg` — contribute modestly to image search and cost nothing when handled in bulk. Worth doing as part of the same pass if your tooling supports it. Not worth a separate project, and not worth renaming files on a live store without checking what references them. Two cautions specific to renaming. Images referenced directly in theme code, email templates or app configuration will break if their filenames change, and the breakage is silent — an image simply stops appearing somewhere nobody is looking. And renamed images lose whatever image search history the old filename accumulated, which for an established store is a real if small cost. Rename new uploads by default and leave established ones alone unless the current names are genuinely useless. Image compression belongs in the same conversation. It rarely fixes a slow store on its own, since Shopify already serves images through its CDN with sensible defaults, but doing it during a bulk alt text pass costs almost nothing extra and removes one variable from any later performance investigation. ## A sequence that works 1. Audit the gap. How many images have no alt text, and which products are affected. 2. Hand-write the products that matter. Usually a small fraction of the catalogue. 3. Build and preview rules for the remainder. 4. Apply in bulk, then spot-check the output. 5. Set rules to run on new products, so the gap does not reopen. 6. Handle decorative images with empty alt attributes. 7. Re-audit quarterly. Step five is what makes this a solved problem rather than a recurring one. Without it, every alt text project is a one-off cleanup that begins decaying the moment it finishes, and you will be running the same audit again in a year. For the wider product data picture, see [SEO and AI search](/category/seo-ai-search). Image weight and page speed are covered in [storefront and design](/category/storefront-design). **Alt text across a whole catalogue, in one pass** ByteInfy's Alt Text Bulk Edit writes alt text with automation rules, plus WebP, JPEG and PNG compression and SEO file renaming — the bulk half of image SEO. [See it on the Shopify App Store](https://apps.shopify.com/byteinfy-alt-text-editor) ## FAQ ### What should Shopify alt text actually say? Describe what the image shows, specifically. "Navy wool overcoat photographed on a model, showing the length at mid-calf" is useful. "navy coat mens coat winter coat buy coat" is keyword stuffing and helps nobody. ### Does alt text affect Shopify SEO? It contributes to image search, gives context about the page content, and is required for accessibility. It is not a major ranking lever on its own. ### Should every image have alt text? Every meaningful image should. Purely decorative images — background textures, spacers, ornamental dividers — should have an empty alt attribute, which tells screen readers to skip them. ### Can I automate alt text generation? For the long tail, sensibly yes. Rules built from product fields — title, colour, type — produce reasonable descriptions at scale and are far better than nothing. ### How long should alt text be? Long enough to describe the image and no longer. A sentence is usually right. --- --- title: "OTP Verification for Shopify COD Orders" description: "An order placed with an unreachable number was never going to be delivered. OTP verification removes those before you pay to ship them anywhere." author: "Aashish Kaushik" published: 2026-10-13T05:01:02.673Z updated: 2026-10-13T05:01:02.713Z url: https://blog.byteinfy.com/shopify-cod-otp-verification --- # OTP Verification for Shopify COD Orders ## Key takeaways - The largest single category of COD failure is orders placed with a number that was never reachable, and OTP addresses it directly. - Conversion will fall slightly, and that is the mechanism working — judge on delivered revenue, never on conversion rate. - Delivery speed is the implementation detail that decides whether genuine buyers abandon at the step. - WhatsApp usually outperforms SMS on speed and open rate in markets where it dominates messaging. Return-to-origin gets discussed as a logistics problem, and the largest single cause is not logistical at all. It is that a substantial share of COD orders are placed with a phone number nobody answers. Not fraud in any dramatic sense. A mistyped digit. A number entered to get past a required field. An impulse order at midnight, forgotten by morning, placed by someone who never expected the parcel to arrive. The courier cannot reach anyone, the parcel comes back, and you have paid shipping in both directions on an order that never had a chance. > **Scope** > > Written for COD-heavy markets, particularly India, where COD is a majority payment method rather than an edge case. ## What OTP actually removes The shopper enters a phone number, receives a code, and enters it before the order is placed. It is a small step and it filters a specific and large category. An order that clears OTP has three properties a courier needs: **The number works.** No typos, no placeholder, no digit missing. **The person was present.** They had the phone in hand at the moment of ordering, which rules out numbers entered from memory incorrectly or belonging to someone else. **They were paying attention.** Completing a verification step requires a small amount of deliberate effort, which is itself a weak commitment signal. That third property is a bonus rather than the point. The first two are what the mechanism buys, and they address the largest bucket of RTO directly. ## What it does not do Being clear about this prevents disappointment. **It does not create commitment.** A shopper with a working phone who changes their mind at the door passes OTP comfortably. That is a different cause requiring a different fix — partial prepayment. **It does not fix addresses.** A verified phone number attached to an incomplete address still produces a failed delivery. **It does not stop determined fraud.** Someone intent on abuse has a working phone. OTP addresses carelessness and impulse, which is where most of the volume is, not deliberate bad actors. **It does not help with coverage problems.** Pincodes your courier serves badly remain pincodes your courier serves badly. ## Cause of RTO and whether OTP addresses it | Cause | OTP helps | | --- | --- | | Unreachable or mistyped number | Directly, and substantially | | Impulse order, forgotten | Partially, through the effort required | | Buyer changed their mind | No — needs partial payment | | Incomplete address | No — needs address validation | | Poor courier coverage | No — needs pincode rules | | Deliberate abuse | Minimally | ## Conversion will fall, and that is fine The objection is always conversion rate, and it is a real cost — some genuine buyers will abandon at the step. But conversion rate is the wrong measure, and using it guarantees the wrong conclusion. The orders OTP removes are disproportionately orders that would have been rejected at the door. Removing them reduces order count and increases delivered revenue. The metric is **delivered revenue net of RTO cost, per visitor**. A checkout that converts a few points worse while cutting RTO substantially is straightforwardly the better checkout, and you can only see that if you are measuring the right thing. Merchants who evaluate OTP on conversion rate uninstall it within a fortnight, every time. ## Implementation decides how much conversion you lose The difference between a well-implemented and badly-implemented OTP step is large, and it comes down to a few specifics. **Speed is the main one.** A code that arrives in three seconds costs you almost nothing. A code that takes twenty seconds loses genuine buyers who conclude it is broken and leave. This is the single largest driver of abandonment at the step, and it is worth testing on a real mobile network at a busy time rather than on office wifi. **Keep it inline.** Verification on the same page, without navigating away. Sending the shopper elsewhere and back introduces every opportunity for them not to come back. **Offer a resend, with a visible timer.** Codes fail. A shopper with no way to request another is a lost order. **Prefill and format the number field properly.** Country code handling, digit formatting and a numeric keypad on mobile all reduce friction at a step where friction is expensive. **Have a fallback.** If WhatsApp delivery fails, try SMS. If both fail, decide in advance whether to let the order through or block it, and make that a deliberate policy rather than an accident of implementation. ## Testing an OTP implementation - Time the code arrival on a real mobile network, at a busy hour - Complete the flow on a mid-range phone, not a desktop browser - Test the resend path, and the wait before resend is offered - Test what happens when the number is entered wrongly - Confirm it holds through accelerated checkout, not just the standard flow - Check the fallback when the primary channel fails The accelerated checkout test is the one that eliminates poor implementations. Anything applied by manipulating the cart can be bypassed entirely when a shopper uses Shop Pay or a wallet button, which means your verification simply does not run on a growing share of orders. ## WhatsApp versus SMS In markets where WhatsApp is the dominant messaging channel — India prominently among them — it generally outperforms SMS on both delivery speed and open rate. The practical arrangement most merchants land on is WhatsApp first with SMS fallback. That covers customers without WhatsApp and the cases where delivery fails, while getting the better channel's performance for the majority. Costs differ between the channels and change over time, so include per-message cost in your calculation. At meaningful order volumes this is a real line item, though it is almost always small against the cost of a single returned parcel. ## Explaining the step to the customer An unexplained verification step reads as an obstacle. The same step with one line of context reads as reasonable, and the difference shows up in abandonment. What works is brief and honest: a short line saying you verify phone numbers so the delivery reaches them. That is true, it is in the customer's interest as well as yours, and it costs one sentence. What does not work is a paragraph of justification, which draws attention to the friction, or vague security language, which implies a problem the customer did not know they had. Three smaller details worth getting right: **Show the number you are sending to**, so a typo is catchable before the code is sent rather than after it fails to arrive. **Say which channel it is coming from.** A customer watching their SMS inbox while the code sits in WhatsApp is a customer who abandons believing the system is broken. **Do not make them re-enter the number after a failure.** Preserve it, let them correct it, and resend. ## When to make it conditional Applying OTP to every COD order is defensible — it is cheap, and it addresses the largest cause of loss. But some merchants find the conversion cost on low-value orders exceeds the RTO saving, and conditional application is the answer. Sensible conditions, once you have the data to support them: **Above a cart value threshold**, since RTO cost scales with order value while the verification cost does not. **For unfamiliar pincodes**, where you have no delivery history and courier performance is unknown. **For customers with a prior rejected COD order**, which is the strongest single predictor available to you. **Not for repeat customers with a delivery history**, who have already demonstrated they accept parcels. Making a good customer verify on every order is friction with no corresponding benefit. That last exclusion is the one most worth implementing and the one most commonly missed. Your returning customers are the people you least need to verify and the people most likely to be irritated by it. ## Where it sits among the other interventions OTP is usually the first thing to implement and rarely the only thing. **OTP first.** Broadest impact, lowest revenue cost, addresses the largest bucket. **Partial prepayment second**, above a cart value threshold your data supports. This addresses commitment, which OTP does not. **Targeted risk rules third**, for the specific pincodes and patterns your measurement exposes. **Pre-dispatch confirmation throughout.** A message letting the buyer confirm or cancel before the parcel ships converts a future RTO into a cancellation costing only the picking. These compound rather than overlap, because each addresses a different cause. Enabling them all simultaneously, though, tells you nothing about which one worked — introduce them one at a time, in that order. > **Measure before you start** > > Export your delivery outcomes and compute RTO rate by pincode and cart value band before changing anything. Without a baseline you cannot tell whether OTP helped, and you will end up arguing about it from impressions of the order count. For the full RTO picture and the cost arithmetic, see [checkout and payments](/category/checkout-payments). App selection in this category is covered in [Shopify apps](/category/shopify-apps). **OTP verification, partial payment and COD rules in one app** ByteInfy's COD & Part Payment app adds 6-digit OTP verification via SMS or WhatsApp, partial prepayment at checkout, and smart COD blocking by pincode, product or cart value. [See it on the Shopify App Store](https://apps.shopify.com/byteinfy-cod-partial-pay) ## FAQ ### How does OTP verification work on a Shopify checkout? The shopper enters their phone number, receives a one-time code by SMS or WhatsApp, and enters it before the order is placed. ### Will OTP verification reduce my conversion rate? Yes, somewhat. That is the intended effect, since the orders it removes are disproportionately those that would have been rejected at delivery. ### Is WhatsApp or SMS better for OTP delivery? In markets where WhatsApp is the dominant messaging channel, it generally outperforms SMS on both delivery speed and open rate. ### Does OTP verification stop fraud? It reduces one specific class of problem — orders placed with numbers that are fake, mistyped or belong to someone else. It does not address a determined bad actor with a working phone. ### Should OTP apply to every COD order? Applying it to all COD orders is defensible because it is cheap and addresses the largest bucket. Some merchants restrict it to higher cart values or unfamiliar pincodes to reduce friction on low-risk orders. --- --- title: "Best Shopify Upsell and Cross-Sell Apps in 2026" description: "Every upsell app promises a higher average order value. The ones that deliver it interrupt at the right moment; the rest cost you conversions you already had." author: "Aashish Kaushik" published: 2026-10-12T13:00:27.527Z updated: 2026-10-12T13:00:27.752Z url: https://blog.byteinfy.com/best-shopify-upsell-apps --- # Best Shopify Upsell and Cross-Sell Apps in 2026 ## Key takeaways - Placement matters more than recommendation quality — an upsell before the purchase is committed risks the order you already had. - Post-purchase upsells are the safest position, because the original order is already banked when the offer appears. - Recommendation quality separates apps far more than feature lists do, and manual rules often beat weak automation. - Every upsell app adds page weight to templates that convert, so measure speed alongside average order value. Upsell apps all promise the same outcome and are compared on the same features: product page offers, cart offers, post-purchase offers, bundles, AI recommendations, analytics. What actually separates them is where they interrupt and what they recommend. Get the first wrong and you lose orders you already had. Get the second wrong and nobody accepts anything. > **On specifics** > > Pricing and features in this category change frequently, and much of the available comparison content is published by upsell app vendors. Nothing here ranks products; trial against your own catalogue. ## Placement is the whole decision Each position carries a different risk to the order you have already won. **Product page.** The riskiest. A shopper reading a product page has not committed, and presenting an alternative or an addition can reopen a decision that was closing. Done well — a genuine complement, presented quietly — it works. Done badly it is a distraction at the worst moment. **Cart.** Moderate risk, often the best-performing pre-purchase position. The shopper has chosen, and a suggestion that completes the purchase is genuinely helpful. The risk is sending them back to browse. **Checkout.** Constrained by design. Extensions can present offers at supported points, and the constraint is protective — checkout is not a page to experiment on. **Post-purchase.** The safest, and frequently the most profitable in practice. The order is banked. A declined offer costs nothing. Acceptance rates are lower than pre-purchase, but so is the downside, and the expected value is often better. ## Placement, risk and what suits it | Placement | Risk to original order | Works for | | --- | --- | --- | | Product page | High | Genuine complements, quietly presented | | Cart | Moderate | Completions, threshold nudges | | Checkout | Low, but constrained | Simple, relevant additions | | Post-purchase | None | Impulse adds, one-time offers | | Email after delivery | None | Replenishment, considered add-ons | The bottom row is under-used. An offer sent after the product has arrived reaches a customer who now knows whether they like it, which is a better moment for a related purchase than any point during the original transaction. ## Recommendation quality separates apps more than features Every app in this category has a recommendation engine and every one claims intelligence. The difference in output is large. The failure mode is recommending the obvious and useless — a second identical item, an accessory for a different model, or the product the customer is already buying. Shoppers notice immediately, and a visibly stupid recommendation damages trust in the rest of the page. What to check during a trial: **Test on your actual catalogue**, not a demo store. Recommendation quality depends on your product data, and thin data produces poor recommendations regardless of the algorithm. **Check the edge cases.** What does it recommend for your newest product with no order history? For a one-off item with no obvious companion? **See whether manual overrides exist.** For most catalogues a merchant who knows the products defines better pairings than an algorithm with limited data. An app that does not let you override its own suggestions is a poor fit for a small or specialised catalogue. **Ask how it handles out-of-stock items.** Recommending something unavailable is worse than recommending nothing at all, and it happens constantly on catalogues with fast-moving variants. ## Upselling and cross-selling need different treatment They are grouped together and behave differently. **An upsell** offers a better or larger version — more capacity, a premium finish, a bigger size. It works best where the difference is easy to state and obviously worth the money. It works on the product page, where the comparison is being made anyway, and post-purchase rarely makes sense for it. **A cross-sell** offers something complementary. It works best in the cart, where the shopper has finished choosing and is open to completing, and post-purchase, where they now know what they need. Applying the same placement and phrasing to both is a common reason upsell programmes underperform. The offer that reads as helpful in one context reads as pushy in the other. ## The metric everyone uses is the wrong one Average order value is the number these apps report, and it can rise while total revenue falls. If an upsell increases the value of orders that complete but reduces how many complete, AOV goes up and revenue per visitor goes down. The app's dashboard shows success. Your bank does not. The metric is **revenue per visitor**, or better, contribution margin per visitor. It captures both sides — what customers spent and whether the interruption cost you customers. ## Measuring an upsell app honestly - Baseline revenue per visitor before installing - Watch conversion rate alongside average order value, not instead of it - Measure page speed on the templates the app touches - Check return rates, since accepted upsells are returned more often than chosen items - Run pre-purchase placements against a control, since they carry real risk - Include the subscription cost in the calculation Returns deserve the specific mention. Products added through an upsell are chosen with less deliberation than products the customer sought out, and they come back more often. An upsell programme evaluated on gross revenue rather than net of returns will look better than it is. ## Page weight, again Every app in this category adds JavaScript to templates that convert — product pages and carts. That weight is paid on every visit, including the majority where nobody sees or accepts an offer. Ask whether the app renders through a theme app extension or injects into theme files, whether it loads on templates where no offer is configured, and what remains after uninstalling. Then measure a product page before and after, on a phone. An upsell app that adds half a second to every product page has to earn that back before it earns anything, and the loss is spread invisibly across every visitor while the gain is visible in a dashboard. ## Fewer offers, better placed The instinct after installing is to enable everything — product page, cart, checkout, post-purchase, plus a popup. The result is a store that asks for more at every step, which reads as pushy and performs worse than one well-chosen offer. Start with post-purchase, because the downside is nil and it tells you what your customers will accept. Add a cart cross-sell if the data supports one. Only then consider pre-purchase placements, and only against a control. This sequencing has a second benefit. The post-purchase phase generates data about which pairings your customers actually accept, and that data is what should drive your cart and product page offers later. Merchants who enable everything simultaneously never learn this, because every placement is competing with every other and no individual result is attributable. ## How the offer is worded The mechanics get the attention and the copy does much of the work. Two offers with identical products and placement can perform very differently. **Say why this item, not just what.** "Customers often add this" is weak. "This case fits the model you are buying" gives a reason, and reasons convert. The recommendation engine may know why; the shopper does not unless you say it. **Make the value explicit.** If the offer includes a saving, state it as money rather than a percentage, and state it against the price of buying separately. If there is no saving, do not imply one — a shopper who works out that the "offer" is just the normal price stops trusting the page. **Keep declining easy and unembarrassing.** Dark patterns — "No thanks, I don't want to save money" — measurably annoy people and increasingly attract regulatory attention. A plain "No thanks" performs adequately and costs you nothing in goodwill. **One offer, not three.** A post-purchase page presenting a single well-chosen item outperforms one presenting a grid. More options is a browsing experience, and the customer has finished browsing. **Set a time limit only if it is real.** Genuine one-time post-purchase pricing is a legitimate reason to act now. A countdown that resets on refresh is discovered quickly and remembered. > **Do not upsell a customer who is already unhappy** > > If an order has a fulfilment problem, a delay, or an open support ticket, suppress the offer. Asking someone to spend more while you are late delivering what they already bought is the single fastest way to turn a recoverable problem into a lost customer. Most apps allow this to be configured and almost nobody configures it. ## A short evaluation sequence 1. Start with post-purchase, where a bad offer cannot cost you an order. 2. Test recommendation quality on your own catalogue, including new and unusual products. 3. Confirm manual overrides exist if your catalogue is small or specialised. 4. Measure revenue per visitor, not average order value. 5. Check page-speed impact on product and cart templates. 6. Add pre-purchase placements last, and only against a control. For the strategy question of which mechanics raise order value, see [promotions and offers](/category/promotions-offers). App weight and selection generally are covered in [Shopify apps](/category/shopify-apps) and [storefront and design](/category/storefront-design). **Offer logic built around your catalogue** ByteInfy builds Shopify upsell, bundle and discount mechanics with Functions — recommendations that fit your products and placements that do not cost you orders. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Where is the best place to put an upsell on Shopify? Post-purchase, on the thank-you page, is the safest and often the most profitable, because the original order is already complete and the offer cannot cost you it. ### What is the difference between upselling and cross-selling? Upselling offers a better or larger version of what the customer is buying. Cross-selling offers something complementary alongside it. ### Do upsell apps hurt conversion rate? They can, and pre-purchase placements are where it happens. An offer that interrupts someone about to buy, or presents an alternative that reopens a decision, costs you orders. ### Are post-purchase upsells worth it if acceptance is low? Usually yes, because the downside is close to zero. The original order is complete, so a declined offer costs you nothing but a page view. ### Should I use AI recommendations or manual rules? Manual rules beat weak automation, and for most catalogues a merchant who knows their products can define better pairings than an algorithm working from thin data. --- --- title: "Agenzia Shopify Partner: cosa significa e perché conta" description: "Il badge \\\"Shopify Partner\\\" compare su quasi ogni sito di agenzia, e da solo dice meno di quanto sembri. Cosa significa davvero il programma, cosa non certifica e cosa verificare prima di fidarsi del logo." author: "Aashish Kaushik" published: 2026-10-12T05:01:04.987Z updated: 2026-10-12T05:01:04.990Z url: https://blog.byteinfy.com/agenzia-shopify-partner-cosa-significa-perche-conta --- # Agenzia Shopify Partner: cosa significa e perché conta ## Key takeaways - Il programma Shopify Partner è gratuito e aperto: chiunque costruisca su Shopify può iscriversi, quindi il badge da solo non dice se un'agenzia lavora bene. - Essere partner dà accesso al pannello partner, ai negozi di sviluppo e a una quota sui piani dei merchant indirizzati; non è una certificazione di competenza tecnica. - I livelli superiori del programma dipendono in gran parte da quanto fatturato generano per Shopify, non da una verifica indipendente della qualità del lavoro. - Il badge è un punto di partenza per la due diligence, non una sostituzione: le domande su lavori vecchi, manutenzione e proprietà del codice restano necessarie comunque. Il badge "Shopify Partner" compare sul sito di quasi ogni agenzia che lavora con Shopify, e da solo dice molto meno di quanto il logo suggerisca. Il programma Shopify Partner è gratuito e aperto a chiunque voglia costruire sulla piattaforma: iscriversi richiede pochi minuti e nessun esame di ammissione. Essere partner è quindi la condizione normale per lavorare su Shopify in modo professionale, non un premio per chi lo fa bene. Questo non significa che il titolo sia inutile. Significa che va capito per quello che è, uno stato di accesso agli strumenti della piattaforma, prima di usarlo come criterio per scegliere chi le costruisce il negozio. Questo articolo spiega cosa il programma dà davvero, cosa non certifica, come funzionano i livelli superiori, come si distingue da una vera revisione (quella delle app pubblicate sull'App Store) e cosa verificare oltre al badge quando valuta un'agenzia. > **Scritto da un partner** > > ByteInfy è iscritta al programma Shopify Partner, come praticamente ogni agenzia che lavora sulla piattaforma. Lo diciamo perché il punto di questo articolo non è distinguerci con il badge, ma spiegare perché il badge da solo non basta a distinguere nessuno. ## Cos'è il programma Shopify Partner, in breve Il programma Shopify Partner è il sistema con cui Shopify apre la piattaforma a chi costruisce per conto di altri: agenzie, sviluppatori indipendenti, designer e creatori di app o temi. L'iscrizione avviene tramite il sito partners.shopify.com, è gratuita e non richiede un colloquio, un test o un caso studio da presentare. Una volta iscritto, un partner riceve accesso a un pannello dedicato, la possibilità di creare negozi di sviluppo gratuiti dove costruire e testare senza pagare un abbonamento, l'accesso ad alcune API e funzionalità prima del rilascio pubblico, e una quota sui ricavi dei piani Shopify dei merchant che indirizza sulla piattaforma. Questi sono strumenti di lavoro pensati per chi costruisce su Shopify per mestiere, non un percorso di certificazione. ## Cosa NON significa essere partner Il punto più importante da capire, e quello che il marketing di molte agenzie lascia volutamente ambiguo. Essere Shopify Partner non significa che Shopify abbia verificato la qualità del codice che l'agenzia scrive, non significa che abbia superato un esame tecnico, e non significa che i progetti passati siano stati controllati da qualcuno. Non è come una certificazione professionale in altri settori, dove un ente terzo verifica competenze specifiche prima di rilasciare il titolo. È più simile a un account gratuito che si attiva compilando un modulo. Questo spiega perché il badge compare tanto spesso: costa zero ottenerlo, e mostrarlo è un modo semplice per un'agenzia di dire "lavoriamo su Shopify", cosa vera per praticamente chiunque faccia questo mestiere. ## Cosa significa davvero, e perché serve comunque Detto questo, il programma non è privo di significato pratico, e conviene capire cosa dà davvero. **Accesso a negozi di sviluppo.** Un'agenzia partner può creare negozi di prova gratuiti dove costruire e testare senza costi, incluso l'accesso a Shopify Plus in ambiente di sviluppo. Un'agenzia che lavora direttamente su negozi reali dei clienti senza un ambiente di test separato, partner o no, è un problema più serio dell'assenza del badge. **Accesso anticipato a funzionalità e API.** I partner ricevono spesso visibilità su nuove funzionalità, cambi di API e scadenze di deprecazione prima che raggiungano tutti i merchant. Questo è concretamente utile: un'agenzia attiva nel programma ha più probabilità di sapere in anticipo quando una versione di API viene ritirata, un tema su cui torniamo nell'articolo sul [versionamento delle API Shopify](/shopify-api-versioning). **Una quota sui ricavi dei merchant indirizzati.** Quando un'agenzia partner aiuta un merchant ad attivare un piano Shopify, riceve una percentuale di quel ricavo. Questo non è di per sé un problema, ma vale la pena saperlo: è uno degli incentivi economici che un'agenzia ha nel consigliarle Shopify rispetto ad altre piattaforme, e nel consigliarle un piano più alto di quanto le serva. **Un segnale di continuità minima.** Mantenere un account partner attivo, con negozi gestiti e un pannello aggiornato, richiede che l'agenzia lavori davvero su Shopify in modo regolare. Non prova qualità, ma rende meno probabile che si tratti di un'agenzia generica che ha aggiunto Shopify all'elenco dei servizi senza sostanza dietro. ## I livelli del programma Shopify struttura il programma partner con livelli che salgono in base a fattori come il fatturato dei merchant indirizzati o gestiti attraverso l'agenzia. I dettagli esatti, le soglie e i nomi dei livelli sono cambiati più volte nel corso degli anni e continueranno probabilmente a cambiare, quindi qui non riportiamo cifre specifiche che rischiano di essere già superate quando le legge. Quello che conta capire è il principio: i livelli più alti riflettono in gran parte il volume di attività generato per Shopify, non una verifica indipendente della qualità tecnica. Un'agenzia a un livello alto ha probabilmente gestito molti negozi o negozi con volumi importanti, il che è un segnale ragionevole di esperienza, ma non è la stessa cosa di un controllo di qualità. Se un'agenzia menziona il proprio livello nel programma, la domanda utile è cosa ha dovuto fare per raggiungerlo, non limitarsi al nome del livello. ## Cosa il programma partner dice, e cosa no | Cosa verifica il programma | Cosa non verifica | | --- | --- | | Che l'agenzia si sia registrata su Shopify | Che il codice che scrive sia buono | | Il volume di merchant o fatturato indirizzato | La soddisfazione di quei merchant nel tempo | | L'accesso a strumenti e negozi di sviluppo | Se l'agenzia li usa in modo professionale | | La partecipazione a un programma di incentivi | La qualità del supporto post-lancio | Un esempio pratico di come usare questa distinzione: se sta valutando un'agenzia per un negozio su Shopify Plus specificamente perché il volume lo giustifica, un'agenzia a un livello alto del programma ha probabilmente già gestito le particolarità di Plus (checkout personalizzato oltre le estensioni standard, B2B con cataloghi, script legacy da migrare). Questo è un'informazione utile per restringere la lista di candidati. Non le dice ancora se quell'agenzia comunica bene, consegna in tempo o lascia un negozio pulito, e per questo servono le domande dirette, non il nome del livello. ## Perché quasi ogni agenzia Shopify mostra questo badge La spiegazione è semplice: se la barriera d'ingresso è pari a zero, non mostrarlo sarebbe più strano che mostrarlo. Un merchant che confronta cinque siti di agenzie vede il logo del programma partner su tutti e cinque, e questo di per sé non separa nessuno. È lo stesso meccanismo che si vede in altri programmi con un nome simile in settori diversi, dove diventare "partner" di una piattaforma pubblicitaria o di un fornitore di software richiede la registrazione più che una verifica. Il problema non è che il programma esista, è che il marketing di molte agenzie lo presenta come se fosse un riconoscimento raro, sapendo che il merchant medio non ha motivo di conoscere i requisiti reali per ottenerlo. Questo non rende il badge disonesto da mostrare. Un'agenzia che costruisce davvero su Shopify è, letteralmente, un partner Shopify, e dirlo è corretto. Il problema nasce quando il badge viene presentato come se sostituisse le prove di competenza che un merchant dovrebbe comunque chiedere. C'è una distinzione correlata che vale la pena fare esplicitamente, perché genera confusione: essere iscritti al programma partner non è la stessa cosa di aver superato la revisione di un'app pubblicata sull'App Store. Qualsiasi persona può registrarsi come partner in pochi minuti. Pubblicare un'app pubblica sull'App Store di Shopify è un processo diverso: richiede che l'app rispetti le linee guida tecniche e di sicurezza di Shopify, superi un processo di revisione con un team dedicato, e resti conforme nel tempo mentre le linee guida cambiano. Un'agenzia che ha pubblicato e mantenuto app proprie sull'App Store, come i quattro prodotti che ByteInfy gestisce (SwipeReel per il video shoppable, myBillPlease per la fatturazione GST in India, un'app per il contrassegno e una per il testo alternativo, elencate su [apps.shopify.com/partners/akway-ecomm-private-limited](https://apps.shopify.com/partners/akway-ecomm-private-limited)), ha dimostrato qualcosa di più concreto del semplice status di partner: ha attraversato ripetutamente un processo di revisione tecnica reale, non solo un modulo di iscrizione. Questo non significa che un'agenzia debba avere app pubblicate per essere brava a costruire negozi o integrazioni, sono competenze diverse. Significa che, se un'agenzia menziona app proprie sull'App Store come prova di esperienza, quella prova pesa di più del badge partner da solo, e vale la pena chiedere di vederle live e leggere le recensioni dei merchant che le usano, non solo il numero dichiarato. L'approfondimento su cosa comporta davvero superare la revisione di un'app è in [Shopify app review guide](/shopify-app-review-guide). ## Partner generico, Plus Partner ed etichette simili Alcune agenzie si presentano con etichette più specifiche legate a Shopify Plus o a categorie particolari del programma. Il principio è lo stesso di prima: queste etichette riflettono soglie di attività o requisiti stabiliti da Shopify, non un audit indipendente del lavoro svolto. Un'agenzia con un'etichetta più avanzata ha probabilmente più esperienza su negozi di dimensioni maggiori, e questo può essere un segnale utile per un merchant che sta valutando Shopify Plus, un argomento approfondito in [quanto costa un negozio Shopify nel 2027](/it/agenzia-shopify-quanto-costa-negozio-nel-2027-prezzi), dove il costo del piano Plus è trattato a parte da quello dello sviluppo. Il consiglio pratico resta lo stesso indipendentemente dall'etichetta: la chieda di spiegare cosa rappresenta quel livello specifico oggi, perché il programma cambia, e non prenda per buono un badge senza contesto. ## Come verificare se un'agenzia è davvero un partner attivo Verificare l'iscrizione al programma è meno importante di verificare l'attività reale dietro di essa, ma entrambe le cose si possono chiedere nella stessa conversazione. Chieda il nome dell'organizzazione partner con cui lavorano, e se è disposta a farlo, verifichi che corrisponda a quanto dichiarato. Più utile del semplice fatto di essere iscritti è chiedere da quanto tempo lo sono, quanti negozi gestiscono attivamente in questo momento, e di vedere, durante una chiamata, il loro pannello partner con almeno un negozio reale collegato. Un'agenzia che esita a mostrare questo, pur affermando di essere partner da anni, merita la stessa cautela di una che non risponde alle domande sui lavori passati. ## Cosa chiedere oltre al badge - Da quanto tempo sono iscritti al programma partner e quanti negozi gestiscono - Il nome dell'organizzazione partner con cui opera il team - Un esempio di negozio reale, costruito da loro, ancora attivo da almeno due anni - Se usano negozi di sviluppo separati per costruire e testare, non il negozio reale del cliente - Come gestiscono le informazioni anticipate su deprecazioni e nuove funzionalità che ricevono come partner - Cosa significa concretamente il loro livello nel programma, se ne menzionano uno Il badge partner è quasi sempre il primo elemento che un'agenzia mette in evidenza sul proprio sito, e proprio per questo conviene guardare oltre, nella stessa pagina, prima ancora di chiamare. I casi studio con dati verificabili contano più del badge: un link a un negozio reale ancora online, non solo una schermata statica, permette di controllare da soli se il negozio esiste ancora e funziona. Le recensioni su una piattaforma terza indipendente, come le recensioni pubbliche sotto un'app che l'agenzia ha pubblicato sull'App Store, sono più difficili da falsificare di una testimonianza scritta sul proprio sito. E la data dell'ultimo aggiornamento del sito stesso dice qualcosa: un'agenzia che mostra ancora screenshot di un tema Shopify che non esiste più probabilmente non aggiorna nemmeno il proprio materiale di vendita da anni, figuriamoci il codice dei clienti. Vale la pena anche controllare se l'agenzia scrive contenuti tecnici propri, non solo pagine di vendita. Un'agenzia che pubblica spiegazioni verificabili su come funziona una parte specifica di Shopify, con i limiti onestamente dichiarati invece che nascosti, sta mostrando di capire la piattaforma a un livello che il badge partner da solo non richiede affatto. ## Perché il badge conta comunque nella scelta Nonostante tutti i limiti descritti, il badge non è privo di valore nella scelta di un'agenzia, semplicemente non è sufficiente da solo. La sua assenza è più informativa della sua presenza. Un'agenzia che si presenta come specializzata in Shopify ma non è nemmeno iscritta al programma partner, gratuito e aperto a chiunque, sta segnalando qualcosa: o lavora su Shopify solo occasionalmente, o non conosce nemmeno la struttura base della piattaforma su cui dice di specializzarsi. Questo è un filtro utile e a costo zero da applicare prima di qualsiasi altra domanda. La sua presenza, invece, va trattata come un punto di partenza. Dice che l'agenzia ha accesso agli strumenti giusti e una qualche continuità di attività sulla piattaforma. Non dice se il codice è pulito, se la documentazione esiste, se il suo team potrà modificare il negozio senza chiamare l'agenzia per ogni cosa, o se il preventivo include la manutenzione. Queste sono le domande che fanno davvero la differenza, e sono raccolte in dettaglio in [come scegliere un'agenzia Shopify: 12 domande da fare](/it/come-scegliere-agenzia-shopify-12-domande-da-fare). ## Il badge non sostituisce la due diligence Il modo più sensato di usare il programma partner nella sua valutazione è come un filtro di ingresso, non come un criterio di decisione finale. Un'agenzia senza badge partner probabilmente non lavora seriamente su Shopify e va scartata a prescindere da cos'altro dica. Un'agenzia con il badge entra nella lista dei candidati validi, ma da lì in poi il lavoro di valutazione è lo stesso che farebbe con qualsiasi fornitore: chiedere del lavoro passato, delle deprecazioni delle API, della proprietà del codice, di cosa succede dopo il lancio. Il logo sul sito web non risponde a nessuna di queste domande, e nessuna agenzia seria si aspetta che lo faccia al posto suo. Se sta confrontando più agenzie e tutte mostrano lo stesso badge, quello che le distingue davvero non è il programma a cui sono iscritte ma le risposte che danno quando gliele chiede direttamente, per iscritto, prima di firmare. **Vuole verificare cosa c'è dietro il badge di un'agenzia** ByteInfy è iscritta al programma Shopify Partner e le mostra volentieri negozi reali che gestisce da anni, non solo il logo sul sito. [Parla con ByteInfy](https://byteinfy.com/contact) ## FAQ ### Essere Shopify Partner è una certificazione di qualità? No. Il programma Shopify Partner è gratuito e aperto: qualsiasi persona o agenzia che voglia costruire su Shopify può iscriversi in pochi minuti, senza un esame di ammissione o una verifica indipendente delle competenze. ### Cosa ottiene un'agenzia diventando Shopify Partner? Accesso al pannello partner, la possibilità di creare negozi di sviluppo gratuiti per testare e costruire, l'accesso anticipato ad alcune funzionalità e API, e una quota sui ricavi dei piani dei merchant che indirizza a Shopify. ### Esistono livelli diversi nel programma Shopify Partner? Sì, Shopify struttura il programma con livelli che salgono in base a fattori come il fatturato dei merchant indirizzati o gestiti tramite l'agenzia. ### Un'agenzia deve per forza essere Shopify Partner per lavorare bene su Shopify? No, ma è quasi impossibile lavorare seriamente su Shopify senza esserlo, perché senza un account partner non si possono creare negozi di sviluppo né accedere a molti strumenti di test. ### Come verifico che un'agenzia sia davvero un partner attivo? Può chiedere di vedere il pannello partner durante una chiamata, o chiedere il nome dell'organizzazione partner per verificarla. ### Cosa dovrei chiedere oltre a "siete Shopify Partner"? Le domande che rivelano davvero la qualità: cosa hanno costruito due anni fa e se funziona ancora, come gestiscono le deprecazioni delle API, chi possiede il codice, cosa succede dopo il lancio. --- --- title: "Video on Shopify Product Pages: Placement and Impact" description: "The debate about whether product video works is less useful than the question of where it goes. Placement decides viewership, and viewership decides everything after." author: "Aashish Kaushik" published: 2026-10-11T13:01:07.569Z updated: 2026-10-11T13:01:07.764Z url: https://blog.byteinfy.com/video-on-product-pages --- # Video on Shopify Product Pages: Placement and Impact ## Key takeaways - Placement decides whether a video is watched at all, and most stores put video too far down the page to be seen. - Gallery placement gets substantially more views than a separate section below the description. - Published conversion lifts come from vendors measuring self-selected stores, so treat them as a ceiling rather than a forecast. - Video helps where images leave a real question unanswered and does very little where they do not. Most discussion of product video argues about whether it works. That is the less useful question, because the answer is obviously "sometimes" and it depends on the product. The more actionable question is where it goes. A video nobody sees has no effect regardless of how good it is, and placement is the single largest determinant of whether it gets watched. > **On the numbers in this article** > > Conversion figures published in this category come overwhelmingly from vendors measuring their own customers. That is a self-selecting group — stores adding video tend to be stores investing in product pages generally. The direction is consistent and worth acting on; the specific percentages are not forecasts. ## Placement decides viewership The common pattern is a video section below the description, beneath the specifications, above the related products. In that position it functions as decoration for people who had already decided. The principle worth applying instead: **video should sit where the doubt occurs.** If the doubt is fit, the video belongs beside or inside the image gallery, before the size selector — that is the moment of hesitation. If the doubt is assembly or setup, near the specifications, where someone reading detail will encounter it. If the video is social proof rather than explanation, lower is correct, because proof reinforces a decision rather than informing one. The gallery is where most product-page video should live, and it creates a real tension worth naming. ## The gallery problem Putting video into the main image carousel gets it seen. It also competes with the images shoppers use to evaluate the product, and an autoplaying clip in the first slot actively obstructs someone trying to look at the item. The compromise most stores land on: a clearly marked video thumbnail in the gallery strip, at position two or three. Visible, deliberately chosen by the shopper, not forced. The primary image remains the primary image. Two details that matter more than they sound: **Mark it clearly as video.** A thumbnail indistinguishable from a photograph gets clicked by people expecting a larger image, who then leave without watching and without returning to the gallery. **Choose the poster frame deliberately.** The default first frame of an autoplay-optimised clip is frequently a blurred motion frame, which looks broken as a still and undermines confidence in the whole gallery. ## Mobile changes the arithmetic Most of this traffic is mobile, and the desktop and mobile cases behave differently enough to plan separately. On desktop, the gallery and buy box sit side by side, so a video opened in the gallery plays directly next to the price and the add-to-cart button. That is the ideal arrangement, and it happens by default without anyone designing it. On mobile, the same video pushes the buy box off screen entirely. The shopper finishes watching and has lost the thing they were about to press. This is why a clip that tests well on desktop can flatten on phones, and it is why the gallery height on mobile deserves specific attention. Vertical format matters for the same reason. A landscape clip in a vertical viewport wastes most of the screen and reads immediately as repurposed desktop content — precisely the impression social-native video exists to avoid. ## Length: shorter than feels right The evidence on length is consistent. Around 91% of viewers prefer video under two minutes, and product-page clips in 2026 are trending under 30 seconds ([Whatmore's 2026 shoppable video guide](https://www.whatmore.ai/blog/the-ultimate-guide-to-shoppable-video-for-2026/), retrieved 2026-09-02). The reason is situational rather than attention span. Someone on a product page has already committed to considering the product. They are not seeking entertainment; they are resolving a doubt. A fifteen-second clip showing the bag worn by someone of stated height does more than a two-minute brand film, because it answers the question being asked. ## What a product-page clip should contain - One question, decided before shooting or selecting - The product in real use or on a real person - A scale reference — a hand, a body, a stated measurement - Legibility with the sound off, since most views are muted - Vertical framing, because most viewers are on phones - No dependence on a hook, since the shopper has already stopped scrolling ## Which products deserve video The filter that saves the most wasted effort. Video helps where images leave a genuine question. It does very little where they do not, and adding it everywhere dilutes the effort while adding weight to every product page. ## Where video earns its place | Product characteristic | Video value | | --- | --- | | Fit, drape or sizing uncertainty | High | | Scale hard to judge from photographs | High | | Motion or mechanism is the point | High | | Assembly or setup required | High | | Texture or material hard to convey | Moderate | | Simple, familiar, well-photographed | Low | | Commodity items bought purely on price | Low | Start with the products in the top rows that also sell in volume. That intersection is where the same production effort returns the most. There is a second selection input worth using: return reasons. If a product is returned frequently because it did not fit, was smaller than expected, or was not what the buyer thought, that is a doubt your images are failing to resolve — and it is exactly the doubt a video can close. Products with high return rates for expectation reasons are often better video candidates than your best sellers, because the video prevents a cost rather than only adding a conversion. ## The page-weight trade is real Video is the heaviest asset you can put on a product page, and this is where video programmes quietly fail. The store adds video, conversion does not move, and nobody connects it to product pages taking a second longer to become interactive. Nothing heavy should load before the shopper indicates interest: - A lightweight poster image, with width and height set so the layout does not shift. - Player and video file fetched on interaction, not on page load. - Nothing video-related loading on product pages that have no video assigned. - Autoplay, where used at all, muted, short, and limited to one element. A store that gets this wrong pays twice — once in Core Web Vitals across every product page, and again because the slower page suppresses the conversions the video was added to win. ## Self-hosted, a general video platform, or a shoppable video app Where the video file actually lives changes the weight and the maintenance burden, and the three common routes suit different stores. Hosting the file directly, through Shopify's own file storage or a general-purpose video host, gives the most control over exactly what loads and when, since there is no third-party player script beyond what is strictly needed to play the file. The cost is that every convenience, a poster frame, adaptive quality for different connection speeds, analytics on watch time, has to be built or configured by hand, and most stores underestimate how much of that a dedicated tool would have handled automatically. A general video platform built for broader use, the kind used for marketing or support video across a whole business, tends to load a fuller player script with features a product page does not need, such as end-of-video suggestions or a branded player chrome designed for a different context. It is a reasonable choice when a store already uses the platform for other video and wants one system rather than several, and a poor choice when the product page is the only place the extra weight is paying for itself. A shoppable video app built specifically for product pages typically loads only where video is assigned, following the theme app extension pattern discussed elsewhere in this series, and adds the interaction layer, tap-to-buy, gallery placement, deferred loading until interaction, as a built-in feature rather than something to configure from parts. This usually gives the best weight-to-feature ratio for the specific case of product-page video, and it is the reason a dedicated app tends to outperform a general video embed on this one template even when both are configured carefully, though it adds a dependency worth weighing against the app-selection principles covered elsewhere in this category. The practical test, whichever route is chosen, is the same one used throughout this article: measure the finished page on a throttled connection before deciding the choice was right, rather than trusting a platform's marketing claims about its own weight. ## What the video should actually show Placement gets it watched. Content decides whether watching helps. The most useful framing is that a product video is answering a question, and the question should be chosen before anything is shot or selected. Your support inbox is the best source — the thing people ask about most is the thing the video should resolve. Four patterns that consistently work: **The scale shot.** Someone of stated height wearing it, or the object beside a familiar reference. This resolves the most common doubt in the most product categories and is the easiest to produce. **The motion shot.** How fabric moves, how a mechanism opens, how a chair reclines. Photography cannot do this at all, which makes it the clearest case for video existing. **The setup walkthrough.** Anything requiring assembly, installation or configuration. This has a second benefit: it reduces returns from people who could not work out how to use the thing. **The comparison.** Two sizes, two finishes, or your product against the obvious alternative. Genuinely useful and rarely produced, because it requires admitting alternatives exist. What consistently does not work on a product page: brand films, founder stories, and anything that takes ten seconds to reach the point. Those have a place elsewhere on the site, and the homepage is usually it. > **Film once, cut twice** > > The same footage serves the product page and social, but not in the same edit. Keep the master uncropped, shoot vertical, and capture a few seconds more than you need at each end. The product-page cut drops the hook; the social cut keeps it. Discovering you need both after the shoot has wrapped is an avoidable expense. ## Testing it so the answer means something Product video is unusually easy to be fooled by, because it gets added to the best products first. A test that produces a usable answer: pick products where images genuinely leave a question open, add video to half of them matched on traffic and baseline conversion, run it for weeks rather than days, and measure conversion and revenue per visitor on the product page — while checking Core Web Vitals on both groups. That last check is the one most stores skip and the one that explains a null result. If the video group got slower, you ran two experiments at once and cannot separate them — the video may have helped while the weight it added cancelled the gain exactly. For format selection and the wider video question, see [video commerce and UGC](/category/video-commerce-ugc). Product page design generally is covered in [storefront and design](/category/storefront-design), and app selection in [Shopify apps](/category/shopify-apps). **Video on product pages without the page-speed cost** SwipeReel adds shoppable video to Shopify product pages — gallery placement, tap-to-buy inside the player, and nothing heavy loading until someone presses play. [See SwipeReel on the Shopify App Store](https://apps.shopify.com/swipereel) ## FAQ ### Where should video go on a Shopify product page? In or beside the image gallery, where shoppers are already looking, rather than as a separate section below the description. Gallery placement gets far more views. ### How long should a product page video be? Short. Around 91% of viewers prefer video under two minutes, and product-page clips are trending under 30 seconds. ### Does product video actually increase conversion? Reported lifts are substantial but come from vendors measuring stores that chose to add video, which is a self-selecting group. ### Should product videos autoplay? Muted, short, and only one per page if at all. Autoplaying video that downloads on page load is the most common way stores lose more in page speed than they gain in engagement. ### Do I need video on every product? No, and trying to is how video programmes stall. Add it where images leave a real question open. --- --- title: "Shopify headless con Hydrogen: quando conviene" description: "Headless non è più veloce di default e non è migliore di default. Compra controllo, e il controllo vale il suo prezzo solo quando ha qualcosa di specifico da farci." author: "Aashish Kaushik" published: 2026-10-11T05:01:05.542Z updated: 2026-10-11T05:01:05.546Z url: https://blog.byteinfy.com/shopify-headless-con-hydrogen-quando-conviene --- # Shopify headless con Hydrogen: quando conviene ## Key takeaways - Headless rimuove il livello del tema e le dà pieno controllo del front end, al costo di costruire e mantenere tutto quello che il tema forniva. - Non è automaticamente più veloce: un negozio headless costruito male è più lento di un tema Liquid ben costruito. - I casi genuini più forti sono requisiti di front end inusuali, un unico front end su più backend, e capacità React già presente in azienda. - Il costo nascosto è tutto quello che l'ecosistema dei temi le dava gratis: app block, editor del tema e autonomia del merchant. Headless viene consigliato per motivi che non reggono a un esame attento, principalmente la velocità e una sensazione generica che sia più moderno. Entrambi sono motivi deboli, e seguirli produce progetti costosi che finiscono più lenti del tema che hanno sostituito. L'architettura è genuinamente utile in circostanze specifiche. Questo articolo prova a nominarle con precisione, ed è altrettanto preciso sui costi, che vengono sistematicamente sottostimati. > **La domanda che inquadra tutto** > > "Cosa costruiremo che un tema non può fare?" Se la risposta non è immediata e specifica, la risposta è un tema. ## Cosa cambia davvero con headless Smette di usare il livello tema di Shopify. Shopify resta il suo backend, prodotti, inventario, ordini, checkout, e costruisce la vetrina da solo, interrogando la Storefront API. Hydrogen è il framework React di Shopify per fare questo, di solito distribuito su Oxygen. Rimuove una parte del lavoro infrastrutturale che rendeva costose le vecchie soluzioni headless, ed è la via supportata. Quello che guadagna è il controllo totale del front end. Quello che perde è tutto ciò che il livello tema stava facendo per lei, ed è una lista più lunga di quanto la maggior parte dei progetti preveda. ## La velocità non è il motivo La giustificazione più comune, e la più debole. Headless non rende una vetrina veloce. Alza il tetto massimo di prestazione, perché controlla esattamente cosa carica e quando. Raggiungere quel tetto richiede una disciplina che molti progetti non mantengono nel tempo. Nel frattempo, una vetrina React pesante che carica un bundle JavaScript grande è comodamente più lenta di un tema Liquid ben costruito, in particolare sui dispositivi mobili di fascia media che gestiscono la maggior parte del traffico e-commerce. Il confronto onesto non è tra headless e un tema lento. È tra headless e un tema ben ottimizzato con le app inutili rimosse, e la maggior parte dei negozi che valutano headless per la velocità non ha ancora fatto quel lavoro più economico. Farlo di solito recupera la maggior parte del guadagno disponibile per una frazione del costo, come spiegato in [Shopify theme vs custom](/shopify-theme-vs-custom). ## I casi in cui conviene davvero Quattro, e hanno in comune il fatto che un tema non può fare la cosa affatto. **Un'esperienza di front end che i temi non possono esprimere.** Un'interazione genuinamente inusuale, un configuratore, un modello di navigazione molto particolare. Non "lo vogliamo su misura" (i temi gestiscono bene lo su misura) ma un'interazione che il modello del tema non può strutturalmente supportare. **Un front end unico su più backend.** Shopify per il commercio, un CMS separato per l'editoriale, altri sistemi ancora, presentati come un'unica esperienza. È un caso forte, e uno che i negozi basati su tema gestiscono goffamente. **Capacità React già presente e voglia di usarla.** Un team che già costruisce e mantiene applicazioni React sta assumendo molto meno rischio nuovo di uno che non lo fa. Al contrario, adottare headless come primo progetto React significa adottare due problemi insieme. **Commercio ricco di contenuti.** Dove editoriale e commercio si intrecciano davvero e il bilanciamento pende verso l'editoriale, un front end su misura sopra entrambe le fonti può essere più pulito che forzarlo dentro un tema commerciale. ## Motivo dichiarato e verdetto | Motivo dichiarato | Verdetto | | --- | --- | | "Sarà più veloce" | Debole, ottimizzi prima il tema | | "È più moderno" | Non è un motivo | | "Ci serve un'interazione su misura che i temi non fanno" | Forte | | "Un front end, più backend" | Forte | | "Il nostro team costruisce già React" | Di supporto, non sufficiente | | "Vogliamo più controllo sul design" | Debole, i temi permettono molto | | "Ce lo ha consigliato l'agenzia" | Chieda cosa abilita di specifico | ## I costi che vengono sottostimati **Le app di vetrina smettono di funzionare.** Il più grande. Le app che si mostrano in vetrina si appoggiano alle theme app extensions, che un front end su misura non ha. Recensioni, upsell, widget video, messaggi di offerta: funzionalità che oggi ottiene installando qualcosa diventano funzionalità che deve costruire e mantenere. Faccia un audit delle app di vetrina prima di impegnarsi; la lista è di solito più lunga del previsto. **I merchant perdono l'editor del tema.** Qualunque modifica ai contenuti faccia il suo team diventa qualcosa da costruire, tramite metafield, metaoggetti o un CMS separato. Salti questo passaggio e ogni cambio di testo diventa un ticket per lo sviluppatore, esattamente il collo di bottiglia che la maggior parte dei team sta cercando di evitare. **Possiede il front end per sempre.** Aggiornamenti del framework, manutenzione delle dipendenze, compatibilità con i browser e accessibilità diventano tutti responsabilità sue. Un tema riceve aggiornamenti dal suo autore; la sua vetrina riceve solo quello che le dà lei. **I miglioramenti di front end di Shopify smettono di arrivare.** Il lavoro della piattaforma su temi e prestazioni della vetrina non raggiunge un front end su misura. Nel corso di diversi anni questo si accumula silenziosamente, ed è invisibile nel momento in cui prende la decisione. ## Prima di impegnarsi su headless - Nomini la cosa specifica che un tema non può fare - Elenchi ogni app di vetrina da cui dipende e cosa la sostituisce - Decida come i merchant modificheranno i contenuti, e lo costruisca - Confermi di avere capacità React per mantenerlo, non solo per costruirlo - Ottimizzi prima il tema attuale e misuri cosa recupera - Preventivi la manutenzione continuativa, non solo la costruzione ## Hydrogen contro costruirlo da soli Se va headless su Shopify, Hydrogen è la scelta sensata di default. È il framework supportato da Shopify, gestisce l'integrazione con la Storefront API in modo idiomatico, e Oxygen rimuove le decisioni sull'hosting. Costruire da soli con un framework diverso è difendibile quando ha requisiti specifici che Hydrogen non serve bene, o infrastruttura esistente che sta estendendo invece di sostituire. Significa che più lavoro di integrazione è suo, e meno dell'ecosistema si applica. Per la maggior parte dei team la domanda non è quale framework ma se andare headless del tutto. Una volta risposto affermativamente, Hydrogen è di solito la risposta alla seconda domanda. ## Cosa cambia, e cosa no, nel checkout Un malinteso frequente che vale la pena chiarire: andare headless non significa costruire il proprio checkout. Il checkout resta di Shopify. La sua vetrina su misura gestisce navigazione, pagine prodotto e carrello, poi passa il testimone al checkout Shopify per il pagamento. È deliberato ed è positivo: il checkout è la superficie a rischio più alto in qualsiasi negozio, comporta obblighi di conformità sui pagamenti, e Shopify lo migliora continuamente. Seguono tre conseguenze. **Checkout Extensibility continua ad applicarsi.** Le estensioni UI, le Functions per sconti e logica di consegna e il branding tramite l'admin funzionano tutti allo stesso modo. Il suo investimento lì non si perde quando cambia la vetrina, come spiegato in [Checkout Extensibility](/shopify-checkout-extensibility). **Il passaggio di mano è un problema di design.** Un cliente che si sposta dalla sua vetrina su misura al checkout Shopify attraversa un confine visivo. La configurazione del branding riduce lo scarto ma non lo elimina, e una transizione brusca nel momento del pagamento costa conversione. Pianifichi quel punto. **Lo stato del carrello deve sopravvivere alla transizione.** È un lavoro ordinario piuttosto che difficile, ma è lavoro, ed è un punto dove le build headless acquisiscono bug sottili, uno sconto applicato sulla vetrina che non si trasferisce, o un carrello che si svuota al ritorno. ## Pianificare la migrazione in sé Se decide che headless è giusto, la migrazione porta rischi che non hanno a che fare con l'architettura ma con il sostituire un intero front end in una volta. **Gli URL non devono cambiare.** Ogni URL di prodotto, collezione e contenuto dovrebbe risolversi esattamente come prima. È il rischio SEO più grande del progetto ed è del tutto evitabile, come trattato con più dettaglio in [migrare senza perdere la SEO](/it/migrare-da-woocommerce-shopify-senza-perdere-seo) per il caso di una migrazione completa di piattaforma. **I dati strutturati vanno ricostruiti.** Il suo tema emetteva lo schema prodotto. La sua vetrina su misura emette quello che scrive lei, ed è facile spedire senza e non accorgersene per mesi. **Il rendering lato server non è opzionale.** Il contenuto renderizzato solo nel browser è contenuto che alcuni crawler e agenti non vedono in modo affidabile. Hydrogen renderizza lato server di default; il rischio è in quello che viene aggiunto dopo. **Faccia girare i due in parallelo se può.** Migrare un sottoinsieme di template per primo, o far girare la nuova vetrina su un dominio di staging con dati reali, fa emergere i problemi mentre quella vecchia sta ancora servendo i clienti. > **Misuri prima e dopo, sugli stessi termini** > > Prenda le basi di Core Web Vitals, tasso di conversione e traffico organico prima del passaggio. Le migrazioni headless coincidono spesso con un cambio di traffico, e senza una base non può distinguere un problema di migrazione da uno stagionale, i due sembrano identici per il primo mese, che è esattamente quando ha bisogno di saperlo. ## Una via di mezzo più economica Vale la pena conoscerla prima di impegnarsi, perché soddisfa buona parte della motivazione a una frazione del costo. I temi Shopify moderni sono considerevolmente più flessibili di quanto la reputazione suggerisca, e il sistema a blocchi di Horizon con composizione annidata ha ampliato ulteriormente questo. Un tema su misura ben costruito può esprimere la maggior parte dei design, e mantiene la compatibilità con le app, l'editor del tema e i miglioramenti della piattaforma. Per la maggior parte dei negozi la cui motivazione è il controllo sul design, un tema su misura è la risposta giusta. Headless è per quando il vincolo è strutturale piuttosto che estetico. Un test utile prima di impegnarsi in un senso o nell'altro: faccia progettare a un designer la vetrina che vuole davvero, poi chieda a uno sviluppatore Shopify esperto se un tema può costruirla. Se la risposta è sì con del lavoro su misura, che di solito è il caso, ha la sua risposta, e la ha prima di spendere il budget piuttosto che dopo. ## Quanto costa, e quando chiedere aiuto Un progetto headless su Hydrogen parte da 5.000 $ secondo i listini pubblicati sulla [pagina servizi headless di ByteInfy](https://byteinfy.com/services/headless-shopify-hydrogen), e sale a 25.000 $ o più con modelli di contenuto su misura, multi-mercato e integrazioni. Questa cifra si somma, non sostituisce, alle voci trattate in [quanto costa un negozio Shopify nel 2027](/it/agenzia-shopify-quanto-costa-negozio-nel-2027-prezzi), dove headless compare come la fascia più alta, non come il punto di partenza tipico. Prima di chiedere un preventivo, verifichi che l'agenzia le abbia posto la domanda che inquadra tutto, e non solo accettato il brief così com'è. Le domande da fare a qualsiasi agenzia, comprese quelle su questa decisione specifica, sono in [come scegliere un'agenzia Shopify](/it/come-scegliere-agenzia-shopify-12-domande-da-fare). **Non sa se le serve headless o un tema migliore** ByteInfy costruisce entrambi, temi Shopify su misura e vetrine Hydrogen, e le dirà chiaramente quale dei due i suoi requisiti giustificano davvero. [Parla con ByteInfy](https://byteinfy.com/contact) ## FAQ ### Shopify headless con Hydrogen è più veloce di un tema normale? Non intrinsecamente. Headless dà il controllo su cosa carica e quando, il che rende raggiungibile un'ottima prestazione. ### Cos'è Hydrogen? Il framework di Shopify basato su React per costruire vetrine su misura contro la Storefront API, di solito distribuito su Oxygen, l'hosting di Shopify per esso. ### Le app Shopify funzionano con una vetrina headless? Le app rivolte alla vetrina in genere no, perché si appoggiano alle theme app extensions che un front end su misura non ha. Le app lato admin continuano a funzionare. ### I merchant possono ancora modificare una vetrina headless? Non tramite l'editor del tema, che non si applica. Qualunque modifica ai contenuti serva ai merchant va costruita, di solito tramite metafield, metaoggetti o un sistema di contenuti separato. ### Quando non dovrei andare headless? Quando la sua ragione è solo la velocità, quando il suo team non ha capacità React, quando dipende da app di vetrina, o quando la risposta onesta a "cosa costruiremo che un tema non può fare" non è chiara. ### Quanto costa un progetto headless con Hydrogen? I listini pubblicati partono da 5.000 $ per una vetrina Hydrogen circoscritta, e salgono a 25.000 $ o più con modelli di contenuto su misura, multi-mercato e integrazioni. --- --- title: "Shopify Horizon: What the New Theme System Changes" description: "Horizon is not a new theme so much as a new way of building them — blocks nested inside blocks, up to eight levels, which moves a lot of layout work out of code and into the editor." author: "Aashish Kaushik" published: 2026-10-10T13:01:02.966Z updated: 2026-10-10T13:01:02.970Z url: https://blog.byteinfy.com/shopify-horizon-theme --- # Shopify Horizon: What the New Theme System Changes ## Key takeaways - Horizon is a block-based theme system supporting up to eight levels of nesting, not simply another theme in the store. - The practical shift is that layout composition moves from developer to merchant, which changes who is blocked on whom during a build. - Deep nesting is powerful and easy to abuse — a page assembled eight levels deep is hard to maintain and easy to make slow. - Existing Online Store 2.0 themes keep working; this is an opportunity to evaluate, not an emergency migration. Shopify ships themes constantly and most of them do not warrant a strategy conversation. Horizon does, because it is not really a theme. It is a change to how themes are composed, and that changes who does the work. The headline capability is nesting: blocks can contain other blocks, up to eight levels deep. That sounds like an implementation detail and is not. It moves a category of work that previously required a developer into the theme editor, and the consequences of that are organisational as much as technical. > **What this is not** > > This is not a migration guide. Existing Online Store 2.0 themes keep working. This is an assessment of what changes and who should care. ## What nesting actually enables Under Online Store 2.0, a page was a stack of sections, and each section contained blocks. The structure was two levels deep and largely fixed by whoever built the section. A merchant could reorder sections and configure blocks within them. Anything else — a two-column layout inside a section, a card containing a group of elements, a repeating pattern with its own internal structure — was a development task. With blocks nesting inside blocks, those arrangements become editor operations. A merchant can build a container, put a grid inside it, put cards inside the grid, and put text and image blocks inside the cards, without touching Liquid. The practical consequence is a change in the shape of a project. A conventional Shopify build has a long tail of small layout requests that each need a developer, each wait in a queue, and each cost more in coordination than in work. That tail shrinks considerably. Developers build the components and the merchant assembles pages from them — which is how most other content systems already work, and is a genuine improvement in throughput. ## The failure mode is obvious once you name it Eight levels of nesting is a lot of rope. A page assembled at maximum depth is difficult to reason about, difficult to hand to someone else, and difficult to change safely. The person who built it knows that the spacing problem is coming from a container four levels up; nobody else does. This is the same failure that afflicts every flexible page builder, and Horizon does not exempt you from it. There is also a performance dimension. Nesting itself is not expensive, but nesting invites accumulation — more blocks, more images, more independently-configured elements on a page that used to be a simple section stack. The system does not make pages slow; it makes it easy to build slow pages without noticing you have. ## Conventions worth agreeing before you build - A maximum nesting depth for ordinary pages — most teams find three or four sufficient - Named, reusable patterns for common arrangements rather than ad-hoc assembly each time - A rule about who may restructure templates, as opposed to editing content within them - A performance budget checked on real pages, not on the theme preview - Documentation of where global spacing and typography are set, so nobody hunts for it The first of those is the one that matters most. Available depth is not a target. Most commerce pages are well served by three levels, and the discipline to stop there is what keeps the store maintainable eighteen months later. ## What it changes for a redesign If a redesign is already on your roadmap, Horizon changes the calculus in two ways. **It moves cost from build to design.** When layout composition is cheap, the expensive part becomes deciding what the layouts should be. A project that would have spent its budget on implementing twelve bespoke sections can spend it on getting the design system right — spacing scale, typography, component inventory — and assemble pages from that. This is a better allocation, but only if someone does the design work. Teams that skip it end up with a flexible system and no coherent visual language, which is worse than a rigid system with one. **It changes the handover.** The deliverable stops being a set of finished pages and becomes a kit: components, patterns and rules for assembling them. That is more valuable and requires more explanation. Budget for the documentation, because an undocumented flexible system reverts to a developer-dependent one the moment the person who built it moves on. ## The SEO risks are the ordinary ones Every theme change carries the same set of risks, and Horizon introduces no special ones. The failures are predictable and therefore preventable: ## Theme migration risks and how to catch them | Risk | How it happens | Check before launch | | --- | --- | --- | | Heading hierarchy breaks | Blocks render their own headings, producing multiple H1s or skipped levels | Crawl staging and audit the heading tree per template | | Structured data lost | Old theme emitted product schema the new one does not | Run key templates through a structured data validator | | Internal links change | Navigation and cross-links rebuilt from scratch | Compare internal link graph before and after | | Image handling differs | Sizes, formats or lazy-loading change | Measure Core Web Vitals on real product pages | | Alt text dropped | Image blocks reconfigured without carrying alt text over | Spot-check product and content images | | URLs change | Rarely intended, occasionally a side effect | Confirm no URL changed; if any did, redirect it | The heading one is the most common and the least noticed. Block-based composition makes it easy to produce a page with three H1s or a jump from H2 to H4, because each block was authored independently and nobody looked at the resulting document outline. > **Do not redesign and re-platform your content at once** > > The temptation during a theme migration is to also rewrite copy, restructure collections and change URLs. Doing them together means that when traffic moves, you cannot attribute it. Ship the theme change with content held constant, confirm stability, then make content changes as a separate release. ## How this sits alongside the rest of the 2026 releases Horizon did not arrive alone, and it reads differently in context. The Summer '26 Edition shipped more than 150 updates on 17 June 2026, and several of them point the same direction: moving control out of code and into configuration. Native A/B testing arrived in the same window, letting merchants schedule, gradually release and split-test themes, checkout and customer-account configurations without a third-party tool. Checkout Components became generally available to Plus merchants, allowing the post-cart flow to be customised with drag-and-drop blocks. Read together with Horizon, the pattern is unmistakable — the surfaces that previously required a developer are becoming merchant-configurable, one at a time. That matters for how you plan. If you are budgeting a build on the assumption that every layout, test and checkout variation is a development ticket, the estimate is probably wrong in a useful direction. It also means the skills that matter on a Shopify team are shifting: less Liquid, more design systems, measurement and knowing which of the now-configurable things are worth configuring. The corollary is a governance question most merchants have not faced. When layout, checkout flow and live experiments are all editable from the admin, the risk is no longer that changes are slow — it is that changes are untracked. A store where four people can restructure the product template and nobody records who changed what is a store where a conversion drop takes a week to diagnose. Whatever you adopt, decide early who may change what, and keep a note of when significant changes ship. A dated changelog in a shared document is enough; the absence of one is what turns a small regression into an investigation. ## Who should act, and when **Adopt now** if you are building a new store, or if your current bottleneck is that routine layout changes require a developer. That bottleneck is exactly what this addresses, and the payback is immediate. **Evaluate, do not rush** if you have a working, performant Online Store 2.0 theme and no pressing layout complaints. Nothing is deprecated. The cost of waiting is low and the ecosystem of patterns and apps built for the new model will be better in six months than it is now. **Prototype first** if you have heavy customisation, unusual templates, or apps deeply integrated into your theme. The nesting model interacts with custom work in ways worth discovering on a copy of your theme rather than on your storefront. Whichever bucket you fall into, the sequencing advice is the same: duplicate your live theme, build one representative template in the new model, and measure it against the equivalent page you already run. One product page and one collection page will tell you almost everything — whether the components you need exist, how deep you actually end up nesting, and what it costs in page weight. That is a day of work, and it converts an architectural decision from a matter of opinion into one with evidence behind it. For the performance side of theme decisions, see [storefront and design](/category/storefront-design). Migration risk and the wider redesign question are covered in the same archive, and the [Shopify development](/category/shopify-development) archive goes into the theme-versus-custom-build decision in more depth. **Planning a Shopify redesign?** ByteInfy designs and builds Shopify storefronts — component systems, theme work and the performance budget to go with it. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Do I have to migrate to Horizon? No. Existing Online Store 2.0 themes continue to work and are not deprecated by Horizon's arrival. ### What is actually new about Horizon compared to Online Store 2.0? Online Store 2.0 introduced sections and blocks, but blocks lived inside sections and could not contain other blocks. Horizon allows blocks to nest inside blocks, up to eight levels deep. ### Will moving to Horizon hurt my SEO? A theme change carries the usual risks — altered heading structure, changed internal linking, lost structured data, different image handling. ### Is Horizon faster than my current theme? Not automatically. The block system does not itself make pages heavy or light — what you assemble with it does. ### Should a new store start on Horizon? For most new builds, yes, if the merchant intends to make ongoing layout changes themselves. The composition flexibility is genuinely useful and starting there avoids a migration later. --- --- title: "Come scegliere un'agenzia Shopify: 12 domande da fare" description: "Un portfolio dimostra che qualcosa è stato lanciato. Non dice se funziona ancora, chi lo mantiene o cosa ha lasciato nel tema di qualcuno. Queste dodici domande fanno emergere quello che il portfolio non mostra, e le risposte separano le agenzie meglio di qualsiasi caso studio." author: "Aashish Kaushik" published: 2026-10-10T05:01:02.857Z updated: 2026-10-10T05:01:03.047Z url: https://blog.byteinfy.com/come-scegliere-agenzia-shopify-12-domande-da-fare --- # Come scegliere un'agenzia Shopify: 12 domande da fare ## Key takeaways - La domanda più utile è cosa hanno costruito due anni fa e se funziona ancora; Shopify ritira le versioni delle API con calendario pubblico, e un'agenzia con esperienza ha vissuto più di uno di questi ritiri. - Le risposte tecniche che contano sono concrete: theme app extensions per ciò che si vede in negozio, Shopify Functions per sconti e regole di checkout, un processo scritto per le deprecazioni. - Proprietà del codice, documentazione e cosa potrà modificare il suo team senza l'agenzia si concordano per iscritto prima di iniziare, perché dopo sono conversazioni scomode. - Un'agenzia che le dice cosa non costruire sta esercitando un giudizio, ed è quel giudizio che sta comprando davvero; quella che è d'accordo con tutto ciò che propone sta vendendo perimetro. Scegliere un'agenzia Shopify è difficile perché il lavoro è invisibile per chi lo compra. Lei vede il negozio e non il codice, e la differenza tra i due emerge solo quando bisogna cambiare qualcosa diciotto mesi dopo. Le dodici domande di questo articolo servono a rendere visibile quella differenza prima di firmare, non dopo. I portfolio non aiutano molto in questo. Dimostrano che qualcosa è stato costruito e lanciato. Non dicono se funziona ancora, quanto è costato mantenerlo né cosa ha lasciato nel tema di qualcuno. Le domande che seguono sono raggruppate in quattro blocchi (lavoro passato, tecnica, proprietà e mercato), e alla fine c'è una tabella per interpretare le risposte, i segnali d'allarme e come strutturare il primo incarico. > **Scritto da un'agenzia** > > Legga con questa riserva. Le domande qui sotto sono quelle che ci aspetteremmo ci venissero fatte, e un'agenzia che le risponde con disagio merita cautela, noi compresi. ByteInfy ha sede in India, lavora con merchant di diversi paesi e pubblica i prezzi di partenza sulla propria [pagina servizi](https://byteinfy.com/services); il resto di questo articolo non parla di noi. ## Domande sul lavoro che hanno già fatto Le prime tre domande guardano indietro, perché quello che un'agenzia ha costruito due anni fa dice più di lei di quello che promette di costruire il mese prossimo. ### 1. Cosa avete costruito due anni fa e funziona ancora? La domanda più rivelatrice che esiste, e quasi mai viene fatta. Chiunque può lanciare qualcosa. La parte interessante è cosa è successo dopo: se funziona ancora, se ha avuto bisogno di interventi d'urgenza, se ha sopravvissuto ai cambi di piattaforma avvenuti da allora. Shopify pubblica ogni trimestre una nuova versione delle proprie API e ritira quelle vecchie con calendario noto; gli Scripts non esistono più e le loro funzioni sono passate a Shopify Functions; checkout.liquid è stato sostituito da Checkout Extensibility; i temi sono cambiati con Online Store 2.0 e poi con Horizon. Un'agenzia con diversi anni sulla piattaforma ha vissuto tutto questo, e come lo ha gestito è un segnale migliore di qualsiasi caso studio. Chieda di vedere un negozio o un'app concreta, con data, e chieda cosa hanno dovuto toccare da allora. Un'agenzia che risponde "niente" o mente o non ha guardato. ### 2. Quale progetto è andato male e cosa avete imparato? Ogni agenzia con storia ha progetti che non sono andati come previsto. Quella che lo riconosce e spiega cosa è cambiato nel suo processo sta mostrando maturità; quella che dice che non le è mai successo sta mostrando poca esperienza o poca sincerità, ed entrambe le cose costano denaro. ### 3. Posso parlare con un cliente che lavora con voi da più di un anno? Le referenze che un'agenzia offre di default sono quelle di clienti recenti e contenti. Ne chieda una vecchia. Un cliente che è con loro da più di un anno può raccontare com'è stato il supporto dopo il lancio, come sono stati gestiti i cambiamenti e se il preventivo finale si è avvicinato a quello iniziale, che sono esattamente le cose che un portfolio non mostra. ## Domande tecniche Le quattro successive hanno risposte corrette concrete, e sono informative anche se non può valutarle a fondo. Se qualcuno di sua fiducia conosce Shopify, lo faccia partecipare alla chiamata. ### 4. Come integrate quello che si vede in negozio? La risposta dovrebbe essere theme app extensions e sezioni del tema. Un'agenzia che continua a iniettare codice nei file del tema sta costruendo qualcosa che il merchant non potrà rimuovere in modo pulito, e quel residuo è la lamentela più frequente di chi eredita un negozio da un'altra agenzia. Chieda anche cosa resta nel tema quando si disinstalla una loro app; la risposta buona è "niente che lei non abbia chiesto". ### 5. Come implementereste uno sconto che Shopify non offre di serie? Shopify Functions. Se propongono di manipolare il carrello con JavaScript o un'app che modifica i prezzi al volo, quel comportamento viene saltato dai checkout accelerati e smette di funzionare non appena Shopify cambia qualcosa. Le regole di sconto, spedizione e pagamento vivono oggi nelle Functions e nelle estensioni di checkout, e un'agenzia che lavora su Shopify nel 2027 lo sa. L'articolo su [sconti personalizzati con Shopify Functions](/it/sconti-personalizzati-con-shopify-functions-fine-degli) spiega cosa si può fare e cosa no. ### 6. Come gestite le deprecazioni delle API? Deve esserci un processo: un inventario di quello che hanno costruito, un calendario e qualcuno assegnato a rivederlo. "Lo vediamo quando capita" significa che lo vedrà lei quando si rompe, probabilmente in piena campagna. Chieda quando è stata l'ultima volta che hanno aggiornato un'app o un'integrazione per una deprecazione e quanto hanno fatturato per farlo. L'articolo sul [versionamento delle API Shopify](/shopify-api-versioning) spiega perché questo non è opzionale. ### 7. Come testate quello che consegnate? Non serve una risposta elaborata, ma deve essercene una, soprattutto per tutto ciò che tocca denaro: sconti, pagamenti, tasse, spedizioni. Un negozio di prova, un tema duplicato prima di pubblicare, ordini di prova con ogni metodo di pagamento. Se la risposta è "lo testiamo sul negozio reale con attenzione", il suo negozio reale è l'ambiente di test dell'agenzia. ## Domande su proprietà e consegna Le tre successive sono commerciali, e decidono se alla fine avrà un asset o una dipendenza. Sono facili all'inizio e scomode alla fine, quindi vanno fatte all'inizio. ### 8. Chi è proprietario del codice, e che documentazione ricevo? Quello che viene concordato, ed è per questo che si concorda per iscritto prima di iniziare. I clienti spesso danno per scontato che il lavoro su misura sia loro; le agenzie spesso vogliono conservare i componenti riutilizzabili. Entrambe le posizioni sono ragionevoli. Quello che non è ragionevole è scoprirlo alla separazione. Sulla documentazione, la domanda utile è se il prossimo sviluppatore potrebbe continuare il lavoro senza chiamare l'agenzia. Un registro dei cambiamenti per file, accesso al repository e una spiegazione di ogni integrazione è il minimo. ### 9. Cosa potrà modificare il mio team senza di voi? La voce che si dimentica di più. Un negozio le cui sezioni può toccare solo lo sviluppatore trasforma un costo una tantum in uno permanente. Chieda esplicitamente che le sezioni siano modificabili dall'editor del tema, che i testi e le immagini di campagna non richiedano codice, e che glielo mostrino in una demo prima di considerare finito il progetto. ### 10. Cosa succede dopo il lancio, e quanto costa? Tutto ciò che è su misura ha bisogno di manutenzione, perché Shopify cambia in modo continuo. Un preventivo che copre il lancio e non dice nulla dei mesi successivi descrive metà del costo. Chieda se c'è supporto incluso e per quanto tempo, se offrono un retainer e cosa include, e cosa succede agli accessi e ai repository se il rapporto finisce. ## Domande sul suo mercato Le ultime due dipendono da dove vende, e sono quelle che distinguono un'agenzia che conosce il suo mercato da una che lo scoprirà con i suoi soldi. ### 11. Quali particolarità del mio mercato devono comparire nel perimetro? Se vende in Italia, la risposta dovrebbe includere la fatturazione elettronica verso lo SDI, l'IVA e l'OSS se vende ad altri paesi dell'Unione Europea, i corrieri abituali (BRT, GLS, Poste, SDA) e i metodi di pagamento locali come Satispay accanto a carte e PayPal. Un'agenzia che non lo chiede lo imparerà durante il suo progetto. L'articolo su [fatturazione elettronica e Shopify](/it/shopify-fatturazione-elettronica-italia-come-metterla-norma) raccoglie cosa deve essere risolto in un negozio italiano su questo punto specifico. Noti che la sede dell'agenzia non è la domanda. Un'agenzia fuori dal suo paese che fa queste domande alla prima chiamata e le mette per iscritto va bene; un'agenzia nella sua stessa città che non le fa, no. L'articolo sui [costi di agenzia tra India e Stati Uniti](/shopify-agency-india-usa-cost) confronta cosa cambia davvero con la sede. ### 12. Cosa mi direste di non costruire? La domanda più utile di tutta la conversazione, e viene lasciata per ultima apposta. Un'agenzia senza risposta sta vendendo perimetro. Una che dice "non le serve headless", "questo lo fa un tema" o "quell'app esiste già e costa meno di noi" sta esercitando un giudizio, ed è il giudizio quello che sta davvero comprando. Vale lo stesso per il suo incarico specifico: se chiede un negozio su misura e la risposta onesta è che un tema configurato le servirebbe meglio, vuole sentirselo dire prima del preventivo e non dopo la fattura. Il confronto tra le due strade è approfondito in [Shopify headless con Hydrogen: quando conviene](/it/shopify-headless-con-hydrogen-quando-conviene). Un'agenzia che è d'accordo con tutto quello che lei propone ha una fortuna insolita con i propri clienti oppure non sta pensando molto all'incarico che ha davanti. ## Come interpretare le risposte Le risposte non sono buone o cattive in astratto; sono segnali, e conviene avere chiaro quale segnale è ciascuna prima della chiamata. ## Cosa dice ogni risposta | Domanda | Risposta che rassicura | Risposta che preoccupa | | --- | --- | --- | | Lavoro di due anni fa | Un esempio concreto e cosa hanno dovuto toccare | "È tutto uguale" o nessun esempio | | Progetto andato male | Un caso e un cambio di processo | "Non ci è mai successo" | | Come integrano il visibile | Theme app extensions e sezioni modificabili | Codice nei file del tema | | Sconti su misura | Shopify Functions, con i suoi limiti | Manipolare carrello o prezzi con JavaScript | | Deprecazioni API | Inventario, calendario e responsabile | "Lo vediamo quando capita" | | Test | Negozio di prova e tema duplicato | Test sul negozio reale | | Proprietà del codice | Per iscritto, con repository e documentazione | "Ne parliamo dopo" | | Cosa modifica il suo team | Demo dell'editor del tema prima di chiudere | Tutto passa dall'agenzia | | Manutenzione | Supporto definito e retainer opzionale con prezzo | Non compare nel preventivo | | Il suo mercato | Chiedono di pagamenti, tasse e spedizioni locali | Preventivano senza chiedere | | Cosa non costruire | Una lista concreta e argomentata | Tutto quello che propone va bene | Non serve che un'agenzia risponda bene a tutte e dodici. Quello che cerca è uno schema. Due o tre risposte deboli su domande di processo possono essere un'agenzia giovane con buon criterio tecnico; risposte deboli su proprietà, manutenzione e "cosa non costruire" insieme descrivono un'agenzia che vende progetti, non risultati. ## Segnali d'allarme Ci sono schemi che si ripetono nei progetti finiti male, e si vedono nella prima conversazione. **Preventivo senza domande.** Un'agenzia che manda un numero senza capire cosa vende sta preventivando con un modello, e i modelli non conoscono il suo catalogo. **Stima senza manutenzione.** Già detto, ma è il segnale più frequente e il più costoso. **Riluttanza a parlare della consegna.** Se proprietà e documentazione sono argomenti scomodi all'inizio, saranno peggiori alla fine. **L'opzione più cara di default.** Headless dove basterebbe un tema, sviluppo su misura dove esiste un'app. **Nessun esempio di lavoro vecchio ancora attivo.** O lavorano da poco, o il lavoro vecchio non è qualcosa di cui vogliono parlare, ed entrambe le cose conviene saperle. **Rifiuto di parlare con il suo sviluppatore attuale.** Se ne ha uno, un'agenzia che lo tratta come una minaccia anziché come una fonte di contesto sta anteponendo il rapporto al risultato. **Prezzi molto sotto la fascia.** Un negozio completo per 500 $ è quasi sempre un tema con valori di default e i prodotti caricati a mano. Non c'è niente di male se è ciò che le serve, ma non è ciò che il preventivo suggerisce. L'articolo su [quanto costa un negozio Shopify nel 2027](/it/agenzia-shopify-quanto-costa-negozio-nel-2027-prezzi) colloca le fasce di prezzo e spiega cosa c'è in ciascun estremo. ## Come strutturare il primo incarico Come organizza il primo lavoro conta quanto chi sceglie, perché determina quanto impara prima di impegnarsi di più. ## Prima di firmare, per iscritto - Perimetro per voci e cosa significa terminato per ciascuna - Chi è proprietario del codice e cosa succede ai componenti riutilizzabili - Quale documentazione viene consegnata e in che formato - Chi mantiene quanto costruito dopo il lancio e a quale costo - Cosa succede ad accessi e repository se il rapporto finisce - Come si gestiscono le deprecazioni delle API e chi paga gli aggiornamenti - Cosa potrà fare il suo team senza l'agenzia, dimostrato nell'editor del tema - Le particolarità del suo mercato (pagamenti, tasse, spedizioni, fatturazione) come voci del perimetro - Valuta, imposte e calendario dei pagamenti **Cominci con qualcosa di circoscritto.** Un progetto definito con una fine chiara, un audit, un'integrazione, un template di campagna, le insegna come lavora un'agenzia con una frazione del rischio di un negozio intero. **Osservi la prima sorpresa.** Ogni progetto incontra qualcosa di inatteso. La reazione è molto più informativa della proposta: lo comunicano presto con opzioni, o lo assorbono in silenzio e lo menzionano quando la scadenza slitta. **Confronti la stima con il risultato.** Non per punire lo scostamento (le stime sono stime), ma perché come l'agenzia lo comunica anticipa com'è un progetto grande. **Chieda di vedere il codice**, anche se non può valutarlo del tutto. Che qualcuno lo guardi, o almeno verifichi che esiste in un repository a cui lei ha accesso, che è documentato e che non è un unico file enorme. ## Agenzia, freelance o team interno Non c'è una risposta universale, e le differenze sono abbastanza chiare. **Un freelance** è spesso un valore migliore per un lavoro definito e circoscritto, e lei tratta direttamente con chi lo fa. Il rischio è la disponibilità futura: lo sviluppatore che ha costruito la sua integrazione potrebbe non essere raggiungibile quando serve aggiornarla. **Un'agenzia** ha senso quando conta la continuità, quando intervengono più discipline (design, sviluppo, SEO, integrazioni) o quando il lavoro è continuativo. In parte paga il fatto che qualcuno resterà lì. Il rischio è pagare una struttura che il progetto non richiede. **Un team interno** si adatta a negozi con esigenze di sviluppo continue e lavoro sufficiente a giustificare l'assunzione. Sotto quella soglia è capacità costosa e inutilizzata. Una combinazione abituale e sensata è un'agenzia o un freelance per progetti definiti, con capacità interna sufficiente per le modifiche di routine e per valutare quanto viene consegnato. Se le serve la versione con più dettaglio su come fare il brief a un'agenzia, è in [assumere un'agenzia di sviluppo Shopify senza indovinare](/hire-shopify-development-agency). E per capire cosa significa davvero "Shopify Partner" quando un'agenzia lo cita, veda [agenzia Shopify Partner: cosa significa e perché conta](/it/agenzia-shopify-partner-cosa-significa-perche-conta). E qualunque sia la scelta, la regola non cambia: descriva il problema, non la soluzione. "Le nostre pagine prodotto su mobile perdono persone prima del pulsante d'acquisto" dà a un'agenzia qualcosa da risolvere. "Ci faccia un tema su misura" dà un'istruzione che potrebbe essere quella sbagliata. **Vuole una risposta onesta su cosa le serve** Ci dica cosa vende, dove e cosa non funziona, e le diremo cosa costruire, cosa no e quanto costerebbe ciascuna cosa, per iscritto e prima di qualsiasi impegno. [Parla con ByteInfy](https://byteinfy.com/contact) ## FAQ ### Cosa devo guardare quando scelgo un'agenzia Shopify? Prove che quello che costruiscono sopravvive. Chieda di lavori di due anni fa, come gestiscono le deprecazioni delle API, se quello che si vede in negozio usa theme app extensions e quale documentazione consegnano. ### Un'agenzia italiana costa più di una estera? Di norma sì, perché il costo orario riflette il costo del lavoro locale. ### Agenzia o freelance per un progetto Shopify? Un freelance è spesso un valore migliore per un lavoro definito e circoscritto, e tratta direttamente con chi lo fa. ### Come capisco se un'agenzia è buona prima di assumerla? Cominci con un incarico piccolo e definito, un audit, un'integrazione o un template, e osservi come comunica, come stima e come reagisce alla prima sorpresa. ### Chi è proprietario del codice che scrive un'agenzia? Quello che viene concordato, ed è per questo che va concordato per iscritto prima di iniziare. ### Quanto costa un'agenzia Shopify? Dipende dal perimetro, e la cifra che conta di più è quella della manutenzione. Un negozio d'agenzia si muove nella maggior parte dei casi tra 2.000 e 8. ### Quali segnali indicano che devo scartare un'agenzia? Che faccia un preventivo senza chiedere del suo business, che non menzioni la manutenzione, che eviti la conversazione su proprietà e consegna, che proponga headless o sviluppo su misura di default, che non possa mostrare lavori vecchi ancora attivi, e che tratti il suo sviluppatore attuale come una minaccia. --- --- title: "Migrare da WooCommerce a Shopify senza perdere la SEO" description: "La SEO non si perde cambiando piattaforma. Si perde con gli URL che cambiano senza redirect e con i contenuti che restano indietro. Con un inventario completo, una mappa di redirect 301 e i metafield pensati bene, il traffico organico sopravvive al cambio." author: "Aashish Kaushik" published: 2026-10-09T13:01:11.380Z updated: 2026-10-09T13:01:11.383Z url: https://blog.byteinfy.com/migrare-da-woocommerce-shopify-senza-perdere-seo --- # Migrare da WooCommerce a Shopify senza perdere la SEO ## Key takeaways - Gli URL di WooCommerce e quelli di Shopify non coincidono mai, perché Shopify fissa i propri percorsi (/products/, /collections/, /pages/), quindi ogni URL vecchio con traffico ha bisogno di un redirect 301 esplicito. - Il lavoro che protegge la SEO si fa prima di spostare un solo prodotto, con un inventario di URL, traffico e link in entrata esportato da Search Console e dal database WordPress. - I campi personalizzati di WooCommerce (composizione, compatibilità, guide alle taglie) non hanno un equivalente automatico; vanno nei metafield di Shopify e la loro destinazione va decisa prima dell'importazione. - Dopo il cambio di DNS, le prime quattro settimane in Search Console dicono se la migrazione è andata bene; gli errori 404 sugli URL vecchi sono l'avviso da correggere lo stesso giorno. La SEO di un negozio non si perde cambiando piattaforma. Si perde quando gli URL cambiano senza che nessuno li reindirizzi, quando i contenuti che posizionavano restano su WordPress e quando il negozio nuovo parte con titoli, descrizioni e dati strutturati diversi da quelli che Google conosceva. Migrare da WooCommerce a Shopify senza perdere la SEO significa evitare queste tre cose, e quasi tutto il lavoro avviene prima di spostare un solo prodotto. Questo articolo segue l'ordine in cui conviene affrontare il processo: l'inventario preliminare, il problema degli URL, la mappa dei redirect 301, i metafield, i contenuti che devono sopravvivere, il giorno del cambio DNS e cosa guardare in Search Console dopo. Alla fine c'è una nota su quando farlo da soli e quando pagare qualcuno, con i prezzi di riferimento. Si rivolge a merchant italiani che vendono già su WooCommerce e hanno traffico organico da proteggere. Se il suo negozio è nuovo e ha poche posizioni, la migrazione è molto più semplice e può saltare metà di quello che segue. ## Perché si perde la SEO in una migrazione Google non posiziona negozi, posiziona URL. Ogni pagina prodotto, categoria o articolo del blog ha una propria storia di link, segnali e posizioni, ed è legata all'indirizzo esatto della pagina. Quando l'indirizzo cambia, Google vede una pagina nuova senza storia e una pagina vecchia scomparsa. Il redirect 301 è il meccanismo che dice a Google che la pagina vecchia si è trasferita in modo permanente a quella nuova, e che deve spostare i segnali accumulati. Senza, la pagina vecchia restituisce un errore 404, i segnali si perdono e la pagina nuova riparte da zero. Con una migrazione di mille prodotti e duecento categorie, ripartire da zero significa mesi di traffico perso. La seconda causa di perdita è il contenuto. WooCommerce permette di salvare informazioni in campi personalizzati, attributi, tab di plugin e widget, e buona parte finisce nell'HTML che Google legge. Se l'importazione a Shopify sposta solo titolo, descrizione, prezzo e immagini, le pagine nuove sono più povere delle vecchie, e posizionano peggio anche con il redirect corretto. La terza causa è più sottile: i dati strutturati, i titoli SEO e le meta description che un plugin come Yoast o Rank Math generava su WordPress non si copiano da soli. Shopify ha i propri campi per questo, e vanno compilati con quello che c'era, non con quello che il tema nuovo mette di default. ## Prima di spostare qualcosa: l'inventario Una migrazione senza inventario è una migrazione al buio, e l'inventario si fa su WooCommerce, non su Shopify. Cominci esportando tutti gli URL che Google conosce. Search Console permette di scaricare le pagine con impressioni e clic degli ultimi sedici mesi; quella lista è quella che conta davvero, perché sono gli URL che portano traffico. La completi con una scansione completa del sito (Screaming Frog o uno strumento simile) per catturare gli URL che esistono anche senza traffico, e con la lista delle pagine che ricevono link esterni, che può estrarre da Search Console o da uno strumento di backlink. A quella lista aggiunga, per ogni URL, il tipo di contenuto (prodotto, categoria, tag, pagina, articolo del blog, filtro), il traffico degli ultimi dodici mesi e il numero di link in entrata. La ordini per traffico. I primi cento URL meritano attenzione individuale; il resto può essere trattato con regole. Esporti anche i dati che WooCommerce salva fuori dal prodotto: attributi, campi personalizzati (meta del prodotto), termini di tassonomie proprie, testi delle tab dei plugin, recensioni. L'esportazione standard di WooCommerce in CSV non include tutto questo, e spesso serve un plugin di esportazione o una query diretta al database di WordPress. È il passaggio che si salta più spesso ed è quello che fa perdere più contenuto. > **I prodotti che non vende più** > > In un negozio con anni di storia ci sono prodotti fuori catalogo ma ancora indicizzati che ricevono visite. Non li scarti senza controllare: se hanno traffico o link, reindirizzi il loro URL alla categoria o al prodotto sostitutivo su Shopify. Se non hanno né l'uno né l'altro, un 404 pulito va bene, e Shopify lo restituisce senza che debba fare nulla. ## Gli URL di WooCommerce e quelli di Shopify non coincidono Shopify impone la struttura dei propri URL, e non c'è tema, app o impostazione che la cambi. È la prima sorpresa per molti merchant che vengono da WordPress, dove i permalink si configurano a piacere. ## Equivalenza dei percorsi tra piattaforme | Tipo di contenuto | WooCommerce (tipico) | Shopify (fisso) | | --- | --- | --- | | Prodotto | /prodotto/nome/ o /product/nome/ | /products/nome | | Categoria | /categoria-prodotto/nome/ | /collections/nome | | Tag prodotto | /tag-prodotto/nome/ | Nessun equivalente diretto, reindirizzare alla collezione | | Negozio | /negozio/ o /shop/ | /collections/all | | Pagina | /nome/ | /pages/nome | | Articolo blog | /blog/nome/ o /nome/ | /blogs/nome-del-blog/nome | | Filtro o attributo | /categoria/?pa_colore=rosso | Nessun URL proprio, reindirizzare alla collezione | Quello che può conservare è l'handle, cioè la parte finale dell'URL. Se un prodotto viveva in /prodotto/scarpa-trail-donna/, su Shopify può vivere in /products/scarpa-trail-donna. Mantenere l'handle non evita il redirect, ma rende la mappa molto più facile da generare con una regola invece che a mano, e conserva la parola chiave nell'URL. Presti attenzione a due dettagli. Shopify non permette barre finali né maiuscole negli handle, e converte i caratteri accentati: un handle con lettere accentate viene trasformato, quindi controlli come risulta ognuno prima di dare per buona la regola. E gli URL di filtri e attributi di WooCommerce, che in molti negozi generano migliaia di pagine indicizzate, non hanno una destinazione propria su Shopify; la scelta ragionevole è reindirizzarli alla collezione madre. I tag prodotto meritano una decisione a parte. Su WooCommerce ogni tag ha la propria pagina; su Shopify i tag filtrano dentro una collezione ma non generano un URL indicizzabile equivalente. Se una pagina tag aveva traffico, crei una collezione con quel nome e reindirizzi; altrimenti, reindirizzi alla categoria più vicina. L'articolo sulla [SEO delle pagine collezione](/shopify-collection-page-seo) spiega come sfruttare le collezioni per coprire quelle ricerche. ## La mappa dei redirect 301 La mappa dei redirect è il documento centrale della migrazione: una tabella con due colonne, URL vecchio e URL nuovo, con una riga per ogni URL dell'inventario che merita di essere conservato. Shopify gestisce i redirect da Negozio online, Navigazione, Redirect URL. Si possono creare uno per uno o importare in CSV, e l'importazione è l'unica opzione realistica per una migrazione vera. Il file ha due colonne, "Redirect from" e "Redirect to", con percorsi relativi, senza dominio. Un redirect di Shopify risponde con un 301 permanente, che è ciò di cui Google ha bisogno. Ci sono tre limitazioni da conoscere prima di costruire la mappa. Shopify non reindirizza percorsi che esistono già nel negozio nuovo, quindi non può reindirizzare /products/x se /products/x è un prodotto attivo. Shopify ignora i parametri di query nel confronto dei percorsi, quindi /categoria/?pa_colore=rosso e /categoria/ vengono trattati come lo stesso URL di origine; la soluzione è reindirizzare il percorso base e accettare che i filtri si perdano. E non ammette espressioni regolari né wildcard, quindi ogni URL ha bisogno della propria riga. Generi la mappa con regole per il grosso (prodotto per prodotto, categoria per collezione) e riveda a mano i cento URL con più traffico e quelli con link esterni. Quei cento sostengono la maggior parte del traffico organico di quasi ogni negozio, e un errore su uno di essi pesa più di cento errori su URL senza visite. Eviti le catene di redirect. Se su WooCommerce c'erano già redirect vecchi, il nuovo redirect deve portare dall'origine più antica direttamente alla destinazione su Shopify, senza passare dall'URL intermedio. Google segue catene brevi, ma ogni salto perde qualcosa e rallenta la rielaborazione. Eviti anche di reindirizzare tutto alla home page. È la soluzione rapida che alcuni plugin e alcune agenzie di fretta offrono, e Google la tratta come un 404 mascherato: il segnale non si trasferisce e chi cercava un prodotto specifico atterra su una pagina generica. ## Metafield: dove va quello che WooCommerce salvava nei campi personalizzati Quello che su WooCommerce erano campi personalizzati, attributi e tab di plugin, su Shopify sono metafield, e la decisione su quale campo va dove si prende prima dell'importazione, non dopo. Un metafield di Shopify ha un namespace, una chiave e un tipo (testo, numero, lista, riferimento a un altro prodotto, file, tra gli altri). I metafield si definiscono da Impostazioni, Dati personalizzati, e una volta definiti appaiono nell'editor di ogni prodotto e possono essere mostrati nel tema dall'editor di sezioni senza scrivere codice. Questo significa che la composizione di un cosmetico, la tabella di compatibilità di un ricambio o la guida alle taglie di un capo possono continuare ad apparire nella pagina prodotto, e quindi continuare a contare per la SEO. Il lavoro ha tre passaggi. Primo, elencare tutti i campi che WooCommerce salva per prodotto e decidere quali sono visibili sul sito (quelli vanno nei metafield) e quali sono interni (quelli possono andare in metafield nascosti, in tag o essere scartati). Secondo, definire i metafield su Shopify con il tipo corretto; un campo che su WordPress era testo libero ma in realtà conteneva sempre un numero conviene definirlo come numero per poterlo filtrare. Terzo, includere questi campi come colonne nel CSV di importazione dei prodotti, con il formato di intestazione che Shopify si aspetta per i metafield. Le varianti meritano attenzione a parte. WooCommerce permette attributi che non generano varianti e attributi che sì; Shopify ha fino a tre opzioni per prodotto che generano sempre varianti, con un limite di varianti per prodotto che è salito nel tempo ma resta comunque presente. Un prodotto con cinque attributi su WooCommerce non si importa così com'è: bisogna decidere quali sono opzioni d'acquisto (taglia, colore) e quali sono informazioni (materiale, provenienza), e queste ultime vanno nei metafield. L'articolo sui [metaoggetti e metafield di Shopify](/shopify-metaobjects-metafields) spiega come strutturare contenuti più complessi, come guide riutilizzabili o schede di ingredienti condivise tra prodotti. ## Il contenuto che deve sopravvivere intatto Oltre agli URL e ai metafield, ci sono quattro cose che Google leggeva nel negozio vecchio e che deve leggere allo stesso modo nel nuovo. **Titoli SEO e meta description.** Yoast, Rank Math e plugin simili salvano un titolo e una descrizione per pagina nella propria tabella, distinti dal nome del prodotto. Shopify ha i campi equivalenti su ogni prodotto, collezione e pagina, nella sezione "Elenco nei motori di ricerca", e il CSV di importazione li accetta come colonne. Esporti quelli del plugin e li carichi; non lasci che Shopify ne generi di nuovi a partire dalla descrizione, perché cambiare tutti i titoli in blocco è una delle cause più frequenti di calo dopo una migrazione. **Descrizioni lunghe e contenuto HTML.** La descrizione prodotto di WooCommerce ammette HTML, e molti negozi hanno tabelle, elenchi e titoli che aiutano a posizionare. Shopify ammette HTML nella descrizione, ma il CSV di importazione può alterare la formattazione se non è correttamente gestito. Controlli un campione di prodotti con descrizioni lunghe prima di importare l'intero catalogo. **Articoli del blog.** WooCommerce vive dentro WordPress, e molti negozi hanno decine di articoli che portano traffico. Shopify ha un blog, con meno funzioni, e gli articoli si importano con un CSV proprio o via API. Conservi handle, date di pubblicazione e autore. Se il blog aveva categorie, su Shopify diventeranno tag dell'articolo o blog separati. L'articolo sulla [SEO del blog Shopify](/shopify-blog-seo) spiega cosa si può e non si può fare con la struttura del blog di Shopify. **Dati strutturati.** I temi Shopify includono dati strutturati di prodotto di default (nome, prezzo, disponibilità, valutazioni se c'è un'app di recensioni), e in molti casi sono migliori di quelli generati da WordPress. Ma se su WooCommerce aveva FAQ, breadcrumb o organizzazione contrassegnati con un plugin, verifichi che il tema nuovo o un'app li riproducano. Usi lo strumento di test dei risultati multimediali di Google su una pagina prodotto e una collezione prima del lancio. ## Il giorno del cambio DNS ## Prima di cambiare il DNS - Il negozio Shopify è completo e verificato dietro password, con prodotti, collezioni, pagine e blog importati e controllati a campione - I titoli SEO e le meta description importati coincidono con quelli di WooCommerce su un campione di venti pagine con traffico - Il CSV dei redirect è importato su Shopify e testato con dieci URL per ogni tipo (prodotto, categoria, pagina, blog) - Il dominio principale è configurato su Shopify e il certificato SSL emesso, anche se il DNS punta ancora a WordPress - Il negozio vecchio smette di accettare ordini qualche ora prima, così nessun ordine si perde nel cambio - I clienti sono importati; le password non si possono spostare e c'è un'email di reimpostazione pronta - Search Console è verificata per il dominio (verifica via DNS, che sopravvive al cambio di piattaforma) - La sitemap di Shopify (/sitemap.xml) è pronta per essere inviata appena cambia il DNS - Analitica, pixel e consenso sono installati e testati sul negozio di prova - C'è una persona assegnata a controllare Search Console e gli errori 404 ogni giorno per le prime due settimane Il cambio DNS vero e proprio si fa in una finestra di basso traffico, di notte durante la settimana o una domenica mattina secondo il suo mercato. Da quel momento, i redirect devono rispondere dal primo secondo: se un crawler di Google arriva su un URL vecchio e trova un 404 perché il CSV non era ancora stato importato, quell'URL entra nella coda degli errori e impiega più tempo a riprendersi. Se cambia anche dominio (non solo piattaforma), usi lo strumento di cambio di indirizzo di Search Console dopo che i redirect sono attivi. Se il dominio resta lo stesso, non serve; invii la nuova sitemap e attenda. Non elimini WordPress lo stesso giorno. Lo tenga accessibile su un sottodominio o in locale per almeno tre mesi, perché emergeranno contenuti che nessuno ricordava, immagini mancanti e campi non esportati. È più economico recuperarli da una copia viva che da un backup. ## Cosa controllare in Search Console nelle settimane successive Le quattro settimane dopo il cambio dicono se la migrazione ha funzionato, e Search Console è dove si vede. **Errori 404 nel rapporto pagine.** È il primo posto da controllare ogni giorno. Qualsiasi URL vecchio con traffico che compare come "Non trovato" è un redirect mancante o scritto male, e si corregge aggiungendo la riga alla mappa e reimportandola. Gli URL senza traffico né link possono restare in 404. **Copertura e indicizzazione.** Il numero di pagine indicizzate scenderà all'inizio (gli URL vecchi escono) e salirà dopo (i nuovi entrano). Quello che conta è che i nuovi entrino: se dopo tre settimane le pagine prodotto di Shopify non sono ancora indicizzate, controlli che la sitemap sia inviata, che il tema non metta tag noindex di default su qualche tipo di pagina e che la password del negozio sia stata tolta. **Rendimento per pagina.** Confronti i clic dei venti URL principali di WooCommerce con quelli delle loro destinazioni su Shopify. Un calo tra il 10 e il 30% durante le prime settimane è normale; un URL specifico che scende a zero indica un problema in quel redirect o in quella pagina. **Core Web Vitals.** Shopify è di solito più veloce di un WordPress carico di plugin, ma un tema mal configurato o dieci app installate il giorno del lancio possono ribaltare la situazione. Riveda il rapporto dopo quattro settimane, quando ci sono dati di campo, e legga l'articolo sulla [velocità dei temi Shopify](/shopify-theme-speed) se qualcosa risulta in rosso. Se dopo otto settimane il traffico organico resta il 30% sotto il punto di partenza e i 404 sono puliti, il problema non è la migrazione: è contenuto più povero nelle pagine nuove, titoli cambiati o un tema che mostra meno testo di quello vecchio. Torni all'inventario e confronti una pagina vecchia con la sua equivalente nuova, elemento per elemento. ## Quando farlo da soli e quando affidarsi a un'agenzia La migrazione di un negozio piccolo senza molto traffico organico si può fare da soli. Shopify ha un'app ufficiale di importazione da WooCommerce che sposta prodotti, clienti e ordini, e il CSV dei redirect si genera con un foglio di calcolo e un po' di pazienza. Se il suo negozio ha meno di duecento prodotti, il blog è piccolo e Search Console non mostra un traffico che le toglie il sonno, proceda pure. Vale la pena pagare quando c'è traffico organico da proteggere, un catalogo grande con campi personalizzati, un gestionale che deve restare sincronizzato (compresa la fatturazione elettronica, trattata in [Shopify e fatturazione elettronica in Italia](/it/shopify-fatturazione-elettronica-italia-come-metterla-norma)), o più lingue. In questi casi il costo di un redirect fatto male o di un campo perso si misura in mesi di vendite, e supera di molto il costo del lavoro. Una migrazione di catalogo e clienti con mappa di redirect parte da 1.500 $ sulla pagina servizi di [migrazione Shopify di ByteInfy](https://byteinfy.com/services/shopify-migration), al momento della stesura, e il negozio in sé (tema, sezioni, design) è una voce distinta che si preventiva a parte, come spiegato in [quanto costa un negozio Shopify nel 2027](/it/agenzia-shopify-quanto-costa-negozio-nel-2027-prezzi). Se affida il lavoro a un'agenzia, chieda di vedere la mappa dei redirect prima del cambio DNS e di ricevere l'inventario con cui ha lavorato. Un'agenzia che non può mostrarle quel documento non ha fatto il lavoro che protegge la SEO, per quanto bello sia il negozio. L'articolo su [come scegliere un'agenzia Shopify](/it/come-scegliere-agenzia-shopify-12-domande-da-fare) ha altre domande di questo tipo, e la [checklist SEO per Shopify](/it/checklist-seo-shopify-2027-25-punti-che-contano) raccoglie cosa controllare nel negozio nuovo una volta assestata la polvere della migrazione. **Deve migrare da WooCommerce e ha traffico da proteggere** Ci dica quanti prodotti ha, quali campi personalizzati usa e cosa dice Search Console, e riceverà un piano di migrazione con la mappa dei redirect come prima consegna. [Parla con ByteInfy](https://byteinfy.com/contact) ## FAQ ### Si perde la SEO migrando da WooCommerce a Shopify? Non necessariamente. A far perdere posizioni sono gli URL cambiati senza redirect, i contenuti lasciati fuori dall'importazione o il lancio del nuovo negozio con titoli e descrizioni diversi. ### Posso mantenere gli stessi URL di WooCommerce su Shopify? Non del tutto. Shopify impone che i prodotti vivano in /products/, le collezioni in /collections/ e le pagine in /pages/, e non permette di cambiare questi prefissi. ### Come si fanno i redirect 301 su Shopify? Dal pannello di Shopify, in Negozio online, Navigazione, Redirect URL, può crearli uno per uno o importare un file CSV con due colonne, il percorso vecchio e quello nuovo. ### Cosa succede alle immagini di WooCommerce durante la migrazione? Le immagini vengono ricaricate sul CDN di Shopify, quindi i loro URL cambiano. Google indicizza le immagini separatamente, e quel traffico si recupera più lentamente di quello delle pagine. ### Quanto tempo impiega Google a riflettere la migrazione? Con i redirect attivi dal primo minuto, Google di norma ricalcola la maggior parte degli URL importanti in due-sei settimane, anche se cataloghi grandi possono richiedere più tempo. ### Conviene migrare in bassa stagione? Sì, quando possibile. Una migrazione fa perdere un po' di traffico per qualche settimana anche quando va bene, e conviene che quelle settimane non coincidano con il suo mese migliore. ### Quanto costa migrare da WooCommerce a Shopify con un'agenzia? Una migrazione di catalogo e clienti con mappa di redirect parte da 1.500 $ sulla pagina servizi di ByteInfy, al momento della stesura. --- --- title: "Shopify e fatturazione elettronica in Italia: come metterla a norma" description: "Shopify gestisce ordini e pagamenti, non la fattura fiscale. Mettere un negozio a norma con lo SDI significa collegare un'app o un gestionale, aggiungere i campi giusti in checkout e decidere cosa succede per B2B, B2C e resi." author: "Aashish Kaushik" published: 2026-10-09T05:01:07.575Z updated: 2026-10-09T05:01:07.618Z url: https://blog.byteinfy.com/shopify-fatturazione-elettronica-italia-come-metterla-norma --- # Shopify e fatturazione elettronica in Italia: come metterla a norma ## Key takeaways - Shopify non trasmette fatture allo SDI in modo nativo; la conformità passa sempre da un'app di fatturazione elettronica o da un gestionale collegato via integrazione. - Per le vendite B2B e verso la Pubblica Amministrazione la fattura elettronica è obbligatoria; per il B2C dipende dal regime e da cosa richiede il cliente, e va verificato con il commercialista. - Il checkout deve raccogliere partita IVA, codice fiscale e codice destinatario o PEC quando il cliente li richiede, altrimenti l'integrazione non ha i dati per emettere la fattura. - Le note di credito per i resi seguono lo stesso canale elettronico della fattura originale, e vanno pianificate insieme all'app scelta, non aggiunte dopo. Shopify non trasmette le fatture al Sistema di Interscambio in modo nativo, e questo è il punto da cui partire prima di qualsiasi altra decisione. Mettere a norma un negozio Shopify in Italia significa collegare un'app di fatturazione elettronica o un gestionale che parli con lo SDI, non aspettarsi che l'admin lo faccia da solo. Shopify emette una ricevuta d'ordine e, con le impostazioni giuste, un documento di vendita interno, ma quel documento non è una fattura fiscale valida e non arriva da nessuna parte fuori dal suo negozio. Per chi vende principalmente a privati la questione è meno urgente ma non sparisce: l'obbligo di fattura elettronica dipende dal regime fiscale e da cosa chiede il cliente. Per chi vende anche a partite IVA, a imprese o alla Pubblica Amministrazione, l'integrazione con lo SDI è necessaria fin dal primo ordine di quel tipo. Questo articolo segue l'ordine in cui un merchant italiano affronta il problema: come funziona lo SDI in breve, cosa Shopify non fa, le due strade per collegarlo, i dati che servono in checkout, i casi particolari, le note di credito e infine cosa verificare prima di andare live. > **Non è consulenza fiscale** > > Questo articolo spiega cosa serve tecnicamente per collegare Shopify allo SDI. Le soglie, i regimi e gli obblighi specifici del suo caso li verifichi con il suo commercialista prima di scegliere un'app o firmare un contratto di integrazione. Le regole sui regimi forfettari, in particolare, sono cambiate più volte negli ultimi anni. ## Come funziona la fatturazione elettronica in Italia, in breve La fattura elettronica in Italia passa dal Sistema di Interscambio, lo SDI, un servizio dell'Agenzia delle Entrate che riceve un file XML in formato FatturaPA, lo valida e lo consegna al destinatario. Non è un'email con un PDF allegato: è un documento strutturato con campi obbligatori, tra cui i dati del cedente e del cessionario, il codice destinatario o la PEC per la consegna, il regime fiscale applicato e il dettaglio dell'IVA per riga. Per le operazioni tra imprese (B2B) e verso la Pubblica Amministrazione, la fattura elettronica tramite SDI è obbligatoria da anni. Per le vendite al consumatore finale (B2C), la regola più comune è che il negozio emetta un corrispettivo elettronico tramite registratore telematico o servizio equivalente, e la fattura solo se il cliente la richiede esplicitamente al momento dell'acquisto o entro i termini di legge. Un e-commerce che vende quasi solo a privati può quindi avere un flusso di fatturazione elettronica più leggero di un negozio B2B, ma raramente può farne a meno del tutto, perché prima o poi arriva un cliente con partita IVA o una richiesta di fattura. Il codice destinatario è la chiave che indirizza il file al sistema del cliente: sette caratteri per le imprese che ricevono le fatture tramite un proprio software, "0000000" per chi le riceve solo via PEC, e un codice specifico per la Pubblica Amministrazione. Senza questo dato, o senza una PEC valida, l'app di fatturazione non può consegnare il documento, anche se lo ha generato correttamente. ## Cosa Shopify non fa da solo Vale la pena essere precisi su questo punto, perché è la causa più comune di sorprese dopo il lancio. Shopify genera una conferma d'ordine e un'email al cliente, entrambe utili ma non equivalenti a una fattura. Con le impostazioni di tassazione configurate, mostra l'IVA applicata riga per riga, il che aiuta chi genera la fattura a valle ma non sostituisce il documento stesso. Non assegna una numerazione fiscale progressiva conforme alla normativa italiana, non genera il file XML nel formato FatturaPA e non ha alcun collegamento diretto con lo SDI. Nessuna app "gratuita" installata dall'admin cambia questo fatto: la trasmissione allo SDI richiede sempre un sistema esterno, a canone o incluso in un gestionale che già usa. Questo non è un limite di Shopify rispetto ad altre piattaforme: nessuna piattaforma di e-commerce generalista trasmette fatture allo SDI in modo nativo, perché è un obbligo specifico del mercato italiano che ha senso implementare come livello separato, spesso condiviso con la contabilità generale dell'azienda e non solo con il negozio online. ## Le due strade per collegare lo SDI Ci sono sostanzialmente due modi per risolvere il problema, e la scelta dipende da cosa usa già per la contabilità. **Un'app di fatturazione elettronica dedicata.** Installata dall'App Store di Shopify, legge gli ordini tramite webhook quando vengono creati o pagati, genera la fattura o il corrispettivo nel formato corretto e la trasmette allo SDI. Il costo è un canone mensile, di solito proporzionale al numero di documenti emessi. È la strada più veloce per un negozio che non ha già un gestionale di contabilità, o che ne ha uno separato e preferisce tenere la fatturazione dell'e-commerce a parte. **Un gestionale o software di contabilità esistente, collegato via integrazione.** Se il suo commercialista o il suo team amministrativo lavora già con un gestionale che gestisce anche l'invio allo SDI, la scelta più sensata è collegare Shopify a quel sistema invece di aggiungerne un altro. L'integrazione legge gli ordini da Shopify, li trasforma nel formato che il gestionale si aspetta e lascia che sia il gestionale, non una nuova app, a occuparsi della trasmissione. Questo evita di avere due fonti di verità sulla fatturazione, un problema che con il tempo genera differenze tra quello che dice Shopify e quello che dice la contabilità. La seconda strada richiede più lavoro di integrazione ma paga nel tempo, soprattutto per negozi con volumi importanti o con vendite su più canali oltre a Shopify. ByteInfy costruisce questo tipo di connettori come parte del suo servizio di [integrazioni Shopify](https://byteinfy.com/services/shopify-integrations), partendo da 1.500 $ per un'integrazione singola secondo i listini pubblicati, con retry e log così che un errore di trasmissione non passi inosservato per settimane. ## Le due strade a confronto | Caratteristica | App di fatturazione dedicata | Gestionale esistente collegato | | --- | --- | --- | | Costo | Canone mensile, spesso a scalare sui documenti | Progetto di integrazione una tantum, più il canone del gestionale | | Tempo di attivazione | Giorni, spesso configurabile da soli | Settimane, richiede scoping e test | | Punto di verità unico | No, se il commercialista usa un altro sistema | Sì, tutto passa dal gestionale esistente | | Adatto a | Negozi solo Shopify, senza gestionale strutturato | Aziende con contabilità già impostata o vendite multicanale | ## Cosa deve gestire l'integrazione, in pratica Qualunque strada scelga, il flusso tecnico deve rispondere a tre domande per ogni ordine: chi è il cliente fiscalmente, cosa gli si può vendere e come consegnargli il documento. **Raccolta dei dati fiscali in checkout.** Il checkout standard di Shopify raccoglie nome, indirizzo e contatti, ma non ha un campo nativo per partita IVA, codice fiscale o codice destinatario pensato per un negozio B2C italiano. Questi campi vanno aggiunti con una checkout UI extension o con l'app di fatturazione stessa, che spesso include il proprio modulo. Il tema descritto in [Checkout Extensibility](/shopify-checkout-extensibility) è la base tecnica: da quando checkout.liquid è stato sostituito, ogni campo aggiuntivo in checkout passa da un'estensione supportata, non da un hack sul tema. **Decisione su chi riceve la fattura e chi il corrispettivo.** L'integrazione deve sapere, ordine per ordine, se emettere un corrispettivo (cliente privato senza richiesta di fattura) o una fattura elettronica (cliente che ha indicato partita IVA o l'ha richiesta esplicitamente). Questa logica va scritta con il commercialista, non improvvisata dallo sviluppatore, perché sbagliarla ha conseguenze fiscali. **Trasmissione e conferma.** Una volta generato il documento, l'app o il gestionale lo invia allo SDI e riceve una ricevuta di consegna o di scarto. Un sistema ben costruito riporta questo stato dentro Shopify, per esempio come tag sull'ordine, così che chi gestisce il servizio clienti veda subito se una fattura è stata scartata e serva un'azione. ## Casi particolari: forfettari, B2B e vendite estero **Regime forfettario.** Le regole sull'obbligo di fattura elettronica per chi è in regime forfettario sono cambiate più volte e dipendono da soglie di ricavi che vanno verificate con il commercialista al momento in cui legge questo articolo, non date per scontate da una fonte online. Quello che non cambia è che, obbligo o meno, un'app o un gestionale di fatturazione resta comunque lo strumento con cui emettere e archiviare i documenti in modo ordinato. **Vendite B2B con codice destinatario o PEC.** Per un cliente business, il checkout deve raccogliere il codice destinatario a sette cifre o, in alternativa, un indirizzo PEC valido. Senza uno dei due, l'app di fatturazione non può consegnare il documento anche se lo genera correttamente, e l'ordine resta bloccato in uno stato di errore che va gestito manualmente. Vale la pena rendere questo campo obbligatorio per i clienti che si dichiarano aziende, piuttosto che scoprirlo dopo l'emissione. **Vendite verso l'estero.** Per i clienti fuori dall'Italia, l'obbligo di trasmissione tramite SDI non si applica nello stesso modo, ma restano le regole IVA ordinarie: reverse charge per le vendite B2B verso altri paesi UE con partita IVA valida, e il regime OSS per le vendite B2C ai consumatori di altri paesi dell'Unione una volta superata la soglia annua. La maggior parte delle app di fatturazione italiane gestisce anche i documenti verso l'estero, ma vale la pena verificarlo esplicitamente prima di sceglierne una, soprattutto se il suo negozio vende già fuori Italia con Shopify Markets, come trattato in [migrare senza perdere la SEO](/it/migrare-da-woocommerce-shopify-senza-perdere-seo) per il caso di negozi multi-mercato. **Marketplace e vendite multicanale.** Se vende anche su un marketplace oltre al negozio Shopify, la fatturazione va unificata a livello di gestionale o di commercialista, non duplicata per canale. È uno dei motivi per cui, superata una certa dimensione, collegare un gestionale esistente batte l'aggiunta di un'app per ogni canale di vendita. ## Note di credito e resi Un reso che genera un rimborso in Shopify non genera automaticamente una nota di credito elettronica, e questo è un punto che molti flussi di fatturazione trascurano finché non arriva la prima contestazione. Quando la fattura originale era elettronica, la nota di credito deve seguirla nello stesso canale: un documento XML che fa riferimento alla fattura di origine, trasmesso allo SDI come la fattura stessa. Il flusso corretto collega il rimborso Shopify alla generazione della nota di credito nel sistema di fatturazione, così che i due eventi restino sincronizzati. Un rimborso gestito solo dentro Shopify, senza che il gestionale ne sia informato, lascia una fattura attiva per un ordine che in realtà è stato restituito, e la discrepanza emerge tipicamente in sede di dichiarazione, quando è più costoso correggerla. Vale la pena chiedere esplicitamente, a chi le vende un'app o costruisce l'integrazione, come viene gestito questo caso, e testarlo con un ordine di prova prima del lancio. ## Checklist prima di andare live Una lista di controlli concreti, da eseguire con ordini di prova reali prima di aprire il negozio ai clienti. ## Prima di attivare la fatturazione elettronica - Campo per partita IVA, codice fiscale e codice destinatario o PEC presente in checkout per i clienti che lo richiedono - Logica chiara su quando emettere corrispettivo e quando fattura, concordata con il commercialista - Un ordine di prova B2C senza richiesta di fattura, verificato dal corrispettivo generato - Un ordine di prova B2C con richiesta di fattura, verificato dal documento e dalla ricevuta SDI - Un ordine di prova B2B con codice destinatario, verificato dalla consegna al sistema del cliente - Un reso di prova, verificato dalla nota di credito generata e collegata alla fattura originale - Stato di trasmissione (consegnata, scartata, in attesa) visibile su Shopify o nel gestionale, non solo nel pannello dell'app - Procedura scritta per chi gestisce una fattura scartata dallo SDI L'ultimo punto è quello che i negozi più piccoli saltano più spesso. Una fattura scartata dallo SDI non è un evento raro, e se nessuno sa chi deve correggerla, resta scartata finché qualcuno non se ne accorge durante la chiusura del mese. ## Quanto costa mettere a norma un negozio Il costo si divide in due parti che vale la pena distinguere fin dal preventivo: il canone ricorrente dell'app o del gestionale, e il lavoro una tantum per collegarlo a Shopify. Un'app di fatturazione dell'App Store ha un canone mensile che varia con il volume di documenti, e la configurazione base è spesso alla portata del merchant stesso, seguendo la documentazione dell'app. Un'integrazione su misura verso un gestionale esistente, con i campi di checkout, la logica corrispettivo o fattura e la gestione delle note di credito, parte da 1.500 $ secondo i listini pubblicati di [ByteInfy per le integrazioni Shopify](https://byteinfy.com/services/shopify-integrations), e sale con il numero di flussi da coprire. Questo costo si somma, non sostituisce, a quanto trattato nell'articolo su [quanto costa un negozio Shopify nel 2027](/it/agenzia-shopify-quanto-costa-negozio-nel-2027-prezzi), dove la fatturazione elettronica compare come una delle integrazioni più richieste dai merchant italiani. ## Quando conviene un'agenzia e cosa chiederle Configurare un'app di fatturazione semplice, per un negozio B2C con pochi ordini business, è spesso alla portata del merchant seguendo la documentazione dell'app scelta. Conviene un'agenzia quando ha già un gestionale con cui integrarsi, quando vende anche B2B con volumi da automatizzare, o quando il checkout deve raccogliere dati fiscali che il tema attuale non gestisce. Qualunque strada scelga, chieda a chi configura l'integrazione di mostrarle un ordine di prova completo per ogni caso, non solo la schermata di configurazione dell'app. Le domande da fare a qualsiasi fornitore o agenzia, comprese quelle su come gestiscono i dati sensibili e la manutenzione nel tempo, sono nell'articolo su [come scegliere un'agenzia Shopify](/it/come-scegliere-agenzia-shopify-12-domande-da-fare). **Deve collegare Shopify alla fatturazione elettronica?** ByteInfy costruisce integrazioni tra Shopify e gestionali o app di fatturazione, con i campi di checkout e la logica corrispettivo-fattura concordati per iscritto prima del preventivo. [Parla con ByteInfy](https://byteinfy.com/contact) ## FAQ ### Shopify manda le fatture allo SDI da solo? No. Shopify genera una ricevuta d'ordine e, con le impostazioni giuste, un documento di vendita, ma non trasmette nulla al Sistema di Interscambio. ### Devo emettere fattura elettronica anche se vendo solo a privati? Dipende dal regime e da cosa richiede il cliente. ### Quali dati devo raccogliere in checkout per fatturare correttamente? Partita IVA o codice fiscale per chi vuole fattura, codice destinatario a sette cifre o PEC per i clienti B2B, e la ragione sociale se diversa dal nome dell'intestatario dell'ordine. ### Le note di credito per i resi passano anche loro dallo SDI? Sì, quando la fattura originale era elettronica. Il gestionale o l'app collegata deve generare la nota di credito con riferimento alla fattura di origine e trasmetterla come la fattura stessa. ### Posso usare lo stesso sistema per i clienti italiani e per quelli esteri? Per le vendite fuori Italia il vincolo dello SDI non si applica allo stesso modo, ma restano le regole IVA (reverse charge, OSS per il B2C nell'Unione Europea) e la necessità di un documento valido nel paese di destinazione. ### Quanto costa collegare Shopify a un sistema di fatturazione elettronica? Se sceglie un'app dedicata dall'App Store, il costo principale è il canone mensile dell'app, e la configurazione la fa spesso chi vende l'app. ### Chi controlla che tutto funzioni prima del lancio? Nessuno lo fa al posto suo. --- --- title: "Bundles or Volume Discounts: Which Raises AOV on Shopify" description: "Volume discounts sell more of one thing. Bundles sell a different combination of things. Which works depends on whether your customer wants two, or wants a set." author: "Aashish Kaushik" published: 2026-10-08T13:01:15.253Z updated: 2026-10-08T13:01:15.293Z url: https://blog.byteinfy.com/shopify-bundles-vs-volume-discounts --- # Bundles or Volume Discounts: Which Raises AOV on Shopify ## Key takeaways - Volume discounts increase quantity of one product; bundles change what combination the customer buys. These suit different catalogues. - Volume works where a second unit has genuine value — consumables, refills, gifts, anything routinely bought in multiples. - Bundles work where products complete each other, and they let you attach slower stock to something that already sells. - Both cannibalise if applied to what customers were buying anyway, so measure against a control rather than counting mechanic revenue. Both mechanics claim the same benefit and are frequently discussed interchangeably, which is why merchants often pick the one their app supports rather than the one their catalogue needs. They work differently. A volume discount asks a customer to buy more of what they already chose. A bundle asks them to buy something they had not considered, attached to something they had. Those are different requests, and they succeed with different products. > **A prior question** > > Before either, check whether the mechanic is doing anything at all. If customers were already buying two, a volume discount on two units is a price cut. That is the failure mode both mechanics share. ## What each one actually does **A volume discount increases depth.** Buy three, save fifteen percent. The customer buys more units of one product. The discount applies to all of them, including the units they would have bought at full price. **A bundle increases breadth.** Buy this with that, save. The customer buys a different combination. The discount is blended across products you chose to pair, which means you decide where the margin comes from. That second distinction is the most commercially important one in this comparison. With a volume discount, the discount lands wherever the customer's demand already was. With a bundle, you choose. ## Where volume discounts work Volume discounts succeed when a second unit has genuine value to the same buyer. That sounds obvious and it excludes more of most catalogues than merchants expect. They work well for: **Consumables and refills.** Anything used up and rebought. A customer buying skincare, coffee, filters or supplements has real use for three. **Low-consideration repeat items.** Socks, basics, stationery. Buying several is normal behaviour. **Gifting categories**, where multiples are bought for different people. **Anything with a stocking-up instinct**, particularly where the customer worries about running out. They work poorly for: **Considered single purchases.** Nobody wants three jackets, and offering a discount on three reads as confusing rather than generous. **Durable goods**, where a single unit lasts for years. **Highly variant-dependent products**, where the customer wants three different sizes rather than three identical units — which is a bundle problem, not a volume one. ## Where bundles work Bundles succeed when products complete each other, and their strategic advantage is that you decide the composition. They work well for: **Complementary sets.** The product plus what it needs — the camera plus the card, the shoes plus the care kit. **Attaching slow stock to fast stock.** The single most useful commercial property of bundling. The anchor supplies the demand; the attachment supplies the incremental revenue. **Reducing a decision.** A starter set answers "what else do I need", which is genuine work done for the customer. **Gift-ready combinations**, particularly seasonally. They work poorly for: **Products with no natural companion.** Forcing a pairing produces a discount on two unrelated items. **Catalogues where everything is a considered purchase**, since bundling two considered items doubles the hesitation rather than halving it. ## Choosing between them | Your situation | Likely fit | | --- | --- | | Consumables, refills, repeat purchases | Volume | | Products that complete each other | Bundle | | Slow stock you want to move | Bundle, attached to a seller | | Customers already buy multiples | Neither — you would be discounting existing behaviour | | Wide margin variance across catalogue | Bundle, so you control where the discount lands | | Customers want different variants | Bundle, dynamic rather than fixed | | Single durable products | Probably neither | ## The margin difference The arithmetic matters and is frequently skipped. **A volume discount reduces margin on every unit sold under it.** If a customer would have bought two and now buys three at fifteen percent off, you gave up fifteen percent on all three to gain one. Whether that is profitable depends on the margin and on how many customers moved. **A bundle blends margin across chosen products.** If the anchor carries strong margin and the attachment carries weak margin, the blended discount can be structured so the total remains healthy. You are choosing which product absorbs the discount. This is why bundles are generally the safer mechanic for catalogues with wide margin variance, and why volume discounts are cleaner for catalogues where margin is fairly uniform. Model both against contribution margin rather than gross — shipping, payment fees and returns all move with order value, and a larger discounted order is not automatically a better one. ## Cannibalisation is the shared failure Both mechanics produce impressive-looking reports, because revenue attributed to them is always positive. People bought bundles; there is bundle revenue. The question neither report answers is whether total revenue rose. A bundle of two things a customer was going to buy separately is a discount on behaviour you already had. A volume discount at a quantity customers already reached is the same. ## Measuring either mechanic honestly - Establish a baseline before launching — average order value, units per order, revenue per visitor - Run a control: matched products or a matched period without the mechanic - Measure revenue per visitor, not revenue attributed to the mechanic - Check whether units per order rose, or only the discount did - Give it weeks, since promotional effects distort early - Include return rates, which often rise on discounted multi-item orders ## Implementation differences worth knowing Two practical points that affect the choice. **Volume discounts are simpler.** Shopify's native discounts handle quantity-based pricing reasonably, and the logic is easy to express and test. Fewer moving parts, fewer failure modes. **Bundles are more demanding**, particularly around inventory. A component sold both inside a bundle and separately depletes from two directions, and fixed bundles carry their own stock count that must stay synchronised with components. This is where bundle implementations actually break, and it is worth asking about before choosing an app. For anything requiring custom logic, Shopify Functions is the supported route since legacy Scripts stopped running on 30 June 2026. Avoid implementations that achieve pricing by manipulating the cart, which can be bypassed entirely at accelerated checkouts. There is a reporting difference too. A volume discount is one product sold in greater quantity, which every analytics tool already understands. A bundle is several line items with a discount, and separating "these sold as a bundle" from "these happened to share an order" requires the app to track it deliberately. If you intend to make decisions from bundle data, confirm that data exists and survives an uninstall before you build a year of reporting on it. ## How to present each one The mechanic is half the work. How it appears on the page decides whether anyone takes it, and the two need presenting differently. **Volume discounts need the ladder visible at the point of quantity selection.** A shopper choosing quantity should see what the next rung is worth without changing anything — "buy 2, save 10%; buy 3, save 15%" laid out beside the selector. Volume discounts that only reveal themselves in the cart perform far worse, because the decision they are meant to influence has already been made. **Bundles need to show the saving against the parts.** A shopper cannot evaluate a bundle price without knowing what the components cost separately. Show both, and show the difference as a number rather than a percentage — money saved is more legible than a proportion, particularly on lower-value baskets. Two presentation errors are common enough to name. The first is stating a saving that requires arithmetic to verify: shoppers do not do the arithmetic, they either trust it or leave. The second is offering too many rungs or too many bundle permutations — past three or four options, choice paralysis costs more than the extra flexibility gains. > **Say what the customer gets, not what you are doing** > > "Save ₹400 when you buy the set" outperforms "Bundle discount applied" every time. The first describes a benefit to the shopper; the second describes a mechanic to yourself. This sounds trivial and is one of the more reliable copy improvements available on either offer type. ## A reasonable way to decide 1. Look at your current baskets. What do customers already buy together, and how many units do they already take? This is your answer more often than any framework. 2. If multiples are already common, a volume discount is probably a price cut. Look at bundles instead. 3. If products naturally pair, bundle — and use it to attach something you want to move. 4. Model both against contribution margin, not gross. 5. Launch three, not thirty. Both mechanics sprawl, and a catalogue with forty bundles is one nobody can merchandise or keep in stock. 6. Measure against a control, over weeks. Step one is the one that saves the most wasted effort. Your existing order data usually indicates which mechanic your customers are already halfway toward, and building toward existing behaviour beats trying to create new behaviour. For app selection in this category, see [Shopify apps](/category/shopify-apps). Offer structure and margin modelling are covered in [promotions and offers](/category/promotions-offers), and the inventory implications in [POS and operations](/category/pos-operations). **Offer logic that fits your catalogue** ByteInfy builds Shopify bundle and volume pricing with Functions — component-aware inventory, blended margin and merchandising that holds through checkout. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What is the difference between a bundle and a volume discount? A volume discount reduces the price when a customer buys more units of the same product — buy three, save fifteen percent. A bundle offers several different products together at a combined price. ### Which raises average order value more? Neither reliably; it depends on your products. Volume discounts win where a second unit has real value to the same buyer, such as consumables and refills. ### Do volume discounts hurt margin more than bundles? Volume discounts reduce margin on every unit including the ones that would have sold anyway, which is their main risk. ### Can I run both at the same time? Technically often yes, but they interact in ways that need testing, and Shopify's rules about combining same-type discounts apply. ### How do I know if either is actually working? Compare against a control — a matched period, or comparable products without the mechanic running. Revenue from bundles is always positive because people bought bundles. --- --- title: "Sconti personalizzati con Shopify Functions (fine degli Scripts)" description: "Gli Scripts non esistono più e ogni logica di sconto che Shopify non offre nativamente oggi passa dalle Functions. Cosa sono, cosa possono fare, cosa no, e quanto costa farle costruire." author: "Aashish Kaushik" published: 2026-10-08T05:01:08.001Z updated: 2026-10-08T05:01:08.004Z url: https://blog.byteinfy.com/sconti-personalizzati-con-shopify-functions-fine-degli --- # Sconti personalizzati con Shopify Functions (fine degli Scripts) ## Key takeaways - Shopify ha dismesso gli Scripts e i merchant Plus dovevano migrare entro il 2025; oggi la logica di sconto personalizzata si scrive come Shopify Function, su tutti i piani. - Una Function gira dentro il checkout di Shopify, non attorno; per questo funziona anche con i checkout accelerati che aggiravano le manipolazioni del carrello. - Le Functions non possono chiamare servizi esterni durante l'esecuzione; tutto ciò che serve va messo prima in metafield o attributi del carrello. - Prima di far costruire una Function, verifichi che lo sconto non sia già ottenibile con gli sconti nativi o con un'app esistente; una singola Function costa da 1.500 $. Se il suo negozio ha bisogno di uno sconto che Shopify non offre tra quelli nativi, oggi la risposta è una Shopify Function. Gli Scripts, il vecchio meccanismo riservato a Shopify Plus, sono stati dismessi, e i merchant Plus dovevano completare la migrazione entro il 2025. Le Functions li sostituiscono con una differenza importante: funzionano su tutti i piani, non solo su Plus. Per un merchant italiano questo apre casi che prima richiedevano app costose o rinunce. Prezzi diversi per i clienti con Partita IVA, sconti a scaglioni per quantità, spedizione gratuita sopra una soglia che cambia per mercato, bundle che si compongono da soli nel carrello. Tutto questo si scrive una volta, gira dentro il checkout e non si rompe quando il cliente paga con Shop Pay o PayPal. Questo articolo spiega cosa sono le Functions in termini pratici, quali sconti si possono costruire, cosa non possono fare, e come decidere se ne ha davvero bisogno prima di pagare qualcuno per scriverne una. ## Cosa cambia con la fine degli Scripts La differenza tra Scripts e Functions non è solo tecnica: cambia chi può usare la logica personalizzata e dove quella logica viene eseguita. Gli Scripts erano codice Ruby che un merchant Plus scriveva nell'app Script Editor. Giravano sul carrello e sul checkout, ma con un limite noto: i checkout accelerati (Shop Pay, Apple Pay, il pulsante PayPal dal carrello) non passavano sempre dalla stessa strada, e le manipolazioni del carrello potevano essere aggirate. Inoltre erano un ambiente chiuso, con un solo linguaggio e nessun modo di distribuire la stessa logica su più negozi. Le Functions rovesciano l'impostazione. Sono compilate in WebAssembly, girano dentro l'infrastruttura del checkout, hanno tempi di esecuzione misurati in millisecondi e vengono valutate in ogni percorso di acquisto, accelerato o meno. Si scrivono in JavaScript, TypeScript o Rust e si distribuiscono tramite un'app, il che significa che la stessa regola può essere installata su più negozi o venduta sull'App Store. Il passaggio è raccontato in dettaglio in [Shopify Scripts to Functions](/shopify-scripts-to-functions). Se ha ancora Scripts attivi, quella pagina è il punto di partenza; se non li ha mai avuti, può saltarla e leggere qui cosa costruire. ## Cosa sono le Functions, in pratica Una Function è un programma che riceve una fotografia del carrello, applica una regola e restituisce un'istruzione a Shopify. Non ha accesso a Internet, non salva nulla, non conosce il mondo fuori dal checkout. L'input arriva tramite una query GraphQL che la Function dichiara in anticipo: righe del carrello, quantità, prezzi, tag del cliente, attributi, metafield di prodotti e varianti, mercato e valuta. L'output è una lista di operazioni: "applica il 10% a queste righe", "nascondi questo metodo di spedizione", "unisci questi tre prodotti in un bundle". Shopify esegue le operazioni e mostra il risultato nel checkout. La configurazione della regola (percentuali, soglie, tag) vive in un metafield collegato allo sconto o alla personalizzazione. Questo è il punto che rende una Function utilizzabile da un merchant: l'app che la contiene può offrire una pagina di amministrazione dove il suo team cambia la soglia da 100 a 150 euro senza toccare codice. > **Chi scrive la Function** > > Le Functions richiedono uno sviluppatore, un'app di distribuzione e la Shopify CLI. Un merchant senza sviluppatore ha due strade: un'app pubblica che espone la regola di cui ha bisogno, oppure un'app custom costruita per il suo negozio. La prima costa un canone mensile, la seconda un progetto una tantum da 1.500 $ in su secondo i listini pubblicati. ## I tipi di sconto che può costruire Shopify raggruppa le Functions per obiettivo, e per gli sconti le famiglie che contano sono quattro. ## Famiglie di Functions per gli sconti | Famiglia | Cosa fa | Esempi | | --- | --- | --- | | Discount | Applica sconti su prodotti, ordine o spedizione in base a regole sul carrello e sul cliente | Sconti a scaglioni, prezzi rivenditore, regalo con acquisto, spedizione gratis sopra soglia | | Cart Transform | Unisce o espande righe del carrello | Bundle composti nel carrello, kit venduti come un prodotto solo | | Payment Customization | Nasconde, rinomina o riordina i metodi di pagamento | Mostrare il bonifico solo ai clienti B2B, nascondere il contrassegno sopra un importo | | Delivery Customization | Nasconde, rinomina o riordina i metodi di spedizione | Ritiro in sede solo per un CAP, corriere espresso solo sotto un peso | La famiglia Discount è quella che sostituisce direttamente gli Scripts di sconto. Shopify l'ha unificata: una sola Function può applicare sconti di classe prodotto, ordine e spedizione insieme, e dichiarare con quali altre classi si combina. Le regole di combinazione sono spiegate in [Shopify discount stacking](/shopify-discount-stacking). Cart Transform è la famiglia meno intuitiva e più utile per chi vende kit. Invece di creare un prodotto "bundle" con il suo inventario separato, la Function unisce tre righe del carrello in una sola con un prezzo proprio, e l'inventario resta sui singoli componenti. Il dettaglio è in [Shopify Functions cart transform](/shopify-functions-cart-transform). ## Casi d'uso per un merchant italiano I casi che tornano più spesso nei negozi italiani hanno a che fare con il B2B, le soglie di spedizione e i pagamenti. **Prezzi per rivenditori senza codici sconto.** Un cliente con Partita IVA, riconosciuto tramite tag o tramite l'account aziendale, vede il prezzo rivenditore applicato in automatico nel checkout. Nessun codice da comunicare, nessun rischio che il codice giri su un forum. **Sconti a scaglioni per quantità.** Dieci pezzi il 5%, cinquanta il 12%, cento il 20%. È il caso classico degli Scripts e una Function lo fa su tutti i piani, per riga o per totale ordine. Le opzioni sono confrontate in [Shopify tiered discounts](/shopify-tiered-discounts). **Spedizione gratuita con soglia per mercato.** Con Shopify Markets, lo stesso negozio vende in Italia, Germania e Francia. La Function legge il mercato del carrello e applica una soglia diversa per ognuno, in valuta locale. **Incentivo al pagamento anticipato.** Un merchant che vuole spingere il bonifico o la carta rispetto al contrassegno può abbinare una Payment Customization, che mostra i metodi giusti, a una Discount Function, che applica lo sconto quando il cliente sceglie il metodo incentivato. Il meccanismo è descritto in [prepaid discount con Functions](/prepaid-discount-shopify-payment-method-discounts-functions). **Regalo con acquisto.** Sopra una soglia, un prodotto entra nel carrello a prezzo zero. Con una Function il regalo non può essere acquistato a prezzo zero da solo, cosa che con le vecchie soluzioni a codice sconto succedeva regolarmente. **Bundle configurabili.** Tre prodotti scelti dal cliente da una lista diventano un kit con prezzo fisso. Cart Transform li unisce, l'inventario resta sui componenti, la fattura riporta il kit. ## Cosa le Functions non possono fare I limiti delle Functions sono precisi, e sapere dove finiscono evita di pagare per qualcosa che poi non funziona. **Nessuna chiamata di rete.** La Function non può interrogare un gestionale, un CRM o un servizio di validazione durante l'esecuzione. Se lo sconto dipende da un dato esterno (il saldo punti del cliente, un listino aggiornato ogni notte), un'app deve scrivere quel dato in un metafield prima, e la Function lo legge da lì. **Nessuna memoria tra esecuzioni.** Ogni valutazione parte da zero. Non può contare quante volte un cliente ha usato uno sconto; quel conteggio vive altrove. **Limiti di dimensione e di istruzioni.** L'input che la Function chiede e il numero di operazioni che può eseguire hanno tetti. Un carrello con centinaia di righe e una regola che le confronta tutte tra loro può superarli, e questo va testato prima del lancio. **Nessuna interfaccia propria.** La Function calcola, non mostra. Se vuole che il cliente veda "ti mancano 20 euro alla spedizione gratuita", quello è compito del tema o di una checkout UI extension, che sono strumenti diversi. **Non tutto è disponibile su tutti i piani.** Gli sconti sì. Alcune personalizzazioni della fase di pagamento e il branding del checkout restano legati a Plus, e va verificato caso per caso. L'elenco completo, con gli esempi di cosa succede quando si supera un limite, è in [Shopify Functions limitations](/shopify-functions-limitations). ## Quanto costa e chi la costruisce Una singola Function ha un costo di progetto una tantum, e la variabile che lo muove è quanta interfaccia di configurazione serve. I listini pubblicati partono da 1.500 $ per una singola Function o checkout extension, con una fascia tipica tra 1.500 e 3.000 $, e sono su [byteinfy.com/services/shopify-checkout-extensions](https://byteinfy.com/services/shopify-checkout-extensions). Il lavoro comprende la scrittura delle regole in linguaggio naturale prima del codice, la Function stessa, la sua distribuzione tramite app custom sul suo negozio, i test nell'anteprima del checkout e l'attivazione con un modo rapido per spegnerla. La parte che fa salire il prezzo è la pagina di amministrazione. Una Function con soglie fisse nel codice costa il minimo; una con una schermata dove il suo team cambia percentuali, tag e soglie da solo costa di più, ma non richiede più uno sviluppatore per ogni modifica. Se prevede di cambiare le regole ogni stagione, la seconda opzione si ripaga in fretta. L'alternativa è un'app pubblica. Se sull'App Store esiste un'app che fa esattamente la sua regola, il canone mensile è quasi sempre più conveniente di uno sviluppo, almeno finché la regola resta standard. Il confronto tra le due strade è in [custom vs public Shopify app](/custom-vs-public-shopify-app), e le voci di costo di un progetto Shopify nel complesso sono in [quanto costa un negozio Shopify nel 2027](/it/agenzia-shopify-quanto-costa-negozio-nel-2027-prezzi). ## Come migrare dagli Scripts senza fermare il checkout Se ha ancora regole scritte come Scripts, la migrazione è un progetto con un ordine preciso, e saltare passaggi costa ordini persi. ## Piano di migrazione da Scripts a Functions - Inventario di ogni Script attivo, con la regola scritta in italiano e un esempio di carrello per ognuna - Verifica di quali regole esistono già come sconto nativo o come app, per eliminarle dal progetto - Riscrittura di ogni regola rimasta come Function, una alla volta - Test di ogni Function nell'anteprima del checkout con i carrelli di esempio dell'inventario - Verifica delle combinazioni tra sconti, con le classi dichiarate in modo coerente - Attivazione in una finestra di basso traffico con lo Script corrispondente disattivato subito prima - Monitoraggio degli ordini delle prime 48 ore per confrontare gli sconti applicati con quelli attesi - Documentazione delle regole e di dove si cambiano i parametri, consegnata al suo team Il primo punto è quello che fa risparmiare di più. Molti Scripts scritti anni fa replicavano funzioni che Shopify ha aggiunto nel frattempo agli sconti nativi: sconto quantità, spedizione gratis sopra soglia, sconto automatico per collezione. Ognuna di queste regole non va migrata, va sostituita con la funzione nativa, e il progetto si accorcia. ## Quando basta uno sconto nativo Prima di far costruire una Function, guardi cosa fanno gli sconti nativi di Shopify, perché coprono più casi di quanto si pensi. Gli sconti automatici e i codici nativi gestiscono percentuali e importi fissi su prodotti, collezioni e ordini, sconti quantità a scaglioni semplici, spedizione gratuita sopra soglia, acquisti "compra X ricevi Y", limiti per cliente e per numero di utilizzi, date di validità e regole di combinazione tra classi. Per la maggior parte dei negozi con un catalogo normale e promozioni stagionali, questo basta. Il caso "compra X ricevi Y" senza app è spiegato in [how to set up BOGO on Shopify](/how-to-set-up-bogo-on-shopify). Una Function serve quando la regola dipende da qualcosa che gli sconti nativi non vedono: un tag cliente, un metafield di prodotto, il mercato, il peso, il metodo di pagamento, una combinazione di condizioni. Se riesce a descrivere la regola in una frase senza parole come "solo se", "tranne quando" o "per i clienti che", probabilmente non le serve una Function. Se non ci riesce, ne ha bisogno, e a quel punto il lavoro conviene farlo bene una volta. **Ha una regola di sconto che gli sconti nativi non coprono?** ByteInfy scrive Shopify Functions per sconti, spedizioni e pagamenti da 1.500 $, con le regole concordate per iscritto prima del codice e un interruttore per spegnerle in un clic. [Parla con ByteInfy](https://byteinfy.com/contact) ## FAQ ### Cosa sono le Shopify Functions? Piccoli programmi, scritti in JavaScript o Rust e compilati in WebAssembly, che Shopify esegue dentro il checkout per calcolare sconti, riordinare metodi di pagamento e spedizione, validare il carrello o trasformarlo in bundle. ### Le Functions servono solo a chi ha Shopify Plus? No. Gli Scripts erano riservati a Plus, le Functions per gli sconti funzionano su tutti i piani. ### Posso fare uno sconto diverso per i clienti con Partita IVA? Sì. Un tag sul cliente o un metafield leggibile dalla Function permette di applicare percentuali o prezzi diversi ai rivenditori, senza codici sconto. ### Le Functions possono leggere dati da un sistema esterno? Non durante l'esecuzione. Una Function non fa chiamate di rete. ### Quanto costa far costruire una Shopify Function? I listini pubblicati partono da 1.500 $ per una singola Function o checkout extension, con una fascia tipica tra 1.500 e 3.000 $. Programmi con più regole insieme (contrassegno, upsell, validazioni) vengono quotati insieme. ### Cosa succede ai miei Scripts se non ho ancora migrato? Gli Scripts sono dismessi e non vanno più considerati un'opzione. Ogni regola che facevano va riscritta come Function con lo stesso comportamento, testata nell'anteprima del checkout e attivata in una finestra di basso traffico. ### Posso combinare più Functions di sconto insieme? Sì, entro le regole di combinazione di Shopify. Gli sconti hanno classi (prodotto, ordine, spedizione) e ogni sconto dichiara con quali classi si combina. Una Function rispetta le stesse regole degli sconti nativi. --- --- title: "Shopify Product Page SEO: Beyond the Title Tag" description: "Product pages rarely fail because of their title tags. They fail because the data is thin, the specifications are in an image, and nothing links to them." author: "Aashish Kaushik" published: 2026-10-07T13:01:21.884Z updated: 2026-10-07T13:01:22.030Z url: https://blog.byteinfy.com/shopify-product-page-seo --- # Shopify Product Page SEO: Beyond the Title Tag ## Key takeaways - Product data completeness matters more than keyword placement, and it now feeds classic search, shopping surfaces and AI agents at once. - Specifications published as images are invisible to every machine reading your catalogue, and this is extremely common. - Variant pages are a duplication risk — decide deliberately which variants deserve indexable URLs. - Products are usually over-linked internally while collections are under-linked, which is backwards for category queries. Product page SEO advice tends to be about title tags and keyword placement. Those matter and they are rarely the reason a product page underperforms. The common causes are duller: fields left empty, specifications published as graphics, manufacturer copy identical to forty other retailers, and a page that nothing internally links to. All four are fixable, and none of them require writing better headlines. > **One piece of work, three channels** > > Everything below improves classic Google ranking, your shopping feed, and the AI surfaces Shopify now syndicates eligible products to. That is the strongest argument for doing it — the same effort pays three times. ## Completeness beats cleverness The fields on a Shopify product are not just admin metadata. They are what machines use to understand and categorise what you sell. A product with an empty product type, unlabelled variant options and a description of brand voice is not ranked poorly so much as poorly understood. Systems cannot categorise it, cannot match it to specific queries, and cannot answer comparison questions about it. ## Fields that need to be right, across the catalogue - Title stating the thing literally — what a person would type - Product type, populated and consistent across similar products - Vendor, populated - Variant options describing real attributes, not internal codes - Description containing material, dimensions, compatibility and use case - Alt text describing the product rather than the marketing concept Consistency across the catalogue matters as much as correctness within one product. A product type of "Boots" on some items and "Footwear - Boots" on others fragments your own categorisation for no benefit. ## Specifications in images are invisible The single most common and most costly technical error in product catalogues. A great many stores publish dimensions, materials, compatibility and care instructions as a designed graphic. It looks good. To a shopper it is perfectly usable. To every machine reading the page, that information does not exist. The consequence is that the product cannot match any query mentioning those attributes, cannot answer a comparison question, and is invisible to the AI shopping surfaces Shopify now syndicates to automatically. Keep the graphic if it serves shoppers, and add the same information as text as well. This is not a design compromise — the two can coexist, and the text version can sit in a specifications table below the image. ## Manufacturer copy is a losing position If you resell products, your descriptions are probably the manufacturer's, and so are those of every other retailer carrying the item. This is rarely penalised. It is simply that nothing distinguishes your page, so there is no reason for a search engine to prefer it over any of the others. What creates a reason: **Your own photography**, particularly showing scale and real use. **Your own specifics** — the things you know from selling it that the manufacturer's copy does not say. Which size runs small. What it does not work with. Who it suits. **Genuine reviews**, which are original content by definition and answer questions the description does not. **The questions your customers actually ask**, answered on the page. Your support inbox is the best content brief available for a product page, and almost nobody uses it. You do not need to rewrite eight hundred descriptions. Add original detail to the products that matter commercially, and let the long tail carry manufacturer copy. Identifying which products matter is easier than it sounds. Sort by revenue, then by search impressions in Search Console, and look at where the two lists overlap and where they diverge. Products with impressions but few clicks are usually a title or description problem you can fix cheaply. Products with revenue but no impressions are ranking for nothing and being found some other way, which means original content there has the most headroom. ## Variants and the duplication question Shopify variants raise a decision most merchants make by default rather than deliberately. Variants that represent genuinely different search intent can justify indexable URLs — different capacities, different formats, meaningfully different products sold under one listing. Someone searching for the 512GB model has a specific intent that a generic product page serves poorly. Variants that are colours or sizes of the same item generally should not each have an indexable page. They produce near-duplicates competing with each other, and none of them accumulates the signals that would let one rank. The practical check is Search Console. If variant URLs are appearing in the duplicate or crawled-not-indexed buckets in volume, the platform has already decided they are not distinct, and you should stop generating them. ## How to actually stop generating variant URLs Deciding that colour and size variants should not each have an indexable page is the easy part. Implementing that decision on Shopify takes a bit more than flipping a setting, because the platform does not offer a single switch for it. The most reliable route is the canonical tag your theme renders in the page head. When a shopper lands on a variant URL, such as a product page with a query string identifying a specific colour, the canonical tag should point to the base product URL without that parameter. Most modern Shopify themes do this by default, so the first step is checking rather than building: view source on a few variant URLs and confirm the canonical link element points to the clean product URL, not to itself. Where a theme is not doing this correctly, or where a custom template has broken it, the fix usually lives in the product template's head section, and it is a small, contained change rather than a structural one. This is worth confirming directly with whoever maintains your theme rather than assuming, since a broken canonical tag on variant URLs is exactly the kind of quiet issue that produces the duplicate-content signals mentioned above without ever throwing an obvious error. Beyond the canonical tag, check whether your theme or any installed app is generating separate crawlable links to each variant, for instance a colour swatch that changes the page URL and creates a new, distinct link a crawler can follow independently, rather than updating the page in place with JavaScript. If variant swatches behave this way, a crawler can discover and attempt to index each combination as if it were a separate page, working against the canonical tag rather than with it. The Search Console check described above should be repeated after making any of these changes, not just once at the start. Canonical and indexation signals take time to be reprocessed, so treat this as a fix you verify weeks later rather than one you confirm the same day, and note the date you made the change so you know how long to wait before concluding it did or did not work. ## Nothing links to your product pages Internal linking on Shopify stores is consistently lopsided, and usually in a way that hurts. Products are reachable from collections and search. Collections are reachable from navigation. Editorial content, where it exists, tends to link to individual products. That last habit is the problem. A blog post about choosing walking boots should link to the walking boots *collection*, because the collection is the page that should win the category query. Linking to one product instead spends the link on a page that was never going to rank for the category and deprives the page that could. ## Where internal links should point | Content | Should link to | Common mistake | | --- | --- | --- | | Category or buying guide | The collection | One specific product | | Product comparison | Both products, and the collection | Only the winner | | How-to content | The collection, plus one relevant product | Nothing at all | | Product page | Its collection, via breadcrumbs | No breadcrumb | | Collection | Adjacent collections | Nothing | Breadcrumbs deserve specific attention. They are the most reliable product-to-collection link on a store, and many themes either omit them or render them without markup. Adding them is usually a small template change, it benefits shoppers who want to browse sideways, and it emits BreadcrumbList structured data that clarifies your site hierarchy at the same time. ## Schema, and where it should come from Product schema — price, availability, condition, reviews where genuine — should be rendered server-side in the page source, so a crawler sees it without executing JavaScript. Two things to check before adding anything: **What your theme already emits.** View source on a product page and look. Modern themes frequently emit product schema, and installing an app to add it produces two conflicting copies. **Whether it matches the visible page.** Schema stating a price the page does not show is worse than no schema, because it undermines trust in everything else you mark up. ## Out-of-stock and discontinued products What you do with products that are no longer available is a genuine SEO decision, and the default — deleting them — is usually the worst option. A product page that has been live for two years has accumulated links, search history and sometimes rankings. Deleting it discards all of that and produces a 404 for everyone who arrives from an old link, an old email or a bookmark. The better options, in order of how permanent the absence is: **Temporarily out of stock: keep the page live.** Show that it is unavailable, offer a notify option, and suggest alternatives. The page keeps its rankings and is ready when stock returns. Removing and recreating it later starts from zero. **Permanently discontinued, direct replacement exists: redirect** to the replacement. The link equity transfers and the customer lands somewhere useful. **Permanently discontinued, no replacement: redirect to the collection.** Less ideal than a direct replacement but far better than a 404, and the shopper arrives among relevant alternatives. **Seasonal products: keep the page year-round.** A page that vanishes each spring and reappears each autumn never accumulates anything. Keep it, mark it unavailable, and let it build history across seasons. > **Availability schema must match reality** > > Whatever you do, the structured data has to agree with the page. An out-of-stock product still declaring availability in its schema is exactly the kind of mismatch that erodes trust in all your markup — and on shopping surfaces it produces a listing that sends buyers to something they cannot purchase. ## The order to work in 1. Audit field completeness across the catalogue. This is a bulk problem, so treat it as one. 2. Move specifications out of images into text. 3. Decide the variant indexation question and stop generating what you do not want. 4. Add original detail to commercially important products only. 5. Fix internal linking, particularly breadcrumbs and editorial link targets. 6. Verify schema is present once, server-side, and accurate. Steps one to three are mechanical and finite — they have an end state, and once reached they stay reached. Steps four and five are ongoing, but only across the products that matter commercially, which is what keeps the work sustainable rather than endless. For the structural work at collection level, see [SEO and AI search](/category/seo-ai-search). Product data for AI surfaces is covered in the same archive, and page design in [storefront and design](/category/storefront-design). **Alt text and image SEO across a whole catalogue** ByteInfy's Alt Text Bulk Edit handles alt text with automation rules, plus image compression and SEO file renaming — the bulk half of product page SEO. [See it on the Shopify App Store](https://apps.shopify.com/byteinfy-alt-text-editor) ## FAQ ### Should every product variant have its own URL? Usually not. Variants that represent genuinely different search intent — a different capacity, a different format — can justify their own indexable page. ### How long should a Shopify product description be? Long enough to state the facts a buyer needs and no longer. Length is not the metric; completeness and structure are. ### Does duplicate manufacturer copy hurt product pages? It makes ranking harder, because your page is then one of many carrying identical text and nothing distinguishes it. ### Where should product schema come from? Ideally your theme, rendered server-side in the page source so a crawler sees it without executing JavaScript. ### What is the highest-impact product page SEO fix? For most catalogues, moving specifications out of images and into text, and filling the empty structured fields. --- --- title: "Checklist SEO Shopify 2027: 25 punti che contano" description: "La SEO su Shopify non fallisce sulle parole chiave. Fallisce su URL duplicati delle collezioni, pagine varianti sottili, app che rallentano e dati strutturati mancanti. Venticinque punti, in ordine di impatto." author: "Aashish Kaushik" published: 2026-10-07T05:01:09.060Z updated: 2026-10-07T05:01:09.249Z url: https://blog.byteinfy.com/checklist-seo-shopify-2027-25-punti-che-contano --- # Checklist SEO Shopify 2027: 25 punti che contano ## Key takeaways - I problemi che frenano di più un negozio Shopify sono strutturali (URL duplicati, canonical, velocità), non di parole chiave, e vanno risolti prima di scrivere contenuti. - Shopify gestisce da solo sitemap, canonical di base e hreflang con Markets, ma lascia al merchant titoli, meta, alt text, dati strutturati e la pulizia delle app. - Le pagine collezione e prodotto portano quasi tutto il traffico organico di un e-commerce; il blog serve a intercettare domande, non a vendere direttamente. - Search Console è l'unico strumento che dice cosa Google vede davvero; una checklist senza misurazione è un elenco di buone intenzioni. La SEO di un negozio Shopify si gioca per la maggior parte su una decina di impostazioni strutturali, e solo in seconda battuta sulle parole chiave. Se il tema linka gli URL annidati delle collezioni, se le pagine varianti si indicizzano da sole, se dodici app aggiungono script a ogni pagina, nessun articolo del blog compenserà. Questa checklist parte da lì e arriva ai contenuti solo quando la base regge. I 25 punti sono raggruppati per area e ordinati per impatto dentro ogni gruppo. Alcuni li fa Shopify da solo e vanno solo verificati; altri richiedono un intervento sul tema o una decisione editoriale. Per ognuno indichiamo chi lo fa di solito, così può capire cosa può chiudere internamente e cosa passare a chi sviluppa. Per la guida completa alla SEO Shopify, con i ragionamenti dietro ogni punto, veda [Shopify SEO guide 2026](/shopify-seo-guide-2026). Questa pagina è la versione operativa. > **Cosa Shopify fa da solo** > > Shopify genera la sitemap XML, aggiunge i canonical di base, redirige il dominio secondario su quello primario, serve le immagini in WebP e crea gli hreflang quando usa Markets. Non deve fare nulla di tutto questo a mano, e un'agenzia che le vende una di queste voci come intervento sta vendendo aria. ## Struttura e URL (punti 1-5) La struttura degli URL su Shopify è fissa, e la maggior parte degli errori nasce dal cercare di combatterla anziché dal lavorarci dentro. **1. Verifichi che i link interni puntino a /products/handle e non a /collections/x/products/handle.** Shopify aggiunge da solo un canonical sull'URL annidato, ma un tema che linka sempre la versione annidata spreca crawl budget e diluisce i segnali interni. È una modifica di poche righe nel tema, e di solito la fa lo sviluppatore. Il dettaglio è in [Shopify duplicate content](/shopify-duplicate-content). **2. Scelga handle brevi e stabili.** L'handle è la parte finale dell'URL. "maglione-lana-merino-grigio" è meglio di "maglione-lana-merino-grigio-taglia-m-nuova-collezione-2027". Una volta pubblicato, non lo cambi senza un redirect. **3. Non usi le pagine tag come pagine di categoria.** Gli URL /collections/all/tag-x sono deboli e duplicano le collezioni. Se una combinazione di filtri merita una pagina, crei una collezione automatica con quel criterio e un titolo proprio. **4. Mantenga un solo dominio primario.** Shopify redirige il .myshopify.com e i domini secondari sul primario. Verifichi che www e non-www puntino allo stesso posto e che HTTPS sia forzato, e non tocchi altro. **5. Tenga un registro dei redirect.** Ogni prodotto eliminato, ogni collezione rinominata, ogni pagina spostata è un redirect 301 da creare in Contenuti, URL redirect. Un registro in un foglio condiviso evita i 404 che compaiono mesi dopo. ## Pagine prodotto e collezione (punti 6-11) Le pagine collezione e prodotto portano quasi tutto il traffico organico di un e-commerce, e sono quelle su cui vale la pena spendere tempo. **6. Scriva titoli e meta description per ogni collezione.** Le collezioni sono le pagine di categoria, e "Maglioni" come titolo non compete con nessuno. Un titolo del tipo "Maglioni in lana merino da donna, made in Italy" e una description con la promessa reale della pagina cambiano il click-through. Il lavoro sulle collezioni è approfondito in [Shopify collection page SEO](/shopify-collection-page-seo). **7. Aggiunga testo alle collezioni, sotto la griglia.** Duecento parole utili in fondo alla collezione (per chi è il prodotto, come scegliere, cosa distingue la sua selezione) danno a Google un contesto che la griglia di immagini non dà. In cima alla pagina il testo allontana i prodotti; in fondo non disturba nessuno. **8. Riscriva le descrizioni prodotto, non le copi dal fornitore.** La descrizione del produttore è già su cinquanta negozi. Una descrizione scritta per il suo cliente, con le domande che il suo servizio clienti sente più spesso, è unica per definizione. Le regole sono in [Shopify product page SEO](/shopify-product-page-seo). **9. Verifichi cosa indicizza per le varianti.** Gli URL con ?variant= hanno canonical sul prodotto base, quindi in genere non sono un problema. Lo diventano se il tema crea pagine separate per colore o se un'app genera URL indicizzabili per ogni combinazione. **10. Scriva l'alt text delle immagini come una frase.** "Maglione girocollo in lana merino grigio indossato, vista frontale" serve a Google Immagini e all'accessibilità; "maglione" non serve a nessuno. Con centinaia di immagini si fa in massa, con un'app o uno script, non a mano. Veda [Shopify image alt text SEO](/shopify-image-alt-text-seo). **11. Gestisca i prodotti esauriti con giudizio.** Un prodotto che tornerà resta pubblicato con l'avviso e il modulo di notifica. Un prodotto che non tornerà va reindirizzato alla collezione o al sostituto, non lasciato in 404 e nemmeno lasciato indicizzato per anni. ## Dati strutturati e contenuti (punti 12-16) I dati strutturati sono ciò che permette a Google e ai motori di risposta di estrarre prezzo, disponibilità e recensioni senza indovinare. **12. Verifichi che il tema emetta il markup Product.** Dawn e Horizon lo fanno; molti temi acquistati lo fanno male o due volte. Usi il test dei risultati multimediali di Google su tre pagine prodotto e guardi cosa esce. Se manca prezzo o disponibilità, è un intervento sul tema. **13. Aggiunga Organization, BreadcrumbList e, dove ha senso, FAQPage.** Organization sulla home, BreadcrumbList su collezioni e prodotti, FAQPage solo su pagine che hanno davvero domande e risposte visibili. Il markup deve rispecchiare la pagina. **14. Non installi due app che generano lo stesso markup.** Markup duplicato è peggio di markup assente, perché i valori possono contraddirsi. Una sola fonte per ogni tipo di dato. **15. Usi il blog per le domande, non per i prodotti.** Il blog di Shopify serve a intercettare le ricerche informative ("come lavare la lana merino", "differenza tra cashmere e merino") e a portare quel traffico alle collezioni con link interni. Un articolo che ripete la scheda prodotto compete con la scheda stessa. Le regole in [Shopify blog SEO](/shopify-blog-seo). **16. Collega ogni articolo a due o tre collezioni, e ogni collezione a un articolo.** Il link interno è la parte della SEO che nessuna app fa bene e che costa zero. Un menu di navigazione pulito e i link nei testi delle collezioni fanno la maggior parte del lavoro. ## Velocità e Core Web Vitals (punti 17-20) La velocità di un negozio Shopify dipende dal tema e dalle app, e la home page è la pagina meno utile da misurare. **17. Misuri le pagine prodotto e collezione con dati di campo.** Search Console, sezione esperienza sulle pagine, e il rapporto CrUX dicono cosa vedono gli utenti reali. Il punteggio di velocità dell'admin Shopify non è Core Web Vitals e non va confuso con esso. **18. Faccia un inventario delle app e degli script che lasciano.** Ogni app che tocca la vetrina aggiunge script. Le app disinstallate spesso lasciano righe nel theme.liquid. Un audit del tema le trova e le rimuove; è il singolo intervento che sposta di più i numeri, come spiegato in [Shopify theme speed](/shopify-theme-speed). **19. Dimensioni le immagini per il punto in cui compaiono.** Shopify serve WebP e ridimensiona, ma il tema deve chiedere la dimensione giusta. Un'immagine hero da 4000 pixel caricata su mobile è un problema del tema, non di Shopify. **20. Non installi app di velocità.** Quasi tutte aggiungono uno script che rimanda gli altri script. Togliere la causa batte aggiungere un cerotto. ## Chi fa cosa nella checklist | Area | Lo fa Shopify | Lo fa il merchant | Lo fa chi sviluppa | | --- | --- | --- | --- | | URL e redirect | Sitemap, canonical base, redirect di dominio | Handle, registro redirect | Link interni canonici nel tema | | Collezioni e prodotti | Nulla | Titoli, meta, testi, alt text | Template collezione con testo in basso | | Dati strutturati | Nulla | Verifica con il test di Google | Markup Product, Organization, Breadcrumb | | Velocità | WebP, CDN, cache | Rimozione app inutili | Pulizia tema, dimensioni immagini, script | | Internazionale | Hreflang, sottocartelle o domini | Traduzioni reali, prezzi per mercato | Configurazione Markets, template per mercato | | Misurazione | Nulla | Search Console e GA4 ogni settimana | Tracciamento tramite Customer Events | ## Internazionale e Shopify Markets (punti 21-22) Se vende anche fuori dall'Italia, Markets fa il lavoro tecnico e le lascia quello editoriale. **21. Scelga tra sottocartelle e domini per mercato una volta sola.** Markets supporta entrambi e genera gli hreflang. Le sottocartelle (/de, /fr) ereditano l'autorità del dominio principale e sono la scelta più semplice per la maggior parte dei negozi; i domini separati hanno senso solo con brand o team locali. Cambiare dopo il lancio è una migrazione. **22. Traduca titoli, meta e testi delle collezioni, non solo l'interfaccia.** Una traduzione attivata ma non fatta produce pagine in tedesco con titoli in italiano. Ogni mercato ha bisogno delle sue parole chiave, e le ricerche in tedesco non sono la traduzione letterale di quelle in italiano. ## Misurazione e manutenzione (punti 23-25) Una checklist senza misurazione è un elenco di buone intenzioni, e Search Console è l'unico strumento che dice cosa Google vede davvero. **23. Verifichi la proprietà in Search Console e invii la sitemap.** La sitemap è su /sitemap.xml e la genera Shopify. Dopo l'invio, guardi il rapporto di copertura ogni settimana: pagine escluse, 404, canonical alternativi scelti da Google. **24. Controlli il tracciamento dopo ogni cambio di tema o app.** GA4 e i pixel pubblicitari su Shopify passano dai Customer Events, e un cambio di tema può duplicarli o spegnerli. Un ordine di test dopo ogni modifica costa dieci minuti. **25. Rifaccia i punti strutturali a ogni cambio di tema.** Un tema nuovo cambia link interni, markup, dimensioni immagini e script. Tutto quello che ha verificato nei punti da 1 a 20 va riverificato, ed è più veloce farlo prima di pubblicare il tema che dopo. ## I 25 punti, da spuntare - Link interni su /products/handle, non sugli URL annidati nelle collezioni - Handle brevi e stabili - Nessuna pagina tag usata come categoria - Un dominio primario, HTTPS forzato - Registro dei redirect 301 aggiornato - Titolo e meta description per ogni collezione - Testo utile in fondo a ogni collezione - Descrizioni prodotto riscritte, non copiate dal fornitore - Varianti non indicizzate come pagine separate - Alt text delle immagini scritto come frase - Prodotti esauriti gestiti con avviso o redirect - Markup Product verificato con il test di Google - Organization, BreadcrumbList e FAQPage dove ha senso - Una sola fonte per ogni tipo di markup - Blog usato per le domande informative - Link incrociati tra articoli e collezioni - Core Web Vitals misurati su prodotto e collezione con dati di campo - Inventario delle app e degli script residui - Immagini dimensionate per il punto in cui compaiono - Nessuna app di velocità installata - Sottocartelle o domini per mercato scelti una volta - Titoli, meta e testi tradotti per ogni mercato - Search Console verificata e sitemap inviata - Tracciamento verificato dopo ogni modifica - Punti strutturali riverificati a ogni cambio di tema ## Gli errori che vediamo più spesso nei negozi italiani Tre schemi si ripetono, e nessuno riguarda le parole chiave. **Il tema premium mai pulito.** Il negozio è nato su un tema acquistato nel 2022, ha cambiato quattro app di recensioni e due di bundle, e ognuna ha lasciato qualcosa nel theme.liquid. Le pagine prodotto caricano venti script di cui otto non servono più. La correzione è un audit del tema, e si fa una volta. **Le collezioni senza testo e senza meta.** Il catalogo è stato importato in fretta, le collezioni hanno titoli di una parola e nessuna description, e Google mostra nello snippet il primo prodotto della griglia. È il lavoro editoriale a più alto ritorno che un merchant possa fare da solo, e non richiede sviluppatori. **Markets attivato senza tradurre.** Il negozio vende in Germania e Francia con prezzi in euro e hreflang corretti, ma le pagine sono in italiano con l'interfaccia tradotta. Google le vede come duplicati tradotti a metà, e i clienti tedeschi le vedono come un negozio straniero. Per capire cosa aspettarsi da un'agenzia SEO su questi punti, e cosa non può prometterle nessuno, veda [Shopify SEO agency what to expect](/shopify-seo-agency-what-to-expect). I prezzi di partenza per un audit tecnico sono su [byteinfy.com/services/shopify-seo](https://byteinfy.com/services/shopify-seo). **Vuole sapere quali dei 25 punti fermano il suo negozio?** ByteInfy fa audit tecnici SEO su Shopify da 1.000 $, con un elenco ordinato per impatto e le correzioni sul tema verificate in Search Console. [Parla con ByteInfy](https://byteinfy.com/contact) ## FAQ ### Shopify è penalizzato nella SEO rispetto a WooCommerce? No. Shopify ha una struttura URL fissa e meno libertà su alcuni dettagli tecnici, ma genera sitemap, canonical e hreflang da solo e serve pagine veloci di default. ### Posso cambiare la struttura degli URL di Shopify? No. I prefissi /products/, /collections/, /pages/ e /blogs/ sono fissi. Può scegliere l'handle di ogni risorsa e creare redirect 301, ma non rimuovere i prefissi. ### Cosa fare con gli URL duplicati delle collezioni? Shopify aggiunge da solo un canonical che punta a /products/handle, quindi Google consolida i segnali. ### Quante app SEO servono su Shopify? Di norma nessuna o una. ### Il blog di Shopify serve per la SEO? Sì, ma per intercettare domande informative, non per vendere. ### Come gestisco la SEO se vendo in più paesi con Shopify Markets? Markets genera i tag hreflang e permette sottocartelle o domini per mercato. ### Ogni quanto rifare questa checklist? I punti strutturali una volta, poi a ogni cambio di tema o app. I punti sui contenuti e sulla misurazione ogni mese. Search Console va aperto ogni settimana, anche solo per cinque minuti. --- --- title: "BFCM Inventory and Fulfilment Ops for Shopify" description: "The stock that runs out during BFCM is rarely the product you promoted. It is the free gift, the bundle component, and the variant nobody was watching." author: "Aashish Kaushik" published: 2026-10-06T13:01:24.011Z updated: 2026-10-06T13:01:24.014Z url: https://blog.byteinfy.com/bfcm-inventory-ops --- # BFCM Inventory and Fulfilment Ops for Shopify ## Key takeaways - Offer mechanics consume stock in patterns your forecast does not describe, because demand for a gift is driven by sales of something else. - Continue-selling-when-out-of-stock is safe all year and dangerous during BFCM, when weeks of ordering compress into hours. - Decide before the weekend what each offer does when its component runs out, because the alternative is deciding it at 2am. - Fulfilment capacity is a hard constraint, and extending the sale window is the cheapest way to spread the load. Most BFCM inventory planning forecasts demand for the products being promoted. That is the easy half, and it is not where stores get caught. What runs out is the free gift attached to a threshold offer, the component shared between a bundle and its standalone listing, and the variant that was never the point of the campaign. These are consumed by demand for something else entirely, which is precisely why nobody is watching them. > **Scope** > > Inventory and fulfilment operations for the BFCM period. Offer structure and checkout readiness are covered separately in the series. ## Offer mechanics consume stock in unfamiliar patterns Ordinary selling decrements stock in a way your forecast describes. Promotional mechanics do not, and each one fails differently. **Free gift with purchase.** The gift is consumed at a rate driven by sales of the qualifying products, which may be your entire catalogue. If the threshold is easy to hit, the gift is effectively being ordered by every large basket. **Bundles.** A component sold both inside a bundle and separately depletes from two directions. Fixed bundles compound this, because the bundle carries its own stock count that must stay synchronised with its components. **Buy X get Y.** Drains the Y product at a rate governed by demand for X. If Y is a slower-moving item you chose precisely because it was slow, you may be about to discover how fast it can move. **Tiered thresholds.** Shift the basket composition, so products that usually sell in ones start selling in twos and threes. ## Mechanic and the stock it quietly consumes | Mechanic | What actually depletes | Who is watching it | | --- | --- | --- | | Free gift over threshold | The gift SKU | Usually nobody | | Fixed bundle | Every component, plus bundle stock | Partly | | Dynamic bundle | Components, from two directions | Rarely | | Buy X get Y | The Y product | Rarely | | Tiered spend | Higher quantities of mid-price items | No | | Flat percentage | Broadly as forecast | Yes | The rightmost column is the point. The mechanics that are hardest to forecast are also the ones nobody has been made responsible for watching, which is how a campaign runs out of its own centrepiece. ## Decide the out-of-stock behaviour in advance For every offer, there is a question with three possible answers, and you should choose deliberately rather than discover it. When the gift, or the bundle component, runs out: **The offer stops applying.** Cleanest, and the shopper sees the offer disappear. Requires that the mechanism actually checks stock, which not all do. **It substitutes.** Another product takes its place. Good customer experience, needs configuring in advance, and needs a substitute chosen. **It oversells.** The offer keeps applying and you owe people something you do not have. Occasionally acceptable if you can restock quickly; usually the worst outcome. Set a stock alert on every gift, every bundle component and every Y product before the period starts. These are not the items your normal alerting covers, because they are not normally your constraint. ## Inventory preparation - Stock alerts on every gift, bundle component and buy-X-get-Y item - A written decision for each offer about what happens at zero - Continue-selling settings reviewed product by product, not globally - Reserved allocation for anything central to an advertised campaign - A check that bundle stock and component stock are actually synchronised - Someone named as responsible for watching these during the period ## Continue-selling is the setting that bites Allowing sales when stock reaches zero is defensible for made-to-order products or where inbound stock is reliable and imminent. All year it causes no trouble. BFCM changes the arithmetic without changing the setting. Volume that would normally arrive over weeks arrives in hours, so a product that would have oversold by three units across a fortnight oversells by three hundred over a weekend, and nobody notices until fulfilment. Review this product by product before the period. It is tedious and it prevents the most expensive category of BFCM failure, which is taking money for things you cannot ship. The damage is not only the cancellations. An oversold order that gets refunded a week later produces a support contact, a payment reversal, a customer who now distrusts you, and frequently a public review saying so — all attached to a customer you acquired at the highest cost of the year. The unit economics of an oversell during BFCM are far worse than the same mistake in March. ## Fulfilment capacity is a real constraint Inventory is only half of it. You also have to physically get parcels out, and your capacity to do that does not scale with demand. Three things worth settling before the period: **Know your daily dispatch ceiling.** Actual, not aspirational. How many parcels can be picked, packed and collected in a day with the people and space you have. **Compare it against your forecast.** If peak-day orders exceed the ceiling, you will build a backlog, and a backlog during BFCM compounds because volume continues arriving. **Decide how to spread the load.** Extending the sale window is the cheapest option — it moves demand off the peak days without reducing it. Early access for your email list does the same thing while rewarding your best customers. Both are decisions made in October, not during the weekend. > **Communicate dispatch times honestly** > > A shopper told delivery will take a week and receiving it in a week is satisfied. One told two days and receiving it in a week is not, and contacts support about it. During BFCM the second scenario generates a support load on top of a fulfilment load, at the moment you have capacity for neither. Set the expectation wide. ## Returns are part of the operation, not an afterthought Return rates run higher on discounted and gifted purchases than on full-price ones, and the returns from BFCM arrive in December when everyone is exhausted. Plan for the volume rather than being surprised by it. Make sure the returns process is documented and staffable, that returned stock can be received and re-shelved rather than accumulating in a corner, and that refunds are processed promptly — a slow refund after a discounted purchase is how a price-driven buyer becomes a permanent non-customer. There is a specific complication with offer mechanics. When a customer returns part of an order that qualified for a gift or a threshold discount, the remaining order may no longer qualify. Decide your policy in advance — reclaim the gift, absorb it, or adjust the refund — and make sure whoever processes returns knows it. This question arrives during the first week of December without fail, and answering it ad hoc produces inconsistent decisions you will hear about later. ## Forecasting when last year does not help The standard method is to take last year's BFCM and adjust. It works when nothing changed, and something has almost always changed. Three situations where last year is actively misleading: **You are running different mechanics.** Last year's flat percentage tells you very little about how a threshold-plus-gift structure will consume stock. The total may be similar; the distribution across SKUs will not be. **Your catalogue has moved.** Products added, discontinued, or repriced since last November change which items the offer pulls through. A bundle built around a product that was not in last year's range has no history at all. **Your traffic mix has changed.** More paid, more email, more organic, a new market — each brings a different basket composition, and basket composition is what determines which components deplete. What to do instead of ignoring history entirely: use last year for the aggregate, and model the distribution from the mechanic. For a gift over a threshold, estimate what share of orders will exceed that threshold based on your current average order value, and multiply. For a bundle, estimate the anchor product's uplift and derive component demand from it. These are rough numbers, and rough numbers that describe the right shape beat precise numbers describing the wrong one. > **Buy the gift, not the forecast** > > For low-cost gift items, the cheapest insurance is to over-order deliberately. A surplus of a small promotional item costs you its unit price and some storage. Running out mid-campaign costs you the offer, the customer experience, and a decision made under pressure. The asymmetry is usually stark enough to make the answer obvious. ## During the period **Watch component stock, not just headline products.** The dashboard everyone looks at shows top sellers. The thing that will break is not on it. **Check the backlog daily.** Orders placed against orders dispatched. A gap that grows two days running will not close on its own. **Cancel early if you must cancel.** An oversell caught on day one and communicated clearly costs far less than a fulfilment failure discovered in the second week of December. Decide in advance who makes that call, because the instinct during peak is to hope it resolves itself. For offer structure and what each mechanic costs, see the [BFCM 2026](/series/bfcm-2026) series. Inventory across retail and online is covered in [POS and operations](/category/pos-operations). **Operations that hold up under peak** ByteInfy builds Shopify integrations for inventory, fulfilment and the operational reporting the admin does not give you. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Why do my bundle components run out during BFCM? Because demand for a bundle component is driven by sales of the anchor product, not by its own standalone demand. ### Should I allow overselling during BFCM? Very rarely. Continue-selling-when-out-of-stock is defensible for made-to-order items or where you have reliable inbound stock. ### What happens when a free gift runs out mid-campaign? That depends entirely on your configuration, and most merchants have never checked. The possibilities are that the offer stops applying silently, that it substitutes something else, or that it oversells the gift. ### How far ahead should I plan BFCM inventory? Far enough that reordering is still possible, which for most supply chains means well before November. ### Should I extend my BFCM sale to spread fulfilment load? Often yes. A longer window spreads picking, packing and dispatch across more days, reduces the risk of a single-day failure destroying the period, and matches consumer behaviour, which now starts earlier. --- --- title: "Agenzia Shopify: quanto costa un negozio nel 2027 (prezzi reali)" description: "Un negozio Shopify fatto da un'agenzia costa da circa 1.000 $ a oltre 25.000 $. La differenza non è il negozio in sé, sono il catalogo, le integrazioni e quanta parte del design va costruita da zero." author: "Aashish Kaushik" published: 2026-10-06T05:01:08.240Z updated: 2026-10-06T05:01:08.246Z url: https://blog.byteinfy.com/agenzia-shopify-quanto-costa-negozio-nel-2027-prezzi --- # Agenzia Shopify: quanto costa un negozio nel 2027 (prezzi reali) ## Key takeaways - La maggior parte dei negozi pronti al lancio costa tra 2.000 e 8.000 $ di sviluppo; sotto i 1.000 $ si compra quasi sempre un tema configurato, non un progetto. - Le tre variabili che muovono il preventivo sono il catalogo, le integrazioni (gestionale, SDI, corriere) e la quota di design su misura. - Il piano Shopify, le app a canone e le commissioni sui pagamenti non stanno nel preventivo dell'agenzia e vanno sommati a parte. - La manutenzione pesa sul costo totale a tre anni più del prezzo di lancio; un preventivo senza voce di manutenzione descrive metà della spesa. Un negozio Shopify realizzato da un'agenzia costa, nel 2027, da circa 1.000 $ per la personalizzazione di un tema esistente a oltre 25.000 $ per una vetrina headless con integrazioni complesse. La maggior parte dei merchant italiani che partono da zero spende tra 2.000 e 8.000 $ per un negozio pronto al lancio, con il piano Shopify, le app e le commissioni sui pagamenti da sommare a parte. La forbice è ampia perché il prezzo non dipende dal "negozio" in sé. Dipende da tre variabili: quanto è grande il catalogo, quante integrazioni servono (gestionale, fatturazione elettronica verso lo SDI, corriere) e quanta parte del design deve essere costruita su misura invece che configurata. Le cifre di partenza citate in questo articolo sono quelle pubblicate su [byteinfy.com/services](https://byteinfy.com/services), in dollari perché è così che sono elencate. Altre agenzie hanno listini diversi, ma le proporzioni tra le voci tendono a ripetersi, e sono le proporzioni che le servono per leggere un preventivo. > **Scritto da un'agenzia** > > Legga con la dovuta prudenza. I prezzi indicati sono quelli che pubblichiamo noi e li usiamo come riferimento perché sono verificabili, non perché siano gli unici possibili. Un'agenzia con sede a Milano avrà costi orari diversi da una con sede in India, e nessuna delle due cifre è automaticamente quella giusta per il suo progetto. ## Le fasce di prezzo nel 2027, in breve Prima i numeri, poi le spiegazioni. ## Costi di partenza per tipo di lavoro | Tipo di lavoro | Prezzo di partenza | Fascia tipica | | --- | --- | --- | | Personalizzazione di un tema esistente | da 1.000 $ | tra 1.000 e 3.000 $ | | Negozio nuovo su Online Store 2.0 | da 2.000 $ | tra 2.000 e 8.000 $ | | Migrazione da WooCommerce, Magento o altro | da 1.500 $ | da 1.500 $, ERP e multi-store a preventivo | | Audit SEO tecnico e correzioni | da 1.000 $ | tra 1.000 e 3.000 $ al mese se continuativo | | Ottimizzazione velocità (Core Web Vitals) | da 750 $ | tra 750 e 1.500 $ | | Checkout extension o Shopify Function | da 1.500 $ | tra 1.500 e 3.000 $ per singola funzione | | Integrazione con gestionale o fatturazione | da 1.500 $ | tra 1.500 e 4.000 $ per sistema | | App Shopify su misura | da 3.000 $ | tra 8.000 e 25.000 $ se pubblica sull'App Store | | Vetrina headless con Hydrogen | da 5.000 $ | da 5.000 a oltre 25.000 $ | | Manutenzione mensile | da 500 $ al mese | monitoraggio più cinque ore di sviluppo | Due osservazioni su questa tabella. La prima è che "negozio" non compare come voce unica: un progetto reale è quasi sempre la somma di due o tre righe, per esempio negozio nuovo più migrazione più integrazione con il gestionale. La seconda è che le fasce sono larghe perché descrivono lavoro a ore mascherato da prezzo fisso. Un'agenzia seria stima le ore dopo una chiamata di scoping e poi le blocca in un preventivo chiuso; un'agenzia che le dà un prezzo prima di sapere quanti prodotti ha sta indovinando. ## Cosa sta comprando quando paga un'agenzia Sta comprando ore di persone, non licenze. Questo spiega perché due preventivi per lo stesso negozio possono differire del triplo: cambiano il costo orario, il numero di ore stimate e quanto lavoro l'agenzia riesce a riutilizzare da progetti precedenti. Le ore si distribuiscono di solito in questo modo. Una fase di analisi, in cui l'agenzia legge il catalogo, i flussi di pagamento e spedizione e gli strumenti che deve collegare. Una fase di design, sempre più spesso fatta a livello di sezione anziché di pagina intera, così che quello che approva sia esattamente quello che il tema editor mostrerà. Lo sviluppo del tema su Online Store 2.0, con template JSON e sezioni che il suo team potrà modificare senza chiamare nessuno. La configurazione: pagamenti (PayPal, Satispay, carte tramite Shopify Payments), spedizioni, IVA, Shopify Markets se vende anche fuori dall'Italia. I test su dispositivi reali, il lancio con DNS e redirect, e un periodo di supporto post-lancio che nei listini pubblicati è di 30 giorni. Quello che non sta comprando, e che spesso genera malintesi, è la piattaforma. Il piano Shopify, il dominio, le app a canone e le commissioni sui pagamenti sono contratti tra lei e i rispettivi fornitori. Un'agenzia che li include nel proprio prezzo li sta semplicemente rifatturando, e conviene saperlo. ## Tema configurato, tema personalizzato o sviluppo su misura La scelta del livello di intervento è la decisione che sposta di più il preventivo, e vale la pena capirla prima di chiedere offerte. **Tema configurato.** Un tema gratuito o premium installato e riempito di contenuti, senza codice. Sotto i 1.000 $ si compra quasi sempre questo, spesso da un freelance. Funziona bene per cataloghi piccoli e brand che possono adattarsi a ciò che il tema offre. Il limite è che ogni deviazione dal tema diventa un'app in più o un compromesso. **Tema personalizzato.** Un tema esistente a cui l'agenzia aggiunge sezioni, template di landing page e miglioramenti alla pagina prodotto, costruiti come file separati così che gli aggiornamenti del tema restino sicuri. Parte da 1.000 $ e si ferma di solito sotto i 3.000 $. È la scelta giusta quando un tema premium copre l'80% delle esigenze e manca solo il 20% che conta per la conversione. **Sviluppo su misura.** Un tema costruito da zero su Online Store 2.0, con architettura, sezioni e template pensati sul suo catalogo. Parte da 2.000 $ e arriva a 8.000 $ per i casi con molte integrazioni. Ha senso quando il flusso di acquisto è particolare (configuratori, B2B con listini, prodotti su misura) o quando il brand ha un design system che nessun tema riesce a rispettare. **Headless.** Una vetrina separata, costruita con Hydrogen o Next.js, che parla con Shopify tramite API. Parte da 5.000 $ e sale rapidamente. È quasi sempre la scelta sbagliata sotto una certa soglia di fatturato, e ne parliamo a parte in [Shopify headless con Hydrogen: quando conviene](/it/shopify-headless-con-hydrogen-quando-conviene). Il confronto dettagliato tra tema e custom, con i criteri per decidere, è in [Shopify theme vs custom](/shopify-theme-vs-custom). ## Le tre variabili che muovono il preventivo Il catalogo, le integrazioni e la quota di design su misura spiegano quasi tutta la differenza tra un preventivo da 2.000 $ e uno da 8.000 $. **Il catalogo.** Non conta solo il numero di prodotti, conta la qualità dei dati. Cento prodotti con varianti pulite, immagini nominate e descrizioni pronte costano meno da importare di trenta prodotti con dati sparsi in tre fogli Excel e foto da rinominare. Se arriva da WooCommerce, i campi personalizzati (attributi, ACF, dati tecnici) vanno mappati in metafield, ed è lavoro a ore. **Le integrazioni.** Ogni sistema esterno è una riga di preventivo. Per un merchant italiano le più frequenti sono il gestionale o il software di fatturazione elettronica (la trasmissione allo SDI passa da app o gestionali di terze parti, Shopify non la fa nativamente), il corriere o la piattaforma di spedizione, e i marketplace. Una singola integrazione ben fatta parte da 1.500 $; il collegamento a un'app già esistente sull'App Store costa molto meno perché è configurazione, non sviluppo. Il tema è approfondito in [Shopify e fatturazione elettronica in Italia](/it/shopify-fatturazione-elettronica-italia-come-metterla-norma). **La quota di design su misura.** Ogni sezione disegnata da zero costa design più sviluppo più test. Un negozio con sei sezioni personalizzate e il resto da tema costa una frazione di uno con venti. La domanda utile da farsi non è "cosa vorrei" ma "cosa cambia il tasso di conversione", e un'agenzia onesta dovrebbe aiutarla a togliere sezioni dal brief, non ad aggiungerne. ## I costi che non stanno nel preventivo Il preventivo dell'agenzia è una parte della spesa, e chi lo confronta con il budget totale senza aggiungere il resto si trova con una sorpresa a metà progetto. **Il piano Shopify.** Si paga a Shopify, in fatturazione mensile o annuale. Per i piani base si tratta di poche decine di euro al mese; Shopify Plus al momento della stesura parte da circa 2.300 USD al mese con contratto triennale, e diventa una discussione seria solo sopra un certo volume o quando servono funzioni di checkout riservate a Plus. **Le app a canone.** Fatturazione elettronica, recensioni, bundle, spedizioni, email marketing: ognuna ha un canone mensile, e la somma cresce in fretta. Un'agenzia che le consiglia di rimuovere app anziché aggiungerle sta facendo il suo interesse; su questo punto legga [quante app Shopify sono troppe](/how-many-shopify-apps-is-too-many). **Le commissioni sui pagamenti.** Shopify Payments, PayPal e Satispay applicano commissioni per transazione. Non sono un costo dell'agenzia ma incidono sul margine e vanno messe nel conto. **Contenuti e fotografie.** Le agenzie di sviluppo di norma non scrivono le schede prodotto né scattano le foto. Se ha bisogno di entrambe, sono voci separate o fornitori separati. **L'IVA sulla fattura dell'agenzia.** Se l'agenzia ha sede fuori dall'Unione Europea, la prestazione di servizi verso un'impresa italiana rientra di norma nel reverse charge: la fattura arriva senza IVA e l'IVA la integra lei in contabilità. Non è un costo aggiuntivo, ma è un adempimento che il suo commercialista deve conoscere prima della prima fattura. ## Perché un'agenzia in India costa meno, e cosa verificare Il costo orario riflette il costo del lavoro locale, non la qualità del codice. Un'agenzia con sede in India che lavora con merchant internazionali può proporre gli stessi stack (Online Store 2.0, Checkout Extensibility, Shopify Functions, Hydrogen) a un prezzo orario più basso, e questo è il motivo principale per cui i listini in dollari citati qui sono quelli che sono. Quello che cambia davvero, e che va verificato prima di firmare, è altro. La sovrapposizione di orario: tra l'Italia e l'India ci sono tre ore e mezza o quattro e mezza di differenza a seconda della stagione, e questo per un progetto con demo settimanali è gestibile, per un'emergenza alle 18 di un venerdì lo è meno. La lingua dei contenuti: il codice non ha lingua, ma le etichette del checkout, le email transazionali e le pagine legali devono essere in italiano corretto, e va chiarito chi le scrive. Gli adempimenti italiani: nessuna agenzia estera invierà le sue fatture allo SDI, e nemmeno una italiana lo farà a mano; serve un'app o un gestionale, e l'agenzia deve saperlo configurare. Il confronto tra costi di agenzie in India, USA ed Europa è trattato in [Shopify agency India vs USA cost](/shopify-agency-india-usa-cost). Le domande da fare a qualsiasi agenzia, italiana o estera, sono in [come scegliere un'agenzia Shopify](/it/come-scegliere-agenzia-shopify-12-domande-da-fare). ## Come leggere un preventivo senza farsi sorprendere Un preventivo confrontabile ha voci separate, e ogni voce risponde a una domanda precisa. Se riceve una cifra sola, chieda di scomporla prima di confrontarla con le altre. ## Cosa deve essere scritto nel preventivo - Voci separate per analisi, design, sviluppo del tema, configurazione, migrazione dei dati e lancio - Numero di revisioni incluse per fase e costo delle revisioni aggiuntive - Cosa succede alle richieste di modifica a metà progetto e come vengono quotate - Chi possiede il codice e i file di design alla consegna - Quali app a canone vengono installate e quanto costano al mese - Durata e contenuto del supporto post-lancio - Costo e contenuto della manutenzione dopo il periodo di supporto - Tempi di risposta garantiti per un negozio fermo L'ultimo punto è quello che i merchant dimenticano più spesso. Un negozio che vende è un negozio che prima o poi si rompe alle 19 di un sabato di dicembre, e il preventivo dovrebbe dire chi risponde e in quanto tempo. ## La manutenzione decide il costo totale Su tre anni, la manutenzione supera quasi sempre il costo di lancio, ed è la voce che meno agenzie mettono nel primo preventivo. Faccia il conto con i listini pubblicati. Un negozio da 5.000 $ di sviluppo più 500 $ al mese di manutenzione per 36 mesi fa 23.000 $, di cui il lancio è meno di un quarto. Anche a un canone più basso o con una manutenzione a chiamata, la proporzione non cambia molto, perché Shopify rilascia continuamente e ritira le versioni delle API su un calendario pubblicato. Tutto ciò che è personalizzato (tema, Functions, integrazioni) va aggiornato, e chi non lo aggiorna scopre il problema quando una funzione smette di rispondere. Il retainer di manutenzione ha senso perché sostituisce interventi d'urgenza con un team che conosce già il negozio. Se il suo team interno sa fare le modifiche di routine e ha qualcuno che legge il codice, può ridurre il canone al solo monitoraggio. Se non c'è nessuno, il retainer è il costo di avere qualcuno reperibile. Il meccanismo delle versioni API è spiegato in [Shopify API versioning](/shopify-api-versioning). ## Quando conviene spendere di più Spendere di più conviene quando il costo aggiuntivo compra un ricavo o un risparmio misurabile, e in tre casi succede quasi sempre. Quando le integrazioni sostituiscono lavoro manuale. Se oggi qualcuno copia gli ordini nel gestionale a mano ogni giorno, un'integrazione da 1.500 $ si ripaga in mesi di ore risparmiate e di errori evitati, e questo prima di considerare la fatturazione elettronica. Quando il negozio vende già. Un'ottimizzazione della velocità da 750 $ o un intervento di conversione da 1.500 $ su un negozio con traffico a pagamento ha un ritorno che si misura in settimane; lo stesso lavoro su un negozio senza traffico è prematuro. Quando vende in più mercati. Shopify Markets gestisce valute, domini localizzati e prezzi per mercato, ma configurarlo bene con traduzioni, IVA per paese e spedizioni è lavoro che vale la pena far fare bene una volta sola. Spendere di più non conviene quando compra complessità. Headless per un catalogo da cento prodotti, un'app su misura per una funzione che esiste già sull'App Store, venti sezioni personalizzate su una home page che nessuno scorre fino in fondo. Un'agenzia che le dice di no a queste richieste sta esercitando il giudizio che lei le sta pagando. **Vuole un preventivo con le voci separate?** ByteInfy pubblica i prezzi di partenza per ogni servizio e quota a voce chiusa dopo una chiamata di scoping, dicendole prima quando un tema o un'app esistente costano meno di uno sviluppo. [Parla con ByteInfy](https://byteinfy.com/contact) ## FAQ ### Quanto costa far realizzare un negozio Shopify a un'agenzia? Per un negozio nuovo su Online Store 2.0 le cifre di partenza pubblicate sono di 2.000 $, con una fascia tipica tra 2.000 e 8.000 $ a seconda di catalogo, integrazioni e sezioni personalizzate. ### Quanto costa Shopify al mese, oltre all'agenzia? Il piano si paga direttamente a Shopify e va da poche decine di euro al mese per i piani base fino a Shopify Plus, che al momento della stesura parte da circa 2. ### Un'agenzia italiana costa più di una estera? Di norma sì, perché il costo orario riflette il costo del lavoro locale. ### Cosa deve contenere un preventivo Shopify serio? Voci separate per analisi, design, sviluppo, configurazione, migrazione dei dati e lancio; il numero di revisioni incluse; chi possiede il codice; cosa succede dopo il lancio e a quale costo. ### Conviene un tema pronto o uno sviluppo su misura? Se un tema premium copre l'80% delle sue esigenze, personalizzarlo costa meno e si aggiorna più facilmente. ### La fatturazione elettronica è inclusa nel costo del negozio? Quasi mai come sviluppo, perché Shopify non invia fatture allo SDI in modo nativo e la trasmissione passa da app o gestionali di terze parti a canone. ### Quanto costa mantenere un negozio Shopify dopo il lancio? I retainer di manutenzione pubblicati partono da 500 $ al mese per monitoraggio e cinque ore di sviluppo. --- --- title: "Best Shopify COD Apps for Indian Stores in 2026" description: "Every COD app lists the same features. The one that matters is which cause of RTO it actually addresses, because verification and commitment are different problems." author: "Aashish Kaushik" published: 2026-10-05T13:01:29.199Z updated: 2026-10-05T13:01:29.204Z url: https://blog.byteinfy.com/best-shopify-cod-apps --- # Best Shopify COD Apps for Indian Stores in 2026 ## Key takeaways - RTO has distinct causes, and apps address different ones — verification removes uncontactable buyers, prepayment removes uncommitted ones. - A COD app that only blocks orders is the weakest category, because blocking removes revenue rather than converting it. - Test that the app's checks survive accelerated checkout, since anything applied by cart manipulation can be bypassed entirely. - Judge on delivered revenue net of RTO cost, never on conversion rate, or you will reject the interventions that worked. COD apps are difficult to compare because they all list the same capabilities: OTP verification, COD blocking, partial payment, order confirmation, risk scoring. The feature grids are nearly identical. The useful question is not which features an app has but which cause of RTO it addresses, because RTO is not one problem. An app that solves the cause you do not have will not help you, and you will conclude COD apps do not work. > **On specifics** > > Ratings, pricing and features in this category change frequently, and much of the available comparison content is published by COD app vendors. Nothing here ranks products; check current listings and trial before committing. ## RTO has several causes and they need different fixes Before evaluating any app, work out which of these dominates for you. The data is in your own delivery outcomes. **Uncontactable buyers.** A mistyped number, a number entered to get past a form, an order placed and forgotten. The courier cannot reach anyone. This is usually the largest single bucket. **Uncommitted buyers.** Reachable, remembers ordering, and declines at the door. Nothing was at stake, so declining costs them nothing. **Address and coverage problems.** Incomplete addresses, pincodes with poor courier coverage, deliveries attempted when nobody is home. **Buyer's remorse.** More common at higher cart values and in categories with fit or sizing uncertainty. **Duplicate and impulse ordering.** The same person ordering several times over, or ordering late at night and reconsidering in the morning. ## Cause and the mechanism that addresses it | Cause | What fixes it | What does not | | --- | --- | --- | | Uncontactable buyer | OTP verification | Partial payment, blocking | | Uncommitted buyer | Partial payment, COD fee | OTP verification | | Address or coverage | Address validation, pincode rules | Verification of any kind | | Buyer's remorse | Partial payment, better product info | OTP verification | | Duplicate or impulse | Pre-dispatch confirmation | Blocking | That table is the actual buying guide. Measure your own outcomes, identify which rows describe your losses, and evaluate apps on whether they implement the corresponding mechanism well. A store losing mostly to uncontactable buyers and a store losing mostly to remorse need different products, and no feature grid will tell you which you are. ## The four things a COD app can do **Verification.** OTP by SMS or WhatsApp before the order is placed. Addresses the largest bucket directly. Implementation quality varies mainly on speed of delivery and whether the step happens inline or sends the shopper elsewhere — a slow OTP is where genuine buyers abandon. **Partial prepayment.** Collect a portion online, the balance on delivery. Works behaviourally rather than financially: the amount barely reduces exposure, but it converts a free option into a decision. **Rules and restrictions.** Restrict or price COD by pincode, cart value, product, or customer history. The valuable version is targeted; the crude version is a blanket switch. **Pre-dispatch confirmation.** Message the buyer to confirm or cancel before the parcel ships. A cancellation here costs only the picking, which makes it the cheapest possible save. An app doing only the third of these is the weakest option, because blocking removes revenue rather than converting it. Restriction is a useful component of a strategy and a poor strategy on its own, and apps that lead with it are usually the cheapest for a reason. ## The technical questions that eliminate candidates Feature lists will not distinguish these. Ask directly and test. ## Before committing to a COD app - How is the check applied — at the platform level, or by manipulating the cart? - Does it hold through Shop Pay, Apple Pay and Google Pay? - How fast does the OTP actually arrive, on a real Indian mobile network? - Does WhatsApp delivery work, and what is the fallback when it does not? - Can rules be scoped by pincode, cart value and customer history independently? - Does the app expose delivery outcomes back into its own rules over time? - What page weight does it add, and does it load on pages with no COD decision? The accelerated checkout question is the one that eliminates the most candidates. Anything implemented by cart manipulation can be bypassed entirely when a shopper uses a wallet button, which means your verification simply does not run on a growing share of orders. Complete a real order through each accelerated method during the trial. ## Measure it correctly or you will draw the wrong conclusion This is where most COD app evaluations go wrong, and the error is systematic rather than occasional. Merchants install an app, see conversion fall, and uninstall it. But conversion falling is the intervention working — it removed orders that would have been rejected. Judging on conversion rate guarantees you reject every effective intervention. The metric is delivered revenue net of RTO cost, per visitor. It captures both the orders you did not take and the parcels you did not send back twice. A defensible evaluation: 1. Baseline before installing. RTO rate and delivered contribution margin, broken down by pincode and cart value band. 2. Enable one mechanism, narrowly, on the highest-risk segment. 3. Wait weeks, not days. RTO is only visible after the full delivery cycle completes, so early numbers are meaningless. 4. Compare delivered margin, not order count. 5. Widen or narrow on the evidence. > **Do not enable everything at once** > > Turning on OTP, partial payment and pincode rules simultaneously tells you nothing about which one worked, and leaves you unable to relax the one that is costing you most. Introduce them one at a time, in order of expected impact. ## Where the friction should sit in the flow Two apps can implement the same mechanism and produce very different conversion outcomes, purely through where in the journey the friction lands. **Before the order is placed** is where verification belongs. An OTP step at checkout removes the bad order before it exists, which is the cheapest possible point. The cost is that some genuine buyers abandon at the step. **Immediately after the order** is where confirmation belongs. The order exists, nothing has shipped, and a message asking the buyer to confirm converts a doubtful order into either a certain one or a free cancellation. This is the highest-return message most COD merchants can send and the one most commonly not sent at all. **Before dispatch** is the last cheap point. After this, every intervention costs you shipping in at least one direction. **After a failed attempt** is expensive but not worthless. A message offering a reschedule or an address correction is worth more than a second blind delivery attempt, which usually fails for the same reason the first one did. The design principle is to push friction as early as possible and information as late as necessary. An app that only intervenes after dispatch is working at the expensive end of the problem, however well it does it. > **Speed is a feature here** > > The one implementation detail that most affects OTP conversion is how fast the code arrives. A code that takes twenty seconds loses genuine buyers who assume it is broken. When trialling, test on a real Indian mobile network at a busy time of day, not on office wifi — and test WhatsApp and SMS separately, because they behave differently. ## What to do before installing anything A surprising amount of RTO reduction is available without an app at all, and doing it first means you evaluate the app against a cleaner baseline. **Fix your address form.** Many RTO cases begin with an incomplete address that a better form would have caught. Required fields, pincode validation and a landmark field cost nothing. **Set delivery expectations on the product page.** A buyer who knows when the parcel arrives and what they will owe is far more likely to be there with the cash. **Send a confirmation message manually** for a fortnight and see how many cancellations it produces. That number tells you what a confirmation feature is worth to you before you pay for one. **Export and analyse your delivery outcomes.** RTO by pincode, by cart value, by category. This is the single most valuable hour available, because it tells you which app category you need and whether the problem is as large as you assume. ## Cost, and what it should be measured against COD apps charge monthly, sometimes with per-verification costs for SMS or WhatsApp messages. The comparison that matters is not app cost against app cost. It is app cost against the cost of the RTO parcels it prevents — forward shipping, return shipping, packaging, handling at both ends, tied-up capital and inventory opportunity cost. Put a real number on one RTO incident for your operation. Most merchants who do this find the app pays for itself at a surprisingly low volume of prevented returns, which reframes the pricing question entirely and usually settles it. For the full RTO picture and the interventions in sequence, see [checkout and payments](/category/checkout-payments). App selection generally is covered in [Shopify apps](/category/shopify-apps). **OTP, partial payment and COD rules in one app** ByteInfy's COD & Part Payment app adds OTP verification via SMS or WhatsApp, partial prepayment at checkout, and smart COD blocking by pincode, product or cart value. [See it on the Shopify App Store](https://apps.shopify.com/byteinfy-cod-partial-pay) ## FAQ ### What does a COD app actually do? The useful ones do one or more of four things — verify the buyer is contactable, usually by OTP; collect a partial prepayment to create commitment; apply rules that restrict or price COD by pincode, cart value or history; and message the buyer before dispatch so they can confirm or cancel. ### Do COD verification apps reduce conversion? Yes, somewhat, and that is the mechanism working. The orders removed are disproportionately those that would have been rejected at delivery. ### Is OTP verification or partial payment more effective? They address different causes and compound rather than overlap. OTP removes orders placed with an unreachable number. Partial payment removes orders from buyers who never committed. ### Can these apps work with Shop Pay and other accelerated checkouts? This is the question to test explicitly. Anything implemented by manipulating the cart can be bypassed when a shopper uses an accelerated checkout button. ### Should I just block COD on risky orders? Rarely as a first response. Blocking removes the order and its revenue entirely, and in a COD-majority market that is a large cost to solve a problem concentrated in a small share of orders. --- --- title: "Shopify Plus en España: cuándo pasar y qué hace una agencia Plus" description: "Shopify Plus parte de unos 2.300 dólares al mes con contrato de tres años, y compensa cuando el volumen, el checkout o el B2B lo justifican, no cuando la tienda simplemente va bien. Este artículo explica qué desbloquea Plus, qué no resuelve por sí solo en España y qué hace de verdad una agencia en un proyecto Plus." author: "Aashish Kaushik" published: 2026-10-05T05:01:00.480Z updated: 2026-10-05T05:01:00.486Z url: https://blog.byteinfy.com/shopify-plus-espana-cuando-pasar-que-hace-una --- # Shopify Plus en España: cuándo pasar y qué hace una agencia Plus ## Key takeaways - Shopify Plus parte de aproximadamente 2.300 dólares al mes con contrato de tres años en el momento de escribir; frente a Advanced, el salto se paga con menores comisiones a volumen alto, checkout más personalizable, B2B nativo y tiendas de expansión. - Las señales de que ha llegado el momento son concretas, comisiones de pago que superan la diferencia de cuota, reglas de checkout que Advanced no permite, venta B2B con catálogos y condiciones por cliente, o varias tiendas por país o marca. - Plus no resuelve por sí mismo Bizum, el IVA con la OSS, la facturación española ni los transportistas; eso se configura igual en cualquier plan, y una agencia que conozca España lo pone en el alcance desde el principio. - Una agencia en un proyecto Plus hace tres cosas, planificar la migración de plan sin cortar ventas, construir las Functions y extensiones de checkout que justifican el cambio, y dejar al equipo del comerciante operando sin ella. Shopify Plus compensa cuando el volumen, el checkout o el B2B lo justifican, no cuando la tienda simplemente va bien. Parte de aproximadamente 2.300 dólares al mes con contrato de tres años en el momento de escribir, y el error más habitual entre comerciantes españoles es pasarse a Plus por prestigio o por una recomendación genérica y descubrir que lo que necesitaban estaba disponible en Advanced. Este artículo explica qué es Plus y qué cuesta, qué desbloquea frente a Advanced, las señales de que ha llegado el momento y las de que todavía no, lo que Plus no resuelve por sí mismo en España (Bizum, IVA, facturación, envíos), qué hace de verdad una agencia en un proyecto Plus y cómo preparar el cambio de plan sin cortar ventas. Está pensado para tiendas en España que facturan lo suficiente como para que alguien les haya propuesto Plus, y para responsables de ecommerce en Latinoamérica que se hacen la misma pregunta con otra moneda. ## Qué es Shopify Plus y qué cuesta Shopify Plus es el plan de Shopify para tiendas de gran volumen, y su diferencia con los planes estándar no es la plataforma sino el contrato, las comisiones y un conjunto de funciones que solo existen ahí. La plataforma es la misma. Un comerciante Plus usa el mismo panel, los mismos temas, las mismas apps y el mismo checkout que uno en Advanced. Lo que cambia es que Plus se contrata con un compromiso de duración, que en el momento de escribir parte de unos 2.300 dólares al mes con contrato de tres años (la cuota es mayor con contrato de un año, y por encima de cierto volumen pasa a un porcentaje de la facturación), que las comisiones de Shopify Payments son más bajas, y que se accede a funciones que los planes estándar no tienen. Shopify factura en varias monedas según el país, así que un comerciante español puede ver la cuota en euros. La cifra cambia con cierta frecuencia y ha subido en los últimos años, de modo que la referencia válida es la página oficial de precios de Shopify Plus en el momento de contratar, no este artículo. Para una comparación de cómo se traduce esa cuota en otro mercado, el artículo sobre [precios de Shopify Plus en India](/shopify-plus-pricing-india) sigue la misma lógica con otra moneda. A la cuota se suma lo de siempre: apps, tema, comisiones de pasarela y, en un proyecto Plus, el trabajo de agencia para construir lo que justifica el cambio. Ese trabajo es la parte del coste que este artículo intenta hacer visible. ## Qué desbloquea Plus frente a Advanced Las diferencias entre Advanced y Plus son concretas, y conviene tenerlas delante antes de decidir, porque varias de las que se citan como exclusivas de Plus han dejado de serlo. ## Advanced frente a Plus, en el momento de escribir | Capacidad | Advanced | Plus | | --- | --- | --- | | Cuota mensual | Fija, publicada por país | Desde unos 2.300 $ al mes con contrato de 3 años | | Comisiones de Shopify Payments | Tarifa estándar del plan | Más bajas, negociables a volumen | | Extensiones de checkout (información y envío) | Sí | Sí | | Personalización del paso de pago y marca del checkout | Limitada | Completa | | Shopify Functions (descuentos, envío, validación) | La mayoría | Todas, incluidas las que requieren Plus | | B2B nativo (catálogos, precios y condiciones por empresa) | No | Sí | | Tiendas de expansión (varias tiendas bajo un contrato) | No | Sí, con un número incluido | | Shopify Flow (automatizaciones) | Sí | Sí | | Límites de API y de personal | Estándar | Más altos | | Soporte | Estándar | Prioritario, con gestor de cuenta en algunos casos | Tres observaciones sobre esa tabla. Primero, Shopify Flow y las extensiones de checkout para los pasos de información y envío están en todos los planes desde hace tiempo; si alguien le vende Plus "para poder personalizar el checkout", pregunte qué personalización concreta y si de verdad requiere Plus. Segundo, el B2B nativo es probablemente la función más decisiva para quien vende a empresas: catálogos por cliente, precios negociados, condiciones de pago y pedidos con aprobación sin apps de terceros. Tercero, las tiendas de expansión son lo que hace Plus interesante para grupos con varias marcas o varios países que no caben en Shopify Markets. Lo que ya no está en ninguna columna es Scripts. Era la herramienta exclusiva de Plus para escribir reglas de descuento y checkout, está retirada, y los comerciantes Plus tuvieron que migrar a Shopify Functions. Si hereda una tienda Plus con años de historia, lo primero es comprobar que no queda lógica de Scripts sin migrar. El artículo sobre [migrar de Scripts a Functions](/shopify-scripts-to-functions) explica cómo se hace, y el de [descuentos personalizados con Shopify Functions](/es/descuentos-personalizados-con-shopify-functions-adios) qué se puede construir hoy. ## Las señales de que ha llegado el momento Hay cuatro situaciones que justifican Plus por sí solas, y se reconocen con números, no con sensaciones. **Las comisiones superan la diferencia de cuota.** Calcule lo que paga hoy en comisiones de Shopify Payments a su volumen actual y lo que pagaría con la tarifa Plus. Si el ahorro anual se acerca o supera la diferencia de cuota entre Advanced y Plus, el cambio se paga solo y todo lo demás es ganancia. Este cálculo es el primero que debe hacer, y una agencia seria lo hace con usted antes de proponer nada. **El checkout necesita reglas que Advanced no permite.** Ocultar o reordenar métodos de pago según el cliente o el carrito, personalizar el paso de pago, aplicar lógica de descuentos o validación que solo está disponible en Plus. Si su equipo ya ha chocado con "esto requiere Shopify Plus" al intentar configurar algo concreto, esa es una señal directa. El artículo sobre [Checkout Extensibility](/shopify-checkout-extensibility) detalla qué está en cada plan. **Vende a empresas con condiciones distintas por cliente.** Precios negociados, catálogos restringidos, pago a 30 o 60 días, pedidos con aprobación. Hacerlo con apps en Advanced es posible y frágil; en Plus es nativo, y para distribuidores, mayoristas y marcas con canal profesional suele ser la razón principal. **Necesita varias tiendas bajo una misma gestión.** Marcas distintas, países con catálogos o condiciones legales distintas que Shopify Markets no cubre, o una tienda de outlet separada. Las tiendas de expansión de Plus lo permiten bajo un contrato, con usuarios y facturación unificados. Si se da una de estas cuatro con claridad, Plus es una decisión de negocio y no de prestigio, y el resto del artículo trata de hacerla bien. ## Las señales de que todavía no Hay razones por las que se propone Plus que no lo justifican, y son más frecuentes que las buenas. **"La tienda va bien y toca crecer."** Crecer no requiere Plus. Advanced aguanta volúmenes altos sin problema, y lo que limita una tienda que crece suelen ser el tema, las apps y la operación, no el plan. Si la tienda va bien, invierta en velocidad, en conversión y en contenido antes que en cuota. **"Para tener mejor soporte."** El soporte prioritario de Plus existe, pero una tienda bien construida y documentada necesita poco soporte de Shopify, y el que necesita lo cubre mejor una agencia o un retainer que conoce su tienda. **"Para personalizar el checkout."** Ya se ha dicho: las extensiones de checkout y la mayoría de Functions están en todos los planes. Compruebe qué personalización concreta necesita y en qué plan está disponible antes de aceptar que "requiere Plus". **"Porque lo recomienda la agencia."** Un proyecto Plus es más grande y más rentable para quien lo hace. Pida el cálculo de comisiones y la lista de funciones exclusivas que va a usar, con nombre. Si no las hay, la recomendación no es para usted. **Antes de agotar Markets.** Si el motivo es vender en Portugal, Francia o México con precios y dominios locales, Shopify Markets lo resuelve desde Advanced con multimoneda y dominios o subcarpetas por país. Plus se justifica cuando necesita tiendas separadas de verdad, no cuando necesita vender en más sitios. > **Una prueba rápida** > > Escriba en una hoja las funciones exclusivas de Plus que usaría en los primeros seis meses, con nombre (B2B nativo, tiendas de expansión, una personalización concreta del paso de pago). Añada el ahorro anual en comisiones a su volumen actual. Si la hoja tiene menos de dos funciones y el ahorro no cubre la diferencia de cuota, la respuesta es Advanced más una buena agencia, y volver a mirarlo dentro de un año. ## Lo que Plus no resuelve por sí mismo en España Una tienda española tiene un conjunto de requisitos que no dependen del plan, y Plus no los configura solo. Una agencia que conozca el mercado los pone en el alcance desde el principio; una que no, los descubre después. **Bizum.** No está en Shopify Payments; se ofrece a través de pasarelas compatibles con sus propias tarifas y su propia integración. Funciona igual en Plus que en Advanced, y en un proyecto Plus con checkout personalizado hay que comprobar que la pasarela y las Functions de pago conviven bien. **IVA, OSS e inversión del sujeto pasivo.** Los tipos de IVA por producto y por país, la ventanilla única (OSS) si vende a consumidores de otros países de la Unión Europea, y el tratamiento de las ventas a empresas de otros Estados miembros se configuran en los ajustes de impuestos de Shopify y, en B2B, en las condiciones de cada empresa. Plus añade el B2B nativo, pero la configuración fiscal correcta es trabajo de su asesor y de la agencia, no del plan. **Facturación conforme a la normativa española.** Shopify genera confirmaciones de pedido, no facturas con los requisitos legales españoles. Hace falta una app o una integración con su programa de facturación, y en B2B, la factura por cliente con sus datos fiscales. Es una partida del proyecto en cualquier plan. **Transportistas y envíos.** Correos, SEUR, MRW, GLS, puntos de recogida, envíos a Canarias con su régimen fiscal propio. Se resuelve con apps de envío y, cuando las reglas son complejas, con Functions de envío que funcionan en todos los planes. El artículo sobre [Shopify en España: Bizum, IVA y envíos](/es/shopify-espana-bizum-iva-envios) recorre cada uno de estos puntos con más detalle, y aplica igual antes y después de pasar a Plus. ## Qué hace una agencia en un proyecto Plus Una agencia en un proyecto Plus hace tres cosas, y ninguna es "activar el plan". **Planificar el cambio sin cortar ventas.** Pasar a Plus es un cambio de contrato y de configuración sobre la misma tienda, no una migración de plataforma, pero en una tienda con checkout personalizado, B2B o varias tiendas hay un orden: qué se construye antes del cambio, qué se activa el día del cambio y qué se revisa después. La agencia escribe ese plan y lo ejecuta en una ventana de poco tráfico. **Construir lo que justifica el cambio.** Si el motivo era el checkout, la agencia construye las extensiones de checkout y las Shopify Functions para descuentos, reglas de envío y personalizaciones de pago, y una interfaz para que su equipo cambie las reglas sin desarrollador. Si era B2B, configura empresas, catálogos, listas de precios y condiciones, e integra la facturación por cliente. Si eran tiendas de expansión, monta cada tienda con su tema, sus impuestos, sus transportistas y su sincronización de catálogo y stock. Una Function o extensión de checkout parte de 1.500 dólares en el [servicio de extensiones de checkout y Functions de ByteInfy](https://byteinfy.com/services/shopify-checkout-extensions), en el momento de escribir, y los programas completos de checkout se presupuestan juntos. **Dejar al equipo del comerciante operando sin la agencia.** Documentación de cada Function y cada regla, formación del equipo en el panel de B2B o de tiendas de expansión, y un retainer opcional para deprecaciones y cambios. Un proyecto Plus que termina con el comerciante dependiendo de la agencia para cambiar una regla de descuento ha convertido un coste único en uno permanente. Lo que una agencia no hace, y conviene que quede claro, es negociar la cuota con Shopify por usted ni garantizar que Plus le salga a cuenta. La primera conversación es con Shopify; la segunda, con la agencia, y una agencia honesta le dirá en esa segunda conversación si el cálculo no sale. ## Cómo preparar el cambio de plan Un cambio a Plus se prepara con la misma disciplina que una migración, aunque la tienda sea la misma. ## Antes de activar Shopify Plus - El cálculo de comisiones a su volumen actual está hecho y comparado con la diferencia de cuota - La lista de funciones exclusivas de Plus que usará en seis meses está escrita, con nombre - Las condiciones del contrato (duración, cuota, porcentaje sobre facturación si aplica, moneda) están revisadas por quien firma - El inventario de apps está revisado y se sabe cuáles se sustituirán por funciones nativas de Plus (B2B, por ejemplo) - Las Functions y extensiones de checkout están construidas y probadas en una tienda de desarrollo antes del cambio - Si hay Scripts heredados, están migrados a Functions y probados con pedidos de prueba - Bizum, IVA, OSS, facturación y transportistas están configurados y probados con cada método de pago - Si hay tiendas de expansión, el plan de sincronización de catálogo y stock entre tiendas está definido - Analítica y conversiones están verificadas en el checkout nuevo, porque las extensiones pueden alterar el seguimiento - Hay una ventana de cambio en horario de poco tráfico y una persona revisando pedidos las primeras horas El punto que más se olvida es el de la analítica. Un checkout con extensiones y Functions nuevas puede cambiar cómo se disparan los eventos de compra, y descubrir a las tres semanas que Google Ads o Meta llevan sin recibir conversiones es una forma cara de estrenar Plus. Pruebe cada método de pago con un pedido real y compruebe que aparece en cada herramienta. El segundo es el contrato. Un compromiso de tres años a una cuota que puede pasar a porcentaje sobre facturación merece que lo lea quien firma, con las proyecciones de ventas delante. Un contrato de un año cuesta más al mes pero deja margen si el cálculo no sale. ## Cuánto cuesta el trabajo de agencia en un proyecto Plus El trabajo de agencia en un proyecto Plus se presupuesta por partidas, y las partidas dependen del motivo del cambio. Un proyecto cuyo motivo es el checkout tiene como partidas principales las Functions y extensiones (desde 1.500 dólares cada una, o un programa presupuestado en conjunto), la interfaz de configuración para su equipo y las pruebas con cada método de pago. Un proyecto cuyo motivo es el B2B añade la configuración de empresas y catálogos, la integración de facturación por cliente y, casi siempre, una integración con el ERP o el programa de gestión, que en la [página de servicios de ByteInfy](https://byteinfy.com/services) parte de 1.500 dólares por sistema. Un proyecto de tiendas de expansión multiplica la partida de tienda (desde 2.000 dólares cada una en Online Store 2.0) por el número de tiendas y añade la sincronización. Lo que ninguna de esas partidas incluye es el mantenimiento, y en Plus es más relevante que en otros planes porque hay más lógica a medida que puede romperse con una deprecación. Un retainer parte de 500 dólares al mes; sin él, el coste aparece igual, en forma de urgencias. Para situar todo esto dentro del presupuesto general, el artículo sobre [cuánto cuesta una tienda hecha por una agencia](/es/agencia-shopify-cuanto-cuesta-una-tienda-2027-precios) recorre las bandas de cada servicio. ## Cómo elegir la agencia para un proyecto Plus Las preguntas para elegir una agencia Plus son las mismas que para cualquier proyecto Shopify, con tres añadidos. Pregunte por un proyecto Plus concreto que hicieran hace más de un año y qué hubo que tocar desde entonces: si migraron Scripts a Functions, cómo lo hicieron y cuánto costó. Pregunte qué funciones exclusivas de Plus usaría en su caso, con nombre, y si alguna de las que le proponen está en realidad disponible en Advanced. Y pregunte cómo dejarían a su equipo cambiando reglas de descuento, envío y pago sin llamarles. Shopify tiene un programa de partners con una categoría para Plus. Pertenecer a él es una señal de experiencia, no una garantía, y no sustituye a las preguntas. ByteInfy es una agencia con sede en India que trabaja con comerciantes de varios países y construye Functions y extensiones de checkout para tiendas de todos los planes; lo que pide a cada cliente Plus es el cálculo de comisiones y la lista de funciones antes de presupuestar, porque es ahí donde se decide si el proyecto tiene sentido. Las doce preguntas completas, con las respuestas que tranquilizan y las que preocupan, están en [cómo elegir una agencia Shopify](/es/como-elegir-una-agencia-shopify-12-preguntas). **Se plantea Shopify Plus y quiere saber si le sale a cuenta** Envíenos su volumen mensual, las comisiones que paga hoy y lo que necesita en checkout o B2B, y recibirá el cálculo y una lista de lo que requiere Plus y lo que no, antes de cualquier presupuesto. [Hablar con ByteInfy](https://byteinfy.com/contact) ## FAQ ### ¿Cuánto cuesta Shopify Plus en España? En el momento de escribir, Shopify Plus parte de aproximadamente 2. ### ¿A partir de qué facturación compensa Shopify Plus? No hay una cifra única, porque depende de las comisiones que paga hoy y de qué funciones necesita. ### ¿Qué puedo hacer en el checkout con Shopify Plus que no puedo con Advanced? Las extensiones de checkout y la mayoría de Shopify Functions funcionan en todos los planes para los pasos de información y envío. ### ¿Shopify Plus resuelve Bizum, el IVA y la facturación en España? No por sí mismo. ### ¿Qué es una agencia Shopify Plus? Una agencia con experiencia en proyectos sobre el plan Plus: migraciones de plan, Functions y extensiones de checkout, B2B, tiendas de expansión, integraciones con ERP. ### ¿Qué pasó con Shopify Scripts? Scripts era la herramienta exclusiva de Plus para descuentos y reglas de checkout escritas en Ruby. Está retirada, y los comerciantes Plus tuvieron que migrar sus scripts a Shopify Functions. ### ¿Puedo bajar de Shopify Plus si no compensa? Sí, dentro de las condiciones del contrato firmado, que suele tener una duración mínima. --- --- title: "A BFCM Video Campaign for Shopify, Start to Finish" description: "BFCM video fails for two reasons — it gets made too late to test, and it lands on the pages you can least afford to slow down. Both are avoidable in October." author: "Aashish Kaushik" published: 2026-10-04T13:01:15.314Z updated: 2026-10-04T13:01:15.504Z url: https://blog.byteinfy.com/bfcm-video-campaign --- # A BFCM Video Campaign for Shopify, Start to Finish ## Key takeaways - BFCM video must be finished before November, because a clip that lands during peak has no time to be tested or measured. - Existing UGC and Reels are a better starting library than new production, because they exist now and have already been audience-tested. - Video on BFCM landing pages and product pages is expensive in page weight, on the traffic you paid the most to acquire. - Offer-specific video dates itself — make the offer messaging removable without re-editing the clip. BFCM video fails in two predictable ways. It gets commissioned in early November and goes live with no time to test whether it works. And it lands on landing pages and product pages that are receiving the most expensive traffic of your year, adding weight exactly where a slow page costs the most. Both are timing problems, and both are solved in October. > **Scope** > > Making and placing video for the BFCM period. Offer structure, checkout readiness and the wider calendar are covered separately in the series. ## Start with what already exists The instinct is to plan a shoot. For most stores that is the slow, expensive and highest-risk path, particularly under an immovable deadline. You almost certainly already have usable footage: Reels and TikToks you have posted, customer content tagging your products, clips from previous campaigns. That library has two advantages new production cannot match — it exists now, and it has engagement data telling you which clips people actually responded to. Search your brand and product names on TikTok and Instagram, check your tagged mentions, and look at what previous campaigns produced. Most stores find considerably more usable footage than they expected, and much of it from customers they never knew had posted. The rights caveat applies and matters: a creator who agreed to a repost has not agreed to commercial storefront use, and platform music licences do not travel to your website. Clear both before anything goes live, because doing it retrospectively during your busiest week is not a position you want to be in. ## When the existing library is not enough Sometimes the audit in October turns up very little. A newer store, a recent rebrand, or a catalogue of products nobody has posted about yet all leave you with a thin library and a deadline that has not moved. The decision at that point is between stretching what little exists and commissioning something narrow, and the two paths suit different situations. Stretching the existing library works when you have a handful of usable clips and a catalogue where one hero product carries most of the BFCM revenue. Recut what you have into shorter, more targeted pieces, pair it with static product photography for everything else, and accept that not every product will have video this year. This is the faster and cheaper path, and it is the right one for most stores under a hard October deadline. A narrow commissioned shoot makes sense when the gap is on the specific products expected to sell the most during BFCM, and when a phone-shot clip by someone on your team would genuinely be worse than nothing. This does not mean a production crew. A single afternoon with a phone, a tripod and the checklist above covers most of what a BFCM clip needs, and it is achievable inside the October timeline if it is scoped narrowly from the start, to the two or three products that matter most rather than the whole catalogue. What does not work is deciding this in November. A shoot scheduled after the freeze date has no time to be edited, tested and placed before Cyber Week, which puts you back in the timing failure this whole approach exists to avoid. If the October audit shows a real gap, make the shoot-or-skip decision in October, alongside the audit itself, not after watching the calendar run out. The middle option worth naming separately: asking a handful of existing customers for a quick phone clip of the product in use, in exchange for early access to the sale or a small credit. It is slower than reusing what exists and faster than a commissioned shoot, and it produces exactly the kind of unpolished, credible footage that performs well on a product page. ## What to actually make, if you make something If you do commission, be narrow. BFCM is the wrong moment for brand films. The clips that earn their place resolve a doubt on a product you expect to sell heavily: **Fit or scale on a real person**, for anything worn or held. The most reliable conversion video there is. **The product in genuine use**, for anything whose value is not obvious from a photograph. **A quick demonstration** of the thing customers ask about most. Your support inbox will tell you what that is. **What is in the box**, for bundles and gift sets — which are exactly what you are pushing during BFCM and exactly where contents are ambiguous. That last one is underrated. BFCM bundles frequently combine products in ways a shopper has not seen before, and a fifteen-second clip showing what actually arrives removes a real hesitation. ## A BFCM clip that works - Under 30 seconds, and shorter than feels right - Works with the sound off, since most storefront views are muted - Vertical, because most of this traffic is mobile - One question answered, decided before shooting - Scale reference visible — a hand, a person, a stated measurement - No spoken or on-screen discount percentage baked into the footage ## Do not bake the offer into the video The constraint most likely to cost you re-editing time. A clip that says "40% off this weekend" is unusable the moment the offer changes, unusable after the weekend, and dated forever afterwards. Offers change more often than merchants expect — a competitor moves, stock runs short, a threshold gets adjusted in the final planning week. Keep the offer in the layer you can edit without touching the footage: the text overlay your video app renders, the caption, the surrounding page, the badge on the product. The video stays about the product and remains usable in January. This also means one library serves the whole period and the year after it, rather than a set of clips with an expiry date. Merchants who bake the offer in end up re-shooting annually for no reason other than that last year's number is visible in the footage. ## Placement, and its cost Two placements matter during BFCM, and both are expensive. **Product pages**, for clips resolving a specific doubt. Near the gallery, not far down the page. This is where video converts. **The BFCM landing page or homepage**, for discovery-oriented content that shows what is on offer. The problem is that these are precisely the pages receiving traffic you paid a premium to acquire, during the one week every competitor is bidding against you. Video is the heaviest asset you can put on a page. A slow landing page during BFCM is the most expensive slow page you will ever have. The rules are the same as any time of year but the stakes are higher: - A lightweight poster image with width and height set, so nothing shifts. - Player and video file load on interaction, never on page load. - Nothing video-related loading on pages with no video. - Autoplay, if used at all, muted, short, and one element per page. Measure the finished pages on a mid-range phone on a throttled connection, not your desktop on office wifi. The gap between those two experiences is where most of your paid BFCM traffic actually lives. > **Video is a change, and the freeze applies to it** > > Adding video to product pages during Cyber Week is shipping a change into peak with no observation window, on the templates you can least afford to break. Whatever freeze date you set for discount logic should cover anything heavy on your key templates too. ## The timeline **Early October — audit what exists.** Search for existing content, clear rights, and decide whether you need to make anything at all. **Mid October — select and edit.** Trim the hooks, cut for length, add captions, choose poster frames. If you are shooting, this is when it happens. **Late October — place and measure.** Video live on a subset of products. Measure Core Web Vitals before and after. This is the week that tells you whether the implementation is sound. **Early November — extend to the rest**, on the evidence from late October, and finish the landing page. **Mid November — freeze.** No new video, no player changes, no placement changes on key templates. **Cyber Week — watch.** Conversion on video pages against those without, and page speed under real traffic. ## The same clips work harder off the storefront A BFCM video library made only for product pages is being under-used. The same clips, cut differently, cover most of the campaign surfaces you need anyway — and producing them once rather than four times is the difference between a manageable October and a frantic one. **Paid social** wants the hook back. The trimmed opening you removed for the product page is exactly what a feed needs, so keep both cuts from the same master rather than treating them as separate shoots. **Email** cannot play video reliably, but an animated still or a clearly-marked poster frame linking to the page works well and materially outperforms a static product photograph in most tests worth trusting. **Organic social** during the period should not be only offer announcements. Clips that answer product questions perform steadily while pure promotion fatigues fast, and they carry the offer in the caption where it costs nothing to change. **Post-purchase and support** is the surface nobody plans for. A short how-to clip attached to the confirmation email reduces the "how does this work" contacts that spike after a high-volume period, and reduces returns caused by people using something wrongly. The planning implication is to brief the shoot, or the selection, against all of these at once. Shooting vertical, keeping the master uncropped, and capturing a few seconds more than you need at each end costs nothing at the time and saves a re-shoot when you discover the clip needs to be a different length for a different surface. > **Keep the masters** > > Whatever app hosts your storefront video, keep unedited master files in your own storage. Next year you will want to recut this year's footage, and having only the transcoded, trimmed, offer-stamped versions means starting over. ## Measuring it during a period that distorts everything BFCM is the worst time of year to evaluate anything, because every variable moves at once. Traffic composition changes, intent changes, and prices change. Two things make it tractable: **Use a matched control.** Products with video against comparable products without, during the same period. Any before-and-after comparison across the BFCM boundary is measuring the season, not the video. **Watch page speed alongside conversion.** If the video group got slower, you ran two experiments simultaneously and cannot separate them. This is the most common reason a video test returns a confusing null result. And record the outcome somewhere durable. BFCM generates evidence about what works on your catalogue that is worth far more than the period's revenue, and most merchants lose it because nobody wrote anything down while it was happening. For the wider video question, see [video commerce and UGC](/category/video-commerce-ugc). Landing pages and page weight are covered in [storefront and design](/category/storefront-design), and the full sequence in the [BFCM 2026](/series/bfcm-2026) series. **Shoppable video live before your freeze date** SwipeReel turns existing Reels and TikTok UGC into shoppable carousels, stories and product-page feeds — with tap-to-buy inside the video and no page-load cost. [See SwipeReel on the Shopify App Store](https://apps.shopify.com/swipereel) ## FAQ ### When should BFCM video be finished? Before November. Video needs to be live long enough to be tested, measured and fixed, and a clip that goes up during Cyber Week is a change shipped into peak with no observation window. ### Do I need to shoot new video for BFCM? Usually not. Existing Reels, TikToks and customer content are already made and already tested with an audience. ### Where should BFCM video go? Product pages for clips that resolve a specific doubt, and the landing page or homepage for discovery-oriented content. ### Should the video mention the discount? Be careful. A clip stating a specific percentage becomes unusable the moment the offer changes and dates itself immediately afterwards. ### Is video worth it for BFCM at all? It depends on whether your products have doubts that images leave unresolved. If they do, video resolves them at the moment your traffic is most expensive, which is when resolution is worth most. --- --- title: "Shopify headless con Hydrogen: cuándo compensa" description: "Ir headless cambia los valores por defecto de Shopify por control, y se hereda todo lo que esos valores resolvían en silencio. Para la mayoría de tiendas, un tema rápido y bien construido es mejor negocio; para unas pocas, Hydrogen es la única forma de tener el storefront que necesitan." author: "Aashish Kaushik" published: 2026-10-04T05:01:22.801Z updated: 2026-10-04T05:01:22.804Z url: https://blog.byteinfy.com/shopify-headless-con-hydrogen-cuando-compensa --- # Shopify headless con Hydrogen: cuándo compensa ## Key takeaways - Headless significa que el escaparate deja de ser un tema de Shopify y pasa a ser una aplicación propia (con Hydrogen, Next.js u otro framework) que habla con Shopify por API; el checkout, los pedidos y el panel siguen siendo de Shopify. - Lo que se gana es control total sobre el front, contenido de fuentes externas y libertad de diseño; lo que se pierde es el editor de temas, las apps que se instalan y funcionan, y una parte del trabajo que Shopify hacía gratis. - Un storefront headless parte de 5.000 dólares y llega a 25.000 o más en la página de servicios de ByteInfy en el momento de escribir, y a eso hay que sumar un equipo que lo mantenga después. - Compensa en tiendas con contenido intensivo que el editor de temas no puede expresar, en multi-mercado con lógica propia y en equipos con ingenieros que vayan a operarlo; para el resto, un tema Online Store 2.0 bien hecho es más rápido y más barato. Shopify headless con Hydrogen compensa en pocos casos, y en esos pocos compensa mucho. La regla corta: si su tienda cabe en un tema de Online Store 2.0, headless le costará más, tardará más y probablemente irá más lento; si el editor de temas le ha dicho tres veces "eso no se puede", y las tres eran necesidades reales de negocio, headless es la salida. Este artículo explica qué significa headless en Shopify y qué papel juega Hydrogen, qué se gana y qué se pierde con respecto a un tema, qué cuesta y quién lo mantiene, y en qué situaciones concretas tiene sentido. Al final hay una lista de comprobación para decidir y las alternativas que conviene agotar antes. Está escrito para comerciantes y responsables de ecommerce en España y Latinoamérica a los que alguien (una agencia, un inversor, un artículo) les ha sugerido que "deberían ir headless". La mayoría no deberían, y este artículo intenta explicar cómo saber si usted es la excepción. ## Qué significa headless en Shopify Headless quiere decir que el escaparate deja de ser un tema de Shopify y pasa a ser una aplicación web propia que obtiene los datos de Shopify por API. En una tienda normal, Shopify lo hace todo: guarda el catálogo, procesa el checkout, gestiona pedidos y clientes, y además dibuja las páginas que ve el cliente usando un tema en Liquid. En una tienda headless, Shopify sigue haciendo todo lo primero, pero las páginas las dibuja una aplicación separada, escrita normalmente en React, que pide productos, colecciones, precios y carrito a la Storefront API de Shopify y los presenta como quiera. El checkout no cambia. Cuando el cliente pulsa "comprar", el storefront headless lo envía al checkout de Shopify, que sigue siendo el de siempre con sus métodos de pago, Shop Pay y las extensiones que tenga configuradas. Esto es importante porque mucha gente cree que headless significa reescribir el checkout, y no: el checkout de Shopify no se puede sustituir, ni con headless ni sin él. **Hydrogen** es el framework que Shopify publica para construir esos storefronts. Está basado en React, trae resueltas las consultas a la Storefront API, el carrito, las cuentas de cliente y la estructura de páginas, y se despliega en **Oxygen**, el alojamiento de Shopify para Hydrogen, incluido en los planes de Shopify sin coste adicional en el momento de escribir. No es obligatorio: un storefront headless puede hacerse en Next.js, Astro, Nuxt o cualquier framework que sepa hacer peticiones HTTP, y alojarse donde se quiera. Hydrogen es simplemente la opción con menos piezas que montar. Para una explicación más técnica de la arquitectura, con ejemplos de código, el artículo en inglés sobre [headless Shopify con Hydrogen](/headless-shopify-hydrogen) entra en más detalle. ## Qué se gana al ir headless Lo que se compra con headless es control, y el control se nota en tres sitios. **Libertad de diseño y de estructura.** Un tema de Shopify, por muy personalizado que esté, trabaja dentro de lo que Liquid y el editor de secciones permiten. Un storefront headless es una aplicación web completa: puede tener páginas que mezclan productos y contenido editorial en cualquier proporción, transiciones y estados que Liquid no expresa, componentes reutilizables con lógica propia y una estructura de navegación que no depende de colecciones. Para marcas cuya web es tan editorial como transaccional (revistas con tienda, marcas de moda con lookbooks extensos, productos configurables), esto es la razón principal. **Contenido de varias fuentes.** Un storefront headless puede leer productos de Shopify y a la vez artículos de un CMS externo (Sanity, Contentful, Storyblok), fichas técnicas de un PIM, disponibilidad de un ERP y reseñas de un servicio propio, y componer una página con todo ello. Con un tema esto se hace a base de metafields y apps, y tiene límites; con headless, el límite lo pone el equipo. **Un solo front para varios canales o mercados.** Una empresa con varias tiendas Shopify (por país, por marca) puede tener un único storefront que consulte a la tienda correspondiente según el dominio, con componentes compartidos y lógica de merchandising propia. Shopify Markets resuelve la mayoría de casos de multimoneda y dominios localizados desde un tema, pero cuando la lógica de qué se muestra a quién es realmente compleja, headless da más margen. Hay una cuarta ventaja que se cita mucho y merece matiz: la velocidad. Un storefront headless bien construido puede ser muy rápido, porque el equipo controla cada byte que se envía. Pero un tema bien construido también, y muchos proyectos headless salen más lentos que el tema que sustituyen porque cargan frameworks enteros y librerías que el tema no necesitaba. La velocidad no viene con la arquitectura; viene con la disciplina, y el artículo sobre [velocidad de temas en Shopify](/shopify-theme-speed) demuestra cuánto se puede conseguir sin salir del tema. ## Qué se pierde: todo lo que el tema hacía en silencio La factura de headless no es solo el desarrollo inicial. Es todo lo que Shopify resolvía sin que nadie lo notara y que ahora pasa a ser responsabilidad suya. **El editor de temas.** Su equipo de marketing edita hoy secciones, textos, imágenes y páginas de campaña sin tocar código. En headless, esa capacidad hay que reconstruirla: un CMS conectado, componentes editables, un flujo de previsualización. Es factible y suele hacerse, pero es una partida del presupuesto y nunca queda tan integrada como el editor nativo. **Las apps que se instalan y funcionan.** Reseñas, upsells, buscadores con filtros, vídeo en la página de producto, banners de envío gratis, pop-ups, chat. En un tema, se instalan y aparecen. En headless, cada una hay que integrarla en el storefront usando su API si la tiene (y no todas la tienen), y cada actualización de la app puede requerir trabajo del equipo. El artículo sobre [cuántas apps son demasiadas](/how-many-shopify-apps-is-too-many) es útil aquí a la inversa: en headless, cada app que se quiera es un pequeño proyecto. **Las actualizaciones automáticas.** Cuando Shopify añade una función a los temas (nuevos bloques, mejoras de rendimiento, cambios en el carrito), los temas la reciben. Un storefront headless la recibe cuando su equipo la implementa. Hydrogen mitiga esto en parte porque Shopify lo actualiza, pero lo que se construye encima es suyo. **Las cuentas de cliente, la búsqueda, los filtros, las páginas de error, el SEO técnico.** Todo eso viene resuelto en un tema y en headless hay que construirlo o integrarlo. Las nuevas cuentas de cliente de Shopify funcionan con headless, la búsqueda y los filtros tienen API, y Hydrogen trae bases para todo ello, pero cada pieza es una decisión y un trabajo, no una casilla. > **Quién lo mantiene después** > > La pregunta que más se olvida al decidir headless no es cuánto cuesta construirlo sino quién lo cuida después. Un tema de Shopify puede quedar sin desarrollador durante meses y seguir funcionando. Un storefront headless sin nadie que actualice dependencias, revise deprecaciones de la Storefront API y arregle lo que se rompe pierde valor cada trimestre. Si no tiene un ingeniero en plantilla o un retainer de mantenimiento comprometido, esa es la respuesta a "cuándo compensa": todavía no. ## Hydrogen, Next.js u otro framework Si la decisión de ir headless está tomada, la siguiente es con qué, y aquí las opciones son menos dramáticas de lo que parece. **Hydrogen con Oxygen** es la opción más integrada. Shopify mantiene el framework, el alojamiento está incluido en el plan, las consultas a la Storefront API vienen tipadas, el carrito y las cuentas de cliente están resueltos, y las actualizaciones de la base llegan de Shopify. Es la elección razonable cuando el storefront es principalmente una tienda y el equipo trabaja con React. Su límite es que Oxygen es un entorno concreto con sus reglas; si necesita ejecutar procesos que Oxygen no permite, tendrá que sacarlos a otro sitio. **Next.js** tiene sentido cuando su empresa ya lo usa en otras partes, cuando el equipo lo conoce mejor o cuando el storefront es parte de una aplicación mayor (una plataforma con área de cliente, herramientas o contenido que no es de tienda). Se aloja donde se quiera, habla con la misma Storefront API y hay ejemplos oficiales. Se paga con más piezas que mantener uno mismo. La comparación en detalle está en [Hydrogen frente a Next.js para headless Shopify](/hydrogen-next-js-headless-shopify). **Astro, Nuxt y otros** son válidos cuando el equipo los domina y la tienda es una parte pequeña de un sitio principalmente de contenido. Hay menos ejemplos y menos soporte específico de Shopify, y eso se nota cuando algo falla. La respuesta corta: Hydrogen si Shopify va a ser el centro y no tiene una razón fuerte para otra cosa; Next.js si ya vive en Next; otro framework solo si su equipo lo conoce mucho mejor que las dos anteriores. ## Cuánto cuesta y quién lo paga cada mes Un storefront headless cuesta más que un tema en el desarrollo inicial y, sobre todo, en lo que viene después. ## Orden de magnitud por opción (ByteInfy, USD, en el momento de escribir) | Opción | Precio de partida | Rango habitual | Quién lo mantiene | | --- | --- | --- | --- | | Personalización de un tema existente | 1.000 $ | 1.000 a 3.000 $ | Su equipo desde el editor de temas | | Tienda nueva en Online Store 2.0 | 2.000 $ | 2.000 a 8.000 $ | Su equipo desde el editor, con retainer opcional | | Storefront headless con Hydrogen o Next.js | 5.000 $ | Hasta 25.000 $ o más | Ingenieros propios o retainer obligatorio | | Retainer de mantenimiento | 500 $ al mes | Según bolsa de horas | La agencia | Las cifras salen de la [página de servicios de headless de ByteInfy](https://byteinfy.com/services/headless-shopify-hydrogen) y de sus servicios de tienda y tema, y son precios de partida, no presupuestos. Lo que las mueve en headless es el modelo de contenido (cuántos tipos de página, cuántas fuentes de datos), el número de mercados e idiomas, las integraciones y qué apps de tienda hay que reconstruir a mano. El coste que no aparece en esa tabla es el equipo. Un tema puede vivir con un retainer de pocas horas al mes o incluso sin él durante temporadas; un storefront headless necesita alguien que lo conozca, de forma continua, y ese alguien es un ingeniero en plantilla o una agencia con un compromiso mensual. Si al calcular el coste de headless solo suma el desarrollo inicial, está calculando la mitad. Para situar estas cifras dentro del presupuesto total de una tienda, el artículo sobre [cuánto cuesta una tienda hecha por una agencia](/es/agencia-shopify-cuanto-cuesta-una-tienda-2027-precios) recorre todas las partidas. ## Los casos en los que compensa Hay cuatro situaciones en las que headless es la respuesta correcta, y se reconocen porque el tema ya ha fallado en ellas. **Contenido intensivo que el editor de temas no puede expresar.** Marcas cuya página de producto es una historia, con capítulos, vídeo, comparativas y contenido que cambia según el visitante. Revistas o medios con tienda integrada. Catálogos técnicos con configuradores. Si su equipo de diseño ha entregado tres propuestas y las tres han vuelto de desarrollo con "el tema no puede hacer eso", y no era capricho, headless es el camino. **Multi-mercado con lógica de merchandising propia.** Shopify Markets cubre monedas, dominios localizados, precios por mercado e idiomas desde un tema, y para la mayoría es suficiente. Cuando además necesita que el surtido, el orden, las promociones y el contenido cambien por mercado con reglas propias, o combinar varias tiendas Shopify bajo un único front, headless da el margen que Markets no da. **Un equipo de ingeniería que va a ser el dueño del storefront.** Si tiene ingenieros en plantilla que ya construyen su web, su app o su plataforma, y el storefront de Shopify es una pieza más, headless encaja en cómo trabajan y el tema les estorba. Sin ese equipo, la condición no se cumple. **Una web que ya es headless por otras razones.** Empresas con un sitio corporativo o de contenido en Next.js u otro framework que quieren añadir comercio sin fragmentar la experiencia en dos sitios. Aquí headless no es una elección; es la forma de que la tienda viva dentro de lo que ya existe. Fuera de estos cuatro casos, la respuesta honesta que una agencia debería darle es que no lo necesita. ## Los casos en los que no compensa La mayoría de las tiendas a las que se les propone headless están en uno de estos casos, y el motivo de la propuesta suele estar en quien la hace, no en la tienda. **"Para ir más rápido."** Un tema bien construido, con pocas apps y las imágenes bien dimensionadas, pasa Core Web Vitals con holgura. Si su tienda va lenta, la causa casi siempre son las apps y el tema mal configurado, y se arregla con una [optimización de velocidad](https://byteinfy.com/services/shopify-speed-optimization) que parte de 750 dólares, no con un proyecto de 15.000. **"Para tener un diseño único."** Un tema a medida en Online Store 2.0 puede tener cualquier diseño que quepa en una página web normal. Lo que headless añade es lógica y estructura, no estética. El artículo sobre [tema frente a tienda a medida](/shopify-theme-vs-custom) explica dónde está el límite real de un tema. **"Porque la competencia lo hace."** Las grandes marcas que van headless tienen equipos de ingeniería que lo justifican. Copiar la arquitectura sin el equipo es copiar el coste sin el beneficio. **"Porque lo dijo la agencia."** Un proyecto headless es más grande, más largo y más rentable para quien lo construye que un tema. Eso no lo hace malo, pero sí obliga a preguntar por qué se propone. Una agencia seria le dirá que no lo necesita antes de presupuestarlo; el artículo sobre [cómo elegir una agencia Shopify](/es/como-elegir-una-agencia-shopify-12-preguntas) incluye esa pregunta entre las doce. Si su tienda tiene menos de unos pocos cientos de productos, un equipo de marketing que edita la web sin desarrollador y ninguna de las cuatro situaciones del apartado anterior, headless es dinero que rendiría más en producto, en contenido o en publicidad. ## Alternativas que conviene agotar antes Antes de aceptar un presupuesto headless, hay tres cosas que resuelven la mayoría de las necesidades que lo motivan, a una fracción del coste. **Secciones y bloques a medida en el tema.** Casi todo lo que "el tema no puede hacer" puede hacerlo una sección programada a medida: comparadores, configuradores sencillos, páginas de campaña con estructura propia, bloques de contenido editorial. Se editan desde el editor de temas y no rompen las actualizaciones si se construyen bien. Parten de 1.000 dólares en el servicio de personalización de temas. **Metafields y metaobjetos.** Guías reutilizables, fichas de ingredientes, tablas de especificaciones, contenido estructurado que se comparte entre productos. Shopify los tiene nativos, se muestran desde el editor y cubren gran parte de lo que antes justificaba un CMS externo. **Shopify Markets para lo internacional.** Monedas, dominios o subcarpetas por país, precios por mercado, idiomas con la app de traducción. Para la mayoría de tiendas que venden en España, Portugal y varios países de Latinoamérica, resuelve lo que se pedía a headless. ## Antes de decidir headless - Ha listado por escrito las tres cosas concretas que el tema no puede hacer y son necesidades de negocio, no de gusto - Una agencia o desarrollador ha confirmado que una sección a medida, metafields o Markets no las resuelven - Tiene un ingeniero en plantilla o un retainer de mantenimiento comprometido para después del lanzamiento - Ha sumado al presupuesto la reconstrucción de las apps de tienda que hoy usa (reseñas, buscador, upsells, vídeo) - Ha previsto cómo editará marketing el contenido sin un desarrollador (CMS, previsualización, permisos) - Ha fijado en el alcance objetivos de Core Web Vitals y SEO iguales o mejores que los del tema actual - Ha planificado redirecciones si alguna URL cambia y un plan de vuelta atrás si el proyecto se retrasa - Alguien de su confianza que no cobra por el proyecto ha revisado la decisión Si la lista sale completa, headless es probablemente la decisión correcta y el siguiente paso es un descubrimiento corto con quien vaya a construirlo, para responder con datos a una sola pregunta: si se paga a sí mismo en su caso. Si la lista no sale completa, la respuesta de momento es un tema mejor, y headless puede esperar a que las condiciones cambien. **Le han propuesto headless y no sabe si lo necesita** Cuéntenos qué no puede hacer su tema hoy y quién mantendría el storefront mañana, y le diremos por escrito si headless compensa en su caso o si una sección, metafields o Markets lo resuelven por mucho menos. [Hablar con ByteInfy](https://byteinfy.com/contact) ## FAQ ### ¿Qué es Shopify headless? Una arquitectura en la que el escaparate (lo que ve el cliente) no es un tema de Shopify sino una aplicación web independiente que obtiene productos, colecciones y carrito de Shopify a través de la Storefront API. ### ¿Qué es Hydrogen? El framework de Shopify para construir storefronts headless con React. ### ¿Headless es más rápido que un tema de Shopify? Solo si se construye con cuidado. Un tema bien hecho en Online Store 2. ### ¿Cuánto cuesta un storefront headless con Hydrogen? En la página de servicios de ByteInfy, en el momento de escribir, un storefront headless parte de 5.000 dólares para un proyecto acotado y llega a 25. ### ¿Pierdo las apps de Shopify si voy headless? Las apps que funcionan en el panel de Shopify (inventario, facturación, envíos, email) siguen funcionando. ### ¿Puedo volver a un tema después de ir headless? Sí. Shopify sigue teniendo su tienda online activa aunque el tráfico vaya al storefront headless, y volver consiste en configurar un tema y cambiar el DNS. ### ¿Hydrogen o Next.js para headless Shopify? Hydrogen si quiere que Shopify aloje y actualice la base del storefront en Oxygen y su equipo trabaja bien con React. Next. --- --- title: "Cómo elegir una agencia Shopify: 12 preguntas" description: "Un portafolio demuestra que algo se lanzó. No dice si sigue funcionando, quién lo mantiene ni qué dejó en el tema de alguien. Estas doce preguntas sacan a la luz lo que el portafolio no enseña, y las respuestas separan a las agencias con más fiabilidad que cualquier caso de éxito." author: "Aashish Kaushik" published: 2026-10-03T13:01:05.330Z updated: 2026-10-03T13:01:05.370Z url: https://blog.byteinfy.com/como-elegir-una-agencia-shopify-12-preguntas --- # Cómo elegir una agencia Shopify: 12 preguntas ## Key takeaways - La pregunta más útil es qué construyeron hace dos años y si sigue funcionando; Shopify retira versiones de API con calendario público y una agencia con experiencia ha vivido varias de esas retiradas. - Las respuestas técnicas que importan son concretas, theme app extensions para lo que se ve en la tienda, Shopify Functions para descuentos y reglas de checkout, y un proceso escrito para las deprecaciones. - La propiedad del código, la documentación y lo que su equipo podrá editar sin la agencia se acuerdan por escrito antes de empezar, porque después son conversaciones incómodas. - Una agencia que le dice qué no construir está ejerciendo criterio, y ese criterio es lo que en realidad se compra; la que acepta todo lo que propone está vendiendo alcance. Elegir una agencia Shopify es difícil porque el trabajo es invisible para quien lo compra. Usted ve la tienda y no el código, y la diferencia entre ambos solo aparece cuando hay que cambiar algo dieciocho meses después. Las doce preguntas de este artículo están pensadas para hacer visible esa diferencia antes de firmar, no después. Los portafolios no ayudan mucho con esto. Demuestran que algo se construyó y se lanzó. No dicen si sigue funcionando, cuánto ha costado mantenerlo ni qué dejó en el tema de alguien. Las preguntas que siguen se agrupan en cuatro bloques (trabajo pasado, técnica, propiedad y mercado), y al final hay una tabla para interpretar las respuestas, las señales de alarma y cómo estructurar el primer encargo. > **Escrito por una agencia** > > Léalo con esa reserva. Las preguntas de abajo son las que esperaríamos que nos hicieran, y una agencia que las responde con incomodidad merece cautela, nosotros incluidos. ByteInfy tiene sede en India, trabaja con comerciantes de varios países y publica sus precios de partida en su [página de servicios](https://byteinfy.com/services); el resto de este artículo no habla de nosotros. ## Preguntas sobre el trabajo que ya hicieron Las tres primeras preguntas miran hacia atrás, porque lo que una agencia construyó hace dos años dice más de ella que lo que promete construir el mes que viene. ### 1. ¿Qué construyeron hace dos años y sigue funcionando? La pregunta más reveladora que existe, y casi nunca se hace. Cualquiera puede lanzar algo. Lo interesante es lo que pasó después: si sigue en marcha, si ha necesitado arreglos de urgencia, si sobrevivió a los cambios de plataforma que ha habido desde entonces. Shopify publica cada trimestre una versión nueva de sus APIs y retira las antiguas con calendario conocido; Scripts ya no existe y sus funciones pasaron a Shopify Functions; checkout.liquid se sustituyó por Checkout Extensibility; los temas cambiaron con Online Store 2.0 y después con Horizon. Una agencia con varios años en la plataforma ha vivido todo eso, y cómo lo gestionó es una señal mejor que cualquier caso de éxito. Pida ver una tienda o una app concreta, con fecha, y pregunte qué tuvieron que tocar desde entonces. Una agencia que responde "nada" o miente o no ha mirado. ### 2. ¿Qué proyecto salió mal y qué aprendieron? Toda agencia con historia tiene proyectos que no salieron como se esperaba. La que lo reconoce y explica qué cambió en su proceso está mostrando madurez; la que dice que nunca ha pasado está mostrando poca experiencia o poca sinceridad, y ambas cosas cuestan dinero. ### 3. ¿Puedo hablar con un cliente que lleve más de un año con ustedes? Las referencias que ofrece una agencia por defecto son las de clientes recientes y contentos. Pida una antigua. Un cliente que lleva más de un año puede contar cómo fue el soporte después del lanzamiento, cómo se gestionaron los cambios y si el presupuesto final se pareció al inicial, que son exactamente las cosas que un portafolio no enseña. ## Preguntas técnicas Las cuatro siguientes tienen respuestas correctas concretas, y son informativas aunque no pueda evaluarlas a fondo. Si alguien de su confianza sabe de Shopify, pídale que esté en la llamada. ### 4. ¿Cómo integran lo que se ve en la tienda? La respuesta debería ser theme app extensions y secciones del tema. Una agencia que sigue inyectando código en los archivos del tema está construyendo algo que el comerciante no podrá quitar limpiamente, y ese residuo es la queja más frecuente de quien hereda una tienda de otra agencia. Pregunte también qué queda en el tema cuando se desinstala una app suya; la respuesta buena es "nada que usted no haya pedido". ### 5. ¿Cómo implementarían un descuento que Shopify no trae de serie? Shopify Functions. Si proponen manipular el carrito con JavaScript o una app que edita precios al vuelo, ese comportamiento se lo saltan los checkouts acelerados y deja de funcionar en cuanto Shopify cambia algo. Las reglas de descuento, envío y pago viven hoy en Functions y en extensiones de checkout, y una agencia que trabaja en Shopify en 2027 lo sabe. El artículo sobre [descuentos personalizados con Shopify Functions](/es/descuentos-personalizados-con-shopify-functions-adios) explica qué se puede hacer y qué no. ### 6. ¿Cómo gestionan las deprecaciones de API? Tiene que haber un proceso: un inventario de lo que han construido, un calendario y alguien asignado a revisarlo. "Lo vemos cuando surja" significa que lo verá usted cuando se rompa, probablemente en plena campaña. Pregunte cuándo fue la última vez que actualizaron una app o integración por una deprecación y cuánto cobraron por ello. El artículo sobre [versionado de la API de Shopify](/shopify-api-versioning) explica por qué esto no es opcional. ### 7. ¿Cómo prueban lo que entregan? No hace falta una respuesta elaborada, pero tiene que haber una, sobre todo para cualquier cosa que toque dinero: descuentos, pagos, impuestos, envíos. Una tienda de pruebas, un tema duplicado antes de publicar, pedidos de prueba con cada método de pago. Si la respuesta es "lo probamos en la tienda real con cuidado", su tienda real es el entorno de pruebas de la agencia. ## Preguntas sobre propiedad y entrega Las tres siguientes son comerciales, y deciden si al final tendrá un activo o una dependencia. Son fáciles al principio e incómodas al final, así que van al principio. ### 8. ¿Quién es propietario del código, y qué documentación recibo? Lo que se acuerde, y por eso se acuerda por escrito antes de empezar. Los clientes suelen dar por hecho que el trabajo a medida es suyo; las agencias suelen querer conservar componentes reutilizables. Ambas posturas son razonables. Lo que no es razonable es descubrirlo en la separación. Sobre la documentación, la pregunta útil es si el siguiente desarrollador podría continuar el trabajo sin llamar a la agencia. Un registro de cambios por archivo, acceso al repositorio y una explicación de cada integración es el mínimo. ### 9. ¿Qué podrá editar mi equipo sin ustedes? La partida que más se olvida. Una tienda cuyas secciones solo puede tocar el desarrollador convierte un coste único en uno permanente. Pida explícitamente que las secciones sean editables desde el editor de temas, que los textos y las imágenes de campaña no requieran código y que se lo enseñen en una demo antes de dar por terminado el proyecto. ### 10. ¿Qué pasa después del lanzamiento, y cuánto cuesta? Todo lo que es a medida necesita mantenimiento, porque Shopify cambia de forma continua. Un presupuesto que cubre el lanzamiento y no dice nada de los meses siguientes describe la mitad del coste. Pregunte si hay soporte incluido y durante cuánto tiempo, si ofrecen un retainer y qué incluye, y qué ocurre con los accesos y los repositorios si la relación termina. ## Preguntas sobre su mercado Las dos últimas dependen de dónde vende, y son las que distinguen una agencia que conoce su mercado de una que lo va a descubrir con su dinero. ### 11. ¿Qué particularidades de mi mercado tienen que constar en el alcance? Si vende en España, la respuesta debería incluir Bizum, el IVA y la OSS si vende a otros países de la Unión Europea, los transportistas habituales y la factura con los datos que exige la normativa. Si vende en México, Colombia, Argentina o Chile, debería mencionar la pasarela local (Mercado Pago u otra), la facturación electrónica del país, los envíos contra reembolso donde existan y la moneda. Una agencia que no lo pregunta lo aprenderá durante su proyecto. El artículo sobre [Shopify en España: Bizum, IVA y envíos](/es/shopify-espana-bizum-iva-envios) recoge lo que tiene que estar resuelto en una tienda española. Fíjese en que la sede de la agencia no es la pregunta. Una agencia fuera de su país que hace estas preguntas en la primera llamada y las pone por escrito sirve; una agencia en su misma ciudad que no las hace, no. El artículo sobre [costes de agencia entre India y Estados Unidos](/shopify-agency-india-usa-cost) compara qué cambia de verdad con la ubicación. ### 12. ¿Qué me dirían que no construya? La pregunta más útil de toda la conversación, y se deja para el final a propósito. Una agencia sin respuesta está vendiendo alcance. Una que dice "no necesita headless", "eso lo hace un tema" o "esa app ya existe y cuesta menos que nosotros" está ejerciendo criterio, y el criterio es lo que en realidad se compra. Lo mismo vale para su propio encargo: si pide una tienda a medida y la respuesta honesta es que un tema configurado le serviría mejor, quiere oírlo antes del presupuesto y no después de la factura. Una agencia que está de acuerdo con todo lo que usted propone tiene una suerte inusual con sus clientes o no está pensando mucho en el encargo que tiene delante. ## Cómo interpretar las respuestas Las respuestas no son buenas o malas en abstracto; son señales, y conviene tener claro qué señal es cada una antes de la llamada. ## Qué dice cada respuesta | Pregunta | Respuesta que tranquiliza | Respuesta que preocupa | | --- | --- | --- | | Trabajo de hace dos años | Un ejemplo concreto y qué hubo que tocar | "Todo sigue igual" o ningún ejemplo | | Proyecto que salió mal | Un caso y un cambio de proceso | "Nunca nos ha pasado" | | Cómo integran lo visible | Theme app extensions y secciones editables | Código en archivos del tema | | Descuentos a medida | Shopify Functions, con sus límites | Manipular el carrito o los precios con JavaScript | | Deprecaciones de API | Inventario, calendario y responsable | "Lo vemos cuando surja" | | Pruebas | Tienda de pruebas y tema duplicado | Pruebas en la tienda real | | Propiedad del código | Por escrito, con repositorio y documentación | "Ya lo hablamos luego" | | Qué edita su equipo | Demo del editor de temas antes de cerrar | Todo pasa por la agencia | | Mantenimiento | Soporte definido y retainer opcional con precio | No aparece en el presupuesto | | Su mercado | Preguntan por pagos, impuestos y envíos locales | Presupuestan sin preguntar | | Qué no construir | Una lista concreta y argumentada | Todo lo que propone les parece bien | No hace falta que una agencia acierte las doce. Lo que busca es un patrón. Dos o tres respuestas flojas en preguntas de proceso pueden ser una agencia joven con buen criterio técnico; respuestas flojas en propiedad, mantenimiento y "qué no construir" a la vez describen una agencia que vende proyectos, no resultados. ## Señales de alarma Hay patrones que se repiten en los proyectos que acaban mal, y se ven en la primera conversación. **Presupuesto sin preguntas.** Una agencia que envía un número sin entender qué vende usted está presupuestando con una plantilla, y las plantillas no conocen su catálogo. **Estimación sin mantenimiento.** Ya se ha dicho, pero es la señal más frecuente y la más cara. **Reticencia a hablar de la entrega.** Si la propiedad y la documentación son temas incómodos al principio, serán peores al final. **La opción más cara por defecto.** Headless donde un tema bastaría, desarrollo a medida donde existe una app. El artículo sobre [cuándo compensa headless con Hydrogen](/es/shopify-headless-con-hydrogen-cuando-compensa) sirve para reconocerlo cuando se lo propongan. **Ningún ejemplo de trabajo antiguo en marcha.** O llevan poco tiempo, o el trabajo antiguo no es algo de lo que quieran hablar, y ambas cosas conviene saberlas. **Negativa a hablar con su desarrollador actual.** Si tiene uno, una agencia que lo trata como una amenaza y no como una fuente de contexto está priorizando la relación sobre el resultado. **Precios muy por debajo de la banda.** Una tienda completa por 500 dólares es casi siempre un tema con valores por defecto y los productos cargados a mano. No hay nada malo en ello si es lo que necesita, pero no es lo que el presupuesto sugiere. El artículo sobre [cuánto cuesta una tienda hecha por una agencia](/es/agencia-shopify-cuanto-cuesta-una-tienda-2027-precios) sitúa las bandas de precio y explica qué hay en cada extremo. ## Cómo estructurar el primer encargo Cómo organiza el primer trabajo importa tanto como a quién elige, porque determina cuánto aprende antes de comprometerse más. **Empiece con algo acotado.** Un proyecto definido con un final claro, una auditoría, una integración, una plantilla de campaña, le enseña cómo trabaja una agencia con una fracción del riesgo de una tienda entera. Aprende cómo comunica, cómo estima y qué calidad de código entrega en algo de lo que puede marcharse. **Observe la primera sorpresa.** Todo proyecto encuentra algo inesperado. La reacción es mucho más informativa que la propuesta: lo plantean pronto con opciones, o lo absorben en silencio y lo mencionan cuando el plazo se retrasa. **Compare la estimación con el resultado.** No para castigar la desviación (las estimaciones son estimaciones), sino porque cómo la comunica la agencia anticipa cómo será un proyecto grande. **Pida ver el código**, aunque no pueda evaluarlo del todo. Que alguien lo mire, o como mínimo compruebe que existe en un repositorio al que usted tiene acceso, que está documentado y que no es un único archivo enorme. **Fíjese en con quién habla.** Si la persona de la reunión comercial desaparece después de firmar, ese es el patrón de toda la relación. ## Antes de firmar, por escrito - Alcance por partidas y qué significa terminado en cada una - Quién es propietario del código y qué pasa con los componentes reutilizables - Qué documentación se entrega y en qué formato - Quién mantiene lo construido después del lanzamiento y a qué precio - Qué ocurre con accesos y repositorios si la relación termina - Cómo se gestionan las deprecaciones de API y quién paga las actualizaciones - Qué podrá hacer su equipo sin la agencia, demostrado en el editor de temas - Las particularidades de su mercado (pagos, impuestos, envíos, facturación) como partidas del alcance - Moneda, impuestos y calendario de pagos ## Agencia, freelancer o equipo propio No hay una respuesta universal, y las diferencias son bastante claras. **Un freelancer** suele ser mejor valor para un trabajo definido y acotado, y usted trata directamente con quien lo hace. El riesgo es la disponibilidad futura: el desarrollador que construyó su integración puede no estar localizable cuando haga falta actualizarla. **Una agencia** tiene sentido cuando importa la continuidad, cuando intervienen varias disciplinas (diseño, desarrollo, SEO, integraciones) o cuando el trabajo es continuo. En parte paga por el hecho de que alguien seguirá ahí. El riesgo es pagar una estructura que su proyecto no necesita. **Un equipo propio** encaja en tiendas con necesidades de desarrollo continuas y trabajo suficiente para justificar la contratación. Por debajo de ese umbral es capacidad cara sin usar. Una combinación habitual y sensata es una agencia o un freelancer para proyectos definidos, con capacidad interna suficiente para los cambios rutinarios y para evaluar lo que se entrega. Si quiere la versión en inglés de este razonamiento, con más detalle sobre cómo briefar a una agencia, está en [cómo contratar una agencia de desarrollo Shopify sin adivinar](/hire-shopify-development-agency). Y sea cual sea la opción, la regla no cambia: describa el problema, no la solución. "Nuestras páginas de producto en móvil pierden a la gente antes del botón de compra" da a una agencia algo que resolver. "Háganos un tema a medida" le da una instrucción que puede ser la equivocada. **Quiere una respuesta honesta sobre lo que necesita** Cuéntenos qué vende, dónde y qué le falla, y le diremos qué construir, qué no y cuánto costaría cada cosa, por escrito y antes de cualquier compromiso. [Hablar con ByteInfy](https://byteinfy.com/contact) ## FAQ ### ¿Qué debo mirar al elegir una agencia Shopify? Pruebas de que lo que construyen sobrevive. ### ¿Es mejor una agencia en España, en Latinoamérica o en el extranjero? Lo que importa no es la sede sino si conoce su mercado y lo pone por escrito. ### ¿Agencia o freelancer para un proyecto Shopify? Un freelancer suele ser mejor valor para un trabajo acotado y definido, y trata directamente con quien lo hace. ### ¿Cómo sé si una agencia Shopify es buena antes de contratarla? Empiece con un encargo pequeño y acotado, una auditoría, una integración o una plantilla, y observe cómo comunica, cómo estima y cómo reacciona a la primera sorpresa. ### ¿Quién es propietario del código que escribe una agencia? Lo que se acuerde, y por eso hay que acordarlo por escrito antes de empezar. ### ¿Cuánto cuesta una agencia Shopify? Depende del alcance, y la cifra que más importa es la del mantenimiento. Una tienda de agencia se mueve en la mayoría de los casos entre 2.000 y 8. ### ¿Qué señales indican que debo descartar una agencia? Que presupueste sin preguntar por su negocio, que no mencione mantenimiento, que esquive la conversación sobre propiedad y entrega, que proponga headless o desarrollo a medida por defecto, que no pueda enseñar trabajos antiguos que sigan en marcha y que trate a su desarrollador actual como una amenaza. --- --- title: "Migrar de WooCommerce a Shopify sin perder SEO" description: "El SEO no se pierde en la migración, se pierde en las URLs que cambian sin redirección y en el contenido que se queda por el camino. Con un inventario completo, un mapa de redirecciones 301 y los metafields bien pensados, el tráfico orgánico sobrevive al cambio de plataforma." author: "Aashish Kaushik" published: 2026-10-03T05:01:04.620Z updated: 2026-10-03T05:01:04.661Z url: https://blog.byteinfy.com/migrar-woocommerce-shopify-sin-perder-seo --- # Migrar de WooCommerce a Shopify sin perder SEO ## Key takeaways - Las URLs de WooCommerce y las de Shopify no coinciden nunca, porque Shopify fija sus rutas (/products/, /collections/, /pages/), así que cada URL antigua con tráfico necesita una redirección 301 explícita. - El trabajo que protege el SEO se hace antes de mover un solo producto, con un inventario de URLs, tráfico y enlaces entrantes exportado de Search Console y de la propia base de datos de WordPress. - Los campos personalizados de WooCommerce (composición, compatibilidad, guías de tallas) no tienen equivalente automático; van a metafields de Shopify y hay que decidir su destino antes de la importación. - Después del cambio de DNS, las primeras cuatro semanas en Search Console dicen si la migración ha salido bien; los errores 404 en URLs antiguas son el aviso que hay que atender el mismo día. El SEO de una tienda no se pierde al cambiar de plataforma. Se pierde cuando las URLs cambian sin que nadie las redirija, cuando el contenido que posicionaba se queda en WordPress y cuando la tienda nueva se lanza con títulos, descripciones y datos estructurados distintos de los que Google conocía. Migrar de WooCommerce a Shopify sin perder SEO consiste en evitar esas tres cosas, y casi todo el trabajo ocurre antes de mover un solo producto. Este artículo recorre el proceso en el orden en que conviene hacerlo: el inventario previo, el problema de las URLs, el mapa de redirecciones 301, los metafields, el contenido que debe sobrevivir, el día del cambio de DNS y lo que hay que mirar en Search Console después. Al final hay una nota sobre cuándo hacerlo por su cuenta y cuándo pagar a alguien, con precios de referencia. Se dirige a comerciantes de España y Latinoamérica que ya venden en WooCommerce y tienen tráfico orgánico que proteger. Si su tienda es nueva y apenas tiene posiciones, la migración es mucho más sencilla y puede saltarse la mitad de lo que sigue. ## Por qué se pierde el SEO en una migración Google no posiciona tiendas; posiciona URLs. Cada página de producto, categoría o artículo de blog tiene su propio historial de enlaces, señales y posiciones, y ese historial está atado a la dirección exacta de la página. Cuando la dirección cambia, Google ve una página nueva sin historial y una página antigua que ha desaparecido. La redirección 301 es el mecanismo que le dice a Google que la página antigua se ha mudado de forma permanente a la nueva, y que debe trasladar las señales acumuladas. Sin ella, la página antigua devuelve un error 404, las señales se pierden y la página nueva empieza de cero. Con una migración de mil productos y doscientas categorías, empezar de cero significa meses de tráfico perdido. El segundo motivo de pérdida es el contenido. WooCommerce permite guardar información en campos personalizados, atributos, pestañas de plugins y widgets, y buena parte de esa información acaba en el HTML que Google lee. Si la importación a Shopify solo mueve título, descripción, precio e imágenes, las páginas nuevas son más delgadas que las antiguas, y posicionan peor aunque la redirección esté bien. El tercero es más sutil: los datos estructurados, los títulos SEO y las metadescripciones que un plugin como Yoast o Rank Math generaba en WordPress no se copian solos. Shopify tiene sus propios campos para ello, y hay que rellenarlos con lo que había, no con lo que el tema nuevo pone por defecto. ## Antes de mover nada: el inventario Una migración sin inventario es una migración a ciegas, y el inventario se hace en WooCommerce, no en Shopify. Empiece por exportar todas las URLs que Google conoce. Search Console permite descargar las páginas con impresiones y clics de los últimos dieciséis meses; esa lista es la que importa de verdad, porque son las URLs que traen tráfico. Complételo con un rastreo completo del sitio (Screaming Frog u otra herramienta similar) para capturar las URLs que existen aunque no tengan tráfico, y con la lista de páginas que reciben enlaces externos, que puede sacar de Search Console o de una herramienta de backlinks. A esa lista añada, por cada URL, el tipo de contenido (producto, categoría, etiqueta, página, entrada de blog, filtro), el tráfico de los últimos doce meses y el número de enlaces entrantes. Ordénela por tráfico. Las cien primeras URLs merecen atención individual; el resto puede tratarse con reglas. Exporte también los datos que WooCommerce guarda fuera del producto: atributos, campos personalizados (meta de producto), términos de taxonomías propias, textos de pestañas de plugins, reseñas. La exportación estándar de WooCommerce a CSV no incluye todo esto, y a menudo hace falta un plugin de exportación o una consulta directa a la base de datos de WordPress. Es el paso que más se salta y el que más contenido pierde. > **Los productos que no vende ya** > > En una tienda con años de historia hay productos descatalogados que siguen indexados y siguen recibiendo visitas. No los descarte sin mirar: si tienen tráfico o enlaces, redirija su URL a la categoría o al producto sustituto en Shopify. Si no tienen ninguna de las dos cosas, un 404 limpio es aceptable, y Shopify devuelve uno sin que haga nada. ## Las URLs de WooCommerce y las de Shopify no coinciden Shopify impone la estructura de sus URLs, y no hay tema, app ni configuración que la cambie. Esa es la primera sorpresa para muchos comerciantes que vienen de WordPress, donde los enlaces permanentes se configuran a gusto. ## Equivalencia de rutas entre plataformas | Tipo de contenido | WooCommerce (habitual) | Shopify (fijo) | | --- | --- | --- | | Producto | /producto/nombre/ o /product/nombre/ | /products/nombre | | Categoría | /categoria-producto/nombre/ | /collections/nombre | | Etiqueta de producto | /etiqueta-producto/nombre/ | Sin equivalente directo, redirigir a colección | | Tienda | /tienda/ o /shop/ | /collections/all | | Página | /nombre/ | /pages/nombre | | Entrada de blog | /blog/nombre/ o /nombre/ | /blogs/nombre-del-blog/nombre | | Filtro o atributo | /categoria/?pa_color=rojo | Sin URL propia, redirigir a la colección | Lo que sí puede conservar es el handle, es decir, la parte final de la URL. Si un producto vivía en /producto/zapatilla-trail-mujer/, en Shopify puede vivir en /products/zapatilla-trail-mujer. Mantener el handle no evita la redirección, pero hace el mapa mucho más fácil de generar con una regla en lugar de a mano, y conserva la palabra clave en la URL. Preste atención a dos detalles. Shopify no permite barras finales ni mayúsculas en los handles, y convierte caracteres acentuados: un handle con "ñ" o con tildes se transforma, así que revise cómo queda cada uno antes de dar por buena la regla. Y las URLs de filtros y atributos de WooCommerce, que en muchas tiendas generan miles de páginas indexadas, no tienen destino propio en Shopify; lo razonable es redirigirlas a la colección padre. Las etiquetas de producto merecen una decisión aparte. En WooCommerce cada etiqueta tiene su página; en Shopify las etiquetas filtran dentro de una colección pero no generan una URL indexable equivalente. Si alguna página de etiqueta tenía tráfico, cree una colección con ese nombre y redirija; si no, redirija a la categoría más cercana. El artículo sobre [SEO de páginas de colección](/shopify-collection-page-seo) explica cómo aprovechar las colecciones para cubrir esas búsquedas. ## El mapa de redirecciones 301 El mapa de redirecciones es el documento central de la migración: una tabla con dos columnas, URL antigua y URL nueva, con una fila por cada URL del inventario que merezca conservarse. Shopify gestiona las redirecciones desde Tienda online, Navegación, Redirecciones de URL. Se pueden crear una a una o importar en CSV, y la importación es la única opción realista para una migración. El archivo lleva dos columnas, "Redirect from" y "Redirect to", con rutas relativas (sin dominio). Una redirección de Shopify responde con un 301 permanente, que es lo que Google necesita. Hay tres limitaciones que conviene conocer antes de construir el mapa. Shopify no redirige rutas que ya existen en la tienda nueva, así que no puede redirigir /products/x a otro sitio si /products/x es un producto activo. Shopify ignora los parámetros de consulta al comparar rutas, así que /categoria/?pa_color=rojo y /categoria/ se tratan como la misma URL de origen; la solución es redirigir la ruta base y aceptar que los filtros se pierden. Y no admite expresiones regulares ni comodines, por lo que cada URL necesita su propia fila. Genere el mapa con reglas para el grueso (producto a producto, categoría a colección) y revise a mano las cien URLs con más tráfico y las que tienen enlaces externos. Esas cien son las que sostienen la mayor parte del tráfico orgánico de casi cualquier tienda, y un error en una de ellas pesa más que cien errores en URLs sin visitas. Evite las cadenas de redirección. Si en WooCommerce ya había redirecciones antiguas (de una URL de 2019 a otra de 2022, por ejemplo), la nueva redirección debe llevar del origen más antiguo directamente al destino en Shopify, no pasar por la URL intermedia. Google sigue cadenas cortas, pero cada salto pierde algo y ralentiza el reprocesado. Evite también redirigir todo a la página de inicio. Es la solución rápida que ofrecen algunos plugins y algunas agencias con prisa, y Google la trata como un 404 encubierto: la señal no se traslada y el usuario que buscaba un producto concreto aterriza en una portada genérica. ## Metafields: dónde va lo que WooCommerce guardaba en campos personalizados Lo que en WooCommerce eran campos personalizados, atributos y pestañas de plugins, en Shopify son metafields, y la decisión de qué campo va a dónde se toma antes de la importación, no después. Un metafield de Shopify tiene un espacio de nombres, una clave y un tipo (texto, número, lista, referencia a otro producto, archivo, entre otros). Los metafields se definen desde Configuración, Datos personalizados, y una vez definidos aparecen en el editor de cada producto y pueden mostrarse en el tema desde el editor de secciones sin programar. Eso significa que la composición de un cosmético, la tabla de compatibilidad de un recambio o la guía de tallas de una prenda pueden seguir apareciendo en la página de producto, y por tanto seguir contando para el SEO. El trabajo tiene tres pasos. Primero, listar todos los campos que WooCommerce guarda por producto y decidir cuáles se ven en la web (esos van a metafields) y cuáles son internos (esos pueden ir a metafields ocultos, a etiquetas o descartarse). Segundo, definir los metafields en Shopify con el tipo correcto; un campo que en WordPress era texto libre pero en realidad siempre contenía un número conviene definirlo como número para poder filtrar por él. Tercero, incluir esos campos como columnas en el CSV de importación de productos, con el formato de encabezado que Shopify espera para metafields. Las variantes merecen atención aparte. WooCommerce permite atributos de producto que no generan variantes y atributos que sí; Shopify tiene hasta tres opciones por producto que siempre generan variantes, y un límite de variantes por producto que ha ido subiendo pero que sigue existiendo. Un producto con cinco atributos en WooCommerce no se importa tal cual: hay que decidir cuáles son opciones de compra (talla, color) y cuáles son información (material, origen), y esa información va a metafields. El artículo sobre [metaobjetos y metafields en Shopify](/shopify-metaobjects-metafields) explica cómo estructurar contenido más complejo, como guías reutilizables o fichas de ingredientes compartidas entre productos. ## El contenido que debe sobrevivir tal cual Además de las URLs y los metafields, hay cuatro cosas que Google leía en la tienda antigua y que deben leerse igual en la nueva. **Títulos SEO y metadescripciones.** Yoast, Rank Math y plugins similares guardan un título y una descripción por página en su propia tabla, distintos del nombre del producto. Shopify tiene los campos equivalentes en cada producto, colección y página (en la sección "Listado en motores de búsqueda"), y el CSV de importación los admite como columnas. Exporte los del plugin y cárguelos; no deje que Shopify genere unos nuevos a partir de la descripción, porque cambiar todos los títulos de golpe es una de las causas más frecuentes de caída tras una migración. **Descripciones largas y contenido HTML.** La descripción de producto de WooCommerce admite HTML, y muchas tiendas tienen ahí tablas, listas y encabezados que ayudan a posicionar. Shopify admite HTML en la descripción, pero el CSV de importación puede alterar el formato si no se escapa bien. Compruebe una muestra de productos con descripciones largas antes de importar el catálogo entero. **Entradas de blog.** WooCommerce vive dentro de WordPress, y muchas tiendas tienen decenas de artículos que traen tráfico. Shopify tiene blog, con menos funciones, y las entradas se importan con su propio CSV o por API. Conserve handles, fechas de publicación y autor. Si el blog tenía categorías, en Shopify serán etiquetas de artículo o blogs separados. El artículo sobre [SEO del blog en Shopify](/shopify-blog-seo) explica qué se puede y qué no se puede hacer con la estructura de blog de Shopify. **Datos estructurados.** Los temas de Shopify incluyen datos estructurados de producto por defecto (nombre, precio, disponibilidad, valoraciones si hay app de reseñas), y en muchos casos son mejores que los que generaba WordPress. Pero si en WooCommerce tenía FAQ, migas de pan u organización marcadas con un plugin, compruebe que el tema nuevo o una app las reproduce. Use la prueba de resultados enriquecidos de Google sobre una página de producto y otra de colección antes del lanzamiento. Por último, revise la tienda nueva en busca de contenido duplicado que Shopify genera por su cuenta: la misma página de producto accesible desde varias colecciones, o las páginas de etiquetas. Shopify pone etiquetas canónicas correctas en la mayoría de los casos, pero conviene entender qué hace y por qué; el artículo sobre [contenido duplicado en Shopify](/shopify-duplicate-content) lo detalla. ## El día del cambio de DNS La migración se decide en el inventario, pero se ejecuta en un día concreto, y ese día tiene un orden. ## Antes de cambiar el DNS - La tienda Shopify está completa y revisada tras contraseña, con productos, colecciones, páginas y blog importados y comprobados por muestreo - Los títulos SEO y metadescripciones importados coinciden con los de WooCommerce en una muestra de veinte páginas con tráfico - El CSV de redirecciones está importado en Shopify y probado con diez URLs de cada tipo (producto, categoría, página, blog) - El dominio principal está configurado en Shopify y el certificado SSL emitido, aunque el DNS aún apunte a WordPress - La tienda antigua deja de aceptar pedidos unas horas antes para que ningún pedido se pierda en el cambio - Los clientes están importados; las contraseñas no se pueden mover y hay un correo de restablecimiento preparado - Search Console está verificado para el dominio (verificación por DNS, que sobrevive al cambio de plataforma) - El sitemap de Shopify (/sitemap.xml) está listo para enviarse en cuanto el DNS cambie - Analítica, píxeles y consentimiento están instalados y probados en la tienda de pruebas - Hay una persona asignada a revisar Search Console y los errores 404 cada día durante las dos primeras semanas El cambio de DNS en sí se hace en una ventana de poco tráfico, de madrugada entre semana o un domingo por la mañana según su mercado. Desde ese momento, las redirecciones tienen que responder desde el primer segundo: si un rastreador de Google llega a una URL antigua y encuentra un 404 porque el CSV no se había importado todavía, esa URL entra en la cola de errores y tarda más en recuperarse. Si además cambia de dominio (no solo de plataforma), use la herramienta de cambio de dirección de Search Console después de que las redirecciones estén activas. Si el dominio es el mismo, no hace falta; envíe el sitemap nuevo y espere. No borre WordPress el mismo día. Manténgalo accesible en un subdominio o en local durante al menos tres meses, porque aparecerán contenidos que nadie recordaba, imágenes que faltan y campos que no se exportaron. Es más barato recuperarlos de una copia viva que de una copia de seguridad. ## Qué vigilar en Search Console las semanas siguientes Las cuatro semanas posteriores al cambio dicen si la migración ha funcionado, y Search Console es donde se ve. **Errores 404 en el informe de páginas.** Es el primer lugar a mirar cada día. Cualquier URL antigua con tráfico que aparezca como "No encontrada" es una redirección que falta o está mal escrita, y se corrige añadiendo la fila al mapa e importándola. Las URLs sin tráfico ni enlaces pueden dejarse en 404. **Cobertura e indexación.** El número de páginas indexadas bajará al principio (las URLs antiguas salen) y subirá después (las nuevas entran). Lo que importa es que las nuevas entren: si a las tres semanas las páginas de producto de Shopify siguen sin indexarse, revise que el sitemap está enviado, que el tema no mete etiquetas noindex por defecto en algún tipo de página y que la contraseña de la tienda se retiró. **Rendimiento por página.** Compare los clics de las veinte URLs principales de WooCommerce con los de sus destinos en Shopify. Una caída de entre el 10 y el 30 % durante las primeras semanas es normal; una URL concreta que cae al cero indica un problema en esa redirección o en esa página. **Core Web Vitals.** Shopify suele ser más rápido que un WordPress cargado de plugins, pero un tema mal configurado o diez apps instaladas el día del lanzamiento pueden invertirlo. Revise el informe a las cuatro semanas, cuando haya datos de campo, y lea el artículo sobre [velocidad de temas en Shopify](/shopify-theme-speed) si algo sale en rojo. **Enlaces internos rotos.** Las descripciones de producto y las entradas de blog importadas conservan enlaces a URLs antiguas de WooCommerce. Funcionan gracias a las redirecciones, pero conviene actualizarlos para que apunten directamente a las URLs nuevas; un rastreo de la tienda Shopify con Screaming Frog los encuentra en minutos. Si a las ocho semanas el tráfico orgánico sigue un 30 % por debajo del punto de partida y los 404 están limpios, el problema no es la migración: es contenido más delgado en las páginas nuevas, títulos que cambiaron o un tema que muestra menos texto que el anterior. Vuelva al inventario y compare una página antigua con su equivalente nuevo elemento a elemento. ## Cuándo hacerlo solo y cuándo contratar La migración de una tienda pequeña sin mucho tráfico orgánico se puede hacer por cuenta propia. Shopify tiene una app oficial de importación desde WooCommerce que mueve productos, clientes y pedidos, y el CSV de redirecciones se genera con una hoja de cálculo y algo de paciencia. Si su tienda tiene menos de doscientos productos, el blog es pequeño y Search Console no muestra un tráfico que le quite el sueño, adelante. Merece la pena pagar cuando hay tráfico orgánico que proteger, un catálogo grande con campos personalizados, un programa de gestión o ERP que debe seguir sincronizado, o varios idiomas. En esos casos el coste de una redirección mal hecha o de un campo perdido se mide en meses de ventas, y supera con mucho el coste del trabajo. Una migración de catálogo y clientes con mapa de redirecciones parte de 1.500 dólares en la [página de servicios de migración de ByteInfy](https://byteinfy.com/services/shopify-migration), en el momento de escribir, y la tienda en sí (tema, secciones, diseño) es una partida distinta que se presupuesta aparte. Si va a contratar, pida a la agencia que le enseñe el mapa de redirecciones antes del cambio de DNS y que le entregue el inventario con el que trabajó. Una agencia que no puede enseñar ese documento no ha hecho el trabajo que protege el SEO, por muy bonita que quede la tienda. El artículo sobre [cómo elegir una agencia Shopify](/es/como-elegir-una-agencia-shopify-12-preguntas) tiene más preguntas de ese tipo, y el de [cuánto cuesta una tienda hecha por una agencia](/es/agencia-shopify-cuanto-cuesta-una-tienda-2027-precios) sitúa la migración dentro del presupuesto total. Y una vez en Shopify, la [checklist SEO para Shopify](/es/checklist-seo-para-shopify-2027-25-puntos-que) recoge lo que conviene revisar en la tienda nueva cuando el polvo de la migración se haya asentado. **Va a migrar de WooCommerce y tiene tráfico que proteger** Cuéntenos cuántos productos tiene, qué campos personalizados usa y qué dice Search Console, y recibirá un plan de migración con el mapa de redirecciones como primera entrega. [Hablar con ByteInfy](https://byteinfy.com/contact) ## FAQ ### ¿Se pierde SEO al migrar de WooCommerce a Shopify? No tiene por qué. Lo que hace perder posiciones es cambiar URLs sin redirigirlas, dejar contenido fuera de la importación o lanzar la tienda nueva con títulos y descripciones distintos. ### ¿Puedo mantener las mismas URLs en Shopify que tenía en WooCommerce? No del todo. Shopify obliga a que los productos vivan en /products/, las colecciones en /collections/ y las páginas en /pages/, y no permite cambiar esos prefijos. ### ¿Cómo hago las redirecciones 301 en Shopify? Desde el panel de Shopify, en Tienda online, Navegación, Redirecciones de URL, puede crear redirecciones una a una o importar un archivo CSV con dos columnas, la ruta antigua y la nueva. ### ¿Qué pasa con las imágenes de WooCommerce al migrar? Las imágenes se vuelven a subir al CDN de Shopify, así que sus URLs cambian. Google indexa imágenes por separado, y ese tráfico se recupera más despacio que el de las páginas. ### ¿Cuánto tarda Google en reflejar la migración? Con las redirecciones activas desde el primer minuto, Google suele reprocesar la mayor parte de las URLs importantes en dos a seis semanas, aunque catálogos grandes pueden tardar más. ### ¿Debo migrar en temporada baja? Sí, siempre que pueda. Una migración pierde algo de tráfico durante unas semanas incluso cuando sale bien, y conviene que esas semanas no coincidan con su mejor mes. ### ¿Cuánto cuesta migrar de WooCommerce a Shopify con una agencia? Una migración de catálogo y clientes con mapa de redirecciones parte de 1.500 dólares en la página de servicios de ByteInfy, en el momento de escribir. --- --- title: "Product Page Design That Converts on Shopify" description: "Most product page advice is a list of elements to add. The better question is which doubt each element resolves, and what to remove because it resolves nothing." author: "Aashish Kaushik" published: 2026-10-02T13:01:02.844Z updated: 2026-10-02T13:01:02.886Z url: https://blog.byteinfy.com/shopify-pdp-design --- # Product Page Design That Converts on Shopify ## Key takeaways - A product page exists to resolve doubts, so the design question is which doubts your category actually produces. - Images do most of the persuading, and scale reference is the single most commonly missing element. - Everything competing with the buy decision above the fold is costing you something, including well-intentioned trust badges. - Mobile is not a smaller version of desktop — the buy box being pushed below a tall gallery is the most common mobile conversion leak. Most product page advice is a list of things to add: badges, reviews, urgency, video, a size guide, a related products carousel. Follow all of it and you get a page that says a great deal and converts worse than the one you started with. A more useful frame: a product page exists to resolve the doubts standing between an interested shopper and a purchase. Every element either resolves a doubt, or it competes for attention with the elements that do. That reframing makes the design decisions answerable, because you can ask of anything on the page which doubt it addresses. > **Start by naming the doubts** > > Before changing a template, write down the five questions your support team is asked most about a product. Those are your doubts, they are category-specific, and they should drive the layout rather than a generic best-practice list. ## The decision apparatus goes above the fold A short list, and it is short deliberately: the image, the title, the price, the variant selector, the add-to-cart button. That is what someone needs to make the decision. Everything else supports it and belongs below. The most common and most expensive violation is on mobile, where a tall image gallery pushes the buy box off screen entirely. The shopper arrives, sees a photograph, scrolls, sees more photographs, and has not yet encountered a price. Some of them leave before they do. Check this on an actual mid-range phone rather than a desktop browser resized. The gallery that looks balanced in a responsive preview frequently occupies the entire viewport on a real device, and browser resizing does not reproduce the address bar, the safe area, or the way a real thumb scrolls. ## Images do most of the work For physical products, images persuade more than copy does, and the coverage matters more than the count. What most catalogues are missing is not more photographs but specific ones: **Scale reference.** The single most commonly absent and most commonly needed. A product photographed alone on white tells a shopper nothing about size. A hand, a body, a room, or a stated measurement resolves it instantly. **The product in use.** Worn, held, installed, on a table. This is what someone is actually trying to imagine, and studio isolation shots do not help them do it. **Material and finish detail.** Close enough to see texture. This is where returns originate — a fabric that looked different, a finish that read as metal and is not. **Contents or packaging**, where what arrives is not obvious. Ambiguity about what is included generates support contacts and cancellations. **The awkward angle.** The one that shows the thing a shopper might worry about — the back, the underside, the join. ## Image coverage per product - Product alone, clean, for the grid and thumbnails - In use or worn by a real person - A clear scale reference, or stated dimensions in-frame - Detail shot showing material and finish - What is actually in the box, if that is unclear - The angle a sceptical buyer would ask for ## Structure the description; do not write an essay Descriptions fail by being paragraphs. A shopper looking for one fact — whether it fits a 15-inch laptop, whether it is machine washable — should find it without reading anything. What works is structure. Key facts near the top as a short list. Specifications as a table or list, not embedded in prose. Prose reserved for the things that genuinely need explaining, such as why a design choice was made or how the product differs from the obvious alternative. There is a second reason for this beyond usability. Specifications published as text are readable by AI shopping agents, which since Shopify's Summer '26 release receive eligible product data automatically. Specifications published as an image are invisible to them. A great many stores publish dimensions and materials as a graphic, and to a machine that information does not exist. ## What to remove The harder half of product page design, and the more valuable. **Urgency that is not true.** Countdown timers that reset, stock counters that always say four left. Shoppers recognise these, and the cost is trust rather than a neutral outcome. **Generic trust badges.** A specific, true claim — a real guarantee, a stated returns window — helps. An invented security seal near your buy button occupies the most valuable space on the page to say nothing. **Related products above the fold.** Offering alternatives before someone has decided on this product invites them to start over. **Multiple competing calls to action.** Add to cart, plus buy now, plus add to wishlist, plus notify me, plus a chat prompt. Each additional choice dilutes the primary one. **Popups on the product page.** A shopper this far down the funnel is closer to purchase than anyone else on the site, and interrupting them for an email address is a poor trade. ## Variants deserve more attention than they get Variant selection is where a large share of product page abandonment happens, and it is rarely treated as a design problem. **Show what is unavailable, do not hide it.** A shopper looking for a size that is out of stock should see that it exists and is unavailable, with a notify option. Removing it entirely reads as the product not coming in their size at all. **Change the image on selection.** Choosing a colour should show that colour. This is basic and frequently broken, particularly on themes carrying app-driven variant logic. **Use real labels.** Variant options should say what a customer would say, not internal codes. This matters for shoppers and, again, for the agents reading your catalogue. **Do not require a choice you can default.** If ninety percent of buyers choose one option, pre-selecting it removes a step for most people. ## Doubt and the element that resolves it | Doubt | What resolves it | | --- | --- | | Will it fit or suit me | Scale reference, on-body imagery, size guidance | | What is it actually made of | Detail imagery, materials stated as text | | Will it work with what I own | Compatibility stated explicitly, not implied | | What if it is wrong | Returns terms, visible and specific | | When will it arrive | Delivery estimate on the page, not at checkout | | Is it any good | Rating summary near the title, reviews below | ## Reviews, used properly Reviews are the most powerful element on a product page and the most commonly mishandled, usually by being given either too much prominence or too little. **The rating summary belongs near the title.** A star rating and a count, linked to the reviews below. This is a decision input and it belongs with the other decision inputs. **The reviews themselves belong lower.** They are for the shopper who is unconvinced and wants evidence. Placing full review text high on the page pushes the buy box down to serve a minority. **Show the unflattering ones.** A product with only five-star reviews reads as filtered, and shoppers have learned to distrust it. A visible three-star review that explains a real limitation increases trust in all the others, and it pre-empts a return from someone for whom the product was wrong. **Surface reviews that answer doubts.** A review mentioning fit on a specific body type, or compatibility with a specific device, is worth more than a generic positive one. Where a platform lets you highlight or sort by helpfulness, use it. **Answer the critical ones publicly.** A merchant response to a two-star review is read by far more people than the reviewer, and it demonstrates support in a way no badge can. The absence of reviews is its own design problem. A new product with none should not display an empty five-star row, which reads as broken. Either omit the module entirely until reviews exist, or state plainly that this product is new — honesty here costs less than the appearance of a rating system nobody is using. > **Review widgets are heavy** > > Most review apps load JavaScript on every page, including ones with no reviews to show. Check what yours costs on a product page and whether it loads where it is not used. A review widget that adds half a second to every product page is buying its social proof with conversion you cannot see leaving. ## Test one thing, on one template Product page changes are unusually easy to misattribute, because merchants tend to change several things at once on their best-selling product and then read the result as validation. Change one element, on one template, measured against a matched control. Run it long enough to clear the noise. And check page speed alongside conversion, because several of the additions in this article — video, review widgets, image galleries — carry weight, and a slower page suppresses the gains the change was meant to produce. For the wider storefront picture, see [storefront and design](/category/storefront-design). Video on product pages is covered in [video commerce and UGC](/category/video-commerce-ugc), and the product data implications in [SEO and AI search](/category/seo-ai-search). **Product pages that resolve doubts instead of adding elements** ByteInfy designs and builds Shopify storefronts — product page templates, image strategy and the performance budget that keeps them fast. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What should be above the fold on a Shopify product page? The product image, the title, the price, the variant selector and the add-to-cart button. That is the decision apparatus. Everything else — reviews, description, shipping detail, related products — belongs below it. ### How many product images do I need? Enough to answer the doubts your category produces, which is usually more than merchants think and fewer than a hundred. ### Do trust badges increase conversion? Sometimes, and they also occupy attention near the buy button. Badges that communicate something specific and true — a genuine guarantee, a real returns window, a recognised payment method — can help. ### Should the description be long or short? Structured rather than long or short. A shopper scanning for one fact should find it without reading. Specifications as a list, key facts near the top, and prose only where it genuinely explains something. ### Where should reviews go on a product page? The rating summary belongs near the title, where it supports the decision. The reviews themselves belong lower, where someone who wants them can find them. --- --- title: "Shopify en España: Bizum, IVA y envíos" description: "Una tienda Shopify en España se decide en tres configuraciones que las guías escritas para Estados Unidos no mencionan, Bizum en el checkout, el IVA con sus tipos y territorios, y los envíos con Correos y mensajería. Aquí están en el orden en que un comerciante las encuentra." author: "Aashish Kaushik" published: 2026-10-02T05:00:38.643Z updated: 2026-10-02T05:00:38.647Z url: https://blog.byteinfy.com/shopify-espana-bizum-iva-envios --- # Shopify en España: Bizum, IVA y envíos ## Key takeaways - Bizum no viene activado en Shopify por defecto; se ofrece a través de pasarelas compatibles en España y conviene que aparezca en el checkout sin desplegar listas, porque para muchos compradores es el primer método que buscan. - El IVA en Shopify se configura por país y por producto: tipo general, reducido y superreducido, precios con impuestos incluidos para particulares, Canarias, Ceuta y Melilla fuera del IVA, y la OSS para ventas al resto de la Unión Europea. - Los envíos en España se resuelven con zonas por territorio (península, Baleares, Canarias, Ceuta y Melilla), tarifas por peso o importe, y una app o integración para puntos de recogida. - Shopify Markets permite vender a Portugal, Francia o Latinoamérica desde la misma tienda, con moneda, idioma y dominio por mercado, sin duplicar la tienda. Una tienda Shopify en España funciona con las mismas herramientas que en cualquier otro país, pero tres configuraciones deciden si vende o no: Bizum activado a través de una pasarela compatible y visible en el checkout, el IVA configurado con sus tipos, sus territorios y la OSS para el resto de Europa, y los envíos con zonas separadas para península, islas y ciudades autónomas. Ninguna de las tres es difícil. Las tres faltan en las guías escritas para el mercado estadounidense, y cada una cuesta pedidos cuando no está. Esta guía las toma en el orden en que un comerciante español las encuentra, con lo que Shopify hace de serie, lo que necesita una app y lo que conviene dejar por escrito si trabaja con una agencia. ## Pagos: Bizum primero, y el resto alrededor Bizum es el primer ajuste de pagos que hacer en una tienda española, y no viene activado por defecto. Para una parte importante de los compradores en España, Bizum es el método por defecto en el móvil, el que buscan antes de sacar la tarjeta. Está disponible en Shopify a través de pasarelas de pago compatibles, que se añaden como método de pago adicional desde los ajustes de pagos. Cada pasarela tiene su proceso de alta con el banco, sus comisiones y su plazo de liquidación, y conviene compararlas antes de elegir. Alrededor de Bizum, el conjunto habitual: tarjetas Visa y Mastercard a través de Shopify Payments, Apple Pay y Google Pay para compradores en móvil, PayPal para quienes lo prefieren, y Shop Pay para acelerar el checkout de clientes que ya lo han usado en otra tienda. Con Shopify Payments como procesador principal se evitan las comisiones adicionales que Shopify aplica cuando se usa solo una pasarela externa; compruebe la tabla de comisiones de su plan para España antes de decidir. Dos detalles que se olvidan. El primero, el orden: Bizum debe verse en el checkout sin desplegar un menú de "otros métodos", porque un comprador que no lo encuentra a la primera asume que no está. El segundo, las pruebas: haga un pedido real con Bizum desde un móvil antes de lanzar, incluida la vuelta desde la app del banco al checkout de Shopify, que es donde fallan las integraciones mal configuradas. ## Métodos de pago para una tienda Shopify en España | Método | Cómo se activa | Nota | | --- | --- | --- | | Bizum | Pasarela compatible, como método adicional | Debe verse sin desplegar listas; probar el retorno desde la app bancaria | | Tarjetas Visa y Mastercard | Shopify Payments | Base de cualquier tienda; comisión según plan | | Apple Pay y Google Pay | Shopify Payments | Reducen el checkout en móvil a una confirmación | | Shop Pay | Shopify Payments | Acelera el pago de clientes que ya lo usan | | PayPal | Cuenta de PayPal Business | Con comisiones propias y, según el caso, comisión adicional de Shopify | | Transferencia bancaria | Pago manual | Útil en B2B; el pedido queda pendiente hasta confirmar | | Contra reembolso | Pago manual o app | Poco habitual en España; añade riesgo de devolución | ## IVA: tipos, territorios y precios con impuestos incluidos El IVA en Shopify se configura por país, por región y por producto, y una tienda española necesita las tres capas. **Tipos.** El tipo general es el 21 %. Existen un tipo reducido del 10 % y uno superreducido del 4 % para categorías concretas de productos. Shopify aplica un tipo por país, y las excepciones se crean como anulaciones de impuestos por colección: una colección con los productos al 10 %, otra con los del 4 %, cada una con su anulación. Si su catálogo mezcla tipos, esa estructura de colecciones hay que diseñarla antes de importar productos. **Territorios.** Canarias, Ceuta y Melilla están fuera del territorio de aplicación del IVA; tienen sus propios impuestos indirectos (IGIC en Canarias, IPSI en Ceuta y Melilla) que se liquidan en destino. En Shopify se gestiona con anulaciones por región que ponen el IVA a cero para esas provincias, y con una decisión sobre quién asume el impuesto y los trámites en destino, que conviene explicar en la página de envíos. **Precios con impuestos incluidos.** La normativa de consumo exige que el particular vea el precio final. En Shopify se activa la opción de incluir impuestos en los precios, y a partir de ahí el precio del producto es el precio con IVA. Si también vende a empresas y quiere mostrar precios sin IVA a clientes B2B, las funciones de empresa de Shopify lo permiten con catálogos y condiciones por cliente. **Facturación.** Shopify no emite facturas con los requisitos españoles por defecto. Necesita una app de facturación o una integración con su programa contable que genere facturas con numeración correlativa, NIF y desglose de IVA. Tenga en cuenta que la normativa española de facturación electrónica está en despliegue, con obligaciones nuevas para el software de facturación; consulte con su asesor qué plazos le aplican y elija una herramienta que los cumpla. ## OSS: vender al resto de la Unión Europea Si vende a particulares de otros países de la UE, el IVA que se aplica cambia a partir de un umbral, y Shopify puede calcularlo si se lo indica. Las ventas a distancia a particulares en otros estados miembros tributan con el IVA español hasta un umbral conjunto de 10.000 euros anuales para toda la UE. Superado ese umbral, tributan con el IVA del país de destino, y el sistema de ventanilla única (OSS) permite declararlo todo desde España sin darse de alta en cada país. Shopify aplica los tipos de cada país de destino cuando se configura el registro de la OSS en los ajustes de impuestos de la Unión Europea. Lo que conviene tener claro es que el precio con impuestos incluidos cambia según el destino: un producto a 100 euros con IVA en España tiene un precio con impuestos distinto en Francia o en Alemania si mantiene el mismo precio base. Shopify permite decidir si el precio mostrado se mantiene fijo y el IVA se ajusta dentro, o si el precio base se mantiene y el total cambia. Con Shopify Markets, además, puede fijar precios por mercado y redondearlos, lo que resuelve el problema para las tiendas que venden en varios países. > **La ronda de comprobación con su asesor** > > Antes de lanzar, repase con su asesor fiscal tres cosas: si su catálogo tiene productos a tipo reducido o superreducido y cómo se marcan, si va a superar el umbral de la OSS y desde cuándo, y qué herramienta de facturación cumple las obligaciones que le aplican. Shopify calcula bien el IVA que se le configura; lo que no puede hacer es decidir la configuración por usted. ## Envíos: zonas, tarifas y puntos de recogida Los envíos en España se resuelven con zonas por territorio, tarifas por peso o importe y una app para etiquetas y puntos de recogida. **Zonas.** Como mínimo, cuatro: península, Baleares, Canarias, y Ceuta y Melilla. Cada una con sus tarifas y plazos, porque el coste real de enviar a Canarias no se parece al de enviar a Valencia. Si vende a Portugal, otra zona; si vende a Francia o Italia, una zona por país o por grupo con tarifas similares. El error habitual es una única zona "España" con una tarifa plana que pierde dinero en cada envío insular. **Tarifas.** Por peso, por importe o combinadas, con el umbral de envío gratis que su margen aguante. Un envío gratis a partir de 50 o 60 euros es habitual en península; en islas conviene o subir el umbral o no ofrecerlo. Shopify permite tarifas condicionales por peso y por importe en cada zona, sin app. **Transportistas.** Correos y Correos Express, SEUR, MRW, GLS, Nacex y DHL cubren la mayoría de tiendas, y cada uno tiene una app propia o está en los agregadores logísticos que imprimen etiquetas y generan seguimiento desde el admin de Shopify. Un agregador conviene cuando quiere comparar precio por envío entre transportistas; una app propia del transportista cuando tiene contrato con uno y volumen para negociarlo. **Puntos de recogida.** Shopify no incluye en España un selector nativo de puntos de recogida en el checkout. Se añade con la app del transportista o del agregador, que muestra el mapa de puntos en el checkout o en la página del carrito. Pruébelo en móvil y con Shop Pay activado, porque algunas apps solo funcionan en el flujo de checkout estándar. Si necesita algo que ninguna app cubra, una extensión de checkout a medida es la vía soportada; el artículo sobre [componentes de checkout en Shopify](/shopify-checkout-components) explica qué se puede y qué no. **Devoluciones.** El comprador tiene derecho de desistimiento de catorce días en ventas a distancia. Una política de devoluciones clara en la tienda y un flujo de devolución desde la cuenta del cliente ahorran correos y reducen disputas. Shopify permite gestionar devoluciones desde el admin y algunas apps automatizan la etiqueta de vuelta. ## Shopify Markets para vender fuera de España Si vende a Portugal, Francia, México o Argentina desde la misma tienda, Shopify Markets es la forma de hacerlo sin duplicar nada. Un mercado en Shopify es un país o un grupo de países con su propia moneda, su idioma, sus precios ajustados o redondeados y, si quiere, su dominio o subcarpeta. Desde una sola tienda puede tener /es para España, /pt para Portugal, /mx para México, cada uno con su moneda y su idioma, y Shopify genera las etiquetas hreflang que Google necesita para no confundir las versiones. Un cliente en México ve pesos, textos en español de México si los ha traducido, y las opciones de envío de su zona. Lo que Markets no hace por usted es traducir. Un mercado con moneda cambiada y textos en español de España no está localizado; está convertido. Para Portugal o Francia necesita traducciones reales, y para Latinoamérica conviene al menos revisar vocabulario, tallas y formas de pago, porque las pasarelas que funcionan en México o Colombia no son las de España. El artículo sobre [multimoneda en Shopify](/shopify-multi-currency-india) cubre la parte de monedas y conversión desde una perspectiva distinta, la de India, con reglas que se aplican igual. ## Lo que Shopify hace solo, lo que necesita app y lo que necesita desarrollo Una forma útil de planificar una tienda española es clasificar cada requisito en una de tres cajas. **Shopify de serie:** tarjetas y monederos con Shopify Payments, IVA por país y anulaciones por región y colección, precios con impuestos incluidos, zonas y tarifas de envío condicionales, Markets con moneda e idioma por mercado, descuentos básicos, cuentas de cliente y devoluciones desde el admin. **Con una app:** Bizum a través de la pasarela compatible, etiquetas y seguimiento con transportistas, puntos de recogida, facturas con requisitos españoles, reseñas, email y WhatsApp. **Con desarrollo:** reglas de envío o de pago que dependan de varias condiciones (por ejemplo, ocultar contra reembolso en Canarias y por encima de cierto importe), descuentos escalonados que crucen productos, un selector de puntos de recogida que ninguna app haga como usted quiere, integraciones con su ERP o su programa de facturación. Todo eso corre hoy como Shopify Functions o extensiones de checkout, y la guía sobre [descuentos con Shopify Functions](/es/descuentos-personalizados-con-shopify-functions-adios) explica el primer caso. Saber en qué caja cae cada requisito antes de hablar con una agencia evita pagar desarrollo por lo que una app hace, y evita instalar cinco apps para lo que una extensión resolvería. ## Lista de lanzamiento para una tienda Shopify en España ## Antes de abrir la tienda al público - Bizum activado a través de la pasarela elegida, visible en el checkout y probado desde un móvil con retorno desde la app bancaria - Shopify Payments activo con tarjetas, Apple Pay, Google Pay y Shop Pay - IVA configurado con precios con impuestos incluidos, anulaciones para tipos reducidos y para Canarias, Ceuta y Melilla - Registro de la OSS reflejado en los ajustes de impuestos de la UE si vende fuera de España - App de facturación que cumpla los requisitos españoles, con numeración y NIF, probada con un pedido real - Zonas de envío separadas para península, Baleares, Canarias, y Ceuta y Melilla, con tarifas y plazos propios - Transportistas conectados con etiquetas y seguimiento, y puntos de recogida probados en móvil - Política de devoluciones con los catorce días de desistimiento y flujo de devolución desde la cuenta del cliente - Páginas legales: aviso legal, política de privacidad, cookies con consentimiento, condiciones de compra - Mercados de Shopify Markets creados y traducidos de verdad si vende a Portugal, Francia o Latinoamérica Ninguno de esos puntos requiere una agencia. Lo que una agencia aporta, si la contrata, es hacerlos en el orden correcto, dejar por escrito qué se hizo y resolver la parte de desarrollo cuando la haya. Pídale la lista con cada punto marcado; una que no sepa qué es la OSS o dónde se anula el IVA de Canarias va a aprenderlo con su tienda. Las [preguntas para elegir una agencia Shopify](/es/como-elegir-una-agencia-shopify-12-preguntas) incluyen cómo comprobarlo en la primera conversación. Y si el catálogo grande, las integraciones o el checkout personalizado hacen que el proyecto supere lo que un comerciante puede montar solo, el artículo sobre [cuánto cuesta una tienda Shopify con agencia](/es/agencia-shopify-cuanto-cuesta-una-tienda-2027-precios) sitúa los precios de referencia. **Va a lanzar o a ordenar una tienda Shopify en España** Describa su catálogo, sus transportistas y los países a los que vende, y recibirá un alcance escrito con lo que se configura sin código, lo que necesita una app y lo que requiere desarrollo. [Hablar con ByteInfy](https://byteinfy.com/contact) ## FAQ ### ¿Se puede cobrar con Bizum en Shopify? Sí. Bizum está disponible a través de pasarelas de pago compatibles en España, que se instalan como método de pago adicional en Shopify. ### ¿Cómo configuro el IVA en Shopify para España? En los ajustes de impuestos, con España como país de la tienda, active el cobro de IVA, marque que los precios incluyen impuestos si vende a particulares, y cree anulaciones para los productos con tipo reducido o superreducido. ### ¿Debo mostrar los precios con IVA incluido? Sí si vende a particulares en España o en la Unión Europea. La normativa de consumo exige el precio final con impuestos. ### ¿Qué transportistas funcionan con Shopify en España? Correos, Correos Express, SEUR, MRW, GLS, Nacex y DHL, entre otros, mediante apps de sus propios servicios o de agregadores logísticos que imprimen etiquetas desde el admin. ### ¿Cómo gestiono los envíos a Canarias en Shopify? Con una zona de envío separada para Canarias, tarifas propias y anulación del IVA para esa región. ### ¿Necesito Shopify Markets para vender a Portugal o a México? No es obligatorio, pero es la forma correcta. ### ¿Una agencia extranjera puede configurar bien una tienda española? Sí, siempre que conozca Bizum, el IVA por territorios, la OSS y los transportistas españoles, y acepte que todo eso conste en el alcance por escrito. --- --- title: "Partial Payment on Shopify COD Orders" description: "A customer who has paid something has made a decision. A customer who has paid nothing has taken an option. The gap between those two behaviours at the door is large." author: "Aashish Kaushik" published: 2026-10-01T13:00:38.555Z updated: 2026-10-01T13:00:38.745Z url: https://blog.byteinfy.com/shopify-partial-payment --- # Partial Payment on Shopify COD Orders ## Key takeaways - Partial prepayment works behaviourally rather than financially — the amount barely reduces your exposure, but it converts a free option into a commitment. - It is usually higher-revenue than blocking COD, because blocking removes the order entirely while partial payment keeps it. - Set the threshold from your own RTO data by cart value and pincode, not from a benchmark published by someone with a different catalogue. - Charge enough to represent a real decision and little enough that prepaying in full does not become the obvious choice. Cash on delivery is a free option. The customer takes it at checkout, decides at the door whether to exercise it, and you carry the forward shipping, the return shipping and the tied-up capital either way. Partial payment is the cheapest available way to change that, and the interesting thing about it is that it does not work the way most merchants assume. > **Scope** > > Written for COD-heavy markets, particularly India, where COD is a majority payment method rather than an edge case. ## It is behavioural, not financial The instinct is to think of partial payment as reducing exposure. If the customer pays 15% up front, you are 15% less exposed on a rejected parcel. That is true and it is not the point. Fifteen percent of a small order is a small sum, and it barely dents the cost of a failed delivery — you still pay both shipping legs and the handling. What it actually changes is the customer's relationship to the order. Someone who has paid nothing has deferred a decision. Someone who has paid anything, however little, has made one. The behavioural difference at the door is large relative to the amount collected, which is why token amounts work nearly as well as substantial ones. Understanding this matters practically, because it tells you not to reach for a large percentage. The goal is to create a decision point, not to insure the order. ## Why it beats blocking Blanket COD blocking is what merchants reach for first, and it is usually the more expensive intervention. Blocking removes the order and all its revenue. In a market where COD is a majority payment method, that is not a marginal adjustment — it is removing most of your demand to solve a problem that exists in a minority of it. Partial payment keeps the order, keeps the customer, and changes the economics. The customer who would have accepted the parcel still buys. The customer who was never going to accept it now either commits or does not order, and both outcomes are better than a rejected parcel. ## Interventions compared | Intervention | Effect on order volume | Effect on RTO | Revenue outcome | | --- | --- | --- | --- | | Block COD entirely | Large reduction | Large reduction | Usually negative in COD markets | | COD fee | Small reduction | Moderate reduction | Positive, less than partial payment | | Partial payment | Small reduction | Large reduction | Usually the best available | | OTP verification | Small reduction | Large reduction | Strong, addresses a different cause | | Nothing | None | None | Depends entirely on your RTO rate | The last two rows are worth noting together. OTP verification and partial payment address different causes — verification removes uncontactable buyers, partial payment removes uncommitted ones — so they compound rather than overlap. ## Setting the amount Two failure modes bracket the decision. **Too little** and it does not read as a commitment. A trivial sum feels like a fee rather than a decision, and it produces the conversion cost without the behavioural benefit. **Too much** and the customer reasons they may as well prepay in full. At that point you have not built a partial payment mechanism, you have built a worse prepaid checkout with an extra step. Between those, the specific number matters less than merchants expect. Both fixed amounts and percentages work. Percentages scale better across a wide price range, which matters if your catalogue spans very different values — a fixed amount that is meaningful on a small order is negligible on a large one, and large orders are where RTO hurts most. ## Apply it where the risk is The most common implementation error is applying partial payment to every COD order. RTO risk is not uniformly distributed. It concentrates by cart value, by geography, and by customer history. Applying friction uniformly costs you conversion on the orders that were never a problem. ## Where partial payment earns its cost - Above a cart value threshold set from your own data - Pincodes where your delivery history shows elevated RTO - Customers with a prior rejected COD order - First-time customers placing an unusually large order - Categories with high buyer's remorse, such as fashion sizing - Multiple orders to one address in a short window The threshold should come from your own numbers. Export delivery outcomes, compute RTO rate by cart value band and by pincode, and let that decide where the rule applies. Almost every merchant who does this finds the problem concentrated far more narrowly than assumed — which means the rule can be narrower, and cost far less revenue, than a blanket policy. ## Explaining it to the customer This is where implementations fail on execution rather than on logic. A partial payment requirement that appears without explanation reads as a trick. The same requirement, explained in one line, reads as reasonable — and the explanation that works is straightforward rather than defensive. Say what is being charged now and what is due on delivery, in numbers, before the customer commits. Say why, briefly, without a paragraph of justification. And make the balance due unmistakable on the confirmation and in the delivery message, because a customer who does not have the right cash at the door produces exactly the failed delivery you were preventing. That last point is easy to miss. Partial payment changes the amount due on delivery, and a customer expecting to pay the full price who is asked for a different figure is a customer who may refuse the parcel over confusion rather than intent. ## Measuring it honestly The metric merchants use is conversion rate, and it is the wrong one. Conversion will fall. That is the mechanism working. The number that matters is delivered revenue net of RTO cost, per visitor. That captures both sides — the orders you did not take and the parcels you did not send back — and it is the only figure that tells you whether the intervention helped. A reasonable evaluation: 1. Baseline first. RTO rate and delivered contribution margin, by cart value band and pincode, before changing anything. 2. Introduce the rule narrowly, on the highest-risk segment only. 3. Hold it long enough to clear the noise — weeks, not days, since RTO is only visible after the delivery cycle completes. 4. Compare delivered margin, not order count. 5. Widen or narrow based on what the data shows, rather than on how the order count feels. > **Expect to over-tighten first** > > Merchants almost always set the first rule too strictly, watch order count fall, and panic. Hold it long enough to see delivered revenue rather than gross orders. Loosening from slightly too strict is far easier than finding the right level from a position of accepting everything. ## Reconciliation, refunds and the operational detail Partial payment splits one order across two payment events, and that has consequences downstream that are easy to overlook when the mechanism is being evaluated purely as a conversion lever. **Reconciliation.** The prepaid portion settles through your online payment provider; the balance arrives as cash to your courier or your counter. Those are two different reconciliation paths with different timings, and your finance process needs to expect that. An order is not fully settled until both halves land, and the gap can be days. **Refunds are the awkward case.** A customer who cancels after prepaying is owed the prepaid amount back, and that refund runs through the online provider while nothing was ever collected on the balance. Decide in advance what your policy is — refund in full, refund less a processing cost, or hold as credit — and state it before the customer pays rather than discovering it during a dispute. **Partial delivery.** If an order ships in more than one parcel, or part of it is unavailable, the amount due at the door changes and the prepaid portion no longer maps cleanly to what arrived. This is the most common source of genuine confusion, and the answer is usually to avoid splitting partial-payment orders across shipments where you can. **Accounting treatment.** The prepaid amount is received before the sale completes, which may need handling differently from a straightforward payment depending on how your books are kept. Worth a conversation with whoever maintains them before launch rather than at year end. > **Tell the courier the right number** > > The single most avoidable failure here is a courier collecting the full order value from a customer who already prepaid part of it. Confirm that the balance-due amount, not the order total, is what reaches your delivery partner — and check it on a real order rather than assuming the integration handles it. ## Where it fits with everything else Partial payment is one intervention among several, and the order to implement them in is fairly consistent. **OTP verification first.** Broadest impact, lowest revenue cost, and it addresses the largest single bucket — orders placed with a number that was never reachable. **Partial payment second**, above a threshold your data supports. **Targeted risk rules third**, for the specific pincodes and patterns measurement exposed. **Pre-dispatch confirmation throughout.** A message that lets a buyer cancel before dispatch converts a future RTO into a cancellation, which costs you only the picking. For the full RTO picture and the cost arithmetic behind it, see [checkout and payments](/category/checkout-payments). Payment method selection for Indian stores is covered in the same archive. **Partial payment, OTP and COD rules in one app** ByteInfy's COD & Part Payment app adds partial prepayment, OTP verification via SMS or WhatsApp, and smart COD blocking by pincode, product or cart value. [See it on the Shopify App Store](https://apps.shopify.com/byteinfy-cod-partial-pay) ## FAQ ### What is partial payment on a COD order? The customer pays a portion of the order value online at checkout and the balance in cash on delivery. ### How much partial payment should I ask for? Enough to represent a genuine decision and little enough that the customer does not conclude they may as well prepay in full. ### Is partial payment better than blocking COD? Usually, yes. Blocking removes the order and its revenue entirely. Partial payment keeps the order, keeps the customer, and shifts the economics. ### Will partial payment reduce my conversion rate? Yes, somewhat, and that is the intended effect. The orders it removes are disproportionately those that would have been rejected at the door. ### Can I apply partial payment only to some orders? That is the better implementation. Applying it above a cart value threshold, to unfamiliar pincodes, or to customers with prior RTO history targets the friction where the risk actually is. --- --- title: "Descuentos personalizados con Shopify Functions (adiós Scripts)" description: "Shopify Scripts ya no existe y Shopify Functions ocupa su lugar en todos los planes. Esta guía explica qué descuentos cubre Shopify de serie, cuáles necesitan una Function y cómo encargar una sin pagar de más." author: "Aashish Kaushik" published: 2026-10-01T05:01:04.665Z updated: 2026-10-01T05:01:04.673Z url: https://blog.byteinfy.com/descuentos-personalizados-con-shopify-functions-adios --- # Descuentos personalizados con Shopify Functions (adiós Scripts) ## Key takeaways - Shopify Scripts se ha retirado y toda la lógica de descuento personalizada corre ahora como Shopify Functions, que funcionan dentro del checkout y también en los pagos acelerados como Shop Pay, Apple Pay o Google Pay. - Antes de encargar una Function, agote los descuentos nativos de Shopify: porcentaje, importe, compre X y llévese Y, envío gratis y las reglas de combinación cubren más de lo que parece. - Una Function hace falta cuando la regla depende de varias condiciones a la vez: escalones por cantidad o importe, etiquetas de cliente, metafields, exclusiones o mercados concretos. - Una Function vive dentro de una app, así que el comerciante necesita o una app del App Store construida sobre Functions o un desarrollador que le construya una app propia con su interfaz de configuración. Los descuentos personalizados en Shopify se construyen hoy con Shopify Functions. Scripts, la herramienta que los comerciantes de Shopify Plus usaban para reglas de precio a medida, se ha retirado, y Functions la sustituye en todos los planes, no solo en Plus. La diferencia práctica más importante es que una Function se ejecuta dentro del checkout de Shopify, así que el descuento se aplica igual si el cliente paga con tarjeta, con Bizum a través de una pasarela compatible, con Shop Pay o con Apple Pay. Antes de encargar una Function conviene saber tres cosas: qué descuentos cubre Shopify sin código, en qué punto una regla deja de caber en esa configuración nativa, y qué se está comprando cuando se encarga una. Esta guía va en ese orden. ## Qué ha cambiado con la retirada de Scripts Scripts era código Ruby que corría en el checkout de Shopify Plus para modificar precios, opciones de envío y métodos de pago. Solo existía en Plus, se editaba desde una app propia de Shopify y tenía límites de rendimiento que obligaban a escribirlo con cuidado. Shopify anunció su retirada con años de antelación y pidió a los comerciantes Plus que migraran sus reglas a Functions. Hoy Scripts no se ejecuta, y cualquier tienda que todavía tenga documentación de Scripts debería comprobar que la lógica se reescribió. Es un error más frecuente de lo que parece: una regla de envío gratis para clientes con cierta etiqueta que dejó de funcionar sin que nadie lo notara, porque nada avisa cuando un Script deja de existir. Functions es distinto en tres aspectos que importan al comerciante. Está disponible en todos los planes. Se escribe en JavaScript o Rust y se compila a un formato que Shopify ejecuta en su infraestructura con límites de tiempo muy estrictos, lo que significa que no puede llamar a servicios externos ni ralentizar el checkout. Y vive dentro de una app, propia o del App Store, con lo que la configuración se hace desde esa app y no desde el admin de Shopify. El artículo sobre [migrar de Scripts a Functions](/shopify-scripts-to-functions) recoge el proceso para tiendas Plus que todavía lo tengan pendiente. ## Los descuentos que Shopify cubre sin código La mayoría de comerciantes que piden un descuento personalizado no lo necesitan, y esa es la primera comprobación que una agencia honesta debería hacer. Desde el admin de Shopify, sin ninguna app, se pueden crear descuentos de porcentaje o importe fijo sobre productos concretos, colecciones o todo el pedido; descuentos de compre X y llévese Y con el producto de regalo gratis o rebajado; envío gratis por importe mínimo o por país; y descuentos automáticos que se aplican sin código promocional. Cada uno acepta requisitos mínimos de importe o cantidad, restricciones a segmentos de clientes y límites de uso. Además, cada descuento tiene reglas de combinación: si se puede sumar a otros descuentos de producto, de pedido o de envío. Buena parte de los problemas de descuentos que se pisan o no se aplican se resuelven ahí, sin tocar nada más. La guía sobre [acumulación de descuentos en Shopify](/shopify-discount-stacking) explica esas reglas con ejemplos. ## Reglas de descuento habituales y si necesitan una Function | Regla | Nativo de Shopify | Function | | --- | --- | --- | | 10 % en una colección durante una campaña | Sí | No | | Compre 2 y llévese 1 gratis del mismo producto | Sí | No | | Envío gratis a partir de 60 euros en España | Sí | No | | Descuento distinto según segmento de clientes | Sí, con segmentos | No en la mayoría de casos | | 5 % a partir de 3 unidades, 10 % a partir de 6, 15 % a partir de 12, mezclando productos | No | Sí | | Precio especial para clientes con etiqueta mayorista, solo en ciertos productos | Parcialmente | Sí si hay varias condiciones | | Descuento que excluye productos ya rebajados o con cierto metafield | No | Sí | | Pack de tres productos vendido como uno, con su propio precio | No | Sí, con Cart Transform | | Descuento solo en un mercado de Shopify Markets | Parcialmente | Sí para reglas finas | La regla práctica es sencilla: si el descuento se describe con una sola condición y una sola acción, casi seguro es nativo. Si se describe con "y", "excepto", "según" o "a partir de" varias veces, probablemente sea una Function. ## Cuándo una regla necesita una Function Una Function hace falta cuando la regla depende de varias condiciones a la vez o de datos que los descuentos nativos no leen. **Escalones por cantidad o por importe mezclando productos.** Un 5 % a partir de tres unidades de cualquier producto de una colección, un 10 % a partir de seis y un 15 % a partir de doce. Shopify nativo hace escalones sobre un mismo producto, pero no sobre la suma de varios. Es la petición más frecuente y el artículo sobre [descuentos escalonados en Shopify](/shopify-tiered-discounts) la trata en detalle. **Reglas por etiqueta de cliente o por metafield.** Precio mayorista para clientes etiquetados como tal, solo en ciertos productos y solo a partir de cierta cantidad. Los segmentos nativos cubren la primera condición; las otras dos necesitan código. **Exclusiones.** Un descuento de campaña que no se aplique a productos ya rebajados, a tarjetas regalo, a una marca concreta o a productos con un metafield que indique precio fijo. Las exclusiones son donde los descuentos nativos se quedan cortos con más frecuencia. **Packs y agrupaciones.** Vender tres productos como uno con su propio precio y su propia línea en el pedido no es un descuento sino una transformación del carrito, y se hace con la Function de Cart Transform. La guía sobre [Cart Transform](/shopify-functions-cart-transform) explica la diferencia con un descuento de pack. **Reglas por mercado.** Un descuento que solo exista en México o solo en Portugal, con condiciones distintas por país. Shopify Markets permite precios por mercado, pero las reglas de descuento con condiciones finas por mercado suelen acabar en una Function. Lo que una Function de descuento no puede hacer también conviene saberlo: no puede consultar un servicio externo en tiempo real, no puede leer datos que no estén en el carrito, el cliente o el producto, y tiene un límite de tiempo de ejecución que impide reglas muy pesadas. El artículo sobre [limitaciones de Shopify Functions](/shopify-functions-limitations) recoge las que más sorprenden. ## Los tres tipos de descuento en Functions Las Functions de descuento se organizan por dónde se aplica el descuento, y una misma Function puede combinar varios. **Descuento de producto.** Rebaja líneas concretas del carrito. Es el tipo para escalones por cantidad, precios mayoristas y exclusiones por producto. El cliente ve la rebaja en cada línea. **Descuento de pedido.** Rebaja el subtotal del pedido en conjunto. Es el tipo para reglas por importe total, por segmento de cliente o por combinación de condiciones que no se atribuyen a un producto en particular. **Descuento de envío.** Rebaja o anula el coste de envío según condiciones. Es el tipo para envío gratis por etiqueta de cliente, por mercado o por combinación de productos, más allá del umbral simple que Shopify ya permite. Cuando el comerciante describe su regla, el desarrollador la traduce a uno o varios de estos tipos, y es útil que esa traducción esté escrita antes de programar nada. Una regla mal descrita produce una Function correcta que hace lo que no se quería. > **Escriba la regla en lenguaje llano antes de encargarla** > > La mayoría de Functions que se rehacen no fallaron por código sino por alcance. "Descuento para mayoristas" no es una regla. "Un 20 % en los productos de la colección Mayorista, para clientes con la etiqueta mayorista, a partir de 10 unidades sumando toda la colección, no combinable con códigos promocionales, solo en el mercado de España" sí lo es. Pida que esa frase conste en el presupuesto y que la Function se pruebe contra ella. ## App del App Store o Function a medida Una Function no se instala sola: vive dentro de una app. El comerciante tiene dos caminos. **Una app del App Store construida sobre Functions.** Muchas apps de descuentos por volumen, packs y precios mayoristas se han reescrito sobre Functions después de la retirada de Scripts, y ofrecen una interfaz para configurar reglas sin código. Es la opción correcta cuando su regla es una variante de algo común. Antes de instalar, pregunte al proveedor si el descuento se aplica mediante Functions o modificando el carrito en el tema, porque la segunda vía sigue existiendo y falla con los pagos acelerados. La comparativa de [apps de descuento por volumen frente a packs](/shopify-bundles-vs-volume-discounts) ayuda a decidir. **Una app propia con una Function a medida.** Cuando la regla es específica de su negocio, cuando ninguna app la cubre sin forzarla, o cuando ya tiene tres apps de descuentos y quiere reducirlas a una. Un desarrollador crea una app instalada solo en su tienda, con la Function y una pequeña interfaz para que su equipo cambie los parámetros sin volver a llamarle. El [servicio de extensiones de checkout y Functions](https://byteinfy.com/services/shopify-checkout-extensions) de ByteInfy presupuesta una Function individual entre 1.500 y 3.000 dólares, y los programas de varias reglas en conjunto. La decisión suele reducirse a una pregunta: cuántas veces al año cambia la regla y quién la cambia. Si la cambia marketing cada campaña, necesita una interfaz, y eso se paga tanto en la app del App Store (como cuota mensual) como en la app propia (como desarrollo inicial). Si la regla es estable, la app propia sale más barata a dos años vista. ## Cómo encargar una Function sin pagar de más Encargar una Function es encargar una regla de negocio, y la mayor parte del coste está en definirla bien. ## Antes de pedir presupuesto por una Function de descuento - La regla escrita en una o dos frases, con todas las condiciones y excepciones - Tres o cuatro carritos de ejemplo con el resultado esperado en cada uno, incluido uno que no debe recibir descuento - Qué ocurre si el cliente también tiene un código promocional - En qué mercados y monedas debe funcionar, si vende con Shopify Markets - Quién cambiará los parámetros y con qué frecuencia - Cómo se desactiva en un minuto si algo va mal durante una campaña - Qué apps de descuento existentes se desinstalan cuando la Function esté en marcha Los carritos de ejemplo son lo más valioso de esa lista. Sirven para que el desarrollador entienda la regla sin ambigüedad, sirven como pruebas automáticas, y sirven para que usted valide la entrega sin leer código. Una Function que pasa los cuatro carritos acordados está terminada; una que no, no lo está, y no hay discusión posible. Sobre el alcance, pida explícitamente que la Function se pruebe en el checkout real de una tienda de desarrollo, con Shop Pay activado, y no solo en el carrito. Y pida que la entrega incluya la app en un repositorio al que usted tenga acceso, porque una Function que solo existe en el ordenador del desarrollador es una dependencia, no un activo. ## Descuentos y IVA en España y Latinoamérica Un detalle que afecta a comerciantes en Europa: el descuento se aplica sobre el precio con impuestos incluidos cuando la tienda está configurada para mostrar precios con IVA, que es lo habitual en España para venta a particulares. El importe del descuento que ve el cliente y el que aparece en la factura deben coincidir, y Shopify lo gestiona bien siempre que la configuración de impuestos esté correcta antes de crear la Function. Para tiendas que venden en varios países con Shopify Markets, conviene decidir si el escalón se define en euros y se convierte, o si se define por mercado. Un umbral de 60 euros convertido a pesos mexicanos da una cifra rara; definirlo como 1.200 pesos en el mercado de México queda más limpio y lo puede leer una Function que conozca el mercado del carrito. Ese es un ejemplo de regla que empieza siendo nativa (envío gratis a partir de un importe) y acaba siendo Function en cuanto hay varios mercados con umbrales propios. Para el caso concreto de la venta en España, con Bizum, IVA y transportistas, el artículo sobre [Shopify en España](/es/shopify-espana-bizum-iva-envios) reúne la configuración completa. ## Qué hacer esta semana Si tiene una tienda Plus que usó Scripts, confirme por escrito que todas las reglas se migraron y pruebe cada una en el checkout. Si tiene apps de descuento instaladas, pregunte a cada proveedor si funcionan sobre Functions y pruebe un pedido con Shop Pay. Si tiene una regla que hoy hace a mano (aplicando códigos a clientes concretos, corrigiendo precios en pedidos), escríbala en una frase y compruebe con la tabla de arriba si es nativa o necesita código. Y si necesita código, encargue la regla, no la Function: la frase, los carritos de ejemplo y el interruptor de apagado son lo que se compra. El código es la parte fácil. **Tiene una regla de descuento que Shopify no cubre de serie** Escríbala en una frase con sus condiciones y excepciones, y recibirá una respuesta sobre si es nativa, si existe una app que la cubra o qué costaría como Function propia. [Hablar con ByteInfy](https://byteinfy.com/contact) ## FAQ ### ¿Qué son las Shopify Functions? Son pequeños programas que Shopify ejecuta dentro de su propia infraestructura en el momento del checkout para personalizar descuentos, opciones de envío, métodos de pago, validación del carrito y transformaciones del carrito como los packs. ### ¿Shopify Scripts sigue funcionando? No. Shopify anunció su retirada con antelación y los comerciantes de Shopify Plus que dependían de Scripts tuvieron que migrar sus reglas a Functions. ### ¿Necesito Shopify Plus para usar Functions de descuento? No. Las Functions de descuento están disponibles en todos los planes de Shopify. ### ¿Puedo crear una Function sin saber programar? No directamente. Una Function se escribe en código y se despliega dentro de una app. ### ¿Cuánto cuesta encargar una Shopify Function de descuento? Como referencia, una Function o extensión de checkout individual se presupuesta entre 1.500 y 3.000 dólares en la página de servicios de ByteInfy. ### ¿Los descuentos de Shopify Functions funcionan con Shop Pay y Apple Pay? Sí. Esa es una de las razones principales de su existencia. ### ¿Cómo se combinan varios descuentos en Shopify? Con las reglas de combinación que Shopify permite definir en cada descuento: si se puede combinar con descuentos de producto, de pedido o de envío. Una Function respeta esas mismas reglas. --- --- title: "Shopify Collection Page SEO: Fixing the Structural Problems" description: "Category queries are won by collection pages, and most Shopify collections are a heading, a filter bar and a grid. That is the largest untapped surface on most stores." author: "Aashish Kaushik" published: 2026-09-30T13:00:39.351Z updated: 2026-09-30T13:00:39.363Z url: https://blog.byteinfy.com/shopify-collection-page-seo --- # Shopify Collection Page SEO: Fixing the Structural Problems ## Key takeaways - Category queries are collection-page queries, but most Shopify collections contain no text and cannot compete for them. - Filtered and sorted URLs multiply into thin near-duplicate pages that consume crawl budget without ranking. - Auto-generated collections built on tags proliferate silently, and stores routinely have far more than anyone realises. - Collection content should answer selection questions, not repeat product detail, or it competes with your own product pages. Most Shopify stores treat collections as navigation and product pages as content. Search treats it close to the opposite. A query like "waterproof hiking boots" or "gifts for new parents" is a category query. The page that should answer it is a collection — a page showing the relevant options with enough context to help someone choose. On a typical Shopify store that page is a heading, a filter bar and a grid, with no text at all. That is the largest untapped surface on most stores, and it is untapped mostly because the theme makes it awkward. > **Do the structural work first** > > The content advice below only pays off once the indexation problems are fixed. Writing collection copy on a store where filtered URLs are eating the crawl budget is decorating a room with a leaking roof. ## Count your collections before anything else The first action is arithmetic, and it surprises people. Auto-generated collections built on tags multiply quietly. A tagging scheme that made sense for merchandising produces a collection per tag, most containing a handful of products, all crawlable. Add manual collections created for campaigns that ended, and stores routinely find several times more collections than anyone believed existed. Every near-empty collection is a thin page competing for attention it cannot hold. So before writing anything: - Export the full list and sort by product count. - Anything with two or three products is a candidate for merging, noindexing or deletion. - Anything created for a campaign that ended should be deleted and redirected. - Anything nobody can explain should be investigated before it is removed. Consolidation is usually the highest-return action available, and it costs nothing but decisions. Two cautions before deleting anything. Check traffic first — an old campaign collection occasionally still receives links or search traffic, and that should be redirected rather than dropped. And check whether a collection is referenced by navigation, an app, or an automated feed, because removing one that a product feed depends on causes problems well outside search. ## Filtered and sorted URLs The second structural problem, and the one that shows up most clearly in Search Console. Shopify collections support filtering and sorting, and those produce URLs — `?sort_by=`, filter parameters, tag-filtered paths. On a large catalogue these multiply fast, and each one is a near-identical page containing a subset of the same products. The general position for most stores is that these should be crawlable, so products remain discoverable, but not indexed, so they do not compete with the canonical collection. How to achieve that depends on your theme and filter implementation, which is why generic advice here is unreliable. What is reliable is the diagnostic. Open Search Console's page indexing report and read the "Duplicate, Google chose a different canonical" and "Crawled — currently not indexed" buckets. On most Shopify stores these are filtered collection variants, and the volume tells you how much crawl budget is going somewhere useless. ## Collection indexation audit - Export every collection and its product count - Identify collections with too few products to satisfy a query - Check Search Console for filtered URLs in the duplicate and not-indexed buckets - Confirm pagination beyond page one is not being indexed as a landing page - Check that internal links point at canonical collection URLs consistently - Look for collections created for ended campaigns and still live ## Decide which collections are load-bearing Not every collection deserves content, and treating them equally is why collection SEO projects stall. Usually a small number are commercially load-bearing — they map to real category demand, they contain enough products to satisfy someone arriving from that query, and they are how you would want to be found. Those get a full treatment. The rest exist for navigation and can remain grids. Identify them by combining two things: search demand for the category term, and whether the collection could actually satisfy someone arriving on it. A collection matching a high-volume query but containing four products fails the second test, and sending traffic there is worse than not ranking. ## What collection content should actually say The most common mistake once merchants start writing is producing product copy at the category level. Collection content should answer **selection** questions — the things someone decides between options, not the details of any one option: **What the category covers**, and what it does not. Someone arriving on "walking boots" may want hiking boots, and the page should orient them quickly. **How to choose within it.** The two or three variables that actually differentiate the products. This is the most valuable content on the page and the most commonly missing. **What distinguishes the options you carry**, at a category level — the difference between the entry option and the premium one, in terms a buyer cares about. **The questions asked before committing.** Sizing, care, compatibility, delivery. Your support inbox is the best source for these. What it should not do is repeat product detail. That competes with your own product pages, and duplicated between the two, neither ranks well. Keep the division clean: the collection helps someone choose between options, the product page describes one option fully. ## Where collection content belongs | Position | Content | Why | | --- | --- | --- | | Above the grid | One short orienting paragraph | The shopper came for products, not an essay | | Below the grid | The substantive selection guidance | Available without obstructing the grid | | Below that | Category-level FAQs | Answers extraction-friendly questions | | Never | Long text between heading and products | Delays what the visitor actually wants | The above-and-below split matters. A large block of copy between the heading and the grid delays what the shopper came for and can cost conversion, which is why merchants who try collection content once often abandon it. Split it and both audiences are served. ## Make the template cooperate Most themes render the collection description in one cramped position above the grid, which is why merchants write forty words and stop. If collection content is going to be part of your strategy, the template needs adjusting so there is somewhere sensible for it to go — typically a short field above and a longer field below, with the second usually requiring a metafield rather than the built-in description. That is a small development task, and it is the thing that makes the content work possible rather than painful. Doing the content first, into a template that fights you, is why these projects produce forty-word descriptions on eight collections and then stop. Fix the template once and the writing becomes an ordinary editorial task that someone without developer access can keep doing, which is the difference between a one-off push and a habit. ## Internal linking into collections Collections are usually the worst-linked pages on a Shopify store, and it is a large part of why they underperform. The typical pattern: collections are reachable from the main navigation and almost nowhere else. Products link up to their collection sometimes, breadcrumbs may or may not exist, and blog content links to products rather than categories. The result is that the pages you most want to rank receive the least internal support. Four changes that cost little: **Breadcrumbs on product pages**, linking back to the collection. This is the most reliable collection link on a store and many themes either omit it or render it without markup. **Editorial content linking to collections, not products.** A blog post about choosing walking boots should link to the walking boots collection, because that is the page that should rank for the category. Linking to a single product instead is the most common wasted internal link on Shopify stores. **Cross-links between related collections.** A short "you may also be looking for" between adjacent categories helps both discovery and the link graph. **Consistent anchor text.** Link to the collection using the term it should rank for, not "click here" or "shop now". This is free and routinely skipped. > **Check where your links actually point** > > Crawl your own site and count internal links by destination type. Most Shopify stores discover that products receive the overwhelming majority and collections receive almost none, which is precisely backwards for category-query performance. ## The order to work in 1. Count and consolidate collections. Merge, noindex or delete the thin ones. 2. Fix filtered URL indexation, using Search Console to confirm the problem and the fix. 3. Identify the load-bearing collections — usually a small number. 4. Adjust the template so content has somewhere to live. 5. Write selection-focused content for those collections only. 6. Re-check Search Console after several weeks, and watch which collections start ranking. Steps one and two are finite and stay fixed once done, unless someone installs something careless. Steps three to five are ongoing but only across a small set of pages, which is what makes this tractable for a team without a dedicated content function. For the wider structural picture, see [SEO and AI search](/category/seo-ai-search). Template work and page speed are covered in [storefront and design](/category/storefront-design). **Collections that should rank and do not?** ByteInfy audits and fixes Shopify collection architecture — indexation, consolidation, templates and the content that wins category queries. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Should Shopify collection pages have text on them? The commercially important ones should. A query like "waterproof hiking boots" is a category query, and the page that should win it is a collection. ### How do I stop Shopify filtered URLs being indexed? Filtered and sorted collection URLs generally want to be crawlable but not indexed, so their products remain discoverable while the near-duplicate variants do not compete. The approach depends on your theme and filter implementation. ### Do collection descriptions above the grid hurt conversion? A large block of text between the heading and the products can, because it delays what the shopper came for. ### How many collections should a Shopify store have? Fewer than most stores end up with. Auto-generated collections built on tags multiply quietly, and each near-empty one is a crawlable thin page. ### Should thin collections be noindexed or deleted? If a collection exists for navigation or merchandising but cannot satisfy a search query, noindex is usually right. If it exists for no clear reason, deleting and redirecting is cleaner. --- --- title: "Checklist SEO para Shopify 2027: 25 puntos que importan" description: "La mayoría de las listas de SEO para Shopify repiten consejos de palabras clave. Lo que frena a una tienda suele ser estructural, y estos 25 puntos están ordenados por lo que de verdad mueve posiciones en 2027." author: "Aashish Kaushik" published: 2026-09-30T05:00:42.959Z updated: 2026-09-30T05:00:42.999Z url: https://blog.byteinfy.com/checklist-seo-para-shopify-2027-25-puntos-que --- # Checklist SEO para Shopify 2027: 25 puntos que importan ## Key takeaways - Los problemas de SEO que más pesan en Shopify son estructurales: URLs de producto duplicadas bajo colecciones, canónicas mal resueltas, paginación e índices llenos de páginas sin valor. - Los datos estructurados de producto, organización, FAQ y migas de pan son lo que permite a Google y a los motores de respuesta con IA extraer y citar una tienda con confianza. - La velocidad se mide en páginas de producto y colección con datos de campo, no en la portada con una herramienta de laboratorio, y las apps son la causa habitual de que falle. - Sin Search Console verificado, sitemap enviado e informes mensuales de clics por página de destino, ninguna lista de comprobación sirve para saber si algo mejoró. Una tienda Shopify posiciona o no en 2027 por razones que en su mayoría no tienen que ver con palabras clave. Tienen que ver con URLs de producto duplicadas, canónicas que apuntan a donde no deben, datos estructurados incompletos, plantillas lentas por apps que nadie revisa y contenido que no enlaza con las colecciones que venden. Esta checklist de 25 puntos empieza por lo estructural, que es donde está el impacto, y termina en el seguimiento, que es lo que permite saber si algo cambió. Los puntos están agrupados en siete bloques y ordenados dentro de cada bloque por prioridad. Si solo tiene una tarde, haga los seis primeros. Si tiene una agencia, pídale que le entregue esta lista con cada punto marcado y una nota de qué hizo. ## Estructura de URLs e indexación (puntos 1 a 5) La estructura de URLs de Shopify es fija, y eso es una ventaja y un problema. La ventaja es que no puede romperla. El problema es que trae decisiones de fábrica que no siempre convienen. **1. Enlaces de producto siempre a la URL canónica.** Shopify enlaza cada producto desde /products/nombre y también desde /collections/coleccion/products/nombre. Añade una canónica a la corta, pero si las tarjetas de producto del tema enlazan a la larga, el enlazado interno apunta a la versión no canónica en toda la tienda. Se corrige en el tema, en el snippet de la tarjeta de producto, usando la URL del producto sin el prefijo de colección. El artículo sobre [contenido duplicado en Shopify](/shopify-duplicate-content) explica todas las variantes de este problema. **2. Colecciones con etiquetas y filtros fuera del índice.** Las URLs /collections/nombre/etiqueta y las combinaciones de filtros generan miles de páginas casi idénticas. Compruebe en Search Console cuántas hay indexadas y bloquee las que no aporten búsqueda propia con noindex desde el tema. **3. Variantes que no crean páginas indexables.** El parámetro ?variant= no debería indexarse. La canónica de Shopify lo gestiona bien por defecto; verifique que ninguna app o edición del tema la haya cambiado. **4. Paginación limpia.** Las páginas 2, 3 y siguientes de una colección deben ser rastreables, con enlaces normales y sin canónica forzada a la página 1. Muchos temas lo hacen bien; algunas apps de scroll infinito lo rompen. **5. Sitemap enviado y revisado.** Shopify genera sitemap.xml automáticamente. Envíelo en Search Console y revise cada mes qué URLs del sitemap no están indexadas y por qué. ## Páginas de producto (puntos 6 a 10) La página de producto es la que convierte y la que Google entiende mejor si se le dan los datos correctos. **6. Título y meta descripción propios por producto.** No el nombre del producto y punto: nombre, atributo diferencial y marca, con una descripción que diga a quién sirve. El campo de SEO de cada producto en el admin es donde se edita. Para catálogos grandes, hágalo con reglas a partir de los campos del producto y revise a mano los productos que más venden. **7. Descripción original y útil.** Las descripciones copiadas del fabricante compiten con cientos de tiendas que tienen el mismo texto. Escriba para el comprador que compara: para qué sirve, para quién no, qué incluye, cómo se elige la talla o el modelo. **8. Datos estructurados de producto completos.** Product con nombre, imagen, precio, moneda, disponibilidad, SKU, marca y valoraciones agregadas si las hay. Valide una página de producto con la herramienta de resultados enriquecidos de Google después de cada cambio de tema. **9. Imágenes con nombre de archivo y texto alternativo descriptivo.** El texto alternativo describe la imagen para quien no la ve y para el buscador de imágenes. Una frase que diga qué se ve, no una lista de palabras clave. La guía de [texto alternativo en Shopify](/shopify-image-alt-text-seo) recoge cómo hacerlo a escala. **10. Productos agotados o retirados gestionados.** Un producto que no volverá se redirige a su colección o a su sustituto con una redirección 301 desde el admin de Shopify. Uno que volverá se mantiene publicado con disponibilidad correcta en los datos estructurados. > **El orden importa más que la lista** > > Los diez primeros puntos concentran la mayor parte del impacto en tiendas que llevan un año o más publicadas. Es habitual encontrar tiendas con un blog trabajado y buenos enlaces que no posicionan porque el enlazado interno apunta a URLs no canónicas y las colecciones filtradas han creado veinte mil páginas indexadas. Arreglar eso primero suele mover más que cualquier contenido nuevo. ## Páginas de colección (puntos 11 a 14) Las colecciones son las páginas que deberían posicionar para las búsquedas de categoría, y en la mayoría de tiendas son las más descuidadas. **11. Una colección por intención de búsqueda real.** Si sus compradores buscan "zapatillas de trail mujer", esa colección debe existir con ese título y esa URL, no como un filtro dentro de "zapatillas". Compruebe con el autocompletado de Google qué combinaciones buscan de verdad antes de crear colecciones. **12. Texto de colección que aporte algo.** Un párrafo introductorio y, si la plantilla lo permite, un bloque de texto al final con guía de compra y enlaces a colecciones relacionadas. Es el lugar natural para el contenido que Google usa para entender de qué trata la categoría. El artículo sobre [SEO de páginas de colección](/shopify-collection-page-seo) desarrolla cómo estructurarlo. **13. Colecciones automáticas revisadas.** Las condiciones automáticas son cómodas, pero generan colecciones vacías o con dos productos cuando el catálogo cambia. Una colección vacía indexada es una página de baja calidad a ojos de Google. **14. Migas de pan con datos estructurados.** BreadcrumbList en colecciones y productos ayuda a Google a entender la jerarquía y aparece en los resultados. Muchos temas las muestran visualmente pero no las marcan. ## Velocidad y Core Web Vitals (puntos 15 a 18) La velocidad afecta al posicionamiento a través de Core Web Vitals, que Google mide con usuarios reales por plantilla. La portada es el peor sitio para medirla, porque casi nadie entra por ahí. **15. Datos de campo por plantilla, no puntuación de laboratorio.** Search Console muestra qué grupos de URLs fallan en LCP, INP y CLS. Empiece por las plantillas de producto y colección, que es donde aterriza el tráfico de búsqueda. La puntuación de velocidad del propio Shopify no es Core Web Vitals. **16. Auditoría de apps.** Cada app que inyecta un script en todas las páginas cuesta tiempo de carga aunque solo se use en una. Liste las apps, mida qué cargan y desinstale las que no aporten ventas. Después de desinstalar, revise el tema: muchas apps dejan código detrás. **17. Imágenes con dimensiones y tamaños adecuados.** Anchura y altura declaradas para evitar saltos de diseño, formatos modernos servidos por el CDN de Shopify, y tamaños ajustados a lo que la plantilla muestra. Un tema como Horizon lo hace bien por defecto; los temas antiguos o muy editados, no siempre. **18. Fuentes y scripts que no bloqueen el renderizado.** Fuentes del sistema o precargadas, scripts de terceros diferidos, nada de librerías cargadas en todas las páginas para una sola función. El artículo sobre [velocidad del tema en Shopify](/shopify-theme-speed) explica qué mueve el número y qué no. ## Contenido y enlazado interno (puntos 19 a 21) El contenido sirve para captar búsquedas informativas y para repartir autoridad entre las páginas que venden. Sin la segunda parte, la primera no rinde. **19. Contenido que responda a búsquedas reales y enlace a colecciones.** Guías de compra, comparativas, cómo elegir. Cada artículo enlaza a las colecciones y productos que menciona, y cada colección relevante enlaza de vuelta desde su texto. El [SEO del blog de Shopify](/shopify-blog-seo) tiene sus propias particularidades, empezando por la estructura de URLs de los blogs. **20. Enlazado interno desde las páginas con más autoridad.** Portada, colecciones principales y los artículos con más enlaces externos deberían enlazar a las colecciones que quiere posicionar. Un menú principal bien pensado es enlazado interno en todas las páginas a la vez. **21. Sin páginas huérfanas ni cadenas de redirecciones.** Cada página indexable recibe al menos un enlace interno. Las redirecciones creadas en el admin no deberían encadenarse: A a B a C se convierte en A a C. ## Datos estructurados y motores de respuesta (puntos 22 y 23) En 2027 una parte creciente de las búsquedas se responde con IA, desde AI Overviews de Google hasta asistentes como ChatGPT o Perplexity. Esos sistemas citan las páginas que pueden extraer con claridad y atribuir con confianza. **22. Datos estructurados más allá del producto.** Organization con nombre, logotipo y perfiles sociales en la portada; FAQPage en las páginas que respondan preguntas; Article con autor y fecha en el contenido editorial. Todo validado, sin errores de precio o disponibilidad, porque un error anula el resultado enriquecido. **23. Páginas fáciles de extraer.** Encabezados que digan de qué trata cada sección, la respuesta al principio de cada apartado, un autor identificable y una fecha de actualización real. La guía sobre [GEO para Shopify](/shopify-geo-ai-search) explica cómo se decide qué tiendas cita un motor de respuesta. ## Los 25 puntos por bloque, con el impacto habitual y quién suele hacerlo | Bloque | Puntos | Impacto habitual | Quién lo hace | | --- | --- | --- | --- | | URLs e indexación | 1 a 5 | Alto en tiendas de más de un año | Desarrollador de tema | | Páginas de producto | 6 a 10 | Alto, directo en ventas | Comerciante con reglas, desarrollador para el schema | | Páginas de colección | 11 a 14 | Alto para búsquedas de categoría | Comerciante y redactor | | Velocidad | 15 a 18 | Medio a alto según plantilla | Desarrollador de tema | | Contenido y enlazado | 19 a 21 | Medio, crece con el tiempo | Redactor con criterio SEO | | Datos estructurados y IA | 22 y 23 | Medio, creciente | Desarrollador de tema | | Seguimiento | 24 y 25 | Sin esto no se sabe nada | Comerciante o agencia | ## Seguimiento y medición (puntos 24 y 25) Ninguna lista sirve si no se puede saber qué cambió después de aplicarla. **24. Search Console verificado, con una propiedad por dominio y mercado.** Sitemap enviado, informe de páginas revisado cada mes, informe de Core Web Vitals por plantilla, y alertas de errores de datos estructurados atendidas. Si vende en varios países con Shopify Markets y dominios localizados, cada dominio necesita su propiedad. **25. Informe mensual de clics e impresiones por página de destino, cruzado con ingresos.** No posiciones medias ni tráfico total: qué colecciones y productos reciben clics de búsqueda y cuánto venden. Es el único informe que dice si el SEO está funcionando, y es el que una [agencia de SEO para Shopify](/shopify-seo-agency-what-to-expect) debería entregar sin que se lo pida. ## Cómo aplicar la checklist en una tienda que ya funciona En una tienda nueva, los 25 puntos se hacen en el orden de la lista y en la mayoría de casos en unas pocas semanas. En una tienda que lleva años publicada, el orden cambia según lo que Search Console muestre. ## Los seis puntos para una primera tarde - Abrir el informe de páginas de Search Console y anotar cuántas URLs indexadas son colecciones filtradas, etiquetas o variantes - Comprobar en una tarjeta de producto cualquiera si el enlace incluye /collections/ en la ruta - Validar una página de producto con la herramienta de resultados enriquecidos de Google - Abrir el informe de Core Web Vitals y anotar qué plantillas fallan en móvil - Listar las apps instaladas y marcar las que no se han usado en tres meses - Buscar en Google site:sudominio.com y revisar qué aparece en las dos primeras páginas Con esos seis datos ya sabe si su problema es de indexación, de velocidad, de datos o de contenido, y puede priorizar el resto de la lista con criterio. Lo habitual en tiendas con más de un año es que los bloques 1 y 4 concentren casi todo el problema, y que el contenido, que es donde la mayoría de comerciantes invierte, esté esperando a que se arregle lo de abajo. Si la tienda vende en España y en Latinoamérica, añada una comprobación: que cada mercado en Shopify Markets tenga el idioma y la moneda correctos, el hreflang generado y contenido traducido de verdad, no solo el precio convertido. Google trata una página en español de España y una en español de México como variantes regionales del mismo idioma, y conviene indicárselo bien. Un [servicio de SEO para Shopify](https://byteinfy.com/services/shopify-seo) que empiece por una auditoría técnica, en lugar de por un plan de contenidos, está aplicando exactamente este orden. Si el primer entregable que le proponen es una lista de palabras clave, pregunte por los puntos 1 a 5 antes. **Quiere saber cuántos de estos 25 puntos falla su tienda** Comparta la URL de su tienda y el acceso a Search Console, y recibirá la lista con cada punto marcado, qué cuesta arreglar cada uno y en qué orden. [Hablar con ByteInfy](https://byteinfy.com/contact) ## FAQ ### ¿Shopify es bueno para el SEO? Sí, con matices. ### ¿Por qué Shopify genera URLs duplicadas de producto? Porque enlaza cada producto tanto en /products/nombre como en /collections/coleccion/products/nombre. ### ¿Qué datos estructurados necesita una tienda Shopify? Como mínimo, Product con precio, disponibilidad y valoraciones en cada página de producto, Organization en la portada, BreadcrumbList en colecciones y productos, y FAQPage o Article en el contenido editorial. ### ¿Cómo afecta la velocidad al SEO de Shopify? A través de Core Web Vitals, que Google mide con datos de usuarios reales por plantilla. ### ¿Debo tener un blog en mi tienda Shopify? Solo si va a publicar contenido que responda a búsquedas reales de sus compradores y a enlazarlo con sus colecciones. Un blog con tres entradas de 2023 no ayuda y ocupa presupuesto de rastreo. ### ¿Con qué frecuencia debo revisar esta checklist? Los puntos estructurales, una vez al montar la tienda y cada vez que cambie de tema o instale apps que toquen la plantilla. Los de contenido e indexación, cada mes con Search Console delante. ### ¿Sirve esta checklist para vender en varios países con Shopify Markets? Sí, con un punto extra: cada mercado con dominio o subcarpeta propia necesita hreflang correcto, contenido traducido de verdad y no solo la moneda cambiada, y un sitemap por mercado. --- --- title: "A BFCM Discount Calendar for Shopify Stores (2026)" description: "Most BFCM calendars are a list of dates. This one is a list of decisions, ordered so that each week's work depends only on decisions already made." author: "Aashish Kaushik" published: 2026-09-29T13:00:40.396Z updated: 2026-09-29T13:00:40.399Z url: https://blog.byteinfy.com/bfcm-discount-calendar --- # A BFCM Discount Calendar for Shopify Stores (2026) ## Key takeaways - Black Friday 2026 is Friday 27 November, Cyber Monday is 30 November, and Cyber Week runs 27 November to 3 December. - Offer structure should be settled by late October, because everything downstream depends on it and late changes cause checkout bugs. - Mid-November is the freeze date for discount logic — a change shipped after that has no observation window before peak. - The week after Cyber Monday matters more than most merchants plan for, because it decides whether BFCM buyers become customers. Most BFCM calendars are lists of dates with tasks attached. The problem with that format is that it does not tell you what depends on what, so teams work on the visible items and discover the structural decisions late. This one is ordered by dependency. Each week's work only requires decisions made in earlier weeks, which is what stops a team from building emails against an offer that changes twice. The anchors: Black Friday falls on Friday 27 November 2026, Cyber Monday on 30 November, and Cyber Week runs to 3 December. > **Adjust the dates, keep the order** > > If you are reading this later than October, compress rather than skip. The sequence matters more than the specific weeks, because the dependencies do not change. ## Early October: decide the offer Nothing else can start until this is settled, and it is the week most commonly skipped. **Model two or three candidate offer structures** against contribution margin on real product-level data — not gross margin. Shipping subsidies, payment fees and elevated return rates all move against you during BFCM, and an offer that looks comfortable at gross margin can land near break-even once they are included. **Decide what each offer is for.** Clearing specific stock, raising average order value, acquiring customers, or defending against a competitor. These point at different mechanics, and an offer asked to do all four does none well. **Choose the mechanic, not just the number.** A flat sitewide percentage is the easiest to build and the most expensive, because it discounts your best sellers at the same rate as the stock you actually wanted to move. ## Mid October: lock the mechanics and build **Lock the offer.** Late changes to discount logic are the single largest source of checkout bugs, and every week of delay here compresses the testing window at the other end. **Build in staging.** Every offer, configured as it will actually run. **Decide combination behaviour** for every pair of offers that could be simultaneously active — including discount codes still circulating from earlier campaigns that nobody has expired. **Start the landing pages.** Building them now gives you real URLs to test the discount logic against, and lets them be indexed before the period rather than launching on the busiest day of the year as pages Google has never seen. ## Late October: test and audit **Walk every customer path.** Every offer combination a real shopper could reach, on a real device, including guest checkout and at least one accelerated checkout method completed end to end. **Audit apps.** Anything not currently earning its place adds page weight and a failure mode. Remove it now — not in November, when there is no time to observe the consequences. **Check inventory against the offers.** Gifts, bundle components and buy-X-get-Y items are drawn down by demand for something else, and they are the stock nobody is watching. Set alerts and decide in advance what each offer does when its component runs out. ## Late October verification - Every offer combination tested as a shopper, not as an admin - A complete purchase through each enabled accelerated checkout - Inventory alerts on every gift and bundle component - Page speed measured on landing pages, on a phone, on a slow connection - Old discount codes reviewed and expired - Landing page copy reconciled against the actual discount configuration ## Early November: warm the list **Build the audience before you need it.** Email remains the highest-return BFCM channel, and its return depends on a list that has heard from you recently. The offer should not be the first message a subscriber has received in three months. **Send early access to your best customers.** This shifts some demand off the peak days, which helps fulfilment, and it rewards the people most likely to buy anyway with something better than a public discount. **Finalise creative** — ads, emails, landing page copy. Every headline should repeat its offer's promise word for word, because shoppers scan for confirmation they are in the right place and a paraphrase costs you an expensive click. ## Mid November: freeze **The freeze date is the most valuable line in this calendar.** After it, no changes ship to checkout, cart or discount logic. This is not caution for its own sake. A change needs live traffic afterwards to reveal its problems, and a change made two days before Black Friday has no observation window at all. The reason a late change feels safe is that you have not yet seen it fail. Creative and content can still change. Logic cannot. **Agree the rollback plan.** Know how to disable each offer quickly, and who has access. During peak, the correct response to a misbehaving discount is to turn it off, not to debug it live. ## Cyber Week: watch, do not build 27 November to 3 December. The work now is observation. **Watch order-level margin, not revenue.** Revenue looks good during BFCM almost regardless. Margin per order is what reveals a discount applying that should not be. **Watch the proportion of orders receiving each offer.** A rate that moves sharply overnight means something changed and nobody was told. **Have a person placing test orders**, twice a day. The failures that hurt most are silent ones no alert is configured for. **Write down what breaks, as it happens.** Peak generates a dozen small discoveries everyone is certain they will remember and nobody does. This note is the entire basis of next year's preparation. ## What to watch, and what it means | Signal | Likely cause | | --- | --- | | Margin per order falling | Discounts stacking beyond intent | | An offer's application rate dropping | Stock exhausted, or a date boundary hit | | Checkout completion falling | A discount failing at checkout, or an app degrading | | Support asking about a code | Combination settings, or an unenterable code | | Revenue fine, units down | Discounting deeper than needed | ## The week after Cyber Monday The most under-planned week in the calendar, and the one with the best return available. You have just acquired a large number of first-time buyers, at the highest acquisition cost of the year. Most merchants exhale and let them go quiet, which means the period bought revenue rather than customers. **Send a genuine post-purchase sequence.** Not a receipt. Delivery expectations, how to use the product, what to do if something is wrong. BFCM buyers frequently know nothing about your brand beyond one discounted transaction. **Give them a reason to come back that is not a discount.** Training buyers that you are only worth buying from in November is how BFCM revenue stops being incremental. **Handle returns well.** Return rates are elevated on discounted purchases. A good return experience is one of the few things that converts a discount-driven buyer into a repeat one. ## What to do if you are starting late Most merchants read a calendar like this in November, not October. Skipping straight to the current week is the wrong response, because the earlier weeks contain the decisions everything else depends on. Compress instead. The minimum viable version, in priority order: **One day: model the offer against contribution margin.** Even a rough calculation on your top twenty products will tell you whether the discount you were about to run is survivable. This is the single highest-value hour available to a late starter, because it is the decision that cannot be corrected afterwards. **One day: build and test the offer, including combinations.** Do not skip the combination testing, even under time pressure. It is the failure that costs the most and it is invisible until a customer finds it. **Half a day: expire old codes and audit dead apps.** Fast, and removes two of the most common peak failures. **Then stop adding.** A late starter's instinct is to compensate with more — more offers, more emails, more landing pages. The opposite is correct. One well-tested offer beats three that nobody had time to walk through, and complexity is what breaks under load. What to genuinely drop if time is short: additional offer mechanics beyond the first, extensive landing page work, and anything requiring development. What never to drop: combination testing, an accelerated checkout test, and inventory alerts on gift and bundle components. > **Late is not a reason to skip the freeze** > > A compressed timeline makes the freeze more important, not less. If you build the offer a week before Black Friday, freeze it three days before regardless. The alternative is shipping changes into peak with no observation window, which is how a small configuration error becomes the weekend. ## Mid December onward: account for it honestly **Measure incrementality, not gross revenue.** A share of BFCM sales would have happened anyway at full price. If you cannot estimate that share, you cannot say whether the promotion made money — and a rough estimate from last year's baseline beats the implicit assumption of zero. **Review the note you kept.** Decide what to repeat and what to drop while it is fresh. **Expire everything.** Codes, automatic discounts, banner messaging. Sale messaging left visible in January is a common and damaging error. For offer structure and margin modelling, see the [BFCM 2026](/series/bfcm-2026) series. Checkout verification is covered in [checkout and payments](/category/checkout-payments), and the discount mechanics in [promotions and offers](/category/promotions-offers). **Want the offer logic built and tested before your freeze date?** ByteInfy builds Shopify discount mechanics with Functions — tiered thresholds, gifts, bundles and stacking rules that behave under peak load. [Start a project](https://byteinfy.com/#contact) ## FAQ ### When is Black Friday 2026? Friday 27 November 2026. Cyber Monday is Monday 30 November, and Cyber Week is generally treated as 27 November to 3 December. ### When should I start BFCM preparation? Structural decisions — what the offer is and what it does to margin — want to be settled by late October. ### How long should a BFCM sale run? Longer than the weekend, for most stores. Extended windows spread fulfilment load, reduce the risk of a single-day technical failure destroying the period, and match consumer behaviour, which now starts earlier. ### Should I discount before Black Friday? Early-access offers to your email list work well and shift some demand off the peak days, which helps fulfilment. ### What should I do the week after Cyber Monday? Convert. You have just acquired a large number of first-time buyers at high cost, and most merchants let them go quiet. --- --- title: "Agencia Shopify: cuánto cuesta una tienda en 2027 (precios reales)" description: "Una tienda Shopify hecha por una agencia cuesta en la mayoría de los casos entre 2.000 y 8.000 dólares. Lo que separa un extremo del otro no es el tamaño de la agencia sino el catálogo, las integraciones y cuántas secciones se diseñan desde cero." author: "Aashish Kaushik" published: 2026-09-29T05:00:40.342Z updated: 2026-09-29T05:00:40.534Z url: https://blog.byteinfy.com/agencia-shopify-cuanto-cuesta-una-tienda-2027-precios --- # Agencia Shopify: cuánto cuesta una tienda en 2027 (precios reales) ## Key takeaways - Una tienda Shopify de agencia se mueve en 2027 entre 2.000 y 8.000 dólares; por debajo suele ser un tema instalado con valores por defecto y por encima, headless o integraciones complejas. - Cuatro variables explican casi toda la diferencia de precio, catálogo, integraciones, secciones a medida y lógica de checkout, y conviene tenerlas claras antes de pedir presupuesto. - El presupuesto de la agencia es solo una parte del coste; el plan de Shopify, las apps, las comisiones de pago y el mantenimiento corren por cuenta del comerciante. - Un presupuesto útil detalla partidas, define qué significa terminado, fija la propiedad del código y dice qué podrá editar su equipo sin la agencia. Una tienda Shopify construida por una agencia cuesta en 2027, en la mayoría de los casos, entre 2.000 y 8.000 dólares. La cifra baja corresponde a un tema premium bien configurado con unas pocas secciones propias; la alta, a una tienda con catálogo grande, integraciones y plantillas diseñadas desde cero. Por encima de esa banda están los proyectos headless y los programas de checkout personalizado, que se presupuestan aparte. Esas son las cifras de partida que publica ByteInfy en su [página de servicios](https://byteinfy.com/services), y coinciden a grandes rasgos con lo que un comerciante en España o Latinoamérica verá en presupuestos de otras agencias serias. Lo que cambia entre agencias no es tanto el número como lo que ese número incluye, y ahí es donde conviene leer con atención. Este artículo desglosa los tramos de precio, los factores que los mueven, los costes que no aparecen en el presupuesto de ninguna agencia y las preguntas que separan un presupuesto útil de uno decorativo. ## Los tramos de precio de una agencia Shopify en 2027 Los servicios de una agencia Shopify se agrupan en tramos bastante estables, y conviene conocerlos antes de pedir el primer presupuesto. ## Precios de partida por servicio (ByteInfy, en USD, en el momento de escribir) | Servicio | Desde | Rango habitual | | --- | --- | --- | | Tienda nueva en Online Store 2.0 | 2.000 $ | 2.000 a 8.000 $ | | Personalización de un tema existente | 1.000 $ | 1.000 a 3.000 $ | | Migración desde WooCommerce, Magento o Wix | 1.500 $ | Según catálogo y ERP | | Optimización de velocidad | 750 $ | 750 a 1.500 $ | | SEO técnico y contenidos | 1.000 $ | 1.000 a 3.000 $ al mes | | Extensiones de checkout y Shopify Functions | 1.500 $ | 1.500 a 3.000 $ por función | | App a medida | 3.000 $ | Apps públicas de 8.000 a 25.000 $ | | Storefront headless con Hydrogen | 5.000 $ | Hasta 25.000 $ o más | | Mantenimiento mensual | 500 $ al mes | Según bolsa de horas | La lectura correcta de esa tabla es que una tienda no es un solo servicio. Un comerciante que llega con un tema comprado y quiere tres secciones nuevas está en el tramo de personalización, no en el de tienda nueva. Uno que viene de WooCommerce necesita migración más tienda, y probablemente una revisión de SEO. Sumar los tramos que aplican a su caso da una cifra más fiable que preguntar cuánto cuesta una tienda en abstracto. También conviene fijarse en que los precios se publican en dólares. Una agencia con sede en España o en México presupuestará en euros o en pesos, y la conversión no es lo único que cambia: los impuestos y las condiciones de pago también dependen de dónde esté la agencia, como se explica más abajo. ## Qué incluye una tienda de 2.000 dólares y qué incluye una de 8.000 La diferencia entre el suelo y el techo de la banda está en tres cosas: catálogo, integraciones y secciones a medida. Una tienda cercana a los 2.000 dólares parte de un tema de Shopify (Dawn, Horizon o un tema premium de pago), lo configura con la identidad de la marca, monta las plantillas de producto y colección con los bloques que el tema ya trae, y conecta pagos, envíos e impuestos. Es una tienda que vende desde el primer día y que el propio comerciante puede editar desde el editor de temas. No hay código propio más allá de ajustes menores, y el trabajo de la agencia es sobre todo criterio: qué tema elegir, cómo organizar las colecciones, qué apps instalar y cuáles no. Una tienda cercana a los 8.000 dólares tiene secciones diseñadas desde cero (comparadores de producto, guías de tallas, configuradores), plantillas específicas para campañas, integraciones con sistemas externos (un ERP, un programa de facturación, un servicio de logística) y a menudo alguna extensión de checkout o una Shopify Function para reglas de descuento o envío que Shopify no incluye por defecto. Esa tienda exige diseño en Figma, revisiones semanales sobre una tienda de pruebas y una fase de validación que la de 2.000 no necesita. Entre ambas hay un continuo, y la pregunta útil para su agencia es cuál de esos elementos justifica su parte del precio. Si no sabe responder línea a línea, el presupuesto se ha hecho a ojo. ## Los cuatro factores que mueven el presupuesto Casi toda la variación entre presupuestos se explica por cuatro variables, y merece la pena tenerlas claras antes de la primera llamada. **Tamaño y complejidad del catálogo.** Cincuenta productos con dos variantes cada uno se importan en una tarde. Cinco mil productos con metafields, imágenes por variante y categorías anidadas exigen scripts de importación, validación fila a fila y una estructura de colecciones pensada para el SEO. El catálogo determina también cuántas plantillas distintas hacen falta: una tienda de moda con tallas y colores no se resuelve con la misma plantilla de producto que una tienda de suplementos. **Integraciones.** Cada sistema externo que debe hablar con Shopify añade trabajo: mapeo de campos, pruebas de sincronización en ambas direcciones, gestión de errores y alertas cuando algo falla. Una integración sencilla de pedidos a contabilidad se presupuesta en el tramo de 1.500 a 4.000 dólares; un ERP con stock, precios por cliente y devoluciones, bastante más. Si su negocio ya funciona con un programa de gestión, esa integración suele ser la partida más cara del proyecto y la que más conviene definir antes. **Diseño a medida frente a tema configurado.** Cada sección diseñada desde cero cuesta diseño, maquetación, pruebas en móvil y documentación para que el comerciante pueda editarla después. Un tema premium bien elegido cubre el 80 % de las necesidades de la mayoría de tiendas; el 20 % restante es lo que se paga, y conviene decidir con la agencia si ese 20 % vende más o solo queda más bonito. **Checkout y lógica de negocio.** Descuentos escalonados, reglas de envío por zona, ocultar métodos de pago según el carrito, validar direcciones: todo eso corre hoy como Shopify Functions o extensiones de checkout, y cada una es un pequeño proyecto de desarrollo con su propio presupuesto. Si su modelo de negocio depende de reglas así, cuente con ellas desde el principio en lugar de descubrirlas la semana antes del lanzamiento. Para la decisión de fondo entre tema y desarrollo a medida, el artículo sobre [tema frente a tienda a medida](/shopify-theme-vs-custom) entra en más detalle. ## Los costes que ninguna agencia incluye en el presupuesto El presupuesto de la agencia es la parte visible del coste de una tienda. Hay otra parte que corre por cuenta del comerciante y que conviene sumar antes de decidir, porque puede superar a la primera en el segundo año. **El plan de Shopify.** Basic, Shopify y Advanced tienen cuotas mensuales distintas y comisiones de pago distintas, y la diferencia entre planes se nota sobre todo en las comisiones cuando el volumen crece. Shopify Plus, pensado para tiendas de gran volumen, parte de unos 2.300 dólares al mes con contrato de tres años en el momento de escribir. Consulte la página de precios de Shopify para su país, porque la cuota se factura en moneda local en varios mercados y cambia con cierta frecuencia. **Las apps.** Reseñas, envíos, email marketing, traducciones, buscador. Cada app tiene su cuota mensual, y una tienda media acumula entre cinco y quince sin darse cuenta. El artículo sobre [cuántas apps son demasiadas](/how-many-shopify-apps-is-too-many) explica cómo revisar esa lista y cuáles suelen sobrar. **Las comisiones de pago.** Shopify Payments cobra un porcentaje por transacción que varía por país, plan y método de pago. En España, Bizum se ofrece a través de pasarelas compatibles con sus propias tarifas, además de la comisión de Shopify si no usa Shopify Payments. En Latinoamérica, pasarelas locales como Mercado Pago tienen sus propias comisiones y plazos de liquidación. Ese porcentaje, aplicado a la facturación anual, suele ser el coste más grande de todos. **El mantenimiento.** Shopify actualiza la plataforma de forma continua y retira versiones de API con calendario público. Cualquier cosa a medida necesita revisión periódica. Un retainer de mantenimiento parte de 500 dólares al mes en la tabla de arriba; sin él, el coste aparece de todas formas, pero en forma de urgencias y a peor precio. > **Sobre monedas e IVA** > > Las cifras de este artículo están en dólares estadounidenses porque así las publica la agencia de referencia. Una agencia con sede en España facturará en euros con IVA; una agencia fuera de la Unión Europea facturará sin IVA español, y será el comerciante quien lo declare por inversión del sujeto pasivo si es empresa. Pregunte siempre si el precio incluye impuestos y en qué moneda se factura, y tenga en cuenta el tipo de cambio si paga en dólares desde una cuenta en euros o en pesos. ## Agencia en España, en Latinoamérica o en India: qué cambia en el precio La ubicación de la agencia cambia el precio por hora, pero no necesariamente el precio del proyecto, y esa distinción importa más de lo que parece. Una agencia con sede en Madrid, Barcelona, Ciudad de México o Bogotá tiene costes de estructura más altos que una agencia en India o en Europa del Este, y sus tarifas por hora lo reflejan. Pero una tienda Shopify es un proyecto acotado, y una agencia con experiencia en la plataforma lo hace en menos horas que una que está aprendiendo con su proyecto. El precio final de una tienda de tamaño medio puede acabar siendo parecido; lo que cambia es el margen que queda para diseño, pruebas y soporte. Lo que sí cambia con la ubicación es la conversación inicial. Una agencia que no conoce Bizum, el IVA intracomunitario, la OSS o los transportistas habituales en España tendrá que aprenderlo durante su proyecto. Una que trabaja habitualmente con comerciantes internacionales lo pregunta en la primera llamada y lo pone por escrito. ByteInfy, por ejemplo, tiene sede en India y trabaja con comerciantes de varios países; lo que pide a cada cliente es que las particularidades de su mercado consten en el alcance antes de empezar, porque es ahí donde se pierden los proyectos, no en el código. El artículo sobre [cómo elegir una agencia Shopify](/es/como-elegir-una-agencia-shopify-12-preguntas) recoge las preguntas que sirven para distinguir una agencia que conoce su mercado de una que lo va a descubrir con su dinero. ## Tres tiendas tipo y lo que costarían Unos ejemplos orientativos ayudan a situar su caso en la banda. Son escenarios construidos con los precios de la tabla, no proyectos concretos. **Marca de cosmética con 40 productos, sin integraciones, vende solo en España.** Tema premium configurado, plantilla de producto con bloques de ingredientes y reseñas, Bizum y tarjeta, envíos con Correos y otro transportista, IVA configurado. Está en la parte baja de la banda: entre 2.000 y 3.500 dólares, más el tema si es de pago. Lo que más pesa es el criterio para elegir el tema y ordenar las colecciones. **Tienda de recambios con 3.000 referencias, viene de WooCommerce, tiene un programa de gestión propio.** Migración con mapa de URLs y redirecciones 301, importación validada del catálogo con metafields de compatibilidad, integración de stock con el programa de gestión, plantilla de colección con filtros. Migración desde 1.500 dólares, tienda en la parte media de la banda e integración aparte: en conjunto, entre 7.000 y 12.000 dólares según el estado de los datos de origen. Aquí el riesgo no es el precio sino el SEO, y el artículo sobre [migrar de WooCommerce a Shopify sin perder SEO](/es/migrar-woocommerce-shopify-sin-perder-seo) explica por qué. **Marca de moda que vende en España, Portugal, México y Chile, con descuentos por volumen y reglas de envío distintas por país.** Tienda con secciones a medida, Shopify Markets configurado con monedas y dominios localizados, una Shopify Function para los descuentos escalonados y otra para las reglas de envío, traducciones. Parte alta de la banda más dos funciones de checkout: entre 10.000 y 15.000 dólares. Si además quisiera headless, se dispararía, y probablemente no lo necesita. ## Cómo leer un presupuesto de agencia Shopify Un presupuesto útil se reconoce porque responde a preguntas concretas sin que haga falta hacerlas. ## Lo que debe constar por escrito antes de firmar - Alcance por partidas: tema, secciones, plantillas, integraciones, migración de datos - Qué se considera terminado en cada partida y quién lo valida - Precio fijo o por horas, y qué ocurre con los cambios pedidos a mitad del proyecto - Plazo estimado y dependencias del comerciante (contenidos, imágenes, accesos) - Qué soporte se incluye tras el lanzamiento y durante cuánto tiempo - Quién es propietario del código, del tema y de las cuentas creadas - Moneda, impuestos y calendario de pagos - Qué podrá editar su equipo desde el editor de temas sin llamar a la agencia La partida que más se olvida es la última. Una tienda cuyas secciones solo puede editar el desarrollador convierte un coste único en uno permanente, y es la queja más frecuente de los comerciantes que cambian de agencia. Pida explícitamente que las secciones sean editables desde el editor de temas y que se entregue un registro de cambios con cada archivo tocado. La segunda partida que se olvida es la del soporte posterior. Un presupuesto que cubre el lanzamiento y no dice nada de los treinta días siguientes está describiendo la mitad del trabajo. Las tiendas fallan en la primera semana real, con pedidos de verdad y clientes de verdad, y alguien tiene que estar ahí. ## Cuándo un precio es demasiado bajo y cuándo demasiado alto Los extremos de la banda de precios suelen indicar un problema de alcance, no una ganga ni un abuso. Un presupuesto de 500 dólares por una tienda completa casi siempre significa un tema instalado con sus valores por defecto y los productos cargados a mano. No hay nada malo en ello si es lo que necesita, pero no es una tienda diseñada, y las secciones que pida después se cobrarán aparte y a menudo con prisa. Pregunte qué pasa cuando quiera cambiar algo y quién lo hará. Un presupuesto de 20.000 dólares por una tienda de cien productos sin integraciones merece la pregunta contraria: qué parte de eso es diseño de marca, qué parte desarrollo y qué parte gestión de proyecto. A veces la respuesta es razonable, por ejemplo una marca que necesita identidad visual completa y fotografía. A menudo es headless propuesto por defecto donde un tema bastaría. El artículo sobre [cuándo compensa headless con Hydrogen](/es/shopify-headless-con-hydrogen-cuando-compensa) explica cómo distinguirlo. Entre esos extremos, la señal de calidad más fiable es que la agencia haga preguntas sobre su negocio antes de dar un número. Un presupuesto que llega sin una conversación previa se ha hecho con una plantilla, y las plantillas no conocen su catálogo. ## Cuándo no necesita una agencia Hay casos en los que la respuesta honesta es que no hace falta contratar a nadie, y una agencia seria debería decirlo en la primera llamada. Si vende menos de cincuenta productos, no tiene integraciones y su marca cabe en un tema premium, Shopify está diseñado para que monte la tienda usted mismo. El editor de temas, las plantillas de Horizon y las apps del App Store cubren la mayoría de necesidades de una tienda pequeña. Lo que gana con una agencia en ese caso es tiempo y criterio, no funcionalidades, y puede que ese tiempo valga más invertido en producto y marketing. Si lo que necesita es un cambio puntual (una sección, una página de campaña, arreglar la velocidad), un freelancer o una personalización de tema acotada suele ser mejor valor que un proyecto de tienda nueva. La [personalización de tema](https://byteinfy.com/services/shopify-theme-customization) parte de 1.000 dólares precisamente porque muchos comerciantes no necesitan más que eso. Donde una agencia aporta lo que un comerciante no puede hacer solo es en integraciones, checkout personalizado, migraciones con SEO en juego y tiendas con catálogos grandes. Ahí el coste de equivocarse supera con mucho el coste de contratar, y ahí es donde tiene sentido pagar. **Quiere un presupuesto por partidas para su tienda** Describa su catálogo, sus integraciones y su mercado, y recibirá un alcance escrito con precio fijo y con lo que su equipo podrá editar sin depender de nadie. [Hablar con ByteInfy](https://byteinfy.com/contact) ## FAQ ### ¿Cuánto cuesta una tienda Shopify hecha por una agencia en 2027? En la mayoría de los casos, entre 2.000 y 8.000 dólares. ### ¿Qué incluye una tienda Shopify de 2.000 dólares? Un tema de Shopify o un tema premium configurado con la identidad de la marca, plantillas de producto y colección con los bloques que el tema ya trae, pagos, envíos e impuestos conectados, y una revisión de velocidad y SEO básica. ### ¿Es más barata una agencia Shopify fuera de España? Por hora, normalmente sí. Por proyecto, no siempre, porque una agencia con experiencia necesita menos horas. ### ¿Qué costes no incluye el presupuesto de la agencia? El plan mensual de Shopify, las comisiones de Shopify Payments o de la pasarela que use, las cuotas de las apps instaladas, el dominio y el mantenimiento posterior. ### ¿Cómo sé si un presupuesto de agencia Shopify es demasiado caro? Pida el desglose por partidas y pregunte qué justifica cada una. Un precio alto es razonable cuando hay diseño de marca completo, integraciones o checkout personalizado. ### ¿Cuándo no necesito contratar una agencia Shopify? Si vende pocos productos, no tiene integraciones y su marca cabe en un tema premium, puede montar la tienda usted mismo con el editor de temas y las apps del App Store. ### ¿El precio de una agencia Shopify lleva IVA? Depende de dónde esté la agencia. Una agencia española factura en euros con IVA. --- --- title: "How to Set Up a BOGO Offer on Shopify (2026)" description: "Shopify's native discounts cover more BOGO cases than most merchants realise. Here is what native handles, where it stops, and what to reach for when it does." author: "Aashish Kaushik" published: 2026-09-28T13:01:20.437Z updated: 2026-09-28T13:01:20.447Z url: https://blog.byteinfy.com/how-to-set-up-bogo-on-shopify --- # How to Set Up a BOGO Offer on Shopify (2026) ## Key takeaways - Shopify's native Buy X Get Y discount covers straightforward BOGO offers with no app and no code required. - Native stops at automatic gift insertion, conditional logic beyond its built-in fields, and storefront messaging beyond the cart. - Shopify Functions is the supported route for custom discount logic — legacy Scripts stopped running on 30 June 2026. - The most common implementation error is not the discount itself but failing to test how two offers behave when a shopper qualifies for both. Most articles about setting up BOGO on Shopify begin by recommending an app. That is usually premature. Shopify's native discount system handles a genuine buy X get Y, and a substantial share of merchants install and pay for an app to do something the platform already does. This walks through what native covers, where it actually stops, and what the supported route is when you cross that line. > **Before you start** > > Decide what your offer is in plain language first — which products qualify, what the shopper gets, and what happens if they qualify twice. Half of BOGO implementation problems are specification problems discovered during configuration. ## Setting up a native Buy X Get Y discount In the Shopify admin, discounts live under **Discounts**, and the type you want is **Buy X Get Y**. The configuration asks for four things, and each has a trap worth knowing about. **What the customer buys.** Specific products, specific collections, or a minimum quantity or amount. The trap here is variants: if a product has several variants and you set a minimum quantity, confirm whether the platform is counting across variants or within one. Merchants frequently intend "any two shirts" and configure something that requires two of the same size. **What the customer gets.** The product or collection given free or discounted, and how many. Setting the discounted quantity higher than one is where offers become expensive quickly, so check the arithmetic on a large basket before saving. **How many times it can be used per order.** This is the setting that most often produces a surprise. Left uncapped, a shopper adding ten qualifying items receives five free ones. That may be exactly what you want; it frequently is not. **Combinations.** Whether this discount may combine with product, order or shipping discounts. Configure this deliberately. The default is not always what you would choose, and this is the most common cause of both unintended stacking and offers silently not applying. ## Test these before making the discount live - A basket that just qualifies, and one that just fails to qualify - A basket that qualifies twice over, to confirm the per-order cap behaves - The offer alongside every other active discount and circulating code - Checkout through an accelerated button, not only the standard flow - The whole path on mobile, as a customer who is not logged in ## Where native genuinely stops Four limits, in rough order of how often they force a merchant to reach for something else. **Automatic gift insertion.** Native discounts reduce the price of something already in the cart. They do not put a product there. If your offer is "spend ₹3,000 and receive a free tote", native requires the shopper to find and add the tote themselves — which most will not do, and the offer underperforms for reasons that look like disinterest but are actually friction. **Storefront messaging.** Native discounts are silent until the cart. There is no product-page badge, no collection flag, no progress indicator counting a shopper toward a threshold. For threshold offers this is the difference between the offer working and not, because "you are ₹400 away from a free gift" does work that a static banner does not. **Conditional logic beyond the built-in fields.** Offers conditioned on customer tag, order history, market, or a combination of cart properties are outside what the discount form expresses. **Complex tiering.** Multi-rung ladders, where the reward changes at several thresholds, are awkward to express as several separate discounts that must be prevented from interfering with each other. ## Crossing the line: Functions, not Scripts When you do need custom logic, there is now one supported answer. Shopify Functions is the platform mechanism for custom discount behaviour: it runs server-side, applies at checkout, and holds through accelerated checkouts. The alternative you may still find referenced is Shopify Scripts, the older Plus-only mechanism. It stopped running on 30 June 2026 ([Shopify updates coverage, Fudge](https://www.fudge.ai/blog/shopify-updates-june-2026/), retrieved 2026-09-02). Any guide recommending Scripts is out of date, and any store still relying on them has already had the problem. The distinction that matters when evaluating an app, or a developer, is whether the discount is applied through Functions or by manipulating the cart. Cart manipulation — adding line items, rewriting the cart through the storefront, routing through draft orders — produces the failure mode where a discount is visible in the cart and absent at checkout, or is bypassed entirely by Shop Pay. ## Native, Functions or app | Requirement | Native | Functions | App | | --- | --- | --- | --- | | Simple buy X get Y | Yes | Unnecessary | Unnecessary | | Automatic free gift in cart | No | Yes | Yes | | Product-page offer messaging | No | Needs theme work | Yes | | Conditional on customer tag or history | No | Yes | Depends | | Multi-rung tiered thresholds | Awkward | Yes | Yes | | Holds through Shop Pay | Yes | Yes | Only if Functions-based | | No monthly fee | Yes | Yes | No | The honest reading of that table is that native and Functions together cover almost everything, and what apps genuinely sell is the storefront messaging layer plus not having to commission development. ## Communicating the offer so it actually converts A correctly configured discount that nobody notices performs like no discount at all, and this is where native's silence costs real money. The surfaces that matter, and what to do about each without an app: **Product page.** The highest-value placement, because it is where the add-to-cart decision happens. Native gives you nothing here, but a theme edit can render a badge or line of copy on qualifying products — driven off a collection or a metafield rather than hardcoded, so it disappears when the offer ends without anyone remembering to remove it. **Collection grid.** Offer flags while browsing create discovery. Same approach: a badge conditioned on collection membership. **Cart.** Native does show the discount here once it applies, which is necessary but late. What it does not show is distance to the threshold, and for any spend-based offer that indicator is the mechanic. If you build one thing beyond native, build this. **Post-purchase.** Confirming the discount was applied, itemised, reduces support contacts noticeably. Shoppers who are unsure whether an offer applied will ask, and each of those is a support cost the offer caused. > **Make the end date do the work** > > Whatever you build, drive the visibility from the same source as the discount itself — the collection, the metafield, the date range. Offer messaging left behind after an offer ends is one of the most common and most damaging storefront errors, because a shopper who arrives expecting a discount that no longer exists does not simply shrug. Tie the two together and the problem cannot occur. ## The mistake that costs the most It is not the discount configuration. It is failing to test what happens when a shopper qualifies for two things at once. Offers are usually built one at a time, weeks apart, by someone thinking about that offer in isolation. They then meet each other in a real cart, along with the code you emailed subscribers in September and forgot about. The outcomes are a total discount nobody approved, or a shopper who qualifies for two offers, receives one, and abandons because the number does not match the landing page. Before any offer goes live, list every other discount that could be active — including codes already in circulation — and walk the customer path for each combination. Anything you cannot make behave correctly should be made explicitly non-combinable rather than left to resolve itself at checkout. > **Freeze discount logic before peak** > > Discount logic is the most fragile thing on a store during its highest-traffic week. Set a date beyond which no offer changes ship, and hold it. A change made two days before a sale is a change with no time to observe it. ## After it is live Two things worth doing that most merchants skip. **Check it is actually applying, in production, on a real order.** Place one. The discount that worked in configuration and fails on the live theme is common enough to be worth the price of one order. **Watch inventory on the given item.** A buy-X-get-Y offer consumes stock of the Y product at a rate nobody forecast, because it is driven by demand for X rather than demand for Y. Merchants routinely run out of the free item midway through a campaign and discover it when the discount silently stops applying. Set a stock alert on the given product before launch, and decide in advance what the offer becomes when that item runs out. **Measure the offer, not the app.** Whether the mechanic made money is a question about incremental margin against a control period, not about whether the discount applied correctly. These get conflated constantly, and a merchant concludes an offer "did not work" when what they measured was that it worked exactly as configured on people who would have bought anyway. For the strategic question of which mechanic to run and what it does to margin, see [promotions and offers](/category/promotions-offers). App selection is covered in [Shopify apps](/category/shopify-apps), and BFCM-specific offer structure in the [BFCM 2026](/series/bfcm-2026) series. **Need offer logic native discounts cannot express?** ByteInfy builds custom Shopify discount logic with Functions — conditional offers, automatic gifts and tiered thresholds that hold through checkout. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Can I do BOGO on Shopify without an app? Yes, for straightforward cases. ### Why is my Shopify BOGO discount not applying? The usual causes are a customer eligibility setting narrower than intended, a date range that has not started or has ended, a combination rule preventing it from stacking with another active discount, or the minimum quantity not being met because variants are being counted separately. ### Can a BOGO discount work with a discount code at the same time? Sometimes, depending on how you configure combinations. Shopify distinguishes product, order and shipping discounts and lets you specify which types may combine. Two product discounts generally do not stack. ### Do BOGO discounts work with Shop Pay and other accelerated checkouts? Native discounts do, because they apply at the platform level rather than by modifying the cart. ### How do I automatically add a free gift to the cart? Native discounts do not do this — they discount an item the shopper has already added. Automatic insertion of a gift product requires either an app or custom development. --- --- title: "Shopify in België: Bancontact, btw en verzending" description: "Een Belgische Shopify-webshop draait op vier instellingen die algemene gidsen overslaan: Bancontact, een afhaalpuntenkiezer, btw voor België en de rest van de EU, en een webshop die zowel Nederlands als Frans spreekt." author: "Aashish Kaushik" published: 2026-09-28T05:00:44.248Z updated: 2026-09-28T05:00:44.259Z url: https://blog.byteinfy.com/shopify-belgie-bancontact-btw-verzending --- # Shopify in België: Bancontact, btw en verzending ## Key takeaways - Bancontact is beschikbaar via Shopify Payments in België en moet expliciet geactiveerd worden; zonder Bancontact haakt een aanzienlijk deel van de Belgische kopers af in de checkout. - Shopify heeft geen ingebouwde afhaalpuntenkiezer; bpost en Mondial Relay koppelt u via een vervoerdersapp of een op maat gebouwde checkout-extensie. - Belgische btw geldt voor verkoop in België, en het éénloketsysteem OSS voor verkoop aan de rest van de EU boven de drempel van 10.000 euro; prijzen moeten inclusief btw worden getoond. - Nederlands en Frans naast elkaar regelt u met Shopify Markets en een goed vertaald thema, niet met een tweede webshop. Een Shopify-webshop in België werkt met dezelfde tools als elders, maar vier instellingen bepalen of hij ook echt verkoopt: Bancontact geactiveerd via Shopify Payments, een puntenkiezer voor bpost of Mondial Relay, een btw-instelling die België onderscheidt van de rest van de EU, en Nederlands en Frans naast elkaar netjes geregeld. Geen van deze punten is moeilijk. Ze worden allemaal overgeslagen door gidsen die voor de Amerikaanse markt zijn geschreven, en elk kost bestellingen zodra het ontbreekt. Dit artikel behandelt ze in de volgorde waarin een Belgische ondernemer ze tegenkomt, met wat Shopify van zichzelf doet, wat een app vraagt en wat ontwikkelwerk vraagt. Verkoopt u ook in Nederland, lees dan aanvullend [Shopify in Nederland: iDEAL, Klarna, btw en verzending](/nl/shopify-nederland-ideal-klarna-btw-verzending), want daar wijken betaalmethode en soms het taalregister af. ## Betalen: Bancontact eerst, de rest ernaast Bancontact is beschikbaar via Shopify Payments in België, en dat is de eerste instelling om te doen. Voor een groot deel van de Belgische kopers is Bancontact de standaard betaalmethode, degene die ze zoeken vóór ze een creditcard pakken. Een webshop die Bancontact niet aanbiedt, verliest bestellingen die geen enkele productpagina-optimalisatie terughaalt. De activering gebeurt in de betaalinstellingen van Shopify Payments, met België als land van de webshop. Rond Bancontact hoort de gebruikelijke basis: Visa- en Mastercard-kaarten, Apple Pay en Google Pay voor mobiele kopers, en PayPal voor wie daaraan gehecht is. Shop Pay versnelt de checkout van klanten die het elders al hebben gebruikt. Twee aandachtspunten. Eerst de volgorde in de checkout: Bancontact moet zichtbaar zijn zonder een lijst uit te klappen. Daarna de kosten: elke betaalmethode heeft een eigen tarief in de tarieventabel van Shopify Payments, en een externe aanbieder voegt extra kosten toe bovenop wat Shopify zelf rekent. Bekijk de tabel voor België voordat u kiest. ## Betaalmethoden voor een Belgische webshop | Methode | Beschikbaarheid | Let op | | --- | --- | --- | | Bancontact | Shopify Payments, België | Expliciet activeren, als eerste tonen in checkout | | Visa en Mastercard | Shopify Payments | Standaardbasis, onmisbaar voor Franse en Luxemburgse kopers | | Apple Pay en Google Pay | Shopify Payments | Verkorten mobiele checkout tot één bevestiging | | PayPal | Aparte gateway | Verwacht door een deel van de kopers, aparte kosten | | Shop Pay | Shopify Payments | Nuttig voor klanten die het al elders gebruikten | | Overschrijving | Handmatige betaling | Relevant in B2B, te beheren met een openstaande orderstatus | Voor checkout-aanpassingen, bijvoorbeeld een specifiek bericht tonen per betaalmethode of een optie verbergen op basis van de winkelwagen, loopt alles tegenwoordig via [Checkout Extensibility](/shopify-checkout-extensibility) en Shopify Functions, op vrijwel elk abonnement. ## Verzending: bpost, Mondial Relay en de afhaalpuntenkiezer Shopify heeft geen ingebouwde afhaalpuntenkiezer. Dit is de tweede instelling, en die vraagt een app of ontwikkelwerk. Belgische kopers gebruiken afhaalpunten op grote schaal, omdat thuisbezorging overdag niet uitkomt voor wie werkt. bpost (postkantoren, postpunten en pakjesautomaten) en Mondial Relay (netwerk van punten en kluizen) zijn de twee netwerken om aan te bieden. De keuze van het punt gebeurt in checkout of op de winkelwagenpagina, met een kaart, en het adres van het punt vervangt dat van de klant in de bestelling. Drie manieren om dit te doen. Een vervoerdersapp uit de Shopify App Store die de kiezer toevoegt en het adres van het punt doorgeeft; dit is het snelst. Een koppeling met een multi-vervoerdersplatform dat naast de kiezer ook labels en tracking regelt. Of een maatwerk checkout-extensie voor een webshop die controle wil over weergave en regels, bijvoorbeeld afhaalpunten beperken tot winkelwagens onder een bepaald gewicht. Welke optie u ook kiest, controleer dat de kiezer ook werkt met versnelde checkouts (Shop Pay, Apple Pay). Sommige apps tonen die alleen in de standaardflow, waardoor een deel van de bestellingen zonder afhaalpunt doorgaat. Stel voor de tarieven aparte zones in: België, Frankrijk, Luxemburg, Nederland. De verzendtarieven van bpost naar Frankrijk en van Mondial Relay naar België hebben niets met elkaar te maken, en één tarief voor alles kost óf marge óf verkopen. > **Test de puntenkiezer op een telefoon** > > Het merendeel van de Belgische bestellingen gebeurt op mobiel. Een puntenkiezer met een kaart die op een telefoonscherm onbruikbaar is, is een verkapt verlaten winkelwagentje. Plaats een testbestelling vanaf uw eigen telefoon, met Bancontact, tot en met de bevestiging. ## Btw: België, de EU en het éénloketsysteem Belgische btw geldt voor verkoop in België, die van het land van bestemming voor verkoop in de EU boven een drempel, en Shopify berekent beide zodra de instellingen kloppen. Voor verkoop aan consumenten in België geldt het Belgische tarief, en prijzen moeten inclusief btw worden getoond. De instelling "belasting in prijzen opnemen" van Shopify moet aanstaan, anders komt de btw er in checkout bovenop en ziet de koper een andere prijs dan op de productpagina. Voor verkoop naar Frankrijk, Luxemburg of Nederland geldt de Europese regel van het éénloketsysteem (OSS): onder de 10.000 euro aan jaarlijkse intracommunautaire omzet mag u Belgische btw rekenen; daarboven de btw van het land van bestemming, aangegeven via OSS. Shopify biedt een belastinginstelling per EU-land die deze logica volgt zodra uw OSS-nummer is ingevuld. Twee technische details. Met prijzen inclusief btw en verschillende btw-tarieven per land varieert de prijs exclusief btw per bestemming als de getoonde prijs gelijk blijft, wat het standaardgedrag is. Wilt u een gelijkblijvende marge, dan laat Shopify Markets toe prijzen per markt aan te passen. En B2B-verkoop met een geldig intracommunautair btw-nummer is vrijgesteld; Shopify regelt de vrijstelling per klant zodra het veld is ingevuld en gevalideerd. ## Tweetaligheid: Nederlands en Frans op één webshop Een serieuze Belgische webshop bestaat in het Nederlands en het Frans, en Shopify Markets maakt dat mogelijk zonder tweede webshop. Het mechanisme: een standaardtaal, een tweede taal geactiveerd in de taalinstellingen, en URL's per submap (/fr voor Frans als Nederlands de standaardtaal is, of andersom). Shopify Markets genereert de hreflang-tags per taal en markt, wat Google vertelt welke versie aan wie te tonen. De vertaling zelf doet u met de Shopify-app Translate & Adapt of een app van derden, en daarna handmatig voor de pagina's die verkopen. Een automatische vertaling van uw productteksten naar het Frans valt onmiddellijk op bij Franstalige kopers, en dat kost bestellingen. Drie punten om na activering te controleren. Het thema moet alle vaste teksten (knoppen, winkelwagenberichten, e-mails) vertaald hebben, niet alleen de content; thema's uit de Theme Store leveren de taalbestanden, maatwerkontwikkeling moet ze toevoegen. De checkout volgt de taal van de klant. En notificatie-e-mails moeten in beide talen bestaan. ## Kosten: wat een Belgische webshop kost om te draaien De kosten van een Belgische Shopify-webshop bestaan uit het abonnement, betaalkosten, apps en, eventueel, het bureau. Het Shopify-abonnement wordt maandelijks betaald, afhankelijk van het plan. De transactiekosten van Shopify Payments gelden per bestelling, met een tarief dat afhangt van de betaalmethode en het land van de kaart; Bancontact en kaarten hebben niet hetzelfde tarief, en een Franse kaart op een Belgische webshop is een Europese transactie, geen binnenlandse. De tarieventabel van Shopify Payments voor België is gepubliceerd en wordt bijgewerkt; raadpleeg die in plaats van een artikel. Apps vormen de derde post. Puntenkiezer, klantreviews, e-mail, vertaling: elke app heeft een maandabonnement. Een typische Belgische webshop heeft er vier of vijf nodig; daarboven controleert u of Shopify het werk niet al zelf doet, zoals besproken in [wat een webshop echt kost](/nl/shopify-bureau-kosten-2027-wat-webshop-echt-kost). Het bureau, als u er een inhuurt, wordt apart geoffreerd. Bij ByteInfy begint een verkoopklare webshop bij $2.000 en een aanpassing van een bestaand thema bij $1.000, in Amerikaanse dollars op het moment van schrijven. Voor een Belgische onderneming valt een dienst van een aanbieder buiten de EU meestal onder de verleggingsregeling voor btw. ## Wettelijke vermeldingen en Belgische verplichtingen Een Belgische webshop moet een aantal gegevens tonen, en Shopify levert de plekken zonder de inhoud te leveren. Verplichte vermeldingen: naam, ondernemingsnummer (KBO), adres, contactgegevens en het btw-nummer. Algemene verkoopvoorwaarden in het Nederlands en het Frans. Het herroepingsrecht van veertien dagen voor verkoop op afstand aan consumenten, met het modelformulier. Een privacybeleid conform de AVG, en een cookiebanner die toestemming vraagt. Shopify biedt sjablonen voor beleid, in het Engels, om te vertalen en aan te passen. De cookiebanner kan die van Shopify zijn of een app; in beide gevallen moet die trackingscripts blokkeren vóór toestemming, wat vereist dat pixels via de Customer Events van Shopify laden en niet los in het thema zijn geplakt. ## Lancering van een Belgische Shopify-webshop - Bancontact geactiveerd in Shopify Payments en als eerste zichtbaar in checkout - Puntenkiezer bpost of Mondial Relay getest op mobiel, ook met Shop Pay - Aparte verzendzones voor België, Frankrijk, Luxemburg en Nederland - Prijzen inclusief btw getoond, Belgisch tarief als standaard, EU-tarieven per land ingesteld met OSS-nummer - Btw-vrijstelling voor B2B-klanten met gevalideerd intracommunautair nummer - Nederlands en Frans geactiveerd, thema en e-mails vertaald, hreflang gecontroleerd - Wettelijke vermeldingen, voorwaarden en herroepingsrecht in beide talen - Cookiebanner die pixels daadwerkelijk blokkeert vóór toestemming - Volledige testbestelling vanaf een telefoon tot en met bevestiging en e-mail ## Wanneer een bureau nuttig is, en wanneer niet Een Belgische webshop op een thema uit de Theme Store, met een eenvoudige catalogus en een vervoerdersapp, stelt u zonder bureau in door bovenstaande punten te volgen. Een bureau wordt nuttig zodra een van de vier instellingen buiten het gewone kader valt: een puntenkiezer met bijzondere regels, gemengde B2B- en B2C-btw, een maatwerkthema om te vertalen, of een koppeling met boekhoudsoftware of een ERP. Het is onmisbaar bij een migratie vanaf een ander platform, waar redirects en tweetalige Belgische SEO zich afspelen op de dag van de overstap, zoals besproken in [WooCommerce naar Shopify migreren zonder SEO-verlies](/nl/woocommerce-naar-shopify-migreren-zonder-seo-verlies). De SEO van een Belgische webshop volgt dezelfde regels als elders, met tweetaligheid erbij. De [Shopify SEO checklist](/nl/shopify-seo-checklist-2027-25-punten-tellen) behandelt de 25 punten, waaronder die voor meerdere markten. **Start of neemt u een Shopify-webshop in België over** Beschrijf uw catalogus, uw vervoerders en uw talen, en u krijgt een schriftelijke scope met wat zonder code te regelen is en wat ontwikkelwerk vraagt. [Praat met ByteInfy](https://byteinfy.com/contact) ## FAQ ### Werkt Bancontact op Shopify? Ja. Bancontact is beschikbaar via Shopify Payments voor webshops die vanuit België verkopen en wordt geactiveerd in de betaalinstellingen. Het verschijnt daarna als optie in de checkout naast kaarten en digitale wallets. ### Hoe bied ik bpost of Mondial Relay aan op Shopify in België? Shopify levert geen ingebouwde afhaalpuntenkiezer. U heeft een vervoerdersapp nodig die de puntenkaart toevoegt aan checkout of winkelwagen, of een maatwerkintegratie met een checkout-extensie. ### Welke btw reken ik op een Belgische Shopify-webshop? Belgische btw voor verkoop aan consumenten in België. Voor verkoop naar andere EU-landen de btw van het land van bestemming via het éénloketsysteem OSS, zodra u de drempel van 10. ### Heb ik een aparte webshop nodig voor het Frans? Nee. Shopify Markets biedt één webshop met twee talen, submappen per taal en automatisch gegenereerde hreflang-tags. Een tweede webshop verdubbelt het werk aan catalogus en onderhoud zonder SEO-voordeel. ### Wat kost een Shopify-webshop in België? Het Shopify-abonnement, transactiekosten van Shopify Payments die per betaalmethode verschillen, appabonnementen (vervoerder, reviews, e-mail) en, indien u er een inhuurt, het bureau. ### Moeten prijzen inclusief btw worden getoond? Ja, voor verkoop aan consumenten in België en de EU. ### Kan een buitenlands bureau een Belgische webshop goed instellen? Ja, als het Bancontact, afhaalpunten, OSS en tweetaligheid kent en bereid is die punten schriftelijk in de scope op te nemen. --- --- title: "Headless Shopify met Hydrogen: wanneer het loont" description: "Headless is niet standaard sneller en niet standaard beter. Het koopt controle, en controle is alleen zijn prijs waard als u er iets specifieks mee wilt doen." author: "Aashish Kaushik" published: 2026-09-27T13:00:48.887Z updated: 2026-09-27T13:00:48.903Z url: https://blog.byteinfy.com/headless-shopify-met-hydrogen-wanneer-loont --- # Headless Shopify met Hydrogen: wanneer het loont ## Key takeaways - Headless verwijdert de themalaag en geeft volledige controle over de front end, tegen de prijs van alles zelf bouwen en onderhouden wat het thema leverde. - Het is niet automatisch sneller; een slecht gebouwde headless webshop is ruim langzamer dan een goed gebouwd Liquid-thema. - De sterkste echte gevallen zijn ongebruikelijke front-end-eisen, één front end over meerdere backends, en React-kennis die al in huis is. - De verborgen kosten zijn alles wat het thema-ecosysteem gratis gaf: appblokken, de thema-editor en zelfredzaamheid voor de ondernemer. Headless wordt aanbevolen om redenen die geen stand houden bij nader onderzoek, vooral snelheid en een algemeen gevoel dat het moderner is. Beide zijn zwakke redenen, en ze volgen levert dure projecten op die uiteindelijk langzamer zijn dan het thema dat ze vervingen. De architectuur is oprecht waardevol in specifieke omstandigheden. Dit artikel probeert die precies te benoemen, en is even precies over de kosten, die stelselmatig worden onderschat. > **De vraag die alles kadert** > > "Wat gaan we bouwen dat een thema niet kan?" Is het antwoord niet direct en specifiek, dan is het antwoord een thema. ## Wat headless echt verandert U stopt met het gebruiken van de themalaag van Shopify. Shopify blijft uw backend, producten, voorraad, orders, checkout, en u bouwt de storefront zelf, met bevragingen op de Storefront API. Hydrogen is het React-framework van Shopify hiervoor, meestal gehost op Oxygen. Het neemt een deel van het infrastructuurwerk weg dat oudere headless-bouwsels duur maakte, en het is de ondersteunde route. Wat u wint, is volledige controle over de front end. Wat u verliest, is alles wat de themalaag voor u deed, en die lijst is langer dan de meeste projecten vooraf inschatten. ## Snelheid is niet de reden De meest gehoorde rechtvaardiging, en de zwakste. Headless maakt een storefront niet snel. Het verhoogt het prestatieplafond, omdat u precies bepaalt wat laadt en wanneer. Dat plafond bereiken vraagt discipline die veel projecten niet volhouden. Ondertussen is een zware React-storefront die een groot JavaScript-bundel verzendt ruim langzamer dan een goed gebouwd Liquid-thema, vooral op de middenklasse mobiele toestellen die het meeste commerce-verkeer voor hun rekening nemen. De eerlijke vergelijking is niet headless tegenover een langzaam thema. Het is headless tegenover een goed geoptimaliseerd thema waarvan onnodige apps zijn verwijderd, en de meeste webshops die headless overwegen voor snelheid hebben dat goedkopere werk nog niet gedaan. Dat doen herstelt meestal het grootste deel van de beschikbare winst tegen een fractie van de kosten, zoals besproken in [Shopify theme vs custom](/shopify-theme-vs-custom). ## De gevallen waarin het echt loont Vier, en ze hebben gemeen dat een thema het ding helemaal niet kan. **Een front-end-ervaring die thema's niet kunnen uitdrukken.** Een echt ongebruikelijke interactie, een configurator, een sterk afwijkend navigatiemodel. Niet "we willen het op maat" (thema's kunnen prima op maat), maar interactie die het themamodel structureel niet ondersteunt. **Eén front end over meerdere backends.** Shopify voor commerce, een apart CMS voor redactionele content, andere systemen daarnaast, gepresenteerd als één ervaring. Dit is een sterk argument, en een dat thema-gebaseerde webshops onhandig afhandelen. **Bestaande React-kennis en zin om die te gebruiken.** Een team dat al React-applicaties bouwt en onderhoudt, neemt veel minder nieuw risico dan een team dat dat niet doet. Andersom: headless als eerste React-project oppakken is twee problemen tegelijk aannemen. **Contentrijke commerce.** Waar redactie en commerce echt door elkaar lopen en de balans richting redactie neigt, kan een maatwerk front end over beide bronnen schoner zijn dan het in een commercethema forceren. ## Genoemde reden en oordeel | Genoemde reden | Oordeel | | --- | --- | | "Het wordt sneller" | Zwak, optimaliseer eerst het thema | | "Het is moderner" | Geen reden | | "We hebben een maatwerkinteractie nodig die thema's niet kunnen" | Sterk | | "Eén front end, meerdere backends" | Sterk | | "Ons team bouwt al React" | Ondersteunend, niet voldoende | | "We willen meer ontwerpcontrole" | Zwak, thema's staan veel toe | | "Ons bureau raadde het aan" | Vraag wat het specifiek mogelijk maakt | ## De kosten die worden onderschat **Storefront-apps stoppen met werken.** De grootste. Apps die in de webshop worden getoond, leunen op theme app extensions, die een maatwerk front end niet heeft. Reviews, upsells, videowidgets, aanbiedingsmeldingen: functionaliteit die u nu krijgt door iets te installeren, wordt functionaliteit die u bouwt en onderhoudt. Inventariseer uw storefront-apps voordat u zich vastlegt; de lijst is meestal langer dan verwacht. **Ondernemers verliezen de thema-editor.** Welke contentbewerking uw team ook doet, het wordt iets dat u bouwt, via metafields, metaobjecten of een apart CMS. Slaat u dit over, dan wordt elke tekstwijziging een ticket voor de ontwikkelaar, precies het knelpunt dat de meeste teams proberen te ontlopen. **U bezit de front end voor altijd.** Framework-upgrades, onderhoud van dependencies, browsercompatibiliteit en toegankelijkheid worden allemaal uw verantwoordelijkheid. Een thema krijgt updates van de maker; uw storefront krijgt alleen wat u er zelf in stopt. **De eigen front-end-verbeteringen van Shopify komen niet meer aan.** Platformwerk aan thema's en storefrontprestaties bereikt een maatwerk front end niet. Over meerdere jaren stapelt dit zich stilletjes op, en het is onzichtbaar op het moment dat u de beslissing neemt. ## Vóór u voor headless kiest - Benoem het specifieke ding dat een thema niet kan - Lijst elke storefront-app op waarvan u afhankelijk bent en wat die vervangt - Beslis hoe ondernemers content gaan bewerken, en bouw het - Bevestig dat u React-kennis heeft om het te onderhouden, niet alleen te bouwen - Optimaliseer eerst uw huidige thema en meet wat dat oplevert - Begroot doorlopend onderhoud, niet alleen de bouw ## Hydrogen versus het zelf bouwen Gaat u headless op Shopify, dan is Hydrogen de logische standaardkeuze. Het is het ondersteunde framework van Shopify, het handelt de Storefront API-integratie idiomatisch af, en Oxygen neemt hostingbeslissingen weg. Zelf iets bouwen met een ander framework is verdedigbaar bij specifieke eisen die Hydrogen niet goed dient, of bestaande infrastructuur die u uitbreidt in plaats van vervangt. Het betekent dat meer van het integratiewerk voor u is, en minder van het ecosysteem van toepassing is. Voor de meeste teams is de vraag niet welk framework, maar of headless überhaupt de juiste route is. Is die vraag positief beantwoord, dan is Hydrogen meestal het antwoord op de tweede vraag. ## Wat wel en niet verandert aan de checkout Een veelvoorkomend misverstand dat het waard is recht te zetten: headless gaan betekent niet dat u uw eigen checkout bouwt. De checkout blijft van Shopify. Uw maatwerkstorefront regelt browsen, productpagina's en winkelwagen, en draagt daarna over aan de Shopify checkout voor betaling. Dat is bewust en het is goed: checkout is het risicovolste onderdeel van elke webshop, brengt verplichtingen rond betalingscompliance met zich mee, en Shopify verbetert het doorlopend. Drie gevolgen. **Checkout Extensibility blijft van toepassing.** UI-extensies, Functions voor korting- en verzendlogica, en branding via de admin werken allemaal op dezelfde manier. Uw investering daarin gaat niet verloren als de storefront verandert, zoals beschreven in [Checkout Extensibility](/shopify-checkout-extensibility). **De overdracht is een ontwerpprobleem.** Een klant die van uw maatwerkstorefront naar de Shopify checkout gaat, steekt een visuele grens over. Brandinginstellingen verkleinen de kloof maar heffen die niet op, en een schokkerige overgang op het moment van betalen kost conversie. Plan dit overgangspunt. **De status van de winkelwagen moet de overgang overleven.** Dit is gewoon werk in plaats van moeilijk werk, maar het is wel werk, en het is een plek waar headless-bouwsels subtiele bugs oplopen, een korting die op de storefront is toegepast maar niet meegaat, of een winkelwagen die leeg is bij terugkeer. ## De migratie zelf plannen Beslist u dat headless de juiste keuze is, dan brengt de migratie risico's met zich mee die niets met de architectuur te maken hebben en alles met het in één keer vervangen van een hele front end. **URL's mogen niet veranderen.** Elke product-, collectie- en content-URL zou zich precies moeten oplossen als voorheen. Dit is het grootste SEO-risico van het project en volledig te vermijden, zoals uitgebreider besproken in [migreren zonder SEO-verlies](/nl/woocommerce-naar-shopify-migreren-zonder-seo-verlies) voor het geval van een volledige platformwissel. **Structured data moet opnieuw worden opgebouwd.** Uw thema stuurde product-schema mee. Uw maatwerkstorefront stuurt wat u zelf schrijft, en het is makkelijk om zonder de lucht in te gaan en het maandenlang niet te merken. **Server-side rendering is geen keuze.** Content die alleen in de browser wordt gerenderd, is content die sommige crawlers en agents niet betrouwbaar zien. Hydrogen rendert standaard server-side; het risico zit in wat er later aan wordt toegevoegd. **Laat de twee parallel draaien als het kan.** Eerst een subset templates migreren, of de nieuwe storefront op een staging-domein met echte data laten draaien, brengt problemen naar boven terwijl de oude webshop klanten nog steeds bedient. > **Meet vóór en na, op dezelfde manier** > > Neem Core Web Vitals, conversieratio en organisch verkeer als nulmeting vóór de overstap. Headless-migraties vallen vaak samen met een verandering in verkeer, en zonder nulmeting kunt u een migratieprobleem niet onderscheiden van een seizoensgebonden probleem, ze zien er de eerste maand identiek uit, precies wanneer u het moet weten. ## Een goedkopere tussenweg De moeite waard om te kennen vóór u zich vastlegt, want het vervult een groot deel van de motivatie tegen een fractie van de kosten. Moderne Shopify-thema's zijn aanzienlijk flexibeler dan de reputatie doet vermoeden, en het blokgebaseerde systeem van Horizon met geneste samenstelling heeft dat verder verbreed. Een goed gebouwd maatwerkthema kan de meeste ontwerpen uitdrukken, en het behoudt app-compatibiliteit, de thema-editor en platformverbeteringen. Voor de meeste webshops waarvan de motivatie ontwerpcontrole is, is een maatwerkthema het juiste antwoord. Headless is voor wanneer de beperking structureel is in plaats van esthetisch. Een nuttige test vóór u zich in een van beide richtingen vastlegt: laat een ontwerper de storefront ontwerpen die u echt wilt, en vraag daarna een ervaren Shopify-ontwikkelaar of een thema dat kan bouwen. Is het antwoord ja met wat maatwerk, wat meestal het geval is, dan heeft u uw antwoord, en heeft u dat vóór het uitgeven van het budget in plaats van erna. ## Wat het kost, en wanneer u hulp inschakelt Een headless project op Hydrogen begint bij $5.000 volgens de gepubliceerde prijzen op de [dienstenpagina headless Shopify van ByteInfy](https://byteinfy.com/services/headless-shopify-hydrogen), en loopt op tot $25.000 of meer met een eigen contentmodel, multi-market en koppelingen. Dit bedrag komt bovenop, niet in plaats van, de posten uit [wat een webshop echt kost](/nl/shopify-bureau-kosten-2027-wat-webshop-echt-kost), waar headless de hoogste categorie is, niet het gebruikelijke startpunt. Vraag voordat u een offerte aanvraagt of het bureau u de kaderende vraag heeft gesteld, en niet gewoon de brief heeft aangenomen zoals die is. De vragen om aan elk bureau te stellen, inclusief over precies deze beslissing, staan in [een Shopify bureau kiezen](/nl/shopify-bureau-kiezen-12-vragen-vooraf). **Weet u niet of u headless nodig heeft of een beter thema** ByteInfy bouwt beide, maatwerk Shopify-thema's en Hydrogen-storefronts, en vertelt u eerlijk welke van de twee uw eisen echt rechtvaardigen. [Praat met ByteInfy](https://byteinfy.com/contact) ## FAQ ### Is headless Shopify met Hydrogen sneller dan een gewoon thema? Niet vanzelf. Headless geeft controle over wat er laadt en wanneer, wat uitstekende prestaties bereikbaar maakt. ### Wat is Hydrogen? Het React-gebaseerde framework van Shopify voor het bouwen van maatwerk storefronts tegen de Storefront API, meestal gehost op Oxygen, Shopify's hosting daarvoor. ### Werken Shopify-apps met een headless storefront? Apps die zichtbaar zijn in de webshop meestal niet, omdat ze leunen op theme app extensions die een maatwerk front end niet heeft. Apps aan de admin-kant blijven werken. ### Kunnen ondernemers een headless storefront nog zelf aanpassen? Niet via de thema-editor, die is niet van toepassing. Welke contentaanpassingen ondernemers ook nodig hebben, die moeten gebouwd worden, meestal via metafields, metaobjecten of een apart contentsysteem. ### Wanneer kies ik beter niet voor headless? Als uw enige reden snelheid is, als uw team geen React-kennis heeft, als u afhankelijk bent van storefront-apps, of als het eerlijke antwoord op "wat gaan we bouwen dat een thema niet kan" onduidelijk is. ### Wat kost een headless project met Hydrogen? De gepubliceerde startprijzen beginnen bij $5.000 voor een afgebakende Hydrogen-storefront, en lopen op tot $25.000 of meer met een eigen contentmodel, multi-market en koppelingen. --- --- title: "Een Shopify bureau kiezen: 12 vragen vooraf" description: "Een portfolio bewijst dat er iets is gelanceerd. Het zegt niets over of het nog werkt, wie het onderhoudt of wat het in iemands thema heeft achtergelaten. Deze twaalf vragen halen naar boven wat een portfolio niet laat zien." author: "Aashish Kaushik" published: 2026-09-27T05:01:19.587Z updated: 2026-09-27T05:01:19.779Z url: https://blog.byteinfy.com/shopify-bureau-kiezen-12-vragen-vooraf --- # Een Shopify bureau kiezen: 12 vragen vooraf ## Key takeaways - De nuttigste vraag is wat een bureau twee jaar geleden bouwde en of het nog werkt; Shopify faseert API-versies uit op een vast schema, en een ervaren bureau heeft dat meerdere keren meegemaakt. - De technische antwoorden die ertoe doen zijn concreet, theme app extensions voor wat zichtbaar is in de webshop, Shopify Functions voor kortingen en checkoutregels, en een geschreven proces voor deprecaties. - Eigendom van de code, documentatie en wat uw team zelf kan aanpassen zonder het bureau spreekt u vooraf schriftelijk af, want achteraf zijn dat ongemakkelijke gesprekken. - Een bureau dat u vertelt wat u niet moet bouwen, oefent oordeel uit, en dat oordeel is wat u eigenlijk koopt; een bureau dat overal mee instemt, verkoopt scope. Een Shopify bureau kiezen is lastig omdat het werk onzichtbaar is voor wie het koopt. U ziet de webshop en niet de code, en het verschil tussen beide wordt pas zichtbaar zodra er achttien maanden later iets moet veranderen. De twaalf vragen in dit artikel zijn bedoeld om dat verschil zichtbaar te maken vóór u tekent, niet erna. Portfolio's helpen daar weinig bij. Ze tonen dat er iets gebouwd en gelanceerd is. Ze zeggen niets over of het nog werkt, wat het gekost heeft om te onderhouden, of wat het heeft achtergelaten in iemands thema. De vragen hieronder zijn verdeeld in vier blokken, oud werk, techniek, eigendom en markt, en aan het eind staat een tabel om antwoorden te duiden, waarschuwingssignalen en hoe u de eerste opdracht opzet. > **Geschreven door een bureau** > > Lees dit met dat in het achterhoofd. De vragen hieronder zijn wat wij zouden verwachten dat ons gevraagd wordt, en een bureau dat er ongemakkelijk van wordt, verdient voorzichtigheid, wijzelf inbegrepen. ByteInfy is gevestigd in India, werkt met ondernemers uit meerdere landen en publiceert startprijzen op zijn [dienstenpagina](https://byteinfy.com/services); de rest van dit artikel gaat niet over onszelf. ## Vragen over het werk dat ze al deden De eerste drie vragen kijken terug, want wat een bureau twee jaar geleden bouwde, zegt meer over het bureau dan wat het volgende maand belooft te bouwen. ### 1. Wat heeft u twee jaar geleden gebouwd, en werkt het nog? De meest onthullende vraag die er is, en hij wordt bijna nooit gesteld. Iedereen kan iets lanceren. Interessant is wat daarna gebeurde: draait het nog, was er spoedwerk voor nodig, heeft het de platformwijzigingen sindsdien overleefd. Shopify brengt elk kwartaal een nieuwe API-versie uit en faseert oude uit op een bekend schema; Scripts bestaan niet meer en hun functies zijn overgegaan naar Shopify Functions; checkout.liquid is vervangen door Checkout Extensibility; thema's zijn veranderd met Online Store 2.0 en later met Horizon. Een bureau met meerdere jaren op het platform heeft dat allemaal meegemaakt, en hoe het daarmee omging is een beter signaal dan welke succescase dan ook. Vraag om een concrete webshop of app te zien, met datum, en vraag wat ze sindsdien hebben moeten aanpassen. Een bureau dat "niets" antwoordt, liegt of heeft niet gekeken. ### 2. Welk project ging mis, en wat heeft u ervan geleerd? Elk bureau met geschiedenis heeft projecten die niet liepen zoals gepland. Wie dat erkent en uitlegt wat er in het proces is veranderd, toont volwassenheid; wie zegt dat het nooit is gebeurd, toont weinig ervaring of weinig eerlijkheid, en beide kosten geld. ### 3. Mag ik spreken met een klant die al langer dan een jaar bij u zit? De referenties die een bureau standaard aanbiedt, zijn van recente, tevreden klanten. Vraag om een oude. Een klant die er al meer dan een jaar bij zit, kan vertellen hoe de support na de lancering was, hoe wijzigingen werden aangepakt en of de eindfactuur in de buurt kwam van de eerste inschatting, precies de dingen die een portfolio niet laat zien. ## Technische vragen De volgende vier hebben concrete juiste antwoorden, en zijn informatief ook als u ze niet volledig kunt beoordelen. Kent iemand die u vertrouwt Shopify, laat die dan meeluisteren. ### 4. Hoe integreert u wat zichtbaar is in de webshop? Het antwoord hoort theme app extensions en thema-secties te zijn. Een bureau dat nog code in themabestanden injecteert, bouwt iets dat de ondernemer niet netjes kan verwijderen, en dat residu is de meest gehoorde klacht van wie een webshop van een ander bureau erft. Vraag ook wat er in het thema achterblijft bij het verwijderen van een van hun apps; het goede antwoord is "niets dat u niet zelf heeft gevraagd". ### 5. Hoe zou u een korting bouwen die Shopify niet standaard biedt? Shopify Functions. Stellen ze voor om de winkelwagen met JavaScript te manipuleren of een app te gebruiken die prijzen on the fly aanpast, dan wordt dat gedrag overgeslagen door versnelde checkouts en stopt het met werken zodra Shopify iets wijzigt. Kortings-, verzend- en betaalregels leven vandaag in Functions en checkout-extensies, en een bureau dat in 2027 op Shopify werkt, weet dat. Het artikel over [kortingen bouwen met Shopify Functions](/nl/kortingen-bouwen-met-shopify-functions-scripts-zijn-gestopt) laat zien wat wel en niet kan. ### 6. Hoe gaat u om met API-deprecaties? Er hoort een proces te zijn: een inventarisatie van wat ze hebben gebouwd, een schema en iemand die het bewaakt. "Dat pakken we op als het zich voordoet" betekent dat u het merkt zodra het breekt, waarschijnlijk midden in een campagne. Vraag wanneer ze voor het laatst een app of koppeling hebben aangepast vanwege een deprecatie en wat ze daarvoor in rekening brachten. Het artikel over [Shopify API-versionering](/shopify-api-versioning) legt uit waarom dit geen bijzaak is. ### 7. Hoe test u wat u oplevert? Er hoeft geen uitgebreid antwoord te komen, maar er moet er wel een zijn, zeker voor alles dat geld raakt: kortingen, betalingen, belastingen, verzending. Een testwebshop, een gedupliceerd thema vóór publicatie, testbestellingen met elke betaalmethode. Is het antwoord "we testen zorgvuldig op de echte webshop", dan is uw echte webshop de testomgeving van het bureau. ## Vragen over eigendom en oplevering De volgende drie zijn commercieel, en bepalen of u uiteindelijk een bezit of een afhankelijkheid overhoudt. Ze zijn makkelijk aan het begin en ongemakkelijk aan het eind, dus stelt u ze aan het begin. ### 8. Wie is eigenaar van de code, en welke documentatie krijg ik? Wat u afspreekt, en daarom spreekt u het vooraf schriftelijk af. Opdrachtgevers gaan er vaak van uit dat maatwerk van hen is; bureaus willen vaak herbruikbare componenten behouden. Beide posities zijn redelijk. Niet redelijk is het pas ontdekken bij het einde van de samenwerking. Over documentatie is de nuttige vraag of de volgende ontwikkelaar het werk zou kunnen voortzetten zonder het bureau te bellen. Een changelog per bestand, toegang tot de repository en een uitleg van elke koppeling is het minimum. ### 9. Wat kan mijn team zelf aanpassen zonder u? De post die het vaakst wordt vergeten. Een webshop waarvan alleen de ontwikkelaar de secties kan aanpassen, maakt van een eenmalige kostenpost een blijvende. Vraag expliciet dat secties bewerkbaar zijn vanuit de thema-editor, dat campagneteksten en -beelden geen code vereisen, en dat het u wordt getoond in een demo vóór het project als afgerond geldt. ### 10. Wat gebeurt er na de lancering, en wat kost dat? Alles wat maatwerk is, heeft onderhoud nodig, omdat Shopify doorlopend verandert. Een offerte die de lancering dekt en niets zegt over de maanden erna, beschrijft de helft van de kosten. Vraag of er support is inbegrepen en voor hoe lang, of ze een retainer aanbieden en wat daarin zit, en wat er gebeurt met toegang en repositories als de samenwerking stopt. ## Vragen over uw markt De laatste twee hangen af van waar u verkoopt, en scheiden een bureau dat uw markt kent van een bureau dat het met uw geld gaat leren. ### 11. Welke bijzonderheden van mijn markt horen in de scope? Verkoopt u in Nederland, dan hoort het antwoord iDEAL, btw en OSS als u ook aan andere EU-landen verkoopt, PostNL of een ander verzendplatform en facturen met KvK- en btw-nummer te bevatten. Verkoopt u in België, dan hoort Bancontact, het tweetalige karakter van uw webshop en bpost of Mondial Relay erbij. Een bureau dat dat niet vraagt, leert het tijdens uw project. De artikelen over [Shopify in Nederland](/nl/shopify-nederland-ideal-klarna-btw-verzending) en [Shopify in België](/nl/shopify-belgie-bancontact-btw-verzending) verzamelen wat er in elke markt moet kloppen. Let erop dat de vestigingsplaats van het bureau niet de vraag is. Een bureau buiten uw land dat deze vragen bij het eerste gesprek stelt en schriftelijk vastlegt, voldoet; een bureau in uw eigen stad dat dat niet doet, niet. Het artikel over [kosten van bureaus in India versus de VS](/shopify-agency-india-usa-cost) zet in perspectief wat werkelijk verandert met de vestigingsplaats. ### 12. Wat zou u mij afraden om te bouwen? De nuttigste vraag van het hele gesprek, en die bewaart u expres voor het laatst. Een bureau zonder antwoord verkoopt scope. Een bureau dat zegt "u heeft geen headless nodig", "dat kan een thema" of "die app bestaat al en kost minder dan wij" oefent oordeel uit, en dat oordeel is wat u eigenlijk koopt. Hetzelfde geldt voor uw eigen opdracht: vraagt u om een maatwerkwebshop en is het eerlijke antwoord dat een ingesteld thema u beter zou dienen, dan wilt u dat vóór de offerte horen, niet na de factuur. Het artikel [Headless Shopify met Hydrogen: wanneer het loont](/nl/headless-shopify-met-hydrogen-wanneer-loont) gaat dieper in op precies deze afweging. Een bureau dat het met alles eens is wat u voorstelt, heeft ofwel ongewoon veel geluk met zijn klanten, of denkt niet goed na over de opdracht die voorligt. ## Hoe u antwoorden interpreteert Antwoorden zijn niet goed of slecht op zichzelf; het zijn signalen, en het is handig vooraf helder te hebben welk signaal welk is. ## Wat elk antwoord zegt | Vraag | Antwoord dat geruststelt | Antwoord dat zorgen baart | | --- | --- | --- | | Werk van twee jaar geleden | Een concreet voorbeeld en wat is aangepast | "Alles is nog hetzelfde" of geen voorbeeld | | Project dat misging | Een casus en een procesverandering | "Dat is ons nooit overkomen" | | Hoe ze het zichtbare integreren | Theme app extensions en bewerkbare secties | Code in themabestanden | | Maatwerkkortingen | Shopify Functions, met de beperkingen erbij | Winkelwagen of prijzen manipuleren met JavaScript | | API-deprecaties | Inventarisatie, schema en verantwoordelijke | "Dat pakken we op als het zich voordoet" | | Testen | Testwebshop en gedupliceerd thema | Testen op de echte webshop | | Eigendom van de code | Schriftelijk, met repository en documentatie | "Dat bespreken we later wel" | | Wat uw team aanpast | Demo van de thema-editor vóór afronding | Alles loopt via het bureau | | Onderhoud | Vastgestelde support en optionele retainer met prijs | Komt niet voor in de offerte | | Uw markt | Vragen naar lokale betalingen, belastingen, verzending | Offreren zonder te vragen | | Wat niet te bouwen | Een concrete, onderbouwde lijst | Alles wat u voorstelt is prima | Een bureau hoeft niet alle twaalf goed te beantwoorden. Wat u zoekt, is een patroon. Twee of drie zwakke antwoorden op procesvragen kunnen een jong bureau met goed technisch oordeel zijn; zwakke antwoorden op eigendom, onderhoud en "wat niet te bouwen" samen beschrijven een bureau dat projecten verkoopt, geen resultaten. ## Waarschuwingssignalen Er zijn patronen die terugkeren bij projecten die slecht aflopen, en ze zijn al in het eerste gesprek te zien. **Offerte zonder vragen.** Een bureau dat een bedrag stuurt zonder te begrijpen wat u verkoopt, offreert met een sjabloon, en sjablonen kennen uw assortiment niet. **Inschatting zonder onderhoud.** Al genoemd, maar het meest voorkomende en duurste signaal. **Terughoudendheid over oplevering.** Zijn eigendom en documentatie aan het begin ongemakkelijke onderwerpen, dan worden ze aan het eind erger. **Standaard de duurste optie.** Headless waar een thema zou volstaan, maatwerk waar een bestaande app het doet. **Geen voorbeeld van oud werk dat nog draait.** Ofwel doen ze dit nog niet lang, ofwel is het oude werk niet iets waarover ze willen praten, en beide is nuttig om te weten. **Weigering om met uw huidige ontwikkelaar te praten.** Heeft u er een, dan zet een bureau dat die als bedreiging behandelt in plaats van als bron van context, de relatie boven het resultaat. **Prijzen ver onder de bandbreedte.** Een complete webshop voor $500 is bijna altijd een thema met standaardinstellingen en handmatig ingevoerde producten. Daar is niets mis mee als dat is wat u nodig heeft, maar het is niet wat de offerte suggereert. Het artikel over [wat een Shopify webshop echt kost](/nl/shopify-bureau-kosten-2027-wat-webshop-echt-kost) plaatst de prijsbandbreedtes en legt uit wat er aan elk uiterste zit. ## Hoe u de eerste opdracht opzet Hoe u het eerste werk organiseert, telt net zo zwaar als wie u kiest, want het bepaalt hoeveel u leert vóór u zich verder vastlegt. ## Vóór u tekent, schriftelijk - Scope per onderdeel en wat "klaar" per onderdeel betekent - Wie eigenaar is van de code en wat er gebeurt met herbruikbare componenten - Welke documentatie wordt opgeleverd en in welk formaat - Wie het gebouwde na de lancering onderhoudt en tegen welke kosten - Wat er gebeurt met toegang en repositories als de samenwerking stopt - Hoe API-deprecaties worden aangepakt en wie de updates betaalt - Wat uw team zonder het bureau kan doen, aangetoond in de thema-editor - De bijzonderheden van uw markt (betalingen, belastingen, verzending, facturatie) als scope-onderdelen - Valuta, belastingen en betalingsschema **Begin met iets afgebakends.** Een gedefinieerd project met een duidelijk eind, een audit, een koppeling, een campagnesjabloon, leert u hoe een bureau werkt tegen een fractie van het risico van een hele webshop. **Let op de eerste verrassing.** Elk project stuit op iets onverwachts. De reactie is veel informatiever dan het voorstel: brengen ze het vroeg met opties, of absorberen ze het stilzwijgend en noemen ze het pas als de deadline schuift. **Vergelijk de inschatting met het resultaat.** Niet om de afwijking af te straffen, inschattingen zijn inschattingen, maar omdat hoe het bureau erover communiceert, anticipeert op hoe een groot project zal zijn. **Vraag om de code te zien**, ook als u die niet volledig kunt beoordelen. Laat iemand ernaar kijken, of controleer minstens dat die in een repository staat waar u toegang toe heeft, gedocumenteerd is en niet één enorm bestand is. ## Bureau, freelancer of eigen team Er is geen universeel juist antwoord, en de verschillen zijn redelijk duidelijk. **Een freelancer** is vaak beter geprijsd voor afgebakend werk, en u heeft rechtstreeks contact met wie het bouwt. Het risico is beschikbaarheid later: de ontwikkelaar die uw koppeling bouwde, is misschien niet bereikbaar als die moet worden bijgewerkt. **Een bureau** is logisch zodra continuïteit telt, meerdere disciplines nodig zijn (ontwerp, ontwikkeling, SEO, koppelingen) of het werk doorlopend is. U betaalt deels voor het feit dat er altijd iemand zal zijn. Het risico is betalen voor een structuur die uw project niet nodig heeft. **Een eigen team** past bij webshops met doorlopende ontwikkelbehoeften en genoeg werk om de aanstelling te rechtvaardigen. Onder die drempel is het dure, ongebruikte capaciteit. Een gebruikelijke en verstandige combinatie is een bureau of freelancer voor afgebakende projecten, met genoeg interne capaciteit voor routinematige wijzigingen en om te beoordelen wat wordt opgeleverd. Wilt u de Engelse versie van dit betoog, met meer detail over hoe u een bureau briefeert, die staat in [een Shopify-ontwikkelbureau inhuren zonder te gokken](/hire-shopify-development-agency). En welke keuze u ook maakt, de regel verandert niet: beschrijf het probleem, niet de oplossing. "Onze mobiele productpagina's verliezen bezoekers vóór de koopknop" geeft een bureau iets om op te lossen. "Bouw ons een maatwerkthema" geeft een instructie die de verkeerde kan zijn. **Wilt u een eerlijk antwoord over wat u nodig heeft** Vertel wat u verkoopt, waar en wat er niet werkt, en u hoort wat te bouwen, wat niet en wat elk onderdeel zou kosten, schriftelijk en vóór enige verplichting. [Praat met ByteInfy](https://byteinfy.com/contact) ## FAQ ### Waar moet ik op letten bij het kiezen van een Shopify bureau? Bewijs dat wat ze bouwen standhoudt. Vraag naar werk van twee jaar geleden, hoe ze API-deprecaties aanpakken, of wat zichtbaar is in de webshop theme app extensions gebruikt, en welke documentatie u krijgt. ### Is een Nederlands of Belgisch bureau beter dan een buitenlands bureau? Wat telt is niet de vestigingsplaats maar of het bureau uw markt kent en dat schriftelijk vastlegt. ### Bureau of freelancer voor een Shopify-project? Een freelancer is vaak beter geprijsd voor afgebakend werk, en u heeft rechtstreeks contact met wie het bouwt. Een bureau is logisch zodra continuïteit telt, meerdere disciplines nodig zijn, of het werk doorlopend is. ### Hoe weet ik of een Shopify bureau goed is vóór ik het inhuur? Begin met een klein, afgebakend project, een audit, een koppeling of een sjabloon, en let op hoe ze communiceren, hoe goed hun inschatting klopt en hoe ze reageren op de eerste verrassing. ### Wie is eigenaar van de code die een bureau schrijft? Wat u afspreekt, en daarom spreekt u het vooraf schriftelijk af. Opdrachtgevers gaan er vaak van uit dat maatwerk van hen is; bureaus willen vaak herbruikbare componenten behouden. ### Wat kost een Shopify bureau? Dat hangt af van de scope, en het bedrag dat het meest telt is dat van het onderhoud. Een webshop van een bureau ligt meestal tussen $2.000 en $8.000; een thema-aanpassing begint bij $1. ### Welke signalen betekenen dat ik een bureau beter kan overslaan? Dat het offreert zonder naar uw bedrijf te vragen, onderhoud niet noemt, het gesprek over eigendom en oplevering ontwijkt, standaard headless of maatwerk voorstelt, geen oud werk kan tonen dat nog draait, en uw huidige ontwikkelaar als bedreiging behandelt. --- --- title: "Using TikTok UGC on Your Shopify Storefront" description: "TikTok content works on a storefront for the same reason it works in a feed — it looks real. The parts that go wrong are rights, placement and page weight." author: "Aashish Kaushik" published: 2026-09-26T13:01:21.595Z updated: 2026-09-26T13:01:21.635Z url: https://blog.byteinfy.com/tiktok-ugc-shopify --- # Using TikTok UGC on Your Shopify Storefront ## Key takeaways - UGC is credible precisely because it is visibly not a studio production, so polishing it away destroys the thing that made it work. - Rights are the step most stores skip — a creator agreeing to a repost has not agreed to commercial storefront use. - Feed content and product-page content have different jobs, and the best-performing TikTok is often the worst product-page clip. - Own the file. Embedding TikTok's player gives you their layout, their script on your page, and a video that vanishes if the post is deleted. TikTok content works on a product page for the same reason it works in a feed: it looks like a person, not a brand. That credibility is the whole asset, and it is remarkably easy to destroy by polishing it, cropping it wrongly, or licensing it carelessly. This covers finding it, getting the rights properly, deciding what belongs where, and doing it without a page-speed cost that cancels the benefit. > **Start with rights** > > Everything below assumes you have permission. If you take one thing from this article, take that section — it is the part with actual legal consequences and the part most commonly skipped. ## Rights, before anything else A creator posting publicly about your product has not licensed you to use that video commercially. Tagging your brand is not consent. Enthusiasm is not consent. Sending you the video is closer, but still is not a licence unless it says so. What you need is explicit permission covering storefront use specifically. In practice that means asking, in writing, and being clear about: - Where it will appear — your product pages, your homepage, your ads if applicable. - For how long. Perpetual is cleaner for you and a bigger ask; a defined term is easier to get. - Whether you may edit it. You will want to trim and recut, and that should be agreed. - What happens if they later object. Have a process for taking something down. ## Rights, per video - Written permission from the creator, covering commercial storefront use - Agreement on editing, since you will need to trim and reformat - Consent from anyone else identifiable in the video - Audio checked separately — platform music licences rarely travel - A record you can find in two years, not a message in a DM inbox - A defined path for withdrawal if the creator changes their mind Audio deserves its own line. Music licensed for use on TikTok is licensed for TikTok. The same track on your storefront is a different use under a different licence. The practical answer is to replace the audio or use clips that work muted, which most product video should anyway — the majority of storefront views are silent. ## Finding what already exists Most stores have more UGC than they realise, and they have never looked. Search your brand name and your product names on TikTok. Check your tagged mentions. Look at the hashtags around your category. Stores routinely discover a body of content made by customers they were never aware of. This is a better starting point than commissioning, for three reasons: it exists already, it has engagement data telling you what resonated, and the creator has already demonstrated genuine enthusiasm — which is not something you can brief into existence. When you approach creators, being specific helps. "May we use this specific video on our product page for our hiking boots, for a year, with editing?" gets a much higher response rate than a general partnership enquiry, because it is a small, clear request rather than the start of a negotiation. ## Feed content and product-page content are not the same The judgement most stores get wrong. A TikTok in a feed competes for attention against everything else. It front-loads a hook, moves fast, and frequently withholds information to hold the viewer. That is correct for the feed and wrong for a product page, where the shopper has already chosen the product and wants a specific question answered. ## What transplants to a product page | Clip type | Product page | Discovery placement | | --- | --- | --- | | Demonstration or how-to | Excellent | Good | | Fit or scale on a real person | Excellent | Good | | Honest review with specifics | Excellent | Fair | | Unboxing | Good | Good | | Trend or audio-led format | Poor | Good | | Pure entertainment | Poor | Fair | The rule for product pages: choose clips that answer a question a shopper is actually asking. For homepage carousels and collection placements, the feed-native content is fine, because the job there really is to catch attention. ## Edit for the storefront, but do not sand it down Imported clips usually need small changes, and there is a line between necessary and destructive. **Necessary:** trim the scroll-stopping hook, since the shopper has already stopped. Make it work muted, with captions if needed. Cut it shorter — product-page clips are trending under 30 seconds. Remove platform furniture like "link in bio" overlays, which are confusing on a page where the product is right there. Choose the poster frame deliberately, because the autoplay-optimised first frame is often a blurred motion frame that looks broken as a still. **Destructive:** colour-grading it to match your brand palette, adding your logo bug, re-recording the audio in a brand voice, or cutting it so tightly that the person disappears. Each of these moves the clip toward looking like an advert, and looking like an advert is exactly the property that makes UGC stop working. The test is simple: if the edited version could plausibly have been made by your marketing team, you have edited too much. Shoppers are considerably better at detecting this than marketers expect, and the detection is instant and unconscious. ## Own the file Two ways to get TikTok content onto a Shopify page, and only one is sensible. **Embedding the TikTok post** loads TikTok's script on your page, renders in their layout, gives you no product tagging or add-to-cart, and disappears entirely if the creator deletes the post, goes private, or their account is suspended. You are building your product page on something you do not control. **Downloading the file, with permission, and hosting it** through a shoppable video app gives you a video in your layout, with products attached and purchase inside the player. This is what the format is for. Whichever app you use, keep unedited masters in your own storage. Every future migration problem is trivial if you have the source files and expensive if you do not. ## Page weight, again Video is the heaviest thing you can add to a product page, and this is where video projects quietly fail — the store adds UGC, conversion does not move, and nobody connects it to product pages loading a second slower. Nothing heavy should download before a shopper indicates interest. A lightweight poster image with width and height set, so the layout does not shift. Player and video file on interaction only. Nothing video-related loading on pages with no video. Autoplay, if used, muted, short and limited to one element. ## Paying creators, and when it is worth it Permission is free to ask for and often freely given. Paying changes the relationship, and it is worth understanding what you are buying. **Paying for usage rights** on content that already exists is the cheapest form of paid UGC. The video is made, you have seen it perform, and you are buying certainty and a longer licence rather than commissioning an unknown. For content you actually want on a product page, this is usually good value. **Commissioning new content** costs more and carries production risk — you are paying before you know whether the clip works. It makes sense when you have a specific gap: a product with no existing UGC, or a question none of your current clips answers. **Ongoing creator relationships** are the most expensive and the most useful at scale, because a creator who understands your products makes better content the second time. Two cautions. Paid content that reads as paid loses the credibility that made UGC valuable — the brief should ask for honesty, not enthusiasm, and creators who are told to be positive produce clips that sound like it. And disclosure requirements apply to paid partnerships in most markets; check what your jurisdiction expects and comply visibly, since undisclosed paid content discovered later damages the brand far more than the disclosure would have cost. > **Ask for the question, not the video** > > The most useful brief you can give a creator is a question rather than a script: "show how it fits someone your height" or "show what it looks like after a month". You get something specific and genuinely useful, and it still sounds like them. ## A first pass worth running 1. Search for existing UGC about your products. Make a list. 2. Approach creators with specific, small requests. 3. Clear rights properly, audio included, and record them. 4. Pick five to ten clips for products where images leave a real question open. 5. Edit lightly, then place in or near the image gallery rather than far down the page. 6. Measure Core Web Vitals and conversion against matched products without video, over weeks. Step six is what makes it a test rather than a rollout. Adding video everywhere at once feels decisive, changes fifty pages simultaneously, and leaves you unable to attribute anything to anything. For format and placement in more depth, see [video commerce and UGC](/category/video-commerce-ugc). App selection is in [Shopify apps](/category/shopify-apps), and page weight in [storefront and design](/category/storefront-design). **TikTok UGC, shoppable, on your storefront** SwipeReel imports TikTok and Instagram UGC in one click and turns it into shoppable carousels, stories, grids and popups with tap-to-buy inside the video. [See SwipeReel on the Shopify App Store](https://apps.shopify.com/swipereel) ## FAQ ### Can I use a creator's TikTok video on my Shopify store? Not without permission. Posting publicly does not licence commercial use, and tagging your brand is not consent. You need explicit agreement covering storefront use specifically, ideally in writing and specifying duration. ### Should I embed TikToks or download and host them? Host them, with permission. ### Does UGC convert better than professional video? For demonstrating real-world use, fit and scale, generally yes, because it visibly is not a production and reads as credible. For showing detail, finish and construction, professional video is better. ### Will TikTok videos hurt my page speed? Only if implemented carelessly. Video is the heaviest asset you can add to a product page. Behind a poster image that loads on interaction, the cost is small. ### How do I find UGC about my products? Search your brand name and product names on TikTok, check your tagged mentions, and look at hashtags around your category. Many stores find content already exists that they were unaware of. --- --- title: "WooCommerce naar Shopify migreren zonder SEO-verlies" description: "SEO gaat niet verloren door van platform te wisselen. Het gaat verloren bij URL's die zonder redirect veranderen en content die achterblijft. Met een volledige inventarisatie, een 301-redirectmap en goed doordachte metafields overleeft uw organische verkeer de overstap." author: "Aashish Kaushik" published: 2026-09-26T05:00:51.738Z updated: 2026-09-26T05:00:51.742Z url: https://blog.byteinfy.com/woocommerce-naar-shopify-migreren-zonder-seo-verlies --- # WooCommerce naar Shopify migreren zonder SEO-verlies ## Key takeaways - De URL's van WooCommerce en die van Shopify komen nooit overeen, omdat Shopify zijn eigen paden vastlegt (/products/, /collections/, /pages/), dus elke oude URL met verkeer heeft een expliciete 301-redirect nodig. - Het werk dat de SEO beschermt, gebeurt voordat u één product verplaatst: een inventarisatie van URL's, verkeer en inkomende links uit Search Console en de WordPress-database. - De eigen velden van WooCommerce (samenstelling, compatibiliteit, maattabellen) hebben geen automatische tegenhanger; ze gaan naar Shopify-metafields, en waar ze terechtkomen bepaalt u vóór de import. - De eerste vier weken na de DNS-wissel in Search Console vertellen of de migratie geslaagd is; 404-fouten op oude URL's zijn het signaal dat u dezelfde dag oppakt. SEO van een webshop gaat niet verloren door van platform te wisselen. Het gaat verloren wanneer URL's veranderen zonder dat iemand ze doorverwijst, wanneer content die goed scoorde achterblijft op WordPress, en wanneer de nieuwe webshop lanceert met andere titels, meta-omschrijvingen en structured data dan waar Google mee bekend was. WooCommerce naar Shopify migreren zonder SEO-verlies betekent deze drie dingen vermijden, en bijna al het werk gebeurt voordat u één product verplaatst. Dit artikel loopt het proces door in de volgorde waarin het handig is: de inventarisatie vooraf, het URL-probleem, de 301-redirectmap, metafields, de content die moet overleven, de dag van de DNS-wissel en wat u daarna in Search Console controleert. Aan het eind staat een opmerking over wanneer u het zelf doet en wanneer u iemand inhuurt, met richtprijzen. Dit is geschreven voor Nederlandse en Belgische ondernemers die al op WooCommerce verkopen en organisch verkeer hebben om te beschermen. Is uw webshop nieuw en heeft die nauwelijks posities, dan is de migratie veel eenvoudiger en kunt u de helft van het onderstaande overslaan. ## Waarom SEO verloren gaat bij een migratie Google rangschikt geen webshops, het rangschikt URL's. Elke productpagina, categorie of blogartikel heeft zijn eigen geschiedenis van links, signalen en posities, en die geschiedenis zit vast aan het exacte adres van de pagina. Verandert dat adres, dan ziet Google een nieuwe pagina zonder geschiedenis en een oude pagina die verdwenen is. De 301-redirect is het mechanisme dat Google vertelt dat de oude pagina permanent is verhuisd naar de nieuwe, en dat de opgebouwde signalen mee moeten. Zonder redirect geeft de oude pagina een 404-fout, gaan de signalen verloren en begint de nieuwe pagina bij nul. Bij een migratie van duizend producten en tweehonderd categorieën betekent bij nul beginnen maanden verloren verkeer. De tweede oorzaak van verlies is content. WooCommerce laat u informatie opslaan in eigen velden, attributen, plugin-tabs en widgets, en een groot deel daarvan komt in de HTML terecht die Google leest. Verplaatst de import naar Shopify alleen titel, omschrijving, prijs en afbeeldingen, dan zijn de nieuwe pagina's dunner dan de oude, en scoren ze slechter, ook als de redirect klopt. De derde oorzaak is subtieler: de structured data, SEO-titels en meta-omschrijvingen die een plugin zoals Yoast of Rank Math op WordPress genereerde, kopiëren zichzelf niet. Shopify heeft daar eigen velden voor, en die vult u met wat er al stond, niet met wat het nieuwe thema standaard invult. ## Vóór u iets verplaatst: de inventarisatie Een migratie zonder inventarisatie is een migratie in het donker, en de inventarisatie maakt u op WooCommerce, niet op Shopify. Begin met het exporteren van alle URL's die Google kent. Search Console laat u de pagina's met vertoningen en klikken van de afgelopen zestien maanden downloaden; die lijst telt echt, want dat zijn de URL's die verkeer opleveren. Vul aan met een volledige crawl van de site (Screaming Frog of een vergelijkbaar hulpmiddel) om URL's te vangen die bestaan maar geen verkeer hebben, en met de lijst pagina's die externe links ontvangen, die u uit Search Console of een backlinktool haalt. Voeg aan die lijst per URL het type content toe (product, categorie, tag, pagina, blogartikel, filter), het verkeer van de afgelopen twaalf maanden en het aantal inkomende links. Sorteer op verkeer. De eerste honderd URL's verdienen individuele aandacht; de rest kan met regels worden behandeld. Exporteer ook de gegevens die WooCommerce buiten het product zelf bewaart: attributen, eigen velden (productmeta), termen van eigen taxonomieën, teksten uit plugin-tabs, reviews. De standaard CSV-export van WooCommerce bevat dit niet allemaal, en vaak is een exportplugin of een directe query op de WordPress-database nodig. Dit is de stap die het vaakst wordt overgeslagen en het meeste content kost. > **De producten die u niet meer verkoopt** > > Een webshop met jaren geschiedenis heeft uitverkochte producten die nog steeds geïndexeerd zijn en bezoekers trekken. Gooi ze niet zomaar weg: hebben ze verkeer of links, verwijs de URL dan door naar de categorie of het vervangende product op Shopify. Hebben ze geen van beide, dan is een schone 404 prima, en Shopify geeft die zonder dat u iets hoeft te doen. ## De URL's van WooCommerce en die van Shopify komen niet overeen Shopify legt zijn eigen URL-structuur vast, en geen thema, app of instelling verandert dat. Dit is de eerste verrassing voor veel ondernemers die van WordPress komen, waar permalinks vrij instelbaar zijn. ## Gelijkwaardigheid van paden tussen platforms | Type content | WooCommerce (gebruikelijk) | Shopify (vast) | | --- | --- | --- | | Product | /product/naam/ | /products/naam | | Categorie | /product-categorie/naam/ | /collections/naam | | Producttag | /product-tag/naam/ | Geen directe tegenhanger, doorverwijzen naar collectie | | Winkel | /winkel/ of /shop/ | /collections/all | | Pagina | /naam/ | /pages/naam | | Blogartikel | /blog/naam/ of /naam/ | /blogs/naam-van-blog/naam | | Filter of attribuut | /categorie/?pa_kleur=rood | Geen eigen URL, doorverwijzen naar collectie | Wat u wel kunt behouden, is de handle, het laatste deel van de URL. Stond een product op /product/trailschoen-dames/, dan kan het op Shopify op /products/trailschoen-dames staan. De handle behouden voorkomt de redirect niet, maar maakt de map veel makkelijker met een regel in plaats van handmatig te genereren, en behoudt het trefwoord in de URL. Let op twee details. Shopify staat geen slotstreepjes of hoofdletters toe in handles, en zet geaccentueerde tekens om; een handle met een umlaut of accent verandert dus, controleer hoe elk exemplaar eruitziet voordat u de regel goedkeurt. En de filter- en attribuut-URL's van WooCommerce, die bij veel webshops duizenden geïndexeerde pagina's opleveren, hebben geen eigen bestemming op Shopify; het is verstandig ze door te verwijzen naar de bovenliggende collectie. Producttags verdienen een aparte beslissing. Op WooCommerce heeft elke tag zijn eigen pagina; op Shopify filteren tags binnen een collectie maar leveren ze geen equivalente indexeerbare URL op. Had een tagpagina verkeer, maak dan een collectie met die naam aan en verwijs door; zo niet, verwijs dan naar de dichtstbijzijnde categorie. Het artikel over [SEO van collectiepagina's](/shopify-collection-page-seo) laat zien hoe u collecties inzet om die zoekopdrachten te dekken. ## De 301-redirectmap De redirectmap is het centrale document van de migratie: een tabel met twee kolommen, oude URL en nieuwe URL, met een rij voor elke URL uit de inventarisatie die het waard is te behouden. Shopify beheert redirects vanuit Webshop, Navigatie, URL-omleidingen. U kunt ze één voor één aanmaken of als CSV importeren, en importeren is de enige realistische optie bij een echte migratie. Het bestand heeft twee kolommen, "Redirect from" en "Redirect to", met relatieve paden zonder domein. Een redirect van Shopify antwoordt met een permanente 301, wat Google nodig heeft. Er zijn drie beperkingen om vooraf te kennen. Shopify verwijst geen paden door die al bestaan in de nieuwe winkel, dus u kunt /products/x niet doorverwijzen als /products/x een actief product is. Shopify negeert queryparameters bij het vergelijken van paden, dus /categorie/?pa_kleur=rood en /categorie/ worden als dezelfde bron-URL behandeld; de oplossing is het basispad door te verwijzen en te accepteren dat de filters verloren gaan. En het ondersteunt geen reguliere expressies of wildcards, dus elke URL heeft zijn eigen rij nodig. Genereer de map met regels voor het gros (product naar product, categorie naar collectie) en controleer handmatig de honderd URL's met het meeste verkeer en die met externe links. Die honderd dragen bij bijna elke webshop het grootste deel van het organische verkeer, en een fout in een van hen weegt zwaarder dan honderd fouten in URL's zonder bezoekers. Vermijd redirectketens. Waren er op WooCommerce al oude redirects (van een URL uit 2019 naar een andere uit 2022, bijvoorbeeld), dan moet de nieuwe redirect van de oudste bron rechtstreeks naar de Shopify-bestemming leiden, niet via de tussenliggende URL. Google volgt korte ketens, maar elke sprong verliest iets en vertraagt de herverwerking. Vermijd ook alles doorverwijzen naar de homepage. Het is de snelle oplossing die sommige plugins en gehaaste bureaus bieden, en Google behandelt het als een verborgen 404: het signaal gaat niet mee, en wie een specifiek product zocht, komt op een generieke pagina terecht. ## Metafields: waar gaat wat WooCommerce in eigen velden bewaarde Wat op WooCommerce eigen velden, attributen en plugin-tabs waren, zijn op Shopify metafields, en de beslissing welk veld waar naartoe gaat, neemt u vóór de import, niet erna. Een Shopify-metafield heeft een namespace, een sleutel en een type (tekst, getal, lijst, verwijzing naar een ander product, bestand, onder andere). Metafields definieert u onder Instellingen, Eigen gegevens, en eenmaal gedefinieerd verschijnen ze in de editor van elk product en kunt u ze zonder code laten zien in het thema via de sectie-editor. Dat betekent dat de samenstelling van een cosmeticaproduct, de compatibiliteitstabel van een onderdeel of de maattabel van een kledingstuk in de productpagina kunnen blijven staan, en dus blijven meetellen voor SEO. Het werk kent drie stappen. Eerst alle velden die WooCommerce per product bewaart opsommen en beslissen welke zichtbaar zijn op de site (die gaan naar metafields) en welke intern zijn (die kunnen naar verborgen metafields, naar tags, of vervallen). Daarna de metafields op Shopify definiëren met het juiste type; een veld dat op WordPress vrije tekst was maar in werkelijkheid altijd een getal bevatte, definieert u beter als getal zodat u erop kunt filteren. Ten slotte deze velden als kolommen opnemen in de CSV voor productimport, met de kopnotatie die Shopify voor metafields verwacht. Varianten verdienen aparte aandacht. WooCommerce staat attributen toe die geen varianten opleveren en attributen die dat wel doen; Shopify heeft maximaal drie opties per product die altijd varianten opleveren, met een aantal varianten per product dat in de loop der tijd is gestegen maar nog steeds een plafond kent. Een product met vijf attributen op WooCommerce importeert u niet zomaar: u beslist welke koopopties zijn (maat, kleur) en welke informatie zijn (materiaal, herkomst), en die laatste gaan naar metafields. Het artikel over [metaobjecten en metafields in Shopify](/shopify-metaobjects-metafields) legt uit hoe u complexere content structureert, zoals herbruikbare gidsen of ingrediëntenfiches die tussen producten worden gedeeld. ## De content die intact moet blijven Naast URL's en metafields zijn er vier dingen die Google op de oude webshop las en op dezelfde manier op de nieuwe moet lezen. **SEO-titels en meta-omschrijvingen.** Yoast, Rank Math en vergelijkbare plugins bewaren per pagina een titel en omschrijving in hun eigen tabel, los van de productnaam. Shopify heeft de bijbehorende velden op elk product, elke collectie en pagina, in de sectie "Weergave in zoekmachines", en de importCSV accepteert ze als kolommen. Exporteer die van de plugin en laad ze in; laat Shopify er geen nieuwe uit de omschrijving genereren, want alle titels ineens veranderen is een van de vaakst voorkomende oorzaken van een terugval na een migratie. **Lange omschrijvingen en HTML-content.** De productomschrijving van WooCommerce staat HTML toe, en veel webshops hebben daar tabellen, lijsten en koppen die helpen bij het scoren. Shopify staat HTML toe in de omschrijving, maar de import-CSV kan de opmaak verstoren als die niet goed wordt geëscaped. Controleer een steekproef van producten met lange omschrijvingen voordat u de hele catalogus importeert. **Blogartikelen.** WooCommerce leeft binnen WordPress, en veel webshops hebben tientallen artikelen die verkeer opleveren. Shopify heeft een blog met minder functies, en artikelen worden geïmporteerd met een eigen CSV of via de API. Behoud handles, publicatiedatums en auteur. Had het blog categorieën, dan worden dat op Shopify tags per artikel of aparte blogs. Het artikel over [SEO van de Shopify-blog](/shopify-blog-seo) legt uit wat wel en niet kan met de blogstructuur van Shopify. **Structured data.** Shopify-thema's bevatten standaard structured data voor producten (naam, prijs, beschikbaarheid, beoordelingen als er een reviews-app is), en die zijn in veel gevallen beter dan wat WordPress genereerde. Had u op WooCommerce echter FAQ's, breadcrumbs of organisatiegegevens gemarkeerd met een plugin, controleer dan of het nieuwe thema of een app die reproduceert. Gebruik de rich results-test van Google op een productpagina en een collectiepagina vóór de lancering. ## De dag van de DNS-wissel ## Vóór u het DNS wisselt - De Shopify-webshop staat compleet en gecontroleerd achter een wachtwoord, met producten, collecties, pagina's en blog geïmporteerd en steekproefsgewijs gecontroleerd - De geïmporteerde SEO-titels en meta-omschrijvingen komen overeen met die van WooCommerce, gecontroleerd op twintig pagina's met verkeer - De redirect-CSV is geïmporteerd in Shopify en getest met tien URL's per type (product, categorie, pagina, blog) - Het hoofddomein staat ingesteld in Shopify en het SSL-certificaat is uitgegeven, ook al wijst het DNS nog naar WordPress - De oude webshop stopt enkele uren van tevoren met het accepteren van bestellingen, zodat er geen order verloren gaat bij de wissel - Klanten zijn geïmporteerd; wachtwoorden kunnen niet worden meegenomen en er staat een resetmail klaar - Search Console is geverifieerd voor het domein (verificatie via DNS overleeft de platformwissel) - De sitemap van Shopify (/sitemap.xml) staat klaar om in te dienen zodra het DNS wisselt - Analytics, pixels en toestemming zijn geïnstalleerd en getest op de testwebshop - Er is iemand aangewezen om de eerste twee weken elke dag Search Console en 404-fouten te controleren De eigenlijke DNS-wissel doet u in een rustig uur, doordeweeks 's nachts of op zondagochtend, afhankelijk van uw markt. Vanaf dat moment moeten de redirects vanaf de eerste seconde werken: komt een crawler van Google op een oude URL en vindt die een 404 omdat de CSV nog niet was geïmporteerd, dan komt die URL in de foutenwachtrij terecht en herstelt langzamer. Verandert ook het domein (niet alleen het platform), gebruik dan na het actief worden van de redirects het hulpmiddel voor adreswijziging in Search Console. Blijft het domein hetzelfde, dan hoeft dat niet; dien de nieuwe sitemap in en wacht af. Verwijder WordPress niet dezelfde dag. Houd het minstens drie maanden bereikbaar op een subdomein of lokaal, want er duiken content op die niemand zich herinnerde, ontbrekende afbeeldingen en velden die niet zijn geëxporteerd. Ze terughalen uit een levende kopie is goedkoper dan uit een back-up. ## Wat u de weken erna in Search Console controleert De vier weken na de wissel vertellen of de migratie is geslaagd, en Search Console is waar u dat ziet. **404-fouten in het paginarapport.** Dit is elke dag de eerste plek om te kijken. Elke oude URL met verkeer die als "Niet gevonden" verschijnt, is een ontbrekende of foutieve redirect, en u corrigeert dat door de rij aan de map toe te voegen en opnieuw te importeren. URL's zonder verkeer of links kunt u op 404 laten staan. **Dekking en indexering.** Het aantal geïndexeerde pagina's daalt eerst (oude URL's verdwijnen) en stijgt daarna (nieuwe komen erbij). Belangrijk is dat de nieuwe erbij komen: staan de productpagina's van Shopify na drie weken nog niet geïndexeerd, controleer dan of de sitemap is ingediend, of het thema geen noindex-tags op een bepaald paginatype zet, en of het wachtwoord van de webshop is verwijderd. **Prestaties per pagina.** Vergelijk de klikken van de twintig belangrijkste WooCommerce-URL's met die van hun bestemmingen op Shopify. Een daling tussen de 10 en 30 procent tijdens de eerste weken is normaal; een specifieke URL die naar nul zakt, wijst op een probleem met die redirect of die pagina. **Core Web Vitals.** Shopify is meestal sneller dan een WordPress vol plugins, maar een slecht ingesteld thema of tien apps die op de lanceerdag zijn geïnstalleerd, kunnen dat omkeren. Bekijk het rapport na vier weken, wanneer er velddata is, en lees het artikel over [snelheid van Shopify-thema's](/shopify-theme-speed) als er iets rood kleurt. Blijft het organische verkeer na acht weken 30 procent onder het startpunt terwijl de 404's schoon zijn, dan ligt het probleem niet bij de migratie zelf: het is dunnere content op de nieuwe pagina's, veranderde titels, of een thema dat minder tekst toont dan het oude. Ga terug naar de inventarisatie en vergelijk een oude pagina element voor element met de nieuwe tegenhanger. ## Wanneer u het zelf doet en wanneer u iemand inhuurt De migratie van een kleine webshop zonder veel organisch verkeer kunt u zelf doen. Shopify heeft een officiële importeer-app vanuit WooCommerce die producten, klanten en orders verplaatst, en de redirect-CSV genereert u met een spreadsheet en wat geduld. Heeft uw webshop minder dan tweehonderd producten, is het blog klein en toont Search Console geen verkeer waar u wakker van ligt, ga dan gerust zelf aan de slag. Het is de moeite waard om te betalen wanneer er organisch verkeer te beschermen valt, een grote catalogus met eigen velden, een boekhoudsysteem dat gesynchroniseerd moet blijven, of meerdere talen. In die gevallen wordt een verkeerd afgehandelde redirect of een verloren veld gemeten in maanden aan omzet, en dat overstijgt ruim de kosten van het werk. Een migratie van catalogus en klanten met een redirectmap begint bij $1.500 op de [migratiedienstenpagina van ByteInfy](https://byteinfy.com/services/shopify-migration), op het moment van schrijven, en de webshop zelf (thema, secties, ontwerp) is een aparte post die apart wordt geoffreerd, zoals ook beschreven in [wat een webshop echt kost](/nl/shopify-bureau-kosten-2027-wat-webshop-echt-kost). Besteedt u dit uit, vraag dan om de redirectmap te zien vóór de DNS-wissel en om de inventarisatie te ontvangen waarmee is gewerkt. Een bureau dat dat document niet kan tonen, heeft het werk niet gedaan dat de SEO beschermt, hoe mooi de webshop er ook uitziet. Het artikel over [een Shopify bureau kiezen](/nl/shopify-bureau-kiezen-12-vragen-vooraf) heeft meer van dit soort vragen, en de [Shopify SEO checklist](/nl/shopify-seo-checklist-2027-25-punten-tellen) verzamelt wat u controleert in de nieuwe webshop zodra het stof van de migratie is neergedaald. **Gaat u migreren vanaf WooCommerce en heeft u verkeer te beschermen** Vertel hoeveel producten u heeft, welke eigen velden u gebruikt en wat Search Console laat zien, en u krijgt een migratieplan met de redirectmap als eerste oplevering. [Praat met ByteInfy](https://byteinfy.com/contact) ## FAQ ### Verlies ik SEO bij een migratie van WooCommerce naar Shopify? Niet per se. Wat posities kost, is URL's veranderen zonder redirect, content buiten de import laten en de nieuwe winkel lanceren met andere titels, meta-omschrijvingen en structured data. ### Kan ik dezelfde URL's aanhouden als op WooCommerce? Niet helemaal. Shopify verplicht dat producten onder /products/ staan, collecties onder /collections/ en pagina's onder /pages/, en die voorvoegsels kunt u niet wijzigen. ### Hoe maak ik 301-redirects aan in Shopify? In het Shopify-adminpaneel, onder Verkoopkanalen, Webshop, Navigatie, URL-omleidingen, maakt u ze één voor één aan of importeert u een CSV-bestand met twee kolommen: het oude pad en het nieuwe. ### Wat gebeurt er met afbeeldingen uit WooCommerce bij de migratie? Afbeeldingen worden opnieuw geüpload naar het CDN van Shopify, waardoor hun URL's veranderen. Google indexeert afbeeldingen apart, en dat verkeer herstelt langzamer dan dat van pagina's. ### Hoe lang duurt het voordat Google de migratie verwerkt? Met redirects die vanaf de eerste minuut werken, verwerkt Google de belangrijkste URL's meestal binnen twee tot zes weken, al kunnen grote catalogi langer duren. ### Kan ik het beste migreren in een rustige periode? Ja, waar mogelijk. Een migratie kost enkele weken wat verkeer, ook als het goed gaat, en die weken vallen liever niet in uw beste maand. ### Wat kost het om met een bureau van WooCommerce naar Shopify te migreren? Een migratie van catalogus en klanten met een redirectmap begint bij $1.500 op de dienstenpagina van ByteInfy, op het moment van schrijven. --- --- title: "Best Shopify Bundle Apps in 2026" description: "Bundle apps look interchangeable until you ask how the bundle exists in your catalogue. Fixed or dynamic is the decision everything else follows from." author: "Aashish Kaushik" published: 2026-09-25T13:00:55.344Z updated: 2026-09-25T13:00:55.384Z url: https://blog.byteinfy.com/best-shopify-bundle-apps --- # Best Shopify Bundle Apps in 2026 ## Key takeaways - The real fork is whether a bundle is a single new product or a rule applied to several existing ones — everything else follows from that. - Fixed bundles are simple to report on and terrible at variants; dynamic bundles handle variant choice and complicate inventory. - Inventory is where bundle apps break, because a component sold both inside and outside a bundle can be drawn down from two directions. - Since Scripts stopped running on 30 June 2026, bundle discount logic should apply through Shopify Functions, not cart manipulation. Bundle apps are difficult to compare because they all describe themselves the same way: create bundles, increase average order value, drag-and-drop builder, analytics included. The screenshots look identical. There is exactly one question that separates them, and it has to be answered before anything else: does a bundle exist in your catalogue as a product, or as a rule? > **On specifics** > > Ratings, pricing and feature sets in this category change constantly, and much of the comparison content available is published by bundle app vendors ranking their own category. Nothing here ranks products; check current listings. ## Fixed or dynamic: the decision everything follows from **A fixed bundle is a product.** You create a new item in your catalogue — "Starter Kit" — with its own SKU, price, images and inventory. Customers buy it like any other product. **A dynamic bundle is a rule.** The shopper adds several products, and a rule recognises the combination and applies pricing. There is no new catalogue item; the bundle exists only as behaviour at the cart. That distinction determines almost everything downstream: ## Fixed and dynamic compared | Fixed bundle | Dynamic bundle | | --- | --- | | Exists as | A product with a SKU | A cart rule | | Variant selection | Effectively impossible at scale | Native to the model | | Inventory | Its own count, needs syncing to components | Draws on component stock directly | | Reporting | Clean — it is a product that sold | Harder — attribution across line items | | Merchandising | Full product page, images, reviews | Usually a widget on existing pages | | Best for | Curated sets with no choice | Mix-and-match, anything with variants | If your products have meaningful variants, this decides it. A fixed bundle of three t-shirts in customer-chosen sizes requires a bundle variant for every size combination, which is unmanageable past a handful of options. Dynamic handles it because the shopper picks each component's variant at the cart. If your bundle is a genuinely curated fixed set — a gift box, a starter kit, a fixed trio — fixed is simpler, reports cleanly, and gets a real product page you can merchandise and collect reviews on. ## Inventory is where bundles break The failure mode nobody demonstrates, and the one that causes actual losses. A component sold both inside a bundle and separately is being drawn down from two directions. Sell fifty bundles containing product A while also selling product A on its own, and your stock of A depletes faster than either channel's forecast suggests. With fixed bundles this is worse, because the bundle has its own inventory count that must stay synchronised with its components. If that sync is imperfect, you either oversell the bundle or hold phantom stock in it that the standalone product cannot access. Ask any vendor, specifically: - When a bundle sells, what decrements? The bundle's own count, the components, or both? - What happens when one component runs out? Does the bundle become unavailable, silently oversell, or substitute? - Can I see component-level stock across bundle and standalone sales in one place? - What happens at a stocktake, when physical counts meet bundle inventory? > **Set alerts on components, not bundles** > > A bundle's availability is limited by its scarcest component, and that component is often not the one anyone is watching. Put stock alerts on every component of every active bundle, and decide in advance what the bundle does when one runs out. Discovering this during a campaign is the expensive version. ## How the discount is applied The second technical question, and the one that determines whether your bundle survives checkout. Since legacy Shopify Scripts stopped running on 30 June 2026, custom discount logic should apply through Shopify Functions. Functions run server-side and hold through accelerated checkouts. Some apps, particularly older ones, achieve bundle pricing by manipulating the cart — adding and removing line items, rewriting the cart, or routing through draft orders. The failure modes are specific: the bundle price is visible in the cart and gone at checkout, or the whole mechanic is bypassed when a shopper uses Shop Pay or a wallet button. Ask whether pricing applies via Functions, and test a complete purchase through an accelerated checkout before committing. That single test eliminates more candidates than any feature comparison. ## Merchandising: where the bundle is seen A bundle nobody notices is not a bundle. Where the app can display the offer varies more than the feature lists suggest. **On the product page** is the highest-value placement, because it reaches a shopper already considering a component. "Buy this with X and Y and save" at the moment of decision is the mechanic working. Check whether the widget can sit near the buy button rather than only far down the page. **On collection pages**, flagging that a product is part of a bundle, creates discovery while browsing. **A dedicated bundle page** matters mainly for fixed bundles, which deserve a real product page with their own images, description and reviews. **In the cart**, suggesting a completion — "add Z to complete the bundle and save" — catches shoppers who assembled most of one by accident. That last case is more valuable than it sounds and less commonly supported than you would expect, because the shopper has already demonstrated intent for most of the bundle. ## Reporting you will actually want Bundle reporting is where the fixed-versus-dynamic choice bites again, and it is worth knowing before you commit. A fixed bundle reports cleanly: it is a product, it sold, you know how many. A dynamic bundle is several line items with a discount, and separating "these three products sold together as a bundle" from "these three products happened to be in the same order" requires the app to track it deliberately. The questions worth asking: **Can I see bundle revenue separately** from the components' standalone revenue? Without this you cannot tell whether the bundle is working. **Can I see cannibalisation?** The number that matters is not bundle revenue, it is whether total revenue rose. A bundle of things people were buying anyway is a discount wearing a costume. **Does bundle data survive uninstalling the app?** Frequently not, which is worth knowing before you build a year of reporting on it. ## Do not skip the control group Bundles are unusually easy to be fooled by. Bundle revenue is always positive — people bought bundles — so the report always looks like success. The real question is whether those customers would have spent the same or more without the bundle. Answering it needs a comparison: a matched period, or a subset of products without bundles running alongside those with them. Merchants who skip this step reliably overestimate what bundling contributed, sometimes by a lot. ## What to bundle, and what not to App choice is the easy half. Deciding what goes in a bundle is where the commercial outcome is actually determined, and the common instincts are mostly wrong. **Bundling your best sellers together is usually a mistake.** Those products sell at full price on their own. Putting two of them in a discounted set gives away margin on demand you already had, and it is the most frequent way a bundle programme loses money while appearing to succeed. **The useful pattern is anchor plus attachment.** One product people already want, paired with something they would not have sought out — a complementary item, a refill, an accessory, slow-moving stock that is genuinely useful alongside the anchor. The anchor supplies the demand; the attachment supplies the incremental revenue. **Bundles should reduce a decision, not add one.** A set that answers "what else do I need with this" is doing work for the shopper. A mix-and-match builder with fourteen options is asking them to do work, and past a small number of choices, conversion falls rather than rises. **Price the bundle so the saving is legible.** A shopper should be able to see, without arithmetic, that the bundle is better than buying the parts. Savings that require a calculator do not convert, and savings under roughly a tenth of the total rarely change behaviour at all. > **Start with three bundles, not thirty** > > Bundle programmes tend to sprawl, and a catalogue with forty bundles is one nobody can merchandise, report on or keep in stock. Launch three, measure them properly against a control, and expand only into what demonstrably worked. ## A short evaluation sequence 1. Decide fixed or dynamic from your variant situation. This eliminates most of the market immediately. 2. Ask the four inventory questions above, and do not accept vague answers. 3. Confirm pricing applies via Functions, and test through an accelerated checkout. 4. Check product-page merchandising on your actual theme, not a demo store. 5. Measure page-speed impact before and after installing. 6. Confirm what happens on uninstall — to the bundles, and to the reporting. For bundle strategy and what the mechanic does to margin, see [promotions and offers](/category/promotions-offers). App selection generally is covered in [Shopify apps](/category/shopify-apps), and the inventory side in [POS and operations](/category/pos-operations). **Bundle logic an app cannot express?** ByteInfy builds custom Shopify bundle and discount logic with Functions — component-aware inventory, dynamic pricing and merchandising that fits your theme. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What is the difference between a fixed and a dynamic bundle? A fixed bundle is a new product in your catalogue containing a set combination, with its own SKU, price and inventory. ### Do Shopify bundles work with variants? With fixed bundles, generally poorly — a bundle of three t-shirts in chosen sizes becomes an unmanageable number of bundle variants. ### How does inventory work with bundles? This is the hardest part and the most common source of trouble. ### Does Shopify have native bundle functionality? Shopify has bundle capabilities, and for straightforward cases they may be sufficient. Apps become worthwhile when you need dynamic component selection, complex pricing rules, bundle-specific merchandising on product pages, or mix-and-match structures. ### Do bundles actually increase average order value? They can, and they are one of the more reliable AOV mechanics because they change what the shopper buys rather than only what they pay. --- --- title: "Kortingen bouwen met Shopify Functions (Scripts zijn gestopt)" description: "Shopify Scripts zijn uitgefaseerd en Shopify Functions zijn de vervanger. Wat dat betekent voor staffelkorting, BOGO, B2B-prijzen en gratis verzending, en wanneer u wel en niet een ontwikkelaar nodig heeft." author: "Aashish Kaushik" published: 2026-09-25T05:00:51.687Z updated: 2026-09-25T05:00:51.690Z url: https://blog.byteinfy.com/kortingen-bouwen-met-shopify-functions-scripts-zijn-gestopt --- # Kortingen bouwen met Shopify Functions (Scripts zijn gestopt) ## Key takeaways - Shopify Scripts zijn uitgefaseerd; alle maatwerkkortingen draaien nu als Shopify Functions, ook zonder Plus. - De meeste kortingen, staffels, BOGO en kortingscodes, maakt u zonder code in de Shopify-admin; een Function is voor regels die daar niet in passen. - Een Function draait in de checkout zelf en werkt daardoor ook met Shop Pay, Apple Pay en Google Pay, waar cart-manipulatie faalt. - Schrijf de kortingsregels eerst in gewone taal uit; dat is het duurste deel van het werk en het deel dat het vaakst wordt overgeslagen. Kortingen op Shopify bouwt u sinds het einde van Scripts op twee manieren: met de standaardkortingen in de admin voor alles wat daarin past, en met Shopify Functions voor de regels die daar niet in passen. Shopify Scripts zijn uitgefaseerd; Plus-merchants moesten vóór 2025 migreren. Functions zijn de vervanger, ze werken op alle plannen en ze draaien in de checkout zelf, waardoor ze ook gelden in Shop Pay, Apple Pay en Google Pay. Deze gids legt uit wat u zonder code kunt, wanneer u een Function nodig heeft, hoe die werkt en wat de bekende beperkingen zijn. De voorbeelden zijn de kortingen die merchants in Nederland en België het meest vragen: staffels, twee halen één betalen, gratis verzending boven een drempel en aparte prijzen voor zakelijke klanten. Wie de Engelse achtergrond zoekt, leest [Shopify Scripts to Functions](/shopify-scripts-to-functions). > **Eerst de regels, dan de code** > > Het duurste deel van een kortingsproject is niet het bouwen, maar het opschrijven van de regels. Wat gebeurt er bij een retour, bij een combinatie met een kortingscode, bij een product dat op is, bij een klant die in twee groepen zit. Schrijf dat in gewone taal uit voordat iemand een regel code typt. ## Wat er veranderde toen Scripts stopten Shopify Scripts waren Ruby-scripts die alleen op Shopify Plus draaiden en de winkelwagen, verzendopties en betaalmethoden aanpasten. Ze zijn uitgefaseerd en vervangen door Shopify Functions, die op alle plannen werken en op een andere plek in de flow draaien. Het verschil zit in waar de logica wordt uitgevoerd. Scripts draaiden op de winkelwagen en de checkout van het oude model, samen met checkout.liquid. Toen Checkout Extensibility checkout.liquid verving, verdween ook de plek waar Scripts leefden. Functions draaien in de nieuwe checkout, als onderdeel van Shopify's eigen berekening van kortingen, bezorgopties en betaalmethoden. Daardoor gelden ze overal waar de checkout wordt gebruikt, inclusief de versnelde checkouts die vroeger langs de winkelwagen heen gingen. Voor merchants heeft dat drie gevolgen. Kortingslogica die vroeger Plus vereiste, is nu op elk plan te bouwen. Logica die vroeger in een script stond, moet opnieuw worden gebouwd als Function; een automatische vertaling bestaat niet. En apps die kortingen nabootsen door de winkelwagen te manipuleren, werken niet in versnelde checkouts, wat u pas merkt als klanten via Shop Pay afrekenen zonder korting. ## Wat u zonder code kunt maken De meeste kortingen die een webshop nodig heeft, zitten in de Shopify-admin onder Kortingen. Begin daar, en bouw pas een Function als de admin het echt niet kan. **Kortingscodes en automatische kortingen** met een percentage, een vast bedrag of gratis verzending, met minimumbedragen, minimale aantallen en beperking tot bepaalde producten, collecties of klantgroepen. **Koop X, krijg Y** als automatische korting of code, waarmee u twee halen één betalen, een gratis product bij aankoop of korting op een tweede artikel maakt. De Engelse gids [How to set up BOGO on Shopify](/how-to-set-up-bogo-on-shopify) loopt de instellingen door. **Hoeveelheidskortingen** op basis van aantal per product of per bestelling, via de standaardkorting met minimale hoeveelheid. Het artikel [Shopify volume discount without app](/shopify-volume-discount-without-app) laat zien hoe ver u daarmee komt. **Kortingscombinaties**, waarmee u per korting bepaalt of die samen met product-, order- en verzendkortingen mag gelden. Dat is de plek waar u bepaalt of een kortingscode boven op een automatische staffel komt. **Marktprijzen** via Shopify Markets, waarmee u per land een andere prijs of afronding hanteert. Dat is geen korting, maar het lost een deel van de vragen op die vroeger met een script werden opgelost. Wat de admin niet kan, is logica die afhangt van combinaties, van berekende totalen over meerdere producten, van klantgegevens buiten de standaardgroepen of van externe regels zoals een maximale korting per klant per maand. Daar begint een Function. ## Wanneer u een Function nodig heeft Een Function is nodig zodra de kortingsregel voorwaarden combineert die de standaardkorting niet kent, of zodra u wilt bepalen wat een klant in de checkout ziet aan bezorgopties en betaalmethoden. ## Standaardkorting of Shopify Function | Kortingsregel | Standaard in admin | Shopify Function | | --- | --- | --- | | Tien procent met een code | Ja | Niet nodig | | Twee halen, één betalen op een collectie | Ja, via Koop X krijg Y | Niet nodig | | Staffel: vijf procent vanaf drie stuks, tien vanaf zes | Ja, met meerdere kortingen en combinaties | Als de staffel over verschillende producten heen telt | | Gratis verzending vanaf vijftig euro | Ja | Als de drempel per klantgroep of regio verschilt | | Korting voor zakelijke klanten met btw-nummer | Deels, via klantgroepen | Als prijs afhangt van bedrijf, volume en contract | | Bundelprijs voor een zelf samengestelde set | Nee | Ja, via een cart transform Function | | Korting bij een bepaalde betaalmethode | Nee | Ja, met een betaalmethode-Function en een kortingsregel | | Maximale korting per klant per periode | Nee | Ja, met een Function en opslag in metafields | | Bezorgopties verbergen bij bepaalde producten | Nee | Ja, via een delivery customization Function | De rechterkolom is bewust kort, want elke Function is ontwikkelwerk dat onderhouden moet worden. Wie twijfelt, vraagt een bureau eerst of de admin het kan. Een bureau dat meteen een Function voorstelt zonder de standaardkorting te proberen, verkoopt scope. ## Hoe een kortings-Function werkt Een Function is een klein programma dat in een Shopify-app leeft, door Shopify wordt aangeroepen tijdens de berekening van de checkout, en een lijst met kortingen teruggeeft op basis van de winkelwagen die het binnenkrijgt. De opbouw is steeds dezelfde. De Function vraagt met een query de gegevens op die het nodig heeft: de regels in de winkelwagen, de klant, eventueel metafields op producten of op de klant. Het programma, geschreven in JavaScript of Rust en gecompileerd naar WebAssembly, past de regels toe en geeft terug welke korting op welke regel geldt. Shopify voert het uit, snel en zonder dat er een externe server aan te pas komt. De instellingen van de Function, zoals percentages, drempels en welke collecties meedoen, staan meestal in metafields die de merchant via een beheerscherm in de app aanpast. Dat beheerscherm is het verschil tussen een Function die u zelf kunt bijstellen en een Function waarvoor u elke keer de ontwikkelaar belt. Vraag bij elke offerte expliciet of er een beheerscherm bij zit; de Engelse gids [Shopify Functions discounts](/shopify-functions-discounts) laat zien hoe zo'n opzet eruitziet. Een Function wordt geïnstalleerd als een korting in de admin, met een naam, een looptijd en combinatie-instellingen zoals elke andere korting. Voor uw team ziet het er dus vertrouwd uit; het verschil zit in wat de korting kan berekenen. ## Vier kortingen die merchants het meest vragen De vragen die wij van webshops in Nederland en België horen, komen steeds op dezelfde vier kortingen neer. Dit is hoe ze in de praktijk worden gebouwd. **Staffelkorting over producten heen.** Vijf procent vanaf drie stuks, tien vanaf zes, tellend over alle producten in een collectie in plaats van per product. De standaardkorting telt per product; een Function telt de totale hoeveelheid in de collectie en past de korting toe op elke regel. Het artikel [Shopify tiered discounts](/shopify-tiered-discounts) beschrijft de varianten. **Twee halen, één betalen met een goedkoopste-gratis-regel.** De standaardkorting kan dit voor vaste combinaties. Zodra de klant zelf uit een grote collectie kiest en de goedkoopste gratis moet zijn, ook bij vier of zes stuks, is een Function betrouwbaarder. **Gratis verzending boven een drempel die per land verschilt.** Vijftig euro voor Nederland, vijfenzeventig voor België, omdat PostNL en bpost verschillend kosten. Dat kan deels met verzendprofielen per zone; een Function wordt nodig als de drempel ook afhangt van klantgroep of productcategorie. **Zakelijke prijzen.** Een aparte prijs voor klanten met een geverifieerd btw-nummer, oplopend met het volume. Op Shopify Plus lost B2B met catalogi en prijslijsten dit op. Op de reguliere plannen kan een Function korting geven op basis van een klanttag, mits de btw-verwerking in de checkout apart is geregeld. ## Beperkingen die u vooraf moet kennen Functions zijn snel en betrouwbaar omdat ze beperkt zijn. Die beperkingen bepalen wat u wel en niet kunt bouwen, en een bureau hoort ze vóór de offerte te noemen. Een Function kan geen externe systemen raadplegen tijdens de berekening. Wat het nodig heeft, moet in de winkelwagen, de klant of metafields staan. Een korting die afhangt van uw voorraadsysteem of uw CRM vraagt dus om een koppeling die die gegevens vooraf naar metafields schrijft. Er zijn limieten aan de rekentijd en de grootte van de invoer; bij zeer grote winkelwagens of zeer veel regels loopt een slordig gebouwde Function daar tegenaan. Kortingen volgen bovendien de combinatieregels van Shopify: product-, order- en verzendkorting zijn drie klassen, en een Function zit in één ervan. Wat u ziet als "één korting" is soms twee Functions. En ten slotte: een Function verandert de berekening, niet de weergave. Wilt u de staffel op de productpagina tonen, dan is dat werk in het thema. Wilt u in de checkout een melding tonen, dan is dat een checkout-UI-extensie. Het artikel [Shopify Functions limitations](/shopify-functions-limitations) somt de grenzen volledig op. > **Test in alle checkouts, niet alleen in de gewone** > > Plaats een testbestelling via de reguliere checkout, via Shop Pay en via Apple Pay of Google Pay op een telefoon. Een korting die in één van de drie ontbreekt, is het bekendste symptoom van een app die de winkelwagen manipuleert in plaats van een Function te gebruiken. ## Migreren vanaf Scripts of vanaf een oude app Wie nog een Script in zijn admin heeft staan, of een kortingsapp die is gebouwd op cart-manipulatie, migreert in vier stappen. De volgorde is belangrijk, want de eerste stap wordt het vaakst overgeslagen. ## Van Scripts of cart-apps naar Functions - Documenteer elke bestaande kortingsregel in gewone taal, inclusief uitzonderingen en wat er bij een retour gebeurt - Bepaal per regel of de standaardkorting in de admin het kan; schrap wat niet meer gebruikt wordt - Laat de overgebleven regels als Function bouwen, met een beheerscherm voor drempels en percentages - Test elke regel in de reguliere checkout, in Shop Pay en in Apple Pay of Google Pay, met en zonder kortingscode - Zet de nieuwe korting aan in een rustig uur, met de oude app nog geïnstalleerd, en verwijder de oude pas na een week - Controleer na verwijdering of er restanten van de oude app in het thema zijn achtergebleven Wat de migratie kost, hangt af van het aantal regels dat overblijft na stap twee. Een enkele Function of checkout-extensie bouwt ByteInfy [vanaf $1.500](https://byteinfy.com/services/shopify-checkout-extensions), met de bandbreedte van 1.500 tot 3.000 dollar per Function. Meerdere regels samen worden als één programma geoffreerd. Een bureau dat u zonder deze stappen een prijs geeft, heeft de regels niet gelezen, en de Engelse gids [Hiring a Shopify development agency](/hire-shopify-development-agency) laat zien welke vragen daar nog meer bij horen. ## App uit de App Store of eigen Function Een bestaande kortingsapp is goedkoper en sneller dan een eigen Function, mits de app Functions gebruikt en uw regel erin past. Een eigen Function wint zodra de regel specifiek is voor uw bedrijf of zodra u geen maandelijks abonnement wilt voor één regel. Vraag een leverancier van een kortingsapp twee dingen: draait de korting als Shopify Function, en wat laat de app achter in het thema bij verwijdering. Het eerste bepaalt of de korting in Shop Pay werkt; het tweede bepaalt of u er ooit weer vanaf komt. Het artikel [Shopify discount stacking](/shopify-discount-stacking) laat zien hoe apps en standaardkortingen samen gedragen. Een eigen Function past bij regels die u nergens in een app terugvindt, of bij webshops met genoeg volume om het verschil tussen een abonnement en een eenmalige bouw terug te verdienen. Zorg dan dat de code in een repository staat waar u toegang toe heeft en dat er een beheerscherm bij zit. Een Function zonder beheerscherm is een korting die u niet zelf kunt uitzetten, en dat wilt u op de avond vóór een campagne niet ontdekken. **Wilt u weten of uw kortingsregel een Function nodig heeft?** Beschrijf de regel in gewone taal en u hoort of de Shopify-admin het kan, of een bestaande app volstaat, of dat het een Function wordt, met een vaste prijs. [Praat met ByteInfy](https://byteinfy.com/contact) ## FAQ ### Wat zijn Shopify Functions? Kleine programma's die in de checkout van Shopify draaien en de logica van kortingen, bezorgopties, betaalmethoden en cartvalidatie aanpassen. Ze worden gebouwd in een app, gecompileerd naar WebAssembly en door Shopify uitgevoerd. ### Zijn Shopify Scripts echt gestopt? Ja. Shopify heeft Scripts uitgefaseerd en Plus-merchants moesten vóór 2025 migreren naar Functions. Een webshop die nog op Scripts leunde, heeft die logica ergens onderweg verloren. ### Heb ik Shopify Plus nodig voor Shopify Functions? Voor kortingsfuncties niet. Functions voor kortingen, bezorging en cartvalidatie werken op alle plannen. Sommige aanpassingen van de betaalstap en de opmaak van de checkout vragen wel om Plus. ### Kan ik een staffelkorting maken zonder Function? Vaak wel. Shopify heeft standaard hoeveelheidsregels via automatische kortingen en kortingscodes, en op Plus via B2B-catalogi. Een Function is nodig zodra de staffel afhangt van combinaties, klantgroepen of totalen die de standaardkorting niet kent. ### Werken kortingen van een app ook met Shop Pay en Apple Pay? Alleen als de app Shopify Functions gebruikt. Apps die de winkelwagen aanpassen, bijvoorbeeld door een verborgen kortingsproduct toe te voegen, worden door versnelde checkouts overgeslagen. ### Wat kost het om een kortingsregel als Function te laten bouwen? Een enkele Function of checkout-extensie kost bij ByteInfy tussen 1.500 en 3.000 dollar, afhankelijk van de complexiteit van de regels en of er een beheerscherm bij hoort. ### Kan ik meerdere kortingen tegelijk laten gelden? Shopify bepaalt met kortingscombinaties welke soorten korting samen mogen: productkorting, orderkorting en verzendkorting. Een Function valt onder een van die klassen en volgt dezelfde combinatieregels. --- --- title: "Checkout Extensibility: What Plus Merchants Must Migrate" description: "The old checkout let you edit a Liquid template and do almost anything. The new one gives you defined extension points, a faster checkout, and no way to break it." author: "Aashish Kaushik" published: 2026-09-24T13:01:07.314Z updated: 2026-09-24T13:01:07.504Z url: https://blog.byteinfy.com/shopify-checkout-extensibility --- # Checkout Extensibility: What Plus Merchants Must Migrate ## Key takeaways - Checkout extensibility replaced checkout.liquid with defined extension points — UI extensions, Functions, and branding through the admin. - Checkout Components reached general availability for Plus merchants in 2026, allowing the post-cart flow to be composed with drag-and-drop blocks. - The constraint is real: some customisations that worked in checkout.liquid have no equivalent, and the honest answer is sometimes to drop them. - What you gain is a checkout that stays fast, upgrades itself, and cannot be broken by a bad template edit. For years, customising a Shopify Plus checkout meant editing `checkout.liquid`, and that file could do almost anything. Merchants added fields, rewrote layouts, injected scripts, and built flows the platform never anticipated. That flexibility had a cost that was invisible until it was not. Every heavily-customised checkout was a bespoke, unversioned piece of code that Shopify could not upgrade. Performance improvements, security patches and conversion work could not reach the stores that had rewritten it — which were, inevitably, the largest ones. Checkout extensibility is the trade: defined extension points instead of an editable template. > **Who this affects** > > Primarily Shopify Plus merchants who customised checkout. Merchants on other plans never had checkout.liquid and are largely unaffected, though Functions and UI extensions are relevant to them too. ## What the new model consists of Not one replacement but four mechanisms, each covering a slice of what the template used to do. **Checkout UI extensions** add interface elements at supported points in the flow — a message, a field, a custom block in a defined location. You do not choose an arbitrary position; you choose from the extension points Shopify supports. **Shopify Functions** handle logic: discounts, delivery customisation, payment customisation, validation. This is where anything that used to be conditional script now lives. **Branding through the admin.** Colours, typography, logo, layout choices are configured rather than coded. This is the part that has moved furthest out of development. **Checkout Components**, generally available to Plus merchants in 2026, allow the post-cart flow to be customised with drag-and-drop blocks ([Shopify Editions coverage, ShopAppy](https://shopappy.com/ecommerce/shopify-editions-summer-26-what-shopify-actually-announced), retrieved 2026-09-02). The direction across all four is consistent: less code, more configuration, and no way for a merchant to break the checkout by editing it badly. ## What genuinely does not migrate The section most migration guides avoid, and the one that matters most for planning. Some customisations that worked in `checkout.liquid` have no equivalent, because the new model is deliberately bounded. Being honest about this early saves a project from discovering it late. ## Old customisation and its fate | Customisation | Status now | | --- | --- | | Branding, colours, fonts, logo | Fully supported, configured in admin | | Custom fields at checkout | Supported at defined extension points | | Conditional discount logic | Supported via Functions | | Hiding or reordering payment methods | Supported via payment customisation Functions | | Hiding or renaming shipping rates | Supported via delivery customisation Functions | | Trust badges, messaging, upsell blocks | Supported at extension points | | Arbitrary layout rewrites | Not supported | | Injecting third-party scripts freely | Not supported | | Custom multi-step flows outside the model | Not supported | The bottom three are where projects stall. A merchant who built a genuinely unusual checkout flow will not be able to rebuild it exactly, and the correct response is usually to ask what business problem it solved and whether the new model addresses that problem differently — rather than to seek a workaround, which tends to produce something fragile. ## The migration is an audit before it is a build The most common mistake is scoping the work from the current checkout's code rather than from its intent. Checkout customisations accumulate over years. Some were added for a promotion that ended in 2022. Some address a payment provider you no longer use. Some exist because someone once asked, and nobody has questioned them since. ## Audit before scoping - List every customisation currently live, including ones added by apps - For each, write down the business reason in plain language - Mark the ones nobody can justify any more, and plan to drop them - Identify any that depend on injected third-party scripts - Note anything seasonal that will not appear in a current audit - Check which apps rely on checkout access and whether they have migrated The seasonal item catches teams out — a customisation that only appears during a November promotion is invisible in a July audit and absent when it is needed, which is the worst possible moment to discover a gap in the migration scope. The app question is equally important. Apps that touched the old checkout have had to migrate too, and not all of them did well. Check that every app you depend on at checkout supports the current model. ## What you get back The trade is not one-sided, and the gains are worth stating. **The checkout stays fast, without you.** Shopify optimises checkout continuously, and those improvements now reach your store. Under the old model, a heavily customised checkout was frozen at whatever performance it had when it was written. **It upgrades itself.** New payment methods, accessibility improvements and conversion work arrive without a project. **It cannot be broken by an edit.** A misconfigured extension fails in a bounded way. A bad edit to `checkout.liquid` could take down the only page that takes money. **Less ongoing development.** Branding and, increasingly, layout are merchant-editable. The work that used to be a ticket is now a setting. For most merchants the honest accounting is that they lose a handful of customisations they had stopped valuing and gain a checkout that improves on its own. For a small number with genuinely unusual requirements, the loss is real. There is a second-order gain worth noting too. Because every extensibility checkout is built from the same components, problems are shared rather than private. When something behaves oddly, it is far more likely that someone else has hit it and documented it — which is not true of a checkout that only your store has ever run. Bespoke code is lonely to debug, and that cost never appeared on any invoice for the original customisation. ## Test the things the demo will not show Checkout is the one page where a fault costs the entire order, so verification should be more thorough than elsewhere. - Every accelerated checkout method you have enabled, completed end to end, not just rendered. - Every discount combination a real shopper could reach, including codes still circulating. - A failed payment, confirming the recovery path works. - An international address, if you sell across markets. - Guest checkout, not only logged-in. - A mobile device on a slow connection, which is where most of your traffic actually is. > **Do not migrate checkout during peak** > > This work should not be shipped anywhere near a high-traffic period. Checkout changes need weeks of ordinary traffic to reveal edge cases, and the failure mode is losing orders rather than degrading an experience. If a peak period is approaching, wait until after it. ## Who can change checkout now An organisational consequence worth planning for deliberately, because it is the change teams notice day to day. Under the old model, checkout customisation was unambiguously a developer task. Nobody edited `checkout.liquid` casually, which was dangerous but at least had a clear owner. The new model splits the work three ways. Branding and layout are merchant-editable in the admin. Composition of the post-cart flow is merchant-editable through Checkout Components. Logic remains a development task through Functions and UI extensions. That is mostly good — routine changes stop waiting in a development queue. It introduces a governance question that most merchants have not faced: when several people can change how checkout looks and behaves, and none of those changes go through review, a conversion drop becomes genuinely hard to diagnose. Two lightweight practices prevent most of the pain: **Decide who may change what.** Not everyone with admin access should be reconfiguring the page that takes money. Shopify's staff permissions can express this; most stores have never used them for it. **Keep a dated note of significant changes.** A shared document is enough. The failure it prevents is the one where conversion falls four percent, nobody can recall what shipped that week, and the investigation takes longer than the change did. > **Watch checkout completion, not just conversion** > > Store-wide conversion rate moves for a dozen reasons. The number that isolates checkout problems is the proportion of sessions that reach checkout and then complete. If that ratio moves after a change, the change is the cause, and you will know within days rather than after a month of arguing about traffic quality. ## A sequence that works 1. Audit the current checkout for what exists and why. 2. Cut what nobody can justify. 3. Map each survivor to a UI extension, a Function, a branding setting, or Checkout Components. 4. Identify the unmappable ones and decide explicitly whether to solve the underlying problem differently or drop it. 5. Check every app that touches checkout. 6. Build and test on a development store, including all the paths above. 7. Ship well away from peak, and watch order completion rates for a fortnight. Step four is the one that needs a decision-maker rather than a developer, and getting it in front of one early is what keeps the project moving. Development teams tend to park unmappable requirements rather than escalate them, on the reasonable assumption that a workaround will emerge. Usually none does, and the decision surfaces weeks later with the deadline much closer. Ask for it in the first week. For the wider checkout picture, see [checkout and payments](/category/checkout-payments). Discount logic and Functions are covered in [promotions and offers](/category/promotions-offers) and [Shopify development](/category/shopify-development). **Still carrying a legacy checkout?** ByteInfy migrates Shopify Plus checkouts to extensibility — UI extensions, Functions and Checkout Components, with the audit that decides what is worth keeping. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What replaced checkout.liquid on Shopify Plus? Checkout extensibility, which is a set of defined mechanisms rather than one file. ### Why did Shopify remove checkout.liquid? Because an editable checkout template meant every merchant's checkout was a bespoke, unversioned piece of code that Shopify could not upgrade, optimise or guarantee. ### What are Checkout Components? A drag-and-drop way of composing the post-cart flow, generally available to Plus merchants as of the Summer 2026 release. ### Can I still customise my Shopify checkout? Yes, within defined boundaries. You can add interface elements at supported extension points, change discount and delivery and payment behaviour with Functions, apply branding through the admin, and compose the flow with Checkout Components. ### Do I need a developer to migrate? For branding and layout, increasingly not — that work has moved into the admin and Checkout Components. For anything involving custom logic, validation or third-party calls, yes. --- --- title: "Shopify in Nederland: iDEAL, Klarna, btw en verzending" description: "Een Shopify-webshop voor de Nederlandse markt staat of valt met vier instellingen. iDEAL en Klarna via Shopify Payments, btw inclusief in de prijzen, verzendregels die kloppen en een checkout die Nederlands spreekt." author: "Aashish Kaushik" published: 2026-09-24T05:01:06.795Z updated: 2026-09-24T05:01:06.836Z url: https://blog.byteinfy.com/shopify-nederland-ideal-klarna-btw-verzending --- # Shopify in Nederland: iDEAL, Klarna, btw en verzending ## Key takeaways - iDEAL en Klarna zijn beschikbaar via Shopify Payments; zet iDEAL bovenaan, want het is de betaalmethode die Nederlandse klanten verwachten. - Zet prijzen inclusief btw, hanteer 21 en 9 procent correct en registreer voor OSS zodra u structureel aan consumenten in andere EU-landen verkoopt. - PostNL, DHL en DPD koppelt u via een verzendplatform; de verzendregels in Shopify bepalen wat de klant in de checkout ziet. - Test de complete bestelflow met een echte iDEAL-betaling van één euro voordat u live gaat. Een Shopify-webshop voor de Nederlandse markt staat of valt met vier instellingen: iDEAL en Klarna via Shopify Payments, btw inclusief in de prijzen met het juiste tarief, verzendregels voor PostNL of een andere vervoerder, en een checkout die in het Nederlands en in euro's werkt. Alle vier zijn zonder ontwikkelaar in te stellen. Alle vier gaan in de praktijk regelmatig mis, meestal omdat een webshop is opgezet met Amerikaanse standaardinstellingen en nooit is nagelopen. Deze gids loopt de vier onderdelen langs, met daarbij wat de wet vraagt, wat Nederlandse klanten verwachten en wat u vóór de lancering test. Verkoopt u ook in België, lees dan aanvullend [Shopify in België: Bancontact, btw en verzending](/nl/shopify-belgie-bancontact-btw-verzending), want daar wijken betaalmethoden, btw-tarieven en taal af. > **Wat deze gids niet is** > > Dit is geen juridisch of fiscaal advies. De btw-regels hieronder zijn de hoofdlijnen; de precieze toepassing hangt af van uw situatie en die bespreekt u met uw boekhouder. De Shopify-instellingen zijn wel exact. ## Betaalmethoden: iDEAL eerst, Klarna ernaast Nederlandse consumenten betalen overwegend met iDEAL, en een webshop zonder iDEAL verliest bestellingen bij de laatste stap. iDEAL en Klarna zijn beschikbaar via Shopify Payments, wat betekent dat u geen aparte betaalprovider nodig heeft om ze aan te bieden. Shopify Payments activeert u in Instellingen, Betalingen. Na verificatie van uw bedrijf en bankrekening kiest u welke betaalmethoden zichtbaar zijn. Voor Nederland zet u iDEAL aan, Klarna als u achteraf of gespreid betalen wilt aanbieden, en de creditcards, Apple Pay en Google Pay voor wie daarmee betaalt. Bancontact zet u aan als u ook Belgische klanten verwacht; het kost niets extra om het beschikbaar te hebben. Waarom Shopify Payments en niet een externe provider? Twee redenen. Ten eerste rekent Shopify bij een externe betaalprovider een extra transactievergoeding bovenop wat de provider zelf vraagt; met Shopify Payments vervalt die. Ten tweede werken de versnelde checkouts, waaronder Shop Pay, alleen met Shopify Payments. Een externe provider zoals Mollie kan alsnog een goede reden hebben, bijvoorbeeld als u die al gebruikt voor andere kanalen of specifieke betaalmethoden nodig heeft die Shopify Payments niet biedt. Reken dan wel de extra vergoeding mee. ## Betaalmethoden voor Nederlandse klanten via Shopify Payments | Betaalmethode | Wanneer aanbieden | Let op | | --- | --- | --- | | iDEAL | Altijd | Zet het bovenaan in de checkout; klanten zoeken het als eerste | | Klarna | Bij hogere orderwaarden en mode, wonen, elektronica | Hogere kosten per transactie, eigen productvoorwaarden | | Creditcard | Altijd | Vooral zakelijke klanten en buitenlandse bezoekers | | Apple Pay en Google Pay | Altijd | Snel op mobiel, geen extra instellingen nodig | | Bancontact | Bij Belgische klanten | Gratis om te activeren, verplicht als u serieus in België verkoopt | | Shop Pay | Altijd | Alleen met Shopify Payments, slaat gegevens op voor terugkerende klanten | De volgorde van betaalmethoden in de checkout stelt u in bij Shopify Payments. Zet iDEAL bovenaan. Een Nederlandse klant die eerst een creditcardformulier ziet, twijfelt of hij wel bij een Nederlandse winkel is. ## iDEAL instellen en waar het misgaat iDEAL zelf vraagt geen configuratie. Wat misgaat, zit in de omgeving eromheen: de valuta, de taal en het testen. **Valuta.** Uw winkelvaluta moet euro zijn. Een webshop die in dollars is aangemaakt en later naar euro wordt omgezet, neemt oude prijsafrondingen mee. Controleer de winkelvaluta in Instellingen, Algemeen vóórdat u producten importeert. **Taal van de checkout.** De checkout volgt de taal van het thema. Zet Nederlands als hoofdtaal en controleer de vertalingen van de checkout in Thema, Vertalingen. Standaardvertalingen zijn bruikbaar maar houterig; "Doorgaan naar verzending" en "Bestelling plaatsen" leest anders dan wat een Nederlandse klant gewend is. **Testen met een echte betaling.** Plaats één bestelling van een euro met iDEAL vanuit uw eigen bankapp. U ziet dan wat de klant ziet: de bankselectie, de terugkeer naar de bedankpagina, de bevestigingsmail. Restitueer daarna vanuit de order. De testmodus van Shopify Payments simuleert kaarten, geen iDEAL. **Bevestigingsmails.** Controleer dat de ordermails in het Nederlands zijn, het btw-bedrag tonen en uw KvK-nummer en btw-identificatienummer bevatten. Klanten en de Belastingdienst verwachten dat. ## Klarna: achteraf betalen zonder verrassingen Klarna verhoogt bij sommige categorieën de conversie, vooral bij mode en wonen waar klanten thuis willen passen of zien. Het kost meer per transactie dan iDEAL en Klarna stelt eigen voorwaarden aan wat u verkoopt. Via Shopify Payments zet u Klarna aan bij de betaalmethoden. Klarna toont in de checkout de opties die voor het orderbedrag gelden, zoals betalen na ontvangst of in termijnen. Op de productpagina kunt u de Klarna-melding tonen; sommige thema's ondersteunen dat standaard, anders is er een app of een kleine aanpassing van het thema. Drie zaken om vooraf te regelen. Ten eerste: uw retourbeleid moet kloppen met de betaaltermijn, anders betaalt een klant een product dat al onderweg terug is. Ten tweede: Klarna weigert sommige productcategorieën; controleer dat vóór u het inschakelt. Ten derde: bij een deels geretourneerde order moet de restitutie via Shopify lopen, zodat Klarna de betaling van de klant aanpast. Handmatig terugbetalen buiten Shopify om levert dubbele boekingen op. ## Btw in Nederland: inclusief, 21 of 9 procent, en OSS Aan consumenten toont u prijzen inclusief btw, met 21 procent als standaardtarief en 9 procent voor onder meer levensmiddelen, boeken en geneesmiddelen. Zet dat in Shopify vóór u een product aanmaakt. In Instellingen, Belastingen en douanerechten zet u "Alle prijzen inclusief belasting" aan en stelt u Nederland in als regio waar u btw rekent. Shopify kent het standaardtarief; producten met het lage tarief geeft u een belastingoverschrijving via een collectie. Maak een collectie "btw 9 procent", voeg de producten toe en stel voor die collectie het lage tarief in. **Btw over verzendkosten.** In Nederland volgt de btw over verzendkosten het tarief van de goederen. Bij een bestelling met alleen boeken is dat 9 procent, bij een gemengde bestelling naar rato. Shopify heeft hiervoor een instelling om belasting over verzendkosten te rekenen; controleer bij uw boekhouder of de standaardverwerking voor u volstaat. **OSS en verkoop naar andere EU-landen.** Verkoopt u voor meer dan tienduizend euro per jaar aan consumenten in andere EU-lidstaten, dan rekent u de btw van het land van de klant en draagt u die af via het éénloketsysteem, OSS. Shopify kan per EU-land het juiste tarief toepassen; u vult uw OSS-registratie in bij de belastinginstellingen voor de EU. Onder de drempel rekent u Nederlandse btw. Belgische klanten vallen hier ook onder, dus wie serieus in België verkoopt, komt vrijwel altijd boven de drempel uit. **Zakelijke klanten.** Verkoopt u aan bedrijven in andere EU-landen met een geldig btw-nummer, dan wordt de btw verlegd. Shopify valideert btw-nummers niet standaard in de reguliere checkout; daar is een app voor, of de B2B-functionaliteit op Shopify Plus. > **Controleer de btw op de factuur, niet alleen in de checkout** > > Shopify maakt standaard geen factuur die aan de Nederlandse eisen voldoet. De orderbevestiging toont bedragen, maar een factuur met KvK-nummer, btw-identificatienummer, factuurnummer en btw-specificatie per tarief komt uit een factuurapp of uw boekhoudkoppeling. Regel dat vóór de eerste zakelijke klant erom vraagt. ## Verzending: PostNL, DHL, DPD en de regels in Shopify De vervoerder kiest u op volume en pakketformaat; de verzendregels in Shopify bepalen wat de klant in de checkout ziet. Die twee staan los van elkaar, en dat is precies waar het vaak fout gaat. **De vervoerder koppelen.** Shopify Shipping met kortingslabels, zoals in de Verenigde Staten, is in Nederland op het moment van schrijven niet beschikbaar. Nederlandse webshops koppelen PostNL, DHL eCommerce of DPD via een verzendplatform zoals Sendcloud of MyParcel, of via de app van de vervoerder zelf. Het platform haalt de orders op, drukt labels en stuurt de track-en-tracecode terug naar Shopify, zodat de verzendmail automatisch de link bevat. **Verzendregels in Shopify.** In Instellingen, Verzending en bezorging maakt u verzendprofielen met zones en tarieven. Voor Nederland is een gangbare opzet een vast tarief onder een drempel en gratis verzending erboven. Voor België een apart tarief, want de vervoerderskosten liggen hoger. Brievenbuspakketten krijgen een eigen tarief op basis van gewicht als u kleine producten verkoopt. **Afhaalpunten.** PostNL en DHL bieden afhaalpunten; of die in de checkout selecteerbaar zijn, hangt af van uw verzendplatform en van een app die de puntenkiezer in de checkout plaatst. Sinds Checkout Extensibility gebeurt dat via een checkout-extensie, niet meer via aanpassingen aan checkout.liquid. Vraag uw verzendplatform welke extensie het levert. **Levertijd communiceren.** Nederlandse klanten verwachten een concrete belofte: "vóór 23.00 uur besteld, morgen in huis" of "verzending binnen twee werkdagen". Zet die belofte op de productpagina en in de checkout, en zorg dat uw verzendplatform en uw eigen proces die belofte ook waarmaken. Een belofte die u niet nakomt, kost meer dan geen belofte. ## Retouren, bedenktijd en keurmerken Consumenten in de EU hebben veertien dagen bedenktijd na ontvangst, en uw webshop moet dat duidelijk vermelden. Wie dat niet doet, verlengt de bedenktijd wettelijk met een jaar. Zet uw retourvoorwaarden op een eigen pagina, link ernaar vanuit de footer en de productpagina, en vermeld wie de retourkosten draagt. In Shopify regelt u retouren vanuit de order: u maakt een retour aan, verstuurt eventueel een retourlabel via uw verzendplatform en restitueert zodra het pakket binnen is. Klanten kunnen zelf een retour aanvragen via hun account als u klantaccounts inschakelt. Keurmerken zijn niet verplicht. Thuiswinkel Waarborg en WebwinkelKeur worden door Nederlandse consumenten herkend en helpen vooral een nieuw merk aan vertrouwen. Ze stellen eisen aan uw algemene voorwaarden, retourbeleid en klachtafhandeling, en die eisen zijn een goede checklist, ook als u geen keurmerk aanvraagt. Vergeet de juridische pagina's niet: algemene voorwaarden, privacyverklaring die aan de AVG voldoet, en een cookiebanner die vóór het plaatsen van marketingcookies toestemming vraagt. Shopify heeft een eigen cookiebanner en een privacyinstelling voor de EU die u bij Instellingen, Privacy van klanten inschakelt. ## Bol.com naast uw eigen webshop Veel Nederlandse merken verkopen zowel via hun eigen Shopify-webshop als via Bol.com. Dat is een verstandige combinatie, mits voorraad en prijzen synchroon lopen. Een koppeling tussen Shopify en Bol.com regelt u met een app die producten, voorraad en orders uitwisselt. Orders van Bol.com komen dan als Shopify-orders binnen, zodat u één verzendproces heeft. Let op drie dingen: de btw-verwerking van Bol.com-orders in uw boekhouding, de voorraadsynchronisatie bij snelle verkoop tijdens acties, en dat uw eigen webshop niet duurder is dan uw Bol.com-aanbod. Klanten vergelijken. Voor de SEO van uw eigen webshop geldt: Bol.com ranket op uw productnaam, vaak boven u. Uw eigen webshop wint op collectiepagina's, content en merkzoekopdrachten. De [Shopify SEO checklist](/nl/shopify-seo-checklist-2027-25-punten-tellen) laat zien waar u dat verschil maakt. ## Controles vóór de lancering Loop deze lijst één keer volledig door voordat u het wachtwoord van uw webshop verwijdert. Elk punt is een keer misgegaan bij een webshop die dacht klaar te zijn. ## Vóór u live gaat - Winkelvaluta is euro en prijzen zijn inclusief btw met 21 of 9 procent per product - iDEAL staat bovenaan in de checkout; Klarna, kaarten, Apple Pay en Google Pay zijn geactiveerd waar gewenst - Eén echte iDEAL-testbetaling van een euro geplaatst, ontvangen en gerestitueerd - Checkout en ordermails zijn Nederlands, tonen btw en bevatten KvK- en btw-nummer - Verzendprofielen voor Nederland en België zijn ingesteld en getest met een kortingscode boven en onder de drempel - Verzendplatform stuurt de track-en-tracecode terug naar de order en de verzendmail - Retourbeleid, algemene voorwaarden en privacyverklaring staan online en zijn gelinkt in de footer - Cookiebanner vraagt toestemming vóór marketingcookies en Google Analytics respecteert die keuze - Facturen met btw-specificatie komen uit een factuurapp of boekhoudkoppeling - Search Console is geverifieerd en de sitemap is ingediend Wat u hier niet zelf kunt, is beperkt. Een afhaalpuntenkiezer in de checkout, een btw-validatie voor zakelijke klanten of een koppeling met uw boekhouding of magazijn zijn ontwikkelwerk. Zo'n koppeling begint bij ByteInfy [vanaf $1.500](https://byteinfy.com/services/shopify-integrations); de instellingen hierboven kunt u zonder ontwikkelaar afronden, en dat is meestal de betere volgorde. **Twijfelt u of uw Nederlandse checkout goed staat?** Stuur uw webshop-URL en u krijgt een korte controle van betaalmethoden, btw-instellingen en verzendregels, met wat u zelf kunt aanpassen. [Praat met ByteInfy](https://byteinfy.com/contact) ## FAQ ### Werkt iDEAL op Shopify? Ja. iDEAL is beschikbaar via Shopify Payments voor webshops die vanuit Nederland verkopen. U activeert het in de instellingen van Shopify Payments, waarna het in de checkout verschijnt naast de andere betaalmethoden. ### Kan ik Klarna aanbieden op Shopify? Ja. Klarna is via Shopify Payments beschikbaar in Nederland, met betalen achteraf en gespreid betalen. De transactiekosten liggen hoger dan bij iDEAL en Klarna hanteert eigen voorwaarden voor wat u mag verkopen. ### Moet ik prijzen inclusief of exclusief btw tonen? Aan consumenten inclusief. Zet in de belastinginstellingen van Shopify dat prijzen inclusief btw zijn en stel het Nederlandse tarief in. ### Wat is OSS en wanneer heb ik het nodig? OSS, het éénloketsysteem, is de EU-regeling waarmee u btw van andere lidstaten via één aangifte in Nederland afdraagt. ### Welke vervoerder is het beste voor Shopify in Nederland? PostNL is het meest gebruikt, DHL eCommerce en DPD zijn volwaardige alternatieven. De keuze hangt af van uw volume, pakketformaat en of u afhaalpunten wilt aanbieden. ### Hoe stel ik gratis verzending vanaf een bedrag in? In Verzending en bezorging maakt u een tarief op basis van orderwaarde. Een tarief van nul euro vanaf bijvoorbeeld vijftig euro, en een betaald tarief daaronder. ### Moet ik een keurmerk hebben? Verplicht is het niet. Thuiswinkel Waarborg en WebwinkelKeur worden door Nederlandse consumenten herkend en verhogen vertrouwen, vooral voor een nieuw merk. --- --- title: "BFCM Landing Pages on Shopify That Actually Convert" description: "Your BFCM landing page receives your most expensive traffic of the year. It should say one thing, load fast, and never disagree with what the cart charges." author: "Aashish Kaushik" published: 2026-09-23T13:00:51.981Z updated: 2026-09-23T13:00:52.020Z url: https://blog.byteinfy.com/bfcm-landing-pages --- # BFCM Landing Pages on Shopify That Actually Convert ## Key takeaways - A BFCM page receives your most expensive traffic of the year, so page weight costs more here than anywhere else on the site. - One offer per page converts better than a page listing every deal, because a shopper arriving from a specific ad wants the thing that ad promised. - The page must never state a discount the cart cannot deliver — mismatch between promise and checkout is the fastest way to lose an expensive visitor. - Build it in October, freeze it in mid-November, and have the offer messaging driven from the same source as the discount itself. Your BFCM landing page receives the most expensive traffic you will buy all year. Every visitor arrived through an auction you paid a premium to win, at the one time of year every competitor is bidding against you. That changes the standard the page has to meet. A page that converts adequately in March is losing you money in November, because the cost of each visitor it fails is several times higher. > **Scope** > > Building and structuring the page. Offer mechanics and margin are covered separately in the BFCM series, as is checkout readiness. ## One page, one offer The most common structural mistake is a page that lists everything. A shopper arriving from an ad about 40% off outerwear wants outerwear at 40% off. A page presenting that alongside a bundle deal, a gift-with-purchase and a sitewide code makes them do sorting work they did not ask for, at the exact moment their intent is highest. The pattern that works is one landing page per offer, matched to the ad or email that drove the click. If you run four distinct mechanics, that is four pages, each saying one thing clearly. This costs more to build and converts better, and the arithmetic is easy at BFCM traffic costs. There is a place for a single "all deals" page — as a hub for people who arrive without a specific intent, from your homepage or a brand search. It should not be the destination for a specific campaign. ## The page must not disagree with the cart This is the failure that costs the most and it is entirely preventable. The page says 40% off. The shopper adds items, reaches the cart, and the discount is 30%, or applies to some items only, or has not applied at all. They now believe either that the site is broken or that you were misleading them, and both conclusions end the session. The cause is almost always process rather than technology. Landing page copy is written by one person in October. The discount is configured by another person in November. Nobody reconciles the two, and the offer changed slightly in between. ## Reconcile before publishing - Read the page copy aloud against the actual discount configuration - Add the exact products the page shows and check the cart total matches the claim - Verify any excluded products are stated on the page, not just in the discount settings - Confirm the discount applies via an accelerated checkout, not only the standard flow - Check the page's stated end date matches the discount's configured end date That last one is a specific and common failure — a page saying "ends Monday" and a discount configured to end Sunday night, producing a morning of angry emails. ## Page weight matters more here Everything on this page is being loaded by traffic you paid a premium for, frequently on a phone, frequently on a connection you do not control. The things that typically bloat a BFCM page: **Oversized hero imagery.** Sale pages attract ambitious design, and a full-width hero at desktop resolution is the single heaviest element on most of them. Serve appropriately sized images and set dimensions so nothing shifts. **Countdown timers.** Often a third-party script for something achievable with a stated date and time. If you use one, use a lightweight implementation, and make sure the deadline is real. **Video.** Rarely earns its weight on a landing page whose job is to state an offer and send people to products. **Every globally-loading app.** Your review widget, popup tool and chat app will all load here whether or not they contribute. This is a good page to check that against. Measure it on a mid-range phone on a throttled connection, not on your desktop on office wifi. The gap between those two experiences is where most of your paid traffic actually lives, and it is invisible from a developer machine. ## Structure that works A reliable shape, top to bottom: 1. The offer, stated plainly, above the fold. Not a brand statement. The discount, what it applies to, and when it ends. 2. How to get it, if any action is required — a code, a threshold, a qualifying product. If it is automatic, say so, because shoppers now expect to hunt for a code. 3. The products, immediately. Grids beat prose here; the shopper wants to see what is included. 4. The mechanic explained, if it is not self-evident. Tiered offers and bundles need a sentence. 5. Exclusions, stated clearly. Buried exclusions are the second-largest source of BFCM complaints. 6. A single clear action. One button doing one thing. What does not belong: brand storytelling, newsletter capture competing with the purchase, and links away to other campaigns. Navigation deserves a decision rather than a default. A full site header gives the shopper a dozen ways to leave a page you paid to get them to. Stripping it entirely can feel disorienting and hurts trust. The usual compromise is a reduced header — logo, cart, and little else — which keeps the page feeling like part of your store without offering an exit at every glance. ## What actually breaks under peak traffic Shopify's infrastructure handles the volume. What breaks on a BFCM landing page under real traffic is almost always something the merchant added, not the platform underneath it. **Apps making live calls per page load.** A stock counter, a "people are viewing this" widget, or a personalisation script that calls an external service on every visitor. Under normal traffic that call is invisible. Under BFCM traffic, the third-party service itself can slow down or rate-limit you, and the page starts waiting on someone else's server before it can finish rendering. **Inventory sync lag.** A page showing a product as available when a sudden spike has already sold through it. This is not a landing page problem specifically, but a landing page pointed at a hero product with limited stock is the exact place a sellout gets discovered by a shopper mid-checkout, which is a worse experience than the same sellout on a regular collection page. **Discount code contention.** A single-use or capped code advertised on the page can exhaust its allocation faster than expected when the traffic is concentrated into a few hours instead of spread across a season. A shopper who arrives from an ad promising a code that no longer works is the mismatch problem from earlier, just caused by volume instead of process. **Server-rendered personalisation.** Anything that computes a different version of the page per visitor, rather than serving one cached page to everyone, multiplies your server load by your visitor count instead of serving from cache. A static or largely static landing page survives a traffic spike far more predictably than one doing per-visitor work. The practical test is a load test against a copy of the actual page, not a synthetic blank page, at a multiple of your expected peak rather than your expected average. Run it in November on the frozen version, so any fix has time to be built, deployed and retested before the traffic is real. ## Build in October, freeze in November Two dates matter. **Build in late October** and publish in a teaser or low-key state. This gives you a real URL to test the discount logic against, lets the page be indexed before the period rather than arriving unknown on your highest-traffic day, and means the build problems surface with weeks of slack rather than hours. **Freeze in mid-November.** After that date, no changes to the page, the offer, or the discount logic. The reasoning is not caution for its own sake — a change needs live traffic afterwards to reveal its problems, and a change made two days before Black Friday has no observation window at all. > **Tie the messaging to the offer's source** > > Drive the page's offer messaging from the same source as the discount — the collection, the metafield, the date range. Sale messaging left visible after an offer ends is one of the most damaging storefront errors, because a shopper who arrives expecting a discount that no longer exists does not shrug and buy anyway. If the two are wired to one source, this cannot happen. ## Where the traffic actually comes from, and what that implies A BFCM landing page serves several audiences arriving with different knowledge, and a page written for only one of them underperforms for the rest. **Paid social.** Arrives cold, on a phone, mid-scroll, with whatever the ad creative promised as their only context. This audience needs the offer restated immediately and identically to the ad. Any gap between ad copy and page headline reads as the wrong page. **Email.** Arrives warm, already a customer, frequently on mobile, and already knows your brand. They need less persuasion and more specifics — what is included, what is excluded, when it ends. **Brand search.** Someone typing your name plus "black friday". The highest-intent traffic you will get and the cheapest. They need to find the offer without hunting, which is an argument for linking the deals page prominently from your homepage during the period. **Direct and returning.** People who bookmarked the page or saw it earlier. They may arrive before the offer starts, which means the page needs a sensible pre-launch state rather than a broken one. That last case is routinely mishandled. A page built in October and shared early will be visited before the discount is live. Decide what it says then — a countdown to the start, an email capture, a clear "starts 27 November" — rather than leaving a page that advertises an offer which does not yet apply. > **Match the headline to the ad, literally** > > The single cheapest conversion improvement available on a BFCM page is making its headline repeat the ad's promise word for word. Shoppers scan for confirmation they are in the right place, and a paraphrase costs you a measurable share of an expensive click. ## After the period The page should not simply vanish. **Redirect it or repurpose it**, rather than leaving a 404 for the links that will keep arriving for weeks from emails, social posts and bookmarks. A redirect to the relevant collection preserves whatever authority the page accumulated. **Keep the URL for next year** if the campaign recurs. A page at the same URL annually accumulates links and history, which is worth more than a fresh URL with a year in it. **Record what happened.** Which page converted, what the traffic cost, which offer structure worked. Next year's planning otherwise restarts from memory and repeats the same mistakes. For offer structure and the margin arithmetic, see the [BFCM 2026](/series/bfcm-2026) series. Page-weight fundamentals are covered in [storefront and design](/category/storefront-design), and the checkout side in [checkout and payments](/category/checkout-payments). **Need BFCM pages built and tested before the freeze?** ByteInfy builds Shopify landing pages and the discount logic behind them — fast, reconciled with the cart, and tested through every checkout path. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Should I build a dedicated BFCM landing page or just use a collection? A collection page works well when the offer is simply a discounted set of products, and it has the advantage of already existing and already being indexed. ### When should a BFCM landing page go live? Earlier than most merchants think, in an unpublished or teaser state. ### How do I stop my BFCM page slowing down under traffic? Page weight is the merchant's problem, not the platform's. Shopify handles the traffic. ### Should the landing page show a countdown timer? Only if the deadline is real and the timer is cheap. A genuine deadline creates useful urgency. ### What is the most common BFCM landing page mistake? Promising something the cart does not deliver. The page says 40% off, the discount applies at 30% or only to some items, and the shopper discovers it at checkout. --- --- title: "Shopify SEO checklist 2027: 25 punten die tellen" description: "Shopify regelt de technische basis van SEO zelf. Wat een webshop tegenhoudt zit in collecties, productpagina's, snelheid en content. Vijfentwintig punten, in volgorde van impact." author: "Aashish Kaushik" published: 2026-09-23T05:00:51.083Z updated: 2026-09-23T05:00:51.096Z url: https://blog.byteinfy.com/shopify-seo-checklist-2027-25-punten-tellen --- # Shopify SEO checklist 2027: 25 punten die tellen ## Key takeaways - Shopify regelt sitemap, canonicals en https zelf; het verschil zit in wat u met collecties, productpagina's en content doet. - Collectiepagina's zijn uw belangrijkste SEO-pagina's, want daar zoeken mensen op categorie in plaats van op productnaam. - Snelheid meet u op product- en collectiepagina's in velddata, niet op de homepage met een score-app. - AI-zoekmachines citeren pagina's die ze schoon kunnen uitlezen; gestructureerde data en duidelijke koppen doen het meeste werk. Shopify SEO in 2027 draait om vijf gebieden: techniek, collectiepagina's, productpagina's, snelheid en content. De techniek regelt Shopify grotendeels zelf. De overige vier bepalen of uw webshop wordt gevonden op de zoekwoorden waarop uw klanten daadwerkelijk zoeken, en daar heeft u zelf de hand in. Deze checklist zet vijfentwintig punten op een rij, in volgorde van impact, met bij elk punt wat u zelf kunt doen en wanneer u hulp nodig heeft. De checklist is geschreven voor webshops in Nederland en België, dus met aandacht voor Markets, hreflang en de tweetalige situatie in België. Wilt u de uitgebreide achtergrond, lees dan de Engelse [Shopify SEO guide 2026](/shopify-seo-guide-2026). Deze pagina is de kortere, praktische versie. > **Hoe u deze checklist leest** > > Elk punt staat op zichzelf. Loop de lijst één keer door, markeer wat bij u niet op orde is, en begin bij de eerste groep. Collecties en productpagina's leveren voor de meeste webshops meer op dan alle technische punten bij elkaar. ## Techniek: wat Shopify regelt en wat u zelf controleert Shopify verzorgt de technische basis. Sitemap, https, canonicals, mobiele weergave en een 301-redirecttool zitten in het platform. Dat betekent niet dat u niets hoeft te controleren. **1. Controleer Search Console.** Verifieer uw domein, dien de sitemap in op /sitemap.xml en kijk elke maand naar de rapporten Indexering en Core Web Vitals. Een webshop zonder Search Console vaart blind, en het is gratis. **2. Één domein, één versie.** Zorg dat www en niet-www naar dezelfde versie doorverwijzen en dat het myshopify-adres niet geïndexeerd wordt. Shopify regelt het laatste zelf; het eerste stelt u in bij Domeinen. **3. Redirects na elke wijziging.** Verandert u een producthandle of collectie-URL, dan maakt Shopify de redirect niet automatisch aan. Doe dat in Online Store, Navigatie, URL-redirects. Een gewijzigde URL zonder redirect is een 404 met verloren positie. **4. Dubbele URL's in kaart.** Shopify maakt /collections/x/products/y aan naast /products/y en zet een canonical naar de laatste. Dat is in orde. Wat vaak niet in orde is: tag-pagina's, gesorteerde en gefilterde varianten en varianten met een ?variant= parameter die geïndexeerd raken. Het artikel [Shopify duplicate content](/shopify-duplicate-content) beschrijft welke u noindext en hoe u robots.txt.liquid bewerkt. **5. Gestructureerde data van het thema.** Controleer met de Rich Results Test van Google of uw productpagina Product-schema levert met prijs, beschikbaarheid en beoordeling. Veel thema's doen het half; sommige apps dubbelen het. Twee keer hetzelfde schema is slechter dan één keer. ## Collectiepagina's: de pagina's die het meest opleveren Mensen zoeken op categorie, niet op productnaam. "Wollen wintertrui dames" is een collectiepagina, geen productpagina. Daarom zijn collecties de belangrijkste SEO-pagina's van uw webshop, en daarom verdienen ze de meeste aandacht. **6. Één collectie per zoekintentie.** Maak collecties op basis van hoe klanten zoeken, niet op basis van uw interne indeling. "Cadeaus onder 25 euro" is een zoekintentie; "Leverancier X, seizoen 3" niet. **7. Eigen tekst op elke collectie.** Een collectie met alleen een productgrid heeft niets om op te ranken. Schrijf een inleiding boven de producten en, als het thema het toelaat, een langere tekst eronder met antwoorden op de vragen die klanten over die categorie hebben. Het artikel [Shopify collection page SEO](/shopify-collection-page-seo) laat zien hoe u dat opbouwt. **8. Titel en metabeschrijving per collectie.** Shopify vult ze standaard met de collectienaam. Herschrijf ze met het zoekwoord, het aanbod en een reden om te klikken. Houd de titel rond de zestig tekens. **9. Interne links naar collecties.** Vanuit de navigatie, vanuit productpagina's en vanuit blogartikelen. Een collectie die alleen via een filtermenu bereikbaar is, krijgt geen linkwaarde. ## Productpagina's: uniek, compleet en leesbaar Productpagina's ranken op de productnaam en op specifieke zoekopdrachten zoals "merk model maat". Ze verkopen ook, dus elke verbetering hier telt dubbel. **10. Geen leverancierstekst.** Honderd webshops met dezelfde fabrieksbeschrijving concurreren om dezelfde positie, en de fabrikant wint. Schrijf eigen beschrijvingen, ook al zijn ze korter. Begin bij uw twintig best verkopende producten. **11. Alt-tekst op elke afbeelding.** Beschrijf wat er te zien is in een volledige zin, niet een rij zoekwoorden. Alt-tekst is ook wat een screenreader voorleest. Voor grote catalogi is bulkbewerking via een app of een AI-agent verdedigbaar; zie [Shopify image alt text SEO](/shopify-image-alt-text-seo). **12. Varianten en indexering.** Als uw thema elke variant een eigen URL geeft, controleer dan of die geïndexeerd worden. Meestal wilt u dat niet: de hoofdpagina ranket, de varianten zijn duplicaten. **13. Beoordelingen zichtbaar en in schema.** Beoordelingen op de pagina helpen conversie; beoordelingen in Product-schema helpen sterren in zoekresultaten. Controleer dat de reviewapp het schema niet dubbel plaatst naast het thema. **14. Antwoorden op de pagina.** Maat, materiaal, levertijd, retourbeleid, verzendkosten met PostNL of bpost. Elke vraag die een klant vóór de aankoop stelt, hoort op de pagina te staan. Het artikel [Shopify product page SEO](/shopify-product-page-seo) gaat dieper op de opbouw in. ## Snelheid: meten waar het telt Snelheid telt via Core Web Vitals, en de oorzaak van een trage Shopify-winkel is bijna altijd een stapel apps in plaats van het thema. **15. Meet met velddata.** Open het Core Web Vitals-rapport in Search Console. Dat toont wat echte bezoekers ervaren op echte pagina's. De snelheidsscore in uw Shopify-admin en de labscore van een snelheidsapp zijn daar geen vervanging voor. **16. Meet op product- en collectiepagina's.** De homepage is de minst nuttige pagina om te meten, want de meeste bezoekers landen ergens anders. Test het template dat uw advertentieverkeer ontvangt. **17. Tel de apps.** Elke app die iets op de storefront toont, laadt scripts. Verwijder wat u niet gebruikt en controleer na verwijdering of er restanten in theme.liquid zijn achtergebleven; veel apps ruimen zichzelf niet op. Het artikel [Shopify theme speed](/shopify-theme-speed) laat zien wat de score daadwerkelijk beweegt. ## Waar u snelheid meet en wat het u vertelt | Meting | Wat het meet | Gebruik het voor | | --- | --- | --- | | Search Console Core Web Vitals | Echte bezoekers, per URL-groep | Bepalen of er een probleem is en op welk template | | PageSpeed Insights (veld) | Echte bezoekers op één URL | Eén product- of collectiepagina controleren | | PageSpeed Insights (lab) | Een gesimuleerde lading | Oorzaken vinden, niet om te rapporteren | | Shopify-snelheidsscore in admin | Eigen labmeting van Shopify | Trend volgen, geen doel op zich | ## Content: blog en pagina's met een doel Een blog op Shopify ranket prima, mits elk artikel een vraag beantwoordt die uw klanten daadwerkelijk stellen en doorlinkt naar de collectie die erbij hoort. **18. Begin bij zoekvragen.** Typ uw categorie in Google en kijk naar de suggesties en de vragen. "Hoe was ik een wollen trui" is een artikel dat naar uw truiencollectie linkt. Vijf van zulke artikelen per categorie doen meer dan vijftig nieuwsberichten. **19. Link vanuit elk artikel.** Naar de collectie, naar de producten die u noemt en naar verwante artikelen. Een artikel zonder interne links is een doodlopende weg. Het artikel [Shopify blog SEO](/shopify-blog-seo) behandelt de opbouw. **20. Onderhoud oude artikelen.** Een artikel uit 2024 met een verouderd retourbeleid of een verdwenen product schaadt vertrouwen. Werk het bij of verwijder het met een redirect naar het beste alternatief. ## Nederland, België en Markets Wie in Nederland en België verkoopt, heeft te maken met twee landen, twee btw-regimes, twee talen in België en, als u wilt, meerdere valuta. Shopify Markets regelt meerdere valuta en gelokaliseerde domeinen; de SEO-kant vraagt een paar bewuste keuzes. **21. Kies submappen of eigen domeinen bewust.** Een submap zoals /nl-be/ deelt de autoriteit van uw hoofddomein; een eigen .be-domein moet zijn eigen autoriteit opbouwen maar oogt lokaler. Voor de meeste webshops zijn submappen de verstandige start. **22. Vertaal ook de metadata.** Shopify genereert hreflang-tags voor elke markt, maar de titels en metabeschrijvingen vertaalt u zelf. Doe dat ook voor de Franstalige versie van België; een Franstalige klant die op een Nederlandse pagina landt, is weg. **23. Lokaliseer de inhoud, niet alleen de taal.** Verzendkosten met PostNL of bpost, iDEAL of Bancontact bij de betaalmethoden, retouradres, btw-vermelding. Zoekmachines en klanten zien het verschil tussen een vertaalde Nederlandse winkel en een Belgische winkel. Het artikel [Shopify in België: Bancontact, btw en verzending](/nl/shopify-belgie-bancontact-btw-verzending) behandelt de praktische kant. ## AI-zoekmachines en gestructureerde data ChatGPT, Perplexity en Google AI Overviews citeren pagina's die ze schoon kunnen uitlezen en betrouwbaar kunnen toeschrijven. Dat is grotendeels dezelfde discipline als goede SEO, met twee extra accenten. **24. Beantwoord de vraag in de eerste alinea.** Onder elke kop eerst het antwoord, daarna de toelichting. AI-systemen halen een passage uit een pagina; een passage die op zichzelf staat, wordt vaker gebruikt. Een FAQ-blok met echte klantvragen helpt om dezelfde reden. **25. Schema en auteur.** Product, Organization, FAQ, Breadcrumb en Article-schema, één keer en correct, plus een zichtbare auteur met een korte bio op artikelen. Het artikel [Shopify GEO and AI search](/shopify-geo-ai-search) beschrijft wat aantoonbaar helpt en wat mythe is. ## Hoe u de checklist gebruikt Doe niet alles tegelijk. Vijfentwintig punten in één sprint betekent dat u na drie weken nog niets hebt gemeten. Werk in deze volgorde en meet na elke stap in Search Console. ## De eerste vier weken - Week 1: Search Console verifiëren, sitemap indienen, Core Web Vitals-rapport lezen, apps tellen en ongebruikte apps verwijderen - Week 2: de tien belangrijkste collecties voorzien van eigen tekst, titel en metabeschrijving - Week 3: de twintig best verkopende producten voorzien van eigen beschrijvingen en alt-teksten - Week 4: gestructureerde data testen, dubbele URL's noindexen, één blogartikel per hoofdcategorie plannen - Doorlopend: elke maand het rapport Prestaties in Search Console lezen en de pagina's met veel vertoningen en weinig klikken herschrijven Wanneer heeft u hulp nodig? Bij de technische punten als uw thema het schema niet levert of als robots.txt.liquid u niet vertrouwd is, bij snelheid als de apps eruit zijn en de score nog steeds tegenvalt, en bij content als u geen tijd heeft om te schrijven. Een technische SEO-audit met fixes begint bij ByteInfy [vanaf $1.000](https://byteinfy.com/services/shopify-seo); de meeste punten hierboven kunt u echter zelf doen, en dat is ook de bedoeling van deze lijst. **Wilt u weten welke van de 25 punten bij u niet op orde zijn?** Stuur uw webshop-URL en u krijgt een korte, eerlijke inschatting van wat de meeste impact heeft en wat u zelf kunt oppakken. [Praat met ByteInfy](https://byteinfy.com/contact) ## FAQ ### Is Shopify goed voor SEO? Ja, de basis is in orde. Sitemap, canonicals, https, redirects en bewerkbare titels en metabeschrijvingen zitten in het platform. Wat u niet kunt veranderen is de URL-structuur met /collections/ en /products/. ### Welke Shopify SEO tips hebben het meeste effect? Collectiepagina's met eigen tekst en een logische titel, productpagina's met unieke beschrijvingen in plaats van leverancierstekst, en het verwijderen van apps die de winkel vertragen. ### Heb ik een SEO-app nodig op Shopify? Meestal niet. Titels, metabeschrijvingen, alt-teksten en redirects zijn standaard bewerkbaar. Een app is nuttig voor bulkbewerking van alt-teksten of voor gestructureerde data als uw thema die niet levert. ### Hoe ga ik om met dubbele content op Shopify? Shopify zet zelf een canonical van /collections/x/products/y naar /products/y. Wat u zelf oplost zijn tag-pagina's, filtercombinaties en varianten met een eigen URL die geïndexeerd worden. Zet daar een noindex op of bewerk robots.txt.liquid. ### Hoe werkt SEO voor Nederland en België tegelijk? Met Shopify Markets krijgt elke markt een submap of een eigen domein, en Shopify genereert de hreflang-tags. ### Telt snelheid mee voor SEO? Ja, via Core Web Vitals. Meet op product- en collectiepagina's met velddata uit Search Console, niet met de snelheidsscore in uw Shopify-admin. ### Hoe word ik zichtbaar in ChatGPT en Google AI Overviews? Door pagina's te maken die een vraag direct beantwoorden, met een duidelijke kop, gestructureerde data en een herkenbare auteur. AI-zoekmachines citeren wat ze schoon kunnen uitlezen en betrouwbaar kunnen toeschrijven. --- --- title: "Shopify POS in India: What Works and What Does Not" description: "Most Shopify POS guides are written from a US perspective and describe a setup that is not straightforwardly available in India. Here is the honest local picture." author: "Aashish Kaushik" published: 2026-09-22T13:00:49.123Z updated: 2026-09-22T13:00:49.321Z url: https://blog.byteinfy.com/shopify-pos-india --- # Shopify POS in India: What Works and What Does Not ## Key takeaways - Shopify POS works in India, but the first-party hardware and payments experience available in the US and UK does not transfer directly. - GST-compliant invoicing is the single largest gap and usually needs an app or an integration with existing accounting software. - The unification benefit — one catalogue, one customer, one inventory pool across online and retail — is real in India and is the actual reason to choose it. - Verify payments, hardware and tax handling for your specific setup before committing, because the answer changes by year and by city. Most Shopify POS material is written from a US perspective, and it describes an experience that does not fully transfer. Shopify's own card readers, its first-party payment processing, and the hardware ecosystem around them are shaped by markets where Shopify Payments has deep support. India is not one of those markets in the same way. That does not mean Shopify POS is a bad choice here. It means the evaluation is different, and the parts you need to verify are different. This is the local picture, including the gaps. > **Verify currently, not from any article** > > Payments, hardware availability and tax handling in India change year to year. Everything below should be confirmed against Shopify's current documentation and your payment provider before you buy anything. Including this article. ## What genuinely transfers The core proposition is unaffected by geography, and it is the actual reason to consider Shopify POS. Retail and online run on one system. One catalogue, one customer record, one inventory pool, one set of reports. A sale in the shop decrements the same stock your website sells from. A customer who bought online and walks in is the same customer, with their history visible. For a retailer who also sells online, this removes an entire category of daily work — the reconciliation between two systems that each think they are authoritative. That benefit is identical in Mumbai and Manchester, and it is what should drive the decision. The 2026 releases strengthened this further with mixed fulfilment, letting one order combine ship-to-home and in-store pickup items, and support for running multiple legal entities from a single store rather than one Shopify instance per entity. The second is genuinely useful for Indian groups operating retail and online under different companies, which is a common structure. ## Payments: the first thing to verify This is where the divergence is sharpest. In markets with full Shopify Payments support, the flow is seamless: Shopify's own reader, Shopify's processing, everything settled and reported in one place. In India, that first-party path is not the default assumption, and retailers typically operate differently. The common patterns: **A separate card terminal alongside Shopify POS.** The customer pays on your existing terminal, the sale is recorded in Shopify POS as the corresponding payment type. This works and is widely done. The cost is that settlement and reconciliation happen in two systems rather than one, which erodes some of the unification benefit. **UPI and QR-based payment**, recorded similarly. Given UPI's dominance in Indian retail, this matters more here than any guide written elsewhere will tell you, and how gracefully your setup handles it is worth testing specifically. **Cash**, which the 2026 releases improved with a built-in cash ledger handling tracking, reconciliation and reason codes on the device. For cash-heavy Indian retail this is a genuine improvement over informal till management. Verify, before committing: which processors are supported, what happens to reconciliation when payment is taken outside Shopify, and whether the reporting you need still works when payment data arrives from elsewhere. ## GST is the largest gap Be direct about this one, because it is the most common reason Indian retailers reject Shopify POS after evaluating it. Shopify calculates tax and can be configured with GST rates. What it does not do natively is produce the full GST-compliant invoice an Indian business needs — correct format, HSN codes, the split between CGST, SGST and IGST presented as required, and a numbering scheme that satisfies filing. The routes available: ## Handling GST with Shopify POS | Approach | What it gives you | Cost | | --- | --- | --- | | GST invoicing app | Compliant invoices generated from Shopify orders | Monthly fee, another dependency | | Integration with accounting software | Orders sync to a system built for Indian compliance | Setup work, sync failure modes | | Custom development | Exactly the invoice and workflow you need | Build and maintain | | Manual, outside Shopify | Full control | Not viable at any volume | Most retailers land on an integration with the accounting software they already use, because filing happens there regardless. The point to internalise is that this is a requirement to solve during implementation, not a gap discovered afterwards — and it should be part of the cost calculation when comparing Shopify POS against a local POS that handles GST natively. ## Hardware, verified locally Do not order hardware from a compatibility list written for another market. The questions that matter: - Is the device sold in India, with support and replacement? A reader with no local supply chain is a single point of failure with a long lead time. - Does it work with your chosen payment path? Hardware and processing are coupled, and this is where the market difference bites. - Receipt printer, cash drawer, barcode scanner — these are more standardised and generally less problematic, but confirm the specific models. - What is the fallback when a device fails? Every counter needs a way to keep trading. ## Before committing in India - Confirm your payment path end to end, including settlement and reconciliation - Decide and cost your GST invoicing route - Verify every hardware item is locally available and supported - Test what happens when connectivity drops mid-transaction - Check the reports your accountant needs can actually be produced - Run one location before rolling out to several The connectivity item deserves emphasis. Retail locations in India vary enormously in connection quality, and offline behaviour should be tested under realistic conditions rather than trusted from a feature list. ## When a local POS is the better answer An honest comparison needs this section. If you are a **purely offline retailer** with no online presence and no plan for one, Indian POS systems built for local billing, GST and hardware will generally serve you better and cost less. The unification benefit — the entire reason to choose Shopify POS — is worth nothing to you. If you have **complex local compliance requirements**, sector-specific billing rules, or need deep integration with an Indian accounting or inventory package, a system built for that market is likely to fit better than Shopify plus integrations. If you are **price-sensitive with many small outlets**, the per-location Pro pricing compares unfavourably with local systems charging per terminal or flat. Shopify POS wins when online and offline are both real parts of your business. That is the honest boundary. ## The cost model in practice POS Lite is included with your Shopify plan. POS Pro is charged per location. The consequence is that the calculation is about footprint, not headcount. Staff are free. Additional tills within one location are free. Each new location is not. A business with one shop and eight staff pays once; a business with four kiosks pays four times regardless of how quiet they are. Model this against your actual expansion plan, and include the GST solution and any payment integration in the total. Comparing Shopify POS Pro against a local POS on licence fee alone will mislead you in both directions. ## Staff, training and the adoption risk The failure that sinks POS projects in India is rarely technical. It is that the counter staff do not use the system the way it was designed, and the data quality degrades until the reports stop being trusted. This risk is higher than in markets where staff have usually encountered similar systems before. If your team has been running a till that does one thing well, moving to a system that also manages customers, inventory and omnichannel orders is a genuine change in job description, not a software update. What reduces the risk: **Configure permissions before launch, not after.** Decide which roles can discount, refund, open the drawer and edit inventory. Retrofitting this onto a store where everyone shares a manager login is much harder than setting it up on day one, and shared logins destroy the per-staff attribution that makes the reporting worth having. **Train on the awkward transactions, not the easy ones.** Everyone can process a straightforward sale after ten minutes. The training that matters covers returns, exchanges, the online customer walking in, and what to do when the connection drops. **Give it a fallback everyone knows.** Staff who are unsure what to do when something fails will invent a workaround, and the workaround becomes permanent. A written, practised fallback prevents a year of unreconcilable entries. **Expect a slower first fortnight** and staff it accordingly. A queue forming while someone learns the interface is how a good system acquires a bad reputation internally, and internal resistance is much harder to reverse than a configuration error. ## A sensible evaluation sequence 1. Confirm the unification benefit applies to you. If you do not sell online, stop here and evaluate local systems. 2. Solve payments on paper before anything else — processor, hardware, reconciliation. 3. Decide the GST route and cost it. 4. Trial with one location, running your five most common awkward transactions. 5. Test offline behaviour and a device failure. 6. Then decide about rolling out. Step four matters more than any feature comparison. Write down the transactions your staff currently handle awkwardly — the returns, the exchanges, the customer who bought online — and check each one in a trial. Those are what you are buying a fix for. For the full platform picture, see [POS and operations](/category/pos-operations). GST invoicing specifics and payment methods for Indian stores are covered in the same archive and in [checkout and payments](/category/checkout-payments). **Running retail and online in India?** ByteInfy builds Shopify integrations for Indian merchants — GST invoicing, payment reconciliation and the operational pieces the platform leaves open. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Does Shopify POS work in India? Yes, Shopify POS is usable in India. The differences from markets like the US and UK are in payment processing and hardware, where Shopify Payments supports its own card readers directly. ### Can Shopify POS generate GST-compliant invoices? Not fully out of the box in the way an Indian accounting package does. ### What payment hardware can I use with Shopify POS in India? This is the question to verify directly and currently, because the answer has changed repeatedly. Shopify's first-party readers are tied to Shopify Payments availability, which differs by market. ### Is Shopify POS worth it for a single-store retailer in India? If you also sell online, usually yes, because the unification is the value. ### How does Shopify POS pricing work in India? POS Lite is included with your Shopify plan. --- --- title: "Shopify bureau kosten 2027: wat een webshop echt kost" description: "Een offerte van een Shopify bureau zegt weinig zonder context. Dit is wat de prijs bepaalt, wat er na de lancering bijkomt en hoe u twee offertes naast elkaar legt." author: "Aashish Kaushik" published: 2026-09-22T05:00:48.493Z updated: 2026-09-22T05:00:48.533Z url: https://blog.byteinfy.com/shopify-bureau-kosten-2027-wat-webshop-echt-kost --- # Shopify bureau kosten 2027: wat een webshop echt kost ## Key takeaways - De bouwprijs is zelden de grootste kostenpost over drie jaar; abonnement, apps, betaalkosten en onderhoud zijn dat wel. - Een goede offerte noemt scope, wat er buiten valt, wie de code bezit en wat onderhoud na de lancering kost. - Een thema aanpassen begint bij enkele honderden tot duizend dollar, een nieuwe webshop bij enkele duizenden, headless bij vijfduizend en meer. - Vergelijk offertes op dezelfde scope en op wat u na de oplevering zelf kunt, niet op het eindbedrag alleen. Een Shopify-webshop laten bouwen door een bureau kost in 2027 ergens tussen ongeveer duizend dollar voor een aanpassing op een bestaand thema en enkele tienduizenden dollars voor een headless storefront met eigen contentmodel en koppelingen. Het middenveld, een nieuwe webshop op Online Store 2.0 met eigen secties, ligt meestal tussen tweeduizend en achtduizend dollar. Dat zijn de bouwkosten. De totale kosten over drie jaar zien er anders uit, en dat is het bedrag waar u op moet rekenen. Deze gids gaat over die totale rekening. Wat de bouwprijs bepaalt, welke kosten er na de oplevering elke maand bijkomen, hoe een bureau in Nederland zich verhoudt tot een bureau buiten Europa, en hoe u twee offertes eerlijk naast elkaar legt. Wilt u eerst weten hoe u überhaupt een bureau beoordeelt, lees dan [Een Shopify bureau kiezen: 12 vragen vooraf](/nl/shopify-bureau-kiezen-12-vragen-vooraf). > **Geschreven door een bureau** > > Lees deze gids met dat in gedachten. De prijzen hieronder zijn de startprijzen die wij zelf publiceren, en de vragen zijn de vragen die wij van een goede opdrachtgever verwachten. Een bureau dat er ongemakkelijk van wordt, is een signaal. ## Wat de prijs van een Shopify bureau bepaalt De prijs volgt de scope, en de scope wordt bepaald door vijf dingen: het thema, de catalogus, de koppelingen, de checkout en wie het na de lancering onderhoudt. **Thema of maatwerk.** Een gekocht thema uit de Shopify Theme Store dat u laat instellen en aanvullen met een paar eigen secties is de goedkoopste route. Een maatwerkthema waarin elke sectie door uw team te bewerken is kost een veelvoud, omdat er ontworpen, gebouwd en getest wordt. Welke van de twee u nodig heeft, hangt af van hoe ver uw merk van de standaardthema's afstaat. Het artikel [Shopify theme vs custom](/shopify-theme-vs-custom) behandelt die afweging in detail. **Catalogus.** Vijftig producten met drie varianten is een middag werk. Vijfduizend producten met metafields, maten, materialen en filters is een migratieproject op zich. Ook de kwaliteit van uw huidige data telt mee: schone spreadsheets zijn goedkoper dan een export uit een oud systeem die eerst opgeschoond moet worden. **Koppelingen.** Elke koppeling met een extern systeem kost geld: boekhouding, magazijn, PIM, marketplace zoals Bol.com, verzendsoftware. Sommige lopen via een bestaande app, andere vragen om maatwerk. Elke maatwerkkoppeling moet bovendien onderhouden worden, want de API aan beide kanten verandert. **Checkout.** Sinds checkout.liquid is vervangen door Checkout Extensibility loopt alles wat u in de checkout wilt aanpassen via UI-extensies en Shopify Functions. Dat is degelijker dan vroeger, maar het is ontwikkelwerk met een prijs. Een kortingsregel of een bezorgregel als Function is een afgebakend stuk werk; een complete B2B-checkout is dat niet. **Onderhoud.** Wie na de lancering de theme-updates test, apps verwijdert, secties bijbouwt en een kapotte pagina voor een campagne repareert. Als het antwoord "niemand" is, komt dat later alsnog op de factuur, maar dan met spoedtoeslag. ## Startprijzen per dienst De onderstaande bedragen zijn de startprijzen die ByteInfy publiceert op zijn [dienstenpagina](https://byteinfy.com/services), in Amerikaanse dollars zoals daar vermeld. Ze zijn bedoeld als ijkpunt om offertes tegen af te zetten, niet als marktbrede waarheid: een bureau in Amsterdam of Antwerpen met een grotere overhead zit hoger, een freelancer soms lager. ## Startprijzen Shopify-diensten (USD, op het moment van schrijven) | Dienst | Startprijs | Waar het meestal op uitkomt | | --- | --- | --- | | Thema aanpassen (secties, landingspagina's) | vanaf $1.000 | $1.000 tot $3.000 per vast afgebakend pakket | | Nieuwe webshop op Online Store 2.0 | vanaf $2.000 | $2.000 tot $8.000 afhankelijk van catalogus en koppelingen | | Migratie vanaf WooCommerce, Magento of Wix | vanaf $1.500 | ERP en multi-store na scoping | | Checkout-extensies en Shopify Functions | vanaf $1.500 | $1.500 tot $3.000 per Function of extensie | | Maatwerk Shopify-app voor één webshop | vanaf $3.000 | publieke App Store-app $8.000 tot $25.000 | | Headless storefront (Hydrogen of Next.js) | vanaf $5.000 | tot $25.000 en meer met contentmodel en multi-market | | Technische SEO-audit en fixes | vanaf $1.000 | doorlopend $1.000 tot $3.000 per maand | | Snelheidsoptimalisatie (Core Web Vitals) | vanaf $750 | $750 tot $1.500 per thema | | Onderhoud en support | vanaf $500 per maand | monitoring plus vijf ontwikkeluren | Twee opmerkingen bij deze tabel. Ten eerste: de rechterkolom is belangrijker dan de linker. "Vanaf" zegt alleen waar het begint; de bandbreedte zegt wat u waarschijnlijk betaalt. Ten tweede: geen enkel bedrag hierboven bevat het Shopify-abonnement, apps of transactiekosten. Daar gaat de volgende sectie over. ## Uurtarief, vaste prijs of retainer Voor een afgebakend project wilt u een vaste prijs op een geschreven scope. Voor doorlopend werk wilt u een retainer. Een kaal uurtarief zonder inschatting is voor u als opdrachtgever de duurste vorm, omdat alle onzekerheid bij u ligt. Een vaste prijs werkt alleen als de scope op papier staat: welke pagina's, welke secties, welke koppelingen, wat "klaar" betekent en wat er gebeurt met wijzigingen halverwege. Een bureau dat een vaste prijs geeft zonder scoping-gesprek gokt, en gokt in zijn eigen voordeel. Een bureau dat eerst een uur met u belt en daarna een prijs stuurt, heeft nagedacht. Een retainer met een urenbank is logisch zodra u elke maand kleine dingen nodig heeft: een campagnepagina, een sectie erbij, een app die eruit moet, een theme-update die getest moet worden. U betaalt een vast bedrag, krijgt een vast aantal uren en weet wie er opneemt als er iets kapot is. Vraag of ongebruikte uren meegaan naar de volgende maand en wat de opzegtermijn is. Een uurtarief is prima voor werk dat niemand vooraf kan inschatten, zoals het ontwarren van een thema waar drie vorige bureaus in hebben zitten. Spreek dan een plafond af en een moment waarop het bureau stopt en rapporteert. ## De kosten die niet op de offerte staan De bouwprijs is een eenmalig bedrag. Wat een webshop echt kost, bepaalt u door de maandelijkse kosten over drie jaar bij elkaar op te tellen. **Shopify-abonnement.** De reguliere plannen zijn maandbedragen in de tientallen tot lage honderden euro's. Shopify Plus begint op het moment van schrijven rond USD 2.300 per maand bij een driejarig contract. Plus is pas interessant bij hoge volumes of bij checkout-aanpassingen die de reguliere plannen niet toestaan; laat een bureau u niet naar Plus praten omdat het voor hen makkelijker bouwt. **Apps.** Elke app is een abonnement, en elke app voegt scripts toe die uw winkel langzamer maken. Tien apps van twintig euro is tweehonderd euro per maand, oftewel meer dan zevenduizend euro over drie jaar. Een bureau dat een maatwerksectie voorstelt in plaats van een app is soms duurder in de bouw en goedkoper over de looptijd. Het artikel [How many Shopify apps is too many](/how-many-shopify-apps-is-too-many) laat zien waar die grens ligt. **Betaalkosten.** iDEAL en Bancontact zijn beschikbaar via Shopify Payments; per transactie betaalt u een vergoeding die per plan verschilt. Klarna en creditcards zijn duurder per transactie dan iDEAL. Bij een omzet van een paar ton per jaar zijn betaalkosten al snel een grotere post dan de bouw. **Verzendsoftware.** PostNL, DHL of DPD koppelt u meestal via een verzendplatform, dat zelf een maandbedrag en een prijs per label rekent. **Onderhoud.** Shopify schakelt oude API-versies op een vast schema uit, en thema's krijgen updates die uw maatwerk kunnen raken. Wat er niet wordt bijgehouden, breekt op het slechtste moment, meestal vlak voor een campagne. Zie [Shopify API versioning](/shopify-api-versioning) voor hoe dat schema werkt. > **Reken met drie jaar, niet met de lancering** > > Een webshop van vierduizend dollar met tweehonderd euro aan apps, vijfhonderd dollar onderhoud en betaalkosten kost over drie jaar een veelvoud van het bouwbedrag. Vraag een bureau om de maandelijkse kosten expliciet in de offerte te zetten, ook de kosten die niet aan het bureau zelf worden betaald. ## Bureau in Nederland of België, of daarbuiten Het uurtarief van een bureau in Amsterdam, Utrecht of Gent ligt hoger dan dat van een bureau in India of Oost-Europa. Dat is geen geheim. De vraag is wat u voor het verschil terugkrijgt, en of het bureau buiten Europa uw markt kent. Een lokaal bureau heeft voordelen die u niet in een offerte terugziet: het kent iDEAL, Bancontact en de btw-regels uit ervaring, het zit in uw tijdzone, en u kunt langsgaan. Het nadeel is de prijs en soms de wachttijd; goede lokale bureaus hebben een planning die maanden vooruit vol zit. Een bureau buiten Europa, ByteInfy is zelf een Shopify-bureau gevestigd in India dat met internationale merchants werkt, is per uur goedkoper en werkt vaak sneller op de kleinere klussen. De risico's zijn bekend: communicatie, tijdzone, en de vraag of het bureau Shopify Payments met iDEAL, de Nederlandse btw of het Belgische tweetalige landschap begrijpt. Vraag naar eerder werk voor Europese webshops, naar wie uw vaste aanspreekpunt is en op welke uren die bereikbaar is. Het artikel [Shopify agency India vs USA cost](/shopify-agency-india-usa-cost) zet de prijsverschillen in perspectief. Fiscaal is het overzichtelijk: een dienst van een bureau buiten de EU aan een Nederlandse of Belgische onderneming valt onder de verleggingsregeling. U geeft de btw zelf aan en trekt die in dezelfde aangifte weer af. Bespreek de precieze verwerking met uw boekhouder, maar laat het geen reden zijn om een bureau af te wijzen. ## Hoe u twee offertes eerlijk vergelijkt Twee offertes met hetzelfde eindbedrag beschrijven zelden hetzelfde werk. Voordat u naar de prijs kijkt, legt u ze naast elkaar op scope. ## Vergelijk offertes op deze punten - Dezelfde functielijst: welke pagina's, secties, koppelingen en checkout-regels zitten erin, en welke expliciet niet - Thema: gekocht en ingesteld, of maatwerk waarin uw team elke sectie zelf kan bewerken - Data: wie de producten, klanten en orders migreert en wie de kwaliteit controleert - Eigendom: wie de code bezit, waar de repository staat en wat u meekrijgt als de samenwerking stopt - Onderhoud: wat het per maand kost, wat erin zit en hoe snel er gereageerd wordt bij een storing - Meerwerk: wat een wijziging halverwege kost en hoe die wordt goedgekeurd - Maandelijkse kosten: abonnement, apps, betaalkosten en verzendsoftware expliciet opgeteld - Wat u zelf kunt: welke wijzigingen uw team na de oplevering zonder het bureau doorvoert Het laatste punt vergeten de meeste opdrachtgevers. Een webshop waarvoor u bij elke tekstwijziging het bureau nodig heeft, heeft een eenmalige kostenpost omgezet in een permanente. Vraag expliciet wat uw eigen team na de lancering kan. Let ook op wat een bureau niet vraagt. Een offerte zonder vragen over uw assortiment, uw huidige systemen en uw doelgroep is een sjabloon met uw naam erboven. De offerte die u wilt, komt na een gesprek waarin het bureau u minstens één keer heeft afgeraden iets te bouwen. ## Wanneer u te veel betaalt, en wanneer te weinig Te veel betalen herkent u aan scope die u niet nodig heeft. Headless waar een snel thema volstaat, een maatwerk-app waar een bestaande app het voor twintig euro per maand doet, Shopify Plus voor een winkel die nog geen tienduizend orders per jaar draait. Een bureau dat standaard de duurste route adviseert, verkoopt scope in plaats van oordeel. Te weinig betalen herkent u aan wat er ontbreekt. Geen redirects bij een migratie, geen test van de betaalmethoden, geen snelheidsmeting op product- en collectiepagina's, geen documentatie, geen onderhoudsvoorstel. Die dingen kosten geld, en als ze niet in de offerte staan, worden ze niet gedaan. De goedkoopste offerte is vaak de offerte waarin het meeste is weggelaten. Er is een betrouwbare manier om dat te testen zonder groot risico: begin klein. Laat een bureau eerst een afgebakende klus doen, zoals een audit, een landingspagina of één koppeling. U leert hoe ze communiceren, hoe goed hun inschatting klopt en wat hun code waard is, op een project waar u zonder schade van kunt weglopen. De Engelse gids [hire a Shopify development agency](/hire-shopify-development-agency) beschrijft hoe u zo'n eerste opdracht inricht. ## Wat u nu kunt doen Schrijf uw scope uit voordat u offertes aanvraagt. Beschrijf het probleem, niet de oplossing: "onze mobiele productpagina verliest bezoekers vóór de koopknop" geeft een bureau iets om op te lossen, "bouw een maatwerkthema" geeft een instructie die de verkeerde kan zijn. Noem wat niet mag veranderen, zoals URL's en koppelingen waar u van afhankelijk bent, en wie bij u beslist. Vraag daarna aan twee of drie bureaus een vaste prijs op die scope, met de maandelijkse kosten erbij en een onderhoudsvoorstel. Vergelijk op de checklist hierboven. Kies niet op het laagste bedrag, maar op de offerte die de meeste van uw vragen al beantwoordt voordat u ze stelt. **Wilt u weten wat uw webshop echt gaat kosten?** Stuur uw scope of uw huidige webshop en u krijgt een eerlijke inschatting, inclusief het advies om iets niet te bouwen als dat beter is. [Praat met ByteInfy](https://byteinfy.com/contact) ## FAQ ### Wat kost een Shopify webshop laten bouwen door een bureau? Dat hangt af van de scope. Een aanpassing op een bestaand thema begint bij ongeveer duizend dollar, een nieuwe webshop op Online Store 2. ### Waarom verschillen offertes van Shopify bureaus zo sterk? Omdat ze zelden dezelfde scope beschrijven. Het ene bureau rekent een gekocht thema met instellingen, het andere een maatwerkthema met eigen secties, checkout-extensies en koppelingen. ### Welke kosten komen er na de lancering bij? Het Shopify-abonnement, appabonnementen, transactiekosten van betaalmethoden zoals iDEAL en creditcard, verzendsoftware en onderhoud. Shopify wijzigt zijn platform doorlopend en schakelt oude API-versies uit, dus maatwerk moet worden bijgehouden. ### Is een bureau in het buitenland goedkoper? Vaak wel per uur, maar het verschil zit in de totale prijs en in wat u terugkrijgt. ### Moet ik een uurtarief of een vaste prijs afspreken? Voor een afgebakend project is een vaste prijs op een geschreven scope het veiligst. Voor doorlopend werk is een maandelijkse retainer met een urenbank overzichtelijker dan losse facturen. ### Betaal ik btw over een buitenlands bureau? Bij een dienst van een bureau buiten de EU aan een Nederlandse of Belgische onderneming wordt de btw meestal verlegd. U geeft de btw zelf aan en trekt die in dezelfde aangifte weer af. ### Wat is een redelijk bedrag voor onderhoud? Onderhoudsplannen beginnen rond vijfhonderd dollar per maand voor monitoring en een klein aantal ontwikkeluren. Grotere urenbanken zijn per uur goedkoper. --- --- title: "Headless Shopify mit Hydrogen: wann es sich lohnt" description: "Headless tauscht Shopifys Standardverhalten gegen Kontrolle, und Sie erben alles, was diese Standards still erledigt haben. Für welche Shops sich das lohnt, was es kostet und warum ein gutes Theme in den meisten Fällen die bessere Antwort ist." author: "Aashish Kaushik" published: 2026-09-21T13:00:48.485Z updated: 2026-09-21T13:00:48.488Z url: https://blog.byteinfy.com/headless-shopify-mit-hydrogen-wann-es-sich-lohnt --- # Headless Shopify mit Hydrogen: wann es sich lohnt ## Key takeaways - Headless mit Hydrogen lohnt sich, wenn der Theme-Editor Ihren Anforderungen wiederholt im Weg steht, nicht weil es moderner klingt. - Was Sie verlieren, ist unsichtbar bis zum Launch: Theme-Editor, App-Erweiterungen im Storefront, automatische SEO-Grundlagen, Markets-Integration ohne Code. - Headless ist nicht automatisch schneller; ein gut gebautes Theme schlägt einen nachlässig gebauten Headless-Storefront jedes Mal. - Ein Headless-Build beginnt bei ByteInfy bei 5.000 $ und reicht bis 25.000 $ und mehr; der größere Posten ist das Team, das ihn danach betreibt. Headless Shopify mit Hydrogen lohnt sich, wenn der Theme-Editor Ihren Anforderungen wiederholt im Weg steht, wenn mehrere Märkte eigene Merchandising-Logik brauchen oder wenn ein eigenes Engineering-Team den Storefront betreiben wird. Für die meisten Händler in Deutschland, Österreich und der Schweiz trifft keiner dieser Punkte zu, und ein gut gebautes Theme auf Online Store 2.0 ist die bessere, günstigere und wartungsärmere Antwort. Das ist die kurze Fassung, und sie kommt von einer Agentur, die Headless-Storefronts baut. Die lange Fassung erklärt, was Headless technisch bedeutet, was Sie gewinnen, was Sie verlieren, was es kostet und wie Sie die Entscheidung so treffen, dass Sie sie in zwei Jahren nicht bereuen. Wer den englischen Ausgangsartikel lesen möchte: [Headless Shopify with Hydrogen](/headless-shopify-hydrogen). > **Headless ist nicht automatisch schneller** > > Das häufigste Argument für Headless ist Geschwindigkeit, und es ist das schwächste. Ein Headless-Storefront kann sehr schnell sein, weil Sie jedes Byte kontrollieren. Er kann auch langsam sein, weil dieselbe Kontrolle jedes Skript und jede Abfrage zu Ihrer Verantwortung macht. Ein gut gebautes Theme mit wenigen Apps erreicht gute Core Web Vitals ohne diesen Aufwand. Wer Geschwindigkeit will, räumt zuerst das Theme auf. ## Was Headless bei Shopify bedeutet Headless trennt das Frontend, also alles, was Kunden sehen, vom Backend, also Produkten, Bestellungen, Kunden und Checkout. Shopify bleibt das Backend und liefert Daten über die Storefront API. Das Frontend bauen Sie selbst. Hydrogen ist Shopifys eigenes Framework dafür, auf React aufgebaut, mit fertigen Bausteinen für Produktabfragen, Warenkorb, Kundenkonten und Markets. Oxygen ist das zugehörige Hosting bei Shopify. Die Alternative ist ein eigenes Framework wie Next.js mit eigenem Hosting, das dieselbe Storefront API nutzt. Der englische Beitrag [Hydrogen vs Next.js for headless Shopify](/hydrogen-next-js-headless-shopify) vergleicht beide. Was bleibt: der Checkout. Auch bei Headless läuft der Checkout bei Shopify, mit Shopify Payments, Klarna, PayPal, in der Schweiz TWINT, mit Checkout Extensibility und Shopify Functions. Das ist eine gute Nachricht, weil der Checkout der Teil ist, den Sie am wenigsten selbst bauen wollen. Was entfällt: das Theme, der Theme-Editor, die Theme App Extensions, mit denen Apps etwas im Storefront anzeigen, und die vielen kleinen Dinge, die ein Theme automatisch erledigt, von der Sitemap bis zum hreflang-Tag. Das ist der Teil, der bei der Entscheidung unterschätzt wird. ## Was Sie gewinnen Headless liefert drei Dinge, die ein Theme nicht liefern kann: volle Kontrolle über das Frontend, eigene Content-Modelle und die Freiheit, Shopify-Daten mit anderen Quellen zu mischen. **Kontrolle über das Frontend.** Jede Komponente, jede Interaktion, jedes geladene Byte ist Ihre Entscheidung. Für Marken, deren Design-Abnahme regelmäßig an "das kann das Theme nicht" scheitert, ist das der eigentliche Grund für Headless. Für Marken, deren Theme das Design abbildet, ist es Kontrolle ohne Nutzen. **Eigene Content-Modelle.** Ein inhaltsstarker Storefront mit Magazin, Ratgebern, Lookbooks und Produktgeschichten stößt im Theme-Editor an Grenzen. Headless erlaubt ein CMS wie Sanity oder Contentful oder Shopify Metaobjects als Content-Quelle, mit Redaktions-Workflows, die der Theme-Editor nicht hat. Der englische Artikel [Shopify metaobjects and metafields](/shopify-metaobjects-metafields) zeigt, wie weit man mit Bordmitteln kommt, bevor Headless nötig wird. **Mehrere Quellen in einem Storefront.** Wer Produktdaten aus Shopify mit Verfügbarkeiten aus einem ERP, Inhalten aus einem CMS und Filialdaten aus einem dritten System kombiniert, kann das im Theme nur über Apps und Metafelder abbilden. Headless macht daraus eine Frage der Datenschicht. Alle drei Punkte sind real. Die Frage ist, ob Ihr Shop einen davon braucht. ## Was Sie verlieren Was Sie verlieren, ist bis zum Launch unsichtbar, weil das Theme es still erledigt hat. Die Liste ist länger, als die meisten Händler erwarten. **Der Theme-Editor.** Jede Änderung, die im Theme-Editor ein Klick war, etwa ein neues Banner, eine umsortierte Sektion, ein geänderter Text auf der Startseite, ist bei Headless eine Codeänderung mit Deployment, oder sie braucht ein CMS, das Sie zusätzlich aufsetzen und pflegen. Ihr Marketing verliert die Fähigkeit, den Shop selbst zu verändern, wenn Sie das nicht bewusst zurückbauen. **Storefront-Apps.** Bewertungen, Bundles, Größentabellen, Shoppable Video, Upsells, Wunschlisten: Alles, was sich über Theme App Extensions in das Theme einhängt, funktioniert bei Headless nicht mehr automatisch. Jede dieser Funktionen wird über die API des App-Anbieters neu eingebaut, sofern es eine gibt, oder ersetzt. Admin-Apps für Bestellungen, Versand oder Buchhaltung bleiben unverändert. **SEO-Grundlagen.** Sitemap, Canonical-Tags, hreflang für Markets, strukturierte Daten für Produkte, Redirects, robots.txt: Das Theme liefert das ohne Ihr Zutun. Bei Headless bauen und pflegen Sie es. Es ist machbar, aber es ist Arbeit, und Fehler kosten Rankings. Vereinbaren Sie SEO-Parität mit dem bisherigen Shop als Abnahmekriterium; die [Shopify SEO Checkliste](/de/shopify-seo-optimierung-checkliste-mit-25-punkten) ist eine brauchbare Prüfliste dafür. **Markets ohne Code.** Shopify Markets deckt Mehrwährung und lokalisierte Domains ab, und im Theme funktioniert das mit wenigen Einstellungen. Hydrogen bringt Bausteine für Markets mit, aber Sprach- und Währungswechsel, Preisanzeige in CHF und Euro und die passenden hreflang-Tags sind Ihre Implementierung. **Kundenkonten, Suche, Filter.** Das Theme bringt Kundenkonto-Seiten, Suche und Kollektionsfilter mit. Bei Headless bauen Sie sie über die entsprechenden APIs nach. Jede davon ist überschaubar, zusammen sind sie Wochen. ## Theme auf Online Store 2.0 und Headless mit Hydrogen im Vergleich | Kriterium | Theme (Online Store 2.0) | Headless (Hydrogen) | | --- | --- | --- | | Änderungen am Storefront | Theme-Editor, ohne Entwickler | Code oder CMS, mit Deployment | | Storefront-Apps | Theme App Extensions, sofort nutzbar | über App-APIs neu einbauen oder ersetzen | | SEO-Grundlagen | automatisch (Sitemap, Canonical, hreflang) | selbst bauen und pflegen | | Markets (CHF, EUR, Sprachen) | Einstellungen | eigene Implementierung mit Hydrogen-Bausteinen | | Geschwindigkeit | gut, wenn Apps diszipliniert sind | sehr gut oder sehr schlecht, je nach Team | | Checkout | Shopify Checkout | Shopify Checkout, unverändert | | Startpreis bei ByteInfy | ab 2.000 $ (Shop-Entwicklung) | ab 5.000 $, bis 25.000 $ und mehr | | Betrieb nach dem Launch | Theme-Updates, Wartung ab 500 $ pro Monat | Engineering-Kapazität dauerhaft nötig | | Passt für | die meisten Händler in DACH | inhaltsstarke Marken, Multi-Market mit eigener Logik, Teams mit Engineering | ## Was Headless kostet, jetzt und später Ein Headless-Build hat zwei Kostenblöcke, und der zweite ist der, der Projekte scheitern lässt. Der erste Block ist der Bau. Bei ByteInfy beginnt ein fokussierter Headless-Storefront bei 5.000 $ und reicht mit individuellen Content-Modellen, mehreren Märkten und Integrationen bis 25.000 $ und mehr, wie auf der Seite [Headless Shopify](https://byteinfy.com/services/headless-shopify-hydrogen) beschrieben. Zum Vergleich: Eine Shop-Entwicklung auf Online Store 2.0 beginnt bei 2.000 $. Andere Agenturen kalkulieren anders; die Größenordnung des Unterschieds ist überall ähnlich. Was in einem Angebot stehen sollte, listet der Artikel [Shopify Agentur Kosten 2027](/de/shopify-agentur-kosten-2027-was-ein-shop-wirklich). Der zweite Block ist der Betrieb. Ein Theme wird von Shopify und dem Theme-Anbieter weiterentwickelt; Sie spielen Updates ein. Ein Headless-Storefront ist Ihre Software: Abhängigkeiten aktualisieren, API-Versionen nachziehen, Deployments, Monitoring, Fehlerbehebung. Das braucht entweder ein internes Team oder einen Retainer, der deutlich über dem eines Theme-Shops liegt. Wer diesen Block nicht über drei Jahre rechnet, vergleicht einen Baupreis mit einem Baupreis und übersieht, wo das Geld hingeht. Dazu kommen Kosten, die im Theme nicht anfallen: ein CMS mit eigener Lizenz, das Nachbauen von App-Funktionen, das Nachbauen der SEO-Grundlagen, und bei Next.js das Hosting. Oxygen ist bei Hydrogen Teil des Shopify-Angebots; die genauen Bedingungen hängen vom Plan ab und sollten vor der Entscheidung geprüft werden. ## Wann sich Headless lohnt Die Entscheidung fällt an vier Kriterien, und sie sollten ehrlich beantwortet werden, bevor ein Angebot eingeholt wird. ## Vier Fragen vor der Headless-Entscheidung - Scheitert die Design-Abnahme wiederholt daran, dass das Theme etwas nicht kann, und ist das Problem nach einer Theme-Anpassung immer noch da - Brauchen Sie ein Content-Modell mit Redaktions-Workflow, das Metaobjects und der Theme-Editor nicht abbilden - Haben mehrere Märkte (Deutschland, Österreich, Schweiz oder darüber hinaus) eigene Merchandising-Logik, die über Markets-Einstellungen hinausgeht - Gibt es ein Team, intern oder auf Retainer, das den Storefront nach dem Launch dauerhaft betreibt, inklusive Updates, Deployments und Monitoring Wenn Sie alle vier mit Ja beantworten, ist Headless eine gute Entscheidung, und Hydrogen ist ein guter Weg dorthin. Wenn Sie die vierte Frage mit Nein beantworten, ist Headless unabhängig von den anderen drei keine gute Entscheidung, weil der Storefront nach dem Launch verfällt. Wenn Sie nur die erste Frage mit Ja beantworten, ist die Antwort meist eine Theme-Anpassung oder ein individuelles Theme auf Online Store 2.0. Der englische Artikel [Shopify theme vs custom](/shopify-theme-vs-custom) beschreibt, wie weit ein individuelles Theme geht, und die Antwort ist: weiter, als die meisten Händler denken. Theme-Anpassungen beginnen bei ByteInfy bei 1.000 $. ## Wenn Sie es bauen: worauf es ankommt Wer die vier Fragen mit Ja beantwortet hat, sollte den Build so aufsetzen, dass die Verluste aus dem Abschnitt oben bewusst zurückgebaut werden. **Entscheiden Sie zuerst, dann modellieren Sie.** Eine kurze Discovery, die eine Frage ehrlich beantwortet: Zahlt sich Headless hier aus? Erst danach Content- und Datenmodell, dann Komponentensystem, dann Seiten. Wer mit Seiten beginnt, baut das Datenmodell dreimal. **Machen Sie SEO- und Performance-Parität zum Abnahmekriterium.** Sitemap, Canonical, hreflang, strukturierte Daten, Redirects und Core Web Vitals werden vor dem Launch gegen den bestehenden Shop gemessen, nicht danach. Der englische Artikel [Shopify theme speed](/shopify-theme-speed) nennt die Werte, die zählen. **Listen Sie jede Storefront-App vor dem Start.** Mit der Frage: Hat sie eine API, wird sie nachgebaut, wird sie ersetzt, oder entfällt sie? Diese Liste verhindert die Überraschung in Woche acht, wenn die Bewertungen fehlen. **Geben Sie dem Marketing ein Werkzeug zurück.** Ein CMS oder Metaobjects mit klaren Content-Typen, damit Banner, Kampagnen und Texte ohne Deployment änderbar sind. Sonst wird jede Kampagne zum Ticket. **Verlangen Sie Runbooks.** Deployment, Rollback, Monitoring, API-Umstellungen: dokumentiert so, dass Ihr Team den Storefront ohne die Agentur betreiben kann. Was Sie dazu vertraglich festhalten sollten, steht im Artikel [Shopify Agentur auswählen: 12 Fragen vor dem Vertrag](/de/shopify-agentur-auswahlen-12-fragen-vor-dem-vertrag). ## Die ehrliche Zusammenfassung Headless mit Hydrogen ist ein gutes Werkzeug für eine kleine Gruppe von Shops: inhaltsstarke Marken, Multi-Market-Setups mit eigener Logik, Teams mit Engineering-Kapazität. Für diese Gruppe ist es die richtige Entscheidung, und Hydrogen mit Oxygen ist der Weg mit der engsten Shopify-Integration. Für alle anderen ist ein gutes Theme auf Online Store 2.0 die bessere Antwort: günstiger im Bau, deutlich günstiger im Betrieb, mit Theme-Editor für das Marketing, mit Apps, die sofort funktionieren, mit SEO-Grundlagen, die ohne Zutun stimmen. Eine Agentur, die Ihnen das sagt, bevor sie ein Headless-Angebot schreibt, arbeitet in Ihrem Interesse. **Sie sind unsicher, ob Headless für Ihren Shop die richtige Entscheidung ist?** ByteInfy beantwortet in einem kurzen Gespräch die eine Frage, die zählt, nämlich ob Headless sich bei Ihnen auszahlt, und baut danach entweder den Hydrogen-Storefront oder das Theme, das Ihnen besser dient. [Mit ByteInfy sprechen](https://byteinfy.com/contact) ## FAQ ### Was bedeutet Headless bei Shopify? Headless trennt das Frontend, also das, was Kunden sehen, vom Backend, also Produkten, Bestellungen und Checkout. ### Ist Headless schneller als ein Shopify-Theme? Nur wenn es sorgfältig gebaut wird. Ein Headless-Storefront kann sehr schnell sein, weil Sie jedes geladene Byte kontrollieren. ### Was kostet Headless Shopify mit Hydrogen? Ein fokussierter Headless-Storefront beginnt bei ByteInfy bei 5.000 $ und reicht mit individuellen Content-Modellen, mehreren Märkten und Integrationen bis 25.000 $ und mehr. ### Hydrogen oder Next.js? Hydrogen, wenn Shopify den Storefront auf Oxygen hosten soll und Ihr Team mit React arbeitet; die Integration mit Storefront API, Warenkorb und Kundenkonten ist dort am engsten. Next.js, wenn Sie bereits Next. ### Funktionieren Shopify-Apps mit Headless? Teilweise. Apps, die im Admin arbeiten, etwa für Bestellungen, Versand oder Buchhaltung, funktionieren unverändert. ### Was passiert mit SEO bei Headless? Alles, was Shopify im Theme automatisch liefert, also Sitemap, Canonical-Tags, hreflang für Markets, strukturierte Daten und Redirects, muss im Headless-Storefront nachgebaut und gepflegt werden. ### Für welche Shops lohnt sich Headless? Für Shops mit einem inhaltsstarken Storefront, den der Theme-Editor nicht mehr abbildet, für Multi-Market-Setups mit eigener Merchandising-Logik, für Marken mit eigenem Engineering-Team, das den Storefront betreiben wird, und für Fälle, in denen die Design-Abnahme wiederholt an "das kann das Theme nicht" scheitert. --- --- title: "Shopify Agentur auswählen: 12 Fragen vor dem Vertrag" description: "Ein Portfolio zeigt, was gebaut wurde, nicht, ob es noch läuft. Zwölf Fragen, deren Antworten mehr über eine Shopify-Agentur verraten als jede Referenzliste, und was Sie vor der Unterschrift schriftlich festhalten sollten." author: "Aashish Kaushik" published: 2026-09-21T05:00:47.861Z updated: 2026-09-21T05:00:47.904Z url: https://blog.byteinfy.com/shopify-agentur-auswahlen-12-fragen-vor-dem-vertrag --- # Shopify Agentur auswählen: 12 Fragen vor dem Vertrag ## Key takeaways - Fragen Sie nach Projekten, die zwei Jahre alt sind und noch laufen; das zeigt, ob eine Agentur Shopifys Plattformänderungen übersteht. - Die Antworten auf Theme App Extensions, API-Versionen und Shopify Functions trennen Agenturen zuverlässiger als jede Fallstudie. - Code-Eigentum, Dokumentation, Zugänge und Wartung gehören vor dem Start in den Vertrag, nicht in das Gespräch bei der Trennung. - Eine Agentur, die Ihnen von etwas abrät, verkauft Urteilsvermögen statt Umfang, und das ist, was Sie eigentlich einkaufen. Eine Shopify-Agentur auszuwählen ist schwer, weil die Arbeit für den Käufer unsichtbar ist. Sie sehen den Shop, aber nicht den Code, und der Unterschied zwischen beidem zeigt sich erst, wenn achtzehn Monate später etwas geändert werden muss. Portfolios helfen dabei wenig: Sie zeigen, dass etwas gebaut und gelauncht wurde, aber nicht, ob es noch läuft, was die Wartung gekostet hat oder was es im Theme hinterlassen hat. Die zwölf Fragen in diesem Artikel ersetzen das Portfolio durch Antworten, die sich prüfen lassen. Sie sind in vier Gruppen sortiert: Referenzen, Technik, Zusammenarbeit und Vertrag. Am Ende stehen die Warnsignale und ein Vorschlag, wie Sie den ersten Auftrag so zuschneiden, dass Sie mit wenig Risiko viel über die Agentur lernen. Was ein Shop kostet und wie Sie ein Angebot lesen, behandelt der Artikel [Shopify Agentur Kosten 2027](/de/shopify-agentur-kosten-2027-was-ein-shop-wirklich). > **Geschrieben von einer Agentur** > > Lesen Sie entsprechend. ByteInfy ist eine Shopify-Agentur mit Sitz in Indien, die mit internationalen Händlern arbeitet. Die Fragen unten sind die, die wir selbst erwarten würden, und eine Agentur, die sie nur ungern beantwortet, verdient Vorsicht, uns eingeschlossen. ## Referenzen: Fragen 1 bis 3 Die ersten drei Fragen prüfen, ob die Arbeit einer Agentur hält, nicht nur, ob sie gelauncht wurde. **Frage 1: Zeigen Sie mir ein Projekt, das zwei Jahre alt ist und noch läuft.** Jeder kann etwas launchen. Die interessante Frage ist, was danach passiert ist: Läuft es noch, hat es Notfallarbeit gebraucht, hat es die Plattformänderungen seither überstanden. Shopify liefert laufend aus und stellt API-Versionen nach festem Zeitplan ab. Scripts sind abgekündigt, Checkout Extensibility hat checkout.liquid abgelöst, Themes haben sich mit Online Store 2.0 und Horizon verändert. Eine Agentur, die seit einigen Jahren baut, hat all das erlebt, und wie sie damit umging, ist ein besseres Signal als jede Fallstudie. **Frage 2: Was musste an älteren Projekten gerettet werden, und warum?** Jede Agentur hat Projekte, die nachgearbeitet werden mussten. Die Antwort zeigt, ob sie das offen benennt und was sie daraus geändert hat. "Nichts" ist keine glaubwürdige Antwort. **Frage 3: Haben Sie Erfahrung mit Händlern in Deutschland, Österreich oder der Schweiz?** Nicht wegen des Standorts, sondern wegen der Anforderungen: Rechtstexte und Button-Lösung, MwSt-Anzeige, Klarna und PayPal, DHL, für die Schweiz TWINT und CHF, für alle drei Länder Shopify Markets. Eine Agentur, die diese Themen von sich aus anspricht, hat sie schon gelöst. Was in Deutschland konkret verlangt wird, steht im Artikel [Shopify rechtssicher in Deutschland](/de/shopify-rechtssicher-deutschland-impressum-dsgvo-button). ## Technik: Fragen 4 bis 7 Vier technische Fragen, deren Antworten aufschlussreich sind, auch wenn Sie sie nicht vollständig bewerten können. **Frage 4: Wie bauen Sie Storefront-Funktionen für Apps ein?** Die Antwort sollte Theme App Extensions lauten. Eine Agentur, die weiterhin Code direkt in Theme-Dateien schreibt, baut etwas, das Händler nicht sauber wieder entfernen können. Theme-Reste sind die häufigste Beschwerde von Händlern über übernommene Arbeit. **Frage 5: Wie gehen Sie mit API-Abkündigungen um?** Es sollte einen Prozess geben: ein Inventar, einen Zeitplan, eine zuständige Person. "Wir kümmern uns darum, wenn es ansteht" bedeutet, dass Sie sich darum kümmern, wenn es bricht. Der englische Artikel [Shopify API versioning](/shopify-api-versioning) beschreibt, was der Zeitplan verlangt. **Frage 6: Wie würden Sie individuelle Rabattlogik umsetzen?** Shopify Functions. Wer Warenkorb-Manipulation im Theme vorschlägt, baut etwas, das von Shop Pay, Apple Pay und Google Pay umgangen wird. Scripts sind keine Antwort mehr; sie sind abgekündigt, und Plus-Händler mussten bis 2025 migrieren. Was Functions können, erklärt der Artikel [Rabatte mit Shopify Functions bauen](/de/rabatte-mit-shopify-functions-bauen-scripts-sind). **Frage 7: Was empfehlen Sie mir nicht zu bauen?** Die nützlichste Frage des gesamten Gesprächs. Eine Agentur ohne Antwort verkauft Umfang. Eine, die sagt "Sie brauchen kein Headless", "das kann ein Theme" oder "diese App gibt es schon und sie kostet weniger als wir", übt Urteilsvermögen aus, und Urteilsvermögen ist das, was Sie eigentlich kaufen. Dasselbe gilt für Ihr eigenes Briefing: Wenn Sie ein individuelles Theme anfragen und die ehrliche Antwort lautet, dass ein angepasstes Theme Ihnen besser dient, wollen Sie das vor dem Angebot hören, nicht nach der Rechnung. Wann Headless sich lohnt, behandelt der Artikel [Headless Shopify mit Hydrogen](/de/headless-shopify-mit-hydrogen-wann-es-sich-lohnt). ## Zusammenarbeit: Fragen 8 und 9 Zwei Fragen zur Arbeitsweise, die entscheiden, wie sich die Zusammenarbeit anfühlt, wenn etwas schiefgeht. **Frage 8: Wie testen Sie, und wie sehe ich Zwischenstände?** Die Antwort muss nicht ausgefeilt sein, aber es muss eine geben, besonders für alles, was Geld berührt. Wöchentliche Demos auf einem passwortgeschützten Vorschau-Shop, auf dem Sie selbst mit Ihrem Telefon testen, sind ein guter Standard. Eine Agentur, die erst zum Launch etwas zeigt, hat Ihnen bis dahin jede Möglichkeit zur Korrektur genommen. **Frage 9: Mit wem spreche ich nach der Unterschrift?** Wenn die Person aus dem Verkaufsgespräch nach der Unterschrift verschwindet, ist das das Muster für die gesamte Beziehung. Fragen Sie, wer das Projekt führt, wer den Code schreibt, und ob Sie mit beiden sprechen können. Fragen Sie auch, ob die Agentur bereit ist, mit Ihrem bestehenden Entwickler zu sprechen; wer ihn als Bedrohung statt als Kontextquelle behandelt, stellt die Beziehung über das Ergebnis. ## Vertrag und Eigentum: Fragen 10 bis 12 Die kommerziellen Fragen entscheiden, ob Sie am Ende ein Asset oder eine Abhängigkeit haben. Sie sind am Anfang leicht zu klären und am Ende unangenehm. **Frage 10: Wem gehört der Code, und was passiert mit wiederverwendbaren Komponenten?** Händler gehen oft davon aus, dass ihnen individuelle Arbeit vollständig gehört; Agenturen erwarten häufig, wiederverwendbare Teile zu behalten. Beide Positionen sind vertretbar, und der Moment, sie in Einklang zu bringen, ist der Vertragsbeginn. Klären Sie zudem, ob der Code in einem Repository liegt, auf das Sie Zugriff haben. **Frage 11: Welche Dokumentation erhalte ich, und was kann mein Team ohne Sie ändern?** Die Antwort bestimmt, ob der nächste Entwickler die Arbeit übernehmen kann oder sie rekonstruieren muss. Der zweite Teil ist der, den Händler vergessen: Ein Shop, der für jede kleine Änderung die Agentur braucht, hat einen einmaligen Preis in einen dauerhaften verwandelt. Fragen Sie explizit, welche Sektionen, Texte und Einstellungen Ihr Team im Theme-Editor selbst pflegt. **Frage 12: Was kostet der Betrieb nach dem Launch, und wer trägt API-Umstellungen?** Alles Individuelle muss gewartet werden, und ein Angebot ohne Wartungsanteil beschreibt die Hälfte der Kosten. Fragen Sie nach Supportzeitraum, Retainer-Konditionen und wer zahlt, wenn Shopify eine API-Version abstellt. Zur Einordnung: ByteInfy bietet [Wartung und Support](https://byteinfy.com/services/shopify-maintenance) ab 500 $ pro Monat an; andere Agenturen haben andere Modelle, und beide Zahlen gehören in den Vergleich. ## Vor dem Start schriftlich festhalten - Leistungsumfang mit Definition von "fertig", inklusive Templates, Integrationen, Migration und Rechtstext-Einbindung - Umgang mit Änderungswünschen während des Projekts und deren Preis - Code-Eigentum, Repository-Zugang und Lizenz für wiederverwendete Komponenten - Gelieferte Dokumentation, in welcher Form und für wen - Supportzeitraum nach dem Launch, Wartungskonditionen und Reaktionszeiten - Verantwortung und Kosten für API-Umstellungen und Theme-Updates - Was Ihr Team ohne die Agentur selbst ändern kann - Zahlungsplan, Währung und Umgang mit Kursschwankungen - Herausgabe aller Zugänge, Repositories und Dokumente bei Vertragsende ## Agentur, Freelancer oder eigener Entwickler Es gibt keine universell richtige Antwort, aber die Abwägung ist recht klar. ## Drei Wege im Vergleich | Kriterium | Freelancer | Agentur | Eigener Entwickler | | --- | --- | --- | --- | | Passt für | klar umrissene, abgeschlossene Aufgaben | Kontinuität, mehrere Disziplinen, laufende Arbeit | dauerhaften Entwicklungsbedarf | | Stärke | direkter Draht, oft besseres Preis-Leistungs-Verhältnis | jemand ist auch später noch da | kennt den Shop, sofort verfügbar | | Risiko | Verfügbarkeit, wenn später Upgrades anstehen | Overhead, den das Projekt nicht braucht | teure Kapazität unterhalb der Auslastung | | Typische Kombination | für Einzelprojekte neben einer Agentur | für Projekte, mit internem Wissen für Routine | ab laufendem Bedarf, Agentur für Spitzen | Eine verbreitete und sinnvolle Aufteilung ist: Agentur oder Freelancer für definierte Projekte, dazu genug internes Wissen, um Routineänderungen zu machen und zu beurteilen, was geliefert wird. Der englische Beitrag [Hiring a Shopify development agency](/hire-shopify-development-agency) geht auf die Abwägung im Detail ein. ## Warnsignale, die mit Enttäuschung korrelieren Muster, die in schlecht gelaufenen Projekten regelmäßig vorkommen. Keines davon ist allein ein Ausschlusskriterium, mehrere zusammen sind es. **Keine Fragen zu Ihrem Geschäft.** Eine Agentur, die ein Angebot schreibt, ohne zu verstehen, was Sie verkaufen und an wen, kalkuliert aus einer Vorlage, nicht aus Ihrer Situation. **Schätzungen ohne Wartungsanteil.** Alles Individuelle muss gewartet werden. Ein Angebot, das das ignoriert, beschreibt die Hälfte der Kosten. **Zurückhaltung bei Übergabe und Eigentum.** Wenn Dokumentation und Code-Eigentum am Anfang unangenehme Themen sind, werden sie später schlimmer. **Die teuerste Option als Standard.** Headless, wenn ein Theme reicht. Individuell, wenn eine App existiert. Shopify Plus, wenn kein Plus-Feature gebraucht wird; zum Zeitpunkt der Erstellung beginnt Plus bei etwa 2.300 USD pro Monat bei dreijähriger Laufzeit, und eine Agentur sollte begründen können, warum Sie das brauchen. **Keine älteren Projekte, die noch laufen.** Entweder macht die Agentur das noch nicht lange, oder die älteren Projekte sind nichts, worüber sie gern spricht. Beides ist wissenswert, bevor Sie sich binden. **Kein Interesse an Ihrem bestehenden Entwickler.** Wer vorhandenes Wissen als Konkurrenz behandelt, verliert Kontext, den Sie bezahlen. > **Definieren Sie, was "fertig" bedeutet** > > Streitigkeiten in Entwicklungsprojekten drehen sich fast immer um Umfang, nicht um Qualität. Vereinbaren Sie, was enthalten ist, was als abgeschlossen gilt und was mit Änderungswünschen während des Projekts passiert. Schreiben Sie es auf. Das schützt beide Seiten und ist die wirksamste einzelne Maßnahme gegen ein unglückliches Projekt. ## Den ersten Auftrag klein halten Wie Sie das erste Stück Arbeit zuschneiden, zählt so viel wie die Wahl der Agentur, weil es bestimmt, wie viel Sie lernen, bevor Sie sich weiter binden. **Beginnen Sie mit etwas Abgeschlossenem.** Ein Audit, eine Integration, ein Template. Ein definiertes Projekt mit klarem Ende zeigt Ihnen, wie eine Agentur arbeitet, zu einem Bruchteil des Risikos eines großen Baus. Sie lernen Kommunikation, Schätzgenauigkeit und Code-Qualität an etwas, von dem Sie zurücktreten können. Ein technischer SEO-Audit ab 1.000 $ oder eine Speed-Optimierung ab 750 $ sind typische Einstiege; was sie umfassen, steht unter [byteinfy.com/services](https://byteinfy.com/services). **Beobachten Sie die erste Überraschung.** Jedes Projekt trifft auf etwas Unerwartetes. Die Reaktion darauf sagt mehr als das Angebot: Wird es früh mit Optionen angesprochen, oder still absorbiert und erwähnt, wenn der Termin rutscht? **Vergleichen Sie Schätzung und Ergebnis.** Nicht, um eine Überschreitung zu bestrafen, sondern weil die Art, wie eine Agentur darüber kommuniziert, zeigt, wie ein größeres Projekt laufen wird. **Sehen Sie sich den Code an**, auch wenn Sie ihn nicht vollständig bewerten können. Lassen Sie jemanden draufschauen, oder prüfen Sie mindestens, dass er in einem Repository liegt, auf das Sie Zugriff haben, dokumentiert ist und nicht aus einer einzigen riesigen Datei besteht. **Briefen Sie das Problem, nicht die Lösung.** "Unsere mobilen Produktseiten verlieren Leute vor dem Kaufbutton" gibt einer Agentur etwas zu lösen. "Bauen Sie uns ein individuelles Theme" gibt ihr eine Anweisung, die falsch sein kann. Sagen Sie auch, was sich nicht ändern darf: URLs, Integrationen, das, was Ihr Team heute selbst pflegt. Und nennen Sie eine Person, die entscheidet, denn Projekte scheitern häufiger an ungeklärten Meinungen als an Technik. Der eigentliche Ertrag eines kleinen ersten Auftrags ist Information über die Agentur. Ein Händler, der ein großes Budget auf Basis eines Portfolios an ein unbekanntes Team vergibt, kauft auf der unzuverlässigsten Grundlage, die es gibt. **Sie wollen eine ehrliche Antwort darauf, was Sie wirklich brauchen?** ByteInfy baut Shopify-Shops, Apps und Integrationen und sagt Ihnen, wenn ein Theme, eine bestehende App oder gar nichts die bessere Entscheidung ist. [Mit ByteInfy sprechen](https://byteinfy.com/contact) ## FAQ ### Worauf sollte ich bei einer Shopify-Agentur achten? Auf Belege dafür, dass ihre Arbeit hält. Fragen Sie nach Projekten von vor zwei Jahren, wie sie mit API-Abkündigungen umgeht, ob Storefront-Funktionen über Theme App Extensions laufen und welche Dokumentation Sie erhalten. ### Sollte die Agentur in Deutschland sitzen? Nicht zwingend. Entscheidend ist, ob sie deutsche Anforderungen kennt, also Rechtstexte, Button-Lösung, MwSt-Anzeige, DHL-Anbindung, Klarna und für die Schweiz TWINT, und ob Kommunikation, Zeitzone und Sprache für Ihr Team funktionieren. ### Agentur, Freelancer oder eigener Entwickler? Ein Freelancer ist für ein klar umrissenes Stück Arbeit oft die bessere Wahl, mit direktem Draht zur Person, die es baut. ### Wem gehört der Code, den die Agentur schreibt? Was Sie vereinbaren, und das muss vor dem Start schriftlich geschehen. Händler gehen oft davon aus, dass ihnen individuelle Arbeit vollständig gehört; Agenturen erwarten häufig, wiederverwendbare Komponenten zu behalten. Beide Positionen sind vertretbar. ### Wie erkenne ich eine schlechte Shopify-Agentur vor dem Vertrag? An Angeboten ohne Fragen zu Ihrem Geschäft, an Schätzungen ohne Wartungsanteil, an Zurückhaltung bei Übergabe und Code-Eigentum, an der Empfehlung der teuersten Option als Standard und am Fehlen älterer Projekte, die noch laufen. ### Wie groß sollte der erste Auftrag sein? So klein, dass Sie ihn abbrechen könnten, ohne dass es weh tut. Ein Audit, eine Integration, ein Template. ### Was sollte im Vertrag mit einer Shopify-Agentur stehen? Der genaue Leistungsumfang mit Definition von "fertig", der Umgang mit Änderungswünschen und deren Preis, Code-Eigentum und Repository-Zugang, gelieferte Dokumentation, Supportzeitraum nach dem Launch, Wartungskonditionen, Verantwortung für API-Umstellungen, Zahlungsplan und Währung sowie die Herausgabe aller Zugänge bei Vertragsende. --- --- title: "Agentic Commerce: How AI Agents Buy From Your Shopify Store" description: "Shopify turned agentic commerce on by default in June 2026. Your catalogue is already exposed to AI shopping agents — the open question is whether it is good enough to be chosen." author: "Aashish Kaushik" published: 2026-09-20T13:00:47.968Z updated: 2026-09-20T13:00:47.972Z url: https://blog.byteinfy.com/agentic-commerce-shopify --- # Agentic Commerce: How AI Agents Buy From Your Shopify Store ## Key takeaways - Since the Summer '26 Edition, eligible Shopify products auto-syndicate to ChatGPT, Copilot, Google AI Mode, Gemini and the Shop app with no merchant setup. - Agents evaluate structured fields, not storefronts — design, photography and brand voice are invisible to them. - The merchant's job has narrowed to data quality, accuracy and the third-party corroboration agents use to break ties. - Being described incorrectly is worse than being absent, and the cause is almost always an empty or misleading field. For most of ecommerce history the shopper did the work: search, open several tabs, compare, decide. Agentic commerce changes who does that. A shopper describes what they want, and a system researches, compares and returns a recommendation. For a Shopify merchant the important thing is that this has already happened to you, whether or not you have thought about it. ## Shopify turned it on for you The Summer '26 Edition shipped on 17 June 2026 with more than 150 updates, and agentic commerce arrived on by default: eligible products auto-syndicate to ChatGPT, Microsoft Copilot, Google AI Mode, Gemini and the Shop app through the Universal Commerce Protocol, with no setup required from the merchant ([Shopify Editions coverage, Codilar](https://www.codilar.com/blog/shopify-summer-2026-edition/), retrieved 2026-09-02). That is an unusual situation. A significant distribution channel was connected on your behalf, without a project, a budget or a decision. The consequence is that the question is not whether to participate but whether what you are already sending is any good. > **Scale, for context** > > OpenAI has described ChatGPT processing around 50 million shopping queries daily as of February 2026. Whatever share of that touches your category, it is not a channel that can be dismissed as speculative. ## Agents read fields, not storefronts This is the shift that matters, and it is uncomfortable for anyone who has invested in their storefront. An agent evaluating products does not see your homepage. It does not see your photography, your typography, the care in your product page layout, or the brand voice in your copy. It reads structured data: titles, types, variant attributes, prices, availability, specifications. A product with a beautiful page and thin data is invisible to this channel. A product with an ordinary page and complete data is not. That inversion is genuinely difficult for brands whose differentiation is presentational, and it is worth stating plainly rather than softening. ## What good data looks like to an agent The work is unglamorous and specific. ## What agents need and where merchants fail | Field | What an agent does with it | Common failure | | --- | --- | --- | | Title | Identifies and matches the product | Campaign phrasing instead of the literal thing | | Product type | Places it in a category | Left empty | | Variant options | Filters by size, colour, capacity | Internal SKU codes | | Description | Extracts specifications and use cases | Brand voice with no facts | | Price and availability | Compares and checks buyability | Structured data disagreeing with the page | | Specifications | Answers comparison questions | Buried in an image nobody can read | | Reviews | Corroborates quality claims | Present on page, absent from markup | The specifications-in-an-image failure is worth calling out. A great many stores publish dimensions, materials and compatibility as a graphic. To a shopper that is fine. To an agent it does not exist, and the product simply fails to match any query mentioning those attributes. ## Answer the comparison questions explicitly Agents are asked comparative questions constantly — is this waterproof or only water resistant, does it fit a 15-inch laptop, is it dishwasher safe, does it work with the previous model. A product page that answers those in plain text can be cited. One that requires inference from photographs or from a brand's general reputation cannot. The most valuable content you can add to a product page for this channel is a short, factual section that answers the five questions your support team is asked most. That is also good for humans, which is the pattern throughout this subject: the things that make you legible to agents are mostly things that make you clearer to people. It is a rare optimisation problem where the two audiences want the same thing, and it means the work is defensible even if you are sceptical about how large this channel becomes. ## Being described wrongly is worse than being absent The failure mode merchants do not anticipate. An agent that cannot find you costs you a sale you never knew about. An agent that finds you and describes you incorrectly actively harms you — wrong price band, wrong materials, wrong compatibility, a recommendation to someone for whom the product is unsuitable. The cause is almost always a field left empty or a description written for a human who would fill the gaps from context. The remedy is the audit above, and it is worth doing specifically because the downside is not neutral. A shopper who buys the wrong thing on an agent's advice does not blame the agent; they return the product and remember your brand as the one that did not fit. ## Run this quarterly - Ask each major assistant the ten questions your buyers actually ask - Record whether you appear, and exactly how you are described - Check the price band, materials and compatibility it states - Note any product it recommends for a use case it is unsuitable for - Trace each error back to the field that caused it, and fix that field ## Authority still decides ties Complete data makes you eligible. It does not make you chosen. When several products answer a query equally well, agents lean on corroboration — reviews, third-party coverage, comparison sites, forum discussion, retail media. These are sources that are not you, and they carry weight precisely because they are not you. This produces a specific imbalance worth naming. A merchant can perfect their own product data in a fortnight, and it is entirely within their control. Third-party presence is slow, partly outside their control, and is what actually breaks ties. Stores consistently over-invest in the half they own and wonder why the results plateau. ## Where this leaves paid acquisition An honest uncertainty rather than a prediction. If a growing share of product discovery happens inside an assistant's answer, the surfaces that paid acquisition targets change shape, and nobody currently knows how that settles. What can be said is that the inputs to being recommended are not purchasable in the way ad placements are. They are data quality, genuine reviews and third-party credibility. That is a slower and less controllable growth mechanism than buying traffic, and merchants whose model depends heavily on paid acquisition should at least be watching it. ## Returns, support and the agent-bought customer A question almost nobody is planning for: what happens after an agent buys something. A customer who arrived through an assistant's recommendation has had a different pre-purchase experience from one who browsed your site. They may not have seen your sizing guide, your delivery terms, your returns policy or your brand at all. They were told a product matched their need and they accepted that. Three practical consequences worth anticipating: **Expectation mismatch drives returns.** If the agent's description of a product is subtly wrong, the return is caused upstream of anything you did at checkout. This is another reason the accuracy audit matters commercially rather than just for visibility. **They do not know your policies.** Delivery timescales, return windows and warranty terms that a browsing customer encountered are new information to this one. Post-purchase communication carries more weight here, because it may be the first time your brand has actually spoken to them. **Brand recall is weaker.** A customer who chose you from a storefront remembers choosing you. One who accepted a recommendation may not recall your name a week later. If repeat purchase matters to your model, the post-purchase sequence is doing work it was not previously asked to do. None of this is a reason to avoid the channel. It is a reason to treat an agent-sourced order as a customer relationship that starts at the confirmation email rather than one that started three sessions ago, and to make that email work harder than it currently does. ## What to do this quarter 1. Audit product data against the table above, starting with your best-selling twenty products rather than the whole catalogue. 2. Move specifications out of images into text. 3. Add a factual Q&A section to product pages answering your most common support questions. 4. Check your structured data matches the visible page, particularly price and availability. 5. Run the assistant audit and fix whatever it exposes. 6. Decide your AI crawler policy deliberately, and write down why. None of that is exotic. It is the same product data hygiene that improves classic Google rankings and your shopping feed, which is the strongest argument for doing it — the work pays in three channels at once, and it would be worth doing even if agentic commerce turned out to be smaller than expected. > **Ignore anyone selling an AI visibility score** > > The measurement problem here is genuinely unsolved. Tools that track assistant answers over time are useful; tools reporting a single share-of-voice number are reporting a number they cannot substantiate. Judge this channel on data quality and spot checks, not on a dashboard metric. For the content and citation side of this, see [SEO and AI search](/category/seo-ai-search). Product data quality overlaps heavily with the work in [storefront and design](/category/storefront-design), and the catalogue operations angle with [POS and operations](/category/pos-operations). **Is your catalogue legible to the agents already reading it?** ByteInfy audits Shopify product data and structured data for both classic search and AI surfaces — the same work, paying in both channels. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What is agentic commerce? Agentic commerce is the use of an AI agent to research, compare, recommend and in some cases complete a purchase on a shopper's behalf, rather than the shopper browsing and buying directly. ### Do I need to do anything to appear in AI shopping agents? On Shopify, the distribution is handled for you. Since the Summer 2026 release, eligible products syndicate automatically to several AI surfaces through the Universal Commerce Protocol with no merchant setup. ### Will AI agents replace my storefront? Not wholesale, and not soon. Agents currently do most of their work at the research and comparison stage, with the purchase frequently still completing on the merchant's own site. ### How do I stop AI agents from using my product data? You can restrict AI crawler access through robots directives, and Shopify exposes AI crawler rules per store. ### How can I tell if agents are recommending my products? Imperfectly. There is no analytics surface for this yet. The practical method is to ask the assistants the questions your buyers ask and record whether you appear and how you are described, repeated monthly. --- --- title: "Migrating to Shopify Without Losing Your Design" description: "Migrations rarely fail on the data. They fail on the URLs nobody mapped, the schema nobody noticed had gone, and the redesign that shipped at the same time." author: "Aashish Kaushik" published: 2026-09-20T09:00:47.857Z updated: 2026-09-20T09:00:47.896Z url: https://blog.byteinfy.com/shopify-store-migration-design --- # Migrating to Shopify Without Losing Your Design ## Key takeaways - The single largest migration risk is URLs, and it is entirely preventable with a complete redirect map. - Do not migrate and redesign simultaneously — when traffic moves, you will not know which change caused it. - Structured data, heading hierarchy and internal links are lost quietly, because nothing visibly breaks when they go. - Expect a settling period of weeks to months, and agree in advance what would count as a problem. Platform migrations rarely fail on the parts people worry about. Product data transfers, orders import, customers arrive. The failures are elsewhere, and they are quiet. They are the URL that changed with no redirect, the product schema that stopped being emitted, the internal links that were rebuilt from scratch and now point at different things, and the redesign that shipped in the same release and made all of it unattributable. > **The one rule** > > Do not migrate and redesign at the same time. When the numbers move afterwards — and they will — you need to know which change caused it. ## URLs are the largest risk Every platform structures URLs differently, so some change is unavoidable. What is avoidable is a URL changing with nothing behind it. **Build a complete map** from every existing URL to its new equivalent. Products, collections, content pages, and anything else that resolves today. **Include what you have forgotten.** Old campaign pages, discontinued products, paginated archives, anything with an inbound link. Crawl your existing site rather than working from a sitemap, because sitemaps omit exactly the things that are easiest to lose. **Implement redirects on day one**, not as a follow-up task. The window between launch and redirects is a window of 404s served to real traffic and to crawlers. **Verify after launch** by crawling the old URL list and confirming each resolves to something sensible. This takes an hour and catches the omissions that are otherwise found by customers. ## What gets lost invisibly The category that separates a smooth migration from one that is argued about for months. ## What is lost quietly, and how to catch it | Element | Why it is missed | Check | | --- | --- | --- | | Structured data | Nothing visibly breaks | Validate key templates before and after | | Heading hierarchy | Looks fine, outline is wrong | Crawl and audit heading levels | | Internal links | Navigation rebuilt from scratch | Compare link graphs before and after | | Alt text | Images migrate, descriptions do not | Spot-check across product images | | Meta descriptions | Frequently not mapped in the import | Check a sample, and the templates | | Canonical tags | Platform defaults differ | View source on several page types | The unifying property is that none of these change how a page looks. A product page can be visually perfect, emit no schema, carry three H1s, link nowhere and have lost every alt text — and pass a design review comfortably. Which is why the pre-launch check has to be a crawl, not a look. ## Design: match first, improve later The temptation is to treat migration as an opportunity. It is, and taking it immediately costs you the ability to understand what happened. **Migrate with the design as close to the original as practical.** Not identical — platform differences make that impractical — but recognisably the same store with the same structure. **Confirm stability first.** Traffic settled, conversion broadly in line, and nothing obviously broken anywhere. **Then redesign**, as a separate project with its own before-and-after. This is slower and less exciting. It is also the difference between knowing whether your new platform helped and having a permanent argument about it. Where a full match is impossible, keep the **structure** even where the styling changes. Same page types, same information in the same order, same navigation logic. Structure is what carries the SEO and the user habits; styling is comparatively safe to change. ## Data that needs deciding, not just moving Some things do not map cleanly and need a decision rather than an import. **Variant structures** differ substantially between platforms, and a naive import can produce a catalogue that technically works and is completely unusable in practice. **Customer passwords** do not migrate between platforms. Every returning customer will need to reset theirs, which is both a communication task and a support load — plan for it deliberately rather than discovering it on launch morning. **Order history** matters for support and for customer expectations. Decide how much comes across and where the rest lives. **Reviews** are frequently tied to a platform or app and do not travel automatically. Losing years of reviews is a real commercial loss, and it is worth solving before launch rather than after. **Blog content and its URLs**, which are frequently the most-linked pages on a site and among the most commonly overlooked in a commerce migration, because the project is scoped around products and everything else is treated as an afterthought. ## Before you launch - Complete redirect map, tested against a crawl of the old site - Structured data validated on every key template - Heading hierarchy audited across page types - Internal link graph compared before and after - Alt text and meta descriptions spot-checked - Reviews migrated or a plan for their absence - Analytics and conversion tracking verified firing - A named person watching the first fortnight ## Sequencing the launch itself The cutover is a few hours where a great deal can go wrong, and most of the pain is avoidable with ordering rather than skill. **Have the new store fully built and tested on a staging domain first.** Not partly built. Every template, real data, real content, walked end to end including a completed test purchase. **Freeze changes to the old store** in the days before. A product added to the old catalogue during migration is a product missing from the new one, and nobody notices until a customer asks. **Launch when traffic is low**, and when the people who built it are available. Friday evening is traditional and wrong — nobody is around for the weekend when something surfaces. **Redirects go live with the switch**, not afterwards. This is the most common sequencing error and the most expensive. **Verify immediately, not the next morning.** Crawl the old URL list, complete a real purchase, check analytics is recording, and confirm structured data is present. Half an hour of checks at the moment of switching catches things that otherwise run for days. **Submit the new sitemap** and let Search Console know the structure has changed, so recrawling starts promptly rather than at its own pace. ## Communicating it to customers The non-technical half, which affects support load more than anything on the checklist. Returning customers will meet an unfamiliar store, and if passwords did not migrate they will meet a login that does not work. Both are fine if expected and alarming if not. Tell them beforehand, briefly — the store is moving, here is when, you may need to reset your password, your order history is preserved or is not. A short email prevents a large proportion of the support contacts a migration otherwise generates, and it converts a confusing experience into an expected one. Brief your support team on what changed, what to expect, and where to check an order that was placed on the old platform. During the first fortnight they are the ones who will find the problems the checks missed, and they need somewhere to report them. > **Watch the support inbox as a monitoring tool** > > For the first two weeks after a migration, customer emails are your most sensitive instrument. They surface broken paths, missing content and confusing changes long before analytics does, and a pattern in them — three people asking the same thing — is a defect report rather than three confused customers. ## Expect a settling period Traffic fluctuates after any migration, and the first weeks are not a verdict. Agree in advance what would count as a problem, because otherwise the first bad week produces a panic and the first good one produces a declaration of success. **Some fluctuation is entirely normal**, even in migrations where every single thing was done correctly. **Weeks to months** is a realistic settling window depending on site size. **A sustained decline after several months** is not settling. That is a specific problem, and the redirect map and structured data are where to look first. Keep the old site accessible internally if you can, at least for a quarter. When something is missing, comparing against the original is far faster than reconstructing what it used to do from memory. It is also worth resisting the urge to change things during the settling period. The instinct when traffic dips is to act, and acting adds variables to a situation you are still trying to read. Unless something is clearly broken, hold the store stable for the first month and let the numbers resolve. Changes made in week two to fix a dip that would have recovered on its own are how a straightforward migration turns into an unresolvable argument about what actually happened. > **Crawl the old site before you switch anything** > > The single most valuable artefact in a migration is a complete crawl of the existing site — every URL, title, meta description, heading structure and internal link. It costs an hour, it is impossible to produce afterwards, and every subsequent check compares against it. For redesign decisions after the migration settles, see [storefront and design](/category/storefront-design). The SEO checks are covered in [SEO and AI search](/category/seo-ai-search). **Migrating to Shopify without losing what works** ByteInfy handles Shopify migrations end to end — redirect mapping, structured data, internal linking and the checks that catch what goes missing quietly. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Will migrating to Shopify hurt my SEO? It can, and the causes are predictable rather than inherent. Lost URLs without redirects, missing structured data, broken heading hierarchy and rebuilt internal linking account for most migration traffic losses. ### Should I redesign at the same time as migrating to Shopify? Preferably not. Doing both means that when traffic and conversion move, you cannot attribute the change to the platform or to the design. ### How do I handle URLs when migrating to Shopify? Build a complete mapping from every old URL to its new equivalent before launch, and implement it as redirects on day one. ### How long does it take for traffic to recover after a migration? Weeks to months, depending on site size and how much changed. Some initial fluctuation is normal even when everything is done correctly. ### What is most commonly forgotten in a Shopify migration? Structured data and internal links. Both are invisible in a visual review — a page can look perfect while emitting no product schema and linking nowhere. --- --- title: "WooCommerce zu Shopify migrieren ohne Rankingverlust" description: "Rankings gehen bei einer Migration nicht verloren, weil die Plattform wechselt, sondern weil URLs, Inhalte und Meta-Daten unterwegs verloren gehen. Der Ablauf, mit dem ein WooCommerce-Shop auf Shopify ankommt, ohne dass Google ihn neu bewerten muss." author: "Aashish Kaushik" published: 2026-09-20T05:00:47.681Z updated: 2026-09-20T05:00:47.687Z url: https://blog.byteinfy.com/woocommerce-zu-shopify-migrieren-ohne-rankingverlust --- # WooCommerce zu Shopify migrieren ohne Rankingverlust ## Key takeaways - Rankingverluste bei der Migration entstehen durch fehlende 301-Redirects, geänderte Inhalte und verlorene Meta-Daten, nicht durch den Plattformwechsel selbst. - Shopify hat feste URL-Pfade (/products/, /collections/, /pages/, /blogs/); jede WooCommerce-URL braucht deshalb einen Eintrag in der Redirect-Tabelle. - Titles, Descriptions, Alt-Texte, Produkttexte und Zusatzfelder müssen bewusst übertragen werden; Metafelder sind der Ort für alles, was WooCommerce in Custom Fields hielt. - Nach dem Umzug entscheidet die Kontrolle in der Search Console über vier bis acht Wochen, ob Redirects greifen und Inhalte neu indexiert werden. Eine Migration von WooCommerce zu Shopify verliert Rankings nicht, weil die Plattform wechselt, sondern weil URLs, Inhalte und Meta-Daten unterwegs verloren gehen. Google bewertet Seiten, keine Systeme. Wenn jede alte URL per 301 auf die richtige neue URL zeigt, die Seiten ihre Titles, Texte und Bilder behalten und die Kategorie-Struktur erhalten bleibt, verarbeitet Google den Umzug in wenigen Wochen, und die Rankings kommen mit. Der Ablauf dafür ist bekannt: Bestandsaufnahme, URL-Mapping, Datenmigration mit Metafeldern, 301-Redirects, Inhalte und Meta-Daten, Cutover mit Sitemap und Search Console, danach Kontrolle. Dieser Artikel geht ihn in dieser Reihenfolge durch und nennt die Stellen, an denen deutsche, österreichische und Schweizer Händler zusätzlich aufpassen müssen: Rechtstexte, MwSt, Zahlungsarten und die Plugins, die auf WooCommerce diese Themen abgedeckt haben. > **Was Shopify bei einer Migration vorgibt** > > Shopify hat feste URL-Pfade: Produkte liegen unter /products/, Kategorien werden zu Kollektionen unter /collections/, Seiten unter /pages/, Beiträge unter /blogs/. Diese Präfixe lassen sich nicht entfernen. Eine WooCommerce-URL wie /produkt/wanderschuh-damen/ wird deshalb zu /products/wanderschuh-damen, und jede solche Änderung braucht einen Redirect. Passwörter können von keiner Plattform migriert werden. ## Warum Migrationen Rankings verlieren Die drei Ursachen für Rankingverluste bei einem Plattformwechsel sind fehlende Redirects, geänderte Inhalte und Duplikate. Alle drei entstehen durch Nachlässigkeit, nicht durch Technik. Fehlende Redirects sind die häufigste Ursache. Wer nur die Startseite und die Top-20-Produkte weiterleitet, verliert die Rankings der restlichen 800 Produkte, der Kategorien, der Blogartikel und der Seiten, die über Jahre Backlinks gesammelt haben. Jede URL, die in der Search Console Impressionen hat oder von außen verlinkt wird, braucht einen Eintrag. Geänderte Inhalte sind die zweite Ursache. Eine Migration ist oft der Anlass für ein neues Design, neue Texte und eine neue Kategorie-Struktur. Jede dieser Änderungen ist für sich sinnvoll, aber zusammen mit dem Umzug bedeutet sie, dass Google neue URLs mit neuem Inhalt in neuer Struktur sieht und die Seiten neu bewerten muss. Wer Rankings behalten will, migriert erst, stabilisiert, und ändert dann. Duplikate sind die dritte Ursache und bei Shopify spezifisch: Produkt-URLs mit Kollektions-Pfad, Tag-Seiten und Varianten-Parameter. Was dagegen hilft, steht in der [Shopify SEO Checkliste](/de/shopify-seo-optimierung-checkliste-mit-25-punkten), und es gehört in die Migration, nicht in die Nacharbeit. ## Schritt 1: Bestandsaufnahme vor dem ersten Export Bevor ein Produkt bewegt wird, brauchen Sie eine vollständige Liste dessen, was der alte Shop hat und was davon Wert trägt. Exportieren Sie alle URLs des WooCommerce-Shops: Produkte, Kategorien, Tags, Seiten, Beiträge, Attribut-Seiten, Bilder. Ein Crawler wie Screaming Frog liefert das inklusive Titles, Descriptions, Statuscodes und interner Verlinkung. Ergänzen Sie aus der Search Console die URLs mit Impressionen und Klicks der letzten zwölf Monate, und aus einem Backlink-Tool die URLs mit externen Links. Aus diesen drei Quellen entsteht die Liste der URLs, die auf keinen Fall ins Leere laufen dürfen. Listen Sie alle Plugins auf, mit einer Zeile pro Plugin: was es tut, ob es aktiv genutzt wird, womit es auf Shopify abgebildet wird. Bei deutschen Shops steht hier meist Germanized oder German Market, dazu Zahlungs-Plugins, Versand-Plugins für DHL oder die Post, SEO-Plugins wie Yoast oder Rank Math, Cookie-Plugins und Formular-Plugins. Jedes davon ist auf Shopify eine Einstellung, eine App, Theme-Code oder entfällt. Notieren Sie alle Custom Fields, Attribute und Taxonomien, die im Theme ausgegeben werden. Das sind die Daten, die bei einem naiven Produktexport verloren gehen, weil sie nicht in den Standardfeldern von WooCommerce liegen. ## Schritt 2: URL-Mapping von WooCommerce auf Shopify Das URL-Mapping ist eine Tabelle mit zwei Spalten, alte URL und neue URL, und sie ist das wichtigste Dokument der gesamten Migration. Shopify erzeugt URLs aus dem Handle, also dem Slug, den Sie beim Import mitgeben. Wenn der WooCommerce-Slug "wanderschuh-damen" ist und der Shopify-Handle ebenfalls, wird aus /produkt/wanderschuh-damen/ die URL /products/wanderschuh-damen. Die Redirect-Regel ist dann trivial. Wo Slugs kollidieren, etwa weil zwei Produkte in verschiedenen Kategorien denselben Slug hatten, muss die Tabelle das auflösen. Kategorien werden zu Kollektionen. Eine verschachtelte WooCommerce-Kategorie wie /produkt-kategorie/schuhe/wanderschuhe/damen/ wird zu einer flachen Kollektion /collections/wanderschuhe-damen. Die Hierarchie bilden Sie über Navigation und interne Verlinkung ab, nicht über die URL. Was eine Kollektionsseite braucht, um zu ranken, beschreibt der englische Artikel [Shopify collection page SEO](/shopify-collection-page-seo). Tags, Attribut-Seiten und Paginierungs-URLs prüfen Sie einzeln. Die meisten haben keine Rankings und können auf die übergeordnete Kollektion zeigen. Die wenigen mit Impressionen bekommen eine eigene Kollektion. ## URL-Mapping von WooCommerce auf Shopify | WooCommerce-URL (typisch, deutsch) | Shopify-URL | Anmerkung | | --- | --- | --- | | /produkt/wanderschuh-damen/ | /products/wanderschuh-damen | Handle gleich Slug, Präfix ändert sich | | /produkt-kategorie/wanderschuhe/ | /collections/wanderschuhe | Kategorie wird Kollektion | | /produkt-kategorie/schuhe/wanderschuhe/damen/ | /collections/wanderschuhe-damen | Hierarchie wird flach | | /produkt-schlagwort/wasserdicht/ | /collections/wasserdicht oder übergeordnete Kollektion | nur bei Suchnachfrage eigene Kollektion | | /blog/pflegetipps-leder/ | /blogs/ratgeber/pflegetipps-leder | Blog-Handle wählen, Beitrags-Slug behalten | | /ueber-uns/ | /pages/ueber-uns | Seiten unter /pages/ | | /shop/ | /collections/all | Shop-Übersicht auf Alle Produkte | | /warenkorb/, /kasse/, /mein-konto/ | /cart, /checkout, /account | Systemseiten, Redirects meist unnötig | | /wp-content/uploads/2024/03/bild.jpg | Shopify-CDN-URL | Bild-URLs ändern sich, Bilder-Rankings gehen teils verloren | Bilder sind der Punkt, den die Tabelle nicht vollständig löst. WooCommerce-Bilder liegen unter /wp-content/uploads/, Shopify-Bilder auf dem Shopify-CDN. Bild-Redirects sind auf Shopify nicht möglich, weil die alten Pfade nach dem DNS-Wechsel nicht mehr existieren. Rankings in der Bildersuche gehen deshalb teilweise verloren und bauen sich über Alt-Texte und Dateinamen neu auf. ## Schritt 3: Daten migrieren, Metafelder inklusive Die Datenmigration umfasst Produkte, Varianten, Bilder, Kategorien, Kunden, Bestellungen, Rabattcodes und alle Zusatzfelder. Die Zusatzfelder sind der Teil, der bei Standard-Tools verloren geht. Produkte und Varianten exportieren Sie aus WooCommerce als CSV oder über die REST-API und importieren sie über Shopify-CSV, ein Migrations-Tool oder ein Skript gegen die Admin-API. Bei kleinen Katalogen reicht CSV. Bei großen Katalogen mit vielen Varianten, Attributen und Bildern ist ein Skript zuverlässiger, weil es Fehler protokolliert und wiederholbar ist. Prüfen Sie nach dem Import stichprobenartig Varianten, Preise inklusive MwSt, Lagerbestände, Gewichte für den Versand und Bildreihenfolge. Custom Fields, Attribute und alles, was WooCommerce in Postmeta hielt, landen in Shopify als Metafelder. Metafelder sind typisierte Zusatzfelder an Produkten, Varianten, Kollektionen, Kunden und Bestellungen, die im Theme ausgegeben werden können. Größentabellen, Materialangaben, Lieferzeiten, Herstellerangaben und Pflegehinweise gehören hierhin. Der englische Artikel [Shopify metaobjects and metafields](/shopify-metaobjects-metafields) erklärt die Struktur. Kunden importieren Sie mit Name, Adressen, E-Mail und Tags. Passwörter können nicht übernommen werden. Planen Sie eine E-Mail an Bestandskunden, die den Umzug erklärt und zum Setzen eines neuen Passworts führt. Bestellungen lassen sich als Historie importieren, damit Kunden ihre Bestellungen sehen und Sie Auswertungen behalten; Zahlungsstatus und Fulfillment werden als abgeschlossen markiert. Rabattcodes, die in Newslettern und Anzeigen im Umlauf sind, müssen mit gleichem Code und gleichen Bedingungen neu angelegt werden. Was auf Shopify nativ geht und was eine Function braucht, steht im Artikel [Rabatte mit Shopify Functions bauen](/de/rabatte-mit-shopify-functions-bauen-scripts-sind). ## Schritt 4: 301-Redirects einrichten Redirects werden in Shopify unter Navigation, URL-Weiterleitungen angelegt, einzeln oder per CSV-Import. Die Tabelle aus Schritt 2 ist die Importdatei. Shopify unterstützt keine Muster, Platzhalter oder regulären Ausdrücke. Jede alte URL braucht eine eigene Zeile. Bei 2.000 Produkten und 150 Kategorien sind das über 2.000 Zeilen, was per CSV kein Problem ist, per Hand aber nicht machbar. Shopify behandelt abschließende Schrägstriche tolerant, aber Groß- und Kleinschreibung sowie Parameter prüfen Sie explizit. Vermeiden Sie Weiterleitungsketten. Wenn im WooCommerce-Shop schon Redirects existierten, etwa von einem noch älteren Shop, leiten Sie die Ursprungs-URL direkt auf die Shopify-URL, nicht über den Zwischenschritt. Alte Ketten finden Sie im Crawl aus Schritt 1. Testen Sie die Redirects vor dem Cutover auf der Shopify-Domain mit einer Stichprobe aus jeder Kategorie der Tabelle: Produkte, Kollektionen, Blog, Seiten, alte Kampagnen-URLs. Nach dem Cutover crawlen Sie die vollständige alte URL-Liste und prüfen, dass jede Zeile mit 301 auf eine Seite mit Status 200 endet. Ein 404 in dieser Liste ist ein Fehler in der Tabelle, kein Schicksal. ## Schritt 5: Inhalte und Meta-Daten übertragen Rankings hängen an Inhalten, und Inhalte sind mehr als Produktbeschreibungen. Titles, Descriptions, Alt-Texte, Überschriften und strukturierte Daten müssen bewusst mitgenommen werden. Titles und Descriptions aus Yoast oder Rank Math liegen in eigenen Feldern und werden bei einem Standardexport nicht mitgenommen. Exportieren Sie sie aus dem Crawl oder aus dem Plugin und schreiben Sie sie in die SEO-Felder von Shopify, die pro Produkt, Kollektion, Seite und Artikel verfügbar sind. Wer diesen Schritt auslässt, ersetzt jeden gepflegten Title durch "Produktname, Shopname" und wundert sich über sinkende Klickraten. Alt-Texte an Bildern gehen bei den meisten Bildimporten verloren. Exportieren Sie sie aus der WordPress-Mediathek und setzen Sie sie beim Import über die API oder nachträglich per App. Der englische Artikel [Shopify image alt text SEO](/shopify-image-alt-text-seo) beschreibt beide Wege. Kategorietexte aus WooCommerce, also Beschreibungen über oder unter dem Produktraster, gehören in die Kollektionsbeschreibung und, für den Text unter dem Raster, in ein Metafeld, das das Theme ausgibt. Blogartikel importieren Sie mit Datum, Autor und Bildern; interne Links in den Artikeln zeigen noch auf WooCommerce-URLs und werden durch die Redirects abgefangen, sollten aber nach dem Cutover auf die neuen URLs umgeschrieben werden. ## Cutover: DNS, Sitemap und Search Console Der Cutover ist der Moment, in dem die Domain auf Shopify zeigt. Er dauert Minuten, wenn alles vorbereitet ist, und Wochen, wenn nicht. Vor dem DNS-Wechsel muss der Shopify-Shop unter der Vorschau-Domain vollständig geprüft sein: Redirects, Produkte, Zahlungen, Versand, Rechtstexte, Tracking. Der Shop ist per Passwort geschützt und für Google unsichtbar, was in dieser Phase gewollt ist. Entfernen Sie den Passwortschutz erst nach dem DNS-Wechsel. Der DNS-Wechsel selbst erfolgt in einem ruhigen Zeitfenster, in Deutschland typisch nachts oder am frühen Sonntagmorgen. Redirects müssen ab der ersten Sekunde greifen, was sie tun, wenn sie vor dem Wechsel importiert wurden. Halten Sie den alten Shop noch einige Wochen erreichbar, unter einer Subdomain oder intern, um Daten nachzuschlagen. Nach dem Wechsel reichen Sie die Shopify-Sitemap in der Search Console ein, für dieselbe Property, die schon den alten Shop enthielt. Ein Adressänderungs-Tool ist nur bei Domainwechsel nötig; bei gleicher Domain reicht die Sitemap. Prüfen Sie robots.txt, dass keine Pfade gesperrt sind, die indexiert werden sollen. ## Cutover-Ablauf - Redirect-Tabelle vollständig importiert und stichprobenartig auf der Vorschau-Domain getestet - Produkte, Varianten, Preise inkl. MwSt, Bestände und Metafelder gegen die Quelle geprüft - Titles, Descriptions und Alt-Texte übertragen und stichprobenartig verglichen - Zahlungsarten (Shopify Payments, Klarna, PayPal, in der Schweiz TWINT) mit Testbestellung geprüft - Versandzonen und -kosten für Deutschland, Österreich und Schweiz eingerichtet, DHL oder Post angebunden - Rechtstexte, Bestellbutton, Cookie-Einwilligung und Tracking nach deutschen Anforderungen geprüft - DNS in ruhigem Zeitfenster umgestellt, Passwortschutz entfernt, Redirects im Live-Betrieb getestet - Sitemap in der Search Console eingereicht, robots.txt geprüft, alter Shop intern erreichbar gehalten - Kunden-E-Mail zum Passwort-Reset verschickt ## Nach dem Umzug: vier bis acht Wochen Kontrolle Der Umzug ist nicht mit dem DNS-Wechsel abgeschlossen, sondern wenn die Search Console zeigt, dass Google die neuen URLs übernommen hat. In den ersten Tagen prüfen Sie den Bericht "Seiten" in der Search Console: Steigt die Zahl der indexierten Shopify-URLs, sinkt die Zahl der alten? Tauchen 404-Fehler auf, sind das Lücken in der Redirect-Tabelle, die Sie sofort schließen. Crawlen Sie die alte URL-Liste wöchentlich, bis jede Zeile sauber auf 200 endet. In den ersten Wochen vergleichen Sie Klicks und Impressionen pro Landingpage mit dem Vorjahr und mit den Wochen vor dem Umzug. Schwankungen sind normal, Trends nicht: Eine Kollektion, die nach drei Wochen weiter fällt, hat meist ein inhaltliches Problem, etwa fehlenden Text oder einen schwächeren Title. Prüfen Sie zudem Core Web Vitals pro Template, weil ein neues Theme mit neuen Apps hier oft schlechter startet als der alte Shop; der englische Artikel [Shopify theme speed](/shopify-theme-speed) nennt die Ursachen. ## Was DACH-Händler zusätzlich beachten Ein WooCommerce-Shop in Deutschland hat über Jahre Plugins gesammelt, die rechtliche und lokale Anforderungen abdecken. Auf Shopify werden diese Anforderungen anders gelöst, und die Migration ist der Moment, jede einzeln zu prüfen. Germanized und German Market liefern auf WooCommerce Button-Lösung, MwSt-Hinweise, Grundpreise, Lieferzeiten, Widerrufsbelehrung in der Bestellbestätigung und Rechtstext-Einbindung. Auf Shopify verteilt sich das auf Einstellungen, Theme-Code und Rechtstext-Apps. Was im Einzelnen wohin gehört, steht im Artikel [Shopify rechtssicher in Deutschland](/de/shopify-rechtssicher-deutschland-impressum-dsgvo-button). Zahlungsarten wechseln den Anbieter. Klarna, PayPal, SEPA-Lastschrift und Kreditkarte laufen über Shopify Payments oder Drittanbieter; Kauf auf Rechnung braucht einen Anbieter mit Risikoübernahme. Für die Schweiz kommt TWINT über Shopify Payments hinzu, was der Artikel [Shopify in der Schweiz](/de/shopify-schweiz-twint-chf-mwst-agenturwahl) beschreibt. Versand-Plugins für DHL oder die Post werden durch Versand-Apps ersetzt; Versandzonen und Preise pro Land müssen neu angelegt werden. Mehrere Länder und Währungen, die auf WooCommerce über Plugins liefen, deckt Shopify Markets ab, mit Mehrwährung, lokalisierten Domains und hreflang. Das ist meist einfacher als vorher, aber es muss bewusst eingerichtet werden. Eine Migration mit vollständigem Redirect-Plan, verifizierten Daten und Search-Console-Monitoring beginnt bei ByteInfy als [Shopify Migration](https://byteinfy.com/services/shopify-migration) bei 1.500 $; der Theme-Bau kommt als eigener Posten dazu. Welche Kostenposten in einem Migrationsangebot stehen sollten, listet der Artikel [Shopify Agentur Kosten 2027](/de/shopify-agentur-kosten-2027-was-ein-shop-wirklich). **Sie planen den Umzug von WooCommerce zu Shopify?** ByteInfy erstellt die URL-Tabelle, migriert Katalog, Kunden und Metafelder, importiert die Redirects vor dem Cutover und beobachtet die Search Console danach. [Mit ByteInfy sprechen](https://byteinfy.com/contact) ## FAQ ### Verliere ich bei der Migration von WooCommerce zu Shopify Rankings? Nicht, wenn jede alte URL per 301 auf die passende neue URL zeigt, die Seiten ihre Titles, Texte und Bilder behalten und die Struktur der Kategorien erhalten bleibt. ### Wie übertrage ich die URLs von WooCommerce auf Shopify? Sie exportieren alle URLs aus WooCommerce, ordnen jeder die neue Shopify-URL zu und importieren die Liste als CSV unter Navigation, URL-Weiterleitungen. ### Kann ich Kundenkonten und Passwörter mitnehmen? Kundendaten wie Name, Adresse und Bestellhistorie lassen sich importieren, Passwörter nicht, weil keine Plattform sie im Klartext speichert. Kunden müssen nach dem Umzug ein neues Passwort setzen. ### Was passiert mit Custom Fields, Attributen und Plugins? Custom Fields und Produktattribute aus WooCommerce landen in Shopify als Metafelder, die im Theme ausgegeben werden. Plugins haben kein Gegenstück; ihre Funktion wird durch Shopify-Funktionen, Apps oder Theme-Code ersetzt. ### Wie lange dauert es, bis Google die neue Seite indexiert hat? Das hängt von der Größe des Shops und der Crawl-Frequenz ab. Bei kleinen Shops sind die meisten Seiten innerhalb weniger Tage neu indexiert, bei großen Katalogen kann es mehrere Wochen dauern. ### Was kostet eine WooCommerce zu Shopify Migration? Eine Migration von Katalog, Kunden und Bestellungen mit vollständigem Redirect-Plan beginnt bei ByteInfy bei 1.500 $. ### Was ist mit Germanized oder German Market? Diese WooCommerce-Plugins bündeln deutsche Rechtsanforderungen wie Button-Lösung, Grundpreise, Lieferzeiten und MwSt-Hinweise. Auf Shopify gibt es kein direktes Gegenstück; die Punkte werden durch Shopify-Einstellungen, das Theme und gegebenenfalls Apps abgedeckt. --- --- title: "Why Shopify Discounts Do Not Stack, and How to Fix It" description: "Two offers that each work alone frequently do nothing together. The cause is almost always a combination setting nobody touched, and the symptom is silence." author: "Aashish Kaushik" published: 2026-09-19T13:00:48.655Z updated: 2026-09-19T13:00:49.011Z url: https://blog.byteinfy.com/shopify-discount-stacking --- # Why Shopify Discounts Do Not Stack, and How to Fix It ## Key takeaways - Shopify distinguishes product, order and shipping discounts, and combination rules are set per discount rather than globally. - Two product discounts generally do not stack, which surprises merchants who built each offer separately weeks apart. - The failure is silent — the discount simply does not apply, no error is raised, and the shopper sees a total that does not match your landing page. - Automatic discounts and discount codes behave differently at accelerated checkouts, and codes can be structurally unenterable. A merchant builds a 20% collection discount in September and a free-shipping-over-threshold offer in October. Both work. In November a customer qualifies for both, gets one, and emails to ask why the site lied to them. Nothing is broken. Shopify applied its combination rules, which nobody configured, and the defaults did not match what anyone assumed. This is the most common discount problem on the platform and it is almost entirely a settings problem. > **The short version** > > Shopify separates discounts into product, order and shipping types. Combination is allowed between types, configured per discount, and generally not permitted between two discounts of the same type. ## The three types, and why the distinction matters Every Shopify discount is one of three things, and the type determines what it can combine with. **Product discounts** reduce the price of specific items — a percentage off a collection, a buy X get Y, an amount off particular products. **Order discounts** reduce the order total — a percentage or amount off everything, usually with a minimum spend. **Shipping discounts** reduce or remove shipping cost. The rule that follows: discounts of different types can be configured to combine. Two discounts of the same type generally cannot. A product discount plus free shipping is achievable. Two separate product discounts, both applying to the same order, generally is not. This catches merchants because it is not how discounts feel from the customer side. A shopper does not experience "a product discount and an order discount"; they experience two offers. The distinction is a platform implementation detail that leaks directly into your promotional planning. ## Combination settings are per discount, and default to off The second thing that surprises people. Combination is not a global store setting. Each discount carries its own configuration specifying which other types it may combine with. That means a discount created without touching those checkboxes will not combine with anything, even where the types would permit it. Two compatible offers built weeks apart by someone not thinking about the other will simply not stack, and nobody will have made a decision to that effect. The practical implication is that combination has to be planned across your whole promotional calendar rather than per offer. Before creating any discount, know what else could be active — including codes already in circulation — and configure deliberately in both directions. ## The failure is silent, which is what makes it expensive If discounts errored when they failed to combine, this would be a minor annoyance. They do not. The shopper qualifies for two offers, receives one, and sees a total lower than full price but higher than the landing page promised. From their side this looks like a store that overstates its discounts. Some ask; most leave. You will not see this in your reports. There is no failed-discount metric. The order either happened at a total you did not expect, or did not happen at all, and neither shows up as an error anywhere. ## How to detect it before customers do - Build every offer that could overlap and walk the customer path for each pairing - Include discount codes already emailed and not expired - Test a cart that qualifies for two offers and confirm which one wins - Check the total against what the campaign page promises - Watch order-level margin for movement after any new offer goes live ## A worked example of diagnosing one complaint A customer emails saying the site promised 20% off and they only received free shipping. Working through this on the actual order, rather than guessing, takes a few minutes and settles it definitively. Open the order in the Shopify admin and look at the Discount line in the order summary, which shows exactly what applied and, in most cases, the name of the discount. If only the shipping discount is listed, the product discount did not apply to this order, and the question becomes why. Next, open the discount itself from Discounts in the admin and check its Combinations section, which lists which of the other two types, product, order or shipping, it is permitted to combine with. If the 20% offer is a product discount and its combinations do not include shipping discounts, that setting alone explains the outcome: both offers were live, both were valid for this customer, and Shopify applied the one it was told to apply rather than both. Also check the discount's Active dates and Minimum purchase requirements against the actual order, since a threshold calculated per line item rather than per order is a common reason an order that looks large enough on the customer's screen does not actually qualify. If the customer's cart mixed several variants of the same product, check whether the discount counts variants separately, since a threshold written as a certain quantity of one product can silently exclude a cart holding that quantity spread across different sizes or colours. Once the cause is confirmed, the reply to the customer can be specific rather than apologetic in the abstract: state which discount applied, why the other did not combine with it, and whether that combination rule is one you intend to change. That specificity is usually what turns a complaint into an accepted explanation rather than a repeat contact, and it is also the moment to add this pairing to the list described later in this article, so the same question does not arrive from the next customer who hits it. ## Codes and accelerated checkouts A separate stacking-adjacent problem that costs real revenue during promotions. Automatic discounts apply at the platform level. They survive every checkout path, including Shop Pay, Apple Pay and Google Pay. Discount codes require the shopper to enter them somewhere. Accelerated checkout buttons frequently compress or skip the step where that field appears. A shopper using a wallet button may have no opportunity to enter your code at all. This means a campaign built entirely on a code will structurally fail for a portion of your traffic, and that portion is growing. Where the offer is unconditional, use an automatic discount. Reserve codes for cases where you genuinely need to gate the offer behind knowledge of the code. ## When the cart shows one thing and checkout another Worth distinguishing from ordinary stacking problems, because the cause is different. Native discounts and Shopify Functions apply at checkout. What appears in the cart and what is charged are the same computation, so they cannot disagree. If you see a discount in the cart that vanishes at checkout, the discount is probably not being applied at the platform level. It is being applied by something modifying the cart — an older app using cart rewrites, draft orders, or line-item manipulation. Those approaches are bypassed by accelerated checkouts and can be overridden by anything else touching the cart. The fix is not configuration. It is moving to an implementation that applies at checkout, which since 30 June 2026 means Shopify Functions — legacy Scripts stopped running on that date. ## Making complex combinations actually work Sometimes the offer you want genuinely cannot be expressed as two native discounts that combine. The supported answer is to stop trying to make two discounts cooperate and express the combined outcome as one. Shopify Functions lets you write the logic that produces the final result — evaluate the cart, decide what the customer should receive, and emit that as a single set of discount operations. Instead of hoping two discounts resolve correctly, you compute the intended outcome directly. This is more work and needs a developer, but it eliminates the entire class of problem. There is no combination setting to get wrong because there is one discount, and no ambiguity about which offer won because the logic decided explicitly rather than the platform arbitrating between two things that were never designed to meet. ## Choosing an approach | Situation | Approach | | --- | --- | | Two offers of different types | Native discounts, combinations configured on both | | Two offers of the same type | Rethink as one offer, or make them mutually exclusive | | Conditional on customer tag or history | Shopify Functions | | Multi-rung tiered thresholds | Shopify Functions | | Simple, unconditional, storewide | Native automatic discount | | Offer that must be gated by knowledge | Discount code, accepting accelerated-checkout limits | ## Telling the customer what is happening A large share of the damage from non-stacking offers is communication rather than mechanics. The shopper does not know your discount types; they know they were promised two things and got one. Three practices that remove most of the friction without changing any logic: **Say what combines, on the offer itself.** A single line — "cannot be combined with other discounts" — on the campaign page and in the email costs nothing and prevents the entire expectation gap. Merchants avoid this line because it feels like it weakens the offer. It does not weaken it nearly as much as a shopper discovering the limitation at checkout. **Apply the better discount, and say so.** Where two offers compete, the shopper should end up with whichever is worth more to them, and the cart should say that is what happened. "Your 20% collection discount has been applied instead of code SAVE10" turns an apparent failure into evident fairness. **Itemise in the cart and at checkout.** A total that is simply lower reads as arbitrary. A total showing which discount applied and what it saved is checkable, and checkable totals generate far fewer support contacts. > **The support inbox is your best diagnostic** > > Discount problems reach you as customer emails long before they show up in any report. If two people in a week ask why a code did not work, that is not two confused customers — it is a configuration problem with a much larger silent majority behind it. Treat the second email as the signal. ## The planning habit that prevents all of this Most stacking problems are not technical failures but planning failures, and one habit prevents nearly all of them: maintain a single list of every discount that could be active, with its type, its dates, and its combination settings. Most merchants cannot produce this list on request, which is precisely why the problems occur. Offers accumulate. Codes from old campaigns keep working because nobody set an expiry. An agency created something two years ago that nobody has thought about since. Before any promotional period, review that list, expire what should be dead, and explicitly decide what may combine with what. That review is twenty minutes and prevents the failure mode that costs the most during peak trading. > **Set expiry dates on everything** > > A discount code with no end date is a permanent liability. It will be found, shared, and used during a period when you are also running something else. Every code should have an expiry, even ones you expect to extend — extending is one click and forgetting is expensive. For offer strategy and what each mechanic does to margin, see [promotions and offers](/category/promotions-offers). Checkout behaviour is covered in [checkout and payments](/category/checkout-payments), and the Functions migration in [Shopify development](/category/shopify-development). **Offers that will not behave?** ByteInfy builds Shopify discount logic with Functions — combined outcomes computed once, instead of several discounts hoping to cooperate. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Why is my Shopify discount code not working? The usual causes, in order of frequency: a combination setting preventing it from applying alongside an active automatic discount, a date range not yet started or already ended, customer eligibility narrower than intended, minimum requirements not met because variants are counted separately, or a usage limit already reached. ### Can two automatic discounts apply to the same order? Only if their types are compatible and combinations are configured to allow it. Shopify separates product, order and shipping discounts. ### Can a customer use a discount code and an automatic discount together? Yes, if the combination settings on both permit it and their types are compatible. This needs to be configured explicitly on each discount. ### Why did my discount apply in the cart but not at checkout? This usually indicates the discount is not being applied at the platform level but by something modifying the cart — commonly an older app. ### How do I let customers stack discounts freely? You largely cannot, and should be careful about wanting to. Shopify's constraints on combining same-type discounts exist to keep totals predictable. --- --- title: "Shopify Theme or Custom Build: How to Decide" description: "The choice is not really theme versus custom. It is how much customisation a theme can absorb before rebuilding becomes cheaper than fighting it." author: "Aashish Kaushik" published: 2026-09-19T09:01:43.985Z updated: 2026-09-19T09:01:44.024Z url: https://blog.byteinfy.com/shopify-theme-vs-custom --- # Shopify Theme or Custom Build: How to Decide ## Key takeaways - The decision is a spectrum, not a binary — stock theme, configured theme, customised theme, and custom build are four different commitments. - Most stores that think they need a custom build need a customised theme, which costs a fraction and keeps platform updates. - The real cost of custom is maintenance, and it arrives every year rather than once. - Horizon's nested block system widened what themes can express, which moves the threshold further toward themes than it was. The question gets framed as a binary and it is not. There are four distinct commitments, and most stores comparing the extremes should be looking at the middle two. Framing it properly changes the answer for a lot of merchants, usually toward spending less. > **The useful question** > > Not "theme or custom" but "how much customisation can a theme absorb before fighting it costs more than replacing it". ## The four options **A stock theme, configured.** A premium or free theme, set up entirely through the editor with no code changes at all. Fastest, cheapest, receives updates from its author. Constrained to what the theme supports. **A theme with custom sections.** The theme handles standard patterns; bespoke sections and blocks are built for the parts that are genuinely specific. Still updateable, with care. This is where most stores belong. **A heavily customised theme.** The theme is the starting point and substantial parts have been rewritten. Updates become difficult, because merging author changes into modified files is where the cost appears. **A custom build.** Written from the ground up. Total control, total ownership, and no updates arriving from anywhere but you. ## What each option costs and keeps | Option | Build cost | Annual cost | Keeps theme updates | | --- | --- | --- | --- | | Stock theme | Lowest | Near zero | Yes | | Theme + custom sections | Moderate | Low | Mostly | | Heavily customised theme | High | Moderate | Difficult | | Custom build | Highest | Highest | No | The third column is where decisions go wrong. Build cost is discussed and compared; annual cost is often not mentioned at all, and it is what determines the total over three years. ## Themes cover more than merchants expect The assumption behind most custom-build decisions is that themes cannot express a distinctive design. That has become steadily less true. Modern themes support extensive layout configuration, custom sections, metafield-driven content, and app blocks. Horizon's block-based system, with nesting up to eight levels, widened this considerably — composition that previously required development is now editor work. The practical consequence is that "we want it to look bespoke" is no longer a reason to go custom. Themes handle bespoke. What themes struggle with is *structurally* unusual interaction — configurators, non-standard browsing models, interfaces that do not resemble a commerce page. Before commissioning a custom build, it is worth having a designer produce what you actually want and asking an experienced Shopify developer whether a theme can build it. The answer is usually yes with some custom sections, and finding that out costs a conversation rather than a budget. ## Where custom genuinely wins Four situations where a theme is the wrong tool. **Interaction a theme cannot structurally express.** A product configurator, a booking flow, a browsing model unlike a catalogue. **Extreme performance requirements** where you need control over every byte, and where you have the discipline to maintain that control. This is rarer than it is claimed, because most stores lose their performance advantage to app scripts within a year regardless of architecture. **Deep integration with other systems** that needs to be present throughout the front end rather than at a few points. **A design system spanning several properties**, where the storefront is one surface among many and consistency across them matters more than commerce conventions. Notice what is absent: wanting a distinctive look, wanting to be faster, and disliking the theme's admin. The first is achievable with a theme, the second is achievable with discipline, and the third is usually a configuration problem. ## The maintenance cost nobody quotes The most under-discussed part of this decision, and the one that determines total cost. A premium theme receives updates. When Shopify changes something, when a browser changes something, when an accessibility standard tightens, the theme author responds and you take the update. A custom build receives what you pay for. Every platform change, every deprecated API, every new checkout requirement is your project. This is not occasional — Shopify ships continuously, and a storefront that is not maintained drifts steadily toward broken. Budget for it explicitly. A custom build with no maintenance allocation is a store that will look neglected in three years and will be expensive to rescue. ## Before choosing custom - Have a Shopify developer confirm a theme genuinely cannot do it - Compare three-year total cost, not build cost - Identify who maintains it, and budget for that annually - Check which storefront apps you depend on and whether they still work - Confirm someone internally can brief and review front-end work ongoing - Ask what happens if the agency that built it becomes unavailable That last question is worth asking aloud. A custom theme with no documentation, built by an agency you no longer work with, is one of the more expensive positions a store can be in. ## The middle option, in practice For most stores the answer is a good premium theme plus custom sections, and it is worth being concrete about what that looks like. The theme provides the product page, collection page, cart and the standard patterns — all maintained by its author. Custom sections cover the parts specific to you: a particular merchandising module, a comparison table your category needs, an unusual homepage arrangement. Those sections are additive. They live alongside the theme rather than rewriting it, which means theme updates remain applicable. The discipline that keeps this working is resisting the urge to modify the theme's own files when a new section would do. This gets you most of the distinctiveness of custom, most of the maintainability of a theme, and a build cost between the two. It also degrades gracefully, which is an underrated property. If the relationship with your developer ends, a theme with custom sections is something any competent Shopify agency can pick up, because the majority of it is a documented commercial theme they already know. A ground-up custom build with no documentation is a considerably harder handover, and the cost of that shows up precisely when you are least able to absorb it. ## Choosing a premium theme well If the answer is a theme, which theme matters more than merchants treat it. The differences between them are mostly invisible in a demo and expensive afterwards. **Check what it weighs before it has anything on it.** Themes vary substantially in baseline page weight, and a feature-heavy theme starts you in a hole you then add apps to. Run the theme demo through PageSpeed rather than judging by how it looks. **Look at how it handles your catalogue shape.** A theme designed for a twelve-product boutique behaves differently with eight hundred products and heavy filtering. Ask the author, or find a live store using it at your scale. **Check the section inventory against your actual needs.** Every section you need that the theme lacks is custom work, and every section it has that you do not need is weight. The fit matters more than the count. **Look at the author's update history.** A theme last updated eighteen months ago is a theme whose maintenance you have quietly inherited. This information is public and almost nobody checks it. **Test the admin experience.** Your team will spend more time in the theme editor than looking at the storefront. A theme with confusing settings costs you every week, forever. > **Do not choose a theme from its demo store** > > Demo stores are populated with ideal photography, no apps, and content sized exactly to the layout. Your store has none of those. Install the theme on a development store with your real products and your real images before committing — the gap between demo and reality is where most theme regret originates. ## A way to decide 1. Design what you actually want, without reference to what is technically easy. 2. Ask a Shopify developer whether a theme can build it, and what the custom sections would be. 3. If yes — which it usually is — take the theme plus sections route. 4. If no, be specific about what cannot be done. "It would look different" is not a reason; "the browsing model is not a catalogue" is. 5. Compare three-year costs including maintenance, not build costs. 6. Confirm who maintains it before committing to anything custom. Step four is where most of the value is. Forcing the reason to be specific either confirms the custom build is necessary or reveals that it is not, and both outcomes are worth the hour it takes. One caution about who you ask. An agency that only builds custom will tend to find that you need a custom build, and an agency that only sells theme setups will find the opposite. Neither is dishonest; both are answering from what they do. If you can, ask someone who builds across the range, and ask them to argue the case against their own recommendation before you accept it. For what Horizon changed about theme capability, see [storefront and design](/category/storefront-design). The headless question, which is a different decision again, is covered in [Shopify development](/category/shopify-development). One last framing that helps more than any feature comparison: a theme is a constraint you accept in exchange for speed and cost, and a custom build is a constraint you remove in exchange for time and money. Neither is the better answer in the abstract. The question is only whether the constraint you are accepting is currently costing you anything measurable, and for most stores at launch the honest answer is that it is not yet. **Not sure which of the four you need?** ByteInfy builds Shopify storefronts across the range — configured themes, custom sections and full builds — and will tell you which one your requirements justify. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Is a premium Shopify theme good enough for a serious store? For most stores, yes, particularly with some custom work on top. Premium themes handle the standard commerce patterns competently and receive updates. ### How much does a custom Shopify theme cost? Widely variable, and the figure that matters is not the build cost but the annual maintenance. A custom theme needs updating as Shopify changes, as apps change, and as browsers change. ### Will a custom theme be faster? It can be, because you control exactly what loads. It frequently is not, because custom builds accumulate the same app scripts and third-party tags as everyone else. ### Does a custom theme help SEO? Only indirectly. What helps is clean markup, fast loading, correct structured data and sensible internal linking, all of which a good premium theme already provides. ### What is the middle option between theme and custom? A premium theme with custom sections and blocks built on top. --- --- title: "Shopify rechtssicher in Deutschland: Impressum, DSGVO, Button-Lösung" description: "Shopify liefert einen Shop, der in Deutschland ohne Anpassung nicht rechtssicher ist. Welche Texte, Einstellungen und Registrierungen fehlen, wo Sie sie im Admin finden und was in Österreich und der Schweiz abweicht." author: "Aashish Kaushik" published: 2026-09-19T05:01:12.302Z updated: 2026-09-19T05:01:12.343Z url: https://blog.byteinfy.com/shopify-rechtssicher-deutschland-impressum-dsgvo-button --- # Shopify rechtssicher in Deutschland: Impressum, DSGVO, Button-Lösung ## Key takeaways - Shopify bringt keine deutschen Rechtstexte mit; Impressum, AGB, Widerrufsbelehrung und Datenschutzerklärung müssen erstellt, eingebunden und aktuell gehalten werden. - Die Button-Lösung verlangt einen eindeutig beschrifteten Bestellbutton wie "Zahlungspflichtig bestellen"; in Shopify wird der Text über die Checkout-Inhalte geändert, auch für Express-Zahlungen. - Cookie-Einwilligung, Auftragsverarbeitung und Tracking sind DSGVO-Themen, die der Shop technisch umsetzen muss, bevor Pixel und Analytics laufen. - Verpackungsregister, Grundpreise, Lieferzeiten und Barrierefreiheit sind Pflichten, die kein Rechtstext-Generator abdeckt und die vor dem Launch geprüft gehören. Ein Shopify-Shop ist in Deutschland nach der Einrichtung nicht rechtssicher, und das liegt nicht an Shopify, sondern daran, dass deutsches Verbraucherrecht Dinge verlangt, die keine Plattform als Standard mitbringt: ein Impressum, eine Widerrufsbelehrung, eine Datenschutzerklärung, einen Bestellbutton mit eindeutiger Beschriftung, Grundpreise, Lieferzeiten und eine Cookie-Einwilligung vor dem ersten Tracking-Pixel. Jeder dieser Punkte ist im Admin oder im Theme lösbar. Der Fehler passiert, wenn Händler den Shop live schalten und diese Punkte "später" nachziehen. Dieser Artikel geht die Pflichten der Reihe nach durch und zeigt, wo sie in Shopify umgesetzt werden. Er ersetzt keine Rechtsberatung. Gesetze ändern sich, Abmahnvereine finden neue Themen, und was hier steht, entspricht dem Stand zum Zeitpunkt der Erstellung. Wer im Zweifel ist, fragt eine Kanzlei oder einen Anbieter mit Aktualisierungsservice. > **Keine Rechtsberatung** > > Dieser Text beschreibt, welche Anforderungen üblicherweise gelten und wie sie in Shopify technisch umgesetzt werden. Er ist keine Rechtsberatung und ersetzt keine anwaltliche Prüfung Ihres konkreten Shops. ByteInfy ist eine Shopify-Agentur mit Sitz in Indien und übernimmt die technische Umsetzung; die inhaltliche Prüfung der Texte gehört zu einer Kanzlei oder einem Rechtstext-Anbieter. ## Die vier Pflichttexte und wo sie in Shopify hingehören Impressum, Datenschutzerklärung, Widerrufsbelehrung und AGB sind die Texte, ohne die ein Shop in Deutschland nicht starten sollte. Shopify hat für jeden einen Platz, aber für keinen einen ausreichenden Inhalt. **Impressum.** Die Anbieterkennzeichnung nach § 5 DDG (früher TMG) muss von jeder Seite mit höchstens zwei Klicks erreichbar sein und Name, Anschrift, Kontakt, Registereintrag, Umsatzsteuer-Identifikationsnummer und je nach Rechtsform weitere Angaben enthalten. In Shopify legen Sie das Impressum als Seite an und verlinken es im Footer-Menü. Der frühere Pflichtlink zur EU-Plattform für Online-Streitbeilegung ist mit der Einstellung der Plattform im Jahr 2025 entfallen; prüfen Sie Ihr Impressum auf veraltete Verweise. **Datenschutzerklärung.** Sie muss alle Verarbeitungen, Empfänger und Drittlandübermittlungen nennen, die in Ihrem Shop stattfinden. Das schließt Shopify selbst ein, jede installierte App, jeden Zahlungsanbieter, jeden Versanddienstleister und jedes Tracking-Tool. Shopify bietet unter Einstellungen, Richtlinien ein Feld dafür; der Text wird dann im Checkout verlinkt. Die Vorlage von Shopify ist nicht für Deutschland geschrieben. **Widerrufsbelehrung.** Verbraucher haben ein 14-tägiges Widerrufsrecht; die Belehrung muss den gesetzlichen Mustertext enthalten und um das Muster-Widerrufsformular ergänzt werden. Shopify hat ebenfalls ein Richtlinienfeld dafür. Prüfen Sie, ob Ausnahmen für Ihre Produkte gelten, etwa bei versiegelten Hygieneartikeln, personalisierten Waren oder digitalen Inhalten. **AGB.** Nicht gesetzlich verpflichtend, aber in der Praxis Standard, weil sie Vertragsschluss, Zahlung, Lieferung und Eigentumsvorbehalt regeln. AGB müssen vor der Bestellung zumutbar zur Kenntnis genommen werden können; ein Link im Checkout genügt, ein Pflicht-Häkchen ist nicht vorgeschrieben. Für alle vier Texte gilt: Sie ändern sich. Anbieter wie IT-Recht Kanzlei, Händlerbund oder Trusted Shops bieten Texte mit Aktualisierungsservice und Shopify-Anbindung an, sodass Änderungen automatisch in den Shop übernommen werden. Das ist kein Werbehinweis, sondern der Weg, den die meisten deutschen Shopify-Händler gehen, weil selbst geschriebene Texte innerhalb eines Jahres veralten. ## Die Button-Lösung im Shopify-Checkout Der Button, mit dem der Kunde die Bestellung abschließt, muss eindeutig auf die Zahlungspflicht hinweisen. Das ist die Vorgabe aus § 312j Abs. 3 BGB, und sie ist einer der häufigsten Gründe für Abmahnungen. Erlaubt sind Beschriftungen wie "Zahlungspflichtig bestellen" oder "Kaufen". Nicht ausreichend sind "Bestellen", "Weiter", "Bestellung abschicken" oder das englische "Pay now", das Shopify als Standard mitbringt. Den Text ändern Sie in den Theme-Inhalten unter Checkout und System; dort finden Sie die Übersetzung des Buttons und ändern sie für die deutsche Sprache. Bei einem Theme-Wechsel wird diese Änderung nicht immer übernommen; prüfen Sie sie nach jedem Wechsel neu. Express-Zahlungen sind der zweite Prüfpunkt. PayPal Express, Shop Pay, Apple Pay und Google Pay führen teils in eigene Abläufe, und der Button, der dort die Bestellung abschließt, muss ebenfalls eindeutig sein. Testen Sie jede aktivierte Express-Zahlung auf dem Smartphone bis zum Abschluss und dokumentieren Sie den Ablauf mit Screenshots. Unmittelbar vor dem Button müssen die wesentlichen Informationen stehen: Produktbezeichnung, Gesamtpreis inklusive MwSt, Versandkosten und bei Abonnements die Laufzeit. Shopifys Checkout zeigt die Bestellübersicht auf dem letzten Schritt an; auf dem Smartphone ist sie teils eingeklappt, was Gegenstand rechtlicher Diskussion ist. Was Checkout Extensibility, das checkout.liquid abgelöst hat, hier erlaubt und was nicht, beschreibt der englische Artikel [Shopify checkout extensibility](/shopify-checkout-extensibility). ## Preise, Versandkosten, Lieferzeit und Grundpreis Neben den Rechtstexten verlangt das Gesetz Angaben an jedem Produkt und auf der Bestellstrecke. Diese Punkte sind Theme-Arbeit, nicht Textarbeit. **Preise inklusive MwSt.** Verbraucherpreise müssen als Endpreise mit MwSt angezeigt werden, mit dem Hinweis "inkl. MwSt." und einem Hinweis auf Versandkosten in der Nähe des Preises. In Shopify aktivieren Sie "Steuern in Preisen enthalten"; den Hinweis "inkl. MwSt., zzgl. Versand" gibt das Theme aus, wenn es dafür vorbereitet ist. Nicht jedes Theme aus dem Theme Store macht das an jeder Stelle, etwa in Produktkarten in Kollektionen oder in Empfehlungen. **Versandkosten.** Eine eigene Seite mit den Versandkosten pro Land, verlinkt vom Preishinweis und im Footer. Für Kunden in Österreich und der Schweiz müssen die Kosten für das jeweilige Land stehen, nicht nur "Versand ab 4,90 Euro". **Lieferzeit.** Verbraucher müssen wissen, bis wann geliefert wird. "Lieferzeit 2 bis 4 Werktage" auf der Produktseite ist der übliche Weg; Shopify hat dafür kein natives Feld, es wird über Metafelder oder das Theme gelöst. Für Produkte mit abweichender Lieferzeit muss die Angabe pro Produkt stimmen. **Grundpreis.** Waren nach Gewicht, Volumen, Länge oder Fläche brauchen den Grundpreis (etwa Preis pro 100 g oder pro Liter) in der Nähe des Gesamtpreises. Shopify unterstützt Grundpreise an der Variante; das Theme muss sie in Produktseite, Kollektion, Warenkorb und Checkout ausgeben. ## Pflichtangaben und wo sie in Shopify umgesetzt werden | Pflicht | Rechtsgrundlage (Deutschland) | Umsetzung in Shopify | | --- | --- | --- | | Impressum | § 5 DDG | Seite anlegen, im Footer verlinken | | Datenschutzerklärung | Art. 13 DSGVO | Richtlinien-Feld, im Checkout und Footer verlinkt | | Widerrufsbelehrung mit Formular | § 312g BGB, Art. 246a EGBGB | Richtlinien-Feld plus Seite | | Bestellbutton | § 312j Abs. 3 BGB | Theme-Inhalte, Checkout und System | | Endpreis mit MwSt und Versandhinweis | PAngV | Steuereinstellung plus Theme-Ausgabe | | Grundpreis | PAngV | Variante mit Grundpreis plus Theme-Ausgabe | | Lieferzeit | Art. 246a EGBGB | Metafeld oder Theme-Block | | Cookie-Einwilligung | § 25 TDDDG, DSGVO | Shopify-Einwilligung oder Consent-App | | Bestellbestätigung | § 312i BGB | Shopify-Benachrichtigung, Inhalt prüfen | ## DSGVO: Auftragsverarbeitung, Cookies und Tracking Die DSGVO betrifft in einem Shopify-Shop drei Ebenen: den Vertrag mit Shopify, die Einwilligung der Besucher und die Apps und Tools, die Daten empfangen. **Auftragsverarbeitung.** Shopify verarbeitet Kundendaten in Ihrem Auftrag; der entsprechende Vertrag ist Teil der Nutzungsbedingungen. Daten werden außerhalb der EU verarbeitet, was über Angemessenheitsbeschlüsse und Standardvertragsklauseln abgedeckt wird. Für Ihre Datenschutzerklärung heißt das, dass Shopify als Empfänger mit Drittlandübermittlung genannt wird. Dasselbe gilt für jede App, die Kundendaten liest, und für Zahlungs- und Versandanbieter. **Cookie-Einwilligung.** Nicht notwendige Cookies und vergleichbare Technologien, also Meta Pixel, Google Analytics, Google Ads, TikTok Pixel und die meisten Personalisierungs-Apps, brauchen eine Einwilligung vor dem Setzen. Der Banner muss Ablehnen so leicht machen wie Akzeptieren. Shopify bringt in den Einstellungen unter Kundendatenschutz eine Einwilligung mit, die mit der Customer Privacy API zusammenarbeitet, sodass Pixel erst nach Einwilligung feuern, wenn sie über Shopify Customer Events eingebunden sind. Consent-Apps erweitern das um Kategorien, Protokollierung und Google Consent Mode, der für Google Ads inzwischen vorausgesetzt wird. **Tracking sauber einbinden.** Pixel, die direkt im Theme-Code stehen, feuern vor jeder Einwilligung. Der saubere Weg sind Shopify Customer Events oder eine Consent-App, die die Einwilligung an alle Tags weitergibt. Wer das richtig einrichtet, bekommt zudem Zahlen, die Shopify und GA4 annähernd übereinstimmen lassen; ByteInfy bietet das als [Analytics und Tracking Setup](https://byteinfy.com/services/shopify-analytics-setup) ab 500 $ an. **Betroffenenrechte.** Auskunft, Berichtigung und Löschung müssen umsetzbar sein. Shopify bietet dafür Funktionen im Kundendatensatz und verpflichtet App-Anbieter über Pflicht-Webhooks, Löschanfragen zu verarbeiten. Der englische Artikel [Shopify GDPR mandatory webhooks](/shopify-gdpr-mandatory-webhooks) beschreibt, was Apps hier leisten müssen. ## Registrierungen, die kein Shop-Setting sind Einige Pflichten liegen außerhalb von Shopify und werden bei der Planung häufig vergessen, weil sie weder Text noch Theme betreffen. **Verpackungsregister.** Wer Verpackungen an Endverbraucher in Deutschland in Verkehr bringt, muss sich im Verpackungsregister LUCID registrieren und an einem dualen System beteiligen, bevor die erste Sendung rausgeht. Die Registrierungsnummer gehört nach verbreiteter Praxis ins Impressum. **Elektrogeräte und Batterien.** Wer Elektrogeräte oder Batterien verkauft, braucht Registrierungen nach ElektroG und Batterierecht, mit Rücknahmepflichten und Hinweispflichten im Shop. Das betrifft mehr Händler, als man denkt, etwa jeden, der Produkte mit eingebauter Batterie verkauft. **Barrierefreiheit.** Seit Ende Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz für Onlineshops, mit Ausnahmen für sehr kleine Unternehmen. Theme, Bilder, Formulare und Inhalte müssen Anforderungen an Kontrast, Tastaturbedienung, Alt-Texte und Struktur erfüllen. Alt-Texte für Produktbilder sind dabei sowohl Barrierefreiheit als auch SEO; der englische Beitrag [Shopify image alt text SEO](/shopify-image-alt-text-seo) zeigt, wie man sie in großen Katalogen pflegt. **Produktspezifische Pflichten.** Lebensmittelkennzeichnung, Textilkennzeichnung, Spielzeugsicherheit, Kosmetikverordnung und ab Dezember 2024 die Produktsicherheitsverordnung mit Angaben zum Hersteller und zur verantwortlichen Person in der EU. Was für Ihre Produkte gilt, klären Sie mit Ihrem Rechtstext-Anbieter oder einer Kanzlei. ## Was in Österreich und der Schweiz abweicht Wer in alle drei Länder verkauft, richtet die Texte nach dem strengsten Standard aus und ergänzt Länderbesonderheiten, statt drei getrennte Regelwerke zu pflegen. In Österreich gelten ähnliche Pflichten mit eigenen Grundlagen: Impressum nach ECG und Mediengesetz, Widerruf nach FAGG, Cookie-Einwilligung nach TKG. Die Widerrufsfrist ist ebenfalls 14 Tage, die Preisangaben müssen inklusive MwSt sein, der österreichische Normalsatz liegt bei 20 Prozent. Eine deutsche Widerrufsbelehrung ist nicht automatisch für Österreich korrekt; Anbieter mit Aktualisierungsservice liefern meist länderspezifische Varianten. In der Schweiz gilt das revidierte Datenschutzgesetz, das eine Datenschutzerklärung verlangt, aber keine Cookie-Einwilligung im EU-Stil vorschreibt. Sobald EU-Kunden bedient werden, kommt die DSGVO hinzu. Ein gesetzliches Widerrufsrecht für Onlinekäufe gibt es in der Schweiz nicht; viele Händler gewähren freiwillig eines. Preise werden inklusive MwSt angezeigt, der Normalsatz liegt zum Zeitpunkt der Erstellung bei 8,1 Prozent. Was ein Schweizer Shop zusätzlich braucht, von TWINT bis Zoll, steht im Artikel [Shopify in der Schweiz](/de/shopify-schweiz-twint-chf-mwst-agenturwahl). Technisch löst Shopify Markets die Länderunterschiede bei Währung, Steuern und Domains. Für Rechtstexte pro Land legen Sie Seiten pro Markt an oder nutzen die Übersetzungsfunktion, um Textvarianten pro Markt auszuspielen. Die SEO-Seite von Markets behandelt die [Shopify SEO Checkliste](/de/shopify-seo-optimierung-checkliste-mit-25-punkten). ## Vor dem Launch prüfen Die folgende Liste deckt die Punkte ab, die in Abmahnungen und in Audits am häufigsten auffallen. Sie ist als Ablauf vor dem Live-Gang gedacht, nicht als vollständige Rechtsprüfung. ## Rechtsprüfung vor dem Live-Gang - Impressum, Datenschutzerklärung, Widerrufsbelehrung mit Formular und AGB angelegt, im Footer und im Checkout verlinkt - Bestellbutton im Checkout und in jeder Express-Zahlung auf "Zahlungspflichtig bestellen" oder gleichwertig geändert, auf dem Smartphone getestet - Steuern in Preisen enthalten, Hinweis "inkl. MwSt., zzgl. Versand" an Produktkarten, Produktseite, Warenkorb geprüft - Versandkostenseite mit Kosten pro Land, Lieferzeit an jedem Produkt, Grundpreise bei Waren nach Menge - Cookie-Einwilligung aktiv, Pixel feuern erst nach Einwilligung, Ablehnen ist so leicht wie Akzeptieren - Jede installierte App, jeder Zahlungs- und Versandanbieter in der Datenschutzerklärung genannt - Bestellbestätigung per E-Mail enthält Vertragsinhalt, Widerrufsbelehrung und AGB - Verpackungsregister erledigt, ElektroG und Batterierecht geprüft, Produktsicherheit geprüft - Theme auf Kontrast, Tastaturbedienung und Alt-Texte geprüft - Rechtstexte an einen Aktualisierungsservice angebunden oder Termin zur Prüfung eingetragen Zwei Punkte aus der Liste verdienen einen zweiten Blick. Die Bestellbestätigung: Shopifys Standardvorlage enthält keine Widerrufsbelehrung und keine AGB; beides gehört in die Vorlage unter Benachrichtigungen. Und die Apps: Jede App, die nach dem Launch dazukommt, ist ein neuer Empfänger in der Datenschutzerklärung und potenziell ein neues Skript, das vor der Einwilligung lädt. ## Rechtssicherheit ist Theme-Arbeit, nicht nur Textarbeit Die meisten Punkte in diesem Artikel haben eine Textseite und eine Theme-Seite. Der Text kommt vom Anbieter, die Ausgabe im Theme kommt von jemandem, der den Theme-Code kennt: der MwSt-Hinweis an jeder Produktkarte, der Grundpreis in Kollektion und Warenkorb, die Lieferzeit pro Produkt, die Pixel hinter der Einwilligung, die Bestellbestätigung mit den richtigen Anhängen. Bei einem neuen Shop gehört das in die Leistungsbeschreibung, bei einem bestehenden Shop ist es ein überschaubares Projekt. ByteInfy setzt solche Anpassungen als [Theme-Anpassung](https://byteinfy.com/services/shopify-theme-customization) ab 1.000 $ um; die Texte selbst kommen von Ihrem Rechtstext-Anbieter. Was Sie bei einem Angebot dafür prüfen sollten, steht im Artikel [Shopify Agentur Kosten 2027](/de/shopify-agentur-kosten-2027-was-ein-shop-wirklich). **Ihr Theme zeigt MwSt, Grundpreis oder Lieferzeit nicht überall an?** ByteInfy prüft Theme, Checkout und Tracking gegen die Liste oben, setzt die technischen Punkte um und arbeitet mit dem Rechtstext-Anbieter Ihrer Wahl zusammen. [Mit ByteInfy sprechen](https://byteinfy.com/contact) ## FAQ ### Welche Rechtstexte braucht ein Shopify-Shop in Deutschland? Mindestens ein Impressum, eine Datenschutzerklärung, eine Widerrufsbelehrung mit Muster-Widerrufsformular und, in der Praxis, AGB. Dazu kommen Angaben zu Versandkosten und Lieferzeiten, die als eigene Seite oder im Checkout sichtbar sein müssen. ### Wie setze ich die Button-Lösung in Shopify um? Der Bestellbutton im letzten Schritt des Checkouts muss eindeutig auf die Zahlungspflicht hinweisen, etwa mit "Zahlungspflichtig bestellen" oder "Kaufen". Den Text ändern Sie in Shopify über die Inhalte des Checkouts in den Theme-Inhalten. ### Brauche ich einen Cookie-Banner in Shopify? Ja, sobald Sie Cookies oder ähnliche Technologien einsetzen, die nicht technisch notwendig sind, also etwa Meta Pixel, Google Analytics oder Google Ads Conversion Tracking. Die Einwilligung muss vor dem Setzen erfolgen und ablehnbar sein. ### Ist Shopify DSGVO-konform? Shopify stellt die technische Grundlage bereit, etwa einen Auftragsverarbeitungsvertrag als Teil der Nutzungsbedingungen, Datenschutzeinstellungen für Kundendaten und Schnittstellen für Auskunft und Löschung. ### Muss ich Grundpreise anzeigen? Ja, für Waren, die nach Gewicht, Volumen, Länge oder Fläche verkauft werden, etwa Lebensmittel, Kosmetik oder Stoffe. Der Grundpreis muss in der Nähe des Gesamtpreises stehen, auf der Produktseite und in der Kollektion. ### Was ist mit der Barrierefreiheit? Seit Ende Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz, dass Onlineshops für Verbraucher barrierefrei nutzbar sind, mit Ausnahmen für sehr kleine Unternehmen. ### Gelten die Regeln auch in Österreich und der Schweiz? Österreich hat eigene, ähnliche Vorgaben, etwa Impressum nach ECG und Mediengesetz, Widerruf nach FAGG und Cookie-Einwilligung nach TKG. --- --- title: "Best Shopify SEO Apps in 2026" description: "Shopify SEO apps fall into four categories, and only two of them are worth money for most stores. Here is what each actually does and what none of them can help with." author: "Aashish Kaushik" published: 2026-09-18T13:01:42.703Z updated: 2026-09-18T13:01:42.895Z url: https://blog.byteinfy.com/best-shopify-seo-apps --- # Best Shopify SEO Apps in 2026 ## Key takeaways - Shopify handles canonicals, sitemaps and clean URLs natively, so apps claiming to fix those are selling you something you already have. - The categories that genuinely earn their fee are bulk metadata editing and structured data, because both are scale problems. - An SEO app that injects script into every page can cost you more in Core Web Vitals than it returns in rankings. - No app fixes thin collections, weak product data or an absent content strategy, and those are what actually hold most stores back. The Shopify App Store lists a great many SEO apps and they describe themselves almost identically. Most merchants install one, see no change, and conclude SEO apps do not work. The more useful framing is that these apps automate specific mechanical tasks. Some of those tasks matter a lot at scale and are genuinely tedious by hand. Others duplicate something Shopify already does. Knowing which is which is most of the decision. > **On ratings and rankings** > > Review counts, pricing and feature sets in this category change constantly, and a large share of "best SEO app" content is published by SEO app vendors. Nothing here ranks specific products; check current listings before deciding. ## What Shopify already does for you Start here, because it eliminates a whole category of app marketing. Out of the box, Shopify generates and maintains an XML sitemap, sets canonical tags on products reachable through multiple paths, produces clean and readable URLs, serves everything over SSL, gives you editable page titles and meta descriptions on every resource, provides alt text fields on images, and ships responsive themes. Any app whose pitch is "adds canonical tags" or "generates a sitemap" is selling you something you have. This is not rare — it is one of the most common claims in the category, and it works because merchants do not know the platform already handles it. ## The four categories that actually exist Underneath the marketing, SEO apps do four things. ## What each category does and whether it earns its fee | Category | The job | Worth paying for | | --- | --- | --- | | Bulk metadata editing | Titles, descriptions, alt text across many products at once | Yes, above a few hundred products | | Structured data | Emitting schema your theme does not | Yes, if your theme is weak here | | Redirect and 404 management | Catching and redirecting broken URLs | At scale, or after a migration | | Audit and reporting | Scanning for issues and scoring pages | Rarely — free tools do this | The two on the left worth money are worth it for the same reason: they are scale problems. Editing metadata for eight hundred products by hand is not a strategy, it is a fortnight. Emitting correct product schema across a catalogue is not something to do manually. The bottom category is where most money is wasted. Audit apps produce a list of issues you could get free from Search Console and a crawler, wrapped in a score that moves for reasons you cannot act on. ## Bulk editing is the one most stores actually need If your catalogue is large, this is the category to look at first, and the reason is arithmetic rather than sophistication. A store with six hundred products has six hundred title tags, six hundred meta descriptions and several thousand images needing alt text. Doing that by hand is weeks of work, and the work decays — new products arrive without metadata, and the gap reopens. What good bulk tooling gives you: - Rule-based generation. Templates using product fields, so new products inherit sensible metadata automatically rather than launching bare. - Bulk overwrite with preview. The ability to see what a rule will produce across the catalogue before committing it. - Alt text at scale, including automation rules, since images outnumber products several times over. - Exception handling, so your twenty most important products can be written by hand while the long tail is generated. That last point separates useful tools from blunt ones. A rule applied to everything produces uniform, mediocre metadata. The right pattern is hand-written metadata where it matters and generated metadata everywhere else. ## Structured data, and what changed in 2026 The second category worth money, with one important caveat about what has changed. Google fully retired FAQ rich results for all sites on 7 May 2026. If you are evaluating an app on the promise of FAQ rich snippets, that promise is obsolete. What still matters is accurate Product schema — price, availability, condition, review data where genuine — plus Organization, BreadcrumbList and Article markup on content. Many themes emit some of this and few emit all of it correctly, which is the genuine gap an app fills. Two cautions. First, schema that contradicts the visible page is worse than no schema, so an app generating markup from fields that do not match what shoppers see is actively harmful. Second, check whether your theme already emits product schema before installing something that will emit a second, conflicting copy — duplicate structured data is a real and common outcome of installing an app on a modern theme. ## Redirects matter most right after a change Redirect management is worth its fee in specific circumstances rather than permanently. Shopify has built-in URL redirect functionality, and for a store changing a handful of URLs a year that is sufficient. The case for an app is a migration, a replatform, a large collection restructure, or a catalogue where products are regularly discontinued and their URLs left to 404. What an app adds is scale and detection: bulk import of redirect maps, automatic detection of 404s from real traffic, and patterns rather than one-to-one rules. If you are not in one of those situations, the native feature is fine. ## The page-speed trap This is the consideration most missing from SEO app comparisons, and it is the one that can make an SEO app net negative. Some apps in this category inject JavaScript into every page — to render schema client-side, to manage redirects, or to collect data for their reporting. That weight lands on every template, including ones that gain nothing. Page speed is itself both a ranking input and a conversion factor. An app that improves your metadata while costing you a second of load time on every product page has probably not helped. Schema, in particular, should be rendered server-side in the page source, not injected by script — a crawler should see it in the HTML. ## Ask before installing any SEO app - Does it render schema server-side, or inject it with JavaScript? - Does it load on templates where its feature does not apply? - Does my theme already emit the schema this app generates? - What happens to generated metadata if I uninstall — does it persist or vanish? - Does it write into theme files, or use a theme app extension? The fourth question catches people out. Some apps store metadata in their own database and render it dynamically, which means uninstalling strips every title and description you generated. Others write to Shopify's native fields, which persist. The difference is the difference between an app you can leave and an app you are locked into. ## What no app will fix Worth being blunt, because this is where most disappointment originates. **Thin or duplicate collection pages.** Auto-generated collections multiplying into near-empty crawlable pages is a structural problem requiring merchandising decisions, not a plugin. **Weak product data.** Vague titles, empty product types, descriptions written as brand voice rather than fact. An app can bulk-edit these fields; it cannot decide what should be in them, and that decision is the actual work. **No content.** Category-level search demand is won by collection and editorial content that answers selection questions. No app writes that. **Site architecture.** How collections nest, what links to what, which pages are reachable in how many clicks — these are design decisions. **Authority.** Nothing installable substitutes for being referenced by sources that are themselves trusted. ## The free tools you should exhaust first Before paying for anything, there is a set of free tooling that covers most of what an audit app sells, and covers it better because the data comes from Google rather than from a third-party crawl. **Search Console** is the single most valuable and the most underused. Its page indexing report tells you exactly which URLs Google has chosen not to index and why — and on Shopify stores those buckets are usually filtered collection variants, which is genuinely actionable. The performance report tells you which queries you already rank for, which is the honest starting point for any content plan. **Bing Webmaster Tools** is worth ten minutes to connect, partly for its own traffic and partly because several AI answer surfaces draw on that index. **A crawler** run against your own site will find broken links, redirect chains, missing metadata and duplicate titles — the entire contents of most audit app reports. **PageSpeed Insights and the Core Web Vitals report** give you field data from real visitors, which no app can replicate because it comes from Chrome. Running these first does two things. It tells you whether you have a problem an app can solve, and it gives you a baseline to judge whether the app you buy actually changed anything. Merchants who skip this step have no way to evaluate the tool they are paying for, which is how a subscription survives three years without anyone asking what it did. ## How to decide 1. Count your products. Under a couple of hundred, do metadata by hand and install nothing. 2. Check what your theme already emits. View source on a product page and look for existing schema before buying an app to add it. 3. Identify which of the four jobs you need. Most stores need one, not a suite. 4. Test page-speed impact on a duplicate theme before committing. 5. Confirm the exit path — what persists if you uninstall. For the structural work that actually moves Shopify rankings, see [SEO and AI search](/category/seo-ai-search). Page weight and app selection generally are covered in [storefront and design](/category/storefront-design) and [Shopify apps](/category/shopify-apps). **Image alt text across a whole catalogue** ByteInfy's Alt Text Bulk Edit handles alt text with automation rules, plus image compression and SEO file renaming — the bulk half of Shopify SEO, done properly. [See it on the Shopify App Store](https://apps.shopify.com/byteinfy-alt-text-editor) ## FAQ ### Do I need an SEO app for Shopify? Most stores do not need one to start. Shopify already generates sitemaps, sets canonical tags, produces clean URLs and serves over SSL. ### Which Shopify SEO app is best? The honest answer is that it depends on which of four jobs you need done, and most stores need bulk editing rather than an all-in-one suite. ### Can an SEO app get me to page one? No, and any app implying otherwise should be treated with suspicion. Apps automate mechanical tasks — writing metadata across many products, emitting schema, finding broken links. ### Do SEO apps slow down a Shopify store? Some do. Apps that inject script into every page to render schema or manage redirects add weight to templates that gain nothing from them. ### Does Shopify have built-in SEO features? Yes, more than most merchants realise. Automatic sitemap generation, canonical tags, editable page titles and meta descriptions, alt text fields, clean URL structure, SSL and mobile-responsive themes are all standard. --- --- title: "Hiring a Shopify SEO Agency: What to Expect" description: "The hardest thing about buying SEO is that you cannot judge it for months, and by then you have paid for months. Here is what to ask before that." author: "Aashish Kaushik" published: 2026-09-18T09:01:19.259Z updated: 2026-09-18T09:01:19.287Z url: https://blog.byteinfy.com/shopify-seo-agency-what-to-expect --- # Hiring a Shopify SEO Agency: What to Expect ## Key takeaways - Shopify SEO is mostly structural — indexation, product data, page weight — and an agency that only offers content is offering half. - Reported rankings and traffic are easy to present favourably, so agree in advance on metrics that are hard to game. - The first month should be diagnosis, and a proposal that skips straight to deliverables has not looked at your store. - Ask what they would tell you not to do; an agency with no such answer is selling scope rather than judgement. SEO is unusually hard to buy well. The work takes months to show results, the reporting is easy to present favourably, and the buyer frequently cannot evaluate the recommendations. That combination attracts a spread of quality wider than most professional services, and it means the questions you ask before signing matter more than usual. > **What this is** > > A buyer's guide, written by people who sell the service. Read it with that in mind — the questions below are ones we would expect to be asked, and an agency that cannot answer them comfortably is worth being cautious about. ## Shopify SEO is mostly structural The most useful thing to understand before hiring anyone. On most Shopify stores, the constraints are not keyword choice. They are duplicate collection URLs consuming crawl budget, thin auto-generated collections, product data too sparse for Google or AI surfaces to use, app scripts costing page speed, and collection pages with no content competing for category queries. None of that is content work. An agency whose proposal is a content calendar is offering the fifth thing on the list before the first four have been looked at. A proposal that reflects your actual store will mention some of these specifically, because they will be visible in ten minutes of looking. ## The first month should be diagnosis What good looks like at the start. **A crawl of your store**, producing a list of real problems rather than a generic audit template. **Search Console analysis**, particularly the page indexing report. On a Shopify store this is where the structural problems announce themselves. **Product data assessment.** Completeness, consistency, whether specifications are text or trapped in images. **Page speed measured on real devices**, with the app-level causes identified. **A prioritised plan** that says what to do first and why, with an honest view of what each item is likely to achieve. If a proposal skips this and arrives with deliverables, it was written from a template. That is not automatically disqualifying — the work may still be competent — but you are buying a process rather than a response to your situation. ## Agree metrics that are hard to game The reason SEO reporting has a poor reputation. ## Metrics, and how much to trust them | Metric | Gameable | Better used as | | --- | --- | --- | | Keyword rankings | Very | A directional signal, not a report | | Total organic traffic | Somewhat | Context, alongside other numbers | | Impressions | Very | Nearly meaningless alone | | Organic revenue | Hard | A primary measure | | Organic sessions to key templates | Hard | A primary measure | | Indexed pages versus intended | Hard | Excellent for structural work | | Core Web Vitals field data | Hard | Excellent, and comes from Google | Rankings deserve the scepticism. Ranking positions vary by location, device and personalisation, and a report can be assembled from terms that happen to have moved. Rankings are a useful internal signal and a poor basis for judging an engagement. The lower rows are harder to present selectively, which is exactly why they are better. Agree them before starting, and agree the measurement window. ## Questions that separate agencies Six worth asking, and the answers are more informative than the pitch. **"What would you tell me not to do?"** An agency with no answer is selling scope. One with a real answer — do not blog yet, do not rebuild the site, do not buy that app — is exercising judgement. **"What did you find when you looked at my store?"** They should have looked. Specifics here separate a genuine response from a template. **"What will this not fix?"** Honest boundaries. SEO does not fix a weak product, an uncompetitive price, or a category you have no authority in. **"Who actually does the work?"** Whether the person sitting in the meeting is the person doing it, and who you will be speaking to in month four when the novelty has worn off. **"What happens when we stop?"** Structural fixes persist. Content stops accumulating. An agency should be clear which parts of their work are durable. **"How will we know it worked?"** If the answer is a report, ask again. ## What to expect month by month Roughly, and with the caveat that stores differ. **Month one.** Diagnosis, and the beginning of structural fixes. Very little visible movement in any metric, and that is exactly what should happen. **Months two and three.** Structural work landing. Indexation improves, page speed moves, product data fills in. Traffic may begin responding, particularly if crawl waste was significant. **Months four to six.** Content and collection work. Rankings on category terms start moving. **Beyond six months.** Compounding, if the work has been good. This is where authority and content investment show up. An agency promising significant movement in a matter of weeks is describing something other than what usually happens — or is planning to show you rankings on terms that were always going to be easy to win and were never worth winning. ## The warning signs Patterns that correlate with disappointment, drawn from what merchants report after engagements go badly. **A proposal that mentions nothing specific about your store.** Generic audits are cheap to produce and expensive to buy. **Deliverables measured in quantity.** "Twenty blog posts a month" or "fifty backlinks" describes output rather than outcome, and both are quantities you can buy without anyone thinking about your business. **Vagueness about who does the work.** Sales in the meeting, someone unnamed afterwards. **Reporting that arrives before results could exist.** A detailed report in month one is a report about activity, and activity is not the thing you bought. **Reluctance to explain reasoning.** An agency that says a change is needed but cannot say why, in terms you understand, is either not sure or not willing to be checked. Ask them to explain one recommendation from first principles and see whether the answer survives a follow-up question. **Anything involving link buying.** Aside from the risk, it signals that authority is being simulated rather than built. **No interest in your product data or page speed.** On Shopify these are frequently where the problem is, and an agency uninterested in them is running a playbook rather than looking at your store. ## Setting the engagement up well What the buyer controls, and it affects the outcome more than most merchants realise. **Give access early.** Search Console, analytics, the store admin. An agency working without data is guessing, and the delay in providing it comes out of the engagement. **Name a decision-maker.** SEO work generates recommendations that need approving — template changes, collection consolidation, product data decisions. Engagements stall on unresolved approval far more often than on technical difficulty. **Be honest about capacity.** If nobody internally can write product descriptions or approve template changes, say so at the start. The plan should reflect what will actually happen rather than what would be ideal. **Agree the reporting cadence and format** in advance, including what is in it. Monthly is normal; the content matters more than the frequency. **Expect to do some of the work.** The best outcomes involve the merchant doing things only they can do — product knowledge, photography, answering the questions customers actually ask. An engagement where the agency does everything is usually one where the distinctive content never gets made. > **Ask for the audit as a standalone first** > > A paid audit is a low-commitment way to evaluate an agency. You get a diagnosis you own, you see how they think, and you can take the findings elsewhere if the fit is wrong. Any agency confident in their work will offer this; one that will only sell a long retainer is asking you to commit before you can judge. ## Agency or in-house Both, usually, and in a particular order. **The structural work suits an agency.** It is finite, specialised, and has an end state. Indexation fixes, product data structure, page weight, template work. **The ongoing work suits in-house.** Content, product data maintenance, and the continuous small decisions benefit from knowing the business and the customers. The common failure is paying an agency retainer indefinitely for work that should have been transferred. A good engagement leaves you able to maintain what was built, and an agency that resists that is optimising for the retainer rather than for your store. The handover is worth specifying in the contract rather than assuming it. What documentation you receive, what access remains yours, whether the templates and content are transferable, and who owns anything custom that was built. These are easy conversations at the start and awkward ones at the end, and the difference between an engagement that leaves you stronger and one that leaves you dependent is usually settled in that paperwork rather than in the work itself. > **Be wary of guarantees** > > Nobody controls Google. An agency guaranteeing rankings is either promising something they cannot deliver or planning to deliver it on terms so uncompetitive that ranking means nothing. Confidence about process is reasonable; guarantees about outcomes are not. For the structural work itself, see [SEO and AI search](/category/seo-ai-search). Collection architecture and product data are covered in the same archive. **Want the diagnosis before the proposal?** ByteInfy audits Shopify stores for indexation, product data, page weight and AI-surface readiness — and tells you plainly what is worth fixing first. [Start a project](https://byteinfy.com/#contact) ## FAQ ### How much does Shopify SEO cost? It varies enormously by scope and market, and the more useful question is what the engagement covers. An audit is a defined piece of work with a deliverable. ### How long before Shopify SEO shows results? Structural fixes — indexation, page speed, product data — can show within weeks because they remove impediments rather than building authority. Content and authority work takes months. ### What should a Shopify SEO agency actually do first? Diagnose. Crawl the store, read Search Console, look at indexation and page speed, and audit product data. ### How do I know if my SEO agency is doing anything useful? Agree measurable outcomes in advance, prefer metrics that are hard to present selectively, and ask for the reasoning behind recommendations rather than only the list. ### Should I hire an agency or do Shopify SEO in-house? The structural work is finite and specialised, which suits an engagement. The ongoing content and product data work is continuous and benefits from knowing the business, which suits in-house. --- --- title: "Rabatte mit Shopify Functions bauen (Scripts sind abgeschaltet)" description: "Shopify Scripts sind abgekündigt, und alles, was früher als Ruby-Script im Checkout lief, läuft heute als Shopify Function. Was das für Staffelrabatte, Bundles und Kundenpreise bedeutet, was Shopify nativ kann und wann eine Function nötig ist." author: "Aashish Kaushik" published: 2026-09-18T05:01:02.099Z updated: 2026-09-18T05:01:02.107Z url: https://blog.byteinfy.com/rabatte-mit-shopify-functions-bauen-scripts-sind --- # Rabatte mit Shopify Functions bauen (Scripts sind abgeschaltet) ## Key takeaways - Shopify Functions ersetzen Scripts; Scripts sind abgekündigt, und Plus-Händler mussten bis 2025 migrieren. - Viele Rabattfälle deckt Shopify nativ ab; eine Function lohnt sich erst für Logik, die automatische Rabatte und Kombinationsregeln nicht abbilden. - Eine Function läuft im Checkout, wird über Metafelder konfiguriert und braucht eine App als Hülle, die jemand pflegen muss. - Eine einzelne Function kostet bei ByteInfy 1.500 $ bis 3.000 $; der größere Posten ist die Konfigurationsoberfläche, damit Ihr Team Regeln ohne Entwickler ändern kann. Rabatte, die früher als Shopify Script liefen, laufen heute als Shopify Function, und für die meisten Händler ist die erste Frage nicht, wie man eine Function baut, sondern ob man eine braucht. Scripts sind abgekündigt, Plus-Händler mussten bis 2025 migrieren, und Shopify hat gleichzeitig die nativen Rabatte so erweitert, dass ein Teil der alten Script-Logik heute ohne Code funktioniert. Eine Function lohnt sich erst für das, was übrig bleibt: Staffelrabatte über mehrere Stufen, Bundles mit eigener Preislogik, Kundenpreise nach Tags oder Metafeldern und Regeln, die von Lieferland oder Zahlungsart abhängen. Dieser Artikel erklärt, was Functions sind, welche Rabattfälle Shopify nativ abdeckt, wann eine Function nötig wird, was sie kostet und wie Sie alte Scripts geordnet ablösen. Die technische Tiefe hält sich in Grenzen; wer Code sehen will, findet ihn im englischen Artikel [Shopify Functions for discounts](/shopify-functions-discounts). > **Scripts sind abgekündigt** > > Shopify Scripts, der Ruby-basierte Script Editor für Plus-Händler, sind abgekündigt, und Plus-Händler mussten bis 2025 auf Functions migrieren. Wer noch Script-Logik im Betrieb hat oder Dokumentation aus der Script-Ära nutzt, arbeitet mit einem abgeschalteten System. Checkout-Anpassungen laufen heute ausschließlich über Checkout Extensibility, das checkout.liquid abgelöst hat, und über Functions. ## Was eine Shopify Function ist Eine Function ist ein kleines, kompiliertes Programm, das Shopify im Checkout ausführt, um Rabatte, Versandoptionen, Zahlungsarten oder den Warenkorb selbst zu verändern. Der entscheidende Unterschied zu Scripts liegt in der Ausführung. Scripts liefen als interpretierter Ruby-Code, den der Händler im Admin bearbeitete. Functions werden in Rust oder JavaScript geschrieben, zu WebAssembly kompiliert und als Teil einer App installiert. Shopify führt sie mit strengen Grenzen aus: keine Netzwerkzugriffe, begrenzte Laufzeit, begrenzte Eingabegröße. Das macht sie schnell und berechenbar, aber auch enger als Scripts. Eine Function bekommt als Eingabe den Warenkorb, den Kunden, die Lieferadresse und konfigurierte Metafelder. Sie gibt als Ausgabe eine Liste von Operationen zurück, etwa "10 Prozent auf diese drei Zeilen" oder "diese Versandoption ausblenden". Die Konfiguration, also welche Stufen, welche Prozentsätze, welche Kundengruppen, liegt in Metafeldern und wird über eine Oberfläche in der App gepflegt. Für Rabatte gibt es Functions, die Produkt-, Bestell- und Versandrabatte erzeugen; in aktuellen API-Versionen lassen sich diese Klassen in einer Function kombinieren. Dazu kommen Functions für Versandregeln, Zahlungsreihenfolge, Warenkorb-Validierung und Cart Transform, mit dem Bundles im Checkout als ein Artikel erscheinen. Der englische Beitrag [Shopify Functions cart transform](/shopify-functions-cart-transform) geht auf Letzteres ein. ## Was Shopify nativ kann, bevor Sie eine Function bauen Ein großer Teil der Rabattwünsche, die als "wir brauchen eine Function" ankommen, lässt sich mit den nativen Rabatten von Shopify abbilden. Das zu prüfen spart Geld. Shopify bietet automatische Rabatte und Rabattcodes für Prozent- oder Betragsrabatte auf Produkte, Kollektionen oder die gesamte Bestellung, Kaufe-X-erhalte-Y, kostenlosen Versand, Mindestbestellwerte oder Mindestmengen und Kombinationsregeln, mit denen Sie festlegen, ob Produkt-, Bestell- und Versandrabatte zusammen gelten. Der englische Artikel [Shopify discount stacking](/shopify-discount-stacking) erklärt die Kombinationslogik im Detail. Was damit geht: 10 Prozent auf alles über 100 Euro, drei Artikel zum Preis von zwei, kostenloser Versand ab 50 Franken, ein Willkommenscode, der sich nicht mit dem Sale kombinieren lässt. Für viele Händler in Deutschland, Österreich und der Schweiz deckt das den gesamten Bedarf ab. Was nicht geht: eine Staffel mit fünf Mengenstufen und unterschiedlichen Prozentsätzen, ein Rabatt nur für Kunden mit dem Tag "Großhandel", ein Bundle aus drei beliebigen Artikeln einer Kollektion zum Festpreis, ein Rabatt, der nur bei Lieferung nach Österreich gilt, oder eine Regel, die von der Zahlungsart abhängt. Für diese Fälle brauchen Sie eine Function oder eine App, die eine Function mitbringt. ## Rabattfall, Weg und Aufwand | Rabattfall | Nativ in Shopify | Function nötig | Typischer Weg | | --- | --- | --- | --- | | Prozent auf Kollektion oder Bestellung | Ja | Nein | Automatischer Rabatt | | Kaufe 2, erhalte 1 gratis | Ja | Nein | Kaufe-X-erhalte-Y | | Kostenloser Versand ab Betrag | Ja | Nein | Versandrabatt | | Staffel mit mehreren Mengenstufen | Nur eingeschränkt | Ja | Product Discount Function | | Preis nach Kunden-Tag oder Metafeld | Nein | Ja | Function mit Kundenbedingung | | Bundle zum Festpreis aus freier Auswahl | Nein | Ja | Cart Transform plus Rabatt | | Rabatt nur für Lieferland oder Zahlungsart | Nein | Ja | Function mit Adress- oder Zahlungsbedingung | | Zahlungsarten je nach Warenkorb sortieren | Nein | Ja | Payment Customization Function | ## Vier Rabattfälle, die Functions brauchen Die folgenden vier Fälle sind die, die in Anfragen aus dem deutschsprachigen Raum am häufigsten vorkommen. Sie zeigen, wie eine Function aufgebaut ist, ohne dass Sie Code lesen müssen. **Staffelrabatte nach Menge.** Ab 5 Stück 5 Prozent, ab 10 Stück 10 Prozent, ab 25 Stück 15 Prozent, pro Produkt oder über die Kollektion gerechnet. Die Function liest die Stufen aus einem Metafeld, zählt die Menge im Warenkorb und gibt den passenden Prozentsatz zurück. Ihr Team ändert Stufen in der App, nicht im Code. Der englische Artikel [Shopify tiered discounts](/shopify-tiered-discounts) zeigt Varianten. **Kundenspezifische Preise für B2B.** Kunden mit dem Tag "haendler" oder einem Metafeld "preisgruppe" bekommen 20 Prozent auf alles oder feste Preise pro Kollektion. Die Function prüft den eingeloggten Kunden und wendet die Regel an. Voraussetzung ist, dass der Kunde im Checkout erkannt wird, also ein Kundenkonto hat. Für Plus-Händler mit B2B-Funktionen gibt es teils native Wege; für alle anderen ist das eine Function. **Bundles zum Festpreis.** Drei beliebige T-Shirts für 60 Euro. Cart Transform fasst die drei Artikel zu einem Bundle zusammen, ein Rabatt setzt den Preis. Bestand und Fulfillment bleiben auf Ebene der Einzelartikel. Ohne Function braucht das ein Bundle-Produkt mit eigener Variante pro Kombination, was bei freier Auswahl nicht skaliert. **Regeln nach Lieferland oder Zahlungsart.** Kostenloser Versand nur nach Deutschland, ein Rabatt für Vorkasse, TWINT für Schweizer Kunden an erster Stelle. Diese Fälle laufen über Versand- und Zahlungs-Functions, die Adresse oder Zahlungsart als Eingabe lesen. Für Händler mit Kunden in Deutschland, Österreich und der Schweiz ist das der Fall, der am häufigsten unterschätzt wird. ## Was eine Function kostet und was danach kommt Eine Function ist ein überschaubares Stück Software, aber sie ist Software, und das bringt Kosten für Bau, Oberfläche und Pflege. Bei ByteInfy liegt eine einzelne Function oder Checkout-Erweiterung zwischen 1.500 $ und 3.000 $, wie auf der Seite [Checkout Extensions und Functions](https://byteinfy.com/services/shopify-checkout-extensions) beschrieben. Mehrere Functions, etwa Rabatt, Versandregel und Zahlungsreihenfolge, werden zusammen angeboten. Andere Agenturen kalkulieren anders; was in jedem Angebot stehen sollte, listet der Artikel [Shopify Agentur Kosten 2027](/de/shopify-agentur-kosten-2027-was-ein-shop-wirklich). Der Posten, der in Angeboten oft fehlt, ist die Konfigurationsoberfläche. Eine Function ohne Oberfläche bedeutet, dass jede Änderung an Stufen oder Prozentsätzen einen Entwickler braucht. Eine Function mit Oberfläche in der App bedeutet, dass Ihr Marketing die Regeln vor dem nächsten Sale selbst anpasst. Der Unterschied im Preis ist real, aber die zweite Variante ist über zwei Jahre gerechnet fast immer günstiger. Der dritte Posten ist Pflege. Shopify stellt API-Versionen nach festem Zeitplan ab, und eine Function, die gegen eine abgekündigte Version gebaut ist, muss nachgezogen werden. Wer eine Function beauftragt, sollte klären, wer das übernimmt und was es kostet. Ein Wartungsvertrag ab 500 $ pro Monat deckt das bei ByteInfy ab; die Alternative ist, es pro Vorfall zu beauftragen. Ob Sie für eine Custom App mit Functions auf Ihrem Plan bleiben können oder Plus brauchen, hängt vom Plan und vom Function-Typ ab und sollte vor dem Angebot geprüft werden. Zum Zeitpunkt der Erstellung beginnt Shopify Plus bei etwa 2.300 USD pro Monat bei dreijähriger Laufzeit, und eine Rabattregel allein rechtfertigt diesen Sprung selten. ## Die Grenzen, die Sie vorher kennen sollten Functions sind bewusst eng gebaut, und wer die Grenzen kennt, plant keine Regel, die daran scheitert. Eine Function hat keinen Netzwerkzugriff. Sie kann nicht während des Checkouts Ihr ERP nach dem aktuellen Kundenpreis fragen. Alles, was sie wissen muss, kommt aus Warenkorb, Kunde, Adresse und Metafeldern. Kundenpreise aus dem ERP müssen deshalb vorher in Metafelder synchronisiert werden, was eine Integration ist, keine Function. Eine Function hat Grenzen bei Laufzeit und Eingabegröße. Bei sehr großen Warenkörben oder sehr vielen Regeln kann eine ungeschickt gebaute Function an diese Grenzen stoßen. Gute Agenturen testen mit realistischen Warenkörben, nicht mit drei Artikeln. Eine Function ändert nicht, was der Kunde im Warenkorb auf der Shopseite sieht, sondern was im Checkout gilt. Wer Staffelpreise schon auf der Produktseite anzeigen will, braucht zusätzlich Theme-Code, der dieselben Regeln liest. Das ist ein häufiger Grund für Verwirrung: Der Rabatt greift, aber die Produktseite zeigt noch den alten Preis. Der englische Artikel [Shopify Functions limitations](/shopify-functions-limitations) listet die technischen Grenzen vollständig. ## Von Scripts zu Functions: ein geordneter Ablauf Wer noch Script-Logik dokumentiert hat oder eine Function neu plant, sollte in derselben Reihenfolge vorgehen: erst verstehen, dann reduzieren, dann bauen, dann testen. ## Migrationsplan für Rabattlogik - Jede bestehende Regel in einfacher Sprache aufschreiben, mit drei Beispielwarenkörben und dem erwarteten Ergebnis - Prüfen, welche Regeln Shopify inzwischen nativ abbildet, und diese als automatische Rabatte anlegen - Die verbleibenden Regeln nach Function-Typ sortieren (Rabatt, Versand, Zahlung, Cart Transform) - Entscheiden, welche Werte Ihr Team selbst ändern können muss, und diese als Metafelder mit Oberfläche planen - Kombinationsregeln festlegen, damit sich Function-Rabatte und native Rabatte nicht ungewollt addieren - Jede Function im Checkout-Preview mit den Beispielwarenkörben testen, auch mit Shop Pay und Apple Pay - Theme-Anzeige prüfen, wenn Staffelpreise schon auf der Produktseite sichtbar sein sollen - Klären, wer die Function bei API-Umstellungen nachzieht und zu welchem Preis Der erste Punkt ist der wichtigste und wird am häufigsten übersprungen. Eine Regel, die niemand in einfacher Sprache beschreiben kann, wird auch als Function nicht das tun, was erwartet wird. Der englische Artikel [Shopify Scripts to Functions](/shopify-scripts-to-functions) beschreibt die Migration Schritt für Schritt, inklusive der Fälle, in denen ein Script durch native Rabatte ersetzt werden konnte. ## Function, App oder nichts: die Entscheidung Am Ende stehen drei Wege, und der günstigste ist oft der richtige. **Nichts bauen**, wenn native Rabatte reichen. Prüfen Sie das ehrlich, auch wenn die Regel ursprünglich als Script lief; Shopify hat die nativen Rabatte seit der Script-Ära erweitert. **Eine App aus dem App Store**, wenn Ihr Fall verbreitet ist und eine App ihn mit eigener Oberfläche und Wartung abdeckt. Staffelrabatte und Bundles sind solche Fälle. Die Monatsgebühr kauft Ihnen Pflege, die Sie sonst selbst tragen. Der englische Artikel [Shopify bundles vs volume discounts](/shopify-bundles-vs-volume-discounts) vergleicht die Ansätze. **Eine eigene Function**, wenn Ihre Regel spezifisch ist, wenn Apps sie nicht abbilden oder wenn Sie die Abhängigkeit von einem App-Anbieter vermeiden wollen. Dann gehört eine Oberfläche dazu, und ein Plan für die Pflege. Eine Agentur, die alle drei Wege nennt und den günstigsten empfiehlt, arbeitet in Ihrem Interesse. Eine Agentur, die bei jeder Rabattanfrage eine Function anbietet, verkauft Umfang. Wie Sie das im Vorfeld erkennen, steht im Beitrag [Shopify Agentur auswählen: 12 Fragen vor dem Vertrag](/de/shopify-agentur-auswahlen-12-fragen-vor-dem-vertrag). **Sie haben eine Rabattregel, die Shopify nicht nativ kann?** ByteInfy schreibt die Regel mit Ihnen in einfacher Sprache auf, prüft, ob ein nativer Rabatt oder eine App reicht, und baut die Function mit Oberfläche, wenn sie wirklich nötig ist. [Mit ByteInfy sprechen](https://byteinfy.com/contact) ## FAQ ### Was ist der Unterschied zwischen Shopify Scripts und Shopify Functions? Scripts waren Ruby-Code, den Plus-Händler direkt im Script Editor pflegten und der Warenkorb, Versand und Zahlung im Checkout beeinflusste. ### Brauche ich Shopify Plus für Functions? Nicht grundsätzlich. Functions laufen auf allen Plänen, aber ob eine Function in einer Custom App für Ihren einzelnen Shop auf Ihrem Plan verfügbar ist, hängt vom Plan und vom Function-Typ ab. ### Welche Rabatte kann Shopify ohne Function? Prozent- oder Betragsrabatte auf Produkte, Kollektionen oder die Bestellung, Kaufe-X-erhalte-Y, kostenlosen Versand, Mindestbestellwerte und Kombinationsregeln zwischen Produkt-, Bestell- und Versandrabatten. ### Was kostet eine Shopify Function für Rabatte? Eine einzelne Function oder Checkout-Erweiterung liegt bei ByteInfy zwischen 1.500 $ und 3.000 $. Dazu kommt bei Bedarf eine Konfigurationsoberfläche in der App, damit Ihr Team Stufen und Prozentsätze ohne Entwickler ändern kann. ### Kann eine Function externe Daten abfragen? Nein. Eine Function hat keinen Netzwerkzugriff und muss innerhalb enger Zeit- und Grössengrenzen laufen. Alles, was sie wissen muss, kommt aus dem Warenkorb, dem Kunden und aus Metafeldern, die vorher gesetzt wurden. ### Wie migriere ich meine alten Scripts? Zuerst inventarisieren, was jedes Script tut, in einfacher Sprache und mit Beispielen. Dann prüfen, welche Regeln Shopify inzwischen nativ abdeckt, und nur den Rest als Functions nachbauen. ### Funktionieren Functions mit Shop Pay und Express-Checkouts? Ja, und das ist einer der Hauptgründe für Functions. --- --- title: "Turn Instagram Reels Into a Shoppable Shopify Feed" description: "The fastest route to a populated video feed is content you already made. Here is how to bring Reels onto a Shopify storefront without wrecking page speed or your rights position." author: "Aashish Kaushik" published: 2026-09-17T13:02:09.688Z updated: 2026-09-17T13:02:09.727Z url: https://blog.byteinfy.com/instagram-reels-to-shopify --- # Turn Instagram Reels Into a Shoppable Shopify Feed ## Key takeaways - Existing Reels are audience-tested content, which makes them a better starting library than anything shot specifically for the storefront. - Not every Reel transplants — feed content is made to stop a scroll, product-page content is made to resolve a doubt. - Rights are the step most stores skip: a creator agreeing to a social repost has not agreed to commercial storefront use. - Import once and the work is done; import badly and you have fifty untagged videos and no product links. Most stores adding video start by planning a shoot. That is the slow, expensive path to finding out whether video helps your catalogue at all. The fast path is content you already have. If you post to Instagram, you have a library of clips that were made for your products, watched by your actual audience, and already filtered by engagement — you know which ones people responded to. Bringing those onto the storefront is a day of work rather than a production budget. > **What this assumes** > > That you have an Instagram presence with product-relevant Reels. If you do not, the same mechanics apply to TikTok content, and the strategy question of whether video suits your catalogue is covered separately. ## Why existing content beats new production Three advantages, and the third is the one people miss. **It exists.** No brief, no shoot, no editing cycle. The gap between deciding to try video and having video live is days rather than months. **It is audience-tested.** You can see which clips people watched and responded to. That is genuine signal about what your customers want explained, and it is not available for content you have not published yet. **It looks native.** UGC and social-native video reads as real in a way studio production does not, and that credibility is much of why the format works. Content shot specifically to look like a Reel usually does not, and shoppers are better at detecting this than marketers expect. ## Not every Reel belongs on a product page The important caution. Feed content and product-page content have different jobs, and the best examples of each are rarely the same clip. A Reel in a feed is competing for attention against everything else in that feed. It front-loads a hook, moves fast, and often withholds information to keep someone watching. That is correct for the feed and wrong for a product page, where the shopper has already chosen to look at this product and wants a question answered. ## What transplants and what does not | Reel type | Product page | Homepage carousel | | --- | --- | --- | | Product demonstration or how-to | Excellent | Good | | Fit or scale on a real person | Excellent | Good | | Unboxing | Good | Good | | Trend or audio-led format | Poor | Fair | | Brand story or founder content | Poor | Good | | Pure entertainment | Poor | Poor | The practical rule: for product pages, choose clips that answer a question. For discovery placements — homepage carousels, collection pages — the feed-native content works fine, because the job there is genuinely to catch attention. ## Sort the rights out first This is the step that gets skipped, and it is the one with actual consequences. **Your own content, your own products, your own staff.** Generally fine, with one caveat: audio. Music available for use on Instagram is licensed for Instagram. Using the same track on your storefront is a different use with a different licence, and the safe move is to replace the audio or use clips that work muted — which most product video should anyway, since most views are silent. **Content featuring a customer or creator.** This needs explicit permission for commercial use on your storefront. A creator who agreed to a repost on Instagram has not agreed to appear as marketing on your product page indefinitely. Get it in writing, specify the storefront use and the duration, and keep the record. **Content someone else made about your product.** Common, valuable, and the highest-risk category. Enthusiasm about your product is not a licence, and neither is tagging your account. Ask directly, and be specific about where it will appear. ## Before importing anything - Confirm you have rights to the video for commercial storefront use - Check the audio separately — platform music licences rarely travel - Confirm anyone identifiable in the clip has agreed to this use - Record the permission somewhere you can find it in two years - Decide what happens if a creator later withdraws permission ## Getting them onto the storefront Two approaches, and only one is really viable. **Embedding the Instagram post** is superficially easiest. It is also the wrong answer: you get an embed rather than shoppable video, you load Instagram's script on your page, the layout is theirs rather than yours, and the whole thing disappears if the source post is deleted or the account goes private. **Importing the video file** and hosting it through a shoppable video app gives you a video you control, in your layout, with products attached and add-to-cart inside the player. This is what the format is for. When evaluating the import path specifically: - Is it a sync or a one-time upload? A sync keeps working; an upload means manual work forever. - Does product tagging survive import, or must every video be re-tagged by hand? Across fifty clips this is the difference between an afternoon and a fortnight. - What happens when a source post is deleted? Ideally nothing, because you hold the file. - Can you keep the original? Always keep unedited masters in your own storage. Every future migration problem becomes trivial if you have them. ## Do not let it cost you page speed Video is the heaviest asset you can put on a product page, and this is where video projects quietly fail — the store adds video, conversion does not move, and nobody connects it to product pages taking a second longer. The rule is that nothing heavy loads before a shopper indicates interest: - A lightweight poster image renders in place, with width and height set so the layout does not shift. - The player and video file load on interaction, not on page load. - Nothing video-related loads on pages that contain no video. - Autoplay, if used at all, is muted, short, and limited to one element per page. A store that gets this wrong pays twice — once in Core Web Vitals across every product page, and again because the slower page suppresses the conversions the video was meant to win. ## Editing a Reel for the storefront Most imported clips need small changes, and the changes are consistent enough to be worth naming. **Trim the hook.** A Reel opens with something designed to stop a scroll — a jump cut, a question, a bold claim. On a product page the shopper has already stopped, so that opening is three wasted seconds before the useful part starts. Cut to the substance. **Make it work muted.** Most storefront views are silent. If the clip depends on a voiceover, add captions or choose a different clip. This also sidesteps the audio licensing problem entirely. **Cut it shorter than feels right.** Product-page clips are trending under 30 seconds, and a shopper resolving one doubt does not need 60. Most Reels lose nothing by being halved. **Remove platform furniture.** Text overlays positioned for Instagram's interface sit awkwardly in a different player, and captions referencing "link in bio" or "follow for more" are actively confusing on a product page where the product is right there. **Check the first frame.** It becomes your poster image, and an autoplay-optimised Reel frequently starts on a blurred motion frame that looks broken as a still. Choose the poster deliberately rather than accepting the default. > **One library, two edits** > > Resist maintaining a single version for both social and storefront. The edits that make a clip work in a feed are the ones that make it worse on a product page. Keep the master, export twice, and treat them as different deliverables from the same shoot. ## A first pass that tells you something 1. Pick five to ten products where images genuinely leave a question open. Skip products where they do not. 2. Find the Reels that answer those questions. Use your own engagement data to choose between candidates. 3. Clear the rights, including audio. 4. Import, tag products, and place them in or near the image gallery rather than far down the page. 5. Measure Core Web Vitals before and after on those templates. 6. Compare conversion against matched products without video, over weeks rather than days. Step six is what separates a test from a rollout. Adding video everywhere at once feels decisive and leaves you unable to attribute anything, because you changed fifty pages simultaneously and every other variable moved with them. A matched control group is the only thing that turns "we added video and revenue went up" into a statement you can act on next quarter. > **Mobile vertical is the default, not an option** > > Most of this traffic is mobile, and Reels are vertical. A landscape crop in a vertical viewport wastes most of the screen and immediately reads as repurposed desktop content — which is exactly the impression social-native video exists to avoid. For the wider question of whether video suits your catalogue, and the format-by-format placement guide, see [video commerce and UGC](/category/video-commerce-ugc). App selection is covered in [Shopify apps](/category/shopify-apps), and the page-weight picture in [storefront and design](/category/storefront-design). **Your Reels, shoppable, without the page-speed cost** SwipeReel imports Instagram Reels and TikTok UGC in one click and turns them into shoppable carousels, stories, grids and popups with tap-to-buy inside the video. [See SwipeReel on the Shopify App Store](https://apps.shopify.com/swipereel) ## FAQ ### Can I legally use my own Instagram Reels on my Shopify store? Content you created yourself, featuring people who consented, is generally straightforward to reuse. ### How do I add Instagram Reels to a Shopify product page? Practically, through an app that imports the video and lets you attach products to it. ### Will adding Reels slow my store down? It depends entirely on implementation. Video assets loaded on page load will slow it substantially. Video behind a poster image that loads only on interaction costs very little. ### What makes a Reel work on a product page rather than in a feed? A feed Reel has to stop a scroll, so it front-loads a hook. ### How many videos do I need to start? Fewer than you think. Five to ten good clips attached to your best-selling products will tell you whether the format works for your catalogue. --- --- title: "WooCommerce to Shopify Migration: What Actually Breaks" description: "Moving products from WooCommerce to Shopify is the easy part, and it is the part every migration guide covers. The parts that actually go wrong are URLs, variants, customer passwords and the redirect map. This is a migration plan built around the failure points rather than the data export." author: "Aashish Kaushik" published: 2026-09-17T09:01:18.149Z updated: 2026-09-17T09:01:18.339Z url: https://blog.byteinfy.com/woocommerce-to-shopify-migration --- # WooCommerce to Shopify Migration: What Actually Breaks ## Key takeaways - Product data migrates reliably. URLs, variant structures, customer passwords and order history are where migrations actually fail. - The redirect map is the single highest-stakes deliverable. WooCommerce and Shopify use different URL structures, so every indexed URL needs an explicit destination. - Customer passwords cannot be migrated. Every customer will need to reset, and how you communicate that decides whether you keep them. - Expect a temporary ranking dip even on a well-executed migration. Plan for recovery over weeks, and do not migrate in your peak season. - Migrate to a store that is ready, not to a placeholder. A rushed cutover means fixing a live store under traffic. Most guides to WooCommerce to Shopify migration are guides to exporting products, which is the part that reliably works. Products, images, descriptions and prices move across with well-established tooling and rarely cause real trouble. The things that go wrong are URLs, variant structures, customer accounts and redirects. Those are also the things that, when they go wrong, cost you traffic you had already earned. This is a migration plan organised around the failure points. ## What moves cleanly Set expectations correctly on the easy parts, because they are genuinely easy. **Products.** Titles, descriptions, images, prices, SKUs, inventory. Established migration tooling handles this, and for a standard catalogue it is close to routine. **Collections.** WooCommerce categories map onto Shopify collections conceptually. The mapping needs review, because Shopify distinguishes manual and automated collections and your category logic may fit one better than the other, but the data moves. **Customers.** Names, email addresses, addresses. With one enormous exception, covered below. **Content pages.** About, contact, policies. Straightforward, though the URLs will change. ## What actually breaks ### URLs, and therefore SEO This is the big one. WooCommerce and Shopify construct URLs differently, and Shopify's structure is not fully configurable. Product and category URLs will change, which means **every indexed URL on your site needs an explicit redirect to its new destination.** This is the highest-stakes deliverable in the entire migration, and it is the one most often done partially. The failure mode is not a missing redirect returning a 404, which is at least visible. It is the lazy catch-all: redirecting everything that does not match a rule to the home page. > A redirect from a product page to the home page is read by Google as a soft 404. It does not pass the page's ranking signals, it just quietly discards them. A URL that 404s honestly is treated better than one that redirects somewhere irrelevant. If you take one thing from this page: map every URL individually, and never let unmatched URLs fall through to the home page. Build the redirect map from data, not from assumption: 1. Export every indexed URL. Use Search Console's page report and your existing sitemap, not a crawl alone, because a crawl misses URLs that are indexed but no longer linked. 2. Map each one to its new destination explicitly. 3. Include category pages, tag archives, paginated URLs and any content pages. 4. Test the map before cutover and again immediately after. 5. Re-check a sample a week later, because edge cases surface under real traffic. ### Variant structures WooCommerce attributes and variations do not map perfectly onto Shopify's option model. Shopify has a defined limit on options per product, and stores that used WooCommerce's flexibility to model complex products often need genuine rework rather than a data transform. Find this out during planning, not during migration. Audit your most complex products first, not your simplest, because the simple ones tell you nothing about whether the migration is hard. ### Customer passwords Passwords are stored hashed. They cannot be migrated, from any platform to any other. Every customer will need to reset their password. This is not a technical problem, it is a communications one, and it is where migrations lose customers who were otherwise perfectly happy. Plan the email. Send it at cutover, explain plainly why it is needed, and make the reset path obvious. A returning customer who hits a login failure with no explanation frequently does not come back for a second attempt. ### Order history Importable, but decide whether you want it. Historical orders in Shopify are records rather than live orders, and importing large volumes has implications for reporting and for how your numbers look afterwards. Some merchants import everything, some import a recent window, some keep a read-only archive of the old store. All three are defensible; drifting into it without deciding is not. - Every indexed URL exported and mapped to a specific destination - No catch-all redirect to the home page - Most complex products audited for variant structure before cutover - Password reset email written and scheduled - Order history decision made explicitly - Integrations inventoried: payment, shipping, ERP, email, reviews - A rollback plan for the first 48 hours ## Sequencing the migration Order matters more than speed. **Build first, migrate second.** Get the Shopify store into a state you would be happy to launch before moving data into it. Migrating into a half-built store means finishing the build on a live site under real traffic. **Migrate data to a password-protected store.** Shopify stores can be locked while you work. Use that. Import, check, fix, re-import. **Test on your worst products.** The complex ones with many variants, the ones with unusual shipping rules, the bundles. If those work, the rest will. **Prepare redirects before cutover, not after.** The window between DNS changing and redirects going live is a window where Google finds 404s. **Cut over at a genuinely quiet time.** Not your peak season, not the week before a campaign. You want attention available for the two weeks afterwards. **Watch Search Console daily for a fortnight.** Specifically coverage errors and any spike in 404s. This is when redirect gaps surface, and they are cheap to fix immediately and expensive to fix in three months. ## The ranking dip is normal Even a well-executed migration typically produces a temporary drop while Google recrawls, reprocesses redirects and re-establishes which URL is which. Recovery usually happens over weeks rather than days. Knowing this in advance matters, because the panic response is to start changing things during the dip, which makes the cause of any subsequent movement impossible to read. Give a clean migration time before intervening. What is *not* normal is a dip that does not recover, and the cause is almost always the redirect map: missing entries, or entries pointing at the home page instead of the matching page. > Do not redesign and migrate simultaneously if you can avoid it. Two large changes at once means that when traffic or conversion moves, you cannot attribute it. Migrate, stabilise for a few weeks, then redesign. The exception is when the existing design is precisely why you are moving. ## The integrations audit nobody does early enough Products and URLs get attention. Integrations get discovered mid-migration, and that is where timelines slip. Before you start, list every system that currently touches your WooCommerce store and decide what happens to each: **Payments.** Which gateway, and is it available on Shopify in your country? Saved payment methods and stored cards do not transfer, and for subscription businesses this is a substantial piece of work rather than a detail. **Shipping and fulfilment.** Carrier accounts, rate rules, any 3PL connection. Shopify's shipping model differs from WooCommerce plugins and complex rate logic often needs rebuilding rather than porting. **Subscriptions.** If you run recurring orders, this is the single hardest part of any WooCommerce migration. Subscriptions carry billing relationships and payment tokens that generally cannot move. Scope this first, because it may change the whole plan. **Accounting and ERP.** Whatever syncs orders to your finance system needs an equivalent, and the field mapping is rarely identical. **Email and marketing.** Lists can move; automation logic and any behavioural triggers tied to WooCommerce events need rebuilding. **Reviews.** Product reviews are valuable content and do not automatically follow. Most review platforms have an import path, but it needs doing deliberately and it is easy to lose years of reviews by forgetting. > Subscriptions are the migration killer. If you have an active subscriber base on WooCommerce, get a clear answer on how their billing relationships will be handled before committing to a date. It is far better to discover the constraint during planning than to be halfway through a cutover with subscribers who cannot be billed. ## What to do in the first fortnight after cutover The migration is not finished at launch. The two weeks afterwards decide how much of your traffic you keep. **Daily:** check Search Console coverage for new 404s and crawl errors. Every one is a redirect gap and each is cheap to fix now. **Daily for the first three days:** place a real test order end to end, with a real payment method. Checkout issues are the most expensive category of post-migration bug and the least likely to be reported by customers, who simply leave. **Watch your analytics for traffic sources that vanished.** A referral or email source dropping to zero usually means a link pattern nobody mapped. **Keep the old site accessible but not indexable** for a short window if you can, so you have a reference while checking content came across correctly. **Resubmit your sitemap** and let Google find the new structure rather than waiting. ## What to ask an agency quoting the migration Four questions separate a migration quote that includes the hard parts from one that quotes the product export. 1. "How do you build the redirect map, and does it include category and paginated URLs?" If the answer is a plugin with no mention of Search Console data, the map will be incomplete. 2. "What happens to URLs with no obvious match?" The right answer involves a judgement call per URL, or an honest 404. The wrong answer is "they go to the home page." 3. "How are you handling customer password resets?" A migration plan that has not thought about this has not thought about customers. 4. "Show me the rollback plan." For the first 48 hours there should be one. If you are still choosing who does the work, [what to look for in a Shopify development agency](/hire-shopify-development-agency) covers selection, and [Shopify theme speed](/shopify-theme-speed) is worth reading before the build, because migration is the cheapest possible moment to get performance right. **Migrating from WooCommerce and want the redirects done properly?** ByteInfy handles WooCommerce to Shopify migrations with a URL-level redirect map built from Search Console data, not a plugin default. [Start a project](https://byteinfy.com/#contact) ## The short version Product data is the easy part. Budget your attention for URLs, variants, passwords and redirects. Build the store before you migrate into it. Map every indexed URL individually and never let unmatched URLs fall to the home page. Write the password reset email before cutover. Migrate outside your peak season and watch Search Console daily for two weeks afterwards. Expect a dip, plan for recovery in weeks, and resist changing things while it recovers. A migration done this way keeps the traffic you spent years earning. A migration done around a product export usually does not. After the move, [a monthly retainer](/shopify-retainer-guide) is a reasonable way to catch the long tail of issues that surface in the months following a migration. ## FAQ ### How long does a WooCommerce to Shopify migration take? For a straightforward catalogue, a few weeks including build, data migration, redirect mapping and testing. Complexity comes from custom post types, unusual variant structures, subscriptions and integrations rather than from raw product count. ### Will I lose my Google rankings when migrating to Shopify? Not permanently, if the redirects are done properly. Expect a temporary dip while Google reprocesses the URLs. Rankings are lost when redirects are missing, point to the wrong pages, or send everything to the home page. ### Can I migrate my customers' passwords? No. Passwords are stored hashed and cannot be transferred between platforms. Customers keep their accounts and order history if you migrate those, but everyone has to reset their password, so plan the email that tells them. ### Does order history transfer to Shopify? It can be imported, but it is a genuine decision rather than an automatic yes. Historical orders in Shopify are records, not live orders, and importing them has implications for reporting. Decide whether you need them or whether an archive is sufficient. ### What breaks most often in a WooCommerce migration? URL structure, because the two platforms build product and category URLs differently. Second is variant structure, because WooCommerce attributes do not always map onto Shopify's option model without rework. ### Should I redesign at the same time as migrating? Usually not simultaneously. If rankings or conversion move afterwards, you will not know which change caused it. Migrate first, stabilise, then redesign, unless the existing design is the reason you are moving. ### When is the worst time to migrate? Your peak trading season. Also avoid migrating immediately before a major campaign, because the first fortnight after cutover is when unexpected issues surface and you want attention available. --- --- title: "Shopify in der Schweiz: TWINT, CHF, MwSt und Agenturwahl" description: "Ein Shopify-Shop für die Schweiz braucht Franken als Shopwährung, TWINT im Checkout, korrekte MwSt und einen Plan für Zoll und Versand. Was zu tun ist und woran Sie eine Agentur erkennen, die das schon gemacht hat." author: "Aashish Kaushik" published: 2026-09-17T05:01:00.719Z updated: 2026-09-17T05:01:00.726Z url: https://blog.byteinfy.com/shopify-schweiz-twint-chf-mwst-agenturwahl --- # Shopify in der Schweiz: TWINT, CHF, MwSt und Agenturwahl ## Key takeaways - CHF gehört als Shopwährung in die Grundeinstellung; Euro für Deutschland und Österreich kommt über Shopify Markets dazu, nicht umgekehrt. - TWINT ist über Shopify Payments in der Schweiz verfügbar und gehört neben Kauf auf Rechnung und Karte in jeden Schweizer Checkout. - Die Schweizer MwSt, die Versandhandelsregelung für ausländische Händler und die Einfuhr aus der EU sind Steuer- und Zollthemen, die vor dem Launch geklärt sein müssen. - Eine Agentur für den Schweizer Markt erkennen Sie daran, dass sie nach Kanton, Sprachen, Zollabwicklung und Rappenrundung fragt, bevor sie ein Angebot schreibt. Ein Shopify-Shop für die Schweiz braucht vier Dinge, die ein deutscher Shop nicht braucht: Franken als Shopwährung, TWINT und Kauf auf Rechnung im Checkout, die Schweizer MwSt mit korrekter Preisanzeige und einen Plan für Zoll und Versand über die EU-Aussengrenze. Wer diese vier Punkte vor dem Launch löst, hat den Grossteil der Schweiz-spezifischen Arbeit hinter sich. Der Rest, also Sprachen, Datenschutz und Agenturwahl, folgt daraus. Dieser Artikel richtet sich an Schweizer Händler, die einen Shopify-Shop aufbauen, und an Händler aus Deutschland und Österreich, die in die Schweiz verkaufen wollen. Beide Gruppen stossen auf dieselben Themen, nur aus unterschiedlicher Richtung. Am Ende steht eine Liste mit Kriterien für die Agenturwahl, weil "Shopify Agentur Schweiz" eine Suchanfrage ist, die meist zu Agenturen mit Schweizer Adresse führt, aber nicht zu Agenturen mit Schweizer Erfahrung. > **Keine Steuer- oder Rechtsberatung** > > MwSt-Sätze, Registrierungspflichten und Zollregeln ändern sich. Die Angaben hier entsprechen dem Stand zum Zeitpunkt der Erstellung und ersetzen keine Beratung durch einen Treuhänder oder eine Anwaltskanzlei. ByteInfy ist eine Shopify-Agentur mit Sitz in Indien, die mit internationalen Händlern arbeitet; die technische Umsetzung ist unser Teil, die Steuerfrage gehört zu Ihrem Treuhänder. ## CHF als Shopwährung, Euro über Markets Die Shopwährung ist die wichtigste Einstellung, die Sie am Anfang treffen, weil sie sich später nicht mehr sauber ändern lässt. Die Shopwährung bestimmt, in welcher Währung Shopify Auszahlungen, Berichte, Rabatte und Geschenkgutscheine führt. Wenn die Schweiz Ihr Hauptmarkt ist, gehört CHF in diese Einstellung. Wer als Schweizer Händler den Shop in Euro aufsetzt, weil "die meisten Themes das so zeigen", rechnet danach jede Auszahlung und jeden Rabatt um. Für Deutschland und Österreich kommt Euro über Shopify Markets dazu. Shopify Markets deckt Mehrwährung und lokalisierte Domains oder Unterordner ab, mit eigenen Preisen pro Markt oder automatischer Umrechnung mit Aufrundung. Für Händler, die in beide Richtungen verkaufen, ist das der Weg, der ohne zweiten Shop auskommt. Die SEO-Seite von Markets, also hreflang und Domain-Entscheidung, behandelt die [Shopify SEO Checkliste](/de/shopify-seo-optimierung-checkliste-mit-25-punkten). Ein Detail, das häufig vergessen wird: die Rappenrundung. In der Schweiz werden Barzahlungen auf fünf Rappen gerundet, und viele Händler runden auch Onlinepreise auf 0.05 oder 0.00, weil Preise wie 29.99 CHF fremd wirken. Shopify Markets erlaubt Rundungsregeln pro Markt; stellen Sie sie ein, bevor Sie Preise pflegen, sonst rechnet der Shop "29.99" und der Kunde sieht "29.99" statt "30.00". Für deutsche Händler gilt dasselbe umgekehrt. Der Shop bleibt in Euro, die Schweiz wird ein Markt mit CHF-Preisen. Ob Sie feste CHF-Preise oder Umrechnung verwenden, hängt davon ab, wie stark der Kurs schwankt und ob Ihre Marge das trägt. ## TWINT, Rechnung und die Zahlungsarten, die Schweizer erwarten Ein Schweizer Checkout ohne TWINT und ohne Kauf auf Rechnung verliert Kunden, die sonst gekauft hätten. TWINT ist über Shopify Payments in der Schweiz verfügbar. Sobald Shopify Payments für einen Schweizer Shop aktiviert ist, erscheint TWINT als Zahlungsart im Checkout, ohne separate App und ohne eigenen Vertrag mit TWINT. Der grösste Teil der TWINT-Zahlungen findet auf dem Smartphone statt, deshalb gehört ein Testkauf auf dem Handy zu jeder Abnahme. Kauf auf Rechnung ist in der Schweiz eine der etablierten Zahlungsarten, besonders bei höheren Warenkörben und bei älteren Zielgruppen. Shopify bietet das nicht nativ an; Sie brauchen einen Anbieter, der das Risiko übernimmt und als Zahlungsart im Checkout erscheint. Prüfen Sie, welche Anbieter in der Schweiz aktiv sind, welche Gebühren sie berechnen und wie sie mit Ihrer Buchhaltung zusammenarbeiten. Karten (Visa, Mastercard, PostFinance-Karten) und Apple Pay oder Google Pay decken den Rest ab. Für Kunden aus Deutschland und Österreich kommen Klarna, PayPal und SEPA-Lastschrift in Frage, je nachdem, was Shopify Payments in Ihrem Setup anbietet. ## Zahlungsarten für einen Schweizer Shopify-Checkout | Zahlungsart | Verfügbar über | Wichtig für | | --- | --- | --- | | TWINT | Shopify Payments (Schweiz) | Mobile Käufer, kleine bis mittlere Warenkörbe | | Kauf auf Rechnung | Drittanbieter mit Risikoübernahme | Höhere Warenkörbe, B2B, ältere Zielgruppen | | Kreditkarte, PostFinance | Shopify Payments | Standard, alle Zielgruppen | | Apple Pay, Google Pay | Shopify Payments | Mobile Käufer, schneller Checkout | | Klarna, PayPal | Shopify Payments oder Drittanbieter | Kunden in Deutschland und Österreich | | Vorkasse, Banküberweisung | Manuelle Zahlungsart in Shopify | B2B, Grossaufträge | Die Reihenfolge der Zahlungsarten im Checkout lässt sich mit Shopify Functions steuern, etwa TWINT für Schweizer Kunden zuoberst und Klarna für deutsche Kunden. Solche Regeln laufen als Payment Customization Function; die technische Seite beschreibt der englische Artikel [Shopify checkout extensibility](/shopify-checkout-extensibility). ## MwSt: Sätze, Preisanzeige und die Versandhandelsregelung Die Schweizer MwSt ist niedriger als in der EU, aber die Regeln für ausländische Händler sind der Punkt, an dem Projekte ins Stocken geraten. Zum Zeitpunkt der Erstellung liegt der Normalsatz bei 8,1 Prozent, der reduzierte Satz bei 2,6 Prozent für Lebensmittel, Bücher, Medikamente und einige weitere Waren. Shopify berechnet die Steuer nach Lieferland, wenn Sie die Steuereinstellungen für die Schweiz aktiviert und die Sätze geprüft haben. Preise müssen in der Schweiz inklusive MwSt angezeigt werden; die Einstellung "Steuern in Preisen enthalten" gehört deshalb eingeschaltet. Für Schweizer Händler, die nach Deutschland und Österreich verkaufen, gilt die EU-Seite: Ab bestimmten Schwellen wird die MwSt des Ziellandes fällig, und die Abwicklung läuft über das OSS-Verfahren oder eine Registrierung. Das ist ein Thema für den Treuhänder, aber die technische Voraussetzung, nämlich Steuern pro Markt in Shopify, muss die Agentur einrichten. Für deutsche und österreichische Händler, die in die Schweiz verkaufen, ist die Versandhandelsregelung entscheidend: Wer mit Kleinsendungen in die Schweiz einen Jahresumsatz von 100.000 Franken überschreitet, wird in der Schweiz mehrwertsteuerpflichtig und muss sich registrieren. Darunter zahlt der Kunde Einfuhrsteuer und Zollgebühren bei Zustellung. Das führt zu Rücksendungen und schlechten Bewertungen, weil der Kunde den Betrag nicht erwartet hat. Viele Händler entscheiden sich deshalb bewusst für Registrierung und Lieferung verzollt, auch unter der Schwelle. ## Versand und Zoll: Post, Einfuhr und DDP Die Schweiz ist kein EU-Mitglied, und jede Sendung über die Grenze ist eine Zollsendung. Das ist der Punkt, der Händler aus Deutschland und Österreich am häufigsten überrascht. Für Schweizer Händler mit Lager in der Schweiz ist der Inlandsversand über die Post unkompliziert. Die Post bietet Economy- und Priority-Versand, Abholung und Anbindungen an Shopify über Versand-Apps. Für den Versand nach Deutschland und Österreich wird jede Sendung zur Ausfuhr, mit Zollinhaltserklärung und Einfuhrumsatzsteuer im Zielland. Für Händler aus der EU, die in die Schweiz liefern, gibt es zwei Modelle. Bei DAP (unverzollt) zahlt der Kunde Zoll, Einfuhrsteuer und die Gebühr des Zustellers bei Empfang. Bei DDP (verzollt) übernehmen Sie das und rechnen es in den Preis ein. DDP kostet mehr Aufwand in der Abwicklung, DAP kostet Kunden. DHL, die Post und spezialisierte Dienstleister bieten DDP-Lösungen an; in Shopify brauchen Sie dafür korrekte HS-Codes und Herkunftsländer an jedem Produkt, was bei grossen Katalogen ein eigenes Datenprojekt ist. Rücksendungen aus der Schweiz in die EU sind ebenfalls Zollvorgänge. Wer im grossen Stil in die Schweiz verkauft, arbeitet häufig mit einer Retourenadresse in der Schweiz oder einem Dienstleister, der Retouren sammelt und gebündelt zurückführt. ## Sprachen: Deutsch zuerst, dann messen Die Schweiz hat vier Landessprachen, und drei davon sind für Onlinehandel relevant. Die Reihenfolge, in der Sie sie angehen, sollte der Nachfrage folgen. Die Deutschschweiz ist der grösste Teil des Marktes. Ein Shop auf Deutsch deckt ihn ab, mit einer Besonderheit: Schweizer Hochdeutsch verwendet "ss" statt "ß" und einige eigene Begriffe wie "Velo", "Natel" oder "parkieren". Ein Shop, der für Deutschland geschrieben wurde, wirkt in der Schweiz lesbar, aber fremd. Wer die Schweiz als Hauptmarkt hat, schreibt Kollektionstexte und Produktseiten in Schweizer Schreibweise. Französisch für die Romandie und Italienisch für das Tessin sind eigene Märkte mit eigener Suche. Shopify unterstützt mehrere Sprachen über Markets und Übersetzungs-Apps, mit eigenen URLs pro Sprache und automatischem hreflang. Übersetzen Sie zuerst Kollektionen und die meistverkauften Produkte, nicht die Startseite und die Über-uns-Seite. Die Search Console zeigt Ihnen nach einigen Wochen, ob Suchanfragen aus der Romandie ankommen und ob sich die Übersetzung weiterer Seiten lohnt. ## Datenschutz und Impressum in der Schweiz Schweizer Shops unterliegen dem revidierten Datenschutzgesetz, und sobald EU-Kunden dazukommen, zusätzlich der DSGVO. Das revidierte Schweizer DSG verlangt eine Datenschutzerklärung, die Zweck, Empfänger und Übermittlung ins Ausland transparent macht. Eine Cookie-Einwilligung im EU-Stil ist nach Schweizer Recht nicht in derselben Form vorgeschrieben, wird aber von den meisten Schweizer Shops eingesetzt, weil Kunden aus Deutschland und Österreich ohnehin darunter fallen und weil Tracking-Tools eine Einwilligung voraussetzen. Shopify bringt eine Cookie-Einwilligung in den Einstellungen mit; Apps erweitern sie um Kategorien und Protokollierung. Für die Anbieterkennzeichnung gilt in der Schweiz das Lauterkeitsrecht: Identität und Kontaktadresse müssen im Shop klar erkennbar sein. Wer nach Deutschland verkauft, braucht zusätzlich ein Impressum nach deutschen Anforderungen. Was dort im Detail verlangt wird, steht im Artikel [Shopify rechtssicher in Deutschland](/de/shopify-rechtssicher-deutschland-impressum-dsgvo-button). ## Woran Sie eine Agentur für den Schweizer Markt erkennen Eine Schweizer Adresse ist kein Beleg für Schweizer Erfahrung, und eine ausländische Adresse ist kein Ausschlusskriterium. Was zählt, sind die Fragen, die eine Agentur im ersten Gespräch stellt. ## Fragen, die eine erfahrene Agentur von sich aus stellt - Ist die Schweiz der Hauptmarkt oder ein Zusatzmarkt, und welche Währung soll die Shopwährung sein - Soll TWINT über Shopify Payments laufen, und welcher Anbieter übernimmt Kauf auf Rechnung - Wie werden MwSt-Sätze pro Markt eingestellt, und ist die Versandhandelsregelung geklärt - Werden Sendungen in die EU oder aus der EU verzollt oder unverzollt geliefert, und sind HS-Codes an den Produkten gepflegt - Sollen Preise auf 0.05 gerundet werden, und gilt das pro Markt - Welche Sprachen brauchen eigene Kollektions- und Produkttexte - Welche Datenschutzerklärung und welche Cookie-Einwilligung passen zu Schweizer und EU-Kunden - Welche Versand-App bindet die Post an, und wie werden Retouren aus dem Ausland abgewickelt Eine Agentur, die diese Fragen stellt, hat die Themen schon einmal gelöst. Eine Agentur, die ein Angebot schreibt, ohne nach Währung, Zoll und Rappenrundung zu fragen, wird diese Punkte während des Projekts als Änderungswünsche abrechnen. Die allgemeinen Kriterien für die Agenturwahl, von Referenzen über Code-Eigentum bis zur Wartung, listet der Beitrag [Shopify Agentur auswählen: 12 Fragen vor dem Vertrag](/de/shopify-agentur-auswahlen-12-fragen-vor-dem-vertrag). Beim Preis lohnt sich der Vergleich in derselben Währung. Angebote in CHF, EUR und USD schwanken gegeneinander; wer über mehrere Monate arbeitet, regelt das Kursrisiko vorab. Welche Kostenposten in einem Angebot stehen sollten, beschreibt der Artikel [Shopify Agentur Kosten 2027](/de/shopify-agentur-kosten-2027-was-ein-shop-wirklich). ## Was ein Schweiz-Setup technisch umfasst Aus den Punkten oben ergibt sich ein Setup, das sich als Projekt beschreiben lässt: Shopwährung und Markets, Shopify Payments mit TWINT, ein Anbieter für Kauf auf Rechnung, Steuern pro Markt, Versand-App mit Post-Anbindung, HS-Codes und Herkunftsländer am Katalog, Rundungsregeln, Datenschutz und Anbieterkennzeichnung, bei Bedarf Sprachen. ByteInfy setzt solche Konfigurationen als Teil der [Shop-Entwicklung](https://byteinfy.com/services/shopify-store-development) ab 2.000 $ um, Zahlungsregeln im Checkout als [Checkout-Extensions und Functions](https://byteinfy.com/services/shopify-checkout-extensions) ab 1.500 $. Die Steuer- und Zollentscheidungen bleiben bei Ihnen und Ihrem Treuhänder; die Agentur setzt um, was entschieden ist, und sagt Ihnen, was Shopify davon nativ kann und was eine App oder eine Function braucht. **Sie planen einen Shopify-Shop für die Schweiz?** ByteInfy richtet Währung, TWINT, Steuern pro Markt, Versand und Checkout-Regeln ein und sagt Ihnen vorab, welche Punkte Shopify nativ abdeckt und wo eine Function oder App nötig ist. [Mit ByteInfy sprechen](https://byteinfy.com/contact) ## FAQ ### Ist TWINT in Shopify verfügbar? Ja, TWINT ist über Shopify Payments in der Schweiz verfügbar und wird im Checkout als eigene Zahlungsart angezeigt, sobald Shopify Payments für einen Schweizer Shop aktiviert ist. ### Soll mein Shop in CHF oder in Euro laufen? Wenn die Schweiz Ihr Hauptmarkt ist, in Franken. Die Shopwährung bestimmt, in welcher Währung Auszahlungen, Berichte und Rabatte geführt werden, und sie lässt sich nach den ersten Bestellungen nicht mehr ohne Weiteres ändern. ### Wie hoch ist die MwSt in der Schweiz für Onlineshops? Zum Zeitpunkt der Erstellung liegt der Normalsatz bei 8,1 Prozent, der reduzierte Satz für Lebensmittel, Bücher und einige weitere Waren bei 2,6 Prozent. ### Muss ich als deutscher oder österreichischer Händler in der Schweiz MwSt zahlen? Möglicherweise. Die Versandhandelsregelung sieht vor, dass ausländische Händler ab einem Jahresumsatz von 100.000 Franken mit Kleinsendungen in die Schweiz mehrwertsteuerpflichtig werden und sich registrieren müssen. ### Brauche ich den Shop auf Französisch und Italienisch? Das hängt davon ab, wo Sie verkaufen wollen. Die Deutschschweiz ist der größte Teil des Marktes, aber die Romandie und das Tessin sind eigene Märkte mit eigener Suche. ### Gilt die DSGVO für Schweizer Shops? Für Schweizer Händler gilt zunächst das revidierte Schweizer Datenschutzgesetz. Sobald Sie an Kunden in der EU verkaufen oder deren Verhalten auswerten, kommt die DSGVO hinzu. ### Muss die Agentur in der Schweiz sitzen? Nein, aber sie muss den Markt kennen. Entscheidend ist, ob die Agentur TWINT, Kauf auf Rechnung, die Schweizer MwSt, die Post-Anbindung, Zollabwicklung und die Rappenrundung schon einmal in einem Shop umgesetzt hat. --- --- title: "Best Shopify Shoppable Video Apps in 2026" description: "Every shoppable video app shows you the same polished demo reel. The differences that matter are page weight, format coverage and what happens to your Core Web Vitals." author: "Aashish Kaushik" published: 2026-09-16T13:01:39.928Z updated: 2026-09-16T13:01:40.125Z url: https://blog.byteinfy.com/best-shopify-shoppable-video-apps --- # Best Shopify Shoppable Video Apps in 2026 ## Key takeaways - Video apps vary enormously in page-weight cost, and that cost is paid on every page view whether or not anyone presses play. - Format coverage matters more than feature count — carousels, stories, grids and popups each do a different job at a different point in the journey. - Importing existing Reels and TikTok content is the fastest path to a populated feed, so import tooling is worth more than production features for most stores. - Test on your own theme and measure Core Web Vitals before and after, because vendor demo stores are optimised in ways yours is not. Every app in this category demos the same way: a beautifully shot vertical reel, a tap, an add-to-cart, a conversion figure. The demos are indistinguishable, and they are all running on a vendor's own store, which is optimised in ways yours is not. The decisions that actually separate these apps are duller and more consequential. What does it cost your page weight. Which formats does it actually support. Can it get your existing content in without a week of manual work. This is a guide to comparing on those. > **A note on figures** > > Conversion lifts published in this category — 25–45% improvements, 30%+ on product pages — come from vendors measuring stores that chose to add video. That is a self-selecting group. The mechanism is real; treat any specific percentage as a ceiling rather than a forecast. ## Page weight is the first filter, not the last Video is the heaviest thing you can put on a product page, and a video app is the mechanism by which that weight arrives. This should be the first question you ask, not a footnote after the feature comparison. The distinction that matters is what loads before anyone presses play. A well-built app renders a lightweight poster image with correct dimensions, and fetches the player and the video only when a shopper interacts. A poorly-built one loads a player library, and sometimes the video itself, on every page view — including the vast majority where nobody watches anything. This compounds. The app is typically installed across every product page, so the cost is paid on your highest-traffic templates. A store can add video, see no conversion improvement, and never connect it to product pages becoming a second slower. ## Page-weight questions for any video vendor - Does the player load on page load, or on interaction? - Is the poster image served at the right dimensions with width and height set? - Does the app render through a theme app extension, or by injecting script into theme files? - What is added to pages that contain no video at all? - What remains in the theme after uninstalling? The last two are the ones vendors answer least comfortably. An app that injects script globally to support video on a few templates is charging every page for a feature most of them do not use. ## Format coverage, and why one format is not enough The formats do different jobs, and an app that supports only some of them constrains your strategy in ways that are not obvious at purchase. ## Format, placement and purpose | Format | Belongs on | The job | | --- | --- | --- | | Product page clip | Product page, near the gallery | Answers one doubt about this specific item | | Carousel | Homepage, collection pages | Discovery of products not yet considered | | Stories | Homepage, mobile-first placements | Browsable, familiar interaction pattern | | Grid or wall | Shop-the-look, lookbook pages | Browsing by aesthetic rather than category | | Popup or floating | Any page, triggered | Prompting and recovery; most intrusive | | Live or scheduled | Event pages | Real-time selling, a different discipline | Most stores need at least a product-page format and one discovery format, because those are the two distinct jobs. An app strong on carousels but weak on product-page embedding will look good on your homepage and do nothing for conversion where it matters. Worth checking specifically: whether the product-page format can be placed inside the image gallery rather than only as a separate section further down. Gallery placement gets substantially more views, and support for it varies. ## Import tooling is worth more than production features For most stores the content problem is larger than the technical one, and the fastest solution is content that already exists. The 2026 pattern is explicitly this — brands importing TikTok Shop and Instagram Reels content directly onto Shopify storefronts, keeping a consistent look across touchpoints while owning customer data the social platforms withhold ([Videowise, 8 Shoppable Video Trends for 2026](https://videowise.com/live-commerce/8-shoppable-video-trends-driving-ecommerce-revenue-in-2026), retrieved 2026-09-02). So evaluate import seriously: - Is it a sync or an upload? A one-time upload means manual work forever. A sync keeps working, but check what happens when a source post is deleted or set private. - Does it carry the product tagging across, or must every imported video be re-tagged by hand? On fifty videos this is the difference between an afternoon and a fortnight. - What happens when the platform API changes? It will. Ask how the vendor handled the last time. - Can it import creator content you did not post? And separately — have you secured the rights to do so? That last point is a genuine legal question that this category routinely glosses over. A creator agreeing to a repost on Instagram has not agreed to appear on your product page as commercial material. Get it in writing. ## What the demo will not show you Four things worth testing during a trial, none of which appear in a sales conversation. **Behaviour on your theme.** Vendor demos run on vendor themes. Video components are notoriously sensitive to container widths, aspect-ratio handling and CSS resets. Install on a duplicate of your live theme, not a fresh one. **Mobile vertical rendering.** Most of this traffic is mobile, and a landscape clip in a vertical viewport wastes most of the screen. Check what the app does with mixed aspect ratios, because your existing library will have both. **The empty state.** What renders on a product page with no video assigned? Ideally nothing, with no reserved space and no layout shift. Some apps leave a gap or a placeholder. **Analytics honesty.** Ask what counts as a view, and whether the reported "conversion from video" is a genuine attribution or simply any order from a session that loaded a page containing video. The second is close to meaningless and is more common than it should be. > **Test with your worst product page** > > Trials get run on a flagship product with three good videos. Test instead on a page with many variants, a long description and several other apps already active. That is where component conflicts and layout problems surface, and it is the page you will actually have to support. ## Free tiers and how they are metered Most apps in this category have a free tier, and they differ in what they limit. This matters because the limit determines when you are forced to upgrade, and that is not always the number you expected. Metering by **video count** suits a store with a small, curated library and unlimited traffic. Metering by **views or impressions** suits a store testing the concept, and becomes expensive precisely when the feature starts working. Metering by **format** — carousels free, product-page embeds paid — is the one to watch, because the paid format is usually the one that converts. Read the limit before designing your strategy around a tier. A store that builds its homepage around a free carousel and then discovers product-page embedding is the paid feature has done the work in the wrong order. ## Where video hosting lives, and why it matters An overlooked question: whose infrastructure serves the video file, and what happens to it if you leave. Most apps in this category host your video on their own CDN. That is generally good for performance — video delivery is a specialised problem and a dedicated CDN with adaptive bitrate will outperform files served from your own assets. It also means your library lives somewhere you do not control. The practical consequences appear at the edges: **Migration.** If you switch apps, can you export the originals, or only the versions the app transcoded? A store that uploaded fifty videos directly, kept no local copies, and can only retrieve compressed derivatives has effectively lost its library. **Continuity.** If the app is uninstalled or the subscription lapses, does existing video stop rendering immediately? Usually yes, which means an expired card can silently strip video from every product page. **Bandwidth limits.** Some plans meter delivery. A video that performs well is a video that is watched, so success and cost move together — check whether a spike in traffic produces a bill or a throttle. None of this is a reason to avoid hosted video; self-hosting on Shopify's own files has real limits and no adaptive delivery. It is a reason to keep your own master copies of everything you upload, which costs nothing and removes the worst outcome. > **Keep the originals** > > Whatever app you choose, keep unedited master files in your own storage. Every migration problem in this category becomes trivial if you still have the source video, and expensive if you do not. ## A short evaluation sequence 1. Shortlist on format coverage — which apps support the two formats you actually need. 2. Install the leading candidate on a duplicate theme. 3. Import ten real videos, including at least one landscape and one with awkward aspect ratio. 4. Measure PageSpeed on a product page before and after. 5. Complete a purchase from inside a video, on mobile, through an accelerated checkout. 6. Uninstall and inspect what remains in the theme. Step four is the one that eliminates candidates fastest, and step six is the one that tells you what you are committing to. For the strategy question of whether video suits your catalogue at all, see [video commerce and UGC](/category/video-commerce-ugc). The wider page-weight picture is in [storefront and design](/category/storefront-design), and app selection generally in [Shopify apps](/category/shopify-apps). **Shoppable video without the page-weight cost** SwipeReel imports Instagram Reels and TikTok UGC into shoppable feeds — carousels, stories, grids and popups, with tap-to-buy inside the video. [See SwipeReel on the Shopify App Store](https://apps.shopify.com/swipereel) ## FAQ ### Do shoppable video apps slow down a Shopify store? Some do, substantially. The determining factor is whether the app loads its player and video assets on page load or only on interaction. ### Can I import my Instagram Reels and TikToks automatically? Most apps in this category offer some import path, but the quality varies and platform APIs change. ### What is the difference between shoppable video and a normal video embed? A normal embed plays. Shoppable video carries product data — a tappable hotspot, a pinned variant, an add-to-cart that does not navigate away from the video. ### Where should shoppable video appear on my store? Product page clips answer a specific doubt about that item. Carousels and stories on the homepage and collection pages drive discovery. Grids suit shop-the-look pages. ### Is a free shoppable video app good enough? For a small catalogue with a handful of videos, often yes. Free tiers typically limit video count, views or formats rather than crippling the core function. --- --- title: "How Much Does a Shopify Store Cost to Build in 2027?" description: "The honest answer is that a Shopify store costs anywhere from a few hundred to six figures, and the range is not agencies being evasive. It reflects genuinely different projects. This breaks the cost into its four real components so you can work out which end of the range you are at." author: "Aashish Kaushik" published: 2026-09-16T09:01:34.103Z updated: 2026-09-16T09:01:34.288Z url: https://blog.byteinfy.com/shopify-store-cost --- # How Much Does a Shopify Store Cost to Build in 2027? ## Key takeaways - Four things drive the cost, the Shopify plan, the theme, the app stack and the build time. Only the last of those varies by an order of magnitude. - A theme-based store with light customisation is a fundamentally different project from a custom or headless build, and no single price range covers both honestly. - Recurring cost is the number most merchants underestimate. Apps and platform fees continue monthly long after the build is paid for. - Quotes vary widely because scope is usually underspecified. A detailed brief narrows a quote range faster than any negotiation does. - The most expensive version of this project is the one built twice, which is what happens when the build starts before the requirements are settled. Ask what a Shopify store costs and you will get a range wide enough to be useless: a few hundred at one end, well into six figures at the other. That range is not evasion. It reflects the fact that "a Shopify store" describes four quite different projects that happen to run on the same platform. This breaks the cost into the components that actually drive it, explains why quotes for the same brief diverge so sharply, and covers the costs that show up after launch rather than before. ## The four components Every Shopify build is the same four line items in different proportions. ### 1. The platform A Shopify subscription, billed monthly or annually, plus payment processing fees on each transaction. This is the most predictable cost in the project and the one you have least control over. Shopify publishes current plan pricing, and it changes, so check it rather than trusting any article including this one. The decision that matters here is which plan, and the honest answer for most new stores is the cheapest one that supports what you need today. Plans are easy to move up and the higher tiers exist for volume and features you can grow into. ### 2. The theme Three options. A free theme, which is genuinely viable for a straightforward catalogue. A premium theme, a one-off purchase covering most requirements most of the time. Or a custom theme, built for you. The strong default is a premium theme. Custom themes are justified when a theme is genuinely blocking something that matters to the business, not when the brand wants to feel bespoke. For most stores launching, the money spent on a custom theme buys more if it goes to product photography and traffic. ### 3. The app stack This is the cost merchants most reliably underestimate, because it is recurring and it accumulates. A typical store ends up with apps for reviews, email, some combination of upsell and bundling, maybe subscriptions, maybe a loyalty programme. Individually each looks small. Collectively, an app stack can rival the platform subscription, and it rarely shrinks, because apps are added when a need appears and uninstalled approximately never. > Audit your app stack twice a year. In most stores we look at, at least one paid app is installed, billing, and not doing anything visible — usually because the campaign it was bought for ended eighteen months ago. Apps also carry a speed cost, so an unused one is charging you twice. ### 4. Build time This is where the order of magnitude lives, and it is the only component that genuinely explains a range from hundreds to six figures. ## The four project types Quotes vary because these four get described with the same words. **Theme setup.** A premium theme, configured properly, with your products, content and branding. No custom development. Fast and, done well, completely respectable. **Customised theme.** A premium theme plus real development: sections the theme does not include, integrations, adjusted cart or checkout behaviour. This is where most serious small and mid-size stores land. **Custom build.** Theme built from scratch against a design, usually with integrations into other systems. Justified by genuine complexity rather than by preference. **Headless.** A separate front end, typically [Hydrogen](/headless-shopify-hydrogen), talking to Shopify through APIs. Maximum control, and a substantially larger project with ongoing engineering implications that continue long after launch. - Which of the four project types is your brief, honestly? - Does your catalogue have unusual variant or bundling needs? - Do you need integrations with an ERP, POS or 3PL? - Is checkout customisation involved, or standard checkout? - Are you migrating existing data, and how much? - Who writes the content and takes the photography? ## Why two quotes for the same brief differ so much Almost always because the brief did not pin the scope, so each agency filled the gaps with its own assumptions. One quoted a theme customisation. The other quoted a custom build. Both quoted honestly and the numbers are incomparable. The fix is not negotiation, it is specificity. Ask each agency to list, in writing: 1. Which project type they are quoting 2. What is explicitly out of scope 3. How many rounds of revision are included 4. Who supplies content, images and copy 5. What happens if scope changes mid-project That last one matters more than it looks. A quote with no change process is a quote that will be renegotiated under pressure. > The most expensive version of this project is the one built twice. That happens when the build begins before requirements are settled, and it is far more costly than paying a bit more for an agency that insists on a discovery phase before writing code. ## What you pay after launch Budget for these before launch, because they arrive whether you planned for them or not. **Platform and apps**, monthly, indefinitely. **Maintenance.** Themes and apps need updating, Shopify ships platform changes, and things break. Whether that is a [monthly retainer](/shopify-retainer-guide) or ad-hoc work, it is not zero. **Iteration.** No store converts as well as it will after six months of changes. Launch is the start of the work. A store with a build budget and no iteration budget tends to stay exactly as it launched. **Traffic.** The single most common expensive mistake in this whole category is spending the entire budget on the build and nothing on getting anyone to see it. A store nobody visits is the most costly outcome available, whatever it cost to build. ## Where the money actually goes on a build It is worth understanding what you are paying for when an agency quotes build time, because the line item that surprises people is rarely the development. **Discovery and scoping.** Understanding your catalogue, your operations and your integrations before writing code. This feels like overhead and is the single best predictor of whether the project lands on budget. Projects that skip it are the ones that get built twice. **Design.** Either adapting a premium theme to your brand, or designing screens from scratch. The gap between these two is large, and it is often where a quote is quietly much bigger than expected. **Development.** The part everyone pictures. Usually a smaller share of the total than clients assume. **Data migration.** If you are coming from another platform, this is its own project with its own risks. [Migrating from WooCommerce](/woocommerce-to-shopify-migration) in particular has failure points around URLs and redirects that sit outside the build itself. **Testing and launch.** Cross-browser, cross-device, checkout testing with real payment methods, and the launch itself. Compressed by optimistic timelines more often than any other phase, and the compression shows up as bugs in week one. **Post-launch support.** Usually a defined window, often thirty days. Find out what happens on day thirty-one before you sign, because that is when it becomes either a new invoice or a [retainer conversation](/shopify-retainer-guide). ## The questions that narrow a quote fastest If you want a tighter number, give a tighter brief. Five things move a quote range more than anything else: 1. Product count and variant complexity. Not just how many products, but how complicated the most complicated one is. 2. Integrations. ERP, POS, 3PL, accounting, email, a subscription service. Each is a conversation. 3. Migration. From what, how much history, and does it need to come across. 4. Checkout requirements. Standard checkout is straightforward. Custom checkout logic means Shopify Functions or checkout extensions, which is real development. 5. Who supplies content. Copy and photography are a genuine cost and often the thing that delays a launch. An agency that assumes you are supplying it and a client who assumed otherwise is the most common timeline dispute in this business. ## How to spend a fixed budget well If your budget is fixed, the ordering matters more than the total. **Get the fundamentals right first.** Fast, works properly on mobile, checkout does not break. [Theme speed](/shopify-theme-speed) is worth real money here and is usually cheaper to get right during the build than to retrofit. **Spend on photography and copy.** These outperform theme customisation for conversion, consistently, and they carry across any future rebuild. **Keep the app stack minimal at launch.** Add apps when you have a demonstrated need, not in anticipation of one. **Hold back something like a fifth of the budget** for the first three months post-launch. That is when you learn what your customers actually do, and having no money left to act on it wastes the learning. **Want a real number for your specific brief?** ByteInfy quotes Shopify builds against a written scope, and will tell you when a premium theme and a week of configuration is genuinely all you need. [Start a project](https://byteinfy.com/#contact) ## Three budgets, three sensible plans If it helps to see the shape rather than the abstraction, here is how the same money is best spent at three different levels. No figures, because they move and vary by region, but the ordering holds. **Tight budget.** Premium theme, configured well. Minimal apps. Spend the difference on product photography and a copywriter for your top twenty products. Launch, then use what you learn to decide where custom work is actually justified. This is a completely legitimate store and many successful ones never leave this configuration. **Middle budget.** Premium theme plus real customisation for the two or three things that genuinely differentiate you, whether that is a configurator, a bundling mechanic or a specific merchandising idea. A proper migration if you are coming from another platform. Keep something back for the first quarter of iteration. **Larger budget.** Now custom design and development, deeper integrations, possibly [headless](/headless-shopify-hydrogen) if you have a genuine reason for it and the engineering capacity to maintain it afterwards. At this level the constraint is rarely money, it is the clarity of the requirements, and the discovery phase becomes the most valuable line item in the quote. The failure pattern is the same at every level: over-specifying the build and under-specifying what happens after. A store is not finished at launch, it is only visible from then on. ## The short version The platform, theme and app costs are broadly similar for everyone. Build time is what varies, and it varies because "a Shopify store" covers four different projects. Work out which of the four you actually need before collecting quotes. Write the scope down. Ask each agency what they assumed. And keep a meaningful slice of the budget for after launch, because that is when the store starts telling you what it needs. If you are at the stage of choosing who builds it, [what to look for in a Shopify development agency](/hire-shopify-development-agency) covers the selection, and [custom versus public app development](/custom-vs-public-shopify-app) is worth reading before anyone quotes you for custom functionality you might not need. ## FAQ ### How much does it cost to build a Shopify store? It depends on which of four project types you are buying. A theme-based store with light configuration sits at the low end, a heavily customised theme in the middle, a custom build higher, and headless highest. The platform subscription and apps are the same regardless; the build time is what differs. ### Is a Shopify store cheaper than WooCommerce? Up front, usually not, because Shopify charges a subscription where WooCommerce is free software. Over time it often works out closer, because hosting, security, maintenance and developer time for WooCommerce are real costs that a Shopify subscription absorbs. ### What ongoing costs should I budget for? The Shopify plan, transaction or payment fees, every paid app in your stack, your domain, and some allowance for maintenance. The app stack is the one that grows quietly, because apps get added and rarely removed. ### Why do agency quotes vary so much for the same brief? Nearly always because the brief was not specific enough for two agencies to be quoting the same project. One assumed a theme customisation, the other a custom build. Ask each to list their assumptions and the gap usually explains itself. ### Can I build a Shopify store myself? Yes, and for a straightforward catalogue with a good theme that is often the right call. Bring in help when you hit something the theme cannot do, when checkout logic gets involved, or when speed and conversion start mattering more than launch date. ### Do I need a custom theme? Usually not at the start. Premium themes cover most requirements, and the money is better spent on product photography, content and getting traffic. Custom becomes justified when the theme is genuinely blocking something that matters. ### What is the most common budget mistake? Spending everything on the build and nothing on what comes after. A beautiful store with no traffic budget and no plan for iteration is the most common expensive outcome in this category. --- --- title: "Shopify SEO Optimierung: Checkliste mit 25 Punkten" description: "Die meisten Shopify-Shops verlieren Sichtbarkeit nicht an Keywords, sondern an Struktur: doppelte URLs, dünne Kollektionsseiten, fehlende Daten. 25 Punkte in der Reihenfolge, in der sie Wirkung zeigen." author: "Aashish Kaushik" published: 2026-09-16T05:01:02.406Z updated: 2026-09-16T05:01:02.446Z url: https://blog.byteinfy.com/shopify-seo-optimierung-checkliste-mit-25-punkten --- # Shopify SEO Optimierung: Checkliste mit 25 Punkten ## Key takeaways - Technische Struktur zuerst, denn doppelte Kollektions-URLs, Tag-Seiten und Variantenseiten kosten mehr Sichtbarkeit als fehlende Keywords. - Kollektionsseiten sind bei Shopify die wichtigsten Rankingseiten für Kategorie-Suchanfragen und brauchen eigenen Text, eigene Titles und interne Links. - Für Deutschland, Österreich und die Schweiz gehört Shopify Markets mit hreflang, lokaler Währung und passenden Domains zur SEO, nicht nur zum Checkout. - Messen Sie in der Search Console pro Template, nicht pro Shop, sonst sehen Sie nicht, wo die Klicks tatsächlich verloren gehen. Shopify SEO Optimierung beginnt nicht bei Keywords, sondern bei der Struktur des Shops. Die meisten Shopify-Shops im deutschsprachigen Raum verlieren Sichtbarkeit an doppelte Kollektions-URLs, dünne Kollektionsseiten, indexierte Tag- und Variantenseiten und Apps, die den Shop verlangsamen. Erst wenn diese Basis stimmt, zahlen sich Titles, Texte und Blogartikel aus. Die folgenden 25 Punkte sind in der Reihenfolge sortiert, in der sie Wirkung zeigen: erst Technik, dann Kollektionen und Produktseiten, dann Content und interne Verlinkung, dann Märkte und Sprachen für Deutschland, Österreich und die Schweiz, zuletzt Messung. Wer die Liste von oben nach unten abarbeitet, arbeitet an den größten Hebeln zuerst. Eine ausführliche englische Grundlage bietet der [Shopify SEO Guide 2026](/shopify-seo-guide-2026). > **Was Shopify vorgibt und was Sie ändern können** > > Shopify erzeugt Sitemap, Canonical-Tags und robots.txt automatisch, und das ist meist gut so. Die Pfade /products/, /collections/ und /pages/ lassen sich nicht entfernen. Ändern können Sie robots.txt.liquid, Theme-Code, Redirects, Metafelder und alles, was Titles, Texte und Verlinkung betrifft. Die Liste konzentriert sich auf das, was in Ihrer Hand liegt. ## Technik: die ersten sechs Punkte Die technische Basis entscheidet, ob Google Ihre Signale bündelt oder auf Dutzende Varianten derselben Seite verteilt. **1. Kollektions-Pfade in Produktlinks entfernen.** Viele Themes verlinken Produkte als /collections/schuhe/products/sneaker statt /products/sneaker. Der Canonical zeigt auf die kurze URL, aber die interne Verlinkung verteilt Linkkraft auf Duplikate. Stellen Sie im Theme sicher, dass Produktkarten die kanonische URL verwenden. **2. Tag-Seiten aus dem Index halten.** Jeder Tag erzeugt eine URL unter /collections/all/tagname. Bei großen Katalogen sind das schnell hunderte dünne Seiten. Setzen Sie noindex über das Theme oder sperren Sie die Pfade in robots.txt.liquid, wenn die Tag-Seiten keinen eigenen Inhalt haben. **3. Variantenseiten prüfen.** Produkt-URLs mit ?variant= sind per Canonical abgedeckt, werden aber indexiert, wenn sie intern verlinkt werden. Prüfen Sie in der Search Console unter "Seiten", welche Parameter-URLs im Index sind. **4. Sitemap kontrollieren.** Die automatische Sitemap enthält Produkte, Kollektionen, Seiten und Blogartikel. Sie enthält auch ausverkaufte Produkte, die Sie längst vergessen haben. Reichen Sie die Sitemap in der Search Console ein und vergleichen Sie eingereichte mit indexierten URLs. **5. Redirects sauber pflegen.** Jede gelöschte oder umbenannte URL braucht eine 301-Weiterleitung unter Navigation, URL-Weiterleitungen. Weiterleitungsketten (A auf B auf C) sollten Sie auflösen. Nach einer Migration ist das der wichtigste Punkt der gesamten Liste; Details im Artikel [WooCommerce zu Shopify migrieren](/de/woocommerce-zu-shopify-migrieren-ohne-rankingverlust). **6. Core Web Vitals pro Template messen.** Nicht die Startseite zählt, sondern Produkt- und Kollektionsseiten, weil dort die Suchbesucher landen. Prüfen Sie Felddaten in der Search Console und im CrUX-Bericht. Apps sind der häufigste Grund für schlechte Werte. Was den Wert tatsächlich bewegt, steht im englischen Artikel [Shopify theme speed](/shopify-theme-speed). ## Kollektionen und Produktseiten: Punkte 7 bis 13 Kollektionsseiten sind bei Shopify die wichtigsten Rankingseiten für Kategorie-Suchanfragen, und sie sind fast immer die am schlechtesten gepflegten. **7. Jede Kollektion braucht eigenen Text.** Ein kurzer Einleitungstext über dem Raster, ein ausführlicher Text darunter. Ohne Text hat die Seite für Google nichts, was sie von hundert anderen Shops unterscheidet. Der englische Artikel [Shopify collection page SEO](/shopify-collection-page-seo) zeigt Aufbau und Länge. **8. Titles pro Kollektion schreiben.** Der Standard-Title ist der Kollektionsname plus Shopname. Ein Title wie "Wanderschuhe Damen kaufen" mit dem eigentlichen Suchbegriff ist besser als "Damen" mit Shopname. **9. Automatische Kollektionen prüfen.** Automatische Kollektionen nach Tags oder Preis erzeugen leicht Überschneidungen: Dieselben zwanzig Produkte in fünf Kollektionen, jede mit identischem Raster und ohne Text. Reduzieren Sie auf Kollektionen, für die es Suchnachfrage gibt. **10. Produkttitel für Suche schreiben, nicht für den Katalog.** "Modell 4711 blau" ist ein interner Name. "Wanderschuh Damen wasserdicht, blau" ist ein Suchbegriff. Der Title kann vom sichtbaren Produktnamen abweichen, dafür gibt es das SEO-Feld. **11. Produktbeschreibungen nicht vom Hersteller kopieren.** Herstellertexte stehen in hundert Shops. Eigener Text, eigene Bilder, eigene Antworten auf Kundenfragen sind der einzige Weg, sich abzuheben. Der englische Beitrag [Shopify product page SEO](/shopify-product-page-seo) geht auf die Struktur ein. **12. Alt-Texte für Produktbilder pflegen.** Alt-Texte sind Barrierefreiheit, Bildersuche und Kontext für Google. Ein Alt-Text beschreibt, was auf dem Bild zu sehen ist, in einem ganzen Satz. Bei tausenden Bildern ist das eine Aufgabe für Automatisierung mit Kontrolle. **13. Strukturierte Daten prüfen.** Die meisten Themes liefern Product-Schema mit Preis, Verfügbarkeit und Bewertung. Prüfen Sie mit dem Rich-Results-Test von Google, ob Preis in Euro oder Franken und Verfügbarkeit korrekt ankommen, besonders bei Varianten und bei mehreren Märkten. ## Content und interne Verlinkung: Punkte 14 bis 18 Content zahlt sich bei Shopify vor allem dann aus, wenn er auf Kollektionen und Produkte verlinkt, die verkaufen. **14. Blogthemen aus Suchdaten ableiten.** Google Autocomplete für Ihre Kategorie, die Suchanfragen in der Search Console und Kundenfragen aus dem Support sind bessere Themenquellen als Brainstorming. Ein Artikel pro echter Frage, nicht pro Keyword. **15. Jeder Artikel verlinkt auf mindestens eine Kollektion.** Ein Blogartikel ohne Link auf eine Verkaufsseite ist ein Aufsatz. Der Link gehört in den Text, nicht nur in die Seitenleiste. Der englische Artikel [Shopify blog SEO](/shopify-blog-seo) beschreibt das Muster. **16. Kollektionen untereinander verlinken.** Von "Wanderschuhe Damen" auf "Wandersocken" und "Wanderrucksäcke", im Text, nicht nur im Menü. Das ist der Teil der internen Verlinkung, den fast alle Shops auslassen. **17. Doppelte Inhalte in Blog und Seiten vermeiden.** Ein Ratgeber als Blogartikel und als Seite unter /pages/ ist ein Duplikat. Entscheiden Sie sich für einen Ort. Der englische Artikel [Shopify duplicate content](/shopify-duplicate-content) listet die typischen Fälle. **18. Autor und Aktualität sichtbar machen.** Name, Datum der letzten Aktualisierung und eine kurze Autorenzeile helfen Lesern und Antwortsystemen, den Inhalt einzuordnen. Für KI-Suche ist das inzwischen ein wesentlicher Punkt; mehr dazu im englischen Beitrag [Shopify GEO and AI search](/shopify-geo-ai-search). ## Märkte und Sprachen für DACH: Punkte 19 bis 22 Wer in Deutschland, Österreich und der Schweiz verkauft, hat drei Märkte mit einer Sprache, zwei Währungen und unterschiedlichen Versand- und Steuerregeln. Das ist eine SEO-Frage, nicht nur eine Checkout-Frage. **19. Shopify Markets statt Kopien des Shops.** Shopify Markets deckt Mehrwährung und lokalisierte Domains oder Unterordner ab und setzt hreflang automatisch. Drei separate Shops mit identischem Inhalt erzeugen Duplikate über drei Domains und dreifachen Pflegeaufwand. **20. Währung und Preise pro Markt korrekt ausspielen.** Euro für Deutschland und Österreich, Franken für die Schweiz, inklusive korrekter MwSt-Anzeige. Google liest Preise aus den strukturierten Daten; wenn dort Euro steht, während die Seite Franken zeigt, ist das ein Fehler. Was in der Schweiz zusätzlich zu beachten ist, steht im Artikel [Shopify in der Schweiz](/de/shopify-schweiz-twint-chf-mwst-agenturwahl). **21. Lokale Begriffe berücksichtigen.** Österreich und die Schweiz suchen teils anders: "Turnschuhe" statt "Sneaker", "Velo" statt "Fahrrad", "Jänner" statt "Januar". Wenn Sie den Markt ernst nehmen, gehören diese Begriffe in Kollektionstexte oder eigene Marktinhalte. **22. Domain-Entscheidung bewusst treffen.** Eine .de-Domain mit Unterordnern für /at und /ch ist der pflegeleichte Weg. Eigene .at- und .ch-Domains lohnen sich, wenn Sie lokale Inhalte, lokalen Versand und lokale Preise unterschiedlich genug gestalten, um die Domain zu tragen. Beides funktioniert mit Markets. ## Messung: Punkte 23 bis 25 Ohne Messung pro Template optimieren Sie blind. **23. Search Console pro Template auswerten.** Filtern Sie Seiten nach /collections/, /products/ und /blogs/. So sehen Sie, ob Klicks bei Kollektionen oder bei Produkten verloren gehen, und welche Kollektion Impressionen ohne Klicks hat, was auf einen schwachen Title hinweist. **24. Indexierte URLs mit gewollten URLs vergleichen.** Die Zahl der indexierten Seiten sollte ungefähr der Zahl Ihrer Produkte, Kollektionen, Seiten und Artikel entsprechen. Ein Vielfaches davon bedeutet Duplikate, ein Bruchteil bedeutet Crawling- oder Qualitätsprobleme. **25. Umsatz pro Landingpage tracken.** GA4 mit Shopify Customer Events, so eingerichtet, dass Umsatz nach Landingpage auswertbar ist. SEO, das Impressionen zählt, aber keinen Umsatz zuordnen kann, lässt sich nicht priorisieren. ## Die häufigsten Duplikat-Quellen bei Shopify | Quelle | Beispiel-URL | Maßnahme | | --- | --- | --- | | Kollektions-Pfad in Produktlinks | /collections/schuhe/products/sneaker | Theme auf kanonische Produkt-URL umstellen | | Tag-Seiten | /collections/all/blau | noindex oder Sperre in robots.txt.liquid | | Varianten-Parameter | /products/sneaker?variant=123 | Canonical prüfen, interne Links ohne Parameter | | Automatische Kollektionen | fünf Kollektionen, gleiche Produkte | zusammenführen, Text ergänzen | | Blog und Seite mit gleichem Inhalt | /blogs/ratgeber/x und /pages/x | einen Ort wählen, den anderen weiterleiten | | Markt-Kopien ohne Markets | shop.de, shop.at, shop.ch identisch | Shopify Markets mit hreflang | ## Die Reihenfolge für die ersten 30 Tage 25 Punkte auf einmal sind zu viel. Die folgende Reihenfolge bündelt die Punkte mit dem größten Hebel in einen Monat, den Sie mit einem kleinen Team schaffen. ## Die ersten 30 Tage - Woche 1: Search Console einrichten, Sitemap einreichen, indexierte URLs mit gewollten vergleichen (Punkte 4, 23, 24) - Woche 1: Produktlinks im Theme auf kanonische URLs umstellen, Tag-Seiten und Parameter prüfen (Punkte 1 bis 3) - Woche 2: Redirects auflösen, Core Web Vitals pro Template messen, App-Liste durchgehen (Punkte 5, 6) - Woche 2: Die zehn wichtigsten Kollektionen mit Text, Title und Querverlinkung versorgen (Punkte 7, 8, 16) - Woche 3: Automatische Kollektionen zusammenführen, Produkttitel der Top-50-Produkte überarbeiten (Punkte 9, 10) - Woche 3: Strukturierte Daten und Preise pro Markt im Rich-Results-Test prüfen (Punkte 13, 20) - Woche 4: Shopify Markets für AT und CH aufsetzen oder prüfen, Domain-Entscheidung treffen (Punkte 19, 22) - Woche 4: Ersten Blogartikel aus Suchdaten schreiben, mit Link auf eine Kollektion (Punkte 14, 15) - Laufend: Alt-Texte, Produktbeschreibungen, GA4-Umsatz pro Landingpage (Punkte 11, 12, 25) Was nach 30 Tagen übrig bleibt, sind die Punkte, die Zeit brauchen: Content, Alt-Texte und Beschreibungen. Die lassen sich als wöchentliche Routine einplanen. ## Häufige Fehler, die die Liste nicht ersetzt Drei Fehler tauchen unabhängig von der Liste immer wieder auf, und sie machen die Arbeit an den 25 Punkten zunichte. **Eine SEO-App als Lösung.** SEO-Apps für Shopify automatisieren Titles, Alt-Texte und Schema. Das ist hilfreich, ersetzt aber keine Struktur. Eine App, die automatisch Alt-Texte aus dem Produktnamen erzeugt, produziert tausend identische Alt-Texte. Welche Apps sich lohnen, beschreibt der englische Artikel [Best Shopify SEO apps](/best-shopify-seo-apps). **Themenwechsel ohne Redirect-Prüfung.** Ein neues Theme ändert keine URLs, aber es ändert interne Links, Schema und oft die Kollektions-Pfade in Produktkarten. Prüfen Sie nach jedem Themenwechsel die Punkte 1, 13 und 6. **Rankings ohne Umsatz.** Ein Blogartikel, der für eine informative Suchanfrage rankt und niemanden in eine Kollektion führt, ist Aufwand ohne Ertrag. Punkt 15 und Punkt 25 sind die Kontrolle dagegen. Wenn Sie die technischen Punkte nicht selbst umsetzen können oder wollen, beginnt ein technischer Audit mit priorisierter Fehlerliste bei [ByteInfy Shopify SEO](https://byteinfy.com/services/shopify-seo) bei 1.000 $. Welche Fragen Sie einer SEO-Agentur vorher stellen sollten, steht im Beitrag [Shopify Agentur auswählen: 12 Fragen vor dem Vertrag](/de/shopify-agentur-auswahlen-12-fragen-vor-dem-vertrag). **Sie wollen wissen, welche der 25 Punkte bei Ihrem Shop offen sind?** ByteInfy prüft Struktur, Indexierung, Kollektionen und Geschwindigkeit Ihres Shops und liefert eine priorisierte Liste, die Sie selbst oder mit Unterstützung abarbeiten können. [Mit ByteInfy sprechen](https://byteinfy.com/contact) ## FAQ ### Wo fange ich bei Shopify SEO an? Bei der Struktur, nicht beim Content. Prüfen Sie zuerst, welche URLs Google indexiert, ob Kollektions-Pfade mit /products/ dupliziert werden, ob Tag-Seiten und Variantenseiten im Index landen und ob die Sitemap sauber ist. ### Warum ranken meine Kollektionsseiten nicht? Meist, weil sie keinen eigenen Inhalt haben. Eine Kollektionsseite mit nur einem Produktraster und einem Titel hat für Google kaum Text, der sie von hundert anderen Shops unterscheidet. ### Brauche ich für Österreich und die Schweiz eigene Domains? Nicht zwingend. Shopify Markets deckt Mehrwährung und lokalisierte Domains oder Unterordner ab und setzt hreflang automatisch. Ob eine .at- oder . ### Schaden Apps meinem Shopify SEO? Sie können, auf zwei Wegen. Erstens laden viele Apps Skripte auf jeder Seite und verschlechtern Core Web Vitals. Zweitens erzeugen manche Apps eigene URLs, Filter-Parameter oder duplizierte Inhalte. ### Wie oft sollte ich Blogartikel veröffentlichen? Regelmäßig genug, um Themen abzudecken, die Ihre Käufer tatsächlich suchen, und selten genug, dass jeder Artikel gut ist. ### Was ist der Unterschied zwischen SEO und GEO bei Shopify? SEO zielt auf Rankings in klassischen Suchergebnissen, GEO darauf, von KI-Antwortsystemen wie Google AI Overviews, ChatGPT oder Perplexity zitiert zu werden. ### Kann ich Shopify SEO selbst machen oder brauche ich eine Agentur? Die meisten Punkte dieser Liste können Sie selbst umsetzen, etwa Titles, Texte, Alt-Texte und Redirects. Technische Punkte wie robots.txt.liquid, strukturierte Daten im Theme, Speed-Optimierung oder das Aufräumen alter App-Reste erfordern Theme-Code. --- --- title: "Shopify Agentur Kosten 2027: was ein Shop wirklich kostet" description: "Die Spanne bei Shopify-Agenturen reicht von wenigen tausend bis zu mehreren zehntausend Euro. Was den Unterschied ausmacht, welche Preismodelle es gibt und welche Kosten nach dem Launch weiterlaufen." author: "Aashish Kaushik" published: 2026-09-15T13:00:10.022Z updated: 2026-09-15T13:00:10.030Z url: https://blog.byteinfy.com/shopify-agentur-kosten-2027-was-ein-shop-wirklich --- # Shopify Agentur Kosten 2027: was ein Shop wirklich kostet ## Key takeaways - Der Preis eines Shopify-Shops hängt weniger vom Design ab als von Katalogumfang, Integrationen und dem Anteil an individuell gebauten Sektionen. - Festpreis, Stundensatz und Retainer haben jeweils einen Einsatzzweck; ein Festpreis ohne schriftlichen Umfang schützt niemanden. - Die laufenden Kosten (Shopify-Plan, Apps, Wartung, Zahlungsgebühren) übersteigen den Baupreis über drei Jahre oft deutlich und fehlen in den meisten Angeboten. - Bei Agenturen außerhalb der EU gilt für Unternehmen in der Regel das Reverse-Charge-Verfahren; die MwSt führen Sie selbst ab, was den Vergleich mit Inlandsangeboten verändert. Ein Shopify-Shop von einer Agentur kostet 2027 selten einen einzigen festen Betrag, sondern eine Spanne, die sich fast vollständig durch drei Faktoren erklärt: den Umfang des Katalogs, die Zahl der Integrationen und den Anteil an individuell gebauten Teilen. Zur Einordnung: ByteInfy beginnt bei 2.000 $ für die [Shop-Entwicklung](https://byteinfy.com/services/shopify-store-development), und die meisten Projekte landen laut eigener Preisangabe zwischen 2.000 $ und 8.000 $. Eine Theme-Anpassung beginnt bei 1.000 $, eine Migration bei 1.500 $, eine eigene App bei 3.000 $. Diese Zahlen sind ein Referenzpunkt, kein Marktdurchschnitt. Agenturen in Deutschland, Österreich und der Schweiz kalkulieren mit anderen Stundensätzen, anderen Overheads und meist in Euro oder Franken. Der Rest dieses Artikels erklärt, wie Sie ein Angebot lesen, welche Posten regelmäßig fehlen und wann ein günstigerer Weg die bessere Entscheidung ist. > **Geschrieben von einer Agentur** > > Lesen Sie entsprechend kritisch. ByteInfy sitzt in Indien und arbeitet mit internationalen Händlern, auch aus dem deutschsprachigen Raum. Die genannten Preise sind die eigenen Startpreise; für andere Anbieter gelten andere Zahlen. Was sich übertragen lässt, sind die Kostentreiber und die Fragen, die Sie vor der Unterschrift stellen sollten. ## Was den Preis wirklich treibt Der Preis folgt dem Aufwand, und der Aufwand folgt selten dem Design. Drei Dinge machen den Unterschied zwischen dem unteren und dem oberen Ende der Spanne. **Der Katalog.** Fünfzig Produkte mit je drei Varianten sind ein Nachmittag Datenpflege. Fünftausend Produkte mit Metafeldern, Größentabellen, Herstellerangaben und Bildern in vier Sprachen sind ein eigenes Teilprojekt, das Import-Skripte, Prüfläufe und Nacharbeit braucht. **Die Integrationen.** Jede Anbindung an ein Warenwirtschaftssystem, eine Buchhaltung, ein Fulfillment oder ein Versandtool ist ein eigenes Stück Software, das getestet und überwacht werden muss. Eine einzelne Integration beginnt bei ByteInfy bei 1.500 $; komplexe ERP-Anbindungen werden nach Scoping angeboten. **Der individuelle Anteil.** Ein Theme aus dem Theme Store, das mit eigenen Sektionen ergänzt wird, ist der günstigste Weg zu einem professionellen Shop. Ein individuelles Theme, eigene Checkout-Erweiterungen oder ein Headless-Storefront verschieben den Preis in eine andere Größenordnung. Wann sich das lohnt, behandelt der Artikel [Headless Shopify mit Hydrogen](/de/headless-shopify-mit-hydrogen-wann-es-sich-lohnt). Alles andere, etwa Anzahl der Seiten, Sprachen oder Zahlungsarten, beeinflusst den Preis, aber deutlich weniger als diese drei Punkte. ## Die drei Preismodelle und wann welches passt Agenturen rechnen nach Festpreis, nach Stundensatz oder als Retainer. Jedes Modell verteilt das Risiko anders. **Festpreis** passt, wenn der Umfang vor Projektstart schriftlich feststeht. Sie tragen kein Risiko bei Fehlschätzungen der Agentur, dafür kostet jede Änderung während des Projekts einen Nachtrag. Ein Festpreis ohne detaillierte Leistungsbeschreibung ist keiner, sondern ein Stundensatz mit Verzögerung. **Stundensatz oder Tagessatz** passt für Arbeit, deren Umfang sich erst beim Machen zeigt: Audits, Fehlersuche, Aufräumen eines alten Themes. Sie zahlen, was gebraucht wird, und brauchen dafür einen Budgetdeckel und regelmäßige Abrechnung. **Retainer** passt für laufende Arbeit nach dem Launch. Ein monatlicher Betrag deckt Monitoring, Updates und ein Stundenkontingent. ByteInfy bietet [Wartung und Support](https://byteinfy.com/services/shopify-maintenance) ab 500 $ pro Monat an; der Stundenpreis sinkt mit größerem Kontingent. In der Praxis kombinieren viele Händler die Modelle: Festpreis für den Bau, Stundensatz für unvorhersehbare Nacharbeit, Retainer für den Betrieb. Das ist kein Nachteil, solange die Übergänge klar vereinbart sind. ## Startpreise nach Leistung Die folgende Tabelle listet die Startpreise, die ByteInfy auf der eigenen Leistungsseite ausweist. Sie zeigt weniger, was ein Shop bei einer bestimmten Agentur kostet, als vielmehr, wie sich die Leistungen zueinander verhalten: eine Speed-Optimierung ist eine andere Größenordnung als ein Headless-Build, und das gilt bei jeder Agentur. ## Startpreise ByteInfy (USD, Stand der Leistungsseite) | Leistung | Startpreis | Typische Spanne laut Preisangabe | | --- | --- | --- | | Shop-Entwicklung (Online Store 2.0) | ab 2.000 $ | 2.000 $ bis 8.000 $ | | Theme-Anpassung | ab 1.000 $ | 1.000 $ bis 3.000 $ | | Migration (WooCommerce, Magento, Wix) | ab 1.500 $ | komplexe ERP-Setups nach Scoping | | Custom App für einen Shop | ab 3.000 $ | Public App 8.000 $ bis 25.000 $ | | Checkout-Extensions und Functions | ab 1.500 $ | 1.500 $ bis 3.000 $ pro Function | | SEO (technischer Audit) | ab 1.000 $ | laufend 1.000 $ bis 3.000 $ pro Monat | | Speed-Optimierung | ab 750 $ | 750 $ bis 1.500 $ | | Headless (Hydrogen, Next.js) | ab 5.000 $ | bis 25.000 $ und mehr | | Wartung und Support | ab 500 $ pro Monat | fünf Entwicklungsstunden inklusive | Zwei Dinge fallen auf. Erstens liegt die Migration unter der Shop-Entwicklung, weil sie den Theme-Bau nicht enthält; beides zusammen ist der realistische Preis für einen Plattformwechsel. Zweitens ist die Spanne bei Apps am größten, weil eine Public App mit Abrechnung, Onboarding und App-Store-Review ein Produkt ist und kein Projekt. Wenn Sie Angebote aus DACH vergleichen, bauen Sie sich dieselbe Tabelle mit deren Zahlen. Das macht sichtbar, ob ein Anbieter beim Theme günstig und bei Integrationen teuer ist oder umgekehrt. ## Die laufenden Kosten, die im Angebot fehlen Der Baupreis ist über drei Jahre gerechnet häufig der kleinere Teil. Was nach dem Launch weiterläuft, steht selten im Angebot, gehört aber in Ihre Kalkulation. **Der Shopify-Plan.** Die Plangebühren finden Sie auf der aktuellen Preisseite von Shopify; sie hängen vom gewählten Plan und der Abrechnungsart ab. Shopify Plus beginnt zum Zeitpunkt der Erstellung bei etwa 2.300 USD pro Monat bei dreijähriger Laufzeit und ist für die meisten Händler in DACH erst relevant, wenn Plus-Funktionen im Checkout oder im B2B-Bereich gebraucht werden. **Apps.** Jede App mit Monatsgebühr ist ein Dauerposten. Zehn Apps zu je 20 bis 50 Euro sind schnell mehrere tausend Euro im Jahr, und viele davon verlangsamen zusätzlich den Shop. Der englische Artikel [How many Shopify apps is too many](/how-many-shopify-apps-is-too-many) geht darauf im Detail ein. **Zahlungsgebühren.** Shopify Payments, Klarna, PayPal und in der Schweiz TWINT kosten pro Transaktion. Diese Gebühren sind kein Agenturposten, aber sie gehören in dieselbe Rechnung wie der Plan. **Wartung und API-Umstellungen.** Shopify stellt API-Versionen nach festem Zeitplan ab. Individueller Code, Apps und Integrationen müssen dann angepasst werden. Wer das nicht einplant, zahlt es als Notfall. Der englische Beitrag zu [Shopify API versioning](/shopify-api-versioning) beschreibt den Rhythmus. **Content.** Produkttexte, Übersetzungen für Österreich und die Schweiz, Bilder und Rechtstexte werden im Angebot oft als "vom Kunden geliefert" markiert. Wenn Sie sie nicht liefern können, ist das ein weiterer Posten. ## Inland oder Ausland: was der Standort der Agentur ändert Der Standort verändert den Stundensatz, die Zusammenarbeit und die Steuer, und alle drei gehören in den Vergleich. Beim Stundensatz liegt eine Agentur außerhalb des deutschsprachigen Raums häufig niedriger. Ob das Gesamtprojekt günstiger wird, hängt davon ab, wie viel Abstimmung nötig ist und wie gut die Agentur Ihre Anforderungen versteht. Sprache, Zeitzone und Erfahrung mit deutschen Rechtstexten, MwSt-Sätzen oder DHL-Anbindungen sind keine Nebensache. Was ein Shop in Deutschland rechtlich braucht, steht im Artikel [Shopify rechtssicher in Deutschland](/de/shopify-rechtssicher-deutschland-impressum-dsgvo-button). Bei der Steuer gilt für Unternehmen in Deutschland, Österreich und der Schweiz, die eine Agentur außerhalb der EU beauftragen, in der Regel das Reverse-Charge-Verfahren: Die Rechnung enthält keine MwSt, und Sie führen die Steuer selbst ab und ziehen sie als Vorsteuer wieder ab, sofern Sie vorsteuerabzugsberechtigt sind. Für den Vergleich heißt das, dass Sie Nettopreise mit Nettopreisen vergleichen. Klären Sie den konkreten Fall mit Ihrer Steuerberatung. Bei der Währung lohnt ein Blick auf die Abrechnung. Angebote in USD schwanken in Euro oder Franken mit dem Kurs; bei einem Festpreis über mehrere Monate ist das ein Punkt, den Sie vorab regeln sollten. Welche Fragen Sie einer Agentur unabhängig vom Standort stellen sollten, listet der Beitrag [Shopify Agentur auswählen: 12 Fragen vor dem Vertrag](/de/shopify-agentur-auswahlen-12-fragen-vor-dem-vertrag). ## So lesen Sie ein Angebot Ein Angebot ist erst dann vergleichbar, wenn es die Bestandteile einzeln benennt. Die folgende Liste deckt die Punkte ab, an denen sich Angebote in der Praxis unterscheiden. ## Vor dem Vergleich prüfen - Ist der Katalogumfang genannt (Anzahl Produkte, Varianten, Sprachen, Metafelder) - Sind die Integrationen einzeln aufgeführt, mit Richtung des Datenflusses - Welche Templates werden gebaut (Startseite, Kollektion, Produkt, Landingpages, Blog) - Ist die Migration inklusive Redirects und URL-Mapping enthalten - Sind Rechtstexte, Cookie-Consent und Checkout-Anpassungen für Deutschland und Österreich berücksichtigt - Wie lange läuft der Support nach dem Launch, und was kostet die Wartung danach - Wem gehört der Code, und wie erhalten Sie Zugriff auf Theme und Repository - Was passiert bei Änderungswünschen während des Projekts, und zu welchem Satz - Wird in USD, EUR oder CHF abgerechnet, und wer trägt das Kursrisiko Ein Angebot, das mehr als zwei dieser Punkte offenlässt, ist kein Festpreis. Es ist eine Schätzung, deren Lücken Sie später bezahlen. ## Wann ein Theme reicht und wann nicht Der günstigste Shop ist der, der nicht gebaut werden muss. Ein Theme aus dem Theme Store mit eigenen Sektionen deckt einen großen Teil der Anforderungen ab, und eine gute Agentur sagt Ihnen das, bevor sie ein individuelles Theme anbietet. Ein angepasstes Theme reicht, wenn Ihr Katalog in die Standardstruktur passt, Ihre Marke mit Farben, Schriften und eigenen Sektionen ausgedrückt werden kann und Ihre Integrationen über Apps oder eine einzelne Anbindung laufen. Die [Theme-Anpassung](https://byteinfy.com/services/shopify-theme-customization) ab 1.000 $ deckt genau das ab: neue Sektionen, Landingpage-Templates, Produktseiten-Erweiterungen, ohne dass Theme-Updates brechen. Ein individueller Bau lohnt sich, wenn das Theme Ihren Anforderungen wiederholt im Weg steht, wenn mehrere Märkte unterschiedliche Merchandising-Logik brauchen oder wenn eigene Checkout-Regeln über Shopify Functions nötig sind. Der englische Beitrag [Shopify theme vs custom](/shopify-theme-vs-custom) nennt die Entscheidungskriterien; für Rabattlogik ohne Scripts siehe [Rabatte mit Shopify Functions bauen](/de/rabatte-mit-shopify-functions-bauen-scripts-sind). Headless mit Hydrogen ab 5.000 $ ist die teuerste Variante und nur dann sinnvoll, wenn der Theme-Editor Ihre Anforderungen wirklich nicht abbilden kann. Wer diese Frage ehrlich beantwortet, spart meist mehr Geld als bei jeder Preisverhandlung. ## Drei typische Szenarien, durchgerechnet Abstrakte Spannen helfen wenig, deshalb hier drei erfundene, aber typische Ausgangslagen mit den oben genannten Startpreisen. Die Zahlen sind ByteInfy-Startpreise in USD; bei anderen Agenturen setzen Sie deren Sätze ein, die Struktur bleibt gleich. **Szenario 1: Ein neues D2C-Label aus Deutschland mit 80 Produkten.** Ein Theme aus dem Theme Store, fünf eigene Sektionen, Klarna und PayPal über Shopify Payments, DHL-Versand, deutsche Rechtstexte über einen Generator. Hier reicht eine Theme-Anpassung zwischen 1.000 $ und 3.000 $ oder eine Shop-Entwicklung am unteren Ende ab 2.000 $. Laufend kommen Plan, zwei bis drei Apps und Zahlungsgebühren dazu. Wartung kann in dieser Phase oft entfallen, solange niemand am Theme-Code arbeitet. **Szenario 2: Ein Händler mit 1.200 Produkten zieht von WooCommerce um.** Die Migration ab 1.500 $ deckt URL-Mapping, Redirects und Datenübernahme ab; der Theme-Bau kommt als Shop-Entwicklung ab 2.000 $ dazu, ein technischer SEO-Audit ab 1.000 $ sichert die Rankings nach dem Umzug. Wie der Umzug ohne Rankingverlust gelingt, steht im Artikel [WooCommerce zu Shopify migrieren](/de/woocommerce-zu-shopify-migrieren-ohne-rankingverlust). Realistisch liegt dieses Projekt im mittleren Bereich der Spanne, weil die Datenqualität bei WooCommerce-Exporten den Aufwand bestimmt. **Szenario 3: Ein wachsender Händler mit ERP, drei Märkten und eigenen Rabattregeln.** Shop-Entwicklung am oberen Ende bis 8.000 $, eine ERP-Integration ab 1.500 $, zwei Shopify Functions für Staffelrabatte und Versandregeln ab 1.500 $ pro Function, Shopify Markets für Deutschland, Österreich und die Schweiz mit Euro und Franken, plus Wartung ab 500 $ pro Monat. Hier ist der Baupreis fünfstellig, und die laufenden Kosten sind über drei Jahre ähnlich hoch wie der Bau. Die drei Szenarien zeigen, warum die Frage "Was kostet ein Shopify-Shop" ohne Kontext nicht zu beantworten ist. Dieselbe Agentur mit denselben Sätzen liefert für Szenario 1 und Szenario 3 Angebote, die um den Faktor fünf auseinanderliegen, und beide sind korrekt. ## Ein realistisches Budget aufstellen Ein brauchbares Budget besteht aus drei Zeilen: Bau, erstes Jahr Betrieb, Reserve für Änderungen. Für den Bau nehmen Sie das Angebot mit vollständiger Leistungsbeschreibung. Für das erste Betriebsjahr addieren Sie Shopify-Plan, Apps, Zahlungsgebühren auf Basis Ihres erwarteten Umsatzes, Wartung und die Content-Arbeit, die Sie nicht selbst leisten. Für die Reserve rechnen Sie mit einem Anteil des Baupreises, weil jedes Projekt auf etwas Unerwartetes trifft: eine Integration, die anders funktioniert als dokumentiert, ein Rechtstext, der eine Checkout-Änderung erzwingt, ein Theme-Update, das eine Sektion bricht. Wer so rechnet, vergleicht nicht mehr den günstigsten Baupreis, sondern die günstigsten drei Jahre. Das ist die Zahl, die für Ihr Geschäft zählt. Eine Übersicht über alle Leistungen und Startpreise finden Sie unter [byteinfy.com/services](https://byteinfy.com/services). **Sie möchten wissen, was Ihr Shop wirklich kostet?** ByteInfy nennt Ihnen nach einem Scoping-Gespräch einen festen Preis mit vollständiger Leistungsbeschreibung, und sagt Ihnen, wenn eine Theme-Anpassung die günstigere Lösung ist. [Mit ByteInfy sprechen](https://byteinfy.com/contact) ## FAQ ### Was kostet ein Shopify-Shop von einer Agentur? Das hängt vom Umfang ab. Ein Shop auf einem angepassten Theme mit überschaubarem Katalog liegt am unteren Ende, ein individuelles Theme mit ERP-Anbindung, mehreren Märkten und eigenen Checkout-Regeln deutlich darüber. ByteInfy startet bei 2. ### Warum unterscheiden sich Angebote so stark? Weil Angebote selten denselben Umfang beschreiben. Ein Angebot enthält Content-Migration, Redirects und 30 Tage Support, das andere nur die Theme-Anpassung. Dazu kommen Stundensätze, die je nach Standort, Größe und Spezialisierung der Agentur stark auseinanderliegen. ### Ist eine Agentur aus dem Ausland günstiger? Häufig beim Stundensatz, nicht zwingend beim Gesamtprojekt. Rechnen Sie Zeitzonen, Abstimmungsaufwand und Sprache mit ein. ### Welche Kosten laufen nach dem Launch weiter? Der Shopify-Plan, kostenpflichtige Apps, Zahlungsgebühren, ein Premium-Theme mit Updates und die Wartung. Ein Wartungsvertrag beginnt bei ByteInfy bei 500 $ pro Monat. ### Reicht ein fertiges Theme oder brauche ich ein individuelles? Für die meisten Shops reicht ein gutes Theme aus dem Theme Store, das um eigene Sektionen ergänzt wird. ### Wie erkenne ich, ob ein Festpreis realistisch ist? Ein Festpreis ist nur so gut wie die Leistungsbeschreibung dahinter. Prüfen Sie, ob Katalogumfang, Anzahl der Templates, Integrationen, Migration, Tests und Support explizit genannt sind und was bei Änderungswünschen passiert. ### Muss ich Shopify Plus einplanen? Nur wenn Sie Funktionen brauchen, die Plus voraussetzt, etwa bestimmte Anpassungen im Checkout oder B2B-Funktionen im großen Stil. Shopify Plus beginnt zum Zeitpunkt der Erstellung bei etwa 2.300 USD pro Monat bei dreijähriger Laufzeit. --- --- title: "Shopify Retainer: What It Costs and What Should Be In It" description: "A Shopify retainer is a monthly agreement to keep a store maintained and improved. It is also one of the easiest agency purchases to get wrong, because the thing being sold is availability rather than output. Here is what belongs in one, how they are priced, and the cases where you should not buy one at all." author: "Aashish Kaushik" published: 2026-09-15T09:00:08.931Z updated: 2026-09-15T09:00:08.954Z url: https://blog.byteinfy.com/shopify-retainer-guide --- # Shopify Retainer: What It Costs and What Should Be In It ## Key takeaways - A retainer buys availability and continuity, not a fixed list of deliverables, which is why two retainers at the same price can differ enormously in value. - Most are priced as a monthly block of hours. The clauses that matter are rollover, response time, and what happens when the store breaks outside those hours. - If your store needs fewer than roughly ten hours of work a month and nothing is on fire, a retainer is usually worse value than paying per project. - The strongest reason to hold one is that the agency keeps context. Re-explaining a theme, an app stack and a checkout to a new developer every quarter costs more than the retainer does. - Ask what happens to unused hours and whether emergency work is inside or outside the agreement, before the emergency. A Shopify retainer is a monthly agreement with an agency or developer to keep your store maintained and improved. It sounds simple, and it is the agency purchase merchants most often regret, because what you are buying is availability rather than a defined deliverable. That distinction is the whole thing. When you buy a project, you can point at the outcome. When you buy a retainer, you are buying the right to have someone competent pick up the phone, already knowing how your checkout works. Whether that is worth the money depends almost entirely on how much small work your store actually generates. This covers what belongs in a retainer, how they are priced, the clauses that decide value, and the cases where you should not buy one. ## What a retainer actually covers A well-constructed Shopify retainer has four parts. If a proposal is missing one of them, that is worth a question. **Maintenance.** Theme updates, app updates, checking that nothing broke when Shopify shipped a platform change, monitoring uptime and speed. This is the floor. It is unglamorous and it is the part that prevents the expensive surprises. **Fixes.** Something breaks, someone fixes it, within a stated window. The stated window is the product here. "We'll get to it" is not a response time. **Improvement work.** A share of the monthly hours aimed at things you chose rather than things that went wrong. Without this, a retainer is an insurance policy with a subscription fee. **Continuity.** The least visible and most valuable part: the agency retains context. Your theme's quirks, why that app was chosen, what the last developer did to the cart drawer, which of your integrations is fragile. > Continuity is usually where the real economics sit. Onboarding a new developer onto an existing Shopify store realistically costs somewhere between five and fifteen hours before they ship anything useful — reading the theme, mapping the app stack, understanding the checkout. If you change developers twice a year, you are paying that cost twice a year, invisibly. ## How retainers are priced Almost all Shopify retainers are a monthly block of hours at an effective hourly rate. The headline monthly figure is the least informative number in the proposal. The figures that actually matter: - Hours included, and at what seniority. Twenty hours of a junior's time and twelve of a senior's are not comparable, and the cheaper one is frequently the more expensive one. - Effective hourly rate. Monthly fee divided by included hours. This is the number to compare across proposals. - Overage rate. What an hour costs once you exceed the block. Some agencies charge a premium above the retainer rate, some charge the same. - Rollover. Whether unused hours carry forward, up to what cap, and for how long. Rates vary enormously by region, and by whether you are buying a single developer or a team with a project manager, a designer and a developer behind it. A cheap retainer from a solo developer with no cover is a real risk during BFCM; a team retainer costs more and someone is always available. - Hours included per month, and at what seniority - Effective hourly rate (monthly fee ÷ hours) - Overage rate once the block is used - Rollover policy, cap and expiry - Response time for urgent issues, in writing - Whether emergency work sits inside or outside the agreement - Notice period and handover terms ## The clauses that decide whether it is worth it Three clauses separate a retainer that pays for itself from one you resent by month four. ### Rollover Seasonal businesses have quiet Februaries and frantic Novembers. A strict use-it-or-lose-it retainer punishes exactly that shape: you pay for hours you cannot use in the quiet months and blow through the block when it matters. Ask for rollover with a cap, commonly something like carrying unused hours for a quarter. Most agencies will agree to a reasonable version, because it also smooths their own workload. ### Response time, stated in hours "Priority support" means nothing. A stated response time means something. Distinguish between: - Response time, when someone acknowledges and starts looking, and - Resolution time, which no honest agency guarantees for an unknown bug. Get response time in writing, and get it differentiated by severity. A cosmetic issue on a collection page and a broken checkout are not the same event. ### What counts as an emergency This is the clause that surfaces at the worst moment. If your checkout breaks at 9pm on Black Friday, is that inside the retainer or billed as emergency work at a premium? Both answers are legitimate. What is not legitimate is discovering the answer during the emergency. Ask before you sign. ## When you should not buy a retainer An agency writing a page about retainers has an obvious incentive to tell you to buy one. So, plainly: a lot of stores should not. **Your store is stable and you ship rarely.** If the last six months produced two small change requests, a retainer is paying monthly for availability you are not using. Pay per project. Revisit when the small requests become tedious to keep commissioning individually. **You need fewer than about ten hours a month.** Below that, the overhead of a retainer relationship rarely beats simply booking work as it arises. The exception is if those few hours are unpredictable and urgent, because then you are genuinely buying the response time. **You are mid-replatform or about to rebuild.** Retainers are for running stores. If a rebuild is coming, scope the rebuild and start a retainer after it lands, when there is something to maintain. **You have an in-house developer.** Then what you may want is occasional specialist help — checkout extensions, a Hydrogen question, an app build — not a monthly block. Buy the specialism, not the availability. **Not sure whether you need a retainer at all?** ByteInfy runs Shopify retainers and also tells merchants when paying per project is the better deal. A short call will establish which one you are. [Start a project](https://byteinfy.com/#contact) ## When a retainer clearly pays The inverse cases are just as clear. **You ship changes continuously.** New collections, landing pages, seasonal campaigns, A/B tests. The volume of small work makes per-project commissioning administratively expensive on both sides. **Your store carries real revenue risk.** If an hour of downtime is meaningful money, the response time clause alone justifies the fee. **Your stack is complex.** Multiple apps, custom checkout extensions, an ERP integration, a headless front end. The context cost of re-onboarding someone is high enough that continuity is the product. If you are running [headless Shopify on Hydrogen](/headless-shopify-hydrogen) or maintaining [checkout extensions built after the move off Scripts](/shopify-scripts-to-functions), this is you. **You have a plan you keep not executing.** Speed work, SEO fixes, CRO tests. A retainer with dedicated improvement hours turns an intention into a schedule, which is the only thing that ever gets these done. ## What a good retainer month looks like Abstract descriptions of retainers are easy to agree with and hard to evaluate. Here is the shape of a month that is working, on a store with a mid-sized block of hours. **Week one.** The monthly check: theme and app updates applied on a duplicate theme and tested before going live, a speed measurement recorded, error logs reviewed. An hour or two, mostly unglamorous, and the reason nothing catches fire in week three. **Weeks two and three.** The improvement work. This is the part you agreed at the start of the month: a product page change, a new section, a speed fix, a bug that has been annoying you but never made it to urgent. Crucially, it was planned, not reactive. **Week four.** A short written update. What was done, what the hours went on, what is queued for next month. If you are not getting this, you cannot tell whether the retainer is working, and neither can they. Across that month a proportion of the hours will get eaten by things nobody planned. That is normal and it is partly what you are buying. What is not normal is *every* month being consumed that way, because a retainer that is permanently firefighting is telling you something about the store's underlying condition that a retainer alone will not fix. > If three consecutive months have gone entirely on unplanned work, stop and do a proper audit instead of renewing. Perpetual firefighting usually means an underlying problem — a fragile integration, an app conflict, technical debt in the theme — that is cheaper to fix once than to keep patching monthly. ## The handover test One question exposes more about an agency than any case study: what would happen if you left tomorrow? A good answer involves documentation that already exists, code in a repository you have access to, and app accounts registered to your email rather than theirs. A bad answer involves a promise to "put something together" at the time. Check this at the start of the relationship, not the end. Ask for access to the repository and a document describing the store's architecture in month one. If either is difficult to obtain while the relationship is good, it will be considerably harder when it is not. ## How to compare two retainer proposals Put them side by side on the effective hourly rate first, then adjust for everything that rate does not capture. Ask both agencies the same three questions: 1. "Show me a month of work from a similar client." Not a case study. An actual breakdown of where the hours went. This reveals whether their retainers are mostly reactive firefighting or genuinely include improvement work. 2. "Who specifically will work on our store, and what happens when they are on holiday?" Single-person cover is the most common failure mode in the cheaper tier. 3. "What does month one look like?" A good answer involves an audit and a documented map of your store before any work starts. An agency that begins shipping changes on day one without understanding the theme is one you will pay to undo things later. And ask what happens at the end. Notice period, code access, documentation handover. A retainer you cannot cleanly leave is a dependency rather than a service. If you are earlier in the process and still choosing a partner at all, [what to look for when hiring a Shopify development agency](/hire-shopify-development-agency) covers the selection itself, and the [theme speed guide](/shopify-theme-speed) is a fair test of whether a prospective agency actually knows the platform. ## The short version A retainer buys availability, continuity and a response time. It is worth it when your store generates a steady stream of small work, when downtime costs real money, or when your stack is complex enough that context has value. It is not worth it when your store is quiet, when you need fewer than about ten hours a month, or when a rebuild is imminent. Before signing, get three things in writing: rollover, response time by severity, and the definition of an emergency. Those three clauses will determine, more than the monthly figure, whether you are still happy with the arrangement in month six. ## FAQ ### What is a Shopify retainer? A monthly agreement with an agency or developer covering ongoing work on your store, typically a set number of hours plus an agreed response time for issues. It covers maintenance, small improvements and availability rather than one defined project. ### How much does a Shopify retainer cost? It varies by region and seniority far more than by scope. What matters more than the number is the hours included, whether they roll over, and whether urgent work is inside the agreement or billed separately. Ask for the effective hourly rate and compare that. ### Do I need a retainer for a Shopify store? Not always. If your store is stable, your app stack is settled and you ship changes rarely, a retainer can be money spent on availability you do not use. Pay per project until the volume of small work makes that annoying. ### What should a Shopify retainer include? At minimum, theme and app updates, monitoring, bug fixes, a defined response time, and a share of hours for improvement work rather than only maintenance. A retainer that is purely reactive is an insurance policy, not a growth investment. ### Do unused retainer hours roll over? Sometimes, usually with a cap and an expiry. This is the single most valuable clause to negotiate, because seasonal businesses have quiet months and busy ones, and a strict use-it-or-lose-it retainer penalises exactly that pattern. ### What is the difference between a retainer and a support plan? A support plan is generally reactive, covering fixes when something breaks. A retainer should include proactive work as well, improvements you planned rather than only problems you did not. ### Can I cancel a Shopify retainer? Terms vary, commonly a 30 to 90 day notice period. Ask about notice and about handover before signing, specifically whether documentation and code access transfer cleanly when you leave. --- --- title: "Comment choisir une agence Shopify : 12 questions à poser" description: "Un portfolio montre ce qui a été lancé, pas ce qui tient encore. Douze questions, sur le passé, la technique, la propriété et le prix, séparent les agences Shopify mieux que n'importe quelle référence." author: "Aashish Kaushik" published: 2026-09-15T05:00:42.688Z updated: 2026-09-15T05:00:42.878Z url: https://blog.byteinfy.com/comment-choisir-agence-shopify-12-questions-poser --- # Comment choisir une agence Shopify : 12 questions à poser ## Key takeaways - La question la plus révélatrice porte sur le travail d'il y a deux ans, tourne-t-il encore, a-t-il survécu à la fin des Scripts et de checkout.liquid, qui l'a maintenu. - Quatre questions techniques (extensions de thème, dépréciations d'API, Functions, tests) distinguent une agence qui construit proprement d'une agence qui construit vite. - La propriété du code, la documentation et ce que votre équipe pourra modifier seule se négocient avant la signature, jamais après. - Une agence qui vous dit ce qu'il ne faut pas construire exerce un jugement, et c'est ce que vous achetez. Choisir une agence Shopify se fait sur douze questions, pas sur un portfolio. Le portfolio montre ce qui a été lancé ; il ne dit pas si la boutique tourne encore, qui l'a maintenue quand Shopify a retiré les Scripts et checkout.liquid, ni ce qu'elle a laissé dans le thème. Les questions ci-dessous portent sur le passé de l'agence, sa manière de construire, ce qu'elle vous laisse à la fin et ce qu'elle facture. Les réponses sont informatives même si vous ne pouvez pas toutes les évaluer techniquement, et une agence qui y répond mal à l'aise mérite de la prudence. Cet article est écrit par une agence, ce qui vaut avertissement et engagement : ce sont les questions que nous attendons, et nous les listons parce qu'elles nous servent autant qu'à vous. > **Lisez en gardant cela en tête** > > Les douze questions ne sont pas un questionnaire à envoyer par e-mail. Elles se posent en conversation, dans l'ordre qui vous convient, et la manière de répondre compte autant que la réponse. Une hésitation sur la propriété du code en dit plus long qu'un oui rapide. ## Les questions sur le passé Trois questions sur ce que l'agence a déjà livré, parce que le passé est la seule preuve disponible. 1. Montrez-moi une boutique livrée il y a deux ans. Ouvrez-la sur votre téléphone. Vérifiez qu'elle fonctionne, mesurez sa vitesse, regardez si elle a l'air maintenue. Shopify publie en continu et retire des versions d'API selon un calendrier public ; une boutique de 2024 a traversé la fin des Scripts, le remplacement de checkout.liquid par Checkout Extensibility et plusieurs versions d'API. Demandez ce qui a dû être réparé, et qui l'a fait. 1. Quel projet s'est mal passé, et pourquoi. Toute agence en a un. Celle qui n'en trouve aucun n'a pas assez de recul ou ne veut pas en parler. Celle qui en décrit un avec ce qu'elle a changé ensuite vous montre comment elle réagira sur le vôtre. 1. Puis-je parler à un client dont le projet est terminé depuis un an. Pas un client en cours, qui a intérêt à rester en bons termes. Un client qui a vécu la livraison, la maintenance et l'après. ## Les questions techniques Quatre questions dont les réponses attendues sont précises, et qu'une agence sérieuse reconnaît immédiatement. 1. Comment intégrez-vous des fonctionnalités dans le thème. La réponse attendue est : par des sections et des blocs de l'éditeur de thème, et par des extensions d'application pour ce qui vient d'une application. Une agence qui injecte du code dans les fichiers du thème construit quelque chose que vous ne pourrez pas retirer proprement et qui bloque les mises à jour du thème. 1. Comment gérez-vous les dépréciations d'API. Il doit y avoir un processus : un inventaire de ce qui appelle quelle version, un calendrier, un responsable. « On s'en occupe quand ça arrive » signifie que vous vous en occuperez quand ça cassera. Notre article sur le versionnage des API Shopify explique ce que cette question recouvre. 1. Comment construiriez-vous une remise personnalisée. Shopify Functions. Si l'agence propose de manipuler le panier depuis le thème, ce comportement sera contourné par Shop Pay et Apple Pay. Si elle propose des Scripts, elle n'a pas suivi l'actualité de la plateforme depuis plusieurs années. 1. Comment testez-vous, et sur quoi. Pas forcément une réponse élaborée, mais une réponse : un thème dupliqué, un checkout de prévisualisation, des commandes de test depuis un téléphone, et un plan de retour arrière. Pour tout ce qui touche à l'argent, l'absence de réponse est une réponse. ## Les questions techniques et ce que les réponses révèlent | Question | Bonne réponse | Mauvais signe | | --- | --- | --- | | Intégration dans le thème | Sections, blocs, extensions d'application | Modification des fichiers du thème, scripts collés dans le layout | | Dépréciations d'API | Inventaire, calendrier, responsable | « On verra au moment venu » | | Remise personnalisée | Shopify Functions | Manipulation du panier dans le thème, Scripts | | Tests | Thème dupliqué, checkout de prévisualisation, retour arrière | « On teste en production, c'est plus rapide » | | Vitesse | Budget Core Web Vitals fixé et mesuré avant le lancement | « On installera une application de vitesse » | | Applications | Vérifier d'abord que Shopify ne le fait pas nativement | Une application par besoin | ## Les questions sur la propriété et la suite Trois questions qui décident si vous obtenez un actif ou une dépendance, et qui se règlent avant la signature. 1. Qui possède le code, et où est-il. La réponse doit être écrite dans le contrat. Les clients supposent souvent posséder tout le travail sur mesure ; les agences attendent souvent de garder leurs composants réutilisables. Les deux positions sont défendables, et le moment de les concilier est le début. Demandez aussi où vit le code : un dépôt auquel vous avez accès, pas seulement le thème publié. 1. Que pourra faire mon équipe seule. Changer une bannière, créer une page de campagne, modifier un seuil de remise, ajouter une section. Une boutique où chaque changement passe par l'agence a converti un coût unique en coût permanent. La réponse devrait citer l'éditeur de thème et une interface de configuration pour ce qui est sur mesure. 1. Que reçoit-on à la livraison, et qui maintient ensuite. Une documentation lisible par le développeur suivant, un journal des modifications du thème, et une offre de maintenance chiffrée. Un devis qui ne parle pas de maintenance décrit la moitié du coût, parce que tout ce qui est sur mesure doit suivre les changements de Shopify. ## Les questions sur le prix Deux questions sur l'argent, dont la seconde est la plus utile de toute la conversation. 1. Qu'est-ce qui est inclus, et qu'est-ce qui ne l'est pas. Deux devis pour « une boutique Shopify » peuvent décrire des projets sans rapport. Le devis doit préciser le thème, les modèles de page, le catalogue, les intégrations, les paiements et transporteurs de vos pays, les redirections si vous migrez, et le support après lancement. Notre article sur le coût d'une boutique Shopify en 2027 détaille chaque poste et compare les grilles. 1. Que me déconseilleriez-vous de construire. Une agence sans réponse vend du périmètre. Une agence qui dit « vous n'avez pas besoin de headless », « un thème du Theme Store fait ça », « cette application existe et coûte moins cher que nous » exerce un jugement, et le jugement est ce que vous achetez. Cela vaut aussi pour votre brief : si vous demandez un thème sur mesure et que la réponse honnête est qu'un thème adapté vous servirait mieux, vous voulez l'entendre avant le devis, pas après la facture. Notre comparatif thème ou sur-mesure donne les critères qu'une bonne agence devrait citer. > **Une agence qui dit oui à tout ne réfléchit pas à votre brief** > > Si chaque proposition que vous faites est acceptée sans question, l'agence est soit exceptionnellement chanceuse avec ses clients, soit en train de chiffrer ce que vous demandez plutôt que ce dont vous avez besoin. La première question qu'elle devrait vous poser porte sur votre catalogue, vos pays de vente et ce que vous vendez, pas sur votre budget. ## Les réponses qui doivent vous inquiéter Quelques schémas reviennent dans les projets qui déçoivent, et ils sont repérables dès la première conversation. Aucune question sur votre activité. Une agence qui chiffre sans savoir ce que vous vendez, à qui et dans quels pays chiffre à partir d'un modèle. L'option la plus chère par défaut. Headless quand un thème suffit, sur-mesure quand une application existe, Shopify Plus quand Advanced fait le travail. Notre article sur [Shopify Plus](/fr/shopify-plus-faut-passer-que-fait-agence-shopify) liste les cas où le plan se justifie, et ils sont moins nombreux que les agences ne le suggèrent. Un tarif horaire sans plafond. Il vous fait découvrir le total à la fin. Pour une création, un prix fixe après cadrage protège les deux parties. Le refus de parler à votre développeur actuel. Si vous en avez un, une agence qui le traite comme une menace plutôt que comme une source de contexte privilégie la relation sur le résultat. L'absence de travaux anciens encore en ligne. Soit l'agence est récente, soit les travaux anciens ne sont pas quelque chose qu'elle souhaite montrer. Les deux sont bons à savoir. ## Agence locale, freelance ou à l'étranger Les douze questions valent pour tous les profils, et le bon choix dépend de votre projet plus que d'une règle générale. Un freelance est souvent le meilleur rapport qualité-prix pour un travail défini et contenu, avec un accès direct à la personne qui le fait. Le risque est la disponibilité plus tard : celui qui a construit votre intégration n'est peut-être plus joignable quand elle doit être mise à jour. Une agence locale, à Paris, Lyon, Bruxelles, Genève ou Lausanne, partage votre langue et votre fuseau horaire, connaît Bancontact, TWINT, Mondial Relay et la TVA de votre pays sans qu'on ait à les lui expliquer, et coûte généralement plus cher à périmètre égal. Une agence à l'étranger, comme ByteInfy en Inde, coûte moins et travaille à distance, avec des démonstrations hebdomadaires et un canal écrit. Elle doit prouver qu'elle connaît votre marché, et les douze questions ci-dessus s'y appliquent avec une treizième : « qu'est-ce que Bancontact, et comment le configure-t-on ». Notre article sur [le coût d'une agence Shopify en Inde et aux États-Unis](/shopify-agency-india-usa-cost) compare les grilles. Un arrangement courant et raisonnable : une agence ou un freelance pour les projets définis, et assez de compétence interne pour gérer les changements courants et évaluer ce qui est livré. ## Cadrer le premier projet comme un test La manière de structurer le premier travail compte autant que le choix de l'agence, parce qu'elle décide de ce que vous apprenez avant de vous engager davantage. ## Un premier projet qui vous renseigne - Choisir un périmètre contenu avec une fin claire : un audit, une intégration, une page de campagne - Écrire ce que « terminé » veut dire, avec ce qui est inclus et ce qui arrive aux demandes en cours de route - Observer la réaction au premier imprévu : levé tôt avec des options, ou absorbé en silence jusqu'au retard - Comparer l'estimation au résultat, pour juger la communication plus que l'écart - Demander à voir le code, ou faire vérifier qu'il existe dans un dépôt accessible, documenté et lisible - Noter qui est votre interlocuteur après la signature, et si c'est la même personne qu'avant Le vrai livrable d'un premier petit projet est de l'information sur l'agence. Un marchand qui engage un budget important avec une équipe inconnue sur la foi d'un portfolio achète sur la preuve la moins fiable disponible. Pour la version anglaise de ce raisonnement, avec les mêmes questions dans un autre contexte de marché, notre article [engager une agence Shopify sans deviner](/hire-shopify-development-agency) est le point de départ. Les services de ByteInfy et leurs prix de départ sont sur la page [services](https://byteinfy.com/services), pour que la question 11 ait une réponse avant même l'appel. **Posez-nous ces douze questions** Envoyez votre projet en quelques lignes, et vous recevrez des réponses écrites aux douze questions de cet article, y compris ce que nous vous déconseillerions de construire. [Parler à ByteInfy](https://byteinfy.com/contact) ## FAQ ### Comment vérifier la qualité d'une agence Shopify ? Demandez à voir une boutique livrée il y a deux ans, vérifiez sa vitesse et son fonctionnement aujourd'hui, et posez les questions techniques de cet article : extensions de thème, dépréciations d'API, Shopify Functions, tests. ### Faut-il une agence Shopify Partner ou Plus Partner ? Le statut Partner est un filtre utile, pas une garantie. Il indique que l'agence a des boutiques référencées chez Shopify. ### Agence locale ou agence à l'étranger ? Une agence locale partage votre langue et votre fuseau horaire et coûte généralement plus cher. Une agence à l'étranger coûte moins et doit prouver qu'elle connaît votre marché : TVA, Bancontact, TWINT, points relais. ### Que doit contenir un devis d'agence Shopify ? Le périmètre précis (thème, modèles de page, catalogue, intégrations), un prix fixe ou un plafond, un calendrier, ce qui est hors périmètre, la durée du support après lancement, le tarif de la maintenance, et la propriété du code. ### Combien coûte une agence Shopify ? Chez ByteInfy, une boutique complète démarre à 2 000 $ et une personnalisation de thème à 1 000 $ au moment de la rédaction, en dollars américains. ### Que faire si l'agence refuse de parler de propriété du code ? C'est un signal d'alerte. La propriété, l'accès au dépôt et la documentation sont des conversations faciles au début et pénibles à la fin. Une agence qui les esquive prépare une dépendance. ### Faut-il commencer par un petit projet ? Oui quand le projet est important. Un audit, une page de campagne ou une intégration montre comment l'agence communique, estime et code, pour une fraction du risque d'une refonte complète. --- --- title: "The BFCM Checkout Readiness Checklist for Shopify" description: "Checkout is the one part of your store where a fault costs you the whole order. Here is what to verify before Black Friday, and what to stop changing before it." author: "Aashish Kaushik" published: 2026-09-14T13:00:10.504Z updated: 2026-09-14T13:00:10.508Z url: https://blog.byteinfy.com/bfcm-checkout-readiness --- # The BFCM Checkout Readiness Checklist for Shopify ## Key takeaways - Black Friday 2026 is 27 November and Cyber Week runs to 3 December, so checkout work should be finished and frozen by mid-November. - Most BFCM checkout failures are discount-logic failures, not infrastructure failures — the platform scales, your offer combinations do not. - Accelerated checkout buttons bypass parts of the cart, so every offer must be tested through Shop Pay and the wallet buttons, not just the standard flow. - A freeze date is the highest-value thing on this list, because a change shipped without observation time is the one that breaks the weekend. Checkout is the only part of a store where a fault costs you the entire order rather than degrading the experience. Everywhere else, a problem loses you some conversion at the margin. Here it loses you the transaction outright, and during BFCM it loses you the transaction at the moment you have paid the most to acquire it. Black Friday 2026 falls on Friday 27 November, with Cyber Week running to 3 December. Working backwards from that, checkout work wants to be finished and frozen by mid-November. > **What this covers** > > Checkout, cart and discount behaviour. Offer strategy and margin are a separate problem covered elsewhere in the series, as are inventory and fulfilment. ## Stop worrying about traffic The most common BFCM anxiety is capacity, and for a Shopify merchant it is largely misplaced. Platform infrastructure handling peak load is Shopify's problem, and it is one they have solved at a scale no individual merchant approaches. What actually fails during peak is merchant-controlled: - Discount logic behaving in ways nobody tested, at a volume that surfaces every edge case at once. - Apps timing out or degrading, particularly ones making synchronous third-party calls during checkout. - Third-party scripts slowing pages precisely when conversion is most valuable. - Inventory overselling, especially where bundles or gifts decrement stock nobody was forecasting. Every item on that list is yours. That is good news, because it means preparation actually helps — none of these are things you can only hope go well, and each one can be verified in advance by someone willing to sit down and test it properly. ## Discount logic is where BFCM breaks If you fix one thing on this page, fix this. Offers are built one at a time, over several weeks, each by someone thinking about that offer alone. They then meet each other in a real cart, alongside the discount code you emailed subscribers in October and forgot about, and a customer who has been carrying an abandoned cart since before any of it went live. The failure modes are consistent and all bad: ## How offer combinations fail | Failure | What the shopper sees | What it costs you | | --- | --- | --- | | Unintended stacking | A total lower than you approved | Margin, silently, on your largest baskets | | Silent non-application | A price that does not match the landing page | The order, with no error logged | | Code cannot be entered | No field on an accelerated checkout | Every wallet-button conversion in that campaign | | Gift not added | Offer promised, gift absent | Support contacts and abandonment | | Discount on the gift line | A total that reads as a bug | Trust, and usually the order | The test is dull and non-negotiable. List every discount that could be simultaneously active, including codes already in circulation. Then walk the actual customer path for each combination, on a real device. Anything you cannot make behave correctly should be made explicitly non-combinable rather than left to resolve itself at checkout under load. ## Test the accelerated checkouts specifically Shop Pay, Apple Pay, Google Pay and the other wallet buttons take a meaningful and growing share of orders, and they do not behave like the standard flow. They compress or skip steps, which means anything depending on a skipped step is invisible to a shopper using one. The practical consequences: **Discount codes need a field.** Automatic discounts apply at the platform level and survive. Codes require the shopper to type them somewhere, and accelerated buttons frequently bypass that. A BFCM campaign built entirely on a code will structurally fail for a portion of your traffic. **Cart-manipulating apps get bypassed.** Any app achieving its behaviour by rewriting the cart rather than through Shopify Functions may simply not run. This is the single strongest practical argument for Functions-based discount logic. **Upsells positioned in the cart are skipped.** If your AOV plan depends on a cart-page upsell, wallet-button shoppers never see it. Test a complete purchase through each accelerated method you have enabled, with your actual offers active. Not the standard flow with the button visible — an actual completed order. ## Checkout verification, before the freeze - A complete purchase through every enabled accelerated checkout method - Every offer combination a real shopper could reach, including old codes - The whole path on a mid-range phone on a slow connection, not desktop - A cart large enough to stress any per-order discount caps - Guest checkout, not only a logged-in account - An international address, if you sell across markets - A failed payment, to confirm the recovery path works The failed payment case is skipped almost universally and matters more during BFCM than at any other time, because card declines rise sharply when people are spending unusually, hitting limits they do not normally approach. A shopper whose first card is refused will try a second one if the path back is obvious, and will leave if it is not. ## Audit apps in October, not November Every app touching cart or checkout is a dependency and a page-weight cost. Both matter more at peak. The audit is straightforward: open a product page and the cart in DevTools, look at what third parties load, and ask of each one whether it is currently earning more than it costs. Apps trialled and abandoned are the easiest wins, and most stores have several — an uninstalled app frequently leaves its theme snippet behind and continues loading. Do this in October. Removing something load-bearing days before peak creates precisely the risk you are trying to eliminate, and there is no time to observe the consequences. > **The freeze date is the most valuable line on this page** > > Pick a date in mid-November after which no change ships to checkout, cart or discount logic. Then hold it, including against a good idea. A change made two days before Black Friday has no observation window, and the reason it feels safe is that you have not yet seen it fail. ## Inventory and the quiet oversell Checkout and inventory meet in a way that only becomes visible at BFCM volume, and the failure is expensive because it happens after you have taken the money. Ordinary selling decrements stock predictably. BFCM offer mechanics do not. A free gift consumes stock of a product whose demand is driven by sales of something else entirely. A bundle can draw down a component that is also sold separately, from two directions at once. A buy-X-get-Y drains a variant nobody is watching because it was never the product being promoted. Three things worth settling before the weekend: **Decide what happens when a gift runs out.** The options are that the offer stops applying, that it substitutes, or that it oversells. All three are defensible; discovering which one your setup does at 2am on Black Friday is not. Set a stock alert on every gift and bundle component. **Check overselling settings deliberately.** Continue-selling-when-out-of-stock is right for some products and catastrophic for others. During BFCM the volume compresses weeks of ordering into hours, so a setting that was harmless all year can produce hundreds of unfulfillable orders before anyone notices. **Reserve stock for the offers you have advertised.** If an offer is the centrepiece of a campaign, the inventory backing it should not also be freely sellable through every other route. > **The cancellation you choose beats the one you are forced into** > > If you do oversell, cancelling early and communicating clearly costs far less than a fulfilment failure discovered a week later. Decide in advance who makes that call and how quickly, because during peak the instinct is to hope it resolves itself. It does not. ## The week itself Preparation is most of it, but a few things belong to the days themselves. **Watch order-level margin, not just revenue.** Revenue during BFCM looks good almost regardless. The number that reveals a discount logic problem is what you earned per order, and a sharp move there is the earliest signal something is applying that should not be. **Monitor the proportion of orders receiving each offer.** If an offer that applied to 30% of orders on Friday applies to 3% on Saturday, something changed and nobody was told. **Keep a rollback path.** Know how to disable each offer quickly and who has access to do it. During peak, the correct response to a misbehaving discount is usually to turn it off, not to debug it live. **Write down what broke, while it is happening.** Peak weekends generate a dozen small discoveries that everyone is certain they will remember and nobody does. A running note costs nothing and is the entire basis of next year's preparation, which otherwise restarts from memory and repeats the same faults. **Have someone actually watching.** Automated alerting is better than nothing, but the failures that hurt most are the silent ones that no alert is configured for. A person placing a test order twice a day catches things monitoring does not. For offer structure and the margin arithmetic behind it, see the [BFCM 2026](/series/bfcm-2026) series. Checkout mechanics beyond peak season are covered in [checkout and payments](/category/checkout-payments), and the discount implementation detail in [promotions and offers](/category/promotions-offers). **Want your checkout stress-tested before the freeze?** ByteInfy audits and builds Shopify checkout and discount logic — offer combinations, Functions and the accelerated checkout paths most stores never test. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Will my Shopify store handle Black Friday traffic? Shopify's own infrastructure handles peak traffic and it is not a useful thing for a merchant to worry about. ### When should I stop making changes before BFCM? Mid-November for anything touching checkout, discounts or the cart. ### Do discount codes work with accelerated checkout buttons? Automatic discounts applied at the platform level do. Discount codes require a field the shopper can type into, and accelerated buttons frequently bypass that step. ### What is the most common BFCM checkout problem? Two offers meeting in one cart in a way nobody tested. Offers get built independently over several weeks, then encounter each other alongside codes still circulating from earlier campaigns. ### Should I turn off apps before BFCM? Audit rather than disable indiscriminately. Any app that is not currently earning its place should be removed, because each one adds page weight and a failure mode. --- --- title: "Migration WooCommerce vers Shopify sans perdre son SEO" description: "Une migration WooCommerce vers Shopify perd du SEO quand les URL changent sans redirections, quand le contenu s'appauvrit et quand la bascule est improvisée. Voici le plan qui évite les trois." author: "Aashish Kaushik" published: 2026-09-14T05:00:17.073Z updated: 2026-09-14T05:00:17.095Z url: https://blog.byteinfy.com/migration-woocommerce-vers-shopify-sans-perdre-son-seo --- # Migration WooCommerce vers Shopify sans perdre son SEO ## Key takeaways - Les positions se perdent sur les URL, pas sur la plateforme ; un plan de redirections 301 complet, ancienne URL vers nouvelle, est le cœur d'une migration réussie. - WooCommerce et Shopify n'ont pas la même structure (/produit/ et /categorie-produit/ contre /products/ et /collections/), la correspondance se prépare dans un tableau avant de déplacer quoi que ce soit. - Les attributs WooCommerce deviennent des variantes ou des métachamps Shopify, les clients sont importés sans mot de passe, et les images changent d'URL. - Le jour de la bascule, les redirections doivent être en place avant le changement de DNS, et Search Console surveillé chaque jour pendant un mois. Une migration WooCommerce vers Shopify ne perd du SEO que pour trois raisons : des URL qui changent sans redirection, un contenu qui s'appauvrit dans le transfert, et une bascule improvisée qui laisse Google découvrir des 404 pendant des jours. Chacune se prévient avec un plan écrit avant de déplacer le premier produit. Ce plan tient dans un tableau de correspondance, une liste de redirections 301 et une checklist de bascule, et c'est ce que cet article décrit, dans l'ordre d'exécution. Il s'adresse à un marchand français, belge ou suisse dont la boutique WooCommerce a des positions à protéger, un catalogue de quelques centaines à quelques milliers de produits, et souvent une TVA multi-pays et des transporteurs locaux à reconfigurer au passage. ## Pourquoi les migrations perdent des positions Les moteurs de recherche indexent des URL, pas des boutiques. Quand une URL disparaît, la position qu'elle portait disparaît avec elle, sauf si une redirection 301 transmet le signal à sa remplaçante. WooCommerce et Shopify n'ont pas la même structure. Un produit WooCommerce vit typiquement sous /produit/nom-du-produit/ (ou /product/ selon la langue de l'installation), une catégorie sous /categorie-produit/nom/, un article sous /nom-de-l-article/ ou /blog/nom/. Shopify impose /products/nom, /collections/nom et /blogs/nom-du-blog/nom-de-l-article. Aucune URL ne survit telle quelle, et Shopify ne permet pas de conserver la structure WordPress. Le contenu est la deuxième cause. Les descriptions longues, les onglets, les FAQ produit, le texte des catégories : une migration pressée les laisse derrière, et la page Shopify se retrouve plus mince que la page WooCommerce qu'elle remplace. Google le voit. La troisième cause est la bascule elle-même. Un changement de DNS avant que les redirections soient importées, un sitemap qui pointe encore vers les anciennes URL, un robots.txt de boutique en construction laissé actif : chacun coûte des jours d'exploration perdus. Notre article sur [la migration WooCommerce vers Shopify](/woocommerce-shopify-migration-india), écrit pour un autre marché, couvre les mêmes mécanismes avec des contraintes locales différentes. ## L'inventaire : tout ce qui a une URL Avant de migrer, listez chaque URL de la boutique WooCommerce qui reçoit du trafic ou des liens, et notez ce qu'elle devient. L'export se fait avec un crawl de la boutique (un outil de crawl SEO) croisé avec Search Console (les pages qui reçoivent des impressions) et Google Analytics (les pages qui reçoivent des sessions). Le résultat est un tableau : URL actuelle, type (produit, catégorie, page, article, image, PDF), trafic sur douze mois, liens entrants, et nouvelle URL prévue. Ce tableau révèle des choses que le marchand a oubliées : des pages de destination de campagnes anciennes, des articles de 2018 qui rankent encore, des PDF de notices liés depuis des forums, des URL de tags et de filtres que WooCommerce indexait sans qu'on le sache. ## Correspondance des URL WooCommerce vers Shopify | Type WooCommerce | URL type WooCommerce | URL Shopify | Remarque | | --- | --- | --- | --- | | Produit | /produit/nom/ | /products/nom | Le handle Shopify peut reprendre le slug WordPress | | Catégorie | /categorie-produit/nom/ | /collections/nom | Sous-catégories aplaties, une collection par niveau utile | | Étiquette produit | /etiquette-produit/nom/ | /collections/nom ou noindex | Migrer seulement les étiquettes qui rankent | | Article de blog | /nom-article/ ou /blog/nom/ | /blogs/actualites/nom | Un seul blog Shopify suffit dans la plupart des cas | | Page | /nom-page/ | /pages/nom | Mentions légales, CGV, à propos | | Images | /wp-content/uploads/… | CDN Shopify | Rediriger seulement les images qui reçoivent du trafic Google Images | | Paramètres de filtre | /categorie/?filter_… | Non migrés | Rediriger vers la collection parente | Deux décisions structurantes à ce stade. La première : conserver les slugs. Si le produit WooCommerce s'appelle /produit/veste-lin-beige/, le produit Shopify doit s'appeler /products/veste-lin-beige, ce qui rend la redirection prévisible et conserve le mot-clé dans l'URL. La seconde : aplatir la hiérarchie des catégories. Shopify n'a pas de sous-collections ; une catégorie « Femme > Vestes > Lin » devient une collection « vestes-lin-femme » et la navigation reconstruit la hiérarchie. ## Les redirections 301 : la liste, pas les règles Shopify gère les redirections par liste explicite, une ancienne URL vers une nouvelle, importée en CSV. Il ne gère pas les redirections par motif, ce qui change la méthode. Sur WordPress, une règle « tout ce qui commence par /produit/ va vers /products/ » suffisait. Sur Shopify, chaque URL a sa ligne. Pour deux mille produits, cinq cents articles et cent pages, c'est un fichier de deux mille six cents lignes, généré à partir du tableau d'inventaire, pas écrit à la main. Trois règles de qualité. Une redirection va toujours vers la page la plus proche, pas vers l'accueil ; une redirection massive vers l'accueil est traitée par Google comme un 404 déguisé. Les chaînes sont interdites : si /ancien/ redirigeait déjà vers /moins-ancien/ sur WordPress, la nouvelle redirection part de /ancien/ directement vers Shopify. Et les URL avec et sans barre oblique finale, avec et sans www, sont couvertes ; Shopify normalise une partie, pas tout. Les redirections s'importent dans la boutique Shopify avant la bascule DNS. Elles n'ont aucun effet tant que le domaine pointe vers WordPress, et elles doivent être actives dès la première seconde où il pointe vers Shopify. > **Testez les redirections avant la bascule** > > Sur l'URL temporaire de la boutique Shopify (nom.myshopify.com), chaque redirection importée est testable. Prenez les cent URL qui reçoivent le plus de trafic dans le tableau, testez-les une par une, et corrigez le fichier avant d'importer le reste. Une erreur de format dans le CSV est invisible jusqu'au jour de la bascule. ## Les données : produits, variantes, clients, commandes Les données WooCommerce ne rentrent pas telles quelles dans Shopify, et les différences de modèle décident de ce qui se perd. Les produits et les variations. Shopify accepte jusqu'à trois options par produit (taille, couleur, matière) et un nombre limité de variantes. Une boutique WooCommerce avec quatre attributs de variation doit en fusionner ou en séparer. Les attributs descriptifs (composition, origine, entretien) deviennent des métachamps, que le thème affiche dans des blocs dédiés. Le tableau d'inventaire porte cette correspondance, produit par produit. Le contenu produit. Description courte et longue, onglets, FAQ, tableaux de tailles : tout ce qui vivait dans des extensions WooCommerce doit trouver sa place dans la description Shopify ou dans des métachamps. C'est le poste où le contenu s'appauvrit quand personne ne le surveille. Les clients. Ils s'importent avec leurs coordonnées, leurs adresses et, si vous le décidez, leurs commandes passées. Aucun mot de passe ne se transfère, sur aucune plateforme. Le processus prévoit un e-mail d'invitation au moment de la bascule, formulé comme une amélioration plutôt qu'une réinitialisation. Les commandes. Leur import sert à l'historique client et au service après-vente, pas à la comptabilité, qui reste dans le système d'origine pour l'exercice en cours. Les images. Elles sont téléchargées sur le CDN de Shopify et changent d'URL. Le texte alternatif suit si l'export le contient ; sinon, c'est le moment de l'écrire. ## Le thème, la TVA et les transporteurs Une migration change de plateforme, pas seulement d'hébergement, et les réglages de vente doivent être refaits. Le thème. Le design WooCommerce ne se transfère pas. Soit un thème du Theme Store adapté à votre charte, soit un thème sur mesure. Le choix se fait sur les mêmes critères que pour une création, et notre article sur [le design d'une boutique migrée](/shopify-store-migration-design) explique pourquoi une migration est le bon moment pour ne pas tout reproduire. La TVA. Les taux par pays de l'UE, le guichet unique OSS, les prix TTC : ce qui était configuré dans une extension WooCommerce se reconfigure dans les paramètres de taxes de Shopify. Une boutique française qui vend en Belgique et en Suisse a trois régimes à régler ; nos articles sur [Shopify en Belgique](/fr/shopify-belgique-bancontact-mondial-relay-tva-frais) et [Shopify en Suisse](/fr/shopify-suisse-twint-chf-tva-points-regler) détaillent chacun. Les transporteurs. Colissimo, Mondial Relay, Chronopost, bpost : les extensions WooCommerce ont leur équivalent en applications Shopify, avec un sélecteur de points relais à retester au checkout. Les tarifs par zone se ressaisissent. Les paiements. Shopify Payments remplace la passerelle WooCommerce, avec Bancontact et TWINT selon le pays de la boutique. Les abonnements clients, si vous en aviez, demandent une application dédiée et une migration des moyens de paiement enregistrés, qui n'est pas toujours possible. ## Le jour de la bascule La bascule se fait dans une fenêtre calme, dans un ordre précis, et rien n'est laissé à découvrir le lendemain. ## Bascule WooCommerce vers Shopify - Redirections 301 importées et testées sur les cent URL les plus visitées - Catalogue, clients et contenu vérifiés ligne par ligne contre la source sur un échantillon - Titres, métadescriptions et textes de collection en place, pas seulement les produits - Mot de passe de boutique en construction retiré et robots.txt vérifié - Sitemap Shopify accessible et soumis dans Search Console dès la bascule - DNS modifié dans une fenêtre de faible trafic, avec un TTL réduit la veille - WordPress conservé en lecture seule sur un sous-domaine pendant un mois, pour vérifier - E-mail d'invitation aux clients envoyé après vérification du checkout, pas avant - Suivi Search Console quotidien pendant quatre semaines : couverture, 404, Core Web Vitals Le mois qui suit est la partie de la migration que les devis oublient. Search Console remonte les 404 que l'inventaire a manqués (il y en a toujours), les erreurs de redirection et les pages que Google met du temps à réindexer. Chaque 404 reçoit sa redirection dans la semaine. Les positions bougent pendant quelques semaines, puis se stabilisent ; une baisse temporaire pendant la réindexation est normale, une baisse qui dure au-delà signale des URL oubliées ou du contenu appauvri. ## Ce qui se gagne au passage Une migration bien faite est aussi l'occasion de corriger ce que WooCommerce avait laissé s'accumuler. Les doublons de contenu entre catégories, les pages de tags indexées, les paramètres de filtre crawlables : ils ne sont pas migrés, et c'est une amélioration. Les descriptions produit du fournisseur, copiées sur cinquante boutiques, peuvent être réécrites pour les produits qui font le chiffre. Les données structurées Product et BreadcrumbList, souvent absentes ou incomplètes sur WooCommerce, sont fournies par le thème Shopify. La vitesse, qui dépendait de l'hébergement et des extensions, dépend désormais du thème et des applications, avec un contrôle plus direct. Pour le suivi après migration, notre [checklist SEO Shopify](/fr/checklist-seo-shopify-2027-25-points-qui-comptent) donne les 25 points à vérifier une fois la boutique stable, et le [guide SEO Shopify](/shopify-seo-guide-2026) le contexte complet. Chez ByteInfy, une migration de catalogue et de clients avec redirections démarre à 1 500 $ au moment de la rédaction, le thème et les intégrations étant chiffrés à part. La page [migration Shopify](https://byteinfy.com/services/shopify-migration) décrit le processus, dont le suivi Search Console après bascule. **Votre boutique WooCommerce a des positions à protéger** Envoyez l'URL de la boutique et le nombre de produits, et vous recevrez un plan de migration écrit avec l'inventaire des URL, les redirections et la bascule, à prix fixe. [Parler à ByteInfy](https://byteinfy.com/contact) ## FAQ ### Perd-on du SEO en passant de WooCommerce à Shopify ? Pas si les redirections 301 couvrent chaque URL ancienne, si les titres, descriptions et contenus sont conservés et si la bascule est propre. ### Comment rediriger les anciennes URL WooCommerce ? Avec les redirections d'URL de Shopify, importées en masse par fichier CSV. Chaque produit, catégorie, page et article a une ligne, ancienne URL vers nouvelle. ### Les clients gardent-ils leur compte ? Les clients sont importés avec leurs coordonnées et leur historique, mais aucun mot de passe ne peut être transféré, quelle que soit la plateforme. ### Que deviennent les attributs et variations WooCommerce ? Les variations deviennent des variantes Shopify (jusqu'à trois options par produit) et les attributs descriptifs deviennent des métachamps. La correspondance se prépare dans le tableau de migration, produit par produit. ### Combien de temps garder les redirections ? Indéfiniment. Les liens externes vers vos anciennes URL ne disparaissent pas, et Google continue de les visiter longtemps. Les supprimer après quelques mois recrée les 404 que la migration avait évités. ### Combien coûte une migration WooCommerce vers Shopify ? Chez ByteInfy, une migration de catalogue et de clients avec redirections démarre à 1 500 $ au moment de la rédaction. Le thème, les intégrations ERP et les configurations multi-boutiques se chiffrent après cadrage. ### Faut-il migrer le blog WordPress ? Oui si ses articles apportent du trafic. Ils passent dans le blog Shopify avec des redirections vers les nouvelles URL (/blogs/nom/article). --- --- title: "Shopify Scripts Are Gone: Migrating to Functions" description: "Scripts ran in a sandbox on Shopify's servers and could be edited in the admin. Functions are compiled WebAssembly modules deployed as an app. That difference shapes the whole migration." author: "Aashish Kaushik" published: 2026-09-13T13:01:02.073Z updated: 2026-09-13T13:01:02.113Z url: https://blog.byteinfy.com/shopify-scripts-to-functions --- # Shopify Scripts Are Gone: Migrating to Functions ## Key takeaways - Legacy Shopify Scripts stopped running on 30 June 2026, so this is a completed deprecation rather than an upcoming one. - Functions are compiled WebAssembly deployed through an app, which means version control and a deployment step where Scripts had neither. - The migration is rarely a translation — Functions have a different execution model, and logic that worked in a Script often needs restructuring rather than porting. - Shipping and payment customisations migrate to their own Function APIs, not to the discount one, and are commonly forgotten. Shopify Scripts stopped running on 30 June 2026. If you are reading this because something broke, the answer is that nothing broke — a deprecation completed on schedule, and the failure mode was silence rather than an error. That silence is the reason this deprecation caused more damage than it should have. A Script that stops running does not throw. Discounts simply stop applying, orders complete at full price, and unless someone was watching order-level margin closely, nothing surfaces for weeks. > **If you are unsure whether this affects you** > > Check whether your store ever had Script Editor installed, and look at whether any expected automatic discount is currently failing to apply. Absence of errors is not evidence that nothing is wrong here. ## What actually changed Scripts and Functions solve the same problem with fundamentally different architecture, and understanding the difference explains why migration is more than a translation exercise. ## Scripts and Functions compared | Shopify Scripts | Shopify Functions | | --- | --- | | Language | Ruby | Rust or JavaScript, compiled to WebAssembly | | Availability | Plus only | Discount Functions available beyond Plus | | Editing | In the admin, via Script Editor | Code in a repository, built and deployed | | Deployment | Save and it is live | Build, deploy through an app, then configure | | Execution | Sandboxed at runtime | WebAssembly at defined extension points | | Version control | None | Whatever your repository provides | | Performance | Variable | Fast and bounded by design | The two rows that change how teams work are editing and deployment. Scripts could be modified by anyone with admin access, in the browser, and were live on save. That was genuinely convenient and genuinely dangerous — there was no history, no review, and no way to know who changed pricing logic or when. Functions invert this. You get version control, review and repeatability. You also get a deployment step, which means the merchant who used to adjust a discount rule themselves on a Friday afternoon now files a ticket. ## The migration is restructuring, not porting The common expectation is that a Script can be translated line by line. It usually cannot, because the execution model differs. A Script ran with broad access and could iterate over the cart making decisions procedurally. A Function receives a defined input, produces a defined output, and runs at a specific extension point with limits on what it can see and how long it may take. Logic written against the first model frequently needs to be re-expressed rather than converted. Three patterns that tend to need rethinking: **Multi-pass cart logic.** Scripts that walked the cart repeatedly, adjusting as they went, need restructuring into a single evaluation producing a set of discount operations. **Decisions requiring data the Function cannot see.** A Script that consulted broad shop state may need that data supplied through metafields, which the Function receives as input. This is often the largest piece of the work and is easy to underestimate. **Interdependent Scripts.** Stores commonly ran several Scripts that assumed a particular execution order. Functions do not offer the same implicit sequencing, and overlapping logic must be made explicit. ## Do not forget shipping and payment This is the most common oversight in the migration, and it is expensive because it is discovered at checkout. Scripts covered three areas: line item discounts, shipping rates, and payment method behaviour. Merchants migrating tend to focus on discounts, because that is the visible commercial feature, and forget that their Script also hid a payment method from certain customers or renamed a shipping rate. Each of these has its own Function API — discounts, delivery customisation and payment customisation are separate extension points, not variations of one. Audit for all three before scoping the work: ## Audit before you scope - Every discount rule the Script applied, including edge cases nobody documented - Any shipping rate hidden, renamed or reordered - Any payment method hidden or reordered by customer, cart or address - Conditions referencing customer tags, metafields or order history - Behaviour depending on the order in which multiple Scripts ran - Anything only triggered seasonally, which will not be visible in a current audit That final item catches teams out. A Script handling a Christmas promotion is invisible in a July audit and absent when November arrives, which is the worst possible moment to discover it. ## Who can change discount logic now This is an organisational consequence that deserves explicit planning, because it is the change merchants feel most. Under Scripts, a merchant could adjust a threshold themselves. Under Functions, the logic is compiled. There are two ways to restore merchant control, and choosing between them should be a deliberate decision made during the migration rather than discovered afterwards: **Configuration through metafields.** Build the Function to read its parameters — thresholds, product sets, dates — from metafields, and expose those in the admin. The logic is fixed; the numbers are editable. This covers most real needs and is the right default. **A full app interface.** Build an embedded admin interface for configuring offers. More work, more flexibility, and effectively what commercial discount apps sell. If you migrate a Script into a hardcoded Function without either, you will have converted every future pricing tweak into a development ticket. That is a common and avoidable outcome. ## A migration sequence that does not break checkout 1. Inventory everything. Every Script, every rule, every edge case. Interview whoever configured them, because the code frequently does not explain the intent. 2. Write down the intended behaviour in plain language, separately from the code. This is the specification you will test against, and it will expose rules nobody can justify any more. 3. Decide what stays. Migration is a good moment to delete rules that exist because of a promotion in 2023. Porting logic nobody wants is pure cost. 4. Build the Functions, with configuration exposed through metafields where merchants need control. 5. Test combinations exhaustively, including accelerated checkouts and every case where two rules could apply at once. 6. Deploy and verify on real orders, watching order-level margin for the first week rather than assuming success. > **Test with real historical carts** > > Take twenty genuine past orders that the old Scripts affected and confirm the new Functions produce the same outcome. This catches the edge cases that a specification written from memory will miss, and it is far cheaper than finding them in production. ## The failure modes to watch for after deploying A Function that deploys successfully is not a Function that behaves correctly, and the ways these go wrong are specific enough to be worth listing. **Silent non-application.** The most common and the most costly. The Function runs, produces no discount operation because a condition was subtly wrong, and the order completes at full price. There is no error anywhere. The only signal is margin that looks slightly too good, which nobody investigates. **Over-application.** The inverse, and easier to spot because someone eventually notices the revenue. Usually caused by a condition that was implicitly scoped in the old Script by surrounding code and is now evaluated independently. **Correct in the cart, wrong at checkout.** Rarer with Functions than with cart-manipulating apps, but still possible where storefront messaging is computed separately from the actual discount. If your theme displays a calculated saving, that calculation is a second implementation of the same logic and the two will drift. **Timeouts under load.** Functions run within bounded execution limits. Logic that is comfortable on a five-item cart may not be on a fifty-item one, and the carts that break are disproportionately your largest orders. **Metafield drift.** If you exposed configuration through metafields, someone will eventually enter a value the Function does not handle — a blank threshold, a deleted product reference, a date in the wrong format. Validate inputs inside the Function and decide explicitly what it does with nonsense, because the default is usually to apply nothing. > **Instrument before you need it** > > Add a monitor on the proportion of orders receiving each expected discount, and alert when it moves sharply. This is the only reliable defence against silent non-application, and it costs an afternoon. Every merchant who lost money to the Scripts deprecation lost it because nothing was watching this number. ## What you gain, honestly The migration is unwelcome work, but the destination is better in ways worth stating. Functions are faster and more predictable than Scripts were, and they run within defined limits rather than variably. Discount Functions extend beyond Plus, which widens what non-Plus merchants can do. And the deployment model, whatever it costs in convenience, means pricing logic now lives in version control with a history — which is a substantial improvement over a system where anyone with admin access could silently change how your store charges people. The convenience loss is real and should be mitigated rather than denied. Build for configuration, not just for behaviour, and the merchant keeps the control that mattered while you keep the review that was missing. For the wider development picture on Shopify, see [Shopify development](/category/shopify-development). Discount strategy and mechanics are covered in [promotions and offers](/category/promotions-offers), and checkout behaviour in [checkout and payments](/category/checkout-payments). **Still carrying Script-era discount logic?** ByteInfy migrates Shopify discount, shipping and payment logic to Functions — with configuration exposed so your team keeps control. [Start a project](https://byteinfy.com/#contact) ## FAQ ### When exactly did Shopify Scripts stop working? Legacy Shopify Scripts stopped running on 30 June 2026. ### What is the difference between Shopify Scripts and Shopify Functions? Scripts were Ruby, edited in the admin through the Script Editor, available only to Plus merchants, and executed in a sandbox at runtime. ### Do I need to be on Shopify Plus to use Functions? Discount Functions are available beyond Plus, which is a meaningful widening compared with Scripts. Some extension points and higher input limits remain tied to Plus. ### Can I edit a Function in the Shopify admin like I could a Script? No, and this is the largest workflow change. A Function is code in a repository that must be built and deployed. ### What happens to my discounts if I do nothing? They stopped applying on 30 June 2026. --- --- title: "Réductions personnalisées avec Shopify Functions (fin des Scripts)" description: "Les Shopify Scripts ont disparu et Shopify Functions les remplace sur tous les plans. Ce que vous pouvez construire en réductions personnalisées, ce qui reste hors de portée, et comment se passe un projet." author: "Aashish Kaushik" published: 2026-09-13T05:00:12.771Z updated: 2026-09-13T05:00:12.794Z url: https://blog.byteinfy.com/reductions-personnalisees-avec-shopify-functions-fin-scripts --- # Réductions personnalisées avec Shopify Functions (fin des Scripts) ## Key takeaways - Shopify Functions remplace les Scripts pour la logique de réduction, sur tous les plans et pas seulement Plus ; les marchands Plus devaient migrer avant 2025. - Paliers, remises par groupe de clients, exclusions par collection, cadeau automatique et remise selon le moyen de paiement se construisent en Functions sans modifier le thème. - Une Function s'exécute dans le checkout, y compris avec Shop Pay et Apple Pay, ce que les manipulations de panier côté thème ne garantissaient jamais. - Les Functions ont des limites strictes (pas d'appel réseau, taille et temps d'exécution bornés) qui imposent d'écrire les règles avant le code. Les réductions personnalisées sur Shopify se construisent aujourd'hui avec Shopify Functions, sur tous les plans, et plus avec les Scripts, qui sont dépréciés et que les marchands Plus devaient abandonner avant 2025. Une Function est un petit programme que Shopify exécute dans le checkout pour décider quelle remise s'applique, à qui, et dans quelles conditions. Elle couvre les paliers, les remises par groupe de clients, les exclusions, les cadeaux automatiques et les remises liées au moyen de paiement, avec deux avantages que les anciennes approches n'avaient pas : elle fonctionne dans les checkouts accélérés, et elle ne touche pas au thème. Cet article s'adresse au marchand qui a une règle de remise en tête et veut savoir si elle est faisable, à celui qui a encore des Scripts à migrer, et à celui qui hésite entre une application et un développement sur mesure. ## Pourquoi les Scripts ont disparu et ce qui les remplace Les Scripts étaient des programmes Ruby réservés à Shopify Plus, exécutés côté serveur pour modifier les prix, la livraison et les moyens de paiement. Ils ont été remplacés parce qu'ils ne tenaient pas dans le nouveau checkout. Le nouveau checkout de Shopify, avec Checkout Extensibility en remplacement de checkout.liquid, repose sur des composants que Shopify contrôle et sur des points d'extension déclarés. Les Scripts, qui modifiaient librement les objets de la commande, n'entraient pas dans ce modèle. Shopify Functions est la réponse : une logique compilée en WebAssembly, exécutée dans un environnement isolé, avec une entrée définie (le panier, le client, les métachamps) et une sortie définie (les remises à appliquer). Trois différences comptent pour un marchand. Les Functions sont disponibles sur tous les plans pour les réductions, la livraison et la validation, là où les Scripts exigeaient Plus. Elles s'exécutent dans tous les checkouts, y compris Shop Pay et Apple Pay. Et elles sont installées via une application, ce qui leur donne une interface de configuration dans l'administration plutôt qu'un éditeur de code. Notre guide [des Scripts aux Functions](/shopify-scripts-to-functions) détaille la migration technique ; ici, le sujet est ce que vous pouvez construire. ## Ce qu'une Function de réduction sait faire Une Function de réduction lit le panier et le client, applique vos règles, et renvoie une ou plusieurs remises. À l'intérieur de ce cadre, presque toute règle exprimable en une phrase se construit. Les paliers par quantité ou par montant. « 10 % à partir de trois articles, 15 % à partir de cinq », ou « 20 euros de remise à partir de 150 euros de panier ». Notre article sur [les remises par paliers](/shopify-tiered-discounts) montre les variantes courantes, et [la remise par volume sans application](/shopify-volume-discount-without-app) explique ce que Shopify fait nativement avant d'aller plus loin. Les remises par client. Un pourcentage pour les clients avec un tag « pro », un tarif pour les membres d'un programme, une remise de bienvenue pour un client sans commande précédente, si cette information est portée par un tag ou un métachamp client. Les exclusions. Pas de remise sur les nouveautés, sur une marque précise, sur les produits déjà soldés. Une Function lit les collections, les tags et les métachamps produit et exclut ce qui doit l'être. Les cadeaux et les offres croisées. Un produit offert à partir d'un montant, un deuxième article à moitié prix, une remise sur un accessoire quand le produit principal est dans le panier. Le cas du [« un acheté, un offert »](/how-to-set-up-bogo-on-shopify) est le plus demandé. Les remises selon le moyen de paiement ou la livraison. Une remise pour le paiement anticipé, la livraison offerte en point relais Mondial Relay au-dessus d'un seuil, des frais de port réduits pour les clients d'une zone. Ces cas mêlent Function de réduction et Function de livraison. ## Besoin de réduction et façon de le construire | Besoin | Shopify natif | Application publique | Function sur mesure | | --- | --- | --- | --- | | Code promo simple ou remise automatique sur une collection | Oui | Inutile | Inutile | | Paliers par quantité ou par montant | Partiel | Oui | Oui, règles exactes | | Remise par tag ou métachamp client | Non | Selon l'application | Oui | | Exclusions fines (tags, métachamps, marque) | Partiel | Selon l'application | Oui | | Cadeau automatique à partir d'un seuil | Non | Oui | Oui | | Remise selon le moyen de paiement | Non | Rare | Oui | | Règles combinées propres à votre marque | Non | Rarement | Oui | La colonne de gauche mérite un test avant tout projet. Les remises automatiques et les codes promo de Shopify couvrent plus de cas qu'on ne le pense, avec des conditions par montant, par quantité et par groupe de clients. Le projet Function commence là où ces conditions s'arrêtent. ## Ce qu'une Function ne peut pas faire Les Functions ont des limites strictes, et un projet qui les ignore se découvre au moment du test. Pas d'accès réseau. Une Function ne peut pas interroger votre CRM, votre ERP ou un service de calcul. Tout ce dont elle a besoin doit être dans Shopify avant le checkout : tags, métachamps, attributs de panier. Si votre règle dépend d'une donnée externe, il faut d'abord la synchroniser dans Shopify. Pas d'historique. Une Function voit le panier et le client courant, pas les commandes passées. « 10 % pour les clients qui ont commandé trois fois » suppose qu'un processus ait posé un tag ou un métachamp « fidèle » sur le client au préalable, par exemple avec Shopify Flow. Une taille et un temps d'exécution bornés. La logique doit rester simple et déterministe. Ce n'est pas une contrainte pour des règles de remise ; c'en est une pour des calculs qui parcourent des milliers de lignes. Des combinaisons encadrées. Shopify décide ce qui peut se cumuler par classe de réduction (produit, commande, livraison), et chaque réduction déclare ses combinaisons. Une Function ne contourne pas ces règles ; elle les suit. Notre article sur [l'empilement des réductions](/shopify-discount-stacking) explique le mécanisme, et [les limites des Shopify Functions](/shopify-functions-limitations) fait la liste complète. > **Écrivez la règle en français avant d'écrire une ligne de code** > > La majorité des projets de réduction qui dérapent le font parce que la règle n'était pas écrite. « 15 % pour les pros » ne dit pas si la remise s'applique aux produits soldés, si elle se cumule avec un code, ni ce qui se passe quand un pro a aussi un code de bienvenue. Une page de règles avec des exemples de panier, validée avant le développement, est le livrable le plus rentable du projet. ## Application publique ou Function sur mesure La question revient à chaque projet, et la réponse dépend de la distance entre votre règle et ce que les applications font déjà. Une application publique de réductions ou de paliers convient quand votre règle est standard, quand vous voulez une interface prête aujourd'hui, et quand l'abonnement mensuel reste raisonnable par rapport au chiffre d'affaires concerné. Vérifiez qu'elle applique la remise par Function et non par manipulation du panier dans le thème ; la seconde méthode est contournée par les checkouts accélérés et ajoute un script sur chaque page. Une Function sur mesure convient quand la règle est propre à votre marque, quand plusieurs règles doivent s'articuler, ou quand vous refusez qu'une application tierce injecte quoi que ce soit dans le thème. Le coût est un développement unique plutôt qu'un abonnement, et l'interface de configuration est construite pour vos règles, pas pour celles de tout le monde. Chez ByteInfy, une Function ou une extension de checkout se chiffre entre 1 500 et 3 000 $ au moment de la rédaction, avec l'interface de configuration dans l'administration. La page [extensions de checkout et Shopify Functions](https://byteinfy.com/services/shopify-checkout-extensions) décrit le cadrage. ## Comment se passe un projet de Function de réduction Un projet de Function se déroule en quatre étapes, et la première est la plus longue. Les règles. Elles sont écrites en français courant avec des exemples de panier, y compris les cas limites : que se passe-t-il avec un produit soldé, avec deux remises applicables, avec un client qui a un tag et un code. Cette page est validée avant tout développement. Le développement. La Function est construite dans une application personnalisée installée sur votre boutique, avec une interface de configuration dans l'administration : seuils, pourcentages, collections exclues, tags de clients. Votre équipe pourra modifier ces paramètres sans développeur. Les tests. Sur un checkout de prévisualisation, avec les paniers des exemples, dans le flux standard et avec Shop Pay. Les combinaisons avec vos codes promo existants sont testées explicitement. La mise en service. Activée dans une période calme, avec un moyen de la désactiver en un clic. Une Function de réduction touche à l'argent ; le retour arrière doit être prêt avant la mise en ligne. ## Migrer des Scripts vers les Functions : les pièges Une boutique Plus qui avait des Scripts a probablement plusieurs règles à réécrire, et certaines ne se traduisent pas mot pour mot. ## Migration Scripts vers Functions - Inventorier chaque Script en production, avec sa règle en français et un exemple de panier - Identifier les Scripts qui dépendaient de données non disponibles dans une Function (historique, appels externes) - Prévoir le tagging ou les métachamps qui remplaceront ces données, par exemple via Shopify Flow - Reconstruire les règles de cumul, qui ne se comportent pas comme dans les Scripts - Tester chaque règle dans le flux standard et dans Shop Pay - Comparer les totaux d'un échantillon de commandes réelles entre l'ancien et le nouveau comportement - Désactiver les Scripts seulement après la validation, en gardant l'inventaire Le piège le plus courant concerne l'empilement. Les Scripts permettaient des cumuls que Shopify ne permet plus par défaut, et un marchand qui offrait « 10 % pro » plus « livraison offerte » plus « code de bienvenue » doit décider explicitement ce qui se cumule, dans le nouveau cadre. Le second piège concerne l'ordre d'application : les Scripts s'exécutaient dans un ordre écrit, les Functions selon les classes de réduction et les règles de combinaison. Pour les marchands qui se demandent si Plus reste nécessaire une fois les Scripts partis, notre article [faut-il passer à Shopify Plus](/fr/shopify-plus-faut-passer-que-fait-agence-shopify) répond : pour les réductions, non. ## Préparer une opération commerciale avec des Functions Une Function de réduction se teste avant une opération, pas pendant. Le calendrier commercial français et belge (soldes d'hiver et d'été, Black Friday, fêtes) concentre les remises sur des périodes courtes, où une règle mal réglée coûte cher en quelques heures. Trois précautions : tester les combinaisons avec les codes de l'opération une semaine avant, vérifier que la page de campagne annonce exactement ce que la Function applique, et garder le bouton de désactivation à portée de main. Le message affiché au client est le second sujet. Une Function applique la remise ; elle n'affiche rien sur la page produit ou dans le panier. L'affichage (« plus que 20 euros pour la livraison offerte ») passe par une section de thème ou une extension d'application, alimentée par les mêmes seuils. Une bonne agence livre les deux ensemble, sinon le client découvre la remise au checkout, après la décision. Pour les exemples concrets, notre article [réductions avec Shopify Functions](/shopify-functions-discounts) montre le code d'une Function de paliers. **Vous avez une règle de remise que Shopify ne fait pas nativement** Écrivez-la en une phrase, avec un exemple de panier, et vous recevrez une réponse sur ce qui est faisable en Function, ce qu'une application couvre déjà, et un prix fixe. [Parler à ByteInfy](https://byteinfy.com/contact) ## FAQ ### Qu'est-ce qu'une Shopify Function ? Un petit programme compilé en WebAssembly que Shopify exécute dans le checkout pour appliquer une logique personnalisée : réductions, règles de livraison, moyens de paiement, validation du panier. ### Les Shopify Scripts fonctionnent-ils encore ? Non. Les Scripts sont dépréciés et les marchands Plus devaient migrer vers Shopify Functions avant 2025. Une boutique qui en dépend encore doit réécrire sa logique en Functions. ### Faut-il Shopify Plus pour utiliser les Functions ? Non pour les réductions, les règles de livraison et la validation du panier. Certaines personnalisations de l'étape de paiement et la marque du checkout restent liées à Plus. ### Puis-je créer une réduction par paliers sans application ? Oui, avec une Function de réduction qui lit le panier et applique un pourcentage selon la quantité ou le montant. ### Comment se combinent plusieurs réductions ? Shopify gère les combinaisons par classe de réduction (produit, commande, livraison) et chaque réduction déclare avec quoi elle peut se cumuler. ### Combien coûte une Function de réduction sur mesure ? Chez ByteInfy, une Function ou une extension de checkout se chiffre entre 1 500 et 3 000 $ au moment de la rédaction, avec l'interface de configuration dans l'administration pour que votre équipe modifie les règles sans développeur. ### Une Function peut-elle appeler un service externe ? Non. Elle s'exécute sans accès réseau, avec les données du panier, du client et des métachamps fournies en entrée. Toute donnée nécessaire doit être disponible dans Shopify avant le checkout. --- --- title: "Shopify Theme Speed: What Actually Moves the Score" description: "Image compression is the advice everyone gives and rarely the thing holding a Shopify store back. The weight that matters is scripts you installed and forgot." author: "Aashish Kaushik" published: 2026-09-12T13:01:05.058Z updated: 2026-09-12T13:01:05.258Z url: https://blog.byteinfy.com/shopify-theme-speed --- # Shopify Theme Speed: What Actually Moves the Score ## Key takeaways - App scripts are the largest controllable cost on most Shopify storefronts, and they load on pages where their feature is never used. - Fonts block text rendering, and a theme loading four weights of two families delays the largest visible element on every page. - Uninstalling an app frequently leaves its code in the theme, so stores carry the weight of tools they stopped paying for. - Measure with field data from real visitors, not lab scores — a lab test on a fast connection hides exactly the problems your mobile traffic experiences. Every Shopify speed guide opens with image compression, and for most stores it is close to irrelevant. Shopify already serves images through its own CDN with sensible defaults. Compressing them further produces a small gain on a problem that was not the constraint. The weight that actually holds Shopify stores back is code the merchant added — app scripts, tracking pixels, fonts, and theme features nobody uses any more. This is a guide to finding and removing that, in the order that produces the largest gains. > **Measure before changing anything** > > Everything below is worth doing only if it applies to your store. Run a real measurement first, on a product page, and let it decide where you spend effort. ## Look at what your store actually requests Before any advice applies, you need to see what your storefront loads. This takes five minutes and replaces guesswork with a list. Open a product page in Chrome, open DevTools, go to the Network tab, filter to JS, and sort by transfer size. You now have a ranked list of every script the page loads and what each one costs. Do the same on your homepage and your cart, because they differ. What you are looking for: - Third parties you do not recognise. These are almost always apps, and sometimes apps you no longer use. - Scripts loading on pages where their feature does not appear. A review widget on your blog. A popup app on the cart. This is the single most common finding. - Duplicate functionality. Two apps both doing analytics, two both doing reviews. - Anything large enough to be surprising. A single script over a few hundred kilobytes deserves justification. This list is your work queue. Everything else in this article is about acting on it. ## App scripts are the main event For most Shopify stores, app JavaScript is the largest controllable cost on the page. Each app is individually defensible; collectively they are why Core Web Vitals sit in the amber. The specific failure is scope. Apps commonly load globally rather than only where they are used, because global loading is simpler for the vendor and invisible to the merchant. Nothing appears broken, so nobody investigates. Three actions, in order of return: **Remove apps you are not using.** Trialled and abandoned apps are the easiest win and almost every store has some. Check the pricing page in your admin against the features actually live on your storefront. **Check what uninstalled apps left behind.** This is the one merchants miss. Uninstalling an app does not always remove its code from your theme, particularly for older apps that injected snippets directly rather than using theme app extensions. Stores routinely carry the weight of tools they stopped paying for years ago. Search your theme files for references to apps you no longer have. **Scope the apps you keep.** Some apps allow you to limit which templates they load on. Where they do, use it. Where they do not, weigh the feature against a cost you pay on every page. ## Theme file audit - Search theme.liquid for script tags referencing services you no longer use - Check snippets for orphaned app includes - Look for duplicate tracking pixels, which accumulate through agency handovers - Confirm each remaining third party corresponds to something live on the storefront - Note anything you cannot identify, and find out what it is before removing it That last point matters. Removing a script you cannot identify is how a store loses its conversion tracking three days before a campaign. ## Fonts block your largest element Fonts are the most underestimated cost, because they are small in bytes and expensive in timing. A custom font must download before text rendered in it becomes visible. On most storefronts the largest visible element is text — a headline, a product title — so font loading directly delays largest contentful paint, which is a Core Web Vital. A theme loading four weights of a heading family plus four of a body family is loading eight files to render a page that visibly uses three of them. The remedies are straightforward: - Load only the weights you use. Audit which weights actually appear. Most designs use two or three. - Use font-display: swap so text renders immediately in a fallback and reflows when the font arrives. Visible fallback text beats invisible correct text. - Choose a fallback that matches metrically, so the swap does not shift the layout and cost you cumulative layout shift. - Consider system fonts for body copy. Unfashionable, free, and instant. ## Images, properly this time Images are not usually the constraint, but there are two image problems that genuinely cost you, and neither is compression. **Missing dimensions.** An image without width and height attributes gives the browser no way to reserve its space, so the page shifts as it loads. This is cumulative layout shift, it is a Core Web Vital, and it is one attribute away from fixed. **Everything loading eagerly.** Images below the fold should load lazily. Images above it should not — lazy-loading your hero image delays the very element the score measures. The distinction matters: the fix is not "lazy-load everything", which is a common and counterproductive over-correction. ## Theme features you do not use Themes ship with features for the widest possible market, and you are paying for all of them. Mega-menu code on a store with six collections. A currency converter for a store selling in one currency. A quick-view modal nobody opens. Product-page video support on a catalogue with no video. Each is a small amount of JavaScript and CSS, and collectively they are a meaningful fraction of theme weight. This requires developer time and carries risk, so it belongs after the app audit rather than before it. But on a heavily customised store carrying years of accumulated features, it is often the second-largest win available. ## Measure the right thing Two distinctions that change what you should act on. **Field data over lab data.** A lab test runs on a simulated connection from a test location. Field data comes from your actual visitors, on their actual devices and connections. When they disagree, the field data is what your customers experience and the lab score is a diagnostic. Chrome's Core Web Vitals report and Search Console's page experience data are field sources. **Core Web Vitals over composite scores.** A single number blends several things and moves for reasons you cannot act on. Largest contentful paint, interaction to next paint and cumulative layout shift each point at a specific cause, which makes them actionable in a way a composite score is not. ## Metric, common Shopify cause, first fix | Metric | Usual cause on Shopify | Where to start | | --- | --- | --- | | Largest contentful paint | Render-blocking fonts, hero image loading late | Font weights and display, eager hero | | Interaction to next paint | App JavaScript occupying the main thread | App audit, remove and scope | | Cumulative layout shift | Images and embeds without reserved space | Width and height attributes everywhere | | Time to first byte | Rarely the merchant's problem on Shopify | Usually nothing; check app server calls | ## What you cannot fix, and should stop trying to Some of what a Shopify score reports is not yours to change, and effort spent there is wasted. **Shopify's own scripts.** The platform loads its own JavaScript for checkout, analytics and various storefront behaviours. You cannot remove it, and audits that flag it are reporting a fact rather than an opportunity. **Server response time.** Time to first byte on Shopify is a platform concern. If yours is genuinely poor, the cause is almost always an app making a slow synchronous call during page generation, not Shopify being slow — so the fix is still an app fix. **Third-party pixels the business requires.** Marketing platforms need their tags. You can load them more carefully, defer them, or consolidate duplicates, but a business running paid acquisition cannot remove its tracking to win points. The honest move is to make them as cheap as possible and accept the remainder. Knowing which category a finding falls into is what separates a useful audit from a list of complaints. An audit that tells you to remove Shopify's checkout script is not an audit worth acting on. ## Do it in this order 1. Measure, on a product page, with field data where available. 2. Remove apps you are not using, and delete what previous ones left behind. 3. Scope the apps you keep to the templates that need them. 4. Fix fonts — weights, display, fallback metrics. 5. Fix image dimensions and lazy-loading boundaries. 6. Strip unused theme features, with developer help. 7. Re-measure, and check conversion alongside speed. Steps two and three are usually most of the gain, which is why they come before anything requiring development work. > **Watch conversion, not just the score** > > Every change here alters what loads, and some of what loads is doing a job. Removing a popup app improves your score and may reduce email capture. Optimise for what the store earns, not for a number, and change one thing at a time so you can tell which change did what. For the wider storefront picture including theme choice and redesign decisions, see [storefront and design](/category/storefront-design). App selection and the weight different categories add is covered in [Shopify apps](/category/shopify-apps), and the SEO consequences of page speed in [SEO and AI search](/category/seo-ai-search). **Store slower than it should be?** ByteInfy audits Shopify storefront performance — app weight, render-blocking assets and the theme code nobody remembers adding. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Why is my Shopify store slow when I have compressed all my images? Because images are rarely the binding constraint on a Shopify store. Shopify already serves images through its CDN with reasonable optimisation. ### How many apps can a Shopify store have before speed suffers? There is no useful number, because apps differ by orders of magnitude in weight. One badly-built app can cost more than ten well-built ones. ### Does a premium theme make my store faster? Not reliably. Premium themes often carry more features, and features are code. A well-built free theme with few apps will usually outperform a feature-heavy premium theme carrying eight integrations. ### Do I need to be on Shopify Plus for a fast store? No. Plus does not make storefront rendering faster in any way a shopper experiences. Speed on Shopify is overwhelmingly determined by what the merchant adds to the theme, which is identical across plans. ### What score should I be aiming for? Treat the score as a diagnostic rather than a target. --- --- title: "Shopify en Suisse : TWINT, CHF, TVA et les points à régler" description: "La Suisse n'est pas l'UE, et une boutique Shopify suisse le sent à chaque réglage, TWINT au checkout, prix en CHF arrondis, TVA à 8,1 %, douane pour tout ce qui vient d'Europe. Voici les points à régler, dans l'ordre." author: "Aashish Kaushik" published: 2026-09-12T05:00:18.730Z updated: 2026-09-12T05:00:18.735Z url: https://blog.byteinfy.com/shopify-suisse-twint-chf-tva-points-regler --- # Shopify en Suisse : TWINT, CHF, TVA et les points à régler ## Key takeaways - TWINT est disponible via Shopify Payments en Suisse et doit être activé ; c'est le moyen de paiement que les acheteurs suisses attendent avant la carte. - Les prix en CHF se gèrent avec Shopify Markets, avec des règles d'arrondi à vérifier pour respecter l'habitude suisse des 5 centimes. - La TVA suisse (8,1 % au taux normal au moment de la rédaction) s'applique aux ventes en Suisse ; les envois depuis l'UE passent la douane et le client paie des frais si vous ne livrez pas en DDP. - Une boutique qui vise la Suisse romande, alémanique et italienne doit prévoir trois langues, ce que Shopify Markets permet sans seconde boutique. Une boutique Shopify en Suisse se règle en cinq points : TWINT activé via Shopify Payments, des prix en francs suisses avec les bons arrondis, la TVA suisse au lieu de la TVA européenne, une livraison qui absorbe la douane pour tout ce qui vient de l'UE, et des langues qui couvrent au moins le français et l'allemand. Aucun de ces points n'est compliqué isolément. Ensemble, ils expliquent pourquoi tant de boutiques françaises ou belges « ouvertes à la Suisse » ne vendent presque rien de l'autre côté de la frontière. Cet article s'adresse à deux profils : le marchand suisse qui lance sa boutique, et le marchand de l'UE qui veut vendre en Suisse proprement. Les réglages sont les mêmes ; les conséquences douanières et fiscales diffèrent. ## Paiement : TWINT, cartes, et la question de la facture TWINT est disponible via Shopify Payments en Suisse, et c'est le premier réglage à faire pour une boutique suisse. TWINT est le portefeuille mobile que les acheteurs suisses utilisent au quotidien, et beaucoup le cherchent au checkout avant de sortir une carte. Son activation se fait dans les paramètres de paiement, avec la Suisse comme pays de la boutique. Une boutique domiciliée dans l'UE qui vend en Suisse via Shopify Markets ne bénéficie pas automatiquement de TWINT, parce que la disponibilité dépend du pays de la boutique ; c'est un des arguments pour une entité ou une boutique suisse quand le volume le justifie. Autour de TWINT, les cartes Visa et Mastercard, Apple Pay et Google Pay, et PayPal pour ceux qui y tiennent. PostFinance, très répandu, passe par un prestataire de paiement tiers plutôt que par Shopify Payments, avec les frais supplémentaires que cela implique côté Shopify. Le paiement sur facture mérite une réflexion à part. Il reste répandu, surtout en Suisse alémanique, et son absence fait perdre des commandes sur les paniers élevés. Il n'est pas dans Shopify Payments : soit un prestataire tiers qui prend le risque d'impayé contre une commission, soit un paiement manuel avec un suivi des encaissements que votre équipe doit tenir. ## Moyens de paiement pour la Suisse | Moyen | Disponibilité | Remarque | | --- | --- | --- | | TWINT | Shopify Payments, boutique suisse | À activer explicitement, à placer en premier au checkout | | Cartes Visa et Mastercard | Shopify Payments | Socle par défaut | | Apple Pay et Google Pay | Shopify Payments | Utiles sur mobile, courants en Suisse | | PostFinance | Prestataire tiers | Très répandu, frais supplémentaires côté Shopify | | Paiement sur facture | Prestataire tiers ou manuel | Attendu en Suisse alémanique sur les paniers élevés | | PayPal | Passerelle séparée | Attendu par une partie des acheteurs | Les règles d'affichage des moyens de paiement, par exemple masquer la facture sous un certain montant, se construisent avec une Function de personnalisation de paiement, comme le décrit notre article sur [Checkout Extensibility](/shopify-checkout-extensibility). ## Prix en CHF : devise, arrondis et affichage Les prix en francs suisses se gèrent nativement pour une boutique suisse et via Shopify Markets pour une boutique européenne. Pour une boutique domiciliée en Suisse, le CHF est la devise de base et tout suit. Pour une boutique française ou belge, Shopify Markets ajoute la Suisse comme marché avec le CHF comme devise. Deux options : des prix convertis automatiquement selon le taux du jour, ou des prix fixés à la main par marché. La seconde est préférable dès que le volume compte, parce qu'elle permet des prix « ronds » et une marge stable. L'arrondi est un détail qui se voit. Les Suisses ont l'habitude de prix arrondis à 5 centimes, et un prix de 24,97 CHF signale une conversion automatique plus qu'une boutique locale. Shopify Markets propose des règles d'arrondi par devise ; vérifiez qu'elles produisent des prix crédibles sur votre catalogue. Sur le plan SEO, chaque marché doit avoir ses prix dans les données structurées Product avec la devise correcte. Un visiteur suisse qui voit un prix en euros dans les résultats Google et un prix en CHF sur la page a déjà un doute. Le point 24 de notre [checklist SEO Shopify](/fr/checklist-seo-shopify-2027-25-points-qui-comptent) traite ce cas. ## TVA suisse : taux, seuil et affichage La TVA suisse s'applique aux ventes en Suisse, au taux normal de 8,1 % au moment de la rédaction, et son assujettissement obéit à des règles différentes de celles de l'UE. Pour une boutique suisse, la TVA suisse s'applique aux ventes domestiques, avec des taux réduits pour certaines catégories de biens. Les prix aux particuliers s'affichent toutes taxes comprises, ce qui suppose le réglage « inclure les taxes dans les prix » activé et les taux suisses configurés dans Shopify. Pour un vendeur étranger, la règle générale est l'assujettissement en Suisse à partir de 100 000 CHF de chiffre d'affaires mondial dès lors qu'il réalise des ventes en Suisse, avec des dispositions particulières pour les envois de faible valeur. Ce seuil et ses conditions évoluent ; vérifiez auprès de l'Administration fédérale des contributions ou d'un fiduciaire avant de décider si vous vous immatriculez. Deux conséquences pratiques. Si vous n'êtes pas assujetti en Suisse, vous vendez hors TVA européenne (exportation) et le client suisse paie la TVA suisse à l'importation, avec les frais de dédouanement. Si vous êtes assujetti, vous facturez la TVA suisse et pouvez livrer en DDP, ce qui change complètement l'expérience client. Dans Shopify, cela se traduit par une configuration de taxes distincte pour le marché suisse et un prix TTC cohérent. > **Le prix que le client suisse voit doit être le prix qu'il paie** > > Un client suisse qui commande sur une boutique française à 49 euros et reçoit une facture de dédouanement à la livraison ne recommande pas la boutique. Si vous ne livrez pas en DDP, dites-le clairement avant le checkout, sur la page produit et dans les conditions de livraison, avec une estimation des frais. ## Livraison : la Poste, la douane et le choix DDP ou DAP Toute livraison de l'UE vers la Suisse passe la douane, et la question à trancher est qui paie les droits et la TVA à l'importation. En DAP (ou DDU), le client paie à la réception. C'est simple pour le vendeur et mauvais pour le client : frais surprise, colis retenu, refus, retour à vos frais. En DDP, vous payez les droits et la TVA, intégrés à votre prix ou à vos frais de port, et le colis arrive sans surprise. Les transporteurs proposent les deux ; le DDP coûte plus cher par envoi et rapporte plus en conversion et en recommandes. Pour une boutique suisse, la Poste suisse est le transporteur par défaut, avec PostPac Economy et Priority, des points de retrait et des consignes. Les acheteurs suisses ont l'habitude d'une livraison rapide et fiable, et un délai de cinq jours est perçu comme lent. Dans Shopify, créez une zone de livraison Suisse distincte, avec ses propres tarifs, et si vous livrez depuis l'UE, un tarif qui reflète le DDP. Pour les documents douaniers, les codes SH par produit et le pays d'origine se stockent en métachamps ou dans les champs de conformité de Shopify, et les applications d'expédition les lisent pour générer les déclarations. Le Liechtenstein suit le régime douanier suisse ; ajoutez-le à la même zone. ## Langues : français, allemand et italien sur une boutique La Suisse romande n'est qu'une partie du marché, et une boutique qui vise toute la Suisse doit exister en allemand, et idéalement en italien. Shopify Markets permet plusieurs langues par marché, avec des sous-dossiers (/fr-ch, /de-ch, /it-ch) et des balises hreflang générées. Le thème doit avoir ses textes fixes traduits, ce que les thèmes du Theme Store fournissent et que les développements sur mesure doivent ajouter. Le checkout et les e-mails suivent la langue du client. La traduction du contenu se fait avec Translate & Adapt ou une application tierce, puis à la main pour les pages qui vendent. L'allemand de Suisse n'est pas l'allemand d'Allemagne dans les usages (par exemple « ss » plutôt que « ß »), et un lecteur zurichois le remarque. Si vous lancez d'abord en français, prévoyez la structure d'URL pour les autres langues dès le départ. Changer de structure après coup demande un plan de redirections complet. ## Frais et coût d'exploitation Une boutique suisse coûte l'abonnement Shopify, les frais de Shopify Payments, les applications, la douane si vous livrez en DDP depuis l'UE et, le cas échéant, une agence. Les frais de transaction de Shopify Payments pour la Suisse ont leur propre grille, différente de celle de l'UE, avec des taux qui varient selon le moyen de paiement et l'origine de la carte. TWINT, les cartes suisses et les cartes européennes n'ont pas le même coût. Consultez la grille publiée pour la Suisse plutôt que de supposer. Les applications suivent la même logique qu'ailleurs : transporteur, avis, e-mailing, traduction. Une boutique suisse type en a besoin de quatre ou cinq. Si vous passez par une agence, elle se chiffre à part. Chez ByteInfy, une boutique prête à vendre démarre à 2 000 $, une personnalisation de thème à 1 000 $ et une Function ou extension de checkout à 1 500 $, en dollars américains au moment de la rédaction. Pour une entreprise suisse, une prestation de services reçue d'un prestataire étranger relève de l'impôt sur les acquisitions (le mécanisme suisse d'autoliquidation) au-delà d'un seuil ; votre fiduciaire saura le traiter. Les postes sont détaillés dans [combien coûte une boutique Shopify en 2027](/fr/agence-shopify-combien-coute-boutique-2027-tarifs-reels). ## Lancement d'une boutique Shopify pour la Suisse - TWINT activé dans Shopify Payments et visible en premier au checkout - Décision prise sur le paiement sur facture, avec prestataire ou processus manuel - CHF configuré comme devise de base ou de marché, prix fixés par marché, arrondis à 5 centimes vérifiés - TVA suisse configurée avec les taux en vigueur, prix affichés TTC - Assujettissement en Suisse vérifié avec un fiduciaire si vous vendez depuis l'UE - Zone de livraison Suisse et Liechtenstein distincte, tarifs DDP ou avertissement DAP explicite - Codes SH et pays d'origine renseignés par produit pour les déclarations douanières - Français et allemand activés, thème, checkout et e-mails traduits, hreflang vérifiés - Commande de test avec TWINT depuis un téléphone, jusqu'à l'e-mail de confirmation ## Une boutique européenne qui vend en Suisse : le résumé Pour une boutique française ou belge, la Suisse est un marché à part entière, pas une zone de livraison de plus. Le minimum sérieux : un marché Suisse dans Shopify Markets avec le CHF et des prix fixés à la main, une zone de livraison avec tarif DDP ou un avertissement clair, des codes SH par produit, et l'allemand en plus du français. Le maximum, quand le volume le justifie : une entité ou une boutique suisse avec Shopify Payments local, TWINT et la TVA suisse en direct. Entre les deux, la personnalisation du thème par marché permet d'adapter les messages de livraison, les transporteurs affichés et les arguments selon que le visiteur vient de Lausanne ou de Lyon. Notre article sur [la personnalisation du thème par marché](/shopify-theme-customization-market) montre comment faire sans dupliquer le thème. Pour le voisin belge, avec sa TVA européenne et Bancontact, notre article sur [Shopify en Belgique](/fr/shopify-belgique-bancontact-mondial-relay-tva-frais) suit la même structure. **Vous voulez vendre en Suisse sans les mauvaises surprises** Décrivez votre situation, boutique suisse ou européenne, catalogue, transporteurs, et vous recevrez un périmètre écrit avec ce qui se règle dans Shopify et ce qui demande un développement. [Parler à ByteInfy](https://byteinfy.com/contact) ## FAQ ### TWINT fonctionne-t-il sur Shopify ? Oui. TWINT est disponible via Shopify Payments pour les boutiques suisses et s'active dans les paramètres de paiement. Il apparaît au checkout à côté des cartes et des portefeuilles numériques. ### Comment afficher les prix en CHF sur Shopify ? Avec Shopify Payments configuré pour une boutique suisse, le CHF est la devise principale. ### Quelle TVA appliquer sur une boutique Shopify suisse ? La TVA suisse au taux normal de 8,1 % au moment de la rédaction, avec des taux réduits pour certains biens. ### Comment livrer en Suisse depuis la France ou la Belgique ? Chaque envoi passe la douane. ### Faut-il une boutique séparée pour la Suisse ? Pas nécessairement. Shopify Markets gère le CHF, les prix par marché, la langue et le domaine ou sous-dossier suisse depuis une boutique européenne. ### Les Suisses paient-ils sur facture ? Le paiement sur facture reste répandu en Suisse, surtout en Suisse alémanique. Il ne fait pas partie de Shopify Payments et passe par un prestataire tiers ou un paiement manuel avec suivi des impayés. ### Quels sont les frais d'une boutique Shopify en Suisse ? L'abonnement Shopify, les frais de transaction de Shopify Payments qui diffèrent selon le moyen de paiement et le pays de la carte, les applications, les frais de douane si vous livrez en DDP et, le cas échéant, l'agence. --- --- title: "Shopify App Development in 2026: A Practical Guide" description: "The hard parts of a Shopify app are rarely the features. They are the distribution choice, the review requirements, and the storefront surface you commit to on day one." author: "Aashish Kaushik" published: 2026-09-11T13:01:08.804Z updated: 2026-09-11T13:01:08.826Z url: https://blog.byteinfy.com/shopify-app-development-guide --- # Shopify App Development in 2026: A Practical Guide ## Key takeaways - The public-versus-custom decision is made before any code exists and determines your review obligations, billing model and support burden. - Extensions are the modern surface — theme app extensions, checkout UI extensions and Functions replace the old pattern of injecting code into themes. - Shopify's own requirements checklist is a substantial part of the build, not a formality at the end. - Performance is a review consideration and a merchant retention issue, because an app that slows storefronts gets uninstalled regardless of its features. Most people planning a Shopify app underestimate it in a predictable way. They scope the feature accurately and the surrounding work not at all — authentication, sessions, webhooks, billing, the requirements checklist, and the question of where in a merchant's store the app actually appears. This is a guide to those parts, because the feature is usually the easy half. > **Scope** > > Building an app, not marketing one. The distribution and listing side is a separate discipline covered elsewhere. ## The first decision: public or custom Made before any code exists, and it determines almost everything that follows. **A public app** is listed on the App Store, installable by anyone, and subject to Shopify's review and requirements. You get distribution — merchants find you — and in exchange you accept review, a support obligation to strangers, and a product that must work across every theme and configuration you have never seen. **A custom app** is built for one merchant. No listing, no App Store review, no unknown themes. You get to make assumptions. You also get no distribution, and if the client leaves, the app has no other market. ## Public and custom compared | Public app | Custom app | | --- | --- | | Distribution | App Store discovery | None | | Review process | Required | Not required | | Requirements checklist | Applies fully | Largely not | | Support burden | Unknown merchants at scale | One known client | | Billing | Shopify billing API, revenue share | Whatever you agree | | Theme compatibility | Must work everywhere | One theme | | Best when | You have a market | You have a client | The mistake to avoid is building a custom app with vague intentions of listing it later. Retrofitting a single-merchant app into a public one usually means rewriting the assumptions, and the assumptions are load-bearing — one theme becomes every theme, one configuration becomes every configuration, and one known client becomes an unknown support queue. ## Where your app actually lives The surfaces have changed substantially, and code written against the old patterns is a liability. **The embedded admin.** Your app's interface inside the Shopify admin, built with Polaris and App Bridge so it feels native rather than like an iframe someone bolted on. **Theme app extensions.** How an app renders on the storefront now. App blocks that merchants place through the theme editor, with no code injected into theme files. This is the modern replacement for the old pattern of writing snippets into a merchant's theme, and it is better for everyone: merchants can place and remove your feature themselves, and uninstalling actually removes it. **Checkout UI extensions.** Interface elements at supported points in checkout, replacing the old `checkout.liquid` approach. **Shopify Functions.** Server-side logic for discounts, delivery and payment customisation. Since legacy Scripts stopped running on 30 June 2026, this is the supported route for that behaviour. **Admin extensions and POS UI extensions** for apps extending those surfaces. The important architectural point: if your app needs to appear on the storefront, design around theme app extensions from the start. Injecting into theme files still technically works in places and produces exactly the problems merchants complain about — code left behind after uninstall, conflicts with theme updates, and a footprint they cannot control. ## The parts that take longer than the feature Four areas that consistently absorb more time than planned. **OAuth and session management.** Straightforward in principle, fiddly in practice. Token storage, session persistence across embedded contexts, handling reinstalls and scope changes. **Webhooks, done reliably.** Webhooks can be delayed, duplicated or missed. An app that assumes exactly-once delivery will corrupt its own data. Idempotency and reconciliation are not optional extras. **Billing.** The billing API, trials, plan changes, cancellations, failed payments, and what your app does when a merchant downgrades. Build this early; retrofitting it is painful because it touches everything. **Mandatory compliance webhooks and data handling.** Customer data requests, redaction, shop redaction. Required, and easy to leave until the review rejects you for it. ## Before submitting for review - Every required webhook implemented and tested, including compliance ones - OAuth handling reinstalls and scope changes correctly - Billing covering trials, upgrades, downgrades and failed payments - Storefront features delivered as theme app extensions, not injected code - Performance measured on a real storefront, not a development store - Uninstall genuinely removing your footprint - Documentation and support contact that a reviewer can actually use ## Performance is a product feature Worth stating separately because it is the most common reason a good app gets uninstalled. Any app rendering on the storefront adds weight to pages merchants care about. If your app loads a script globally to support a feature used on one template, you are charging every page for something most of them do not use. The consequences are commercial rather than technical. Merchants increasingly audit app weight, page speed affects their rankings and conversion, and an app that visibly costs them Core Web Vitals is the first one removed when they do a cleanup. Practical rules: load only where your feature is used, defer everything you can, keep your bundle small, and measure on a realistic storefront rather than a clean development store with nothing else installed. ## The review process Shopify's review is more thorough than most first-time submitters expect, and treating it as a formality at the end is why timelines slip. The requirements checklist is public. Read it at the start of the project, not the end — a substantial share of it describes things that are architectural rather than cosmetic, and discovering them after the build is how a two-week fix appears. The common rejection causes are consistent: incomplete or missing mandatory webhooks, billing that does not handle the required cases, an onboarding flow a reviewer cannot complete, insufficient documentation, and storefront implementations that inject code rather than using extensions. Build against the checklist continuously and the review becomes an administrative step. Build the app and then read the checklist, and it becomes a project. Resubmission after a rejection also costs calendar time you cannot compress, which matters most when a launch is tied to a date someone has already announced. ## Supporting an app you did not expect to support Support is the cost first-time app builders model least accurately, and for a public app it is not optional. The shape of it is unintuitive. Most tickets are not bugs. They are merchants whose theme does something your app did not anticipate, merchants who have another app touching the same surface, merchants who configured something in a way you did not imagine was possible, and merchants asking questions your documentation answers but they did not find. Three consequences worth building for: **Make your app diagnosable from the outside.** When a merchant reports that something does not appear, you need to determine why without access to their store. Logging that records what your app did for that shop, and a status view inside the app showing its own configuration, turns a two-day exchange into a two-minute answer. **Assume conflicts with other apps.** Merchants routinely run dozens. Your app will share a page, a cart, or a checkout with something you have never seen. Defensive rendering, namespaced styles and avoiding global side effects prevent most of the resulting tickets. **Write the documentation before launch.** Not because reviewers require it, though they do, but because every question it answers is a ticket you do not receive. The install-and-first-use path deserves the most attention, since that is where merchants abandon. > **Reviews are support, visibly** > > On the App Store your responses to reviews are public and permanent. A merchant who left one star because of a misunderstanding, answered helpfully, becomes evidence that you support your product. Unanswered negative reviews are the first thing a prospective merchant reads. ## Decisions that are hard to reverse Worth deciding deliberately at the start, because changing them later is expensive: **Public or custom**, as above. **Where data lives.** Your own database is the usual answer, but what you store, and what you rely on Shopify's API for at request time, affects both performance and your compliance obligations. Storing less means fewer obligations and less to redact, but every field you do not keep is an API call on the critical path, and rate limits are real. **Whether you use Functions.** If discount, delivery or payment logic is core to your app, that shapes the architecture from day one rather than being bolted on afterwards at considerable cost. **Your storefront surface.** Theme app extensions versus anything else. This one is genuinely hard to change and directly affects how merchants experience your app. **Your billing model.** Flat, tiered, usage-based. It affects your data model, not just your pricing page. **Your API version policy.** Shopify versions its APIs and retires old ones on a published schedule. An app that pins to a version and never revisits it will eventually stop working, and the failure arrives on Shopify's timetable rather than yours. Decide early how you track deprecations and how often you upgrade, because an app carrying three years of accumulated version debt is far harder to move than one upgraded quarterly. For the public-versus-custom decision in more depth, and the review process specifically, see [Shopify development](/category/shopify-development). The performance considerations overlap with [storefront and design](/category/storefront-design). **Building a Shopify app?** ByteInfy designs, builds and ships Shopify apps — through App Store review and into production, with the parts that are not the feature handled properly. [Start a project](https://byteinfy.com/#contact) ## FAQ ### How long does it take to build a Shopify app? A genuinely simple app with one clear function can be a few weeks. ### What is the difference between a public and a custom Shopify app? A public app is listed on the App Store, installable by any merchant, subject to Shopify's review and requirements. ### What stack should I use for a Shopify app? Shopify's own tooling targets Remix, and their libraries and templates are the least resistance path. Node with any framework is well supported. ### Do I need to use Shopify Functions? Only if your app changes discount, delivery or payment behaviour. Since legacy Scripts stopped running on 30 June 2026, Functions are the supported mechanism for that logic. ### How do apps make money on Shopify? Through Shopify's billing API, typically recurring subscriptions, often with usage components or tiered plans. Shopify takes a revenue share, and the specifics have changed over time. --- --- title: "Shopify en Belgique : Bancontact, Mondial Relay, TVA et frais" description: "Une boutique Shopify belge se joue sur quatre réglages que les guides généralistes oublient, Bancontact, les points relais, la TVA belge et européenne, et le bilinguisme. Voici comment les régler, dans l'ordre." author: "Aashish Kaushik" published: 2026-09-11T05:00:43.729Z updated: 2026-09-11T05:00:43.918Z url: https://blog.byteinfy.com/shopify-belgique-bancontact-mondial-relay-tva-frais --- # Shopify en Belgique : Bancontact, Mondial Relay, TVA et frais ## Key takeaways - Bancontact est disponible via Shopify Payments en Belgique et doit être activé explicitement ; sans lui, une partie importante des acheteurs belges quitte le checkout. - Shopify n'a pas de sélecteur de point relais natif, Mondial Relay et bpost passent par une application ou une intégration sur mesure au checkout. - La TVA belge s'applique aux ventes en Belgique et le guichet unique OSS aux ventes dans le reste de l'UE au-delà du seuil de 10 000 euros ; les prix doivent être affichés toutes taxes comprises. - Le bilinguisme français et néerlandais se gère avec Shopify Markets et un thème traduit proprement, pas avec une seconde boutique. Une boutique Shopify en Belgique fonctionne avec les mêmes outils qu'ailleurs, mais quatre réglages décident si elle vend ou non : Bancontact activé via Shopify Payments, un sélecteur de points relais pour Mondial Relay ou bpost, une configuration de TVA qui distingue la Belgique du reste de l'UE, et un bilinguisme français et néerlandais géré proprement. Aucun de ces points n'est difficile. Tous sont oubliés par les guides écrits pour le marché américain, et chacun coûte des commandes quand il manque. Cet article les prend dans l'ordre où un marchand belge les rencontre, avec ce que Shopify fait nativement, ce qui demande une application et ce qui demande un développement. ## Paiement : Bancontact d'abord, le reste ensuite Bancontact est disponible via Shopify Payments en Belgique, et c'est le premier réglage à faire. Pour une part importante des acheteurs belges, Bancontact est le moyen de paiement par défaut, celui qu'ils cherchent avant de sortir une carte de crédit. Une boutique qui ne le propose pas au checkout perd des commandes qu'aucune optimisation de page produit ne récupère. L'activation se fait dans les paramètres de paiement de Shopify Payments, avec la Belgique comme pays de la boutique. Autour de Bancontact, le socle habituel : les cartes Visa et Mastercard, Apple Pay et Google Pay pour les acheteurs mobiles, et PayPal pour ceux qui y sont attachés. Shop Pay accélère le checkout des clients qui l'ont déjà utilisé ailleurs. Deux points d'attention. D'abord, l'ordre d'affichage : Bancontact doit être visible sans dérouler une liste. Ensuite, les frais : chaque moyen de paiement a son propre taux dans la grille de Shopify Payments, et un prestataire tiers ajoute des frais supplémentaires côté Shopify. Regardez la grille pour la Belgique avant de choisir. ## Moyens de paiement pour une boutique belge | Moyen | Disponibilité | Remarque | | --- | --- | --- | | Bancontact | Shopify Payments, Belgique | À activer explicitement, à placer en premier au checkout | | Cartes Visa et Mastercard | Shopify Payments | Socle par défaut, indispensable pour les acheteurs français et luxembourgeois | | Apple Pay et Google Pay | Shopify Payments | Réduisent le checkout mobile à une validation | | PayPal | Passerelle séparée | Attendu par une partie des acheteurs, frais distincts | | Shop Pay | Shopify Payments | Utile pour les clients qui l'ont déjà utilisé ailleurs | | Virement bancaire | Paiement manuel | Pertinent en B2B, à gérer avec un statut de commande en attente | Pour les personnalisations du checkout, par exemple afficher un message spécifique selon le moyen de paiement ou masquer une option selon le panier, tout passe désormais par [Checkout Extensibility](/shopify-checkout-extensibility) et Shopify Functions, sur tous les plans pour l'essentiel. ## Livraison : Mondial Relay, bpost et le sélecteur de points relais Shopify n'a pas de sélecteur de points relais natif. C'est le deuxième réglage, et il demande une application ou un développement. Les acheteurs belges utilisent massivement les points relais, parce que la livraison à domicile en journée ne convient pas à ceux qui travaillent. Mondial Relay (réseau de points et de consignes) et bpost (bureaux de poste, points poste et distributeurs de colis) sont les deux réseaux à proposer. Le choix du point se fait dans le checkout ou sur la page panier, avec une carte, et l'adresse du point remplace celle du client dans la commande. Trois façons de le faire. Une application de transporteur du Shopify App Store qui ajoute le sélecteur et transmet l'adresse du point ; c'est le plus rapide. Une intégration avec une plateforme d'expédition multi-transporteurs qui gère les étiquettes et le suivi en plus du sélecteur. Ou une extension de checkout sur mesure pour une boutique qui veut contrôler l'affichage et les règles, par exemple limiter les points relais aux paniers sous un certain poids. Quelle que soit l'option, vérifiez que le sélecteur fonctionne aussi avec les checkouts accélérés (Shop Pay, Apple Pay). Certaines applications l'affichent seulement dans le flux standard, et une part des commandes passe sans point relais. Pour les tarifs, configurez des zones distinctes : Belgique, France, Luxembourg, Pays-Bas. Les tarifs de livraison de Colissimo vers la France et de Mondial Relay vers la Belgique n'ont rien à voir, et un tarif unique fait perdre soit de la marge soit des ventes. > **Testez le sélecteur de points relais sur un téléphone** > > La majorité des commandes belges se passent sur mobile. Un sélecteur de points relais dont la carte est inutilisable sur un écran de téléphone est un abandon de panier déguisé. Passez une commande de test depuis votre propre téléphone, avec Bancontact, jusqu'à la confirmation. ## TVA : Belgique, UE et guichet unique La TVA belge s'applique aux ventes en Belgique, celle du pays de destination aux ventes dans l'UE au-delà d'un seuil, et Shopify calcule les deux si les paramètres sont bons. Pour les ventes aux particuliers en Belgique, le taux belge s'applique et les prix doivent être affichés toutes taxes comprises. Le réglage « inclure les taxes dans les prix » de Shopify doit être activé, sinon la TVA s'ajoute au checkout et l'acheteur découvre un prix différent de celui de la page produit. Pour les ventes vers la France, le Luxembourg ou les Pays-Bas, la règle européenne du guichet unique (OSS) s'applique : en dessous de 10 000 euros de ventes intracommunautaires annuelles, vous pouvez appliquer la TVA belge ; au-dessus, la TVA du pays de destination, déclarée via l'OSS. Shopify propose une configuration de taxes par pays de l'UE qui suit cette logique une fois votre numéro OSS renseigné. Deux détails techniques. Avec des prix TTC et des taux de TVA différents par pays, le prix hors taxes varie selon la destination si le prix affiché reste le même, ce qui est le comportement par défaut. Si vous préférez une marge constante, Shopify Markets permet d'ajuster les prix par marché. Et les ventes B2B avec numéro de TVA intracommunautaire valide sont exonérées ; Shopify gère l'exemption par client si le champ est renseigné et validé. Pour la Suisse, hors UE, la logique change entièrement : douane, TVA suisse et devise en CHF. Notre article sur [Shopify en Suisse](/fr/shopify-suisse-twint-chf-tva-points-regler) la traite à part. ## Bilinguisme : français et néerlandais sur une seule boutique Une boutique belge sérieuse existe en français et en néerlandais, et Shopify Markets le permet sans seconde boutique. Le mécanisme : une langue par défaut, une langue secondaire activée dans les paramètres de langue, et des URL en sous-dossier (/nl pour le néerlandais si le français est la langue par défaut, ou l'inverse). Shopify Markets génère les balises hreflang pour chaque langue et chaque marché, ce qui indique à Google quelle version montrer à qui. La traduction elle-même se fait avec l'application Translate & Adapt de Shopify ou une application tierce, puis à la main pour les pages qui vendent. Une traduction automatique de vos fiches produit vers le néerlandais se remarque immédiatement du côté flamand, et elle coûte des commandes. Trois points à vérifier après activation. Le thème doit avoir tous ses textes fixes (boutons, messages du panier, e-mails) traduits, pas seulement le contenu ; les thèmes du Theme Store fournissent les fichiers de langue, les développements sur mesure doivent les ajouter. Le checkout suit la langue du client. Et les e-mails de notification doivent exister dans les deux langues. Pour l'organisation par marché plutôt que par langue, par exemple si la France et la Belgique ont des tarifs ou des transporteurs différents, notre article sur [la personnalisation du thème par marché](/shopify-theme-customization-market) détaille comment un même thème s'adapte. ## Frais : ce qu'une boutique belge coûte à faire tourner Le coût d'une boutique Shopify belge se compose de l'abonnement, des frais de paiement, des applications et, éventuellement, de l'agence. L'abonnement Shopify se paie mensuellement, en fonction du plan. Les frais de transaction de Shopify Payments s'appliquent sur chaque commande, avec un taux qui dépend du moyen de paiement et du pays de la carte ; Bancontact et les cartes n'ont pas le même taux, et une carte française sur une boutique belge est une transaction européenne, pas domestique. La grille de Shopify Payments pour la Belgique est publiée et mise à jour ; consultez-la plutôt qu'un article. Les applications forment le troisième poste. Sélecteur de points relais, avis clients, e-mailing, traduction : chacune a un abonnement mensuel. Une boutique belge type en a besoin de quatre ou cinq ; au-delà, vérifiez que Shopify ne fait pas déjà le travail. L'agence, si vous en prenez une, se chiffre à part. Chez ByteInfy, une boutique prête à vendre démarre à 2 000 $ et une personnalisation de thème existant à 1 000 $, en dollars américains au moment de la rédaction. Pour une entreprise belge assujettie, une prestation de services reçue d'un prestataire hors UE relève de l'autoliquidation de la TVA. Le détail des postes est dans [combien coûte une boutique Shopify en 2027](/fr/agence-shopify-combien-coute-boutique-2027-tarifs-reels). ## Mentions légales et obligations belges Une boutique belge doit afficher un certain nombre d'informations, et Shopify fournit les emplacements sans fournir le contenu. Les mentions obligatoires : dénomination, numéro d'entreprise (BCE), adresse, contact, et le numéro de TVA. Les conditions générales de vente en français et en néerlandais. Le droit de rétractation de quatorze jours pour les ventes à distance aux particuliers, avec le formulaire type. La politique de confidentialité conforme au RGPD, et le bandeau de consentement aux cookies. Shopify propose des modèles de politiques, en anglais, à traduire et à adapter. Le bandeau de cookies peut être celui de Shopify ou une application ; dans les deux cas, il doit bloquer les scripts de suivi avant consentement, ce qui suppose que les pixels soient chargés via les événements clients de Shopify et non collés dans le thème. ## Lancement d'une boutique Shopify belge - Bancontact activé dans Shopify Payments et visible en premier au checkout - Sélecteur de points relais Mondial Relay ou bpost testé sur mobile, y compris avec Shop Pay - Zones de livraison distinctes pour la Belgique, la France, le Luxembourg et les Pays-Bas - Prix affichés TTC, TVA belge par défaut, taux par pays de l'UE configurés avec le numéro OSS - Exemption de TVA pour les clients B2B avec numéro intracommunautaire validé - Français et néerlandais activés, thème et e-mails traduits, hreflang vérifiés - Mentions légales, CGV et droit de rétractation dans les deux langues - Bandeau de cookies qui bloque réellement les pixels avant consentement - Commande de test complète depuis un téléphone jusqu'à la confirmation et l'e-mail ## Quand une agence est utile, et quand elle ne l'est pas Une boutique belge sur un thème du Theme Store, avec un catalogue simple et une application de transporteur, se configure sans agence en suivant les points ci-dessus. Une agence devient utile quand un des quatre réglages sort du cadre : un sélecteur de points relais avec des règles particulières, une TVA B2B et B2C mélangée, un thème sur mesure à traduire, ou une intégration avec un logiciel de facturation ou un ERP. Elle est indispensable pour une migration depuis une autre plateforme, où les redirections et le SEO belge bilingue se jouent le jour de la bascule. Le SEO d'une boutique belge suit les mêmes règles qu'ailleurs, avec le bilinguisme en plus. Notre [checklist SEO Shopify](/fr/checklist-seo-shopify-2027-25-points-qui-comptent) couvre les 25 points, dont ceux qui concernent les marchés multiples. **Vous lancez ou reprenez une boutique Shopify en Belgique** Décrivez votre catalogue, vos transporteurs et vos langues, et vous recevrez un périmètre écrit avec ce qui se règle sans code et ce qui demande un développement. [Parler à ByteInfy](https://byteinfy.com/contact) ## FAQ ### Bancontact fonctionne-t-il sur Shopify ? Oui. Bancontact est disponible via Shopify Payments pour les boutiques belges et s'active dans les paramètres de paiement. Il apparaît ensuite comme option au checkout à côté des cartes et des portefeuilles numériques. ### Comment proposer Mondial Relay sur Shopify en Belgique ? Shopify ne fournit pas de sélecteur de point relais natif. ### Quelle TVA appliquer sur une boutique Shopify belge ? La TVA belge sur les ventes aux particuliers en Belgique. ### Faut-il une boutique séparée pour le néerlandais ? Non. Shopify Markets permet une boutique avec deux langues, des sous-dossiers par langue et des balises hreflang générées. Une seconde boutique double le travail de catalogue et de maintenance sans avantage SEO. ### Quels sont les frais d'une boutique Shopify en Belgique ? L'abonnement Shopify, les frais de transaction de Shopify Payments qui varient selon le moyen de paiement, les abonnements aux applications (transporteur, avis, e-mailing) et, le cas échéant, l'agence. ### Les prix doivent-ils être affichés TTC ? Oui pour la vente aux particuliers en Belgique et dans l'UE. ### Une agence étrangère peut-elle configurer une boutique belge correctement ? Oui si elle connaît Bancontact, les points relais, l'OSS et le bilinguisme, et si elle accepte que ces points soient écrits dans le périmètre. --- --- title: "GEO for Shopify: Getting Cited by ChatGPT and AI Overviews" description: "AI assistants now answer the questions that used to start on Google. They cite sources they can parse, verify and attribute — which is a different job from ranking." author: "Aashish Kaushik" published: 2026-09-10T13:01:00.436Z updated: 2026-09-10T13:01:00.637Z url: https://blog.byteinfy.com/shopify-geo-ai-search --- # GEO for Shopify: Getting Cited by ChatGPT and AI Overviews ## Key takeaways - Since the Summer '26 Edition, eligible Shopify catalogues auto-syndicate to ChatGPT, Copilot, Google AI Mode and Gemini through the Universal Commerce Protocol. - AI surfaces extract claims that are specific, attributed and dated — vague marketing prose is not extractable at any volume. - Product data completeness is the highest-leverage GEO work for a store, because it feeds classic search, shopping surfaces and AI agents at once. - Google retired FAQ rich results on 7 May 2026, so structured Q&A is now an entity and extraction signal rather than a SERP feature. The question that used to begin on Google now frequently begins in an assistant. "What's a good waterproof jacket for commuting under ₹8,000" is a query someone types into ChatGPT, and the answer arrives as a recommendation rather than a list of shops to evaluate. That changes what optimisation means. Ranking gets you a position a person chooses from. Citation gets you named inside an answer a person mostly accepts. The second is a smaller surface with more decisive influence, and the work to earn it is related to SEO but not identical. > **Terminology** > > GEO, AEO and AI SEO all describe roughly this. The label matters less than the distinction: optimising to be *extracted and attributed*, rather than to be *listed*. ## Shopify already handles the distribution The most important thing for a Shopify merchant to know is that a large part of this is no longer your job. Shopify shipped the Summer '26 Edition on 17 June 2026 with over 150 updates, and agentic commerce arrived on by default: eligible products auto-syndicate to ChatGPT, Microsoft Copilot, Google AI Mode, Gemini and the Shop app through the Universal Commerce Protocol, with no merchant setup ([Shopify Editions coverage, Codilar](https://www.codilar.com/blog/shopify-summer-2026-edition/), retrieved 2026-09-02). The consequence is a clean split. Distribution is solved for you. What is not solved is whether the data being distributed is good enough to be selected, and accurate enough to be described correctly when it is. That is entirely yours, and it is where the work is. ## Product data is the highest-leverage work An AI agent evaluating products does not see your storefront. It reads fields. A product with a vague title, empty product type, unlabelled variant options and a description written in brand voice is not ranked poorly by these systems — it is not usable by them. The remedy is unglamorous and it pays three times over, because the same data feeds classic Google, your shopping feed and the AI surfaces: ## Product data that machines can use - Titles that state the thing literally — what someone would type, not a campaign phrase - Product type and vendor populated consistently across the whole catalogue - Variant options describing real attributes, not internal SKU codes - Descriptions carrying material, dimensions, compatibility and use case as facts - Structured data for price, availability and condition that matches the visible page - Alt text describing the product rather than the marketing concept - Explicit answers to the comparison questions buyers actually ask That last one is underrated. Agents are frequently asked comparative questions — is this waterproof or water resistant, does it fit a 15-inch laptop, is it dishwasher safe. A product page that answers those in plain text is citable. One that requires inference is not. ## Write claims that can be extracted For content rather than product data, the principle is narrow: extractable claims are specific, attributed and dated. Compare two sentences carrying the same idea. "Video is becoming increasingly important for ecommerce conversion" cannot be cited, because there is nothing in it to attribute — no figure, no source, no time. "Around 91% of viewers prefer video under two minutes, according to Whatmore's 2026 shoppable video guide" can be, because every element a citation needs is present. This is a writing discipline more than a technical one, and it is largely the same discipline that makes content trustworthy to humans. Structure helps too — a heading that asks the question a person asks, answered directly in the paragraph beneath it, is far easier to extract than the same information buried mid-section. ## What extracts well versus what does not | Extractable | Not extractable | | --- | --- | | A figure with a named source and a date | "Studies show" with no source | | A direct answer in the first sentence under a heading | An answer arrived at after three paragraphs of context | | A specific, bounded claim | A sweeping generalisation | | Stated limitations and scope | Unqualified assertion | | A defined term, defined once, clearly | A term used loosely and variably | ## Structured data, after the FAQ change Google fully retired FAQ rich results for all sites on 7 May 2026. If you added FAQ schema for the expanded SERP listing, that reason is gone. It remains worth emitting for a different purpose. Question-and-answer pairs in structured form state your positions unambiguously in a format built for parsing, which is exactly what extraction-based systems want. The change is one of motive: add it because it accurately describes content that genuinely answers questions, not as a SERP tactic. The schema that carries more weight for a commerce site is the ordinary, boring set — Product with accurate price and availability, Organization with real identifiers, BreadcrumbList, Article or BlogPosting on content, and Person on authors. Accurate and complete beats exotic. Schema that contradicts the visible page is worse than none, because it undermines the trust the rest of your markup is trying to build. ## Crawler access is a decision you should make deliberately AI crawlers can be allowed or blocked, and many stores have made this choice by accident — inheriting a robots.txt from a theme, an agency, or a blog post about protecting content. For a merchant the calculus usually favours access. Your content exists to sell a product; being absent from the surfaces that increasingly mediate product discovery is a straightforward loss. The case for blocking is much stronger for publishers whose writing *is* the product, and merchants frequently adopt publisher arguments that do not apply to them. Whatever you decide, decide it explicitly, write down why, and review it. The specific crawler names change often enough that a rule set written two years ago is describing a landscape that no longer exists. ## Authority still decides who gets picked Extractability gets you eligible. It does not get you chosen. When several sources answer a question equally clearly, the system picks between them on signals that look a great deal like the ones classic search has always used. That means the unglamorous work still matters. Being mentioned by sources that are themselves trusted. Having a real, identifiable author with a traceable history rather than an anonymous byline. Consistent naming across your own properties, so the entity a system builds for your brand is one entity rather than three fragments. Reviews and third-party coverage that corroborate what you say about yourself. For a Shopify merchant there is a specific version of this worth naming. Assistants asked to recommend products lean heavily on sources that are not the merchant — roundups, comparison sites, forums, retail media. A store with excellent product data and no third-party presence is well described when mentioned and rarely mentioned. The two halves are not substitutes, and merchants consistently over-invest in the half they control. > **The cheapest authority work** > > Make sure the basic facts about your business are consistent everywhere they appear — legal name, address, founding, category, contact. Assistants reconcile these across sources, and contradictions between your site, your social profiles and your App Store listing weaken the entity rather than enriching it. This costs an afternoon and is the highest ratio of benefit to effort available here. ## What not to bother with A quantity of GEO advice in circulation is either recycled SEO or invented. Some things worth not spending money on: **Keyword stuffing for AI.** These systems are not matching strings. Repeating a phrase does not increase citation probability and reads badly to the humans who arrive. **Dedicated "AI-optimised" pages** that duplicate existing content in a supposedly more parseable form. This is thin duplicate content with a new justification, and it carries the ordinary risks of thin duplicate content. **Chasing every new schema type.** Accurate Product, Organization and Article markup outperforms an exotic type applied loosely. Breadth of vocabulary is not the constraint; accuracy is. **Tools promising to measure your "AI visibility score".** The underlying measurement problem is genuinely unsolved. Some of these tools are useful for tracking assistant answers over time; none of them can tell you a share-of-voice number with the confidence their marketing implies. ## How to tell whether any of this is working Measurement is genuinely poor here, and anyone claiming otherwise is selling something. There is no Search Console for assistants. What you can do: 1. Ask the assistants directly. Take the ten questions your buyers actually ask and put them to each major assistant. Record whether you appear, how you are described, and whether the description is accurate. Repeat monthly. 2. Watch referral traffic from assistant domains in analytics. It is a fraction of the real influence, since most assistant-driven discovery ends in a branded search rather than a click, but it is a directional signal. 3. Watch branded search volume for lifts you cannot attribute to campaigns. Assistant recommendations frequently surface as someone searching your brand name shortly afterwards. 4. Check accuracy, not just presence. Being described incorrectly is worse than being absent, and it is usually caused by product data you can fix. Point four is the one to act on first. Merchants who run this exercise commonly discover the assistants have their price band, materials or compatibility wrong — and the cause is almost always a field left empty or a description that assumed a human reader. For the structural Google-side work that underpins all of this, see [SEO and AI search](/category/seo-ai-search). Product data quality overlaps heavily with the storefront work in [storefront and design](/category/storefront-design). **Want your catalogue readable by both Google and the assistants?** ByteInfy does Shopify SEO and GEO as one engagement — product data, structured data and the content that gets cited. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What is GEO and how is it different from SEO? GEO — generative engine optimisation — is the practice of making content and product data usable by systems that generate answers rather than list links. ### Do I need to do anything for my products to appear in ChatGPT? Since the Summer 2026 Shopify release, eligible products auto-syndicate to several AI surfaces with no merchant setup. ### Does blocking AI crawlers hurt me? It depends what you sell and what you publish. Blocking removes you from surfaces that increasingly mediate product discovery, which for a commerce site is usually a straightforward loss. ### How do I know if an AI assistant is citing my store? Imperfectly, which is the honest answer. There is no equivalent of Search Console for these surfaces yet. ### Is GEO worth doing if I am a small store? The product data work is worth doing regardless, because it improves classic search, your Merchant Center feed and AI surfaces simultaneously. The content and authority side scales with ambition. --- --- title: "Shopify Plus : faut-il passer, et que fait une agence Shopify Plus" description: "Shopify Plus démarre à environ 2 300 $ par mois. Ce que le plan débloque réellement, les signaux qui indiquent qu'il est temps, et ce qu'une agence Shopify Plus apporte que le plan seul n'apporte pas." author: "Aashish Kaushik" published: 2026-09-10T05:00:48.877Z updated: 2026-09-10T05:00:48.884Z url: https://blog.byteinfy.com/shopify-plus-faut-passer-que-fait-agence-shopify --- # Shopify Plus : faut-il passer, et que fait une agence Shopify Plus ## Key takeaways - Shopify Plus change surtout trois choses, le checkout (personnalisation et marque), les outils multi-boutiques et B2B, et le niveau de support ; il ne rend pas une boutique plus rapide ni un thème meilleur. - Le plan démarre à environ 2 300 $ par mois sur un engagement de trois ans au moment de la rédaction, ce qui n'a de sens qu'avec un volume ou un besoin précis à mettre en face. - Les Scripts sont remplacés par Shopify Functions et checkout.liquid par Checkout Extensibility ; une boutique Plus ancienne a probablement une dette de migration à régler. - Une agence Shopify Plus se juge sur ce qu'elle a construit en Functions et en extensions de checkout, pas sur son badge. Shopify Plus vaut son prix quand vous avez un besoin précis que les autres plans ne couvrent pas : un checkout à personnaliser au-delà de ce que les extensions permettent sur les plans standards, plusieurs boutiques à piloter depuis une organisation, du B2B natif, ou un volume qui rend les frais de transaction du plan intéressants. Sans l'un de ces besoins, une boutique Advanced bien construite fait le même travail pour beaucoup moins. Le plan démarre à environ 2 300 $ par mois sur un engagement de trois ans au moment de la rédaction, et ce chiffre n'a de sens qu'avec quelque chose à mettre en face. Cet article répond à deux questions dans l'ordre : ce que Plus change et ne change pas, puis ce qu'une agence Shopify Plus fait concrètement, parce que le plan seul ne construit rien. > **Écrit par une agence** > > ByteInfy construit des Functions, des extensions de checkout et des boutiques pour des marchands sur tous les plans. Nous n'avons aucun intérêt à ce que vous passiez à Plus si votre boutique n'en a pas besoin, et une bonne partie de cet article explique pourquoi. ## Ce que Shopify Plus change réellement Le plan Plus se distingue sur quatre terrains : le checkout, l'organisation multi-boutiques, le B2B et le support. Le reste est commun à tous les plans. Le checkout. Depuis Checkout Extensibility, tous les plans peuvent ajouter des extensions d'interface aux étapes d'information et de livraison. Plus va plus loin : personnalisation de la marque du checkout, certaines personnalisations de l'étape de paiement, et des Functions dont la portée est plus large. Si votre checkout doit ressembler à votre boutique jusqu'au bouton de paiement, c'est un argument Plus. Notre article sur [Checkout Extensibility](/shopify-checkout-extensibility) détaille la frontière entre les plans. Les boutiques d'extension. Une organisation Plus peut gérer plusieurs boutiques (une par pays, par marque ou par canal) avec des utilisateurs, des paramètres et des rapports partagés. Pour une marque qui vend en France, en Belgique et en Suisse avec des catalogues et des conditions réellement différents, c'est parfois plus simple que Shopify Markets sur une seule boutique. Le B2B natif. Catalogues par entreprise, grilles tarifaires, conditions de paiement, commandes sur bon de commande. Avant Plus, ce besoin passait par des applications et des contournements. Le support et les outils d'exploitation. Un accompagnement dédié, des permissions plus fines, des automatisations Flow plus étendues et des outils de lancement de campagne. ## Ce que Shopify Plus ne change pas Le plan ne rend pas une boutique plus rapide, ne corrige pas un thème mal construit et ne réduit pas le nombre d'applications. La vitesse dépend du thème, des images et des scripts tiers, sur tous les plans. Une boutique Plus avec quinze applications reste lente. Le budget Core Web Vitals se fixe et se mesure indépendamment du plan. Le thème est le même. Online Store 2.0, sections, blocs, métachamps : rien ne change entre Advanced et Plus. Une refonte ne devient pas moins chère parce que vous êtes sur Plus. Les Functions et les métaobjets existent sur tous les plans. Les réductions personnalisées, les règles de livraison, la validation de panier, la plupart de ces logiques se construisent sans Plus. Ce que Plus ajoute est une portée plus large sur certaines cibles, pas l'accès au mécanisme. Le détail est dans notre article sur [les limites des Shopify Functions](/shopify-functions-limitations). Le SEO ne change pas non plus. La structure d'URL, les données structurées et Shopify Markets sont identiques. ## Combien coûte Shopify Plus, tout compris Le prix du plan est la partie visible. Le passage à Plus coûte aussi en construction et en migration. Le plan démarre à environ 2 300 $ par mois sur un engagement de trois ans au moment de la rédaction. Au-delà d'un certain chiffre d'affaires, le tarif devient variable. Les frais de transaction diffèrent également des plans standards, ce qui joue en faveur de Plus à partir d'un volume que seul votre relevé Shopify Payments permet de calculer précisément. Le travail d'agence s'ajoute. Une Function ou une extension de checkout se chiffre entre 1 500 et 3 000 $ chez ByteInfy ; un programme de checkout complet (règles de paiement, ventes additionnelles, validation) se chiffre ensemble. Une boutique d'extension par marché demande sa propre configuration de paiements, de livraison et de taxes. La migration compte aussi. Une boutique Plus ancienne a souvent des Scripts et des personnalisations checkout.liquid à réécrire. Ce n'est pas optionnel : les Scripts sont dépréciés et checkout.liquid n'est plus supporté. Pour une lecture comparée des tarifs selon les marchés, notre article sur [le prix de Shopify Plus](/shopify-plus-pricing-india) donne la grille dans un autre contexte, avec la même logique de calcul. ## Les signaux qu'il est temps de regarder Plus - Vous avez besoin de personnaliser le checkout au-delà de ce que les extensions permettent sur votre plan actuel - Vous gérez ou allez gérer plusieurs boutiques par pays ou par marque avec des équipes communes - Vous vendez en B2B avec des grilles tarifaires et des conditions par client - Votre volume rend les frais de transaction du plan standard plus coûteux que l'abonnement Plus - Vous avez une équipe qui exploitera les automatisations et les permissions avancées - Un besoin précis vous bloque aujourd'hui et une application ne le règle pas proprement Si vous cochez un seul de ces points, calculez. Si vous n'en cochez aucun, la question est réglée pour cette année. ## Les cas où rester sur Advanced est la bonne réponse Une bonne partie des marchands qui demandent Plus veulent en réalité quelque chose que leur plan actuel fait déjà. Les réductions personnalisées. Paliers, remise par groupe de clients, exclusions, cadeau à partir d'un montant : tout cela se construit avec Shopify Functions sur tous les plans. Notre article sur [les réductions avec Shopify Functions](/fr/reductions-personnalisees-avec-shopify-functions-fin-scripts) montre comment. Le multi-devises et le multi-pays. Prix en euros pour la France et la Belgique, en CHF pour la Suisse, domaines ou sous-dossiers localisés, balises hreflang : Shopify Markets s'en charge sur tous les plans. La vitesse et la conversion. Aucun plan ne les améliore. Une passe de vitesse à partir de 750 $ et un audit de conversion à partir de 1 500 $ font plus pour le chiffre d'affaires qu'un changement de plan. Le sentiment de « professionnalisme ». Plus n'est pas un label visible par vos clients. Ils voient votre boutique, votre checkout et vos délais de livraison. > **Le piège de l'engagement** > > L'engagement de trois ans se signe une fois. Une boutique qui passe à Plus pour un pic saisonnier ou un projet qui ne se concrétise pas paie le plan pendant trente-six mois. Faites le calcul sur le volume que vous avez, pas sur celui que vous espérez. ## Ce qu'une agence Shopify Plus fait concrètement Le plan ouvre des possibilités. L'agence les construit, et c'est là que l'écart entre deux agences Plus se creuse. ## Chantiers Plus et ce qu'ils impliquent | Chantier | Ce que l'agence fait | Ce que vous devez fournir | | --- | --- | --- | | Checkout personnalisé | Extensions d'interface, marque du checkout, Functions de paiement et de livraison | Les règles écrites en français courant, validées avant le code | | Migration Scripts vers Functions | Inventaire des Scripts, réécriture en Functions, tests sur un checkout de prévisualisation | L'accès aux Scripts existants et un exemple de chaque cas | | Boutiques d'extension par marché | Configuration paiements, livraison, taxes, thème partagé ou dérivé | Les règles de TVA, les transporteurs et les moyens de paiement par pays | | B2B | Catalogues, grilles tarifaires, conditions de paiement, comptes entreprise | La liste des clients, des tarifs et des conditions actuelles | | Intégrations ERP et facturation | Application personnalisée avec webhooks, files d'attente et rapprochement | Un accès au système cible et un interlocuteur côté finance | | Automatisations Flow | Flux de commandes, de stock et de clients | Les processus que votre équipe fait aujourd'hui à la main | Deux de ces chantiers méritent un mot de plus. La migration des Scripts. Les Scripts Ruby qui géraient vos remises et vos règles de livraison ne tournent plus. Les Functions font le même travail, en WebAssembly, avec une logique déclarative et des limites d'exécution strictes. Une agence qui a fait cette migration plusieurs fois sait où les comportements diffèrent, par exemple sur l'empilement des remises. Notre guide [des Scripts aux Functions](/shopify-scripts-to-functions) liste les cas. Le checkout. Depuis la fin de checkout.liquid, tout ce qui est personnalisé dans le checkout passe par des extensions d'interface ou des Functions. Une agence qui propose encore de modifier le checkout « dans le code » n'a pas fait la transition. ## Comment choisir une agence Shopify Plus Le badge Plus Partner est un filtre utile, pas une garantie. Les questions qui séparent les agences sont techniques et commerciales. Demandez des exemples de Functions et d'extensions de checkout en production, avec ce qu'elles font. Une agence Plus sans Function à montrer a construit ses boutiques Plus avant 2023 ou avec des applications. Demandez comment elle gère les dépréciations d'API. Shopify retire des versions selon un calendrier public ; une boutique Plus a plus de code sur mesure, donc plus d'exposition. Il doit y avoir un inventaire, un calendrier et un responsable. Demandez ce qu'elle laisse dans le thème et ce que votre équipe pourra modifier seule. Une boutique Plus où chaque changement de règle passe par l'agence a converti l'abonnement en dépendance. Demandez ce qu'elle vous déconseillerait de construire. Une agence qui répond « vous n'avez pas besoin de Plus pour ça » exerce un jugement, et c'est ce que vous achetez. Ces questions sont développées dans notre article [comment choisir une agence Shopify](/fr/comment-choisir-agence-shopify-12-questions-poser), qui s'applique aux agences Plus comme aux autres. ## Plus, Advanced, ou autre chose : décider proprement La décision se prend sur trois chiffres et une liste. Les trois chiffres : votre volume mensuel via Shopify Payments, ce que vous payez aujourd'hui en frais de transaction, et le coût des applications que Plus remplacerait. Si la somme des économies approche le coût du plan, la conversation commence. La liste : les besoins bloquants que vous avez aujourd'hui. Pas ceux que vous imaginez pour dans deux ans. Pour chacun, la question est « une Function, une extension ou une application le règle-t-elle sur mon plan actuel ». Si la réponse est oui pour tous, restez. Si un besoin reste sans réponse hors Plus et que les chiffres tiennent, passez, et faites-le avec un plan de migration écrit avant de signer l'engagement. La page [extensions de checkout et Shopify Functions](https://byteinfy.com/services/shopify-checkout-extensions) de ByteInfy décrit comment ce travail est cadré, sur Plus comme sur les autres plans. **Vous hésitez entre Plus et votre plan actuel** Envoyez vos besoins bloquants et votre volume mensuel, et vous recevrez une réponse écrite sur ce qui se construit sans Plus et ce qui le justifie. [Parler à ByteInfy](https://byteinfy.com/contact) ## FAQ ### Qu'est-ce que Shopify Plus apporte de plus qu'Advanced ? Principalement la personnalisation avancée du checkout (marque, certaines étapes de paiement), les fonctions B2B natives, les boutiques d'extension pour plusieurs marchés ou marques, des outils d'automatisation comme Flow avec plus de possibilités, et un support prioritaire. ### Combien coûte Shopify Plus ? Environ 2 300 $ par mois sur un engagement de trois ans au moment de la rédaction, avec des tarifs variables au-delà d'un certain volume de ventes. ### Faut-il une agence pour passer à Shopify Plus ? Pas pour l'abonnement lui-même. Une agence sert à exploiter ce que le plan débloque, checkout personnalisé, Functions, boutiques d'extension, intégrations ERP, et à migrer proprement ce qui tournait sur Scripts ou checkout.liquid. ### Les Shopify Scripts fonctionnent-ils encore sur Plus ? Non. Les Scripts sont dépréciés et les marchands Plus devaient migrer vers Shopify Functions avant 2025. Une boutique Plus qui repose encore sur des Scripts a une dette technique à traiter en priorité. ### Une boutique en France, en Belgique ou en Suisse a-t-elle des raisons spécifiques de passer à Plus ? Le cas le plus fréquent est le multi-marchés avec des exigences distinctes par pays, où les boutiques d'extension et le checkout personnalisé par marché apportent quelque chose. ### Que demander à une agence Shopify Plus avant de signer ? Des exemples de Functions et d'extensions de checkout en production, la manière dont elle gère les dépréciations d'API, ce qu'elle laisse dans le thème, et ce que votre équipe pourra modifier seule. --- --- title: "Checklist SEO Shopify 2027 : 25 points qui comptent vraiment" description: "La plupart des checklists SEO Shopify listent cent points dont quatre-vingts ne changent rien. Celle-ci en garde 25, classés par ordre d'impact, avec ce que chacun corrige." author: "Aashish Kaushik" published: 2026-09-09T13:00:52.415Z updated: 2026-09-09T13:00:52.436Z url: https://blog.byteinfy.com/checklist-seo-shopify-2027-25-points-qui-comptent --- # Checklist SEO Shopify 2027 : 25 points qui comptent vraiment ## Key takeaways - Les problèmes qui coûtent le plus de positions sur Shopify sont structurels, doublons d'URL collection/produit, pages de tags indexées et filtres crawlables, pas le choix des mots-clés. - Les données structurées Product, BreadcrumbList et Organization sont ce qui permet à Google et aux moteurs de réponse d'extraire et de citer vos pages. - La vitesse se perd surtout dans les applications, chaque script tiers coûte plus que la plupart des optimisations d'image ne rapportent. - Pour vendre en France, en Belgique et en Suisse, Shopify Markets gère les hreflang et les domaines localisés, à condition d'avoir choisi une structure et de s'y tenir. Le SEO Shopify se joue d'abord sur la structure, ensuite sur la vitesse, et seulement après sur le contenu. La plupart des boutiques francophones qui stagnent après leur première année n'ont pas un problème de mots-clés : elles ont des doublons d'URL, des pages de tags indexées, des applications qui ralentissent chaque modèle de page et des collections sans texte. Cette checklist garde 25 points, classés par ordre d'impact, et explique ce que chacun corrige. Elle est pensée pour une boutique qui vend en France, en Belgique et en Suisse, ce qui ajoute une question de structure internationale que les checklists anglophones ignorent. Pour le contexte général, notre [guide SEO Shopify](/shopify-seo-guide-2026) reste la référence longue ; cet article en est la version opérationnelle. > **Comment lire cette liste** > > Chaque point indique ce qu'il corrige et où le vérifier. Les cinq premiers valent plus que les vingt suivants réunis. Si vous ne faites qu'une chose ce mois-ci, faites la première section. ## Structure et URL : les cinq points qui changent tout Les doublons et les URL parasites diluent le signal avant que le contenu ne compte. Ces cinq points sont les plus rentables de la liste. 1. Les URL produit en double. Shopify crée pour chaque produit une URL /products/nom et une URL /collections/categorie/products/nom. La balise canonique pointe vers la première, mais le thème lie souvent la seconde depuis les grilles de collection. Vérifiez que les liens de collection utilisent l'URL canonique. Notre article sur le contenu dupliqué sur Shopify détaille le mécanisme. 1. Les pages de tags. Chaque tag de collection génère une URL /collections/categorie/tag. Indexées par défaut selon le thème, elles créent des dizaines de pages presque identiques. Passez-les en noindex, sauf pour les tags qui correspondent à une requête réelle et méritent une vraie collection. 1. Les filtres à facettes. Les filtres de recherche et découverte ajoutent des paramètres d'URL. Si le thème les rend en liens crawlables plutôt qu'en actions, Google explore des milliers de combinaisons sans valeur. Vérifiez dans Search Console le rapport de couverture : une explosion d'URL « explorées, non indexées » est le symptôme. 1. La pagination. Les pages 2, 3 et suivantes d'une collection doivent rester indexables avec un canonique vers elles-mêmes, pas vers la page 1. Certains thèmes font l'inverse et cachent les produits en profondeur. 1. Les collections « all » et les collections vides. /collections/all liste tout le catalogue et concurrence vos vraies catégories. Les collections vides après une rupture ou une fin de saison renvoient une page sans produit. Redirigez ou masquez. ## Pages produit et collection : le contenu qui vend et qui ranke Une fois la structure propre, les pages qui reçoivent le trafic doivent avoir de quoi le retenir. 1. Le titre de page produit. Le thème génère souvent « Nom du produit – Nom de la boutique ». Ajoutez la caractéristique décisive (matière, contenance, compatibilité) quand le nom seul ne dit rien. Le champ SEO de Shopify permet de l'écrire à la main. 1. La métadescription. Elle ne ranke pas, elle fait cliquer. Écrivez-la pour le marché : prix en euros ou en CHF, livraison en point relais, délai. Une description générique perd contre un concurrent qui annonce « livré en 48 h en Belgique ». 1. Le texte de collection. Une collection sans contenu est une liste de liens. Un paragraphe d'introduction utile et un bloc plus long sous la grille donnent à Google de quoi comprendre la catégorie. Le détail est dans le SEO des pages de collection. 1. Les variantes. Chaque variante peut avoir sa propre URL avec un paramètre ?variant=. Elles doivent rester canonicalisées vers le produit parent, sauf si une variante est cherchée en tant que telle (une couleur emblématique, un format), auquel cas un produit séparé se justifie. 1. Les descriptions produit. Le texte du fournisseur, copié sur cinquante boutiques, ne ranke nulle part. Réécrivez au moins les produits qui font le chiffre d'affaires, avec les questions que vos clients posent réellement. Notre article sur le SEO des pages produit donne la structure. 1. Le texte alternatif des images. Il sert l'accessibilité et Google Images, et il est vide sur la majorité des catalogues. Une phrase descriptive par image, pas une liste de mots-clés. Le sujet est traité dans le texte alternatif d'images sur Shopify. ## Données structurées : ce qui vous rend citable Les données structurées sont ce qui permet à Google d'afficher le prix et la disponibilité, et aux moteurs de réponse d'extraire vos pages avec confiance. 1. Le schéma Product. Prix, devise, disponibilité, avis. La plupart des thèmes récents l'incluent, mais souvent avec la mauvaise devise sur un marché localisé ou sans le champ de disponibilité. Testez une page produit par marché dans l'outil de résultats enrichis de Google. 1. Le schéma BreadcrumbList. Il donne à Google la hiérarchie collection → produit et s'affiche dans les résultats. Vérifiez qu'il reflète la collection canonique et non la première collection par ordre alphabétique. 1. Les schémas Organization et FAQ. Organization sur la page d'accueil avec le nom, le logo et les profils sociaux. FAQ sur les pages qui répondent à des questions réelles, pas sur toutes. Les moteurs de réponse citent les pages qu'ils peuvent extraire proprement, ce que notre article sur le GEO développe. ## Les 25 points par catégorie et par priorité | Catégorie | Points | Priorité | Où vérifier | | --- | --- | --- | --- | | Structure et URL | 1 à 5 | Haute | Search Console, rapport de couverture | | Pages produit et collection | 6 à 11 | Haute | Éditeur de thème, champs SEO | | Données structurées | 12 à 14 | Moyenne | Outil de résultats enrichis | | Vitesse et thème | 15 à 18 | Haute | CrUX, Search Console, Core Web Vitals | | Contenu et blog | 19 à 21 | Moyenne | Search Console, requêtes par page | | International FR, BE, CH | 22 à 24 | Haute si multi-pays | Shopify Markets, balises hreflang | | Suivi | 25 | Continue | Search Console, sitemaps | ## Vitesse et thème : là où les applications coûtent Les Core Web Vitals sont un signal de classement et, surtout, un facteur de conversion. Sur Shopify, la lenteur vient rarement du thème lui-même. 1. L'inventaire des applications. Chaque application installée peut ajouter un script chargé sur toutes les pages, y compris celles où elle ne sert à rien. Listez-les, mesurez ce que chacune coûte, désinstallez celles que Shopify remplace. C'est l'action de vitesse la plus rentable, comme l'explique notre article sur la vitesse des thèmes. 1. Les images. Dimensions adaptées au conteneur, format moderne, chargement différé sous la ligne de flottaison et jamais pour l'image principale. Shopify gère l'essentiel si le thème utilise correctement les paramètres d'image. 1. Les polices. Deux familles maximum, chargées avec un affichage de secours pour éviter le texte invisible. Les polices hébergées par Shopify se chargent plus vite que celles importées depuis un service tiers. 1. Le décalage de mise en page. Bannières, avis et widgets d'application qui s'insèrent après le chargement font sauter la page. Réservez leur espace dans le thème. Ce point se mesure dans Search Console sous Core Web Vitals, par modèle de page. ## Contenu et blog : ce qui apporte du trafic hors marque Le catalogue attire les requêtes de produit. Le contenu attire les requêtes d'avant-achat, celles où le client ne connaît pas encore votre marque. 1. Un blog qui répond à des questions réelles. Pas « nos nouveautés de printemps » mais « quelle taille choisir pour… », « comment entretenir… », « X ou Y, lequel ». Chaque article renvoie vers la collection ou le produit concerné. Notre guide du SEO de blog sur Shopify détaille la méthode. 1. Le maillage interne. Les collections lient vers les sous-collections, les produits vers les produits complémentaires, les articles vers les collections. Shopify ne le fait pas seul ; le thème et les métachamps le permettent. 1. La suppression du contenu mort. Les articles de 2019 sans trafic, les pages de campagne expirées, les produits archivés encore indexés. Redirigez vers le contenu vivant le plus proche plutôt que de laisser des 404. ## International : France, Belgique et Suisse sur une seule boutique Vendre dans trois pays francophones avec deux devises et des règles de TVA différentes est le point où les boutiques Shopify perdent le plus de temps. 1. La structure de marchés. Shopify Markets permet un sous-dossier par marché (/fr-be, /fr-ch), un sous-domaine ou un domaine par pays. Le sous-dossier est le plus simple à gérer pour le SEO, parce qu'il partage l'autorité du domaine principal. Choisissez une fois et ne changez plus sans plan de redirections. 1. Les balises hreflang. Shopify Markets les génère automatiquement pour chaque marché activé. Vérifiez qu'elles pointent vers des URL qui existent et répondent en 200, et que le marché par défaut porte bien la balise x-default. 1. Les prix et la devise par marché. Les prix en CHF pour la Suisse et en euros pour la France et la Belgique doivent apparaître dans le schéma Product du marché correspondant, avec la TVA du pays. Un prix en euros affiché à un visiteur suisse est un signal de confiance perdu avant même le clic. Nos articles sur Shopify en Belgique et Shopify en Suisse couvrent le paramétrage. ## Suivi : le point qui rend les 24 autres mesurables 1. Search Console, par page d'atterrissage. Vérifiez la propriété, soumettez le sitemap que Shopify génère, puis regardez les impressions et les clics par page plutôt que la position moyenne globale. Une checklist sans mesure est une liste de tâches. Avec Search Console, chaque point ci-dessus a un avant et un après. ## Avant de cocher un point comme terminé - La correction est visible dans le code source de la page, pas seulement dans l'éditeur - Elle est testée sur un modèle de page de chaque type (accueil, collection, produit, article) - Elle est testée sur chaque marché actif, pas seulement sur le marché par défaut - Le rapport Search Console concerné a été noté à la date de la correction - Le thème de secours a été conservé une semaine au cas où ## Ce que cette checklist laisse volontairement de côté Quelques pratiques courantes ne figurent pas dans les 25 points, parce qu'elles rapportent peu ou nuisent. La densité de mots-clés et le bourrage des balises. Un titre lisible bat un titre optimisé. Google comprend les synonymes depuis longtemps. Les applications SEO tout-en-un. Elles automatisent des balises que le thème gère déjà et ajoutent un script sur chaque page. Le gain est rarement mesurable ; le coût en vitesse l'est. Le sitemap manuel. Shopify génère et met à jour le sien. Soumettez-le, ne le remplacez pas. La réécriture des URL Shopify. La structure /products/ et /collections/ est imposée. Les contourner par des redirections en cascade coûte plus qu'elle ne rapporte. Le SEO d'une boutique migrée obéit aux mêmes règles, avec une contrainte de plus : préserver les positions existantes pendant la bascule. Notre article sur [la migration WooCommerce vers Shopify](/fr/migration-woocommerce-vers-shopify-sans-perdre-son-seo) traite ce cas. Pour une boutique qui préfère déléguer, un audit technique avec corrections démarre à 1 000 $ sur la page [SEO Shopify](https://byteinfy.com/services/shopify-seo) de ByteInfy, avec un rapport Search Console mensuel plutôt qu'un tableau de bord de vanité. **Votre boutique coche combien de ces 25 points** Envoyez l'URL de votre boutique et vos marchés actifs, et vous recevrez la liste de ce qui vous coûte des positions, classée par impact. [Parler à ByteInfy](https://byteinfy.com/contact) ## FAQ ### Par quoi commencer une checklist SEO Shopify ? Par la structure des URL. Les doublons entre /products/ et /collections/.../products/, les pages de tags indexées et les filtres crawlables diluent le signal avant même que le contenu ne compte. ### Shopify est-il mauvais pour le SEO ? Non. Shopify impose une structure d'URL fixe et quelques comportements par défaut discutables, mais tout ce qui compte se corrige dans le thème ou les paramètres. ### Faut-il une application SEO sur Shopify ? Rarement pour l'essentiel. Le thème gère les titres, les métadescriptions et les données structurées. ### Comment gérer le SEO pour la France, la Belgique et la Suisse sur une seule boutique ? Avec Shopify Markets. Il génère les balises hreflang, gère les prix en euros et en francs suisses et permet des sous-dossiers ou des domaines localisés. ### Les pages de collection doivent-elles avoir du texte ? Oui, mais un texte utile, placé sous la grille de produits ou en introduction courte. ### Combien de temps avant de voir un effet ? Les corrections de structure et de vitesse se mesurent dans Search Console en quelques semaines. Le contenu met plus longtemps. ### Que faire des pages de tags et des filtres ? Les laisser en noindex ou les canonicaliser vers la collection parente, sauf si un tag correspond à une vraie requête et mérite une collection dédiée. --- --- title: "Agence Shopify : combien coûte une boutique en 2027 (tarifs réels)" description: "Une boutique Shopify confiée à une agence démarre autour de 2 000 $ et grimpe avec le catalogue, les intégrations et le sur-mesure. Voici ce qui fait bouger le devis, et ce qu'il ne montre jamais." author: "Aashish Kaushik" published: 2026-09-09T05:00:16.817Z updated: 2026-09-09T05:00:16.836Z url: https://blog.byteinfy.com/agence-shopify-combien-coute-boutique-2027-tarifs-reels --- # Agence Shopify : combien coûte une boutique en 2027 (tarifs réels) ## Key takeaways - Trois variables expliquent l'essentiel de l'écart entre deux devis, le point de départ (thème ou sur-mesure), la taille du catalogue et le nombre d'intégrations. - Les prix de départ publiés par ByteInfy vont de 500 $ par mois pour la maintenance à 5 000 $ pour un headless, avec une boutique complète entre 2 000 et 8 000 $. - Le devis de construction n'est que la moitié du coût, l'abonnement Shopify, les frais de paiement, les applications, la TVA et la maintenance forment l'autre moitié. - Le devis le moins cher coûte souvent le plus sur douze mois quand il repose sur du code injecté dans le thème, des applications en cascade ou une livraison sans documentation. Une boutique Shopify réalisée par une agence ne se résume pas à un chiffre unique, mais les ordres de grandeur existent. Chez ByteInfy, une boutique prête à vendre sur Online Store 2.0 démarre à 2 000 $ et se situe le plus souvent entre 2 000 et 8 000 $ selon la taille du catalogue, les intégrations et les sections sur mesure. Une personnalisation de thème existant démarre à 1 000 $, une migration à 1 500 $, une boutique headless à 5 000 $. Ces tarifs sont en dollars américains, valables au moment de la rédaction, et ils ne disent rien tant qu'on ne sait pas ce qui fait passer un projet du bas au haut de la fourchette. C'est l'objet de cet article : expliquer ce que vous achetez réellement quand vous payez une agence Shopify, quels postes gonflent un devis, quels coûts n'y figurent jamais, et comment comparer deux propositions qui n'ont pas le même périmètre. > **Écrit par une agence** > > Lisez en gardant cela en tête. Les fourchettes ci-dessous sont les nôtres, publiées sur nos pages de services. D'autres agences, en France, en Belgique ou en Suisse, pratiquent des tarifs différents, souvent plus élevés à périmètre égal, parfois moins. Ce qui compte est de comparer le périmètre, pas seulement le total. ## Ce qui fait varier le devis Trois variables expliquent l'essentiel de l'écart entre un devis à 2 000 $ et un devis à 8 000 $ : le point de départ, le catalogue et les intégrations. Le point de départ. Une boutique construite sur un thème du Theme Store, adapté à votre charte, coûte moins cher qu'un thème conçu de zéro. Le thème premium couvre souvent la majeure partie du besoin, et l'agence n'a plus qu'à ajouter les sections manquantes. Un thème sur mesure se justifie quand la mise en page ou la logique de navigation ne rentre pas dans ce que le Theme Store propose. Le catalogue. Dix produits avec trois variantes chacun se configurent à la main. Deux mille références avec des tailles, des couleurs et des métachamps demandent un import scripté, des vérifications ligne par ligne et des modèles de page produit capables d'afficher ces données proprement. Les intégrations. Un ERP, un logiciel de facturation, un transporteur avec points relais, un outil d'e-mailing : chaque système à connecter ajoute du travail de cartographie et de test. C'est le poste le plus souvent sous-estimé dans un premier devis, parce que le marchand le considère comme acquis et que l'agence ne le découvre qu'au cadrage. Une quatrième variable pèse moins sur le prix initial mais beaucoup sur le coût total : ce que votre équipe pourra modifier seule après la livraison. Une boutique où chaque changement de bannière passe par l'agence transforme un coût unique en coût permanent. ## Les fourchettes de départ, poste par poste Voici les prix de départ publiés sur les pages de services de ByteInfy au moment de la rédaction. Ils sont exprimés en dollars américains, l'agence étant basée en Inde et travaillant avec des marchands internationaux. ## Prix de départ par prestation (USD, au moment de la rédaction) | Prestation | À partir de | Fourchette habituelle | | --- | --- | --- | | Création de boutique (Online Store 2.0) | 2 000 $ | 2 000 à 8 000 $ selon catalogue et intégrations | | Personnalisation de thème existant | 1 000 $ | 1 000 à 3 000 $ pour un jeu de sections ou une page de campagne | | Migration depuis WooCommerce, Magento ou Wix | 1 500 $ | Devis après cadrage pour les ERP et multi-boutiques | | Optimisation de vitesse | 750 $ | 750 à 1 500 $ pour un thème | | SEO technique | 1 000 $ | 1 000 à 3 000 $ par mois pour le contenu en continu | | Extensions de checkout et Shopify Functions | 1 500 $ | 1 500 à 3 000 $ par Function ou extension | | Boutique headless (Hydrogen ou Next.js) | 5 000 $ | Jusqu'à 25 000 $ et plus avec multi-marchés et CMS | | Maintenance mensuelle | 500 $ / mois | Surveillance et cinq heures de développement incluses | Ce tableau appelle deux remarques. D'abord, ces prestations s'additionnent rarement toutes : une boutique neuve inclut le paramétrage des paiements et de la livraison ainsi que le SEO technique de base. Ensuite, les postes en dollars sont soumis au taux de change du jour et, pour une entreprise assujettie, à l'autoliquidation de la TVA sur les prestations de services reçues d'un prestataire hors UE. Votre comptable saura le traiter, mais prévoyez-le dans votre budget. Pour la comparaison avec les agences locales, notre article sur [le coût d'une agence Shopify en Inde et aux États-Unis](/shopify-agency-india-usa-cost) détaille les écarts de tarif horaire et ce qu'ils recouvrent. ## Trois profils de projet et leur budget Les mêmes prix de départ donnent des totaux très différents selon le profil du marchand. Trois cas typiques, construits à partir de la grille ci-dessus et non de projets clients précis, montrent comment le budget se compose. Le lancement d'une marque avec vingt produits. Un thème du Theme Store adapté, quelques sections sur mesure pour la page d'accueil et la page produit, Shopify Payments avec les moyens de paiement locaux, une zone de livraison par pays. Ce projet reste dans le bas de la fourchette de création de boutique, et le poste suivant est presque toujours la vitesse et le suivi analytique. La refonte d'une boutique existante avec cinq cents références. Le catalogue est déjà sur Shopify, le thème a accumulé trois ans d'applications et de modifications inline. Le travail consiste à nettoyer, à reconstruire les sections proprement et à mesurer la vitesse avant et après. C'est souvent une personnalisation de thème dans sa fourchette haute plutôt qu'une création. La migration d'une boutique WooCommerce avec deux mille produits et un ERP. Ici, la migration à partir de 1 500 $ ne couvre que le déplacement des données et les redirections. Le thème, l'intégration ERP (à partir de 1 500 $ pour une connexion) et le suivi SEO post-bascule se chiffrent séparément. Le total dépasse celui d'une création simple, et c'est normal : il y a trois projets dans un. ## Thème du Theme Store ou boutique sur mesure La question qui décide le plus du budget mérite une réponse honnête plutôt qu'un réflexe. Un thème du Theme Store, personnalisé, convient à la majorité des marchands qui lancent ou relancent une boutique. Vous payez le thème une seule fois, l'agence adapte les couleurs, la typographie et ajoute les sections qui manquent. L'avantage est double : le prix, et le fait que le thème reçoit des mises à jour de son éditeur, à condition que l'agence n'ait pas modifié les fichiers de base. Un thème sur mesure se justifie dans trois cas : une identité visuelle que les thèmes existants trahissent, une logique de catalogue inhabituelle (configurateurs, produits composés, B2B avec grilles tarifaires), ou une équipe marketing qui a besoin d'un système de pages de campagne éditable sans développeur. Le headless (Hydrogen, Next.js) est un troisième niveau, et il est presque toujours prématuré en dessous d'un certain volume. Vous échangez les réglages par défaut de Shopify contre du contrôle, et vous héritez de tout ce que ces réglages géraient silencieusement : cache, SEO, comptes clients, recherche. Une agence sérieuse vous le dira avant de chiffrer. Notre comparatif [thème ou développement sur mesure](/shopify-theme-vs-custom) développe les critères. ## Les coûts que le devis ne montre pas Le devis de l'agence couvre la construction. Il ne couvre pas ce que la boutique coûte à faire tourner, et c'est là que les surprises arrivent. L'abonnement Shopify. Il se paie mensuellement, en plus de l'agence, et le plan choisi dépend de votre volume et des fonctions dont vous avez besoin. Shopify Plus, pour les grandes boutiques, démarre à environ 2 300 $ par mois sur un engagement de trois ans au moment de la rédaction. Les frais de transaction. Shopify Payments prend un pourcentage sur chaque commande, variable selon le pays et le moyen de paiement. Bancontact en Belgique, TWINT en Suisse et les cartes en France passent tous par ce canal, avec des taux différents. Un passage par un prestataire de paiement tiers ajoute des frais supplémentaires côté Shopify. Les applications. Une boutique moyenne en accumule vite une dizaine, chacune avec son abonnement mensuel. Une partie de la valeur d'une bonne agence consiste à vous dire lesquelles Shopify remplace nativement. La maintenance. Shopify publie en continu et retire des versions d'API selon un calendrier public. Tout ce qui est sur mesure doit suivre. Un devis qui ne mentionne pas la maintenance décrit la moitié du coût. La TVA. Pour une agence française, belge ou suisse, elle s'ajoute au devis hors taxes. Pour un prestataire hors UE, c'est l'autoliquidation. Dans les deux cas, ce n'est pas neutre pour une petite structure en franchise de TVA qui ne récupère rien. > **Le prix affiché n'est jamais le prix total** > > Additionnez l'agence, l'abonnement Shopify, les frais de paiement, les applications et la maintenance sur douze mois avant de comparer deux options. Un devis de construction plus élevé assorti de moins d'applications et d'une boutique que votre équipe peut modifier seule coûte souvent moins cher sur l'année qu'un devis bas suivi de dépendances. ## Agence locale ou agence à l'étranger Le choix entre une agence à Paris, Bruxelles, Genève ou à l'autre bout du monde est autant une question de mode de travail que de prix. Une agence locale partage votre fuseau horaire, votre langue et vos habitudes de facturation. Elle connaît Mondial Relay, Colissimo, Bancontact et TWINT sans qu'on ait à les lui expliquer. Elle coûte généralement plus cher à périmètre égal, parce que ses charges le sont. Une agence à l'étranger, comme ByteInfy en Inde, propose des tarifs plus bas et travaille en anglais, avec des échanges écrits possibles en français. Le décalage horaire se gère avec des démonstrations hebdomadaires et un canal écrit (WhatsApp, e-mail). Ce qui doit être vérifié, c'est la connaissance des spécificités de votre marché : TVA intracommunautaire, moyens de paiement locaux, transporteurs, mentions légales. Dans les deux cas, le critère qui compte est ce que l'agence a livré il y a deux ans et si cela tourne encore. Notre guide pour [engager une agence Shopify sans deviner](/hire-shopify-development-agency) liste les questions à poser, et sa version française, [comment choisir une agence Shopify](/fr/comment-choisir-agence-shopify-12-questions-poser), les adapte au marché francophone. ## Lire un devis correctement Deux devis pour « une boutique Shopify » peuvent décrire des projets sans rapport. Avant de comparer les totaux, vérifiez qu'ils parlent de la même chose. ## Ce qu'un devis Shopify doit préciser - Thème du Theme Store ou thème sur mesure, et lequel - Nombre de modèles de page livrés (accueil, collection, produit, pages de campagne) - Import du catalogue : combien de produits, de variantes, de métachamps, et qui fournit les données - Intégrations incluses (facturation, transporteur, e-mailing, ERP) et celles qui sont hors périmètre - Paramétrage des paiements, des zones de livraison et des taxes pour vos pays - Redirections 301 et suivi Search Console si vous migrez - Ce que votre équipe pourra modifier seule dans l'éditeur de thème - Durée du support après lancement et tarif de la maintenance ensuite - Propriété du code, accès au dépôt et documentation remise Un devis qui laisse plusieurs de ces points dans le flou n'est pas forcément malhonnête. Il est incomplet, et l'incomplétude se paie en avenants. ## Quand le prix bas coûte cher Le devis le moins cher est rarement le moins cher sur douze mois, pour des raisons précises. Le code injecté dans le thème. Certaines agences ajoutent leurs fonctionnalités directement dans les fichiers du thème plutôt que dans des sections ou des extensions d'application. Cela va plus vite. Cela empêche aussi les mises à jour du thème et laisse des débris que le développeur suivant devra nettoyer. Les applications à la place du développement. Installer une application pour chaque besoin fait baisser le devis initial et fait monter l'abonnement mensuel et le temps de chargement. Notre article sur [le nombre raisonnable d'applications](/how-many-shopify-apps-is-too-many) explique ce que chacune coûte en scripts. L'absence de vitesse mesurée. Une boutique lente perd des ventes et des positions. Un devis sérieux fixe un budget Core Web Vitals avant le lancement et le mesure. Corriger la vitesse après coup se facture séparément, à partir de 750 $ dans notre grille. La livraison sans documentation. Une boutique que seule l'agence comprend est une boutique où vous n'avez pas le choix du prestataire suivant. Le coût de ce verrouillage n'apparaît sur aucun devis et se paie pendant des années. ## Comment obtenir un devis fiable Un devis fiable commence par un brief précis, et vous contrôlez ce brief. Décrivez le problème plutôt que la solution. « Nos pages produit perdent les visiteurs mobiles avant le bouton d'achat » donne à l'agence quelque chose à résoudre. « Faites-nous un thème sur mesure » lui donne une instruction qui est peut-être la mauvaise. Dites ce qui ne doit pas changer : les URL, les intégrations dont vous dépendez, ce que votre équipe modifie déjà elle-même. Fournissez les chiffres : nombre de produits, de variantes, de commandes par mois, pays de vente, moyens de paiement attendus. Une agence qui chiffre sans ces données chiffre à partir d'un modèle, pas de votre situation. Demandez un premier périmètre réduit si le projet est gros. Un audit, une page de campagne ou une intégration vous apprend comment l'agence travaille pour une fraction du risque. Enfin, exigez un devis écrit avec un prix fixe et un calendrier. Un tarif horaire sans plafond est une invitation à découvrir le total à la fin. Pour ByteInfy, le processus est un appel de cadrage, puis un périmètre écrit avec un prix fixe. Les pages de [services](https://byteinfy.com/services) détaillent chaque prestation et son prix de départ. **Vous voulez un chiffre pour votre projet, pas une fourchette** Décrivez votre catalogue, vos pays de vente et vos intégrations, et vous recevrez un périmètre écrit avec un prix fixe. [Parler à ByteInfy](https://byteinfy.com/contact) ## FAQ ### Combien coûte une boutique Shopify réalisée par une agence ? Chez ByteInfy, une boutique prête à vendre sur Online Store 2. ### Quels coûts s'ajoutent au devis de l'agence ? L'abonnement Shopify mensuel, les frais de transaction de Shopify Payments, les abonnements aux applications, la TVA (ou son autoliquidation pour un prestataire hors UE) et la maintenance des développements sur mesure. ### Un thème du Theme Store suffit-il ou faut-il un thème sur mesure ? Un thème du Theme Store personnalisé convient à la majorité des boutiques. ### Pourquoi les agences facturent-elles parfois à l'heure plutôt qu'au forfait ? Le tarif horaire convient aux petites interventions et à la maintenance. ### Une agence à l'étranger est-elle moins chère qu'une agence française ? Généralement oui à périmètre égal, parce que ses charges le sont. ### Combien coûte la maintenance d'une boutique Shopify ? Le forfait de maintenance de ByteInfy démarre à 500 $ par mois avec surveillance et cinq heures de développement. ### Faut-il passer par Shopify Plus dès le départ ? Rarement. --- --- title: "Headless Shopify with Hydrogen: When It Pays Off" description: "Headless is not faster by default and not better by default. It buys you control, and control is only worth its price when you have something specific to do with it." author: "Aashish Kaushik" published: 2026-09-08T13:00:35.357Z updated: 2026-09-08T13:00:35.360Z url: https://blog.byteinfy.com/headless-shopify-hydrogen --- # Headless Shopify with Hydrogen: When It Pays Off ## Key takeaways - Headless removes the theme layer and gives you full control of the front end, at the cost of building and maintaining everything the theme provided. - It is not automatically faster — a badly built headless storefront is comfortably slower than a well-built Liquid theme. - The strongest genuine cases are unusual front-end requirements, a shared front end across several backends, and existing in-house React capability. - The hidden cost is everything the theme ecosystem gave you free: app blocks, the theme editor, and merchant self-service. Headless gets recommended for reasons that do not survive examination — mostly speed, and a general sense that it is more modern. Both are poor reasons, and following them produces expensive projects that end up slower than the theme they replaced. The architecture is genuinely valuable in specific circumstances. This is an attempt to name those precisely, and to be equally precise about the costs, which are consistently understated. > **The framing question** > > "What will we build that a theme cannot?" If the answer is not immediate and specific, the answer is a theme. ## What headless actually changes You stop using Shopify's theme layer. Shopify remains your backend — products, inventory, orders, checkout — and you build the storefront yourself, querying the Storefront API. Hydrogen is Shopify's React framework for doing this, usually deployed on Oxygen. It removes a chunk of the infrastructure work that made earlier headless builds expensive, and it is the supported path. What you gain is total control of the front end. What you lose is everything the theme layer was doing for you, and that list is longer than most projects account for. ## Speed is not the reason The most common justification, and the weakest. Headless does not make a storefront fast. It makes the performance ceiling higher, because you control exactly what loads and when. Reaching that ceiling requires discipline that many projects do not sustain. Meanwhile a heavy React storefront shipping a large JavaScript bundle is comfortably slower than a well-built Liquid theme, particularly on the mid-range mobile devices most commerce traffic uses. The honest comparison is not headless against a slow theme. It is headless against a well-optimised theme with unnecessary apps removed — and most stores considering headless for speed have not done that cheaper work first. Doing it usually recovers most of the available gain for a fraction of the cost. ## The cases where it genuinely pays Four, and they have in common that a theme cannot do the thing at all. **A front-end experience themes cannot express.** Genuinely unusual interaction, a configurator, a highly custom browsing model. Not "we want it to look bespoke" — themes handle bespoke fine — but interaction that the theme model structurally cannot support. **One front end over several backends.** Shopify for commerce, a separate CMS for editorial, other systems besides, presented as one experience. This is a strong case, and one theme-based stores handle awkwardly. **Existing React capability and appetite.** A team that already builds and maintains React applications is taking on much less new risk than a team that does not. Conversely, adopting headless as a first React project is adopting two problems. **Content-heavy commerce.** Where editorial and commerce genuinely interleave and the balance sits toward editorial, a custom front end over both sources can be cleaner than forcing it into a commerce theme. ## Reason and whether it holds | Stated reason | Verdict | | --- | --- | | "It will be faster" | Weak — optimise the theme first | | "It is more modern" | Not a reason | | "We need a custom interaction themes cannot do" | Strong | | "One front end, several backends" | Strong | | "Our team already builds React" | Supporting, not sufficient | | "We want more design control" | Weak — themes allow a great deal | | "Our agency recommended it" | Ask what specifically it enables | ## The costs that get understated **Storefront apps stop working.** The biggest one. Apps rendering on the storefront rely on theme app extensions, which a custom front end does not have. Reviews, upsells, video widgets, offer messaging — features you currently get by installing something become features you build and maintain. Audit your storefront apps before committing; the list is usually longer than expected. **Merchants lose the theme editor.** Whatever content editing your team does becomes something you build, through metafields, metaobjects or a separate CMS. Skip this and every copy change becomes a developer ticket, which is exactly the bottleneck most teams are trying to escape. **You own the front end forever.** Framework upgrades, dependency maintenance, browser compatibility, and accessibility all become your responsibility. A theme receives updates from its author; your storefront receives only what you give it. **Shopify's own front-end improvements stop arriving.** Platform work on themes and storefront performance does not reach a custom front end. Over several years this compounds quietly, and it is invisible at the moment you make the decision. ## Before committing to headless - Name the specific thing a theme cannot do - List every storefront app you rely on and what replaces each - Decide how merchants will edit content, and build it - Confirm you have React capability to maintain it, not just build it - Optimise your current theme first and measure what that recovers - Budget for ongoing maintenance, not just the build ## Hydrogen versus building it yourself If you go headless on Shopify, Hydrogen is the sensible default. It is Shopify's supported framework, it handles Storefront API integration idiomatically, and Oxygen removes hosting decisions. Rolling your own with a different framework is defensible when you have specific requirements that Hydrogen does not serve well, or existing infrastructure you are extending rather than replacing. It means more of the integration work is yours, and less of the ecosystem applies. For most teams the question is not which framework but whether to go headless at all. Once that is answered affirmatively, Hydrogen is usually the answer to the second question. ## What checkout does, and does not, change A frequent misconception worth settling: going headless does not mean building your own checkout. Checkout remains Shopify's. Your custom storefront handles browsing, product pages and cart, then hands off to Shopify checkout for payment. That is deliberate and it is good — checkout is the highest-risk surface on any store, it carries payment compliance obligations, and Shopify improves it continuously. Three consequences follow: **Checkout extensibility still applies.** UI extensions, Functions for discount and delivery logic, and branding through the admin all work the same way. Your investment there is not lost when the storefront changes. **The handoff is a design problem.** A shopper moving from your custom storefront to Shopify checkout crosses a visual boundary. Branding configuration narrows the gap but does not eliminate it, and a jarring transition at the moment of payment costs conversion. Plan the seam. **Cart state has to survive the transition.** This is ordinary work rather than difficult work, but it is work, and it is a place where headless builds acquire subtle bugs — a discount applied on the storefront that does not carry, or a cart that empties on return. ## Planning the migration itself If you decide headless is right, the migration carries risks that have nothing to do with the architecture and everything to do with replacing an entire front end at once. **URLs must not change.** Every product, collection and content URL should resolve exactly as before. This is the single largest SEO risk in the project and it is entirely avoidable. **Structured data must be rebuilt.** Your theme was emitting product schema. Your custom storefront emits whatever you write, and it is easy to ship without it and not notice for months. **Server-side rendering is not optional.** Content rendered only in the browser is content some crawlers and agents will not reliably see. Hydrogen renders on the server by default; the risk is in what gets added afterwards. **Run the two in parallel if you can.** Migrating a subset of templates first, or running the new storefront on a staging domain with real data, surfaces problems while the old one is still serving customers. > **Measure before and after, on the same terms** > > Take Core Web Vitals, conversion rate and organic traffic baselines before the switch. Headless migrations frequently coincide with a traffic change, and without a baseline you cannot tell a migration problem from a seasonal one — the two look identical for the first month, which is exactly when you need to know. ## A cheaper middle path Worth knowing before committing, because it satisfies a good share of the motivation at a fraction of the cost. Modern Shopify themes are considerably more flexible than the reputation suggests, and Horizon's block-based system with nested composition widened that further. A well-built custom theme can express most designs, and it keeps app compatibility, the theme editor, and platform improvements. For most stores whose motivation is design control, a custom theme is the right answer. Headless is for when the constraint is structural rather than aesthetic. A useful test before committing either way: brief a designer to produce the storefront you actually want, then ask an experienced Shopify developer whether a theme can build it. If the answer is yes with some custom work — which it usually is — you have your answer, and you have it before spending the budget rather than after. For theme capabilities and the redesign decision, see [storefront and design](/category/storefront-design). Development considerations more broadly are covered in [Shopify development](/category/shopify-development), and the performance question in the storefront archive. **Not sure whether you need headless or a better theme?** ByteInfy builds both — custom Shopify themes and Hydrogen storefronts — and will tell you plainly which one your requirements actually justify. [Start a project](https://byteinfy.com/#contact) ## FAQ ### Is headless Shopify faster than a normal theme? Not inherently. Headless gives you control over what loads and when, which makes excellent performance achievable. ### What is Hydrogen? Shopify's React-based framework for building custom storefronts against the Storefront API, usually deployed on Oxygen, Shopify's hosting for it. ### Do Shopify apps work with a headless storefront? Storefront-facing apps generally do not, because they rely on theme app extensions that a custom front end does not have. Admin-side apps continue working. ### Can merchants still edit a headless storefront? Not through the theme editor, which does not apply. Whatever content editing merchants need has to be built, usually through metafields, metaobjects or a separate content system. ### When should I not go headless? When your reason is speed alone, when your team has no React capability, when you depend on storefront apps, or when the honest answer to "what will we build that a theme cannot" is unclear. --- --- title: "Passing Shopify App Store Review the First Time" description: "Review is not a formality at the end of a build. A large part of the checklist describes architecture, and discovering that after the app is written is how timelines slip." author: "Aashish Kaushik" published: 2026-09-08T05:00:16.335Z updated: 2026-09-08T05:00:16.529Z url: https://blog.byteinfy.com/shopify-app-review-guide --- # Passing Shopify App Store Review the First Time ## Key takeaways - The requirements checklist is public and substantially architectural — read it before building, not before submitting. - The common rejection causes are consistent: mandatory webhooks, billing edge cases, an onboarding a reviewer cannot complete, and code injected into themes. - Reviewers install your app on a fresh store with no data, which is the state most developers never test. - Resubmission costs calendar time you cannot compress, which matters most when a launch date has been announced. App review is commonly treated as an administrative step at the end of a build. That framing is why timelines slip. A substantial share of Shopify's requirements describe architecture rather than presentation — how your app authenticates, how it bills, how it renders on a storefront, what it does when a merchant asks for their data. Discovering those after the app is written turns a fortnight of work into a rewrite. > **Read the checklist first** > > Shopify publishes its requirements. Reading them at the start of a project costs an hour and changes design decisions. Reading them before submission costs weeks. ## What reviewers actually do Understanding the process makes the requirements easier to anticipate. A reviewer installs your app on a **fresh development store**. No products, no orders, no customers, no configuration. They follow your onboarding as a merchant would, try the core function, check billing, and look at what your app does to the storefront. That fresh-store state is the one most developers never test. Your development environment has data because you have been building against it for months. A reviewer's does not, and an app that assumes existing products or prior configuration will fail immediately in a way you have never seen. ## The recurring rejection causes Consistent enough to be worth listing plainly. **Mandatory compliance webhooks missing or incomplete.** Customer data request, customer redaction, shop redaction. Required, easy to implement, and routinely left until last. **Billing edge cases unhandled.** Trials, upgrades, downgrades, failed payments, what happens when a merchant cancels mid-cycle. Billing is where apps look finished and are not. **Onboarding a reviewer cannot complete.** Requires an external account, assumes existing data, has a step that fails silently on an empty store, or simply does not explain what to do first. **Storefront code injected into themes.** Writing snippets into theme files rather than using theme app extensions. This is both a rejection cause and the thing merchants complain about most, since injected code frequently survives uninstall. **Insufficient documentation.** A reviewer who cannot work out what your app does, or how to test it on an empty store, will reject it — and they are right to. **OAuth handled incorrectly.** Particularly around reinstalls and scope changes, which are the paths developers test least of all. ## Requirement area and what actually fails | Area | Common failure | | --- | --- | | Compliance webhooks | Not implemented, or return the wrong status | | Billing | Downgrades and cancellations unhandled | | Onboarding | Assumes data that a fresh store lacks | | Storefront rendering | Theme file injection instead of app extensions | | OAuth | Reinstall and scope change paths untested | | Documentation | Missing, or written for developers not reviewers | | Performance | Storefront weight not measured | | Uninstall | Leaves code or data behind | ## Test on an empty store The single highest-value thing you can do before submitting, and it takes an afternoon. Create a fresh development store. Install your app as a merchant would, from nothing. Then walk the whole path: ## The fresh-store test - Install the app with no products and no configuration - Complete onboarding without consulting your own documentation - Trigger the core function on an empty catalogue - Add one product, and check the app behaves sensibly - Subscribe to a paid plan, then downgrade, then cancel - Uninstall, and inspect what remains in the theme and in your database - Reinstall, and confirm the previous state is handled correctly Each of those steps corresponds to a rejection cause. Working through them yourself finds the problems before a reviewer does, and finding them yourself costs days rather than review cycles. ## Build against the checklist continuously The practical difference between a smooth review and a painful one is when the checklist enters the project. **At the start**, it shapes architecture. You choose theme app extensions because you know injected code is a problem. You implement compliance webhooks in the first sprint because you know they are required. You design onboarding for an empty store because you know that is what a reviewer sees. **At the end**, each of those becomes rework, and rework on foundational decisions is expensive. There is no trick here beyond timing. The requirements are public and stable enough to plan against, and none of them are surprising once read. Treating them as design inputs rather than as a final exam is the whole technique. ## Performance is part of it Worth separating because developers under-weight it. Any app rendering on a storefront adds requests and JavaScript to pages merchants care about. Reviewers look at this, and more importantly merchants look at it — an app that visibly costs Core Web Vitals is the first one removed during a cleanup, regardless of how good its features are. Load only where your feature is used. Defer what you can. Measure on a realistic storefront with a real theme and other apps installed, not on a clean development store where yours is the only script on the page. ## Documentation for a reviewer, not a developer A specific and commonly missed distinction. Your developer documentation explains how the app works. What a reviewer needs is different: what the app does, how to set it up on a fresh store, what to test, and how to reach you if something is unclear. Write that separately and keep it short. A reviewer who can follow a clear five-step test path will do so; one who has to infer it will find something to reject. ## The listing is reviewed too Developers focus on the app and forget that the App Store listing is part of what gets assessed, and part of whether anyone installs afterwards. **Screenshots must show the actual app.** Mockups, marketing renders and interfaces that do not match the shipped product are a rejection cause and, separately, produce uninstalls from merchants who expected something else. **The description must describe what it does**, not what it will do next quarter. Claiming functionality that is not there fails review and generates support load if it slips through. **Pricing must match reality.** What the listing says and what the billing API charges have to be the same, including trial length and what each tier includes. **Support contact must work.** A reviewer may use it. So will merchants, and an unanswered support address is visible in your reviews within weeks. **Category and search terms should be honest.** Listing in categories your app does not genuinely serve produces installs from merchants who will churn and leave a one-star review explaining why. ## After approval, the work changes Passing review is a milestone rather than an ending, and two things start immediately. **Merchants will use it in ways you did not anticipate.** Themes you have never seen, apps you have never heard of touching the same surface, configurations you assumed were impossible. Building your app so it can be diagnosed from the outside — logs recording what it did for a given shop, a status view showing its own configuration — turns a multi-day support exchange into a two-minute answer. **Your reviews become your marketing.** They are public and permanent, and how you respond to criticism is read by every prospective merchant. A one-star review answered helpfully demonstrates support in a way no listing copy can; the same review left unanswered is the first thing people see. There is also the ongoing obligation nobody enjoys. Shopify versions its APIs and retires old ones on a published schedule, so an app that ships and is never touched again will eventually break on someone else's timetable. Decide early how you track deprecations and how often you upgrade, because an app carrying years of version debt is far harder to move than one kept current. > **Keep a fresh install path working forever** > > The empty-store test is not only for review. Every merchant who installs your app is a fresh store, and it is the state you will keep breaking as you add features to the version you use daily. Re-run it before every significant release. ## Plan for the resubmission you hope not to need Even well-prepared apps sometimes come back with something. Budget for at least one cycle in your timeline. This matters most when a launch date has been communicated — to a client, to a marketing plan, to a partner — because review time is calendar time you cannot compress by adding effort. The other reason to leave slack: fixing a blocking issue sometimes reveals the next one, since a reviewer who could not get past step two has not yet seen step five. When a rejection does arrive, read it literally and fix exactly what it names before resubmitting. Developers frequently interpret a specific rejection as a general criticism, rewrite more than was asked, and introduce something new. If the feedback is ambiguous, ask rather than guess — a clarifying question costs a day and a wrong guess costs a full cycle. For the wider build considerations, see [Shopify development](/category/shopify-development). The public-versus-custom decision, which determines whether review applies at all, is covered in the same archive. **Building an app and want it through review first time?** ByteInfy designs, builds and ships Shopify apps — architecture against the requirements checklist from day one, through review and into production. [Start a project](https://byteinfy.com/#contact) ## FAQ ### How long does Shopify app review take? It varies, and the number that hurts is not the first review but the round trip after a rejection. ### What are the most common reasons apps get rejected? Missing or incomplete mandatory webhooks, billing that does not handle required cases, an onboarding flow a reviewer cannot complete on a fresh store, insufficient documentation, and storefront features implemented by injecting code into themes rather than using theme app extensions. ### Do I need to implement GDPR webhooks? The mandatory compliance webhooks — customer data request, customer redaction and shop redaction — are required, and missing them is a straightforward rejection. ### Does my app need to work on every theme? It needs to work on the themes a reviewer will try, and in practice to work broadly across the ecosystem. ### Can I fix issues and resubmit quickly? You can resubmit, but each cycle takes time and reviewers may find new issues once a blocking one is resolved. --- --- title: "Custom Shopify App or Public App: How to Choose" description: "A custom app assumes one merchant, one theme, one configuration. A public app can assume none of those, and that difference runs through the whole build." author: "Aashish Kaushik" published: 2026-09-07T13:00:31.133Z updated: 2026-09-07T13:00:31.137Z url: https://blog.byteinfy.com/custom-vs-public-shopify-app --- # Custom Shopify App or Public App: How to Choose ## Key takeaways - The decision precedes any code and determines review obligations, billing, support burden and how much you may assume. - A custom app can assume one theme and one configuration; a public app must work on stores you will never see. - Retrofitting a custom app into a public one usually means rewriting the assumptions, because the assumptions are load-bearing. - Build custom when you have a client, public when you have a market — and be honest about which you actually have. The public-versus-custom decision gets made casually and then constrains everything afterwards. It is worth about an hour of deliberate thought, because it is expensive to reverse. The core difference is not distribution. It is **how much you are allowed to assume**. > **The one-sentence test** > > Build custom when you have a client. Build public when you have a market. Confusing the two is where the expensive mistakes start. ## What each one actually is **A public app** is listed on the App Store and installable by anyone. You get discovery — merchants find you without you finding them — and in exchange you accept Shopify's review, the requirements checklist, a support obligation to strangers, and a product that must work on themes and configurations you will never see. **A custom app** is built for one merchant. No listing, no review, no unknown themes. You can assume their theme, their catalogue shape, their business rules. You also get no distribution, and if that client leaves, the app has no other market. ## The practical differences | Public app | Custom app | | --- | --- | | Distribution | App Store discovery | None | | Review process | Required | Not required | | Requirements checklist | Applies fully | Largely not | | Themes to support | All of them | One | | Support burden | Unknown merchants, at scale | One known client | | Billing | Shopify billing API, revenue share | Whatever you agree | | Cost to build | Higher | Lower | | Ongoing cost | Support, review, compatibility | Maintenance for one client | ## Assumptions are the whole difference This is the part that determines cost, and it is worth being concrete. A custom app can assume the merchant's theme structure, so storefront rendering is straightforward. It can assume their product data is shaped a particular way. It can assume a specific set of other apps is installed. It can assume the merchant knows how to use it, because you will show them. A public app can assume none of that. Every theme is different. Product data varies wildly in completeness. Other apps you have never heard of will touch the same cart. And onboarding has to work for a merchant with no context, on an empty store, without you present. That is why a public app costs more to build for the same visible functionality. Most of the extra work is invisible in a feature list. ## The retrofit trap The most common expensive mistake in this decision. A team builds a custom app for a client, it works well, and someone suggests listing it. The reasoning seems sound — the hard part is done, it just needs a listing. It rarely works out that way, because the assumptions are load-bearing. One theme becomes every theme. One configuration becomes every configuration. One client who can be phoned becomes a support queue of strangers. Onboarding designed for a handover meeting has to work unattended on an empty store. The realistic answer is usually a substantial rewrite of everything except the core logic. That does not mean never do it. It means decide honestly at the start: if listing is a genuine intention, build public from day one and accept the higher cost. If it is a vague possibility, build custom and treat any future listing as a new project with its own budget. ## Choose custom when **You have a specific client with a specific need.** The clearest case, and the most common. **The requirement is genuinely unique to their business.** Nobody else would install it, so distribution is worth nothing. **It integrates with systems only they have.** An ERP, a warehouse system, a bespoke internal tool. **Speed matters more than reach.** A custom app can ship considerably faster, because it skips review entirely and can assume its own environment. ## Choose public when **You have identified a real market**, not a hypothetical one. Ideally several merchants have asked for the same thing. **The function generalises.** If solving it for one merchant solves it for a hundred, distribution is worth having. **You can sustain support.** This is the condition most often underestimated. A public app generates tickets indefinitely, and most are not bugs — they are themes behaving unexpectedly, other apps conflicting, and merchants configuring things in ways you did not imagine. **You want recurring revenue** rather than project fees, and you are prepared for the ongoing obligation that comes with it. ## Before committing either way - Name who will install this — a client, or a market you can describe - Decide whether listing is a genuine intention or a vague possibility - Establish who handles support in a year, and whether they can - Confirm your billing model matches the choice - Check whether the requirement generalises or is genuinely specific - Budget for review and compatibility if public, maintenance if custom ## The middle options people forget The choice is presented as binary and there are two other arrangements worth knowing, both of which suit situations where neither pure option fits. **An unlisted public app.** Built as a public app, subject to the same architecture, but not surfaced in App Store search. Installed by direct link. This suits a small set of known merchants — a group of clients, a franchise network, several stores under one ownership — where you want the discipline and multi-store capability of a public app without a listing. **A public app with a private tier.** A listed app that also serves specific clients with configuration or features they paid for. Common among agencies who built something for one client, found it generalised, and now run both models from one codebase. Both add complexity, and neither should be chosen first. But if you find yourself saying "it is custom, but for four merchants", one of them is probably what you actually need — and building four custom apps, or one custom app with hardcoded branches for four clients, is the outcome to avoid. ## Ownership and what happens afterwards A commercial question that developers under-discuss and clients care about a great deal. **Who owns the code?** For custom work this needs settling in writing before the build. A client paying for a bespoke app usually assumes they own it; agencies often assume they retain reusable components. Both positions are reasonable and they need reconciling in advance rather than at the point of separation. **Who maintains it?** Shopify ships continuously and retires API versions on a published schedule. An app that is built and never touched will eventually break, on someone else's timetable. Somebody has to own that, and "the agency, presumably" is not an arrangement. **What happens if the relationship ends?** A custom app with no documentation, built by an agency the client no longer works with, is one of the more expensive positions a merchant can be in. Documentation and a clean handover path are worth agreeing at the start, when nobody is annoyed. **For public apps, what happens if it stops paying?** Apps get abandoned, and merchants who built workflows around them are left stranded. If you are building public, having an honest position on what you would do — sunset gracefully, open-source it, sell it — is worth more than pretending the question will not arise. > **Decide the maintenance arrangement before you build** > > The most common failure in custom app work is not technical. It is an app that works perfectly for eighteen months, breaks when an API version is retired, and belongs to nobody. Name who watches for deprecations and who pays for the upgrade, in the same conversation where you agree the build. ## What custom apps should borrow from the checklist A closing point worth making, because it is easy to lose. Custom apps skip App Store review, which removes real work. It also removes a discipline that was doing something useful. Several requirements on that checklist are good practice regardless of who installs the app: handling reinstalls and scope changes properly, implementing compliance webhooks, using theme app extensions rather than injecting code into themes, and not leaving debris behind on uninstall. A custom app that ignores all of it is cheaper to build and worse to live with — particularly for the client, who inherits theme injection and an app that cannot be cleanly removed. Read the checklist even when it does not apply to you, and adopt the parts that are about quality rather than about listing. The same applies in reverse to the parts that genuinely do not matter for a single merchant. A custom app does not need a polished onboarding flow for someone with no context, because you will be in the room. It does not need to handle every theme. Skipping those is not cutting corners; it is the whole reason custom is cheaper. The discipline is distinguishing between requirements that exist because the App Store demands them and requirements that exist because the software should be good. For the wider build considerations, see [Shopify development](/category/shopify-development). The review process specifically is covered in the same archive, and the app-versus-custom-work question from a merchant's side in [Shopify apps](/category/shopify-apps). **Building an app and unsure which shape it should be?** ByteInfy designs and builds both — custom apps for single merchants and public apps through App Store review — and will say plainly which your situation warrants. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What is the difference between a custom and a public Shopify app? A public app is listed on the Shopify App Store, installable by any merchant, and subject to Shopify's review and requirements. ### Do custom Shopify apps need to pass App Store review? No. App Store review applies to public listings. ### Can I turn a custom app into a public one later? You can, but it is usually more work than expected. A custom app is built assuming one theme, one configuration and one set of business rules. ### Which is cheaper to build? Custom, usually by a considerable margin, because it can assume things a public app cannot. ### How do custom apps handle billing? However you agree with the client, typically outside Shopify's billing API — an invoice, a retainer, a project fee. Public apps generally use Shopify's billing with its revenue share. --- --- title: "How to Structure BFCM Offers That Do Not Destroy Margin" description: "Most BFCM margin damage is decided in October, when someone picks a headline discount without modelling what it does to average order value, returns and January demand." author: "Aashish Kaushik" published: 2026-09-07T05:00:20.531Z updated: 2026-09-07T05:00:20.540Z url: https://blog.byteinfy.com/bfcm-offer-structure --- # How to Structure BFCM Offers That Do Not Destroy Margin ## Key takeaways - Black Friday 2026 falls on 27 November and Cyber Week runs 27 November to 3 December, so offer structure needs to be settled by late October. - A flat sitewide percentage is the easiest offer to build and the hardest to recover from, because it discounts your best sellers at the same rate as your slowest stock. - Threshold and bundle mechanics raise average order value instead of cutting unit margin, which is why they survive contact with a spreadsheet. - Model the discount against contribution margin, not gross margin — shipping, payment fees and BFCM return rates all move against you at once. The offer is usually decided in a twenty-minute conversation in October. Someone suggests 30%, someone else says competitors did 40% last year, and the number is set. Everything after that — the emails, the landing page, the inventory buy — is execution against a figure nobody modelled. That conversation is where most BFCM margin is lost, and it happens early enough to fix. Black Friday 2026 is Friday 27 November, with Cyber Week running 27 November to 3 December, which means the structural decisions want to be settled by late October at the latest. > **What this covers** > > Offer mechanics and margin structure. Inventory, fulfilment and checkout readiness are separate problems with their own deadlines, covered in the rest of the BFCM series. ## The flat percentage is the easiest choice and the most expensive A sitewide percentage is attractive because it is trivially easy to build, communicate and understand. It is also the only offer structure that guarantees you discount every product at the same rate regardless of whether that product needed discounting. Consider what that means in practice. Your best-selling item, which sells at full price all year and would have sold through BFCM anyway, gets the same 30% as the slow-moving stock you actually wanted to clear. In absolute terms you gave away the most margin on the products that needed the least help. There is a second cost that shows up in January. A store that runs a deep sitewide discount every November teaches its customers that November is when you buy. Demand does not disappear — it moves. The revenue looks fine in the BFCM report and worse in the annual one, and the two are rarely compared. None of which makes a flat percentage always wrong. It is defensible with broad overstock, with a catalogue of fairly uniform margin, or where the headline number is itself the marketing. It is a bad *default*, which is what it usually is. ## Mechanics that raise order value instead of cutting unit margin The structural alternative is to build offers that change what a shopper buys rather than what they pay per unit. ## Offer mechanics and what each one does to margin | Mechanic | Effect on unit margin | Effect on order value | Best used for | | --- | --- | --- | --- | | Flat sitewide % | Falls on every unit | Neutral | Broad overstock, uniform margin | | Tiered spend threshold | Unchanged below threshold | Rises | Raising AOV on a deep catalogue | | Free gift over threshold | Cost of gift only | Rises | Moving a specific SKU while protecting price | | Bundle at a set price | Blended across the bundle | Rises | Attaching slow stock to a best seller | | Buy X get Y | Falls on the Y unit only | Rises | Volume clearance without touching headline price | | Category-specific % | Falls only where you chose | Neutral | Targeted clearance, protects best sellers | The pattern is that everything except the flat percentage either protects your unit economics or gives you control over exactly where the discount lands. A free gift over a threshold costs you the gift, not a percentage of every order. A bundle blends margin across products you chose to pair. A tiered threshold costs nothing at all from shoppers who were going to spend below it. These mechanics also compose better with each other than percentages do. Two overlapping percentage discounts produce an outcome nobody modelled; a threshold plus a bundle is legible. ## Model against contribution margin, not gross margin This is the single most common analytical error, and it is what turns a survivable discount into a loss-making one. Gross margin is revenue minus cost of goods. It is the number most merchants have to hand and the one they discount against. But BFCM moves several other costs at the same time, all in the wrong direction: ## Costs that rise during BFCM and belong in the model - Shipping subsidy — free-shipping thresholds are far more commonly hit during a discount period - Payment processing, which is a percentage and therefore scales with order volume, not margin - Return rate, consistently higher on discounted and gifted purchases than on full-price ones - Support cost per order, as discount mechanics generate questions that full-price purchases do not - Ad costs, since auction prices rise across the whole BFCM window Work the arithmetic on your actual numbers before committing. A 35% discount on a product carrying 60% gross margin looks comfortable. Subtract a subsidised shipping cost, payment fees, an elevated return rate and the acquisition cost of the order, and the same offer can land close to break-even — and that is before you count the full-price sales it cannibalised. > **The cannibalisation question nobody asks** > > A share of BFCM revenue would have arrived anyway at full price. If you cannot estimate that share, you cannot tell whether the promotion made money. A rough estimate from last November's baseline is far better than assuming it is zero, which is the implicit assumption in most BFCM reporting. ## Decide what each offer is actually for Offers fail when they are asked to do several jobs at once. Before setting a mechanic, name the goal — because different goals point at different structures. **Clearing specific stock.** Category or product-level discounts, or a bundle that attaches the slow item to something that sells. Not a sitewide percentage, which discounts the stock you needed to clear at the same rate as everything else. **Raising average order value.** Tiered thresholds and free gifts. The mechanic should make a larger basket obviously worthwhile at a specific, stated number. **Acquiring new customers.** A strong entry offer on a genuine entry product, with the discount concentrated at first purchase rather than spread across the catalogue. This is the one case where accepting weak margin is straightforwardly rational, provided you know your repeat rate. **Defending against competitors.** Usually the worst reason to discount, and the most common unstated one. If a competitor's price is the trigger, the honest question is whether you are in a price fight you can win. ## What happens when two offers meet Every offer you run interacts with every other offer you run, and with the discount codes still circulating from earlier campaigns. This is where BFCM promotions break, and it breaks at checkout on the busiest day of the year. Shopify's native discounts have real limits on combination. Automatic discounts and discount codes can be configured to combine in specific ways — product, order and shipping discounts have distinct combination rules — but the behaviour is not arbitrary and it is not always what a merchant assumed when they built two offers independently a fortnight apart. The failure modes are consistent: - Unintended stacking. A tiered threshold plus an existing subscriber code produces a total discount nobody signed off on, on a basket large enough to matter. - Silent non-application. The shopper qualifies for two offers, gets one, and does not understand why the number differs from the landing page. This one is worse than it looks because it does not error — it just quietly converts less. - Free gift plus percentage. The gift is added at a discounted price rather than free, or the percentage applies to the gift line, producing a total that reads as a bug. The test that catches these is dull and non-negotiable: build every offer in a staging environment, then walk the actual customer path for each combination a real shopper could reach. Include the codes you have already sent out and forgotten about, and include the case where someone has an abandoned cart from before the offers went live. Anything you cannot make behave correctly should be made mutually exclusive rather than left to resolve itself at checkout. An offer that does not stack is a communication problem; an offer that stacks wrongly is a margin problem you discover in the reconciliation. ## The timeline that actually works Preparation timing is one of the few areas with consistent evidence behind it: merchants who begin BFCM preparation well in advance reliably outperform those who assemble it in November, and the recommended runway has lengthened year on year. A workable sequence from here: 1. Early October — model two or three candidate offer structures against contribution margin on real product-level data. 2. Mid October — choose the mechanics and lock them. Late changes to discount logic are where checkout bugs come from. 3. Late October — build and test the offers in a staging environment, including how they interact and what happens when a shopper qualifies for two. 4. Early November — freeze offer logic. Test the actual customer path end to end, on mobile, as a new customer. 5. Mid November — warm the list. The offer should not be the first message a subscriber has received in three months. The freeze in step four matters more than it looks. Discount logic is the most fragile thing on a store during the highest-traffic week of the year, and every change after the freeze is a change you are shipping without time to observe it. For the mechanics of building these offers on Shopify — where native discounts stop and Functions begin — see the [promotions and offers](/category/promotions-offers) archive. Checkout-side readiness is covered separately in [checkout and payments](/category/checkout-payments), and the full sequence lives in the [BFCM 2026](/series/bfcm-2026) series. **Want the offer logic built and tested before the freeze?** ByteInfy builds Shopify discount mechanics with Functions — tiered thresholds, gifts, bundles and stacking rules that behave under load. [Start a project](https://byteinfy.com/#contact) ## FAQ ### When is Black Friday 2026? Black Friday falls on Friday 27 November 2026 and Cyber Monday on Monday 30 November, with Cyber Week generally treated as 27 November to 3 December. ### Is a sitewide percentage discount ever the right answer? Sometimes. It is defensible when you have broad overstock, when your catalogue has fairly uniform margin, or when your brand is well known enough that the headline number is itself the marketing. ### How deep does a BFCM discount need to be to get noticed? Less deep than most merchants assume, if the offer is structured well. ### Should I discount my best sellers? Usually not at the same rate as everything else. Your best sellers would have sold anyway, so every point of discount on them is margin given away rather than demand created. ### What is the most common BFCM margin mistake? Modelling on gross margin and forgetting that shipping subsidies, payment processing and return rates all rise during BFCM. --- --- title: "Hiring a Shopify Development Agency Without Guessing" description: "A portfolio proves something was built. It says nothing about whether it still works, who maintains it, or what it left behind in someone's theme." author: "Aashish Kaushik" published: 2026-09-06T13:00:26.219Z updated: 2026-09-06T13:37:37.273Z url: https://blog.byteinfy.com/hire-shopify-development-agency --- # Hiring a Shopify Development Agency Without Guessing ## Key takeaways - A portfolio shows what shipped, not what survived — ask what they built two years ago and whether it still runs. - How an agency handles storefront rendering and API versioning tells you more than any case study. - The handover terms decide whether you end up with an asset or a dependency, and they are easiest to agree before the work starts. - An agency that will tell you not to build something is exercising judgement rather than selling scope. Evaluating a development agency is hard because the work is invisible to the buyer. You can see the storefront and not the code, and the difference between the two only becomes apparent when something needs changing eighteen months later. Portfolios do not help much with this. They show that something was built and launched. They say nothing about whether it still works, what it cost to maintain, or what it left behind in someone's theme. > **Written by an agency** > > Read accordingly. The questions below are ones we would expect to be asked, and an agency that answers them uncomfortably is worth being careful about — including us. ## Ask about the work that is two years old The most revealing question available, and it is rarely asked. Anyone can launch something. The interesting question is what happened afterwards: does it still run, has it needed emergency work, did it survive the platform changes that have happened since. Shopify ships continuously and retires API versions on a published schedule. Legacy Scripts stopped running on 30 June 2026, checkout extensibility replaced `checkout.liquid`, and Horizon changed what themes can express. An agency that has been building for several years has lived through all of that, and how they handled it is a better signal than anything in a case study. Ask specifically whether their older work needed rescuing, and what they did about it. ## The technical questions that separate agencies Six, and the answers are informative even if you cannot fully evaluate them. **"How do you handle storefront rendering for apps?"** The answer should be theme app extensions. An agency still injecting code into theme files is building something merchants cannot cleanly remove. **"How do you handle API deprecations?"** There should be a process — an inventory, a schedule, someone assigned. "We deal with it when it comes up" means you will deal with it when it breaks. **"How would you implement custom discount logic?"** Shopify Functions. If they suggest cart manipulation, that behaviour will be bypassed by accelerated checkouts. **"What do you leave behind on uninstall or handover?"** Ideally nothing you did not ask for. Theme debris is the most common complaint merchants have about inherited work. **"How do you test?"** Not necessarily an elaborate answer, but there should be one, particularly for anything touching money. **"What documentation do we get?"** The answer determines whether the next developer can pick it up or has to reverse-engineer it. ## Ask what they would tell you not to build The single most useful question in the whole conversation. An agency with no answer is selling scope. One that says "you do not need headless", "a theme can do that", or "this app already exists and costs less than we would" is exercising judgement, and judgement is the thing you are actually buying. The same applies to the brief you arrive with. If you ask for a custom build and the honest answer is that a configured theme would serve you better, you want to hear that before the estimate rather than after the invoice. An agency that agrees with everything you propose is either unusually lucky in its clients or is not thinking hard about the brief in front of it. ## Settle ownership and handover first The commercial questions that determine whether you end up with an asset or a dependency. ## Agree before work starts - Who owns the code, and what happens to reusable components - What documentation is delivered, and in what form - Who maintains it after launch, and at what cost - What happens to access and repositories if the relationship ends - How API deprecations are handled, and who pays for upgrades - Whether your team can make routine changes without the agency The last item is the one merchants forget. A build that requires the agency for every small change is a build that has converted a one-off cost into a permanent one. Ask explicitly what your team will be able to do unaided. These are easy conversations at the start and awkward ones at the end. Having them early costs an hour and prevents the most common form of agency regret. ## Agency, freelancer or in-house There is no universally right answer, and the trade-offs are reasonably clear. **A freelancer** is frequently better value for a defined, contained piece of work, and you get direct access to the person doing it. The risk is availability later — the developer who built your integration may not be reachable when it needs upgrading. **An agency** makes sense where continuity matters, where several disciplines are involved, or where the work is ongoing. You are partly paying for the fact that someone will still be there. The risk is paying for overhead the project does not need. **In-house** suits stores with continuous development needs and enough work to justify the hire. Below that threshold it is expensive capacity sitting idle. A common and sensible arrangement is an agency or freelancer for defined projects, with enough internal capability to handle routine changes and to evaluate what is being delivered. ## Scoping the first engagement well How you structure the first piece of work matters as much as who you pick, because it determines how much you learn before committing further. **Start with something contained.** A defined project with a clear end — an audit, one integration, one template — tells you how an agency works at a fraction of the risk of a large build. You learn their communication, their estimating accuracy and their code quality on something you can walk away from. **Watch how they handle the first surprise.** Every project meets something unexpected. The response to that is far more informative than the proposal: do they raise it early with options, or do they absorb it silently and mention it when the deadline slips? **Check the estimate against the outcome.** Not to punish an overrun — estimates are estimates — but because how an agency communicates about one tells you what a larger project will be like. **Ask to see the code**, even if you cannot fully evaluate it. Have someone who can look at it, or at minimum check that it exists in a repository you have access to, is documented, and is not one enormous undifferentiated file. **Notice who you actually talk to.** If the person in the sales conversation disappears after signing, that is the pattern for the whole relationship. The point of a small first engagement is that its real deliverable is information about the agency. A merchant who commits a large budget to an unknown team on the strength of a portfolio is buying on the least reliable evidence available. ## Briefing them properly The buyer controls more of the outcome than most merchants realise, and a poor brief produces a poor result from a good agency. **Describe the problem, not the solution.** "Our mobile product pages lose people before the buy box" gives an agency something to solve. "Build us a custom theme" gives them an instruction that may be the wrong one. **Say what must not change.** URLs, the integrations you depend on, the things your team can currently edit themselves. Agencies cannot protect what they do not know matters. **Name a decision-maker.** Development projects stall on unresolved opinion more often than on technical difficulty. **Be honest about your capacity.** If nobody internally can maintain what is built, that should shape what gets built. ## Warning signs Patterns that correlate with disappointment. **No questions about your business.** An agency that produces a quote without first understanding what you sell is quoting from a template rather than from your situation. **Estimates with no maintenance component.** Anything custom needs maintaining, and an estimate that ignores it is describing half the cost. **Reluctance to discuss handover.** If ownership and documentation are awkward topics at the start, they will be worse later. **Recommending the most expensive option by default.** Headless when a theme would do, custom when an app exists. **No examples of older work still running.** Either they have not been doing this long, or the older work is not something they particularly want to discuss — and both are worth knowing before you commit. **Unwillingness to talk to your existing developer.** If you have one, an agency that treats them as a threat rather than a source of context is prioritising the relationship over the outcome. > **Be specific about what "done" means** > > Development disputes are almost always about scope rather than quality. Agree what is included, what constitutes complete, and what happens to changes requested mid-build. Write it down. This protects both sides and it is the single most effective thing a buyer can do to avoid an unhappy project. For the technical decisions this often involves, see [Shopify development](/category/shopify-development). The theme-versus-custom question is covered in [storefront and design](/category/storefront-design). **Want an honest answer about what you actually need?** ByteInfy builds Shopify apps, storefronts and integrations — and will tell you when a theme, an existing app, or doing nothing is the better call. [Start a project](https://byteinfy.com/#contact) ## FAQ ### What should I look for in a Shopify development agency? Evidence that what they build survives. Ask about work from two years ago, how they handle API deprecations, whether storefront features use theme app extensions, and what documentation you receive. ### How much does Shopify development cost? It varies widely by scope, and the figure that matters more is the ongoing cost. Shopify ships continuously and retires API versions on a schedule, so anything custom needs maintaining. ### Should I hire an agency or a freelancer for Shopify work? A freelancer is often better value for a defined, contained piece of work. An agency makes more sense where continuity matters, where several disciplines are involved, or where the work is ongoing. ### What questions reveal whether an agency is any good? Ask what they would advise you not to build, how they handle deprecations, what happens to your code if the relationship ends, and to see something they built two years ago that is still running. ### Who owns the code an agency writes for me? Whatever you agree, which means it needs agreeing in writing before the work starts. Clients frequently assume they own bespoke work outright; agencies often expect to retain reusable components.