The 21 Things We Check on Every Site We Host
A client asked a fair question recently: how would they know their site had been done properly? The honest answer at the time was that they’d have to take our word for it. That wasn’t good enough, so we wrote the standard down and now measure every site against it. Twenty-one checks, four categories. Can it be found. Is robots.txt being served, does it point to a working sitemap, and is any search or AI crawler being blocked? Is there a file on the server quietly overriding what the SEO plugin thinks it’s publishing? Is the site accidentally telling search engines not to index it? Is the certificate valid and is anything still loading over an insecure connection? Can it be understood. Exactly one business listing — not two, not none — carrying a real address or a real list of towns served, a phone number, hours and services, in the format search engines and AI assistants read. Can it be quoted. A title that earns a click rather than saying “Homepage”. A description that reads like a sentence rather than a keyword list. One clear heading at the top of the page. Does it actually work. No demo content left over from the theme. No placeholder phone numbers. No contact form that accepts messages and discards them. No broken images or dead links. We ran it across every site we host. Nothing passed all twenty-one on the first pass, including ours. We worked through them until most did, and the ones that still have an open item have a named reason and an owner. The useful part isn’t the list. It’s that it’s written down and dated, so “your site is set up properly” is a thing we can show you rather than a thing we say.
New Fiber at the Data Center
The servers that run our clients’ websites and email live in a data centre rather than an office cupboard, which means redundant power, proper cooling, and a network connection that doesn’t depend on one cable. This week a second fiber line went live into our rack. The reason isn’t speed, although that helps. It’s that a single connection is a single point of failure. Fiber gets cut. Equipment fails. Providers have bad days. One line means a bad day for them is a bad day for every site and every mailbox we host. Two lines from that point on means an outage has to happen twice before anyone notices. When it went live we measured it properly rather than trusting the paperwork, and that’s worth a word. A single download test is a bad measurement. One connection to a server a long way away is limited by the distance as much as the line, so it under-reports badly — our first test showed a fraction of the real figure and looked alarming. Running several transfers at once against a server nearby gave the honest number, and the line delivers what it should. We also checked the network card’s error counters before and after, because a connection that looks fine while quietly corrupting packets is a problem that only shows up as things being slow for no reason. None of this is visible to anyone whose site we host, which is the point. Infrastructure work is successful when nobody has a story about it.
Everything Gets Backed Up Before It Gets Changed
Most of what goes wrong with a website doesn’t happen because somebody broke in. It happens because somebody changed something. That includes us. Anyone who works on live systems long enough has made a change that did something they didn’t intend. The question isn’t whether it happens, it’s how long the site is broken afterwards and whether anything is lost. So here’s how we work, plainly, because it’s worth knowing what to expect from whoever maintains your site. Before a change is made, the current state is saved. Not “there’s a backup from last night” — the specific thing about to be changed, exported first, with the exact command to put it back written down before anything is touched. Changes go one at a time, with the result checked before the next one starts. Ten changes at once means ten suspects when something breaks. Nothing is deleted. Content that’s no longer wanted gets unpublished, not removed. A file that’s replaced gets kept. Storage is cheap and regret isn’t. And the check afterwards is done against the live site, not against what the settings screen claims. A setting that says it saved and a page that actually shows the change are two different facts, and only the second one counts. We rebuilt a site this month and went in with the rollback commands written down first. We ended up needing them — something went wrong mid-way, the site went down, and it came back from a snapshot taken before the work started. Total damage: an afternoon. Without that snapshot, the same mistake would have been a genuinely bad week for somebody’s business. The discipline isn’t cautious. It’s the difference between an inconvenience and a disaster.
Getting Your Email Into the Inbox Instead of the Spam Folder
If your emails to customers land in spam, the problem usually isn’t what you wrote. It’s that the receiving server can’t confirm the message really came from you. Three records do that job. They live in your domain’s DNS settings, not on your website, which is why most people have never seen them. SPF is a list of the servers allowed to send email using your domain name. If a message arrives claiming to be from you but came from a server that isn’t on the list, that’s a flag. DKIM is a signature. Your mail server signs every outgoing message with a key, and the receiving server checks the signature against a public one published in your DNS. If it matches, the message wasn’t tampered with in transit and it genuinely came from your system. DMARC ties the two together and tells receiving servers what to do when a message fails — ignore it, quarantine it, or reject it outright. It also lets you receive reports about who is sending mail claiming to be you. Get all three right and Gmail, Outlook and the rest have a reason to trust you. Get them wrong or leave them missing and you’re asking to be trusted on the strength of nothing. A few things worth knowing that cost people deliverability without their realising: Forwarding breaks SPF. If mail is forwarded from one address to another, it arrives at the final destination from the wrong server and fails the check — and the failure counts against whoever forwarded it. Sending from a Gmail address while your website claims to be your own domain is a mismatch, and a small one that adds up. And a sudden change in how much mail you send looks suspicious even when it’s legitimate. If your mail is landing in spam, these are the first things to check, and they’re checkable in minutes.
Six Months of Email Nobody Was Scanning
Here’s a failure mode worth understanding, because it applies to more than email. The mail server we run scans every message for viruses before delivering it. Standard stuff. Earlier this year we went looking through the logs for an unrelated reason and found the same line repeating on every message, going back six months: the scanner had failed, and the message had been passed through unchecked. Every single message. For half a year. No alert, no bounce, no error anyone would see. Mail arrived normally. The dashboard looked fine. The cause was mundane — a software update had recreated a system account without the permissions the scanner needed to talk to the mail system. Each piece was running. They just couldn’t reach each other any more, and the failure had been designed to fail open so that mail kept flowing. That design decision is defensible. Blocking everyone’s email because a scanner is down would have been worse. But it means the failure is silent, and silent failures last exactly as long as nobody goes looking. Two things came out of it. We fixed the scanner, and we now monitor for the failure message itself rather than for the scanner being “up” — because it was up the whole time. Up and useless. And it changed what we look at during maintenance. A service that’s running tells you nothing. A service that’s producing the result it’s supposed to produce is the only thing worth checking. Anything that logs a failure on every single transaction should be screaming, and if it isn’t, that’s the real problem. Most of what we found across our systems this month was some version of this: something running, logging success, and producing nothing.