コーポレートサイトをHubSpotへ移行した翌月、オーガニック流入が半分に落ちた。原因を調べると、旧サイトで100本以上あった記事のうち、リダイレクトが設定されていたのは主要な十数本だけだった。残りは404のまま放置され、被リンクも検索順位もそこで切れていた。製造業や情報通信業の大手企業のサイト移行をご支援していると、この相談が一定の頻度で持ち込まれます。

URLリダイレクトは、移行プロジェクトの中でもっとも地味で、もっとも後回しにされやすい工程です。設定自体は管理画面の数クリックで終わるため、「あとでまとめてやればよい」と判断されます。しかし評価の引き継ぎは、設定した時点ではなくGoogleが再クロールした時点で効き始めます。後回しにした分だけ、順位が落ちている期間が長くなります。本記事では、HubSpotのURLリダイレクトツールの仕様と、Google検索セントラルが示す移行の作法を突き合わせ、私たちが移行案件で実際に踏んでいる手順を整理します。記載内容は2026年10月23日時点のものです。

なぜURLを変えると検索トラフィックが落ちるのか？

URLが変われば、検索エンジンから見ればそれは別のページです。旧URLが積み上げてきた評価は、新URLに自動では移りません。ページ・投稿・記事のURL変更は、アナリティクスの閲覧データをリセットし、ページの検索順位にも影響します。

ここで必要になるのがリダイレクトです。リダイレクトは「このページは別の場所に移りました」という宣言であり、ユーザーと検索エンジンの両方に対して機能します。宣言がなければ、旧URLは単なる存在しないページとして扱われます。

Googleはリダイレクトをどう解釈しているのか？

リダイレクトのタイプによって、Googleの扱いは変わります。永続的なリダイレクトは検索結果に新しいリダイレクト先を表示し、一時的なリダイレクトは検索結果にリダイレクト元のページを表示します。Googlebotはどちらも追跡しますが、インデックス登録パイプラインが「リダイレクト先が正規版である」というシグナルとして使うのは永続的なリダイレクトだけです。

手段は、Googleによって正しく解釈される可能性が高い順に並んでいます。永続的なものはHTTP 301（moved permanently）とHTTP 308、次いで遅延なしのmeta refresh、最後にJavaScriptのlocationです。一時的なものはHTTP 302（found）、HTTP 303、HTTP 307、そして遅延ありのmeta refreshです。このうちもっとも確実なのは、サーバー側のリダイレクトです。HTTPステータスコードそのものの定義はRFC 9110（HTTP Semantics）に規定されています。

HubSpotがホストするドメインでは、サーバー設定ファイルを直接触ることはできません。代わりにURLリダイレクトツールが同等の役割を果たし、301・302・305を選べます。つまりHubSpot上でも、Googleがもっとも確実に解釈するサーバー側リダイレクトを選択できます。

「評価を引き継ぐ」とは具体的に何が起きることなのか？

URLをリダイレクトすると、Googleはリダイレクト元と先の両方を記録し、どちらか一方が正規版、もう一方が正規URLの代替名になります。そして、ユーザーのクエリから古いURLのほうが信頼されていると解釈される場合、検索結果に代替名が表示されることがあります。

この仕様を知らないと、移行直後に「リダイレクトしたのに検索結果に旧URLが出ている」という報告が上がったとき、設定ミスだと判断して余計な手を加えてしまいます。これは正常な動作で、ユーザーが新しいドメイン名に慣れてくると代替ドメイン名は自動的に表示されなくなります。私たちが移行の進捗を社内説明する際は、この点を最初に共有しておくようにしています。

引き継ぎに時間がかかる理由もはっきりしています。サイト移転の完了を認識するために、Googlebotは新旧両サイトのすべてのURLに少なくとも1回アクセスする必要があり、移転はURLごとに行われます。一括で切り替わるものではありません。

HubSpotのURLリダイレクトツールで何ができるのか？

HubSpotのリダイレクト設定は、設定画面のコンテンツ配下にあるドメインとURLの「URL Redirects」タブに集約されています。ここが唯一の置き場であり、記事単位・ページ単位の設定画面には分散していません。移行プロジェクトでは、この1画面の運用ルールを決めることが実質的な設計作業になります。

