Fix guides

Fix: No response — timeouts, DNS, SSL/TLS and connection errors

Pages show No response when our server gets no HTTP answer. Fix timeouts, DNS and IPv6 records, SSL certificate chains and refused or reset connections.

Updated Oct 24, 2026

No response in the Pages tab means our server never got an HTTP answer from the site. There’s no status code because the request failed before the server could send one. These pages are counted in the Server errors (5xx) issue.

Find the affected pages in the app

  1. Open Site crawl and the latest crawl.
  2. On Overview, the status chart shows No response with a count.
  3. On Pages, search or scroll for rows with status No response.
  4. In GEO and Local SEO audits (Audits), the same problem shows as The page could not be downloaded (timeout, DNS error or blocked address).
  5. Then find which of the four causes below it is (Timeout, DNS error, SSL/TLS error, Connection refused or reset), with the test in each “How we detect it”.

Timeout

How we detect it

No connection within 10 seconds, or no data for 25 seconds. Test:

curl -sS -o /dev/null --max-time 40 -w "connect %{time_connect}s, TLS %{time_appconnect}s, first byte %{time_starttransfer}s, total %{time_total}s\n" https://example.com/

Why it matters

Slow pages lose visitors, and Google lowers its crawl rate for sites that answer slowly.

Common causes

  • If connect is above 10 seconds or curl hangs before connecting → a firewall silently drops packets (from our IP only, or from all data-centre IPs), or the server is overloaded.
  • If connect is fast but first byte is above 25 seconds → the page is slow to build (PHP, database, external API calls).
  • If only some pages time out → those templates are slow (search, filters, big categories).
  • If the crawl starts fine and then times out → the server slows down under a series of requests, or a firewall starts dropping us after a number of requests.

Fix: basic

  1. Allowlist 147.93.19.85 and 2a02:4780:12:d33e::1 in the firewall or security plugin (see What to allowlist).
  2. Turn on full-page caching (WordPress: LiteSpeed Cache › Cache › Enable Cache, or WP Rocket, or W3 Total Cache Performance › General Settings › Page Cache).
  3. Turn on the host’s CDN if it offers one (Cloudflare, QUIC.cloud, hPanel Performance › CDN).
  4. On shared hosting, check Metrics › Resource Usage (cPanel) for CPU or entry-process limits at crawl time.
  5. Click Crawl again in Site crawl.

Fix: expert

Find slow requests in the server logs. nginx with $request_time in the log format:

log_format timed '$remote_addr "$request" $status $body_bytes_sent $request_time $upstream_response_time';
access_log /var/log/nginx/access_timed.log timed;
awk '$1=="147.93.19.85" && $(NF-1) > 5' /var/log/nginx/access_timed.log | tail -n 20

Then fix the slow template (database indexes, caching, removing slow external calls). See the 504 section of Fix: Server errors (5xx) for timeouts and slow-query logging.

Platform steps

WordPress

Install Query Monitor, open the slow page while signed in, and check Queries by Component and HTTP API Calls.

Cloudflare

In the Cloudflare dashboard › your site › Caching › Cache Rules, turn on caching for HTML with a Cache Rule only if the site has no logged-in or cart pages on the same URLs; otherwise cache static files only.

Verify the fix

The curl timing shows first byte well under 5 seconds. Crawl again in Site crawl shows status codes instead of No response.

Automation

Assisted: needs hosting panel or server SSH; WordPress admin for caching plugins.

DNS error

How we detect it

Our server can’t find the domain’s IP address, or gets an address that doesn’t answer. Test:

dig +short A example.com
dig +short AAAA example.com
dig +short A www.example.com
dig +short AAAA www.example.com
curl -4 -sS -o /dev/null -w "IPv4: %{http_code}\n" https://example.com/
curl -6 -sS -o /dev/null -w "IPv6: %{http_code}\n" https://example.com/

On Windows: nslookup example.com and nslookup -type=AAAA example.com. No terminal? Use Google Admin Toolbox Dig and look up the A and AAAA records.

Why it matters

If DNS is broken for some networks, some visitors and bots can’t reach the site at all.

Common causes

  • If dig +short A returns nothing → the A record is missing, or the domain expired or isn’t delegated (check the registrar).
  • If IPv4 works and curl -6 fails → the AAAA record points to an address the server doesn’t listen on. Our server has IPv6, so it can use that address.
  • If www.example.com returns nothing → the www record is missing, but links on the site use www.
  • If the records changed in the last 48 hours → old answers may still be cached (TTL).
  • If the domain uses DNSSEC and was moved to a new DNS provider → a broken DNSSEC chain makes validating resolvers fail (check with dig +dnssec example.com or an online DNSSEC checker such as DNSViz).

