--- title: "Website Maintenance Checklist: What to Check Each Month" url: "https://healywebdesign.co.uk/news/website-maintenance-checklist/" type: "post" published: "2026-10-28T10:00:00+00:00" modified: "2026-10-17T21:00:57+00:00" author: "leehealy" --- A useful website maintenance checklist gives you a repeatable way to check that your website still works for your business. Each month, review recovery arrangements, software updates, enquiry forms, important links, mobile usability, renewals and access. Record what you checked, what happened and who will deal with anything outstanding. For a business owner, the aim is to understand the condition of the website without needing to become its developer. You should be able to ask straightforward questions and get answers supported by actual tests. This guide sets out a practical monthly review for a business website. Adapt it to the services you use and the importance of the site to your day-to-day work. Urgent faults and security updates may need attention between reviews. ## Your monthly website maintenance checklist at a glance Use these ten checks as the starting point for your own record: - Confirm the person responsible for the website and the route for urgent help - Check recent backup results and the evidence from a restoration test - Review completed, failed and outstanding software updates - Submit a test enquiry and confirm it reaches the right person - Open important pages, links and downloads - Complete a customer task on a phone and check basic keyboard access - Review domain, certificate, hosting and licence renewal arrangements - Check who has access and whether their permissions are still appropriate - Investigate recurring errors, outages or noticeable changes in loading - Record factual corrections, unresolved issues, owners and next steps Keep this list alongside the previous month’s findings. A recurring problem should remain visible until someone has checked the fix. ## 1. Establish who is responsible before checking the technology Start with a short record of the services behind your website. Include the domain registrar, hosting provider, website platform, maintenance contact and any service responsible for sending form notifications. These may belong to different companies, even when you receive one invoice. For each service, record the account owner and who can obtain support. Keep passwords and recovery codes in an appropriate secure system, separate from an ordinary maintenance report. The report should explain how an authorised person obtains access without displaying the credentials themselves. Agree what your business checks and what a supplier checks. For example, your office manager might confirm that opening hours are correct, while a developer investigates failed updates. The distinction makes it easier to report a problem to someone who can resolve it. Also decide what happens when the usual contact is away. If a form stops working on a Friday afternoon, the business needs a known route for reporting it and an alternative contact method for customers. At the monthly review, ask whether any of these details have changed. A new employee, supplier change or expired support arrangement can leave a previously sensible process incomplete. ## 2. Check backup coverage and restoration evidence Find the most recent successful backup and compare its date with the schedule agreed for your website. Read any failure notices rather than assuming the scheduled job completed. Ask what is included, where the copies are held and how far back the available versions go. For a typical WordPress website, full recovery requires both the database and the website files. A database contains material such as posts and settings, while files include themes, plugins and uploaded media. The [official WordPress backup guidance](https://developer.wordpress.org/advanced-administration/security/backup/) explains why these components need to be considered together. Choose backup frequency around what your business could reasonably recreate. A website that changes several times a day has different recovery needs from a small information site updated occasionally. Put that decision in writing so the expected age of a recovery copy is clear. Then ask when a restoration was last tested. The [NCSC’s backup recommendations](https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks) include regularly testing recovery and keeping backup copies protected and separate from the systems they support. A successful backup message alone does not establish that a usable website can be recovered. Have a competent person carry out a restoration exercise in an isolated environment, with outgoing notifications and live connections controlled. Record which backup was used, what was restored, which pages or functions were checked and any problems encountered. Avoid experimenting with a full restore over the live website. Your monthly question is whether the evidence is recent enough for the site’s current setup. Agree a suitable testing interval with your technical contact and revisit it after substantial changes. If recovery has never been tested, give that work a named owner and a date. ## 3. Review updates and the plan for reversing a failed change Ask for a concise list of updates applied since the previous review, together with anything delayed or unsuccessful. For WordPress, this should cover the core platform, themes and plugins. Your hosting provider or developer should also explain who looks after the underlying hosting software. WordPress recommends backing up before an update so the website can be restored if a problem occurs. Its [updating documentation](https://wordpress.org/documentation/article/updating-wordpress/) provides the platform-specific guidance. A developer should select the appropriate procedure for your installation, particularly where the site has custom functionality. An update record should answer three practical questions: what changed, what was tested afterwards and what would happen if an important function failed. For a more substantial change, agree the test environment, timing and recovery approach in advance. The [NCSC’s vulnerability management guidance](https://www.ncsc.gov.uk/collection/10-steps/vulnerability-management) recommends prompt security updates, monitoring update status and having a rollback strategy. It also advises using supported software. A monthly meeting should therefore review how updates are being managed, rather than becoming a reason to postpone an urgent security fix. Ask about exceptions in plain language. If a plugin update has been held back, what is the reason, what is the risk and what is the next action? A repeated entry saying only “awaiting compatibility” leaves the business without a decision to make. After a change, repeat the relevant customer tasks. If the form component changed, test an enquiry. If the menu changed, test navigation. Agree who can authorise recovery and how newer content or submissions would be protected before reverting anything. ## 4. Follow an enquiry all the way to the person handling it Test every important public enquiry form using clearly labelled test information. Use an address you control and tell the receiving team what to expect. Avoid adding real customer details to a test or triggering an appointment, charge or other commitment unnecessarily. Work through the complete sequence: 1. Find the form through the route a customer would use 2. Check that the fields and instructions make sense 3. Send a clearly identified test message 4. Read the confirmation shown on the website 5. Confirm the notification reaches the intended destination 6. Ask the person responsible to acknowledge that it is visible and usable If the form sends an acknowledgement to the visitor, check that too. Read the wording, sender identity and any promised response time. A message written several years ago may describe a process the team no longer follows. Keep a simple inventory when the website has several forms. A general enquiry, recruitment enquiry and quotation request might have different destinations. Testing one does not prove the others reach their intended recipients. For example, imagine a business has moved enquiries from an individual employee to a shared mailbox. The visible website might look unchanged, while a notification setting still points to the former address. A dated test provides a straightforward way to identify that mismatch. If delivery fails, capture the page address, test time and visible result for your technical contact. Check the relevant inbox and spam folder, but avoid repeatedly changing settings without understanding the cause. Once corrected, run the same test again and record receipt. Close the issue only when the full route works. ## 5. Open the pages and links customers depend on Create a small list of priority pages that reflects how people actually use your website. Include the main service pages, contact page and any page currently linked from an advertisement, email signature or printed material. Open these pages while signed out of the website administration area. Click the important links, including telephone links, email links, map links and downloadable documents. Check the destination as well as whether anything opens. A link can load successfully and still be wrong. A brochure button might open last year’s document. A location link might point to an old office. A service page might send visitors to an unrelated enquiry form after an edit. For larger sites, a technical link-checking tool can help identify pages needing inspection. Ask for a prioritised list rather than a long export with no explanation. Test reported problems before deciding what to change, because some external services restrict automated checks. Record the original page, the link text, the destination and the expected result. Those details save time when someone else makes the correction. Repeat the click after the change, including on any page where the same link appears elsewhere. ## 6. Complete real tasks on mobile and with a keyboard Choose a familiar customer task and complete it on a phone. For example, find a particular service, read the details, open the contact options and send a test enquiry. Note the phone and browser used so a reported problem can be reproduced. Watch for practical obstacles: a menu that will not close, a banner covering a button, text obscured by a floating contact widget or fields that are difficult to complete. Rotate the device where useful and check that the page remains workable when text is enlarged. Include a basic keyboard check on a desktop or laptop. Move through links and controls using the keyboard, checking that the current position is visible and that you can move onwards. Review form labels and error messages. [W3C’s Easy Checks](https://www.w3.org/WAI/test-evaluate/preliminary/) offers introductory checks for these issues and explains that passing them does not establish complete accessibility. Keep the monthly review focused enough to repeat. Choose changed pages and important customer tasks, then arrange specialist investigation when a problem needs deeper assessment. A screenshot helps show a visual fault; a short description of the exact sequence helps explain an interaction that failed. ## 7. Review domain, certificate and service renewals Maintain a renewal record covering your domain, hosting and paid services the website depends on. Include the renewal date, supplier, responsible person and how renewal is handled. Check that the supplier has a current contact address and that an authorised person can access the account. Where automatic renewal is enabled, review the actual status and any payment warnings. Following a renewal, verify the updated expiry date or confirmation. Treat an expected future renewal and a completed renewal as separate entries. For a .uk domain, [Nominet’s renewal guidance](https://registrars.nominet.uk/uk-namespace/registration-and-domain-management/renewals/) describes the registrar’s role in renewing on behalf of the registrant. Ask your registrar about the process for your own domain rather than assuming the same rules apply to every extension. Also ask who monitors the website’s HTTPS certificate and responds if renewal fails. Certificate renewal should normally be automated and monitored by the responsible technical provider. [Let’s Encrypt’s integration guidance](https://letsencrypt.org/docs/integration-guide/) covers automated renewal considerations for services using its certificates. Open the public website and investigate any browser security warning promptly. Do not train staff or customers to bypass warnings. Your monthly record should identify the person dealing with an alert, while time-sensitive certificate monitoring continues between reviews. If several suppliers are involved, confirm which one owns each task. Paying for hosting does not, by itself, explain who manages the domain account or every separate licence. ## 8. Check access against people’s current responsibilities Review the people with access to your website and associated services. Start with privileged accounts, then check suppliers, temporary collaborators and employees whose responsibilities have changed. Make sure every account has an understood purpose. WordPress uses roles and capabilities to control what people can do. For example, an Editor and an Administrator have different default permissions. The [official roles documentation](https://wordpress.org/documentation/article/roles-and-capabilities/) explains these distinctions. Ask your developer to check the actual permissions on your installation, because plugins and custom changes can alter them. Avoid giving someone administrative access simply because it is the quickest option. Establish the work they need to perform and choose appropriate access. When someone leaves or a supplier finishes a project, follow a controlled handover rather than waiting for the next monthly review. Check that the business retains a reliable way to recover its important accounts. A domain or hosting account tied solely to a former employee’s personal contact details creates an avoidable operational dependency. Ask whether multi-factor authentication is available and appropriately configured for privileged services. Review who receives security alerts. If an unfamiliar administrator appears, investigate promptly with your technical contact instead of treating it as routine tidying. Record access-review decisions without copying passwords, recovery codes or unnecessary personal information into the report. ## 9. Look for recurring faults and changes in loading Read the month’s availability alerts and support tickets together. Look for repetition: the same page failing, an intermittent form problem or a service interruption that has returned after an apparent fix. Ask what a monitoring alert actually checks. A service may confirm that a page responds without testing the menu, form delivery or the information on that page. Your human checks should cover the tasks that matter to the business. When a page feels noticeably slower, write down which page, device and connection you used. Repeat the observation before drawing a conclusion from one visit. If your technical team uses performance measurements, compare like-for-like tests and request an explanation of meaningful changes. Recent additions can provide useful clues. A large document, new image gallery or third-party widget may be worth examining. Let the person investigating establish the cause before removing features or buying extra services. The useful outcome is a clear description of the impact and a next step. “Visitors cannot open the mobile menu after the banner appears” is more actionable than “the website seems bad”. ## 10. Check the facts that changed in the business Review the website against recent business changes. Have opening hours, contact details, staff responsibilities, service availability or locations changed? Are dated announcements still relevant? Does a downloadable document contain an old telephone number? Give particular attention to information that can cause wasted journeys or unhelpful enquiries. If a service is temporarily unavailable, make sure the pages and contact instructions reflect the current position. Agree the wording with the person responsible for that service. Use this review to find inconsistencies across repeated details. A number updated on the contact page might remain unchanged in a footer, downloadable guide or older service page. Keep a short list of the places that contain important shared information. Where a page includes a policy or specialist statement, refer proposed changes to the appropriate owner rather than guessing at the wording. Monthly maintenance can identify that a review is needed without claiming that a quick editorial check establishes legal or technical compliance. ## Finish with a maintenance record someone can act on Keep one dated record for each review. For every check, include the result, relevant evidence and any action required. A simple document or spreadsheet is sufficient if the people responsible can access it and understand it. Use clear status descriptions such as checked successfully, issue found, awaiting information or not tested. Avoid marking a check complete when nobody had access to the necessary evidence. For an outstanding issue, record: - The affected page or service - What happened and how to reproduce it - The practical consequence for customers or staff - The person responsible for the next action - The agreed target date or next decision - The result of testing after a correction For example, a hypothetical entry might say: “Quotation form on the maintenance-services page: message displayed as sent, but the shared inbox received nothing. Developer investigating delivery. Office manager to repeat the test after correction.” This gives the next person enough context to continue. Review the previous month’s open items before starting a fresh list. If an issue remains unresolved, decide whether it needs escalation, a different approach or an explicit business decision. Repeatedly copying it into another report can hide the fact that nothing has changed. ## Decide what needs attention between monthly reviews Monthly maintenance is a useful point for reviewing evidence and allocating work. Some activities need a different rhythm according to the website’s importance and how quickly a failure would affect the business. Arrange more frequent enquiry tests if the site is a major source of time-sensitive leads. Set backup frequency around content and data changes. Agree who receives availability and renewal alerts, and how quickly they should respond. Repeat relevant checks after updates, new forms, changes to notification addresses and other releases. Review access when people join or leave. Correct inaccurate opening information when it changes. A periodic deeper review can cover recovery exercises, account ownership and the continuing suitability of the services behind the site. Choose the interval deliberately with your provider. There is no single schedule that suits every business website. ## Website maintenance checklist FAQs ### Is a monthly website check enough? A monthly review is a sensible way to organise the overall process, but it should sit alongside the checks and alerts your website needs between reviews. A failed enquiry route, an outage or an urgent security update deserves attention when it is discovered. Agree the frequency of routine tests around the consequences of a problem going unnoticed. ### Can I do website maintenance myself? You can usually check business information, click important links, test enquiries and describe problems without specialist tools. Software changes, recovery work and unfamiliar security settings may need a competent developer or hosting provider. Ask for a clear division of responsibilities so you know which checks you own and which evidence to request from someone else. ### Does my hosting package include everything on this checklist? Check the actual service agreement and ask the provider to explain anything unclear. Hosting, backups, update management, recovery assistance and content edits can be handled separately. Record the agreed responsibilities for your website, including any work that requires additional approval. The presence of a feature in a dashboard does not explain who is expected to operate or check it. ### What should I do if an update breaks the website? Contact the person responsible for the update and provide the affected pages, time and symptoms. Follow the agreed recovery process. Before a full restore, establish how newer content or submissions would be preserved. Avoid making unrelated changes while someone is investigating, because that can make the original fault harder to identify. Test the affected task after recovery. ### How do I know whether maintenance has been done properly? Ask for results that match the agreed scope: update details, tested enquiries, backup and restoration evidence, access-review decisions and unresolved issues. Look for dates and outcomes you can understand. A useful report makes uncertainty visible and explains the next action. Even a well-run maintenance process cannot guarantee that a website will never fail or experience a security problem. ## Put a manageable routine in place Start with the checks most closely connected to your customers and your ability to recover the site. Give each one an owner, agree the evidence you expect and keep the open issues visible. If you would like to discuss your website’s ongoing needs, explore Healy Web Design’s [website and marketing services](https://healywebdesign.co.uk/services/website-and-marketing/) or [get in touch](https://healywebdesign.co.uk/contact/) with the setup you currently have and the areas where responsibility is unclear.