Is WordPress secure – and is a coded website more secure?

WordPress core has few vulnerabilities – six in 2025, all of them low priority. Even so, a WordPress website is not secure on its own. In 2025, 91% of the vulnerabilities in the WordPress ecosystem were in plugins and 9% in themes, according to Patchstack. So whether a website gets hacked depends on what has been installed around the core and on whether anyone keeps it updated. This guide covers what actually gets hacked, what you can do about it, what a breach does to your visibility in Google and whether a coded website is more secure – including the risks it has too.

Is WordPress secure?

The core is largely secure, but what is installed around it is not necessarily so. Patchstack, State of WordPress Security in 2026 (updated 25 February 2026) recorded 11,334 new vulnerabilities in the WordPress ecosystem during 2025. That is 42% more than the year before. 91% were in plugins and 9% in themes. In the core itself, six vulnerabilities were found, all of them low priority.

Serious vulnerabilities are rising too: 1,966 of them (17%) were rated high severity – more than in the previous two years combined.

Most telling of all, 46% of the vulnerabilities had no fix available when they were made public. Keeping everything updated is necessary, but it does not protect you against a vulnerability the developer has not yet patched. That leaves two forms of protection: not having the plugin installed, or a firewall that stops the attack before it reaches the code. Patchstack sells that kind of protection itself, but other security companies give the same advice about firewalls.

What decides your security is who maintains what runs on the server, and how much runs there.

Why do WordPress websites get hacked?

WordPress websites are hacked mainly through plugins and themes that are not updated in time, and the attackers are fast. WordPress is also the biggest target: the platform runs 39.5% of all websites and 58.3% of websites with a known CMS, according to W3Techs (October 2026). A vulnerability in a popular plugin can therefore open thousands of websites at once.

The most common ways in:

• Vulnerable plugins and themes. This is where almost all known vulnerabilities are. In Patchstack's list of the ten most exploited vulnerabilities of 2025, all ten were in plugins, and seven could be exploited without logging in (Patchstack).
• Outdated installations. The update exists, but nobody has installed it.
• Weak logins. The login page is public, passwords are reused and two-factor authentication is missing.
• Shared hosting without protection. Without a firewall and isolation between customers, a breach at a neighbour can spread.

The risk can also sit beneath WordPress. In October 2026, two serious security flaws were found in PHP, the language WordPress runs on (SVT, in Swedish). If your website is on an ordinary shared hosting plan, the host updates PHP – so the host decides when your website is secure again. We cover what that means for your choice of platform in Alternatives to WordPress 2026.

The window to act is short. For the most exploited vulnerabilities of 2025, the weighted median time was five hours from the vulnerability becoming known to the first attack Patchstack observed. Roughly half of the high-impact vulnerabilities were exploited within a day. A website that is updated once a month can therefore stay open for weeks.

Sucuri's report on hacked websites shows the same pattern from the other side. In Sucuri's data for 2023 (39,594 cleaned websites and just over 108 million remote scans), 95.5% of the detected infections were on WordPress websites. Sucuri itself points out that the figure does not mean the platform is more or less secure than others – it reflects how widespread WordPress is and who uses Sucuri's services. More useful: 39.1% were running an outdated CMS when they were infected, and 49.21% had at least one backdoor (Sucuri, 2023 Hacked Website & Malware Threat Report). A backdoor left behind is a common way for attackers to get back in, which is why removing the visible damage is not enough.

Does WordPress update itself?

The core does partly; plugins and themes do not by default. Since version 3.7, WordPress installs minor versions and security updates of the core automatically (WordPress Developer Resources). Since version 5.5, automatic updates can be switched on per plugin and theme, but the feature stays off until someone activates it (Make WordPress Core).

The problem is that the parts responsible for almost all vulnerabilities do not update themselves. If nobody has switched the feature on – or switched it off after an update broke a page – every plugin stays on the version that was installed.

Automatic updates can also cause trouble. An update can change how a page looks or stop a form from working. So switch them on for well-maintained plugins, and make sure someone checks the website afterwards. Test larger updates – such as a new theme or a new version of a page builder like Elementor – on a copy of the website first.

Is a security plugin enough?

No. A security plugin such as Wordfence is one layer of several – and another plugin to keep updated. It can block known attacks and alert you to changed files, but it does not replace maintenance. What makes the biggest difference fits in a short list:

1. Fewer plugins. Every plugin is code from another supplier running on your server. Remove the ones you do not use, because a deactivated plugin still sits on the server.
2. Replace plugins that are not maintained. If a plugin has not been updated for a long time, or has been closed in the WordPress.org plugin directory, replace it.
3. Automatic updates and a check afterwards. See the section above.
4. Two-factor authentication and individual accounts. Each person has their own account with only the permissions they need.
5. Backup off the server. A backup on the same server can disappear or be infected in the same breach. Test that restoring actually works.
6. Hosting with a firewall. A server-level firewall stops attacks before they reach WordPress, even against vulnerabilities that do not yet have an update.

There are longer checklists, but these six points cover the routes in described above. We cover the basic hygiene that applies to every website, whatever the platform – HTTPS, security headers and security.txt – in the website checklist for 2026.

Is a coded website more secure than WordPress?

A static coded website has a much smaller attack surface than WordPress. A server-rendered one has a server to protect, and every coded website has dependencies that must be updated. A coded website can be built in three ways, which partly overlap:

• Static (pre-rendered). The framework, for example Astro, builds every page into finished HTML files before they are published. The files are delivered from a CDN. There is no database and no login on the website.
• Server-rendered. The framework, for example Next.js with a server, builds the page when the visitor requests it. Code runs on a server or in serverless functions on every request.
• With a headless CMS. The content lives in a headless CMS such as Sanity – a hosted service with its own login – and the website fetches it when it is built or when the page is shown. The front end can be static or server-rendered. Headless WordPress is a variant where WordPress is the CMS.

The table shows where the work and the risk end up in each architecture. The attack surface ratings are our own assessment.

The less that runs on the server, the less there is to update and the fewer ways in. A static website has the smallest surface. A server-rendered website has a server and a framework to keep updated. Webflow leaves platform maintenance to the supplier. WordPress – and to some extent headless WordPress – leaves most of it to you. In none of these architectures does the risk disappear; it just ends up in different places.

Three events in 2025 show that a coded website is not secure on its own:

