Running and Protecting Your Website

The website is finished. The work is not.

A website is not an object you buy once. It is four separate subscriptions, a pile of software written by other people, and a set of facts about your business, and every one of those decays on its own schedule. The domain expires on a date. The certificate that puts the padlock in the address bar expires on a much shorter date than it used to. The software underneath the site changes every week whether anyone is watching or not. And your hours, your phone number and your service area drift away from what the site says the moment anything changes in the real world.

None of that is a crisis, and spread across a year it is a couple of hours of attention. But the businesses around Cedar Creek Lake that actually lose a website almost never lose it to a hacker. They lose it because a card on file expired, because renewal notices were going to a designer who moved away years ago, or because the site went dark on a Saturday and nobody could remember which company held the domain.

This page is the frame: what changes and on what clock, what actually goes wrong, what deserves attention, and the short list that prevents nearly all of it.

The four clocks

Everything that can go stale on a small business website runs on one of four clocks, and they tick at wildly different speeds. Knowing which clock a thing is on tells you how often to look at it.

The domain, annually. The registration is a lease, not a purchase. It renews on an anniversary date, it is paid with a card that itself expires, and the notices go to whatever address was typed into the account years ago. A lapsed domain does not wait for you: it enters a redemption period, typically thirty days, during which only the original registrant can restore it and the fee is far above a renewal. After that it is released and anyone can take it. This is also the only clock that takes your email down with the site.

The certificate, and faster every year. The maximum lifetime of a public TLS certificate dropped to 200 days on 15 March 2026, and under the schedule the CA/Browser Forum adopted in April 2025 it falls to 100 days on 15 March 2027. Let's Encrypt, which issues the free certificate most small sites run on, stopped sending expiry reminder emails on 4 June 2025. A certificate not renewed automatically will expire, and nothing warns you first.

The software, continuously. A WordPress site sits on core, a theme and some number of plugins, each maintained by a different party on its own schedule. Patchstack, a vendor in this field, logged 11,334 new vulnerabilities across the WordPress ecosystem during 2025 and reported 91 percent of them in plugins rather than in WordPress itself. Plugin count, not brand, is the risk.

The facts, whenever your business changes. Hours, phone number, seasonal closures, whether you still do what the homepage says. This clock has no alarm on it, which is why it quietly costs the most.

What actually breaks

The honest frequency order. Notice how far down the list the hosting company appears.

1. The domain expired. Auto-renew off, the stored card expired, or notices went to an inbox nobody opens. The site does not go down so much as stop existing, and the email stops with it.
2. The certificate expired. Visitors get a full-page browser warning most will not click through, while the site and its files sit there intact.
3. An update broke something. A plugin or theme update collides with another and the site returns a white screen. This is the honest argument against unattended updates on a site with no backup - and the answer is a restorable backup, not manual updates.
4. The host moved the PHP version up and an old plugin is incompatible, or you hit a resource limit on a shared plan. Both are preventable by reading notices the host already sent.
5. A DNS change made without thinking about caching. Resolvers keep handing out the old answer for the length of its time-to-live, so lower that value before a move, not after.
6. The card declined at the host, which is the domain story again except the files are still there.
7. The host genuinely had an outage - real, and the only item here you get to blame on somebody else.
8. The site was hacked and the host suspended it. Indistinguishable from a billing problem until you ask.

Checking a domain's public status separates the first item from all the rest in about a minute. ICANN publishes the EPP status codes, and clientHold, redemptionPeriod or pendingDelete ends the investigation immediately.

Uptime percentages, and what they hide

Hosting is sold on availability percentages, which are close to meaningless at this size once converted into minutes. A thirty-day month holds 43,200 minutes, so 99 percent allows 7 hours 12 minutes of downtime, 99.9 percent allows about 43 minutes, and 99.99 percent allows about 4 minutes 19 seconds. The gap between the last two, the one vendors charge a premium for, is roughly 39 minutes a month.

What the percentage hides matters more. One four-hour outage on a Tuesday afternoon and forty-three one-minute blips at three in the morning both score 99.9 percent; the first costs you customers and the second costs you nothing. And an availability guarantee almost universally pays in service credits rather than cash, capped at a fraction of the monthly fee.

