Миграция с Rebrandly: перенос брендированного домена без потери слаг-параметров

Rebrandly построен вокруг одной центральной абстракции: брендированного домена. Slashtag-и, таксономии тегов и правила Traffic Routing - все это находится под ним. Этот выбор дизайна делает Rebrandly целостным продуктом, и именно поэтому миграция с него отличается от перехода с любого другого сервиса сокращения ссылок.

Когда вы уходите из Rebrandly, вы в первую очередь переносите не ссылки. Вы переносите домен. Ссылки следуют за ним, и детали того, как вы их сохраните, почти полностью зависят от того, что вы решите делать с доменом.

В этом посте рассматриваются два реалистичных пути, формат экспорта из API Rebrandly, вызов массового импорта в Elido и процесс валидации перед объявлением о завершении переноса.

TL;DR#

• Основная абстракция Rebrandly - брендированный домен. Миграция - это в первую очередь перенос DNS, и во вторую - сохранение ссылок.
• Путь А: домен остается прежним, меняется только сервис сокращения. Предварительно настройте слаги в Elido, переключите CNAME, готово.
• Путь Б: домен тоже меняется. Вам понадобится либо цепочка 301 редиректов со старого домена (тариф Rebrandly Pro), либо вы принимаете изменение слагов на новом домене.
• Теги Rebrandly чисто сопоставляются с тегами Elido. Категории Rebrandly требуют ручного сопоставления - у них нет прямого эквивалента.

Что нужно проинвентаризировать в первую очередь#

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

Брендированный домен или домены. Модель воркспейсов Rebrandly позволяет использовать несколько кастомных доменов в одной учетной записи. В агентском или мультибрендовом воркспейсе каждый домен является отдельной единицей миграции. Перечислите их перед планированием окон переключения - один домен за ночь - более безопасный график, чем все сразу.

Активные ссылки. Для больших списков используйте Rebrandly REST API (по состоянию на 12.05.2026), а не экспорт в CSV. Эндпоинт /v1/links поддерживает пагинацию с параметрами last и limit и возвращает полный объект ссылки, включая slashtag, пункт назначения, имя домена, набор тегов и createdAt. Экспорт в CSV из панели настроек воркспейса подходит для менее чем нескольких сотен ссылок, но на больших объемах он непоследовательно обрезает поля.

Интеграции. Если ваша команда создает ссылки через воркфлоу Zapier, Make или Workato, эти коннекторы указывают на API Rebrandly. Каждому из них требуется перенастройка. Это отдельная задача от миграции ссылок со своим льготным периодом. Займитесь этим после переключения DNS, а не до него.

Таксономия тегов и категорий. Rebrandly поддерживает как свободные теги, так и структурированные категории. Теги сопоставляются с тегами Elido один к одному. У категорий нет прямого эквивалента в Elido - ближайшим вариантом является зарезервированный префикс тега (cat:campaign, cat:region), который вы применяете во время импорта. Согласуйте сопоставление до запуска скрипта, а не после.

Путь А: домен остается, сервис сокращения меняется#

Это более чистая миграция. Вы сохраняете go.acme.com (или любой другой ваш короткий брендированный домен). Вы предварительно создаете каждый слаг в Elido под тем же доменом, а затем переключаете CNAME. С точки зрения клика по ссылке ничего не меняется - слаг разрешается в тот же URL назначения, просто через другой edge.

Шаг 1: экспорт из Rebrandly#

Пройдитесь по Rebrandly /v1/links API с пагинацией. Объекты ответа включают slashtag, destination, domain.fullName, tags[], category.name и createdAt. Сохраните как JSONL.

Две вещи, с которыми нужно обращаться осторожно. Во-первых, domain.fullName - если в вашем воркспейсе более одного домена, отфильтруйте тот, который вы переносите в этот проход. Во-вторых, тарифные планы Rebrandly (по состоянию на 12.05.2026) ограничивают количество активных ссылок и кастомных доменов на одну учетную запись. API возвращает все ссылки независимо от этого; в ваш инвентарь могут попасть ссылки на уже удаленные домены. Отфильтруйте их перед импортом.

Шаг 2: предварительная настройка в Elido#

