To https://www.newurl.org?form=FF34&utm_medium=email&utm_campaign=13131
Notice that newurl.org has an extra query parameter form=FF34
The ordering of the form=FF34 query parameter doesn’t matter, but it is needed.
Is there a way to do this with Rules?
Would this be setup under Rules > Redirect Rules or the Rules > Transform Rules?
(Lots of different Rule options here)
You should use Transform Rules for modifications that only Cloudflare and your origin server will see. If you use a TR to change the URL, the visitor (your browser, or Google’s) won’t receive a 301/302 redirect response with a location header pointing to the new URL. And since search engines won’t see a redirect, a TR should not be used when a redirect is required, as often is the case with SEO canonicals.
TRs can be used in combination with origin setups. For instance, I have a site which is a small dictionary, and when users were searching for certain terms in uppercase, this triggered my origin server defense against SQL injection. So I created a TR that lowers the case of the request’s query string if it starts with /s= (search). Users will still see their uppercase input in the browser, and there will be no redirect, but the origin will receive the request transformed as requested.
In your case, you would need a Redirect Rule. Adding a query parameter is rather tricky, and I hope Cloudflare Developers establish a more elegant way to handle query string, the adding/removing of ? and & as needed. Perhaps @smarsh could shed a light as to whether this is an issue being considered.
As it stands, the expression that would add a param to a QS would be something like:
Where 1234 is your new parameter. Since http.request.query does not include ?, you must add it, as well as the ending & to concat the original query string.
If requests already have a query string, as it seems to be your case, this should work. Notice that “preserve query string” is unchecked, as we are adding the original query string as part of the expression.
In case a request does not have a QS, the resulting URL would be:
https://newdomain.example.com/?1234&
and it would be up to your origin to handle the & (Not sure it helps you, but I just found out while testing this that WordPress does redirect removing the &)
