Міграція з TinyURL

Щоб мігрувати з TinyURL, спершу розкладіть посилання на дві купи: посилання на домені, яким ви володієте, і посилання на tinyurl.com. Перша купа переїжджає чисто, бо ви змінюєте один DNS-запис, а старі URL продовжують працювати. Другу купу ви взагалі не можете перенаправити, бо домен належить TinyURL. Ви можете скопіювати призначення в Elido, але кожне місце, де було опубліковано посилання tinyurl.com/xxxx, доведеться оновити вручну.

Друге, що треба знати перед стартом: зараз надійний спосіб переїхати - файл. Експортуйте через документований виклик TinyURL GET /urls/available, зведіть результат до destination, slug, title і завантажте масовим імпортом Elido. Elido також має імпортер TinyURL в один клік, але той звертається до ендпоінта, якого немає в опублікованому API TinyURL, тож ми вважаємо його неперевіреним, доки не вийде запланований фікс. Цей посібник охоплює обидва шляхи й увесь маршрут: від експорту до аналітики, з перемиканням і відкатом посередині. Факти про TinyURL взято з його блогу та специфікації OpenAPI (дати доступу 2026-10-01 і 2026-10-02).

Щоб отримати вердикт функція за функцією, чи переходити взагалі, читайте Elido проти TinyURL або ширший огляд альтернатив TinyURL.

Які посилання TinyURL можна перенести

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

Чесна версія для перших двох рядків: коли ви перестаєте платити TinyURL, ці посилання продовжують відкриватися, поки TinyURL їх зберігає, а ви не можете ні бачити кліки, ні змінювати їх, ні перенаправляти. Деякі команди залишають їх свідомо. Я вважаю це правильним рішенням для старих посилань з малим трафіком.

Крок 1: експорт посилань з TinyURL

TinyURL дає один документований спосіб перелічити ваші посилання: API. Його специфікація OpenAPI (дата доступу 2026-10-02) визначає перелік як GET /urls/{type}, де type - available або archived, з необов'язковими датами from і to та фільтром search, що приймає префікс alias: або tag:. Виклик потребує bearer-токена. Стаття TinyURL про перелік посилань описує той самий ендпоінт і каже, що тип - єдиний обов'язковий вхід.

Чого специфікація не дає - так само важливо. Вона не визначає параметрів page чи per_page і жодних лімітів частоти. Тож для великого акаунта звужуйте кожен запит вікнами from/to (скажімо, по місяцю) і записуйте кожну відповідь на диск, перш ніж робити щось інше:

# One window at a time; inspect the first response by hand before scripting further
curl -s -H "Authorization: Bearer $TINYURL_TOKEN" \
  "https://api.tinyurl.com/urls/available?from=2025-01-01T00:00:00Z&to=2025-02-01T00:00:00Z" \
  > tinyurl-2025-01.json

