HTTP to HTTPS Redirect Checklist for Websites, Subdomains, and Legacy URLs

Overview

If your goal is to force HTTPS, the redirect itself is only one part of the job. A clean http to https redirect depends on infrastructure, application behavior, crawl signals, and testing. Done well, the migration creates one consistent canonical version of every URL. Done poorly, it creates redirect chains, broken assets, tracking gaps, and duplicate indexing.

For most permanent migrations, the preferred pattern is straightforward: every valid HTTP URL should return a single 301 redirect to its HTTPS equivalent. That means preserving the path and query string where appropriate, avoiding unnecessary intermediate hops, and keeping the redirect logic predictable across desktop, mobile, and campaign traffic.

Think of the work in five layers:

• Certificate and hosting readiness: HTTPS must load successfully before you force it.
• Redirect rules: HTTP requests should map cleanly to HTTPS requests.
• Canonicalization: HTTP/HTTPS, www/non-www, slash handling, and case behavior should not conflict.
• Internal references: links, assets, canonicals, sitemaps, and hreflang should point to HTTPS directly.
• Validation: test live responses with a redirect checker, crawl tools, logs, and browser inspection.

If you need a broader refresher on status code choices, see 301 vs 302 vs 307 Redirects: When to Use Each for SEO and User Experience. For this checklist, the assumption is a permanent move from HTTP to HTTPS, which usually calls for a 301 rather than a temporary redirect.

Checklist by scenario

This section breaks the work into common implementation scenarios so you can use the parts that match your stack.

Scenario 1: A single website moving from HTTP to HTTPS

• Install a valid SSL/TLS certificate for the hostname you plan to serve.
• Confirm that the HTTPS version loads normally before enabling any sitewide redirect.
• Create a permanent redirect from http://example.com/* to https://example.com/*.
• Preserve the full request path and, if relevant, the query string.
• Update CMS settings so the site’s primary URL is the HTTPS version.
• Replace hard-coded internal HTTP links with HTTPS links.
• Update canonical tags to point to HTTPS URLs.
• Regenerate XML sitemaps so they list only HTTPS URLs.
• Check robots.txt for hard-coded HTTP sitemap paths or disallowed resources needed for rendering.
• Test a sample of top pages, old landing pages, and URLs with parameters.

This is the cleanest form of website redirect setup. The most important rule is to avoid forcing users and crawlers through multiple hops such as HTTP to HTTPS to non-www to trailing-slash normalization. Consolidate logic where possible.

Scenario 2: HTTP to HTTPS plus www/non-www consolidation

Many sites are not just changing protocol. They are also choosing a preferred hostname such as https://www.example.com or https://example.com. In that case:

• Decide on one canonical host before writing redirect rules.
• Map all variants to that destination: HTTP, HTTPS, www, and non-www.
• Prefer a single-step redirect whenever your platform allows it.
• Update canonical tags, sitemaps, structured data references, and internal links to the final preferred host.
• Verify that login flows, carts, form actions, and cookies still work on the chosen host.

A common source of trouble is stacking separate rules in different places: application, CDN, server config, and plugin. That creates unpredictable behavior and is a frequent cause of a redirect loop fix project later. Document where the canonical host decision is enforced.

Scenario 3: Multiple subdomains

If your site uses hosts like www, blog, shop, help, or geo-specific subdomains, treat them as distinct properties first and a family second.

• Inventory every active subdomain, including marketing and support environments that still receive traffic.
• Confirm each subdomain has certificate coverage.
• Decide whether each subdomain stays separate on HTTPS or is consolidated into another host.
• If a subdomain is staying live, redirect its HTTP version to its HTTPS equivalent.
• If a subdomain is being retired, redirect old URLs to the most relevant HTTPS destination, not just the homepage.
• Review CDN, reverse proxy, and firewall behavior per host.
• Test origin pulls and upstream headers so the application correctly detects HTTPS.

