Accepting a website from a contractor: what to check and what to take away

Handover usually looks like this: the site is demonstrated, everything opens, you say "great" and pay the balance. The problems surface months later — when something needs changing and it turns out there is no access, no code, and the only person who can do it is the same contractor.

Acceptance is not about finding fault. It is the one moment when you have the leverage to receive everything that should be yours.

What you must take away

This matters more than any feature check. Features can be finished later; access is far harder to obtain after the fact.

• The domain registered to you. Not to the contractor, not to "their registrar account". Verify this separately and with your own eyes.

• Hosting access — on your email, with your password.

• Source code in your repository. Not an archive in a messenger, but somewhere you can grant the next developer access.

• An administrator account with full rights, not a reduced one.

• Analytics access — the counters should sit in your account, or the entire history of visits stays with the contractor.

• Instructions for deploying from scratch. Short but working: where the database is, where the environment variables are, what command builds it.

A simple test: imagine you cannot reach the contractor tomorrow. Could you hand the site to somebody else? If not, acceptance is not finished.

What to test yourself

Not by glancing at the homepage, but against a list. Half of these fail quietly.

• The enquiry form arrives. Send a real one and confirm it landed — and that it is stored somewhere rather than only emailed. Mail breaks more often than you would think.

• The site opens on a phone. Your own, on mobile data, not just in a narrowed browser window.

• Search, filters and cart work — everything that was in the brief.

• A non-existent address returns a 404 page, not a blank screen.

• The certificate is in place, the padlock shows, and the site does not open over http without redirecting.

• The text and phone numbers are real. Lorem ipsum and a test number in the footer reach production more often than anyone would like.

What to check in the markup

This is what does not get demonstrated and costs the most later.

• Every page has its own title and description. Not the same one site-wide.

• The site is not blocked from indexing. The most painful mistake there is: a test block left over from development, and the site simply is not in search. Check robots.txt and that the pages carry no indexing ban.

• The sitemap is served and contains addresses that actually work.

• Images have descriptions. While you are there, look at their weight: uncompressed photographs of several megabytes are routine.

If you are launching a multilingual version, add a check of the language relationships — there is a separate piece on the blog about that.

What to put in writing

• What the warranty covers and for how long. And above all, what counts as a warranty case and what counts as a new task.

• Who is responsible for what afterwards: hosting, code, content.

• How changes are requested and how quickly the contractor responds.

Those three remove almost every future argument — not because anyone is acting in bad faith, but because without them the two sides expect different things.

Signs it is too early to accept

• Access will be "sent later".

• The code is only ever shown on a screen.

• The domain is registered to the contractor, explained as convenience.

• There is no clear answer to "how would this be deployed again".

None of these means bad intent. Each of them means that in a year, changing supplier becomes a negotiation instead of a file transfer.

If the site has already been handed over and there are gaps against this list, we can look at what you actually hold and what is missing.