So the useful questions are not about percentages: what was your measured uptime last year, how many incidents lasted longer than an hour, and can I get a person on the phone at eight on a Saturday morning.

The short list that prevents almost everything

Ordered by protection delivered against effort spent. All of it is free or nearly free, and together it is most of the value available to a small site.

1. Unique passwords in a password manager for the registrar, the host, the site admin, the business email and the DNS. One reused password is how a forum breach from years ago becomes your problem today.
2. Multi-factor authentication on the registrar and the host first, the website second. Most small businesses do this backwards. Whoever controls the domain controls the email, and whoever controls the email can reset everything else.
3. Auto-renew on, a current card, and a multi-year registration. Registering for several years at once is the cheapest risk reduction available to an organization whose staff or volunteers turn over.
4. Automatic updates on for core, plugins and themes, and unused plugins deleted rather than deactivated. A deactivated plugin's files are still on disk and still reachable.
5. One backup you control, somewhere the host cannot reach, holding both the files and a database dump. Files alone restore an empty site.
6. Automated certificate renewal, because manual renewal is now a scheduled outage. Let's Encrypt ended its expiration notification service in 2025.
7. Free uptime monitoring, alerting to a phone and to an email address not on the domain being watched. An alert sent to an address that goes down with the site arrives nowhere.
8. Accounts removed when people leave - the previous designer, the employee who moved on, the volunteer who changed churches.

What you can safely ignore

For a five-page site with no login, no cart and no customer data:

• A paid web application firewall. A firewall filters traffic in front of an application; if there is barely an application, it filters nothing you care about.
• Malware scanning on a static HTML site. No database, no plugins, no server-side code, nothing to scan.
• Payment card compliance scanning where no card number ever touches your server, and trust seals, which verify nothing while loading a third-party script on every page.
• Denial-of-service plans and a content delivery network for a business whose customers are all within forty miles. A delivery network solves distance; your customers have none.
• Real-time backups, a staging environment and a written recovery plan document for a site edited twice a year. Weekly backups plus one before every change is fine, and the plan fits on an index card.
• Dark web monitoring add-ons. They tell you a password appeared in a breach; free services do the same and the action item is identical.

The pattern is worth naming. Almost every paid product here addresses the last tenth of the risk, and several address it badly. What a small business should pay for is somebody who answers the phone and can put the site back, which is a service rather than a subscription.

Own the accounts, and write down which is which

Three genuinely independent things get assumed to be one: who your domain name is registered with, whose nameservers answer for it, and whose server holds the site. A small business can easily have all three at different companies without knowing it. The registrar cannot fix a server error and the host cannot fix an expired domain, and calling the wrong one during an outage costs a day.

So write one page and keep it where the insurance policy is kept: which company holds the domain and the email address on that account, which company hosts the site, whose nameservers answer, the site admin address, who owns the Google Business Profile and the social accounts, and where the backups live. In our experience an hour of a four-hour outage goes to working out who to call, and this is the only thing that prevents it.

Everything on that page should be in the business's own name, on an account the business controls, paid with the business's card - not the designer's account, and not a personal address belonging to a former volunteer. That is an administrative decision, it costs nothing, and it prevents the most expensive failure in this subject: losing the domain. There is no backup that restores a domain name.

A realistic year

An honest maintenance year is much smaller than the industry implies.

Automatic, all year: updates, certificate renewal, host backups, uptime monitoring. None of it needs a human unless it reports a problem.

Once a month, ten minutes: load the site on a phone, tap the number, submit the contact form and confirm the message arrives. A form that stopped delivering is the most common silent failure on a small site.

Once a quarter: check the cards on file at the registrar and the host, and look at hours and seasonal information. Around the lake, the difference between July and February is a real content change most sites never make.

Once a year, about an hour: download the files and the database, keep them somewhere you control, and try restoring them. An untested backup is a hypothesis, and that is the moment most businesses find out they had files but no database.

That is the whole job. Anything proposed beyond it should answer one question: what does this do on the day something goes wrong?