How to prepare website content for a staff handover

Preserve decisions, not just passwords

A handover that contains only logins is incomplete. The next editor needs to know which pages matter, who approves changes, where facts come from and what must not be edited casually. Start with the decisions behind the website. Why does a service page use that wording? Which claim requires a current source? Which form creates a task for another team?

Create a short map of the important journeys: finding a service, making contact, booking, paying or asking for support. Link each journey to its pages, forms and connected tools. This gives a new colleague a route through the system instead of a folder full of unrelated files.

Keep secrets in the approved password manager, not in the handover document. The handover should point to access procedures and owners while limiting unnecessary exposure.

Assign ownership by area

One person rarely owns everything. Separate editorial ownership, technical ownership, privacy review, analytics and customer follow-up. For each area, name a role or team, a backup and the decision they can make without further approval.

Describe ownership in practical terms. The service manager approves promises and pricing. The content editor checks clarity and links. The operations team confirms availability. The technical owner maintains forms and integrations. These boundaries prevent a new editor from guessing who must review a change.

Use shared addresses and team spaces where possible. A handover should not fail because the only owner’s personal account is unavailable. Check access before the outgoing person leaves and remove access that is no longer appropriate.

Record sources, review dates and exceptions

Important content needs a source and a review moment. Record where opening hours, prices, service areas, regulations, guarantees and team details are verified. A source can be an internal owner, official document or approved system. Avoid copying facts into a note without saying who keeps them current.

Add review dates based on change risk. A seasonal offer may need monthly review; a stable about page may need quarterly or event-based review. Mark exceptions: a page that must stay unpublished until approval, a form that should not be edited without testing or a translation that is updated separately.

The goal is not to put a date on every sentence. Focus on content that can mislead customers, affect compliance or change how work is delivered.

Explain publishing and rollback

Show how a change moves from idea to live page. Who drafts it? Where is it reviewed? How does someone preview it on a phone? Who publishes? What happens if a link, form or translation breaks?

Include a small release checklist: check title and headings, links, images, accessible labels, contact routes, forms, confirmation messages and connected records. For important changes, record the previous version or use the platform’s revision history. A new editor should know how to undo a mistake without panic.

Test on a realistic journey after publishing. A page can look correct while its form sends data to an old team or its booking link leads to a closed service.

Capture integrations and reporting context

List forms, calendars, CRM routes, analytics tags, consent tools, payment links and third-party embeds. For each, explain purpose, owner, destination and what to check after a content change. Do not assume the next editor can infer a connection from a button.

Explain the important reports briefly. Which conversion matters? Which events are known to be incomplete? When did tracking change? This stops a new owner from treating an unexplained number as a sudden business trend.

Document privacy-sensitive flows and approval needs. A content change can alter what data a form collects or where it goes, even when the visible page looks simple.

Make the handover a guided first task

Do not deliver the document and disappear. Ask the new owner to complete a small supervised task: update a safe sentence, preview it, check the linked action and record the change. This reveals missing access and unclear instructions while help is still available.

Keep a questions list and improve the handover. Remove details nobody uses, add explanations that were requested and schedule a review after the first month. A handover document is part of the maintenance system, not a one-time archive.

The best result is not a thick manual. It is a clear map of ownership, sources, routines and risks that lets the next person act safely and know when to ask for help.

Sources

• Content Strategy · Nielsen Norman Group
• Writing for Web Accessibility · W3C

Frequently asked

How much documentation is enough?

Enough for the next owner to find important pages, understand responsibilities, test changes and recover from a mistake. Keep details linked to real work and remove stale instructions.

Should the handover include all website pages?

Create a map of important journeys and link to the full inventory if needed. Prioritise pages whose errors affect customers, compliance or operations.

When should the handover be reviewed?

Review it after the first month with the new owner and whenever tools, responsibilities or major customer journeys change.