How to Evaluate a CMS: Beyond the Marketing Page (2026)

CMS marketing pages are designed to make you sign before you ask the questions that matter. "Trusted by Fortune 500 companies." "Built for scale." "Enterprise-ready." Every CMS says this. None of it tells you whether the platform will fit your project six months from now.

This post is the buyer-skepticism guide for how to evaluate a CMS in 2026 — what marketing pages hide, the red flags to spot before booking a demo, what to demand in the demo itself, the questions vendors don't want to answer, and the 1-week trial that catches what every other step misses. TL;DR: evaluate the gaps in vendor materials more than the claims. Missing pricing pages, hand-wavy security pages, sparse changelogs, and "contact sales" gates on essential features are stronger signals than the headline copy. Real evaluation is one part marketing-page audit, one part demo grilling, one part hands-on trial — not one part demo and three parts vibes.

The audience: technical buyers in the CMS evaluation phase, non-technical decision-makers approving budgets, agency owners pricing platform recommendations. If you're already deep into headless or performance evaluation specifically, see the 10-point headless CMS evaluation checklist and CMS performance benchmarks: what to test. This post is the meta-question — how do I know if any CMS is good?

What Marketing Pages Actually Tell You

CMS marketing pages tell you three things consistently:

1. What the vendor wants you to think the product is — usually a list of buzzwords (composable, real-time, enterprise, AI-powered) that don't constrain the product's actual capabilities
2. Who the vendor wants for customers — implied by the case studies (logos of large brands → enterprise; logos of agencies → SMB-and-up)
3. What the vendor will charge if you ask — sometimes on the page, often hidden behind "contact sales"

What they don't tell you, almost universally:

• The actual feature gaps versus competitors (every CMS has them; no marketing page admits which)
• The pricing tier where you'll actually land in year 2 (always higher than the entry tier the page emphasizes)
• The migration cost off the platform (none)
• Which features were promised at launch but haven't shipped (the roadmap pages get sparse fast)
• The last 12 months of customer churn (not on the marketing page)
• The real performance numbers under realistic load (almost never)

Reading marketing pages well is a matter of treating the page as evidence about the vendor, not evidence about the product. A clear pricing page tells you the vendor is comfortable with their numbers; a "contact sales" pricing page tells you they're not. A detailed changelog tells you the team ships regularly; a missing changelog tells you they probably don't. A specific case study with metrics tells you the vendor is confident; a glossy logo wall with no metrics tells you they're not.

For broader context on what makes a CMS actually good (not just sound good), see what makes a CMS developer-friendly and WordPress vs modern CMS: honest feature comparison.

Red Flags on Vendor Pages

Specific things that should make you slow down or walk away:

1. No public pricing page.

"Contact sales for pricing" usually means: pricing varies by negotiation, the vendor extracts what each customer can pay, and the contract terms are not standardized. This is fine for genuine enterprise products with custom contracts. It's a yellow flag for anything you'd otherwise expect to self-serve. If a small-team CMS hides pricing, the bill is usually higher than you'd guess.

2. Pricing page exists but the relevant tier is "custom."

Three tiers visible, and the one you actually need is "Enterprise — Contact Us." This pattern hides the real cost from you while signaling to investors that the company has high-ARPU customers. Translation: the entry tier is loss-leader marketing; the actual product lives in the custom tier.

3. No public changelog or release notes.

A CMS shipping monthly updates publishes a changelog. A CMS not publishing a changelog usually isn't shipping monthly updates. Check vendor docs, GitHub releases (for OSS), or a "What's new" section. If the most recent entry is 8 months old, the platform is in maintenance mode regardless of what the homepage says.

4. Sparse, copy-paste documentation.

Open the docs. Pick a specific feature. Read 5 pages. Are they detailed, well-structured, with code examples, or are they three paragraphs of marketing prose with a "Get started" button? Sparse docs usually mean the product is sparse — and the support team will be your only path past the basics.

5. "Enterprise" gates on essential features.

RBAC, SSO, audit logs, content history, multi-environment, basic API access — these should be on every tier. CMSes that gate them behind Enterprise tiers are pricing them as upsells. That's a vendor strategy, but you should know going in: the entry tier is for evaluation, not production. Strapi has done this with content history; Contentful with locale tiers.

