Миграция с 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 - как превышение лимита. Повторов и отсрочки нет: задание останавливается.

Токен идёт из тела запроса в фоновое задание и больше никуда. Строка задания токен не хранит, и ничего не шифруется на диске, потому что ничего не хранится. Тело запроса читается с лимитом 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-only, без CDN-прокси перед ним, потому что выпуск сертификата за прокси может не удаться. Общая настройка описана в статье пользовательские домены для коротких ссылок и на странице функции пользовательских доменов.

Шаг 5: сохраните 301-редиректы

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

Для ссылок tinyurl.com добавить 301 нельзя, потому что редирект принадлежит TinyURL. Лучшее, что вы можете, - убедиться, что адрес назначения за старой ссылкой остаётся рабочим, и заменить ссылку везде, куда дотянетесь. Как работает мост на 301, когда старый хост вам принадлежит, показывает руководство по миграции с Bitly.

Шаг 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 - это рычаг для отмены пакета: отфильтруйте, затем отредактируйте или удалите массово. Если запуск импортёра оборвался на середине (его останавливает деплой или сбой, а проверка каждые пять минут переводит в failed задания без прогресса за 30 минут), сохранённого курсора нет, поэтому задание запускают заново. Повторный запуск безопасен при 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
• Пользовательские домены для коротких ссылок