Переезд с Bitly без поломки ссылок: руководство по режимам сбоев

Ана Ковальска - инженер по решениям в Elido, которая курировала десятки проектов по миграции с Bitly. Она считает, что большую часть проблем можно избежать, если провести аудит до переноса, а не после.

В руководстве по миграции с Bitly описана стратегическая канва: аудит ресурсов, экспорт, импорт, переключение DNS. Этот пост - лучшее место для начала, если вы никогда раньше не занимались миграцией с Bitly.

Этот пост другой. Он сфокусирован на том, что ломается - специфических режимах сбоев, которые возникают, когда концептуальный план готов и вы начинаете работать с реальными данными в продакшене. Семь из них встречаются постоянно, и все семь можно предотвратить, если знать, куда смотреть.

TL;DR#

Слаги Bitly чувствительны к регистру; многие платформы редиректов - нет. bit.ly/AbCd и bit.ly/abcd - это разные ссылки в Bitly, и они будут вести себя по-разному, если ваш скрипт импорта приведет слаги к нижнему регистру.
Разрывы DNS TTL вызывают паузу в работе редиректов даже после переключения CNAME. Снизьте TTL до 60 секунд как минимум за 24 часа до переключения, а не за пять минут.
Вебхуки, указывающие на эндпоинты api-ssl.bitly.com, перестанут работать в тот момент, когда вы отмените или деактивируете аккаунт Bitly. Переподключите всех потребителей данных до того, как измените статус аккаунта.
Диплинки с сегментами пути (bit.ly/app/account/settings) конфликтуют с любыми правилами маршрутизации Elido, которые также соответствуют префиксу пути. Проводите аудит слагов диплинков отдельно от стандартных слагов редиректов.

Семь вещей, которые на самом деле ломаются#

Прежде чем обсуждать инструменты, полезно иметь перед глазами таксономию сбоев. Большинство постмортемов миграций указывают на один из этих пунктов:

1. Чувствительность слага к регистру. Bitly сохраняет регистр в слагах - bit.ly/SummerSale и bit.ly/summersale являются разными ссылками. Если ваш скрипт импорта нормализует слаги к нижнему регистру (распространенное поведение в библиотеках обработки URL), вы незаметно создадите неправильный слаг, и вариант с заглавными буквами выдаст 404. Это затронет email-кампании, где слаг был встроен в смешанном регистре.

2. Поведение завершающего слеша. bit.ly/campaign/ и bit.ly/campaign обрабатываются Bitly как одна и полная ссылка. Некоторые платформы рассматривают вариант с завершающим слешем как отдельный путь. Если ваш воркспейс Elido находится за реверс-прокси со строгой нормализацией URL, запрос с завершающим слешем может разрешиться иначе, чем канонический слаг.

3. Сохранение строк запроса. Если URL назначения в Bitly уже содержит параметры запроса - https://acme.example/landing?source=bitly - а клик также несет UTM-параметры, добавленные при расшаривании, вам нужно убедиться, что слияние ссылок в Elido работает идентично. По умолчанию Bitly объединяет добавленные UTM с существующей строкой запроса. Проверьте это явно для любой ссылки, чей URL назначения уже содержит параметры.

4. Добавление UTM на уровне платформы. Корпоративный уровень Bitly поддерживает добавление UTM на уровне воркспейса: каждый исходящий редирект получает UTM независимо от того, что содержит исходный URL назначения. Если это было включено в Bitly и вы это не задокументировали, ваша аналитика может зависеть от UTM, которые Elido еще не добавляет. Проверьте настройки воркспейса в Bitly на наличие правил автодобавления перед экспортом. Эквивалентом в Elido являются шаблоны UTM на уровне воркспейса или кампании - на странице функции пользовательских доменов описано, где находятся эти настройки.

