The Handover Test

Every website project ends with a handover document nobody reads. Logins, plugin list, where the brand fonts live, who to call when the form stops sending. Useful, all of it, and none of it is the part that matters six months later. The part that matters is the work the site will generate after the handover, and the list of who does it. That list is almost never written, because at the moment of writing it everyone still knows the answer. The person who built the thing is standing right there. The failure arrives later, quietly, when somebody publishes the fourth blog post and nobody has told them the page title is their job.

The pages that don't exist yet

Any site with a blog, a case study library, a careers board or a product catalogue has entries on its sitemap that aren't pages at all. They're templates. One template, however many pages it eventually produces. Scoping starts with counting pages, and the count is where this goes wrong in both directions. Treat a template as a page and you've under-scoped the thing that generates the most ongoing work on the site. Treat it as nothing, which is the more common move, and you've made an open-ended commitment that appears in no document, has no owner, and gets discovered by whoever notices post four says the same thing as post three. The arithmetic is worth saying out loud. A sitemap carrying two templates is not the number of entries it displays. It's that number, minus the two, plus two machines that will each keep producing pages needing individual attention for as long as the site stays alive. Those two lines deserve more thought than most of the fixed pages combined. A pricing page gets written once and revisited when pricing changes. A blog template is a standing order. The reasonable objection is that the CMS handles it. Yoast, Rank Math and their competitors let you set a title and description pattern per post type, so nothing ships naked. That's real and it's better than blank. It also produces a site where every description is one sentence with a different noun dropped in, which is its own kind of empty. Google's documentation on snippets asks for descriptions written for the individual page rather than duplicated across a site, and a pattern applied across four hundred posts is duplication wearing a variable. The template default is a floor, not a finish.

The role that isn't written down either

The same failure has a bigger version, and it's the one that ends careers of documents rather than careers of people. Somewhere in most organisations there's a canonical process document describing who does what. Roles sit next to each other on the same page, at wildly different levels of detail, and nobody notices because everybody currently knows how it actually works. I've read one where a content role was summarised in three lines while the role beside it ran to twenty-one numbered steps, and the three lines were not wrong. They were just nowhere near the real job, which by then covered a knowledge base migration cycle, a weekly search reporting cadence, website and CMS updates, and the training of an internal assistant on the company's own material. None of that was secret. All of it was visible in the sprint record for anyone who looked. It simply wasn't anywhere a replacement would look, which is a different thing and a worse one. A document that understates a role has three practical consequences, and they compound. The role can't be handed over, because the document a new person reads describes a smaller job than the one they've inherited. The role can't be defended in a planning conversation, because the written scope is the scope. And the work that isn't in the document gets treated as discretionary the moment anyone is under pressure, which is precisely when it stops happening.

What a system that survives actually looks like

The fix is not a longer document. Longer documents rot faster, because every fact in them is another fact that can go stale, and nobody re-reads a forty-page process manual to check. What works is a small set of always-true rules, plus a rule about where everything else goes. I build content systems to a context-budget principle. One short file at the root holds only what is true regardless of what you're writing, and it does not enumerate anything else. Everything specific loads on demand. Rules about sentence mechanics or vocabulary sit in their own files and get read when someone is drafting prose, not when they're updating a release note. Repeatable multi-step processes get packaged as workflows rather than described in paragraphs. Anything that must happen automatically rather than on request stops being documentation at all and becomes a hook. The organising decision is a router, and it's four questions long. Is this true always, or only for one kind of content? Is it a rule, or a repeatable sequence of steps? Does it need its own separate working context? Must it fire automatically? Where a new instruction lands follows from the answers, which means the structure doesn't need a committee every time somebody has an idea. That router is the part people underestimate. A system without one accumulates instructions in whichever file the last person happened to have open, and after a year no one can say where a rule ought to live, only where it happens to be. The second half is cadence. Every commitment in a content function has a rhythm, whether or not anyone has named it. Something happens daily, something weekly, something at sprint boundaries, something quarterly, something once a year and badly. Writing the cadence down converts a pile of tasks into a schedule somebody else can pick up, and it does one more thing that matters at handover time: it makes the annual and quarterly items visible. Those are the ones that vanish silently, because a weekly task that stops gets noticed in a week.

