How to review and accept a finished website

First, agree which version you are reviewing

Ask for the review URL and a list of completed pages. Record the date. If development is continuing, establish which sections are ready to review and how new fixes will be identified. Otherwise, you and the developer may be discussing different versions of the same screen.

Keep the agreed scope beside you: pages, features, approved designs, content and integrations. Mark which checks belong before publication and which must happen on the live domain. Delivery from the production mail server and public access for search crawlers need confirmation in the live environment.

A feature outside the agreed scope needs a separate decision about additional work. When reporting a defect, identify the agreed action that cannot be completed. This gives both sides a concrete basis for the discussion.

Scroll the table horizontally

1. Complete a customer journey on your phone

Open the website on your own phone using a direct link, without coaching from the developer. Choose a specific task: establish whether the company serves your area, select a service and submit a request. Find the answers as you would if you were buying.

Check the menu, the service link, the enquiry button and the browser’s back action. Start on an internal page as well as the homepage: people may arrive from search, advertising or a message. Close the menu and cookie notice, scroll to the bottom, and return to the form.

For a telephone link, check the number passed to the calling app; you do not have to place the call. Check the destination of email, messaging and map links. Make sure floating panels leave the last form field and submit button accessible.

2. Follow the form submission to its recipient

Tell the receiving colleague that you are running a test. Send a recognisable message, such as ‘Website check, 21 October, service form’, using your own test contact details. Find that exact enquiry in the inbox or CRM. Compare the message, contact details, selected service and attachment, where applicable. Check that the recipient can reply to the sender.

A success message on the page establishes that the interface displayed success. Acceptance also needs evidence from the receiving end. If different forms route to different people, test each route separately. Repeat the submission on the live domain after publication.

Next, submit an empty form and try an invalid email address. The guidance should explain what needs correcting and remain visible on a phone. Ask the developer to demonstrate a controlled failure on a test copy: the visitor should understand that the message was not sent and have a way to retry. Entered text should be retained where possible. There is no need to disable the company’s working email to demonstrate this.

• Fill in the form with a desktop keyboard and with the phone’s on-screen keyboard.
• If uploads are included, try an ordinary permitted file and an agreed rejection case, such as exceeding the size limit.
• Check whether pressing submit again while a request is in progress creates unwanted duplicates.
• If conversion events are included, ask to see a successful submission event and confirm that a failed submission does not trigger it, taking the visitor’s consent settings into account.

3. Check the content on actual pages

Compare service names, prices and terms, addresses, telephone numbers, business details and opening hours with the approved material. This needs a business owner: a developer may copy text accurately without knowing that a price or address has changed. Assign someone to confirm that the information is current.

Open document links, download the files and inspect their contents. Look at long headings, large tables and pages with little text. For a bilingual website, repeat the journey in each language: the language switch should retain the purpose of the page, while forms and error messages should follow the selected language.

Identify pages that need to survive a move from an older website. Ask the developer to demonstrate what happens when an important old address is opened. The complete migration plan is a separate topic, but a missing service page can be caught during acceptance.

4. Check reading and interaction

Review the website on a real phone and a computer. Where available, try Safari on an iPhone and Chrome on Android; agree additional browser coverage around the project’s audience. Narrowing a desktop window helps expose layout issues, but does not reproduce a phone’s keyboard or browser behaviour.

On a computer, put the mouse aside and move through links and fields with Tab, and backwards with Shift+Tab. You should be able to see which element has focus. Try opening and closing the menu, completing the form and leaving a dialog. If movement gets trapped or focus disappears behind a panel, record the steps.

Increase zoom to 200% and check that text remains readable, controls do not overlap and important information remains available. Review reading comfort at an ordinary screen brightness, the clarity of field labels and whether distracting movement can be stopped. A wide table may deliberately scroll horizontally; the whole page scrolling sideways because a button sticks out is a separate issue.

5. Review loading and search readiness

First open the homepage, a service page and the form on your phone using your usual connection. Note when useful content appears and when the relevant button responds. If the first screen stays blank, an image visibly pushes text around, or the form takes time to respond, save a screen recording with the URL and test conditions.

Run mobile checks in PageSpeed Insights for several representative pages and save the report links. Discuss specific delays and their effect on visitors with the developer. A laboratory score can vary between runs; requiring 100 without agreed measurement conditions does little to define launch readiness.

PageSpeed’s real-user section uses the previous 28 days and needs enough observations. It may be unavailable for a new or low-traffic website. That does not mean the laboratory check failed to run. Ask which evidence is available now and what will be monitored after launch.

For search readiness, ask to see the main URLs, their availability without signing in, the sitemap and confirmation that public pages have no accidental indexing block. A test copy may intentionally be kept out of search. Repeat the checks on the live domain after the move. Publication and technical readiness do not guarantee immediate inclusion or particular search positions.

6. Make an update and check the handover

If an editor is included, ask for your own role and change an agreed type of content yourself: service text, a photograph or a news entry. Use a test entry to check previewing, publishing and restoring the original content. Inspect the result on your phone. This demonstrates that routine work is possible with your actual permissions.

If no editor was commissioned, clarify the update process: who receives new material, what maintenance includes and how additional work is priced. The need for an editor is best settled before development; acceptance should confirm the method you chose.

Check the agreed list of accounts and materials: domain registrar, hosting, editor, analytics, repository or source archive, and design files. Sign in from your side and check recovery through an address you control. Use individual accounts and invitations where the service supports them.

Establish what a backup contains, where it is kept and who can restore the website. Ask for restoration to be demonstrated on a test copy if that is part of the handover. ‘Backups are configured’ does not explain how the site and its enquiries would be recovered after a failure.

Record issues with evidence and a priority

Keep one issue list instead of scattered screenshots in messages. Each entry needs the page URL, device and browser, steps, expected and actual results, and a screenshot or recording. Add the person responsible, the agreed action and the result of the retest.

For example: ‘On the service page in Safari on an iPhone, open the form, complete the fields and submit. Expected: confirmation and an email to the manager. Actual: the button stays in its sending state and no email arrives.’ The developer can repeat that journey and explain which part of the chain was checked. ‘The form behaves strangely’ leaves that work undefined.

Scroll the table horizontally

A short checklist to finish the review

Go through this list with the person responsible for the website on the business side. For remaining issues, retain a clear agreement about who will fix them, when, and how the result will be checked.

• Agreed pages and features have been reviewed on the identified website version.
• The main customer journeys have been completed on a phone and a computer.
• Test enquiries have reached the right people, and submission errors are understandable.
• The content owner has confirmed information, contacts, documents and language versions.
• An update has been completed using the agreed process; accounts and instructions have been handed over.
• Critical fixes have been retested, with owners and dates recorded for remaining issues.
• Post-publication checks are planned for a submission from the live domain, important URLs and ongoing site operation.