Check my website errors: what visitors see

Errors that hit some visitors usually depend on state your browser always has. A script that loads only when a cookie is missing never runs for you, because you set that cookie long ago. A deploy can remove a file that a cached copy of the page still asks for, so a returning visitor sees a missing file while your own refresh loads the new page cleanly. A chat widget or payment widget can fail to load when a visitor has an ad blocker on, and the form beneath it stops working. None of these show on your own screen, which is the only screen you check.

• Open the page in a private window with no saved login and watch the console from the first load.
• Look for requests to your own files that come back as missing, such as a script or stylesheet.
• Load the page with an ad blocker on and see whether a widget or form stops working.
• Submit a form with browser autofill on, the way a phone browser fills it in.

Your browser is the worst possible test for a site you built. It has your login, a set of cookies from every visit you have made, and copies of every file the site has served you. Those saved pieces let the site work in ways it will not work for a stranger. A new visitor arrives with none of them, loads everything fresh, and runs the scripts that only run when nothing is saved yet. The fix is not to clear your cache and hope. It is to run the same pages as someone who has never been there, in a browser with no history, so you see what they see.

The console lists errors with the file and line where they happened, and the network list shows each request with a status. A red line that names a script is a clue, but not yet a bug, because the script may fail on a page nobody visits. A request that returns a missing-file or server error is more useful, since it names the address that failed. Match each one to the step you were on when it appeared. An error that shows up on the same step for every new visitor is the one to fix first. An error that shows up once is worth writing down, since the next deploy can make it hit many visitors.

Not every red line hurts anyone. An analytics script that fails, a font that does not load and a warning about an old browser feature can all appear while the form still works. Errors that matter stop a step: a button that does nothing, a field that never validates, a page that stays on a spinner, or a request the next step needs and never gets. Sort the list by what the visitor could not do, not by how loud the message is. Keep the ones that block a step at the top, and rerun those steps after each fix, so you can see whether the blocked step moved on.

Errors that hit some visitors come back with every deploy that renames, moves or removes a file, and with every change to a third-party widget. Rerun the same visitors after each release, starting from the same page and the same step, so an error that returns shows up where it did before. A test behind a login uses a test account you give the visitors, so the signed-in pages sit on the same list as the public ones.