When the Flat List Stops Working

For a one-brand operator with 10 domains, a flat list works fine — every redirect, every TDS rule, every postback source is already in one place. The Domain table filter is enough.

Past 20+ domains, multiple clients, or separate environments (prod vs staging), the flat list turns into noise: dropdowns get long, audit trails blur across brands, and the wrong domain assignment becomes easy to make. Projects and sites are the seam that fixes this without forcing premature structure.

Projects

  • One project per client, brand, vertical, or environment — whatever boundary matters for billing, isolation, or reporting. Each project shows its domain count, site count, and TDS rule count at a glance.
  • Fields: name (required), description, brand tag, commercial terms, start/end dates. The commercial fields exist for agencies tracking client engagements; ignore them if you do not need them.
  • Used as a filter key everywhere: Domains, Redirects, TDS, Postbacks. Scope a bulk action to one project and the rest of the account stays untouched.

Sites

  • Attach destinations or site-level context to the project that owns them.
  • Fields: name (required), tag, acceptor domain, site locale (BCP 47 — useful when one operator runs multilingual landings). Status: Active, Paused, or Archived.
  • Donor domains attach to the site as redirect sources. The role check is enforced: a domain assigned as acceptor cannot also be a donor for the same flow, which catches a class of misconfiguration at form time.

Practical Setup

  1. Sync domains first (Cloudflare integration → Domains). Projects and sites read from the synced inventory.
  2. Create one project per logical boundary — usually one client, brand, or production environment.
  3. Inside the project, create a site per acceptor domain (where redirected traffic lands). Most projects have 1–3 sites.
  4. Attach donor domains to the project and to specific sites. Then create redirects and TDS rules — both are scoped to the site, so dropdowns stay short.

When to Stay Flat

Fewer than 10 domains and a single use case? Skip projects entirely. Create redirects directly against synced domains; the panel is designed to let you do that.

Layer structure on when the flat list stops being scannable — usually around 20+ domains or when the same dropdown starts mixing your own brands with a client's. Adding projects later is non-destructive; existing redirects keep working while you re-organize.

FAQ

Do I need a project per domain?

No. One project typically holds dozens of domains. The right granularity is "what would you want to scope a bulk action to" — usually a client, brand, or vertical, not a single domain.

What is an acceptor domain?

Only when explicit destination structure helps. Sites are valuable when they make routing easier to understand, not when they add ceremony.

Can I move a domain between projects later?

Yes. The Domains table has a bulk "Assign to project" action; the new project picks up the domain and any site it was attached to follows through. The acceptor role is preserved.

Related Guides