5. Разрыв DNS TTL. Это самая частая причина паузы в редиректах при переключении. DNS-резолверы кэшируют старый CNAME на время действия текущего TTL. Если ваш TTL составлял 86400 секунд в течение двух лет, изменение его на 300 секунд за пять минут до переключения A-записи означает, что большинство резолверов все еще будут хранить старую запись еще 23 часа и 55 минут. Переключение не мгновенно; оно должно распространиться.

6. Переподключение вебхуков. Любая система, потребляющая события вебхуков Bitly - конвейеры аналитики, задачи обогащения CRM, атрибуция заказов Shopify - работает через URL эндпоинта Bitly. Этот эндпоинт отключится, когда вы отмените или понизите тариф аккаунта Bitly ниже уровня, поддерживающего вебхуки. Конфигурация вебхуков Bitly находится на уровне аккаунта и не экспортируется вместе с данными ссылок. Каждого потребителя нужно инвентаризировать и переподключить вручную.

7. Конфликты путей диплинков. Мобильные диплинки часто используют путь короткого URL для кодирования состояния навигации в приложении - bit.ly/app/profile/edit может указывать на назначение вроде yourapp://profile/edit. Когда вы переносите эти слаги в Elido, слаг app/profile/edit содержит слеши. Роутер Elido может обрабатывать пути, разделенные слешами, иначе, чем непрозрачные слаги Bitly. Убедитесь, что слаги диплинков с сегментами пути создаются как точные строки слагов, а не интерпретируются как вложенные пути.

Предмиграционный аудит: сегментация по уровням риска#

Bitly API (доступ от 2026-05-12) предоставляет данные о количестве кликов по ссылке через GET /v4/bitlink/{bitlink}/clicks/summary. Прежде чем экспортировать и импортировать что-либо, используйте это для сегментации вашего инвентаря.

Практическая сегментация:

Критически важный уровень (топ 1%): ссылки с количеством кликов ≥10× от медианного значения за последние 30 дней. Они активны в письмах, печатных материалах, на платных лендингах. Они требуют ручной проверки после переключения, а не только автоматических тестов.
Уровень мониторинга (следующие 9%): ссылки с объемом кликов выше медианного. Автоматической проверки 301 достаточно, но помечайте любые ссылки с неожиданным поведением.
Массовый уровень (оставшиеся 90%): слаги с низким или нулевым трафиком. Проверяйте программно; допустите небольшой процент ошибок и исправляйте по мере поступления отчетов.

Экспортируйте сводку кликов за 30 дней для каждой ссылки на этапе инвентаризации. Простой цикл пагинации через Bitly API reference (доступ от 2026-05-12) позволит получить эти данные; поле link_clicks в эндпоинте групп билинков - это пожизненный счетчик, который менее точен, но достаточен для сортировки:

# Paginate all links in a Bitly group and write to JSONL
NEXT_URL="https://api-ssl.bitly.com/v4/groups/${GROUP_GUID}/bitlinks?size=100"
while [ -n "$NEXT_URL" ]; do
  RESP=$(curl -s -H "Authorization: Bearer ${BITLY_TOKEN}" "$NEXT_URL")
  echo "$RESP" | jq -c '.links[]' >> bitly-links.jsonl
  NEXT_URL=$(echo "$RESP" | jq -r '.pagination.next // empty')
done

Отсортируйте вывод по link_clicks в порядке убывания. Топ 1% - это ваш критически важный уровень. Экспортируйте их слаги в отдельный файл перед запуском массового импорта.

Сохранение слагов: критический вызов API#

Эндпоинт массового импорта Elido POST /v1/links/bulk принимает поле slug для каждой ссылки. Если вы не установите его явно, Elido сгенерирует новый случайный слаг - что является неправильным поведением для миграции. Всегда передавайте исходный слаг.