Fix: basic

  1. Log in where the domain’s DNS is managed (registrar, Cloudflare, or the host’s zone editor; panel paths are in Platform steps below).
  2. Check the A record for @ points to the host’s current IP address.
  3. Add a record for www: a CNAME to example.com, or an A record with the same IP.
  4. Check every AAAA record: if the host doesn’t give you an IPv6 address, delete the AAAA records. If it does, make sure they match the host’s IPv6 address.
  5. If DNSSEC was on with the old provider, turn it off at the registrar, or add the new provider’s DS record.
  6. Wait for the old TTL to pass, then click Crawl again in Site crawl.

Fix: expert

Make the web server listen on IPv6 if you keep an AAAA record.

nginx:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    # ...
}

Apache:

Listen 80
Listen [::]:80
Listen 443
Listen [::]:443

Check the server has the IPv6 address and the firewall allows it:

ip -6 addr show | grep inet6
ss -ltnp | grep -E ":443|:80"

Platform steps

Cloudflare

Cloudflare dashboard › your site › DNS › Records: check A, AAAA and CNAME records for @ and www. With the orange cloud (proxied), Cloudflare answers on IPv4 and IPv6 itself, so a missing origin IPv6 address doesn’t matter.

cPanel

Log in to cPanel › Domains › Zone Editor › Manage next to the domain. Edit or delete A and AAAA records.

Plesk

Log in to Plesk › Websites & Domains › (domain) › Hosting & DNS › DNS (Plesk docs).

Hostinger hPanel

hPanel › Domains › (domain) › DNS / Nameservers › DNS records.

Verify the fix

dig returns the correct A (and AAAA, if used) records for both names, and both curl -4 and curl -6 return 200. Then Crawl again in Site crawl.

Automation

Automatable: needs DNS provider access (for example a Cloudflare API token with DNS edit rights, or the registrar’s API).

SSL/TLS error

How we detect it

The secure connection fails before any page is sent. We check certificates the same way browsers do. Quick check without a terminal: the SSL Labs test (look for “Chain issues” and the expiry date). Terminal test:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "Verify return code|subject=|issuer="
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName
curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/

Why it matters

Visitors get a full-page security warning, and Google doesn’t index pages it can’t load securely.

Common causes

  • If notAfter is in the past or curl says certificate has expired → the certificate expired; auto-renewal failed.
  • If you see Verify return code: 20 (unable to get local issuer certificate) or 21 (unable to verify the first certificate) → the intermediate certificate isn’t sent.
  • If curl says no alternative certificate subject name matches → the certificate doesn’t cover this name (often www vs non-www).
  • If you see self-signed certificate → a placeholder certificate from the server or panel.
  • If the handshake fails with unsupported protocol → the server only offers TLS 1.0/1.1. TLS 1.2 or 1.3 is required.

Fix: basic

cPanel

  1. Log in to cPanel and go to Security › SSL/TLS Status.
  2. Tick the domain and the www. name, click Run AutoSSL.
  3. Wait for the green padlocks.

Plesk

  1. Log in to Plesk and go to Websites & Domains › (domain) › SSL/TLS Certificates.
  2. Click Install (free basic certificate from Let’s Encrypt), tick Include a “www” subdomain, click Get it free.
  3. In Hosting Settings, make sure the new certificate is selected.

Hostinger hPanel

  1. In hPanel, go to Websites › Manage › Security › SSL.
  2. Click Install SSL (or Reinstall) for the domain, including www.

Cloudflare in front

  1. Edge certificates renew automatically. In the Cloudflare dashboard › your site, check SSL/TLS › Edge Certificates for status Active.
  2. With SSL/TLS › Overview set to Full (strict) (SSL/TLS modes explained), the origin certificate must be valid too: install a free Cloudflare Origin Certificate (SSL/TLS › Origin Server › Create Certificate) on the server if needed.

Then click Crawl again in Site crawl.

Fix: expert

Let’s Encrypt with certbot:

certbot certificates
certbot renew --dry-run
certbot --nginx -d example.com -d www.example.com

nginx must use the full chain:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols       TLSv1.2 TLSv1.3;

Apache:

SSLEngine on
SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLProtocol -all +TLSv1.2 +TLSv1.3

(On Apache older than 2.4.8, also add SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem.)

Reload: nginx -t && systemctl reload nginx or apachectl configtest && systemctl reload apache2.

Platform steps

WordPress

After fixing the certificate, mixed-content and redirect issues are covered in Fix: HTTPS, SSL and redirects.