6. Marketing page doesn't mention competitors.

Confident vendors compare themselves to alternatives directly. Vague vendors ("the leading CMS for...") avoid naming competitors because the comparison wouldn't favor them. A marketing page that names 3-5 competitors and explains the trade-offs is more trustworthy than one that pretends competitors don't exist.

7. Customer logos with no case studies behind them.

A "trusted by" wall with logos of brands you recognize, none of which link to a case study, usually means: the brand uses the CMS for one small project that didn't go to production, or the brand was a free pilot, or the logo is misappropriated entirely. Real case studies have metrics, named contacts, specific use cases. Wallpaper logos don't.

8. "Built for AI / AI-native / AI-first" without specifics.

2026 marketing leans hard on AI buzzwords. The honest signal: which specific AI integrations work today, with which models, with what cost? "AI-native" without specifics is brand positioning; "MCP server with X tool, Y tool, Z tool" or "OpenAI Function Calling integration with these endpoints" is product.

9. Self-hosted option claimed but undocumented.

A CMS that says "self-hosted available" but has 3 lines of self-host docs is not really self-hostable. Real self-hosting means: clone the repo, set env vars, run with Docker or PM2, with documented backup and migration paths. If the docs assume you're using their cloud, the self-host claim is marketing.

10. Footer says "Made with [their own product]" but the website performance is bad.

Run PageSpeed Insights on the marketing site. If the CMS vendor's own website doesn't pass Core Web Vitals on a marketing site they fully control, the platform's performance ceiling is suspect. This isn't always damning (small teams running a marketing site differently from production), but it's a signal worth checking.

For specific platform-level red flags by category, see hidden costs of WordPress: what you actually pay — it covers a different but related angle on the cost-vs-marketing gap.

What to Demand in a Demo

Sales demos are designed to make the product look easy. The buyer's job is to make the demo show the things that actually matter for the project. Don't accept the canned demo path.

Demand 1: Build a custom content type live.

Marketing pages all say "model any content type." Make the demo person actually do it. "Show me how to model an event with a recurring schedule, a venue reference, and an attendee count." If they need to call engineering or "follow up after the call," the content modeling story is weaker than the marketing page implied.

Demand 2: Show a schema migration.

"How do I add a field to an existing content type? Show me on a live system." Watch the workflow. Is it admin-UI clicks (good for non-technical, bad for code-as-config)? Code-based with a CLI command? Manual SQL? Each approach has trade-offs; the demo should reveal which one you're getting.

Demand 3: Run a performance test.

"How fast is the public site for a typical post? Pull up PageSpeed Insights on a live customer site." The demo should produce a real LCP, INP, and CLS number. If the demo person says "it depends on hosting" or "we don't have customer sites we can share," that's the answer — performance varies wildly across customer implementations and the vendor doesn't have a standard story.

Demand 4: Walk through the editor preview workflow.

"I'm editing a post. How do I see what visitors will see before publishing?" Watch them set up draft mode, generate a preview URL, share it with a teammate. If preview requires re-auth or doesn't work for non-logged-in reviewers, the editorial workflow is broken in a real way.

Demand 5: Show the content export.

"I want to leave your platform tomorrow. How do I get all my data out?" The answer reveals the lock-in story. A CLI command that exports JSON or NDJSON is the right answer. "Reach out to support and we'll arrange it" is a yellow flag.

Demand 6: Show admin performance under realistic content volume.

"Pull up the admin for a customer with 5,000+ posts and show me the post-list page load time." Most vendor demos use a sample dataset of 20-50 records. Real production scale is usually 50-100x that, and admin performance often degrades non-linearly. If the vendor can't show a high-content-volume admin, the scaling story is unverified.

Demand 7: Show a real customer reference.

"I'd like to talk to a customer with a similar use case to ours. Can you connect me?" Vendors with strong references make these introductions; vendors with weak references slow-walk them or offer "case studies instead." The willingness to connect customers is itself the signal.

