How to keep a website useful after the person who built it leaves

Treat the handover as a continuity project

A website can look finished while depending on one person’s memory. The builder may know where the domain is registered, which service sends form messages, how a booking integration works and which parts of the site should not be edited. If that knowledge leaves with them, the business inherits a fragile system even when the pages still look good.

Start the handover before the relationship ends. Ask for a clear inventory, a walkthrough and time to test the information. The goal is not to preserve every implementation detail. The goal is to make sure the business can keep the website online, answer enquiries, update important information and recover access when something goes wrong.

Create one shared handover document with an owner and a review date. Separate facts that must be verified from recommendations that may change. Record the date of the last successful check, not just the date the document was written. This turns a one-time transfer into a maintainable operating routine.

Transfer ownership before transferring tasks

List the domain registrar, hosting account, website platform, business email, analytics, search tools, payment services and every other system connected to the website. For each one, record the business owner, login method, renewal date, billing contact and recovery route. The business should control the primary account, while a supplier receives delegated access where needed.

Do not accept a shared spreadsheet full of permanent passwords as the final solution. Move credentials into a suitable password manager, enable multi-factor authentication and remove personal accounts that no longer need access. If a provider owns the domain or receives all recovery messages, resolve that before the contract ends. Ownership is especially important when the site, email or payment flow becomes urgent.

Check that the legal business name, billing details and recovery email are current. Confirm who can change DNS, publish content, install extensions, export data or invite new users. A handover is incomplete if the business can log in but cannot perform the actions required to keep the site running.

Document the website’s working parts

Ask the builder to explain the main structure in plain language. Which pages are central to customer journeys? Where are reusable sections, forms, media files and downloadable documents stored? Which parts are safe for a content owner to edit, and which changes require technical review? Screenshots can help, but written instructions should explain the reason behind important steps.

Make a content inventory with page names, purpose, owner, last review date and update frequency. Include legal notices, prices, opening hours, service descriptions, accessibility information and pages that receive search traffic. Note whether an item is edited inside the website, in a connected tool or through a code repository.

Document what happens after a visitor submits a form. Identify recipients, automatic replies, spam protection, CRM or spreadsheet connections, notification rules and failure alerts. Send a test enquiry and follow it through every step. This catches hidden dependencies that a list of URLs cannot reveal.

Check integrations, data and privacy

Create a simple map of data flows. A contact form may send personal information to email, a CRM, an appointment system and an analytics service. A shop may connect payments, fulfilment, invoicing and customer messages. Record why each integration exists, who owns the account and what happens when it fails.

Remove unused connections and confirm that active services still have the right permissions. Review API keys, webhooks, administrator roles and notification addresses. Ask whether the business can export important data in a usable format. Do not leave a critical integration attached only to a former builder’s account.

Update privacy information when the handover changes suppliers or data routes. Confirm that forms collect only what is needed and that retention, access and deletion processes are understood. Accessibility belongs here too: test keyboard navigation, headings, labels, contrast and error messages after any major handover change.

Test backups, updates and recovery

A backup is useful only if it can be restored. Record what is included, how often backups run, how long they are retained and who can retrieve them. Ask for a recent restore test or perform one in a safe environment. Include the database, uploaded files, configuration, domain details and any content stored outside the website platform.

Write down the normal update process. Include who reviews updates, where changes are tested, how a rollback works and what should be checked after publishing. The business does not need to become a developer, but it must know which changes are routine and which need specialist help.

Create an incident list with provider contacts, renewal information and escalation routes. Test access using a second authorised person. If the only recovery method leads to someone who has left, the handover is not finished. A short, rehearsed recovery plan is more valuable than a long document nobody can use under pressure.

Test the handover with a new owner

Give the documentation to someone who was not involved in building the site. Ask them to find the domain account, update a low-risk piece of content, send a test form, check analytics and explain how to report an outage. Their questions will reveal assumptions that the original team no longer notices.

Keep a list of gaps and assign each one to a person with a deadline. Do not wait for a perfect document before taking control of the most important accounts. Prioritise domain, hosting, email, forms, backups and privacy-related systems first, then improve the less urgent detail.

After the handover, schedule a quarterly review. Businesses change, staff leave and integrations are replaced. A useful website is not only one that works today; it is one the current team can understand, protect and improve tomorrow. ChatBuild can help turn this checklist into a clear website foundation and a manageable next step.

Sources

• Cybersecurity guide for SMEs: 12 steps to securing your business · ENISA
• Web Accessibility Initiative · W3C

Frequently asked

What should be included in a website handover?

Include ownership, account access, domain and hosting details, content responsibilities, integrations, backups, update instructions, privacy information, provider contacts and recovery steps.

Who should own the website accounts?

The business should own the domain, core website, hosting and important connected services. Suppliers can receive delegated access without controlling the business’s only recovery route.

Is a password list enough for a handover?

No. A useful handover also explains how the website works, which systems are connected, what can be changed safely and how to recover from an outage or failed update.

How often should handover documentation be reviewed?

Review it at least quarterly and whenever staff, suppliers, domains, integrations or important website processes change.