Checking your site
Your own device and connection can hide problems from you. Here are six checks that take about a minute each and require no special tools.
00
This is not about being careless. Owners use familiar devices, accounts, and connections that first-time visitors do not have, so they often see a different version of the experience.
A signed-in view can show content a first-time visitor never receives. A browser holding yesterday's copy shows you yesterday's page long after it changed. A connection that loads everything instantly hides what the page does on one that does not. None of that is visible from the inside, and no amount of looking harder reveals it.
What follows is six checks. Each takes about a minute, none needs a tool or an account, and each one finds something on more websites than it ought to.
Open your site signed out, in a private window, on a device that has never visited it, on mobile data rather than your own wifi. Then compare that with what you normally see.
The gap between those two views is where almost every “but it works for me” problem lives. If there is no gap, you have learned something worth knowing in sixty seconds.
Content delivery networks keep copies of your pages near your visitors, which is most of the reason websites are fast. It also means that after you change something, some people keep receiving the old copy until that cached version expires, and you may well be one of them.
So after an edit, “it still looks the same” is not evidence that the edit failed. Check from a different network or a different device before concluding anything, and expect a delay between updating something and everybody seeing it.
One script error can stop other parts of a page from working while the layout and words still look normal. The page appears to load, but forms, menus, or booking tools may no longer respond.
“The page loads” is not the same as “the page works”, and the things most likely to be silently broken are the ones that earn money, the contact form, the booking widget, the tap-to-call link.
A form can render exactly as designed and refuse every single click, because something invisible is sitting on top of it. Nothing about the appearance reveals that.
So test by doing. Submit your own contact form and wait for the message to actually arrive. Tap your own phone number on a phone. Complete your own booking. Anything on your site that you have never used yourself should be assumed broken until you have.
When the only difference between two states is their colour, a portion of your visitors receives no signal at all: people with colour vision deficiency, anyone on a dim or glare-washed screen, and anyone who simply did not notice.
If something matters, an error, a required field, which option is selected, which button is the real one, say it in words as well as in colour. It costs nothing to do and it widens who can use the site.
Some visitors navigate entirely by keyboard, through disability, injury or preference. Load your site, do not touch the mouse, and press Tab repeatedly. You should always be able to see where you are, reach everything that matters, and get back out of anything you have entered.
If you cannot complete your own contact process without the mouse, a portion of your audience cannot either, and unlike most website problems, this one carries legal exposure in the United States.
There are no citations on this page, and that is deliberate rather than an oversight.
These are not research findings. They are six things that are true about websites, learned by building them and then maintaining them for long enough to be caught out by each one. Every single one is checkable by you, on your own site, in about a minute, which is a better test than a footnote would be.
Two of the six are worth separating from the rest. The colour one and the keyboard one are not polish; they are the difference between a site some people cannot use and one they can. If you want to see what taking that seriously looks like in practice, this site publishes its own accessibility statement, including what it tests, how it tests it, and what it knows is still unresolved.
What actually moves local visibility, what cannot be moved at all, and why the usual percentages are left out.
Being found locally