If the demo person can't or won't do these, the demo isn't useful — and that's data. Either book a follow-up demo with someone technical, or move on. For the broader evaluation framework that includes these tests as part of the scoring, see how to choose a headless CMS: 10-point checklist.

Questions to Ask the Vendor

Specific questions, with what the answer tells you:

1. "What's the migration path off your platform?"

A confident vendor names the export format and links to a migration guide. A weaker vendor talks about partner agencies that handle migrations or offers vague reassurance. The migration story directly translates to lock-in cost — see the framework-agnostic CMS migration guide for developers for what real migration work looks like.

2. "Show me your sub-processor list."

Required disclosure for any CMS handling personal data under GDPR. The list should include all infrastructure providers (AWS, GCP), CDN providers (Cloudflare, Fastly), email providers (Sendgrid, Postmark), search providers (Algolia, Meilisearch), and third-party tools that touch customer data. If the vendor can't produce this list, they don't have a mature compliance posture. See self-hosted CMS and GDPR: data sovereignty in 2026 for the compliance angle.

3. "What's your release cadence for the last 12 months?"

Tied to the changelog question. A platform shipping 1-2 releases per month is actively maintained. One release every 4-6 months means slower velocity. Quarterly releases for a serious CMS are concerning at this stage of the market.

4. "What features were promised in the last 18 months but haven't shipped?"

An honest vendor names 1-3 specific features. A defensive vendor pushes back. The honest answer is more trustworthy — every roadmap has slip; vendors who pretend otherwise are hiding something.

5. "What's your highest-churn customer segment?"

A senior account executive will know this. Not an exact number, but the shape: "We see churn from teams who outgrow our pricing tiers" or "Self-hosted customers who underestimated ops cost" or "Smaller teams who didn't have engineering capacity." Each answer tells you which customer segment to be careful about. If the answer is "we don't have churn problems," that's marketing — every product has churn.

6. "Walk me through your last critical security incident."

Every platform has had one. The question is how they handled it. Detailed disclosure (CVE, response timeline, customer notification, fix) signals mature security. "We don't discuss specific incidents publicly" is a yellow flag — incident transparency is part of mature security.

7. "What's the typical time-to-launch for a customer in our segment?"

Vendor-cited launch times are usually optimistic by 2-3x. Ask for the average, not the fast cases. Compare to your own timeline; if you're trying to launch in 6 weeks and the vendor's average customer takes 14 weeks, you'll either compromise scope or miss your date.

8. "Can I see your last quarterly all-hands or town hall?"

Cheeky, but informative. Vendors who share internal updates (or a public version) signal transparency. Vendors who decline reveal the boundary of how much they want customers to see.

How to Read the Docs Honestly

Documentation is the most reliable signal in CMS evaluation because it shows what the team actually built, not what marketing wishes existed. Read the docs with two questions in mind: what's covered well, and what's missing?

Signs of healthy docs:

• A real "Getting Started" path from zero to deployed in under an hour
• Code examples for every API endpoint, not just curl examples
• Detailed migration/upgrade guides between versions
• A search bar that returns useful results
• Last-updated timestamps on each page (not 2 years old)
• A clear distinction between stable APIs and experimental ones
• A "concepts" or "architecture" section that explains the why, not just the how

What's missing tells you more:

• No troubleshooting section → vendor expects support tickets, not self-service
• No "limitations" or "known issues" page → either the team is hiding rough edges, or they don't track them publicly
• No comparison page ("X vs alternatives") → vendor avoids competitive framing
• No examples for your specific framework → integration is harder than the marketing implies
• No section on operating in production (monitoring, scaling, backups) → not a production-ready story
• Pricing-related features mentioned but not documented ("Available in Enterprise") → those features may not actually exist yet

The docs-density test: pick a moderately-complex feature you'll need (custom field types, webhooks, draft preview, RBAC). If the dedicated docs page is shorter than 500 words and has no code, the feature is half-finished. Real production features have 2,000-5,000 word docs pages.

For the related question of what good developer experience looks like in docs and code, see TypeScript-first CMS platforms: why type safety matters and what makes a CMS developer-friendly.

How to Read GitHub Activity (For Open-Source CMSes)

For self-hostable or open-source CMSes, GitHub is the most honest signal you'll get. The marketing page can lie; the issue tracker can't.