• Next.js middleware (CVE-2025-29927). A vulnerability with a CVSS score of 9.1, made public on 21 March 2025, let attackers bypass checks in Next.js middleware, for example login protection (GitHub Advisory Database). Static exports were not affected. According to Vercel, projects hosted on Vercel, Netlify or Cloudflare Workers were not affected either (Vercel's postmortem).
• React2Shell (CVE-2025-55182). A vulnerability in React Server Components with the highest possible CVSS score, 10.0, which allowed remote code execution without logging in (React, 3 December 2025). In Next.js it was tracked as CVE-2025-66478 and affected the App Router in versions 15 and 16 (Next.js).
• The npm attacks in September. On 8 September 2025, 18 popular packages were hijacked, including chalk and debug, which together had over two billion downloads a week. The malicious code ran in visitors' browsers, targeted crypto transactions and was discovered within a few hours (Aikido). Later in September came Shai-Hulud, a self-propagating attack that, according to CISA hit over 500 packages and stole access keys to GitHub and cloud services.

The first two hit code that runs on the server. The npm attacks hit the build chain and could reach even a static website, if a hijacked package ended up in the code sent to the visitor.

We describe how a coded website with a headless CMS is built in practice in AI-assisted web development with a headless CMS. The whole decision to switch – where to, what it costs in year 1 and year 3, and how the move is done – is covered in Alternatives to WordPress 2026, and Webflow versus WordPress in detail in Webflow vs WordPress.

Can a static website be hacked?

Yes, but not in the same way. There is no database to inject code into and no login page on the website to guess passwords against. Cloudflare, which itself offers hosting for this type of website, writes that the lack of a connection between website and database reduces vulnerabilities (Cloudflare). Instead, the attacks shift to what surrounds the website:

• Accounts. Anyone who gets into the CMS account, the code repository or the hosting account can publish anything.
• Domain and DNS. If the domain account is hijacked, the traffic can be redirected to another server.
• Forms. Serverless functions or third-party services receive the forms, and they need to validate input and be protected against spam and abuse.
• Third-party scripts. Chat, analytics and ad tags run in the visitor's browser. If the supplier is compromised, your website is hit too.
• The build chain. The packages used when the website is built, as in the npm examples above.

So the protection looks different: two-factor authentication on every account, few people with access, locked package versions and a review of which scripts are actually needed.

What happens to your SEO if the website is hacked?

A breach can become an SEO problem before it shows up as an IT problem. Sucuri found SEO spam on 20.3% of infected websites in 2023. Some breaches are designed to make money from your domain's standing in Google, not to destroy the website, so you may notice nothing when you visit it.

A well-known pattern: the attacker creates masses of auto-generated pages on your domain, often in Japanese, with affiliate links to shops selling counterfeit branded goods. The pages then appear in Google's search results. Some variants hide the pages from the owner, who gets a fake "page not found" on a direct visit (Google on the Japanese keyword hack). Others redirect visitors arriving from the search results to a different website altogether (Google on the gibberish hack).

Here is what can happen in Google:

• A warning in the search result. Google can label the result "This site may be hacked" (Google Search Help), and the browser can show a full-page warning before the visitor reaches the website (Google Search Console Help). The warning may be the first thing a potential customer sees.
• The Security issues report in Google Search Console. It shows whether Google has found hacked content, malware and unwanted software or social engineering, with examples of affected URLs (Google Search Console Help). It is worth checking even when everything looks normal.
• Lower rankings. Google writes that a flagged website can rank lower for a period (Google Search Console Help).

How long it lasts depends on how long the breach went on and how much was indexed in the meantime. That is why it pays to spot breaches early. Connect Google Search Console to the website, send the notifications to an inbox someone reads and run a site: search on the domain now and then to see what Google has actually indexed. Security issues, a manual action and an algorithmic drop produce the same traffic curve but are handled differently – see Google penalty or lost rankings?.

Our WordPress website has been hacked – what do we do?

Isolate the website, restore from a clean backup, change every password, update everything and ask Google to review the website again. In that order:

1. Isolate. Put the website in maintenance mode or ask the hosting company to take it offline temporarily. Save logs and a copy of the infected installation – they show how the attacker got in.
2. Restore from a clean backup. Choose a backup from before the breach. If there is none, the files and database must be cleaned – and removing what you can see is not enough. If a backdoor remains, the attacker can come back.
3. Change every password. WordPress accounts, the database, the hosting account, SFTP and email accounts connected to the website. Generate new security keys in wp-config.php, remove administrator accounts you do not recognise and switch on two-factor authentication. Also check who the owners are in Google Search Console – attackers sometimes add themselves there (Google).
4. Update and clean up. Core, plugins and theme to the latest version. Remove what is not used, and replace the plugin that let the attacker in if it has no update.
5. Ask Google to review. Check that the spam pages no longer exist, then request a review in the Security issues report. According to Google, the review takes anything from a few days to several weeks, and requesting it before the website is fully clean only extends the time it is flagged (Google on requesting a review).

If your website is down or has been hacked, we offer urgent help. You can read how it works and what it costs in Help with your website.

When is WordPress still the right choice?

WordPress is a reasonable choice when someone owns the maintenance and the website needs what WordPress does best. That is often the case when:

• You have an update routine. Someone updates every week, checks the website afterwards and reacts when a serious vulnerability is published.
• The website has few, well-known plugins. Every plugin has a reason to be there and a supplier that maintains it.
• You depend on features that other platforms lack. Membership systems, courses or a WooCommerce shop with niche integrations.
• You have your own WordPress developer. Then the responsibility is already assigned.
• The website is content-heavy and the editorial team knows WordPress. The cost of retraining can be greater than the gain from a switch. Headless WordPress is a middle ground that keeps the editing tool but moves the public front end away from the WordPress server.

So whether WordPress is right for you depends more on maintenance than on the platform. If these points fit, security is manageable. If they do not, a coded website with a headless CMS, or Webflow, is often a better fit, because there is less ongoing maintenance.

How does SEOS Design help you secure or switch?

There are two routes, and which one fits depends on how the website is built and who will own it going forward.

Stay and secure it. If you want to keep WordPress, we often start with a review of the installation: plugins, update status, accounts, backup and hosting. Maintaining an existing WordPress website works best when it is well built and has few plugins. You can see what maintenance can cover on our page about maintenance and support.

Switch. If you want to minimise ongoing maintenance, a coded website with a headless CMS, or Webflow, is often the right route. We explain how to make the decision in Alternatives to WordPress 2026, and how we build under a new website for your business and headless CMS agency. A coded website does not require a maintenance agreement with us. If you have your own developer, they can take over maintenance entirely. Without your own developer, a smaller maintenance agreement is often a good idea, because the dependencies also need updating.

We will give you a recommendation once we know more about your needs. Get in touch with your website's address and what concerns you.