WordPress Security Statistics 2026: Melapress Survey Results

The Melapress WordPress Security Survey is back for 2026!

We run this survey each year to get more clarity on how WordPress professionals approach security, including how they deal with incidents, how they protect their sites, and where the biggest gaps might lie.

This year, we got more respondents than ever before, reaching a broad audience across WordPress agencies, developers, designers, website owners, and administrators. This post covers the most interesting results and statistics we found in the 319 responses.

Have a question about the report or something to add? Join the discussion on Reddit.

Security concern is still high, and barely changed from 2025

One of the clearest results from this survey was that concern about WordPress security is high, at an average of 7.85 out of 10. That’s almost exactly the same as in last year’s survey, when it was at 7.8 out of 10.

This year, more than three quarters of respondents (76.9%) rated their concern at 7 out of 10 or higher, while just over half (50.3%) placed themselves at the very top end of the scale with a score of 9 or 10. 37.5% of respondents rated their concern at 10/10, up slightly from 34% in 2025.

Taken together, the results suggest that security concern in the WordPress space has not changed much over the past year. 

Subscribe for more survey stats we haven’t published yet.

Please enable JavaScript in your browser to complete this form.

Email *

It’s free to get these insights, and you can unsubscribe whenever you want. Read our Privacy policy

Name

Get more insights

Web designers remain less concerned than technical roles

As in 2025, concern also varied depending on the respondent’s role. Developers averaged 8.23 out of 10, compared with 7.03 among web designers. Last year, web designers were also the least-concerned role, with an average score of 7.2 out of 10.

Different levels of exposure to security incidents may be a reason for this. Of the respondents who answered the questions relating to incident history, 80.0% of developers said they had experienced at least one security incident, compared with 63.2% of web designers.

However, the gap doesn’t necessarily mean web designers underestimate security. Their work might just expose them to different responsibilities and consequences than developers, who are often directly involved in maintaining, troubleshooting, and securing WordPress websites.

Security incidents are common, and so are repeat incidents

Security incidents are not an edge case among the WordPress professionals we surveyed. 67.7% of respondents reported experiencing at least one known security incident.

For many, that experience was not limited to a single event. 32.3% of all respondents said they had experienced two to five incidents, while another 13.2% reported more than five.

These statistics show how common security incidents are, but not the full human and business impact behind them. That’s why we asked respondents to share more about what happened after an incident and created the Wall of Security Stories. It brings together first-hand accounts that reveal the human and business impact behind the statistics, how people responded, and what they learned from the experience.

Repeated incidents are associated with stronger security practices

The data also suggests that repeated incident experience is associated with a more security-conscious setup today.

Respondents who reported more than five incidents averaged 8.56 out of 10 for security concern, compared with 7.74 among everyone else. They also reported an average of 4.81 of the predefined security controls, versus 3.92 among other respondents.

Some individual controls showed particularly large differences. 61.9% of respondents with more than five incidents used role-based access control, compared with 41.2% of everyone else, while 78.6% used login security policies, versus 58.1% among other respondents.

Side note: Incident history looks backwards, whereas the survey records the controls respondents have in place today. For this reason, we cannot say that respondents with more incidents were better protected when those incidents occurred. 

Likewise, a higher number of incidents does not necessarily mean a respondent started out with weaker security. Agencies, developers, and larger organizations may manage more websites, operate more complex environments, or simply have greater exposure to potential attacks. The data shows an association between repeated incident experience and stronger current security practices, but it does not tell us why those incidents happened.

Preparedness has barely moved since 2025

WordPress professionals continue to take security seriously, but that concern doesn’t always translate into better preparation for what happens when something goes wrong.

Only 27.9% of respondents reported having a breach recovery plan in 2026, virtually unchanged from the 27% recorded in our 2025 survey.

The picture is almost identical for security training. 26.0% of respondents reported having team security training in place, the same percentage as in 2025.

This gap remains even among the people who are most concerned about security. Of respondents who rated their concern between 7 and 10 out of 10, only 32.5% had a breach recovery plan, while 27.9% reported team security training.

