Vad headless Shopify faktiskt är
En standard Shopify-butik renderar sidor via Liquid-teman. Temat är tätt kopplat till Shopifys backend och hanterar layout, content och handel i ett system. En headless Shopify-butik behåller Shopify som commerce-backend (produkter, lager, checkout, ordrar, kundkonton) men ersätter Liquid-temat med en egen frontend, typiskt byggd på ett ramverk som Next.js, Remix, Astro, Nuxt eller Shopifys eget Hydrogen.
Frontenden läser från Shopify via Storefront API (GraphQL) och renderar sidor hur teamet bestämmer. Checkouten stannar på Shopifys hostade checkout, vilket är skälet att headless Shopify fungerar bra för de flesta handlare och också skälet att det har verkliga gränser.
När headless är rätt svar
De flesta Shopify-butiker behöver inte gå headless. Liquid-teman är snabba, välsupporterade och hanterar merparten av användningsfallen. Fallen där headless är värt merkostnaden:
Content och handel behöver samspela. Redaktionella sidor, produktberättelser, brand journalism, konfiguratorer, långformat-guider, allt renderat konsekvent med produktsidor. Shopifys CMS är lättare än ett dedikerat headless-CMS som Storyblok. För content-tunga varumärken är headless med Shopify plus Storyblok en starkare slutpunkt än Shopify ensamt.
Frontend-prestanda är en direkt affärsdrivare. Mid-market och enterprise-handlare med stora kataloger, hög trafik och stramt satta Core Web Vitals-mål upplever ibland Liquids prestandatak som begränsande. En headless-frontend på ett modernt ramverk kan leverera bättre INP och LCP, även om gapet minskat när Liquid utvecklats.
Egen UX bortom vad teman stödjer. Produktkonfiguratorer, multi-step offertbyggare, inbäddade verktyg, livedata från andra system. Möjligt i Liquid med arbete, men mer naturligt i en React- eller Vue-frontend.
Multi-brand eller multi-site från en backend. Flera storefronts som delar samma Shopify-katalog, var och en med sitt eget varumärke, design och content. Möjligt med Liquid men renare när frontenden är frikopplad.
När headless inte är rätt svar
Att gå headless av fel anledningar är ett av de snabbaste sätten att spränga en Shopify-budget. Fallen där det normalt inte är värt det:
En enkel D2C-butik med standardproduktsidor, inget redaktionellt lager och inget prestandatak som nåtts. Liquid-teman hanterar det snabbare, billigare och med mindre underhåll.
Team utan frontend-kapacitet. Headless betyder löpande ägandeskap av en separat kodbas. Utan interna resurser och utan byråretainer för underhåll blir frontenden en skuld.
Handlare som valde Shopify för app-ekosystemet. Många Shopify-appar antar ett Liquid-tema och hakar på det. På en headless-frontend behöver de antingen ersättas med API-ekvivalenter eller byggas om. Det här är ofta den dolda kostnaden som överraskar team mitt i projektet.
Hydrogen, React och ramverksvalet
Hydrogen är Shopifys eget React-baserade ramverk för headless-storefronts. Det är djupt integrerat med Shopifys Storefront API och levereras hostat på Shopifys Oxygen-plattform. För team som är köpta på Shopify långsiktigt och nöjda med React är Hydrogen vägen med minst motstånd.
Alternativen är framework-first: Next.js, Remix, Astro eller Nuxt, med Shopify åtkomligt via Storefront API:t direkt. Den vägen ger mer flexibilitet i hosting, deployment och tooling, till kostnaden av att bygga mer av commerce-integrationen själva. För content-tunga sajter som parar Shopify med Storyblok eller liknande är Next.js med Vercel eller liknande edge-plattform vanligt.
Ramverksvalet handlar mindre om prestanda (alla är snabba nog) och mer om teamkompetens, hosting-strategi och långsiktigt underhåll. Ett ramverk teamet redan använder i andra produkter vinner normalt över ett de måste lära sig.
Storyblok plus Shopify, content-first-mönstret
För varumärken där content och handel bär lika mycket vikt är parning av Storyblok som CMS med Shopify som commerce ett återkommande mönster. Storyblok hanterar sidor, komponenter och redaktionella arbetsflöden med en visuell editor som contentteam faktiskt använder. Shopify hanterar produkter, lager, ordrar och checkout. Frontenden läser båda och renderar enhetliga sidor.
Det här fungerar bra därför att Storybloks komponentbaserade modell mappar rent på hur varumärken tänker om sidbyggnad, och Shopifys commerce-funktioner mappar rent på hur handlare tänker om att sälja. Integrationspunkten är frontenden. Den drar produktdata från Shopify och content-data från Storyblok, och renderar resultatet.
Avvägningen är komplexitet. Två system att underhålla, två API:er att konsumera, två cachningslager att hantera. För content-tunga varumärken betalar det tillbaka. För produktkatalog-först D2C-butiker är det normalt överdrivet.
SEO på headless Shopify
Headless-SEO är där projekt misslyckas eller lyckas. Med ett Liquid-tema är SEO-defaults i stort sett hanterade, som meta-taggar, strukturerad data, canonical-URL:er och sitemap-generering. På en headless-frontend måste varje del implementeras explicit.
Serverrendering är inte förhandlingsbart. Sidor måste renderas serversidigt eller med statisk generering, inte klientsidigt. Google crawlar och renderar, men en ren client-side SPA förlorar fortfarande SEO-drabbningar. Next.js SSR/SSG, Hydrogen, Astro och Remix hanterar alla det här bra.
URL-struktur kräver explicit design. Shopifys URL-struktur (/products/handle, /collections/handle) är ofta inte vad ett headless-team vill ha. Egna URL:er är möjliga men måste mappa rent mot Shopifys resursidentifierare och bevara redirect-stigar från en ev. migrering.
Strukturerad data måste implementeras manuellt. Product schema, breadcrumb schema, article schema, FAQ schema. Varje typ som spelar roll behöver explicit JSON-LD-output från frontenden.
Sitemap-generering är teamets ansvar. Shopify genererar en sitemap för Liquid-teman, men en headless-frontend behöver sin egen. Normalt byggd från Shopifys katalog plus content från CMS:et.
Se vår Shopify-migreringsguide för mer om SEO-bevarande vid en flytt till headless.
Checkouten, den fasta punkten
Checkouten stannar på Shopify oavsett hur frontenden ser ut. Shopifys hostade checkout hanterar betalning, moms, frakt och orderskapande. Det är skälet att headless Shopify fungerar bra för de flesta marknader och också skälet att det har gränser.
Egen checkout-logik måste passa inom det som Shopify Plus tillåter via checkout extensibility. För B2B-checkout med faktura, PO-nummer och attestflöden stödjer B2B-checkouten de inbyggda fälten. För mer komplexa B2B-scenarier med offertattester och flernivå-flöden blir checkouten en begränsning.
För nordiska betalmetoder integrerar Klarna, Svea, Walley, Adyen och Mollie alla mot Shopify Plus checkout. För B2B hanterar Briqpay faktura och kreditprövning.
Hosting och deployment
Shopifys Oxygen är byggt för Hydrogen och är den enklaste vägen för team på Hydrogen. Bortom Oxygen är de vanliga alternativen Vercel, Cloudflare Pages, AWS eller en managed Node-host. Valet är ramverksberoende. Next.js kör bra på Vercel eller self-hostat, Astro på Cloudflare, Nuxt på flera alternativ.
Edge-rendering är där moderna frontends har en riktig hastighetsfördel. Cachad produktdata serverad från edge-platser nära användaren, plus on-demand commerce-data från Shopify, levererar den hybridupplevelse som de flesta headless-byggen siktar på.
Vad ett headless Shopify-projekt kostar
Ett enklare headless Shopify-bygge med en frontend och standardintegrationer hamnar normalt på 600 000 till 1 200 000 kr. Ett bygge med Storyblok-integration, egen UX, multi-market-stöd eller B2B-lager hamnar i regel på 1 000 000 till 2 500 000 kr. Shopify Plus-licensen ligger ovanpå. Löpande underhåll, typiskt frontend-utvecklartid plus infrastruktur, ligger på 20 000 till 60 000 kr per månad beroende på scope.
Jämfört med ett standard Liquid-temabygge (200 000 till 500 000 kr) är headless alltid en premium. Frågan är om de specifika skälen rättfärdigar det. Kontakta oss för en scoping-diskussion om ni väger avvägningen.