Putting WordPress Behind Cloudflare Doesn't Make It Secure

A website can be running perfectly well and still be dealing with hundreds of requests from bots that have no interest in buying anything, reading anything, or using the service as intended.

Some are crawling pages. Others are probing for vulnerable endpoints, trying common login paths, or generating enough traffic to put pressure on the server. Depending on the target and the type of activity, the result can range from annoying analytics reports to a slow website, an overloaded server, or an actual security incident.

This is becoming a serious consideration for anyone managing websites, particularly agencies responsible for dozens or hundreds of WordPress installations.

One response is to put every site behind Cloudflare. It is an understandable decision. Cloudflare can provide a protective layer between visitors and the origin server, filter certain kinds of unwanted traffic, and help absorb distributed denial-of-service attacks. Its DNS, proxying, firewall and caching capabilities can also simplify parts of website protection and delivery.

For agencies managing multiple client websites, having a consistent layer of protection across their portfolio makes practical sense.

But there is an important distinction that tends to disappear in these conversations: protecting a website's infrastructure and securing the website itself are two different jobs.

Cloudflare can help with the first. It does not automatically take care of the second.

WordPress security is more than blocking bad traffic

WordPress is popular partly because it is accessible. A business can launch a website without building a custom application from scratch, choose a theme, install plugins, connect a few services, and have something useful online in a relatively short time.

That accessibility is one of its strengths. It also means that the quality of the finished website depends heavily on the decisions made by the people building and maintaining it.

A wordpress installation may contain the core software, a theme, several plugins, custom code, administrator accounts, hosting configurations and integrations with external services. Each component introduces its own maintenance requirements and potential security concerns.

An outdated plugin may contain a vulnerability. A compromised administrator account may give an attacker access to the dashboard. An insecure custom implementation may expose information it should not expose. A poorly configured server may allow access that the website owner never intended to provide.

Cloudflare does not automatically fix those problems.

If a vulnerable plugin allows an attacker to compromise WordPress through a request that reaches the origin server, putting the site behind a proxy does not make the vulnerability disappear. If an administrator uses a compromised password, the website still needs appropriate account security. If custom code exposes sensitive information, a caching and traffic-filtering service is not a substitute for fixing the code.

This is why the claim that a website is secure because it uses Cloudflare is too broad.

It may have better protection against certain attacks. That is valuable. But the overall security of the website still depends on everything behind that protective layer.

The traffic problem is only part of the story

Not every bot request is an attack.

Search engines crawl websites so they can discover and index pages. SEO tools collect information. Monitoring services check whether websites are available. Other automated systems retrieve publicly accessible information for legitimate purposes.

Then there are bots that probe for vulnerabilities, scrape content aggressively, or send requests in patterns that consume resources without providing any value to the site owner.

The difficult part is distinguishing useful automation from unwanted activity without blocking legitimate visitors or services.

A site receiving thousands of automated requests does not necessarily mean it has been hacked or is under a denial-of-service attack. The volume, request patterns, source distribution, target endpoints and effect on the origin server all matter.

Still, even traffic that does not qualify as a conventional attack can create operational problems. Crawlers may consume bandwidth, generate excessive PHP requests, trigger expensive database queries, or place unnecessary pressure on an already limited hosting environment.

For a small business website on shared hosting, that can become a real problem long before anyone attempts to steal data.

Cloudflare's traffic filtering, rate limiting, caching and other security controls can help reduce some of this pressure. The appropriate configuration depends on the traffic and the site's requirements. Aggressive rules can also block legitimate customers, search engine crawlers or integrations if they are applied without care.

The goal is not to block everything that looks automated. It is to stop unwanted activity while keeping the website available to the people and services that need it.

Cloudflare needs to be configured properly

There is a difference between having a Cloudflare account and using Cloudflare as part of a properly designed security setup.

A domain can use Cloudflare for DNS without proxying its web traffic through Cloudflare's protective network. When the relevant DNS records are proxied, HTTP and HTTPS requests can pass through Cloudflare before reaching the origin server, allowing supported security and performance features to operate.

But even a proxied website can have weaknesses in its configuration.

For example, if the origin server remains directly accessible from the public internet, an attacker may be able to bypass Cloudflare and send requests straight to the hosting server. Whether that is possible depends on the server setup, exposed IP addresses, firewall rules and other details.

Where appropriate, origin access should be restricted so that web traffic reaches the server through Cloudflare's authorized network, with the necessary exceptions for legitimate services and administration. Cloudflare's origin-facing security options, including authenticated origin connections where supported, can provide additional protection.

The exact implementation depends on the hosting environment. A shared hosting account, a virtual private server and a managed WordPress platform do not necessarily offer the same level of control.

The principle, however, is straightforward: if Cloudflare is supposed to stand between the public internet and your origin server, configure the origin so that the protection cannot simply be bypassed.

The same thinking applies to security rules. Turning on a setting is not the end of the job. You need to understand what it protects, what it might block, and whether it is working as intended.

The uncomfortable part: attackers use Cloudflare too

