Міграція з Bitly: повний посібник без зламаних посилань

Щоб мігрувати з Bitly без зламаних посилань, розділіть посилання на дві групи. Посилання на вашому власному домені можна перенести: імпортуйте слаги в новий інструмент, потім змініть один DNS-запис, і ті самі URL продовжать відкриватися. Посилання на спільному домені bit.ly перенести не можна, бо Bitly володіє цим хостом, тож тримайте акаунт Bitly живим доти, доки ці URL лишаються в листах, PDF і друкованих матеріалах. Сам імпорт триває хвилини. Календарний час іде на кешування DNS і на період витримки, перш ніж щось скасовувати.

Решта цього посібника - деталі, що вирішують, чи буде перенесення непомітним для відвідувачів: експорт, зіставлення полів, правила конфліктів, статус редиректу, час перемикання DNS, перевірка з терміналу та відкат. Факти про Bitly взято з довідкового центру Bitly та довідника API (станом на 2026-10-02); факти про Elido - з коду імпортера та редиректів.

Я Ана, і я займаюся міграціями в Elido. Моє правило просте: спершу вирішіть, що можна перенести, а потім - як. Якщо ви ще обираєте, куди переходити, Elido проти Bitly - це порівняння функцій.

Що можна і чого не можна перенести з Bitly

Коротке посилання - це хост плюс слаг. Ви керуєте тим, куди воно веде, лише якщо керуєте хостом, тож є три випадки і лише одна справжня міграція.

Для посилань bit.ly чесна мета - не «перенести», а «припинити створювати нові». Налаштування брендованого домену до того, як ви захочете піти, - найдешевша страховка в усій цій темі.

Крок 1: інвентаризація та експорт посилань Bitly

Почніть з усього, що може зламатися: короткі посилання (слаг, призначення, назва, теги й група; один акаунт може мати кілька груп, а забута група - це забутий домен), кожен власний домен, що обслуговує посилання Bitly (перевіряйте свої DNS-зони, а не лише налаштування Bitly), надруковані QR-коди (QR-код Bitly працює, доки працює його посилання, а надруковані змінити найважче) і bio-сторінки (вони живуть на власних URL і в експорт посилань не потрапляють).

Експортуйте через API Bitly із Generic Access Token, по одній групі. GET /v4/groups/{guid}/bitlinks?size=100 повертає сторінку посилань і URL pagination.next; порожній next означає, що ви закінчили:

TOKEN="your-generic-access-token"
GROUP="your-group-guid"
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api-ssl.bitly.com/v4/groups/$GROUP/bitlinks?size=100"
# follow .pagination.next until it comes back empty

Експорт із панелі залежить від тарифу й охоплює лише те, що видно на екрані, тож надійний шлях - API. Посібник Short.io з експорту посилань Bitly зазначає, що безкоштовні акаунти Bitly взагалі не можуть експортувати з панелі. Заодно запишіть довічний лічильник кліків кожного посилання: це єдина історія кліків, яку дає Bitly, і потрібна вона до перемикання.

Крок 2: зіставте поля Bitly з Elido та оберіть правило конфліктів

Імпортер Bitly в Elido переносить чотири речі для кожного посилання: слаг, URL призначення (вибірково перевірте UTM на 20 посиланнях), назву (обрізається до 200 символів) і теги, плюс тег imported:bitly для фільтрації та масового редагування.

Не переноситься: довічні лічильники кліків (збережіть їх у власній таблиці), дати створення, дизайни QR (згенеруйте заново в QR-дизайнері), bio-сторінки (відтворіть у bio-сторінках) і конфігурація кампаній чи deep link (створіть заново як кампанії).

Регістр слага та пастка колізій

Bitly вважає bit.ly/CustomWord і bit.ly/customword різними посиланнями, що підтверджує його довідковий центр. Elido зберігає слаги без урахування регістру в межах домену, лишаючи регістр, з яким їх імпортовано, тож два посилання Bitly, що відрізняються лише регістром, конфліктують. Якщо bit.ly/Promo веде на /spring, а bit.ly/promo - на /autumn, то Promo імпортується чисто, а promo конфліктує. Тоді рішення ухвалює правило конфліктів.

• Suffix (типове) перебирає promo-2, promo-3 тощо, до 50 спроб, після чого повідомляє про помилку. Воно мовчки змінює публічний URL: кожне надруковане посилання promo тепер показує весняну сторінку, а осіннє посилання сидить на promo-2 - URL, якого ніхто не друкував.
• Skip лишає наявне посилання недоторканим і записує рядок Bitly з його слагом і причиною.
• Fail зупиняє всю задачу на першому ж конфлікті.

Якщо надрукований слаг має лишитися точним, обирайте skip або fail і вирішуйте кожен конфлікт вручну.

