SEO効果を失わずにWebサイトのドメインを移行する方法！7ステップで超詳しく解説

ドメインの変更をしようとしている人は要注意。重要なキーワードでの順位が下がってしまったら、数週間から数カ月に及んで損失が発生する可能性があります。しかし、サイト移行時にすべてのステップをきちんと踏んでいれば、損失を最小限にとどめ、長期的にはGoogleからの高評価につなげることもできます。

この記事では、SEO効果をできるだけ失わずにWebサイトのドメインを移行する方法を6つのステップでご紹介します。

ドメイン移行を検討段階で、リスクや基本的な知識を得たい人は、こちらの記事もどうぞ。

ホームページの引っ越しでサイトパワーを失わないためのドメイン移行ハック

Workship MAGAZINE

1. サイト移行の範囲設定と計画

サイトの移行をする前に、目的を明確にする必要があります。

たとえば常時SSL化だけの場合と、サイトを完全にリニューアルする場合ではまったく違いますよね。前者はトラフィックをうまく維持すること、後者はよりユーザビリティを上げて収益を上げることが重要なポイントとなるでしょう。サイトの移行は、従来の問題に対処する絶好の機会です。

サイト完成後に修正するよりは、一度にさまざまな問題に対処できる方が費用対効果も高いです。

しかし、サイト移行に伴うリスクもはじめから想定していなくてはなりません。その上でどのような予防措置を取るかを複数検討しておくのです。

コンテンツ、SEO、UX、およびアナリティクスのチームからのフィードバックを求め、起こりうる最大のリスクと利益のリストを作り、対処策を練ります。そのうえで、目的や利用可能なリソースに基づいてサイト移行計画を立てましょう。

サイトの移行は、場合によっては数ヶ月に及ぶ可能性があります。

移行前に、各タスクの担当（SEOコンサルタント、UXコンサルタント、コンテンツエディタ、Web開発者）と予定納期を決めておきましょう。それぞれの役割と責任範囲を、全員が把握している必要があるため、各タスクについては詳細に記載して共有しておくことが重要です。

さらに、サイト移行の開始時間も事前に考えておかなくてはなりません。トラフィックのピーク時に、サイト移行の過程で予想外のことが起こるよりは、トラフィックの比較的少ない時間帯を選びます。

不測の事態にも対応できるよう、柔軟性を持って取り組みましょう。

2. ドメイン移行前にしておくべき準備

ワイヤーフレーム作成

実際にサイトを移行する前に、必ずリニューアル後のプロトタイプまたはワイヤーフレームを作成しましょう。

新サイトのメインとなるテンプレートを確認しておくことで、SEOとUXの両方の問題を早い段階で特定できます。たとえば、コンテンツの大部分がカテゴリページから削除されていたり、トラフィックの多いページがメインナビゲーションに表示されなくなっていることなど…… 潜在的なSEOの問題については、ページのデザインやコピーの大幅な変更を徹底的に見直す必要があります。

技術的なSEO対策

次に、細かなSEO対策を準備します。

少なくとも、次の領域をカバーするようなプロジェクトにしましょう。

• URL構造
• メタデータ（動的に生成されるデフォルト値を含む）
• 構造化データ
• 標準およびメタロボット指令
• コピー＆見出し
• メインナビゲーションとセカンダリナビゲーション
• 内部リンク（任意の形式で）
• ページネーション
• XMLサイトマップ
• HTMLサイトマップ
• Hreflang（国外にサイトがある場合のみ）
• モバイル設定（アプリ、AMP、またはPWAサイトを含む）
• リダイレクト
• カスタム404ページ
• JavaScript、CSS、イメージファイル
• ページの読み込み時間（デスクトップとモバイルの場合）

仕様には、CMS機能の領域も含まれている必要があります。

• カスタムURLを指定してデフォルトのURLを上書きする
• ページタイトルを更新する
• メタ記述の更新
• h1-h6見出しを更新する
• デフォルトの正準タグを追加または修正する
• メタロボットの属性をindex / noindex / follow / nofollowに設定する
• 各画像の代替テキストを追加または編集する
• 説明、URL、画像、タイプ、サイト名のためのOpen Graphフィールドを含む
• カード、URL、タイトル、説明、イメージのためのTwitter Open Graphフィールドを含める
• 一括アップロードまたはリダイレクトの修正
• robots.txtファイルを更新する

特定の属性（h1など）を更新するときに、他の要素（ページタイトルやナビゲーションメニューなど）に影響を与えないようにすることも重要です。

優先順位を決める

サイト移行における成功のカギを握るのは、移行されたページの量とクオリティです。したがって、本当に重要なページを集中して改善しましょう。主に、レガシーサイトへのトラフィックを増やしているページや、外部リンクが発生したページ、変換が良好なページなどです。

優先順位は以下のステップで決めます。

(1)古いサイトをクロールする

古いサイトをクロールして、すべてのURL、ページタイトル、メタデータ、ヘッダー、リダイレクト、壊れたリンクなどをコピーします。以下のポイントには注意を払いましょう。

• robots.txtがあっても無視（重要な部分が誤ってブロックされた場合のみ）
• 内部リンクにおける「nofollow」を外す
• すべてのサブドメインをクロール
• 開始フォルダの外側をクロール
• ユーザーエージェントをGooglebot（デスクトップ・スマートフォン両方）に変更

