Choosing a CMS for multiple websites starts with an architectural question: what should be shared, and what must remain independent? A chain of regional offices may want one design system with local addresses and editors. An agency hosting unrelated clients may value separate backups, access controls and handover more highly. A single dashboard does not automatically provide either outcome.
Compare three operating models
A shared installation can serve several sites from common application code. Updates and reusable components are easier to coordinate, but a faulty shared extension or underlying service may affect every site. Ask which configuration and data belong to each site and whether one site can be restored or exported separately.
Independent installations allow teams to use separate update schedules and contain some failures, but increase the number of environments that need monitoring, patching and backups. Separate installations are not necessarily isolated if they share powerful credentials, infrastructure accounts or an unrestricted database.
A management dashboard over separate installations can centralize updates and status reporting. Treat its administrator account as a high-value target: find out what actions the dashboard can perform, how access is protected and how to disconnect it without losing access to the sites.
Define the boundaries first
Make a small inventory before attending a demo. For each site record its owner, domains, editors, languages, integrations, data categories and expected recovery time. Mark shared content, local overrides, common templates and exceptions. This gives you a test plan rather than a wish list.
For a five-branch business, try this exercise: publish a centrally managed policy, allow each branch to edit only its own address, and then update the central policy. Does the local address remain intact? Can editors preview the result? What happens when a branch has an approved exception?
For an agency, use a different test: invite one client as an editor, confirm they cannot see another client's drafts or customer information, then remove their access. Test with actual low-privilege accounts rather than assuming that a role name means the right permissions.
Domains, content and search settings
Check whether the architecture supports the domain patterns you need and how HTTPS certificates and redirects are managed. Make a map of old and new URLs before migrating, including individual pages and assets. Test each site, not just the first one in the dashboard.
Shared templates save work but changes can have a wide impact. Ask for site-specific previews, version history, rollback and a way to handle local exceptions without copying an entire theme. Establish who approves changes to shared components and which sites receive them.
Each site needs a deliberate search configuration. Check page titles, descriptions, indexability, sitemaps and the actual URLs rendered in published HTML. If substantially similar material appears across domains, determine which version should be primary and make each local page useful to its own audience. Canonical URLs are signals to search engines, not guarantees. For different languages or regions, plan and verify the relationships between corresponding pages.
Backups are only useful if they restore
Ask how application files, database contents and configuration are backed up together. Can a team restore one site without rolling back the others? Where are copies stored, who can access them, and how long are they retained?
Run a recovery exercise in an isolated test environment. Restore a representative site, inspect content and media, and test forms with real notifications disabled. Record the elapsed recovery time and the amount of data that might be lost since the last backup. Compare the result with the service expectations of the site owner.
Plan updates in the same practical way. Inventory shared and site-specific extensions, test a representative sample of site types, and decide who can approve rollout. Check critical paths after updating and document a rollback procedure. A staging site is only useful if it reflects the configurations that matter in production.
Security and costs
Check how users, API credentials and data are scoped. Ask what an attacker who compromises one editor account or extension could reach under the proposed configuration. Require an answer tied to the deployment rather than a generic promise of isolation. Use appropriate administrative access controls, logging and multi-factor authentication where supported.
Estimate traffic and resource requirements from actual usage patterns, not simply the number of domains. A campaign on one site may compete for shared capacity. Agree on monitoring and test expected peaks in a suitable environment.
Calculate the whole operating cost: initial setup and migration, hosting, licenses and extensions, updates, monitoring, backups, recovery drills and support. Ask how costs change as sites and editors are added. Also ask how to export content and move a single site elsewhere.
A practical evaluation checklist
- List sites and owners, and identify shared versus local data.
- Test role boundaries with real low-privilege accounts.
- Publish a shared component, add a local override and test the next update.
- Verify domain, redirect, SEO and indexing settings per site.
- Restore a representative site and time the exercise.
- Test a site-specific integration and document ownership of credentials.
- Compare exit options and total ongoing costs.
The best fit is the model that meets your actual isolation, publishing and recovery requirements within the team's operating capacity. A network of related branches and a portfolio of unrelated client sites can reasonably reach different conclusions.
Originally published in Russian: https://morlix.ru/blog/cms-dlya-upravleniya-neskolkimi-saytami-na-chto-smotret
