Fixing a 429 Too Many Requests error

A 429 Too Many Requests error means something sent too many requests too fast and a server (ours, an upstream API, or a plugin) cut it off to protect itself. The fix depends on who's doing the throttling: check whether it's your server rate-limiting a visitor or bot, or an external API rate-limiting your site. Start with the error log to see which one you're dealing with.

Find the source

Open cPanel from your hosting service and check Error Log under Metrics. A 429 usually shows up one of two ways:

• Your site is returning 429 to visitors. This means our server-level protections, Imunify360, or a security plugin decided a client was making too many requests and started blocking it.
• Your site is receiving 429 from somewhere else. A plugin, theme, or custom code is calling an external API (payment processor, shipping calculator, social feed, AI service) too often, and that API is throttling you back. Look in /wp-content/debug.log if you're on WordPress, or your app's own logs, for the failing request's URL and response body. See Enabling error logging if logging isn't already on.

Aggressive crawlers and bot traffic

A common cause of outbound 429s: search engine bots, SEO tools, or scrapers hitting your site so hard that your own server or a service you depend on starts throttling the traffic. Check Raw Access Logs in cPanel and look for one IP or user agent making a disproportionate number of requests in a short window.

To handle this:

• Legitimate bots (Googlebot, Bingbot) that crawl too fast can usually be slowed down with a Crawl-delay directive in robots.txt, though major search engines increasingly ignore it in favor of their own webmaster tools settings.
• Bad bots and scrapers that ignore robots.txt entirely need to be blocked outright. Add a deny rule for the offending IP or user agent in .htaccess, or block it at the firewall level if your plan supports one.
• If the volume is high enough to affect real visitors, that's a resource or abuse pattern worth reviewing. If it turns out your account is actually the one generating outbound abusive traffic (compromised scripts, for example), that's also a suspension trigger; see Why was my account suspended? for what counts as resource abuse.

Plugin and API loops

The most common self-inflicted 429 on WordPress sites: a plugin polling an external API on every page load, or a broken webhook retrying in a loop after a failed request. Symptoms include a site that feels slow, an API dashboard showing a spike in calls from your domain, or the plugin itself throwing errors about rate limits.

To find the culprit:

1. Turn on WordPress debug logging (see Enabling error logging) and watch /wp-content/debug.log for repeated calls to the same external URL.
2. Deactivate plugins one at a time (starting with anything that syncs data, pulls a feed, or integrates a third-party service) and check whether the 429s stop.
3. Once you've found the plugin, check its settings for a polling interval or caching option, update it to the latest version, or replace it if it's abandoned and no longer respects the API's rate limits.

If the loop is in custom code rather than a plugin, the fix is usually to cache the API response instead of calling it on every request, or to add backoff logic so a failed call doesn't retry immediately.

If it's our server blocking you

If Imunify360 or another server-level rule is the one issuing the 429, it's reacting to request volume it considers abnormal, not blocking you arbitrarily. Confirm the pattern in the access log first: a sudden burst of identical requests, a login form being hammered, or a script hitting an endpoint in a tight loop are the usual triggers. Fixing the source (blocking the bot, fixing the loop) resolves the block; the throttling itself isn't something you disable, since it's what's protecting the server from the same problem in the first place.

When to contact support

If you've checked the logs and can't tell whether the 429 is coming from us or an external service, or you believe legitimate traffic is being blocked, open a ticket from Support → New ticket in the portal. Include the URL that's returning the 429, the approximate time it happened, and any relevant log lines; a real person will confirm whether the block is server-side and help you get it lifted if it's a false positive.