Website Security Essentials: How to Protect Your WordPress Website in 2026

If recent website security news and critical PHP vulnerabilities made you wonder how protected your website actually is, then you’re right to do something about it.

We regularly have conversations about website security, and they tend to start in one of three places:

1. From business owners: “we pay someone to look after the website, so I assume that includes security.“
2. From marketing managers: “IT keeps asking me who’s responsible for the website’s security, and I’m honestly not sure.“
3. From security teams: “we scan the website every week, so if something was wrong we’d know about it.“

All three are fair and they point to the same gap.

On 21 October 2026 the PHP team released fixes for two critical vulnerabilities that could let an attacker take control of a website without needing to log in. PHP runs every WordPress website, so this one affected almost everyone (we covered what the PHP vulnerability means for Australian businesses at the time).

The good news is that most hosts patched it within a day or so.

The not so good news is that issues like this show how much website security depends on things the business never sees and often hasn’t asked anyone to own.

That usually leads to a reactive approach, where problems get fixed as they come up rather than prevented with best practice.

It’s a bit like installing a security camera but never locking the front door. You’ll know straight away when something goes wrong, but nothing is stopping it from happening.

We’ve looked after websites since 2008, and today we keep around 180 businesses’ websites secure every month, including CyberCX, RSL Victoria, Accor and City Facilities Management. This guide is what we’ve learned about best practices for website security, layer by layer.

Key points

• Website security works in four layers: your DNS, your hosting, the website itself, and who has access.
• Vulnerability scanning spots problems after they appear. Hardening removes the weak points before anyone finds them.
• The October 2026 PHP vulnerability needed no login, so 2FA alone wouldn’t have stopped it.
• Cyber incidents could cost Australian businesses $37 billion a year by 2030, CyberCX research projects.
• PHP 8.2 reaches end of life on 31 December 2026, so plan and test upgrades now.
• Fewer plugins, one security plugin and tested weekly updates remove much of the website-level risk.
• If it isn’t written down who’s responsible for website security, it’s usually nobody.

Two website security myths that leave businesses exposed

Most of the security gaps we find aren’t caused by anyone doing a bad job. They come from two reasonable assumptions that just don’t hold up.

Myth 1: “Our web team handles security”

It’s easy to assume, and sometimes it’s true.

But most web teams are designers and developers, which is a different skill set from server and security work.

Unless your agreement says who’s responsible for each part of your website’s security, and what they actually do each week, the honest answer is often that nobody owns it. Assuming someone has it covered isn’t a security policy.

Myth 2: “Vulnerability scanning has us covered”

Most security teams run vulnerability scans, and they should. Scanning is essential for spotting known issues so they can be fixed.

The catch is that scanning is reactive. It’s the security camera from earlier: it tells you when something is already wrong, but it won’t tell you the front door doesn’t have a lock on it.

And sometimes the best fix isn’t a better lock at all. It’s bricking up a door you never use, so there’s nothing left to watch.

That’s what hardening is: putting the locks on, and closing the doors you don’t need.

Your checklist

• Confirm in writing who’s responsible for each part of your website’s security
• Ask what your vulnerability scanning covers, and what it doesn’t

Website security works in layers

Traffic reaches your website through several layers, and each one is a chance to stop bad traffic before it gets to the next.

That traffic is no longer just people. It’s real visitors, AI bots and agents reading your content, and automated scanners probing for weaknesses, all arriving at the same front door.

Here’s how we think about each layer, and what we recommend for each one.

Layer 1: Secure your domain and DNS

DNS is the switchboard for your domain. It tells traffic where to go, whether that’s your website, your email or a subdomain, so everything downstream depends on it.

Most businesses use the DNS that came with their domain name. Many domain companies follow good security practice, but it’s still a single point of failure, and a dedicated DNS provider is a more secure option.

That’s why we recommend Cloudflare.

Cloudflare sits in front of 28.2% of all websites as a reverse proxy. That means traffic passes through Cloudflare’s network before it reaches your server, and bad traffic can be blocked on the way.

It’s also the infrastructure behind WP Engine’s Global Edge Security, and it’s our go-to for DNS.

Cloudflare’s free plan includes DNS, a CDN, a web application firewall and DDoS protection, which is where most websites start. For a business-critical website, the paid plans add more control over the firewall and bot rules, and it’s worth a conversation about which you need.

