Choosing a CMS for SEO, the eight controls to test before you commit and the one test that settles it in an afternoon

No content management system will rank a site for you, and the differences between them that actually matter are narrower and more boring than any comparison page suggests. Eight controls decide whether a platform helps or fights you. Can you set the URL. Can you set the title and description per page. Does the page body arrive in the HTML without a script running. Can you issue a 301 redirect yourself. Can you set a canonical. Can you set noindex per page. Is there an automatic sitemap and does it exclude the right things. And can you change the HTML the template generates. Everything else is preference. The fastest way to decide between two platforms is to build one real page on a trial account of each and run the eight checks below, which takes an afternoon and answers more than a month of reading will.

The eight controls, and what a failure looks like

Control	The check	What a bad answer costs you
URL	Create a page and change its address, including removing a forced prefix such as a dated or category segment	A forced prefix is permanent on every page you will ever publish
Title and description	Set both per page, independently of the on-page headline	Titles that echo the H1 everywhere, and no control over how a result reads
Server-rendered body	Fetch the published page with a tool that does not run JavaScript and look for your paragraph text	The most expensive failure on this list, and the hardest to retrofit
Redirects	Create a 301 from an old address to a new one yourself, without a developer or a support ticket	Every content reorganisation becomes a project
Canonical	Set a canonical URL per page, and check what the platform sets by default	Parameter and variant duplicates you cannot consolidate
Per-page noindex	Switch one page out of search without affecting the rest	Internal search pages, thank you pages and filters in the index forever
Sitemap	Find the generated sitemap and confirm it excludes unpublished and noindexed pages	A file that votes for pages you asked to be left out
Template HTML	Add structured data, change a heading level, and see it in the served source	No schema, and heading structure you cannot correct

The rendering check is the one worth doing first

Of the eight, server rendering is the one that decides whether the rest matter. Everything else on this list can be fixed later with work. A platform that assembles the page body in the browser is a platform where your text may or may not be in the document that gets read, and the only honest way to know is to look.

The check is mechanical. Publish one page with a distinctive sentence in it. Fetch that URL with any tool that returns raw HTML and does not execute scripts, and search the response for your sentence. If it is there, the platform passes. If the response is a small shell with your text nowhere in it, you have found the thing that will cost you the most, and you have found it before signing rather than after migrating. Run the same check on a product or listing page as well as on an article, because the two are often built differently in the same system.

This is not an exotic concern on modern frameworks, it is the normal state of affairs that has to be configured correctly. Our pages on Next.js SEO and the metadata API, when a Vue app needs server rendering and why a crawler always sees a progressive web app as a first-time visitor each work through a different version of the same decision.

The four kinds of platform, and what you are really choosing between

• A hosted site builder. You get everything configured and a ceiling on what you can change. Good when nobody on the team writes code and the site is a few dozen pages. The thing to test is the URL structure and the template HTML, because those are where the ceiling usually sits. Our pages on what you can and cannot control in Wix and Squarespace against Wix cover that comparison specifically.
• A self-hosted traditional CMS. Full control of the HTML and the URL, at the price of maintenance and of plugin sprawl. The thing to test is how many plugins it takes to get the eight controls, because each one is a dependency you will be upgrading for years.
• An enterprise or developer CMS. Fine-grained control, with defaults that can surprise you. The redirect default is the classic example, and our page on Craft CMS URI formats and its redirect default works through one such case. For the Sitecore, Umbraco and Kentico family, the redirect, sitemap and robots defaults in each is the comparison.
• Headless, with a separate front end. The most control and the most ways to lose by default, because the CMS no longer renders anything and the obligation moves to your front end. Our page on the fields to model and the HTML to render in a headless setup lists the gaps that appear between the two.

If your platform is chosen for you because the business already runs on it, that is a legitimate answer and the work is different. Read the per-platform page for the system you are on, find which of the eight controls it makes awkward, and solve that one properly. A site on a mediocre platform with correct URLs, real server-rendered text and working redirects beats a site on a perfect platform with none of them.

Three things sold as SEO features that are not the decision

• A built-in SEO score. A traffic light on a draft measures whether you followed a checklist. It is a writing aid and it has no bearing on how the platform serves pages.
• Page speed claims. Hosting, images and third-party scripts dominate real-world speed on almost every site. Test your own built page rather than reading a benchmark built on a demo site.
• Keyword tools inside the CMS. Convenient, and never the reason to choose a platform. The research tool and the publishing tool do not have to be the same purchase.

The migration question, which is the real cost

If you already have a site, the cost of moving platforms is not the licence. It is the redirect map. Every URL that currently receives traffic or links has to resolve, with one 301 each, to its closest equivalent. Before you compare platforms, export your current URL list with its organic traffic and its inbound links and count the rows. That number, more than any feature table, tells you whether moving is worth it.

Two rules make a migration survivable. Decide the new URL structure before you build anything, because retrofitting it means doing the redirect work twice. And keep the old URLs resolving for at least a year, since links and bookmarks outlive crawls.

Questions about choosing a CMS for SEO

Which CMS is best for SEO?

The one that gives you the eight controls above and that your team will actually publish on. A platform you can configure correctly and nobody uses loses to a simpler one that gets a page a week out of the door.

Do I need a separate SEO plugin?

Only to fill gaps. Check which of the eight controls the platform already gives you natively, then add one plugin for the rest. Two plugins that both write title tags will eventually disagree with each other.

Is a headless setup better for SEO?

It gives you the most control and it moves responsibility for every one of the eight controls onto your front end. Choose it when you have developers who will own that, and not for the architecture itself.

How do I test whether a platform renders text server-side?

Publish a page with a distinctive sentence, fetch the URL with a tool that returns raw HTML without running scripts, and search for the sentence. Present means pass. Do it on an article and on a listing page, because they are often built differently.

Will changing CMS hurt my rankings?

What hurts is losing URLs. Keep every address that has traffic or links resolving with a single 301 to its closest equivalent, keep the page content equivalent, and the platform change itself is uneventful.

How much of ranking is the CMS?

It sets the floor rather than the ceiling. A platform with the eight controls removes technical obstacles. What moves positions afterwards is what the pages say and who links to them.

One more thing the rendering test tells you

The check that matters most on this page has a second use that nobody mentions when platforms are compared. The same fetch that proves your text is in the HTML for a search crawler also proves it is available to the systems that assemble answers when a buyer asks an assistant who they should use. Those answers are built from documents that could be read, which means a page whose content arrives only after a script runs is missing from both conversations at once, and a platform decision made for convenience quietly decides whether you can be described accurately by something you do not control. It is worth asking the buying question in a couple of assistants after a replatform, with your own name left out of the prompt, and checking that the answer still has something of yours to work from. AI Knows Us reports which of your pages the five answer surfaces are drawing on, which is the only way to tell whether a migration lost you ground there as well as in search.