標準リダイレクトとフレキシブルリダイレクトは何が違うのか？

リダイレクトの種類は2つです。標準（Standard）は1つのURLを別のURLへ転送するもの、フレキシブル（Flexible）はURLの構造に基づいて動的に転送するものです。

どちらを選ぶかは、対象URLの本数ではなく規則性で決まります。旧URLと新URLの間に機械的な対応関係があるならフレキシブル、スラッグが人手で付け替えられているなら標準です。私たちが移行案件でマッピング表を作るときは、まず規則性のある塊を切り出してフレキシブルで畳み、残りを標準で一件ずつ登録する順序を取っています。この順序にしないと、登録件数が無駄に膨らみます。

どのプランで使えて、権限は誰に渡すべきか？

URLリダイレクトの作成・管理には、URL Redirects権限が必要です。フレキシブルパターンURLリダイレクトが使えるのはMarketing HubのProfessional・Enterprise、およびContent HubのStarter・Professional・Enterpriseです。

権限の設計で私たちが推奨しているのは、URL Redirects権限を恒常的に持つユーザーを制限し、移行期間中だけプロジェクトメンバーに付与する運用です。リダイレクトは1件の設定ミスがサイト全体の到達性に影響する設定であり、かつ誰でも編集できてしまうと「気づいたら誰かが上書きしていた」という事故が起きます。設定時にはNote欄に作成理由を残すこともできます。

リダイレクトが効かないのはどんなケースか？

リダイレクトツールには、いくつかの制約と留意点があります。設計前に把握しておかないと、移行当日に想定外の404が出ます。前提として、リダイレクトが機能するのはHubSpotに接続済みのドメインに限られます。ドメインの接続はHubSpot側の設定画面で行い、接続済みのドメインはDomains APIでも一覧できます。

特に最後の2点は、プロジェクト計画に直結します。48時間という伝播の幅があるため、切替直後の数時間で動作確認を打ち切ると、誤った結論を出すことになります。

詳細オプションはどれを変えるべきか？

リダイレクト作成画面の「More options」を開くと、挙動を細かく制御する項目が並びます。既定値のままでも多くのケースは動きますが、移行のように大量のURLを扱う場面では、既定値が何なのかを知ったうえで意図的に選ぶ必要があります。

リダイレクトスタイル（301・302・305）はどう選び分けるか？

選べるリダイレクトスタイルは3種類です。Permanent（301）は1つのページURLを別のURLへ転送するもので、新規リダイレクトの既定値です。Temporary（302）は一時的な転送で、サイトのメンテナンスやリニューアル期間中のトラフィック退避に使われます。Proxy（305）は訪問者のブラウザに表示されるURLを変えずに、公開中のページのコンテンツを転送します。

移行で評価を引き継ぐ目的なら、選ぶのは301です。リダイレクトを元に戻す予定がない場合は、永続的なリダイレクトを使います。302を選ぶと検索結果には旧URLが残り続けるため、移行の目的を果たしません。

実務で302が必要になるのは、新サイトの公開を段階的に行い、一部セクションだけ旧サイトに戻す可能性がある場合です。この場合も、確定した時点で301に切り替える作業を計画に入れておきます。切り替えを忘れたまま運用が続いているポータルを、私たちは何度も見てきました。

優先度（Priority）はなぜ設計が必要なのか？

新規リダイレクトには既定で最も低い優先度が割り当てられ、同じ元URLに複数のリダイレクトが存在する場合は、優先度の値が小さいものが適用されます。優先度100と優先度1の2つが該当するなら、適用されるのは優先度1のほうです。

この仕様が効いてくるのは、フレキシブルリダイレクトと標準リダイレクトが同じURLに重なるときです。たとえばブログ全体を新サブドメインへ畳むフレキシブルリダイレクトを入れたうえで、特定の数本だけ統合先の別記事へ飛ばしたい場合、個別指定のほうに小さい優先度を与えなければ、フレキシブル側に飲み込まれます。

