Website checklist before launch, step by step

A checklist asks whether each thing works, and each thing usually does. A stranger does not test items. They follow a path: an old link, a redirect, a homepage, a booking form, a confirmation. The usual breaks sit between those steps. A noindex tag left from staging, a contact form that posts to an inbox nobody reads, a cookie notice that covers the first button on a phone, or a redirect that sends the old address to a page that no longer exists. Each one passes when checked on its own page, and the owner signs off. The stranger can meet one of them before the first screen is done.

• Does an old link or a search result land on the new site, on the same domain and over https?
• Where does each form send its message, and does a reply reach a real inbox?
• Is any password screen, test banner or noindex tag still showing on the live pages?
• Does a cookie notice or chat widget cover the first button on a phone?
• Do the header and footer links go where their labels say they go?

The homepage is the one page everyone checks, so it is the one page most likely to be right. A stranger rarely starts there. They come in through a link that someone saved years ago, a search result for a page that moved, or a bookmark to the old domain. Wrong: the checklist says 'redirects work' because the old homepage opens. Right: open three old addresses from different places, such as a deep product page, a blog post and a PDF link, and confirm each one lands on the matching new page, on one domain, over https.

Watch for a redirect that works once and then loops, and for a page that loads on the www address but not the bare one. A visitor who sees the address bar change twice before the page appears decides the site is broken, even when the final page is fine. Read the run step by step, not just the last page, so the owner can see the chain of addresses instead of trusting the final page.

Staging copies carry settings that were never meant for real visitors. A password screen, a noindex tag, a test banner, a payment provider still in test mode, or an analytics ID that belongs to the old project can all survive a copy to live. The owner checks the staging address and everything looks finished. The live address is the only place where a stranger meets these, so check the live address.

A contact form is the clearest case. The owner sends a message, receives it in the staging inbox, and marks the item done. The live form posts to the same staging address, which nobody reads. Send one message from the live domain, then read it in the inbox that will answer customers. A confirmation email to the visitor shows that the form sends something. It does not show that the message reaches the team that will answer it.

A cookie notice, a chat bubble or a sticky header can sit over the button a stranger needs. On a laptop the overlap may not show. On a phone the notice can take up much of the first screen, and the visitor taps it instead of the call to action. Check the first screen on a phone with every overlay open, then with the notice closed, and make sure the main button is reachable both ways.

Anchor links cause a similar problem. A link that jumps to a section can scroll the heading under a sticky header, so the visitor sees the section title cut off and wonders whether they landed in the right place. A simulated visitor who reads the title and says it is missing has found the bug, even though the link technically worked.

Each later release can bring back a staging setting, add a redirect that loops or put a new banner over the first button. Rerun the same visitor paths after every release that changes a page a stranger uses, not only before the first launch. Keep the old run to compare, so you can see which step changed and which release changed it.