URL移行後は、旧URLから新URLへの対応表を1つ作成し、それを使って公開リンク、canonical宣言、リダイレクト、サイトマップの項目を更新します。このMacデスクトップでの手順では、各変更の整合性を取り、公開後の結果を確認する方法を説明します。

ここでは、同じウェブサイト内で新しいパスに移動する、公開済みのHTML文書の小規模な集合を扱います。例に登場するアドレスとページ名はすべて架空のものです。手順全体を実施するには、公開システム、そのリダイレクト設定、および該当するSearch Consoleのプロパティへのアクセスが必要です。

移行後に整合させるもの

移動する文書ごとに、最終的な移転先を1つ選びます。管理しているリンクはその移転先を直接指し、移転先は自分自身をcanonicalとして示し、現在のサイトマップにはそのアドレスを記載します。旧アドレスからは移転先へリダイレクトします。Googleは、リダイレクトとcanonicalアノテーションを強い正規化シグナル、サイトマップへの掲載を弱いシグナルとして説明しています。これらの方法は互いを補強できますが、最終的にcanonicalを選ぶのはGoogleです。Googleのcanonical化に関するガイダンス。

これらの仕組みにはそれぞれ異なる役割があります。リダイレクトは旧アドレスへのリクエストを処理します。公開リンクは、読者が次にどこへ進むかを決めます。canonical宣言は文書の優先URLを示します。WHATWGはcanonicalリンクタイプについて、その意味を定義しています。サイトマップは、発見してもらうための優先URL一覧を提供します。いずれか1つを更新しても、ほかのものは編集されません。WHATWG HTML Standard: canonical link type、Googleのサイトマップに関するガイダンス。

この整合性確認表を、実務上の受け入れチェックとして使います。これはドキュメントに基づく作業手順であり、Googleの評価システムではありません。

対象 架空のColors文書で期待される結果
旧アドレス https://example.com/notes/colors.html から移転先へ恒久的にリダイレクトする
移転先 https://example.com/library/colors/ でColors文書を配信する
ナビゲーションと文書内のリンク https://example.com/library/colors/ を直接指す
移転先のcanonical https://example.com/library/colors/ を示す
現在のサイトマップの項目 https://example.com/library/colors/ を記載する

個々の設定を変更する前に対応表を1つ作る

Macでスプレッドシートまたはテキストエディタを開き、旧アドレスと移転先を並べて記録します。Googleは、サイト移転の一環として旧URLから新URLへの対応表を準備することを推奨しています。サイトマップの項目を置き換えても、リダイレクトがまだ必要なアドレスの記録が失われないよう、元の一覧のコピーを保管しておきます。Googleのサイト移転に関するガイダンス。

文書 旧パス 最終パス
Colors /notes/colors.html /library/colors/
Palette /notes/palette.html /library/palette/
Shapes /notes/shapes.html /library/shapes/

各行について、変更が必要な場所を記録します。ページエディタ、共通ナビゲーション、canonical設定、リダイレクト設定、サイトマップ生成機能です。公開時の応答とSearch Consoleでの検査用に、別々の確認欄も追加します。これにより、「URLを更新する」という曖昧な指示を、具体的な編集と確認事項の一覧に変えられます。

対応表を確定する前に、移転先のコンテンツを確認します。2つの旧文書を1つの有用な統合文書にまとめた場合は、両方からその文書へリダイレクトできます。無関係な文書を汎用ホームページへ転送することは避けてください。Googleは、関連性のないリダイレクトがソフト404として扱われる可能性があると警告しています。Googleのリダイレクト対応付けに関する推奨事項。

公開リンクを更新し、相対パスを確認する

公開エディタで対応表を使い、ナビゲーション、文書一覧、関連文書へのリンク、記事本文内のリンクを更新します。システムがページレコードからナビゲーションを生成する場合は、生成後の出力を何度も修正するのではなく、元のレコードまたはテンプレートを変更します。特に、旧パスが説明用の例にも登場する場合は、保存前に置換箇所を確認してください。

パスを変更すると、リンクテキストが同じままでも、相対リンクの移転先が変わることがあります。WHATWG URL Standardでは、相対参照はベースURLを基準に解決されます。以下の例では、文書に明示的なベースURLの上書きがないものとします。WHATWG URL Standard。

