Redirect Checker
Show the exact HTTP to HTTPS hop where the query string changes or disappears.
Открыть инструмент >UTM governance
UTM Lost After HTTP to HTTPS Redirect
The protocol upgrade keeps the click alive but strips campaign parameters before the secure landing page loads.
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.
-
Trace the protocol upgrade
Run the live link in Redirect Checker and record the first hop where
http://becomeshttps://. -
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.
-
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.
-
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.
-
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.
-
Replace legacy HTTP launch links
Where possible, stop launching HTTP entry URLs at all and publish the secure canonical version from UTM Builder.
-
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.
-
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.
UTM Builder
Rebuild the canonical secure campaign URL once the redirect rule is fixed.
Открыть инструмент >UTM Decoder / Encoder
Compare the original launch URL against the first HTTPS hop and the final landing page.
Открыть инструмент >HTTP Status Code Checker
Inspect suspicious upgrade hops when you need a quicker status-code check outside the full chain trace.
Открыть инструмент >Выводы
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.
FAQ
Частые вопросы
Why are UTMs lost only when traffic starts on HTTP?
Because the first upgrade hop is often handled by older redirect rules or tracker templates. Directly opening the HTTPS page bypasses the broken step.
Should we keep launching HTTP links if the redirect is fixed?
No. A working redirect is useful for resilience, but the cleaner setup is to publish HTTPS campaign links as the canonical version and keep the HTTP rule only as a safety net.
Which page should we read next if the chain still breaks after the scheme upgrade?
Continue with <a href="/fix/utm-parameters-lost-after-redirect" class="text-blue-600 font-semibold">UTM Parameters Lost After Redirect</a> for the wider redirect path, or <a href="/fix/http-to-https-redirect-problem" class="text-blue-600 font-semibold">HTTP to HTTPS Redirect Problem</a> if the protocol migration itself is still unstable.