なお、バックアップ用として、移行が完了してから数か月の間は、古いサイトのクロールデータのコピーをファイルまたはクラウドに保存しておくことをおすすめします。

(2)インデックス可能なページの特定方法

クロールが完了したら、古いサイトのインデックスページを確認します。次のような特性を持っていることが多いのでチェックしておきましょう。

• 200サーバーに応答する
• canonicalタグがない、または自己参照できるcanonicalタグがある
• メタロボットがない
• robots.txtファイルから除外されない
• 他のページから内部リンクされている

インデックス可能なページは、サイトにトラフィックを誘導する唯一のページだからこそ、サイト移行では優先順位を高める必要があります。

(3)検索上位のページを特定する

元のサイトで最も成果を上げているページを特定することで、サイト移行の際に改善するページの優先順位付けができます。

以下のフィールドを含むスプレッドシートを作成しましょう。

• 従来のURL（クロウデータからインデックス可能なURLのみを含む）
• 過去12か月間のオーガニック検索（アナリティクス）
• 過去12か月間の収益、コンバージョン、コンバージョン率（アナリティクス）
• 過去12か月間のページビュー数（アナリティクス）
• 過去90日間のクリック数（サーチコンソール）
• リンク先ページ（Majestic SEO / Ahrefs）

上記の情報を1か所にまとめることで、最も重要なページを特定できます。このページは、有機的な訪問を生み出し、コンバージョンにつながり、収益に貢献し、多くの参照ドメインのリンクにつながります。

何らかの理由で最も関連性の低いページにリダイレクトされるべきである場合、それらを要求しているユーザーが404ページに飛ぶことはなく、以前に持っていたリンク・エクイティがサイトに残ります。

これらのページのいずれかがなくなり、適切にリダイレクトされない場合、サイトのランキングとトラフィックに悪影響が及ぶ可能性があることも覚えておきましょう。

リダイレクト準備

リダイレクトは、サイト移行においては必須です。古いサイトのURLが存在しなくなり、正しくリダイレ​​クトされない場合、ユーザーは404エラー、または意図に合わない無関係のページにランディングしてしまい、結果的にウェブサイトの順位は簡単に下がってしまうでしょう。

リダイレクトは、検索エンジンとユーザーが、もはや存在しない、名前を変更した、または別の場所に移動したページを見つけるのに役立つため、非常に重要です。

SEOの観点から見ると、リダイレクトは検索エンジンがサイトの新しいURLをより迅速に発見してインデックスできるだけでなく、古いサイトのページが新しいサイトのページとどのように関連しているかがわかります。

301、302、JavaScriptリダイレクト、メタリフレッシュ

サイト移行に伴ってURLが変わる場合、301リダイレクトを使用します。これらは検索エンジンに新しいURLのインデックスを付けるだけでなく、以前のURLから新しいURLへランキング信号を転送するように指示します。

302は、新しいURLのインデックス作成が遅くなり、ランキング信号は古いページから新しいページに引き継がれるまでにかなりの時間がかかることを知っておく必要があります。この302は、リダイレクトが永続的に存続する必要がない場合にのみ使用するべきなのです。

近いうちにリダイレクトの更新や削除が必要な場合や、国別、言語別、デバイス固有のリダイレクトが必要な場合は、302リダイレクトを使用してください。

メタリフレッシュとJavaScriptリダイレクトは避けるべきです。JavaScriptのクロールにはGoogleの方が良くなっていますが、これらが検出されるか、ランク付けのシグナルが新しいページに渡されるという保証はありません。

リダイレクトマッピングプロセス

URLの変更をしていないのに移行後にサイトが表示されなくなった場合は、既存のページがリダイレクトできない原因を探る必要があります。

リダイレクトマッピングファイルは、次の2つの列を含むスプレッドシートです。

• 従来のサイトのURL – >古いサイトのページのURL
• 新しいサイトのURL – >新しいサイトのページのURL。

古いサイトから新しいサイトにページをマッピング（リダイレクト）するときは、常にそれを最も関連性の高いページにマッピングしてみてください。

関連するページが存在しない場合は、ページをサイトにリダイレクトしないでください。無関係なページにユーザーを誘導してしまうことで、UXが非常に悪くなります。

Googleは、関連性のないページにページ全体をリダイレクトすると、404と見なされることもあります。新しいサイトで同等のページが見つからない場合は、親カテゴリページにマッピングしてみてください。

マッピングが完了したら、ファイルを開発チームに送信してリダイレクトを作成し、新しいサイトを公開する前にテストしましょう。

リダイレクトマッピング処理中の効率の向上

小規模なサイトのURLマッピングは、手動でもできます。しかし、数千から数十万ページからなる大規模なサイトでは、すべての単一URLを手動でマッピングすることは事実上不可能であり、自動化する必要性が出てきます。

古いサイトと新しいサイトの共通項目を見つけることで、時間を大幅に節約できるでしょう。これには、ページタイトル、H1見出し、プロダクトコード、SKUなどの他のページ識別子が含まれます。

