Website Maintenance: The Monthly Routine I Recommend

The owners who get burned online are rarely the ones who never thought about their website. They are the ones who thought about it once, at launch, and then got busy running the business. Thirteen years in, the pattern is familiar. A form quietly stopped delivering. An update was never applied. A page had been returning an error since the host had a bad night. Nobody found out until a customer mentioned it.

What follows is the routine I would put in front of a small business owner who wants to stop finding out about problems from customers. It is deliberately mundane, and it takes about ten minutes a month: is the site answering, are the updates applied, does the enquiry path actually work, what has Google already told you, what has quietly gone stale, and what did you change last month. Every item on the list can be done in a browser.

Why a Monthly Routine Beats a Big Cleanup

What actually goes wrong between rebuilds

Sites rarely fail dramatically. They degrade. A plugin updates and breaks one form field. A price list ages by two years, one month at a time. A page starts returning an error and stays that way because nothing on the home page links to it any more. None of that is visible from the front door, which is exactly why it survives so long.

The three things you are protecting

Three things, in order of how much they cost when they break. The first is the enquiry path, because a form that has stopped working is revenue leaving the building silently. The second is your visibility in search, because a site that is down or erroring can lose its place in results. The third is the site itself, meaning the copy and the prices and the hours a customer relies on being right. All three of them exist to serve the yearly plan that the monthly routine is meant to protect.

Why monthly is the right interval

Once a month is the honest answer for most Australian small businesses, with one exception: if something has just changed, look at it that week. Monthly catches the failures that cost money slowly. More often than that and you are checking things that cannot have changed. Less often than that and a small problem gets a full month to settle in.

Start With One Question: Is the Site Answering

What a broken page looks like from Google's side

Google's documentation describes the consequence plainly, and it is worth reading once so you know what is at stake: "Any content Google receives from URLs that return a 5xx status code is ignored." It goes further for anything that keeps failing, because "For Google Search, Google's indexing pipeline removes from the index URLs that persistently return a server error." There is a softer early sign as well, since "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling." The practical reading is that a bad week is survivable and a bad month is expensive.

The two-minute check

Open the site on your phone, on mobile data rather than office wifi. Load the home page, load your main service page, load the page you would send a customer to, and submit the enquiry form. Watch the address bar rather than only the page, because a site can render a friendly error screen on top of a failing response. If everything loads and the message arrives, that is the whole check.

What to do if it fails

If the site is not answering, that is a restore job rather than a diagnosis job, and the first thing to establish is whether it is you or the whole site. Try it on a different network. If it fails everywhere, contact your host with the URL, the time and the exact response you saw, and ask for the estimated fix time. Then put the same message in your own log.

Apply Updates, But Take a Backup First

What to update each month

Whatever the site runs on, the published updates for the components behind it are the ones to apply. WordPress runs a large share of the web, which is why so much of this advice is written around it, and W3Techs, which measures platform usage, reported in October 2026 that "WordPress is used by 40.1% of all the websites, that is a content management system market share of 58.6%." The guidance from the software's own documentation is not hedged either: "You should always update WordPress to the latest version." Looking fine and being maintained are not the same thing, because the risk sits in the components you cannot see. The evidence for that is not from the core software at all. Wordfence's 2024 annual report states: "Plugin vulnerabilities remain the biggest software threat to WordPress, accounting for 96% of all vulnerabilities disclosed." It adds that "Approximately 35% of all vulnerabilities disclosed in 2024 remain unpatched in 2025." That second figure is Wordfence's own statement about the position in 2025, published in that report dated 8 April 2025, so read it as their finding at that time rather than as this month's number.

Why the backup comes before the button

Because the backup is what turns a bad update into an hour rather than a week. The software's own instructions put it first: "Before you get started, it's a good idea to back up your website." Take the copy before you press update, not after something breaks, and confirm where that copy actually lives rather than assuming your host has one. An owner with a current backup can break the site and be back before lunch. An owner without one is entirely dependent on whoever answers the phone, and on what they happen to have kept.

What to do when an update breaks something

Restore the backup, then work out which update caused it, then apply the rest. Do not start editing files at random on a live site while customers are using it. The restore is fast, it is reversible, and it buys you the time to find the actual culprit.

