Start with the job your website has to do
Before you compare CMS platforms, write down the commercial job of the website.
For most B2B teams, the job is not publishing blog posts. The website has to help qualified buyers understand the offer, trust the company, move through product pages, compare options, book calls, and give sales better context.
That changes the CMS requirements.
A brochure site can survive with simple page editing. A serious marketing site needs structure. It needs rules. It needs a publishing workflow that keeps speed, SEO, design quality, and analytics intact as the site grows.
Start with these questions:
- Which pages influence pipeline?
- Which teams need to publish or edit content?
- Which page types repeat across the site?
- Which integrations touch the website?
- Which SEO fields and schema need editorial control?
- Which changes should marketing own without developer help?
- Which changes should stay in design and development hands?
That last question matters. Marketer control sounds good until the CMS gives everyone enough freedom to damage the site.
Requirement 1: structured content, not loose pages
A CMS should model the parts of the site your team reuses.
Loose page builders feel flexible at first. They also invite drift. One product page uses a different testimonial layout. Another has a broken comparison table. A landing page ships with missing metadata. The design system turns into a memory test.
Structured content gives the team safer building blocks.
For a B2B marketing site, that means defined content types for:
- Product or service pages
- Industries or use cases
- Case studies, when the team has approved proof
- Blog posts and guides
- Comparison pages
- Landing pages
- Authors
- Categories
- FAQs, where they belong
- Reusable calls to action
The point is not to make the CMS rigid. The point is to make common work repeatable.
When the CMS matches the website's real content model, marketers publish faster and developers spend less time cleaning up avoidable messes.
Requirement 2: page-building control with guardrails
Marketing needs room to build pages. The brand needs protection from accidental design decisions.
Good CMS requirements define both.
For example, marketing may need to:
- Add approved sections to a landing page
- Reorder blocks
- Edit copy and images
- Choose from approved calls to action
- Publish campaign pages without waiting on a sprint
They should not need freedom to change spacing, invent layouts, ignore accessibility rules, or override the design system on every page.
A maintainable CMS gives marketing controlled flexibility. The site still feels custom, but the editing system keeps the design intact.
That balance matters for Virdis-style custom websites. The CMS should not flatten a custom site into a generic template system. It should let the team operate the site without lowering the design bar every month.
Requirement 3: SEO controls editors can trust
SEO requirements belong in the CMS brief, not in a post-launch cleanup ticket.
At minimum, editors should be able to manage:
- Title tags
- Meta descriptions
- Open Graph titles and descriptions
- Social images
- Slugs
- Canonical rules where needed
- Indexing controls where needed
- Structured data fields for supported content types
- Redirect needs during migration
The CMS should also prevent common mistakes.
Editors should see missing required fields before publishing. Slugs should follow a clear pattern. Metadata should not disappear because someone duplicated a page. The system should make the right SEO action obvious.
This is where many CMS demos understate the real work. A platform may support metadata in a feature list. That does not mean your implementation gives editors a clean, reliable workflow.
Requirement 4: preview that matches production
Preview is not a nice extra for B2B teams. It protects revenue pages.
Marketing needs to see a page before it goes live. So do founders, product leads, and sales leaders when the page carries a core message.
A useful CMS preview should show the page close to production, including layout, responsive behavior, images, navigation, and key components. It should not ask non-technical editors to imagine what fields will become after the build renders them.
Preview matters most when your site uses structured content or a headless CMS. The editing interface and the website are separate. Without a strong preview workflow, editors work blind.
If the team publishes campaign pages, product updates, pricing changes, or migration-sensitive content, preview should be a hard requirement.
Requirement 5: roles and publishing workflow
CMS access should reflect how the team makes decisions.
A small founder-led team may need a light workflow: draft, review, publish. A larger marketing team may need roles for writers, editors, SEO, legal, product marketing, and developers.
Write the workflow before choosing the platform.
Ask:
- Who can create pages?
- Who can publish?
- Who can edit global components?
- Who can change SEO fields?
- Who can update navigation?
- Who approves high-value pages?
- Who owns redirects during migration?
The answer should shape roles, permissions, and approval steps.
Do not overbuild governance. A five-person team does not need enterprise ceremony. But do not ignore permissions either. One rushed edit to a navigation item, form embed, or product page can create real damage.
Requirement 6: integrations with the revenue stack
A B2B website does not run alone.
The CMS may need to work with:
- CRM forms
- Marketing automation
- Analytics
- Tag management
- Customer data tools
- Search tools
- Personalization tools
- Documentation systems
- Product-led signup flows
- Support or chat tools
List the integrations before platform selection. Then decide which integrations need native CMS support, which need custom development, and which should live outside the CMS.
This prevents a common trap: picking a CMS for one convenient native integration, then discovering that the rest of the website needs custom work anyway.
For a custom site, the CMS should fit the technical architecture. It should not force the business into a weaker website just because one integration looked easy.
Requirement 7: analytics and attribution readiness
The CMS does not own analytics, but it can make tracking cleaner or harder.
Your requirements should cover how the site handles:
- Campaign landing pages
- Form locations
- CTA variants
- Page types
- Content categories
- Conversion events
- Thank-you pages or inline confirmations
- UTM preservation
- Script management rules
Marketing should know which pages and components contribute to pipeline. Developers should know where tracking belongs in the system.
If analytics requirements stay vague, the team ships a site that looks finished but cannot answer basic questions after launch.
A good CMS implementation gives the analytics setup enough structure to make reporting cleaner. It will not fix a weak measurement plan by itself.
Requirement 8: migration risk and content cleanup
If you are moving from another CMS, migration belongs in the requirements phase.
Before choosing the new system, map:
- Which pages move
- Which pages merge
- Which pages die
- Which URLs need redirects
- Which metadata needs cleanup
- Which content types need new fields
- Which assets need replacement
- Which old scripts or embeds should not come over
A migration is a chance to remove debt. Treat it that way.
Do not drag every old page into a cleaner CMS because it feels safer. Keep what supports buyers, search, sales, or customer education. Redirect or retire the rest with care.
The CMS requirements should include the migration workflow, not just the end-state platform.
Requirement 9: developer experience and maintenance
Marketing should care about developer experience because it affects future speed.
If the CMS is painful to model, test, deploy, or extend, the site gets slower to improve. Small requests become risky. New page types take longer. The team avoids useful changes because the system feels fragile.
Ask your development team:
- How are content schemas versioned?
- How are preview and production environments handled?
- How does the CMS fit the frontend stack?
- How are changes tested before release?
- How hard is it to add a new content type?
- How hard is it to move away later?
Those questions sound technical, but the business impact is simple. A maintainable CMS helps the site keep pace with the company.
Requirement 10: total operating cost
CMS cost is not the subscription price.
The real cost includes licensing, implementation, migration, training, support, developer time, integrations, redesign flexibility, and the cost of working around the wrong system.
A cheap CMS can become expensive if every meaningful change needs a workaround. A premium CMS can be wasteful if the team needs a simple publishing workflow.
Compare cost against the website's job.
If the site supports sales conversations, product education, paid campaigns, SEO, and conversion, the CMS deserves more scrutiny than a software bill.
A practical CMS requirements checklist
Use this list before you shortlist platforms:
| Requirement area | Questions to answer |
|---|---|
| Commercial role | Which pages support pipeline, trust, and buyer education? |
| Content model | Which page types, fields, and reusable content blocks does the site need? |
| Editing workflow | What can marketing edit without developer help? |
| Design control | Which choices stay locked to protect the design system? |
| SEO | Which metadata, schema, URL, and indexing controls must editors manage? |
| Preview | Can stakeholders review pages in a production-like view before publish? |
| Roles | Who can draft, edit, approve, publish, and change global content? |
| Integrations | Which CRM, analytics, automation, and product systems touch the site? |
| Analytics | How will pages, forms, CTAs, and conversion events stay trackable? |
| Migration | What content moves, merges, redirects, or gets removed? |
| Maintenance | How easy is the system to extend, test, and support? |
| Cost | What will the system cost to operate for the next three years? |
How to choose from the requirements
Once the checklist is written, platform choice gets clearer.
A traditional CMS may fit if the site is simple, the content model is basic, and the team values one familiar editing interface over custom architecture.
A headless CMS may fit if the site needs structured content, custom design, strong performance, reusable page sections, and cleaner integration with a modern frontend.
A visual builder may fit if speed and editor autonomy matter more than deep content modeling or custom system design.
The right answer depends on the work the CMS must support. The requirements make that work visible.
When to bring in a web partner
Bring in a web partner before platform selection if the CMS decision touches redesign, migration, SEO, analytics, or custom development.
That timing matters. Once a platform is chosen, the team tends to defend the choice, even when the requirements say it was the wrong fit.
A good partner will help define the content model, editing workflow, SEO controls, integration needs, and maintenance plan before the build starts. That work protects the site from expensive reversals.
Virdis builds custom websites around strategy, conversion, and long-term maintainability. For CMS decisions, that means choosing the system around the business job first, then designing the editing experience and technical architecture to support it.
