Preserve Query Parameters During a Website Migration: Checklist

A domain or platform migration can preserve page content while quietly breaking the query parameters that make URLs work. Campaign tracking may disappear, filters may reset, and application links may stop behaving as expected.

Use this checklist to inventory important parameters, test redirects from representative old URLs, and monitor the new site after launch. The goal is to preserve parameters that matter—not to copy every parameter blindly.

Key Takeaways

• Map old URLs to their intended new destinations and decide which parameters each destination needs.
• Test query strings through every redirect hop, including duplicates, blank values, and encoded characters.
• Check how your redirect platform handles query strings; behavior varies by server, CDN, CMS, and redirect rule.
• Keep tracking parameters when they serve a business purpose, but avoid carrying sensitive or obsolete values into new URLs.
• Monitor redirects, landing pages, search performance, and application behavior after launch.

1. Inventory URLs and Parameters Before Migration

Start with URLs that receive meaningful traffic or support important workflows. Useful sources include analytics landing-page reports, server logs, campaign links, search landing pages, customer support examples, and application documentation.

Group parameters by purpose. A query string may contain more than one kind:

For each important old URL, record the expected destination, required parameters, optional tracking parameters, and expected behavior. A parameter name alone does not establish that it is safe or useful to preserve. Session identifiers, access tokens, and personal data should not be carried into public URLs without a specific, reviewed reason.

2. Decide What “Preserve” Means

Preserving a query string can mean keeping its values intact, keeping its meaning intact, or translating it into a new format. These are not always equivalent.

For example, an old platform might use ?category=chairs, while the new one uses ?filter=chairs. A redirect that copies the original query string technically preserves it, but the new application may ignore it. Conversely, translating it may preserve the user’s intended filter while changing the URL.

Decide whether each parameter should be:

• Passed through unchanged: appropriate when the new destination understands it and the value remains valid.
• Mapped or transformed: appropriate when the new platform uses a different parameter name or value format. Test the resulting behavior, not just the URL.
• Dropped intentionally: appropriate for obsolete, harmful, or irrelevant values. Record this decision so it is not mistaken for an accidental loss.

Do not assume that every redirect system preserves the original query string by default. Some rules append it, some replace it, and some require an explicit setting. Check the actual behavior of the server, CDN, CMS, or redirect service used in your migration.

3. Build a Representative Redirect Test Set

Test more than a clean URL with one simple parameter. Include examples that reflect real traffic and application behavior:

1. A URL with one ordinary parameter.
2. A URL with multiple parameters, including a campaign parameter.
3. Repeated parameter names, such as tag=a&tag=b.
4. A parameter with an empty value, such as q=.
5. Encoded characters, such as next=%2Faccount%3Ftab%3Dorders.
6. Parameters that should be transformed or deliberately removed.
7. A URL that passes through more than one redirect.

A small test matrix makes expected behavior explicit:

You can inspect the first response with curl. Quote the URL so the shell does not treat & as a command separator:

curl -sS -D - -o /dev/null --max-redirs 0 \
  'https://old.example/catalog?tag=a&tag=b&utm_source=email'

Check the status and Location header. To inspect the whole redirect chain, follow redirects and print the headers:

curl -sS -L -D - -o /dev/null \
  'https://old.example/catalog?tag=a&tag=b&utm_source=email'

The final response headers show the chain’s responses, but this command alone does not prove that the destination application used the parameters correctly. Open the final URL in a browser or test the relevant application behavior as well. If the site requires authentication or a particular method, reproduce that context safely; a public curl request may not represent it.

[Check a redirect with the Redirect Checker](Redirect Checker)

4. Check Query-String Edge Cases

Repeated parameters

Some applications treat repeated keys as a list; others use only the first or last value. A redirect or intermediary that collapses tag=a&tag=b into a single value can change behavior. Test duplicates if your application uses them.

Encoding and reserved characters

Characters such as &, =, +, %, and / can have special meaning in URLs. A value that contains one of these characters must be encoded correctly. Compare the actual Location value and then verify how the destination interprets it. Avoid manually decoding and re-encoding values unless the migration explicitly requires that transformation.

Parameter order and signatures

For many ordinary application URLs, parameter order does not affect meaning. Do not assume this for every integration: signed URLs and some legacy systems may depend on exact serialization. If a signature is involved, test the exact generated URL and confirm the receiving system’s requirements.

Fragments are different

A fragment such as #reviews is handled by the browser and is not sent to the server in the HTTP request. A server-side redirect therefore cannot inspect the incoming fragment in the same way it handles a query string. Test fragment behavior in the browser if it matters to navigation.

Redirect chains and loops

A URL may redirect more than once, and a later rule can alter or discard parameters even if the first redirect preserves them. Test the complete chain, reduce unnecessary hops where practical, and check that the destination does not redirect back to an earlier URL.

5. Review Redirect Rules Before Launch

For every rule or migration setting, confirm:

• Whether the original query string is retained, replaced, or discarded.
• Whether target parameters and incoming parameters are combined, and how duplicate names are handled.
• Whether values are encoded once or accidentally encoded more than once.
• Whether rule order sends the URL through an unexpected catch-all redirect.
• Whether redirects preserve the intended path as well as the query string.
• Whether the destination supports the parameters that are passed through.

Test the deployed rules in a staging environment when possible, then repeat the checks against production after launch. Staging may not use the same CDN, host configuration, or redirect service as production, so a staging pass is not a substitute for a production smoke test.

6. Monitor the Migration

After launch, check old URLs and new landing pages over time. Review server logs and analytics for unexpected redirect responses, traffic landing on the wrong page, missing campaign attribution, and application errors. In Search Console, monitor the relevant properties and reports for indexing or traffic changes, and use the current site-move guidance for the migration steps that apply to your situation.

A change in search traffic is not by itself proof that query parameters caused a problem. Compare affected URLs and dates, inspect their redirect chains, and distinguish tracking changes from changes to page content, canonicals, internal links, or indexing. Keep a record of the test URLs and results so that regressions can be reproduced.

Common Mistakes

• Assuming query strings are always preserved. Verify the behavior of the specific redirect implementation.
• Testing only one parameter. Include duplicates, empty values, encoded values, and multi-hop redirects where relevant.
• Preserving every parameter indiscriminately. Remove obsolete or sensitive values when there is no valid reason to forward them.
• Checking only the Location header. Confirm the final page’s application behavior too.
• Treating a staging test as production proof. Recheck the live redirect configuration after launch.
• Assuming fragments work like query parameters. Fragments are not included in the HTTP request sent to the server.

Best Practices

• Maintain a redirect map with source URL patterns, destination patterns, and parameter decisions.
• Base the test set on real traffic and critical user journeys, while including deliberate edge cases.
• Keep parameter handling explicit in redirect rules; document intentional drops and transformations.
• Avoid unnecessary redirect hops and test for loops.
• Make a post-launch owner responsible for reviewing redirect errors, analytics, and application reports.
• Consult current search-engine documentation before launch. I cannot live-check documentation revisions in this writing environment, so confirm that the linked guidance still reflects current recommendations for your migration.

Conclusion

To preserve query parameters during a website migration, inventory the URLs that matter, decide which values should survive or change, and test the complete redirect path with representative edge cases. Then verify the destination behavior and monitor the live site after launch.

References

• Google Search Central: Site moves with URL changes
• Google Search Central: Redirects and Google Search

These official pages are starting points for migration and redirect guidance. Their current contents were not live-checked for this article; review them before relying on version-sensitive or updated instructions.