There are similar gaps when looking at specific concerns. As an example, among the 90 respondents who identified compliance as a security concern, only 27.8% had a breach recovery plan. In other words, 72.2% did not report having one, even though incident response and recovery planning can be an important part of meeting compliance requirements.

This is also true for website defacement and monitoring, which is one of the controls people implement to detect things like website defacement. Of the 173 respondents concerned about website defacement or reputational damage, 37.0% did not use activity logs or monitoring.

Taken together, the year-over-year figures point to security concern remaining high, but two basic areas of preparedness, recovery planning and training, have barely moved at all. There are also still clear gaps when looking at the concerns WordPress professionals have compared to the security controls they implement.

In-house teams are still more likely to have recovery plans

Who manages security also appears to make a substantial difference.

In our 2025 survey, 31% of respondents whose security was managed in-house had a breach recovery plan, compared with only 13% when security was managed by a third party.

A similar gap appears in 2026. 35.5% of respondents whose security was managed by an in-house developer or systems administrator reported having a breach recovery plan, compared with 22.8% of those whose security was managed by an agency or freelance developer/sysadmin.

That does not necessarily mean externally-managed websites are dramatically less prepared. In some cases, an agency may maintain its own incident-response processes without the client thinking of them as a formal “breach recovery plan”. The result could point to a communication or visibility gap between agencies and their clients, rather than simply an absence of preparation all together.

Either way, it raises an important question for outsourced WordPress security. Does the person responsible for the website know what will happen when an incident occurs?

How WordPress security incidents are actually discovered

Preventing every security incident is unrealistic. How quickly an organization detects one can be just as important as the controls designed to prevent it.

The survey shows a mixture of proactive detection and discovery only after somebody or something external notices a problem.

The most commonly reported discovery method was someone reporting strange behavior on the website, cited by 42.6% of respondents with a confirmed incident.

This is a particularly important finding because it represents a relatively reactive form of discovery. By the time a visitor, customer, colleague, or administrator notices that something looks wrong, an incident may already have become visible enough to affect normal website operation.

By comparison, 38.4% of incident respondents said an incident was discovered through logs or alerts from a logging tool. This was the most commonly reported detection method based on a dedicated monitoring control.

That highlights the practical value of activity logging and monitoring. Rather than waiting for visible symptoms or an external warning, logging tools can provide another route for detecting suspicious activity as it happens.

Other detection methods were also quite common. 35.6% discovered an incident following an alert from their hosting provider or server, while 30.1% reported detection through a malware scanner.

At the other end of the spectrum, 17.1% said a search engine warning played a role in discovering the incident.

The distinction matters. A security system flagging suspicious activity is very different from learning about a compromised website because a visitor notices something unusual or a search engine has already identified a problem. The survey suggests that a significant proportion of WordPress incidents are discovered through these later, more visible signals.

When the search engine notices first, the damage tends to be worse

Incidents discovered through search-engine warnings were associated with more serious outcomes in various areas.

Among incidents discovered through a search engine warning, 45.9% involved a loss of search rankings, compared with only 14.5% of incidents discovered through other methods.

Reputational damage showed a similar pattern. 51.4% of incidents involving a search engine warning resulted in reputational damage, compared with 31.4% of other incidents.

Compliance and legal consequences were also substantially more common. 16.2% of incidents discovered through a search engine warning involved compliance or legal issues, versus just 3.5% of other incidents.

These figures do not mean that search engine warnings cause more serious damage. A more likely explanation is that incidents serious or persistent enough to attract a search engine’s attention may already have progressed further before being discovered.

That makes this specific finding another argument for earlier detection. Ideally, the first sign of a security incident should come from your own monitoring systems, not from a customer, a hosting provider, or a search engine.

What security incidents cost WordPress sites

Security incidents do not all lead to catastrophic outcomes, but, more often than not, there is some form of negative impact.

