Міграція з TinyURL: два шляхи та що кожен із них зберігає

Міграція з Bitly має перевірений часом сценарій: експорт API, CSV, масовий імпорт, переключення DNS. Посібник із міграції з Bitly охоплює кожен крок. TinyURL відрізняється - не складніше, але інакше, що впливає на ваше планування. Різниця, яка має найбільше значення, полягає в тому, чи є у вас обліковий запис TinyURL Pro. Ця єдина змінна розділяє міграцію на дві майже не пов'язані процедури.

Ця стаття описує обидва шляхи та чесно розповідає про те, що не вдасться зберегти під час переїзду.

TL;DR#

• Якщо у вас є обліковий запис TinyURL Pro, TinyURL API дозволяє перелічити та експортувати ваші посилання. CSV включає слаг, цільову сторінку та кількість кліків за 30 днів. Ви можете чисто імпортувати їх до Elido.
• Якщо у вас немає облікового запису - ви просто публікували посилання tinyurl.com/<slug> протягом років - експорту не існує. Ви відновлюєте карту посилань, збираючи дані з власних опублікованих ресурсів.
• У жодному разі ви не зможете зберегти оригінальні слаги tinyurl.com у вашому робочому просторі Elido. TinyURL володіє цим доменом. Ви згенеруєте нові слаги на власному брендованому короткому домені.
• Примітка реаліста: більшість користувачів TinyURL перебувають на безкоштовному тарифі. Для них міграція - це не стільки перенесення даних, скільки оновлення кожного місця, де з'являється посилання TinyURL.

Що робить міграцію з TinyURL відмінною від Bitly#

Ключова структурна різниця - це домен. Користувачі Bitly на платних планах часто використовують власний брендований домен - links.yourbrand.com, яким вони володіють. Коли вони мігрують, запис DNS для цього домену переспрямовується на edge-сервер Elido, і кожен існуючий слаг продовжує працювати. Простір слагів належить їм.

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

TinyURL Pro пропонує власні брендовані домени за $9.99/month (станом на 2026-05-12). Якщо ви користувалися Pro та власним доменом, шлях міграції набагато ближчий до сценарію Bitly: підтвердіть домен в Elido, заздалегідь створіть слаги, а потім змініть CNAME у DNS. Документація щодо власних доменів описує цей процес з боку Elido.

Інша структурна різниця - це журнал аудиту. TinyURL має обмежену видимість історичних даних навіть на Pro. Порівняння elido-vs-tinyurl охоплює повний розрив у функціональності. Для планування міграції практичним наслідком є те, що ви не зможете реконструювати повну історію кліків. Не плануйте цього у своєму бюджеті.

Шлях А: у вас є обліковий запис TinyURL Pro#

TinyURL Pro надає доступ до API за адресою https://tinyurl.com/app/dev (станом на 2026-05-12). API підтримує створення та отримання аліасів. Перелік працює через пагіновані виклики GET, які повертають ваші посилання частинами.

Кроки:

1. Згенеруйте токен API у налаштуваннях додатка TinyURL.
2. Перелічіть усі аліаси, проходячи пагінацію до кінця. TinyURL застосовує обмеження швидкості (rate limits); документація API вказує ліміт запитів на хвилину. Налаштуйте обробку затримок (backoff handler) перед початком - помилка 429 посеред експорту дратує, але вона не руйнує дані, якщо ви записували результати на диск поступово.
3. Для кожного аліаса зберіть слаг, цільову URL-адресу та кількість кліків за останні 30 днів. API TinyURL не надає окремих подій кліків або історичних часових рядів. Ви отримуєте агреговане значення.
4. Створіть плоский CSV: один рядок на посилання, стовпці slug,target_url,clicks_30d.
5. Відсортуйте за clicks_30d у порядку спадання. Топ-1% посилань за обсягом кліків - це зазвичай саме та частина, яка дійсно має значення для поточних кампаній або опублікованого контенту. Пріоритезуйте їх для перевірки та оновлення на ресурсах. Велика кількість посилань із нульовими кліками може бути імпортована, але рідко потребує уваги людини.

Після того, як ви отримаєте CSV, імпорт до Elido відбувається за тією ж схемою, що і будь-яка інша масова міграція. Детальна механіка масового імпорту описана в посібнику з міграції з Bitly - структура API та виклик TypeScript SDK ідентичні; відрізняються лише вихідні дані.

Ланцюжок 301 для брендованих доменів на Pro#

Якщо ваш обліковий запис TinyURL Pro використовував власний брендований домен, ви можете перенести цей домен до Elido. Спочатку зареєструйте його у своєму робочому просторі Elido через процес додавання власних доменів, заздалегідь створіть усі слаги, а потім змініть CNAME:

