HTTPS Migration Checklist

Moving a website from HTTP to HTTPS while checking for mixed-content and redirect issues.

An HTTPS migration is usually straightforward, but missed http:// references can trigger browser warnings and temporary ranking changes. Google treats HTTP→HTTPS as a site move, so test redirects, canonical URLs, and mixed content before launch.

This checklist covers the end-to-end HTTPS migration, from certificate acquisition through post-launch monitoring.

Phase 0: Pre-Migration Planning

Certificate Planning

Choose certificate type: single-domain, wildcard (*.example.com), or multi-domain (SAN)
Choose certificate authority: Let's Encrypt (free) or a paid CA for EV/OV certificates
If using a CDN (Cloudflare, Fastly, Akamai), understand how SSL termination works. Your CDN may manage certificates for you
Plan for certificate renewal before migration (Let's Encrypt: 90-day expiry, auto-renew with certbot or acme.sh)
Plan for all subdomains: will blog., app., cdn., api. all move to HTTPS at the same time?
Document all domains and subdomains that need certificates
Check HSTS preload eligibility: do you want to submit to the HSTS preload list?

SEO Baseline

Record current organic traffic (Search Console, 30-day average)
Record current keyword rankings
Record indexed page count in Search Console
Add and verify the HTTPS property in Google Search Console (separate property from HTTP)
Add HTTPS property in Bing Webmaster Tools
Document the current URL structure. This shouldn't change, but confirm it

Content Audit

Phase 1: Technical Preparation

Certificate and Server Config

Content and Code Updates

Third-Party Integrations

Update CDN configuration to serve assets over HTTPS
Update analytics tracking code (Google Analytics, GA4, GTM) to use HTTPS or remove protocol
Update ad scripts and pixels to HTTPS
Update embedded widgets (chat, forms, booking, reviews) to HTTPS
Update API endpoints to HTTPS (if your backend APIs are moving too)
Update webhooks and callback URLs
Update email template links to HTTPS
Update social sharing buttons and configurations
Verify brand-specific third-party integrations over HTTPS

Phase 2: Testing

Automated Testing

Run a full crawl of the HTTPS staging site and check for http:// references in source code
Use a mixed content scanner (e.g., mixed-content-scan CLI tool, or browser DevTools Security panel)
Run PageSpeed Insights / Lighthouse on HTTPS. Performance should remain the same or improve (HTTP/2 benefits)
Test SSL Labs on the production-ready HTTPS config
Test with various SSL checkers: whynopadlock.com, jitbit.com/sslcheck

Manual Testing

Edge Cases

Legacy browsers: if you support IE11 or older, test SSL compatibility (TLS 1.2 minimum may break very old browsers)
Embedded content: if your site is embedded in iframes on other domains, test that embedding still works over HTTPS
RSS readers: test your RSS feed over HTTPS (some older readers don't handle HTTPS feeds well)
Email clients: test that email template images and links work over HTTPS
CDN and caching: verify that HTTPS caching works correctly. Some CDN configs cache the redirect rather than the content
Rate limiting: the HTTP→HTTPS redirect can trigger rate limits on some servers during the transition

Phase 3: Launch

Go-Live Sequence

1. Deploy the HTTPS version (SSL + server config + updated content) to production
2. Enable HTTP→HTTPS redirect at the server level
3. Verify the redirect works: curl -I http://example.com returns 301 → https://example.com
4. Verify the redirect preserves path and query string
5. Verify HSTS header is present on HTTPS responses
6. Verify the padlock icon in all major browsers
7. Submit the HTTPS sitemap to Google Search Console
8. Use the "Change of Address" tool in Search Console, or wait for Google to pick up the redirects (HTTPS is handled specially)

Immediate Verification

Homepage: padlock, no mixed content warnings
Key landing pages: same check
Checkout/payment: especially critical
Search Console: HTTPS property is receiving data
Analytics: traffic is flowing to the HTTPS property
Redirect: http://example.com/any-page → https://example.com/any-page with 301

First 24 Hours

Monitor Search Console: new HTTPS pages being indexed? Old HTTP pages dropping?
Monitor analytics: any traffic drop? (Small dip is normal, free-fall is not)
Check server logs: any spikes in errors?
Check error tracking for JavaScript errors related to HTTPS
Review browser console reports from real users (if you have error tracking)

Phase 4: Post-Launch and Long-Term

First Week

The HTTP and HTTPS properties in Search Console should show the shift: more traffic on HTTPS, less on HTTP
Full crawl of the HTTPS site: any remaining http:// references?
Check backlinks: your existing backlinks still point to HTTP. The redirect handles this, but you can reach out to update them
Verify all third-party integrations are working over HTTPS
Monitor for any third-party scripts that may have broken (some older scripts don't support HTTPS)

First Month

Rankings should have stabilized. Compare to pre-migration baseline
HTTP indexed pages should be nearly zero (Google recognizes the redirects)
HSTS max-age can be increased to 31536000 (1 year) if all is stable
Consider HSTS preload submission: hstspreload.org
Reach out to major backlink sources to update links to HTTPS
Update any external profiles, directories, and social media to use HTTPS URLs

Long-Term

Certificate auto-renewal: verify it's working (set a calendar reminder to check in 60 days)
Monitor for certificate expiry. Automated alerts are essential
HTTP should remain accessible with a redirect. Don't turn it off; some legacy clients need it
Document the HTTPS setup for future team members

HTTPS Migration: Quick Reference

Nginx Redirect Config

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

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

    # ... rest of site config
}

Apache Redirect Config

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Common Mixed Content Scenarios

Source	Fix
`<img src="http://...">`	Change to `https://` or `//`
`background-image: url(http://...)` in CSS	Change to `https://` or `//`
`<script src="http://...">`	Change to `https://` or host locally
`fetch('http://api...')` in JS	Change to `https://`
YouTube embed with `http://`	Change to `https://` (YouTube supports it)
Google Fonts with `http://`	Change to `https://`
CDN asset with `http://`	Change to `https://` (all major CDNs support it)
Third-party service that doesn't support HTTPS	Replace the service, proxy through your server, or accept the mixed content warning (last resort)

Common Mistakes in HTTPS Migrations

Canonical tags still pointing to HTTP. This sends conflicting signals. Update them all to HTTPS.
Sitemaps still listing HTTP URLs. Google will find these and re-crawl HTTP, slowing the migration.
Not allowing HTTP at all after the switch. HTTP should redirect to HTTPS. Don't just block port 80. Some systems and bots only speak HTTP and need the redirect to recover.
HSTS with includeSubDomains when not all subdomains support HTTPS. This will break those subdomains for users who have visited the main site.
Forgetting about the old Search Console property. You need a new HTTPS property because Google treats HTTP and HTTPS as separate properties.
Self-referencing hreflang tags still in HTTP. If your site is multilingual, this will confuse Google's language targeting.
Not testing with a real certificate before launch. Self-signed certs in staging hide mixed content issues. Test with a valid certificate.
Hardcoded http:// in JavaScript redirects or API calls. These are harder to catch than HTML and CSS references.
No HSTS header. Without HSTS, users can still access the HTTP version (manually or through old links), and every first request starts as HTTP before the redirect.
Forgetting to update CSP headers. If your Content Security Policy only allows http: sources, all HTTPS resources will be blocked.

Navigation Menu

Uh oh!

HTTPS Migration Checklist

Phase 0: Pre-Migration Planning

Certificate Planning

SEO Baseline

Content Audit

Phase 1: Technical Preparation

Certificate and Server Config

Content and Code Updates

Third-Party Integrations

Phase 2: Testing

Automated Testing

Manual Testing

Edge Cases

Phase 3: Launch

Go-Live Sequence

Immediate Verification

First 24 Hours

Phase 4: Post-Launch and Long-Term

First Week

First Month

Long-Term

HTTPS Migration: Quick Reference

Nginx Redirect Config

Apache Redirect Config

Common Mixed Content Scenarios

Common Mistakes in HTTPS Migrations

Pre-Migration Checklist (One-Page Summary)

Uh oh!

FilesExpand file tree

https-migration.md

Latest commit

History

https-migration.md

File metadata and controls

HTTPS Migration Checklist

Phase 0: Pre-Migration Planning

Certificate Planning

SEO Baseline

Content Audit

Phase 1: Technical Preparation

Certificate and Server Config

Content and Code Updates

Third-Party Integrations

Phase 2: Testing

Automated Testing

Manual Testing

Edge Cases

Phase 3: Launch

Go-Live Sequence

Immediate Verification

First 24 Hours

Phase 4: Post-Launch and Long-Term

First Week

First Month

Long-Term

HTTPS Migration: Quick Reference

Nginx Redirect Config

Apache Redirect Config

Common Mixed Content Scenarios

Common Mistakes in HTTPS Migrations

Pre-Migration Checklist (One-Page Summary)