How to Accept a Website from a Developer: Complete Pre-Launch Checklist

A website is not finished merely because the home page opens and resembles the approved design. It must complete business journeys, work on real devices, deliver leads, collect reliable data, remain discoverable and stay under the client's control.

Acceptance is not an exercise in finding reasons to delay payment. It is a structured confirmation that the delivered product matches the contract, the requirements and the user's real tasks. In a sound process, both parties know the criteria in advance, defects can be reproduced, and release readiness does not depend on “it works on my computer.”

If the project is still being planned, include acceptance criteria in the scope of turnkey website development. If delivery is close, use this guide to run a joint review with the development team.

What website acceptance actually means

Accepting a website confirms four outcomes:

1. the agreed scope has been delivered;
2. critical user and business journeys work;
3. the client controls the assets and accounts;
4. ownership and deadlines for post-launch defects are clear.

Acceptance does not necessarily mean that every cosmetic imperfection has disappeared. A large project can have minor visual issues that do not affect sales, payments, data or discoverability. They must be separated from defects that make the release unsafe.

Never judge readiness by the percentage of closed tickets alone. One critical defect outweighs twenty corrected spacing issues.

Step 1. Build a testable baseline

Put the contract, appendices, approved wireframes, designs, sitemap, functional requirements, integration list and confirmed changes in one place. When requirements were agreed verbally, create a summary table and have both parties confirm it.

The website technical specification guide helps check whether page types, roles, states, integrations and acceptance rules were defined. Compare the result with the agreed scope, not with ideas introduced on handover day.

Create an acceptance tracker containing:

• test ID and title;
• URL or screen;
• device and browser;
• expected outcome;
• actual outcome;
• priority;
• screenshot or recording;
• owner;
• retest deadline;
• status.

Agree on a feature freeze before testing. Continuous additions make the tested build a moving target.

Step 2. Test in the right environment

The main review can take place on a password-protected staging site blocked from indexing. Final acceptance still needs a concise production retest because deployment changes DNS, TLS, file paths, caching, email delivery, payment callbacks and redirects.

Record the build number or exact start time. Otherwise, fixes made during the review can blur which version the client is accepting.

On production, confirm that:

• the domain points to the intended infrastructure;
• HTTPS works without warnings;
• page resources load securely;
• staging remains inaccessible to search engines;
• production is not protected by a password or leftover noindex;
• a fresh backup exists before deployment.

Server capacity, TLS and backup responsibilities should be agreed as part of website hosting, not after the first incident.

Step 3. Run complete user journeys

Do not review the site only page by page. Map the journeys it was designed to support:

search or ad → landing page → proof → form → confirmation → CRM → sales response

For ecommerce, add search, filters, product variants, cart, promo code, delivery, payment, receipt and order status. For a service business, include the service page, case study, pricing, enquiry and booking. For a portal, include registration, password recovery, roles, document access and logout.

Test every important journey with:

• valid normal data;
• a realistic user error;
• an unavailable integration or technical failure.

The product must not only accept correct input. It should explain errors clearly and preserve data whenever possible.

Step 4. Inspect pages and navigation

Compare live URLs with the approved sitemap. Open the desktop and mobile menus, footer, logo, breadcrumbs, calls to action, cards, pagination and in-content links.

Look for:

• blank pages, placeholder copy and test products;
• incorrect phone numbers, addresses, hours, email or company details;
• buttons pointing to #, staging or an old domain;
• broken search, filters, sorting and pagination;
• unclear back-navigation;
• missing or unhelpful 404 pages;
• nonexistent URLs returning 200 instead of a real 404;
• redirect loops and unnecessary chains.

The BB STUDIO tools can help inspect response codes, redirects and domain details. Automated crawling is useful evidence, but it does not replace a manual journey test.

Step 5. Compare the interface with approved designs

Review the system rather than a single screenshot: typography, spacing, grid, colors, button states, fields, errors, dialogs, tables and long content. A card that looks correct with a short mock title can break with the actual service name.

When checking website UI/UX design, review:

• whether the primary action is easy to identify;
• text and control contrast;
• component consistency across templates;
• hover, focus, active, disabled, loading and error states;
• readable validation messages;
• long words, prices, tables and translations;
• layout shifts when fonts and media load.

Responsive implementation will not be pixel-identical at every width. It should preserve hierarchy, function and visual consistency.

