A website launch
checklist you can use.

01 / Read the markup

Ten source observations.

Paste HTML into the free preflight checker to flag common omissions. The checker processes it on your device without rendering or crawling the supplied page. Review each finding in context.

1. Page title

   Name this page and its purpose. Review the title in the browser tab; a source check only establishes whether a title is present.

2. Description

   Write a short, accurate summary of the page. A present meta description is a source observation, not a promise about how search results will display.

3. Document language

   Set the html lang value to the language used by the page. Confirm that passages in other languages are marked appropriately.

4. Mobile viewport

   Use width=device-width and initial-scale=1 as a starting point. Keep zoom available, then test the rendered layout on a phone.

5. Headings

   Give the main content a useful heading and organize its sections. Read the heading sequence; presence alone does not establish a sensible structure.

6. Image alternatives

   Describe what an informative image communicates. Use empty alt text for a purely decorative image; an automated presence check cannot choose the right wording.

7. Form labels

   Give inputs persistent labels and connect each label to its control. A placeholder can disappear during typing and should not stand in for that label.

8. Button names

   Make the action clear. Check icon-only buttons in the accessibility tree; a visible glyph does not necessarily supply a useful accessible name.

9. Canonical hint

   If you declare a canonical URL, use the intended preferred page and check that it loads. Search engines treat canonical declarations as signals, not commands.

10. Social preview title

    Check the intended title and other preview metadata. Inspect a real shared preview where practical; a source check does not test the platform’s cached result.

02 / Make the next action concrete

A flag needs a useful fix.

A placeholder-only email field is easy to miss when the empty form looks tidy. An explicit label makes the field’s purpose persistent and connects it to the input. See the MDN label reference.

<input type="email"
  placeholder="Email address">

<label for="contact-email">
  Email address
</label>
<input id="contact-email"
  name="email" type="email">

Those snippets illustrate labeling only. Test the full form, its validation and its actual success path separately.

Image text depends on the job of the image.

<!-- Informative image: describe its useful content. -->
<img src="delivery-window.png"
  alt="Delivery window: Tuesday, 9am to noon">

<!-- Decoration adds no information. -->
<img src="section-divider.svg" alt="">

Both examples have an alt attribute, but only a contextual review can decide whether its wording is appropriate. Linked images need text that communicates the link’s purpose. See the MDN image reference.

03 / Test the rendered page

Five browser passes.

Choose a meaningful route through the website, then repeat it in the relevant browsers and devices. These are review prompts, not five automatic tests.

1. Keyboard and focus

   Move through navigation, forms and dialogs with the keyboard. Watch the focus indicator, follow a logical sequence and verify that you can leave each control. Record the browser and the specific route you tested.

2. Mobile and zoom

   Try the critical pages at narrow widths and with text enlarged. Look for clipped copy, overlapping controls and unwanted horizontal scrolling. Test a real phone as well as a resized desktop window when available.

3. Links and forms

   Follow the main task from entry to completion. Check validation, errors, success states and the destination of submitted data. Use an authorized test environment for transactions; do not submit real payments or production messages as a casual check.

4. Loading and real content

   Check with realistic text, images and connection conditions. Observe loading, empty and error states. Use browser performance tools for measurement; the presence of HTML metadata does not tell you actual load speed.

5. Release operations

   Verify the intended public URL, redirects, navigation and support path after release. Confirm backups and a rollback plan with the project owner. A local build passing is one piece of evidence, not proof of the deployed customer journey.

The W3C WAI preliminary checks offer a practical accessibility starting point and explain why a first review is not a complete evaluation.

04 / Leave evidence

Make the report actionable.

For each finding, record the page, browser or device, steps, observed result and next action. Add a priority with a reason. Keep untested items visible, and record why a check does not apply instead of turning it into a pass.

See an illustrative LaunchCheck report for the shape of a handoff. The example is a demonstration, not a real customer result.