文書URL リンク値 解決後の移転先
https://example.com/notes/colors.html palette.html https://example.com/notes/palette.html
https://example.com/library/colors/ palette.html https://example.com/library/colors/palette.html
https://example.com/library/colors/ /library/palette/ https://example.com/library/palette/

これらの架空のURL解決結果は、JavaScriptのURL APIで確認しました。変更していないpalette.htmlの値は、現在Colorsディレクトリ内を指しているため、ほかの箇所でテキストを置換できていても、この問題は見逃されます。この小規模な文書群では、意図するルート相対パスを使うと移転先が明確になります。別のホストへ移動する場合は、正しい絶対アドレスを使うか、ルート相対リンクが引き続き意図したホストを指すことを確認してください。

Macのブラウザで公開済みのColors文書を開き、Paletteへのリンクをたどります。表示された文書と最終的なアドレスの両方を確認します。共通ナビゲーションや各セクションへのリンクについても同様に繰り返します。リンクが#swatchesを使う場合は、移転先に対応するセクション識別子が存在することを確認してください。パスの対応表だけでは、これを確認できません。

canonicalと恒久的なリダイレクトを設定元で指定する

新しいHTML文書ごとに、canonicalを最終的な絶対URLに設定します。Googleは絶対canonical URLを推奨しており、文書のhead内にあるHTML canonical要素を受け付けています。公開システムにcanonical欄がある場合は、そこにアドレスを入力し、生成された内容を確認します。Googleのcanonical実装手順。

Colorsページでは、次の内容は既存文書のhead内に配置するメタデータ断片です。HTMLページ全体ではありません。

<link rel="canonical" href="https://example.com/library/colors/">

ホストがHTTP Linkレスポンスヘッダーでもcanonicalを送信しているか確認します。Googleは両方の方法に対応していますが、宛先が競合する可能性があるため、どちらか一方を選ぶことを推奨しています。値を生成するテンプレートまたは設定を修正し、次回の公開時に旧アドレスへ戻らないようにします。Googleのcanonical化の方法。

旧アドレスが移転先へ恒久的なサーバー側リダイレクトを返すように設定します。RFC 9110は、301と308を恒久的なリダイレクトとして定義し、移転先をLocationヘッダーで示すと説明しています。両者はリクエストメソッドの扱いが異なります。308はメソッドを維持し、301は従来のPOSTからGETへの変更動作を許容します。通常の文書取得では、Googleはどちらも恒久的なリダイレクトのシグナルとして扱います。RFC 9110: HTTP Semantics、Googleのリダイレクトに関するドキュメント。

具体的な設定方法は、ホストまたは公開システムによって異なります。ブラウザ上での編集だけでは、HTTPレスポンスのルールを作成できません。利用中のプラットフォームでサーバー側リダイレクトを設定できない場合は、文書化されたホスティング設定を使うか、ホスティング事業者に対応表の実装を依頼してください。Googleは、サーバー側リダイレクトが利用できない場合の代替策として、即時のmeta refreshを案内しています。JavaScriptによるリダイレクトは、ほかの方法が使えない場合に限って推奨しています。canonical宣言だけでは、訪問者を新しいアドレスへ移動させられません。Googleがサポートするリダイレクト方法。

同じ移転先を使ってサイトマップを再生成する

サイトマップのソースを更新してから、再生成します。生成済みファイルを手作業で修正すると、次回のビルドで変更が失われやすくなります。この移行では、現在のサイトマップに旧パスではなく、最終的なColors、Palette、ShapesのURLを含める必要があります。

Googleでは、サイトマップに完全修飾された絶対URLを含め、UTF-8でエンコードすることを求めています。ウェブページの一覧だけが必要な場合は、テキスト形式のサイトマップも使用できます。見出しや説明を入れず、1行に1つのURLを記載します。架空の3ページをすべて含めた例は次のとおりです。

https://example.com/library/colors/
https://example.com/library/palette/
https://example.com/library/shapes/

Googleのサイトマップ形式と要件。