私たちがマッピング表を設計する際は、優先度を「個別指定」「部分パターン」「全体パターン」の3階層に分け、階層ごとに値の帯を決めてから登録します。帯を決めずに個別に数値を振ると、後から1件追加するたびに全体の整合を確認する羽目になります。

クエリ文字列・末尾スラッシュ・プロトコルの扱いをどう決めるか？

残りのオプションは、どのURLを「同じURL」とみなすかの定義です。既定値は次のようになっています。

この4つの既定値は、ほとんどの移行でそのまま使えます。意図的に変えるのはMatch query stringsだけだと考えてよく、残りを触る場合は理由を必ずNote欄に残してください。

フレキシブルパターンはどう書くのか？

フレキシブルパターンは、移行工数をもっとも大きく削れる機能です。一方で記法を誤ると、意図しないURL群まで巻き込みます。記法には代表的な3パターンがあるので、まずそれを理解してから応用します。

URL末尾をまとめて引き継ぐにはどう書くか？

特定パスの配下をまとめて転送しつつURLの残りを保持するには、元URLに *rest-of-url、転送先に {rest-of-url} を使います。

たとえば元URLフィールドに http://www.example.com/posts/*rest-of-url、転送先フィールドに http://blog.example.com/posts/{rest-of-url} と入力すると、http://www.example.com/posts/my-first-post が http://blog.example.com/posts/my-first-post へ転送されます。ブログを別サブドメインへ移す場面で、もっとも使用頻度が高い形です。

URLの構成要素を並べ替えるにはどう書くか？

コンポーネント（スラッシュで区切られたURLの各セグメント）を変数として扱うこともできます。元URLでコロン（:）を使って各コンポーネントを定義し、転送先では同じ変数名を波括弧で参照します。

たとえば元URLフィールドに http://www.example.com/:year/:month/:day/:post-name、転送先フィールドに http://blog.example.com/{month}/{day}/{year}/{post-name} と入力すると、日付の並び順を入れ替えた転送ができます。旧CMSが日付入りURLを出力していて、新サイトでは別の並びにしたい場合に使います。

なお、ピリオドを含むURLに対してURLマッピングを作成することは推奨されません。拡張子付きのURLが旧サイトに残っている場合は、フレキシブルではなく標準リダイレクトで個別に登録する判断になります。

クエリパラメータで振り分けるにはどう書くか？

クエリパラメータの値に基づいて転送することもできます。元URLフィールドに http://www.example.com/certification?promo_code=:promocode、転送先フィールドに http://www.example.com/enrollment?promo_code={promocode} と入力する形です。このときは詳細オプションのMatch query stringsをオンにする必要があります。

さらに、コンポーネントと末尾まとめ取りを組み合わせた複合パターンも書けます。複雑な記法ほど検証が重要になるため、本番登録の前に数本のURLで実際の転送先を確認する工程を、私たちは必ず計画に入れています。

サイト移行時の一括登録はどう進めるか？

数十本までなら管理画面で手入力しても構いませんが、数百本を超えるとCSVまたはAPIが現実的な選択肢になります。どちらにも制約があるため、本数と更新頻度で使い分けます。

CSV一括アップロードの制約は何か？

設定画面のImportからCSVを一括アップロードでき、サンプルCSVがテンプレートとして提供されています。制約は2つで、一度に追加・更新できるリダイレクトは最大500件、一括アップロードするURLは最大140文字までです。

加えて、挙動に癖があります。インポートファイルにエラーがあると、同じファイル内で正しく書式設定されているリダイレクトも含めて、1件もインポートされません。エラーが出た場合は、通知からエラーリストをダウンロードできます。

この「全件か、ゼロか」という挙動を踏まえ、私たちは一括登録を500件未満の束に分割し、束ごとにインポートする運用を標準にしています。1,000件を1ファイルで投げて全件失敗すると、原因特定に時間を取られます。また、既存のリダイレクトを上書きする場合は、フィールドマッピングの画面で「Overwrite existing redirects with same original URL」のチェックが必要です。

APIで登録するのはどんなときか？