# Bulk import with slug preservation - 100 links per call
curl -s -X POST "https://api.elido.app/v1/links/bulk" \
  -H "Authorization: Bearer ${ELIDO_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: mig-batch-$(date +%s)" \
  -d '{
    "workspace_id": "'"${WORKSPACE_ID}"'",
    "domain_id": "'"${DOMAIN_ID}"'",
    "links": [
      {
        "slug": "SummerSale",
        "destination_url": "https://acme.example/summer",
        "tags": ["bitly-migrated", "campaign-summer"]
      },
      {
        "slug": "AbCd",
        "destination_url": "https://acme.example/landing",
        "tags": ["bitly-migrated"]
      }
    ]
  }'

В этом вызове стоит обратить внимание на две вещи. Во-первых, значения слагов "SummerSale" и "AbCd" переданы в смешанном регистре точно так же, как они отображались в Bitly. Не приводите их к нижнему регистру. Во-вторых, заголовок Idempotency-Key означает, что вы можете безопасно перезапустить частичный пакет; Elido вернет существующую ссылку, а не создаст дубликат. Это правильный паттерн для миграции, которую может потребоваться возобновить.

Для критически важного уровня запускайте импорт интерактивно для каждой ссылки, а не пакетом, и проверяйте каждую перед продолжением. Для массового уровня делайте пакеты по 100 ссылок на вызов и обрабатывайте массив ошибок в ответе, чтобы отловить любые конфликтующие или неудачные слаги.

Переключение DNS без простоев#

Переключение DNS - это момент, когда смещается живой трафик. При правильном исполнении пользователи не замечают прерываний. При устаревшем TTL возникает задержка, измеряемая часами, а не минутами.

Последовательность имеет значение. См. диаграмму таймлайна ниже.

Horizontal DNS cutover timeline showing T-7d TTL drop to 60s, T-0 A record flip, T+5min 95% propagation, T+1h TTL restore, T+24h audit pass

Таймлайн в деталях:

Т−7 дней: Снизьте TTL для записи CNAME или A до 60 секунд. Это критический шаг, который большинство команд пропускает. RFC 1034 §3.6 (IETF datatracker, раздел о кэшировании записей ресурсов) определяет TTL как максимальную длительность кэширования, в течение которой резолвер может хранить запись. Если ваш текущий TTL равен 86400 (один день), изменение вступит в силу только после истечения срока действия текущей кэшированной версии. Вам нужно снизить TTL как минимум за один полный период текущего TTL до переключения. Одна неделя - это надежно; 24 часа - минимум.

Т−1 час: Убедитесь, что низкий TTL распространился. Используйте инструмент вроде dig @8.8.8.8 links.yourbrand.com +ttl как минимум с трех разных эндпоинтов резолверов. Сообщаемый TTL должен быть около 60 секунд.

Т−0: Замените цель CNAME с края Bitly на край Elido. На стороне Elido домен уже должен быть зарегистрирован и верифицирован в вашем воркспейсе - не переключайте DNS до того, как край Elido будет готов принимать трафик. Первый запрос после распространения инициирует автоматический выпуск TLS-сертификата по запросу, что занимает примерно 2–3 секунды для этого конкретного запроса. Последующие запросы попадают в кэш и разрешаются за считанные миллисекунды на краю в регионе ЕС.

Т+5 минут: Проведите выборочную проверку из другой сети (используйте мобильную точку доступа, чтобы обойти кэш резолвера вашего офиса). curl -sI https://links.yourbrand.com/any-known-slug должен вернуть 301 Moved Permanently, указывающий на ожидаемое место назначения, полученное из заголовков края Elido.

Т+1 час: Верните TTL к его обычному рабочему значению (300 или 3600 секунд). Постоянное поддержание TTL на уровне 60 секунд создает дополнительную нагрузку на вашего DNS-провайдера и инфраструктуру резолверов.

Т+24 часа: Запустите полный аудит слагов (см. следующий раздел).

Согласно RFC 7231 §6.4.2, ответ 301 Moved Permanently может кэшироваться посредниками бесконечно, если только явный заголовок cache-control не переопределяет это. Это означает, что любой клиент, который зашел на старое место назначения Bitly во время разрыва TTL, мог кэшировать 301, указывающий на инфраструктуру Bitly. Эти кэшированные редиректы разрешаются корректно, пока инфраструктура Bitly жива, именно поэтому важно окно наложения аккаунтов Bitly в 30 дней.