Healthy signals on a CMS repo:

• Commit cadence: 5+ commits per week, multiple contributors
• Issue close rate: more closes than opens over a 90-day window
• Response time on new issues: under a week for most, under 48h for security/critical
• Releases tagged regularly: monthly or every 6 weeks; not 8-month gaps
• Labels and triage: issues are tagged (bug, enhancement, documentation), not just sitting in a giant unlabeled pile
• Pull requests merged from outside contributors: the team accepts community work, not just employee work

Red flags on a CMS repo:

• 500+ open issues with no recent activity
• Issues from 2+ years ago still labeled "needs triage"
• Releases tagged but with sparse changelog ("Various fixes and improvements")
• All commits from 2-3 employees, no community PRs merged
• Discussions tab or issue tracker dominated by support questions, not development
• Security-tagged issues that sit open for weeks or months

Specific things to look for:

• Search the repo for "TODO" and "FIXME" — every codebase has them, but the count and age tell you about technical debt
• Check the contributors page — are commits concentrated in one or two maintainers? That's a bus-factor risk.
• Read the last 5 closed bug reports. Are the responses helpful? Is the fix linked? Or do issues close as "won't fix" with no explanation?

For platforms that aren't on GitHub (proprietary SaaS), the equivalents are: status page incident history, support response time data, public roadmap (if any), and community Discord/Slack activity.

The 1-Week Trial: What to Test Before Signing

Marketing pages, demos, docs, and GitHub activity narrow the field to 1-2 candidates. The 1-week trial answers the final question: can my team actually use this thing?

Set aside 4-6 hours per day for 5 working days. The schedule:

Day 1 — Setup and content modeling.

