Redirects and Query Parameters: How to Preserve Tracking Without Breaking Destinations

Overview

When people talk about a 301 redirect or 302 redirect, they often focus on the path and forget the rest of the URL. In practice, the query string matters just as much. Everything after the question mark can carry campaign attribution, internal search filters, language choices, product options, referral data, and application state. If your URL redirect ignores or mishandles those parameters, the destination may still load, but the visit can become difficult to measure or functionally incorrect.

A simple example shows the risk. Suppose a marketing team uses /spring-sale as a tracked campaign link, and that URL redirects to /offers/spring. If the incoming request is /spring-sale?utm_source=newsletter&utm_medium=email, the business expectation is usually that the user lands on /offers/spring?utm_source=newsletter&utm_medium=email. If the redirect drops the query string, analytics lose attribution. If it duplicates or mangles the parameters, reports become messy. If it appends them to a destination that already has parameters, the landing page may break.

This is why query handling should be treated as part of tracking parameters redirect design, not as an afterthought. A technically valid redirect can still be operationally wrong.

In general, you will work with three choices:

• Preserve the full query string and pass it through unchanged.
• Rewrite or map selected parameters to a new destination format.
• Drop parameters intentionally when they are irrelevant, harmful, or likely to create duplicate URL states.

The right option depends on the destination page, the platform, and the role of the original parameters. For campaign routing, preserving parameters is often the safest default. For migrations, application changes, or URL cleanup, selective handling is often better.

If you are also reviewing redirect quality more broadly, pair this topic with Redirect Rule Testing Checklist: What to Verify Before You Publish Changes.

Core framework

The quickest way to handle redirect query parameters properly is to work through a simple decision framework before you publish any rule.

1. Identify what the parameters actually do

Not all query strings are equal. Group them into clear types:

• Attribution parameters, such as UTMs and campaign identifiers.
• Functional parameters, such as filters, sort orders, search terms, IDs, and session-independent state.
• Tracking or platform parameters added by ad systems, email platforms, or analytics tools.
• Unwanted parameters, such as duplicate tracking tags, malformed values, or obsolete keys from retired systems.

This first step matters because it determines whether you should preserve, transform, or discard them. A UTM tag generally needs to survive. A deprecated product filter from an old site may need rewriting. A session token should not be passed through a public redirect.

2. Decide whether the destination supports the same parameter model

A redirect only moves the request; it does not guarantee the target page can interpret the incoming query string. Before you configure a rule, ask:

• Does the destination accept the same keys and values?
• Does it already use its own query parameters?
• Will appending the original parameters create conflicts?
• Is the destination canonical URL supposed to include those parameters?

For example, if the old site used ?category=boots&color=black and the new site expects ?filter=boots-black, a straight pass-through may not work. This is a redirect mapping problem rather than a simple forwarding task.

3. Choose the right redirect behaviour

Most implementations fall into one of these models:

• Pass-through: keep all incoming parameters and append them to the destination.
• Replace: send users to a fixed destination with a fixed query string, ignoring the original one.
• Merge: keep the incoming parameters but add required destination parameters.
• Transform: read one or more incoming parameters and rewrite them into a new format.

For campaign links, pass-through is often the cleanest answer. For app migrations, transform rules are usually safer. For temporary campaign pages, replace can be acceptable if the destination is only meant to carry a controlled parameter set.

4. Be explicit about permanent and temporary use

A 301 vs 302 decision still matters. If the redirect reflects a long-term URL change, a permanent redirect is usually appropriate. If the routing is campaign-specific, time-limited, or being tested, a temporary redirect may be better. The key point here is that status code and query-string behaviour are separate decisions. A correct SEO redirect can still mishandle attribution if parameters are lost.

5. Avoid accidental duplication

The most common issue in a query string redirect is duplication. This happens when:

• The destination already includes ?utm_source=... and the redirect appends another utm_source.
• A rule forwards the full original query string to a destination that also has fixed parameters.
• Multiple redirect layers each append parameters independently.

This can produce invalid URLs, inconsistent attribution, or page states that are hard to reproduce. If you need both destination-specific parameters and incoming campaign data, define merge logic carefully and test for repeated keys.

6. Check canonicalisation alongside redirects

Campaign parameters often create non-canonical URLs by design. That is usually acceptable for tracking, but the destination page should still have a clear canonical strategy. Redirects should not be expected to solve every duplicate-state issue on their own. If your site is also standardising path variants, casing, or slashes, review those rules together. These related guides can help: Uppercase to Lowercase URL Redirects and Trailing Slash Redirects.

7. Test the full request, not just the final page

A landing page that loads is not enough proof that the setup works. You need to verify:

• The original request URL.
• The HTTP status code returned.
• Whether the query string is preserved, altered, or dropped.
• Whether another redirect occurs afterward.
• Whether analytics and application logic recognise the final parameters.

A good redirect checker should show the redirect chain, headers, and final destination. This is especially important when CDNs, CMS plugins, application routing, and server rules all play a role.

Practical examples

The best way to understand pass parameters through redirect logic is to compare common situations.

Campaign short link to a landing page

Incoming URL: /go/spring?utm_source=linkedin&utm_medium=social&utm_campaign=q2_launch

Desired destination: /landing/spring?utm_source=linkedin&utm_medium=social&utm_campaign=q2_launch

This is the classic case for preserving the full query string. The redirect exists to provide a cleaner shareable URL, while the destination still needs attribution data. If the redirect rule strips parameters, reporting breaks. If you use QR codes, this same pattern often applies.

Legacy filtered category page to a new taxonomy

Incoming URL: /shop?dept=mens&type=jackets

New site format: /mens/jackets

Here, a blind pass-through may be unnecessary or harmful. The better outcome is a redirect that maps the old parameters into a new clean path. If some old filters no longer exist, send users to the closest equivalent page rather than carrying unsupported parameters forward.

