What to check when a new website is handed over to you
When a website is handed over, seven areas need checking: content and pages, speed, accessibility, addresses and redirects, forms and email, backups and a way back, and the handover of accounts. The checks follow the acceptance criteria written in the proposal, and the outcome goes into a written handover record. Anything missing is sorted into two groups: what blocks launch, and what can be fixed after it.
This piece fills the gap between two of our others. In how to read a software proposal we explained why the proposal should say when the work counts as “done”. In why website maintenance matters we covered the routine work after launch. Here we look at the day in between: handover day.
What is acceptance testing?
Acceptance testing is the client’s check that the delivered work meets the criteria written into the proposal and scope. Its purpose is to tie the answer to “is it finished?” to a written list both sides have seen in advance.
It rests on two things. The first is the scope in the proposal: which pages, which functions, which languages. The second is the acceptance criteria: the condition under which each deliverable counts as complete. If the proposal has no criteria, handover day turns into an argument. Writing them at the start is the cheapest way to make handover easy.
What should you have before handover?
We suggest going into handover day with these documents:
- The approved scope and acceptance criteria
- The approved sitemap — the list of pages
- If there is an old site, the table mapping old addresses to new ones
- The final versions of the copy and images
- Where each form should deliver its messages
- The list of accounts to be handed over
Most of these are produced during design and build anyway. On the day itself, you are only comparing.
A checklist across seven areas
Keep this table to hand on handover day. The last column is the condition each item must meet to pass.
| Area | What to check | How to check it | Passes when |
|---|---|---|---|
| Content and pages | Every page exists, copy is final, images are in place | Compare page by page against the sitemap | Every page on the approved sitemap is live, with no placeholder text |
| Speed | Load speed of the home page and the most important pages | Mobile test in PageSpeed Insights | Within LCP 2.5 seconds, INP 200 milliseconds, CLS 0.1 |
| Accessibility | Keyboard navigation, alt text, contrast, form labels | Try it by hand with the keyboard, plus an automated scan | Every menu and form works with the keyboard alone |
| Addresses and redirects | Old addresses reach the new ones; no broken links | Open the addresses in the mapping table one by one | Each old address reaches the right new page through a permanent redirect |
| Forms and email | Forms send; email lands in the right inbox | Send every form with a real test message | The message arrives, stays out of spam, and the sender sees a confirmation |
| Backup and a way back | A current backup exists, and restoring it is understood | See where the backup is and when it was taken | The backup is somewhere you can reach, and the restore steps are written down |
| Account handover | Domain, hosting, analytics, Search Console and other accounts | Log in to each account with your own details | You hold administrator rights on every account |
The speed thresholds are the values Google counts as “good” for Core Web Vitals. How to measure speed, and the difference between lab tests and real visitor data, is in why is my website slow?
Content and pages: the part most often skipped
The things most often missed on handover day are small content gaps. Sample text left on a page, a phone number with a digit wrong, an old address, a button that goes nowhere.
As you check, look specifically at these:
- Are the phone number, email and address the same on every page?
- Does every page have its own title and a short description for search results?
- Are the cookie notice, privacy notice and other legal pages in place?
- Is there a designed “page not found” (404) screen that leads people back?
- Are the sharing images right? Paste a page link into a messaging app and look at the preview.
Which legal duties apply to sites in Türkiye is summarised in legal requirements for websites in Türkiye.
How to test accessibility in five minutes
You do not need to be an expert. Put the mouse aside and move through the site with the keyboard alone.
- Can you move through the page in order with the Tab key?
- Is the focused element always visible?
- Does the menu open, and close again with Escape?
- Can you fill in and send the form using only the keyboard?
- When you leave a field wrong, does the error message say what is wrong?
These five questions will not catch everything, but they reveal the biggest problems. Our accessible websites page explains the standard we build to.
Why redirects matter if there is an old site
When a site is replaced, each old address should be connected to its new counterpart with a permanent (301) redirect. Without that, visitors and search engines arriving at old addresses find an empty page.
On handover day, open at least these from the mapping table: the most visited pages, pages other sites link to, and the old contact page. Each should reach the right new page without a chain of redirects. We set out the whole method in redesigning a website without losing SEO.
Forms: test with a real message
A form saying “sent” on screen does not mean the message arrived. Send every form with a real test message and check:
- Did it reach the right inbox?
- Did it land in spam?
- Was the person filling it in shown a confirmation?
- Does the form warn when required fields are left empty?
- Is the form protected against automated spam submissions?
If messages go to spam, the cause is usually the domain’s email security records. We explain these in domain, hosting and business email.
Account handover: log in to each one yourself
Being sent a password does not complete an account handover. You need to log in to each account with your own details and see that you hold administrator rights.
A detailed handover list is at the end of domain, hosting and business email. On handover day, add these to it:
- You are set as an owner of the Search Console property
- You are set as an administrator of the analytics account
- If there is a content management panel, you have your own user
- If the proposal says the source code will be handed over, you have the code and the set-up notes
Who owns the source code is settled at proposal stage. We cover it in the piece on reading a proposal.
How to keep a handover record
Every gap found during the checks goes onto a list. We recommend splitting that list into three columns. The split turns handover day from a drawn-out discussion into a clear decision.
| Column | What goes in | Example | What happens |
|---|---|---|---|
| Blocks launch | Anything in scope that does not work, gives wrong information or carries legal risk | A broken contact form, a wrong phone number, a missing privacy notice | Fixed before launch |
| After launch | Gaps in scope that do not justify holding the launch | A better crop on one image, a small typo | Fixed within the following few days, with a date written down |
| New request | Ideas outside the scope that come up during handover | A new page, another language, a new form | Treated as a separate change request |
The third column matters. New ideas on handover day are entirely natural. Writing them down separately lets the current work finish, and keeps the ideas from being lost. How change requests are handled is in how to read a software proposal.
The record carries two signatures and a date. Once the first column is empty, the site goes live.
The first weeks after handover
Launch day is not the end of the work. In the first weeks, check:
- Has the new sitemap been submitted in Search Console, and are pages being indexed?
- Is traffic from old addresses reaching the new pages?
- Are real messages arriving through the forms?
- Do speed results hold up in real visitor data too?
We describe that monitoring and what monthly maintenance involves in why website maintenance matters, and how to read the Search Console reports in how to read Google Search Console.
Frequently asked questions
What if I have no technical knowledge?
Most items on this list need none. Comparing pages with the sitemap, trying the forms, moving through the site by keyboard and logging in to the accounts yourself are checks anyone can do. For items such as speed and redirects, it is enough to ask the team for the results in writing.
Who is responsible for faults found after handover?
That depends on the warranty and support clause in the proposal. Something in scope that does not work is usually a fault for the team that built it to fix. A new request outside the scope is a separate change request; we recommend the proposal spells out that distinction.
Is a handover record really necessary?
It is not a legal requirement, but it makes life easier. When what was checked, what was missing and what was left for later are all written down, there is a document to turn to if a question comes up months afterwards.
Can we update the site ourselves after handover?
If the proposal includes content management, yes. On handover day, try it briefly: change some text, add an image and check that the change appears on the site. If there is no panel, updates are made as part of maintenance.
If you would like us to hand over your new site against this checklist, see our web design process, and our SEO and maintenance service for the follow-up after launch. To tell us about your project, write to us; we reply within two working days.