Аудит цепочки 301: ежедневная автоматическая проверка#

После переключения запускайте цикл ежедневной проверки для вашего критически важного уровня. Цель - отловить любой слаг, поведение которого изменилось: возвращает неожиданное назначение, выдает 404 или создает цепочку редиректов длиннее двух прыжков.

# Verify top slugs resolve correctly via Elido
# top-slugs.txt: one slug per line, no protocol prefix
DOMAIN="links.yourbrand.com"
FAIL=0

while IFS= read -r slug; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    --max-redirs 0 \
    "https://${DOMAIN}/${slug}")
  LOCATION=$(curl -s -I --max-redirs 0 \
    "https://${DOMAIN}/${slug}" \
    | grep -i '^location:' | tr -d '\r' | cut -d' ' -f2)

  if [ "$STATUS" != "301" ]; then
    echo "FAIL [$STATUS] $slug → expected 301"
    FAIL=$((FAIL + 1))
  else
    echo "OK  [301] $slug → $LOCATION"
  fi
done < top-slugs.txt

echo "---"
echo "Failures: $FAIL"
exit $FAIL

Запускайте этот скрипт для критически важного уровня (обычно 50–200 слагов для большинства команд) каждую ночь в течение первых двух недель после переключения. Направьте вывод в канал оповещений. Если FAIL не равен нулю, нужно, чтобы человек проверил это до пика утреннего трафика.

Флаг --max-redirs 0 используется намеренно: вам нужен редирект от Elido, а не конечное место назначения. Если Status равен 200 вместо 301, значит, что-то на стороне Elido обслуживает назначение напрямую, а не через редирект. Это стоит изучить.

Для уровня мониторинга проводите более легкое еженедельное сканирование. Для массового уровня полагайтесь на отчеты об ошибках из нижестоящих систем - битые ссылки в письмах вызывают изменения в показателях отказов, которые зафиксирует ваша email-платформа.

Переподключение вебхуков#

Вебхуки Bitly описаны в Bitly API reference (доступ от 2026-05-12) в разделе Webhooks. Каждый вебхук срабатывает на события кликов и включает поля bitlink, referrer и user-agent. Типичные потребители:

Shopify: приложения для атрибуции, которые отслеживают, какая короткая ссылка привела к конверсии. Настраиваются в админ-панели приложения Shopify и указывают на сторонний эндпоинт, который вызывает проверку вебхука Bitly.
Stripe: некоторые конвейеры атрибуции биллинга помечают входящие пробные подписки данными UTM из исходной короткой ссылки, полученными через вебхук Bitly.
Slack: боты для отслеживания эффективности ссылок, которые публикуют сводки кликов в канал #marketing.
Кастомные ETL-конвейеры: любые конвейеры хранилищ данных, которые принимают события кликов Bitly для обогащения данных или объединения атрибуции.

Контрольный список миграции для вебхуков:

Экспортируйте конфигурацию вебхуков Bitly до любых изменений аккаунта. Вызов Bitly API GET /v4/workspaces/{workspace_guid}/webhooks вернет список. Сохраните его в файл.
Для каждого потребителя определите URL эндпоинта, принимающего события Bitly, и секрет, используемый для проверки HMAC.
Настройте эквивалентный эндпоинт вебхука Elido. Схемы полезной нагрузки вебхуков Elido отличаются от схем Bitly - поля похожи, но не идентичны. Настройте обработчик потребителя для приема новой схемы.
Запустите оба вебхука параллельно в период наложения. Настройте Elido на отправку вебхуков начиная с дня переключения, сохраняя вебхук Bitly активным. Ваш потребитель будет получать два события на клик в период наложения - дедуплицируйте по короткому URL + метке времени или примите двойной учет в период наложения как известный артефакт.
После 72 часов подтвержденной доставки вебхуков Elido удалите конфигурацию вебхуков Bitly из каждого потребителя.