Destination already contains fixed parameters

Incoming URL: /offer?utm_source=email

Redirect target configured as: /promo?ref=internal

If your system appends the original query string automatically, the final URL may become /promo?ref=internal&utm_source=email. That may be correct. But if the destination already includes campaign tags, you could end up with duplicated keys. This is where merge rules need to be intentional.

Domain forwarding during a campaign migration

A business moves campaign traffic from an old microsite domain to a main-site landing page. Incoming links contain UTMs, ad-platform IDs, and occasionally custom partner parameters. In this case, preserving the query string is usually necessary, but only if the receiving site can accept the extra parameters cleanly. If forwarding happens at registrar or DNS-adjacent tooling with limited control, test carefully. Basic domain forwarding services may behave differently from full server-side rules. For broader context, see Domain Forwarding vs Website Redirects.

Platform-specific redirect constraints

Different stacks handle query strings differently. An Apache redirect rule, an Nginx redirect, a Cloudflare redirect, or WordPress redirects managed by a plugin may not behave the same way by default. Some preserve the query string automatically. Some require explicit variables or flags. Some page-rule tools offer only simple matching. The evergreen lesson is not to assume consistency across platforms. Always verify the exact behaviour in your environment before applying the pattern at scale.

Bulk campaign routing

If you manage many short campaign URLs, document which routes should preserve all incoming parameters and which should overwrite them. A spreadsheet or redirect map should include a column for query-string handling, not just source, target, and status code. This becomes essential in larger rollouts; see Bulk Redirect Uploads: How to Manage Large Redirect Lists Without Errors.

Shop and product redirects

Commerce platforms often rely on query parameters for variant, sort, or tracking behaviour. A redirect that drops them can send users to the wrong product state or remove useful attribution. If your stack includes Shopify, product and collection changes need careful testing around both path redirects and parameter handling. Related reading: Shopify Redirects Guide.

Common mistakes

Most problems with preserve utm parameters redirect setups come from assumptions rather than syntax errors. These are the issues worth checking first.

Assuming all redirects preserve query strings

They do not. Some tools pass them through automatically, some do so only in certain rule types, and some overwrite them when a destination includes its own query string. Treat preservation as something to verify, not something to assume.

Using client-side redirects for critical tracking

JavaScript-based redirects can work, but they introduce more moving parts and are easier to break with timing, browser, or script issues. For campaign routing and attribution, a server side redirect is usually more reliable.

Creating redirect chains that alter parameters

A redirect chain is already undesirable from a performance and maintenance perspective. It becomes worse when different layers handle parameters differently. One hop may preserve them, another may normalise them, and another may drop them. If you need accurate attribution, reduce chains wherever possible. For migration work, Redirect Mapping for Website Migrations is useful background.

Ignoring parameter order and duplication

Some systems read duplicate parameters unpredictably, using either the first instance or the last. Others treat different orders as distinct URLs for caching or logging purposes. If you merge parameters, decide which keys are authoritative.

Passing through sensitive or useless parameters

Not every parameter deserves to survive a redirect. Internal tokens, debugging values, and obsolete identifiers can clutter URLs or leak information. Preserve what has a clear purpose. Drop what does not.

Forgetting the analytics side

Even if the final URL contains UTMs, attribution may still fail if the redirect goes through intermediate systems, appends malformed values, or lands on a page that strips parameters immediately. Check real sessions in analytics and testing environments, not just the browser address bar. For a wider campaign hygiene view, see UTM Link Tracking Best Practices.

Mixing canonical cleanup and campaign routing without a plan

It is common to combine an HTTP to HTTPS redirect, host standardisation such as www to non www redirect, path cleanup, and campaign forwarding all at once. That can work, but only if the rules are designed together. Otherwise, one layer may rewrite the URL before another layer can preserve or interpret the query string correctly.

Not documenting exceptions

Some routes should always preserve parameters. Others should always strip them. If exceptions live only in a developer's memory, future changes will break them. Record the rule logic and the reason for it.

When to revisit

If you want redirects with query parameters to remain reliable, revisit them whenever your URL structure, campaign process, or platform behaviour changes. This is not a set-and-forget area.

Review your setup when:

• You launch a new campaign template, QR code programme, or short-link pattern.
• You migrate domains, landing pages, or CMS platforms.
• You change analytics tooling or attribution conventions.
• You introduce CDN, edge, or hosting-level redirect logic.
• You notice traffic drops, attribution gaps, or unexplained landing-page mismatches.
• You start seeing redirect chains, loops, or duplicate parameter issues in tests.

A practical review process looks like this:

1. List your important tracked entry URLs. Include campaign links, short URLs, QR destinations, and legacy redirects.
2. Mark the expected query behaviour for each. Preserve, replace, merge, or transform.
3. Test real examples with sample parameters. Use URLs that include UTMs and any platform-specific tags you rely on.
4. Inspect each hop in the chain. Do not stop at the final page load.
5. Check analytics capture. Confirm that attribution appears where your team expects it.
6. Document edge cases. Especially where a destination already includes its own parameters.
7. Retest after every routing or platform change. Even small infrastructure changes can alter default query handling.

If you are preparing a site launch or redesign, it is worth folding this into a wider redirect QA process. Start with Redirects for Site Redesigns: A Pre-Launch and Post-Launch Checklist. If you are forwarding old domains into active campaigns, also review How to Redirect an Expired Domain Without Harming SEO or User Trust.

The lasting principle is simple: treat the query string as part of the destination contract. A redirect is not complete until you know what happens to the parameters that arrive with it. Once you build that habit into campaign planning and redirect testing, you are far less likely to lose attribution, confuse users, or create avoidable routing problems.