Build the public website. Make its publishing work clear.

A useful CMS brief identifies the information your team publishes: services, projects, articles, people or resources, with their important relationships. Bring representative entries and ordinary update tasks. We use them to choose the content model, templates and balance between reusable patterns and page-specific editing. A large set of controls is not automatically a better publishing system.

The engagement can include content and page planning, responsive design, WordPress or another selected CMS implementation, agreed forms or connections, initial content work and launch preparation. For an existing installation, we inspect the current theme, extensions and working functions before proposing changes. A migration also needs retained content, media, useful addresses and a reviewed transition.

The agreement names who supplies information, approves facts, prepares changes and makes them public. A small team may combine those responsibilities. The implementation should fit its actual routine instead of adding unnecessary approval machinery. Accounts, licences, technical maintenance and recovery remain explicit operating responsibilities after the editor receives the site.

For the hypothetical service and guide, the owner first approves what should be available together. Follow the actual visitor route in an appropriate public review arrangement. If the guide remains private, preserve that state and choose an accurate interim treatment or hold the service page. Making an unfinished document public merely to remove a broken step would bypass the content decision.

This is a content-model and publishing task within a website build. It differs from diagnosing a scheduled process that failed to publish an already approved article, and from migrating two existing resource editions into a new site. The handover should let the editor repeat the chosen readiness check without having to infer which linked entry is available to whom.