The Website Documentation Every Business Should Hold Itself

The afternoon test

Here is a reasonable way to check whether a business actually controls its own website, rather than merely having access to it: could you hire someone completely new tomorrow — a freelancer, an agency, an employee — and hand them everything they would need to keep the site running, in an afternoon, without waiting on a reply from whoever built it? For most small businesses, the honest answer is no. Not because anything is hidden or wrong, but because it was never written down anywhere except in one person's head or one person's inbox — and that person is not guaranteed to be reachable the day you actually need them.

This is not a checklist for firing anyone or ending a relationship under pressure. It is a small set of documents worth having regardless of whether the current arrangement is working fine, precisely because the moment you discover you need them is a bad time to start writing them from scratch.

Asset and account inventory

Start with a plain list: every system that has something to do with the website, and who owns the account it lives under. Domain registrar, hosting provider, the code repository, the database, analytics and search console properties, the email-sending service, the payment gateway, and any advertising or tag-management accounts connected to it. For each one, note the account owner — your business, by name, not an individual's personal login — and roughly what would break if that specific account became inaccessible.

This list does not need to be exhaustive on day one. It needs to exist, and it needs updating whenever a new service gets connected, which is usually the exact moment nobody remembers to do it — so it is worth treating as part of setting the service up, not a separate task saved for later.

Hosting and DNS topology

Write down, in plain language, where the site actually runs and how traffic gets there: which host, which server or plan, and — separately — where the domain's DNS records are managed, because hosting and DNS control are not always the same account and are frequently assumed to be. Note what the important records currently point to — the main domain, email, any subdomains in active use — so that if DNS ever needs rebuilding from scratch, it is not being reconstructed from memory or trial and error. A short written map of what points where is worth far more during an actual DNS problem than a general sense that "it is set up correctly somewhere."

The deploy process, written down

If the site involves any code at all — a custom theme, a plugin someone built, an integration with another system — write down how a change actually reaches the live site. Is it a file uploaded manually, a repository push that triggers an automatic deployment, a build step that has to run first? Where does that process run, and does it require credentials only one person holds? A business does not need to be able to perform a deploy itself for this to be worth documenting — it needs a new developer to be able to read the process and understand the mechanism within minutes, rather than reverse-engineering it from scratch or waiting for the previous developer to explain it over the phone.

Backup and restore procedure

This deserves its own short document rather than a single line in the inventory: where backups are actually stored, how often they run, and — critically — the exact steps to restore one, including who is authorised to trigger a restore. We have written a fuller breakdown of the questions worth asking to confirm a backup actually works rather than just exists in our piece on verifying backups actually restore, and a broader planning framework in our disaster recovery guide. The version worth keeping on file here is shorter: enough for someone unfamiliar with the setup to locate a backup and attempt a restore without guessing at the process for the first time during an actual emergency.

Third-party dependencies and their renewal dates

Most business websites depend on things that lapse if nobody renews them on time: the domain registration itself, an SSL certificate if it does not renew automatically, a plugin or theme licence, an API key for a payment gateway or mapping service, an email-sending domain's authentication setup. Each of these has an expiry or renewal date somewhere, and each one causes a genuinely avoidable outage when it lapses silently because the renewal reminder went to an inbox nobody checks anymore. A simple dated list — what expires, when, and who gets notified — turns a predictable event into a non-event.

Emergency contacts

A short list of who to actually call when something breaks outside normal hours: the current developer or agency, the hosting provider's support channel, whoever holds the domain registrar login, and anyone internally who needs to be told immediately if the site or a payment system goes down. This sounds obvious until the night it is needed and the honest answer turns out to be "I think it is saved in someone's old phone."

Where to keep this, and who should be able to reach it

None of this is useful locked inside one person's personal notes app or a folder only the outgoing developer can open. It belongs somewhere the business itself controls — a shared drive, an internal wiki, even a well-organised folder of documents — with more than one person able to access it, and a habit of updating it when something changes rather than treating it as a one-time exercise. If it includes any actual credentials, they belong in a proper password manager with controlled access, not typed into the document itself; a document that gets forwarded, printed, or shared more casually than a password vault will eventually put a credential somewhere it should not be.

Why this is what makes a business vendor-independent

None of this documentation makes a current developer, agency or host replaceable in the sense of being disposable — a good working relationship is still worth keeping. What it does is remove the specific dependency that turns an ordinary business decision — change providers, negotiate a better rate, deal with someone leaving — into a crisis, because the knowledge needed to keep operating was never actually held by the business in the first place. A business that could hand this over in an afternoon has a real choice about who it works with. A business that cannot has already made that choice, whether it meant to or not.

A reasonable place to start

None of the six documents above needs to be polished or complete to be useful — a rough, honest version of each is worth more than a perfect one that never gets written. Start with whichever gap would hurt most if it stayed a gap: for a site that takes payments, that is usually the account inventory and the backup procedure; for a site with custom code nobody in the business can read, it is usually the deploy process. Build the rest around whatever time actually allows, and treat the whole set as something to revisit a couple of times a year rather than a project with a single finish line.

---

Pulling this together from scratch, or checking what is actually missing against what you assume exists, is exactly the kind of gap an Essential System Review (RM1,500, currently RM999 until 16 September 2026) is built to surface — a decision-ready report covering eight control points on a single site. JagaWeb Care + Changes (RM1,500/month, excluding SST) is another option if you would rather have this kept current on an ongoing basis rather than checked once. Details at jagaweb.my or sales@jagaweb.my.