Проекты и сайты
Опциональные контейнеры, отражающие то, как организован ваш бизнес. Проекты — для изоляции работы по клиенту или бренду; сайты — для объявления целей редиректов и привязки TDS-правил к конкретной Cloudflare-зоне.
Когда плоский список перестаёт работать
Для оператора с одним брендом и 10 доменами плоский список работает нормально — каждый редирект, каждое TDS-правило, каждый источник постбэков уже на виду. Фильтра в таблице доменов достаточно.
Дальше 20+ доменов, нескольких клиентов или раздельных окружений (prod vs staging) плоский список превращается в шум: выпадайки удлиняются, аудит-логи смешиваются между брендами, а неверное назначение домена становится лёгкой ошибкой. Проекты и сайты — шов, который это лечит, не навязывая преждевременной структуры.
Проекты
- По одному проекту на клиента, бренд, вертикаль или окружение — любая граница, важная для биллинга, изоляции или отчётности. Каждый проект показывает количество доменов, сайтов и TDS-правил с одного взгляда.
- Поля: название (обязательно), описание, бренд-тег, коммерческие условия, даты начала и окончания. Коммерческие поля — для агентств, отслеживающих клиентские контракты; игнорируйте, если не нужны.
- Используются как ключ фильтрации повсюду: Домены, Редиректы, TDS, Постбэки. Ограничьте bulk-действие одним проектом — остальной аккаунт остаётся нетронутым.
Сайты
- Сайт живёт внутри проекта, объявляет акцепторный домен (цель редиректа) и становится якорем для редиректов и TDS-правил, разворачиваемых на Cloudflare Worker этого домена.
- Поля: название (обязательно), тег, акцепторный домен, локаль сайта (BCP 47 — полезно, когда один оператор ведёт мультиязычные лендинги). Статус: Active, Paused или Archived.
- Домены-доноры привязываются к сайту как источники редиректов. Проверка роли работает: домен, назначенный акцептором, не может одновременно быть донором в том же потоке — это ловит класс ошибок в момент формы.
Практическая настройка
- Сначала синхронизируйте домены (Интеграция Cloudflare → Домены). Проекты и сайты читают из синхронизированного инвентаря.
- Создайте по одному проекту на логическую границу — обычно по одному клиенту, бренду или продакшн-окружению.
- Внутри проекта создайте по сайту на каждый акцепторный домен (куда приземляется перенаправленный трафик). У большинства проектов 1–3 сайта.
- Привяжите домены-доноры к проекту и к конкретным сайтам. Затем создавайте редиректы и TDS-правила — обе сущности привязываются к сайту, поэтому выпадайки остаются короткими.
Когда этот слой можно пропустить
Меньше 10 доменов и единственный юзкейс? Пропустите проекты вообще. Создавайте редиректы прямо против синхронизированных доменов — панель так и спроектирована.
Накладывайте структуру, когда плоский список перестал быть скан-руемым, — обычно около 20+ доменов или когда одна выпадайка начинает смешивать ваши бренды с клиентскими. Добавление проектов задним числом не разрушающее; существующие редиректы продолжают работать, пока вы переорганизуете.
FAQ
Нужен ли проект на каждый домен?
Нет. Один проект обычно держит десятки доменов. Правильная гранулярность — «к чему вы захотите ограничить bulk-действие»: обычно клиент, бренд или вертикаль, не отдельный домен.
Что такое акцепторный домен?
Домен, на котором перенаправленный трафик приземляется. Если example.com → landing.com, то landing.com — акцептор. Акцепторные домены также хостят Cloudflare Worker, исполняющий TDS-правила и обслуживающий postback-URL, поэтому одно определение сайта питает все три поверхности.
Можно ли позже перенести домен между проектами?
Да. В таблице Доменов есть bulk-действие «Привязать к проекту»; новый проект подхватывает домен, и любой сайт, к которому он был привязан, переходит за ним. Роль акцептора сохраняется.