Bitlyから移行：リンクを壊さない完全ガイド

Bitlyから移行してリンクを壊さないためには、まずリンクを2種類に分けます。自分の独自ドメイン上のリンクは移せます。スラッグを新しいツールにインポートしてからDNSレコードを1つ変更すれば、まったく同じURLが引き続き解決されます。共有ドメインbit.ly上のリンクは移せません。このホスト名はBitlyが所有しているためで、メールやPDF、印刷物にそのURLが残っている間は、Bitlyのアカウントを維持し続けることになります。インポート自体は数分で終わります。カレンダー上の時間は、DNSのキャッシュと、何かを解約する前のソーク期間に使います。

このガイドの残りは、移行が訪問者から見えないまま終わるかどうかを左右する細部です。エクスポート、フィールドのマッピング、衝突ルール、リダイレクトのステータス、DNSのタイミング、ターミナルからの検証、ロールバックを扱います。Bitlyに関する事実はBitlyのヘルプセンターとAPIリファレンス（accessed 2026-10-02）によるもので、Elidoに関する事実はインポーターとリダイレクトのコードによるものです。

私はAnaで、Elidoで移行を担当しています。ルールは単純です。どう移すかの前に、何が移せるかを決めてください。移行先をまだ選んでいる段階なら、機能比較はElidoとBitlyの比較にあります。

Bitlyから移せるもの、移せないもの

短縮URLはホスト名とスラッグの組み合わせです。リンクの行き先を自分で制御できるのは、ホスト名を自分で制御している場合だけです。そのため3つのケースがありますが、実際の移行になるのは1つだけです。

bit.lyのリンクについて現実的な目標は「移す」ことではなく、「新しく作るのをやめる」ことです。乗り換える必要が出る前にブランドドメインを設定しておくのが、このテーマ全体で最も安上がりな保険です。

ステップ1：Bitlyのリンクを棚卸ししてエクスポートする

壊れうるものをすべて洗い出すところから始めます。短縮リンク（スラッグ、遷移先、タイトル、タグ、グループ。1つのアカウントが複数のグループを持てるため、忘れられたグループは忘れられたドメインになります）、Bitlyのリンクを配信しているすべての独自ドメイン（Bitlyの設定だけでなく、DNSゾーンも確認してください）、印刷済みのQRコード（BitlyのQRコードはリンクが生きている限り動作し続けますが、印刷物が最も変更しにくい）、そしてバイオページ（独自のURLを持ち、リンクのエクスポートには含まれません）です。

エクスポートはBitly APIをGeneric Access Tokenで使い、グループごとに1つずつ行います。GET /v4/groups/{guid}/bitlinks?size=100はリンクのページとpagination.nextのURLを返し、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に対応付け、衝突ルールを選ぶ

ElidoのBitlyインポーターがリンクごとに引き継ぐのは4つです。スラッグ、遷移先URL（20件でUTMを抜き取り確認してください）、タイトル（200文字で切り詰め）、タグで、さらにフィルターや一括編集用にimported:bitlyタグが付きます。

引き継がれないものは、累計クリックカウンター（自分のスプレッドシートに保存してください）、作成日、QRデザイン（QRデザイナーで再生成）、バイオページ（バイオページで再構築）、キャンペーンやディープリンクの設定（キャンペーンとして作り直し）です。

スラッグの大文字小文字と衝突の罠

Bitlyはbit.ly/CustomWordとbit.ly/customwordを別のリンクとして扱います。これはBitlyのヘルプセンターで確認できます。Elidoはスラッグをドメインごとに大文字小文字を区別せずに保存し、インポートされた表記は保持するため、大文字小文字だけが違う2つのBitlyリンクは衝突します。bit.ly/Promoが/springを指し、bit.ly/promoが/autumnを指している場合、Promoは問題なくインポートされ、promoは衝突します。その後の動作は衝突ルールが決めます。

• Suffix（デフォルト）はpromo-2、promo-3と順に試し、最大50回まで続け、それでもだめならエラーを報告します。公開URLを黙って変更してしまいます。印刷済みのpromoリンクはすべて春のページを表示するようになり、秋のリンクは誰も印刷していないpromo-2に置かれます。
• Skipは既存のリンクに手を付けず、Bitlyの行をスラッグと理由とともに記録します。
• Failは最初の衝突でジョブ全体を停止します。

印刷されたスラッグを正確に保つ必要がある場合は、skipまたはfailを選び、衝突を1件ずつ手作業で解決してください。

ステップ3：リンクをElidoにインポートする

規模や元のデータに応じて、リンクを取り込む方法は3つあります。