Зарегистрируйте домен в вашем воркспейсе Elido через процесс кастомных доменов, прежде чем трогать DNS. Домену не обязательно быть активным. Elido подтверждает владение доменом через TXT-запись DNS; вы можете завершить это, не нарушая работу существующей записи CNAME, указывающей на Rebrandly.

Как только домен будет зарегистрирован, выполните массовый импорт ссылок. Эндпоинт POST /v1/links/bulk принимает до 100 ссылок за вызов и возвращает статус успеха/ошибки для каждого элемента, поэтому конфликт слага в одной строке не прерывает всю партию. Явно передавайте slug, чтобы сохранить slashtag из Rebrandly. Сопоставляйте tags[] из Rebrandly напрямую с tags[] в Elido. Передавайте created_at, чтобы сохранить исходную метку времени создания для исторической сортировки.

curl -X POST "https://api.elido.app/v1/links/bulk" \
  -H "Authorization: Bearer $ELIDO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: rebrandly-migration-batch-001" \
  -d '{
    "workspace_id": "ws_xxxxxxxxxxxx",
    "domain_id": "dom_xxxxxxxxxxxx",
    "links": [
      {
        "slug": "summer-promo",
        "destination_url": "https://acme.example/summer",
        "tags": ["campaign", "q3", "rebrandly-migrated"],
        "created_at": "2025-07-01T09:00:00Z"
      },
      {
        "slug": "hero-cta",
        "destination_url": "https://acme.example/hero",
        "tags": ["homepage", "rebrandly-migrated"],
        "created_at": "2025-03-15T14:30:00Z"
      }
    ]
  }'

Тег rebrandly-migrated полезен для фильтрации аналитики после переключения - вы сможете сегментировать ссылки, созданные до миграции, от ссылок, созданных нативно в Elido, и сравнивать тренды кликов за первые 30 дней.

Для сопоставления таксономии категорий: если summer-promo находился в категории Rebrandly под названием Campaigns, добавьте cat:campaigns в массив tags. Это не семантически эквивалентно, но дает вам фильтр в аналитике и дашбордах Elido. Задокументируйте сопоставление в своих заметках о миграции.

Сначала проведите пробный запуск. Большинство команд запускают массовый импорт в тестовом воркспейсе или на небольшой выборке (10-20 ссылок), прежде чем отправлять весь инвентарь. Статус каждого элемента в ответе эндпоинта массового импорта четко покажет любые конфликты слагов или ошибки валидации назначения до того, как вы зафиксируете весь экспорт.

Шаг 3: переключение DNS#

Настал момент. Прежде чем приступить, проверьте следующее:

• Все слаги при массовом импорте вернули статус успеха. Нет нерешенных ошибок.
• Домен зарегистрирован, и TLS настроен в вашем воркспейсе Elido. Протестируйте один слаг напрямую через edge Elido, временно добавив CNAME для тестового поддомена, а не для основного.
• TTL существующей записи CNAME Rebrandly был снижен. Страница цен Rebrandly (по состоянию на 12.05.2026) показывает, что конфигурация DNS доступна начиная с тарифа Free - вы можете снизить TTL без апгрейда. Снизьте его как минимум до 300 секунд за 24 часа до окна переключения.

Когда откроется окно, замените цель CNAME:

go.acme.com.  300  IN  CNAME  edge.elido.me.

Edge Elido использует автоматический TLS по запросу. Если TLS уже был настроен во время предварительной проверки (рекомендуется), первый запрос после распространения DNS будет быстрым. Если нет, сертификат выдается при первом запросе - обычно это занимает 1-3 секунды, затем сертификат кэшируется, и последующие запросы обслуживаются менее чем за 15 мс (p95) из edge в регионе ЕС.

Перед закрытием окна изменений выполните проверку с нескольких резолверов. Проверка распространения только с вашего рабочего места подтверждает только ваш резолвер. Инструменты вроде dig @8.8.8.8 go.acme.com CNAME и dig @1.1.1.1 go.acme.com CNAME позволяют отловить распространенные расхождения.

Путь Б: домен тоже меняется#

Некоторые команды используют миграцию как возможность переименовать брендированный домен - с brand.ly (поддомен, назначенный Rebrandly) на что-то, чем они полностью владеют, или с одного брендового домена на другой после ребрендинга. Другие использовали поддомен Rebrandly (yourname.rebrandly.com) и никогда не настраивали кастомный домен.

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

