WordPress Could Not Complete a Loopback Request

What Site Health is telling you: WordPress tried to make an HTTP request to its own URL and did not get a usable response. Nothing about the front end is necessarily broken, but the features that rely on loopbacks are.

What depends on it

• WP-Cron, unless you have replaced it with a system cron — see how to disable WP-Cron.
• Fatal error protection in the theme and plugin editors, which tests a change by calling the site before applying it.
• Several Site Health checks, including the REST API and scheduled event tests.
• Some backup and import plugins that trigger background processing.

The usual causes, in order

1. HTTP authentication. A staging site behind a password prompt blocks the loopback the same way it blocks a browser. This is the most common cause on staging and the least alarming.

If the site must stay protected, allow the server's own IP through, or accept the warning on staging and check that it does not appear on production.

2. A hosts-file override or split DNS. The server cannot resolve its own domain to itself — common right after a migration, when DNS still points at the old host. The site resolves externally to the new server and internally to the old one.

Test from the server:

curl -sI https://example.com/wp-cron.php | head -1
curl -sI https://example.com | head -1

A timeout or a wrong response from the server itself confirms the resolution problem. The fix is usually a hosts entry on the server pointing the domain at 127.0.0.1 or the local IP — a host support request on managed platforms.

3. A security plugin or firewall. Rules that block requests without a normal user agent, rate-limit repeated requests from one IP, or block the server's own IP will stop loopbacks. Check the plugin's block log around the time of the failed check; the entry is usually there.

4. SSL problems. If the certificate does not validate from the server's perspective — a self-signed certificate, a missing intermediate, or a mismatched hostname — the loopback fails while browsers may still be satisfied. Verify the chain:

curl -vI https://example.com 2>&1 | grep -Ei 'subject|issuer|verify'

The certificate side is covered in fixing the not secure warning.

5. The site URL is wrong. WordPress loops back to whatever siteurl says. If that value still points at an old domain or a local development address, the request goes somewhere that cannot answer. Check Settings → General, or the constants in wp-config.php.

6. Server resource limits. If PHP has no spare workers, the loopback request queues behind the request that made it and times out. This shows up under load and disappears when the site is quiet — the mitigation is caching, per how to speed up a WordPress site.

Diagnose it directly

Run the loopback yourself from PHP, in a temporary must-use plugin:

<?php
add_action('admin_init', function () {
    if (! current_user_can('manage_options') || ! isset($_GET['ts_loopback'])) {
        return;
    }

    $response = wp_remote_post(admin_url('admin-ajax.php'), [
        'timeout'   => 10,
        'body'      => ['action' => 'nopriv_loopback_test'],
        'sslverify' => true,
    ]);

    if (is_wp_error($response)) {
        wp_die('Loopback failed: '.esc_html($response->get_error_message()));
    }

    wp_die('Loopback status: '.wp_remote_retrieve_response_code($response));
});

Load any admin page with ?ts_loopback=1, read the result, then delete the file. The error message is the useful part:

Workarounds when the cause cannot be removed

Replace WP-Cron with a system cron. This removes the most important dependency on loopbacks entirely, and is worth doing regardless — the steps are in how to disable WP-Cron.

Allow the server's own IP in the security plugin and any firewall.

On a password-protected staging site, accept the warning. It is expected there, and the protection is more valuable than the check.

Verify

Re-run Tools → Site Health after each change rather than after all of them, so you know which one worked. Then confirm the practical outcome: schedule a post a few minutes ahead and check that it publishes, and confirm the next backup runs on time.