Test the Enquiry Path Yourself

The form test

Fill the form in as a customer would, with a real email address you can check, and confirm the message arrives in the inbox somebody actually reads. Then press reply on that email and check it goes back to a person rather than to a no-reply address nobody monitors. Do this monthly. A form that submits and delivers nothing is the most expensive failure on this list, and it is invisible from the front end.

The phone and message test

Ring the number on the site and see what happens: whether it is answered, whether it goes to a message bank somebody checks, and whether the message reaches a person. Send a text if that is offered. The number itself matters too, so read it off the page and compare it to the phone in your hand rather than to your memory.

Why your analytics will not tell you this

Analytics reports that a form was submitted, not that the message arrived. A delivery failure is a problem on the receiving side, and no dashboard sees it. That is why this check sits on the routine as something you do by hand, with a real message, every month.

Read What Google Is Already Sending You

The alerts worth opening

Search Console exists to tell you what Google is seeing, and its scope is set out in its own documentation: "Search Console provides information on how Google crawls, indexes, and serves websites." You do not have to go looking for problems, since "If new issues are found by Google on your site, you'll receive an email from Search Console alerting you." The habit is to open those emails and read them rather than filing them. If you are not set up to receive them, that is a ten-minute job and it is the cheapest monitoring available to a small business.

Page indexing, read calmly

The Page indexing report tells you, in Google's own words, to "See which pages Google can find and index on your site, and learn about any indexing problems encountered." Read it as a status report rather than a scorecard, because the same help documentation says "Remember that Not indexed is not necessarily bad." A page you never wanted indexed, an old tag page, a thank-you page, will sit in that list and belong there. Look for pages that should be indexed and are not, and ignore the ones you deliberately kept out.

Security notices are a report, not a project

If Google sends a Security Issues notice, read it and then get help the same week rather than the same year. What that notice means and what to do about the underlying problem is a specialist job, and this routine is not a security programme. The relevant point here is narrow: it is one of the alerts an owner should always open rather than skim.

Fix What Has Quietly Gone Stale

Prices, hours and service areas

Read every price on the site against what you charge today. Check the opening hours, including the public holidays nobody updated. Check the list of suburbs or regions you say you cover, because service areas drift, and a customer who books you for a suburb you stopped visiting is a bad experience for both of you.

People, credentials and contact details

Look at the team page. Somebody has left, somebody has a new role, somebody's title changed two years ago. Check the phone number, the email address and the postal address, and compare each one against your own documents rather than against the site itself. Credentials with expiry dates deserve the same look for the same reason.

Offers, dates and old claims

Any page carrying a dated offer, a seasonal promotion or a year in the heading is a page that ages badly. Either bring it current or take it down. Old claims are the quietest problem of the three, because a customer who spots a stale promise on your site will wonder what else has not been looked at.

Keep a One-Page Log of What Changed

The six columns that matter

Date, what changed, why, who did it, what the effect was, and anything to watch next month. Six columns, one line per entry, and no format to learn. The point is not record keeping for its own sake. It is so that when something breaks in four months, you have a short list of suspects instead of a memory.

Why the log saves money later

Two ways. It shortens diagnosis, because the change that broke things is usually in the last few entries. And it protects you commercially, because a site with a written history is far easier to hand to a new supplier, an agency or a buyer than one where the last three years live in somebody's inbox.

Where to keep it

A shared document that more than one person can open, not a note on one laptop. If a key employee leaves, the log should not leave with them. Put the address of that document at the top of the routine itself, so whoever runs the check can find it.

What to Do When Something Fails

Restore first, diagnose second

Get the site back to a known working state before you start working out why it broke. The backup you took before the last update is what makes that possible, and the difference in cost between an owner who has one and an owner who does not is measured in days of lost enquiries rather than in hours of effort.

Who to call, and when

Call your host when the site is down or the response is a server error and you cannot restore it yourself. Call your developer when the site is up but something inside it has stopped working. Call neither, and read the log instead, when the only change is one you made deliberately five minutes ago. If you would rather not keep a developer on retainer for a site this size, the practical side of keeping a site healthy, not just marketing it is work I do with small businesses.

