コンテンツへスキップ
Anchor Social
Anchor Social$100無料を入手

チェックリスト

移行に伴うリンクとウェブサイトの変更を分析する

プラットフォーム変更、サブフォルダの統合、ドメイン変更は、リンクが収集されるURLを変更します。移行前にアンカーをキャプチャし、インデックスが追いついた後に比較します。

移行前に構造を検査する人物がいる2つの崖をつなぐ粘土の橋
順序が重要

公開日前に快照を取得してください。古いURLがリダイレクトを開始すると、どこにリンクされていたかを再構築するのが難しくなります。当社のインデックスは月1回更新されるため、移行後の状況が反映されるのは1〜2サイクル後になります。7つのステップからなるランブックにはプルとバケットの手法が記載されており、移行の両端のデータが必要です。

移行前

  • 古いドメインのanchorsとtoppagesを取得し、日付付きで両方のファイルを保存する
  • 最も多くのリンクを獲得している50ページをリストアップし、これらには1対1のリダイレクトが必要
  • アンカーバケットにタグを付け、その後に使用するのと同じルールを使用する
  • Search Consoleのリンクレポートを同日にエクスポートし、セカンドオピニオンとする
  • canonicalホストを決定し、サイトマップとhreflangで一貫性を保つ
  • /usのようなサブフォルダなど、削除するすべてのURLパターンを記録する
  • 2024年3月のコアアップデートやスパムアップデートなど、当月のGoogleアップデートカレンダーを記録し、後続のランキング変動が移行のみに起因するものではないようにする

公開前にリダイレクトマップを作成する

リダイレクトマップは移行で最も過小評価される部分です。目的地が最も重要です。移行後のリンクデータ分析の前に、古いURLには明確な目的地が必要です。なぜなら、それらのURLはすでにリンクが指しているアドレスだからです。

1対1がホームページへのダンプに勝る

無関係な古いURLを数百個もホームページに送信すると、検索エンジンや訪問者にほとんど何も伝わりません。関連性がテスト基準です。各高価値の旧URLを最も近い新しいページにマッピングし、残りはトピックに一致するセクションに送信してください。

ステータスコード付きの旧URLを最初にエクスポートします。そのファイルを大切に保管してください。そのファイルがチェックリストであり、どのページがリンクを獲得したかを示します。

ページに一致するものがない場合は、マップにその旨を記載し、最も近いセクションに送信し、注記を追加してください。空白のセルは選択を隠します。表の空白セルは、誰も決定しなかったことを意味します。

公開前にチェーンを平坦化する

新しいページに到達する前に2つの以前のルールを通過するリダイレクトは、遅延とリスクを追加します。2回目の移行が1回目の移行の上に重ねられると、チェーンは簡単に作成されるため、クリーンであると想定するのではなく、切り替えごとにマップを確認してください。余分なホップごとにコストがかかります。切り替え後に各旧URLを1回リクエストし、単一のホップで応答することを確認してください。

早期に修正する。公開後に1つずつチェーンを修正するのではなく、マップ自体で修正し、リストを短く保つ。

まだ機能しているパスを維持する

リデザインでURL構造を変更することは、最も避けられる損失です。パスの変更は、それに向かってリンクされているすべてのリンクの変更でもあります。それらのリンクはあなたの制御外です。機能しているものは維持してください。パスがまだ機能している場合はそれを維持し、移行によって変更を余儀なくされるものだけを変更してください。

リダイレクトが少なく、エラーも少ない。維持するパスが多いほど、リダイレクトが必要ないリンクが増える。

維持されたパスとは、古いアンカー行がまだ何らかの有用な場所を指していることを意味し、シートで再構築するものが1つ減ることを意味します。後での再構築が少なくなります。

効率的なウェブサイトリダイレクトを表す直接フローを持つ滑らかな粘土パイプシステム

移行後に期待すること

それらが重い作業を行い、古いURLから新しいURLへの301リダイレクトにより、古いリンクは機能し続けます。各旧URLにつき1つのリダイレクトを維持し、間にチェーンを入れないことが、各リンクの価値を維持する最も簡単な方法です。リダイレクト。3〜4ホップのチェーンはクローラーを遅くし、平坦化するのが最適です。

