A website runbook is a written, step-by-step guide to the jobs your site needs done again and again: publishing a page, applying an update, restoring a broken layout, renewing a certificate. It exists for one reason. On many sites, the person who knows how to do these things is a single developer, an agency contact or the one colleague who “is good with the CMS”. When that person is unavailable, routine maintenance becomes a guessing game. In plain language, this article covers what a website runbook contains, why it matters and how to build one without a technical background.
The problem a runbook solves
Content management systems make publishing easy, but they also hide a lot of unwritten knowledge. Which plugin must be updated first? Where does the staging copy live? What do you check after changing the menu? Each answer is simple once you know it, and nearly invisible until you need it. Knowledge stored in one person’s habits leaves with that person, whether they move to a new role, take leave or are simply unreachable during an outage.
A runbook turns those habits into shared, checkable steps. It does not replace expertise. It makes expertise repeatable by someone else, on a different day, under mild pressure.
What goes into a website runbook
Think of it as a small collection of one-page procedures, each with the same layout. The most common ones fall into four groups.
Publishing routines
How a new page or post goes from draft to live: who reviews it, which template to use, what to check in preview, how to schedule it, and what to look at after it goes out. A good publishing routine also says where images are sized and stored, and how to add the descriptive text that search engines and screen readers use.
Maintenance routines
Applying updates to the CMS core, themes and extensions; taking a backup beforehand; testing key pages afterwards; and noting what changed. These are the tasks most likely to break a site if done in the wrong order, which makes them the best candidates for a written sequence.
Recovery routines
What to do when something goes wrong: the site shows an error page, a form stops sending email, a page layout is damaged by an edit. The recovery runbook lists the first checks, how to roll back to a backup, and when to escalate to hosting support or a developer. Fixes that worked once should be written here immediately.
Ownership routines
Renewals and housekeeping: domain registration, certificate expiry, user accounts for departed staff, and where the credentials are kept. These are infrequent, so they slip from memory easily and are painful to miss.
How a single runbook entry is structured
Consistency helps readers find what they need quickly. A reliable template has six parts:
- Purpose. A single sentence describing the task and when it applies.
- Prerequisites. The access, tools and approvals required before starting.
- Procedure. Numbered steps, one action each.
- Verification. How to confirm the task succeeded, for example which pages to open and what to expect.
- Troubleshooting. The most likely failures and the first remedy for each.
- Ownership. The role responsible, a backup, and the date last reviewed.
Why planning documents are not runbooks
It is easy to confuse a runbook with the planning documents created when a site is built. A project plan, such as the kind described in this step-by-step guide on preparing a business website before any development begins, explains what the site should be and why. A runbook explains how to look after it once it exists. The two complement each other: the plan captures intent, the runbook captures routine.
Likewise, a list of required pages, as covered in this overview of the pages a business site should have, tells you what to publish, while the runbook tells you how to publish and update each of them consistently.
A worked example: updating a plugin
As an illustration, here is how a maintenance entry might read for a routine plugin update. It is a generic illustration; adapt the names to your own setup.
- Confirm the staging copy matches the live site, and note today’s date in the change log.
- Take a fresh backup of the files and database, and confirm the file appears in the backup location.
- Apply the update on staging first and open the home page, one article, the contact form and the checkout or enquiry page.
- If any of those fail, stop, restore staging from the backup and record the plugin name and version in the notes.
- If all pass, repeat the update on the live site during a quiet hour and run the same four checks.
- Write one line in the change log describing what was updated and what was checked.
Nothing here requires deep technical skill, which is the point. The skill went into deciding the order and the checks once, so that everyone afterwards can benefit from it.
How to start writing one
Begin with the tasks that have gone wrong before, or that only one person can do. Sit beside that person and ask them to perform the task while you write down every action, including the ones they consider too obvious to mention. Then do the reverse: hand the draft to someone else and ask them to follow it exactly, without help. Each time they hesitate, add the missing detail. Two rounds of this are usually enough to produce a procedure that works.
Keep each entry short. If a procedure exceeds a page, split it. Use the names that appear on the screen, not internal jargon. Where a step has a risk, say so plainly: “take a backup first, because this cannot be undone.”
Where runbooks should live
Store the document where the people who need it already look. A shared folder with a clear name, a pinned page in the team’s chat, or a link from the CMS dashboard are all reasonable. Avoid keeping the only copy on the website it describes, since the runbook is most needed when the site is down. Keep an offline or separately hosted copy of the recovery section.
A note on trust and credibility
Visitors never see your runbook, but they feel its effects. Pages that load, forms that work and information that is current are all downstream of routine care. The same is true of trust-building pages such as the one explained in this article on why an About page builds confidence with visitors: its value depends on being accurate and maintained, and a runbook is what ensures someone is responsible for keeping it so.
An outside example of the same discipline
The practice is borrowed from operations teams. Data engineers lean on runbooks to keep scheduled jobs healthy, and TheDataOps.org gathers articles for data teams on pipelines and reliability. A website team can apply the same principle on a smaller scale: document recurring work, test the documents, update them after every lesson.
Keeping it current
A runbook is only useful while it is accurate. Three habits keep it that way. First, assign each entry an owner and a review date. Second, treat every incident as an edit: when something breaks and gets fixed, update the relevant page that day. Third, retire entries that no longer apply, because an outdated procedure that looks authoritative is worse than no procedure at all.
Summary
A website runbook is a modest document with an outsized effect. It captures how routine tasks are done, in steps anyone competent can follow, so that publishing, maintenance and recovery do not depend on one person’s memory. Start with the riskiest or most person-dependent task, write it in six parts, test it with someone new and keep it alive through review. In time, the collection becomes the most practical record of how your site really runs.
