What exactly is a headless CMS, and how does it differ from a traditional one?

A traditional CMS does two jobs at once: it lets you edit content, and it assembles that content into web pages. A headless CMS only does the first. It organizes the content and makes it available through an interface, while a separate piece of software handles the presentation. The advantage is that the same content can feed your website, your app, and other channels simultaneously, and the front end is free to use whatever technology performs best. The cost is that you need engineering capacity to connect the two sides, and editors do not see a full what-you-see-is-what-you-get layout in the admin — they generally rely on a preview function. A team with a single content channel and no engineering resources does not necessarily need this route.

Will a website built on a CMS perform worse in search?

What matters is not which CMS you use but whether a handful of basic capabilities are in place: whether each page can have its own title and description, whether the URL structure is clean and controllable, whether images can be compressed and given alt text, whether a sitemap is generated, and how fast the mobile version loads. All four categories of system can do these things well, and all four can do them badly. What genuinely drags performance down is usually three things: piling on unused themes and plugins until the site slows to a crawl, a disorganized content structure in which similar pages dilute each other, and a redesign where URL migration was handled poorly. Turn these into direct questions and put them to vendors during selection.

If we move our existing site to a different CMS, will we lose all our traffic?

Changing systems does not make traffic disappear; mishandling the change does. The biggest risk comes from URLs changing without proper redirects, leaving search engines and every existing inbound link pointing at dead pages. The practical approach is to inventory all current URLs and identify your best-performing pages, build an old-to-new URL mapping table, set permanent redirects at launch, and preserve page titles, content, and structured data. After launch, keep monitoring indexing status and error pages and fix anything unusual immediately. The content migration itself also needs a proper inventory, particularly images and attachments, which are the files most often left behind.

How to Choose a CMS: Four Options Compared

“Once the site is built, can we update it ourselves?” is one of the most frequently asked questions in a quoting meeting.

Whether you can, how far you can go, and who does it all depend on the content management system you choose. That decision affects far more than launch day — it sets your maintenance costs and your room to expand for years afterwards. This guide does not recommend particular brands. It explains what each of the four routes is really like, so you can judge against your own circumstances.

What a CMS actually does, in plain terms

CMS stands for content management system. In essence it is an admin interface that lets people who cannot write code add, edit, and remove content on a website.

On a site with no CMS, changing a single word means asking an engineer to edit the code and upload it again. On a site with a CMS, an editor signs in, fills in the fields, presses publish, and it is done.

A CMS generally comprises four parts: the content editing interface, permission management (who may edit, who may publish), content storage, and the mechanism that turns content into web pages. The difference between the four options is mainly about who handles each of those four parts, and how much of it.

What each of the four routes is like

One: packaged platforms (subscription-based, all in one place)

The provider supplies the whole environment — hosting, admin, and templates. You register, pick a template, and fill in the content.

Suits: requirements that are mainly about presenting information, no technical staff, a desire to be live quickly, a limited budget.

Limits: layout and features can only be adjusted within what the platform permits; connecting your own systems or building unusual workflows tends to hit a wall; and when you eventually want to leave, you can typically take only text and images, with layout and functionality needing to be rebuilt.

Two: open-source systems (mature software you host yourself)

You use an established community-maintained system, installed on your own hosting, extended through plugins and themes.

Suits: mid-range requirements, a wish to retain room for adjustment, and someone — internal or a vendor — responsible for maintenance and updates.

Limits: the core system and its plugins need regular updates, which is a security necessity rather than an optional extra; and installing too many plugins slows the site down while increasing the risk of conflicts. For where maintenance responsibility begins and ends, see Website Security Basics for Businesses.

Three: headless CMS (content separated from presentation)

“Headless” means there is no front end. This type of system only organizes content and makes it available; a separate piece of software renders the pages.

Suits: one body of content feeding a website, an app, or several channels at once; demanding load-speed requirements; engineering resources available to maintain the front end.

Limits: you need engineering capacity to connect the two sides; editors cannot see the full layout in the admin and depend on preview; and the initial investment is higher than the first two options.

Four: a custom admin system

A management interface built around your actual workflow, containing only the features you will use.

Suits: unusual content structures, an admin that also has to carry operational workflows such as approvals, scheduling, or supplying data externally, or existing systems that need deep integration.

Limits: the highest initial cost and the longest development time, and it needs a clear requirements definition to avoid building the wrong thing.

Comparing the four across the dimensions that matter

Dimension	Packaged platform	Open source	Headless CMS	Custom admin
Time to launch	Fastest	Fast	Moderate	Slowest
Initial investment	Lowest	Low to moderate	Moderate	Highest
Flexibility	Bounded by the platform	Moderate to high	High	Highest
Maintenance burden	Carried by the platform	You own updates	Split across both sides	You own it
Lock-in risk	High	Low	Low	Low
Data portability	Usually content only	Full backup possible	Full export possible	Entirely yours

