How to Redirect a Domain Without Losing Paths or UTM Parameters

To redirect a domain while preserving path and query strings, your redirect layer must forward the full request URI, not just the hostname. In practice, that means requests like:

oldsite.com/pricing?plan=pro&utm_source=email

should arrive at:

newsite.com/pricing?plan=pro&utm_source=email

If your setup only forwards the bare domain, you lose the exact path users asked for. That breaks campaign links, deep links, docs pages, and often the SEO value of the migration itself.

If this change is part of a bigger site move, start with the broader website migration redirect checklist and then come back to this implementation detail.

What "preserve path and query strings" really means

When people say they want domain forwarding, they can mean very different things:

Basic host-only forwarding

Every request goes to one new homepage:

oldsite.com/* -> newsite.com/

This is simple, but it throws away context.

Path-preserving forwarding

The path after the domain stays intact:

oldsite.com/blog/post-1 -> newsite.com/blog/post-1

This is what most site migrations actually need.

Query-preserving forwarding

Campaign and tracking parameters stay intact:

oldsite.com/pricing?utm_source=x -> newsite.com/pricing?utm_source=x

Without this, campaign analytics and attribution often become unreliable.

If you already know campaign parameters matter, make them part of the redirect spec instead of a last-minute QA note.

Why DNS alone is not enough

This is one of the most common points of confusion.

DNS records like CNAME or A records tell the internet where to send traffic. They do not by themselves issue an HTTP 301 or 302 redirect for the browser.

If you want users and crawlers to land on a different URL, you need an HTTP redirect layer that can return:

• the correct status code
• the correct destination
• optional path forwarding
• optional query parameter handling

That is why domain forwarding is not just a DNS task. It is a routing task.

If you are still deciding whether the change is permanent or temporary, read 301 vs 302 vs 307 vs 308 redirects before you set the rule live.

The safest pattern for a real domain migration

For most migrations, the best baseline is:

1. choose the final canonical hostname
2. force HTTPS
3. forward every meaningful old path to its new equivalent
4. preserve important query parameters
5. keep the number of hops to one

Example:

http://oldsite.com/docs/api?ref=partner
  -> https://newsite.com/docs/api?ref=partner

That is much better than:

http://oldsite.com/docs/api
  -> https://oldsite.com/docs/api
  -> https://www.newsite.com/docs/api
  -> https://newsite.com/docs/api

When path preservation matters most

Site migrations

If you are moving to a new domain or replatforming the site, preserving path structure keeps old backlinks and indexed URLs useful.

Docs and knowledge bases

Docs users rarely land on the homepage first. They land on a specific article. Dropping every request on / destroys that experience.

Paid campaigns

If a user clicks an ad with five tracking parameters and the redirect strips them, your reporting becomes less trustworthy immediately.

Social bio and short links

Many branded links are really tiny routing rules. If the target path disappears, so does the clarity of the link strategy.

A clean wildcard forwarding model

The simplest mental model is:

source:      oldsite.com/*
destination: newsite.com/$1

That says:

• take everything after the slash
• insert it into the destination path
• preserve the request shape

For example:

If you also preserve query strings, then:

/pricing/enterprise?utm_source=partner

stays:

/pricing/enterprise?utm_source=partner

If your forwarding plan currently produces two or three hops before the final page, fix that before launch. Our guide to redirect chains and loops shows what to look for.

The four checks that prevent most forwarding mistakes

1. Confirm the destination hostname first

Pick the one final host:

• newsite.com
• or www.newsite.com

Do not try to figure it out halfway through the migration. That is how chains happen.

2. Decide on the status code

If the move is permanent, use a permanent code such as 301.

If it is temporary, use a temporary code such as 302.

If you need a refresher, see 301 vs 302 vs 307 vs 308 redirects.

3. Be explicit about query handling

Do not assume every provider keeps query strings automatically. Test it.

Use real examples:

curl -I 'https://oldsite.com/pricing?plan=pro&utm_source=email'

Then confirm the Location header contains the expected path and parameters.

4. Test both root and deep URLs

Many redirects work for / and fail for deeper pages like:

• /docs/api
• /blog/post-slug
• /pricing/enterprise
• /old-category/product-123

HTTPS and SSL are part of the redirect

One of the worst migration outcomes is this:

• the redirect is technically correct
• but the old domain does not terminate HTTPS cleanly
• so users still see certificate or security issues before the redirect happens

That is why automated SSL matters. The redirect flow begins at the first request, not after your routing logic has already had a perfect chance to execute.

If you want a managed option, UrlEdge Free Redirect Service includes automatic HTTPS and wildcard forwarding support.

Common forwarding mistakes

Redirecting only the homepage

This is the classic "it works on the homepage" launch mistake. Real users do not only visit /.

Forgetting non-www and root-domain behavior

You need to think through:

• oldsite.com
• www.oldsite.com
• subdomains if they are in scope

Dropping campaign parameters

Even if SEO is fine, your attribution data can become unreliable overnight.

Creating multiple hops

Path forwarding loses a lot of value if the request bounces through two or three intermediary hosts first.

Mixing HTTP and HTTPS rules carelessly

If the old host cannot handle HTTPS correctly, users may hit security errors before they ever see your destination.

A practical UrlEdge setup pattern

For a typical permanent migration:

1. connect the old domain
2. enable HTTPS
3. create a wildcard redirect rule
4. preserve the path
5. preserve required query parameters
6. test the top pages with Redirect Checker

This is especially useful when you want a no-code or low-code migration path without rebuilding routing logic inside Nginx, Apache, or app middleware.

FAQ

Can I redirect a naked domain and keep the path?

Yes, as long as your redirect layer supports root-domain forwarding and path preservation. This is a very common migration setup.

Should I always preserve query strings?

Not always, but you should do it deliberately. Preserve tracking, campaign, and functional parameters that matter. Drop junk parameters only if you are confident they are useless.

Is wildcard forwarding enough for every migration?

No. Some migrations need one-to-one mappings for renamed paths. Wildcards are great when the path structure is mostly unchanged.

Can I test this before changing DNS for everyone?

Yes. You should test on staging or controlled hosts first, then verify a real sample of paths before the full cutover.

Related UrlEdge guides

• Free Redirect Service
• Permanent 301 redirects
• DNS configuration docs
• Website migration redirect checklist

Authoritative references

• Google Search Central: site move with URL changes
• MDN: Redirections in HTTP