• Spin up a fresh instance (cloud or self-hosted, whichever you'll use in production)
• Define your 3 most complex content types in their actual modeling workflow
• Add 50-100 test records via the admin
• Goal: prove content modeling matches the marketing claim

Day 2 — Frontend integration.

• Connect a real frontend (Next.js, Astro, your stack of choice)
• Build a real page that consumes content from the CMS
• Implement draft preview for at least one page type
• Goal: prove the API and frontend integration work in your stack

Day 3 — Editor experience.

• Hand the admin to a non-developer on your team for 30+ minutes
• Have them create a post with a featured image, edit it, schedule it, and check it
• Note every friction point
• Goal: validate the editor will actually use the platform

Day 4 — Performance and operations.

• Run k6 or Apache Bench against your test instance with realistic content volume (see CMS performance benchmarks: what to test)
• Set up backups and verify restore
• Check the admin under load (does it stay responsive while the public site is hit?)
• Goal: confirm production readiness for your traffic level

Day 5 — Migration and exit.

• Use the export tool to dump all content
• Verify the export includes media URLs, references, and timestamps
• Try importing into a fresh instance from the export
• Goal: validate the lock-in story matches the demo answer

What the 1-week trial catches that nothing else does: the integration friction in your specific stack with your specific team. Marketing demos use the vendor's reference architecture; real projects use your architecture. The friction shows up in days 2-3 every time.

If you can't get 5 working days for the trial, do at least days 1, 2, and 3. The skip-to-Day-5 quick test (export and re-import) is also extremely informative on its own.

For the broader buying-decision framework, see the 10-point headless CMS checklist for headless evaluation, and the framework-agnostic CMS migration guide for developers for the export-side validation.

What to Do About It

If you're evaluating a CMS for a real project:

1. Audit the marketing page first. Note red flags before booking the demo. Confront the demo person with your concerns directly.
2. Demand the live demo tasks above. If the vendor can't or won't do them, that's data.
3. Ask the 8 vendor questions. The answers (or evasions) tell you what kind of vendor relationship you're signing up for.
4. Read 20+ pages of docs deeply. Look for what's missing — that's where the project will hit walls.
5. Check GitHub activity for OSS candidates. Skip platforms with stale repos.
6. Run the 1-week trial. Don't skip this — every team that skipped it and signed regretted it within 6 months.

If you're evaluating UnfoldCMS specifically, pricing is public, the demo follows the live-task pattern above, and we'd rather have you talk to existing customers than read polished case studies. We're transparent about being a young CMS — small ecosystem, public API still on the roadmap, plugin marketplace not yet at scale. The architecture (Laravel + React + shadcn/ui as one deployable artifact) fits Laravel-and-React shops; for everyone else, the linked posts above point at better-fit alternatives.

For the broader CMS-evaluation framework that includes this post as one input, see WordPress vs modern CMS: honest feature comparison and headless CMS vs traditional CMS: key differences.

FAQ

How long should a CMS evaluation take?

For a real project: 2-4 weeks total. Allocate 3-5 days for marketing-page audit and demo scheduling, 4-6 hours per candidate for hands-on testing, 1 week of trial use on your top pick, and time for the content team to actually try it. Teams that compress this into a single afternoon end up replatforming within 18 months. The migration cost dwarfs the evaluation time savings.

What's the most important thing to check before buying a CMS?

The export and migration story. Every other dimension is reversible if you can get your data out — performance can be tuned, schemas can be migrated, hosting can be upgraded. Lock-in is the dimension that costs months of work to fix. Always test export and re-import before signing a multi-year contract.

How do I know if a CMS vendor is in financial trouble?

Signals: pricing tier changes (especially upward), recent layoff news, slowing release cadence, founder departure, acquisition rumors. None are deal-breakers individually; the pattern across 2-3 of them is. Public companies (Contentful before going private) have SEC filings; private companies require more detective work via Crunchbase, LinkedIn, and trade press.

Should I trust customer case studies on vendor websites?

Partially. Real case studies have specific metrics (TTFB improvements, conversion lifts, content velocity) and a named contact. Logo-only "trusted by" walls aren't case studies — they're brand wallpaper. Cross-reference any case study with the customer's actual website (does it run on the claimed CMS? does the LinkedIn of the named contact still exist there?). Real customers are happy to give 30-minute reference calls; logo-only customers usually aren't reachable.

How do I evaluate an open-source CMS that doesn't have a vendor?

GitHub activity becomes the primary signal. Active commit history (5+ commits per week, multiple contributors), responsive issue triage, regular tagged releases, healthy PR-merge rate from outside contributors. The vendor questions become "ask the maintainers via GitHub Discussions or Discord" — which themselves test the project's community responsiveness. Open-source CMSes without active maintainers are riskier than vendor-backed CMSes; the savings on license cost are wiped out by the bus-factor risk.

Is a 1-week trial really necessary?

Yes for any project that'll live more than 12 months. The trial catches integration friction that demos hide and that docs don't reveal. Every CMS demo looks easy; integration in your specific stack with your specific team is where reality shows. Skipping the trial saves 4-6 days; switching CMSes 6 months in costs 4-6 weeks. The math is obvious once you've done a forced re-platform once.

Sources & Methodology

This post draws on:

• First-hand evaluation projects — UnfoldCMS team has run CMS evaluations across multiple migrations from 2024-2026. The red-flag patterns and demo demands reflect what we actually use.
• Vendor pricing pages, docs, and GitHub repos — checked May 2026 for the linked patterns (Strapi, Contentful, Sanity, Payload, DatoCMS, Storyblok, Hygraph, WordPress)
• Migration project retros — patterns in why teams regret CMS choices, drawn from post-mortems on real switching projects
• Stack Overflow Developer Survey 2024-2025 — for context on what developers actually use vs what marketing claims dominate
• GitHub Insights data — for the issue close rate, contributor diversity, and release cadence baselines

Disclosure: this post is on a CMS vendor's blog. The framework is intentionally vendor-agnostic — every red flag, demo demand, and vendor question applies regardless of platform. UnfoldCMS itself fails some of these tests (small ecosystem, public API on the roadmap not shipped, sparse plugin marketplace) — we say so on our own pricing page and demo. The honest evaluation method works against us as much as for us; that's the point of writing it.

For deeper coverage of any single dimension, see the linked posts. For the headless-specific evaluation framework, the 10-point headless CMS checklist. For the performance-specific benchmarking guide, CMS performance benchmarks: what to test. For the cost-specific accounting, hidden costs of WordPress: what you actually pay.