HTTP to HTTPS Migration: The Complete Checklist

Moving a site from HTTP to HTTPS should be boring. It usually isn't. This checklist is the one I wish I'd had the first time — the steps, the order, and the things that break if you skip them.

Before you touch production

1. Inventory every hostname. apex, www, subdomains, CDN origins, API endpoints. Anything that needs to work over HTTPS needs a certificate.
2. Audit third parties. Analytics, ads, fonts, image CDNs, embedded widgets. Anything loaded over http:// will become mixed content.
3. Grep your source. grep -rn "http://" . — look for hardcoded HTTP URLs in templates, CSS, config, and the database.
4. Check your CDN. If you're behind Cloudflare, Fastly, or CloudFront, understand how origin-to-edge SSL works before you flip the switch. The ERR_TOO_MANY_REDIRECTS trap is almost always a Cloudflare Flexible SSL misconfiguration.

Certificate setup

You have three options, in increasing order of control:

• CDN-managed (Cloudflare, Vercel, Netlify). Free, auto-renewing, zero config. Best for most sites.
• Let's Encrypt via certbot. Free, auto-renewing, but you manage the renewal cron. Standard for self-hosted Nginx/Apache.
• Commercial cert. Needed only if you require EV, wildcard + multi-domain combos that Let's Encrypt doesn't cover, or legal compliance.

Whichever you pick: test with curl -v https://yourdomain before moving on. You should see a clean chain, no warnings.

Server-side redirects

Redirect every HTTP request to HTTPS with a 301. Send the client once, cache it forever.

Nginx

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

Apache

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Behind a proxy (Cloudflare, ALB, Heroku)

Your server sees HTTP from the proxy even when the client used HTTPS. Check X-Forwarded-Proto instead:

# Nginx
if ($http_x_forwarded_proto != "https") {
    return 301 https://$host$request_uri;
}

Fix mixed content

Mixed content is when an HTTPS page loads an HTTP resource. Browsers block scripts and iframes outright; they downgrade the padlock for images. Find and fix every instance.

1. Open the site over HTTPS, pop the browser console, look for "Mixed Content" warnings.
2. Use <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> as a temporary catch-all, but still fix the root cause.
3. Update hardcoded URLs in your database — especially CMS content like WordPress posts, which often have absolute http:// image URLs.

# Safe approach: use WP-CLI (handles serialized PHP correctly)
wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise

# Raw SQL is only safe for siteurl/home (plain strings, not serialized).
# DO NOT run REPLACE on wp_posts or wp_postmeta without a serialization-aware tool.
UPDATE wp_options SET option_value = REPLACE(option_value, 'http://example.com', 'https://example.com') WHERE option_name IN ('siteurl', 'home');

Third-party services to update

• Google Search Console. Add the HTTPS property as a new property, then submit the new sitemap.
• Google Analytics. Update the default URL in View Settings.
• Ads platforms. Google Ads, Facebook Ads, etc. Update destination URLs to avoid an extra redirect hop.
• Webhooks and callbacks. OAuth redirect URIs, payment webhooks, API callback URLs — update them all to HTTPS.
• Email marketing tools. Update the unsubscribe and tracking domains.

Canonical URLs and sitemaps

• Update <link rel="canonical"> in every template to use HTTPS.
• Regenerate sitemap.xml with HTTPS URLs.
• Update robots.txt Sitemap: directive.
• Check hreflang tags — they're a classic "oops, still pointing at HTTP" artifact.

HSTS — the one-way door

HSTS (HTTP Strict Transport Security) tells browsers to never talk to your site over HTTP again, even if the user types http://. It's a security win and a rollback hazard. Roll it out carefully:

# Phase 1: short max-age (verify nothing breaks)
Strict-Transport-Security: max-age=300

# Phase 2: one week
Strict-Transport-Security: max-age=604800

# Phase 3: one year + subdomains (only after full validation)
Strict-Transport-Security: max-age=31536000; includeSubDomains

# Phase 4: submit to browser preload list (IRREVERSIBLE)
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Do not jump straight to preload. If you ever need to downgrade a subdomain to HTTP, you'll be waiting months to get removed from the preload list.

Post-launch checklist

1. Run SSL Labs on every hostname. Aim for A or A+.
2. Crawl with Screaming Frog or a similar tool to find remaining HTTP links.
3. Check Search Console daily for the first two weeks — watch for crawl errors and index status.
4. Check your analytics referrer data. A big drop in referral traffic can mean the referring site hasn't updated links, or an intermediate redirect is stripping the referrer.
5. Verify your redirect chain is exactly one hop: http://old → https://new. Two hops is a performance tax and an SEO dilution risk. Use Redirect Check to confirm.

The short version

1. Get the certificate working on staging first.
2. Fix mixed content before flipping the switch.
3. Add the 301 HTTP→HTTPS redirect.
4. Update every third-party service that references your domain.
5. Roll HSTS out gradually — short max-age, then long, then preload.
6. Verify no redirect chains and monitor Search Console for a few weeks.