5 Essential Practices for Ensuring Website Security

A website security maintenance checklist turns good intentions into work someone owns. Installing a certificate or enabling backups once is only the beginning: settings change, software ages and people join or leave the team. The useful question is whether each control still works today.

Use these five practices as a recurring review for a small-business website. For each one, record the owner, the last check, the result and any follow-up. This is an operational checklist; our broader website security guide explains how the different layers of protection fit together.

1. Check HTTPS and certificate renewal

HTTPS encrypts the connection between a browser and your website. It does not establish that the website is free from malware or that an administrator account is secure. Treat it as one control to maintain, not a complete security verdict.

• Check: open the public site, its login page and important forms over HTTPS. Investigate certificate warnings, incorrect hostnames and content that still loads over HTTP.
• Confirm: certificate renewal is configured, the relevant domain names are covered and someone receives expiry or renewal-failure alerts.
• Recheck after changes: a domain move, DNS change, proxy configuration or hosting migration can affect certificate validation and delivery.
• Record: who manages the certificate, where alerts go and how the team escalates a failed renewal.

Do not instruct visitors to bypass a browser warning. Have the responsible administrator investigate the hostname, certificate chain and renewal process. If the website uses a CDN or proxy, clarify who secures the connection to the origin server as well as the visitor-facing connection.

2. Maintain supported software and verify updates

Keep a list of your CMS, plugins, themes and relevant server components, together with who maintains each one. Hosting support and application maintenance may belong to different people. WordPress’s hardening guidance identifies updates and reducing unnecessary exposure as parts of ongoing security work.

Review update and vulnerability notices promptly. An actively exploited issue should not wait for an arbitrary monthly maintenance appointment. For ordinary changes, use a tested backup and an appropriate staging check, then confirm the live update actually completed. Automated updates still need failure alerts and follow-up.

After a change, test sign-in, navigation, forms and the website’s main customer journey. For a store, use a safe checkout test; for a service business, verify an enquiry reaches its intended destination. A successful update message does not prove every integration still works.

Remove unused software through the platform’s supported process after checking dependencies and keeping a recovery option. Do not assume an inactive plugin can safely be forgotten. If software is no longer supported, plan its replacement rather than relying indefinitely on an old version.

3. Review accounts, passwords and permissions

Give each person an individual account and the access their work requires. Use long, unique passwords stored in an approved password manager where passwords are needed. Avoid shared administrator logins that make it difficult to remove one person’s access or understand who changed a setting.

Review administrators, temporary developer access, API credentials and connected applications. Check that every account has a current owner and a valid reason to remain active. Revoke unnecessary access after a contractor finishes or a staff member leaves, and review secrets they could have copied.

Include the hosting panel, domain registrar, DNS service and recovery email account in this review. Protecting only the CMS login leaves other routes through which the site can be changed. Our office email security guide covers the mailbox that may control password recovery.

Keep a short access record with the account owner, role and review date. Store actual passwords and recovery codes in the appropriate secure system, not in that maintenance record.

4. Test MFA and the account recovery route

Enable multifactor authentication wherever the relevant service supports it, starting with privileged accounts. Prefer phishing-resistant options such as supported passkeys or security keys. Other methods can still improve protection, but they do not all provide the same resistance to phishing. CISA’s MFA guidance explains those differences.

Confirm that the setting applies to the accounts and sign-in methods you use. Review integrations or older clients that may bypass the expected login flow. A checkbox in one service does not enable MFA across your hosting, registrar and email accounts.

Test recovery when a device is unavailable. Keep protected recovery codes or another approved recovery method accessible to the right person, and ensure emergency instructions are available outside the affected account. Do not weaken authentication simply to make a shared login more convenient.

Record who can restore access and how their identity will be verified. If staff receive unexpected authentication prompts, they should report them rather than approve them to make the alerts stop.

5. Back up what matters and prove you can restore it

Choose backup frequency from the amount of recent work or transaction data the business can afford to lose. A rarely edited brochure site and a busy ordering system have different needs. A fixed weekly schedule is not a suitable recommendation for every website.

For WordPress, confirm that both the database and necessary files are covered, together with configuration needed for recovery. WordPress’s backup documentation explains why database and file backups serve different roles. Keep protected copies separate from the production failure or access path where practical.

Monitor failed jobs, available storage and retention. Check that the person responsible can access the backup even if the main hosting account is unavailable. Consider whether an attacker with production credentials could also delete every recovery copy. CISA recommends protected backups and regular recovery testing.

Restore a representative backup into an isolated environment and verify pages, media, accounts and the important business workflow. Disable outgoing email, payment actions and other live integrations in the test copy. Record how long recovery took and whether the result meets the business’s needs.

If compromise is suspected, investigate the cause and the age of the backup before restoring it. A backup can contain the same malicious changes or vulnerable software. Recovery also needs to account for legitimate orders or enquiries received after the restore point.

Put the checklist into a working routine

Use the following as a starting schedule to adapt to the website’s risk and rate of change. It is an editorial planning example, not a compliance standard or a promise that these intervals suit every site.

• When alerts arrive: investigate failed backups, certificate warnings, suspicious access and urgent security notices promptly.
• During the regular maintenance review: inspect update results, important forms, monitoring alerts and unresolved actions. A weekly review may suit some small sites, but urgent work should not wait for it.
• After a staff, supplier or infrastructure change: review access, integrations, recovery contacts and certificate or backup responsibilities.
• On an agreed recovery-test schedule: restore a backup and check the result. Repeat after significant changes to the application or backup process.

For every task, record the date, owner, evidence and next action. Useful evidence could be a successful restore test or confirmation that an obsolete account was removed. Avoid treating an installed security plugin or a green dashboard as proof that all work is complete.

If you outsource maintenance, agree which checks are included, how failures are reported and who responds outside normal working hours. Keep unresolved items visible until someone confirms they are addressed. Monitoring helps identify problems; it does not itself patch software, remove malware or recover lost data.

Frequently asked questions

Is HTTPS enough to secure a website?

No. It protects the connection, while updates, access controls, monitoring and recovery address other risks. Continue checking all five practices.

How often should a website be backed up?

Base the schedule on acceptable data loss and how often content or transactions change. Verify retention and recovery as well as frequency.

Does managed hosting handle all this work?

That depends on the agreement. Confirm responsibilities for the CMS, plugins, accounts, certificates, backup restoration and incident response rather than assuming every task is included.

What should we do if a security check fails?

Record what failed and contact the responsible administrator. Prioritize active compromise, exposed access and unavailable recovery. If an incident is suspected, follow the incident plan and preserve relevant evidence before making broad changes.