URLが移動してもアンカーテキストは変更されません。テキストはリンク元のページにあるためです。変更されるのは目的地の数です。トップページ表では、古いホストが減少し、新しいホストが数回の月次更新を経て増加していく様子が見えます。目的地のシフトはゆっくりと起こります。

一般的な驚きは、古いプラットフォームを早すぎる時期に削除することです。やめてください。Squarespace、Wix、および同様のホストはリダイレクトルールを保持することが多く、プランをキャンセルするとルールが削除され、リンクが他の場所でルールを再構築するまで行き止まりを指すようになります。

hreflangとcanonicalタグも確認する必要があります。不一致は一般的です。例えば、CRAからNext.jsへの移行後、サイトはcanonicalタグとhreflangセットの間に不一致が生じ、リンクがページの2つのバージョンに分割されることがよくあります。

移行後に数値が一致しない場合は、リンクが失われたと仮定する前にトラブルシューティング表を確認してください。月次更新だけでは多くのギャップが説明されます。ギャップは多くの場合タイミングの問題です。

公開後約2回の月次更新後に最初のクリーンな比較が得られることを期待し、各更新の日付をシートに記録してください。そうしないと、平坦な月が止まっていると誤解される可能性があります。時間をかけてください。AhrefsやSemrushは、中間的な確認が必要な場合は、より新鮮なクローリングでギャップを埋めることができます。

移行の種類と注意すべき点

移行主なリスク確認方法
プラットフォーム変更、同じドメイン変更されたURLパターン、失われたリダイレクトtoppages 移行前と移行後、Search Console カバレッジ
新しいドメインリンクは数ヶ月間古いホストに残る両ドメインのanchors、月次
ブログをメインサイトに統合する2つのプロファイルが1つに統合されるリンク元ドメイン別の移行前後のアンカーシェア
/usサブフォルダの削除削除されたパスへのリンクが404になるサブフォルダのURLのtoppagesリスト

切り替え前にトップページを快照する

toppagesを使用して、どのURLがリンクを獲得しているかを確認する。クレジット2つ。

bash
curl -s "https://anchorsocial.org/api.php?action=toppages&q=old-store.example&per=100&key=sk_live_..." \
  -o toppages-pre-move.json

公開通知なしで移動するものを監視する

公開日にはチェックリストがありますが、いくつかの問題は後で静かに現れます。チームが他の作業に移った很久之后、それらは行とインデックスに表示されます。それらは見逃しやすいです。

ステージングビルドに伴うnoindex

検索から除外されたステージングコピーは、その設定をライブサイトに持ち込む可能性があります。最初のクローリングでrobots metaタグとnoindexヘッダーを確認し、ホームページだけでなく各セクションからページをサンプリングしてください。すべてのセクションをサンプリングします。

テンプレートが最初に壊れます。公開後にセクション全体がインデックスから消えた場合、コンテンツを見る前にテンプレートを確認してください。

スクリーンショットも役立ちます。ステージングビルドからのrobots設定のコピーも保管してください。インデックスから何かが消えた場合、2つの設定セットを比較するのには午後ではなく数分かかります。

インデックスに登録されるフラグメントリンク

目次アンカーなどのジャンプリンは、検索結果で別のURLとして表示されることがあります。検索エンジンは通常これらをメインページに折りたたみますが、そうしない場合、同じコンテンツが複数のアドレスの下に表示されることがあります。これらはメインページからの信号を分割し、カバレッジレポートで重複ページのように見えることがあります。ハッシュURLは静かに増殖します。

1つのバージョン、1つのアドレス。1つのアドレスを指すcanonicalタグがありながらサイトマップが別のアドレスをリストすると、混合信号が送られ、レポートに不一致が表示されます。各ページのcanonicalバージョンを1つ設定し、サイトマップが同じバージョンをリストしていることを確認してください。

公開後にハッシュを含むURLについてカバレッジレポートを確認してください。それらは静かに増殖するものです。ハッシュが犯人です。

サブドメインがメインドメインになる

サイトをステージングサブドメインからメインドメインに移行すると、両方のバージョンがしばらく到達可能であるため、独自の重複が発生します。公開前にどのホストがcanonicalかを決めてください。ホストを早期に選択してください。