short.yourbrand.com.  300  IN  CNAME  edge.elido.me.

Тут діє семантика HTTP 301: щойно CNAME почне вказувати на edge Elido, браузери та боти, які переходять за старими посиланнями, отримають відповідь 301 Moved Permanently від Elido, що вказує на цільову URL-адресу. Жодного проміжного переходу через TinyURL не потрібно, оскільки простір слагів був на вашому домені, а не на tinyurl.com. Це чистий шлях.

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

Шлях Б: немає облікового запису, лише опубліковані посилання#

Це більш поширений сценарій. У вас є безкоштовний обліковий запис TinyURL або його взагалі немає, і у вас є колекція посилань tinyurl.com/<slug>, опублікованих у архівах розсилок, дописах у соціальних мережах, друкованих матеріалах або документації. У вас немає доступу до API та механізму експорту. Посилання існують, але у вас немає їхнього списку.

Єдиний спосіб створити інвентар - це систематично шукати на власних опублікованих ресурсах.

Пошук посилань#

Працюйте з кожним ресурсом систематично:

• Архіви електронної пошти/розсилок: знайдіть tinyurl.com в архіві вашої поштової платформи. Більшість платформ дозволяють шукати по надісланих кампаніях. Експортуйте збіги.
• Соціальні мережі: шукайте посилання tinyurl.com у своїх дописах у Twitter/X, LinkedIn та Facebook. Більшість платформ мають функцію експорту контенту на рівні облікового запису. Завантажте його та скористайтеся grep.
• Веб-сайт та документація: запустіть пошук по сайту або сканування. Команда grep -r "tinyurl.com" ./content у репозиторії статичного сайту займає лічені секунди.
• Посилання для відстеження в рекламних платформах: перевірте посилання з UTM-мітками у Google Ads, Meta Ads Manager або там, де ви запускали платні кампанії.

Після того, як ви отримаєте список значень tinyurl.com/<slug>, вам знадобляться цільові URL-адреси. Якщо ви створювали посилання самі та пам'ятаєте ціль - чудово. Якщо ні: переходьте за кожним посиланням вручну або за допомогою скрипта, який робить запит HEAD і зчитує заголовок Location. Редирект TinyURL є публічно доступним - вам не потрібен обліковий запис, щоб дізнатися, куди веде посилання tinyurl.com.

# Bulk-resolve TinyURL destinations from a file of slugs (one per line)
while IFS= read -r slug; do
  dest=$(curl -s -o /dev/null -w "%{redirect_url}" \
    -L --max-redirs 0 "https://tinyurl.com/${slug}" 2>/dev/null || echo "FAILED")
  echo "${slug},${dest}"
done < tinyurl-slugs.txt > slug-target-map.csv

Це дасть вам CSV-файл slug,target_url, необхідний для імпорту. Зауважте, що ви будете імпортувати їх із новими слагами на власному домені - про це нижче.

Прийміть те, що неможливо відновити#

Для посилань, опублікованих у контекстах, до яких ви більше не маєте доступу - акаунт у соцмережах на попередній роботі, пост у спільноті на платформі, яку ви видалили - шляху відновлення немає. Ці старі посилання tinyurl.com продовжуватимуть працювати доти, доки TinyURL залишається в робочому стані, але ви не зможете їх оновити, перенаправити через Elido або побачити, хто за ними переходить. Прийміть це та рухайтеся далі. Міграція того, що ви можете знайти, - це правильне рішення; досконалість тут недосяжна.

Імпорт до Elido#

Незалежно від того, яким шляхом був створений ваш CSV, виклик імпорту однаковий. Ключова відмінність полягає в тому, що ви вказуєте в полі slug.

Якщо у вас є власний брендований домен: ви можете спробувати зберегти слаги зі Шляху А. Спочатку зареєструйте свій домен в Elido, а потім явно передайте slug у тілі масового імпорту. Структура виклику:

curl -X POST "https://api.elido.app/v1/links/bulk" \
  -H "Authorization: Bearer $ELIDO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: tinyurl-migration-batch-001" \
  -d '{
    "workspace_id": "ws_xxxxxxxxxxxx",
    "domain_id": "dom_xxxxxxxxxxxx",
    "links": [
      {
        "slug": "original-slug",
        "destination_url": "https://your-long-destination.com/path",
        "tags": ["tinyurl-migrated"]
      }
    ]
  }'

domain_id повинен посилатися на домен, який уже зареєстрований і підтверджений у вашому робочому просторі. Ендпоінт приймає до 100 посилань за один виклик і повертає статус успіху/помилки для кожного елемента - конфлікт слагів в одному рядку не зупиняє обробку всієї пачки.

