サイト移行チェックリスト：T-4週間から公開後45日まで

404で終わる301は何も保持しない

一部のチームは、すべての旧URLを新しいホームにリダイレクトし、先ページの有効期限を後で設定します。リダイレクト自体は機能します。しかし、これはリスクを伴う習慣です。なぜなら、ログ上では各ホップが正常に見える一方で、最終的なページが404を返す可能性があるためです。

店舗を新しいドメインに移転し、まだ売れている商品だけを残すケースを考えてみましょう。外部リンクの大部分が集まっていたカテゴリページは、今や意味のない宛先にリダイレクトされています。何かを廃止する前に、外部リンク付きのURLを数え上げてください。これを最初のステップにしてください。リンク元を持つページには、同じトピックに関する有効な宛先が必要です。

ルールを簡潔に保ちましょう：1ホップで、最終的に200ステータスコードを返すこと。それ以外は、あなたが選んだ漏れです。

ライブページへの1ホップ301リダイレクトが保護するもの

リンクの価値は、それが指すURLの上にあります。リダイレクトはその価値を運びますが、それは着地先のアドレスが応答し、かつトピックと一致している場合に限り適用されます。同じカタログ内の同じ製品に移動した製品はテストに合格しますが、誰もがリンクしていたページであるにもかかわらず、ホームページに送られた製品は通常合格しません。

テンプレート変更のたびに最終ステータスを再確認してください。ローンチ時には機能していたリダイレクトも、メニューの整理中にカテゴリが削除された後のリリース後に404になることがあります。

誠実な答えとして410が適する場合

リンクも訪問数も、そして実質的な代替品もない古いURLがあります。それらについては、古いページが答えていた質問に答えなくなるページへのリダイレクトよりも、明確な404または410の方が誠実です。無関係なページへのリダイレクトはしばしばソフト404として扱われるため、何も救済されません。

各URLグループの判断と、その理由を記録してください。廃止されたチュートリアルのフォルダと、80のリンク元ドメインを持つページのフォルダでは、異なる対応が必要です。6ヶ月後に同僚にその違いを説明したくなるはずです。

最初のホップだけでなく、最後のホップも確認する

ほとんどのリダイレクトテストは最初の応答で止まりますが、それは止まるべき場所ではありません。チェーンの最後まで追跡し、ホップ数と最終ステータスを古いURLの横に記録してください。2ホップのチェーンは壊れていませんが、遅延を加え、ルールが失敗する可能性のある箇所をもう1つ増やします。

スクリプトが手元にない場合は、スプレッドシートと数回のcurl呼び出しで十分です。APIスクリプトページには、スケジュール実行できるバージョンがあります。

ローンチ後のサイトマップと手動リクエスト

移転後数週間は古いサイトマップにアクセス可能にしておきましょう。古いホストを再訪するクローラーは、そのリスト内のアドレスをまだ見つけることができ、リダイレクトの最初のパスが高速化されます。

手動リクエストは異なるツールです。最も重要な数ページに使用し、数百のURLを1つずつ送信するために使用しないでください。内部リンクがなく、本文が薄いリクエストされたページは再びインデックスから外れる傾向があるため、リクエストの価値は背後にあるページの品質にかかっています。

待つことも有効な計画です。クロールに時間を与え、データに基づいて判断してください。

古いサイトマップをしばらくリストしておく

古いURLがクロール統計に表示されなくなるまで、Search Consoleに古いサイトマップを残してください。その後、意図的に削除し、移行ログに日付を記録してください。

プロパティを整理したように見せるために、ローンチ日に削除しないでください。早期の削除は、まだ追跡する必要のあるすべての古いURLを列挙する唯一のリストを隠してしまいます。

リンクを持つページへのインデックスリクエスト

リダイレクトマップの構築に使用したのと同じ結合を使用して、外部リンクが最も多い20件の新しいURLを選択し、手動でリクエストしてください。ここでは、サイトの規模ではなくリスクに基づいて労力を配分します。

リクエストしたページが数週間後もまだインデックスされていない場合は、再度リクエストする前にページ自体を確認してください。内部リンク、canonical、コンテンツを確認してください。5回目のリクエストは何も変えません。

移転の判断はいつ下すか

移転の判断は、最初のバックリンク取得ではなく、2回目の取得に基づいて行ってください。当社のインデックスは約1ヶ月に1回更新されるため、3日目の取得は主に先月の状況を示します。更新後に2回目の取得を実行し、新しいホスト上のすべてのバックリンクを特定してください。

Pagesレポートとリンクデータは異なる質問に答えます。同じ移転に対する競合する判決としてではなく、並べて読み取ってください。

公開前だけでなく、公開後のサイト監視

公開前の監査は、実行日に真実だったものを記録します。公開後のダメージの大部分は、プラグインの更新、CDNルールの変更、または誰もレビューしていない設定に触れたテンプレート之后に現れます。

公開後の監視を、保存されたベースラインに対する小さな差分のセットとして扱ってください。ダッシュボードは必要ありません。スケジュールと日付付きファイルのフォルダがあれば十分です。

週次監視で比較すべきもの

変更した場合に最も大きな影響を与えるチェックを選び、毎週同じ日に実行してください。

• 上位50件のリンク元古いURLのステータスコードと最終URL
• メインテンプレートのrobots.txtとrobotsメタタグ
• ライブ200 URLの数と新しいサイトマップ内の数の比較
• ホームページ、1つのカテゴリ、1つの記事のcanonicalタグ

単発の監査がなぜ緩やかなドリフトを見逃すか

公開後に設定がドリフトします。テストフラグがオンになったまま、パーマリンクを書き換えるプラグイン、または1ページを修正するために追加されたリダイレクトなど、計画の一部を無効にする可能性があります。公開日に実施された監査では、それらすべてを見ることができます。

スケジュールされた差分比較であれば可能です。ベースラインファイルをバージョン管理に保持し、毎週の出力をそれらと比較してください。そうすれば、予期せぬ変更が発生した日に可視化できます。

サブドメイン、削除、およびサイト全体のドメイン変更

一部のチームはセクションをサブドメインに移し、人気のあるページのみをインデックスします。これは機能する可能性があります。その代償として、静かなページへのリンクは、履歴の少ないホストに到達するため、何かを切る前にそれらを数え上げてください。

削除リクエストは、聞こえるほど広範ではありません。Search Consoleは、リクエストを提出したプロパティに対してのみ削除を適用するため、サブドメインでリクエストしてもメインドメインには影響しません。まずプロパティを確認してください。その後、送信し、両方を検証済みとして維持してください。

サブドメインの人気ページのみをインデックスする

そのセクションのURLごとのリンク数から始めましょう。外部リンクを持ち、トラフィックが少ないページは、人気ページのみルールで最初に非表示にされる可能性があります。それらをクロール可能にしておくか、それぞれを最も近い人気ページにリダイレクトし、ルール beside に理由を記載してください。

メインサイトがサブドメインにリンクする場所は、そのページの発見しやすさを決定します。どのページを非表示にするかを選ぶ前に、それらのリンクをリストしてください。メインサイトがリンクしないページは、どちらの方法でも到達が困難です。

サイト全体のドメイン変更、ページごと

ホストレベルのルールはルートのみを処理しますが、ドメイン変更にはパスレベルのマッピングも必要です。URLの最初の部分が変更され、スラッグが同じ場合、ホストの入れ替えはほとんどのページをカバーしますが、例外には個別の行が必要です。

リンクされたページからリストを構築し、各古いパスを新しいパスに一致させてください。リダイレクトマップレシピは、リンクに基づいてこのリストをランク付けする方法を示しています。