Fix: HTTPS, SSL and redirects (redirect chains, mixed content)

Every site should load on one address, for example https://www.example.com/, and every other version should reach it with one permanent redirect. This guide covers redirect, HTTPS, SSL and mixed-content problems.

The crawler follows at most 5 redirects per URL. A URL that needs more, or loops, shows No response in the Pages tab and counts under Server errors (5xx). See Fix: No response — timeouts, DNS, SSL/TLS.

Find the affected URLs in the app

1. Site crawl › open the crawl › Issues › Redirect chains lists the URLs (the first 20; Export for all).
2. Site crawl › Pages › chip 3xx shows every redirecting URL.
3. Site crawl › Links: search for a redirecting URL to see which pages link to it (Found on). Updating those links removes the redirect from the visitor’s path.
4. See the whole chain for one URL from a terminal:

curl -sIL http://example.com/old-page | grep -iE '^(HTTP|location)'

Typical chain: http://example.com/page → https://example.com/page → https://www.example.com/page → https://www.example.com/page/. That’s three hops; it should be one.

Redirect chains

How we detect it

For every crawled URL, the crawler counts how many redirects it followed before reaching the final page. Two or more hops are counted as a Redirect chain (warning). More than 5 hops or a loop gives No response.

Why it matters

• Each redirect adds a round trip (often 100 to 500 ms on mobile) before the page starts loading.
• Chains delay and dilute signals and waste crawl budget.

Common causes

• If the chain is HTTP → HTTPS → www → slash → separate rules for each step (server, plugin, Cloudflare).
• If the chain loops → Cloudflare SSL mode Flexible plus a server HTTPS redirect, or www and non-www rules pointing at each other.
• If only one old page chains → it moved twice (A → B, then B → C) and the old rule was never updated.
• If every WordPress page has an extra hop → Settings › General URLs (/wp-admin/options-general.php) don’t match the real address.
• If the last hop adds or removes / → internal links use the wrong trailing-slash form.

Fix: basic

1. Pick the one canonical address: HTTPS (always), www or not, trailing slash or not. Use what the site already uses in its links, sitemap and Search Console. Background: Google: site moves with URL changes.
2. Turn on the host’s one-step HTTPS redirect and set the preferred domain (see Platform steps).
3. WordPress: in WordPress admin (/wp-admin/options-general.php) set Settings › General › WordPress Address (URL) and Site Address (URL) to the exact canonical address.
4. Flatten old redirects: edit any rule A → B so it points straight to the final URL C.
5. Update internal links to the final URL (in Site crawl, open the crawl › Links › Found on). See Fix: broken internal links.
6. Use the same trailing-slash form everywhere. WordPress decides it from Settings › Permalinks (/%postname%/ = with slash); don’t add a rule that fights it.

Fix: expert

Apache (.htaccess, at the top, in the site root). For https://www.example.com:

RewriteEngine On
# Any request that is not HTTPS or not on www → one 301 to https://www.example.com
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://www.%1%{REQUEST_URI} [L,R=301]

For the non-www version (https://example.com):

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

Behind Cloudflare or a load balancer, %{HTTPS} may always be off. Use RewriteCond %{HTTP:X-Forwarded-Proto} !https instead of the %{HTTPS} off line.

nginx (one block catches every wrong version):

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://www.example.com$request_uri;
}
# the real site: server_name www.example.com; listen 443 ssl; ...

On nginx older than 1.25, write listen 443 ssl http2; instead of http2 on;. Test and reload:

sudo nginx -t && sudo systemctl reload nginx

WordPress: replace old internal URLs everywhere (backup first; first line is a dry run):

wp search-replace 'http://example.com' 'https://www.example.com' --all-tables --dry-run
wp search-replace 'http://example.com' 'https://www.example.com' --all-tables

Platform steps

Cloudflare

1. In the Cloudflare dashboard, pick your site. Don’t redirect in Cloudflare and on the server in different directions. Either let the server do it, or use one Rules › Redirect Rules rule (Single Redirect).
2. Turn on SSL/TLS › Edge Certificates › Always Use HTTPS.
3. Set SSL/TLS › Overview to Full (strict) (SSL/TLS modes explained). Never combine Always Use HTTPS with Flexible and a server-side HTTPS redirect.

cPanel

1. Log in to your host’s cPanel › Domains › toggle Force HTTPS Redirect for the domain.

Plesk

1. Log in to Plesk › Websites & Domains › domain › Hosting & DNS › Hosting (Plesk docs).
2. Tick Permanent SEO-safe 301 redirect from HTTP to HTTPS and choose the Preferred domain (www or non-www) › OK.

Hostinger hPanel

1. In hPanel › Websites › Manage › Security › SSL › Force HTTPS on.

WordPress

1. Settings › General: both URLs set to the canonical address › Save Changes.
2. Flatten old rules: Rank Math SEO › Redirections or Tools › Redirection (the Redirection plugin) › edit the destination to the final URL.

Shopify

1. In Shopify admin › Settings › Domains › set the Primary domain. Shopify redirects all others to it in one hop and forces HTTPS.
2. Old chained redirects: Online Store › Navigation › URL Redirects › edit “Redirect to”.