Cloudflare is not exclusively a service for legitimate businesses. It is infrastructure that can be used by different kinds of operators, including people with malicious intentions.

An attacker can use Cloudflare in front of infrastructure they control, just as a legitimate website owner can. That does not mean Cloudflare provides the attacker with immunity or that its services are inherently unsafe. It means that using a particular infrastructure provider does not, by itself, establish whether a website is trustworthy.

This is worth remembering when investigating suspicious traffic or infrastructure.

A request associated with Cloudflare does not automatically mean the request is legitimate. Equally, the fact that a suspicious website uses Cloudflare does not prove that Cloudflare itself is responsible for the activity.

The service provider and the person using the service are different things.

For defenders, the practical lesson is to evaluate the behaviour, destination, request patterns and available evidence rather than treating a provider's name as a verdict.

Security decisions should be based on what the traffic is doing, not simply which infrastructure appears in the connection.

Agencies have a bigger responsibility

For an individual website owner, security can be easy to postpone. The site is working, customers can place orders, and there is always another design change or marketing task that seems more urgent.

For an agency managing many WordPress websites, that approach becomes much harder to justify.

Every additional client site adds another installation to maintain. Each one may have different plugins, themes, hosting environments, administrator accounts and business requirements. A vulnerability or compromised credential on one site can create a serious problem for the client, and the agency may be the first organization they turn to for help.

Putting every site behind Cloudflare is a reasonable starting point for a consistent security strategy. It can standardize important parts of traffic protection and make some controls easier to manage across a portfolio.

But the agency still needs a process for the parts Cloudflare does not manage.

That means keeping WordPress core, themes and plugins updated; removing software that is no longer needed; limiting administrator access; using strong authentication; maintaining reliable backups; monitoring for suspicious changes; and having a recovery process that does not depend on hoping the latest backup works.

It also means understanding the hosting environment and the security responsibilities that come with it.

A website does not become secure because someone installed a security plugin, activated a Cloudflare proxy, or added a badge to a proposal. Security comes from how the different parts of the system work together and how consistently they are maintained.

The challenge is not that every WordPress website needs an elaborate enterprise security operation. Many small websites can be protected effectively with a sensible, proportionate setup.

The challenge is that somebody has to take responsibility for that setup.

DNS, hosting and security are not the same thing

Another point in the discussion deserves attention: a business can host its website somewhere else while keeping its DNS on Cloudflare.

That is a perfectly normal arrangement. DNS determines how domain names resolve to the relevant services. Cloudflare can manage DNS while the website itself runs on a separate hosting provider.

When the relevant web records are proxied, Cloudflare can also sit in front of the website's origin server. But DNS hosting alone does not mean that all website traffic is passing through Cloudflare's proxy or receiving its web security protections.

This distinction matters because people sometimes describe their setup as being protected by Cloudflare when they have only moved their DNS management there.

Those are not equivalent configurations.

Before deciding what additional protection a website needs, establish what is actually in place. Is Cloudflare handling DNS only? Are the web records proxied? Are security rules enabled? Can the origin be reached directly? Does the hosting provider already provide a firewall, malware monitoring or other protections?

You cannot evaluate the security of a setup accurately without understanding its components.

A sensible security baseline

For most WordPress businesses, the objective should be to build a security setup that addresses several layers rather than searching for one service that promises to handle everything.

Cloudflare can help protect the public-facing edge of the website. The hosting environment needs appropriate access controls and configuration. WordPress itself needs regular maintenance, sensible permissions and secure authentication. Backups need to be reliable and recoverable. Monitoring needs to provide enough visibility to detect problems and investigate them.

These layers serve different purposes.

A firewall may block a malicious request, but it cannot guarantee that every vulnerability is covered. A backup can help restore a website, but it does not prevent the initial compromise. Regular updates reduce exposure to known vulnerabilities, but they do not eliminate every risk. Strong authentication protects accounts, but it does not repair insecure code.

The objective is to avoid relying on any single control as if it were a complete security strategy.

For an agency, that process should be repeatable. Every site should have a defined maintenance routine, clear ownership of security responsibilities, an appropriate protection configuration and a tested recovery plan. The details can vary according to the site's importance and complexity, but the responsibility should never be ambiguous.

Cloudflare is a layer, not a security strategy

The growing volume of automated traffic gives website owners a good reason to reconsider how they protect their sites. Cloudflare can be a valuable part of that response, especially for agencies looking for a consistent way to protect multiple websites against unwanted traffic and certain network-level attacks.

But the presence of Cloudflare does not tell you whether a WordPress website is properly maintained, whether its administrator accounts are secure, whether its origin server is exposed, or whether its backups can be restored after an incident.

Those questions still need answers.

The same applies when an attacker uses Cloudflare or another major infrastructure provider. The name of the service tells you very little about the intentions of the person using it.

A sensible approach is to put the right protection in front of the website, secure the application behind it, restrict unnecessary access, keep the software maintained and make sure recovery is possible if something goes wrong.

Cloudflare can take care of an important part of that work.

It cannot take responsibility for the whole website.

And that is the part every website owner and WordPress agency needs to understand.