Organize redirects by project

Projects are the top-level organizational unit in Redirections. Each project has its own set of redirect rules, analytics data, deployment history, and team access settings. When you create a project, you define its name, associated domains, and environment type (production, staging, or development).

Within a project, redirect rules are isolated from other projects. This means rule priority ordering, chain detection, and conflict validation all operate within the project scope. Two projects can have rules for the same source URL without conflict because they are evaluated independently.

The project dashboard provides a consolidated view of each project's health: active rules count, lookup volume over the last 24 hours, last deployment timestamp, and any active alerts. A project selector in the navigation bar lets you switch between projects instantly.

As redirect infrastructure grows, a flat list of rules becomes unmanageable. Projects bring structure by grouping related rules together with shared analytics, deployment pipelines, and access controls. The project model mirrors how most organizations think about their web properties — by domain, by team, or by environment.

Each project maintains its own deployment pipeline with independent staging and production states. You can deploy changes to one project without affecting others, and rollback is scoped to the individual project. This isolation prevents a bad deployment in one project from impacting redirect behavior elsewhere.

The overview dashboard aggregates metrics across all your projects, showing total lookups, rules, and deployment activity at a glance. You can quickly identify which projects are most active, which need attention, and which are dormant. Project-level analytics drill down into per-rule detail for focused investigation.