UTM Lost After HTTP to HTTPS Redirect

Symptoms

This issue usually appears when a live campaign link starts on an HTTP tracking domain or legacy landing URL, then upgrades to HTTPS before the visitor reaches the final page. The redirect works, but the final destination arrives without utm_source, utm_medium, or the rest of the campaign tags.

Teams notice it as a reporting mismatch: ad platforms show clicks on tagged URLs, while analytics, CRM records, or downstream dashboards show direct traffic or unassigned sessions. If the only recent change was a domain migration, SSL rollout, or tracking-domain cleanup, treat the protocol hop as the primary suspect.

Why this happens

HTTP to HTTPS upgrades often use older redirect rules, CDN rewrites, or tracker templates that rebuild the destination URL instead of forwarding the full query string. When that first hop recreates the URL without the original parameters, the rest of the chain stays clean but attribution is already gone.

The failure is easy to miss because the browser still lands on the right secure page. Only the query string changes, so you need redirect evidence instead of a visual page check.

• A protocol upgrade rule forwards only the path and ignores everything after the question mark.
• A tracker template points HTTP traffic to a hard-coded HTTPS offer URL with no parameter passthrough.
• CDN or load balancer rewrites normalize the destination before the tagged query string is preserved.

Common causes

Most cases come from configuration drift between web infrastructure and campaign operations. One team enforces HTTPS, another still launches HTTP entry URLs, and no one checks whether the redirect preserves marketing parameters.

Own the incident by hop: edge redirect, tracker or cloaker template, CMS redirect plugin, or landing-page middleware. That keeps the fix concrete.

• 301 or 302 rules upgrade the scheme but do not append the original query string.
• Tracking domains redirect into a new HTTPS hostname with a static destination string.
• Migration rules collapse duplicate slashes, fragments, or uppercase paths and accidentally drop UTMs during normalization.
• Teams test the secure landing page directly instead of the real launch URL that still starts on HTTP.

How to check it

You need to compare the original HTTP launch URL against the first HTTPS hop and the final resolved landing page. Do not skip straight to the secure destination or you will miss the exact handoff where the tags disappear.

Capture one broken example and keep the full string unchanged while you test. Rebuilding the URL by hand hides the issue.

1. Trace the protocol upgrade

   Run the live link in Redirect Checker and record the first hop where http:// becomes https://.

2. Compare the query string before and after

   Use UTM Decoder on the original URL and the first HTTPS URL to see whether any UTM key disappears or changes casing.

3. Validate the approved launch template

   Open the expected campaign link in UTM Builder or your launch sheet and confirm the HTTP entry URL matches what buyers actually shipped.

4. Check the final destination

   Confirm the last HTTPS landing page still contains the same UTMs. If not, escalate with this guide plus HTTP to HTTPS Redirect Problem.

How to fix it

Fix the first protocol-upgrade hop before you change anything else. Once the HTTP entry correctly forwards the full query string into HTTPS, the rest of the chain becomes much easier to validate.

After the redirect rule is repaired, retest the original launch URL and confirm that analytics or CRM storage matches the final HTTPS URL.

1. Forward the original query string

   Update the upgrade rule, CDN rewrite, or tracker template so the HTTPS destination receives the entire original query string instead of a rebuilt URL.

2. Replace legacy HTTP launch links

   Where possible, stop launching HTTP entry URLs at all and publish the secure canonical version from UTM Builder.

3. Retest the exact production URL

   Run the same broken example through Redirect Checker again and confirm the first HTTPS hop now keeps every UTM key.

4. Validate downstream reporting

   Check analytics, CRM, and any click-ID capture logic so the repaired secure URL still carries the same campaign context into reporting.

Relevant tools

These tools cover the core workflow: prove the break on the upgrade hop, inspect the broken query string, and rebuild the clean secure version you want teams to launch.

For the broader pre-launch QA routine, pair this fix with How to validate UTM links before launch.

Conclusion

The issue is resolved only when the original tagged HTTP URL, the first HTTPS hop, and the final landing page all contain the same campaign parameters.

Archive one before-and-after trace and add protocol-upgrade checks to your launch checklist. That is the simplest way to stop SSL migrations and redirect cleanups from silently wiping attribution again.

Related issues

Tracking bugs rarely travel alone. Explore these related guides to build a full remediation plan.

Recommended tools

Use this diagnostic stack whenever you need to capture evidence or verify that a fix worked.

Knowledge base articles

Need deeper theory? These long-form KB articles expand on the concepts touched in the troubleshooting guide.