Fix a Stuck or Failed Cookie Scan

The cookie scanner visits your site’s pages to detect the cookies, scripts, and third-party services in use. Most scans finish on their own. When one stalls, returns nothing, or won’t start, the cause is almost always something between our scanner and your site: a security tool, a certificate, or a host limit. This guide works through each case in order.

First, Check These

The scanner reaches your site over the public internet, so a few things need to be in place:

• Your site is publicly accessible – The scanner cannot reach sites behind HTTP basic auth, a VPN, maintenance mode, or a coming-soon plugin. Turn these off while scanning.
• Your site is not on localhost or a private network – Local addresses and development domains are unsupported. You will see: “Cookie scanning is not available for localhost or development sites.”
• HTTPS is active with a valid SSL certificate – Verification fails on a self-signed, expired, or mismatched certificate. If you hit an HTTP 422, start with the SSL certificate check below.
• The WordPress REST API is reachable – The scanner verifies your site by requesting /wp-json/surecookie/v1/. A firewall that answers with 401 or 403 blocks verification.
• WordPress cron is running – If you see the “WordPress Cron is Disabled” notice, scans may not progress. Enable WP-Cron or set up a server cron job.

Scan Is Stuck or Shows No Progress

When the Latest Scanning Logs drawer detects no progress for about five minutes, it shows a “Scan appears stuck” warning with the message “No progress detected after [time]” and lists possible causes.

Try these steps first:

1. Refresh the Cookie Manager page.
2. Open the All Cookies list to check whether the detected cookies are already there.
3. Clear your browser cache and reload.
4. Clear any server-side or page cache and reload again.

Note: A “Failed to load scanned cookies” error (common on staging sites) is usually a display problem, not a failed scan. The scan often completed and saved cookies in the background. Refresh Cookie Manager and check the All Cookies list before retrying.

If the scan is genuinely stalled:

1. Click Cancel Scan in the drawer (or Cancel Stuck Scan on the scanner page).
2. Reduce the number of pages selected.
3. Click Start Scan again.

The scan runs in the background, so you can safely navigate away. A scan can run up to 30 minutes before it times out.

Other causes to consider:

• A page caused a browser timeout – Pages with heavy JavaScript take longer and can time out. Exclude unusually heavy pages and scan fewer at once.
• Your host is throttling or timing out – Ask your host whether PHP execution time, memory, or outbound-request limits constrain background tasks. A server-level firewall may also be blocking the scanner.
• The scan server is under temporary load – Wait a few minutes and run the scan again.

Scan Won’t Start or Fails to Connect (HTTP 422 / Registration Errors)

Before your first scan, SureCookie runs a one-time Connect step that verifies you own the domain. Our servers request a verification token from your site over HTTPS. If that handshake fails, you will see an error such as “Registration step 2 returned unexpected response (HTTP 422)” or “Could not reach the plugin verification endpoint.” The Connect step runs once per domain.

First, open the All Cookies list to confirm the scan didn’t already finish in the background.

If it didn’t, an HTTP 422 means our server could not verify your site. Work through the causes below in order.

Check Your SSL Certificate First

This is the most common cause on new sites and staging domains, and it is easy to miss because the site still opens in your browser.

Our verification connects over HTTPS and needs a certificate it can trust. If your site serves a self-signed, expired, or mismatched certificate, verification fails with an HTTP 422 even though the page loads normally for visitors. A browser lets you click past a certificate warning; our server cannot.

This shows up in two common situations:

• Brand-new sites where the SSL certificate has not been issued yet.
• SiteGround temporary domains (addresses ending in sg-host.com). Until you install a certificate, SiteGround serves a default placeholder certificate issued to “example.com“, which our server cannot trust.

To fix it:

1. Confirm the cause: open your site and check the padlock in the address bar. A warning, or a certificate issued to a name other than your domain, points to this.
2. Install a valid certificate. On SiteGround, go to Site Tools → Security → SSL Manager and install a Let’s Encrypt certificate for the domain, then allow a few minutes for it to go active. Most other hosts offer a similar one-click SSL option.
3. Or run the scan on your live domain, which already has a valid certificate, instead of a temporary staging address.
4. Once the certificate is active, return to SureCookie and click Start Scan again.

Rule Out Security Tools

If the certificate is valid, something on the site may be intercepting the verification request. Test each of these, re-enabling it afterward:

1. Temporarily disable security and firewall plugins (for example Wordfence or Solid Security), run the scan again, then re-enable them once it succeeds.
2. Pause your CDN or proxy (such as Cloudflare), retry the scan, then re-enable it.
3. Turn off Maintenance Mode or Coming Soon mode while you scan.
4. Deactivate and reactivate the SureCookie plugin, then start the scan again.

Host-Level Bot Protection

Some hosts run bot protection at the server level, separate from any plugin. SiteGround’s Anti-Bot AI is one example. These systems can serve our scanner a security challenge (a CAPTCHA or block page) instead of your real page.

The sign of this is a scan that connects but comes back almost empty (0 cookies, with few or no scripts detected), or verification that keeps failing, even though your site loads fine for visitors and has a valid certificate. Because the challenge targets automated traffic, it affects only the scanner, not your visitors.

Host-level bot protection often cannot be allowlisted by a single IP address. If you have ruled out the causes above and suspect this is happening, contact support with your scan logs and tell us your host. We can confirm it from our side and advise on the best path for your setup.

Related Cases

• HTTP 429 (rate limited) – Too many scan attempts in a short period. Wait 15 to 30 minutes; the limit clears on its own.
• “Registration step 1 failed” or a network error – Our servers could not reach your site at all. Recheck the prerequisites, especially public accessibility, SSL, and REST API access.
• The domain is already registered – Each domain completes the Connect step once. If you moved or reinstalled the site, contact support to reset registration.

Scans or Commands Fail Under WP-CLI

If a WP-CLI command fails with a filesystem or FTP-credentials fatal error, WordPress is auto-detecting FTP as the filesystem method in the CLI context.

Add the following line to your wp-config.php to force direct filesystem access: define( ‘FS_METHOD’, ‘direct’ );

This bypasses FTP auto-detection.

Daily Scan Limits

If a scan stops partway and shows “Scanned [X] of [Y] pages” followed by a note that your daily page budget is exhausted, you have hit a quota, not an error. The remaining pages scan automatically after the limit resets.

• Free plan – Scans up to 5 pages per scan.
• Daily page budget – The page allowance is shared across all sites connected to the same license. When it is exhausted you will see “Daily Limit Reached”, and credits refresh automatically the next day.

When to Contact Support

If you have worked through the prerequisites and steps above and the scan still won’t run, send us the scan logs:

1. Open the Latest Scanning Logs drawer.
2. Click Copy Logs for Support.
3. Include the copied logs in your message.

Also tell us:

• Your site URL, and whether it is live or staging.
• Your hosting provider.
• The exact error message or HTTP status code.
• Which fixes you have already tried.

You can offer temporary WordPress admin access if you are comfortable doing so. Support often needs it to investigate HTTP 422 verification failures.