429 Too Many Requests: How to Find the Cause and Fix It

By Rahul S., founder and SEO consultant at SearchCounselCo. Updated October 15, 2026.

Capture one failed request before changing settings

A page may open while its login, form, AJAX call or inventory sync fails. Capture the request returning 429, rather than only the address in the browser’s address bar.

1. Open developer tools and select Network before reproducing the action.
2. Clear unrelated entries. Enable Preserve log if navigation would remove the request.
3. Repeat the ordinary failing action once. Avoid repeatedly submitting an order, payment or booking.
4. Enter status-code:429 in the filter box, then select the failed request.
5. Inspect Headers and Response. Record its URL, HTTP method, time/timezone, status, request ID and any Retry-After value. Read the provider’s error condition when present.
6. Inspect the Initiator information where available. Match the request with the relevant security event, server log or integration record.

Chrome’s Network reference documents these inspection features. An initiator is the script or action that started a request; it is a clue to investigate, not automatic proof that the script caused the limit.

Keep credentials, cookies and customer data out of shared captures. If a backend makes the external call, the browser may show only your backend’s response; inspect that backend’s redacted provider record too.

curl --silent --show-error --output /dev/null --dump-header - \
  --max-time 20 --write-out '\nhttp_code=%{http_code}\n' \
  'https://example.com/'

Find the component that returned the 429

The HTTP 429 specification does not prescribe one way to count requests or identify users. Find the issuer—the component returning the rejection—and its counter key, meaning the identity used to group requests. That identity might be an IP address, account, token or another configured value.

On a small screen, scroll inside the table to see every column.

An error-page logo or Server header is not enough to identify a rule. Correlate time, path, method and client context. For the wider investigation, use the technical SEO guide.

Ask hosting which component rejected the request, what identity it counted and which other callers shared that identity. Behind a proxy, verify the intended visitor-IP handling using the provider’s restoration guidance. Trust the intended proxy chain rather than accepting any forwarded header as a client identity.

Keep different responses separate: 403 concerns denied access, 503 temporary unavailability, and 504 a gateway wait. Some rate limiters use a different response code. Server capacity and an overly broad rule need different remedies.

Fix the WordPress action that triggers the limit

Start with the failing path and task. A security plugin may reject an incoming request, while a product-sync plugin may receive 429 from an external API. Disabling the site firewall will not resolve an external provider’s exhausted allowance.

When login, AJAX or REST requests fail

• For /wp-login.php, match the legitimate login attempt to the relevant security event. Establish whether one user, one network or a wider group is affected.
• For /wp-admin/admin-ajax.php, identify the action and browser initiator. Several unrelated features use that same handler.
• For a /wp-json/ request, record its exact route, method and authentication context. Do not treat every REST request as the same operation.

When a scheduled job or external sync fails

Read the response from the external host and check the provider’s documented condition. List other jobs sharing that account or quota. Look for duplicate schedules, overlapping workers or retry policies before changing the website’s inbound protection.

A WordPress developer should distinguish a WP_Error object from an HTTP response. A received 429 is not established as success because is_wp_error() is false. Inspect the response status code and the intended application outcome.

Use the right evidence and isolate one component

1. Save the incident record and note recent plugin, theme, deployment or rule changes.
2. Use a backup and suitable staging environment. Record the active configuration and restoration steps.
3. Isolate the implicated component or setting, then repeat the same action. Restore it if the evidence does not support that cause.
4. Compare under the relevant cooldown and workload conditions. One 200 after a pause may only mean a rate window reset.
5. Verify the saved result, next job cycle and continuing protection before calling the repair complete.

The WordPress troubleshooting documentation covers recovery procedures. If the dashboard is inaccessible, have the administrator use the host’s supported recovery tools. Changing every plugin at once can obscure the cause and interrupt unrelated features.

A PHP debug log is not a universal HTTP access log. Follow the WordPress debugging handbook for suitable diagnostics, keep errors off public pages and remove temporary logging when finished.

Investigate a Cloudflare rate limit without removing all protection

Confirm which Cloudflare product is involved. Its 429 documentation distinguishes management-API calls, R2 public access and website end users. An API account quota is not a visitor rule for your website.

1. Open the affected zone’s Analytics page and Events tab, following the current Security Events guidance.
2. Narrow the time range and filter using the incident’s available host/path, client and request details.
3. Expand a matching event. Record the service, action and rule, rather than relying on the visible error page alone.
4. Inspect that rule in Security rules. Review its matching criteria, counting characteristics, threshold, period and action using the dashboard guide and parameter reference.
5. If the evidence confirms a false positive, preserve the original settings, make a scoped correction and retest the affected legitimate path and intended protection.

Security Events can be sampled and does not list all traffic. Narrowing the time range may improve visibility; a missing event does not prove Cloudflare was uninvolved. One request can generate multiple events. A Ray ID is useful context, but is not guaranteed unique.

Available settings depend on the plan. Check whether cached requests count and how visitors are grouped. Follow the rate-limiting best practices, including consistent path interpretation between edge and application. Retain a rollback and the protection the rule was meant to provide.

For APIs, identify the condition before retrying

Read the response body, provider error code and relevant headers. The same status can represent different conditions. Use the provider’s documentation rather than a universal reset-time assumption.

On a small screen, scroll inside the table to see every column.

For example, Stripe documents distinct rate and concurrency reasons, plus provider-specific lock behavior. OpenAI documents temporary rate errors separately from exhausted credit and enforced spending or usage conditions. These are provider examples, not rules for every API.

Check who already retries the request

A job runner, application wrapper and SDK may each retry. Account for their combined behavior before adding another loop. OpenAI’s guidance notes existing SDK retries; AWS’s engineering guidance explains how retries can multiply across layers.