Период грации для ротации секретов - это время наложения. Не ротируйте секрет вебхука Elido, пока каждый потребитель не будет проверен. Ротация секрета до обновления одного из потребителей означает, что этот потребитель будет незаметно отбрасывать события без ошибок - проверка HMAC не пройдет, и большинство обработчиков вебхуков отбрасывают нагрузки с невалидной подписью без оповещения.

План отката: сохраняйте Bitly живым в течение 30 дней#

Процедура отката проста: верните DNS CNAME на цель Bitly. Поскольку вы заранее подготовили снижение TTL и запись DNS все еще находится на уровне 60 секунд (пока вы ее не восстановите), откат DNS распространится менее чем за две минуты.

Подготовьте команду отката до начала:

# Rollback script - run this to revert DNS to Bitly (adapt for your DNS provider)
# Route 53 example using AWS CLI
aws route53 change-resource-record-sets \
  --hosted-zone-id "${HOSTED_ZONE_ID}" \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "links.yourbrand.com",
        "Type": "CNAME",
        "TTL": 60,
        "ResourceRecords": [{"Value": "cname.bitly.com"}]
      }
    }]
  }'

Храните это в файле на своем ноутбуке и в общем репозитории руководств перед переключением. Худший момент для написания инфраструктурных команд - во время активного инцидента.

Оставляйте аккаунт Bitly активным на платном тарифе, поддерживающем работу ссылок, в течение 30 дней после переключения. Руководство по миграции с Bitly рекомендует 90 дней; 30 - практический минимум для команд, которым нужно контролировать расходы. В течение 30-дневного окна любой трафик, который все еще разрешается через Bitly (кэшированные редиректы, старые ссылки bit.ly в печатных материалах), продолжает работать. Через 30 дней оцените остаточный трафик Bitly в вашей аналитике и решите, стоит ли продлевать.

Что отслеживать в течение 30-дневного окна:

Уровень ошибок Elido на вашем кастомном домене (следите за неожиданными 404 в логе доступа).
Любые всплески трафика в Bitly (дашборд Bitly показывает трафик; всплеск может означать, что кэшированный редирект все еще разрешается через Bitly для высокообъемного слага).
Уровни ошибок потребителей вебхуков для всех потребителей, которых вы переподключили.

Постмиграционный аудит: что логировать#

После 30-дневного окна проведите финальный аудит. Что должно быть в логе аудита:

Проверка	Метод	Критерий прохождения
Количество слагов совпадает	`wc -l bitly-export.jsonl` против счетчика Elido API	В пределах 1% (учитывая намеренно удаленные архивные ссылки)
Проверка 301 критического уровня	Скрипт ночного аудита	Ноль сбоев в течение 7 дней подряд
Выверка объема кликов	Сравнение общего числа кликов Elido за 30 дней с данными Bitly за тот же период прошлого года	В пределах ожидаемых сезонных колебаний
Подтверждение потребителей вебхуков	Убедиться, что каждый потребитель получает события Elido и обрабатывает их корректно	Отсутствие скрытых потерь в течение 7 дней
DNS TTL восстановлен	`dig +ttl links.yourbrand.com`	TTL на рабочем значении (300+ секунд)

Запишите это в таблицу аудита вашей команды. Если ваш воркспейс находится на тарифе Business или Enterprise, лог аудита Elido фиксирует все операции API во время импорта и доступен через API. Извлеките записи пакетов импорта и сохраните снимок вместе с этой таблицей.

Распространенные ошибки: три примера из практики#

