Headless CMS

Ett traditionellt CMS är populärt av goda skäl, men det sätter också gränser. Design och funktionalitet sitter ihop, och den kopplingen blir en flaskhals så snart innehållet ska ut på fler ytor än webbplatsen. Det är där ett headless CMS kommer in i bilden. Den intressanta frågan är inte hur modern arkitekturen är, utan vad den gör för er synlighet.

Vad ett headless CMS är

Ett headless CMS är ett innehållshanteringssystem som separerar backend från frontend. Backend fungerar som ett API som kan skicka innehållet till flera olika frontend-applikationer: webbplatsen, men också appar, nyhetsbrev och andra tjänster.

Ett headless CMS är i sig inte särskilt användbart om ni vill visa innehållet för en besökare. Till det behövs en frontend byggd med en site generator som hämtar data från CMS:et och renderar det i webbläsaren. Det är också i frontend-lagret det visuella uttrycket skapas, inte i CMS:et, vars enda uppgift här är att lagra innehållet. Populära site generators är NextJS, Nuxt och Astro.

Arkitekturen kallas ofta JAMSTACK, efter Javascript, API och Markup: en frontend som via ett API hämtar sitt innehåll.

Skillnaden mot ett traditionellt CMS

I ett traditionellt CMS är backend och frontend integrerade och fungerar som en enhet. Designen och funktionaliteten är bundna till varandra, vilket begränsar hur ni kan anpassa er till olika enheter och plattformar.

Med ett headless CMS blir backend en central plats för innehållet, som kan skickas vidare via API till flera frontends utan att någon rör backend. Det ger tre praktiska fördelar:

• Skalbarhet. Frontend kan optimeras för specifika enheter och plattformar, vilket ger bättre prestanda vid stora mängder data och trafik.
• Flexibilitet. Ni kan byta eller lägga till frontend-teknologi utan att flytta innehållet, och integrera de utvecklingsverktyg som passar.
• Bättre upplevelse, även internt. Redaktörer, marknadsförare och utvecklare arbetar i samma innehållsmodell men med olika verktyg, och vägen från idé till publicerad sida blir kortare.

Till det kommer driften. Ett headless CMS hostas normalt i molnet och prissätts efter API-användning, till skillnad från ett traditionellt CMS som WordPress där ni själva hostar och underhåller.

Vilket CMS är bäst för SEO?

Det viktigaste att förstå ur ett SEO-perspektiv är att valet av headless CMS spelar mindre roll än valet av frontend-teknik. Google kan inte se vilket headless CMS som ligger bakom en sida. Den läser bara vad som finns på sidan och hur det är uppsatt i frontend.

Vanliga headless CMS:er som fungerar bra för SEO-vänliga sidor är Storyblok, Sanity, Contentful, Strapi och Prismic. Skillnaden dem emellan handlar om redaktörsupplevelse och innehållsmodellering, inte om synlighet.

Vi delar normalt SEO i tre delar: content, teknisk SEO och länkbyggnad. Grovt sagt tar ett headless CMS hand om contentet, medan site generatorn tar hand om den tekniska delen. Det är därför frontend-valet är det som avgör.

Och här ligger den viktigaste uppdateringen sedan headless slog igenom. Det som avgör är renderingsstrategin, inte om ni valt React eller Vue. En sida som renderas helt i besökarens webbläsare kräver att roboten kör Javascript för att se något innehåll alls. Googlebot gör det, men med fördröjning. Flera AI-crawlers gör det inte över huvud taget, och hämtar bara den HTML som servern levererar. Är den tom är ni osynliga i AI-svaren oavsett hur bra innehållet är.

Slutsatsen är enkel: rendera på servern. Server-side rendering eller statisk generering ger både roboten och besökaren färdig HTML från första svaret. Hela avvägningen mellan renderingsmetoderna går vi igenom i JavaScript-SEO och rendering.

Headless och Core Web Vitals

En snabb sida är en förutsättning för både ranking och konvertering. Med ett headless CMS och en site generator i rätt uppsättning kan ni nå bra resultat i Core Web Vitals relativt enkelt, eftersom ni kontrollerar exakt vad som skickas till webbläsaren. LCP gynnas av statiskt genererade sidor och bilder som levereras i rätt format, och INP gynnas av att ni bara skickar den Javascript som faktiskt används.

Samma arkitektur gör det lättare att bygga mer interaktivt innehåll, vilket ökar tiden på sidan och engagemanget. Fördelen är verklig, men den är inte automatisk. En dåligt byggd headless-frontend kan vara långsammare än en välbyggd WordPress-sida, och vi ser båda varianterna.

Står ni inför en migrering?

Ett byte till headless är en site migration, och det är där risken ligger. URL-strukturen, redirects, metadata, strukturerad data och intern länkning ska följa med, och tappar ni något av det tappar ni synlighet som tog år att bygga. Vi går in i sådana projekt tidigt, innan den nya frontenden är byggd, eftersom det är billigare att lösa i planeringen än i efterhand. Det arbetet ligger i webbutveckling och site migration.

Och funderar ni på om er nuvarande uppsättning håller, tekniskt och innehållsmässigt, får ni svaret i en gratis SEO-analys innan ni fattar beslutet.