diamond-turn-rightサイトリダイレクト

サイトリダイレクトを設定して、サイト内の任意のコンテンツにトラフィックを振り分けます

A GitBook screenshot showing site redirects
サイトのリダイレクトは、ドキュメントを移行したりコンテンツを再構成したりする際に、SEOに影響するリンク切れを避けるために役立ちます。

リダイレクトは、ドキュメントをある提供元から別の提供元へ移行する際によく使われます。たとえば、ちょうどドキュメントをGitBookへ移したときなどです。リンク切れはSEOに影響するため、必要に応じてリダイレクトを設定することをおすすめします。

に加えて GitBookによって作成された自動リダイレクト、サイトのドメイン内の任意のパスからリダイレクトを作成できます。

リダイレクトは次のいずれかとして作成できます。 公開 または 下書き。下書きリダイレクトを使うと、公開前にリダイレクトルールを準備して確認できます。下書きは、有効化されるまで公開サイトには影響しません。

サイトのリダイレクトを管理する

まず、GitBookでサイトのダッシュボードを開き、 設定 タブを開いてから、 ドメインとリダイレクト.

リダイレクトを作成する

クリック リダイレクトを追加 をクリックし、 手動 オプションを選択します。

次の項目を入力します。 ソースパス — リダイレクトしたいURLスラッグ — と、 遷移先 コンテンツの送信先。サイト内の任意のセクション、バリアント、ページを選択できます。

クリック リダイレクトを有効化 すると、リダイレクトがすぐに有効になります。

まだ公開せずにリダイレクトだけ作成したい場合は、代わりに 下書きとして保存 をクリックします。下書きリダイレクトは 下書き タブに表示され、後で有効化できます。

また、 ワイルドカードリダイレクト を作成することもできます。たとえば、ソースパスの末尾に * を追加します。例:

  • /docs/* で /docs/ 配下のすべてに一致

  • /changelog* で /changelog で始まるパスに一致

ソースパスにワイルドカード(*)が含まれる場合、次を有効にできます。 ワイルドカードを一致したテキストに置き換える.

  • オン: * に一致した部分が遷移先のパスに追加されます。

    • 例: ソース /docs/* → 遷移先 /help /docs/install は /help/install にリダイレクトされます

  • オフ: 一致したURLはすべて同じ固定の遷移先にリダイレクトされます。

    • 例: ソース /docs/* → 遷移先 /help /docs/install は /help にリダイレクトされます

同じページに別のリダイレクトを追加したい場合は、 別のリダイレクトを追加 をクリックする前に切り替えてください。 リダイレクトを有効化 または 下書きとして保存.

リダイレクトを追加すると、モーダルは開いたままになり、遷移先コンテンツは前回の選択に設定されたままなので、すばやく別のソースパスを追加できます。

リダイレクトを編集する

リダイレクトを編集するには、一覧でその横にある 編集 アイコンをクリックします。リダイレクトを更新し、変更を公開するには リダイレクトを有効化 をクリックします。

リダイレクトが現在 下書きの場合は、編集モーダルから直接公開することもできます。 リダイレクトを有効化.

下書きリダイレクトを有効化する

下書きリダイレクトは、リダイレクト表の 下書き タブに表示されます。

下書きリダイレクトは次の2つの方法で公開できます。

• リダイレクトを開いて、編集モーダルで リダイレクトを有効化 をクリックする。 • 表の トグル を使って、リダイレクトを直接有効にする。

有効化すると、リダイレクトは 公開 タブに移動し、すぐに訪問者の振り分けを開始します。

CSVからリダイレクトをインポートする

クリック リダイレクトを追加 と入力して CSVをアップロード.

次の列を含むCSVをアップロードします。 source, 遷移先と、任意の intent.

  • source はリダイレクトしたいパスです。たとえば /docs/site-redirects

  • 遷移先 は次のいずれかです。

    • 下のスクリーンショットに示すページの管理URLを使った特定のページ

    • 外部URL

    • 空欄。intent に応じて異なります

  • intent は次のいずれかです。

    • live。空欄のまま、または省略して、公開リダイレクトを作成・更新・削除します

    • draft。下書きリダイレクトを作成・更新・削除します

    • publish。既存の下書きリダイレクトを公開にします 遷移先 は空である必要があります。

ページのGitBook管理URLは、このメニューで確認できます

1回のインポートでサポートされる最大行数は500です。

CSVに重複するsource値が含まれている場合、最初の行のみが処理されます。インポートはupsertとして実行され、同じsourceを持つ既存のリダイレクトは更新され、まだ存在しないsourceには新しいリダイレクトが作成されます。

行の一部が失敗した場合は、右下のトーストからエラーCSVを取得できます。そこにはsource、destination、各エラーの簡単な説明が含まれているので、修正し、errors列を削除して再インポートできます。

CSVの例

source
遷移先
intent
結果

/docs/site-redirects

https://example.com/page

空欄

公開リダイレクトを作成または更新する

/docs/site-redirects

https://example.com/page

live

公開リダイレクトを作成または更新する

/docs/site-redirects

https://example.com/page

下書き

下書きリダイレクトを作成または更新する

/docs/site-redirects

空欄

公開リダイレクトを削除する

/docs/site-redirects

live

公開リダイレクトを削除する

/docs/site-redirects

下書き

下書きリダイレクトを削除する

/docs/site-redirects

publish

既存の下書きリダイレクトを公開する

自動リダイレクトについて

ページが移動または名前変更されると、その正規URLもそれに伴って変わります。コンテンツへのアクセス性を保つため、GitBookは自動的に HTTP 307arrow-up-right リダイレクトを古いURLから新しいURLへ作成します。

URLが読み込まれるたびに、GitBookは次の手順で解決します。

  1. サイトコンテンツは、自動作成されたリダイレクトをたどることで、その正規URLに解決されます。

  2. URLを解決できない場合、URLは スペースレベルのリダイレクトと照合されます。これはリポジトリの .gitbook.yaml ファイルで定義されています。

  3. 最後に、URLはサイトレベルのリダイレクトと照合されます。これは 上記の手順.

最終更新

役に立ちましたか?