WordPress redirect tutorials
WordPress query parameters: preserve them or match them?
Understand the difference between carrying query parameters to a destination and using query conditions to select a redirect in RedirectNest Free and Pro.
Updated
Keeping a query parameter and matching a query parameter are different tasks. Free can preserve safe incoming parameters when an exact path redirects. Pro adds query conditions that help decide which rule should match.
Keeping a campaign parameter
Suppose /old-page/?utm_source=newsletter should redirect to /new-page/ while keeping the campaign value. The Free source field contains /old-page/ only. Choose /new-page/ as the destination and enable safe query preservation. The source path must not include a question mark or fragment.
If the destination already specifies a query value, that value takes priority. Since 0.5.5, RedirectNest also protects it from conflicting array forms and names that WordPress treats as equivalent. For example, an incoming campaign[]=other cannot replace a configured campaign=fixed.
Safe preservation removes recognized private names, including nested values such as profile[email] and credentials[accessToken]. It is not a promise to forward every input or to recognize all personal information. Leave passwords, keys and private values out of URLs you configure or share.
Selecting a rule using a query
A different requirement is sending /offers/?campaign=spring to one destination and other campaigns elsewhere. Here the query affects which redirect is selected. Use Pro matching controls and enter the path and query condition separately. Pasting the complete URL into the exact source field is not the supported configuration.
When a Pro wildcard or regex capture is used in a destination query, it is treated as one value. An ampersand inside the captured path does not create another query parameter. Test an example containing punctuation as well as an ordinary page name.
Fragments, such as #details, are handled by the browser and are not sent to the server as part of an HTTP request. A server-side redirect rule cannot inspect them as though they were query parameters.
A repeatable test
- Test the source with the expected parameter and value.
- Test the source with the parameter missing.
- Test another value so you can see whether the condition is too broad.
- Test a destination that already contains a query value.
- Check case and trailing-slash settings as separate matching choices.
Avoid sensitive tokens in examples, screenshots and exported rule files. Prefer harmless sample values such as campaign=spring. Do not make admin, login or API paths part of a redirect experiment.
See exact and advanced matching for the supported controls. Free covers exact paths and safe query preservation; Pro adds advanced matching tools.
KEEP THE NEXT STEP SIMPLE
See how RedirectNest fits.
Compare the editions, explore the workflow and choose what your website needs.