Setting it up is fairly simple. Cloudflare scans your existing DNS records and copies them across, and then you point your domain’s nameservers at Cloudflare.

Depending on your current provider, that change can take 24 to 48 hours to fully take effect, so we recommend doing it at a quiet time, like overnight or on a weekend.

If your IT team is confident with its own DNS and doesn’t want to move it, that’s fine too. You can route just the website through Cloudflare by pointing the website’s record at it, and leave everything else where it is.

While you’re working on this layer, check your email records (SPF, DKIM and DMARC) carefully. A DNS move that breaks email is the most common way this goes wrong.

And make sure your domain is on auto-renew. A lapsed domain takes your website and your email down with it.

Your DNS checklist

• Move your DNS to a dedicated provider like Cloudflare, or route just the website through it
• Turn on Cloudflare’s proxy and firewall for your website
• Set SSL to strict, so traffic is encrypted all the way to your server
• Check your SPF, DKIM and DMARC records after the move
• Put your domain on auto-renew and lock it at the registrar

Layer 2: Choose secure, managed hosting

Hosting is the next line of defence, and it’s the one most businesses leave to their web designer.

That’s understandable, but it’s worth knowing that hosting ranges from free to thousands of dollars a month depending on the setup, and more expensive doesn’t usually mean better.

What matters most is that the server is managed and kept secure by people whose job that is.

For WordPress, that means managed WordPress hosting. There are plenty of good providers, but the three we recommend for security, performance and speed are WP Engine, Cloudways and Kinsta. All three offer free migrations, so getting started is fairly simple.

WP Engine is best when you want minimal involvement and would like them to manage it for you. We’ve found their team responsive and helpful.

We can’t give them a perfect score, as they’ve quoted surprisingly high for some fairly simple websites, and it can take a while to get through their AI chat to a real person. But overall they’re one of the best in the business.

Cloudways gives you more flexibility and control, which also means your team needs more capability to manage it.

You choose the underlying cloud provider (DigitalOcean, Vultr, Linode, AWS or Google Cloud, all secure and powerful platforms), and Cloudways sits on top to manage the server and show you how it’s performing.

What we like most is being able to scale a server up and down, which helps a lot during busy periods. For experienced web teams, we find it’s the best balance of performance and control.

Kinsta offers exceptional hosting and support. It’s a similar tier to WP Engine, and it suits organisations that want their host to take most of the hosting work off their plate.

Whichever host you choose, check that it keeps backups off the server, and that someone has actually tested restoring one. A backup you’ve never restored is a hope rather than a plan.

What your web host does and doesn’t cover

A managed host keeps the server secure, and the PHP issue showed this working well. Both WP Engine and Cloudways had patches in place across their platforms within a day or so.

What hosts can’t do on their own is move your website to a newer PHP version without risk, because a version jump can break a website.

Some hosts, like Kinsta, will upgrade automatically when a version reaches end of life. That’s great for security, but it can still catch a website out if nobody’s tested it first, so either way it needs to be done with your web team.

This is timely, as PHP 8.2 reaches end of life on 31 December 2026, and plenty of websites are still running it.

We saw why this matters recently. One of the websites we work on moved to a new host, and one line of old code that had worked fine on the old server stopped working on the new one. It took every blog post on the site offline.

The homepage was fine, so the uptime monitor, which only checked the homepage, reported everything as healthy for nearly two weeks. It’s a good reminder that hosting and the website need to be looked after together, and that monitoring should check more than your homepage.

Your hosting checklist

• Host your website on managed WordPress hosting
• Confirm backups are stored off the server, and test a restore
• Check which PHP version your website runs, and plan upgrades with your web team
• Remove hosting and SFTP users who no longer need access
• Monitor your key pages, not just the homepage

Assuming someone has it covered isn’t a security policy.

Layer 3: Harden the website itself

This is where the traffic meets the server, and where real people, AI systems and agents are browsing, clicking and engaging with your content.

At this layer there are two jobs: keeping your admin access secure, and keeping your code secure.

Secure your WordPress admin access

Start with the login page. By default, WordPress logs in at /wp-admin or /wp-login.php, and every automated attack on the internet knows it.

Moving the login page to a different address won’t stop a determined attacker on its own, but it cuts out a huge amount of automated noise and brute-force attempts.