/cms/v3/url-redirects に対しては、GET・POST・PATCH・DELETEの操作が用意されています。リクエストボディのパラメータとして routePrefix、destination、redirectStyle（301・302・305）、isOnlyAfterNotFound、isMatchFullUrl、isMatchQueryString、isPattern、isProtocolAgnostic、isTrailingSlashOptional、precedence が用意されています。

管理画面の詳細オプションが、そのままAPIのパラメータに対応しています。APIを使う判断基準は件数ではなく、再現性が必要かどうかです。移行を複数回のリハーサルで繰り返す場合や、サンドボックスと本番で同じリダイレクト群を維持する場合は、マッピング表からAPIで流し込む構成にしておくと、手作業の差分が発生しません。

URLマッピング表はどう作るか？

元URLの洗い出しには、定石となる調べ方があります。サイトマップを調べること、サーバーログや解析ソフトでトラフィックの多いURLを調べること、Search Consoleのリンク機能で内部リンクと外部リンクのあるページを確認すること、CMSからURL一覧を取得すること、そしてサーバーログで最近アクセスのあったURLを調べることです。

画像や動画、JavaScript・CSSファイルといった埋め込みコンテンツのURLも、移転計画に含めます。ここが抜けると、移行後に旧ドメインの画像を参照し続けるページが残ります。

新URLの構造そのものを見直す場合は、クロールとインデックス登録の観点から推奨されるURL構造が参考になります。移行は構造を直す数少ない機会でもあるため、マッピング作業と同時に検討する価値があります。

私たちがマッピング表を作るときの列構成は、旧URL・新URL・リダイレクト種別・優先度帯・根拠（流入があるか、被リンクがあるか）・担当・検証結果の7列です。根拠の列を入れておくと、「すべてのURLを等しく移す」のではなく、価値のあるURLから順に検証できます。移行の現場では、検証に使える時間が常に足りません。

リダイレクトチェーンはなぜ避けるべきか？

リダイレクトチェーンとは、AがBへ、BがCへ転送される多段構成のことです。動作としては最終的に目的のページへ到達するため、ブラウザで確認する限り問題は見えません。しかし検索エンジンから見ると、話は別です。

チェーンはどうやって発生するのか？

チェーンは意図して作られるものではなく、リダイレクトの積み重ねで自然に発生します。HubSpotでは、公開済みページ・ブログ・ブログ記事のURLを更新すると、システムリダイレクトが自動的に作成されます。ただし、自動生成されたシステムリダイレクトは編集できません。

つまり、記事のスラッグを2回変更すれば、それだけで2段のチェーンが残ります。そこにサイト移行のリダイレクトが重なれば3段です。リダイレクト一覧のDisplayフィルタでManual redirectsとSystem redirectsを切り替えられるので、棚卸しの際はまずシステムリダイレクトの量を把握してください。

クロールに悪影響を及ぼす長いリダイレクトチェーンは避けます。数万ページ規模のサイトほど、この影響が無視できなくなります。

すでにあるチェーンをどう畳むか？

畳み方そのものは単純で、中間のURLを飛ばして最初のURLから最終URLへ直接転送するよう書き換えます。問題は、システムリダイレクトが編集できない点です。この場合、同じ元URLに対して優先度の小さい手動リダイレクトを追加することで、意図した転送先を優先させる設計になります。

棚卸しの手順としては、エクスポート機能でリダイレクト一覧をCSVとして取り出し、元URLと転送先を突き合わせて、転送先が別のリダイレクトの元URLになっている行を抽出します。この作業は表計算ソフトで十分に回せます。

なお、移転でよくある誤りのひとつが、「新しいサイトで間違った（存在しない）URLにリダイレクトしている」ケースです。チェーンを畳む作業は、この誤りを検出する機会でもあります。

公開後、何をどう確認するのか？

リダイレクトは、登録して終わりではありません。評価の移行はGoogleの再クロールを待つ必要があり、その進捗を見る道具が別に用意されています。移行プロジェクトの完了条件を「設定完了」ではなく「移行の進捗が確認できた」に置くことを、私たちはクライアントに最初に合意していただいています。