Webflow

1. Site settings › Publishing › Production › set the default domain (SSL is on by default); Webflow redirects the other domain.

Wix / Squarespace

1. Set the primary domain in Settings › Domains (in the Wix dashboard or your Squarespace account); HTTPS is automatic.

Verify the fix

1. curl -sIL http://example.com/some-page | grep -iE '^(HTTP|location)' shows one 301 and then 200.
2. Test all four versions (http://, http://www., https://, https://www.): each reaches the same final URL in one hop.
3. Site crawl › Crawl again, then Compare: Redirect chains should be under Fixed issues, and the 3xx chip in Pages shows far fewer URLs.

Automation

Assisted: chains are detected and the flattened target can be computed automatically; applying needs WordPress admin via plugin (redirect rules, site URLs), the Cloudflare API token (Redirect Rules, SSL mode), the Shopify Admin API (URL redirects) or server SSH.

Avoid multiple page redirects

How we detect it

In ”+” audits, Lighthouse reports Avoid multiple page redirects when the audited URL needs several redirects, with the time each hop costs.

Why it matters

Each hop delays the first byte of the page, which hurts First Contentful Paint and LCP.

Common causes

• Same as Redirect chains above, usually HTTP → HTTPS → www.

Fix: basic

1. Follow Fix: basic under Redirect chains.
2. Audit the final URL from the address bar.

Fix: expert

Use the one-step Apache or nginx rules under Redirect chains.

Platform steps

All platforms

1. Use the platform steps under Redirect chains.

Verify the fix

1. In Audits, open the ”+” audit and click Run again. The Lighthouse item should pass.

Automation

Assisted: same access as Redirect chains.

URL redirect

How we detect it

The classic audit checks whether the audited URL redirected before the page loaded (the url_redirect statistic). It shows URL redirect under Technical & security.

Why it matters

Each redirect adds a delay. If the URL you share, advertise or list on Google Business Profile redirects, every visitor pays that delay.

Common causes

• If you entered http:// or the non-preferred www version → the site redirected to its canonical address.
• If the page moved → the old URL redirects to the new one.

Fix: basic

1. Open the URL in a browser and copy the final address from the address bar.
2. Run the audit on the final URL in Audits.
3. Update links, ads, social profiles and Google Business Profile to use the final URL.

Fix: expert

No server change needed if the redirect is a single correct 301. If it is a chain, see Redirect chains.

Platform steps

All platforms

1. Update the link wherever it is used (menus, ads, Business Profile website field).

Verify the fix

1. In Audits, click Run again on the final URL. URL redirect should pass.

Automation

Manual: the fix is using the final URL in links and ads; internal links can be updated via WordPress admin or CMS APIs.

Meta refresh

How we detect it

The classic audit looks for <meta http-equiv="refresh"> in the page (the meta_refresh statistic) and shows Meta refresh under Technical & security.

Why it matters

Meta refresh redirects are slow, confusing for visitors and treated by Google as weaker than server redirects.

Common causes

• If WordPress → an “under construction”, maintenance or old redirect plugin added it.
• If a hand-coded page → a leftover redirect page from an old site.
• If the refresh reloads the same page every few seconds → a news or ticker widget.

Fix: basic

1. Press Ctrl+U and search http-equiv="refresh".
2. WordPress: deactivate the maintenance or redirect plugin that adds it (Plugins › Installed Plugins).
3. Add a normal 301 redirect instead (Rank Math › Redirections, Redirection plugin, Shopify URL Redirects).

Fix: expert

Delete the tag from hand-coded pages:

<meta http-equiv="refresh" content="0; url=https://example.com/new-page/">

Replace it with a server-side 301:

Redirect 301 /old-page.html https://example.com/new-page/

location = /old-page.html { return 301 https://example.com/new-page/; }

Platform steps

WordPress

1. Deactivate maintenance/coming-soon plugins once the site is live, then add a 301 in Rank Math SEO › Redirections or Tools › Redirection.

Shopify

1. Remove the tag from layout/theme.liquid (Shopify admin › Online Store › Themes › … › Edit code) and add a redirect under URL Redirects.

Verify the fix

1. Ctrl+U shows no http-equiv="refresh".
2. In Audits, click Run again on the audit. Meta refresh should pass.

Automation

Assisted: detection is automatic; removal needs WordPress admin (plugins), Shopify Admin API (theme files) or server SSH.

SSL certificate errors

How we detect it

When the certificate is invalid, the crawler can’t open the site: pages show No response in the Pages tab and count under Server errors (5xx). Audits fail to load the page. In ”+” audits, Lighthouse reports Does not use HTTPS when the page or files are on HTTP.

Why it matters

HTTPS is a confirmed Google ranking signal. An invalid certificate shows “Your connection is not private” and stops visitors and crawlers completely.

Common causes

• If the browser says NET::ERR_CERT_DATE_INVALID → the certificate expired (auto-renewal failed).
• If it says ERR_CERT_COMMON_NAME_INVALID → the certificate doesn’t cover this name (often www missing).
• If it works in Chrome but fails in curl and crawlers → the intermediate chain is missing.
• If you see “too many redirects” → Cloudflare Flexible mode plus a server HTTPS redirect.

Fix: basic

1. Open the site, click the padlock / site settings icon › Connection is secure › Certificate is valid to see the expiry date and names.
2. Expired: renew it in the hosting panel (see Platform steps below). You can also check it with the SSL Labs test.
3. Wrong name: reissue it for both example.com and www.example.com.
4. Cloudflare: in the Cloudflare dashboard › your site › SSL/TLS › Overview, set Full (strict).

Fix: expert

Check the certificate from a terminal. notAfter is the expiry date; subjectAltName must include both names:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

Renew or reissue with certbot (free certificates from Let’s Encrypt):

sudo certbot renew
sudo certbot --nginx -d example.com -d www.example.com
sudo systemctl reload nginx
systemctl list-timers | grep certbot

Incomplete chain: point the server at the full chain file:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Platform steps

cPanel

1. In cPanel › Security › SSL/TLS Status › select the domains (with www) › Run AutoSSL.

Plesk

1. In Plesk › Websites & Domains › SSL/TLS Certificates › Install (Let’s Encrypt) or Renew, tick Include www.
2. Turn on Keep websites secured for auto-renewal.

Hostinger hPanel

1. In hPanel › Websites › Manage › Security › SSL › Install SSL / reinstall the free certificate.

Cloudflare

1. In the Cloudflare dashboard › your site › SSL/TLS › Overview › Full (strict).
2. Full (strict) needs a valid certificate on the server: a free Let’s Encrypt certificate or a Cloudflare Origin Certificate (SSL/TLS › Origin Server › Create Certificate, then install it on the server).

Verify the fix

1. The openssl command shows a future notAfter and both names.
2. curl -I https://example.com/ returns a status without a certificate error, and the SSL Labs test shows no chain issues.
3. Site crawl › Crawl again: pages should show 2xx instead of No response.

Automation

Assisted: expiry and name problems are detected automatically; renewal needs the hosting panel, server SSH (certbot) or a Cloudflare API token (SSL mode).

Uses HTTPS (mixed content)

How we detect it

In ”+” audits, Lighthouse lists every file loaded over plain HTTP under Uses HTTPS / Does not use HTTPS. Browsers show the same as “Mixed Content” warnings.

Why it matters

Browsers block HTTP files on HTTPS pages, which can break images, styles or forms, and Chrome may drop the padlock.

Common causes

• If images and links use http:// → the site moved to HTTPS but the database still holds old URLs.
• If logo or backgrounds break → full URLs stored in the Customizer or page-builder settings.
• If a script or embed breaks → a third-party file only available on HTTP.

Fix: basic

1. Open the page, press F12 › Console and note each “Mixed Content … requested an insecure resource ‘http://…’”.
2. WordPress: run a search-replace from http://example.com to https://example.com (see WordPress under Platform steps below).
3. Check Appearance › Customize (logo, background images), widgets and page-builder global settings.
4. Replace third-party HTTP embeds with their HTTPS version, or remove them.
5. Once everything is on HTTPS, add HSTS (see Fix: expert).

Fix: expert

Upgrade any remaining HTTP requests with a header:

Header always set Content-Security-Policy "upgrade-insecure-requests"

add_header Content-Security-Policy "upgrade-insecure-requests" always;

HSTS tells browsers to always use HTTPS. Start with max-age=300 for a day, check every subdomain works on HTTPS, then raise it to a year:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Platform steps

WordPress

1. Run the WP-CLI search-replace under Redirect chains, or install Better Search Replace (Tools › Better Search Replace, dry run first).
2. Elementor: Elementor › Tools › Replace URL › old http:// URL, new https:// URL › Replace URL, then Regenerate CSS & Data.
3. Hard-coded theme files: change http:// to https:// or a relative path (/wp-content/...).
4. Optional safety net: Really Simple Security fixes mixed content on the fly, but fixing the database is cleaner.

Cloudflare

1. In the Cloudflare dashboard › your site › SSL/TLS › Edge Certificates › Automatic HTTPS Rewrites on.
2. HSTS: SSL/TLS › Edge Certificates › HTTP Strict Transport Security (HSTS) › Enable HSTS.

Shopify / Wix / Squarespace / Webflow

1. HTTPS is automatic; mixed content comes from embeds or custom code with http://. Edit the embed or custom code and change it to https://.

Verify the fix

1. Browser console shows no Mixed Content warnings.
2. In Audits, click Run again on the ”+” audit; Uses HTTPS should pass.

Automation

Automatable: database URL replacement can run via WordPress admin via plugin or WP-CLI over server SSH; Cloudflare rewrites and HSTS via a Cloudflare API token.

Common questions

Related articles

• Fix: Broken internal links (4xx) and broken resources
• Fix: No response — timeouts, DNS, SSL/TLS and connection errors
• Fix: Cloudflare blocks the crawl or audit (403, 'Just a moment', 429)
• Fix: indexing — noindex, canonical tag, robots.txt and sitemap
• Crawl a whole website

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.