Among respondents with a confirmed incident, website downtime was by far the most common consequence, reported by 68.4%.

That makes availability more than just a theoretical concern. For many WordPress professionals, the most immediate cost of a security incident is simply that the website stops working properly (and all the secondary impacts that come from this).

Other consequences were less common, but still significant. 34.9% of incident respondents reported reputational damage, while 20.1% experienced a loss of search rankings.

The same proportion (20.1%) reported a loss of client trust, showing that the effects of an incident can continue even after the technical problem itself has been resolved.

Direct financial impact was also present. 16.3% of respondents said their most serious incident resulted in lost revenue.

The experiences shared through our Security Stories show what this longer-term damage can look like in practice. One ecommerce website owner described discovering the impact of a hack through Google Search Console:

“After logging in to Google Search Console, I saw traffic had basically gone to 0. Unfortunately, the rankings never fully recovered, and I was left with about 65% of the traffic I had pre-hack.”

This is one example of how the cost of a WordPress security incident can extend far beyond cleaning malware or restoring a compromised website. You can read the full story here.

What WordPress professionals are worried about, and what changed

While overall concern about WordPress security barely moved year over year, there were some shifts in the specific risks people are worried about.

Website availability is still the most commonly selected concern in 2026, chosen by 55.8% of respondents, down slightly from nearly 60% in 2025.

Website defacement or reputational damage was close behind at 54.2%, up from 50% in 2025.

The next most common concern was data theft or loss, which fell to 46.4%, down from 53% in 2025.

Compliance increased slightly from 26% in 2025 to 28.2% in 2026. Finally, financial loss was also selected by 28.2% of respondents.

The risk picture changes by website type

The ranking also changes considerably depending on the type of website a respondent works on.

Among respondents working on blog and content sites, 67.2% selected website availability as a major concern, compared with 49.3% among respondents who did not select blog or content sites.

For membership websites, data protection and reputation stood out more strongly. 60.3% of membership-site respondents were concerned about data theft or loss, compared with 42.6% of other respondents. 63.2% were concerned about website defacement or reputational damage, versus 51.8% among everyone else.

The pattern was similar for ecommerce websites, where the financial and data stakes are higher. 56.6% of ecommerce respondents were concerned about data theft or loss, compared with 41.3% of respondents not working on ecommerce sites. Financial loss was also more prominent, selected by 35.8% of ecommerce respondents, compared with 24.4% of others.

These differences highlight that there isn’t a single WordPress security risk profile. A content publisher may be most worried about staying online, while an ecommerce or membership site has more reason to focus on customer data, transactions, and the reputational fallout of a breach.

Some site types appear more security-mature than others

The survey also suggests that security practices differ substantially depending on the type of WordPress website being managed.

Respondents working on corporate or brand websites were much more likely to use activity logs or monitoring. 70.2% reported having these controls in place, compared with 46.6% of respondents who did not work on corporate or brand websites.

The differences were even more pronounced among membership websites, where access control and continuity are particularly important. 44.1% of membership-site respondents had a breach recovery plan, compared with 23.5% of other respondents.

Membership-site respondents were also much more likely to use role-based access control: 66.2% compared with 37.8% among respondents not working on membership sites.

Ecommerce sites combine higher concern with stronger preparation

Ecommerce respondents also stood out.

Among respondents with a valid concern score, 85.7% of those working on ecommerce websites rated their security concern at 7 out of 10 or higher, compared with 72.5% of respondents not working on ecommerce sites.

That higher level of concern was accompanied by stronger preparation in some areas. 35.8% of ecommerce respondents reported having a breach recovery plan, compared with 23.9% of non-ecommerce respondents.

The consequences of incidents also looked different for ecommerce websites.

Among ecommerce respondents who had experienced an incident and answered the impact question, 31.9% reported losing search rankings, compared with 13.9% among non-ecommerce incident respondents.

Likewise, 29.2% of ecommerce incident respondents reported a loss of client trust, compared with 15.3% among respondents not working on ecommerce sites.

