An arts organization here in Santa Fe spent a year losing applications and nobody could work out why. Artists would fill in the form, attach photos of their work, and hit submit. The form would tell them the image fields were required. They had just attached three images.
Some tried eight times. Some tried on two computers and three browsers. A few gave up and never applied.
The cause turned out to be one setting. iPhones save photos in a format called HEIC, and the form only accepted the older JPG and PNG. It threw the files out without saying why, then reported the fields as empty. Every artist photographing their work on a phone hit the same wall.
The website looked fine the whole time. It loaded fast, it ranked, nothing was broken on any page you could see. That is the thing about the work that happens behind a website: when it goes wrong, it usually goes wrong quietly.
Quiet failures are the expensive ones
A site that goes down gets fixed within the hour, because everybody notices. A site that quietly rejects a third of its form submissions can run for a year, because the people it fails are strangers who never tell you.
You find out from the ones who bother to complain, and they are always a fraction. In that Santa Fe case, three artists emailed. The logs showed twenty failed uploads in five days.
So the useful question is not “is the site up.” It is “is the site doing the job it was built for.” Those are different questions and only one of them is answered by looking at the home page.
Caching: the change you made is not always the page they see
Caching means the server keeps a finished copy of a page and hands that copy to the next visitor instead of building it fresh. It is why fast sites are fast, and it is worth having.
It also means that when you change something, visitors can keep getting the old version.
On that same application form, the fix went into the database immediately and then did not reach a single applicant, because the page was being served from a saved copy made before the change. The form on screen was still running the old rules. Clearing the cache was the difference between a fix that existed and a fix that worked.
This is also the explanation behind the most common piece of unhelpful advice on the internet. When support tells you to clear your browser cache and try again, they are guessing at this problem. Sometimes they are right, which is why the advice survives.
The practical takeaway: any page with a form on it should be excluded from caching. A brochure page can be cached all day. A page that has to talk back to the server should not be.
DNS: the part nobody owns until it breaks
DNS is the address book of the internet. It is what turns your domain name into the actual server your site lives on, and it also routes your email, your subdomains, and anything else attached to your name.
It is almost always the least documented thing a business owns. The domain was registered by someone who has left. The DNS is managed somewhere different from the hosting. The person who set up the email is not the person who built the site.
Two things follow from that, and both bite during a redesign.
The first is that moving a website and moving email are separate jobs that share one control panel. Plenty of sites have gone live smoothly while the client’s email quietly stopped arriving, because a record got cleaned up during the move.
The second is redirects. When a site moves or a page changes address, something has to send the old address to the new one. Skip it and every link anyone ever shared becomes a dead end. Get it slightly wrong and it is worse: I recently found a short link on a client’s site pointing at last year’s ticket page rather than this year’s, with tens of thousands of hits on it. It worked perfectly. It was sending every one of those people to the wrong event.
The practical takeaway: before any migration, write down who controls the domain, who controls DNS, and who controls email. If you cannot name all three, that is the first job.
Security is rarely dramatic
Small business owners picture a hacker. What actually happens is an automated scanner finding a plugin that has not been updated in fourteen months, and quietly adding a file that sends spam or slips links into your pages.
You often do not notice. Your visitors do not notice. Google notices, eventually, and then your traffic falls off a cliff and you start wondering what happened to your rankings.
The unglamorous truth is that most WordPress compromises come through outdated plugins, reused passwords, and abandoned accounts belonging to people who left the company. Not clever attacks. Housekeeping.
The practical takeaway: remove plugins you are not using rather than deactivating them, and audit who still has an admin account twice a year. Both take an afternoon and prevent most of what actually goes wrong.
Maintenance is a schedule, not an event
The pattern I see most often in Albuquerque and Santa Fe is a good website built well, launched, and then left completely alone for three years. Nothing catastrophic happens. It just erodes.
Plugins fall behind. A page still lists a price from two years ago. A staff bio names someone who left. A PDF link points at a file that got replaced. A form sends notifications to an address nobody checks anymore.
None of that shows up in a redesign conversation, because none of it looks like a design problem. It looks like the site is fine.
The fix is boring and it works: decide what needs checking, decide how often, and write it down. Prices and fee schedules on an annual cycle. Staff and board listings whenever someone changes. Forms tested quarterly, by actually submitting one. Plugin updates monthly. Anything with a date on it gets a date to be checked.
What to do with this
You do not need to become technical. You need to know these categories exist so you can ask about them.
If your website takes applications, orders, or enquiries, submit one yourself this week. All the way through, as a stranger would, from your phone. It is the single fastest way to find out whether the thing your site was built to do still works.
If it does not, you will have found in ten minutes what that arts organization spent a year not finding.
Email is the other half of this, and it is a big enough subject to deserve its own post. SPF, DKIM, DMARC and BIMI are four acronyms standing between your messages and somebody’s junk folder, and most businesses have two of them set up wrong. That one is coming next.