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

Rebrandly побудовано навколо єдиної центральної абстракції: брендованого домену. Slashtags, таксономії тегів та правила Traffic Routing - усе це знаходиться під ним. Таке дизайнерське рішення робить Rebrandly цілісним продуктом, і воно ж робить перехід з нього відмінним від будь-якого іншого переїзду скорочувача.

Коли ви залишаєте Rebrandly, ви насамперед мігруєте не посилання. Ви мігруєте домен. Посилання йдуть «у комплекті», а деталі їх збереження майже повністю залежать від того, що ви вирішите робити з доменом.

Цей допис охоплює два реалістичні шляхи, структуру експорту з API Rebrandly, виклик масового імпорту до Elido та процес валідації перед оголошенням про переключення.

TL;DR#

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

Що потрібно проінвентаризувати в першу чергу#

Перш ніж обрати один із шляхів, проведіть ревізію чотирьох речей.

Брендований домен або домени. Модель робочих просторів Rebrandly дозволяє використовувати кілька власних доменів в одному акаунті. У випадку агентства або мультибрендового простору кожен домен є окремою одиницею міграції. Складіть їх список перед плануванням вікон переключення - міграція одного домену за ніч є безпечнішим графіком, ніж усіх одночасно.

Активні посилання. Для великих баз даних використовуйте Rebrandly REST API (доступ станом на 2026-05-12), а не 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 (станом на 2026-05-12) обмежують кількість активних посилань та доменів. API повертає всі посилання незалежно від цього; ваш експорт може містити посилання на доменах, які ви вже вивели з експлуатації. Відфільтруйте їх перед імпортом.

Крок 2: попереднє налаштування в Elido#

Зареєструйте домен у вашому просторі Elido через інтерфейс налаштування власних доменів ще до того, як чіпати DNS. Домен не обов'язково має бути активним. Elido підтверджує право власності через DNS TXT-запис; ви можете зробити це, не порушуючи роботу існуючого 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 належало до категорії Campaigns у Rebrandly, додайте cat:campaigns до масиву tags. Це не ідентична заміна, але це дозволить вам фільтрувати дані в дашборді та аналітиці Elido. Зафіксуйте цю схему у ваших нотатках до міграції.

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

Крок 3: переключення DNS#

Це вирішальний момент. Перед цим переконайтеся в наступному:

• Усі слаги в масовому імпорті отримали статус успіху. Немає невирішених помилок.
• Домен зареєстрований і TLS активовано у вашому просторі Elido. Перевірте один слаг безпосередньо через край Elido, тимчасово додавши CNAME для тестового піддомену, а не для основного.
• Значення TTL для існуючого CNAME Rebrandly було знижено. Сторінка з цінами Rebrandly (станом на 2026-05-12) показує, що налаштування DNS доступні, починаючи з безкоштовного тарифу. Знизьте TTL до 300 секунд щонайменше за 24 години до початку вікна переключення.

Коли вікно відкриється, змініть ціль CNAME-запису:

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

Край Elido використовує автоматичний TLS на вимогу. Якщо TLS було попередньо налаштовано під час валідації (рекомендовано), перший запит після оновлення DNS спрацює миттєво. Якщо ні, сертифікат буде згенеровано під час першого звернення - зазвичай це займає 1-3 секунди, після чого він кешується, і наступні запити обслуговуються із затримкою p95 менше 15 мс через вузол у регіоні ЄС.

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

Шлях Б: домен також змінюється#

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

В обох випадках простір слагів змінюється. Питання в тому, чи зможете ви налаштувати ланцюжок 301-х редиректів зі старого домену, щоб мінімізувати втрату трафіку.

Варіант B1: ланцюжок 301-х редиректів зі старого домену Rebrandly#

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

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

Механіка: залиште старий домен активним у Rebrandly на період перекриття, налаштувавши його як прохідний редиректор. Новий домен запустіть на Elido з першого дня міграції. Через 30–90 днів (залежно від того, як довго ваші матеріали залишаються в обігу) вимкніть старий домен у Rebrandly.

Варіант B2: прийняти зміну слагів#

Якщо старим доменом був піддомен, призначений Rebrandly (yourname.rebrandly.com), або домен, над DNS якого ви більше не маєте контролю, налаштувати 301-й редирект не вдасться. Посилання на старому домені працюватимуть доти, доки працює Rebrandly і ваш акаунт там активний. Трафік за цими посиланнями не йтиме через Elido, тому ви втратите по ньому аналітику.

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

Для команд, що обирають між B1 та B2, розрахунок такий: скільки опублікованих матеріалів містять старі посилання, наскільки важко їх оновити і як довго за ними приходитиме трафік. Посилання в архівах розсилок з високим трафіком та друковані матеріали - аргумент за B1. Кілька внутрішніх документів - аргумент за B2.

Експорт Rebrandly: що ви отримуєте, а що ні#

Rebrandly API (станом на 2026-05-12) експортує наступні поля для кожного посилання через /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 знайдіть усі Zaps, що використовують застосунок Rebrandly, і замініть цей крок на застосунок Elido (перевірте доступність) або на Webhook-дію, яка безпосередньо викликає POST /v1/links. У Make та Workato дійте аналогічно.

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

Перехідний період: для автоматизацій, які створюють посилання рідко (кілька на тиждень), безпечно залишити їх на Rebrandly протягом 1–2 тижнів після переключення DNS. Посилання створюватимуться в старій системі, але оскільки DNS уже переключено, вони успішно резолвитимуться через Elido. Високочастотні автоматизації (десятки посилань на день) слід мігрувати безпосередньо в день переключення.

Більше про API та доступні SDK Elido можна дізнатися на сторінці з цінами, а повна документація доступна за посиланням /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 означає, що слаг або не був створений (перевірте лог імпорту), або є невідповідність регістру. У Rebrandly слаги нечутливі до регістру при переході; в Elido слаги чутливі до регістру під час створення. Якщо у вашому експорті змішаний регістр, приведіть усе до нижнього регістру перед імпортом.

План відкату на 30 днів#

Зберігайте акаунт Rebrandly активним протягом 30 днів після переключення DNS. Зміну DNS можна скасувати в будь-який момент протягом цього вікна - просто поверніть CNAME на край Rebrandly, і старі посилання знову запрацюють. Якщо через 30 днів аналітика не показує аномалій у відсотках успішних переходів і перевірка слагів пройшла успішно, акаунт Rebrandly можна безпечно закривати або переводити на нижчий тариф.

Щодо домену: не переносьте домен до іншого реєстратора під час міграційного вікна. Зміна CNAME - це єдина необхідна операція. Перенос реєстратора додає зайві ризики затримок розповсюдження DNS, які не потрібні під час переключення.

Внутрішній контекст міграції#

Механіка цієї міграції багато в чому повторює стратегію Bitly. Шаблони DNS, налаштування TTL та підхід до збереження слагів ідентичні. Якщо ви тільки оцінюєте перехід на рівні функціоналу, у порівнянні Elido vs Rebrandly детально розібрано відмінності в моделях ціноутворення та переваги резиденції даних в ЄС. Документація з налаштування власних доменів за адресою /features/custom-domains охоплює технічну частину верифікації DNS та TLS з боку Elido. А на сторінці /pricing вказано актуальні ліміти тарифних планів - для масового імпорту великої бази Rebrandly переконайтеся, що ви обрали відповідний план.

---

Джерела: Rebrandly API documentation доступ станом на 2026-05-12. Rebrandly pricing page доступ станом на 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.