Публикация и домены

У каждого опубликованного microsite есть простая постоянная ссылка. Владелец может подключить собственный домен, сохранив работоспособность ранее отправленных ссылок.

Это принятое направление Bonsite. Раздел описывает целевое поведение и архитектуру; автоматическая выдача адресов и подключение клиентских доменов ещё требуют реализации. Публикация этой документации не означает, что сервис подключения доменов уже запущен.

Адреса платформы и клиентских сайтов

Клиентские сайты размещаются на отдельном регистрируемом домене. Маркетинговый сайт, кабинет и авторизация остаются на основном домене продукта.

Назначение	Пример адреса
Главная Bonsite	bonsite.ai
Кабинет владельца	app.bonsite.ai
Автоматический адрес microsite	k7m2x9p4.bonsite.site
Красивое имя — последующий этап	summer-offer.bonsite.site
Поддомен клиента	offer.company.com
Собственный корневой домен	myproduct.com

Все домены в таблице — примеры схемы. Их доступность, владение и окончательное название домена публикации не подтверждены.

На основном домене Bonsite не размещаем клиентские сайты по путям вроде /s/идентификатор. Вариант идентификатор.bonsite.ai также не используем как основной адрес клиентского контента: для него выделяем отдельный домен.

Постоянная ссылка

При первой публикации сайт получает случайный публичный идентификатор. Адрес вида k7m2x9p4.bonsite.site можно сразу скопировать и отправить в мессенджере, письме или рекламе.

• Идентификатор принадлежит сайту, а не версии его содержимого. Правки, новая публикация и откат не меняют адрес.
• Это случайный ID, а не хеш HTML, последовательный номер или часть URL после #.
• Длина и алфавит выбираются при реализации с проверкой уникальности. Восьмизначный пример выше не задаёт требование к длине.
• Страницы живут по обычным путям: k7m2x9p4.bonsite.site/about, /contact.
• После удаления сайта адрес не передаётся другому владельцу. Старые ссылки не должны неожиданно открыть чужой контент.
• В кабинете есть понятная кнопка «Скопировать ссылку».

Случайный адрес не делает сайт приватным. Ограниченный предпросмотр должен иметь отдельный контроль доступа — например, вход по приглашению или пароль. Приватный предпросмотр не публикуется по умолчанию.

Подключение своего домена

В разделе «Домены» владелец вводит адрес, который хочет использовать. Bonsite показывает необходимые DNS-записи, проверяет владение доменом и готовит HTTPS.

Путь подключения:

1. Владелец добавляет домен к конкретному microsite.
2. Bonsite выдаёт записи для подтверждения владения и маршрутизации трафика.
3. Владелец добавляет записи у своего DNS-провайдера.
4. Bonsite проверяет домен и ждёт готовности сертификата.
5. После успешных проверок адрес становится активным и может быть выбран основным.

В интерфейсе различаем состояния «Ожидаем подтверждение», «Настраиваем HTTPS», «Подключён» и «Нужны действия». Если проверка не прошла, показываем конкретную причину и следующий шаг. Пока собственный домен не готов, автоматическая ссылка продолжает работать.

Поддомены и www

Для offer.company.com и www.company.com основной сценарий — CNAME на адрес подключения Bonsite. Точное значение записи выдаётся в кабинете; пользователь не должен угадывать его по примеру документации.

Корневой домен

company.com тоже входит в целевую поддержку. Обычный CNAME в корне зоны поддерживается не всеми DNS-провайдерами. Нужны CNAME flattening/ALIAS либо отдельный механизм apex proxying.

Для первой реализации выбираем и проверяем поддерживаемый способ до того, как обещаем подключение любому DNS-провайдеру. Если прямое подключение корня недоступно, можно предложить www.company.com и HTTPS-перенаправление с корня у провайдера, который его поддерживает. Возможности и стоимость apex proxying проверяются отдельно. Документация Cloudflare.

Один основной адрес

Пока собственного домена нет, основным служит автоматический поддомен. После успешного подключения владелец может сделать собственный домен основным.

Тогда служебная ссылка отвечает постоянным перенаправлением 301 или 308 на основной адрес. Путь и параметры запроса сохраняются: ссылка на /contact?utm_source=email приводит на ту же страницу собственного домена. Неизвестные страницы возвращают корректный 404.

