Redirect Rules
How to create rules, match URL patterns, proxy external content, and bulk import via CSV.
Rule types
Every rule maps an incoming path on your domain to a destination URL. Rules are matched in priority order: exact match first, then wildcard, then named parameters, then catch-all.
/old-page → https://example.com/new-pageMatches only the exact path specified. The fastest and most predictable rule type. Use this for individual page redirects.
/blog/* → https://example.com/postsMatches any path that starts with the prefix. The * matches one or more path segments. For redirect rules, the matched suffix is discarded. To carry it through to the destination, include * in the destination URL — see Reverse proxy rules below for the Plausible example.
/posts/[slug] → https://example.com/articles/[slug]Matches a path segment and substitutes its value into the destination. Use this when the URL structure changes but the slug or ID stays the same.
(no source path) → https://example.comMatches any request that has no other matching rule. Set by leaving the source path blank. Useful for full domain redirects.
Reverse proxy rules
Set the rule type to Proxy (200) to fetch the destination and stream its response back to the visitor — without changing the URL in their browser. Unlike a 301 or 302, no redirect is issued. The visitor stays on your domain. The upstream server is invisible.
- 1. Request hits your domain
- 2. Browser receives redirect
- 3. Browser navigates to destination
- URL bar changes
- 1. Request hits your domain
- 2. Edge fetches destination
- 3. Response streamed back
- URL bar stays the same
Wildcard proxy — the Plausible pattern
The most common use case is proxying an analytics script through your own domain so ad blockers cannot target the upstream hostname. Plausible, Fathom, and Umami all recommend this approach in their own docs.
When you include * in the destination URL of a proxy rule, the matched wildcard suffix is substituted in. This lets you mirror an entire path namespace through your domain.
Then update your Plausible snippet to use data-domain pointing to your domain and src pointing to /plausible/js/script.js. Ad blockers that target plausible.io will never see the request.
In redirectiq.json
Proxy rules are fully supported in file sync. Set "type": "proxy" in your redirectiq.json:
{
"version": 1,
"redirects": [
{ "from": "/plausible/*", "to": "https://plausible.io/*", "type": "proxy" }
]
}Rules & limits
Pattern matching
Wildcard ( * )
A * at the end of a source path matches any continuation of that path. It does not capture the matched value for use in the destination — use named parameters if you need to carry the value through.
Match priority order
- 1
Exact match — /old-page - 2
Wildcard — /blog/* - 3
Named parameter — /posts/[slug] - 4
Catch-all — (blank source path)
Named parameter capture
Named parameters let you capture a URL segment and substitute it into the destination. This is the right tool when your URL structure changes but IDs, slugs, or other values stay the same — common in CMS migrations and domain rebrands.
Single parameter — [param]
Matches exactly one path segment (no slashes). The captured value is substituted wherever [param] appears in the destination.
Multiple parameters
Use multiple named segments to capture and rearrange URL structure.
Spread parameter — [...rest]
Matches the rest of the path including slashes. Use when the path structure after a prefix changes completely.
Note: [param] matches exactly one segment with no slashes. If you need to match multiple segments, use [...rest] or a wildcard rule.
Path & query passthrough
Two optional toggles control how the request path and query string are forwarded.
Preserve path
Appends the full incoming request path to the destination URL. Useful for catch-all rules where you want to mirror the path structure on the new domain.
Preserve query
Appends the incoming query string to the destination URL. Useful when visitors arrive with UTM parameters or search queries that should carry through to the new location.
Bulk CSV import
Import hundreds of redirect rules at once from a CSV file. All rule types are supported — exact paths, wildcards, named parameters, and catch-alls can all be defined in CSV. This is the fastest way to migrate from Cloudflare Page Rules, .htaccess, Nginx configs, or another redirect management tool.
Full bulk import reference — format, validation, Excel tips, migration guides →Migrating from Cloudflare Page Rules?
Cloudflare Page Rules are deprecated. If you were using Page Rules for URL forwarding, export your rules from the Cloudflare dashboard and convert them to the CSV format below. Most Page Rules forwarding patterns map directly — see our Cloudflare migration guide for a field-by-field comparison.
CSV format reference
Columns
| Column | Required | Description |
|---|---|---|
| source_path | Yes | Path to match. Must start with /. Leave blank for catch-all. |
| destination | Yes | Full destination URL including https://. |
| type | No | 301, 302, or proxy. Defaults to 301 if omitted. |
Example CSV
source_path,destination,type /old-page,https://newsite.com/new-page,301 /blog/*,https://newsite.com/posts,301 /posts/[slug],https://newsite.com/articles/[slug],301 /old-section/[...rest],https://newsite.com/new-section/[...rest],301 /plausible/*,https://plausible.io/*,proxy ,https://newsite.com,301
The last row (blank source_path) creates a catch-all rule.
Rules & limits
Plan limits
| Plan | Rules per domain | CSV import |
|---|---|---|
| Hobby (free) | 100 | Up to 100 (plan limit applies) |
| Pro | Unlimited | Up to 500 rows per file |
| Agency | Unlimited | Up to 500 rows per file (split large sets across files) |
Have questions not covered here?
Contact us →