Ecommerce-бренд из DACH, потерявший неделю email-атрибуции. Ритейлер из Германии запустил рассылку, используя слаги Bitly с UTM для каждого подписчика, добавленными в момент отправки. Скрипт миграции привел все слаги к нижнему регистру перед импортом в Elido. После переключения email-платформа генерировала ссылки с оригинальными слагами в смешанном регистре. Эти ссылки возвращали 404 от Elido, так как регистр слага не совпадал. Решением было повторно запустить импорт со слагами, сохранившими регистр, но к тому времени трафик из писем за семь дней попал на 404. Атрибуция для этой когорты была невосстановима. Урок: тестируйте одну живую ссылку из каждого активного канала перед объявлением миграции завершенной.

SaaS-стартап с тройным редиректом для мобильных пользователей. Команда роста использовала кастомный домен Bitly за Cloudflare в режиме прокси (оранжевое облако). После переключения мобильные пользователи получали три редиректа: Cloudflare → Elido edge → место назначения. Дополнительный прыжок возник из-за Cloudflare Page Rule, которое переписывало HTTP на HTTPS перед передачей в Elido, после чего Elido выдавал свой собственный 301. iOS Safari кэшировал промежуточный редирект Cloudflare как постоянный на 30 дней. Решением было перевести запись Cloudflare в режим серого облака (DNS-only) и удалить конфликтующее Page Rule. Кэшированным редиректам в Safari потребовалось 30 дней, чтобы истечь естественным путем. Проверяйте режим прокси вашего CDN до переключения, а не после.

Агентство, пропустившее группу Bitly. Агентство управляло тремя брендами клиентов под одним аккаунтом Bitly, каждый в своей группе Bitly со своим кастомным доменом. Скрипт миграции запросил только группу по умолчанию - ту, для которой был создан токен пользователя API. Два клиентских домена мигрировали чисто. Третий, находящийся в дополнительной группе, так и не был экспортирован. После переключения вышла email-кампания по запуску продукта, указывающая на немигрированный кастомный домен. У домена все еще был CNAME Bitly с полным TTL, и Bitly корректно обслуживал ссылки - но окно переключения для этого домена уже было объявлено закрытым. Пришлось проводить экстренную повторную миграцию в дедлайн. Урок: перечислите все группы через GET /v4/user/groups перед началом любого этапа экспорта. Убедитесь, что токен имеет доступ к каждой группе.

Что дальше#

Руководство по миграции с Bitly охватывает полную стратегическую последовательность для команд, начинающих планирование миграции с нуля. Этот пост - дополнение о режимах сбоев; используйте их вместе.

Что касается продукта, на который вы мигрируете, страница solutions/marketers описывает функции атрибуции и отслеживания кампаний, к которым стремится большинство проектов миграции. Страница /compare/vs-bitly является справочником по паритету функций, если вы все еще подтверждаете целесообразность перехода.

Если вы оцениваете Elido наряду с Rebrandly или Short.io, сравнение elido-vs-bitly охватывает компромиссы по цене и функциям для четырех объемов трафика. Страница функции пользовательских доменов детально описывает механизмы верификации DNS и предоставления TLS - стоит прочитать перед вашим окном переключения DNS.

Сбои миграции почти всегда можно предотвратить. Скрипт аудита, дисциплина TTL и инвентаризация вебхуков занимают два часа работы до переключения. Они экономят дни реагирования на инциденты после него.

Цитаты и источники

Bitly API Reference - dev.bitly.com/api-reference, доступ от 2026-05-12
RFC 1034 - Domain Names: Concepts and Facilities, §3.6 (resource record caching) - datatracker.ietf.org/doc/html/rfc1034
RFC 7231 §6.4.2 - HTTP/1.1 Semantics and Content: 301 Moved Permanently - datatracker.ietf.org/doc/html/rfc7231#section-6.4.2
Bitly API - Groups and Bitlinks endpoints - dev.bitly.com/api-reference, доступ от 2026-05-12

Попробуйте Elido

Вставьте URL - получите короткую ссылку

Без регистрации. Ссылка живёт 30 дней. Зарегистрируйтесь, чтобы оставить её навсегда.

Бесплатно, без регистрации · 2 в день