The hard work of obtaining and installing an SSL certificate is done. Your site now loads over HTTPS, showing that reassuring padlock in browsers. For many site owners, this feels like the finish line. In reality, it's just the beginning of a critical cleanup phase that determines whether your HTTPS migration delivers its full benefits.
After the initial cutover, most sites suffer from mixed content warnings, multi-hop redirect chains, and configuration inconsistencies that undermine security and performance. Users encounter errors. Search engines see duplicate content. Page load times suffer from unnecessary redirects. Security features remain partially enabled because the migration isn't truly complete.
Let's explore how to systematically clean up these issues, optimize your HTTPS implementation, and lock in security with HSTS preloading. This post-migration work transforms a basic HTTPS deployment into a properly secured, performant website.
Understanding Mixed Content
Mixed content occurs when HTTPS pages load resources over HTTP. Browsers see this as a security problem, the page itself is encrypted, but some resources aren't, creating vulnerabilities.
Active mixed content includes scripts, stylesheets, iframes, and other resources that can execute code or modify page behavior. Browsers typically block active mixed content entirely, breaking functionality.
Passive mixed content includes images, audio, and video that don't execute code. Modern browsers often load passive mixed content with warnings, but they're moving toward blocking it entirely.
Both types undermine the security that HTTPS provides. A page with mixed content isn't truly secure, even if most resources load over HTTPS.
Identifying Mixed Content at Scale
For small sites with a few pages, manually inspecting browser console warnings might suffice. At scale, you need systematic approaches.
Open your site in Chrome or Firefox with developer tools active. The console displays mixed content warnings showing exactly which resources load insecurely:
Mixed Content: The page at 'https://example.com/page' was loaded over HTTPS,
but requested an insecure image 'http://example.com/image.jpg'
This works page-by-page but doesn't scale to sites with hundreds or thousands of pages.
Tools like Screaming Frog, Sitebulb, or custom crawlers can scan entire sites detecting mixed content. Configure the crawler to:
- Follow all internal links
- Report HTTP resources on HTTPS pages
- Export results for systematic fixing
Content Security Policy reporting:
Implement CSP in report-only mode with the upgrade-insecure-requests directive:
Content-Security-Policy-Report-Only: upgrade-insecure-requests; report-uri /csp-report
This doesn't fix mixed content yet, but browsers report violations to your endpoint. Collect these reports for a week or two to identify all mixed content instances across actual user traffic.
Search server logs for patterns indicating mixed content. Look for HTTP requests to your domain from pages that should be HTTPS-only. This requires log parsing but provides comprehensive real-world data.
Fixing Mixed Content Systematically
Once identified, mixed content requires systematic remediation. The approach depends on your site's architecture.
Protocol-relative URLs (legacy approach):
Older sites sometimes used protocol-relative URLs:
<img src="//example.com/image.jpg">
These adopt the protocol of the parent page—HTTP pages load them via HTTP, HTTPS pages via HTTPS. While this solves mixed content, it's no longer recommended. Modern sites should use HTTPS explicitly everywhere.
The proper fix is updating all resource references to HTTPS:
<img src="https://example.com/image.jpg">
For sites with resources in templates, databases, or static files, this requires:
Template updates: Modify templates to reference HTTPS URLs. This handles header, footer, and structural elements consistently.
Database content: For content stored in databases (CMS posts, product descriptions), run SQL updates to replace HTTP URLs:
SET content = REPLACE(content, 'http://example.com/', 'https://example.com/')
WHERE content LIKE '%http://example.com/%';
Be careful with blanket replacements—test queries on development environments first and back up databases before running updates.
Configuration files: Check configuration for hardcoded HTTP URLs in settings, constants, or environment variables.
Third-party resources: For external resources (CDNs, widgets, embedded content), verify they support HTTPS. Most do, but some legacy services might not. Find HTTPS-supporting alternatives if necessary.
Content Security Policy with upgrade-insecure-requests:
After fixing known mixed content, deploy CSP with upgrade-insecure-requests:
Content-Security-Policy: upgrade-insecure-requests;
This directive tells browsers to automatically upgrade HTTP requests to HTTPS for resources on your page. It acts as a safety net, catching any missed instances and protecting against mixed content introduced by future updates.
This directive only affects resources from your domain or subdomains, not external resources. External HTTP resources still need manual fixing or HTTPS alternatives.
Understanding Redirect Chains
After HTTPS migration, many sites develop redirect chains—multiple sequential redirects before reaching the final URL. Common patterns:
→ https://www.example.com
→ https://www.example.com/
Each redirect adds latency (typically 100-300ms per hop) and consumes crawl budget. Search engines may not follow long chains completely, potentially affecting indexing.
Redirect chains accumulate when different systems handle different redirects:
- Your web server redirects HTTP to HTTPS
- Your application redirects non-www to www
- Your application adds trailing slashes
- Your application handles old URLs
Each redirect happens in sequence rather than being consolidated.
Redirect Status Codes: 301 vs 308
Understanding redirect status codes helps optimize redirect configuration.
Traditional permanent redirect. Search engines transfer ranking signals from old URLs to new URLs. However, 301 allows the HTTP method to change—POST requests may become GET requests after redirect.
308 (Permanent Redirect):
Newer permanent redirect that preserves the HTTP method. If a POST request hits a 308, the redirected request remains POST.
For typical HTTPS migrations and URL structure changes involving GET requests (most web traffic), 301 and 308 behave similarly. Use 308 for consistency and semantic correctness, but 301 remains widely used and effective.
302 (Found) and 307 (Temporary Redirect):
These temporary redirects tell search engines not to transfer ranking signals. Don't use them for permanent URL structure changes. However, they're appropriate for temporary redirects where you intend to revert.
For HTTPS migration and URL consolidation, use permanent redirects (301 or 308).
Consolidating Redirect Chains
The goal is reducing multi-hop redirects to single hops. Instead of:
http://example.com → https://example.com → https://www.example.com
http://example.com → https://www.example.com (direct)
Implementation approaches:
Server-level configuration:
server_name example.com www.example.com;
return 301 https://www.example.com$request_uri;
return 301 https://www.example.com$request_uri;
server_name www.example.com;
# Your actual site configuration
This configuration handles all variations (http/https, www/non-www) with single redirects to the canonical HTTPS www version.
ServerAlias www.example.com
Redirect permanent / https://www.example.com/
# SSL certificate configuration
Redirect permanent / https://www.example.com/
ServerName www.example.com
# SSL certificate configuration
# Your actual site configuration
Application-level redirects:
If your web server handles protocol and hostname consolidation, configure your application to avoid adding its own redirects. Many frameworks automatically redirect to trailing slashes or perform canonicalization—disable these when server config already handles it.
Testing redirect consolidation:
Use curl to trace redirect chains:
curl -I -L http://example.com
The output shows each redirect hop. Verify that all starting URLs (http/https, www/non-www variations) redirect directly to your canonical URL in one hop.
Canonical URLs and Consolidation
Beyond redirects, canonical URLs help search engines understand your preferred URL structure.
On every page, include a canonical link element:
<link rel="canonical" href="https://www.example.com/page">
This tells search engines which version of potentially duplicate URLs you prefer. Even with perfect redirects, canonical tags provide additional signals.
Canonical URL best practices:
Use absolute URLs: Include the full URL with protocol and domain, not relative paths.
Match your redirect target: Canonical URLs should point to the same destination as your redirects—typically your HTTPS www (or non-www) version.
Apply consistently: Every page needs a canonical tag, even if it's self-referential (pointing to itself).
Update after HTTPS migration: Many sites forget to update canonical tags after HTTPS migration, leaving them pointing to HTTP URLs. This confuses search engines and undermines migration efforts.
Crawl your site extracting canonical tags. Verify they all:
- Use your preferred domain format (www vs non-www)
- Point to valid, accessible URLs
- Don't create chains (canonical pointing to URL that redirects)
Sitemap Updates
XML sitemaps guide search engines to your content. After HTTPS migration, sitemaps need updating.
Every URL in your sitemap should use HTTPS:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<loc>https://www.example.com/page</loc>
<lastmod>2025-01-15</lastmod>
When performing HTTPS migration cleanup, update the lastmod dates for affected pages. This signals to search engines that content has changed and should be recrawled.
Resubmit to search engines:
- Submit the updated sitemap through Google Search Console
- Submit through Bing Webmaster Tools
- Reference the sitemap in robots.txt for other crawlers
Monitor sitemap processing:
Search Console shows how many URLs from your sitemap are indexed and highlights any issues. Monitor this after migration to ensure search engines successfully crawl your HTTPS URLs.
Internal Link Updates
Internal links within your content should point directly to canonical HTTPS URLs, avoiding redirects entirely.
- Reduces redirect-related latency for users
- Improves crawl efficiency for search engines
- Provides cleaner user experience
- Eliminates dependency on redirect configuration remaining correct
Finding and fixing internal links:
Template updates: Start with templates, headers, and navigation. These appear on many pages, so fixing them once affects the entire site.
Content updates: For links within content (blog posts, pages), use database queries similar to mixed content fixes:
SET content = REPLACE(content, 'href="http://example.com', 'href="https://www.example.com')
WHERE content LIKE '%href="http://example.com%';
Adapt this pattern for your specific database schema and URL structure.
Automated link checking: Tools can crawl your site identifying internal links that still point to HTTP or non-canonical domain formats. Schedule regular checks to catch new content with problematic links.
HSTS: HTTP Strict Transport Security
Once HTTPS is clean and stable, HSTS provides an additional security layer by telling browsers to always use HTTPS for your site.
When browsers receive the HSTS header, they remember (for a specified duration) that your site requires HTTPS. Future attempts to visit HTTP URLs automatically upgrade to HTTPS in the browser before any request is sent.
Strict-Transport-Security: max-age=31536000
This tells browsers to enforce HTTPS for one year (31,536,000 seconds).
Strict-Transport-Security: max-age=31536000; includeSubDomains
The includeSubDomains directive extends HSTS to all subdomains. Only add this if all subdomains support HTTPS properly.
Start with a short max-age to test:
Strict-Transport-Security: max-age=300
This five-minute duration lets you test HSTS behavior without long-term commitment. If issues arise, they resolve quickly.
Only proceed to longer durations once confident everything works correctly.
HSTS Preload List
The HSTS preload list is a directory of sites that browsers should always access via HTTPS, even on first visit. Being on this list provides maximum security but requires careful preparation.
To qualify for the preload list:
- Redirect all HTTP traffic to HTTPS (preferably same-host)
- Serve all subdomains over HTTPS
- Serve HSTS header on base domain with:
- max-age of at least 31536000 (1 year)
- includeSubDomains directive
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Submitting to preload list:
Visit hstspreload.org to check eligibility and submit your domain. The site performs automated checks verifying your configuration meets requirements.
After submission, browsers gradually incorporate updates to their preload lists. This takes months as browser updates roll out.
Permanence: Removal from the preload list is possible but slow. Only submit if certain all subdomains will remain HTTPS indefinitely.
Subdomain implications: includeSubDomains means every subdomain must support HTTPS. Test thoroughly before committing.
Benefits: Preload provides protection against certain attacks targeting first visits, enhances privacy, and demonstrates security commitment.
For hosting environments where you control all subdomains and commit to HTTPS long-term, preload is worthwhile. For complex environments with many subdomains or uncertain futures, proceed cautiously. Performance Audits Post-Migration
HTTPS should improve or maintain performance, not degrade it. However, poor post-migration cleanup can introduce performance problems.
Measure before and after:
Use tools like Lighthouse, WebPageTest, or GTmetrix to establish performance baselines before major cleanup work, then verify improvements afterward.
Time to First Byte (TTFB): Ensure HTTPS doesn't significantly increase TTFB. Slight increases are normal due to TLS handshake, but major degradation indicates configuration problems.
Redirect time: Measure how much time redirects consume. Multiple-hop chains can add significant latency.
Page load time: Overall load time should be similar to or better than pre-HTTPS. Modern HTTP/2 over HTTPS often performs better than HTTP/1.1.
Resource loading: Verify all resources load correctly without errors or warnings.
Common performance problems:
Slow redirect chains: As discussed, consolidate redirects to single hops.
Certificate validation delays: Ensure your certificate chain is complete and properly configured. Missing intermediate certificates can slow handshake.
Mixed content blocking: When browsers block active mixed content, functionality breaks. When they load passive mixed content with warnings, it may use inefficient protocols.
HTTP/2 not enabled: HTTPS enables HTTP/2, which improves performance. Verify your server actually serves HTTP/2 to HTTPS connections.
Monitoring and Maintenance
Post-migration cleanup isn't one-time—it requires ongoing attention.
Security headers: Monitor that HSTS and other security headers remain configured correctly. Configuration changes or server updates can accidentally remove them.
Certificate expiration: Track certificate expiration dates. Modern solutions with automated renewal reduce risk, but monitoring provides assurance.
Mixed content: Periodic crawls catch new mixed content introduced by content updates or third-party service changes.
Redirect chains: New redirects can creep in through application updates or configuration changes. Regular checks maintain single-hop efficiency.
Tools like uptime monitors can check:
Configure alerts for issues requiring immediate attention.
Content management policies:
Establish policies ensuring new content uses HTTPS URLs:
- Content guidelines for editors
- Automated checks in publishing workflows
- Regular training for content teams
Prevention is easier than remediation.
Search Console and Analytics Monitoring
After HTTPS migration and cleanup, monitor search engine and analytics impacts.
Property setup: Ensure you have both HTTP and HTTPS properties added, though focus on HTTPS going forward.
Coverage report: Monitor for crawl errors, indexing issues, or warnings about mixed content or security problems.
Performance data: Watch for traffic changes. Properly executed HTTPS migration shouldn't cause traffic drops, though temporary fluctuations can occur during search engine reprocessing.
Security issues: Search Console alerts to detected security problems, including malware or hacked content.
Update analytics configurations to reflect HTTPS:
- Change property URLs to HTTPS
- Update conversion tracking URLs
- Verify goal URLs use HTTPS
- Update campaign tracking URLs
Check for duplicate content tracking where both HTTP and HTTPS versions receive traffic—this suggests incomplete redirect configuration.
Handling Third-Party Services
Many third-party services integrated into your site need updates after HTTPS migration.
Common services requiring updates:
CDN configuration: Update CDN origins to pull from HTTPS. Configure CDN to serve HTTPS to visitors.
Payment processors: Update webhook URLs, return URLs, and other integration endpoints to HTTPS.
Social media integrations: Update Open Graph URLs, Twitter Card URLs, and other social metadata to HTTPS.
Email marketing: Update links in email templates to HTTPS.
Advertising networks: Update ad tags and tracking pixels to use HTTPS versions where available.
Form processors: Update form action URLs and API endpoints to HTTPS.
Neglecting third-party service updates causes broken functionality, tracking gaps, or security warnings even after your core site is clean.
Documentation and Runbooks
Document your HTTPS configuration and cleanup processes for future reference.
Redirect configuration: Note where redirects are configured (web server, application, CDN) and the logic behind routing decisions.
Certificate details: Track certificate issuer, renewal process, and responsible parties.
Security headers: Document which headers are set, where they're configured, and any variations across different parts of your site.
Known issues: Track any permanent exceptions or technical debt that couldn't be fully resolved.
Monitoring setup: Document what's monitored, alert thresholds, and escalation procedures.
This documentation helps future troubleshooting, onboards new team members, and ensures knowledge persists beyond individual contributors.
Conclusion
HTTPS migration isn't complete when the certificate is installed, it's complete when mixed content is eliminated, redirects are optimized, security headers are properly configured, and monitoring ensures ongoing compliance.
This cleanup phase determines whether HTTPS migration delivers full security and performance benefits or creates ongoing technical debt. Sites that neglect post-migration cleanup suffer from security warnings, poor performance, and confused search engine signals.
Systematic approaches to identifying and fixing mixed content, consolidating redirect chains, implementing HSTS, and monitoring configuration ensure your HTTPS deployment achieves its full potential. The investment in thorough cleanup pays dividends in security, performance, and maintainability.
Take the time to do HTTPS migration right. Your users, search rankings, and future self will appreciate the effort spent ensuring your site is truly secure and optimally configured.
.png&w=2048&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)