Documentation your business should have about its own website
If your partner vanished tomorrow, what would the next one need? The one page every business should hold, and who keeps it current.
The short answer
Every business should hold one page that describes its own website well enough that a competent stranger could take it over in a day. Where everything lives, how changes reach the site, which services are involved and what they cost, who has access, what recurs and when, and who to call. The partner writes and updates it, because they make the changes. The business owns it, stores it where it can be reached without the partner, and reads it once a quarter. It is the cheapest insurance in the whole digital setup, and it is the thing that does not get written.
What goes on the page
| Section | Contents |
|---|---|
| The site | Domain(s), what the site is built with, where the code repository is and who owns it |
| Hosting and network | Platform, account name and owner, DNS provider, network layer, certificate handling |
| Deployment | How a change goes from edit to live: repository, branch, preview, approval, production; how to roll back |
| Services | Every third-party service the site depends on: forms, email sending, analytics, search, payments, CRM, with account owner and cost |
| Access | Who has access to what, at what level; where credentials are kept (never the credentials themselves) |
| Recurring | Domain renewal dates, certificate handling, subscriptions and their renewal dates, backup schedule and location, restore test schedule |
| Monitoring | What is monitored, who receives alerts, where the dashboards are |
| Contacts | Partner, the escalation arrangement where one exists, provider support channels, internal owner |
| History | Launch date, major changes, known quirks, last updated date |
Keeping it current
- The partner updates it with every change that touches the setup: a new service, a moved account, a changed deploy path.
- The date at the top changes whenever it does, so staleness is visible.
- The business stores the current copy in its own document storage, not only in the partner’s tools.
- Someone inside reads it quarterly and tries one thing: logs in somewhere, finds a renewal date, opens the monitoring dashboard.
- At every hand-over, in either direction, the page is the checklist.
The one-day test
Hand the page to a developer who has never seen the site and ask them to describe, from the page alone, how they would make a text change and deploy it, what they would do if the site went down, and when the domain renews. If they can answer all three, the page works. If they cannot, the missing answers are what to add.
What this means for you
One page, nine sections, owned by you and maintained by your partner. It turns a developer’s departure into an afternoon’s work, a hand-over into a checklist, and an outage at night into a lookup rather than a search. Ask for it, store it yourself, read it quarterly, and test it once against a stranger. It is the smallest document with the largest effect on continuity.
Frequently asked questions
Is this not the partner's job to keep?
Writing and updating it is the partner's job. Owning it is yours. Keep the current copy in your own storage, not only in the partner's systems, and read it once a quarter. A document you cannot reach on the day you need it is not documentation.
How technical does it need to be?
Readable by a business owner, useful to a developer. Names, locations, links and short descriptions, not code. The developer who takes over will find the technical detail in the repository; what they cannot find there is where the domain is, who holds the analytics, and how deploys happen.
What about passwords?
Never in the document. The document says where credentials are kept, in a password manager the business controls, and who has access. Credentials themselves live only there.