Крок 3: імпортуйте посилання в Elido

Є три шляхи завантажити посилання, залежно від обсягу й джерела.

• Імпортер Bitly. Відкрийте Integrations, потім міграцію Bitly, вставте Generic Access Token, виберіть групу, цільовий домен і правило конфліктів та запустіть. Сторінка міграції Bitly покроково описує форму.
• Масовий імпорт і CSV на панелі. Діалог New link приймає до 100 URL за раз, по одному в рядку або як CSV (url, slug, title); масовий імпорт із Google Sheets описує шлях через таблицю.
• API. POST /v1/workspaces/{workspace_id}/links/bulk приймає до 100 посилань за виклик і повідомляє про успіх чи збій по кожному елементу.

Як поводиться імпортер

Запускайте одну задачу на одну групу Bitly. Задача зупиняється на 50 000 посилань або через 30 хвилин (це запобіжники, а не тарифне обмеження), тож більші акаунти діліть за групами. Токен тримається в пам'яті на час запуску, потім відкидається. Кожна задача звітує про кількість імпортованих, пропущених і невдалих; статус partial означає, що частина рядків не пройшла, а список помилок (максимум 1000 записів) каже, які саме й чому. Фоновий обхід позначає задачу невдалою після 30 хвилин без прогресу. Повторні запуски безпечні за правил suffix і skip, бо вже імпортовані посилання розпізнаються. Відновлення зі збереженого курсору заплановане; нині перервану задачу просто запускають знову.

Та сама система задач обслуговує імпортери для Rebrandly, Short.io, TinyURL і Dub.

Спершу імпортуйте невелику групу й пройдіться по 20 посиланнях на найцінніші призначення. Репетиція коштує пів дня і саме на ній знаходяться слаги, що конфліктують.

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

Крок 4: перемкніть DNS і збережіть редиректи

Цей крок потрібен лише посиланням на вашому домені. Після зміни DNS запит https://links.yourbrand.com/slug має потрапити в сервіс, який уже містить саме цей слаг, тож спершу імпорт, а потім зміна DNS. Деякі інструменти роблять навпаки: підхід Short.io спершу спрямовує ваш домен на них і копіює Bitlink лише тоді, коли хтось по ньому клікає, тож посилання, на яке ніхто не клікнув під час переходу, не переноситься ніколи. Імпорт наперед усуває цю прогалину.

Реєстрація домену в Elido дає TXT-запис на _elido-verify.<hostname> і CNAME на edge.elido.me. Домен верифікується, коли обидва запити розв'язуються, а верифікатор здається через 24 години, якщо якогось із них бракує. Оскільки CNAME і є перемиканням, верифікація завершується під час перемикання, а не раніше. Посібник з налаштування власного домену показує форми.

Арифметика TTL

Відповідь DNS може кешуватися так довго, як сказано в TTL запису (RFC 1035, розділ 3.2.1), тож найгірше вікно застарілих даних дорівнює TTL до зміни. CNAME з 86400 секундами може цілу добу надсилати відвідувачів у Bitly. За D-2 знизьте TTL до 300 секунд і запишіть поточну ціль; скопіюйте її зі своєї зони: це ваше значення для відкату. У D0 виконайте продакшн-імпорт, потім замініть CNAME і додайте TXT-запис. Через п'ять-десять хвилин переконайтеся, що домен показує verified, і запросіть посилання через HTTPS. Тримайте TTL на 300 протягом витримки.

301 проти 302 під час перемикання

Bitly документує свої посилання як редиректи 301 (постійні). Elido дає змогу обрати 301, 302 або 307 для кожного посилання; імпортер не задає жодного, тож імпортовані посилання починають зі 302. Це добре підходить для перемикання: RFC 9110, розділ 15.4.2 каже, що 301 евристично кешується, а 302 за замовчуванням не кешується (розділ 15.4.3). Якщо в перший день перемкнути на 301, а потім відкотитися, кожен клієнт, що закешував відповідь, і далі ходитиме на старе місце.

Лишайтеся на 302 протягом витримки, а потім масово переведіть на 301 посилання, призначення яких ніколи не зміняться, відібравши їх за тегом imported:bitly. 301 проти 302 розбирає, де різниця важлива для SEO, а першоджерело - документація Google про редиректи. Стежте і за подвійними стрибками: проксі, що примусово вмикає HTTPS до того, як запит дійде до Elido, може додати один (ланцюжки редиректів і SEO, посібник про цикл редиректів).

Крок 5: перевірте перемикання через curl

Ніколи не вірте зеленій панелі; запитуйте справжній URL. Спершу підтвердьте DNS через публічний резолвер, а не офісний:

dig +short CNAME links.yourbrand.com @1.1.1.1
dig +short TXT _elido-verify.links.yourbrand.com @1.1.1.1