リダイレクトマッピングに依存する属性が一意であり、複数のページにわたって繰り返されていないことを確認しましょう。リダイレクトマッピングが完了した後にURLが更新されると、リダイレクト、リダイレクトチェーン、リダイレクトループなど、望ましくない状況に対処しなければならない可能性が出てきます。

従来のリダイレクトを可能な限り多く保存しておき、新しいサイトのリダイレクトと組み合わせても問題が発生しないようにしてください。

この初期段階では、リダイレクトマッピングスプレッドシートに同じURLが「古いサイトURL」と「新しいサイトURL」の両方として表示されているかどうかを確認しましょう。

リダイレクトルールで重複コンテンツを避ける

コンテンツの重複を避けるために、基準となるリダイレクトルールをいくつか用意しておきます。

• URLの大文字と小文字を含むすべてのURLは、すべて小文字のURLにリダイレクトされる（例：https : //www.website.com/Page/からhttps://www.website.com/pageなど）

• ホスト：www以外のすべてのURLは、wwwなどと同じURLにリダイレクトする。（https : //website.com/page/はhttps://www.website.com/page/に、など）
• 常時SSL化のプロトコル
• 後続のスラッシュ：末尾にスラッシュが含まれていないURLは、末尾にスラッシュが付いたバージョンにリダイレクト

また、サイトの内部リダイレクトはおすすめしません。検索エンジンがページの読み込むのに余分な時間がかかり、クロールに悪い影響を与えるからです。

3. 移行前と移行後のサイトパワーを比較するための準備

新しいWebサイトの立ち上げにあたり、古いサイトのパフォーマンスをベンチマーキングする必要があります。ベンチマーキングは、新しいサイトのパフォーマンスと以前のサイトのパフォーマンスを比較するだけでなく、新しいサイトでどの部分が不調になったのかを診断し、迅速に対処することです。

キーワードの検索順位を追跡できるようにしておく

サイトのランキングを頻繁に見ていない場合は、サイトリニューアル前にぜひ確認しましょう。でないと、移行がスムーズに行われたのか、それとも上手くいかなかったのか、把握できません。

サイトのオーガニック検索のキーワードを特定し、デスクトップとモバイルでそれらをトラッキングしてください。ヘッド、ミドル、およびロングテールのキーワードの組み合わせを何千も監視するのは、通常は現実的ではないため、監視する必要のある最小限のものは、サイトへのトラフィックを促進するキーワードのみにしておきます。

ブランドキーワードと非ブランドキーワードの両方からトラフィックを獲得する場合は、トラッキングPOVからより多くのものに集中するキーワードのタイプを決める必要があります。

一般的には、ブランド以外のキーワードは競争力が高く、揮発性が高い傾向があります。ほとんどのサイトでは、主にこれらに焦点を当てることが理にかなっています。

デスクトップとモバイルの両方で検索順位を見ましょう。これにより、ひとつのデバイスタイプでパフォーマンスの問題が発生した場合、起動後の問題を診断するのがずっと簡単になります。複数の国から大量のトラフィックを受け取った場合は、他の市場でもランク付けのキーワードを考慮する必要があります。これは、国ごとにビジビリティとランキングが大きく異なる可能性があるためです。

サイトのパフォーマンスを記録しておく

新しいサイトのページの読み込み時間は、トラフィック数と販売の両方に大きな影響を与える可能性があります。ページが読み込まれる時間が長いほど、直帰率も高くなってしまうことはよく言われていますね。

古いサイトのページ読み込み時間とサイトパフォーマンススコアを記録し、移行後と比較しましょう。

GoogleのPageSpeed Insights and Lighthouseツールを使用して、すべての主要ページタイプを確認することをおすすめします。以下のようなサマリーテーブルを使用して、最も重要なパフォーマンス指標のベンチマークを行うことができます。これは、新しいサイトを公開した後の比較に役立ちます。

サーチコンソールデータを保管しておく

また、古いサイトのサーチコンソールデータを可能な限りエクスポートしておくことも検討しましょう。これらは90日間のみ利用可能で、新しいサイトが公開されると消えてしまう可能性があります。

エクスポートすべきデータは以下の通りです。

• 分析クエリとページの検索
• クロールエラー
• ブロックされたリソース
• モバイルユーザビリティの問題
• URLパラメータ
• 構造化データエラー
• あなたのサイトへのリンク
• 内部リンク
• インデックスのステータス

4. サイト公開前のレビューすべき確認事項

とにもかくにも、テストを始めましょう。古いサイトと新しいサイトとの間のコンテンツ関連の問題、たとえば、デスクトップとモバイルサイトのコンテンツの不一致などが、早期に特定することができます。

まずはじめに、テストサイトが検索エンジンにインデックスされないようにしましょう。特定の人だけが閲覧できる方法を、いくつか紹介していきます。

特定のIPだけに公開範囲を限定する

ホワイトリストに登録された、特定のIPアドレスだけにテストサイトを利用できるようにする、という方法は非常に効果的です。主な利点は、ホワイトリストに登録されたユーザーが何の問題もなく簡単にサイトにアクセスして、クロールできることです。

唯一の欠点といえば、IPの制限のためにサードパーティのウェブツール（Googleのツール）を使用できないことでしょうか。

パスワード保護

