Testing website before going live: a fresh visit

Your staging run passed because your browser was never a stranger. It holds a login, cookies set on the staging domain, saved form values and scripts it already loaded. The contact form works for you because your session is still open. A visitor who arrives cold from a search result or an email has none of that. The request may still point at a staging endpoint, or the confirmation email may link to the staging domain.

• Open the live address in a private window with no saved login.
• Submit each form once and note the address its request is sent to.
• Follow the link in the confirmation email and read the domain it opens.
• Search the page source for staging, localhost and test keys.
• Check for a noindex tag or a robots rule that blocks search engines.

Many launch breaks come from settings that differ between staging and the live domain. A signup or payment form can still carry test keys, and the page looks normal until the server rejects the request. Email is the second group. Confirmation links are built from a site address set at build time. If that address still names staging, the link opens the wrong place even though the message arrived in the right inbox.

Cookies and redirects break in quieter ways. A session cookie set on the staging domain is never sent to the live one, so a sign-in that worked on staging logs nobody in live. A redirect from an old address can drop the query string and strip a coupon code or a referral tag. Neither shows up on staging, which never has the live domain's cookies or redirects to get wrong.

A stranger arrives with an empty cache, no cookies and no memory of your demo. They do not know that a menu item sits one level down. They take the site in the order they meet it, and they stop at the first step that makes them doubt the page. Your own run skips every step the browser already remembers, so it never reaches that point of doubt.

A simulated visitor starts the same way: a fresh browser, no login, and only the address you give it. It follows the links it finds, reads the screen at each step and reports where it stopped, with the request that failed and a screenshot of that moment. You do not need to know the page in advance to see that the button did nothing on a phone.

A launch break and a page problem look the same on screen: the form does nothing. The difference is where the failure lives. If the form works on staging and fails on the live address, the cause is configuration, meaning the address, the keys or the environment. If it fails on both, the page or its code is the cause. A private window on the live address separates them further. If the form fails there and worked while you were signed in, the cause is the session, not the form.

Read the request instead of the button. Open the browser's network panel, submit the form and read the address and the status code. A request that goes to a staging host is a settings problem. A request that never leaves the browser is a script problem, and its fix is in the page. Write down which one you found before you change anything, so the next run can tell you whether the fix worked.

Launch is not the last time this breaks. A new environment variable, a changed sender domain or a redirect added next month can send the form back to staging, and a stranger is the first to notice. Run the same visitors against the live address after each release. A GitHub Action can run them on every preview deploy and keep one comment on the pull request.