[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-site-config":3,"$f5HUAfsgwEl2p7sEx0uOexi_II-Htr1Y0fJ3TIICdiic":6,"mdc-zgjjdx-key":122},{"gaMeasurementId":4,"bookingUrl":5},"G-7BYTDCVDDR","https:\u002F\u002Ftidycal.com\u002Fcmdcntr\u002F30-minute-meeting",{"post":7,"related":77},{"id":8,"slug":9,"title":10,"description":11,"summary":12,"content":13,"coverImageUrl":14,"coverImageAlt":15,"tags":16,"targetKeywords":23,"faq":28,"howTo":44,"demo":44,"featured":45,"tool":44,"status":46,"reviewNote":44,"metaTitle":47,"metaDescription":48,"canonicalUrl":49,"sourceTicketId":44,"agentGenerated":45,"publishedAt":50,"publishedBy":44,"createdAt":51,"updatedAt":51,"authorId":52,"clusterId":53,"ctaId":54,"author":55,"cluster":66,"cta":70,"tools":76},"a5765020-18cd-4000-b24f-4df388d7eb03","headless-cms-vs-traditional-cms","Headless CMS vs Traditional CMS: How to Actually Choose","A decision framework for headless CMS vs traditional CMS: the honest tradeoffs, a situation-keyed decision table, and the real Sanity vs Storyblok vs Strapi call we made on a production Nuxt build.","Neither headless nor traditional CMS wins in the abstract. Headless buys front-end control and performance but moves delivery onto your engineers; traditional and DXP carry more delivery for you but couple content to presentation. This guide gives a situation-keyed decision table, explains where modern Sitecore blurs the line, and shares the real evaluation behind why we chose Storyblok on a production Nuxt build.","The honest answer to headless CMS vs traditional CMS is that neither wins in the abstract. The right choice depends on facts about your own team that a feature comparison never asks about. A headless CMS manages content and hands it to your front end through an application programming interface (API), leaving the rendering to your engineers. A traditional CMS manages content and renders the pages itself. The enterprise version of that, a digital experience platform (DXP), bundles personalization, testing, and campaign tooling into one suite. Headless buys you front-end control and performance, and it moves the delivery work onto your engineers. Traditional carries more of that delivery for you and couples your content to its presentation. That is the whole trade. Everything below is about matching it to your situation instead of following whichever side is fashionable this year.\n\nWe build server-side-rendered (SSR), SEO-first front ends in Nuxt, both our own site and client work, and we deliver enterprise Sitecore on regulated and higher-education properties. So we sit on both sides of this line every week. This guide is the decision framework we actually use, including a real evaluation we ran on a production build and where each option falls down.\n\n## What is the difference between headless and traditional CMS?\n\nThe market splits on one axis: how tightly the CMS couples content management to content delivery.\n\n![Coupled vs decoupled architecture: a traditional CMS renders the page itself in one system, while a headless CMS hands rendering to a separate front end you build](\u002Fcovers\u002Fenterprise-cms\u002Fvisuals\u002Fvs-traditional-coupled-decoupled.png)\n\nA **traditional CMS** owns both ends. You author content in it, and it renders the HTML that visitors receive. WordPress is the familiar example of this tier, but the enterprise end of it is the DXP: Sitecore XM\u002FXP, Adobe Experience Manager (AEM), Optimizely. The content and the presentation live in the same system, and templates in that system decide how a given piece of content looks.\n\nA **headless CMS** owns only the content. It stores structured content and exposes it through an API (REST or GraphQL), and it has no opinion about how that content is displayed. Your front end (Next.js, Nuxt, or a native app, or three of them at once) fetches the content and renders it. Contentful, Storyblok, and Sanity are the enterprise-headless names you will hear most.\n\nThe word \"headless\" is literally that: the CMS has had its head (the presentation layer) removed. That seam between the two jobs is the source of every advantage headless has and every cost it imposes. For a fuller definition of the enterprise tier specifically, and how governance and multi-region needs raise the stakes, see [enterprise headless CMS explained](\u002Fblog\u002Fenterprise-cms\u002Fenterprise-headless-cms-explained).\n\n## What are the real tradeoffs of headless vs traditional CMS?\n\nHere is the part the vendor decks skip. Both models are good at different things, and each one hands you a bill.\n\n**Headless gives you:**\n\n- Front-end freedom. You render with whatever framework your team is strongest in, and you are not fighting a templating engine to hit a design.\n- Performance you control. A static or server-rendered Nuxt or Next front end can be fast in ways a monolithic CMS template rarely is, because you own the rendering path, the caching, and the bundle.\n- Multi-channel reuse. The same content API feeds a website, a mobile app, and a kiosk without duplicating content.\n- Clean content modeling. Content is structured data, not pages, which pays off when the same content appears in many places.\n\n**Headless costs you:**\n\n- The front end is now your problem. Every route, layout, preview environment, and deploy pipeline is something your team builds and maintains. Headless does not remove work. It relocates it onto engineering.\n- In-context editing is not free. Authors lose the \"edit the page you are looking at\" experience unless you wire up visual editing deliberately.\n- More moving parts. CMS, front-end app, hosting, and a build or rendering layer are separate systems that each need owning.\n\n**Traditional and DXP gives you:**\n\n- Delivery out of the box. Templates, rendering, preview, and page composition come with the platform. A smaller team can ship without building a front-end stack from scratch.\n- Author-friendly editing. What you see is what you get (WYSIWYG) editing, in-context preview, and page assembly are native, which non-technical authors like.\n- Deep built-in capability at the enterprise end. Sitecore and AEM bundle personalization and experimentation and analytics that would each be a separate integration in a headless stack.\n\n**Traditional and DXP costs you:**\n\n- Content coupled to presentation. Reusing content across channels is harder, and the front end is constrained by the platform's rendering model.\n- Performance ceilings. You are optimizing within the platform's rendering path, not replacing it.\n- License plus specialist cost. The enterprise DXPs are expensive to license and, more importantly, expensive to staff with people who can run them well.\n\nNotice that neither list is short and neither is free. Anyone who tells you headless is simply \"more modern\" is selling you the benefits column and hiding the costs one.\n\n## When should you use a headless CMS?\n\nHeadless earns its keep when specific conditions hold. Use a headless CMS when:\n\n- **You have strong engineers, in-house or through a partner.** This is the load-bearing condition. Headless is a good deal when you have a team that can build and maintain a front end, and a bad one when you do not. If nobody owns the front-end stack, headless just gave you a second system with no operator.\n- **Front-end performance or experience is a competitive edge.** If Core Web Vitals, SEO, and a bespoke UI matter to the business, owning the rendering path is worth the work. This is our home turf, and it is why our own site is a Nuxt front end on a headless source. On the SEO specifics, headless done wrong can tank organic traffic, so read the [headless CMS SEO complete guide](\u002Fblog\u002Fenterprise-cms\u002Fheadless-cms-seo-complete-guide) before you commit.\n- **You publish to more than a website.** A web app plus a native app plus a partner feed is the classic case where one content API beats maintaining the same content in three places.\n- **Your content is genuinely structured and reused.** Deeply modeled, reused-everywhere content favors headless, and Sanity in particular.\n\nDo **not** reach for headless when your site is a handful of marketing pages a small team edits in place, when nobody will own the front end after launch, or when your \"personalization\" is a geolocated banner. In those cases headless adds cost and moving parts for control you will not use. Being honest about this is the difference between advising and selling.\n\n## When should you stay traditional or go DXP?\n\nStay on the traditional or DXP side when the delivery weight is better carried by the platform than by your team.\n\n- **You need deep, data-driven personalization across the journey.** Real rules-and-data personalization, not a banner, is exactly where Sitecore and AEM earn their license cost. Rebuilding that on a headless stack is a large project in its own right.\n- **Your integration surface and governance needs are heavy.** Large author teams with real roles, workflow, and compliance, plus tight coupling to a marketing suite, are what these platforms are built for.\n- **You are in a regulated or higher-education context.** We deliver Sitecore on pharma and higher-education properties, and the reason those clients stay on a DXP is the governance, workflow, and accessibility scaffolding the platform provides, not the raw rendering.\n- **Your team is small and needs the platform to carry delivery.** If you cannot staff a front-end practice, a platform that ships templates and page composition out of the box is the pragmatic call.\n\nThe trap on this side is overbuying: paying for a DXP's personalization and integration depth to run a brochure site. If you are not using the expensive capabilities, a cheaper platform your existing team can operate will cost you less in total.\n\n## Where does modern Sitecore blur the line?\n\nThis is the nuance most comparisons miss, and it matters if Sitecore is on your shortlist. The traditional-versus-headless line now runs *through* Sitecore, not around it.\n\nClassic Sitecore (XP with server-side rendering) is the traditional model: the CMS renders the pages. But modern Sitecore (XM Cloud, headless with JavaScript Services, or JSS) is API-first and composable, so you can run Sitecore as a headless source feeding a Next.js or Nuxt front end while keeping Sitecore's content tree, personalization, and governance. The same is increasingly true across the DXP tier, where \"composable\" is the vendors' word for bolting a headless delivery model onto a platform that used to render everything itself.\n\nThe practical takeaway: \"headless vs traditional CMS\" is not always a choice between two products. On Sitecore it can be a choice about how you run one product. If you already own Sitecore, you may not need to migrate to get headless benefits. You may need to move to its headless delivery model, which is a smaller and safer project. That is work we do on [Sitecore](\u002Fservices\u002Fsitecore) specifically.\n\n## How do you actually choose? A decision table\n\nIgnore the feature matrices and answer these questions about your own situation. Each row points you toward the tier that fits, not the one that markets best.\n\n![A decision quadrant placing headless CMS, composable DXP, traditional CMS, and headless-without-a-team by front-end team strength and how much delivery the platform carries](\u002Fcovers\u002Fenterprise-cms\u002Fvisuals\u002Fvs-traditional-quadrant.png)\n\n| Your situation | Leans headless | Leans traditional \u002F DXP |\n|---|---|---|\n| **Who builds the front end?** | Strong in-house or partner engineers who want control | You want the platform to own delivery |\n| **How much personalization do you need?** | Little, or you will build it yourself | Deep, rules-and-data-driven across the journey |\n| **How structured is your content?** | Highly structured, reused across channels | Page-shaped, edited largely in context |\n| **How many channels?** | Website plus app(s) plus feeds | One website, maybe a second brand site |\n| **How heavy is your integration surface?** | API-first fits a composable stack | Tight coupling to one marketing suite (e.g. Adobe) |\n| **What is your author profile?** | Comfortable with structured editing and preview | Non-technical, wants WYSIWYG in-context editing |\n| **What is your team's capacity to maintain a front end?** | Real capacity, now and after launch | Limited; needs the platform to carry it |\n| **What is the total cost you can absorb?** | License is low; you invest in engineering | You can fund license plus specialists to run it |\n\nThe last row is the one people get wrong most often, so it is worth stating plainly.\n\n## Total cost of ownership is not the license price\n\nThe license is the visible number, and it is rarely the number that decides the project. Total cost of ownership is the license plus the team required to run the platform well plus the ongoing delivery and maintenance.\n\nA \"free\" or cheap headless CMS that needs a full front-end engineering practice to operate can easily cost more than an expensive DXP your existing team already knows. And an expensive DXP run without the discipline it demands forks into an unmaintainable mess that costs a rescue project to fix. We get called in for exactly that pattern more than any other: the platform was fine, the delivery was underfunded.\n\nThere is one more line item worth naming because it fits enterprise CMS work specifically: demand is lumpy. A big build, then quieter maintenance, then a migration or redesign that spikes again. Staffing full-time specialists for the peaks means paying them through the troughs. This is why our support hours never expire. The demand is uneven, so the support should be too, and you draw the hours down when the work actually arrives.\n\n## What we chose on a real build, and why\n\nEnough principle. Here is a concrete decision we made.\n\nOn a recent production Nuxt build for a client, we ran a genuine evaluation of three headless options before writing any content models: **Sanity, Storyblok, and Strapi**. All three are capable. Here is how the tradeoffs actually landed for that project.\n\n- **Sanity** is the developer favorite, and deservedly. Its content model is unusually flexible and its query language (GROQ) treats content as structured data rather than pages. If the priority had been precise, deeply structured content and the team was happy to build the editing experience around it, Sanity would have won.\n- **Strapi** is open-source and self-hostable, which is attractive when you want to own the whole stack and avoid per-seat SaaS pricing. The cost is that you own hosting and upgrades, and the editing experience is yours to build too. For this client that added operational weight they did not want to carry.\n- **Storyblok** won, and the deciding factor was editor experience without giving up the clean component model. Its visual editor gives non-technical authors a live preview of the actual page while keeping the structured, component-based content model that headless is supposed to buy you. Its integration into a modern JavaScript framework was the lightest we have worked with, which shortened the front-end build.\n\nThat decision was specific to that client: non-technical authors who needed in-context preview, a Nuxt front end, and no appetite to self-host. Change any of those and the answer changes. If your authors are technical and your content is deeply relational, Sanity is a reasonable different answer to the same question. The point of the evaluation was to match the tool to the team.\n\n## Does headless or traditional matter more than delivery?\n\nNo, and this is the honest closer. Whichever side of the line you land on, the practices that decide whether the site is an asset or a liability are the same. Build a component library as the single source of truth. Bake accessibility into the CMS layer rather than bolting it on before an audit. Put governance in place that stops the system forking over its multi-year life.\n\nWe apply the same delivery discipline building a Nuxt front end on Storyblok that we apply building components in Sitecore. The tooling differs. The failure modes do not. A well-run traditional build beats a badly-run headless one every time, and the reverse is just as true. Pick the tier that fits your team using the table above, then spend your real attention on delivery, because that is where these projects are actually won or lost.\n\nIf you are weighing headless CMS vs traditional CMS for a specific build, or trying to decide whether to move an existing Sitecore or WordPress site, that is the work we do. Have a look at our [headless CMS](\u002Fservices\u002Fheadless-cms) and [Sitecore](\u002Fservices\u002Fsitecore) practices, or [book a call](https:\u002F\u002Ftidycal.com\u002Fcmdcntr\u002F30-minute-meeting) and we will talk through your actual situation rather than a feature list.\n\n## Read next\n\n- [Enterprise headless CMS explained](\u002Fblog\u002Fenterprise-cms\u002Fenterprise-headless-cms-explained): what the enterprise tier adds over a basic headless CMS, and when you actually need it.\n- [The complete guide to headless CMS SEO](\u002Fblog\u002Fenterprise-cms\u002Fheadless-cms-seo-complete-guide): how to keep organic traffic when you own the rendering path, the part headless most often breaks.\n- [Enterprise CMS in 2026: how to choose the platform and the partner](\u002Fblog\u002Fenterprise-cms\u002Fenterprise-cms-2026-platform-and-partner): the pillar guide to both decisions, platform and delivery.\n- Work with us: our [headless CMS agency](\u002Fservices\u002Fheadless-cms) practice, or [Sitecore development and support](\u002Fservices\u002Fsitecore).","https:\u002F\u002Fcmdcntr.io\u002Fcovers\u002Fenterprise-cms\u002Fheadless-vs-traditional.png","A polished chrome CMS block splitting into two halves, one rendering its own page and one streaming content through a glowing electric-violet API channel to a separate front end",[17,18,19,20,21,22],"headless cms","traditional cms","dxp","sitecore","storyblok","cms selection",[24,25,26,27],"headless cms vs traditional cms","difference between headless and traditional cms","headless vs traditional cms","when to use headless cms",[29,32,35,38,41],{"answer":30,"question":31},"A traditional CMS manages content and renders the pages itself, so content and presentation live in one system. A headless CMS manages only content and exposes it through an API, leaving rendering to a front end your team builds. Headless gives front-end control; traditional carries more delivery for you.","What is the difference between a headless CMS and a traditional CMS?",{"answer":33,"question":34},"Use headless when you have strong engineers to own the front end, when performance or a bespoke UI is a competitive edge, when you publish to more than a website, or when your content is deeply structured and reused. Avoid it when nobody will own the front-end stack after launch.","When should you use a headless CMS?",{"answer":36,"question":37},"Neither is better in the abstract. Headless separates content from presentation and gives engineers full front-end control, which pays off with a strong team. Traditional and digital experience platform (DXP) tools carry more delivery and offer deep built-in personalization, which pays off when integration depth matters more than front-end control.","Is a headless CMS better than a traditional CMS?",{"answer":39,"question":40},"The line runs through Sitecore, not around it. Classic Sitecore renders pages traditionally, but modern Sitecore (XM Cloud with JavaScript Services) runs API-first and headless while keeping its content tree and personalization. If you already own Sitecore, you may move to its headless delivery model rather than migrating platforms.","Does headless vs traditional apply to Sitecore?",{"answer":42,"question":43},"License price rarely decides it. Total cost of ownership is license plus the team to run the platform plus ongoing delivery. A cheap headless CMS that needs a full front-end practice can cost more than an expensive DXP your existing team already knows how to operate.","What costs more, headless or traditional CMS?",null,false,"published","Headless CMS vs Traditional CMS: How to Choose","Headless CMS vs traditional CMS, decided honestly: the tradeoffs, a decision table, when to use headless, and the Storyblok call we made on a Nuxt build.","https:\u002F\u002Fcmdcntr.io\u002Fblog\u002Fenterprise-cms\u002Fheadless-cms-vs-traditional-cms","2026-07-10T14:00:00.000Z","2026-07-14T23:50:41.249Z","ed80da88-f3d1-4aa9-9373-18c39fecb740","23d49753-baf2-4629-b6fc-df27c558f48d","c0fcf6a1-58d2-4262-8996-3ad29d58eea5",{"slug":56,"name":57,"avatarUrl":58,"role":59,"bio":60,"isPublic":61,"expertiseSummary":62,"linkedin":63,"github":64,"twitter":44,"website":65},"michael-graham","Michael Graham","\u002Fapi\u002Fpublic\u002Favatar\u002F7452d3cc-b0aa-46e4-96e6-da9c0225c471","Founder & Software Engineer","Obsessed with building top-tier web software and crafting unique, polished user experiences.",true,"From frontend design to a fully deployed application, I can build the entire pipeline.","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fmikemartire\u002F","https:\u002F\u002Fgithub.com\u002Fmichaelchristophergraham","https:\u002F\u002Fcmdcntr.io",{"slug":67,"name":68,"color":69},"enterprise-cms","Enterprise CMS Delivery","#0EA5E9",{"id":54,"name":71,"ctaType":72,"heading":73,"description":74,"buttonText":75,"url":5,"leadMagnetUrl":44},"Book a Call (blog)","book_call","Shipping AI-generated code that keeps breaking?","Book a free 30-minute call with a senior engineer. We diagnose what is going wrong and give you a concrete fix plan, no obligation.","Book a free call",[],[78,94,107],{"id":79,"slug":80,"title":81,"description":82,"coverImageUrl":83,"coverImageAlt":84,"tags":85,"featured":45,"tool":44,"publishedAt":91,"author":92,"cluster":93},"bf3284f2-bdb2-4d08-b24b-870960743091","headless-cms-seo-complete-guide","Headless CMS SEO: The Complete Guide","The SEO concerns that genuinely change in a headless architecture, and the server-rendered Nuxt patterns we use to get metadata, canonicals, redirects, structured data, sitemaps, and Core Web Vitals right.","https:\u002F\u002Fcmdcntr.io\u002Fcovers\u002Fenterprise-cms\u002Fheadless-seo.png","Chrome and electric-violet diagram of a headless CMS feeding content through an API into a server-rendered front end, with SEO tags and structured data in the HTML response.",[17,86,87,88,89,90],"seo","nuxt","core web vitals","structured data","ssr","2026-07-14T14:00:00.000Z",{"slug":56,"name":57,"avatarUrl":58,"role":59,"bio":60,"isPublic":61},{"slug":67,"name":68,"color":69},{"id":95,"slug":96,"title":97,"description":98,"coverImageUrl":99,"coverImageAlt":100,"tags":101,"featured":45,"tool":44,"publishedAt":104,"author":105,"cluster":106},"69f3e275-8bdb-40dc-ac93-b0e87af05d2f","headless-cms-localization","Headless CMS Localization: Patterns That Scale","How localization actually works in a headless CMS: field-level vs entry-level vs space-level translation, locale URL structure and hreflang, fallbacks, RTL, and keeping Nuxt i18n in sync with the CMS, with first-hand Storyblok and Sitecore notes.","https:\u002F\u002Fcmdcntr.io\u002Fcovers\u002Fenterprise-cms\u002Fheadless-localization.png","A polished chrome globe wrapped in glowing purple circuitry branching into multiple language routes",[17,102,103,21,20,87],"localization","i18n","2026-07-12T14:00:00.000Z",{"slug":56,"name":57,"avatarUrl":58,"role":59,"bio":60,"isPublic":61},{"slug":67,"name":68,"color":69},{"id":108,"slug":109,"title":110,"description":111,"coverImageUrl":112,"coverImageAlt":113,"tags":114,"featured":45,"tool":44,"publishedAt":119,"author":120,"cluster":121},"eb994797-29e0-4ad6-8aaf-01f353cd8410","headless-cms-security","Headless CMS Security: The Real Attack Surface","A headless CMS is secure when you treat it as one, but decoupling moves the attack surface to the seams: API tokens, preview endpoints, webhooks, edge caching, rich-text XSS, RBAC, and front-end secrets. Here is the real surface and a hardening checklist.","https:\u002F\u002Fcmdcntr.io\u002Fcovers\u002Fenterprise-cms\u002Fheadless-security.png","A polished chrome content block splitting apart with glowing electric-violet API connections and a lock symbol at each exposed seam",[17,115,116,117,118],"cms security","api security","web security","enterprise cms","2026-07-11T14:00:00.000Z",{"slug":56,"name":57,"avatarUrl":58,"role":59,"bio":60,"isPublic":61},{"slug":67,"name":68,"color":69},{"data":123,"body":124},{},{"type":125,"children":126},"root",[127,135,140,147,152,161,174,185,199,205,210,218,243,251,269,277,295,303,321,326,331,336,387,399,405,410,453,458,464,477,482,495,501,506,514,715,720,726,731,736,741,747,752,764,797,802,808,813,818,845,851],{"type":128,"tag":129,"props":130,"children":131},"element","p",{},[132],{"type":133,"value":134},"text","The honest answer to headless CMS vs traditional CMS is that neither wins in the abstract. The right choice depends on facts about your own team that a feature comparison never asks about. A headless CMS manages content and hands it to your front end through an application programming interface (API), leaving the rendering to your engineers. A traditional CMS manages content and renders the pages itself. The enterprise version of that, a digital experience platform (DXP), bundles personalization, testing, and campaign tooling into one suite. Headless buys you front-end control and performance, and it moves the delivery work onto your engineers. Traditional carries more of that delivery for you and couples your content to its presentation. That is the whole trade. Everything below is about matching it to your situation instead of following whichever side is fashionable this year.",{"type":128,"tag":129,"props":136,"children":137},{},[138],{"type":133,"value":139},"We build server-side-rendered (SSR), SEO-first front ends in Nuxt, both our own site and client work, and we deliver enterprise Sitecore on regulated and higher-education properties. So we sit on both sides of this line every week. This guide is the decision framework we actually use, including a real evaluation we ran on a production build and where each option falls down.",{"type":128,"tag":141,"props":142,"children":144},"h2",{"id":143},"what-is-the-difference-between-headless-and-traditional-cms",[145],{"type":133,"value":146},"What is the difference between headless and traditional CMS?",{"type":128,"tag":129,"props":148,"children":149},{},[150],{"type":133,"value":151},"The market splits on one axis: how tightly the CMS couples content management to content delivery.",{"type":128,"tag":129,"props":153,"children":154},{},[155],{"type":128,"tag":156,"props":157,"children":160},"img",{"alt":158,"src":159},"Coupled vs decoupled architecture: a traditional CMS renders the page itself in one system, while a headless CMS hands rendering to a separate front end you build","\u002Fcovers\u002Fenterprise-cms\u002Fvisuals\u002Fvs-traditional-coupled-decoupled.png",[],{"type":128,"tag":129,"props":162,"children":163},{},[164,166,172],{"type":133,"value":165},"A ",{"type":128,"tag":167,"props":168,"children":169},"strong",{},[170],{"type":133,"value":171},"traditional CMS",{"type":133,"value":173}," owns both ends. You author content in it, and it renders the HTML that visitors receive. WordPress is the familiar example of this tier, but the enterprise end of it is the DXP: Sitecore XM\u002FXP, Adobe Experience Manager (AEM), Optimizely. The content and the presentation live in the same system, and templates in that system decide how a given piece of content looks.",{"type":128,"tag":129,"props":175,"children":176},{},[177,178,183],{"type":133,"value":165},{"type":128,"tag":167,"props":179,"children":180},{},[181],{"type":133,"value":182},"headless CMS",{"type":133,"value":184}," owns only the content. It stores structured content and exposes it through an API (REST or GraphQL), and it has no opinion about how that content is displayed. Your front end (Next.js, Nuxt, or a native app, or three of them at once) fetches the content and renders it. Contentful, Storyblok, and Sanity are the enterprise-headless names you will hear most.",{"type":128,"tag":129,"props":186,"children":187},{},[188,190,197],{"type":133,"value":189},"The word \"headless\" is literally that: the CMS has had its head (the presentation layer) removed. That seam between the two jobs is the source of every advantage headless has and every cost it imposes. For a fuller definition of the enterprise tier specifically, and how governance and multi-region needs raise the stakes, see ",{"type":128,"tag":191,"props":192,"children":194},"a",{"href":193},"\u002Fblog\u002Fenterprise-cms\u002Fenterprise-headless-cms-explained",[195],{"type":133,"value":196},"enterprise headless CMS explained",{"type":133,"value":198},".",{"type":128,"tag":141,"props":200,"children":202},{"id":201},"what-are-the-real-tradeoffs-of-headless-vs-traditional-cms",[203],{"type":133,"value":204},"What are the real tradeoffs of headless vs traditional CMS?",{"type":128,"tag":129,"props":206,"children":207},{},[208],{"type":133,"value":209},"Here is the part the vendor decks skip. Both models are good at different things, and each one hands you a bill.",{"type":128,"tag":129,"props":211,"children":212},{},[213],{"type":128,"tag":167,"props":214,"children":215},{},[216],{"type":133,"value":217},"Headless gives you:",{"type":128,"tag":219,"props":220,"children":221},"ul",{},[222,228,233,238],{"type":128,"tag":223,"props":224,"children":225},"li",{},[226],{"type":133,"value":227},"Front-end freedom. You render with whatever framework your team is strongest in, and you are not fighting a templating engine to hit a design.",{"type":128,"tag":223,"props":229,"children":230},{},[231],{"type":133,"value":232},"Performance you control. A static or server-rendered Nuxt or Next front end can be fast in ways a monolithic CMS template rarely is, because you own the rendering path, the caching, and the bundle.",{"type":128,"tag":223,"props":234,"children":235},{},[236],{"type":133,"value":237},"Multi-channel reuse. The same content API feeds a website, a mobile app, and a kiosk without duplicating content.",{"type":128,"tag":223,"props":239,"children":240},{},[241],{"type":133,"value":242},"Clean content modeling. Content is structured data, not pages, which pays off when the same content appears in many places.",{"type":128,"tag":129,"props":244,"children":245},{},[246],{"type":128,"tag":167,"props":247,"children":248},{},[249],{"type":133,"value":250},"Headless costs you:",{"type":128,"tag":219,"props":252,"children":253},{},[254,259,264],{"type":128,"tag":223,"props":255,"children":256},{},[257],{"type":133,"value":258},"The front end is now your problem. Every route, layout, preview environment, and deploy pipeline is something your team builds and maintains. Headless does not remove work. It relocates it onto engineering.",{"type":128,"tag":223,"props":260,"children":261},{},[262],{"type":133,"value":263},"In-context editing is not free. Authors lose the \"edit the page you are looking at\" experience unless you wire up visual editing deliberately.",{"type":128,"tag":223,"props":265,"children":266},{},[267],{"type":133,"value":268},"More moving parts. CMS, front-end app, hosting, and a build or rendering layer are separate systems that each need owning.",{"type":128,"tag":129,"props":270,"children":271},{},[272],{"type":128,"tag":167,"props":273,"children":274},{},[275],{"type":133,"value":276},"Traditional and DXP gives you:",{"type":128,"tag":219,"props":278,"children":279},{},[280,285,290],{"type":128,"tag":223,"props":281,"children":282},{},[283],{"type":133,"value":284},"Delivery out of the box. Templates, rendering, preview, and page composition come with the platform. A smaller team can ship without building a front-end stack from scratch.",{"type":128,"tag":223,"props":286,"children":287},{},[288],{"type":133,"value":289},"Author-friendly editing. What you see is what you get (WYSIWYG) editing, in-context preview, and page assembly are native, which non-technical authors like.",{"type":128,"tag":223,"props":291,"children":292},{},[293],{"type":133,"value":294},"Deep built-in capability at the enterprise end. Sitecore and AEM bundle personalization and experimentation and analytics that would each be a separate integration in a headless stack.",{"type":128,"tag":129,"props":296,"children":297},{},[298],{"type":128,"tag":167,"props":299,"children":300},{},[301],{"type":133,"value":302},"Traditional and DXP costs you:",{"type":128,"tag":219,"props":304,"children":305},{},[306,311,316],{"type":128,"tag":223,"props":307,"children":308},{},[309],{"type":133,"value":310},"Content coupled to presentation. Reusing content across channels is harder, and the front end is constrained by the platform's rendering model.",{"type":128,"tag":223,"props":312,"children":313},{},[314],{"type":133,"value":315},"Performance ceilings. You are optimizing within the platform's rendering path, not replacing it.",{"type":128,"tag":223,"props":317,"children":318},{},[319],{"type":133,"value":320},"License plus specialist cost. The enterprise DXPs are expensive to license and, more importantly, expensive to staff with people who can run them well.",{"type":128,"tag":129,"props":322,"children":323},{},[324],{"type":133,"value":325},"Notice that neither list is short and neither is free. Anyone who tells you headless is simply \"more modern\" is selling you the benefits column and hiding the costs one.",{"type":128,"tag":141,"props":327,"children":329},{"id":328},"when-should-you-use-a-headless-cms",[330],{"type":133,"value":34},{"type":128,"tag":129,"props":332,"children":333},{},[334],{"type":133,"value":335},"Headless earns its keep when specific conditions hold. Use a headless CMS when:",{"type":128,"tag":219,"props":337,"children":338},{},[339,349,367,377],{"type":128,"tag":223,"props":340,"children":341},{},[342,347],{"type":128,"tag":167,"props":343,"children":344},{},[345],{"type":133,"value":346},"You have strong engineers, in-house or through a partner.",{"type":133,"value":348}," This is the load-bearing condition. Headless is a good deal when you have a team that can build and maintain a front end, and a bad one when you do not. If nobody owns the front-end stack, headless just gave you a second system with no operator.",{"type":128,"tag":223,"props":350,"children":351},{},[352,357,359,365],{"type":128,"tag":167,"props":353,"children":354},{},[355],{"type":133,"value":356},"Front-end performance or experience is a competitive edge.",{"type":133,"value":358}," If Core Web Vitals, SEO, and a bespoke UI matter to the business, owning the rendering path is worth the work. This is our home turf, and it is why our own site is a Nuxt front end on a headless source. On the SEO specifics, headless done wrong can tank organic traffic, so read the ",{"type":128,"tag":191,"props":360,"children":362},{"href":361},"\u002Fblog\u002Fenterprise-cms\u002Fheadless-cms-seo-complete-guide",[363],{"type":133,"value":364},"headless CMS SEO complete guide",{"type":133,"value":366}," before you commit.",{"type":128,"tag":223,"props":368,"children":369},{},[370,375],{"type":128,"tag":167,"props":371,"children":372},{},[373],{"type":133,"value":374},"You publish to more than a website.",{"type":133,"value":376}," A web app plus a native app plus a partner feed is the classic case where one content API beats maintaining the same content in three places.",{"type":128,"tag":223,"props":378,"children":379},{},[380,385],{"type":128,"tag":167,"props":381,"children":382},{},[383],{"type":133,"value":384},"Your content is genuinely structured and reused.",{"type":133,"value":386}," Deeply modeled, reused-everywhere content favors headless, and Sanity in particular.",{"type":128,"tag":129,"props":388,"children":389},{},[390,392,397],{"type":133,"value":391},"Do ",{"type":128,"tag":167,"props":393,"children":394},{},[395],{"type":133,"value":396},"not",{"type":133,"value":398}," reach for headless when your site is a handful of marketing pages a small team edits in place, when nobody will own the front end after launch, or when your \"personalization\" is a geolocated banner. In those cases headless adds cost and moving parts for control you will not use. Being honest about this is the difference between advising and selling.",{"type":128,"tag":141,"props":400,"children":402},{"id":401},"when-should-you-stay-traditional-or-go-dxp",[403],{"type":133,"value":404},"When should you stay traditional or go DXP?",{"type":128,"tag":129,"props":406,"children":407},{},[408],{"type":133,"value":409},"Stay on the traditional or DXP side when the delivery weight is better carried by the platform than by your team.",{"type":128,"tag":219,"props":411,"children":412},{},[413,423,433,443],{"type":128,"tag":223,"props":414,"children":415},{},[416,421],{"type":128,"tag":167,"props":417,"children":418},{},[419],{"type":133,"value":420},"You need deep, data-driven personalization across the journey.",{"type":133,"value":422}," Real rules-and-data personalization, not a banner, is exactly where Sitecore and AEM earn their license cost. Rebuilding that on a headless stack is a large project in its own right.",{"type":128,"tag":223,"props":424,"children":425},{},[426,431],{"type":128,"tag":167,"props":427,"children":428},{},[429],{"type":133,"value":430},"Your integration surface and governance needs are heavy.",{"type":133,"value":432}," Large author teams with real roles, workflow, and compliance, plus tight coupling to a marketing suite, are what these platforms are built for.",{"type":128,"tag":223,"props":434,"children":435},{},[436,441],{"type":128,"tag":167,"props":437,"children":438},{},[439],{"type":133,"value":440},"You are in a regulated or higher-education context.",{"type":133,"value":442}," We deliver Sitecore on pharma and higher-education properties, and the reason those clients stay on a DXP is the governance, workflow, and accessibility scaffolding the platform provides, not the raw rendering.",{"type":128,"tag":223,"props":444,"children":445},{},[446,451],{"type":128,"tag":167,"props":447,"children":448},{},[449],{"type":133,"value":450},"Your team is small and needs the platform to carry delivery.",{"type":133,"value":452}," If you cannot staff a front-end practice, a platform that ships templates and page composition out of the box is the pragmatic call.",{"type":128,"tag":129,"props":454,"children":455},{},[456],{"type":133,"value":457},"The trap on this side is overbuying: paying for a DXP's personalization and integration depth to run a brochure site. If you are not using the expensive capabilities, a cheaper platform your existing team can operate will cost you less in total.",{"type":128,"tag":141,"props":459,"children":461},{"id":460},"where-does-modern-sitecore-blur-the-line",[462],{"type":133,"value":463},"Where does modern Sitecore blur the line?",{"type":128,"tag":129,"props":465,"children":466},{},[467,469,475],{"type":133,"value":468},"This is the nuance most comparisons miss, and it matters if Sitecore is on your shortlist. The traditional-versus-headless line now runs ",{"type":128,"tag":470,"props":471,"children":472},"em",{},[473],{"type":133,"value":474},"through",{"type":133,"value":476}," Sitecore, not around it.",{"type":128,"tag":129,"props":478,"children":479},{},[480],{"type":133,"value":481},"Classic Sitecore (XP with server-side rendering) is the traditional model: the CMS renders the pages. But modern Sitecore (XM Cloud, headless with JavaScript Services, or JSS) is API-first and composable, so you can run Sitecore as a headless source feeding a Next.js or Nuxt front end while keeping Sitecore's content tree, personalization, and governance. The same is increasingly true across the DXP tier, where \"composable\" is the vendors' word for bolting a headless delivery model onto a platform that used to render everything itself.",{"type":128,"tag":129,"props":483,"children":484},{},[485,487,493],{"type":133,"value":486},"The practical takeaway: \"headless vs traditional CMS\" is not always a choice between two products. On Sitecore it can be a choice about how you run one product. If you already own Sitecore, you may not need to migrate to get headless benefits. You may need to move to its headless delivery model, which is a smaller and safer project. That is work we do on ",{"type":128,"tag":191,"props":488,"children":490},{"href":489},"\u002Fservices\u002Fsitecore",[491],{"type":133,"value":492},"Sitecore",{"type":133,"value":494}," specifically.",{"type":128,"tag":141,"props":496,"children":498},{"id":497},"how-do-you-actually-choose-a-decision-table",[499],{"type":133,"value":500},"How do you actually choose? A decision table",{"type":128,"tag":129,"props":502,"children":503},{},[504],{"type":133,"value":505},"Ignore the feature matrices and answer these questions about your own situation. Each row points you toward the tier that fits, not the one that markets best.",{"type":128,"tag":129,"props":507,"children":508},{},[509],{"type":128,"tag":156,"props":510,"children":513},{"alt":511,"src":512},"A decision quadrant placing headless CMS, composable DXP, traditional CMS, and headless-without-a-team by front-end team strength and how much delivery the platform carries","\u002Fcovers\u002Fenterprise-cms\u002Fvisuals\u002Fvs-traditional-quadrant.png",[],{"type":128,"tag":515,"props":516,"children":517},"table",{},[518,542],{"type":128,"tag":519,"props":520,"children":521},"thead",{},[522],{"type":128,"tag":523,"props":524,"children":525},"tr",{},[526,532,537],{"type":128,"tag":527,"props":528,"children":529},"th",{},[530],{"type":133,"value":531},"Your situation",{"type":128,"tag":527,"props":533,"children":534},{},[535],{"type":133,"value":536},"Leans headless",{"type":128,"tag":527,"props":538,"children":539},{},[540],{"type":133,"value":541},"Leans traditional \u002F DXP",{"type":128,"tag":543,"props":544,"children":545},"tbody",{},[546,568,589,610,631,652,673,694],{"type":128,"tag":523,"props":547,"children":548},{},[549,558,563],{"type":128,"tag":550,"props":551,"children":552},"td",{},[553],{"type":128,"tag":167,"props":554,"children":555},{},[556],{"type":133,"value":557},"Who builds the front end?",{"type":128,"tag":550,"props":559,"children":560},{},[561],{"type":133,"value":562},"Strong in-house or partner engineers who want control",{"type":128,"tag":550,"props":564,"children":565},{},[566],{"type":133,"value":567},"You want the platform to own delivery",{"type":128,"tag":523,"props":569,"children":570},{},[571,579,584],{"type":128,"tag":550,"props":572,"children":573},{},[574],{"type":128,"tag":167,"props":575,"children":576},{},[577],{"type":133,"value":578},"How much personalization do you need?",{"type":128,"tag":550,"props":580,"children":581},{},[582],{"type":133,"value":583},"Little, or you will build it yourself",{"type":128,"tag":550,"props":585,"children":586},{},[587],{"type":133,"value":588},"Deep, rules-and-data-driven across the journey",{"type":128,"tag":523,"props":590,"children":591},{},[592,600,605],{"type":128,"tag":550,"props":593,"children":594},{},[595],{"type":128,"tag":167,"props":596,"children":597},{},[598],{"type":133,"value":599},"How structured is your content?",{"type":128,"tag":550,"props":601,"children":602},{},[603],{"type":133,"value":604},"Highly structured, reused across channels",{"type":128,"tag":550,"props":606,"children":607},{},[608],{"type":133,"value":609},"Page-shaped, edited largely in context",{"type":128,"tag":523,"props":611,"children":612},{},[613,621,626],{"type":128,"tag":550,"props":614,"children":615},{},[616],{"type":128,"tag":167,"props":617,"children":618},{},[619],{"type":133,"value":620},"How many channels?",{"type":128,"tag":550,"props":622,"children":623},{},[624],{"type":133,"value":625},"Website plus app(s) plus feeds",{"type":128,"tag":550,"props":627,"children":628},{},[629],{"type":133,"value":630},"One website, maybe a second brand site",{"type":128,"tag":523,"props":632,"children":633},{},[634,642,647],{"type":128,"tag":550,"props":635,"children":636},{},[637],{"type":128,"tag":167,"props":638,"children":639},{},[640],{"type":133,"value":641},"How heavy is your integration surface?",{"type":128,"tag":550,"props":643,"children":644},{},[645],{"type":133,"value":646},"API-first fits a composable stack",{"type":128,"tag":550,"props":648,"children":649},{},[650],{"type":133,"value":651},"Tight coupling to one marketing suite (e.g. Adobe)",{"type":128,"tag":523,"props":653,"children":654},{},[655,663,668],{"type":128,"tag":550,"props":656,"children":657},{},[658],{"type":128,"tag":167,"props":659,"children":660},{},[661],{"type":133,"value":662},"What is your author profile?",{"type":128,"tag":550,"props":664,"children":665},{},[666],{"type":133,"value":667},"Comfortable with structured editing and preview",{"type":128,"tag":550,"props":669,"children":670},{},[671],{"type":133,"value":672},"Non-technical, wants WYSIWYG in-context editing",{"type":128,"tag":523,"props":674,"children":675},{},[676,684,689],{"type":128,"tag":550,"props":677,"children":678},{},[679],{"type":128,"tag":167,"props":680,"children":681},{},[682],{"type":133,"value":683},"What is your team's capacity to maintain a front end?",{"type":128,"tag":550,"props":685,"children":686},{},[687],{"type":133,"value":688},"Real capacity, now and after launch",{"type":128,"tag":550,"props":690,"children":691},{},[692],{"type":133,"value":693},"Limited; needs the platform to carry it",{"type":128,"tag":523,"props":695,"children":696},{},[697,705,710],{"type":128,"tag":550,"props":698,"children":699},{},[700],{"type":128,"tag":167,"props":701,"children":702},{},[703],{"type":133,"value":704},"What is the total cost you can absorb?",{"type":128,"tag":550,"props":706,"children":707},{},[708],{"type":133,"value":709},"License is low; you invest in engineering",{"type":128,"tag":550,"props":711,"children":712},{},[713],{"type":133,"value":714},"You can fund license plus specialists to run it",{"type":128,"tag":129,"props":716,"children":717},{},[718],{"type":133,"value":719},"The last row is the one people get wrong most often, so it is worth stating plainly.",{"type":128,"tag":141,"props":721,"children":723},{"id":722},"total-cost-of-ownership-is-not-the-license-price",[724],{"type":133,"value":725},"Total cost of ownership is not the license price",{"type":128,"tag":129,"props":727,"children":728},{},[729],{"type":133,"value":730},"The license is the visible number, and it is rarely the number that decides the project. Total cost of ownership is the license plus the team required to run the platform well plus the ongoing delivery and maintenance.",{"type":128,"tag":129,"props":732,"children":733},{},[734],{"type":133,"value":735},"A \"free\" or cheap headless CMS that needs a full front-end engineering practice to operate can easily cost more than an expensive DXP your existing team already knows. And an expensive DXP run without the discipline it demands forks into an unmaintainable mess that costs a rescue project to fix. We get called in for exactly that pattern more than any other: the platform was fine, the delivery was underfunded.",{"type":128,"tag":129,"props":737,"children":738},{},[739],{"type":133,"value":740},"There is one more line item worth naming because it fits enterprise CMS work specifically: demand is lumpy. A big build, then quieter maintenance, then a migration or redesign that spikes again. Staffing full-time specialists for the peaks means paying them through the troughs. This is why our support hours never expire. The demand is uneven, so the support should be too, and you draw the hours down when the work actually arrives.",{"type":128,"tag":141,"props":742,"children":744},{"id":743},"what-we-chose-on-a-real-build-and-why",[745],{"type":133,"value":746},"What we chose on a real build, and why",{"type":128,"tag":129,"props":748,"children":749},{},[750],{"type":133,"value":751},"Enough principle. Here is a concrete decision we made.",{"type":128,"tag":129,"props":753,"children":754},{},[755,757,762],{"type":133,"value":756},"On a recent production Nuxt build for a client, we ran a genuine evaluation of three headless options before writing any content models: ",{"type":128,"tag":167,"props":758,"children":759},{},[760],{"type":133,"value":761},"Sanity, Storyblok, and Strapi",{"type":133,"value":763},". All three are capable. Here is how the tradeoffs actually landed for that project.",{"type":128,"tag":219,"props":765,"children":766},{},[767,777,787],{"type":128,"tag":223,"props":768,"children":769},{},[770,775],{"type":128,"tag":167,"props":771,"children":772},{},[773],{"type":133,"value":774},"Sanity",{"type":133,"value":776}," is the developer favorite, and deservedly. Its content model is unusually flexible and its query language (GROQ) treats content as structured data rather than pages. If the priority had been precise, deeply structured content and the team was happy to build the editing experience around it, Sanity would have won.",{"type":128,"tag":223,"props":778,"children":779},{},[780,785],{"type":128,"tag":167,"props":781,"children":782},{},[783],{"type":133,"value":784},"Strapi",{"type":133,"value":786}," is open-source and self-hostable, which is attractive when you want to own the whole stack and avoid per-seat SaaS pricing. The cost is that you own hosting and upgrades, and the editing experience is yours to build too. For this client that added operational weight they did not want to carry.",{"type":128,"tag":223,"props":788,"children":789},{},[790,795],{"type":128,"tag":167,"props":791,"children":792},{},[793],{"type":133,"value":794},"Storyblok",{"type":133,"value":796}," won, and the deciding factor was editor experience without giving up the clean component model. Its visual editor gives non-technical authors a live preview of the actual page while keeping the structured, component-based content model that headless is supposed to buy you. Its integration into a modern JavaScript framework was the lightest we have worked with, which shortened the front-end build.",{"type":128,"tag":129,"props":798,"children":799},{},[800],{"type":133,"value":801},"That decision was specific to that client: non-technical authors who needed in-context preview, a Nuxt front end, and no appetite to self-host. Change any of those and the answer changes. If your authors are technical and your content is deeply relational, Sanity is a reasonable different answer to the same question. The point of the evaluation was to match the tool to the team.",{"type":128,"tag":141,"props":803,"children":805},{"id":804},"does-headless-or-traditional-matter-more-than-delivery",[806],{"type":133,"value":807},"Does headless or traditional matter more than delivery?",{"type":128,"tag":129,"props":809,"children":810},{},[811],{"type":133,"value":812},"No, and this is the honest closer. Whichever side of the line you land on, the practices that decide whether the site is an asset or a liability are the same. Build a component library as the single source of truth. Bake accessibility into the CMS layer rather than bolting it on before an audit. Put governance in place that stops the system forking over its multi-year life.",{"type":128,"tag":129,"props":814,"children":815},{},[816],{"type":133,"value":817},"We apply the same delivery discipline building a Nuxt front end on Storyblok that we apply building components in Sitecore. The tooling differs. The failure modes do not. A well-run traditional build beats a badly-run headless one every time, and the reverse is just as true. Pick the tier that fits your team using the table above, then spend your real attention on delivery, because that is where these projects are actually won or lost.",{"type":128,"tag":129,"props":819,"children":820},{},[821,823,828,830,834,836,843],{"type":133,"value":822},"If you are weighing headless CMS vs traditional CMS for a specific build, or trying to decide whether to move an existing Sitecore or WordPress site, that is the work we do. Have a look at our ",{"type":128,"tag":191,"props":824,"children":826},{"href":825},"\u002Fservices\u002Fheadless-cms",[827],{"type":133,"value":182},{"type":133,"value":829}," and ",{"type":128,"tag":191,"props":831,"children":832},{"href":489},[833],{"type":133,"value":492},{"type":133,"value":835}," practices, or ",{"type":128,"tag":191,"props":837,"children":840},{"href":5,"rel":838},[839],"nofollow",[841],{"type":133,"value":842},"book a call",{"type":133,"value":844}," and we will talk through your actual situation rather than a feature list.",{"type":128,"tag":141,"props":846,"children":848},{"id":847},"read-next",[849],{"type":133,"value":850},"Read next",{"type":128,"tag":219,"props":852,"children":853},{},[854,864,874,885],{"type":128,"tag":223,"props":855,"children":856},{},[857,862],{"type":128,"tag":191,"props":858,"children":859},{"href":193},[860],{"type":133,"value":861},"Enterprise headless CMS explained",{"type":133,"value":863},": what the enterprise tier adds over a basic headless CMS, and when you actually need it.",{"type":128,"tag":223,"props":865,"children":866},{},[867,872],{"type":128,"tag":191,"props":868,"children":869},{"href":361},[870],{"type":133,"value":871},"The complete guide to headless CMS SEO",{"type":133,"value":873},": how to keep organic traffic when you own the rendering path, the part headless most often breaks.",{"type":128,"tag":223,"props":875,"children":876},{},[877,883],{"type":128,"tag":191,"props":878,"children":880},{"href":879},"\u002Fblog\u002Fenterprise-cms\u002Fenterprise-cms-2026-platform-and-partner",[881],{"type":133,"value":882},"Enterprise CMS in 2026: how to choose the platform and the partner",{"type":133,"value":884},": the pillar guide to both decisions, platform and delivery.",{"type":128,"tag":223,"props":886,"children":887},{},[888,890,895,897,902],{"type":133,"value":889},"Work with us: our ",{"type":128,"tag":191,"props":891,"children":892},{"href":825},[893],{"type":133,"value":894},"headless CMS agency",{"type":133,"value":896}," practice, or ",{"type":128,"tag":191,"props":898,"children":899},{"href":489},[900],{"type":133,"value":901},"Sitecore development and support",{"type":133,"value":198}]