Then turn off file editing inside WordPress, so nobody with a login can change the website’s code from the dashboard, and add spam protection to your forms (we compare the two main options in Turnstile vs reCAPTCHA).

Keep your plugins and code up to date

The code side relies a lot on your web team keeping things current. For WordPress that mostly means plugins.

Updating them carries its own risk, because each update brings in new code that hasn’t always been tested on your website. So we recommend a managed update process on a set schedule:

• Daily: check for available updates and known vulnerabilities.
• Straight away: update any plugin with a known vulnerability, rather than waiting for the weekly cycle.
• Weekly: run managed updates at a set time each week.
• Every update: take a backup first, and use visual regression testing, which takes before-and-after snapshots of your pages so anything that changes is caught before your visitors notice.

Then reduce what needs updating in the first place.

Every plugin is code you’re trusting, so keep them to a minimum, and remove inactive plugins rather than leaving them switched off. Use one security plugin, if any. We often find websites running three or four that overlap and conflict with each other.

Avoid mass-market themes too. Popular themes are popular targets, and they carry a lot of code your website doesn’t use. Where you can, keep the build simple and custom, so there’s less to look after.

The most secure plugin is the one you don’t install.

This is the work a good support plan should cover every week, and it’s what our website maintenance and support plans are built around.

Your website checklist

• Move the login page away from /wp-admin and /wp-login.php
• Turn off file editing in WordPress
• Add spam protection to every form
• Remove inactive and unnecessary plugins
• Keep one security plugin at most
• Set a weekly update window, with a backup and before-and-after checks every time
• Apply security fixes as soon as a vulnerability is found

Layer 4: Lock down who has access

The last layer is people, and it’s the one that’s easiest to fix.

Turn on multi-factor authentication everywhere, not just on the website login. That includes your domain registrar, your hosting account, Cloudflare and anywhere else that controls your website.

If someone gets into your domain registrar, they don’t need to get into your website at all.

Don’t share logins, create individual users. Every person gets their own account with only the access they need, and anyone who doesn’t need admin access doesn’t have it. If you’ve ever shared a password for any of these accounts, it’s worth changing it now.

Remove old accounts. The classic one is a previous developer who still has admin access years after the project ended. We find this more often than you’d think.

Use a password manager. We use 1Password at SGD and recommend it to our clients, and Bitwarden is a good alternative.

There are free options too, which I’d only recommend if you really know what you’re doing. This is one area where it doesn’t pay to go cheap.

Write it down. Every client we look after gets a Website Owner’s Manual that sets out who’s responsible for what, from the domain to the hosting to the weekly updates.

If it isn’t written down, with an agreement behind it, it’s very easy for something important to fall between two teams.

Your access checklist

• Turn on MFA for your domain registrar, hosting, Cloudflare and WordPress
• Give everyone their own login, with only the access they need
• Remove old accounts, especially past developers
• Move shared passwords into a password manager
• Write down who’s responsible for each layer

Why 2FA on its own isn’t enough

Two-factor authentication is best practice, and every admin account should have it. But it only protects the login screen.

The PHP vulnerability is a good example of why that’s not enough. It didn’t need a login at all, so 2FA wouldn’t have made any difference.

What protected websites was the hosting layer patching quickly, and the websites in the best position were the ones with fewer ways in to begin with.

That’s really the whole argument for layers. No single control stops everything, so each layer needs to do its job.

Where IT security and marketing teams meet

Website security sits right where IT and marketing overlap, and the two teams often want different things.

IT teams tend to want consistency and to move carefully. Marketing teams need the flexibility to launch pages, run campaigns and try new tools without waiting weeks for approval.

Putting a proper hardening system in place, like the one outlined above, helps both. IT gets the smallest possible attack surface, and marketing keeps the freedom to do its job inside it.

That matters more now that AI is making attacks cheaper and faster to run. Research by Mandala Partners, commissioned by CyberCX, projects that cyber incidents could cost Australian businesses $37 billion a year by 2030 as AI-driven threats grow.

The same research found that around $24 billion of that could be avoided if businesses put foundational defences in place, which is exactly what hardening is.

No single control stops everything, so each layer needs to do its job.

Your WordPress security checklist

Here’s every action from this guide in one place, grouped by layer, so you can work through it with your web team or IT.

Responsibility checklist

