The website test that matters is the one six months after launch

A website is usually judged at the moment it goes live, when it is at its best: content is fresh, every image was chosen deliberately, and someone who knows the system is available to fix anything. None of those conditions hold six months later, and that is the state the site will spend most of its life in.

Can a non-developer change the things that change?

Some content is stable — a company's positioning does not move every quarter. Other content moves constantly: prices, offers, team members, services, articles, contact details. The failure mode is a build where the moving content is hard-coded and the stable content is editable, which is exactly backwards and is more common than it should be.

Before a build starts, list what will change in the first year and who will change it. That list decides what needs an editing interface. Everything else can be simpler, faster and cheaper precisely because it is fixed.

Does it still load well on the connection your customers actually have?

Performance regressions are rarely dramatic. They arrive one addition at a time: a tracking script, a chat widget, a font, an uncompressed banner uploaded by someone in a hurry. Each is defensible on its own and the cumulative effect is a site that takes several seconds to become useful on an average mobile connection.

• Test on a mid-range phone on mobile data, not on office wifi on a desktop.
• Set a size ceiling for uploaded images and enforce it in the upload interface, not in a policy document.
• Review third-party scripts periodically and remove the ones nobody reads the output of.
• Treat anything that blocks the first render as requiring a specific justification.

Is the content structure still telling the truth?

Businesses change faster than their navigation. A service that has become the main revenue line sits in a dropdown because that is where it was when the site was built; a service that was discontinued is still listed because nobody owns the page. The information architecture quietly becomes a record of what the company used to be.

This is worth an hour, twice a year. Read the navigation as a stranger would and ask whether the order of items matches the order of importance today.

Can anyone find the credentials?

The most expensive website problems are usually administrative rather than technical: an expired domain nobody was notified about, a hosting account tied to a former employee's email, an SSL certificate that lapsed over a weekend, analytics that stopped recording months ago because a tag was removed during a redesign.

A single document listing where the domain is registered, where the site is hosted, who has administrative access, when each renews, and how DNS is managed prevents nearly all of it. It takes twenty minutes to write at handover and is close to impossible to reconstruct in an emergency.

A build is finished when someone who was not involved in it can maintain it. Anything before that is a demo.

What a good handover contains

1. 01Access: registrar, host, CMS, analytics, and who holds the recovery email.
2. 02A short guide to the content types someone will actually edit, with screenshots.
3. 03The image specification: dimensions, format and maximum file size per slot.
4. 04A note on what is safe to change and what will need a developer.
5. 05Renewal dates for the domain, hosting, certificates and any paid plugins or APIs.