CMS options — decision deferred
Reviewed 2026-09-07 against public site evidence and official product documentation. No framework, CMS, paid plan, or hosting has been selected or installed.
Evidence driving the decision
The current site publishes structured service information, dentist/team profiles, a substantial blog, promotions, a savings plan, gallery media, shared practice details, and policy pages. Public asset paths identify WordPress and several plugins, but staff familiarity with WordPress is unknown. No source/export access is available, so a same-CMS choice does not automatically make migration easy. Appointment and contact handling are unresolved separate requirements.
The key comparison is staff usability and enforceable publishing permissions versus recurring service cost and technical maintenance. A modern public site does not itself require a headless CMS or custom login system.
| Option | Fit for this practice | Permissions and review | Maintenance / migration implications | Decision gate |
|---|---|---|---|---|
| Managed WordPress with a restrained editor and rebuilt theme | Fits existing articles, pages and media; could be familiar if staff already use it | Core roles/capabilities and revisions exist. Default Editor is broad; a page-editing draft-only role and clinical review workflow need explicit configuration/customization | Hosting support can reduce operational work, but theme/plugin updates, backups and staging still need ownership. Public HTML is not a WordPress export. Avoid carrying the entire observed plugin stack forward without need | Demo page/media editing, staged edits to already-published pages, approval, rollback and server-side role enforcement; establish responsible maintainer |
| Sanity with structured editing and a separately rendered frontend | Strong candidate for shared practice settings, services, staff records and reusable content; frontend implementation remains a separate choice | Managed roles; custom roles are documented as Enterprise. Required role granularity may determine plan cost | Removes database hosting from practice operations; schemas, preview, frontend deployment and integration glue still need a developer. Rebuild/import content from approved source inventory | Verify affordable plan covers actual publisher/editor/reviewer separation, preview privacy, history, backups/export and seat needs |
| Payload with a custom admin configuration and separately planned delivery | Candidate when code-controlled content types and fine-grained permissions are worth developer ownership | Access-control functions and configurable versions/drafts support tailored permissions; approval lifecycle must be designed and verified | More control but practice/developer must own deployment, database, storage, backups, upgrades and authentication operations. Do not choose solely because it is JavaScript/TypeScript | Named long-term technical owner, realistic maintenance budget, authenticated-preview design, tested role rules and recovery |
These are qualitative assessments, not measured usability results. Do not award a winner before staff try the same representative editing scenarios. A plain static site with code-only edits does not meet the confirmed staff-maintenance requirement without an additional editing workflow. A custom-built CMS has no demonstrated need at this point.
Proposed evaluation criteria
Weights are assumptions for the office manager to revise: staff editing/preview 25%, authorization/approval 25%, total ownership effort and cost 20%, content/SEO migration 15%, recovery/export 10%, integration fit 5%. Security requirements are pass/fail gates, not tradeable points. No numeric scores are assigned because there has been no hands-on CMS trial.
Run the same tasks in the two best candidates after requirements are agreed: update hours, change a portrait, draft a clinical edit, block unauthorized publication, approve/publish, restore a revision, expire an offer, export content, and revoke a departed editor's access. Check draft edits to an already-published page, not just creation of a new draft. Include accessible editor use and mobile preview. Use synthetic content; this is a later discovery experiment, not replacement-site construction.
Compare full recurring cost: editor seats, role/SSO feature tier, hosting, media/storage/bandwidth, backups, preview/staging, developer support, monitoring and integration fees. Obtain current quotes only after seat count and workflow are known; no pricing claims are made here.
Official references
- WordPress roles and capabilities — predefined roles can be customized; Contributor cannot publish posts, while Editor can publish/manage content. This does not by itself implement the proposed clinical review process.
- WordPress revisions — revision comparison/restoration.
- Sanity roles — managed permissions, default roles by plan, and Enterprise custom roles. Verify plan eligibility during selection.
- Payload access control — document/admin access rules.
- Payload versions and drafts — configurable version history and draft/publish behavior. Framework capabilities still require a correctly implemented permission model.
Patient-data handling, contracts, consent and operational controls require separate requirements review. Selecting any of these CMS products does not establish legal compliance or make the CMS an appropriate patient records system.