How to protect a website from hacking: 12 measures to reduce risk

This guide is about prevention; it is not a page selling a cybersecurity audit

The purpose is to answer: “what basic measures should my website have to reduce the risk of being hacked?”

It is different from other pages in the cluster:

• website maintenance explains and offers the recurring service;
• what to do if the website stops working is an outage response protocol;
• website backups focuses specifically on recovery;
• an advanced security audit, penetration test or forensic analysis requires a scope and specialisation different from normal technical maintenance.

A small website can also receive attack attempts

Someone does not need to know your company and decide to attack it personally. Some malicious activity on the Internet uses automated tools that search for vulnerable versions, weak credentials or exposed configurations.

WordPress explains in its security documentation that many common attacks try to exploit old or vulnerable software and carry out automated attempts against login credentials.

That is why company size should not be the criterion for deciding whether a website deserves basic security measures. What matters is the technology it uses, the data it handles and the impact of losing control of the site.

12 measures to reduce the risk of a website being hacked

They do not carry the same weight in every project, but together they create a stronger foundation than relying on a single tool.

1. Keep the software that genuinely forms part of the website up to date

If you use WordPress or another CMS, review the core, plugins and themes. On custom projects, frameworks, libraries, PHP or other dependencies should also be considered when relevant.

Updates may fix known vulnerabilities, as well as bugs and compatibility problems.

That does not mean updating blindly. On a live website, it is sensible to have a recent backup and check that the change does not break important functions.

If your question is specifically about frequency, see how often a website should be updated .

2. Remove plugins, themes, users and components you no longer need

Every installed element adds code, dependencies, permissions and possible points that will need maintenance.

Keeping a disabled plugin that nobody uses, an old theme or a forgotten administrative account adds no value to the business and increases what needs to be controlled.

Before removing something, check that it does not serve a necessary function and keep a backup when the change may be difficult to reverse.

3. Use unique, strong passwords and two-factor authentication

A well-updated website can still be compromised if someone obtains the credentials of an administrative account.

I would apply these practices:

• long, unique passwords for each service;
• do not reuse the same password for email, hosting and WordPress;
• use a password manager where possible;
• enable two-factor authentication on critical accounts;
• remove old access when someone no longer needs it.

Email deserves particular attention: whoever controls the email associated with an account may be able to start password recovery processes.

4. Give each user only the permissions they need

Not everyone who publishes content needs to be an administrator.

The principle of least privilege means granting only the access needed to perform a task. If a limited account is compromised, the potential damage may be lower than if every account has full control.

It is also worth reviewing old users, supplier accounts and temporary access regularly.

5. Protect hosting, the domain and administrative accounts as well

Website security does not end in the WordPress dashboard. Someone who gains access to hosting can modify files, databases, DNS or backups even when the CMS is well configured.

I would protect particularly:

• hosting control panel;
• domain registrar;
• administrative email accounts;
• FTP/SFTP or similar access;
• databases;
• repositories and deployment services, if used.

When the provider offers 2FA and access management, it is worth using them on accounts with the greatest ability to make changes.

6. Use HTTPS, but understand what it actually protects

HTTPS encrypts communication between the user’s browser and the server. It is especially important when forms, credentials or other data are being sent.

But the browser padlock does not mean the website is immune to hacking. A valid SSL certificate does not fix a compromised password, a vulnerable plugin or incorrect permissions.

That is why HTTPS is part of security, but it should not be used as the only proof that a website is protected.

7. Keep backups that can genuinely be used to recover the website

A backup does not prevent someone from finding a vulnerability. Its role is different: allow information to be recovered and return to a known state.

A backup policy should define:

• what is backed up;
• how often;
• where it is stored;
• how many versions are retained;
• who can access them;
• how restoration is verified.

Whenever reasonable, it is worth keeping at least one backup separate from the same environment that could be affected by the incident.

The specific topic is covered in website backups .

8. Install plugins, themes and code from trusted sources

Downloading modified software, licences of doubtful origin or components that are no longer maintained can introduce unnecessary risk.

