Rebrandly は単一の中心的な抽象概念を中心に構築されています：ブランドドメインです。スラッシュタグ、タグ分類法、トラフィックルーティングルールはすべてその下にぶら下がっています。この設計の選択は Rebrandly を一貫した製品にするものであり、同時に他のショートナーからの移行とは異なる点でもあります。
Rebrandly を離れるとき、あなたは主にリンクを移行しているのではありません。ドメインを移行しています。リンクはそれに付いてきます。リンクを保存する方法の詳細は、ドメインをどうするかという決定にほぼ完全に依存します。
この投稿では2つの現実的なパス、Rebrandly の API からのエクスポートの形、Elido へのバルクインポート呼び出し、カットオーバーを発表する前の検証プロセスを説明します。
TL;DR#
- Rebrandly の核心的な抽象概念はブランドドメインです。移行は第一に DNS 引き渡し、第二にリンク保存です。
- パス A：ドメインは同じで、ショートナーだけが変わる。Elido にスラッグを事前プロビジョニングし、CNAME を切り替えれば完了。
- パス B：ドメインも変わる。古いドメインからの 301 チェーン（Rebrandly Pro プラン）が必要か、新しいドメインでのスラッグ変更を受け入れる必要がある。
- Rebrandly のタグは Elido のタグに直接マッピングできます。Rebrandly のカテゴリーは手動マッピングが必要です - 直接的な同等物がありません。
まずインベントリが必要なもの#
どちらのパスにもコミットする前に、4つのものを把握してください。
ブランドドメインまたは複数のドメイン。 Rebrandly のワークスペースモデルではアカウントごとに複数のカスタムドメインが許可されます。エージェンシーまたはマルチブランドのワークスペースでは、各ドメインは個別の移行単位です。カットオーバーウィンドウを計画する前にそれらを列挙してください - 一度にすべてよりも1ドメイン/夜の方が安全なスケジュールです。
アクティブなリンク。 大きなインベントリには CSV エクスポートではなく Rebrandly REST API（2026-05-12参照）を使用してください。/v1/links エンドポイントは last と limit クエリパラメーターでページネーションし、スラッシュタグ、宛先、ドメイン名、タグセット、createdAt を含む完全なリンクオブジェクトを返します。ワークスペース設定パネルからの CSV エクスポートは数百件以下のリンクには問題ありませんが、より大きなエクスポートではフィールドの切り詰めが一貫しません。
インテグレーション。 チームが Zapier、Make、または Workato のワークフローを通じてリンクを作成している場合、それらのコネクターは Rebrandly の API を指しています。それぞれを再設定する必要があります。これはリンク移行とは別のタスクで、独自の猶予ウィンドウがあります。DNS 切り替えの前ではなく後に対処してください。
タグとカテゴリー分類法。 Rebrandly は自由形式のタグと構造化されたカテゴリーの両方をサポートしています。タグは Elido のタグに一対一でマッピングされます。カテゴリーは Elido に直接的な同等物がありません - 最も近いマッピングは、インポート中に適用する予約タグプレフィックス（cat:campaign、cat:region）です。スクリプトを実行した後ではなく前にマッピングに合意してください。
パス A：ドメインはそのまま、ショートナーだけ変わる#
これがクリーンな移行です。go.acme.com（またはブランドショートドメイン）を維持します。同じドメインで Elido にすべてのスラッグを事前プロビジョニングし、CNAME を切り替えます。リンククリックの観点からは何も変わりません - スラッグは異なるエッジを経由するだけで、同じ宛先 URL に解決されます。
ステップ1：Rebrandly からエクスポート#
Rebrandly /v1/links API をページネーションして走査してください。レスポンスオブジェクトには slashtag、destination、domain.fullName、tags[]、category.name、createdAt が含まれます。JSONL として保持してください。
慎重に扱う必要があることが2つあります。まず domain.fullName - ワークスペースに複数のドメインがある場合、このパスで移行するドメインにフィルタリングしてください。次に、Rebrandly の料金プラン（2026-05-12参照）はアカウントごとのアクティブなリンク数とカスタムドメイン数をゲートします。API は関係なくすべてのリンクを返します。インベントリには、すでに廃止したドメインのリンクが含まれている可能性があります。インポート前にそれらをフィルタリングしてください。
ステップ2：Elido での事前プロビジョニング#
DNS に触れる前にカスタムドメインフローで Elido ワークスペースにドメインを登録してください。ドメインはまだライブである必要はありません。Elido は DNS TXT レコードを通じてドメイン所有権を確認します。Rebrandly を指す既存の CNAME を中断することなくそれを完了できます。
ドメインが登録されたら、リンクをバルクインポートします。POST /v1/links/bulk エンドポイントは1回の呼び出しで最大100リンクを受け入れ、アイテムごとの成功/失敗を返すため、1行のスラッグ競合でバッチ全体が中断されません。Rebrandly のスラッシュタグを保存するために slug を明示的に渡してください。Rebrandly の tags[] を Elido の tags[] に直接マッピングしてください。履歴ソートの元の作成タイムスタンプを保存するために created_at を渡してください。
curl -X POST "https://api.elido.app/v1/links/bulk" \
-H "Authorization: Bearer $ELIDO_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: rebrandly-migration-batch-001" \
-d '{
"workspace_id": "ws_xxxxxxxxxxxx",
"domain_id": "dom_xxxxxxxxxxxx",
"links": [
{
"slug": "summer-promo",
"destination_url": "https://acme.example/summer",
"tags": ["campaign", "q3", "rebrandly-migrated"],
"created_at": "2025-07-01T09:00:00Z"
},
{
"slug": "hero-cta",
"destination_url": "https://acme.example/hero",
"tags": ["homepage", "rebrandly-migrated"],
"created_at": "2025-03-15T14:30:00Z"
}
]
}'
rebrandly-migrated タグはカットオーバー後の analytics フィルタリングに便利です - Elido でネイティブに作成されたリンクから移行前のリンクをセグメント分けして、最初の30日間のクリックトレンドを比較できます。
カテゴリー分類のマッピングについて：summer-promo が Campaigns という Rebrandly カテゴリーにあった場合、tags 配列に cat:campaigns を追加してください。意味的には同等ではありませんが、Elido の analytics とダッシュボードビューでフィルターが提供されます。移行メモにマッピングを文書化してください。
まずドライランを行ってください。ほとんどのチームは、完全なインベントリを送信する前にステージングワークスペースまたは小さなサンプル（10〜20リンク）に対してバルクインポートを実行します。バルクエンドポイントのアイテムごとのレスポンスサーフェスは、エクスポート全体をコミットする前にスラッグ競合や宛先検証エラーをきれいに表示します。
ステップ3：DNS カットオーバー#
ここが重要な瞬間です。ここに到達する前に以下を確認してください：
- バルクインポートのすべてのスラッグが成功ステータスを返した。失敗が残っていない。
- ドメインが登録され、Elido ワークスペースで TLS がプロビジョニングされている。本番ドメインではなくテストサブドメインに CNAME を一時的に追加して、Elido エッジに対して1つのスラッグを直接テストしてください。
- 既存の Rebrandly CNAME TTL が下げられている。Rebrandly の料金ページ（2026-05-12参照）では、DNS 設定が Free プランから利用可能であることが示されています - アップグレードなしで TTL を下げられます。カットオーバーウィンドウの少なくとも24時間前に300秒に下げてください。
ウィンドウが開いたら CNAME ターゲットを切り替えます：
go.acme.com. 300 IN CNAME edge.elido.me.
Elido のエッジは自動オンデマンド TLS を実行しています。事前確認中に TLS がすでにプロビジョニングされている場合（推奨）、DNS 伝播後の最初のリクエストは高速です。そうでない場合、証明書は最初のリクエスト時にプロビジョニングされます - 通常1〜3秒、その後証明書がキャッシュされ、以降のリクエストは EU リージョンのエッジから p95 15ms 以下で提供されます。
変更ウィンドウを閉じる前に複数のリゾルバーから確認してください。デスクからの伝播チェックはリゾルバーのみを確認します。dig @8.8.8.8 go.acme.com CNAME や dig @1.1.1.1 go.acme.com CNAME のようなツールは一般的な乖離を検出します。
パス B：ドメインも変わる#
一部のチームは移行をブランドドメインの名称変更の機会として使います - brand.ly（Rebrandly 割り当てのサブドメイン）から完全に所有するものへ、またはリブランド後に別のブランドドメインへ。あるいは Rebrandly のサブドメイン（yourname.rebrandly.com）を使っていてカスタムドメインをまったく設定していなかった場合もあります。
いずれの場合も、スラッグ空間が変わります。問いはリンク切れを最小化するために古いドメインから 301 チェーンを設置できるかどうかです。
オプション B1：古い Rebrandly ドメインからの 301 チェーン#
Rebrandly のトラフィックルーティング機能 - Pro プランで利用可能 - を使用すると、ドメイン全体を新しいベース URL にリダイレクトできます。古いドメインを所有していてトラフィックを転送したい場合、Rebrandly でワイルドカードリダイレクトを設定して、スラッグマッチングで go.old-domain.com/* のすべてのリクエストを go.new-domain.com/* に転送できます。
RFC 7231 §6.4.2 は 301 Moved Permanently のセマンティクスを定義しています：301 を受け取ったクライアントは、保存されている URL を新しい場所に更新すべきです。実際には、これは既存の QR コード、印刷物、公開されたリンクが重複期間中に正しくリダイレクトされることを意味します。ドメインが変わるときに透明な移行に最も近いものです。
仕組み：重複期間中は古いドメインを Rebrandly でライブに保ち、パススルーリダイレクターとして設定します。移行初日から Elido で新しいドメインを実行します。30〜90日後（公開資料がどれだけ長く流通するかによって）、Rebrandly で古いドメインを廃止します。
オプション B2：スラッグ変更を受け入れる#
古いドメインが Rebrandly 割り当てのサブドメイン（yourname.rebrandly.com）か、DNS コントロールをもはや持っていないドメインである場合、301 チェーンは利用できません。古いドメインのリンクは、Rebrandly が稼働していてアカウントをアクティブに保っている限り機能し続けます。古いリンクへのトラフィックは Elido を経由しません。そのアナリティクスのカバレッジが失われます。
実際のアプローチ：新しいドメインで Elido にリンクリストを移行し、最高トラフィックのリンクに新しいスラッグを作成して重要な公開サーフェスを更新し、低トラフィックの古いリンクの長いテールを Rebrandly で自然消滅させます。migrate-from-bitly-playbook では Bitly の移行についての同じ意思決定フレームワークを説明しています - 理由付けはここでも適用できます。
オプション B1 と B2 の間で決断するチームの場合、計算は：古いリンクを含む公開サーフェスがいくつあるか、それらを更新するのがどれほど難しいか、そしてそれらのサーフェスへのトラフィックがどれだけ長く続くかです。高トラフィックのメールアーカイブリンクや印刷物は B1 を支持します。いくつかの内部ドキュメントは B2 を支持します。
Rebrandly のエクスポート：得られるものと得られないもの#
Rebrandly API（2026-05-12参照）は /v1/links 経由でリンクごとに以下のフィールドをエクスポートします：
id- Rebrandly の内部リンク ID（インポートには不要ですが、べき等性キーとして便利）slashtag- 保存するスラッグdestination- UTM パラメーターを含む完全な宛先 URLdomain.fullName- カスタムドメインのホスト名tags[]- 自由形式のタグ。Elido のタグに直接マッピングcategory.name- カテゴリーラベル。タグプレフィックスに手動マッピングcreatedAt、updatedAt- タイムスタンプ。createdAtを Elido のcreated_atフィールドに渡すclicks.total- ライフタイムクリック数。Elido の analytics にはインポートできませんが、タグ（clicks-baseline-1234）または独自のデータレイヤーに保存する価値があります
API がエクスポートしないもの：
- 生のクリックイベント。Rebrandly はクリックごとのレコードを公開していません - 集計カウントのみです。analytics の時計はカットオーバー日から Elido で新たに始まります。
- トラフィックルーティングルール。リンクに条件付きリダイレクト（デバイスやジオルーティング）を設定していた場合、それらのルールはインポート後に Elido のスマートリンクエディターで手動で再作成する必要があります。バルクルーティングルールのインポートはありません。
- チームメンバーの権限。Elido でワークスペースアクセスを再招待する必要があります。
生のクリックイベントがない制約は、リンクを壊さずに Bitly から移行するで直面するのと同じ制約です。処理パターンも同じです：Rebrandly のライフタイムカウンターを保存し、カットオーバー以降の Elido クリックを追跡し、過去の合計を報告するときに組み合わせます。
ウェブフックの再配線：Zapier、Make、Workato#
自動化ワークフローのいずれかが Rebrandly リンクを作成している場合、それらを再設定する必要があります：見込み客ごとにトラッキングリンクを作成する CRM トリガー、スプレッドシートからリンクを短縮する Zap、イベント用 QR コードを生成する Make シナリオ。
メカニズムはプラットフォームによって異なります。Zapier では、Rebrandly アプリを使用するすべての Zap を見つけ、アクションステップを Elido の Zapier アプリ（ローンチ時の可用性を確認）または POST /v1/links を直接呼び出す Webhook アクションに置き換えてください。Make と Workato でも同じ置き換えが適用されます。
ここで正しくシーケンスする2つのこと。まず、事前プロビジョニングが完了する前に Elido に対して自動化を再設定しないでください。事前プロビジョニングが完了する前に Elido に対して自動化を実行すると、スラッグの重複競合が発生します。次に、切り替えの前に（カットオーバーウィンドウ中ではなく事前に）すべての自動化プラットフォームのクレデンシャルストアに Elido API キーを追加してください。
猶予ウィンドウ：低頻度（週数件）でリンクを作成する自動化については、DNS カットオーバー後1〜2週間 Rebrandly に残しても低リスクです。作成するリンクは古いプラットフォーム上になりますが、DNS はすでに切り替わっているため、それらのリンクは Elido 経由で解決されます。1日に数十件のリンクを作成する高頻度の自動化については、カットオーバー日に移行してください。
Elido の API と利用可能な SDK については、料金ページでプランの制限を確認でき、完全な API リファレンスは /help にあります。TypeScript、Python、Go SDK が利用可能です。
カットオーバーを発表する前の検証#
構造的なスポットチェックを行う前に移行完了を発表しないでください。2つのことがサイレントに壊れます：エクスポートでエンコードの問題があった宛先 URL と、バルクインポート中に衝突してスキップされたスラッグです。
トップ100スラッグチェック#
clicks.total 降順でエクスポートされたリンクリストを並べ替えてください。上位100を取得します。それぞれについて、Elido がホストする URL に HEAD リクエストを発行し、Location ヘッダーが期待される宛先と一致することを確認してください：
curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
"https://go.acme.com/summer-promo"
正しい宛先 URL を持つ 301 レスポンスは、スラッグが機能していることを確認します。404 は、スラッグが事前プロビジョニングされていないか（バルクインポートのレスポンスログを確認）、大文字小文字の一致の問題があることを意味します。Rebrandly のスラッシュタグは解決時に大文字小文字を区別しません。Elido のスラッグは作成時に大文字小文字を区別します。エクスポートに混合ケースのスラッシュタグがある場合、インポート前に小文字に正規化してください。
30日間のロールバック計画#
DNS カットオーバー後30日間 Rebrandly アカウントをアクティブに保ってください。DNS の変更はそのウィンドウ中いつでも完全に可逆的です - CNAME を Rebrandly のエッジに戻すと、古いリンクは再び機能します。30日後、analytics がリダイレクト成功率に異常がなく、スラッグチェックが合格していれば、Rebrandly アカウントをダウングレードまたはキャンセルしても安全です。
ドメインについて：移行ウィンドウ中にドメインレジストラーを現在の場所から移転しないでください。CNAME の変更が唯一必要な DNS 操作です。レジストラー移転はカットオーバー中に不必要な伝播リスクを追加します。
内部移行コンテキスト#
この移行の仕組みは Bitly プレイブックと並行しています。DNS パターン、TTL タイミング、スラッグ保存のアプローチは同じです。移行作業にコミットする前に機能レベルで移行を評価している場合、elido-vs-rebrandly 比較では料金モデルの違いと EU 居住地のギャップを詳しく説明しています。/features/custom-domains のカスタムドメインセットアップドキュメントでは DNS 確認と TLS プロビジョニングの Elido 側を説明しています。/pricing には現在のプラン制限があります - 大きな Rebrandly インベントリを事前プロビジョニングするには、インポートを開始する前に適切なプランが必要です。
引用：Rebrandly API ドキュメント 2026-05-12参照。Rebrandly 料金ページ 2026-05-12参照。RFC 7231 §6.4.2 - HTTP 301 Moved Permanently。
Elidoを試す
URLを貼り付けて短縮リンクを取得
登録不要。リンクは30日間有効。永久に保存するには登録してください。
Free、登録不要 · 1日あたり2件