これも別の方法ではありますが、場合によっては欠点が出てきます。一つは、ログイン画面を通貨できない場合、パスワードで保護されたWebサイトをクロールしてテストすることができないこと。

もう一つは、認証用のフォームを使用するパスワードで保護されたWebサイトは、サードパーティのアプリケーションを使用してクロールすることができますが、重大かつ予期しない問題が発生する危険性があります。これは、クローラがページのすべてのリンクをクリックして（ログインしているとき）、ページの作成または削除、プラグインのインストール/アンインストールなどのリンクを簡単にクリックすることができるためです。

Robots.txtで検索防止

次のコードをテストサイトのrobots.txtファイルに追加すると、検索エンジンがテストサイトのページをクロールできなくなります。

ユーザーエージェント： * Disallow：/

この方法の欠点の一つは、テストサーバーに表示されるコンテンツにはインデックスが作成されなくても、許可されていないURLがGoogleの検索結果に表示されることです。もう一つの欠点は、上記のrobots.txtファイルが実際のサイトに移動すると、インデックスが解除される可能性があることです。すでに何度も経験した技術者もいるため、この方法を使って検索エンジンをブロックすることはお勧めしません。

ユーザージャーニー

サイトをリニューアルするとき、ユーザージャーニーにはある程度の影響が及ぶ可能性があります。ユーザーデータのない状態でもできるだけ先のことを予測し、サイトのコンバージョン率に悪影響を及ぼしうる懸念事項を取り除いていくことが最善でしょう。

この段階でのA / Bテストはほとんど不可能なので、まずはユーザーテストを実施して、実際のユーザーからのフィードバックを得ます。残念ながら、UXの問題に対策するサイト改善は多くの時間と労力を費やさなくてはならないこともあり、大変ではあります。

サイト構成のレビュー

サイト移行は、サイトの構成を見直す絶好の機会です。キーワードターゲティングのコンテンツを再編成して、検索トラフィックの可能性を最大限に高めたり、キーワード調査をすることで、コンバージョン率の高いページを特定したりできます。

一方で、サイトの再構成は、慎重に行われる必要があるということも忘れてはいけません。重要なページが隠れてしまっていたり、同じキーワードに対して最適化された類似のページが多すぎたりすると、検索からの流入を阻害してしまう恐れがあるためです。

メタデータとコピーレビュー

サイトのページタイトル、メタ説明、見出し、およびコピーが問題なく古いサイトから新しいサイトに転送されていることを確認します。新しいページを作成した場合は、これらのページが最適化されていることを確認し、他のページで既に狙ったキーワードと重複しないようにします。

プラットフォームを再構築する場合は、新しいページが作成されるときに新しいプラットフォームのデフォルト値が異なる可能性があることに注意してください。

適切に最適化されたページがない状態で新しいサイトを起動すると、サイトのランキングやトラフィックに悪影響です。ユーザーが作成したコンテンツ（ユーザーレビュー、コメントなど）もアップロードされているかどうかを確認しましょう。

内部リンクレビュー

内部リンクはウェブサイトのバックボーンです。サイトのコピーがいかにうまく最適化され、構造化されていても、完璧な内部リンクでサポートされていない限り十分ではありません。内部リンクは、以下のリンクを含むサイト全体で見直しましょう。

• メインナビゲーションとセカンダリナビゲーション
• ヘッダーとフッターのリンク
• 本文のコンテンツリンク
• ページネーションリンク
• 水平リンク（関連記事、類似製品など）
• 垂直リンク（ブレッドクラムナビゲーションなど）
• クロスサイトリンク（例えば、グローバルサイト間のリンクなど）

技術チェック

新しいサイトができた後に大きな技術的不具合が発生してしまうのを避けるために、一連の技術チェックを実施します。

Robots.txtファイルレビュー

ステージング環境で新しいサイトのrobots.txtファイルを準備します。これでエラーやバグをテストし、新しいサイトが公開されたときに検索エンジンのクロールに関する問題を回避できます。robots.txtファイルが次のディレクティブを使用して検索エンジンへのアクセスを妨げる、というサイト移行の古典的な間違いには気をつけましょう。

Disallow：/

これが誤ってライブサイトに持ち越されると、検索エンジンがサイトをクロールしないようにします。検索エンジンがインデックスページをクロールできない場合、そのページに関連付けられたキーワードは検索結果で降格され、最終的にページのインデックスが解除されます。

しかし、ステージング時のrobots.txtファイルに新しいサイトのrobots.txtディレクティブが設定されていると、このような事態を避けることができます。

新しいサイトのrobots.txtファイルを準備するときは、次の点を確認してください。

• インデックスを作成するページへの検索エンジンアクセスをブロックしていない
• 検索エンジンがページコンテンツのレンダリングに必要なJavaScriptやCSSリソースをブロックしていない
• 従来のサイトのrobots.txtファイルのコンテンツが、必要に応じて見直されている
• もはや存在しないサイトマップではなく、新しいXMLサイトマップを参照する

標準的なタグのレビュー

サイトの標準タグを確認します。カノニカルタグを持たないか、別のURLを指しているカノニカルタグを持っていて、それが意図されているかどうか疑問に思うページを探します。

