A customer emails first thing in the morning: “Your website keeps sending me to a casino site.” Or you search for your company on Google and see a warning under your own listing that the site may have been hacked. You try to reach the people who built it. The project was handed over two years ago, and nobody has logged in since.
This article is about avoiding that morning, and knowing what to do if it comes anyway: why sites get hacked, the WordPress measures that matter, updates and backups, access and infrastructure, monitoring, recovery and your duties if personal data is involved. At the end, a table shows what a maintenance contract should spell out.
Why do websites get hacked?
Most business owners think “there’s nothing worth stealing on our site”. The trouble is that most attackers never chose you. Automated tools scan the web around the clock, and wherever they find a plugin or theme version with a known vulnerability, they get in. Your size, sector and traffic are irrelevant to them.
Once inside, the goal often isn’t even your data. The site becomes a tool: publishing spam pages, redirecting visitors to scams, hosting phishing pages or attacking other sites. Usually you find out when Google shows a warning or a customer complains.
The ways in that we see most often:
- Outdated plugins and themes. Once a vulnerability is published, a fix follows; sites that don’t install it stay exposed for months.
- Abandoned plugins. When a developer walks away and a plugin that hasn’t been updated in years turns out to have a hole, the fix never arrives. Plugins closed for security reasons in the WordPress.org directory show a notice reading “This plugin has been closed… Reason: Security Issue”, so check the pages of the plugins you use from time to time.
- Pirated, “nulled” themes and plugins. An unlicensed copy of a premium theme frequently comes with a hidden backdoor. WordPress’s own security documentation is blunt about it: don’t install plugins or themes from untrusted sources.
- Weak or reused passwords. Email and password pairs leaked from other sites are tried automatically against thousands of login pages.
- Misconfiguration: backup files left publicly accessible, directory listing switched on, file permissions wider than necessary, forgotten test installs.
The 2025 edition of the OWASP Top 10, the standard reference list for web application security, puts broken access control, security misconfiguration and software supply chain failures in its top three. That last category broadens the old “outdated components” item, and for a small business website it means something simple: every plugin, theme and library you run is part of your attack surface.
The WordPress basics
WordPress is the system we come across most often on business websites, and it isn’t insecure in itself. Most problems come not from the core but from what is bolted on and from neglect. The basics:
- Run fewer plugins. Each one is a separate codebase, developer and update schedule. Don’t just deactivate plugins you don’t use; delete them.
- Install plugins only from the WordPress.org directory or well-known developers, and check when they were last updated and whether they have been tested with your WordPress version.
- Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. It switches off theme and plugin file editing in the dashboard, so a hijacked admin account can’t simply paste malicious code in.
- Avoid guessable usernames such as “admin”, and turn on two-factor authentication for every administrator.
- Limit login attempts, either with a security plugin or at the firewall in front of the server.
- Tighten file permissions. The WordPress documentation recommends that wp-config.php be readable only by you and the web server, typically 400 or 440.
- Check Tools > Site Health regularly; it flags outdated PHP versions, disabled automatic updates and similar issues.
An update policy and a staging site
“We do the updates” is not a policy. A policy says what gets updated, when, by whom and how.
Since WordPress 3.7, minor maintenance and security releases install automatically by default, and since 5.5 you can switch on automatic updates for each plugin and theme individually from the Plugins screen. That option is off by default. How much you leave on automatic depends on how much custom code the site carries.
The routine we recommend:
- Treat security updates as a priority class. When a vulnerability is announced in a plugin you use, the fix should go on within days, and the same day for serious ones.
- Batch other plugin and theme updates on a regular schedule, weekly or fortnightly.
- Try major releases first on a staging site: new WordPress versions, page builders, e-commerce plugins.
- Take a backup before every update and know how to roll back.
- After updating, check the homepage, forms, checkout and member login.
A staging site is a password-protected copy of the live site, hidden from search engines. Without one, updates either never happen or happen blind on the live site, and both end badly.
Backups: the 3-2-1 rule and restore tests
A backup is only a backup if it can be restored. What we meet most often is a routine everyone believes in, nobody has tested, and which turns out incomplete or corrupt on the bad day.
The 3-2-1 rule says: keep at least three copies of your data, on at least two different types of storage, with at least one held somewhere else, away from your server. For a website, that looks like this:
- Your host’s daily backup is the first layer, but it isn’t enough on its own: if the server or account is compromised, the backups are in the same place.
- The second copy should live with another provider, for example a separate cloud storage account, with credentials different from your site passwords.
- Against ransomware, one copy should be immutable or offline; attackers delete every backup they can reach first.
- Back up both files and database. A database-only backup won’t bring back uploaded images and documents.
- Think about retention: hacks are sometimes discovered weeks later. If you only keep seven days, every backup you have may already be infected.
The single most important point is the restore test. Once a quarter, restore a backup to a staging site and check that it works. You learn two things: whether the backup is sound, and how long a restore takes. The second tells you what to say to customers on the bad day.
Access and infrastructure
Two-factor authentication and least privilege
The keys to your website aren’t only in the WordPress dashboard. The domain registrar, DNS, hosting control panel, email, Google Search Console and Analytics can each be used to take the site over. Turn on two-factor authentication everywhere, preferably with an authenticator app or hardware key rather than SMS, and make sure the transfer lock on your domain is active.
Least privilege is simple: everyone gets exactly the access they need to do their job. Someone who writes blog posts needs an editor or author role, not administrator. Give each person their own account rather than one shared “company” login, so you can see who did what. Close the accounts of staff who leave and agencies you stop working with on the same day; one of the most common holes we find on sites we take over is a working admin account belonging to someone who left years ago.
HTTPS and HSTS
HTTPS is no longer up for debate: certificates come with most hosting plans, and browsers warn anyone filling in a form on an HTTP page. What matters is that the certificate renews automatically and that every page, image and script loads over HTTPS.
The HSTS (HTTP Strict Transport Security) header tells browsers to connect to your site only over HTTPS from now on. To join the browsers’ HSTS preload list, the header needs a max-age of at least one year (31536000 seconds) plus the includeSubDomains and preload directives. Be careful: getting off that list takes months, and every subdomain must support HTTPS. A forgotten subdomain without a certificate simply becomes unreachable.
WAF, CDN and hosting isolation
A web application firewall (WAF) blocks known attack patterns before they reach your server. A CDN and security layer such as Cloudflare, services such as Sucuri, or ModSecurity on the server can all do this. It doesn’t replace updates; it buys time until a fix arrives.
On the hosting side, the classic mistake is running several sites under one user account. When a forgotten campaign microsite gets hacked, your main site on the same account goes with it. Each site should run in isolation under its own system user. Use SFTP or SSH keys instead of FTP, and stay on a PHP version that is still supported.
Monitoring: spotting problems before your customers do
Without monitoring, the news comes from your customers, from Google or from the attacker. The minimum to set up:
- Uptime monitoring that alerts you by email or message if the site stops responding for more than a few minutes.
- File integrity checks that compare core and plugin files with the official versions, through a security plugin or WP-CLI’s wp core verify-checksums and wp plugin verify-checksums commands.
- The Security Issues report in Google Search Console. If Google detects malware, code injection or content injection on your site, it shows up there and you get an email. Without a Search Console account you never see that warning.
- Certificate and domain expiry dates. A lapsed domain can do as much damage as a hack.
- A log of events such as new administrator accounts or plugin installs.
- Blocklists: once your site is flagged by Google Safe Browsing, browsers warn visitors away, and other security services often follow.
If you have been hacked: step by step
Panic is a terrible adviser. Deleting everything in a hurry makes it impossible to work out how the attacker got in, and a week later they are back through the same hole. Work through it in this order:
- Record what you see. Take screenshots, keep the warning emails and make sure server logs aren’t deleted.
- Quarantine the site: switch to maintenance mode or take it offline temporarily with your host. Protecting visitors from malicious content comes first.
- Tell your hosting provider; other accounts on the same server may be affected.
- Change every password: admin accounts, database, SFTP, hosting panel, API keys. In WordPress, regenerate the security keys and salts in wp-config.php so that open sessions are logged out.
- Review the user list and remove any administrators you don’t recognise.
- Clean up. The safest route is to restore a verified clean backup from before the hack. Otherwise reinstall core, plugin and theme files from official sources and hunt for leftovers, such as PHP files in upload folders.
- Find the way in and close it. An outdated plugin? A leaked password? Going live again without knowing is leaving the door open.
- In Search Console, open the Security Issues report, select “Request Review” and explain clearly what you did. Google says reviews can take from a few days to a few weeks, and the warning stays in place meanwhile.
- Tighten monitoring afterwards and write a short incident report.
When personal data is involved
If your site holds form submissions, customer accounts or order data and there is a chance they reached unauthorised people, the problem stops being purely technical. Under Article 33 of the GDPR, and the same article of the UK GDPR, a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people’s rights and freedoms. If there is a high risk to the individuals, Article 34 requires you to tell them as well.
The ICO lets you provide information in phases if you don’t have the full picture within 72 hours, and it expects you to record every breach, including the ones you decide not to report, with your reasons. If an agency or host processes data on your behalf, it must tell you without undue delay; the notification itself is your responsibility as controller. Organisations within the scope of the EU’s NIS2 rules have separate incident reporting duties on top, starting with an early warning within 24 hours.
What a maintenance contract should spell out
“Monthly maintenance” means something different at every agency. Some press the update button and nothing else; others take on monitoring, restore tests and incident response too. The difference shows on the bad day. Ask for these points in writing:
| Item | What the contract should say | The question to ask |
|---|---|---|
| Updates | How often core, plugins and themes are updated, and the testing process | How many days until a security update goes on? |
| Backups | Frequency, retention period, where copies are stored | Is one copy kept away from the server? |
| Restore tests | How often restores are tested and how results are reported | When did you last try a restore? |
| Monitoring | Uptime, file integrity, Search Console and certificate checks | Who hears first when the site goes down? |
| Response | Response times in and out of office hours, contact channel | Who do I call on a Saturday night? |
| Security incidents | Whether clean-up is included or charged separately | Is root cause analysis part of it? |
| Access | Whose name the accounts are in, two-factor authentication | Are the domain and hosting in our name? |
| Personal data | A data processing agreement under Article 28 GDPR, breach notification | How quickly would you tell us about a breach? |
| Reporting | What the monthly report contains | Does it list updates and incidents? |
| Exit | Handover of access and backups when the contract ends | If we leave, do we get everything? |
That last row is often skipped and matters most: domain, hosting and admin accounts belong in your name, not the agency’s, so the keys stay with you if you part ways.
Where to start
- List every account behind your website: domain, DNS, hosting, CMS administrators, email, Search Console. Note whose name each is in and whether two-factor authentication is on.
- Delete unused plugins, themes and user accounts.
- Check the last update date and directory status of the remaining plugins, and replace abandoned ones.
- Find out where your backups are kept and run a restore test this month.
- Verify Search Console and set up uptime monitoring.
- Put a written update policy and a staging site in place.
- Write a short breach response plan: who decides, who calls the legal adviser, who notifies the regulator. In the UK, the government-backed Cyber Essentials scheme is a sensible baseline to measure yourself against.
- Compare your maintenance contract with the table above and get the missing points in writing.
At AYTE Digital we run website maintenance around the points in that table, and not only for sites we built: when we take over a site, we first review where it stands and agree with you which gaps to close first. If you’d like us to look at your site as it is today, a list of its accounts is all we need to start.
