Your website was built years ago as a set of plain HTML pages. There is no WordPress, no dashboard, no plugins to update. Someone told you that means it needs no maintenance at all, and for a long time that seemed to be true. Then the contact form started delivering nothing but spam, and the only person who knew how to edit the pages had moved on.
Static website maintenance is lighter than looking after a WordPress site, but it is not zero. The work moves from updating software to keeping the surroundings in order: the hosting, the domain, the certificate, the form, the scripts the pages load, and the ability to change anything at all. This post covers what a static or hand-coded site still needs, how editing works when there is no CMS, and when it is time to stop maintaining it and move it somewhere else.
What “static” means for upkeep
A static site is a set of files, usually HTML, CSS, JavaScript and images, that the server sends to visitors exactly as they are. Nothing is assembled from a database when someone visits. That is the reason static sites are fast and hard to break into: there is very little running on the server for an attacker to exploit.
The same description covers two quite different kinds of site:
- Hand-written HTML sites, where each page is a file someone edited directly, often built from a template years ago.
- Sites built with a static site generator, such as Hugo, Jekyll or Eleventy, where content is written in simple files and a tool turns it into HTML pages. These are usually kept in version control and published by a build step.
Most small businesses with a static site have the first kind. Much of what follows applies to both. If you are still weighing whether a static site suits your business at all, the post on what a static site costs and when not to buy one covers that decision.
Static website maintenance: what still needs doing
The domain and hosting
Both still renew, and both still have accounts that can be lost or compromised. Make sure each is in your business’s name, the contact email is one you read, and the renewal dates are in a calendar. A static site on hosting that lapses is just as offline as any other.
The security certificate
Most hosts now issue and renew certificates automatically, but older hosting arrangements sometimes still rely on a certificate someone installed by hand. Check when yours expires. Also check that every page loads over HTTPS without warnings. Older HTML sites often have images, scripts or fonts hard-coded with plain “http://” addresses, which browsers flag or block. The guide to fixing mixed content warnings explains how to find and correct them.
The contact form
This is the weak point of almost every static site. A static page cannot send email by itself, so the form relies on something else: a small PHP script on the server, a third-party form service, or a mailto link. Each has its own failure mode. Old PHP form scripts can be abused to send spam and may stop working when the host upgrades PHP. Form services change their terms or plans. Mailto links only work if the visitor’s device has an email app set up, and on a shared or work computer it often is not. Test the form regularly, and if it relies on an old script, have someone look at it.
The scripts the pages load
A static site may have no plugins, but it often loads JavaScript libraries: an old copy of jQuery, a slider, a lightbox, a framework such as Bootstrap. Old versions of these can have known security problems or stop behaving well in current browsers. They do not update themselves. Someone needs to check which versions are in use and whether anything visible depends on them before replacing them.
Tracking and third-party code
Analytics tags, chat widgets, map embeds and social buttons were usually pasted into each page when the site was built. Some of those services have since changed or shut down. Google’s older Universal Analytics, for example, was replaced by Google Analytics 4 and no longer collects data, so a static site still carrying only the old tag is recording nothing. Check what each snippet is and whether it still does anything.
Links, layout and content
Broken links, out-of-date details and pages that look wrong on modern phones affect static sites exactly as they affect any other. Many older templates were built before phones were the main way people browsed, and may not adapt well to small screens.
HTML website maintenance when there is no CMS
The biggest practical difference is editing. With no dashboard, changing a phone number means editing a file and uploading it. That is easy for someone comfortable with code and very easy to get wrong for someone who is not.
Keep one master copy
The single most useful habit is to keep a complete copy of the site’s files somewhere safe, and to always edit that copy and upload from it. Problems start when one person edits files directly on the server, another edits an old copy on their laptop, and the next upload overwrites the first person’s changes.
Change a repeated element everywhere
On a hand-coded site the menu, header and footer are often copied into every page. Changing the phone number in the footer may mean editing twenty files. Search all the files for the old text before uploading, or a few pages will keep showing the old number for years.
Back up before every upload
Download the current files from the server before replacing them. If the upload breaks a page, you can put the old version back in a minute.
Consider version control
For anyone editing the site regularly, keeping the files in a version control system such as Git gives a full history of every change and who made it. For a site edited twice a year it may be more than you need.
A lighter rhythm, not no rhythm
Because there is no CMS to patch, a static site does not need the frequent update cycle a WordPress site does. A sensible routine is to test the form and check the certificate regularly, review the domain and hosting renewals, look over the content and links every few months, and have the scripts and templates reviewed once in a while by someone who reads code. The general signs that a site has been left too long, such as stale dates and broken pages, are listed in the post on recognising when a site needs attention, and most of them apply to static sites unchanged.
Many lists of the best website maintenance services assume every site runs WordPress, and a static site can fall between providers. When you talk to anyone about looking after one, say upfront that it is hand-coded or generated, and ask whether they are comfortable editing HTML directly.
When to stop maintaining it and move
A static site is a good choice for as long as it fits the business. These are the signs it no longer does:
- You want to make changes often, and waiting for someone who can edit code has become the bottleneck.
- You need features a static site handles awkwardly: a blog you post to weekly, online booking, a shop, logins for customers.
- The template is so old that making it work well on phones would mean rebuilding most of it anyway.
- Nobody left in the business, or among your contacts, understands how the site was built.
If several of those apply, maintaining the static site may cost more effort than replacing it. Moving to WordPress gives you a dashboard for everyday changes, at the price of the regular upkeep that comes with a CMS. It is a trade, not an upgrade in every respect. Weigh it against how often you actually change the site.
Common mistakes with static sites
- Assuming “static” means “secure, full stop”. The hosting account, the FTP password and any form script are still targets.
- Losing the source files. If the only copy is on the server and the hosting lapses, the site is gone.
- Editing live files directly. One typo in a shared header can break every page at once.
- Keeping a PHP form script nobody understands. If it is old and unmaintained, replace it rather than hoping.
If the static site has run its course
If you have decided the hand-coded site has done its job and you want something you can edit yourself, our move to WordPress service covers rebuilding an HTML site on WordPress, keeping page addresses where possible and redirecting the ones that have to change.
Next in this series: Website Maintenance During a Redesign