カノニカルタグをクロールして、200個のサーバー応答を返すかどうかを確認することを忘れないでください。そうでない場合は、3xx、4xx、または5xxサーバー応答を排除するために更新する必要があります。noindexディレクティブと組み合わされた別のURLを指し示す標準タグを持つページも探してください。なぜなら、これらの2つのシグナルは競合しており、そのうちの1つを排除する必要があるからです。

メタロボットレビュー

ステージングサイトをクロールしたら、メタロボットのプロパティが “noindex”または “nofollow”に設定されているページを探します。この場合は、それぞれを調べて意図的であることを確認し、 “noindex”または “nofollow”ディレクティブを指定します。

XMLサイトマップレビュー

二つの異なるタイプのサイトマップを準備します。一つは新しいサイトのすべてのインデックス可能なページを含み、もう一つは古いサイトのすべてのインデックス可能なページを含みます。前者は、新しいサイトのURLをGoogleにインデックスさせるのに役立ちます。

後者は、Googleがリダイレクトを認識し、インデックス付きURLの一部が新しい場所に移動したため、検索して検索結果をすばやく更新できるようになります。

各XMLサイトマップをチェックする必要し、次のことを確認しましょう。

• 問題なしで検証できる
• UTF-8としてエンコードされます
• 50,000以上の行を含んでいない
• 圧縮されていない場合、サイズは50MBを超えない

50Kを超える行がある場合、またはファイルサイズが50MBを超える場合は、サイトマップをより小さなものに分割する必要があります。これにより、Googleがサイトマップを頻繁に要求すると、サーバーが過負荷になるのを防ぎます。

さらに、各XMLサイトマップをクロールして、インデックス可能なURLのみが含まれていることを確認する必要があります。インデックスを作成できない以下のようなページは、XMLサイトマップから除外する必要があります。

• 3xx、4xx、および5xxページ（リダイレクト、見つからないページ、不良リクエストなど）
• ソフト404。404の代わりに200のサーバー応答を返すコンテンツのないページ
• 正規化されたページ（自己参照の標準URLは別として）
• メタロボットのnoindexディレクティブを持つページ

<！DOCTYPE html> <html> <head> <meta name = “robots” content = “noindex” /> （…） </ head> <body>（…）</ body> </ html>

• HTTPヘッダーにnoindex X-Robots-Tagを持つページ

HTTP / 1.1 200 OK 日付：火、2017年11月10日17:12:43 GMT （…） X-Robots-Tag：noindex （…）

• robots.txtファイルからブロックされたページ

きれいなXMLサイトマップを構築することで、新しいサイトが実際に公開されたときにインデックスされやすくなります。

Excelで各XMLサイトマップをダウンロードして開くと、hreflangやimage属性などの追加属性の詳細が表示されます。

HTMLサイトマップレビュー

移行前のサイトのサイズと種類によっては、HTMLサイトマップを置く方がいい場合もあります。サイトのメインナビゲーションからリンクされていないURLで構成されるHTMLサイトマップは、ページの発見とインデックスを大幅に強化します。

ただし、URLが多すぎるHTMLサイトマップを生成しないようにしてください。何千ものURLを含める必要がある場合は、セグメント化されたHTMLサイトマップを作成することを検討しましょう。

ネストされたサイトマップの数と各サイトマップに含める必要がある最大URLの数は、サイトの権限によって異なります。Webサイトの信頼性が高いほど、入れ子になったサイトマップとURLの数が増えます。

たとえば、NYTimes.comのHTMLサイトマップは3つのレベルで構成されています。それぞれのサイトマップには、1つのサイトマップにつき1,000以上のURLが含まれています。これらのネストされたHTMLサイトマップは、1851年以降に公開された記事を発見する際に検索エンジンのクローラを助けます。

NYTimes HTMLサイトマップ（レベル1）

NYTimesのHTMLサイトマップ（レベル2）

構造化されたデータレビュー

構造化データマークアップのエラーは早期に特定する必要があるため、新しいサイトが公開される前に修正する必要があります。理想的には、Googleの構造化データテストツールを使用して、すべてのページテンプレートではなくすべてのページテンプレートをテストするのが理想的です。

特にモバイルウェブサイトが応答しない場合は、デスクトップページとモバイルページの両方のマークアップを確認してください。

このツールは、既存のエラーのみを報告しますが、漏れは報告しません。たとえば、製品ページテンプレートにProduct構造化データスキーマが含まれていない場合などです。したがって、エラーをチェックするだけでなく、各ページテンプレートにコンテンツタイプの適切な構造化データマークアップが含まれていることを確認する必要があります。

JavaScriptクロールレビュー

GoogleがJavaScriptの解析が必要なコンテンツをクロールできるようにするには、新しいサイトのすべての単一ページテンプレートをテストする必要があります。ステージングサイトでGoogleのフェッチとレンダーツールを使用できるなら、確実にした方がいいでしょう。

GoogleがJavaScriptで作られたコンテンツをクロールし、インデックスできたとしても、JavaScriptフレームワーク全体でJavaScriptのコンテンツをクロールできるとは限りません。

次の表は、Elephate Agencyの共同創立者であるBartosz氏の調査結果をまとめたものです。JavaScriptフレームワークの中にはSEOに対応していないものがあり、AngularJSが現在最も問題となっています。

