Redirect Checker
Show the exact hop where the protocol upgrade changes the URL and whether the query string survives.
Open tool >Redirect plus UTM recovery
UTM Lost After HTTP to HTTPS Redirect
A protocol upgrade drops UTMs on the secure hop, so the landing page loads but analytics and attribution lose the campaign context.
Introduction
UTM Lost After HTTP to HTTPS Redirect is a narrower incident than generic UTM loss: the landing page often still resolves, but the exact protocol upgrade from http:// to https:// rewrites the URL and drops the campaign tags on the secure hop. Teams usually notice it only after GA4, CRM reports, or partner dashboards start showing direct or '(not set)' traffic while the paid link itself appears healthy.
This issue matters because the protocol hop often sits in shared infrastructure: load balancers, CDN rules, tracking domains, affiliate smartlinks, or old web-server rewrite files. If the upgrade step strips utm_source, utm_medium, or utm_campaign, every later owner inherits bad evidence. A vague screenshot of the final page is not enough; you need one trace that shows the HTTP URL with UTMs and one secure destination that arrives without them.
Treat this guide as the bridge between broad redirect QA and a precise remediation packet. The goal is to prove that the secure redirect is the owner, hand the exact fix to whoever controls that rule, and then retest the same production link until the HTTPS destination keeps every required parameter.
Why the problem happens
Protocol upgrades are easy to underestimate because browsers normalize them quietly. A redirect can return 301 or 308, the page can still load quickly, and nobody notices that the rewrite dropped the original query string during the move to HTTPS.
The failure is especially common when legacy HTTP rules were written before marketing teams standardized UTMs. Old rewrite logic may preserve the path but rebuild the destination URL from scratch, append only a subset of parameters, or force a canonical host without copying the existing query string.
You need evidence from both the transport layer and the final destination. Pair a Redirect Checker export with a secure-page decode from Click ID Extractor so stakeholders can see whether the loss happens on the protocol jump or later inside the page.
- A server-level rewrite sends traffic to HTTPS but omits the original query string variables.
- A CDN or edge rule normalizes the host and protocol but only forwards approved parameters.
- A tracking domain upgrades to HTTPS and then hands off a cleaned landing URL that no longer contains UTMs.
Common causes
Most incidents fall into one of three buckets: insecure-to-secure rewrite rules that ignore the query string, chained upgrades where one owner forwards to another without preserving parameters, or landing infrastructure that treats the HTTPS destination as a canonical clean URL.
Separate the first technical owner from the downstream symptoms. Analytics teams may notice the loss, but they rarely own the redirect. Your runbook should name whether the rule lives in Apache or Nginx config, Cloudflare, an affiliate tracker, a CMS redirect manager, or a partner-controlled bridge domain.
Once you know the bucket, write the failure signature in plain language: 'HTTP URL contains full UTMs, HTTPS hop drops them before the landing page renders.' That sentence is what lets infrastructure teams patch the right layer instead of debating analytics behavior.
- Legacy HTTP to HTTPS rules rebuild only scheme and host, then forget
$query_stringor its platform equivalent. - Multiple canonicalization steps run in sequence: HTTP to HTTPS, www to apex, and path cleanup, with one middle hop deleting the tags.
- Security middleware rejects some query parameters on the secure host because the allow-list never included paid-media tags.
- Affiliate or tracker templates append UTMs on the HTTP entry URL, but the secure bridge URL uses a separate destination field.
Step-by-step troubleshooting
Work from one real production URL. Do not simplify it before testing. The whole point is to prove whether the exact launch link survives the protocol upgrade with every campaign tag intact.
Your strongest evidence packet includes the raw HTTP entry URL, the full redirect chain, the secure landing URL after the upgrade, and one business-facing note that explains which reports or audiences broke because UTMs disappeared.
Retest after every rule change using the same URL from desktop and mobile. HTTP to HTTPS bugs often hide behind cached rules, device branches, or GEO-specific CDN behavior.
-
Capture the insecure-to-secure jump
Run the exact campaign URL through Redirect Checker and save the hop where HTTP becomes HTTPS, including status code, host change, and whether the query string shrank.
-
Validate the status behavior in isolation
Use Check HTTP Redirect to confirm whether the upgrade uses the intended permanent or temporary response and whether cache headers could preserve a broken rule.
-
Decode the final secure URL
Open the resolved landing page in Click ID Extractor so the team can compare the original UTMs with the actual HTTPS destination users received.
-
Compare against the approved tagged template
Rebuild the expected destination in UTM Builder and attach it next to the broken HTTPS result so nobody argues about the intended parameter set.
-
Escalate the right fix path
If the secure hop is the owner, move straight into HTTP to HTTPS redirect problem or the broader UTM parameters lost after redirect workflow when other hops also mutate the tags.
Tools that help solve the problem
Use a compact tool stack and keep every artifact together. This incident does not need fifteen screenshots; it needs one proof chain that shows the source URL, the upgrade hop, the final secure URL, and the expected tagged destination.
The same packet should work for marketers, developers, hosting teams, and partners. When each person sees the exact same before-and-after evidence, the conversation moves from blame to implementation.
After the rule is patched, archive the clean HTTPS trace and attach the supporting KB workflow from How to audit redirects before launch so future launches test this edge case before paid traffic goes live.
HTTP Status Code Checker
Verify the secure redirect response type, cache behavior, and headers before you change server rules.
Open tool >Click ID Extractor
Decode the final HTTPS landing URL so UTMs, click IDs, and missing parameters are visible in one capture.
Open tool >UTM Builder
Generate the approved secure destination that should be used as the comparison baseline in tickets and launch docs.
Open tool >Pixel Scanner
Confirm analytics or browser-side tags only after the secure landing URL itself preserves the right campaign parameters.
Open tool >Conclusion
An HTTP to HTTPS UTM loss is usually a configuration bug, not a mystery attribution problem. Once you isolate the exact secure hop, the incident becomes much easier to assign and much harder for any owner to dismiss.
Keep one regression checklist for every new domain, redirect rule, or CDN migration: test the raw HTTP campaign link, verify the HTTPS destination keeps the full query string, and store the evidence in the launch record.
That discipline turns a one-off firefight into reusable redirect governance. Future launches move faster because the team already knows how to prove the upgrade is safe before budget hits the page.