1つのホスト、どこでも。ホストが1つの場所では変更され、別の場所では変更されない場合、古いバージョンは誰も気づかずに数ヶ月間リンクを収集し続ける可能性があります。その後、サイトマップ、canonicalタグ、およびhreflangセットをその1つのホストにポイントしてください。

消失したように見えるdo-followリンク

リデザイン後、ツールのdo-follow行が急落することがあり、最初の推測はリンクが消えたということです。その推測を受け入れる前に、古いトップページと新しいトップページを比較し、各旧アドレスが正しくリダイレクトされているか確認してください。パニックになる前に確認してください。

それを最初に修正する。リンク元のページにまだ存在しているが、行き止まりのアドレスを指しているリンクは、最初に修正すべきケースです。

早期に日付を設定する。比較の固定日付をチームに提供し、誰もが毎日プルを実行してノイズをニュースとして読まないようにする。

4つの移行で失われたリンクを確認する

これらを順序通りに実行し、最初のステップのファイルを最後のステップのために保管する。

  1. 1

    古いトップページを保存する

    公開前に古いドメインのtoppagesを取得し、日付付きでファイルを保管する。

  2. 2

    古いアドレスをテストする

    各高価値の旧URLをリクエストし、新しいページへの1つのリダイレクトで応答することを確認する。

  3. 3

    1回の更新後に比較する

    次の月次更新後に新しいドメインのanchorsとトップページを取得し、リンク元ドメインで比較する。

  4. 4

    最大のリンク元のみを尋ねる

    まだ古いアドレスを指しているリンクの場合、最大のリンクサイト連絡先し、URLを更新するように依頼する。

開発者とモニターの役割を分担する2人の粘土の人物

移行中の開発者との連携

リダイレクト作業の大部分は開発者に委ねられ、モニタリングはシートを読む担当者に委ねられます。分割を短い表として記録し、各セルに1人の名前を入れることで、2人が同じタスクを想定するのを防ぐことができます。公開前にこれらの役割を紙上で分割し、誰もが相手が監視していると想定しないようにします。役割には名前が必要です。

開発者にタスクリストではなくマップを提供する

タスクリストは開発者に何をすべきかを伝え、マップはどの旧アドレスがどこに行くかを示します。ステータスコードと各行の理由を含む1対1の表を送信し、エッジケースが推測ではなく決定を得るようにしてください。決定は推測に勝ります。

テストプランが先に来る。トップページファイルの古いアドレスから始まる短いテストプランを依頼してください。

月次ファイルの読者を合意する

最初のクリーンな比較は公開後約2回の更新後に来るが、ファイルには読者が必要になる。公開後の最初の読み取りは通常ノイズが多く、それを知っている読者は単なる異常な月に反応しない。その人物、開く日付、結果を記録するシートを指定してください。誰かが責任を持つ必要があります。

日付が問題を解決する。各ファイルの横に更新日付を記録することで、インデックスが止まっているという懸念を、カレンダーに関する単なる事実に変えます。更新日付を誰かが記録しない限り、平坦な月は止まっていると誤解されやすいです。

何も変わらなかった場合でも、更新ごとに1行ずつ記録するようにその人物に依頼し、ファイルに継続的な記録を残してください。毎回1行。

公開前にロールバックを計画する

新しいホストが重要なパスを壊した場合、チームは事前にテストされた戻り手段が必要です。手順を記録し、誰がスイッチを切り替えることができるか、およびロールバック中にリダイレクトがどのように動作するかを含めてください。公開前にリハーサルを行ってください。

ロールバックを記録する。1人の頭の中にあるだけのロールバックは計画ではありません。

移行後、月ごと

  • 1ヶ月目:トップページ20ページをサンプリングし、単一ホップの301を確認する
  • 2ヶ月目:新しいドメインでanchorsを再実行し、バケットシェアを比較する
  • 3ヶ月目:更新されなかった旧ドメインのリンクを探し、最大のリンク元に再ポイントを依頼する
  • Search Consoleのカバレッジでリダイレクトエラーを監視する
  • 移行前の快照と同じシートにすべて記録する