Check a business website before launch
Review visitor tasks, copy, mobile use, accessibility, downloads, old links and handover. Each launch check has an owner and useful pass evidence.
A launch review should show that the website works for its intended visitors and can be operated by its owner. Record what you checked, what you found and who resolved it. A screenshot of a finished homepage is only one small part of that evidence.
Use the checklist below as a working review, adding checks for the actual features in your project. A brochure site and a shop have different operational risks.
Begin with three real visitor tasks
Choose tasks from the approved brief. For the fictional Alder & Grain workshop, they are: decide whether an item is within scope; understand the assessment sequence; and prepare a useful enquiry.
Ask someone unfamiliar with the draft to attempt those tasks on both a phone and a larger screen. Do not tell them which link to click. Note missing answers as well as broken interactions. If the page says “contact us” but never tells the visitor what information to prepare, the link can work while the journey remains incomplete.
Content and navigation checks
| Check | Useful pass evidence | Suggested owner |
|---|---|---|
| Business identity and offer | The factual approver has checked the visible name, scope, location claims and current services | Business owner |
| Contact information | Each published address, telephone link or email route has been checked against the real business details | Business owner |
| Service or product limits | Exclusions, compatibility and important conditions appear beside the relevant offer | Content approver |
| Draft residue | No sample names, unapproved claims, empty pages or temporary instructions remain | Editor |
| Main journeys | A new reader can find the service, limitation and next step without prompting | Reviewer |
| Navigation and body links | Links reach the intended useful destination; labels describe it | Editor and developer |
| Missing pages | An unknown address produces a genuine 404 with useful navigation | Developer |
| Retired destinations | Deliberate removals have the intended response and explanation | Developer and content owner |
| Images and downloads | Files open, are accurate, have suitable rights and are identified clearly | Content owner |
| Policies | The policy pages describe the actual features and information handling of the site | Business owner |
Checking content is more than proofreading. “Same-day repairs” remains a problem if the workshop has never agreed to provide them, even when the sentence is perfectly spelled.
Usability and accessibility checks
W3C's Easy Checks provide an initial accessibility review. They can expose common barriers; passing a short review does not establish complete conformance.
| Check | What to inspect | Evidence to record |
|---|---|---|
| Keyboard journey | Work through navigation and controls without a mouse; the current focus should be visible | Pages, controls and any stopping point |
| Heading structure | Read the headings as an outline and check that they describe the sections | The reviewed pages and fixes |
| Link purpose | Confirm a reader can predict the destination from the wording and context | Ambiguous labels corrected |
| Image alternatives | Check whether meaningful visual information is available in text | Image and alternative-text decisions |
| Text enlargement | Enlarge text to 200% and inspect for hidden or overlapping content | Browser, page and result |
| Narrow layout | Inspect a 320 CSS-pixel-wide viewport or equivalent zoomed layout | Any content or controls that cannot be reached |
| Colour and state | Check text contrast and whether meaning depends on colour alone | The colour combinations and tool or method used |
| Video or audio | Check the alternatives needed for the actual media | Caption, transcript and descriptive-information review |
The text-enlargement and narrow-layout checks relate to W3C's Resize Text and Reflow guidance. Reflow has exceptions for content that needs a two-dimensional layout, such as some tables; the surrounding page should still remain usable.
For features beyond these checks, agree an appropriate accessibility evaluation with someone able to assess them. A score from an automated scanner is evidence about its checks, not a review of every user experience.
Technical and handover checks
| Check | Useful pass evidence | Suggested owner |
|---|---|---|
| Final web address | The intended HTTPS address works, and host variants behave as agreed | Developer or host |
| Search metadata | Distinct titles and descriptions match the visible pages | Editor |
| Indexing settings | Public pages have the intended indexability; staging controls have not carried into production | Developer |
| Sitemap | It contains the intended public canonical pages and excludes drafts and removed destinations | Developer |
| Historical links | Important old paths and meaningful queries reach the agreed result | Developer |
| Device review | Main templates work with the actual copy on representative phone and desktop sizes | Designer and reviewer |
| Credentials and accounts | The business has the agreed access and understands which services recur | Business owner |
| Backups and recovery | The responsible party can explain what is backed up and how recovery is requested or performed | Developer or host |
| Routine changes | The owner completes an agreed editing task or knows the support procedure | Owner and supplier |
| Support handover | Fault reporting, responsibility and response expectations are recorded | Owner and supplier |
If the site contains forms, orders, payments or logins, add end-to-end checks for those functions, including failure cases. Do not tick them as complete merely because a control is visible.
Example of a useful findings log
Fictional review record: these findings demonstrate the format and are not claims about a real client website.
| Finding | Decision | Owner | Evidence needed to close it |
|---|---|---|---|
| The repair page omits the upholstery exclusion | Correct before launch | Content owner | Approved exclusion appears beside the scope |
| A menu link cannot be reached by keyboard | Correct before launch | Developer | Repeat the keyboard task successfully |
| The workshop image is decorative but has a long repeated description | Improve before launch | Editor | Alternative-text decision matches its purpose |
| A future article idea has no approved facts | Leave it out of the release | Content owner | No empty page or navigation promise is published |
Decide whether to launch
Separate issues that prevent a main task, publish inaccurate information or expose something private from optional refinements. Resolve launch blockers and retest the affected journey. Record a responsible person and date for any remaining improvement rather than leaving a vague list of “snags”.
Keep the completed review with the website brief. If this is a replacement site, include the redesign URL decisions. After launch, verify the important journeys again on the public address because hosting behaviour can differ from the preview.
The source notes
Sources and further reading
- W3C: Easy Checks – A First Review of Web Accessibility Checked 4 November 2026
- W3C: Understanding Resize Text Checked 4 November 2026
- W3C: Understanding Reflow Checked 4 November 2026