Subdomains are where hidden dependencies often appear: old API docs, forgotten image hosts, staging hosts exposed to bots, or campaign microsites still printed on QR codes. Include these in your redirect audit even if they are outside the main CMS.

Scenario 4: Legacy URLs and historical content

Older websites often have URL patterns that changed over time. If you are forcing HTTPS during or after a redesign, do not rely on a blanket domain redirect alone.

• Export historical URLs from analytics, CMS records, Search Console exports, backlink tools, and server logs if available.
• Create URL mapping for high-value old pages, documents, campaign landers, and linked resources.
• Redirect each meaningful legacy URL to its best matching HTTPS page.
• Keep redirects in place long enough for users, bookmarks, and backlinks to update naturally.
• Prioritize URLs with external links, conversions, or recurring traffic.

This is especially important for site migration SEO. HTTPS migration is often bundled with IA changes, CMS changes, or hosting changes, and that raises the risk of losing equity from old links. If you also need to fix broken backlinks, your HTTPS checklist should include URL mapping rather than only protocol forcing.

Scenario 5: Apache, Nginx, Cloudflare, and WordPress setups

The principle is the same across platforms, but the right implementation point differs.

Apache

• Use server config or .htaccess only if that fits your environment.
• Keep htaccess redirect logic minimal and well commented.
• Test for conflicts with existing rewrite rules for trailing slashes, language paths, or legacy rewrites.

Nginx

• Handle the redirect at the server block level where possible.
• Verify that upstream applications receive correct forwarded protocol headers.
• Review any duplicate rewrite logic in the application layer.

Cloudflare or another edge platform

• Decide whether to enforce HTTPS at the edge, origin, or both.
• Avoid overlapping cloudflare redirect rules and origin redirects that create chains.
• Make sure SSL mode and origin certificate setup are consistent with your desired behavior.

WordPress

• Update WordPress Address and Site Address to HTTPS.
• Review plugin-generated redirects, security rules, and caching behavior.
• Confirm that media URLs, theme assets, and hard-coded menu links are not still using HTTP.

Whatever stack you use, pick one primary enforcement layer for the ssl redirect and make every other layer aware of it.

Scenario 6: Campaign links, tracking parameters, and QR codes

HTTPS migrations affect marketing operations more than many teams expect.

• Check that UTM-tagged URLs redirect cleanly and preserve parameters.
• Test ad landing pages, email links, social links, and partner links.
• Review shortened links and redirecting campaign domains.
• Confirm QR code destinations still resolve to the intended HTTPS pages.
• Validate that analytics tools attribute sessions correctly after redirect.

If link governance matters to your team, pair this checklist with ongoing analytics review. Two useful reads are Real-Time Analytics for Website Owners: What to Log, What to Ignore, and What to Automate and How Google Ads Auto-Linking to YouTube Changes Redirect Analytics for Campaign Tracking.

What to double-check

Before and after launch, these are the checks most likely to catch expensive mistakes early.

1. Redirect response behavior

• HTTP pages return a 301 to the correct HTTPS page.
• There is no chain such as HTTP to HTTPS to canonical host to normalized path.
• There is no loop between edge and origin.
• Query strings are preserved when they should be.
• Nonexistent HTTP URLs do not all redirect blindly to the homepage unless that behavior is intentional.

A redirect checker or redirect chain checker is useful here. Test representative URLs from every template, content type, and campaign source.

2. Mixed content

• Images, scripts, CSS, fonts, iframes, and video embeds load over HTTPS.
• Third-party resources support HTTPS.
• No hard-coded HTTP assets remain in templates, modules, or custom fields.

A page can technically redirect correctly and still feel broken if the browser blocks insecure assets. Mixed content is one of the most common reasons an HTTPS rollout appears complete while users still see warnings or layout issues.

3. Canonical and crawl signals

