How to Secure WordPress with Cloudflare After a Hack
If your WordPress site has already been hacked, Cloudflare can help you reduce exposure fast while you clean up the damage.
This guide explains how to secure WordPress with Cloudflare after hack events and which settings matter most in real recovery work.
Cloudflare does not remove malware from your server, but it can block repeat attacks, hide your origin server, and add layers that make a compromised site harder to exploit again.
Start by confirming the site is clean
Before tightening security, verify that the infection is actually contained.
If malicious code still exists on the origin server, Cloudflare alone will only mask the symptoms.
- Scan WordPress core, plugins, themes, and uploads for unfamiliar PHP files.
- Review recent administrator accounts, API tokens, and database users.
- Check for injected redirects, spam links, and modified .htaccess or wp-config.php files.
- Reset all passwords for WordPress, hosting, FTP/SFTP, database, and Cloudflare.
After cleanup, update WordPress core, plugins, and themes to current versions.
If a plugin or theme was the entry point, remove it until you can verify it is safe.
Put Cloudflare in front of your WordPress site
To use Cloudflare effectively, your domain must be proxied through Cloudflare DNS.
This means visitors connect to Cloudflare first, and Cloudflare forwards approved traffic to your server.
Once the orange cloud proxy is enabled on the right DNS records, your origin IP is less exposed.
That matters because many post-hack attacks target the server directly once they find the real IP address.
- Enable the proxy for the main domain and www record.
- Keep mail-related records unproxied if required by your email provider.
- Confirm the site loads correctly over HTTPS after the switch.
Lock down the origin server IP
One of the most important steps after a breach is preventing attackers from bypassing Cloudflare.
If they can reach your server IP directly, they can ignore many Cloudflare protections.
Use your hosting firewall, security group, or server-level firewall to allow inbound web traffic only from Cloudflare IP ranges.
This reduces direct access to ports 80 and 443 from the public internet.
- Allow only Cloudflare IP ranges to reach web services.
- Block direct requests to the origin IP from all other sources.
- Keep SSH, control panel, and database ports closed to public access whenever possible.
Cloudflare publishes current IP ranges, and they should be reviewed periodically.
If your host supports it, use a firewall rule set that can be updated automatically.
Set the SSL/TLS mode correctly
After a hack, insecure transport settings can create a second entry point or expose login sessions.
Cloudflare’s SSL/TLS configuration should always match your origin setup.
Use Full or Full (strict) mode, with Full (strict) preferred because it validates the certificate on your origin server.
Avoid Flexible SSL unless you have no other option, because it leaves Cloudflare-to-origin traffic unsecured.
- Install a valid origin certificate or use a trusted certificate from a public CA.
- Turn on Always Use HTTPS.
- Enable Automatic HTTPS Rewrites only if your content still contains insecure links.
If the site was hacked through mixed content or outdated redirects, these HTTPS controls help reduce downgrade attacks and session leakage.
Use firewall rules to protect wp-login and wp-admin
WordPress login pages are high-value targets after a compromise because attackers often return with stolen credentials or brute-force attempts.
Cloudflare Firewall Rules or WAF rules can reduce this risk quickly.
Restrict access to wp-login.php and wp-admin where possible.
For sites with a fixed admin team, you can allowlist trusted IP addresses or require additional challenges for these paths.
- Challenge or block repeated login attempts.
- Restrict admin paths by IP, country, ASN, or hostname where appropriate.
- Protect xmlrpc.php if you do not need it for Jetpack or remote publishing tools.
For many sites, the best approach is a layered one: allow trusted office or home IPs, challenge unknown visitors, and rate-limit abusive behavior.
Turn on Bot Management and rate limiting?
Automated attacks often continue after a hack because the site becomes a known target.
Cloudflare can help separate real users from bots and slow attack volume.
If your plan includes Bot Management, enable it for login, checkout, and form submission pages.
If not, use available bot fight features and rate limiting for sensitive endpoints.
- Rate-limit login endpoints such as wp-login.php.
- Watch for bursts of POST requests to comment forms and XML-RPC.
- Challenge suspicious traffic patterns from low-reputation networks.
These controls do not replace WordPress hardening, but they reduce repeated abuse while you rebuild trust in the site.
Cache safely and bypass dynamic WordPress pages
After a breach, performance settings can accidentally cache pages that should remain dynamic, such as admin screens or logged-in views.
Review Cloudflare cache rules carefully.
Exclude authentication pages, wp-admin, checkout flows, and any personalized content from caching.
Static assets such as images, CSS, and JavaScript can still be cached to reduce server load.
- Bypass cache for wp-admin, wp-login.php, cart, checkout, and account pages.
- Cache only safe static assets.
- Use development mode temporarily if you are testing cleanup changes.
Incorrect caching can preserve bad content longer than expected, so confirm cache settings after any cleanup or theme restoration.
Enable DNS and registrar security
Attackers sometimes return through the domain rather than the application.
A secure DNS and registrar setup is essential after any compromise.
- Turn on two-factor authentication for your Cloudflare account.
- Enable registrar lock and domain transfer protection.
- Use strong, unique passwords for domain, hosting, and admin accounts.
- Limit access to DNS changes to a small set of trusted users.
If someone can edit DNS records, they can redirect traffic to a malicious server even if WordPress itself is clean.
Protecting the domain is as important as protecting the CMS.
Use Cloudflare logs and analytics to spot repeat abuse
After a hack, visibility matters.
Cloudflare’s analytics can help you identify which traffic patterns are still suspicious and whether mitigation rules are working.
Review firewall events, blocked requests, and countries or ASNs with unusual activity.
Look for repeated hits to login pages, admin paths, and old plugin URLs that should no longer exist.
- Monitor spikes in 403, 429, and 5xx responses.
- Check for requests to known vulnerable plugin directories.
- Inspect user agents that look like scraping tools or brute-force frameworks.
These signals can tell you whether you have fully removed the original attack vector or if someone is still probing the site.
Combine Cloudflare with WordPress hardening
Cloudflare is strongest when it is part of a broader recovery plan.
Use it alongside core WordPress security practices so a single weakness does not reopen the site.
- Keep WordPress, themes, and plugins updated.
- Remove unused themes and plugins instead of deactivating them.
- Use least-privilege administrator accounts.
- Set up regular backups stored off-site.
- Install security monitoring that alerts on file changes and login anomalies.
For membership sites, WooCommerce stores, and high-traffic blogs, consider a staged approach: Cloudflare edge protection, host-level firewall rules, file integrity monitoring, and scheduled malware scans.
What to check in the first 24 hours after a hack?
If you need a rapid response plan, focus on the highest-impact actions first.
These steps reduce the chance of reinfection and protect users while you investigate.
- Change all passwords and revoke active sessions.
- Clean or restore the site from a known-good backup.
- Enable Cloudflare proxying and lock the origin IP.
- Set SSL/TLS to Full (strict).
- Protect wp-login.php, wp-admin, and xmlrpc.php with firewall rules.
- Review DNS, registrar settings, and admin accounts.
If email or customer data may have been exposed, notify the affected parties according to your legal and business requirements.
Security recovery is not only technical; it also involves access control, communication, and ongoing monitoring.
Common mistakes to avoid when using Cloudflare after a breach
Many site owners add Cloudflare but leave dangerous gaps open.
Avoid these common errors so the same attack does not succeed twice.
- Leaving the origin IP public and unprotected.
- Using Flexible SSL with a live production site.
- Forgetting to block direct access to admin endpoints.
- Caching pages that should stay private or dynamic.
- Assuming Cloudflare cleans malware from the server.
When you secure WordPress with Cloudflare after hack incidents, the goal is not just to restore access.
The real objective is to remove direct attack paths, reduce login abuse, and make future compromise much harder.
Keep the protection policy documented
Once your defenses are in place, document the rules that matter most.
A clear record helps your team keep Cloudflare, hosting, and WordPress settings aligned during future updates or emergencies.
- Record which DNS records are proxied and which are not.
- Document firewall allowlists and login restrictions.
- Keep a list of approved admin accounts and recovery contacts.
- Schedule periodic reviews of SSL, WAF, and backup settings.
Well-documented controls make it easier to respond quickly if the site is targeted again, and they help preserve the security gains you made during recovery.