You moved to HTTPS for security and SEO. Instead, your indexed pages tanked. This is a known post-migration failure mode. We walk through the exact audit checklist — redirect chains, mixed content, sitemap re-submission — to get Googlebot back on track.
Quick calculator. Put in the expected monthly value of a page or link batch and the natural waiting time.
You flipped the switch to HTTPS. Googlebot showed up. Then the index cratered. This is not a penalty. It is a signal failure. Google sees a new URL structure, new certificates, and possibly broken signals. The most common cause: your HTTPS pages do not have the same internal link equity or the old HTTP URLs are still sending 301s through a chain that wastes crawl budget.
A common situation we see: a site with 10,000 pages migrates. The team sets up a single 301 from HTTP to HTTPS. Sounds fine. But the old site had relative URLs in the sitemap, and the new sitemap still points to HTTP. Or worse, the canonical tags are not updated. Google then sees the HTTPS page as a duplicate of the HTTP page and suppresses it. The fix is not a single line of code. It is a systematic audit.
In practice, when you audit your site structure with a tool like Ahrefs, you can spot the redirect depth and broken internal links immediately. Do not guess. Measure.
| Failure Mode | Typical Root Cause | Detection Method | Operational Fix | Hidden Risk |
|---|---|---|---|---|
| Redirect chain (3+ hops) | HTTP -> www HTTP -> non-www HTTPS -> final HTTPS | Screaming Frog crawl or Ahrefs redirect report | Flatten to single 301: HTTP -> final HTTPS | Chain consumes crawl budget; Google may stop after 5 hops |
| Mixed content (CSS, JS, images on HTTP) | Hardcoded HTTP URLs in templates or DB fields | Chrome DevTools console or site-wide crawl with filter 'src=http://' | Update to protocol-relative URLs or explicit HTTPS | Browsers block insecure content; Google devalues the page |
| Old HTTP sitemap still submitted | Google Search Console still has old sitemap in queue | Check GSC Sitemaps report for 'Couldn't fetch' errors | Remove old HTTP sitemap, add new HTTPS sitemap, request index | Google may keep crawling old URLs, wasting budget |
| Canonical tag pointing to HTTP | Developer forgot to update rel=canonical on HTTPS pages | View page source or use SEO extension to check canonical | Update all canonicals to self-referencing HTTPS | Google treats HTTPS page as duplicate and suppresses it |
| Noindex meta tag present | Staging environment or CMS default on new HTTPS site | Crawl with filter 'meta robots noindex' or use GSC URL inspection | Remove noindex tag, allow indexing in robots.txt | Pages stay out of index indefinitely until tag is removed |
Phase one: audit. Phase two: fix. Phase three: re-submit. Most teams skip the audit and go straight to resubmitting the sitemap. That is like putting a bandage on a broken bone. You need to know which errors are blocking Googlebot.
Edge case: one client had a single page that loaded via HTTPS but the entire CSS file was on an HTTP CDN that had a 302 redirect. Googlebot could not render the page, so it dropped it from the index. The fix was updating the CDN URL. That single change recovered 3,000 pages in 10 days.
Another operational failure: a team used a plugin to redirect HTTP to HTTPS but the plugin also added a trailing slash redirect. That created a 4-hop chain. Google indexed 12% of the site. After flattening the redirect, indexing jumped to 89% within two weeks.
Run a full site crawl on HTTP and HTTPS. Compare URL counts, response codes, and redirect depth. Use a tool that shows hop count.
Filter for URLs with 3+ hops. Flatten each chain to a single 301 redirect from old HTTP URL to final HTTPS URL.
Search for 'src=http://' and 'href=http://' in your HTML. Blocked resources cause Google to render a blank page.
Ensure sitemap URLs use HTTPS and are not blocked by robots.txt. Submit the new sitemap in Google Search Console.
Use GSC URL Inspection to check if Google can see the HTTPS version. Wait 7-14 days before re-auditing.
Initial state: A B2B SaaS site with 1,500 indexed pages on HTTP. After migration to HTTPS, Google showed only 210 indexed URLs.
Diagnosis: Crawl revealed 1,200 URLs with a 3-hop redirect chain (HTTP -> HTTP www -> HTTPS non-www -> HTTPS www). 300 pages had mixed content from an old image CDN. 15% of the sitemap URLs still pointed to HTTP.
Fix steps:
1. Rewrote .htaccess to flatten all redirects to a single 301 from HTTP to HTTPS www (removed 2 hops).
2. Updated all image URLs in the database to use HTTPS via a search-replace script.
3. Regenerated the sitemap using an HTTPS base URL and submitted it in GSC.
4. Requested indexing for the top 200 pages via GSC URL Inspection.
Result: After 10 days, Google indexed 1,100 URLs. After 14 days, 1,480 URLs were indexed. The flattening of the redirect chain alone recovered 900 URLs.
Verify all 301 redirects are single-hop (no chains longer than 2).
Run a mixed content scan: filter for any resource loaded over HTTP.
Confirm canonical tags point to the HTTPS version (self-referencing).
Check robots.txt: no disallow for / or for /sitemap.xml.
Submit the new HTTPS sitemap in Google Search Console; remove the old HTTP sitemap.
Use GSC URL Inspection tool on 10-20 high-value pages to detect coverage errors.
Monitor the Index Coverage report for 'Duplicate without user-selected canonical' errors.
Review server response times on HTTPS; slow TLS handshake can reduce crawl rate.
Expect 7 to 21 days for Google to recrawl and reindex HTTPS pages, provided there are no redirect chain errors or mixed content. If you have fewer than 500 pages, it can happen in 3-5 days. For large sites over 10,000 pages, budget the full 3 weeks. Use GSC URL Inspection to check individual page status earlier.
The most common reason is a redirect chain of 3 or more hops. Google stops following after 5 hops, but even 3 hops wastes crawl budget and can cause pages to be treated as duplicates. Second cause: canonical tags still point to the HTTP version, so Google suppresses the HTTPS page. Run a crawl and check both redirect depth and canonical tags.
Use Chrome DevTools: open the site, go to Console tab, look for 'Mixed Content' warnings. For a full audit, crawl the site with Screaming Frog and filter for URLs containing 'src=http://' or 'href=http://'. Pay special attention to CSS and JavaScript files — one insecure stylesheet can block rendering for all pages.
Use a single 301 redirect from the old HTTP URL to the exact HTTPS URL, preserving the path. Avoid chaining: do not redirect HTTP to HTTP www, then to HTTPS non-www, then to HTTPS www. In Apache: 'Redirect 301 / https://yoursite.com/'. In Nginx: 'return 301 https://yoursite.com$request_uri'. Test with curl -I to verify only one hop.
No. After migration, remove the old HTTP sitemap from GSC and submit only the HTTPS sitemap. Submitting both tells Google there are two versions of the same content, which can cause duplicate content issues. If you already submitted both, use GSC to delete the HTTP property or remove the HTTP sitemap URL.
Some CMS platforms or security plugins add a noindex meta tag to the HTTPS version as a safety default, especially if the SSL certificate was installed via a plugin. Check the <head> section of your HTTPS pages for <meta name='robots' content='noindex'>. If present, remove it from your theme or plugin settings.
Use Ahrefs Site Audit: set up a project with your HTTPS domain. Run a crawl and check the 'Redirects' report for chains longer than 2 hops. Then check 'Internal Pages' for any URLs with HTTP in the source code. The 'Indexability' report will flag pages with noindex or canonical issues. Ahrefs' data shows the exact number of pages affected.
A slow TLS handshake (over 500ms) reduces Googlebot's crawl rate because Google allocates a fixed crawl budget per site. If your server takes 2 seconds to establish the TLS connection, Google will crawl fewer pages per day. Use tools like SSL Labs or WebPageTest to measure handshake time. Optimize by using TLS 1.3 and a fast CDN.
Yes, relative URLs (like /images/logo.png) are safer than absolute HTTP URLs because they automatically inherit the protocol of the page. If you hardcoded HTTP URLs in your content, they create mixed content warnings. After migration, replace all absolute HTTP URLs with either relative paths or protocol-relative URLs (//example.com/image.png).
GSC does not support bulk URL submission beyond 200 URLs per request. For a large site, focus on fixing the technical issues first, then use the sitemap submission to trigger re-crawling. If you need to accelerate indexing for specific pages, use the URL Inspection tool for up to 50 URLs per day. For deeper management, consider <a href='https://medium.com/@alexa.sam2026/drip-feed-indexing-managing-link-velocity-to-prevent-algorithmic-penalties-7c22a9a364d7'>drip-feed indexing strategies that manage link velocity</a> to avoid algorithmic penalties.