Search Consoleでは何を見るのか？

Search Consoleでの監視項目も決まっています。サイトマップについては、旧URLのサイトマップと新URLのサイトマップの2つを送信し、時間の経過とともに旧URLのインデックス数がゼロに近づき、新URLのインデックスが増えていく様子を確認します。旧URLのサイトマップにはリダイレクトの警告が表示されることがありますが、これは正常で、無視して差し支えありません。

インデックスカバレッジのレポートでは、旧サイトの登録URL数が減り新サイトで増えるグラフを確認します。検索クエリのレポートでは、新サイトURLの表示回数とクリック数が増えていくかを見ます。サイトマップの作り方はサイトマップの作成と送信に、トラフィック減少時の切り分け手順は検索トラフィックの減少をデバッグするにまとまっています。

移転にあたって削除・統合したコンテンツは、移転先でそれらのURLがHTTP 404または410のエラーレスポンスコードを返すようにします。到達できないページをすべて別ページへ転送するのではなく、意図的にエラーを返す判断も設計のうちです。それぞれのコードの意味はHTTP ステータス コード、ネットワーク エラー、DNS エラーに整理されています。

アドレス変更ツールはいつ使うのか？

ドメインそのものが変わる移行では、Search Consoleのアドレス変更ツールが使えます。アドレス変更ツールは、移転リクエストの送信前に両方のサイトの所有者であることを確かめ、サイトのいくつかのページで301をチェックします。

アドレス変更のリクエストは、その180日後までの間ならキャンセルできます。キャンセル手順は、既存の301リダイレクト指定を削除し、新サイトから元サイトへの301リダイレクトを追加したうえで、元サイトのアドレス変更ツールで移行をキャンセルする、という順序です。

ドメインが変わらず、同一ドメイン内でURL構造だけを変える場合はこのツールの対象外です。その場合はリダイレクトとサイトマップだけで進めます。ホスティングのみを変える移転の手順は、URL の変更を伴わないサイト移転に整理されています。

HubSpot側のアナリティクスはどう見えるのか？

既存ページのURLを変更すると、それは別のページとして扱われ、指定した期間によっては旧URLと新URLの両方が表示されます。さらに、ページにカノニカルURLが設定されている場合、そのページへのビューはカノニカルURLに帰属します。複数のカノニカルURLがあるときは、ソースコード内の最初のカノニカルURLに帰属します。

ページレポートはクロールされたかビューを受け取ったすべてのURLの履歴データを表示するため、削除またはリダイレクトされたページもレポートに残り続けます。移行後に「ページ数が減らない」という指摘を受けることがありますが、これは仕様です。

HubSpot側で移行後の検出漏れを拾うには、SEO推奨事項も併用できます。カノニカルURLは、新規ページ・ブログ記事では既定でそのURL自身が設定されます。重複した URL を統合するとURL の正規化とはも併せて読んでおくと、リダイレクトとカノニカルの役割分担が整理できます。

サイトマップ側の設定はドメインのサイトマップ編集画面で行います。HubSpotは公開中のウェブサイトページとブログ記事を自動でサイトマップに追加しますが、ランディングページは自動追加されないため、手動で追加する必要があります。移行でランディングページを多く抱える組織は、ここが漏れやすいポイントです。

移行当日までに何を終わらせておくべきか？

最後に、私たちが移行案件で使っている工程の並びを示します。順序を入れ替えると手戻りが発生する箇所があるため、特に検証を後ろに置かないことを強くおすすめします。

各工程の所要期間はサイト規模と旧サイトの状態で大きく変わるため、ここでは順序と完了条件のみを示します。日数の見積もりは、URL本数と検証環境の有無が決まってから算出してください。

工程6の内部リンク更新は、サイト移転を開始したら直ちに、可能な限り多くのリンクを更新します。内部リンク、外部サイトへの依頼、SNSのプロフィールリンク、広告キャンペーンの遷移先が対象として挙げられています。リダイレクトに依存し続けると、チェーンの温床になります。

