--- title: "Headless CMS, Traditional CMS or Static Site?" canonical: https://wavect.io/software-development-guide/headless-cms-vs-traditional-cms/ language: en description: "Compare common website configurations by editing, preview, content reuse, migration and ongoing responsibility. Start with the people who will maintain the …" image: "https://wavect.io/img/general/bak/open_graph_preview.jpg" --- Buyer brief # Which website setup fits your publishing team? Compare common website configurations by editing, preview, content reuse, migration and ongoing responsibility. Start with the people who will maintain the content. Short answer Choose the editing workflow first. Headless separates content management from presentation; static describes delivery. The two can coexist, and neither is a universal upgrade. Best for - Teams choosing an editing workflow before a website build or migration. - Publishers comparing reuse needs with frontend operating responsibility. Outside this guide - Assuming headless automatically improves speed or search rankings. - Replacing a working CMS without a specific publishing problem. // 01 ## Compare the options These are common configurations, not guaranteed product features. | Question | Coupled CMS | Content as code | Headless CMS | | --- | --- | --- | --- | | Daily editing | Often an integrated page editor | Usually a technical workflow | Separate editor; frontend preview needs integration | | Content reuse | Depends on the content model and interfaces | Possible through structured files | Can serve multiple channels through an API | | Preview and approval | Check the product and setup | Check branch previews and review process | Check draft access, preview and publication together | | Operating responsibility | CMS, extensions and hosting | Repository, build and hosting | CMS plus frontend, builds and integration | | Migration and export | Check content, media and plugin dependencies | Check file formats and build dependencies | Check API access, schema and media export | // 02 ## Where Wavect lands on this Keeping a healthy CMS may be the right choice. Better templates, content structure or maintenance can solve an editing problem without a migration. A separate content API adds responsibilities; it needs a real publishing or reuse requirement. [WordPress documents content access through its REST API](https://developer.wordpress.org/rest-api/), so a familiar CMS can also support a separate frontend. [Astro’s CMS guide](https://docs.astro.build/en/guides/cms/) describes combining external content with frontend rendering choices. Sources checked 19 October 2026; these references do not prescribe your stack. Three illustrative situations: a small business with stable pages may keep its existing CMS or use content as code if a technical maintainer is available. A frequent multilingual publisher should test editor roles, previews and translations in candidate systems. A team reusing structured content across channels may benefit from headless, provided frontend and operating ownership are clear. A change in editor skills or workflow can change each recommendation. Before migrating, inventory pages, assets and current URLs. Map content fields, redirects, language equivalents, metadata, canonicals and structured data. Keep drafts out of public indexing and check important old entry paths after launch. Architecture alone does not improve rankings or guarantee their retention. Separate design and implementation, content entry, migration, licences, hosting, build usage, integrations and maintenance. Verify access and export rights rather than assuming headless or open source eliminates lock-in. AI-assisted production is a delivery method, not a CMS category: draft output still needs factual and functional review. Discuss that workflow with [website development](/services/website-development/) and use [Web Apps](/services/web-apps/) when the main need is application behavior. ### Run the same editing rehearsal in each candidate Give an editor one representative service page, an image, a draft translation and a correction to an existing page. Ask them to create the draft, preview the actual frontend, edit search fields, request approval and publish. Then ask them to withdraw the page or restore an earlier version. Observe where the process needs developer help. A demo using only a title field does not test your publishing workflow. Define who can preview unpublished content and what happens when a translated page is missing. Check whether a preview uses the same content model as production, and whether a broken build leaves the last good site available. These are implementation and product questions; the label headless does not answer them. ### Model content for the reuse you actually need A service record can separate title, summary, body, proof reference and contact action. If the same record must appear on a website and another channel, define which fields travel and which belong to presentation. Avoid a single unstructured page-body field when those channels need individual facts. Equally, do not build a universal content model for reuse that nobody can name. Test with real long headings, missing optional fields and more than one language. Decide how links and assets are referenced, who owns shared records and how a change affects every place that displays them. Reuse can reduce duplicate editing while increasing the impact of a mistaken shared update. ### Rehearse migration and exit before choosing Export a representative page, its media, relationships and language versions. Confirm that the receiving team can understand the export without a vendor-only plugin. List what will not transfer: preview configuration, presentation templates, workflow rules or extension data may need rebuilding. For launch, map important old URLs to their retained or replacement destinations and check them after migration. Compare the two systems using the complete operating workload: editor support, CMS updates, frontend dependencies, build failures, backups and recovery. Keep a healthy existing setup when a smaller template or workflow change solves the real problem. // 03 ## Where this usually goes wrong - A content API is available but preview and approvals are only shown in slides. Ask an editor to complete the full rehearsal in the proposed setup. - Every page becomes a custom content type. Start from representative templates and identify which differences genuinely need structured fields. - The migration estimate excludes media, links, translations or redirects. Inventory those objects and assign their review before the implementation quote. // 04 ## The checklist Use this to prepare your scope. - Who edits, how often, and with which technical skills? - Which content types, languages and channels need reuse? - Which previews, roles and approvals must work in practice? - Which forms, integrations and current URLs must remain useful? - Who owns CMS accounts, frontend, exports, hosting and maintenance? - Rehearse draft, preview, approval, publication, withdrawal and recovery. - Test a representative export with media, relationships and translations. - Assign failures and updates across both the CMS and frontend. // 05 ## What this looks like in our work MyMerch provides storefront-engineering context. It is not evidence of a client headless-CMS migration. ### [MyMerch](/case-studies/mymerch/) - **Status:** Live - **Outcome:** ~50% - Efficiency Gain (Client-Reported) - **Summary:** ~50% efficiency gain (client-reported). Delivery errors reduced, Shopify storefront conversion lifted, no rewrite. - **Stack:** Shopify, Shopify Liquid, JavaScript These are selected projects, not our full portfolio. We have shipped 75+ products since 2018. // 06 ## Related services & reading - [SERVICE Website development](/services/website-development/) - [GUIDE Software handover checklist](/software-development-guide/software-handover-checklist/) - [CASE STUDY Mymerch](/case-studies/mymerch/) // 07 ## FAQs ### Can a static website have a CMS? Yes. Content can be managed separately and used to generate static pages. Static delivery and headless content management describe different choices. ### When is a conventional CMS enough? When the team’s editing, preview and publication tasks work well there and no separate frontend or reuse requirement justifies extra operations. ### Will nontechnical colleagues be able to edit? Test their actual tasks in the selected product and preview setup. The architecture label alone does not answer that question. ### Which costs continue after launch? Licences, hosting, build usage, integrations and maintenance depend on the selected setup. Ask for explicit responsibility and exit/export terms. Last reviewed: 2026-10-19 by [Kevin Riedl](/team/kevin-riedl/) [wiki ↗](https://www.wikidata.org/wiki/Q139796365) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/software-development-guide/headless-cms-vs-traditional-cms/#webpage", "@type": "WebPage", "dateModified": "2026-10-19", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-10-19", "url": "https://wavect.io/software-development-guide/headless-cms-vs-traditional-cms/" } ] } ``` ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/software-development-guide/headless-cms-vs-traditional-cms/#article", "@type": "Article", "about": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-10-19", "datePublished": "2026-10-19", "description": "Compare common website configurations by editing, preview, content reuse, migration and ongoing responsibility. Start with the people who will maintain the content.", "headline": "Which website setup fits your publishing team?", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-10-19", "mainEntityOfPage": "https://wavect.io/software-development-guide/headless-cms-vs-traditional-cms/#webpage", "mentions": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, { "@type": "Service", "name": "Website development", "url": "https://wavect.io/services/website-development/" } ], "name": "Which website setup fits your publishing team?", "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "reviewedBy": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/" }, "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".cmp-hero__headline", ".cmp-hero__lead" ] }, "url": "https://wavect.io/software-development-guide/headless-cms-vs-traditional-cms/" }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/software-development-guide/", "name": "Software development guide", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/software-development-guide/headless-cms-vs-traditional-cms/", "name": "Which website setup fits your publishing team?", "position": 3 } ] } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Content can be managed separately and used to generate static pages. Static delivery and headless content management describe different choices." }, "name": "Can a static website have a CMS?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "When the team’s editing, preview and publication tasks work well there and no separate frontend or reuse requirement justifies extra operations." }, "name": "When is a conventional CMS enough?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Test their actual tasks in the selected product and preview setup. The architecture label alone does not answer that question." }, "name": "Will nontechnical colleagues be able to edit?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Licences, hosting, build usage, integrations and maintenance depend on the selected setup. Ask for explicit responsibility and exit/export terms." }, "name": "Which costs continue after launch?" } ], "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".faq-question", ".faq-answer" ] } } ```