These differences do not necessarily mean ecommerce websites are less secure. They may simply have more at stake: transactions, customer accounts, personal data and revenue all depend directly on the website remaining trustworthy and available.

What the data does suggest is that higher-risk website types tend to show both greater concern and, in several areas, stronger security practices. At the same time, their incidents can carry broader business consequences when something does go wrong.

What to do with this information

The survey suggests that WordPress professionals are highly aware of security risks, but awareness does not always translate into preparation.

For most organizations, the next step is not simply adding more tools. It is making sure the controls already in place cover prevention, detection, and recovery in a balanced way.

Create and test a breach recovery plan before an incident happens

A recovery plan is only useful when it has been created (and tested) before it is actually needed.

Define who is responsible for responding to an incident, how compromised systems will be isolated, where clean backups are stored, how websites will be restored and who needs to be informed internally or externally.

The plan should also be tested periodically. A backup that has never been restored or a response process that has never been rehearsed can create a false sense of preparedness.

Make sure you can detect an incident

Customers, hosting providers and search engines can all help surface security problems, but ideally they should not be the first people or systems to tell you something is wrong.

Use activity logging, malware scanning, alerts and other monitoring controls to identify suspicious activity as early as possible.

The goal is not simply to collect more security data. It is to make sure relevant events are visible and that someone is responsible for reviewing and acting on them.

Track user and system activity with detailed logs and alerts for suspicious changes.

Get WP Activity Log

Treat security training as a core control

Security is not purely a technical problem.

Developers, administrators, content teams and other users can all make decisions that affect the security of a WordPress website. Training should therefore be treated as part of the security setup.

This does not necessarily require a large formal training program. The important part is making sure the people who manage or use the website understand the threats relevant to their role, know the organization’s security processes and stay up to date as those risks change.

Keep internal ownership even when security is outsourced

Working with an agency, freelancer or using a managed service can remove much of the day-to-day security workload, but responsibility should not disappear entirely from within your business/organization.

Someone internally should still understand who is responsible for each part of security, what happens when an incident occurs and how recovery will be coordinated.

In particular, make sure there is a clear answer to questions such as: Who receives security alerts? Who can authorize emergency changes? Who restores the website? Who communicates with customers or stakeholders? And who decides when the incident has been resolved?

Outsourcing security works best when responsibilities are clearly divided rather than assumed.

At Melapress, we have plenty of resources that can help you review the fundamentals, identify gaps, and turn the recommendations above into practical steps:

• The complete guide to WordPress security
• Our practical WordPress security checklist
• A guide to using WordPress user roles to improve security
• And if you want to explore how enterprises and businesses approach WordPress security, we recommend listening to our Melapress Show episode.

The important part is to review your security setup regularly and ensure your team understands its role in prevention, detection, and recovery.

Who we surveyed and methodology

• The 2026 survey includes 319 confirmed, valid responses. Duplicate and invalid entries were removed by the Melapress team before analysis.
• Responses were collected between 31 March and 29 July 2026 (UTC).
• Respondents included agencies, developers, web designers, website and business owners, and WordPress administrators. They worked across corporate and brand websites, service websites, blogs and content sites, membership sites, ecommerce websites, and other types of WordPress sites.
• Responses were collected through a broad mix of channels, including in-person and virtual third-party events such as WordCamp Europe, company and partner newsletters, social media, third-party online communities, and similar channels.
• We made an effort to reach a broad audience beyond Melapress’ own channels. Well over half of all responses came through third-party channels. However, a significant minority still came through Melapress-owned channels, which may have influenced some of the results. We have taken this into account when interpreting the findings, particularly where the results relate closely to the types of security controls covered by Melapress products.
• Where an individual question was left unanswered, or an invalid answer was given without invalidating the response as a whole, that answer was excluded from the calculation for that question. As a result, the number of responses used may vary slightly between questions. For example, one result may be based on all 319 responses while another may be based on 317 valid responses for that specific question covered. These differences were generally small, but we wanted to be transparent about them.