Quick answer: Website documentation is the set of records that lets you, your team or a future developer run, update and fix your site without depending on the person who built it. At handover you should receive: a list of every account and who owns it, hosting and domain details, access to the code repository, a list of themes, plugins and licences, notes on custom code and integrations, backup and deployment instructions, a content editing guide and clear support terms. Ask for it in your contract, not after launch.
Why documentation matters
Most business owners only discover missing documentation when something goes wrong. The developer has moved on, nobody knows the hosting password, a licence has expired, or a new agency spends days working out how the site was built before they can change anything.
Good documentation:
- Protects you if your developer becomes unavailable
- Makes it cheaper for anyone to maintain or extend the site
- Speeds up fixes during outages
- Helps your team edit content confidently
- Proves what you own and pay for
It is part of owning your website, not an optional extra. Our article on website ownership explains the wider issue.
The handover checklist
Use this list when agreeing a project and again at launch. Not every site needs every item, but each should be considered.
1. Accounts and access
A single document, stored securely, listing every account connected to the website:
- Domain registrar
- DNS provider, if different
- Hosting control panel and server access (SFTP or SSH)
- Database access
- CMS admin accounts
- Code repository
- CDN and security services
- Email sending services
- Analytics, Tag Manager and Search Console
- Payment gateways and third-party tools
For each, record who owns the account, which email address it is registered to and how access is shared. Accounts should be in your company’s name with your business email. Passwords should be shared through a password manager, not plain email. Our guide to domain security covers protecting the most important account of all.
2. Hosting and environment
- Hosting provider, plan and renewal date
- Server software versions, such as PHP and database version
- Environments: live, staging and any development copies, with their URLs
- SSL certificate type and renewal method
- Email settings and DNS records, such as MX, SPF and DKIM
- Caching and CDN configuration
3. Code and version control
- Location of the code repository and who has access
- Branch structure and what each branch is for
- How to set up a local copy of the site
- Build steps, such as compiling CSS and JavaScript
- Coding standards or conventions used
If your site’s code is not in version control, ask why. Our guide to website version control explains the benefits.
4. Deployment process
- How changes move from development to staging to live
- Who can deploy, and any approval steps
- How to roll back a bad release
- Any automated tests or checks
Our article on the website deployment process shows what a safe process looks like.
5. Theme, plugins and licences
For a WordPress or similar CMS site:
- Theme name, whether it is custom, a child theme or a third-party theme
- Every plugin, its purpose and whether it is free or paid
- Licence keys, renewal dates and the account each licence is registered to
- Plugins that must not be updated without testing, and why
- Any plugins that were modified, which is worth knowing because updates will overwrite changes
6. Custom functionality
For anything built specifically for you:
- What it does and where the code lives
- Custom post types, fields and taxonomies
- Shortcodes or blocks and how to use them
- Scheduled tasks and when they run
- Settings that control the feature
- Known limitations
7. Integrations and APIs
- Each connected system, such as CRM, email marketing, payment, booking or accounting
- What data moves, in which direction and how often
- Where API keys are stored and who owns the accounts
- What happens if the integration fails, and how errors are reported
Clear API documentation is especially important if you have custom APIs.
8. Forms and notifications
- Every form on the site and where submissions go
- Notification email addresses
- Spam protection in use
- Where submission data is stored and for how long
9. Analytics and tracking
- Analytics property and view IDs
- Tag Manager container ID and a summary of tags
- Goals and events set up, and what each measures
- Ad conversion tracking and pixels
- Consent or cookie tool settings
10. Backups and recovery
- What is backed up, how often and where backups are stored
- How long backups are kept
- How to restore, step by step
- When a restore was last tested
11. Security
- Security plugins or services in use
- Login protection, such as two-factor authentication
- Firewall rules
- Who to contact in a security incident
12. Content editing guide
A guide written for your team, not developers:
- How to add and edit pages, posts and products
- How to use page layouts, blocks and reusable sections
- Image sizes and formats to use
- How to update menus, footer and contact details
- What not to touch
Short screen recordings can be more useful than long written guides. Many developers also include a training session. Our article on WordPress client training covers what to expect.
13. Design assets
- Logo files in all formats
- Brand colours and fonts, with licence details for fonts
- Original design files
- Stock photo licences
14. Support and warranty
- What is covered after launch and for how long
- How to report problems and expected response times
- Hourly rates or care plan options for ongoing work
How to get good documentation
- Put it in the contract. List the documentation you expect as a deliverable.
- Agree a format. A shared document, a wiki or a folder in your company’s cloud storage, owned by you.
- Review it before final payment. Check you can log in to every account listed.
- Keep it updated. Every change to plugins, hosting or integrations should update the document.
- Store it safely. Access details should be in a password manager, and the document itself in a place you control.
A quick test of your documentation
Imagine your developer is unreachable tomorrow and your site goes down. Could another competent developer:
- Log in to hosting and the CMS within an hour?
- Find and restore a recent backup?
- Understand the custom code well enough to fix a bug?
- Renew every licence and service?
If the answer to any is no, your documentation has gaps.
FAQ
Is documentation usually included in a website project?
It should be, but the level varies widely. Agree what you will receive before work starts.
What if my current site has no documentation?
Ask your developer to create it, or have another developer review the site through a code audit and write it up.
Who should hold the passwords?
You should, in a password manager your business controls, with access granted to developers as needed.
Own your website properly
Good website documentation turns your site from something only one person understands into a business asset anyone can maintain. If you want a site that is built, documented and handed over properly, see how we help businesses turn visitors into customers.