• Bitlyインポーター。 Integrationsから「Bitly migration」を開き、Generic Access Tokenを貼り付け、グループ、移行先ドメイン、衝突ルールを選んで開始します。フォームの手順はBitly移行ページで説明しています。
• ダッシュボードの一括登録とCSV。 「New link」ダイアログは、1バッチ最大100件のURLを、1行に1つずつ、またはCSV（url、slug、title）で受け付けます。スプレッドシートを使う方法はGoogleスプレッドシートからの一括インポートで解説しています。
• API。 POST /v1/workspaces/{workspace_id}/links/bulkは1回の呼び出しで最大100件のリンクを受け付け、項目ごとに成功か失敗かを報告します。

インポーターの動作

Bitlyのグループごとに1つのジョブを実行してください。ジョブは50,000件または30分で停止します（これは安全上の制限であり、料金プランの上限ではありません）。それより大きいアカウントはグループごとに分けてください。トークンは実行中だけメモリに保持され、その後破棄されます。各ジョブは、インポート済み、スキップ、失敗の件数を報告します。partialステータスは一部の行が失敗したことを意味し、エラー一覧（上限1,000件）にどの行がなぜ失敗したかが記載されます。30分間進捗がないジョブは、スイープ処理によって失敗とマークされます。suffixとskipでは再実行しても安全です。インポート済みのリンクは検出されるためです。保存したカーソルからの再開は計画中で、現状では中断したジョブは単に再実行します。

同じジョブの仕組みで、Rebrandly、Short.io、TinyURL、Dubのインポーターも動いています。

まず小さなグループをインポートし、最も価値の高い遷移先にまたがる20件のリンクを実際にクリックして確認してください。リハーサルにかかるのは半日ですが、衝突するスラッグを見つけられるのはここです。

インポート後のリンク一覧。タグで絞り込めます。DEMOワークスペースの合成サンプルデータであり、顧客の実績ではありません。

ステップ4：DNSを切り替え、リダイレクトを維持する

このステップが必要なのは、自分のドメイン上のリンクだけです。DNSを変更した後、https://links.yourbrand.com/slugへのリクエストは、まさにそのスラッグをすでに保持しているサービスに届かなければなりません。そのため、インポートが先でDNSの変更が後です。ツールによってはこの順序が逆になります。Short.ioの方式では、まず自分のドメインを向こうに向け、誰かがクリックしたときに初めてBitlinkをコピーします。そのため、移行期間中に誰もクリックしなかったリンクは転送されません。先にインポートしておけば、この空白を避けられます。

Elidoにドメインを登録すると、_elido-verify.<hostname>のTXTレコードと、edge.elido.meへのCNAMEが発行されます。両方が解決されるとドメインが検証され、どちらかが欠けていると検証プログラムは24時間後にあきらめます。CNAMEが切り替えそのものなので、検証は切り替えの前ではなく、切り替えの時点で完了します。フォームは独自ドメイン設定ガイドで確認できます。

TTLの計算

DNSの応答は、レコードのTTLが許す限りキャッシュされます（RFC 1035、セクション3.2.1）。したがって、古い情報が残る最悪の期間は、変更前のTTLに等しくなります。86400秒のままのCNAMEは、丸1日の間、訪問者をBitlyに送り続ける可能性があります。D-2にTTLを300秒に下げ、現在の向き先を書き留めてください。自分のゾーンからコピーします。これがロールバック用の値です。D0に本番インポートを実行し、その後CNAMEを入れ替えてTXTレコードを追加します。5〜10分後に、ドメインが検証済みと表示されることを確認し、HTTPSでリンクをリクエストします。ソーク期間中はTTLを300のままにしておきます。

切り替え中の301と302

Bitlyは自社のリンクを301（恒久）リダイレクトと説明しています。Elidoではリンクごとに301、302、307を選べます。インポーターは何も設定しないため、インポートされたリンクは302で始まります。これは切り替えに適しています。RFC 9110、セクション15.4.2によると、301はヒューリスティックにキャッシュ可能ですが、302はデフォルトではキャッシュされません（セクション15.4.3）。初日に301へ切り替えてからロールバックすると、その応答をキャッシュしたすべてのクライアントは、古い行き先に向かい続けます。

ソーク期間中は302のままにし、その後、遷移先が今後変わらないリンクを、imported:bitlyタグで選択して一括で301に切り替えます。SEO上の違いが問題になる場面は301と302のリダイレクトで解説しており、情報源はGoogleのリダイレクトに関するドキュメントです。二重ホップにも注意してください。リクエストがElidoに届く前にHTTPSを強制するプロキシーが、ホップを1つ増やすことがあります（リダイレクトチェーンと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

次に、リダイレクトを追跡せずに1件確認します。curl -s -o /dev/null -D - --max-redirs 0 https://links.yourbrand.com/SummerSaleです。期待するのは302（または選んだステータス）と、エクスポートと一致するlocation:ヘッダーです。404ならスラッグがインポートされておらず、200ならリダイレクトではなくページが返っています。

