Who's going to update your new website a year from now, and can they do it today? That question often says more about whether a site stays current than anything that happens at launch. A website handover should leave the person who'll actually make updates able to change a real page without help, with training written into the scope rather than sold as an extra, a named person to ask when something's awkward, and the logins held by your company. Write those into the proposal, then check them before the final invoice. If a site isn't easy for the team to edit, people usually stop editing it, and a site nobody edits slowly turns back into the one you just paid to replace.
Who is the website handover actually for?
Name the person who'll do the updates before the handover, not after. It may not be whoever ran the project. The person who'll swap in your new line card next spring, or take a discontinued product off the site, can be someone else entirely.
Naming them matters for a second reason. An editable site still goes stale if nobody has been given the updates as part of their job. The handover can't fix that. What it can do is make sure the person who does have the job isn't blocked on day one.
The worst handovers, in my experience, are the ones where the client expected to manage the site themselves, without a third party, and the handover covered none of that. If that expectation isn't written into the project at the start, nothing in the schedule protects it.
There's a legitimate opposite arrangement. Some companies would rather their agency make every change, and that works fine when it's priced and the turnaround is quick. Then the question is what a change costs and how fast it ships, and why website changes take weeks lays out the norms. What doesn't work is the middle: a team that's expected to edit the site and was never set up to.
Why does training get dropped when a project runs long?
Training usually comes last in a project, so if the project runs longer or takes more hours than planned, it's the easiest thing to cut. A client may have planned on including onboarding or training, and by the time the site's built, it makes even less sense for them financially.
Then the conversation turns into something like: "Hey, you need to pay us to train you how to use this thing. You paid us a lot of money to use it."
The fix is to settle it before a single hour is spent. Get training into the proposal as a named deliverable: who's being trained, on which jobs, and by when, priced as its own fixed line kept apart from the build hours, so a build that runs over can't eat it. If the proposal is silent, ask in writing what training is included and what it costs, while the budget is still unspent.
What does "it is what it is" leave you with?
The second kind of bad handover is quieter. The site's delivered, the logins arrive, and that's the end of it. It's just, "Here you go, it is what it is." No collaboration, and none of the line a client should hear from whoever built their site: "Hey, if you want something changed to make your life easier, just let us know."
That offer matters because a lot of what's awkward about editing a site only shows up once somebody starts doing it. The team might find that project write-ups have nowhere to put the material or the industry, or that the change they make every month takes far more steps than it should. A builder who's still listening can often fix that kind of thing quickly. One who has moved on leaves the team to work around it.
One version of this comes up with manufacturers: image-only PDF spec sheets, exported from design files only the agency that built the site holds. The team never got those files or a way to edit specs on the site, so every changed figure means asking that agency to edit and re-upload the original. Spec sheets were never listed as something the team would change, so the handover never covered them. Buyers usually can't search or copy their text. Google's rule of thumb, from a 2011 post, is that text you can copy should be indexable. It may OCR images, but don't count on it. The fix, from our spec sheet entry: figures as page text, PDF as a download.
What should you check before the final invoice?
If you're about to commission a site, write these into the proposal. If you're about to receive one, run them before the last payment and send what fails as a punch list.
- The editor can do the real jobs, alone. List the changes you expect in the first year: a new project or case study, a rewritten service page, a new hire on the team page, a replaced spec sheet. Write acceptance into the proposal around what the agency controls: each of those content types editable in the live CMS without code, training delivered to the named person by a set date, and a recording or guide for your own site supplied. Then have that person do each job, as a draft or on a staging copy, logged in as themselves, without the agency talking them through it, and publish one real change, within a set number of days of the training. A listed job they can't do because the CMS doesn't support it is a defect the agency fixes before sign-off. The time limit matters. An agency will reasonably refuse to let its payment wait on whether your staff find the time. A typo fix proves the login works. The year-one list proves the site is editable by the person who has to edit it.
- Training is in the scope, with names and a date. Plus something to come back to, such as a recorded walkthrough of your own site rather than the platform's general help pages. The person who sat through the training may not be the person editing the site in two years.
- There's a named person for awkward questions. Who do you email when something's harder than it should be, for how long after launch, and is that covered or billed? "Just let us know" is a fine answer, as long as it's written down.
- Your company holds the logins. Administrator access in accounts your company owns, not a single editor login on the agency's account. The full check is in you don't own your website.
If you're planning a B2B website redesign now, these belong in the first conversation, not the last one.
Where does a site that's hard to edit end up?
If it's not easy to edit and it's not straightforward, people are just going to not edit it. A year or two later the business has changed, the site still describes an earlier version of the company, and a prospect still downloads the spec sheet for a line you stopped making two years ago. That's how you run into the same situation again, and when it happens, the handover is often where it started, even if it's rarely the only cause.
If you got a new site recently and nobody's touched it since, it isn't too late to ask: "here's what's hard for us to change" is an easy request for a good partner to say yes to. If the site you have now is already one your team can't edit, the piece on why a marketing team can't fix the site it has covers fixing an existing one. This post is about what to require before you pay for the new one.
