Configure domain forwarding by deciding exactly which hostname, path and query should reach which destination. Then choose the redirect status and test HTTP and HTTPS requests separately. Keep the initial rule as a draft while reviewing its scope; a destination that looks right for the homepage may still mishandle deeper links.
Write a short forwarding specification before opening the dashboard. State whether the entire old site is moving, only one hostname is changing or selected paths need new destinations. Include an example that must redirect and another that must remain untouched. This makes it easier to spot an overbroad rule before it becomes a live change.
Which incoming requests should the rule match?
Cloudflare Redirect Rules can match a wildcard URL pattern. A redirect rule can instead apply to all incoming requests. Cloudflare also permits a custom filter expression for redirect matching. The dashboard instructions describe distinct matching choices. Select the one that expresses the intended scope clearly. An all-traffic rule is a strong choice only when every incoming request covered by that configuration really should have the same forwarding treatment.
For a hostname move, list the exact old hostname and whether an alternate hostname is included. Write the HTTP and HTTPS forms explicitly in the test sheet. If deeper paths should be preserved, include a realistic example such as a product guide, rather than judging the rule only from the domain root.
A hostname match may prompt the creation of a proxied DNS record. Treat the documented DNS prompt as an additional configuration question, not permission to replace a domain’s entire DNS setup. Identify the affected hostname and compare the proposed record with the existing configuration before an authorised change. Keep unrelated web, mail and verification records outside the forwarding edit.
How should the destination and redirect status be chosen?
Cloudflare static redirects use a literal target URL in the Location response header. Cloudflare dynamic redirects determine the target URL through an expression. The Single Redirects settings distinguish a fixed destination from a calculated one. Choose a fixed target for a deliberate one-to-one mapping. Where paths must carry across, request the exact expression and compare its result with several representative URLs before deployment.
Cloudflare documents 301 as a permanent redirect that may change POST to GET. This documented method behaviour matters when a request is more than a normal page visit. Include form submissions or other method-sensitive routes in the planning discussion. Do not assume every request should be forwarded in the same way as a public information page.
Cloudflare documents 308 as permanent while requiring preservation of the original request method. That statement describes the 308 behaviour in Cloudflare’s settings documentation. The appropriate status still depends on the intended move and the destination’s supported behaviour. Ask the application owner to approve any method-sensitive case. A status choice is part of the forwarding contract, not merely a technical preference.
| Test input | Required decision | Evidence to capture |
|---|---|---|
| Old homepage over HTTP | Intended destination and scheme | Initial response and final URL |
| Old homepage over HTTPS | Secure request path works | Browser result and response chain |
| Existing deep path | Preserve, map or deliberately replace path | Location value and destination page |
| URL with query parameters | Preserve or remove the query | Resulting target URL |
| Unrelated hostname or path | Match or leave untouched | Observed rule boundary |
| Method-sensitive request | Approved status and method behaviour | Test request and destination response |
What happens to the query string and HTTPS request?
Cloudflare redirect query-string preservation is disabled by default. Decide the query policy explicitly. A parameter may identify a useful campaign or may contain information that should not be carried to the destination. Use fictional, non-sensitive examples during testing. Record the intended behaviour on the acceptance grid rather than accepting whichever result the default produces.
For HTTPS, test the complete visitor request to the old hostname as well as the final destination. Record any connection or certificate error before interpreting the redirect result. A correct target written in a rule is not proof that a visitor can reach that rule through the intended secure hostname.
Inspect the redirect chain rather than only the final address bar. Write down each observed hop and ask whether it is intentional. If the destination points back to the old site or another rule sends it there, keep the configuration unresolved until the loop is explained. Avoid adding a second speculative rule to mask an unclear first one.
Original forwarding worksheet: preserve a guide path deliberately
This hypothetical example moves a fictional public library from old.example to new.example. The proposed requirement is to preserve existing guide paths and approved query parameters. The root should reach the new homepage, while an unrelated test hostname remains outside the rule. These are acceptance criteria for this exercise, not universal redirect recommendations.
Mapping row. Write the source homepage and its intended destination. Then add a guide URL with a nested path and a fictional query parameter. For each row, calculate the expected target as text before configuring the rule. The reviewer should be able to compare the intended and observed addresses character by character.
Matching row. Describe the chosen incoming-request condition in plain language. Identify the hostname, scheme and path pattern it covers. Add a negative example that must not match. Ask a second person to explain the rule’s scope using the worksheet; disagreement here is a reason to revise the draft rather than proceed.
Target row. Record whether the target is literal or expression-based. Where wildcard captures or expressions are used, identify which input portion supplies each output portion. Test a path with more than one segment. A rule can look convincing on a short example while placing captured text into the wrong position for a deeper URL.
Query row. Enter a harmless parameter such as a fictional campaign label. Record whether it should remain, disappear or be handled by a separate requirement. Inspect the actual Location response after an authorised test. Do not use real account tokens or personal details simply to make the example look realistic.
Status row. Write the reason for a permanent or temporary choice and identify any request method requirement. Have the site owner approve the intended behaviour. If a form or application endpoint is involved, test it in a suitable controlled environment with its application owner, rather than submitting real data through a new forwarding rule.
Boundary row. Test the unrelated example and the destination hostname itself. Confirm that the rule does not accidentally catch its own output. Record the observed chain and the final content. A clean homepage redirect is only one row of the exercise, not evidence that every old URL has been considered.
How should a reviewed rule become an operational change?
The dashboard supports saving a redirect rule as a draft. Use the draft option while reviewing the mapping and scope. Retain the previous relevant configuration, name the change owner and agree a recovery step before an authorised deployment. Keep the forwarding change separate from unrelated DNS or application work so its effect can be assessed clearly.
After activation, repeat the worksheet’s representative requests and retain the result. Ask the content owner to inspect the destination pages as well as the status codes. A technically valid redirect to an irrelevant page may fail the user’s original purpose even when the response chain contains no obvious error.
For the wider domain context, see domain requirements and website hosting. To discuss a forwarding brief, get started with the mapping grid, query policy and method-sensitive exceptions. That makes the intended behaviour concrete before anyone changes the live domain.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.