Canonical, sitemap, внутренние абсолютные ссылки и метаданные для превью в мессенджерах используют основной адрес. Так одна и та же публикация не живёт как несколько конкурирующих копий. Перенаправления и canonical помогают поисковикам определить предпочтительный URL. Документация Google.

При явном отключении собственного домена служебная ссылка снова становится основным адресом; перенаправление снимается. Удаляем привязку домена к сайту и соответствующую конфигурацию на стороне провайдера. Повторное подключение требует нового подтверждения владения. Кратковременный сбой домена не должен самовольно менять основную ссылку.

Изоляция и репутация

Отдельный домен публикации отделяет клиентский HTML и скрипты от кабинета Bonsite. Клиентские сайты не получают cookies авторизации платформы. Каждый microsite находится на собственном origin; служебные cookies не распространяются на общий родительский домен.

Поддомены сами по себе не обеспечивают полной изоляции cookies: атрибут Domain может распространить cookie на соседние поддомены. Поэтому авторизация кабинета не должна использовать общие cookies с клиентским контентом. Для публикаций также требуется отдельно проверить модель cookies, скриптов и встраиваемого предпросмотра между клиентскими сайтами. Документация MDN.

Отдельный домен не гарантирует защиту от SEO- или репутационных последствий злоупотреблений. Нужны возможность пожаловаться на сайт, блокировка фишинга и спама, ограничения массовых публикаций. Нельзя рассматривать поддомены как способ обхода правил поисковых систем. Рекомендации Google для платформ с пользовательским контентом.

Черновики и демо не индексируются. Для публичных публикаций индексирование — отдельная настройка; наличие короткой ссылки само по себе не означает согласия на появление в поиске. noindex не защищает доступ и не заменяет аутентификацию приватного предпросмотра.

Техническая схема

Приложение и хранилище публикаций могут оставаться на DigitalOcean. Для подключения доменов клиентов и управления сертификатами выбираем Cloudflare for SaaS как целевой механизм. Он маршрутизирует запросы с клиентских доменов на общий сервер платформы и управляет HTTPS. Документация Cloudflare.

Автоматический поддомен ─┐
                        ├─ HTTPS / Cloudflare → сервер публикаций → версия microsite
Собственный домен ───────┘

Кабинет Bonsite → настройки сайта, публикаций и подтверждённых доменов

Для собственных поддоменов домена публикации предусматриваем wildcard DNS и соответствующий HTTPS; клиентские домены регистрируются и проверяются отдельно. Один маршрутизатор определяет сайт по проверенной привязке hostname к site ID. Отдельный деплой приложения DigitalOcean на каждый microsite не требуется.

При реализации обязательны:

• Уникальная привязка нормализованного домена к одному сайту; владение подтверждается до активации.
• Неизвестный или удалённый hostname не открывает случайный сайт по умолчанию.
• Кеш разделён по домену, сайту и версии публикации: контент одного клиента не выдаётся другому.
• Публикация переключает активную версию целиком; предыдущая версия доступна для отката.
• Автоматическое продление сертификатов и понятная обработка ошибок DNS/HTTPS.
• Опубликованный сайт не зависит от доступности агента во время просмотра.

Выбор Cloudflare не означает, что интеграция уже подключена или подходит без проверки к текущей конфигурации DO. На этапе реализации проверяем origin, DNS, выпуск сертификатов, тарифные ограничения и весь путь на тестовом клиентском домене.

Объём первой версии

1. Автоматический постоянный адрес на отдельном домене публикации.
2. Копирование ссылки из кабинета.
3. Один собственный hostname на microsite с подтверждением владения.
4. Автоматический HTTPS и состояния подключения.
5. Выбор основного адреса, перенаправление и согласованные canonical/sitemap.
6. Безопасное отключение домена и снятие сайта с публикации.

Красивые имена, несколько доменных алиасов и управление большим числом доменов оставляем следующим этапам. Для пары company.com / www.company.com в первой версии подключаем один адрес, а перенаправление второго настраиваем отдельно.

Готовность подтверждается сквозной проверкой: опубликовать сайт, открыть короткую ссылку с телефона, подключить тестовый домен, проверить HTTPS и перенаправление вложенной страницы, обновить сайт без смены ссылки и отключить домен без передачи его другому владельцу.