• Confirm in writing who’s responsible for each part of your website’s security
• Ask what your vulnerability scanning covers, and what it doesn’t

DNS and domain checklist

• Move your DNS to a dedicated provider like Cloudflare, or route just the website through it
• Turn on Cloudflare’s proxy and firewall for your website
• Set SSL to strict, so traffic is encrypted all the way to your server
• Check your SPF, DKIM and DMARC records after the move
• Put your domain on auto-renew and lock it at the registrar

Hosting checklist

• Host your website on managed WordPress hosting
• Confirm backups are stored off the server, and test a restore
• Check which PHP version your website runs, and plan upgrades with your web team
• Remove hosting and SFTP users who no longer need access
• Monitor your key pages, not just the homepage

Website checklist

• Move the login page away from /wp-admin and /wp-login.php
• Turn off file editing in WordPress
• Add spam protection to every form
• Remove inactive and unnecessary plugins
• Keep one security plugin at most
• Set a weekly update window, with a backup and before-and-after checks every time
• Apply security fixes as soon as a vulnerability is found

Access checklist

• Turn on MFA for your domain registrar, hosting, Cloudflare and WordPress
• Give everyone their own login, with only the access they need
• Remove old accounts, especially past developers
• Move shared passwords into a password manager
• Write down who’s responsible for each layer

How SGD’s website security hardening works

If you’d rather not work through the checklist yourself, our website security hardening service covers all four layers in one project.

We start with a backup and a staging copy of your website, so every change is tested before it goes live. Then we work through your DNS and Cloudflare setup, check your hosting and backups, clean up and harden the website, and tighten who has access to what.

At the end you get a one-page report of what we found, what we fixed, and anything left to decide, along with a short walkthrough call.

From there, one of our website support plans keeps it that way, with the weekly updates, scanning and backups carried on as normal.

Website security FAQs

These are the questions we get asked most often about website security, usually right after a story like the PHP one hits the news.

Is WordPress secure enough for a business website?

Yes, in most cases. WordPress itself is well maintained and patched quickly. Most of the security issues we see come from outdated or unnecessary plugins, mass-market themes, shared logins and hosting nobody is looking after. A WordPress website that’s set up and maintained well is a secure choice for most businesses.

Is Cloudflare’s free plan enough for a business website?

For many websites it’s a good start, as it includes DNS, a CDN, a web application firewall and DDoS protection. Cloudflare describes the free plan as suited to sites that aren’t business-critical, so if your website drives leads or sales, it’s worth looking at whether a paid plan’s extra firewall and bot controls are worth it.

Do I still need a security plugin if I use Cloudflare?

Usually, yes, but only one. Cloudflare stops bad traffic before it reaches your server, while a security plugin watches what happens on the website itself, like login attempts and file changes. They protect different layers. What we’d avoid is running several security plugins at once, as they tend to overlap and conflict.

How often should WordPress plugins be updated?

We recommend checking for updates daily, applying any security fix straight away, and running routine updates weekly at a set time. Each update should start with a backup and finish with a before-and-after check of your key pages, so anything that breaks is caught before your visitors find it.

Does my web host take care of website security?

Partly. A managed host keeps the server secure and patched, which matters a lot. But most hosts don’t manage your plugins, your theme, who has admin access, or your DNS. Those sit with your web team, which is why it helps to have it written down who’s responsible for each part.

What should I do if my website has been hacked?

Contact your web host and your web team straight away, and change the passwords for every account connected to the website. The usual fix is restoring a clean backup from before the hack, then finding and closing the way in so it doesn’t happen again. Some support plans, including our Advanced and Pro plans, include malware clean-up.

How do I know if my website was affected by the October 2026 PHP vulnerability?

Ask your web host or web team which PHP version your website runs. The patched releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or a version your host has patched directly. If your website runs PHP 7.4 or older, it’s also worth planning an upgrade, as those versions no longer get regular security updates.

The bottom line on website security

Website security works in layers, and no single tool or setting covers all of them.

Vulnerability scanning tells you when something is already wrong. Hardening is the proactive part, where you put the locks on, close the doors you don’t need, and make it clear who’s looking after each one.

You don’t need to do everything at once. Start with the layer you’re least sure about, which for most businesses is usually access or DNS, and work from there.

The checklist above is a good place to start. And if you’d like a hand, book a call with me to talk through where your website stands.