Step 6. Use real mobile devices and supported browsers

Browser device emulation is useful during development, but the final pass should include at least one real iPhone and Android phone. Test current Chrome, Safari, Firefox and Edge versions according to the agreed support matrix.

On mobile, verify:

• opening and closing navigation;
• fixed bars and the cookie banner;
• buttons that are not covered by another layer;
• correct keyboard types for phone, email and numeric fields;
• zoom, rotation and safe areas;
• tables, sliders, maps and video;
• file upload from the camera or storage;
• phone, email, messenger and map links;
• checkout or enquiry completion with one hand.

Horizontal scrolling on one template usually points to a wide table, a fixed-width component, an unbroken word or a third-party widget. Record the exact URL and viewport width.

Step 7. Follow every form submission to its destination

A “Thank you” message proves only that the interface changed. It does not prove the company received the lead. Submit a unique test enquiry through every form and follow it to the final owner.

For each form, verify:

1. required and optional fields;
2. phone and email validation;
3. useful error messages;
4. duplicate submission protection;
5. privacy consent;
6. delivery to the correct mailbox;
7. CRM lead creation;
8. source, UTM, landing page and form name;
9. assignment to the right person;
10. customer confirmation when specified.

Test names with apostrophes and hyphens, long messages, spaces and accepted files. Also test a prohibited extension and an oversized upload. Do not use another person's real private data.

If enquiries only reach a developer's personal mailbox or chat, the process has not been handed over to the business.

Step 8. Review content and localization

Proofread more than the home page. Include services, policies, automated emails, validation, 404, site search, cart, account pages and metadata.

For a multilingual site, maintain a URL equivalence table. A language switcher should open the equivalent page, not always send visitors to the home page. Menus, buttons, filters, emails and system messages should not mix languages.

Confirm that:

• facts, prices and terms are current;
• service names are consistent;
• spelling and punctuation are clean;
• useful alt text exists where appropriate;
• downloads have understandable names;
• dates, numbers and currency are localized;
• legal copy has been approved by a qualified owner;
• rights to copy, photography, video, fonts and icons are documented.

Step 9. Check search readiness before indexing

SEO defects may be invisible to a visitor yet prevent search engines from crawling and understanding the product. For each indexable page, confirm a distinct title, description, H1, readable URL, canonical and 200 response.

Also check that:

• robots.txt does not block important sections;
• the XML sitemap contains only canonical indexable URLs;
• staging and parameter duplicates stay excluded;
• redirects from previous URLs work without chains;
• hreflang is reciprocal and maps equivalent languages;
• structured data matches visible content;
• internal links do not lead to 404, 5xx or needless redirects;
• filters and search do not create uncontrolled indexation;
• important content is accessible without an interaction a crawler cannot complete.

When an existing site already has traffic, redirect mapping and URL preservation should be handled inside the SEO promotion process before launch.

Step 10. Assess performance and stability

Do not accept performance based on one random score. Record the page, device, network profile, test region, time and build. Include the home page, a typical landing page, the heaviest template, and a catalog or product detail page where relevant.

Review:

• server response;
• appearance of primary content;
• layout stability;
• response to interaction;
• image and video weight;
• repeat visits with caching;
• behavior under several simultaneous actions;
• console and network errors.

“Score 100” is not a helpful standalone requirement. Better criteria define the tested scenarios, remove obvious blockers and set a reasonable page-weight or performance budget.

Step 11. Cover essential security and privacy

The client is not expected to conduct a full penetration test alone, but basic release risks must be addressed.

Verify that:

• every page uses HTTPS;
• administrator accounts are individual;
• default and shared passwords are removed;
• roles follow least privilege;
• backups run and restoration has been tested;
• dumps, logs and configuration files are not publicly exposed;
• forms use server-side validation and abuse protection;
• secrets and API keys are not exposed in frontend code;
• dependencies have no known critical issues;
• the privacy notice reflects the data actually collected;
• consent behavior matches the agreed model.

Use a password manager for handover and rotate temporary credentials when the project is complete.

Step 12. Validate analytics and conversions

Analytics being present in source code does not mean measurement works. Open a debug or real-time view and complete each important action.

Check:

• the correct container and property;
• no duplicate page views;
• form, phone, messenger, purchase and payment events;
• event names, parameters, currency and value;
• UTM and source transfer to the CRM;
• internal and test traffic rules where specified;
• behavior before and after consent;
• advertising conversions;
• absence of personal data in URLs and event payloads.

Submit one enquiry with test campaign parameters and trace it across the browser, analytics and CRM. This end-to-end test often finds gaps that isolated checks miss.

Step 13. Transfer ownership and documentation

Before final sign-off, create an asset register. Business accounts should belong to the company; a contractor should have a separate revocable user.

The client should control:

• domain registrar and DNS;
• hosting or cloud account;
• CMS super administrator;
• code repository and version history;
• database and backups;
• analytics, Search Console and Tag Manager;
• advertising and CRM accounts;
• business email and mailing services;
• payment, map and other integrations;
• design sources, fonts and licenses.

Request deployment instructions, the backup and restore process, a third-party service list, renewal dates and emergency contacts. Ongoing responsibility can be formalized through website support.

Step 14. Write defects that can be reproduced

“The form does not work” causes unnecessary back-and-forth. A useful defect report includes:

• a precise title;
• exact URL;
• device, operating system and browser;
• prerequisites;
• reproduction steps;
• expected behavior;
• actual behavior;
• screenshot or recording;
• timestamp and test data;
• priority.

For example: “On iPhone 15 in Safari, submitting valid data on /contact/ leaves an endless loader; no email or CRM lead is created.” That is much more actionable than “something freezes on mobile.”

Keep defects separate from new features. If the implementation matches the approved requirement but the desired behavior has changed, log a change request and estimate it independently.

Step 15. Retest after production deployment

After fixes, test the affected journey and nearby functions. Changing form validation can affect CRM mapping; a redirect can break language versions; script optimization can disrupt checkout.

After deployment, run this production smoke test:

1. home and primary landing pages open;
2. HTTPS and redirects are correct;
3. navigation and major calls to action work;
4. a test lead reaches the responsible person;
5. payment succeeds in the intended mode;
6. analytics records the event;
7. production is indexable;
8. sitemap and robots files open;
9. a post-release backup exists;
10. uptime monitoring is active.

For the first 72 hours, watch 404 and 5xx responses, JavaScript failures, email delivery, leads, payments, resource use and indexing. Define an urgent incident channel before release.

Copyable client checklist

Scope and evidence

• Pages and functions match the contract and specification.
• Changes introduced after kickoff are documented.
• Acceptance criteria and warranty terms are known.
• Defects are prioritized.

Journeys and content

• Critical journeys work from start to finish.
• Forms, email, CRM and confirmations are verified.
• Contact data, prices, terms and copy are current.
• No placeholders or broken links remain.
• Missing URLs return a real 404.

Devices and quality

• Real iPhone and Android devices were tested.
• Supported browsers were tested.
• No covered controls or unintended horizontal scrolling remain.
• Empty, loading and error states are understandable.

Search, data and safety

• Titles, H1, canonicals, robots and sitemap are correct.
• Redirects from old URLs were tested.
• Events and conversions reach analytics.
• Production is indexable and staging is not.
• HTTPS, roles, backups and form protection are verified.

Handover

• The company controls the domain, hosting and CMS.
• Code, database, designs, licenses and instructions were transferred.
• Temporary passwords were rotated.
• Support, service levels and emergency contact are agreed.
• A production smoke test was completed.

Deciding whether to release and pay

Final payment should follow the contract and the verified status of the scope. If no critical or high-priority defects remain and minor items have written owners and dates, the product can be accepted under the agreed process. If leads or payments fail, ownership is unclear, sensitive data is exposed, or production remains blocked from search, signing off creates an unreasonable risk.

Compare suppliers on the whole delivery, not only the opening figure. When reviewing website development prices, ask whether QA, deployment, technical SEO, analytics, training, warranty and account handover are included. Completed web design and development work also reveals process quality: inspect mobile journeys, performance and enquiry logic, not only appearance.

Conclusion

Reliable website acceptance has three layers: compliance with agreed requirements, successful real-world business journeys, and client control over every essential asset. Review blockers first, quality second and cosmetic improvements last.

The strongest handover is a shared session. The developer demonstrates completion, the client performs business journeys, and every deviation enters one acceptance register. Release then becomes a controlled transition rather than a leap from staging into live sales.