What this comparison deliberately leaves out: Joomla and Contao do not get their own chapters. Both have declining or highly niche relevance for new B2B projects in the German-speaking market and mainly matter for existing installations. Also excluded: classic website builders such as Wix, Squarespace, Strato or the IONOS builder. For a serious company website with growth ambitions we view them critically – vendor lock-in is high, data export and migration are limited. And this is deliberately not a shop system comparison.
Overview: what the systems typically stand for
| Option | Typical strength | Typical limit |
|---|---|---|
| No CMS needed | Small, long-lived websites; lean code; very good performance; AI-supported changes | No classic editing, roles or approvals |
| WordPress* | Marketing, SEO, landing pages, large ecosystem and many service providers | Requires plugin, maintenance and quality discipline |
| Webflow | Design-driven websites with managed hosting and fast visual delivery | SaaS dependency and limits with complex structures and integrations |
| Neos | Structured content and very good inline editing | Smaller market of specialised agencies |
| TYPO3 | Multisite, multilingualism, roles and governance in the DACH region | Often too heavy for small, agile marketing projects |
| Drupal | Complex data models, portals, permissions, integrations and security | High concept, development and operating costs |
| Storyblok | Headless, omnichannel and free frontend choice with a visual editor | Additional frontend complexity and SaaS dependency |
The wrong question is: which CMS is the best?
Anyone planning a website relaunch often starts with a product question. WordPress or TYPO3? Webflow or a headless CMS? That question comes too early. It assumes it is already clear how the website should be built technically. But exactly that should be derived from the requirements first.
A website today can be a relatively static corporate presence. It can also be a campaign machine, specialist portal, recruiting platform, product database, customer portal and data source for apps all at once. Both projects are called a “website”, yet they need neither the same processes nor the same architecture. The more sensible order is therefore:
- What tasks does the website take on for marketing, sales, service and recruiting?
- Who changes which content – and how often does that really happen?
- Which data and functions come from other systems?
- Who is responsible for operations, security and further development after launch?
- What requirements exist for data protection, accessibility, performance and vendor independence?
- Only then: which system meets these requirements with as little unnecessary complexity as possible?
That sounds obvious. In website projects things often go differently. A system is set in advance out of habit, agency preference or because of a single feature. Processes and requirements are then adapted to the chosen tool. This is one of the most common reasons for unnecessarily expensive relaunches.
Does a company website in 2026 still need a CMS at all?
A few years ago the answer would almost automatically have been “yes”. A CMS was the usual way to change content without programming. That assumption no longer holds without qualification. As of 31 July 2026, W3Techs reports no recognised content management system for 30.4 percent of the websites surveyed. The number does not mean all of these websites are modern, static or AI-supported. But it clearly shows: a classic CMS is not a technical obligation.
For a law firm or medical practice, consultancy, trade business or local branch with ten to thirty long-lived pages, a custom-built website without a database and editing interface can make a lot of sense. The public site then consists of finished HTML, CSS and JavaScript files or is generated statically from a codebase. Changes are published via Git and a controlled development process.
What is new is not the static website. What is new is how economically it can be built and maintained. Tools such as Lovable, Claude Code or OpenAI Codex can generate layouts and components, analyse existing codebases, implement changes and support testing. A small website can therefore genuinely be changed “via AI”. That differs from maintenance in a CMS: the AI edits code and files, not just approved content fields.
This option is particularly interesting when content is rarely changed, only one responsible party exists and no complex editorial or approval processes are required. It is less suitable as soon as several people regularly publish content, manage structured data or have to document legally binding approvals.
Our assessment
“No CMS needed” is not a budget option and not a licence for uncontrolled vibe coding. It is an architecture in its own right that can be simpler, faster and safer given the right requirements – but only with version control, tests, backups and clear responsibility.
Vibe coding: sensible accelerator or expensive shortcut?
Vibe coding describes a development style in which requirements are formulated in everyday language and translated into code by AI tools. For prototypes, small websites and clearly bounded functions this can speed up development considerably. However, the term only describes how code comes about. It says nothing about whether the result is strategically sound, accessible, secure, maintainable or performant. A website can look good in the browser and still have serious flaws: unclear information architecture, unmeasurable forms, missing consent logic, inaccessible dialogues or oversized JavaScript bundles.
- The scope and goal of the website are clearly limited.
- An existing component and design system sets the guard rails.
- Code sits in version control and every change stays traceable.
- Staging, automated tests and manual sign-off are in place.
- A qualified person reviews security, data protection, SEO and accessibility.
It becomes risky when the AI is expected to handle concept, design, code, content and operations at the same time without professional oversight. Decisions are then made faster, but not necessarily better. The costs do not disappear – they resurface later as technical debt, a security gap or an unmanageable codebase.
Connecting AI to the website: more than a chat window
During system selection people now often ask whether the website is “AI-ready”. That is too vague. Almost any modern website can embed an external chatbot. What matters is which data the AI may use, how answers are controlled and whether the function is merely an add-on or part of the digital product.
| Stage | Example | Architectural consequences |
|---|---|---|
| 1. External service | Chatbot or translation embedded as a ready-made service | Check consent, data processing agreements, data transfer and load time |
| 2. AI search | Content is searched semantically and summarised | Clean content structure, indexing, source references and updates required |
| 3. Assistant on your own knowledge base | Approved content, product data or documents are used | Permissions, retrieval, logging, data quality and hallucination control needed |
| 4. AI as a product function | Assistant works with customer data in a portal or application | Authentication, roles, auditability, security architecture and deep backend integration are central |
For stage one a classic CMS or even a static website is often enough. From stage three onwards, structured content, APIs and clear permission models become far more important. Drupal, Storyblok, Neos, TYPO3 or a custom-planned architecture then gain weight. WordPress* can also be connected, but complex scenarios require a very deliberate data and security concept.
What modern website systems must deliver in the frontend
Responsive design: not just desktop, tablet and smartphone
Responsive design is often reduced to three layout views. That is not enough. Websites must work reliably across different screen widths, font scaling, portrait and landscape orientation, and touch, mouse and keyboard input. A good system does not prevent responsive errors automatically. What counts is a robust design system, flexible components and real testing.
Core Web Vitals and load times
Google describes the Core Web Vitals as metrics for real user experience. The focus is currently on LCP for loading, INP for responsiveness and CLS for visual stability. Good values do not come from the name of the CMS, but from frontend code, image strategy, hosting, caching and the controlled use of external scripts.
Static websites and modern headless frontends have structural advantages because they can pre-generate pages and serve them without extensive backend logic. Webflow can also be very fast. WordPress*, TYPO3 and Drupal achieve good values when templates, extensions and infrastructure are properly optimised. Performance budgets, field measurements with real user data and clear rules for new third parties are sensible.
Accessibility as a quality standard
The W3C's WCAG structure accessibility around four principles: content must be perceivable, operable, understandable and robust. The German Accessibility Strengthening Act has applied since 28 June 2025 to certain products and services, with digital offerings in electronic commerce being particularly relevant. Whether a specific company is covered should be checked legally.
For CMS selection this means: the system must enable semantic components and protect editors from typical mistakes. Completely free layouts are not automatically an advantage. Where accessibility is binding, limited, tested components are often better than unlimited design freedom.
What a modern system must deliver in the backend
Editing and approvals
A small marketing department needs different functions than a university, a corporation or a public institution. What matters is not only user accounts, but roles, versioning, four-eyes approvals, previews, scheduled publishing, translation processes and traceable responsibilities. The simpler the project, the more dangerous it is to build in enterprise processes as a precaution.
Structured content and reuse
Services, contacts, locations, events and products should be maintained as structured records when they appear in several places. If the same information is copied across many pages, contradictions and unnecessary maintenance effort arise. Headless and enterprise CMS are strong here, but WordPress* can also be structured sensibly with custom post types and fields.
Interfaces and integrations
An API alone does not make a good integration. What matters is the data model, permissions, error handling, documentation, webhooks, synchronisation direction and responsibility during outages. CRM, ERP, PIM, DAM or applicant systems should not be connected through random plugin chains when they are business critical.
Data protection, security and jurisdiction
Open source and SaaS distribute responsibility differently. With self-hosted systems, hosting, network and data location can largely be determined yourself. In return, updates, monitoring, backups and incident processes have to be organised. With SaaS the provider takes over large parts of operations, while dependencies on contract terms, subprocessors, data flows and jurisdiction arise.
AI functions add new questions: which inputs are transmitted to model providers? Is content used for training? Which data may be indexed? How is access restricted and how are answers logged? These decisions belong in the architecture, not only in the privacy policy.
Agency selection and long-term operations
The system also determines which agencies and specialists will be available later. WordPress* has a very large market, but provider quality varies considerably. TYPO3 and Drupal have smaller, often more technically minded service markets. Neos offers convincing technology but can regionally lead to higher dependence on individual specialists. With Webflow and Storyblok the operating model stays closely tied to the platform provider.
- Who owns domains, hosting accounts, repositories, licences and admin access?
- Is the website documented and can another provider take over?
- Who is responsible for updates, security advisories, backups and recovery?
- Are there staging, version control, automated deployments and sign-off processes?
- How are accessibility, performance and data protection tested?
- What recurring costs arise for licences, plugins, hosting and maintenance?
Market shares 2026: orientation, not a quality ranking
According to current W3Techs data from 31 July 2026, WordPress is used by 41.2 percent of all websites surveyed and reaches a 59.1 percent share among websites with a recognised CMS. Webflow stands at 0.8 percent of all websites and 1.2 percent of the CMS market. Drupal reaches 0.7 and 1.0 percent, TYPO3 0.4 and 0.5 percent. 30.4 percent use none of the CMS monitored by W3Techs.
These figures matter for selection because reach indicates the availability of specialists, extensions and long-term viability. They say nothing about whether a system suits a specific project. TYPO3 is small globally but far more relevant in the German-speaking enterprise and public sector. Storyblok and Neos also operate in niches, yet can fit very well there.
| System / category | Share of all websites | Share of the recognised CMS market |
|---|---|---|
| No monitored CMS | 30.4 % | – |
| WordPress | 41.2 % | 59.1 % |
| Webflow | 0.8 % | 1.2 % |
| Drupal | 0.7 % | 1.0 % |
| TYPO3 | 0.4 % | 0.5 % |
| Neos | below 0.1 % | below 0.1 % |
| Storyblok | below 0.1 % | below 0.1 % |
W3Techs figures as of 31 July 2026. Market shares vary with measurement method and reference date.
The systems in detailed comparison
WordPress*: the pragmatic marketing all-rounder
WordPress* remains the most pragmatic solution for many SME and marketing websites. That is less about the core software than about the large ecosystem. Extensions or proven integration paths exist for practically every common CRM, newsletter system, form, SEO or tracking tool. With Elementor, marketing teams can build pages visually and change them relatively quickly.
The strength is also the risk. WordPress projects are often assembled from too many plugins, add-ons and custom workarounds. This increases the attack surface, update effort and performance risks. A professional setup requires a limited, documented plugin stack, a component model, staging, backups, monitoring and binding update processes.
For AI-supported development WordPress is interesting because theme, plugin and integration code is openly accessible. At the same time, AI should not work uncontrolled directly on a production installation. WordPress can also run headless via the REST API or GraphQL, or be published statically. That raises technical complexity and should only be chosen when there is a concrete benefit.
Webflow: strong design with low operating effort
Webflow combines visual website building, CMS and managed hosting. For design-driven corporate websites and campaigns this is attractive: layouts and interactions can be implemented very directly, while server operations and core updates largely stay with the provider. The platform encourages clean responsive rules more than many classic drag-and-drop builders.
The limits show with complex data models, deep integrations, large multisite structures and strategic sovereignty. Webflow is a proprietary cloud platform. Pricing, product limits, hosting and many dynamic functions remain tied to the provider. Companies with high requirements for data location, auditability or exit should assess this dependency deliberately.
Drupal: when complexity is genuinely there
Drupal plays to its strengths with complex portals, data models, roles, workflows and integrations. The JSON:API is anchored in the core and works together with the entity, field and permission system. That makes Drupal a strong foundation for classic, hybrid and headless architectures.
For a normal SME website Drupal would usually be oversized. It demands a good technical concept, experienced developers and professional operations. High security or compliance requirements do not automatically argue for Drupal, but the system offers far more structural options to implement such requirements cleanly.
TYPO3: multisite, languages and governance
TYPO3 is particularly strong when many websites, languages, roles and organisational units are managed centrally. Universities, associations, public bodies and larger mid-sized companies often use the system for controlled web landscapes. Permissions, workspaces and multisite functions are not bolted on later but part of the typical usage model.
Marketing teams sometimes experience TYPO3 as less spontaneous than WordPress* or Webflow. That is often the consequence of the guard rails in place. Those who need governance benefit from it. Those who only want to build landing pages quickly pay for complexity that adds no value.
Neos: good editing and a structured content model
Neos combines direct inline editing with a flexible content repository. Editors work close to the final presentation while content can still be organised in a structured way via dimensions, workspaces and interfaces. The main risk is the smaller specialist market: companies should check early how many suitable agencies are available and how a provider change would work.
Storyblok: headless with visual editing
Storyblok separates content management from the frontend. Content is delivered via APIs to websites, apps or other channels. The visual editor reduces a typical weakness of many headless systems: editors can see changes in page context. This architecture pays off when several frontends, independent deployment cycles or omnichannel delivery are genuinely required. For a single corporate website it quickly creates unnecessary complexity.
No CMS needed: lean, fast and maintainable via AI in a controlled way
A website without a CMS can be the most economical solution when few pieces of content change rarely. It needs no running database, no plugin updates and no general editing interface. The public attack surface is usually smaller and very good load times are easier to achieve.
AI tools make maintenance more accessible. They can create new pages from existing components, replace text, add structured data or fix technical errors. Nevertheless the process remains a software change. Every adjustment should be a traceable commit, built automatically and reviewed before publication. This architecture is unsuitable when frequent editorial work, many participants, translation workflows or extensive structured content are expected.
Direct comparison by key criteria
| Criterion | WordPress* | Webflow | Drupal / TYPO3 | Neos | Storyblok | No CMS |
|---|---|---|---|---|---|---|
| Marketing agility | Very high | High | Medium to low | Medium to high | Medium | Medium with an AI process |
| Editorial workflows | Good, extensible | Good for small teams | Very strong | Very strong | Strong | Not available |
| Complex data models | Medium | Limited | Very strong | Very strong | Very strong | Custom, but without editing |
| Interfaces | High | Medium | Very high | High | Very high | Custom |
| Hosting freedom | Very high | Low | Very high | Very high | Low to medium | Very high |
| Core Web Vitals potential | Good with discipline | Very good | Very good with good implementation | Very good | Very good | Very high |
| Accessibility | Good with components and rules | Good with clean implementation | Very controllable | Very controllable | Depends on frontend | Very controllable |
| AI-supported code maintenance | Good | Limited by the platform | Good but demanding | Good | Very good in the frontend | Very high |
| Changing agency | Usually good | Medium | Good with documentation | Smaller market | Frontend replaceable, CMS tied | Good with a clean repository |
| Typical project size | Small to medium | Small to medium | Medium to enterprise | Medium | Medium to enterprise | Small to clearly limited |
Which solution fits which company?
| Starting point | Obvious option | What to pay attention to |
|---|---|---|
| Small practice, law firm or local service provider | No CMS or WordPress* | Change frequency, forms, local SEO, accessibility and clear responsibility |
| Marketing-driven SME | WordPress* or Webflow | Landing pages, tracking, SEO, components, maintenance and agency quality |
| Design-driven campaign or corporate site | Webflow or no CMS | Platform lock-in, future content volume, responsive testing and performance |
| International mid-sized company | TYPO3, Neos, Drupal or Storyblok | Languages, multisite, roles, integrations and operating model |
| Content hub with lots of structured content | Neos, Drupal, TYPO3 or WordPress* | Content model, search, taxonomies, editing and API needs |
| Portal or digital platform | Drupal, TYPO3 or a custom headless architecture | Authentication, security, permissions, interfaces and observability |
| Omnichannel with website and app | Storyblok, Drupal or Neos | Frontend team, preview, deployment, API governance and SaaS risk |
| Regulated offering or public body | Drupal or TYPO3; possibly Neos | Accessibility, auditability, hosting, roles and long-term support |
The 15 questions in the CMS check
The check deliberately goes deeper than the usual online quizzes. The following questions feed into the evaluation:
- What task should the website mainly fulfil?
- How often is content likely to change?
- How many people should edit content?
- How extensive and repetitive is the content?
- Which other systems need to be connected?
- How freely and quickly should new pages be designed?
- How important are hosting freedom and vendor independence?
- What budget is planned for concept, design and development?
- How should the website be supported after launch?
- What role should AI play in development and maintenance?
- Which AI functions should the website itself have?
- What requirements exist for data protection and security?
- On which devices and in which situations must the website work reliably?
- How important are very good load times and Core Web Vitals?
- What priority does digital accessibility have?
Anyone who wants to discuss the outcome will find the right setting in our relaunch consulting. The result view does not just name a single system. It provides a primary recommendation and a plausible alternative, a rationale based on the key answers, strengths and limits of the recommended architecture, warnings on data protection, accessibility, security or vendor lock-in, plus the option to request the full comparison matrix as an Excel file.
Conclusion: as much system as necessary – and as little complexity as possible
In 2026 the decision is no longer only between different CMS. Companies can choose between a classic CMS, a website platform, a headless architecture and an AI-maintained code website. That widens the options but does not make the decision easier.
WordPress* remains the pragmatic all-rounder for many marketing and SME websites. Webflow is convincing for design-driven projects with low operating effort. TYPO3 and Drupal make sense when multisite, governance, integrations and security justify the extra cost. Neos combines structured content with very good editing. Storyblok is strong when content is genuinely needed for several frontends.
And sometimes the right answer is: no CMS at all. For small, rarely changed websites a cleanly developed codebase with AI-supported maintenance can be more economical, faster and less maintenance-heavy. What matters is not confusing simplicity with a lack of quality assurance.
The best website system is therefore not the one with the most features. It is the system whose complexity matches the actual requirements, which the responsible people can handle, and which can still be operated sensibly after an agency change.
* In this comparison WordPress refers to the self-hosted open-source variant with the Elementor editor. Headless or static variants can additionally use the REST API, WPGraphQL and/or static publishing.