3つ目に、Bitlyから取得したデータで作ったslug,destinationの2列CSVを使い、エクスポートした全スラッグをループで確認します。

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"

末尾のスラッシュの不一致は見た目だけの問題です。直すのはリンクではなく、比較の側にしてください。ループは最初の1時間後、翌朝、1週間後に実行し、稼働中のチャネルごとに1つのスラッグを、そのチャネルでの大文字小文字そのままの表記で手作業でテストしてください。

承認は、担当エンジニア以外の人が行います。インポート数とスキップ数と失敗数の合計が、絞り込んだエクスポートと一致すること。失敗した行がすべて修正済み、または意識的に破棄されていること。サンプリングした50件のリンクでUTMが保持されていること。累計クリック数上位20件のリンクが手動のクリックテストに合格すること。印刷済みのQRコードがスキャンできること。リダイレクトが有効なHTTPSで1ホップであること。Bitlyの累計カウンターが日付付きで保存されていること。

切り替え日を決める前に、衝突を落ち着いて直せる時間があるうちに、ワークスペースを開始してリハーサルのインポートを実行してください。

ステップ6：移行後の分析で何が起きるか

クリック履歴は引き継げず、どのインポーターでもこれは変えられません。Bitly APIはBitlinkごとに2つのクリックエンドポイント、GET /v4/bitlinks/{bitlink}/clicksとGET /v4/bitlinks/{bitlink}/clicks/summaryを文書化していますが、どちらも時間で区切った集計値を返すだけで、個々のイベントは返しません。クリックごとの行がなければ、過去のリファラー、国、デバイスを再構築する方法はありません。レポートに必要な過去のクリックは、GA4または自前のデータウェアハウスに保存すべきです。

Elidoは、DNSがElidoを指した時点からクリックを数えます。切り替え前に、重要なリンクごとに累計カウンターを日付付きで保存し、すべてのグラフに切り替え日を注記してください。その後は監視します。最初の週は毎日、404と、切り替え前の同じ曜日と比べたクリックの落ち込みを確認し、それ以降は週次で、ベースラインと保存したカウンターに照らして確認します。Elidoが標準でレポートする内容は分析機能のページにあります。

分析の概要。30日間にわたり、1日あたりとホスト別のクリック数を確認できます。DEMOワークスペース、合成データです。

ステップ7：ロールバックを用意し、Bitlyの解約は最後にする

Bitlyを解約するまでは、ロールバックできます。きっかけは事前に合意しておきます。たとえば、原因不明のクリック減少が2日間30%を超えた場合や、上位20件のリンクのいずれかが壊れた場合などです。操作は、古いCNAMEの向き先を戻すことです。TTLが300秒なら、ほとんどのリゾルバーは約5分で追随し、302のままにしていたので、誤った方向を指すキャッシュ済みの301もありません。切り替え後にElidoで作成したリンクは、Bitlyには存在しないため、先にエクスポートしてください。

Bitlyを早く解約しすぎると何が壊れるか

Bitlyのヘルプセンターの説明は具体的で、操作の順序が重要です。bit.lyのリンクはアカウント削除後も動作し、スラッグも再利用できませんが、編集やリダイレクトの変更はできなくなり、メトリクスも失われます。独自ドメインのリンクは、DNSがまだBitlyを指している間だけ動作します。BitlyはSSL証明書の更新を止めるため、訪問者にはやがて「保護されていない通信」の警告が表示されます。なお、ダウングレード（削除とは別）で止まるのは、そのドメインでの新規リンク作成だけです。無償提供ドメインは更新されないため、そのドメイン上のリンクは期限切れで壊れます。Bitlyはこの期限を、発行または最終更新から1年後としています。それ以外はアカウントとともに失われます。編集できなくなったQRコード、Bitly Pages、エクスポートしなかったレポートなどです。

先にDNSを移し、上記のチェックで確認してから、解約またはダウングレードしてください。アカウントは少なくとも90日間は維持します。Bitlyの料金を見れば、保険として保持する最も安いプランを選べます。

ブログの関連記事

• 5分でTLS付きの独自ドメインを設定する
• 短縮リンクの301と302リダイレクト
• Googleスプレッドシートから短縮リンクを一括インポートする
• Rebrandlyから移行：スラッグを失わないブランドドメインの引き継ぎ
• リダイレクトチェーンとSEO

出典：アカウント削除、ダウングレード、リンクの大文字小文字の区別、301リダイレクトに関するBitlyヘルプセンターの記事、およびBitly APIリファレンス（accessed 2026-10-02）。Elidoの動作は、2026-10-26時点のインポーターとリダイレクトのコードを読んで確認したものです。