A page can look fine and still be broken. Here's the checklist that catches it.

Nobody tells you a page is broken. It renders, it looks right, and it quietly fails for a slice of the people who load it until somebody goes looking. I went looking on four of my own live sites last month, expecting to find nothing.

I found the same problems on all four.

The resource

A page can render, pass a glance, and still fail a screen reader, leak a header nobody set, or ship live with half its scripts missing and no error anywhere. I wrote the website best-practices punchlist after finding all four of those on my own sites, and it’s the exact checklist I now run before anything ships: the interface baseline, the security headers, and the deploy-safety habits, each one with the real code to copy and the incident that put it there.

Three from it

Set color-scheme on html and match it to the page’s real theme, or a dark page gets a light-mode scrollbar and native form controls. One line of CSS.

Start a strict Content-Security-Policy in report-only mode before enforcing it. It logs every violation without blocking anything, so a wrong origin can’t take the site down while you’re still finding what it needs to allow.

After you deploy, make a real request to the live endpoint and check the actual response, not the deploy tool’s own “success” message. One of my own deploys served every static file correctly and dropped every backend function for 16 hours and 37 minutes, and it said “success” the whole time.

Get it

Read the punchlist. It’s free, there’s no signup, and every rule on it comes with the code to copy.