SSL Certificate Installed But Google Search Console Still Shows HTTPS Errors: The Fixes Nobody Mentions

If your certificate is installed and the padlock appears in your browser but Google Search Console still shows HTTPS errors, the certificate is almost certainly not the problem. GSC HTTPS errors after a successful SSL installation are caused by configuration issues that persist alongside the certificate: mixed content, incorrect redirects, old HTTP URLs in sitemaps, and www vs non-www consistency. Buying or reinstalling a certificate will not fix any of them.

This article maps each type of GSC HTTPS error to its actual root cause and the specific fix. The one scenario where the certificate itself needs replacing is at the end of the article, after the configuration fixes.

GSC HTTPS Error Types and What They Actually Mean

Fix 1: Mixed Content

Mixed content is the most common cause of partial HTTPS warnings after SSL installation. The certificate is valid and HTTPS is active, but one or more resources on the page (images, JavaScript files, CSS stylesheets, iframes, fonts) are loaded over HTTP rather than HTTPS. Chrome shows the padlock with a warning; GSC may flag these pages as containing security issues.

How to identify the specific resources causing mixed content:

1. Open the affected page in Chrome
2. Open Chrome DevTools (F12 or right-click, Inspect)
3. Click the Console tab
4. Look for warnings showing ‘Mixed Content: The page at https://… was loaded over HTTPS, but requested an insecure resource http://…’
5. The specific resource URL is listed in each warning

Alternatively, use WhyNoPadlock.com: enter the URL and the tool scans for and lists all mixed content resources without requiring DevTools access.

Fixes by platform:

• WordPress: install Really Simple SSL (free plugin) which handles most mixed content automatically, or SSL Insecure Content Fixer (free plugin) for more granular control. Both scan for HTTP resources in the database and update them to HTTPS. After running either plugin, run a search-replace in the database using WP-CLI or a plugin like Better Search Replace to update any remaining http:// references to https://.
• Cloudflare: enable Automatic HTTPS Rewrites in the Cloudflare dashboard under SSL/TLS > Edge Certificates. This rewrites HTTP resource URLs to HTTPS at the CDN layer without requiring changes to the origin server.
• Any CMS: use a database search-replace to change all occurrences of http://yourdomain.com to https://yourdomain.com in the content database. Be careful to preserve http:// references to external domains if those external sites only serve HTTP.

Mixed content from third-party embeds (YouTube, Vimeo, Google Maps, social media widgets) is the category most commonly missed by automated tools. These embeds use their own domain, not yours. If the embed’s URL uses http://, update it to https:// manually in the content editor. All major embed providers have supported HTTPS for several years; there is no technical reason to use HTTP embeds.

Fix 2: HTTP URLs in the Submitted Sitemap

When a site migrates from HTTP to HTTPS, the XML sitemap often still contains the old http:// URLs. GSC crawls the sitemap and follows these URLs, then reports them as HTTP pages. Even if those pages redirect to HTTPS, GSC’s coverage report records the destination URL it crawled, which may show both variants.

How to check: in GSC, go to Sitemaps, click the submitted sitemap URL, and inspect the submitted URLs. If they start with http://, the sitemap needs updating.

Fix:

• WordPress (Yoast or Rank Math): these plugins regenerate the sitemap dynamically. If WordPress Site URL is updated to https://, the sitemap will automatically use HTTPS URLs. Confirm by viewing yoursite.com/sitemap.xml in the browser and checking the URL format.
• Static or custom sitemap: edit the sitemap XML file and replace all http:// with https:// for your domain. Preserve http:// references to any external domains if included.
• After updating: in GSC go to Sitemaps, remove the old sitemap submission, and resubmit the updated sitemap URL. GSC will recrawl on its next scheduled visit.

GSC takes time to reflect sitemap resubmissions. Allow 1-4 weeks for Googlebot to recrawl the updated sitemap and update coverage reports. If the coverage report still shows old HTTP URLs after a month, check whether the sitemap was genuinely updated or whether the CMS is regenerating it with the old http:// base URL.