Verify the fix

openssl s_client shows Verify return code: 0 (ok) for both example.com and www.example.com, and the expiry date is in the future. Then Crawl again in Site crawl.

Automation

Automatable: needs hosting panel access (AutoSSL, Let’s Encrypt button) or server SSH (certbot).

Connection refused or reset

How we detect it

The server refuses the connection or closes it during the request. Test:

curl -v --max-time 15 https://example.com/ 2>&1 | grep -iE "connected|refused|reset|timed out|SSL"

Connection refused means nothing accepts connections on that port. Connection reset by peer means something (often a firewall) cut the connection.

Why it matters

Firewalls that drop data-centre traffic can also drop monitoring tools, link previews and some search engine crawlers.

Common causes

  • If it works for you but not for us → a firewall blocks our IP: host firewall (CSF, Imunify360, fail2ban), CDN or DDoS protection, or country blocking.
  • If it fails for everyone → the web server is stopped, or port 443 is closed.
  • If DNS points to an old server → the old server refuses connections (see DNS error above).
  • If it fails only on IPv6 → the server doesn’t listen on IPv6 but has an AAAA record (see DNS error above).

Fix: basic

  1. Check the site loads in your browser over https.
  2. Allowlist 147.93.19.85 and 2a02:4780:12:d33e::1 in each layer: CDN (Cloudflare guide, Sucuri and QUIC.cloud), host firewall, security plugin.
  3. If the site uses country blocking, add our IPs as an exception. Our server is in a data centre that may be outside the client’s country.
  4. Remove any existing ban for our IP (cPanel Security › IP Blocker; Plesk Tools & Settings › IP Address Banning (Fail2Ban); steps in Host firewall blocks our IP).
  5. Click Crawl again in Site crawl.

Fix: expert

Check the server listens on 443 and the firewall allows it:

ss -ltnp | grep -E ":443|:80"
systemctl status nginx --no-pager   # or apache2 / httpd / lsws
ufw status | grep -E "80|443"

Allow our IPs in CSF and fail2ban (both files and commands are in Fix: 403 and 429 from the server, host firewall or ModSecurity):

# /etc/csf/csf.allow and /etc/csf/csf.ignore
147.93.19.85 # SEOAuditSoftware
2a02:4780:12:d33e::1 # SEOAuditSoftware

Platform steps

Cloudflare

Country blocks are WAF custom rules with ip.src.country (Cloudflare dashboard › your site › Security › WAF › Custom rules). Add and not ip.src in {147.93.19.85 2a02:4780:12:d33e::1} to the rule, or use the skip rule in the Cloudflare guide.

Wordfence (Premium country blocking)

Wordfence › Firewall › Blocking › Country Blocking (Wordfence blocking help): our IPs in Allowlisted IP addresses that bypass all rules are let through.

Verify the fix

curl -v shows Connected to example.com and an HTTP status. Crawl again in Site crawl shows status codes instead of No response.

Automation

Assisted: needs server SSH or hosting panel, and CDN access.

If you can’t access the server

Send the host these exact lines (replace example.com). On Hostinger, open a chat from hPanel:

Our SEO audit tool can't load example.com (no response / connection error).
Please:
1. Allowlist 147.93.19.85 and 2a02:4780:12:d33e::1 in the server firewall, ModSecurity, Imunify360 and any bot protection.
2. Check that the SSL certificate for example.com and www.example.com is valid and sends the full chain.
3. Check that the AAAA (IPv6) record points to an address the server listens on, or remove it.
4. Check the error logs for requests from 147.93.19.85.

Common questions

How long does the crawler wait for a page?

10 seconds to open the connection and 25 seconds for data to arrive. If either runs out, the page shows No response and is counted in the Server errors (5xx) issue.

The site works for everyone else. Why does DNS fail for the crawler?

The most common reason is a wrong AAAA (IPv6) record. Our server has IPv6, so it can connect over the IPv6 address. Many home and office networks only use IPv4, so they never notice that the IPv6 address is dead. Fix or delete the AAAA record.

My browser shows the padlock. Why is there an SSL error?

Browsers often repair a missing intermediate certificate on their own, using a cached copy. Our server, like most servers and bots, does not. Install the full certificate chain (for Let's Encrypt on nginx, use fullchain.pem).

Could country blocking stop the crawl?

Yes. Our server runs in a data centre that may be in a different country from the client's visitors. If the site or its firewall blocks other countries, add our IPs 147.93.19.85 and 2a02:4780:12:d33e::1 as an exception.

Still need help?

Ask in the chat inside the app, or send us a message on the contact page. You can also browse all help topics.