Finding the gaps before somebody else does

None of this is useful as an opinion. It becomes useful as an audit. The instrument I use is a gap register: a list of findings, each one citing the actual artifact it was found in, so a reader can verify it rather than take it on trust. A finding that says "the knowledge base is out of date" is an argument. A finding that names the page, the date it was last touched, and the two governing documents that now contradict each other is a fact somebody can act on before lunch. Priorities go on the same register, and three levels is enough. Something that blocks continuity or correctness. Something that quietly degrades quality on a known cadence. Something that is simply cleanup. The first category is the one worth arguing about, because it's the one that turns into an emergency at exactly the wrong moment. The most common finding, in my experience, isn't a missing document. It's two current documents that disagree. Both are in active use, both get cited as authoritative in different places, and the contradiction survives because nobody has ever had reason to open them side by side. The knowledge base branch that tracks people and access lists is usually the worst offender, since it goes stale fastest and its update cadence is the one most likely to have been set twice.

Your turn

Three things, in order, and none of them takes a week. Split your page count in two. Fixed pages in one column, templates in the other, and never let the two totals merge into a single number on a slide. For every template, write down what gets produced at publish time, who produces it by role rather than by name, and when it happens. Put that block at the top of the handover, above the passwords. Then open your canonical process document and read your own role in it as though you were the person replacing you. If it describes a smaller job than the one you do, you have found the thing that breaks first, and you have found it while you still have the context to fix it.

The test

If your sitemap count and your page count are the same number, you haven't found the templates yet. If your job description fits in three lines, neither has anyone else.

Questions people ask

Isn't this just documentation?

Documentation describes what exists. This is about what recurs. A page that exists needs describing once; a template that produces pages needs an owner, forever. The distinction sounds academic until the person who held both in their head changes jobs.

How long should a handover document be?

Short enough that somebody reads it on their first morning. The long version is the system, not the handover. If the handover has to explain how everything works, the system wasn't written down in time, and you're now compressing a year of context into a document being read by someone who has no way to tell which parts matter.

We use a CMS with metadata templates. Isn't that solved?

Partly. Templates stop pages shipping empty, which is worth having. They don't make a page distinguishable from the four hundred others using the same pattern, and search engines have been explicit for years that per-page descriptions are what they want. Treat the template as the safety net rather than the answer.

Who should own metadata for new posts?

Whoever publishes, at publish time, named by role in writing. Not the agency, which will be gone. Not "the marketing team," which is nobody. The failure mode is always the same: everyone assumes it belongs to someone with more context than they have.

What about a second language?

A second language is a second full set of everything, with its own titles, descriptions and ongoing template obligation. Asked at scoping, it's a line item. Asked after the first language is signed off, it arrives as a favour, and somebody ends up doing it unpaid. This is worth raising before anybody writes a word, which is earlier than feels natural.

What breaks first when someone leaves?

The quarterly and annual work. Daily and weekly commitments announce their own absence within days. Anything on a ninety-day or twelve-month rhythm can lapse two full cycles before it's noticed, and by then the last person who ran it has forgotten the details they didn't write down.

How do I know whether my content operation would survive this?

Pick the person who knows where everything is. Ask what would still happen on schedule if they were unavailable for a quarter, and require the answer to be a document rather than a name. The gap between what people believe is written down and what is actually written down is usually the whole finding. The site launches either way. The difference shows up around month four, when somebody either has a habit or has an audit. If you're staring at a site, a content operation or a search programme that currently runs on one person's memory, that's the kind of problem I take on as freelance work. The Yoma Fleet case study shows a version of it in use, and the contact form on this site reaches me directly.