Fix 3: HTTP to HTTPS Redirect Not Configured or Chained

The SSL certificate handles HTTPS connections. It does not configure the HTTP-to-HTTPS redirect. A visitor who types http://example.com still gets an HTTP response unless the web server explicitly redirects them to HTTPS. If this redirect is missing, GSC sees HTTP pages as live URLs.

A redirect chain occurs when the redirect path has multiple hops: http://www.example.com redirects to http://example.com (HTTP to non-www HTTP), then to https://example.com (HTTP to HTTPS). Two redirects instead of one. GSC and crawl audit tools flag these chains. The fix is a single-step redirect from any HTTP variant to the HTTPS canonical.

Nginx single-step redirect (HTTP to HTTPS non-www canonical):

server {

listen 80;

server_name example.com www.example.com;

return 301 https://example.com$request_uri;

}

Apache single-step redirect (.htaccess):

RewriteEngine On

RewriteCond %{HTTPS} off [OR]

RewriteCond %{HTTP_HOST} ^www\.

RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

After configuring redirects, test the chain using curl: curl -I http://www.example.com should return a single 301 to https://example.com in one hop. If it shows a chain (301 to http://example.com, then 301 to https://example.com), consolidate the redirect into one rule. Redirect chains cost page crawl budget and slow page load time.

Fix 4: Canonical Tags Pointing to HTTP

Canonical tags tell GSC which URL is the authoritative version of a page. If canonical tags still reference http:// after HTTPS migration, GSC sees the HTTP URL as the canonical and may not index the HTTPS version correctly.

How to check: view source on any page (Ctrl+U in Chrome) and search for rel=’canonical’. The href value should use https://.

Fixes:

• WordPress: update WordPress Settings > General > WordPress Address and Site Address to https://. This updates the base URL used by all canonical tag generation, including Yoast, Rank Math, and other SEO plugins.
• Any platform: verify the canonical tag href in page source. If it shows http://, locate where canonical tags are generated in the theme, template, or SEO plugin configuration, and update the base URL.

Fix 5: HSTS Not Configured

HTTP Strict Transport Security (HSTS) is an HTTP response header that instructs browsers to use only HTTPS for all future visits to the domain. Without HSTS, browsers may attempt HTTP first, creating opportunities for downgrade attacks and generating HTTP traffic that GSC sees.

HSTS is not a certificate configuration; it is a server-side HTTP header. The recommended HSTS configuration for Nginx:

add_header Strict-Transport-Security ‘max-age=31536000; includeSubDomains; preload’ always;

For Apache, add this to the VirtualHost block for port 443:

Header always set Strict-Transport-Security ‘max-age=31536000; includeSubDomains; preload’

After adding HSTS with a reasonable max-age (31536000 seconds = 1 year), browsers cache the HTTPS-only instruction for that period. Subsequent visits from the same browser go directly to HTTPS without an HTTP round-trip.

Set max-age gradually for new HSTS deployments: start with max-age=300 (5 minutes), verify HTTPS is working fully, then increase to 86400 (1 day), then to 31536000 (1 year). Adding HSTS with a long max-age before verifying HTTPS works correctly can lock browsers into HTTPS-only mode when HTTPS has issues, making the site inaccessible until the max-age expires. includeSubDomains extends HSTS to all subdomains, which requires all subdomains to also serve valid HTTPS.

When the Certificate Itself Is the Problem

If the configuration fixes above do not resolve the GSC errors, or if GSC reports browser-level certificate errors (ERR_CERT_*, SEC_ERROR_*), the certificate may genuinely need replacement. The specific scenarios where a certificate replacement is the answer:

• Certificate issued for the wrong domain: if the site moved to a new domain and the certificate is still for the old domain, browsers block the new domain entirely. Fix: request reissuance for the new domain name, or buy a new certificate. OV certificates can typically be reissued for a new domain name within the same subscription term if organizational validation is still current.
• Expired certificate: a certificate past its expiry date causes browser errors that GSC’s crawlers also report. Fix: renew via ACME automation (Let’s Encrypt), or for paid certificates, initiate reissuance with the reseller. Most resellers initiate reissuance at no charge within the subscription term.
• Self-signed certificate: self-signed certificates are valid for local development environments but are not trusted by browsers or GSC. Install a CA-issued certificate. Sectigo PositiveSSL DV from an authorized reseller: $4.99/year.
• Certificate for a different subdomain: a certificate for www.example.com installed on a server that also serves shop.example.com (which is not covered by the certificate) causes GSC errors on the shop subdomain. Fix: wildcard certificate covering *.example.com, or a separate certificate for shop.example.com.

The Diagnostic Checklist: Work Through These in Order

6. Run the Qualys SSL Labs scan (ssllabs.com/ssltest) on your domain. A grade of A or A+ with no errors means the certificate is valid and the server TLS configuration is correct. If you get a certificate error here, the certificate is the problem. If you get A or A+, the certificate is not the problem.
7. Open the site in Chrome and check the address bar. If the padlock is complete with no warning, HTTPS is working from the browser perspective. If there is a ‘Not Secure’ partial warning, open DevTools > Console to see mixed content errors.
8. Run WhyNoPadlock.com against the URL to get a full list of mixed content resources without DevTools.
9. Check GSC > Sitemaps and confirm submitted URLs use https://. If not, regenerate and resubmit the sitemap.
10. Check GSC > URL Inspection on a specific affected page. The inspection tool shows what Googlebot sees: canonical URL, redirect chain, and index status.
11. View page source and check rel=canonical href value. Confirm it uses https://.
12. Confirm HTTP-to-HTTPS redirect works: run curl -I http://yourdomain.com and verify a single 301 to https://.
13. Only if SSL Labs shows a certificate error or the browser shows a hard security error: address the certificate issue (reissuance, renewal, or replacement).

The order matters: run SSL Labs first. If the certificate is valid and the grade is A or A+, you can eliminate the certificate from consideration entirely and focus on the configuration fixes. Buyers who buy a replacement certificate without running SSL Labs first often replace a working certificate and still have the original problem because the root cause was never the certificate.

Frequently Asked Questions

GSC shows my HTTPS pages as ‘Discovered but not indexed.’ Is this an SSL issue?

Discovered but not indexed means Googlebot has found the page but has not crawled it yet, typically due to crawl budget allocation or low page priority. This is not an SSL error. SSL and HTTPS status are separate from Googlebot’s indexing queue decisions. If the SSL Labs scan returns A or A+ for the domain, the certificate is not contributing to the indexing delay. Check for thin content, crawl budget limitations, or internal linking depth that might deprioritize the page.

I updated WordPress to https:// but old content still has http:// image URLs in the database. Do I need to update every post?

No, not manually. The Better Search Replace plugin or WP-CLI’s search-replace command handles this across the entire database in one operation. Using WP-CLI: wp search-replace ‘http://yourdomain.com’ ‘https://yourdomain.com’ –all-tables. This updates all occurrences across posts, pages, options, and custom tables simultaneously. Run a database backup before running search-replace to allow rollback if any content behaves unexpectedly after the update.

How long does it take GSC to reflect HTTPS fixes?

GSC crawl frequency depends on the site’s crawl budget and content update frequency. High-traffic sites with frequent content updates may see crawl updates within days. Smaller sites may take 2-8 weeks for Googlebot to revisit and recrawl all affected pages. After fixing redirect chains, mixed content, and sitemap issues, request a recrawl of the most important pages using the URL Inspection tool in GSC, which queues those specific URLs for priority recrawl. This accelerates the update for key pages without waiting for the natural crawl cycle.