Bartosz氏は、他の検索エンジン（Bing、Yandex、Baiduなど）がJavaScriptで生成されたコンテンツのインデックスに苦労していることも明らかにしました。これはサイトのトラフィックがこれらの検索エンジンに依存しているかどうかを知る上で重要です。

ウェブ開発におけるJavaScriptフレームワークの人気が高まるにつれて、優先的に対応せざるを得なくなってくるでしょう。

最後に、外部リソースがブロックされているかどうかを確認する必要があります。残念ながら、これはJavaScriptやCSSファイルなどの多くのリソースが独自のrobots.txtファイルでブロックされているサードパーティのウェブサイトによってホストされているため、100％を制御できるものではありません。

未解決のまま残すと重大な悪影響を及ぼしうるこの種の問題の特定には、Fetch and Renderツールが役立ちます。

モバイルサイトのSEOレビュー

まず、robots.txtファイルが、モバイルサイトのコンテンツのレンダリングに不可欠なJavaScript、CSS、またはイメージファイルを誤ってブロックしていないことを確認します。

これは、検索エンジンがモバイルサイトのページコンテンツをレンダリングおよびインデックスする方法に悪影響を及ぼし、モバイルサイトの検索の可視性およびパフォーマンスを下げる可能性があるからです。

モバイルファーストのインデックスレビュー

Googleのモバイルファーストインデックスに関連する問題を避けるためには、モバイルウェブサイトを徹底的に見直し、次の領域でデスクトップサイトとモバイルサイトの間に矛盾がないことを確認してください。

• ページタイトル
• メタ記述
• 見出し
• コピー
• 標準的なタグ
• メタロボットの属性（noindex、nofollowなど）
• 内部リンク
• 構造化データ

反応性の高いウェブサイトでは、デバイス間で同じコンテンツ、リンク、マークアップを提供する必要があります。また、上記のSEO属性は、デスクトップとモバイルのウェブサイトで同じにする必要があります。

上記に加えて、モバイルサイトの設定に応じていくつかの技術チェックを行う必要があります。

レスポンシブルサイトのレビュー

レスポンシブウェブサイトは、すべてのデバイスに同じHTMLコードを提供しなければならず、画面サイズに応じて（CSSを使用して）調整されます。

Googlebotは、ページとそのアセットをクロールすることが許可されている限り、このモバイル設定を自動的に検出できます。したがって、Googlebotが画像、JavaScript、CSSファイルなどのすべての必須アセットにアクセスできるようにすることは非常に重要です。

ブラウザにページが応答していることを知らせるには、meta = “viewport”タグを各HTMLページの<head>内に配置する必要があります。

<meta name = “viewport” content = “width =デバイス幅、初期スケール= 1.0”>

メタビューポートタグがない場合、フォントサイズが違った形で表示されるかもしれません。そうなると、Googleにはページをモバイルフレンドリーではないものとして評価される可能性があります。

別々のモバイルURLのレビュー

モバイルウェブサイトでデスクトップから別のURLを使用する場合は、次の点を確認してください。

1. 各デスクトップページに、対応するモバイルURLを指すタグがある
2. 各モバイルページに、対応するデスクトップURLを示すrel = “canonical”タグがる
3. モバイルデバイスでデスクトップURLが要求されると、それぞれのモバイルURLにリダイレクトされる
4. AndroidやiPhoneなどを含むすべてのモバイル機器で作業をリダイレクトされている
5. デスクトップページとモバイルページとの間に関連性のないクロスリンクがない。つまり、デスクトップページにある内部リンクはデスクトップページにのみリンクし、モバイルページにあるリンクは他のモバイルページのみにリンクされる
6. モバイルURLは200サーバーレスポンスを返す

ダイナミックサービングレビュー

ダイナミックサービングウェブサイトは、デスクトップやモバイルなど各デバイスに異なるコードを提供しますが、同じURLです。

動的配信サイトで、さまざまなHTTPヘッダーが正しく設定されているかどうかを確認します。これは、ダイナミックサービングウェブサイトがモバイルユーザーエージェントのHTMLを変更し、さまざまなHTTPヘッダーによってGooglebotがモバイルコンテンツを発見するために必要なことです。

モバイルフレンドリーレビュー

モバイルサイトの設定に関わらず、モバイルユーザーエージェントを使用してページを確認し、次のことを確認します。

1. ビューポートが正しく設定されている
2. フォントサイズが小さすぎない
3. タッチ要素（ボタン、リンクなど）が近すぎない
4. 広告、メーリングリスト登録フォーム、アプリダウンロードポップアップなどのような侵入型のインタースティシャルがない
5. モバイルページの読み込みが遅すぎない

Googleのモバイル対応のテストツールを使用すると、上記の問題のほとんどを診断できます。

AMPサイトレビュー

AMP Webサイトがあり、そのサイトのデスクトップバージョンが利用可能な場合は、次の点を確認してください。

• AMP以外の各ページ（デスクトップ、モバイル）には、対応するAMP URLを指すタグがある
• 各AMPページには、対応するデスクトップページを指すrel = “canonical”タグがある
• 対応するデスクトップURLを持たないAMPページには、自己参照型カノニカルタグがある

また、GoogleのAMPテストツールを使用してAMPが有効であることを確認する必要があります。

混合コンテンツエラー