Вариант Б1: цепочка 301 редиректов со старого домена Rebrandly#

Функция Traffic Routing в Rebrandly - доступная на тарифе Pro - позволяет перенаправлять весь домен на новый базовый URL. Если вы владеете старым доменом и хотите перенаправлять трафик, вы можете настроить в Rebrandly wildcard-редирект, который будет пересылать все запросы go.old-domain.com/* на go.new-domain.com/* с сопоставлением слагов.

RFC 7231 §6.4.2 определяет семантику 301 Moved Permanently: клиенты, получившие 301, должны обновить любой сохраненный URL на новый адрес. На практике это означает, что существующие QR-коды, печатные материалы и опубликованные ссылки будут корректно перенаправляться в течение периода перекрытия. Это максимально приближенный к прозрачной миграции вариант при смене домена.

Механика: оставьте старый домен активным на Rebrandly в течение периода перекрытия, настроив его как транзитный редиректор. Запустите новый домен на Elido с первого дня миграции. Через 30-90 дней (в зависимости от того, как долго ваши опубликованные материалы остаются в обращении) выведите старый домен из эксплуатации на Rebrandly.

Вариант Б2: принять изменение слага#

Если старым доменом был поддомен, назначенный Rebrandly (yourname.rebrandly.com), или домен, над DNS которого у вас больше нет контроля, цепочка 301 редиректов недоступна. Ссылки на старом домене будут продолжать работать до тех пор, пока работает Rebrandly и вы поддерживаете учетную запись активной. Трафик по этим старым ссылкам не проходит через Elido; вы теряете охват аналитики по нему.

Практический подход: перенесите список ссылок в Elido на новом домене, создайте новые слаги для наиболее посещаемых ссылок и обновите важные опубликованные поверхности, а длинному хвосту малопосещаемых старых ссылок позвольте постепенно отмирать на Rebrandly. Руководство по миграции с Bitly охватывает ту же схему принятия решений для миграции с Bitly - эти рассуждения применимы и здесь.

Для команд, выбирающих между вариантами Б1 и Б2, расчет таков: сколько опубликованных поверхностей содержат старые ссылки, насколько сложно их обновить и как долго трафик будет продолжать поступать на эти поверхности. Ссылки в архивах рассылок с высоким трафиком и печатные материалы говорят в пользу Б1. Несколько внутренних документов говорят в пользу Б2.

Экспорт из Rebrandly: что вы получаете, а что нет#

Rebrandly API (по состоянию на 12.05.2026) экспортирует следующие поля для каждой ссылки через /v1/links:

• id - внутренний ID ссылки Rebrandly (не нужен при импорте, но полезен в качестве ключа идемпотентности)
• slashtag - слаг для сохранения
• destination - полный URL назначения, включая UTM-параметры
• domain.fullName - имя хоста кастомного домена
• tags[] - свободные теги; сопоставляются напрямую с тегами Elido
• category.name - метка категории; сопоставьте с префиксом тега вручную
• createdAt, updatedAt - метки времени; передайте createdAt в поле created_at в Elido
• clicks.total - общее количество кликов за все время; нельзя импортировать в аналитику Elido, но стоит сохранить в теге (clicks-baseline-1234) или в вашем собственном слое данных

Что API не экспортирует:

• Сырые события кликов. Rebrandly не предоставляет записи по каждому клику - вы получаете только агрегированные данные. Отсчет аналитики в Elido начинается с нуля с дня переключения.
• Правила Traffic Routing. Если вы настроили условные редиректы для каких-либо ссылок (маршрутизация по устройствам или геопозиции), эти правила необходимо воссоздать вручную в редакторе смарт-ссылок Elido после импорта. Массового импорта правил маршрутизации не существует.
• Разрешения членов команды. Доступ к воркспейсу нужно будет настроить заново через приглашения в Elido.

Отсутствие сырых событий кликов - это то же ограничение, с которым вы сталкиваетесь при миграции с Bitly без поломки ссылок. Схема работы с этим такая же: сохраните пожизненный счетчик Rebrandly, отслеживайте клики в Elido с момента переключения и объединяйте их при подготовке отчетов по историческим итогам.

Перенастройка вебхуков: Zapier, Make, Workato#

Если какие-либо из ваших воркфлоу автоматизации создают ссылки Rebrandly, их нужно перенаправить: триггер CRM, который выпускает ссылку отслеживания для каждого потенциального клиента, Zap, который сокращает ссылки из электронной таблицы, или сценарий Make, генерирующий QR-коды для мероприятий.

Механизм различается в зависимости от платформы. В Zapier найдите каждый Zap, использующий приложение Rebrandly, и замените шаг действия на приложение Elido для Zapier (проверьте доступность при запуске) или на действие Webhook, которое вызывает POST /v1/links напрямую. В Make и Workato применяется та же замена.

Здесь нужно правильно спланировать последовательность двух вещей. Во-первых, не перенаправляйте автоматизации до тех пор, пока не будет подтверждено переключение DNS и массовый импорт. Запуск автоматизаций в Elido до завершения предварительной настройки создаст конфликты дубликатов слагов. Во-вторых, заранее добавьте API-ключ Elido в хранилище учетных данных каждой платформы автоматизации - сделайте это заблаговременно, а не во время окна переключения.

Льготный период: для любой автоматизации, создающей ссылки с низкой частотой (несколько в неделю), оставление ее на Rebrandly в течение 1-2 недель после переключения DNS сопряжено с низким риском. Ссылки, которые она создает, будут на старой платформе, но DNS уже переключен, поэтому эти ссылки будут разрешаться через Elido. Для высокочастотной автоматизации, создающей десятки ссылок в день, выполните миграцию в день переключения.

Информацию об API Elido и доступных SDK можно найти на странице цен, где указаны лимиты планов, а полный справочник по API находится в разделе /help. Доступны SDK для TypeScript, Python и Go.

Валидация перед объявлением о переключении#

Не объявляйте о завершении миграции, пока не проведете структурированную выборочную проверку. Две вещи могут сломаться незаметно: URL назначения, у которых были проблемы с кодировкой при экспорте, и слаги, которые столкнулись с конфликтами во время массового импорта и были пропущены.

Проверка топ-100 слагов#

Отсортируйте экспортированный список ссылок по убыванию clicks.total. Возьмите первую сотню. Для каждой из них отправьте HEAD-запрос к URL, размещенному на Elido, и убедитесь, что заголовок Location соответствует ожидаемому назначению:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
  "https://go.acme.com/summer-promo"

Ответ 301 с правильным URL назначения подтверждает, что слаг работает. 404 означает, что либо слаг не был предварительно настроен (проверьте лог ответов массового импорта), либо возникло несовпадение регистра. Slashtag-и Rebrandly нечувствительны к регистру при разрешении; слаги Elido чувствительны к регистру при создании. Если в вашем экспорте есть slashtag-и в разном регистре, приведите их к нижнему регистре перед импортом.

План отката на 30 дней#

Поддерживайте учетную запись Rebrandly активной в течение 30 дней после переключения DNS. Изменение DNS полностью обратимо в любой момент в течение этого окна - направьте CNAME обратно на edge Rebrandly, и старые ссылки снова заработают. Через 30 дней, если аналитика не показывает аномалий в проценте успешных редиректов и проверка слагов прошла успешно, учетную запись Rebrandly можно безопасно понизить в тарифе или закрыть.

Что касается домена: не переносите регистратора домена в другое место во время окна миграции. Изменение CNAME - единственная необходимая операция с DNS. Перенос регистратора добавляет риск задержки распространения, который не нужен во время переключения.

Внутренний контекст миграции#

Механика этой миграции параллельна стратегии миграции с Bitly. Паттерны DNS, тайминг TTL и подход к сохранению слагов идентичны. Если вы оцениваете переход на уровне функций перед началом работ по миграции, в сравнении Elido и Rebrandly подробно рассматриваются различия в моделях ценообразования и разрыв в резидентстве данных в ЕС. Документация по настройке кастомных доменов на /features/custom-domains описывает сторону Elido в проверке DNS и настройке TLS. А на странице /pricing указаны текущие лимиты тарифов - предварительная настройка большого инвентаря Rebrandly требует подходящего плана до начала импорта.

---

Источники: Документация API Rebrandly, доступ от 12.05.2026. Страница цен Rebrandly, доступ от 12.05.2026. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.