WordPress DDoS Attack Site Down Fix

Activate Cloudflare "Under Attack Mode" or Similar WAF

If your site is behind Cloudflare or another Web Application Firewall (WAF) like Sucuri, activate their "Under Attack Mode" or equivalent feature immediately. This will present a JavaScript challenge to visitors, effectively filtering out most bot traffic before it reaches your server. If you don't have one, consider temporarily changing your DNS to point to a free Cloudflare account or similar service to get immediate protection.

✓ 5-10 minutes. Essential first step if a WAF is available.

Analyze Access Logs & Block Malicious IPs/User Agents

SSH into your server and examine your web server access logs (e.g., /var/log/apache2/access.log or /var/log/nginx/access.log). Look for common IP addresses making an unusually high number of requests, or specific user agents that don't belong (e.g., empty, suspicious strings, or known botnets). You can use commands like awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -n 20 to find top IPs.

Block these IPs using your server's firewall (ufw, iptables, or CSF/LFD if installed) or via .htaccess for Apache, or Nginx configuration. For Apache, you can also block specific user agents.

# Example .htaccess block for specific IPs
<Limit GET POST>
  Order Allow,Deny
  Allow from All
  Deny from 192.168.1.100
  Deny from 10.0.0.0/8
</Limit>

# Example .htaccess block for User-Agent
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "badbot|anotherbadbot" [NC]
RewriteRule ^(.*)$ - [F,L]

✓ 15-30 minutes. Requires SSH access and familiarity with server logs.

Disable wp-cron.php & Set Up System Cron

To prevent wordpress wp-cron being abused by bots, disable the default WordPress cron behavior. This stops wp-cron.php from firing on every page load. You'll then need to set up a proper system-level cron job to ensure scheduled tasks still run.

Add the following line to your wp-config.php file, ideally just above /* That's all, stop editing! Happy publishing. */:

define('DISABLE_WP_CRON', true);

Then, create a system cron job (via cPanel cron jobs or SSH crontab -e) to run wp-cron.php every 5-15 minutes:

*/5 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

✓ 10-15 minutes. Crucial for mitigating self-DDoS from bot traffic.

Limit Access to xmlrpc.php and wp-login.php

These files are frequent targets for brute-force and DDoS attempts. If you don't use XML-RPC (e.g., for Jetpack, mobile apps, or remote publishing), disable it. For wp-login.php, you can restrict access to known IP addresses if your team works from static IPs.

Add this to your .htaccess file (for Apache) or Nginx config:

# Block XML-RPC access
<Files xmlrpc.php>
  Order Deny,Allow
  Deny from All
</Files>

# Restrict wp-login.php to specific IPs (replace with your IPs)
<Files wp-login.php>
  Order Deny,Allow
  Deny from All
  Allow from 192.168.1.1
  Allow from 172.16.0.0/16
</Files>

✓ 5-10 minutes. Significantly reduces attack surface. See also: WordPress Brute Force Attack on Login Page and WordPress XMLRPC and Application Password Brute Force Attack Fix.

Review & Disable Unnecessary Plugins/Themes

Sometimes, a vulnerable or poorly coded plugin/theme can be exploited, or simply consume excessive resources under load, exacerbating a DDoS. If you can access wp-admin, deactivate plugins one by one to see if performance improves. If not, you can rename the wp-content/plugins directory via FTP/SSH to disable all plugins at once. Similarly, switch to a default theme (e.g., Twenty Twenty-Four) by renaming your active theme's directory.

✓ 10-20 minutes. Helps identify resource hogs or exploited components.

Contact Your Hosting Provider

Even with the above steps, a severe DDoS can overwhelm shared hosting environments. Inform your hosting provider immediately. They have server-level tools and network-level protections that you don't. They can often implement null-routing for malicious IPs, increase resource limits temporarily, or advise on specific server-side configurations. Provide them with details from your log analysis.

✓ 5 minutes. Essential for large-scale attacks.