Google ChromeがHTTPページを安全でないと判断すると、画像、CSS、JavaScriptファイルなどのすべてのリソースが安全なHTTPSを介して要求されるようになります。

混合コンテンツは、より安全なHTTPS接続を介してロードされたページが、安全でないHTTP接続を介してアセットを要求すると発生します。ほとんどのブラウザは、危険なHTTPリクエストをブロックするか、ユーザーエクスペリエンスを妨げる警告を表示するだけです。

複合コンテンツのエラーを特定には、クローラアプリケーション、GoogleのLighthouseなどを使用するなど、さまざまな方法があります。

画像アセットレビュー

GoogleはHTMLページよりも頻繁に画像をクロールします。サイトの画像を移行する場合、Googleが移行されたイメージをすばやく発見するお手伝いをしてあげましょう。画像インデックス作成の難しい部分は、画像が表示されるウェブページと画像ファイル自体の両方がインデックスされなければならないことです。

サイトのパフォーマンスレビュー

最後に、古いサイトのページ読み込み時間を測定し、これがステージングで利用できるようになったときの新しいサイトとの比較をしてください。この段階では、外部リソース（画像、JavaScript、CSS）、HTMLコード、Webサーバーの設定など、ネットワークに依存しないパフォーマンスの側面に焦点を当てます。

アナリティクストラッキングレビュー

Googleアナリティクスのトラッキングが適切に設定されていることを確認します。このレビューは、トラッキングコードの実装を超えて専門のアナリティクスコンサルタントが行うのが理想的です。目標とイベントが適切に設定されていること、eコマーストラッキングが実装されていること、eコマーストラッキングが有効になっていることなどを確認してください。

テストのリダイレクト

新しいサイトが公開される前にリダイレクトをテストすることは非常に重要であり、後で多くのトラブルを避けることができます。ステージング/テストサーバーでリダイレクトを確認する方法はたくさんありますが、リダイレクトをテストせずに新しいWebサイトを起動しないようにすることが重要です。

ステージング/テスト環境でリダイレクトができるようになったら、リダイレクトのリスト全体をクロールし、次の問題を確認します。

• リダイレクト・ループ（それ自体に無限にリダイレクトするURL）
• 4xxまたは5xxサーバー応答でリダイレクト
• リダイレクトチェーン（別のURLにリダイレクトするURL、別のURLにリダイレクトするURLなど）
• 4xxまたは5xxサーバー応答を返す標準URL
• 正規のループ
• 標準的なチェーン（別のページを指し示す正規表現を持つ別のページを指す正規表現など）
• プロトコル/ホストの矛盾。たとえば、URLはHTTP URLとHTTPS URLまたはwww URLとwww以外のURLの両方にリダイレクトされます。
• 先頭と末尾の空白文字。Excelでtrim（）を使用して削除
• URLに無効な文字がないか

5. 公開日にやること

ダウンタイムを最小限におさえる

サイト移行後、一時的にダウンする可能性がありますが、ダウンする時間は最小限に抑えなければなりません。Webサーバーは503サーバー応答で任意のURL要求に応答する必要があります。

これは、サイトが後でサイトをクロールするメンテナンスのために一時的にダウンしていることを検索エンジンのクローラに通知するものです。

サイトが503サーバー応答をせずにサイトが長時間ダウンし、検索エンジンがその状態のサイトをクロールすると、オーガニック検索のビジビリティが大幅に落ちてしまい、即座に復旧するのが難しくなってしまいます。さらに、ユーザーへの通知も必要となります。

テクニカルスポットチェック

新しいサイトが公開されてから、すぐに次の項目を確認しましょう。

1. 検索エンジンがクロールをブロックされていないことを確認するrobots.txtファイル
2. トップページのリダイレクト
3. トップページの標準タグ
4. トップページのサーバーレスポンス
5. Noindex / nofollowディレクティブ

スポットチェックは、サイトが完全にレスポンシブでない限り、モバイルサイトとデスクトップサイトの両方で実行する必要があります。

また、Googleのサーチコンソールで以下のことも確認します。

1. XMLサイトマップをテストしてアップロードする
2. ドメインの優先順位の設定（wwwまたはnon-www）
3. 国際ターゲット設定
4. 潜在的な重複コンテンツの問題を早期に解決するよう、URLパラメータを設定し
5. 拒否ファイルをアップロードします
6. アドレスの変更ツールを使用する（ドメインを切り替える場合のみ）

6. サイト公開後のテスト

これは「第3ステップ：サイト公開前の確認事項まとめ」で説明したものとほぼ同じものです。ただし、前回との違いは、公開後はさらに多くのデータとツールにアクセスできること。問題が発生したらサイトのパフォーマンスに直接影響するため、このフェーズで確認することは多いですが、問題が早期に特定されれば、それだけ解決も速まります。

第3ステップで紹介した確認事項に加え、ここではSearch Consoleの機能を最大限に活用します。

クロールの統計情報とサーバーログを確認する

Googleが新しいサイトのページをクロールしていることを確認するため、Search Consoleで利用可能なクロールの統計情報に注目してください。一般に、Googlebotが新しいページに到達すると、1日にクロールする平均ページ数が増加する傾向があります。

