A practical website checklist before you launch.

1. Decide what you are releasing

Write down the intended audience, the pages included, and the main action you want a visitor to complete. A private review site and a public launch have different access requirements. Test the intended sign-in or sharing settings rather than assuming a hard-to-guess address makes the site private.

Google’s noindex rule concerns search results; it is not an access restriction. Keep private material behind appropriate access controls. Change search settings only for pages you deliberately want discoverable, and remember that Google needs to crawl an accessible page to see its noindex instruction.

Sources: [1]

2. Walk through the main visitor tasks

Choose three routes that represent the site’s purpose. Start from the page a visitor is likely to land on, not only the homepage. ATN suggests these routes for a small resource directory:

Record the destination reached, not just that you clicked a button. An active-looking control that does nothing should be fixed, removed, or clearly explained before people rely on it.

3. Check mobile and keyboard use

Review important pages on a narrow screen and at increased zoom. Look for clipped text, tables that cannot be read, overlapping controls, and menus that hide the next action. Then use the keyboard to reach navigation, links, forms, and their visible focus indicators.

W3C’s Easy Checks also cover page titles, headings, image alternatives, contrast, and form labels. Use those checks as a starting point and include captions or transcripts where relevant. Passing a quick review is not proof of full accessibility; record the scope of the checks you actually performed.

Sources: [2]

4. Confirm the pages work as pages

Open important page addresses directly and refresh them. Check missing-page behavior, image loading, page titles, and internal links. A page that only works after navigating from the homepage may leave visitors stranded when they follow a shared link.

For public pages intended for Google Search, the minimum technical requirements include crawler access, a successful HTTP response, and indexable content. Meeting those conditions does not guarantee indexing. Use the relevant Search Console reports and URL Inspection after launch when available; do not remove deliberate privacy controls just to satisfy a search checklist.

Sources: [3]

5. Check the promises you make

Review claims about prices, offers, reviews, and testing against the evidence you actually hold. Show unresolved information plainly. Confirm that contact and signup forms reach the intended destination, explain required fields, and display a truthful success or error message. Use authorized test details and remove test records afterwards.

Check any disclosures and privacy information against the features that are active. Do not leave a working-looking subscription form on a page if there is no process behind it. A small site with a clear contact route is more useful than a larger set of unfinished promises.

6. Keep a recovery and follow-up note

Save the release version and know how to restore the last working version. Record any settings changed during launch, especially domain, access, and search settings. Assign someone to check reported problems and repeat the main visitor routes after a significant update.

Finish the release note with three short lists: checked, unresolved, and next review. A known limitation can be managed when it is visible. An untested feature should stay marked untested until someone completes the relevant check.