Pay particular attention to the lock-in row. Before deciding, ask one question: if we ever want to leave, what can we take with us? The answer to that usually affects long-term cost more than any difference in monthly fees. Evaluate it alongside the wider cost picture in How Website Costs Are Calculated.

Six practical conditions that decide the choice

One: who edits, and how often. If the person actually making updates is not comfortable with computers and only touches the site a few times a month, the admin needs to be simple enough to require no documentation. If instead you have a dedicated editor publishing weekly, workflow efficiency and collaboration permissions become important.

Two: whether the content has a fixed structure. Content with defined fields — blog posts, product specifications, case studies — is best managed in structured fields rather than dropped into one large text editor. Structured content is what makes reuse, filtering, and search possible later. For planning topics and article structure, see How to Run a Brand Blog.

Three: whether you need multiple languages. Multilingual is not simply one extra translation. URL structure, language switching, the maintenance workflow for each language, and language markup all have to be handled, and the depth of multilingual support varies enormously between systems. Do it when you have genuine overseas demand, not to look international at the cost of a permanent maintenance burden.

Four: baseline SEO capability. Turn this into a direct checklist: can each page have its own title and description, are URLs customizable and clean, can images be given alt text, is a sitemap generated automatically, can canonical URLs be set to avoid duplicate content, and how fast is the mobile version. For how to judge speed, see the Website Speed Optimization guide.

Five: whether you need to connect other systems. When CRM, ERP, payments, email marketing, or an internal database are involved, whether the system offers a usable interface becomes decisive. For the risks and acceptance approach, see the Guide to System Integration and API Development.

Six: who is responsible for maintenance and updates. This is the question most often skipped. An open-source system nobody updates is a security hole; a custom admin nobody maintains gradually becomes obsolete. Write maintenance responsibility into the contract at selection time.

E-commerce is a separate question

If the core of the site is selling things, the center of gravity shifts from how content is managed to how orders, inventory, payments, and fulfillment flow. That comparison has its own full treatment in Building an E-commerce Site; for choosing and testing payment integrations, see the Guide to Payment Gateway Integration in Taiwan.

What to watch when changing systems

Most companies are not building their first website but moving from an old one to a new one. The biggest risk in that move is not technical — it is URLs changing.

The basic steps:

Inventory your current URLs, flagging the pages that have organic traffic and external links today
Build an old-to-new URL mapping table, one to one, rather than sending everything back to the homepage
Set permanent redirects that take effect the moment you launch
Preserve page titles, content, and structured data — do not take the opportunity to rewrite content at the same time
Inventory your content assets; images, attachments, and downloadable files are the most commonly forgotten
Keep monitoring after launch, watching indexing status and error pages

The full list is in the Website Redesign SEO Checklist. One more point: changing CMS and redesigning the site are best not done at the same time. Launch both together and, when something goes wrong, it is very hard to tell which one caused it.

Three common selection mistakes

Mistake one: using “most features” as the criterion. Features you never use add nothing. They add learning cost and maintenance surface.

Mistake two: looking only at build cost and ignoring maintenance. Subscriptions, hosting, update hours, and plugin licenses accumulate, and the total frequently exceeds the cost of building.

Mistake three: not letting the actual users try it. The person deciding and the person using the admin every day are often not the same person. Have your real editors operate the system once before you choose, and problems invisible in a sales presentation surface quickly. Use a genuine piece of content and go through the complete flow — create, upload an image, preview, publish, edit — rather than watching the vendor demonstrate.

A useful test is to ask the vendor, during the demonstration, to change a page you nominate, and then to change it back yourself. Whether you can do that without an engineer’s help is the most direct answer available on whether the system suits you.

No single CMS suits everyone. The question worth asking is not which one is best, but which one’s limitations you can live with, given your staffing, your content types, and your plans for the next three years.

If you are comparing options, or want to check whether your current system can carry you much further, talk to NETVANA about your website requirements. NETVANA consults before quoting and does not sell fixed packages; our advisory services include architecture review and technical due diligence, and what each service includes and delivers is set out in the software services overview.

Further reading: to understand how the costs break down first, see How Website Costs Are Calculated; if you are building e-commerce, see Building an E-commerce Site; and if a redesign and migration is coming, start with the Website Redesign SEO Checklist. For the questions to ask before you commission a custom build, see How to Choose a Software Development Company; and for when to move from spreadsheets to a custom admin system, see A Guide to Building Internal Admin Systems. For how a CMS language model constrains multilingual sites, see The Multilingual Website Development Guide; and for checking that an open-source CMS license fits commercial use, see Open Source Licensing in Plain Language; and for the redesign project a CMS switch usually belongs to, see How a Website Redesign Actually Runs. After comparing CMS options, see whether a no-code platform fits your case too, see Are Low-Code and No-Code Platforms Right for You.