Якщо ви використовували tinyurl.com/ без власного домену: залиште поле slug порожнім або передайте null. Elido згенерує слаг для кожного посилання. Прийміть зміну слага. Старі посилання tinyurl.com не перенаправляють на ваші нові посилання Elido - ви не можете встановити ланцюжок 301, оскільки не володієте tinyurl.com. Єдиний спосіб відновити трафік - це оновити кожен опублікований ресурс, який містить старе посилання. Це і є робота.

Обмеження ланцюжка 301 для небрендованих посилань#

Це заслуговує на окрему заяву. Посібник migrate-from-bitly-without-breaking-links детально описує шаблон "301 bridge" для міграції з Bitly. Цей шаблон передбачає, що ви контролюєте вихідний домен. Для посилань tinyurl.com це не так.

TinyURL не надає механізму для встановлення редиректу з існуючого tinyurl.com/<slug> на нову адресу. Посилання продовжує вести туди, куди воно було спрямоване в момент створення. Якщо ви хочете, щоб трафік, який йшов на tinyurl.com/abc123, натомість потрапляв на ваше нове посилання Elido, у вас є два варіанти:

1. Оновити кожен опублікований ресурс, щоб він використовував нове посилання Elido. Це правильний підхід.
2. Залишити посилання TinyURL спрямованим на ціль і дозволити Elido обробляти лише майбутні посилання. Це прийнятно, якщо старі посилання використовуються рідко і не є критично важливими для бізнесу.

Варіант 2 насправді не є "міграцією" - це співіснування. Для більшості команд має сенс комбінування обох варіантів: повністю перейти на створення нових посилань в Elido, оновити старі ресурси з найвищим трафіком і дозволити великій кількості старих посилань TinyURL із нульовим трафіком поступово згасати.

Валідація#

Після імпорту перевірте, чи справді працює те, що має значення.

Візьміть свій відсортований CSV і виберіть перші 50 рядків за обсягом кліків (зі Шляху А) або за датою публікації та розміром аудиторії (зі Шляху Б, де ви оцінюєте важливість). Для кожного з цих посилань:

1. Якщо ви використовували власний брендований домен і зберегли слаги: перевірте, чи https://short.yourbrand.com/<slug> веде на правильну ціль. Панель керування Elido показує статус 200 або помилку. Крім того, ви можете запустити перевірку через curl:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
  "https://short.yourbrand.com/your-slug"

2. Якщо ви згенерували нові слаги: переконайтеся, що цільові URL-адреси в панелі керування Elido збігаються з вашим вихідним CSV. Відповідь на імпорт містить статус успіху/помилки для кожного елемента; перегляньте лог помилок перед завершенням міграції.

3. Перевірте свої останні розсилки з високим показником відкриттів та нещодавні дописи у соцмережах. Якщо вони містять посилання TinyURL і ви оновили їх на посилання Elido, переконайтеся, що оновлені посилання працюють. Якщо ви їх не оновили - відзначте їх окремо. Це саме ті посилання, які найімовірніше мають активний трафік кліків, який ви залишаєте поза своєю аналітикою.

Для будь-якого ресурсу, який ви оновили, підтвердіть, що оновлення дійсно потрапило в опубліковану версію. Розсилка, запланована зі старими посиланнями, відредагований твіт, довідкова стаття, кешована CDN - це місця, де оновлення може не відобразитися миттєво.

Примітка реаліста про слаги, які ви не можете залишити#

Груба версія: якщо ви були на безкоштовному тарифі TinyURL і публікували посилання tinyurl.com/<slug>, ви не мігруєте простір слагів. Ви мігруєте список цільових URL-адрес і починаєте з чистого аркуша в Elido з новими слагами на власному домені. Старі посилання tinyurl.com існують вічно на інфраструктурі TinyURL. Ви не можете їх оновити, перенаправити або отримати з них аналітику після того, як припините користуватися обліковим записом.

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

Те, що ви отримуєте натомість - це те, що буде далі: брендовані короткі посилання на домені, яким ви володієте, аналітика кліків, яка не обмежується 30-денним вікном, та модель ціноутворення, яка масштабується без сюрпризів. Робота з міграції - це одноразова витрата. Покращений інструментарій - це назавжди.

Якщо ви оцінюєте, чи є Elido правильним місцем для переїзду перед тим, як розпочати міграцію, порівняння elido-vs-tinyurl детально описує різницю у функціях та відповідності стандартам.

Джерела: Документація TinyURL developer API, доступ від 2026-05-12. Сторінка ціноутворення TinyURL, доступ від 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.