In WordPress I would review:

• the source of the plugin or theme;
• whether it is still receiving updates;
• compatibility with the current version;
• whether it genuinely needs to be installed;
• what permissions and functions it adds.

In custom developments, the same logic applies to libraries, packages and third-party code that becomes part of the project.

9. Review permissions and server configuration according to the technology

Files should not have broader permissions than necessary and sensitive credentials should not be publicly exposed.

WordPress includes specific recommendations for permissions, protecting configuration files, administration over HTTPS and reducing the ability to modify files from the dashboard when that capability is not needed.

I would not apply configurations copied from the Internet without checking the specific server and architecture. A rule that is valid for one environment can break another or create a false sense of security.

10. Protect forms, data input and public-facing functions

Any point that accepts user information needs appropriate controls. This applies to forms, searches, registrations, comments, file uploads, APIs and other inputs.

A properly developed solution should include, where appropriate, data validation, permissions, protection against abuse and server-side controls.

A CAPTCHA can help with certain types of spam or abusive automation, but it does not replace secure code or protect the entire application by itself.

11. Keep enough logs to understand what happened if a problem appears

When something fails, logs can indicate errors, access, changes or unusual behaviour.

The level of logging should be adapted to the project and respect the information that genuinely needs to be retained. A simple landing page does not need the same level of supervision as a platform with users or transactions.

Critical projects may require specialist monitoring and security tools that go beyond basic website maintenance.

12. Be prepared for what to do if you suspect the website has been compromised

Prevention reduces risk, but you also need to be prepared to recover.

It is worth knowing in advance:

• who has access to the hosting and domain;
• where the backups are;
• how to contact the provider;
• which external services the website uses;
• which functions are critical to check after recovery;
• who can change credentials and revoke access;
• when the incident requires a cybersecurity specialist.

If the website has simply stopped responding and you still do not know the cause, first follow the guide on what to do when a website stops working .

Not every website needs the same level of protection

Security should be proportional to risk. I would not apply the same approach to every project.

As data, users and the consequences of failure increase, the depth of controls should also increase and, where appropriate, specialist cybersecurity professionals should be involved.

Signs that may indicate the website is no longer facing a preventive issue

If you observe any of these symptoms, stop treating it simply as a routine review:

• redirects to sites you do not recognise;
• unknown administrator users;
• files or content nobody on the team added;
• malware warnings from the browser, hosting provider or search engine;
• spam pages created without authorisation;
• unsolicited password changes;
• unauthorised email sent from the domain;
• unexpected loss of access to the dashboard or hosting.

At that point it may be necessary to preserve evidence, change credentials from a secure environment, contact the hosting provider and recover from a version known to be clean. If the incident is complex, specialist response may be required.

Which part of this protection can website maintenance cover?

Technical maintenance can help with basic prevention: keeping components updated, reviewing obvious access points, checking SSL, maintaining backups and responding to certain incidents.

But I would not present that as “complete cybersecurity”. Website maintenance does not automatically include:

• penetration testing;
• advanced vulnerability audits;
• 24/7 security monitoring;
• forensic analysis;
• advanced breach response;
• comprehensive regulatory compliance management;
• specialist protection of business infrastructure.

Defining that boundary correctly avoids an impossible promise: no maintenance service can guarantee that a website will never be attacked or compromised.

Quick basic-security checklist for a business website

1. Are the CMS, plugins, theme and dependencies maintained?
2. Have we removed software and users we no longer need?
3. Do critical accounts use unique passwords and 2FA?
4. Does each user have only the permissions they need?
5. Are hosting, domain and administrative email protected as well?
6. Is HTTPS working correctly?
7. Is there a sufficiently recent, recoverable backup?
8. Do we know where plugins, themes and libraries come from?
9. Are critical permissions and configurations appropriate?
10. Do forms and public functions have reasonable controls?
11. Can we review logs if an incident occurs?
12. Do we know who to contact and how to recover the website if something fails?