Secure means there is as little as possible to attack, what remains is patched inside the window attackers now use, and there is a tested way back if it fails.
A website is secure when there is as little as possible to attack, when what remains is patched faster than attackers move, and when there is a tested way back if it fails anyway. An owner can check each part. Here is what they mean, how fast attacks now come, and what to ask whoever looks after your site.
Every website has a front door, the pages visitors see. Most business sites also have a back door, an admin login, an application that builds pages on demand, and a database behind it. The back door is where nearly all successful attacks go, because that is where the code runs and the passwords are.
For a site on WordPress, the back door is large. In 2025, 11,334 new security flaws were disclosed across WordPress, its plugins and its themes. Nine in ten were in plugins. Nearly half, 46 per cent, had no fix available on the day they were made public. Those are Patchstack’s figures. Patchstack sells WordPress security, and Wordfence, another vendor, counts in the same range.
A static site has no application running on the public server and no database to query. The pages are built in advance and served as files. The editor your team uses is reached at an address on the site, but the page there is itself a static file that runs no code on the server; signing in goes through GitHub with two-factor authentication, and a stolen password there cannot execute anything on your site. What is left to attack is the hosting account, the domain, the GitHub account, the tools that build the site, the code libraries those tools depend on, and any script loaded from a third party. That is a much shorter list, but it is not an empty one, and we say so.
The window between a flaw being published and someone trying it on your site is now hours, not weeks.
VulnCheck found that 29 per cent of the vulnerabilities first exploited in 2025 were exploited on or before the day their public record appeared. Mandiant’s 2026 report puts the average time to exploit at minus seven days: on average, attacks begin a week before the fix is public. For WordPress specifically, Patchstack measured a median of five hours from disclosure to the first exploit attempt for the flaws attackers cared about. Cloudflare has logged an attempt 22 minutes after a proof-of-concept was published.
The UK’s Cyber Essentials standard, which many larger UK buyers now require of suppliers, asks for critical and high-severity fixes within 14 days. US law sets no deadline for a private business. Even 14 days is slower than the attackers, which is why the number of things needing patches matters more than how diligently they are patched.
Most of this is automated. Attackers scan every address on the internet for a known flaw and exploit whatever answers. In the UK government’s 2026 survey, 43 per cent of businesses identified an attack or breach in the previous year, and 46 per cent of small businesses.
In 2025 the attacks that made the news were not on websites. They were on the tools that build them. In March 2025 a build tool used by more than 23,000 code repositories was altered to steal secrets. In September 2025 a self-spreading worm compromised hundreds of published code packages that developers install without reading. OWASP, the body that lists the most serious web application risks, moved supply-chain failures to third on its 2025 list.
So a site with no server-side application still has a supply chain, the code libraries it is built from, the build service, and any script it loads from someone else’s server. We pin dependencies to known versions and update them deliberately, keep third-party scripts to the minimum, and run the build with the least access it needs. That does not make the risk zero. It makes it small, known and watched.
Every site, however built, needs a tested way back. That means backups that exist somewhere other than the server they back up, that are taken often enough that losing the gap would not hurt, and that have been restored at least once to prove they work. A backup nobody has restored is a hope.
For a static site, the whole site and every change ever made to it lives in a version-controlled repository in your name or transferable to you on request, and rolling back is a one-line change. For a site that stays on WordPress, it means database and file backups on a schedule, kept off the host, with a restore drill in the calendar.
When we say a site we build is secure, we mean all of the following, and each can be checked.
/wp-login.php to your address and see what appears.)A good answer to all four is possible on any platform. A vague answer to any of them is the thing to worry about.
The Websites page builds to it. WordPress migration moves a site from the large back door to none. Ongoing care is the patching, the backups and the restore drill as routine work. The Website Risk Analysis checks a site you already have against every line of it and gives you the immediate actions in writing.
If you cannot answer the four questions about your own site, that is the place to start.