Templates That Cover Most Cases

  • T1 — Domain redirect: entire domain → another URL. The classic case for parked domains, brand consolidation, ccTLD aliases.
  • T5 — Path redirect: path prefix → another path (e.g., /blog/* → /articles/*). Section moves, vendor migrations, archive relocations.
  • T6 — Exact URL redirect: one specific URL → one specific target. Vanity URLs, individual page moves, fixes after a publish accident.
  • T7 — Maintenance mode: temporary 302 to a holding page. Use during deploys and migrations; the 302 status means search engines do not re-rank.
  • T3/T4 — apex ↔ www canonical: auto-applied when you mark a host. T4 (www → apex) is the modern default; T3 (apex → www) is the legacy variant. The drawer flags which is which.

How to Create a Redirect

  1. Open Redirects. Filter by project or site if your account has multiple — keeps the dropdowns short.
  2. Click Add redirect and select a site. The primary domain (where traffic lands) is inherited from the site.
  3. Pick a template (T1/T5/T6/T7), fill in the source domain or path and the target URL. The form validates that the source domain is in the right role.
  4. Save. The rule lives in 301.st with a Pending status. Click Sync on the row — or Sync all from the table header — to push to Cloudflare.

Why Sync Is a Separate Step

  • Edits stay local until you sync. You see a diff against what Cloudflare currently has, so nothing reaches production by accident.
  • Sync state per row: Synced, Pending (local edit not yet applied), Error (Cloudflare rejected — check the row for the reason), Not synced (rule exists in 301.st but never pushed).
  • "Sync all" batches every pending change in one operation. For agencies migrating 50+ rules at once, that is the difference between a 5-minute task and a 30-minute one.

How Redirects Connect to the Stack

  • Integrations: Cloudflare connection is required — redirects sync through it. Without it, the Sync button is inert.
  • Domains: source domains come from the synced inventory. The source role is enforced; the table only shows eligible domains.
  • Projects and sites: every redirect lives under a site, which lives under a project. Filter by either to scope what you are looking at.
  • Table actions: search by source/target, filter by sync status and enabled/disabled, bulk enable, disable, delete, or sync the selection. Project and site are pickers above the table, not filters: they choose WHICH redirects load, rather than narrowing what is already on screen.

Table Features

The redirect table shows source domain, target URL, status, sync state, and an enabled toggle per row. Inline edits open the drawer with the rule pre-loaded — no full-page navigation.

Bulk operations work on row selection: bulk enable/disable for instant traffic gating, bulk delete for cleanup, bulk sync for shipping batches of pending changes. T7 maintenance mode is the recommended way to gate traffic during deploys — toggle on, sync, deploy, toggle off, sync.

FAQ

Should I use Redirects or TDS?

Redirects for unconditional URL → URL moves (domain parking, path moves, maintenance). TDS when the rule depends on the request itself — geo, device, bot status, UTM parameters, or A/B testing weight. Start with Redirects; layer TDS in when a use case actually needs the condition.

Do redirects require projects and sites?

A site with a primary domain (where traffic lands) — and you have one already: every account is created with a "Default Workspace" project and a "Default" site, so only the domain is yours to point at it. A SECOND project is what becomes useful past a handful of redirects, when filtering and bulk actions start to matter.

What happens if Cloudflare sync fails?

The row keeps your local edit and shows an Error status with the Cloudflare-side reason. Common causes: token scope missing Workers:Edit, target domain not in the correct zone, or the donor was deleted on Cloudflare-side. Fix the cause, click Sync again — nothing is lost.

Related Guides