サーバーのログファイルを確認することは、クロールの問題や非効率性を突き止める最も効果的な方法です。BotifyやOn Crawlなどのツールでクロールをサーバーログデータと組み合わせて、検索エンジンがクロールしないページ、内部リンクがなされていないページ、内部リンクの多い低価値ページを特定しましょう。

クロールエラーを定期的に確認する

公開してから最初の数週間は、できれば毎日クロールエラーを監視してください。これらのエラーを毎日ダウンロードし、報告されたURLをクロールし、都度修正していくことで、より迅速な復旧が可能になります。報告されているすべての404をリダイレクトする必要はほとんどありませんが、最も重要なリダイレクトを追加する必要があります。

Googleアナリティクスでは、最も一般的に要求されている404のURLを簡単に見つけることができます。

 

 

Googleのツールで速度を測る

では、どうやってサイトの読み込み速度を測定するのでしょうか。こんなときは、GoogleのLighthouseとPagespeed Insightsが役立ちます。

PageSpeed Insightsは、デスクトップとモバイルの両方のページのパフォーマンスを測定し、GoogleがChromeから収集したユーザデータに基づいて、実際のページ速度データを示しています。このツールの主要カテゴリは以下の通りです。

• スピードスコア：First Contentful Paint（FCP）とロードされたDOMコンテンツ（DCL）の2つの指標を使用して、ページをFast、Average、またはSlowのいずれかに分類します。両方の指標がそのカテゴリの上位3分の1にある場合、ページは高速と見なされます。
• 最適化スコア：パフォーマンスに基づいてページをGood、Medium、またはLowに分類します。
• ページの負荷分散：ChromeユーザーエクスペリエンスレポートのすべてのFCPイベントとDCLイベントを比較して、Fast、Average、Slowに分類します。
• ページ統計：開発者がページの外観と機能を変更した場合、ページがより速くなるかどうかを示すことができます。
• 最適化の提案：ページに適用できるベストプラクティスのリストです。

GoogleのLighthouseは、モバイルのパフォーマンス、アクセシビリティ、プログレッシブWeb Appsの測定に非常に便利です。どちらのツールも、報告されたサイトのパフォーマンス上の問題を改善するための推奨事項を提供します。

Test your mobile speedを使用して、ページの読み込み時間が遅いことでの離脱率なども測ることができます。

同じツールを使用すると業界の比較もできますので、ぜひ使ってみましょう。

実際のユーザーからの速度の測定

サイトが公開されると、サイトにアクセスしたユーザーに基づいてサイトの速度を評価することができます。Googleアナリティクスでは、新しいサイトの平均読み込み時間を以前のものと簡単に比較できます。

下の地図は、ユーザーのローディング時間を地理別に表したものです。次の例では、ページの読み込み時間が英国、米国、ドイツのユーザーには満足のいくように見えますが、他の国に住むユーザーの方がはるかに高いです。

7. 移行後パフォーマンスのレビュー

サイトの移行は成功したか？これは、新しいサイトが公開されてすぐ、関係者全員が知りたがることです。実際には、最初の数週間または数カ月間のビジビリティがサイトの規模などによって大きく異なるため、少し待たなくてはいけません。

小規模なサイトの場合は、新しいサイトのビジビリティと以前のサイトのビジビリティを比較する期間は、4〜6週で十分です。一方、大規模なウェブサイトの場合は、明確になるまで少なくとも2〜3カ月間待たなければならない場合があります。

さらに、新しいサイトが前のサイトと大きく異なる場合、ユーザーが慣れるまではユーザージャーニーなどをさせる必要があります。そのような変更は、ユーザーが何度も訪問する場合は数週間後に改善されるはずです。いずれにしても、新しいサイトのUXに関するデータを集めておきましょう。

一つ覚えておかなくてはいけないのは、これが一般的な経験則であり、他の要因とともに考慮する必要があるということ。たとえば、技術的な問題に対応するために新しいサイトの立ち上げから数日または数週間後に大幅な追加変更が行われた場合は、移行後に評価されるのも当然遅れてくるでしょう。

測定方法

サイト移行の関係者はサイトのそもののパフォーマンスにばかり目がいきがちですが、移行後に収益が低下する理由は他にもたくさんあります。たとえば、シーズン的な傾向、ブランド関心の低下、サイトのコンバージョン率を大幅に低下させたUXの問題、モバイルのパフォーマンスの低下、ページの読み込み時間の低下など。

有機的なトラフィックと収益の数字に加えて、次の点にも注意してください。

• デスクトップ＆モバイルの可視性（SearchMetrics、SEMrush、Sistrix）
• デスクトップとモバイルのランキング（信頼性の高いランク追跡ツールから）
• ユーザーエンゲージメント（直帰率、ページの平均時間）
• ページの種類ごとのセッション数
• ページタイプごとのコンバージョン率
• 端末別のコンバージョン率（新しいサイトを公開してからそれぞれコンバージョン率が増減しているか）
• インデックスページの数（Search Console）
• XMLサイトマップの提出済みページとインデックス付きページ（Search Console）
• 少なくとも1回の訪問（アナリティクス）を受信したページ
• サイトのスピード（PageSpeed Insights、Lighthouse、Google Analytics）

上記のすべての領域を調べて、初めて移行が成功したかどうかを判断できます。