サイトですでにXMLサイトマップを生成している場合は、その対応形式を維持し、URLの項目を更新します。lastmodを指定する場合は、正確な更新日を使用してください。Googleによると、この値はページの大幅な更新を反映する必要があります。サイトマップを新しく見せるためだけに、すべての日付を自動的に置き換えないでください。GoogleのXMLサイトマップに関するガイダンス。

Macから公開後の結果を確認する

エディタのプレビューでは公開アドレスでのHTTP応答を確認できないため、デプロイ後の出力を確認します。Macでターミナルを開きます。次の診断コマンドには架空のアドレスを使っています。実行前に、自分の対応表にある該当する公開URLに置き換えてください。この例は、実際の移行結果を示すものではありません。

old_url='https://example.com/notes/colors.html'
new_url='https://example.com/library/colors/'

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --dump-header - --output /dev/null "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --location --max-redirs 5 --output /dev/null \
  --write-out 'status=%{http_code}\nfinal=%{url_effective}\nredirects=%{num_redirects}\n' \
  "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  "$new_url"

最初のコマンドは、リダイレクトをたどらずに最初のレスポンスヘッダーを表示します。2つ目はリダイレクトをたどり、最終的なステータス、アドレス、リダイレクト回数を報告します。3つ目は移転先のマークアップを取得し、確認できるようにします。これらのオプションはcurlマニュアルに記載されています。

単純な対応ページでは、最初に301または308が返され、意図したLocationが示された後、最終アドレスで文書が正常に配信されることを確認します。返されたマークアップでcanonicalも確認します。また、ブラウザで文書を読んでください。HTTPの成功応答だけでは、正しい内容が届いたことを証明できません。Googleは、リダイレクトの連鎖を作らず、最終的な移転先へ直接リダイレクトすることを推奨しています。RFC 9110: ステータスコード、Googleのサイト移転に関するガイダンス。

ある行の確認に失敗した場合は、次の診断順序を使います。観測できる出力に基づいて修正できます。

確認結果 次の対応
旧URLが意図しないページへリダイレクトする 対応表またはリダイレクトルールを修正する
リダイレクト先がさらに別のリダイレクトを返す 旧アドレスから最終的な移転先へ直接つなぐ
正しいページに古いcanonicalが設定されている メタデータの設定元を修正して再公開する
ナビゲーションがまだ旧パスへ移動する 元のリンクまたは共通テンプレートを更新する
サイトマップにまだ旧パスが記載されている 生成元の入力を修正して再生成する
ターミナルでタイムアウトが報告される 接続の問題を解決してから再確認し、テストは未完了として記録する

サイトマップを送信し、公開時の確認とインデックス登録を区別する

Search Consoleで、新しいURLを含むプロパティを選び、Sitemapsレポートを使って公開済みサイトマップのアドレスを送信します。Googleによると、このレポートでは送信に加え、処理エラーも確認できます。送信は発見を促すためのヒントであり、インデックス登録を保証するものではありません。Googleのサイトマップ送信手順。

新しい文書を検査するには、Search Consoleの検査バーに完全なURLを入力します。ライブテストを使って、現在アクセス可能か、インデックス登録が可能かを調べます。Googleが選んだcanonicalを確認するには、インデックス登録済みの結果と、その中のGoogle-selected canonical欄を確認します。ライブテストではcanonicalの選択結果を予測できません。Search Console URL Inspectionツール。

この例は同一ホスト内でパスを変更するため、Change of Addressツールは適用されません。Googleは、パスを移動する場合はリダイレクトを実装し、サイトマップを更新するよう案内しています。このツールは、サイト移転後にリダイレクトを設定したドメインまたはサブドメインの移転を対象としています。Search Console Change of Addressツール。

対応表は保守記録として保管します。公開リダイレクト、移転先のコンテンツ、リンク、canonical、サイトマップが整合した後にのみ、その行を完了としてマークします。Googleによるその後のインデックス登録状況は別に記録します。リダイレクトは可能な限り長く維持してください。Googleの一般的な移行ガイダンスでは、少なくとも1年間を推奨しています。今後の文書編集でも最終アドレスを使い続けます。Googleの移行に関するガイダンス。

出典