完璧な Web サイトの再起動 – 完全な SEO チェックリスト
公開: 2023-06-02
テーマの変更、ドメインの切り替え、サーバーの移動など、Web サイトの再起動はオンライン ビジネスにとって重要な時期です。
検索トラフィックとコンバージョンを改善するために再起動しています…
…しかし、可動部分が非常に多いため、問題が発生する可能性もたくさんあります。
心配しないで！
そのため、この Web サイトの再起動と移行の SEO チェックリストを作成しました。 そして、ランキングを維持するだけでなく、オーガニック トラフィックを大幅に増やすための基礎をすべて網羅しました。
飛び込んでみましょう。
目次
- 1 Web サイトの再起動チェックリストが必要なのはなぜですか?
- 2再起動の準備
- 3発売前準備チェックリスト
- 4移行チェックリスト
- 5起動チェックリスト
- 6発売後のチェックリスト
- 7サイトを再起動する準備はできましたか?
Web サイトの再起動チェックリストが必要な理由は何ですか?
ウェブサイトのリニューアルは複雑なプロセスです。
これは、かなり小さいように見えても、ランキングを維持する上で重要な要素である可能性があるものを見逃しやすいことを意味します。
チェックリストのすべての手順が特定の再起動または移行に適用されるわけではありません。 ただし、次のそれぞれの状況に適用される手順が含まれています。
1. ウェブサイトリニューアル（テーマ変更）
単純なテーマの変更は、かなりリスクの低い移行です。
ナビゲーションに大幅な変更を加えず、内部リンク構造をそのまま維持することに重点が置かれます。
2. フレームワーク変更によるWebサイト移行（新CMS）
これはリスクの高い移行です。
ある CMS から別の CMS に移行する場合、古いサイトの構造を正確に複製するのは困難です。 ただし、変更を最小限に抑える方法を紹介します。
3. ドメイン変更またはウェブサイトのリニューアル
これは比較的リスクが低いです。
ブランド変更はかなり日常的な手順であり、Google が期待していることです。 ランキングは一時的に変動する可能性がありますが、すぐに安定するはずです。
4. サーバー移行（ホスティングの変更）
これはかなりリスクの低い移行です。
ただし、新しいサーバー上に古いサイトの正確なコピーを作成する必要があることに注意してください。
5. SEO戦略の再起動（SEOへの取り組みを活性化する計画）
サイト上の情報の再構築を実行することになるため、これは通常、リスクの高い作業となります。 しかし、私たちはこれをチャンスとして分類します。
結局のところ、SEO のためにサイトを再起動する場合、それはおそらく現在の構造に修正が必要な問題があることを意味します。 これらの問題を解決すれば、ランキングが上がるはずです。
再始動の準備中
チェックリストを始める前に、実行することをお勧めする手順がいくつかあります。
まず、既存のサイトの監査を実施し、次に移行中に作業するテスト (またはステージング) サイトを作成します。
1. 既存のサイトをクロールして監査する
再起動の理由の 1 つは、古い「問題」を修正することです。
したがって、再起動/移行を進める前に、現在のサイトの SEO を妨げているすべての問題を特定する必要があります。
Seobility を使用してサイトの完全なページ上の監査を実行できるため、サインアップしてプロジェクトを作成します。
注:無料 (ベーシック) バージョンではサイトの監査を実行できますが、バックリンクをエクスポートすることはできません。 したがって、このガイドのすべての手順に従うには、14 日間の無料のプレミアム トライアルにサインアップすることをお勧めします。
チェックリストのいくつかのステップで Seobility を使用します。 偏見があるかもしれませんが、登録をお勧めする理由がすぐにわかるでしょう。
ウェブサイトを監査するための詳細なガイドをこちらでご覧ください。
2. テスト/ステージング サイトをセットアップする
移行中に作業するテスト/ステージング サイトをセットアップすることをお勧めします。
そうすれば、ライブサイトに影響を与えることなく、調整したり、テストしたり（そして、何かを壊したりすることも！）できます。
テストサイトの準備はできていますか? 移行チェックリストに移りましょう。
発売前準備チェックリスト
コンテンツの移動を開始する前に、実行することをお勧めする手順がいくつかあります。
1. ステージング サイトをパスワードで保護する
当面は、ステージング サイトからクローラーを遠ざける必要があります。 そうしないと、厄介な検索エンジンのボットがインデックスを作成してしまうことになります…。
…これはあなたのランキングに大きなダメージを与えることになります。
幸いなことに、ステージング サイトをパスワードで保護することで、簡単にブロックできます。
クローラーがステージング サイトにアクセスするのを防ぐ方法は他にもあります (robots.txt ファイルでボットを禁止するなど) が、理想とは程遠いです。
Google は引き続き許可されていないステージング サイトの URL を SERP に表示できるだけでなく、ステージング サイトがパスワードで保護されていない場合、どのユーザーやボットがステージング サイトを見つけてしまうかわかりません。 したがって、ドメインをパスワードで保護することが最善の方法です。
そして、ここに素晴らしいものがあります:
ユーザー名とパスワードは、Seobility のクローラー設定 ( 「ダッシュボード」 > 「プロジェクト」 > 「クローラー設定」) で追加できます。 これにより、クローラーがゲートを通過できるようになり、ステージング サイトで監査を実行できるようになります。
サイトをパスワードで保護する最も簡単な方法は、.htaccess を使用することです。 次のコマンドをファイルに追加します。
#ディレクトリを保護する AuthName "ダイアログプロンプト" 認証タイプ 基本 AuthUserFile /home/ユーザー名/website/.htpasswd 有効なユーザーが必要です
次に、サイトにアクセスするためのユーザー名とパスワードを使用して、上記の AuthUserFile の場所で指定したディレクトリに .htpasswd ファイルを作成します。 形式は次のとおりです。
ユーザーのパスワード stagingsiteuser:stayawayG00gle!
2. 現在のコンテンツのマップを含むスプレッドシートを作成する
あなたのサイトにどんなコンテンツがあるのか正確に知っていますか? すべてのページですか？ 私でもない。
しかし、移行を成功させるには…そうする必要があります。
幸いなことに、Seobility を使用すると、サイトのコンテンツの完全なリストを簡単に取得できます。 14 日間の無料トライアルにサインアップし、Web サイトをプロジェクトとして追加し、クロールを実行するだけです。
クロールが完了したら、 [ダッシュボード] > [ウェブサイト] > [オンページ] > [技術とメタ]に移動すると、[クロール統計] の下にクロールされたページの完全なリストが表示されます。
[クロールされたページ] をクリックすると、現在のサイトのすべてのコンテンツ URL をエクスポートできます。
これらのページをスプレッドシートに入力します。 これを、近いうちにいくつかの決定を下すためのベースとして使用する予定です。
注: データ収集に使用できるスプレッドシート テンプレートを作成しました。 ここをクリックして Google アカウントにインポートします。
3. 外部バックリンクのマップを作成する
もう一度 Seobility を使用して、Web サイトへのすべてのバックリンクのリストを取得できます。
サイト用のプロジェクトはすでに作成されています。 したがって、必要なのは、ツールによって検出されたバックリンクのリストをエクスポートすることだけです。
このリストは、コンテンツに関する決定を行うために使用します。
ダッシュボードの「バックリンク」タブに移動し、リストをエクスポートします。
4. 内部バックリンクのマップを作成する
内部リンクはサイトの最適化にとって非常に重要です。 強固な内部リンク構造は、検索エンジンのボットに役立ちます。
- サイトを効果的にクロールする
- ページ間の関係を理解する
したがって、移行中に内部リンク構造に不要な変更を加えないようにする必要があります。
重要なのはコンテンツ内からのリンクだけではありません。
ナビゲーションリンクも重要です。 これらは、Google がサイトの構造を理解し、コンテンツ ハブとカテゴリを強化するのに役立ちます。
移行中は、ナビゲーション リンクをできる限り維持するようにしてください。 大きな変更を行うと、重要なページの強度が失われ、トラフィックが減少する可能性があります。
5. コンテンツとトラフィックのマップを作成する
ステップ 3 と 4 ではリンクを扱いました。 ただし、サイト上のどのページが現在最もトラフィックを受け取っているのかを知る必要もあります。
なぜ？ ランキングの低下を引き起こす可能性のある変更を加えないよう、これらのページには細心の注意を払いたいと考えているからです。
壊れていないなら、修理しないでください！
Google Analytics を使用して、サイト上のすべてのページのトラフィック レポートをエクスポートできます。
移行の目的としては、検索だけでなく、すべてのソースからのトラフィックを確認する必要があります。
GA4 を使用していると仮定すると、ページと画面のレポート (ライフ サイクル > エンゲージメント > ページと画面) またはランディング ページ レポート (ライフ サイクル > エンゲージメント > ランディング ページ) を使用できます。 左上の「このレポートを共有」をクリックし、「ダウンロード」をクリックしてデータをエクスポートできます。
まだ古いバージョンの Google アナリティクスを使用している場合は、 [Google アナリティクス] > [行動] > [サイト コンテンツ] > [すべてのページ]に移動して、エクスポートします。
6. コンテンツの剪定作業を実行する
これで、どのページにリンクがあり、どのページにトラフィックが集まっているかなど、サイトのコンテンツの完全なリストが得られました。 いくつかの決断を下す時が来ました。
「家をきれいにする」チャンスです。
それで、計画は何ですか？
まあ、時間の経過とともに、Web サイトは少し肥大化する可能性があります。 また、サイトがしばらく存在している場合は、同じキーワードをターゲットにした複数のページ (手順 7 で詳しく説明します)、孤立したページ、または古いページが存在する可能性が高くなります。
最初に尋ねるべき質問は次のとおりです。
- ページにトラフィックはありますか?
- ページにバックリンクはありますか?
これらの質問に対する答えが「いいえ」の場合、そのページは次のいずれかの候補になります。
- 消去
- 別のページと結合する
ただし、ページにバックリンクがある場合でも、ページをマージ (つまりリダイレクト) することを検討することをお勧めします。
なぜ？ なぜなら、同じトピックをカバーする 4 つのページがあり、それぞれにバックリンクがある場合、それらを 1 つのページに統合すると、リンクの公平性が統合され、より強力なページが作成されるからです。
また、ページがトラフィックを受け取っていないからといって、それが「良い」ページではないという意味ではないことも指摘しておく必要があります。 削除が必ずしも解決策になるとは限りません。 場合によっては、代わりにページを改善/更新できるか、ランク付けするにはさらに多くのリンク (内部または外部) が必要であると判断する場合があります。
したがって、決定を下す前に各ページを確認することをお勧めします。
結論: ページの品質が低く、ランクがなく、リンクがない場合は、おそらく削除されるべきです。
7. キーワードの共食いを避けるために、ページごとに 1 つのトピック (キーワード) に焦点を当てるようにしてください。
コンテンツ監査により、同じキーワードをターゲットとする複数のページが見つかる可能性があると上で述べました。
これが起こると、これらのページは「キーワード共食い」に見舞われる可能性があります。
複数のページで同じキーワードでランク付けしようとしています。 そしてGoogleはそれを許すつもりはない。
どのページをランク付けするかを決めるのに苦労するでしょう。 そして最悪の場合、どのページもランク付けされない可能性があります。
では、キーワードのカニバリゼーションにどのように対処すべきでしょうか?
私たちのアドバイス:
- どのページがキーワードに最も適しているかを決定します (これがプライマリ ページになります)
- 追加ページにある情報を主ページにマージします。
- 301 追加ページをプライマリ ページにリダイレクトします
8. URL 最適化演習を実行します (二重キーワード、ストップワード、スラッグ内の完全な「タイトル」は使用しない)
これも注意して扱う必要があるステップです。
ページの URL を変更すると、潜在的な利点もありますが、リスクもあります。
URL は短く、キーワードに重点を置き、ランク付けしようとしていない単語はスキップするのが理想的です。
/キーワード1-キーワード2-キーワード3
次のようなものが完璧です。
しかし、これは、SEO にもっと時間とエネルギーを投資し始めるにつれて、私たちのほとんどが学ぶことです。
構造を正しく計画していないか、SEO への影響を認識していなかった可能性があるため、従来の「乱雑な」 URL が存在することがよくあります。
たとえば、WordPress は、タイトル内のすべての単語から単純にスラッグを作成します。 つまり、スラッグを手動で変更しない場合、ほとんどの URL は次のようになります…
/キーワード 1、キーワード 2、およびキーワード 3 を試行せずにランク付けする方法
うわぁ！
URL はページ上のランキングシグナルです。 つまり、最適化には価値のある取り組みが行われるということです。
しかし…
すべての大きな（っぽい）変更と同様に、Google は少し気まぐれな場合があります。 したがって、リスクがないわけではありません。
私は長年にわたって URL を何度も変更してきましたが、ほとんどの場合、その恩恵を受けてきました。 しかし、明らかなブロック要因でない限り、URL をそのままにしておくよう推奨する SEO も少なくありません。
これは、ページがすでに上位にランクされている場合は特に注意する必要があることを意味します。 そして、そのアドバイスはこのプロセスのすべてのステップに当てはまります。
ページの URL を変更する場合は、必ず古い URL を新しい URL に 301 リダイレクトしてください。 これにより、検索エンジンがそれが同じページであることを認識できるようになります。
これについては後ほど詳しく説明します…
詳細: SEO フレンドリーな URL
9. いくつかのプラグインページが変更されているかどうかを確認します
再設計の一環として、いくつかのプラグインを変更することにしたかもしれません。
これは、特にユーザー エクスペリエンスの観点から、心に留めておくことが重要です。
ブログの投稿やページだけでなく、変更された可能性のある他のすべてのページについても細心の注意を払う必要があります。
たとえば、e コマース プラグインを変更した場合は、主要な URL (/shop、/cart、/checkout など) が変更されていないことを確認する必要があります。
もしそうなら？ URL の変更をそれぞれ記録し、それに応じて処理できるようにする必要があります。
10. 現在の URL から新しい URL へのマップを作成する
どの URL を変更するかを決めたら、301 リダイレクトのリストを作成する必要があります。
301 リダイレクトは、Web ページが新しい場所に永久に移動したことをクローラーとブラウザに示します。
ここでも、301 リダイレクトの実行には影響があります。
以前は、リダイレクトを通過したリンクが一部の電力を失うことがありました...
…しかし、Google の Gary Ilyes 氏は、2016 年にリダイレクトが完全な値を渡すようになったと指摘しました。
ただし、連鎖リダイレクトには依然として問題があります。
連鎖リダイレクトは通常、ページ URL が複数回更新され、リダイレクトされた場合に発生します。
リンク→古いURL→新しいURL→さらに新しいURL
このような場合、特に内部 URL の場合は、中間ステップを行わずに、古い URL が新しい URL を指すようにする必要があります。
なぜ？ 301 はページの値を渡しますが、リダイレクトごとに時間とリソースがかかるからです。 これはクローラー (Googlebot など) にとっては好ましくなく、ユーザーにとっては次善の策です。
11. すべての SEO プラグイン設定をメモします。
SEO プラグインの設定は、サイトの SEO の健全性にとって非常に重要です。 移行全体にわたってこれらを維持するか、SEO 目的で Web サイトを再起動する場合は必要な変更を加える必要があります。
現在のすべての設定のスクリーンショットを撮って、新しい設定に反映できるようにします。
12. SEO または UX に影響を与える可能性のある他のすべてのプラグインに注意してください
SEO プラグインは特に重要ですが、サイトの全体的な構造に影響を与える可能性のあるプラグインは他にもたくさんあります。
すべての主要なプラグインの設定をスクリーンショットとして保存して、比較し、すべての設定が正しく移動されたことを確認できるようにする必要があります。
13. ベンチマークを設定します。 Google Analytics の主要なユーザー指標 (直帰率、サイト滞在時間、返品率、人口統計、トラフィックなど) をメモします。
コンテンツ移行マップの大部分が準備できたので、比較のためにいくつかのベンチマーク統計を記録したいと思います。
録音することをお勧めします。
サイト滞在時間: サイトの全体的なユーザー エクスペリエンスが改善されれば、この時間は増加すると予想されます。
直帰率: これは理解するのが難しい指標なので、ここでは詳しく説明しません。 直帰率が低いことは素晴らしいことですが、直帰率が高いことは必ずしも悪いことではありません。 いずれにせよ、比較できるようにメモしてください。
返品率: これも監視するのに適した指標です。 ユーザーエクスペリエンスが改善されれば、ユーザーがより頻繁に戻ってくることが期待されます。
目標: 新しいサイトでさらに多くの目標を達成したいと考えています。
コンバージョン: 重要な指標であるだけでなく、改善が望まれる指標です。
注: これらは私の提案ですが、どのビジネスもユニークです。 したがって、どの指標がビジネスにとって最も重要で、どの指標の改善を目指すかを決定する必要があります。
14. Google Search Console (GSC) で現在のドメインを確認する
これはすでにやっておくべきことです。 しかし、そうでない場合は…。 今がそうする時です！
サイトの実際のアドレス (ドメイン) を変更する場合、実行するアクションの 1 つは GSC でのアドレス変更指示です。
したがって、最初に既存のドメインが検証されていることを確認する必要があります。
15. Bing ウェブマスター ツールを使用して古いドメインを確認する
私たちのほとんどは Google に注目しています (2023 年の時点で Google が検索の約 92% を占めているので、それはまったく正しいことです) が、Bing も市場シェア約 3% で安定したトラフィックを送信できます。
ChatGPT を活用した AI チャット モードなどの最近のイノベーションにより、Bing は引き続き Google から市場シェアを獲得できる可能性もあります。
したがって、Bing のウェブマスター ツールでドメインを確認することをお勧めします。
失うものは何もなく、トラフィックが得られることはありません。
16. 既存のドメインの否認ファイルをダウンロードします。
過去にリンクを否認したことがある場合、特に新しいアドレスに移行する場合は、このファイルのコピーをダウンロードする必要があります。
古いサイトから新しいサイトへの完全な 301 リダイレクトを実行します。 したがって、否認されていない古い有害リンクは新しいドメインに継承されます。 これは、有害なリンクのペナルティも継承されることを意味します。
問題を避けるために、新しいサイトに同じ否認ファイルを使用できます。
17. 新しいサーバーインフラストラクチャを準備する
サイトを新しいインフラストラクチャ (つまり、別のホスティングまたは新しいクラウド サーバー) に移行する場合は、今がすべてがスムーズに実行されていることを確認する時期です。
18. 新しい SSL 証明書を準備してインストールする
新しいインフラストラクチャのセットアップの一環として、次のいずれかを行う必要があります。
- 既存の SSL 証明書を移行する、または
- ドメインが変更された場合は新しいドメインを作成する
これは、特に組織検証済み証明書または拡張検証証明書を使用している場合、多少時間がかかるプロセスになる可能性があります。 したがって、これらすべてを事前に準備していることを確認する必要があります。
起動する前に、証明書を準備してインストールしてください。
19. 現在のサイトマップのコピーを作成します
移行を実行したら、sitemap.xml ファイルに存在するすべてのコンテンツがあることを再確認する必要があります。
コンテンツに変更を加えている場合でも、sitemap.xml のコピーが必要になります。
なぜ？ 新しい sitemap.xml に次のものが含まれていないことを確認する必要があるためです。
- 必要のない、またはもう存在しない余分なページ、または
- 含まれているはずのページがありません
20. robots.txt ファイルのコピーを作成します。
sitemap.xml ファイルと同様に、robots.txt ファイルには、Google や他のボットがサイトをクロールする方法に影響を与える重要なディレクティブが含まれています。
新しい robots.txt ファイルに誤りがあると、あらゆる種類のランキングの混乱が生じる可能性があります。 小さなエラーが常に問題になるわけではありませんが、ブロックすべきではないページを誤ってブロックしてしまうことは問題となります。 Google は Search Central ブログで robots.txt の間違いについて次のように述べています。 
したがって、比較のために古いファイルのコピーを必ず保存してください。
移行チェックリスト
準備は完了しましたか? サイトを移行する時期が来ました!
1.すべての重要なコンテンツを移行する
最初のステップは、すべての重要なコンテンツを古いサイトから新しいサイトに移動することです。
なぜ「重要な」内容と言うのでしょうか?
準備中に保持することに決めたコンテンツのみを移行する必要があるためです。
ページが削除 (または統合) される場合、そのページを新しいサイトにインポートしても意味がありません。 追加のステップを自分たちに与えるだけです。
コンテンツ移行プロセスはフレームワークによって異なります。 ただし、ほとんどの CMS には、移行に役立つプラグインまたは拡張機能が含まれています。
注: 移行中のイメージには特に注意が必要です。 ドメインまたはフォルダー構造が変更された場合は、埋め込まれた画像が正しい URL/パスを指していることを確認する必要があります。
2. 削除または統合されるページに対する適切な応答を作成します。
マージまたは削除されるコンテンツは、適切に処理する必要があります。
訪問者 (または検索エンジン) が古い URL にアクセスしようとすると、適切な応答が提供される必要があります。
では、適切な対応とは何でしょうか?
私たちが推奨するものは次のとおりです。
- 他のページと結合されたページの場合は、古い URL をプライマリ ページにリダイレクトする必要があります。
- 関連性がなくなったが、非常によく似たトピックを含むページがサイト上に存在するページは、関連するトピック/ページにリダイレクトされる必要があります。
- トピックに関連するカテゴリがある場合は、古い URL を親カテゴリに 301 リダイレクトすることをお勧めします。
- 有効ではなくなり、同様のトピックが他に存在しないページには、410 (Gone) 応答が返される必要があります。 これは、ページが戻ってこないのでインデックスから削除する必要があることを Google に通知するため、404 よりも優れています。
- 壊れたページをホームページにリダイレクトしないでください。これはユーザー エクスペリエンスの問題であり、ホームページにリダイレクトされる内部リンクはすべて (ソフト) 404 エラーとして扱われます。
3. カスタム 404 ページを作成する
404 ページにアクセスすると、ユーザーはイライラすることになります。
カスタム 404 ページを使用すれば、その衝撃を和らげることができます。
私たちのアドバイスは？ サイトが再設計され、一部のコンテンツが利用できなくなったことを説明します。 次のような代替の行動方針を提案することもできます。
- ヒットした特定のキーワードを検索する
- ご連絡中
- サイト内の探している可能性のある関連セクションにアクセスする
楽しい 404 のビジュアルやメッセージもイライラを解消するのに役立ちます。
4. ソフト 404 に注意する
削除されたページをホームページにリダイレクトしないようにする必要があると上で述べました。
これは、Google がそのようなリダイレクトをソフト 404 として扱うことを選択する可能性があるためです。 ユーザーは特定のコンテンツを期待していますが、代わりに、関連性のないページ (この場合はホームページ) にリダイレクトされます。 そして、それが起こると、リンクの資産が引き継がれる代わりに、リンクの価値が失われます。
さらに、内部リンクをホームページにリダイレクトすることは、既知のスパム戦術です。 これを行うと、Web サイトがネガティブな SEO シグナルを送信する可能性があります。
5. META の説明を最適化する
移行は、SEO の厄介な問題を解決する絶好の機会です。
したがって、移行プロセスの一環としてメタ ディスクリプションをクリーンアップ (および改善) することをお勧めします。 これは、Google からのクリックスルー率を高めることができる価値のある練習です。
完璧な SEO メタ ディスクリプションを作成する方法については、メタ ディスクリプション ガイドにアクセスしてください。
6. 古い URL から新しい URL へのリダイレクトを準備します (リダイレクト プラグインまたは .htaccess)
移行中に URL が変更されましたか? ランキングを維持するにはリダイレクトを準備する必要があります。
リダイレクトは次の方法で管理できます。
- プラグイン
- cPanel/ホスティングプロバイダー
- Web サイトの .htaccess ファイルから直接。
プラグインを使用すると実装と追跡が容易になるため、可能な限りプラグインを使用することを好みます。 そして、簡単であるほど良いのです。
WordPress を実行している場合、Redirection は 301 の管理に役立つ非常にシンプルなプラグインです。
ただし、.htaccess ファイルを手動で編集する場合は、次の方法で編集できます。
7. (新しい) テスト サイトを監査する
コンテンツとリダイレクトを適切に配置したら、(新しい) テスト サイトの監査を実行するのに良いタイミングです。
なぜなら、このようなチェックリストに従っている場合でも、大規模な移行ではいくつかのエラーや問題が発生する可能性があるからです。
Seobility を使用してサイト監査を実行できます。 また、数回クリックするだけで、パスワード保護やクローラーのブロックを無効にすることができます。
これらの設定は、ダッシュボードの「クローラー設定」にあります。
8. サイト監査で発見された問題を修正する
公開する前に、SEO に関する技術的な問題をできる限り解決しておきたいと思うのは当然のことです。
最も一般的な SEO エラーを見つけて修正する方法の詳細については、SEO 監査ガイドをお読みください。 これは長いステップになるかもしれませんが、非常に価値のあるステップです。
9. 更新された URL で内部コンテンツのリダイレクトを更新します。
リダイレクトは移行において重要な役割を果たすことになります。 しかし、それらを回避する機会があればいつでも…私たちはその機会を利用する必要があります。
結局のところ、リダイレクトは、クローラーとユーザーの両方が実行する必要がある追加の「ホップ」です。 したがって、可能な限り正しいページを直接指すようにリンクを更新することをお勧めします。
そして、内部リンクを使えばまさにそれが可能です。
Seobility では、[リンク] セクションの[OnPage] > [構造] > [リダイレクト]で修正するリダイレクトを見つけることができます。
10. リンク切れの移行問題 (リンク切れ、イメージ切れ) を解決します。
コンテンツを削除し、内部リンクを削除 (またはリダイレクト) するのを忘れた場合は、壊れた内部リンクが作成されます。
そして、それは良くありません。
Seobility「Tech.」の HTTP ステータス概要パネルを確認してください。 404 エラーについては「& メタ」ページを参照してください。
上の例では、現在 404 を返しているページが 19 あることがわかります。したがって、これらのページへの内部リンクはすべて更新する必要があります。
「404」の横の数字をクリックすると、404 を返すすべてのページ (左側) と、それらにリンクしているページ (右側) が表示されます。
壊れたイメージとスクリプトは、[ファイル ソース] パネル (「取得できないファイル ソース」) に表示されます。
11. 新しいテンプレートから「余分な」ページを削除します。
移行によって「余分な」ページが作成されなかったことを再確認する価値があります。
たとえば、新しいテーマを設定した後、デモ コンテンツを削除するのを忘れた可能性があります。 それは起こります…
Seobility のクロール中に検出されたページの完全なリストを参照するには、「クロール統計」 (テクノロジーとメタ) の下の「クロールされたページ」をクリックします。
予期していなかったページに注意してください。
追加チェックとして、Seobility のコンテンツ監査の「テキスト品質」パネルでは、フィラー テキストを含むページが強調表示されます。
…これらのページの一部はジャンクである可能性が十分にあります。
12. 新しい robots.txt ファイルを作成します
内容的には、これでほぼ準備が整ったはずです。 しかし、実際に稼働する準備が整う前に、実行する必要のある手順がまだたくさんあります。
まず最初に、robots.txt ファイルを設定します。
プラットフォームを変更していない場合は、おそらく既存のファイルを新しいサイトにコピーするだけになるでしょう。 ただし、ファイルがすべて正しいかどうかを再確認することは価値があります。
13. 新しいサイトマップを作成する
新しいサイトマップを作成します。
これを古いものと比較して、明らかなエラーがないかどうかを確認します。 また、移行しないことを選択したコンテンツ (リダイレクトまたは削除) がサイトマップに含まれていないことも確認する必要があります。
古いバージョンには存在しなかった追加の分類に注意してください。 見つけた場合は、SEO プラグインが正しく設定されていることを確認してください。
たとえば、WooCommerce はサイトマップに多数のエントリ (色、サイズ、ブランド、その他の製品属性) を作成する傾向があります。
これらはすべて、エンド ユーザーに何の価値も与えない薄いページです。 また、これらのページが多すぎると、サイトが Google によってダウングレードされる可能性があります。
YOAST の SEO プラグインでは、検索から除外したいタクソノミーの値を「いいえ」に設定します。
14. 画像が独自の URL を作成していないことを確認する
WordPress における特に厄介な SEO の落とし穴の 1 つは、(正しく構成されていない場合) 画像 URL が独自のページからアクセスできることです。
これにより、画像のみを含む数百 (または数千) の薄いページが作成される可能性があります。
これは大量の内容の薄いコンテンツであり、SEO にとって大きな問題です。
修正は？ すべての画像ページがインデックス可能ではないことを確認し、実際の画像にリダイレクトします。 YOAST では簡単に実行できます。
スイッチを「はい」にクリックすると、添付ファイルの URL が画像自体に自動的にリダイレクトされます。
15.正規タグが正しいことを確認する
多くの CMS は、同じコンテンツにアクセスするためのさまざまな方法を作成します。 タグ、カテゴリ、ページネーション、フィルター、その他のパラメーターは特に面倒な場合があります。
最近の Google は、正しい URL を適切に推測してくれるようになりました。 しかし、私たちは何もかも偶然に任せたくないのです…
…そのため、各ページに決定版を指す正規タグが付いていることを確認する必要があります。
Seobility は、 「OnPage > 構造」レポートの「正規リンク エラー」で正規リンクの問題をチェックします。
16. 内部リンクの比較
これは超重要です
前述したように、内部リンクは、Google がサイトをクロールし、その構造を認識する方法です。
したがって、次のような大幅な変更は望ましくありません。
ナビゲーション– 直接リンクがある製品やサービスのページ、または第 1 レベルのページからのリンクなど、ランク付けしたいページにはそれらを保持する必要があります。
カテゴリ ページ– 一部のテーマでは、パンくずリストまたはその他の方法でカテゴリ ページへの自動内部リンクが作成されます。 新しいテーマがこれらのリンクを維持していることを確認してください。そうでない場合、投稿/ページに送られる電力が大幅に失われます。 逆に、新しいテーマでこれらのリンクが作成され、以前は存在しなかった場合は、設定を調整してリンクを削除することをお勧めします。
コンテンツ リンク– できる限り多くのリンクを維持する必要があります。 移行は、投稿内のリンクを変更するのに理想的な時期ではありません。
17. NAP、コンテンツ、その他関連するものにスキーマ データを追加します。
スキーマは、構造化された形式で情報を提示することで、機械 (この場合は検索エンジン) がコンテンツを理解するのに役立ちます。
また、Google はスキーマを使用して検索結果にリッチ スニペットを表示します。 これにより、より多くのクリックを獲得できるようになります。
したがって、可能な限りそれを含めたいと考えています。
少なくとも、組織の構造化データ (名前、住所、電話番号) を NAP に含める必要があります。
ただし、製品、レビュー、レシピ、イベント、記事、著者などはすべて、ページに含めることができる独自のスキーマ マークアップを持っています。
SEOPress は、サイトのスキーマの管理に役立つ素晴らしいプラグインです (私のレビューはこちらをご覧ください)。
スキーマとリッチ スニペットの詳細については、詳細なリッチ スニペット ガイドをご覧ください。
18. 重要な法的ページがすべて適切に配置されていることを確認してください
法的ページはサイトに正当性を与え、信頼に役立ちます。 したがって、必要なページがすべて揃っていることを確認してください。
これらには…
- プライバシーポリシー
- 規約と条件
- クッキーポリシー
- GDPR 準拠情報
- FTC アフィリエイトの開示
…およびあなたのニッチ内で必要なその他のページ。
19. 連絡先フォームやその他のフォームが正しく機能することを確認する
連絡先フォームやその他のユーザー入力が正しく機能することを確認します。 ピカピカの新しい Web サイトでも、問い合わせや登録がなければ意味がありません。
20. 会社概要ページをチェックして、古いバージョンと同等かそれよりも包括的であることを確認してください
サイトの「会社概要」ページは、検索エンジンやユーザーとの信頼を築くために重要です。
私たちのアドバイスは？ 自己紹介ページをできるだけ詳細に作成し、可能な限り実際の場所とビジネスで働く人々の写真を含めます。
また、サイトとその作成者/チームの両方のソーシャル メディア リンクを含めることをお勧めします。
これらはすべて、ユーザーと検索エンジンの両方に信頼感をもたらします。 これがなぜそれほど重要なのかについて詳しくは、EEA に関する投稿をご覧ください。
21. Google Analytics、AdWords、Google Tag Manager、Facebook Pixel、その他のサードパーティ スクリプトを追加します。
移行はほぼ完了しました。 ただし、Google Analytics などの必要なサードパーティ スクリプトを追加することは最後に行います。
各スクリプトがロード時間に影響を与えることに注意してください。 したがって、サイトの実行と必要なデータの収集に必要な絶対に必要なスクリプトのみを追加してください。
起動チェックリスト
移行が完了したら、いよいよ起動します。
オフピーク時間帯に起動をスケジュールすることをお勧めします。 これにより、負荷がピークに達する前に問題を解決する時間が得られます。
手順は次のとおりです…
1. パスワード保護を削除するか、noindex/disallow ディレクティブを削除します。
起動の準備ができたので、検索エンジンがサイトにアクセスするのを妨げたり停止したりするためのあらゆる方法を無効にすることができます。
必ず再確認してください。 クローラーがアクセスできない状態で起動することは絶対に避けたいです。
WordPress を使用している場合は、まず「検索エンジンを禁止する」チェックボックスがオフになっていることを確認してください。
[設定] > [読書]で見つけることができます。
2. サーバーホスティングを移動する場合はネームサーバーを更新します
新しいドメインに移動する場合、またはホスティングを変更する場合は、「スイッチ」を押して世界に向けて発信する時期が来ました。
新しいサーバーを指すようにドメインの DNS 設定またはネームサーバーを更新する必要があります。
注: サイトの新しいバージョンが表示されるようになるまで、DNS の変更が完全に反映されるまで数時間待つ必要がある場合があります。
同じホスティングを維持する場合 (ただし別のディレクトリにある場合)、ドメインに接続されているディレクトリを変更するだけで済みます。
あるいは、ステージング サイトで作業している場合は、ホスティングにそれをライブにプッシュするオプションがある可能性があります。 疑問がある場合は、ホストにサポートを求めてください。
3. .htaccess または必要に応じて完全なリダイレクトを設定します。
新しいドメインに切り替えましたか? 訪問者 (およびクローラー) を新しいアドレスに誘導するには、リダイレクトを設定する必要があります。
.htaccess を使用してドメイン レベルでこれを行う方法は次のとおりです。
リライトエンジンがオン
RewriteCond %{HTTP_HOST} ^www.oldsite.com$
RewriteRule (.*)$ https://www.newsite.com/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^oldsite.com [NC]
RewriteRule (.*)$ https://www.newsite.com/$1 [R=301,L]
上記は、http://、https://、http://www、および https://www.oldsite.com を https://www.newsite.com にリダイレクトします。
個々の URL も正しくリダイレクトされます。
4. 古いサイトが検索エンジンからアクセスできないようにする
この時点で、古いサイトが検索エンジンからアクセスできなくなっていることを確認する必要があります。
古いドメインへのリクエストはすべて、上で説明したように 301 リダイレクトする必要があります。そうしないと、コンテンツの重複の問題が発生します。 それは絶対に望んでいません。
不正なサブドメイン (oldsite.domain.com) とサブディレクトリ (domain.com/oldsite) に注意してください。 これらもリダイレクトする必要があります。
5. 徹底的な目視検査を実施する
新しいサイトが公開されたので、細かい歯を使ってページごとに内容を確認し、すべてが正しく表示されていることを確認します。
URL が期待どおりに表示されていることを再確認することも必要です。
6. リダイレクトのテスト
強調したように、リダイレクトは移行の重要な部分です。 したがって、すべてが正常に機能していることを三重に確認する必要があります。
以下をテストすることをお勧めします。
- 内部リダイレクトが正しく機能しているかどうかを確認します (つまり、/contact-us.html を /contact-us に移動した場合は、リダイレクトによってユーザーが最終的に目的の URL に送信されていることを確認してください)。
- 古いドメインから新しいドメインへのリダイレクトが正しく機能しているかどうかを確認します。 www.oldsite.com/page-1 から www.newsite.com/page-1 に送信されるはずです。
- 古いサイトからリダイレクトされた内部リンクを確認します。 アドレスが変更されたページについては、古いサイトの古い URL から新しいサイトの新しい URL に移動することを確認してください。 たとえば、www.oldsite.com/contact-us.html からは www.newsite.com/contact-us に送信されます。
- http から https へのリダイレクトが正しく機能していることを確認します。 http://www.oldsite.com/contact-us.html から https://www.newsite.com/contact-us に送信されます。
7. いくつかのバックリンクをチェックし、マップに従って新しいコンテンツにリダイレクトされていることを確認します。
すべての 301 リダイレクトが適切に設定されていることを確認するもう 1 つの重要な理由は何でしょうか? バックリンク。
リンクの公平性とリンク トラフィックを維持するには、古いサイトを指すすべてのリンクが新しい URL にリダイレクトされていることを確認する必要があります。
Seobility でサイトのバックリンク レポートを実行し、いくつかのリンクをチェックして、正しいページにリダイレクトされていることを確認します。
リダイレクトしないリンクを見つけた場合 (または 404 エラーが発生した場合)、何が問題だったのかを確認するために手順を再度たどる必要があります。
リンクを失わないことが重要です。
ヒント: Seobility のバックリンク リストの [壊れたリンク] タブを使用して、新しいサイトに壊れたバックリンクがあるかどうかを確認できます。 これは、見逃した可能性のある壊れたリンクを見つけるのに役立ちます。
8. site:olddomain.com クエリを実行し、いくつかの URL をクリックして、新しいページにリダイレクトされることを確認します。
Google で site:www.olddomain.com クエリを実行します。 すべてではありませんが、Google が古いサイトに対してインデックスを作成した URL のかなりの部分がリストされます。
これらの結果のいくつかをクリックして、適切なページに完全にリダイレクトされていることを確認します。
リダイレクトされない場合は、できるだけ早くこれを修正する必要があります。 そうしないと、ランキングとトラフィックが失われます。
9. 新しいサイトを Google Search Console に追加します
リダイレクトに問題がなければ、新しいサイトを Google Search Console に送信します。
ここで説明する確認方法のいずれかを実行して、Google Search コンソールで新しいドメインを確認します。
10. 新しいサイトを Bing ウェブマスター ツールに追加します
Bing ウェブマスター ツールで新しいサイトを確認します。 わかっています、わかっています…しかし、やはりトラフィックが発生します。
11. Google Robots Testingツールを使用してRobots.txtファイルをテストします。
Google のロボット テスト ツールを使用してサイトを検証し、コンテンツにアクセスできることを確認します。
いくつかの重要な URL と URL パターンにアクセスして、Google によるクロールが許可されていることを確認してください。
注: robots.txt テスト ツールは、URL プレフィックス プロパティでのみ機能し、ドメイン プロパティでは機能しません。 リンクが機能しない場合は、代わりにこの無料ツールを使用できます。
12. サイトの構造化データが正しいかテストし、エラーを修正する
移行チェックリストの一部として、構造化データ (スキーマ) に取り組みました。
さて、本番環境になったので、スキーマ コードにエラーがないことを確認するためにテストしたいと思います。
Google の Schema Markup Validator とそのリッチリザルト テストを使用して、スキーマをチェックできます。
13. 新しいサイトがモバイルフレンドリーであることを確認する
モバイルフレンドリーなウェブサイトは必須です。
新しいサイトはレスポンシブ デザインであることが望ましいですが、ページ上の個々の要素がモバイルで問題を引き起こす場合に備えて、Google のモバイル フレンドリー テストを実行する価値があります。
14. 新しいサイトマップを送信する
すべてが順調であれば、新しいサイトのクロールを開始するように Google に指示する準備が整いました。
Search Console で新しいドメインに新しい sitemap.xml URL を送信し、送信後にエラーがないことを確認します。
Bing ウェブマスター ツールでも同じことを行います。
15. 新しいプロパティに否認ファイルを追加します
古いサイトの否認ファイルがある場合は、ここでそれを Search Console の新しいプロパティにアップロードします。
そうしないと、有害なリンクを否認することができなくなり、ランキングに悪影響を及ぼす可能性があります。
16. リクエストインデックスの実行
Google は古いサイトを再クロールするときにリダイレクトを検出するため、新しいサイトをすぐに見つけることができます。
ただし、Google に古いドメインを再クロールするように依頼して (301 が表示されるように)、その後新しいドメインをクロールするように依頼することで、プロセスを高速化できます。
これは、Search Console の URL 検査ツール (少数の URL の場合) を使用するか、新しいサイトマップを送信することで実行できます。
17. 住所変更の手続きを実行する
Google のドメイン切り替えプロセスを高速化するもう 1 つの方法は、Search Console のアドレス変更ツールを使用することです。
注: これが機能するには、まずリダイレクトを設定する必要があります。
18. サイトが移転し、不具合が含まれている可能性があることを示す警告/情報メッセージを追加します。
ユーザーへの礼儀として、サイトが最近移行したことを知らせる短いメッセージを表示するとよいでしょう。
その理由は次のとおりです。
- 大幅な再設計の場合、ユーザーは混乱し、少しのガイダンスが必要になる可能性があります。
- 大規模なサイトでは、何かを見落としている可能性があります (あなたも人間です)。 発生した問題をユーザーに報告してもらうことで、クラウドソーシングでヘルプを得ることができます。
19. ソーシャルメディアのURLを更新する
新しいサイトが公開されたので、アクセスできるリンクを更新する必要があります。
ソーシャルメディアが最初の窓口となるでしょう。
ただし、他のリンク (フォーラム プロフィールなど) にアクセスできる場合は、それらも変更する必要があります。
新しいドメインが古いドメインに置き換わっているという外部シグナルを Google が検出すればするほど、このサイトが新しい場所に移動したという兆候が強くなります。
20. ブランド変更したソーシャル メディア ビジュアルを開始する
移行がブランド変更の一部である場合は、新しいブランドを反映するようにソーシャル メディアや外部ビジュアルも更新する必要があります。
これにより、すべてのチャネルにわたってメッセージの一貫性が保たれます。
メール/ニュースレターなどを更新することを忘れないでください。
通常、内部ユーザーが目にすることのないドリップ マーケティング キャンペーンがある場合、それらは忘れられる可能性があります。 したがって、すべてのマーケティング プラットフォームを確認し、それに応じて更新してください。
21. Pagespeed Insights または Lighthouse Audit を確認する
Chrome Dev Tools の PageSpeed Insights 指標または Lighthouse Audit が正常であることを確認することをお勧めします。
問題がある場合は、ページ速度を改善するための 39 のヒントをここで見つけることができます。
発売後のチェックリスト
新しいサイトが公開されたので、追加のチェックとハウスキーピングを行います。
このフェーズは発売日から始まり、数週間後まで続きます。
1. 必要に応じて Google Analytics の目標/コンバージョンを更新します
一部の URL は移行プロセス中に変更された可能性があります。 その場合は、特定の Google Analytics 目標の評価方法やコンバージョンが発生するページを更新する必要がある場合があります。
移行の (できればポジティブな) 結果を追跡することが重要であるため、このステップを最初に行います。
2. 必要に応じて、Facebook Pixel、Google Ads、またはその他のマーケティング ソフトウェアを更新します。
Google Analytics の目標と同様、新しい Web サイトのインフラストラクチャを反映するために更新が必要な他のサードパーティ ソフトウェアがある場合があります。
たとえば、Facebook キャンペーンや Google 広告キャンペーンを実行する場合、ページ レベルでトリガーされたイベントを更新し、イベントが期待どおりに動作していることを確認する必要がある場合があります。
3. ヒート マップ ソフトウェアを追加して、ユーザー エクスペリエンスがどのように向上したかを確認します
ユーザー エクスペリエンスの向上は、Web サイト移行の主な目標である必要があります。 したがって、ユーザーが新しいサイトとどのようにやり取りしているかを測定したいと考えます。
ヒート マップ ソフトウェアまたはユーザー セッション記録を使用して、ユーザーが新しいサイトをどのように閲覧しているかを確認することをお勧めします。
Hotjar を使用すると、両方を行うことができます。
4. 古いドメインを期限切れにしないでください。 (そうしないと、古いリンクが失われます)
301 リダイレクトはすべて適切な場所にあるはずです。 ただし、古いドメインを手放さないでください。
Google は、数か月後にドメインが移動したと見なすことを示唆していますが、私たちは安全策を講じたいと考えています。
なぜ？ なぜなら、更新されていない健全なバックリンクを持つドメインは通常、購入され、新しいサイトとして再作成されるからです。
そうなると、古いドメインへのリンクからすべてのトラフィックと電力が失われる可能性があります。
したがって、ドメインを保持し、毎年更新して、古いドメインへのヒットが引き続きリダイレクトされるようにします。
5. 分析 + トラブルシューティング
移行後の最初の数週間は、古いサイトとメトリクスを比較する必要があります。
現場での滞在時間は改善されましたか? 直帰率は低くなりますか？
ビジネスにとって重要な各指標を確認し、変化がプラスであるかマイナスであるかを評価します。
ネガティブですか？ 原因を考え出して、それに応じて変更を加えてください。
ただし、赤ちゃんをお風呂のお湯と一緒に捨てないでください。 小さな変更を加えます。 その後、数日後に、それらがプラスの影響を与えたかどうかを評価します。
6. Google Search Consoleでカバレッジの問題を確認する
Google が新しいサイトをクロールしているので、Google Search Console ([インデックス] > [ページ]) でページ レポートを確認してください。
これにより、サイトのクロール中に Google が発生した問題が特定されます。 また、現在インデックスが作成されているページの数と、特定のページがインデックスに登録されていない理由も表示されます。
問題や予期せぬ結果が見つかった場合は、解決に向けて作業を開始してください。
7. Search Console のエラーを確認する
Google が新しいサイトをクロールすると、Google Search Console は発生したエラーを表示し始めます。
たとえば、「拡張機能」セクションには、構造化データにエラーがあるかどうかが表示されます。
これらのエラーに注意してください。 できるだけ多くの箇所を (できるだけ早く) 修正する必要があります。
8. 可能な場合は、古いバックリンクを更新するためのアウトリーチを実行します。
301 リダイレクトは完全な値を渡す必要がありますが、新しい URL を指すようにできるだけ多くのバックリンクを更新することをお勧めします。
Seobility からバックリンクをエクスポートし、できるだけ多くのサイトに連絡してリンクを更新するよう依頼することをお勧めします。
そして、メールを送信しながら、あなたのクールな新しい再設計について知らせることができます。
注: あなたのホームページにリンクしている人に連絡することを優先することをお勧めします。
9. ランキングと検索トラフィックを比較する
最初の数週間の変動は正常です。 だからパニックにならないでください！ Google が新しいサイトを特定し、すべてのリダイレクトを認識するまでには時間がかかります。
ただし、1 か月ほど経過すると、トラフィックが落ち着き、理想的には改善し始めるはずです。
そうでない場合は? スケジュールされた Seobility クロールを監視して、エラーやその他の問題に注意することをお勧めします。
何かが見つかったら…修正してください。
Google Search Console のデータを確認することもできます。これにより、どのページのインプレッション数やクリック数が少ないかを把握できる可能性があります。 特定のページで大きな減少が見られた場合は、そのページに特別な注意を払う価値があるかもしれません。
サイトを再起動する準備はできましたか?
ウェブサイトのリニューアルは簡単な作業ではありません。
しかし、この完全な Web サイトの再起動と再設計のチェックリストでは、このプロセスをできるだけシンプルで理解しやすいものにするよう努めました。
冒頭で述べたように、すべての手順が移行または再起動の状況に適用されるわけではありません。 したがって、すべての情報を理解したら、上記の手順に従って独自のカスタム チェックリストを作成することをお勧めします。
そうすれば、再設計、再起動、または移行を SEO で成功させるためにできることはすべてやったと確信できます。
あなた自身で Web サイトの再設計、再起動、または移行を経験したことがありますか? 私たちと共有できる教訓はありますか? 上記のチェックリストは役に立ったと思いますか?
以下のコメント欄でお知らせください。
PS:ブログの更新情報を受信箱に直接届けます。