Ми не перевіряли форму живої відповіді (специфікація не уточнює, чи вона несе список, чи один об'єкт), тож відкрийте один файл і подивіться, перш ніж писати парсер. Виконайте той самий виклик до /urls/archived, якщо хочете й архівні посилання.

Три обмеження формують решту плану:

• Немає акаунта - немає списку. TinyURL заявляє, що посилання, створені без входу, не можна ні керувати, ні видаляти. Запису на користувача немає, тож експортувати нічого.
• Безкоштовний тариф лише для читання. За сторінкою безкоштовного тарифу TinyURL редагування й видалення посилань, аналітика кліків, власні домени й масове створення - усе за платними тарифами.
• Аналітики в списку немає. Історія кліків - на вас. Зробіть знімок екрана або виведіть звіт з TinyURL до скасування. Ми не знайшли документованої кнопки експорту CSV у довідковому центрі TinyURL, тож цей посібник її не обіцяє.

Крок 2: зіставлення даних TinyURL з файлом, який приймає Elido

Що б ви не витягли з TinyURL, зведіть до тих самих трьох полів:

• Довгий URL TinyURL стає destination (ціль посилання).
• Аліас TinyURL стає slug. Залиште порожнім для посилань на tinyurl.com, яким хочете нові коди.
• Назва чи опис TinyURL стає title.

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

Сторінка посилань Elido має вкладку bulk і вкладку CSV, і обидві читають рядки у формі url, slug, title. У вкладці CSV перший рядок відкидається, якщо в ньому немає URL з http(s)://, тож рядок заголовка безпечний. Рядки, що починаються з #, у полі вставки ігноруються. Власні слаги - це літери, цифри й дефіси, тож перевірте аліаси з іншими символами перед завантаженням; рядки, що не пройшли, перелічуються з причиною.

destination,slug,title
https://acme.com/spring-sale,spring-sale,Spring Sale
https://acme.com/pricing,,Pricing page

Якщо ви користувалися тегами TinyURL, збережіть їх. У трьохколонковий CSV вони не вміщаються, але шлях через API нижче їх приймає.

Крок 3: імпорт в Elido

Є два шляхи. Файловий працює сьогодні. Вбудований імпортер існує, але неперевірений.

Надійний шлях: CSV, масова вставка або масовий API

Вкладки bulk і CSV у дашборді обробляють до 100 посилань за пакет, тож більший файл поділіть на частини. Довідкова сторінка масового імпорту проводить через форму, а покрокова інструкція з масового імпорту з Google Sheets зручна, якщо ви чистили експорт у таблиці.

API робочого простору приймає ту саму форму як JSON. POST /v1/workspaces/{workspace_id}/links/bulk приймає domain_id і до 100 links, кожне з destination_url та необов'язковими slug, title і tags. Кожен рядок обробляється окремо, тож один поганий рядок не валить пакет, а відповідь повідомляє, які рядки дали помилку. Додайте тег на кшталт imported:tinyurl самі, щоб потім відфільтрувати пакет. Клієнтські бібліотеки є в розділі API та SDK.

Вбудований імпортер TinyURL і його відома помилка

В Elido є імпортер TinyURL в один клік, описаний на сторінці міграції з TinyURL. Ви вставляєте API-токен TinyURL, вибираєте домен Elido, на який мають потрапити посилання, і обираєте стратегію конфліктів. Проблема в першому HTTP-виклику. Воркер будує такий запит:

GET https://api.tinyurl.com/aliases?page=1&per_page=100
Authorization: Bearer <token>

і очікує у відповідь {"data": [{alias, url, title, tags}], "meta": {"total", "has_more"}}. У специфікації TinyURL шляху /aliases немає; операції з аліасами живуть під /alias/{domain}/{alias}, а перелік - це /urls/{type}. Тобто контракт пагінації ніколи не брався з TinyURL. Наш юніт-тест віддає написану вручну відповідь в очікуваній формі й проходить, що доводить лише збіг парсера з нашим припущенням і нічого про TinyURL. Ми не запускали його проти живого акаунта, бо для цього потрібен токен платного тарифу. Поки що не будуйте міграцію навколо нього.

Фікс запланований: перейти на /urls/available (з /urls/archived за прапорцем), проходити вікнами from/to, парсити захищено й тестувати на справжній захопленій відповіді. Після цього пагінацію та реальний ліміт на запит потрібно переміряти на живому акаунті, бо специфікація не дає ні того, ні іншого.

Сторінка інтеграцій у DEMO-просторі із синтетичними даними. Звідси запускається міграція з TinyURL.

Що робить імпортер, отримавши сторінку

Усе після HTTP-виклику не залежить від питання ендпоінта, і цю частину ми можемо описати за кодом.

• Запуск. POST з token, target_domain_id і необов'язковим conflict_strategy. Обробник відхиляє порожній токен, відсутній домен і будь-яку стратегію поза suffix, skip, fail, потім відповідає 202 із задачею та запускає воркер у фоні, відокремлено від запиту.
• На кожне посилання. Рядок без URL чи без аліаса рахується невдалим із причиною. Інакше аліас стає слагом, призначення й назва копіюються (назва обрізається до 200 символів), а теги копіюються з доданим imported:tinyurl.
• Прогрес. Лічильники скидаються в рядок задачі кожні 50 посилань. Для кожної задачі логується щонайбільше 1000 рядків помилок.
• Помилки автентифікації та частоти. 401 або 403 завершує задачу невдало з повідомленням "check the bearer token", а 429 - як перевищення ліміту частоти. Повторних спроб чи backoff немає: задача зупиняється.

Токен іде з тіла запиту у фонову задачу й далі нікуди. Рядок задачі не записує токена, і нічого не шифрується у спокої, бо нічого не зберігається. Тіло запиту читається з лімітом 4 КБ. Код не перевіряє токен і не перевіряє тариф перед стартом, тож поганий токен проявляється як невдала задача після першого запиту, а не як помилка форми. Ранні версії нашої документації описували попередню перевірку через ендпоінт доменів; цього кроку в коді немає, і в специфікації TinyURL такого шляху теж немає.

Правила конфліктів і ліміти

Перед кожною вставкою воркер робить один індексований пошук за парою домену й слага:

• suffix (за замовчуванням) пробує alias-2, alias-3, до alias-50, і вважає рядок невдалим, якщо всі зайняті.
• skip залишає наявне посилання Elido недоторканим і логує рядок джерела.
• fail завершує задачу невдало на першому конфлікті.

Кожен запуск обмежений 50 000 посилань і 30 хвилинами. Варто знати дві поведінки. Коли досягнуто ліміту в 50 000, цикл просто зупиняється, і задача завершується; вона не провалюється, тож порівняйте підсумкові лічильники із загальною кількістю в джерелі. Коли закінчується 30-хвилинний бюджет, задача позначається невдалою з кількістю імпортованих на цей момент.

Список посилань у DEMO-просторі. Імпортовані посилання несуть тег imported:tinyurl, тож пакет можна відфільтрувати для перегляду.

Безпечне тестування імпортера

Коли ендпоінт виправлять або якщо ви спробуєте імпортер самі до цього, робіть це в малому масштабі. Створіть тимчасовий робочий простір, додайте порожній домен і спершу запустіть задачу зі стратегією fail. Порожній домен означає відсутність конфліктів, тож будь-яка помилка - це проблема парсингу чи автентифікації, а не колізія. Потім порівняйте три числа: кількість у джерелі в TinyURL, total, яке звітує задача, і лічильники імпортованих плюс пропущених плюс невдалих. Оскільки воркер бере meta.total з очікуваної відповіді, розбіжність між total і вашою реальною кількістю - перша ознака, що форма відповіді відрізняється від припущеної парсером. Відфільтруйте за imported:tinyurl, відкрийте десять посилань навмання й порівняйте призначення, слаг і назву з TinyURL.

Запуск нового робочого простору Elido для цього займає пару хвилин; створіть безкоштовний акаунт і спершу додайте свій домен, щоб він був готовий, коли імпорт завершиться.

Крок 4: перемикання власного домену

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

Порядок важливий, бо DNS - останній крок і єдиний, який відчувають відвідувачі:

1. Знизьте TTL запису за добу наперед, щоб перемикання спрацювало швидко.
2. Додайте хост в Elido в розділі Domains і дайте йому верифікуватися. Посібник додавання домену містить точні записи, а усунення проблем із DNS-верифікацією розглядає помилки друку, що стоять за більшістю застряглих станів "Pending".
3. Імпортуйте аліаси на цей хост, поки відвідувачі ще потрапляють у TinyURL.
4. Вибірково звірте імпортовані слаги зі старою поведінкою живого хоста.
5. Змініть DNS-запис. З цього моменту хост розв'язується в Elido, і кожен старий URL на ньому слідує за ним.

Тримайте хост лише на DNS, без CDN-проксі перед ним, бо видача сертифіката за таким проксі може не вдатися. Ширші налаштування описано у власних доменах для коротких посилань і на сторінці власних доменів.

Крок 5: збережіть редиректи 301 цілими

На вашому власному домені URL не змінюється, тож нічого «зшивати» не треба: той самий шлях тепер відповідає з Elido. Захищати треба семантику редиректу. Коди статусу редиректів визначені в RFC 9110; постійний редирект каже браузерам і пошуковим системам, що ціль стабільна, а перемикання довгоіснуючих посилань на тимчасові змінює їх кешування й облік. Про сторону SEO та кешування читайте 301 проти 302.

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

Крок 6: перевірка міграції

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

1. Заморозьте нові посилання в TinyURL. Відтепер створюйте все нове в Elido.
2. Архівуйте файли експорту TinyURL і будь-які звіти, з датою.
3. Відфільтруйте імпортований пакет в Elido за тегом imported:tinyurl.
4. Порівняйте кількості. Імпортовані плюс пропущені плюс невдалі мають дорівнювати кількості рядків у джерелі.
5. Виправте невдалі. Кожен невдалий рядок має причину, зазвичай недійсний URL або поганий символ слага.
6. Протестуйте найважливіші посилання. Візьміть ваші 50 найважливіших посилань і запитайте кожне:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://go.yourbrand.com/spring-sale

7. Порівняйте призначення з джерелом для цих 50. Збіг кінцевого URL, включно з параметрами UTM.
8. Перевірте знову після DNS з мережі, що не кешувала старий запис.
9. Оновіть розміщення tinyurl.com. Пошукайте tinyurl.com в архівах пошти, біо в соцмережах, рекламних платформах і друці, та замініть те, що можете.

Для місць, до яких не дотягнутися, змиріться з втратою. Старі надруковані QR-коди й забуті пости й далі вестимуть у TinyURL, і це правда для кожної міграції скорочувача. Міграція з Bitly без зламаних посилань містить суворіший прохід перевірки, якщо він вам потрібен.

Крок 7: сплануйте відкат

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

Всередині Elido важелем скасування пакета є тег imported:tinyurl: відфільтруйте, потім масово редагуйте чи видаліть. Якщо запуск імпортера обривається посередині (деплой чи збій його зупиняє, а перевірка кожні п'ять хвилин переводить задачі без прогресу 30 хвилин у стан failed), збереженого курсора немає, тож ви перезапускаєте задачу. Повторний запуск безпечний за suffix чи skip, але suffix створить копії -2 посилань, які перший запуск уже записав, тож для повторного запуску надавайте перевагу skip.

Крок 8: очікування щодо аналітики

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

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

Що ви отримуєте від переходу

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

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

• Elido проти TinyURL
• Альтернативи TinyURL
• Bitly проти TinyURL
• Міграція з Bitly: посібник
• Масовий імпорт коротких посилань з Google Sheets
• Власні домени для коротких посилань