• Canonical tags point to HTTPS, not HTTP.
• Hreflang annotations use HTTPS consistently.
• Structured data URLs, Open Graph URLs, and metadata references use HTTPS.
• XML sitemaps list HTTPS URLs only.
• Internal links point directly to HTTPS destinations.

This is where the canonical vs redirect distinction matters. Redirects send users and bots to the right location; canonical tags help clarify the preferred indexed version. They should support each other, not disagree.

4. Application and security behavior

• Sessions persist correctly after redirect.
• Forms submit over HTTPS.
• Cookies use secure settings when appropriate.
• Admin panels, checkout flows, and account pages work end to end.
• No user-controlled parameter creates an open redirect vulnerability.

Any redirect logic that accepts a destination parameter should be reviewed carefully. A migration is a good time to remove loose redirect handlers that can be abused.

5. Logging and monitoring

• Track 3xx, 4xx, and 5xx patterns after launch.
• Watch for spikes in HTTP requests to URLs you did not map.
• Review referrers and campaign parameters to confirm attribution continuity.
• Keep an eye on crawl behavior and indexing trends over the following weeks.

For larger sites, the work does not end at launch. Redirects are an operational asset that should be measured, pruned carefully, and documented.

Common mistakes

The fastest way to improve an HTTPS rollout is to avoid the repeat offenders.

• Using 302s for a permanent move. If the migration is intended to stick, a 301 is usually the cleaner signal.
• Redirecting everything to the homepage. This protects neither users nor SEO value when relevant destination pages exist.
• Creating chains through multiple systems. A CDN rule, plugin rule, and server rule can combine into avoidable hops.
• Forgetting non-HTML assets. PDFs, images, feeds, and downloadable files often have backlinks too.
• Leaving internal links on HTTP. Even when redirects catch them, they waste crawl budget and slow navigation.
• Ignoring old campaign URLs. Print materials, short links, and QR code destinations may outlive a redesign by years.
• Skipping test coverage for subdomains. Smaller properties are often where the broken certificate or loop hides.
• Confusing DNS with redirects. DNS points traffic; redirect rules handle URL forwarding behavior.
• Relying on JavaScript redirects for protocol migration. Server-side redirects are usually more reliable for users and crawlers.
• Removing old redirects too quickly. Legacy URLs can continue receiving meaningful traffic long after a migration.

If your site feels unusually hard to standardize, that is often a sign of accumulated redirect rules, historical domain forwarding, or undocumented exceptions. Clean implementation is easier when you reduce the number of places where rules can be created.

When to revisit

Use this checklist as a recurring review document, not a one-time launch note. Revisit your HTTPS redirect setup in the following situations:

• Before seasonal planning cycles: test high-traffic landing pages, campaign URLs, and short links before demand spikes.
• When workflows or tools change: CDN changes, host moves, CMS migrations, plugin swaps, and security product rollouts can alter redirect behavior.
• When you launch new subdomains or retire old ones: add them to your certificate, redirect, and monitoring plans.
• When analytics looks inconsistent: review parameter handling, referral patterns, and campaign destination behavior.
• When you redesign templates: mixed content and hard-coded HTTP links often return during rebuilds.
• When you inherit an older site: run a fresh redirect audit before making assumptions about what is already covered.

A simple maintenance routine works well:

1. Pick a representative list of priority URLs: homepage, top templates, campaign landers, top linked legacy pages, media files, and one sample per subdomain.
2. Run them through a redirect checker monthly or before major releases.
3. Review logs for unexpected HTTP traffic and 404s.
4. Update redirect documentation when rules are added, removed, or relocated between systems.
5. Retest after any infrastructure change, even if the change seems unrelated to redirects.

The practical goal is not just to force https. It is to make every valid request land on the right secure URL in the fewest possible steps, with no loss of trust, tracking, or crawl clarity. If you treat your HTTPS rules as part of your broader link management and technical SEO workflow, they will hold up better over time.