HubSpotへのサイト移行そのものの進め方はHubSpot CMSへウェブサイト移行をする方法で、ドメイン変更時のコンテンツ内URL置換はブランドドメインの置換方法で解説しています。移行後のSEO運用についてはHubSpotのSEOツールとはとSEOライティング解説も併せてご覧ください。

よくある質問（FAQ）

リダイレクトは何年間維持すべきですか？

維持すべき年数について、HubSpotの公式ナレッジベースおよびGoogle検索セントラルの公式ドキュメントに具体的な期間の記載は確認できませんでした。はっきりしているのは、移転はURLごとに行われ、Googlebotが新旧両サイトのすべてのURLに少なくとも1回アクセスする必要があるという点だけです。私たちは、Search Consoleで旧URLのインデックスがゼロになり、かつ旧URL経由の流入が消えたことを確認できるまでは外さない方針を取っています。

旧サイトが外部サーバーにある場合、HubSpotでリダイレクトできますか？

できません。URLリダイレクトはHubSpotに接続されホストされているドメインでのみ機能し、ドメインが外部でホストされている場合、HubSpotはリダイレクト要求を受け取りません。この場合は、ホスティングプロバイダ・CDN・DNSプロバイダ・サーバー、またはそのプラットフォームのリダイレクト機能で設定する必要があります。

記事を統合するとき、リダイレクトとカノニカルのどちらを使うべきですか？

統合して旧記事を公開停止にするならリダイレクトです。両方のページを残したまま優先版を伝えたいならカノニカルです。判断の基準は、旧URLにアクセスしたユーザーに何を見せたいかにあります。旧記事を残す理由がないなら、リダイレクトのほうが意図が明確に伝わります。正規化の各手段の位置づけは、重複した URL を統合するに整理されています。

リダイレクトを設定したのに、検索結果に旧URLが表示されます。失敗ですか？

設定の失敗とは限りません。サイトが新しいドメイン名に移転した場合、新URLがインデックスに登録されていてもGoogleが検索結果に引き続き古いURLを表示することがあり、これは正常な動作です。まず、該当URLが実際に301を返しているかをHTTPレスポンスで確認し、返っているなら時間を置いて再確認してください。

フレキシブルリダイレクトを入れたら、意図しないページまで転送されました。どうすべきですか？

パターンの適用範囲が広すぎる状態です。対処は2通りあります。パターン自体を狭いパスに切り直すか、除外したいURLに対して優先度の小さい個別リダイレクト（または同一URLへの転送）を追加するかです。同じ元URLに複数のリダイレクトが該当する場合は、優先度の値が小さいものが適用されます。

CSVインポートが全件失敗しました。どこから調べるべきですか？

インポートファイルにエラーがあると、同じファイル内の正しい書式のリダイレクトも含めて1件もインポートされません。通知からエラーリストをダウンロードできるので、まずそれを取得してください。頻出するのは、140文字の上限を超えたURL、フィールドマッピングの不一致、そして既存リダイレクトとの重複です。上書きが必要な場合は、マッピング画面で上書きのチェックを入れます。

ナレッジベースのドメインを変えます。記事URLは自動でリダイレクトされますか？

されません。ナレッジベースのルートURLやドメインの変更では、既存記事URLのリダイレクトは自動作成されません。ドメイン構成に基づいて、別途リダイレクトを設定する必要があります。記事本数分のマッピング表を作る前提で工数を見積もってください。

リダイレクトの設定権限は、制作会社に渡してよいですか？

移行期間中に限定して渡す運用を推奨しています。URL Redirects権限は、1件の設定でサイト全体の到達性を変えられる権限です。恒常的に外部へ付与するのではなく、期間と対象を決めて付与し、移行完了後に回収してください。あわせて、Note欄に設定理由を残すルールを合意しておくと、後からの棚卸しが成立します。

本記事に記載したHubSpotの仕様・上限値・サブスクリプション要件、およびGoogle検索セントラルの記述は、2026年10月23日時点の各一次情報に基づいています。これらは変更される可能性があるため、移行計画の根拠として用いる際は、必ず公式ドキュメントで最新の内容をご確認ください。