Потім подивіться на один редирект, не йдучи за ним: curl -s -o /dev/null -D - --max-redirs 0 https://links.yourbrand.com/SummerSale. Ви очікуєте 302 (або обраний вами статус) і заголовок location:, що збігається з вашим експортом; 404 означає, що слаг не імпортовано, а 200 - що це сторінка, а не редирект.

Далі проженіть кожен слаг з експорту циклом, використавши двоколонковий CSV slug,destination, зібраний з вашої вибірки Bitly:

DOMAIN="links.yourbrand.com"
fail=0
while IFS=, read -r slug dest; do
  out=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' --max-redirs 0 "https://${DOMAIN}/${slug}")
  code=${out%% *}; loc=${out#* }
  case "$code" in 301|302|307) ;; *) echo "BAD STATUS $code $slug"; fail=$((fail+1)); continue;; esac
  [ "$loc" = "$dest" ] || { echo "MISMATCH $slug -> $loc (want $dest)"; fail=$((fail+1)); }
done < slugs.csv
echo "failures: $fail"

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

Підпис про приймання - від людини, яка не є інженером перенесення: імпортовані плюс пропущені плюс невдалі дорівнюють відфільтрованому експорту; кожен невдалий рядок виправлено або свідомо відкинуто; 50 вибіркових посилань зберегли UTM; топ-20 посилань за довічними кліками пройшли ручну перевірку кліком; надрукований QR-код сканується; редиректи роблять один стрибок на чинному HTTPS; довічні лічильники Bitly збережено з датою.

Створіть робочий простір і проведіть репетиційний імпорт, перш ніж призначати дату перемикання, поки ще є час спокійно виправити конфлікти.

Крок 6: чого чекати в аналітиці після міграції

Історія кліків не переноситься, і жоден імпортер цього не змінить. API Bitly документує по два ендпоінти кліків на кожен bitlink, GET /v4/bitlinks/{bitlink}/clicks і GET /v4/bitlinks/{bitlink}/clicks/summary, і обидва повертають лічильники за проміжками часу, а не окремі події. Без рядків по кожному кліку відновити минулі реферери, країни чи пристрої неможливо. Історичні кліки, потрібні для звітності, мають лежати в GA4 або у вашому сховищі даних.

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

Огляд аналітики, де протягом 30 днів ви спостерігаєте кліки за день і за хостом. DEMO-робочий простір, синтетичні дані.

Крок 7: тримайте відкат напоготові, а Bitly скасовуйте останнім

Відкотитися можна, доки ви не скасували Bitly. Заздалегідь погодьте тригер, наприклад необґрунтоване падіння кліків понад 30% протягом двох днів або будь-яке зламане посилання з топ-20. Дія - повернути стару ціль CNAME; за TTL 300 секунд більшість резолверів підтягнуть її приблизно за п'ять хвилин, а оскільки ви лишалися на 302, закешованих 301, що ведуть не туди, немає. Спершу експортуйте посилання, створені в Elido після перемикання, бо їх немає в Bitly.

Що ламається, якщо скасувати Bitly надто рано

Довідковий центр Bitly конкретний, і порядок дій важливий. Посилання bit.ly працюють і після видалення акаунта, а їхні слаги не можна використати повторно, але ви більше не можете їх редагувати чи перенаправляти й втрачаєте їхні метрики. Посилання на власному домені працюють, лише доки ваш DNS вказує на Bitly; Bitly перестає поновлювати SSL-сертифікат, тож зрештою відвідувачі бачать попередження «not secure», а пониження тарифу (на відміну від видалення) лише блокує створення нових посилань на цьому домені. Безкоштовні домени не поновлюються, тож посилання на них ламаються після завершення терміну, який Bitly визначає як один рік від видачі чи останнього поновлення. Решта зникає разом з акаунтом: QR-коди, які ви більше не можете редагувати, Bitly Pages і всі звіти, які ви не експортували.

Спершу перенесіть DNS, підтвердіть перевірками вище й лише тоді скасовуйте чи понижуйте тариф. Тримайте акаунт щонайменше 90 днів; скільки коштує Bitly допоможе обрати найдешевший тариф для страховки.

Читайте також у блозі

• Власний домен із TLS за 5 хвилин
• Редиректи 301 і 302 для коротких посилань
• Масовий імпорт коротких посилань із Google Sheets
• Міграція з Rebrandly: передача брендованого домену без втрати слагів
• Ланцюжки редиректів і SEO

Джерела: статті довідкового центру Bitly про видалення акаунта, пониження тарифу, чутливість посилань до регістру та редиректи 301, а також довідник API Bitly, станом на 2026-10-02; поведінку Elido прочитано з коду імпортера та редиректів 2026-10-26.