What not to do under pressure

Do not start applying every pending update at once, do not install a new plugin to fix a problem you have not identified, and do not accept a change you cannot undo. Pressure is when the wrong decision gets made, which is why the backup and the log exist: they let you act quickly without gambling.

The Whole Routine on One Screen

The ten-minute version

Load the home page and your main service page on mobile data. Submit the enquiry form and check the message arrives. Apply any pending updates. Open the email from Google if there is one. Read one price and one phone number against your own records. Write one line in the log. That is the monthly minimum.

The hour version

Add the rest: walk the team page, the hours, the service areas and any dated offers. Read the Page indexing report properly. Run the phone test as well as the form test. Confirm the backup exists and that you know where it is. Review the log for anything you said you would watch. If the routine keeps turning up more than you can fix in an hour, that is the point to consider a proper one-off audit of the whole site, once the monthly routine is in place.

What to hand over to someone else

The mechanics can go to anyone, because it is browser-level work. What stays with you is the judgement about what matters commercially: which page is the one that earns, which enquiry matters, and what the site is for. For what steady site stewardship has produced for other businesses, the case studies are the honest version of it.

Frequently asked questions

How often should a small business actually look at its website?

Once a month is the honest answer for most Australian small businesses, with one exception: if something has just changed, look at it that week. A monthly habit catches the failures that cost money slowly, which are the ones owners miss. The live risks you are managing are simple, and most of them get worse with time rather than better: a form that stopped delivering enquiries, an update that was never applied, a page that has been returning an error since your host had a bad night, a price list that is two years old. None of that requires a rebuild. It requires a habit.

What happens if my site breaks and I do not notice?

Google notices, and its documentation describes the consequence plainly: "Any content Google receives from URLs that return a 5xx status code is ignored", and "For Google Search, Google's indexing pipeline removes from the index URLs that persistently return a server error." There is a softer early sign too, because "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling." The practical reading is that a bad week is survivable and a bad month is expensive. If your site comes back and stays back, Google rebuilds; if nobody ever noticed it was down, your best pages quietly stop appearing in results.

Do I have to update things if the site looks fine?

Yes, and the strongest evidence for that comes from the plugin ecosystem rather than from the core software. Wordfence's annual report states that "Plugin vulnerabilities remain the biggest software threat to WordPress, accounting for 96% of all vulnerabilities disclosed", and that "Approximately 35% of all vulnerabilities disclosed in 2024 remain unpatched in 2025." That second figure is Wordfence's statement about the position in 2025, from their 2024 annual report published on 8 April 2025. The WordPress project's own documentation says simply: "You should always update WordPress to the latest version." Looking fine and being maintained are not the same thing, because the risk is in the components you cannot see and the failure happens before the page changes.

What is the one step people skip?

The backup, and it is the step that matters most when something goes wrong. WordPress's own update documentation says that "Before you get started, it's a good idea to back up your website", and in practice that means taking the copy before you press update, not after something breaks. An owner who has a current backup can break the site and be back in an hour. An owner who does not is entirely dependent on whoever answers the phone, and on what they happen to have kept.

Should I worry about everything in Search Console?

No, and the tool's own help documentation says so, in a sentence worth remembering the next time a report makes you panic: "Remember that Not indexed is not necessarily bad." Search Console exists to tell you what Google is seeing, because it "provides information on how Google crawls, indexes, and serves websites", and its job is reporting rather than alarming. The two habits that matter are opening the alerts, since "If new issues are found by Google on your site, you'll receive an email from Search Console alerting you", and reading the Page indexing report for exactly the reason it exists: "See which pages Google can find and index on your site, and learn about any indexing problems encountered." Anything that makes sense, leave alone. Anything you cannot explain, ask someone.

Can I hand this routine to someone else?

Yes, and the routine is written so you can. It is deliberately browser-level work: opening a few pages, testing a form, applying updates, reading an email from Google, checking a price and writing one line in a document. None of it needs a developer, a server console or a log file. What you should not hand over is the judgement about what matters commercially, which stays with the owner. If the routine keeps surfacing the same problem, or if a failure needs diagnosis rather than a restore, that is the point at which paying for expertise is cheaper than guessing.