Choose a coordinated retry policy that bounds attempts and waits across the operation. Queue or schedule work for later when appropriate. Do not replace one uncontrolled loop with several independent ones.

Read Retry-After and decide whether repetition is appropriate

Retry-After can contain whole seconds or an HTTP date. It may be absent. A header does not explain every provider error or make every operation appropriate to repeat.

On a small screen, scroll inside the table to see every column.

For eligible retries, spread callers with suitable jitter, coordinate shared quotas and bound attempts and waits. Do not assume that a new token creates a new allowance: the provider may count an account or another shared identity.

HTTP semantics define safe methods, PUT and DELETE as idempotent. Automatically repeating a non-idempotent operation needs suitable application semantics or evidence of its state. Use a provider’s documented idempotency mechanism when supported; inventing a header does not create that support.

Check the recorded outcome before resubmitting a payment, order or booking. The 429 specification also prohibits caching the 429 response itself. Caching eligible successful content to reduce origin work is a different action.

Why can 429 appear after one visible request?

The service may have counted earlier calls from another tab, job, worker or user sharing the same identity. One click may also start multiple requests, and the relevant window may be longer than the period you observed. These are hypotheses to verify against the actual rule or provider record.

Ask which counter the rejected request used and what contributed to it. In an earlier local shared-counter test, actor A used both permitted requests and actor B’s first request received 429. The actors were test labels, not real IP or NAT identities. That model illustrates a mechanism; it does not identify your site’s cause.

Measured examples: the same 429, different mechanisms

A controlled Python HTTP run on October 15, 2026 used a server bound to 127.0.0.1. It covered five scenarios with 23 requests and six passing assertions. No WordPress, Cloudflare, real API account or SDK was tested.

On a small screen, scroll inside the table to see every column.

The credit case used three attempts 20 ms apart, then an explicit test-state change. It does not prove that waiting can never resolve every account condition. The concurrency case held two admitted requests while probing a third. The retry layers were custom functions, not a measurement of SDK defaults.

{
  "condition": "credit_exhausted",
  "status": 429,
  "retry_after": null
}

from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from threading import Thread
from urllib.error import HTTPError
from urllib.request import ProxyHandler, build_opener
import json

class Handler(BaseHTTPRequestHandler):
    def log_message(self, *_args):
        pass
    def do_GET(self):
        self.send_response(429)
        self.send_header("Content-Length", "0")
        self.end_headers()

server = ThreadingHTTPServer(("127.0.0.1", 0), Handler)
thread = Thread(target=server.serve_forever, daemon=True)
thread.start()
url = "http://127.0.0.1:" + str(server.server_port)
opener = build_opener(ProxyHandler({}))

def count_calls(outer_attempts, inner_attempts):
    calls = 0
    for _ in range(outer_attempts):
        for _ in range(inner_attempts):
            calls += 1
            try:
                with opener.open(url, timeout=2) as response:
                    response.read()
                    raise RuntimeError("expected the lab's 429")
            except HTTPError as error:
                with error:
                    error.read()
                    if error.code != 429:
                        raise
    return calls

try:
    print(json.dumps({
        "two_layers": count_calls(3, 3),
        "one_owner": count_calls(1, 3)
    }))
finally:
    server.shutdown()
    server.server_close()
    thread.join(timeout=5)

A socket timeout is not a promised operation deadline

A separate local urllib probe set a 0.2-second timeout and received eight slowly supplied bytes. It completed in 0.406 seconds. In that test, the timeout value did not enforce an absolute elapsed-operation deadline.

Python’s documentation describes that timeout in terms of blocking operations. The local examples illustrate request and retry behavior; production clients need separate treatment of cancellation, slow reads, transport errors, response limits and operation semantics.

Check whether search crawlers receive the same failure

Google’s crawler documentation treats 429 as an overload signal and temporarily slows crawling. Persistently failing indexed URLs can eventually be dropped; there is no universal recovery time. Successful serving can allow crawling to increase gradually.

• Confirm which crawler and exact public URL received the failure.
• Verify claimed Google requests using Google’s documented methods, rather than a user-agent string alone.
• Correlate the failed request with hosting or CDN evidence and the relevant Search Console report.
• Correct the confirmed cause, then monitor subsequent real requests and successful serving.

Google retired Search Console’s manual Crawl Rate Limiter on January 8, 2024. Follow current crawler-response guidance and the crawl-error investigation rather than searching for that old control.

For other automated clients, the crawler-access guide separates permission, firewall decisions and actual fetch success. If the failed request is a sitemap, use the sitemap-fetch workflow. A visitor’s successful page load does not establish crawler access.

Verify the affected action and retain the intended protection

Retest the same permitted action, path and relevant identity after the targeted correction. One unrelated 200 response is not enough.

• Legitimate access: the affected user or client group can complete the original action.
• Application outcome: the save, sync or other operation produced the correct stored result.
• Confirmed cause: the relevant log, rule or caller behavior matches the correction.
• Protection retained: controlled staging checks or appropriate monitoring show intended excess is still handled.
• Relevant duration: observe the cooldown, workload period or next job cycle that originally failed.

Keep the original configuration and rollback record. If symptoms persist, return to the failed request rather than stacking speculative changes.

Copy this incident worksheet

Use this record when asking hosting, a developer or a provider to investigate. Replace the field labels with your details and remove secrets before sharing. This page does not submit a form.

Focus the field, select all and copy. On a phone, touch and hold the text to use your device’s selection controls.

Frequently asked questions

The one thing to do next

Capture one failed request and identify the component and condition that explain it. If legitimate visitors or crawlers remain blocked, a technical SEO review can help trace the request path and organize the evidence needed for hosting or development.