UTM parameters lost after a redirect? How to find the hop that drops them

Why do UTM parameters disappear after a redirect?

The status code is not the problem. UTM parameters are lost when the redirect rule builds the new address without the original query string. Say a visitor opens http://example.com/promo?utm_source=senriko-scan and the server answers Location: https://example.com/promo/. The next request goes out without utm_source, and nothing later in the chain can bring it back.

The usual places to look: HTTP to HTTPS, www to the bare domain or back, an added trailing slash, a country or language redirect, and redirect rules set up in a CDN or hosting dashboard rather than in your code. A server can keep the UTM parameters and a script or meta refresh can then send the browser to an address without them. That is why one look at the last server response is not enough.

In GA4, visits that arrive without their campaign often land in (direct) / (none), and Google’s own help names redirects among the things that strip UTM parameters. The same rule drops Google Ads’ gclid, which travels in the same query string: Google Ads flags it as website redirects losing click data.

An address can also come out clean after an ordinary click through the site’s menu. To test the redirect itself, start from the link in the ad and follow it to the first landing page.

How do you check UTM parameters through a redirect chain?

Checking UTM parameters starts with the starting link. From there, you are looking for the first address where even one parameter went missing.

1. Start from the link in the ad

   Take the landing page URL exactly as the campaign uses it. For a controlled run, utm_source=senriko-scan, utm_medium=senriko-check and utm_campaign=senriko-attribution will do. If the link already has a ?, add the next parameters with &.

2. Record every hop

   Open DevTools, go to the Network panel and tick Preserve log before you load the link. Compare the request with the Location header of every 301, 302, 307 or 308 response. Keep watching after the last 3xx: a script or a meta refresh moves the browser without one.

3. Find the first address that lost something

   Look for the first URL where a parameter is missing or its value changed. Save the two neighbouring URLs, the last good one and the first bad one, for your developer. After the fix, run the same starting link again.

For the server side of the chain, curl is quicker:

curl -sIL "https://example.com/promo?utm_source=senriko-scan"

It prints the status and Location of every response. curl does not run scripts or meta refreshes; only a browser does, so use the Network panel or the UTM Survival Test for those. -I sends HEAD requests, and a few servers answer HEAD differently from GET. If the chain looks odd, follow it with GET instead:

curl -sL -o /dev/null -D - "https://example.com/promo?utm_source=senriko-scan"

If every parameter reaches the landing page and the report is still empty, check the tag and the analytics setup next. The address chain has still answered something useful: the cause is further along the data’s path. Our free GA4 checker shows which GA4 streams a page sends to.

Two cases from our team’s work

What does the UTM Survival Test show?

SENRIKO’s free UTM Survival Test opens your page in a real browser, follows server, script and meta redirects, and reads the form fields and the browser’s storage. It tests with utm_source=senriko-scan, utm_medium=senriko-check and utm_campaign=senriko-attribution. A form page at a different address on the same site is opened directly.

The result tells you whether the UTM parameters survived the trip to the page you tested. The test does not fill in or send a form, accept a cookie banner, check gclid, fbclid or msclkid, or see your CRM.

How do you keep UTM parameters through a redirect?

If a parameter disappeared on a particular hop, give your developer the starting link and the two neighbouring addresses from the chain. The rule has to keep the query string whenever it changes the protocol, domain, path or language.

Nginx

Look at the variable in the destination. $uri holds the path only, without the query string, while $request_uri carries the original path with its parameters:

# UTM parameters are lost
return 301 https://example.com$uri/;

# UTM parameters are kept
return 301 https://example.com$request_uri;

If the path has to change, for example to add a slash, write the parameters in yourself: return 301 https://example.com$uri/$is_args$args;.

Apache and .htaccess

mod_rewrite copies the original query string when the target has none, and discards it as soon as the target carries a query string of its own. The [QSA] flag combines the two; [QSD] drops the original on purpose, so look for it too. A plain Redirect from mod_alias keeps the query string.

# UTM parameters are discarded: the target has its own query string
RewriteRule ^promo$ https://example.com/promo/?ref=ads [R=301,L]

# UTM parameters are kept alongside ref=ads
RewriteRule ^promo$ https://example.com/promo/?ref=ads [R=301,L,QSA]

Cloudflare

A Single Redirect rule keeps the query string only when Preserve query string is switched on, and it is off by default. Check every rule your campaign traffic passes through, the HTTP to HTTPS and www rules included.

Then run the same URL again. Pay particular attention to the variants your ads actually use: with and without www, HTTP, the trailing slash and the locale.

Updating the ads to the final address helps too, but old links saved elsewhere will keep going through the redirect, so test the fixed rule on its own. Before a campaign goes live, run its starting link through the UTM Survival Test. If the UTM parameters reach the page and the source still does not appear in a report or a lead, the next step is the analytics and the form’s data hand-off.

Frequently asked questions