ドメイン移行SEO:Webプロフェッショナル向けのチェックリスト
公開: 2019-05-22あなたのウェブサイトを移行する非常に良い理由がいくつかあります:
- 一部の企業にとって、それはセキュリティの問題です。 良い例は、httpsドメインに移動する必要があるhttpドメインです。
- 他の人にとっては、コンテンツ管理システムのようなものを変更しながらクリーンアップすることの問題です。 たとえば、JoomlaからDrupalに移行する場合は、依然として重要なコンテンツを移行し、それだけを計画するのも良い時期かもしれません。
- 一部の組織では、買収の問題です。 買収された会社は、「マザー」ドメインに組み込まれる必要がある場合があります。
- 一部の企業にとっては、ブランド変更の時期であり、ドメイン名は変更するものの1つです。
移行の理由が何であれ、すべてのドメイン移行にはいくつかのリスクが伴うことを理解する必要があります。リスクの中には良性のものもあれば、Webサイトのトラフィックを破壊するものもあります。
注意深く計画された移行は、これらのリスクを軽減します。 また、Webサイトの所有者は、既存の検索エンジンの参照を保持したり、実際にWebサイトのトラフィック全体を改善したりすることができます。
移転前のベンチマーク
移行のより技術的な側面を計画する前に、さまざまなツールを使用するために掘り下げる必要のあることがいくつかあります。 これは、長いドライブの前にタイヤを蹴るのに似ています。 準備された移行プロジェクトに参加することをお勧めします。
Webサイトはそれぞれ異なりますが、以下の項目のバリエーションが必要になる可能性があります。
- Google検索コンソールから、1年分のGoogleインプレッション、クリックスルー、および位置をエクスポートします。 これにより、移動後に満たす必要のある検索エンジンプレゼンスのベースラインが確立されます。
- ウェブサイト分析ツール(WebTrendsやGoogle Analyticsなど)から、オーガニックトラフィック、総訪問数、404エラーの平均数、バウンス率、コンバージョンの月次統計をエクスポートします。 これも少なくとも1年間は入手してください。 ツールにリアルタイム機能がある場合は、平日の同時トラフィックを把握して、起動後に新しいドメインと比較することもできます。
- 調査ツール(ForeSeeやQualarooなど)がある場合は、満足度と、必要なものを見つけることができる人の割合をエクスポートします。
- コンバージョンが購入ではなくフォームの送信である場合は、これをマーケティング自動化ツールや顧客関係管理(CRM)からエクスポートします。
これらの統計は、比較するための定性的統計と定量的統計の組み合わせを提供します。 移行のためにさまざまな統計を収集することの利点の1つは、問題が発生した場合に、問題を三角測量して、問題がかなり迅速に切り分けられることです。
一部の移行には大量の可動部分が含まれる可能性があり、ほとんどのチームは移動中に非常に忙しくなる可能性があります。 問題の特定と切り分けにかかる時間を最適化して、すでに忙しいチームに過度の負担をかけないようにする必要があります。 このように、データの処理は、すべてのチームが拡張される可能性が高いリリース日ではなく、準備段階で行われます。
ベースライン統計を収集して問題を特定することは、Webサイトの移行を計画している場合、すべてのマーケターが行うべきことです。
さまざまなタイプのWebサイト移行の計画
実行する移行の種類に応じて、計画する必要のあるさまざまなタスクがあります。 決定する必要があることがいくつかあります。
- ドメインのみの変更とURLパスの変更
- 同じコンテンツまたは異なるコンテンツ
- 新しいコンテンツ管理システム(CMS)または同じCMS
- 新しいツールまたは同じツール
違いを考慮して、計画する必要があるものに取り掛かりましょう。
ドメインのみの変更とURLパスの変更
ドメインのみを移動しても、トップレベルドメインの後の文字列は変更されません。 (これらは「パス」または「URLパス」です。)
たとえば、 / products/product1や/about/ companyなどのすべての文字列は変更されないが、ドメインがdomain.comからnew-domain.comに変更される場合、ドメインのみが変更されます。
ドメインの変更
- www.domain.com/path1からwww.new-domain.com/path1 _
- www.domain.com/path2からwww.new-domain.com/path2 _
- www.domain.com/path3からwww.new-domain.com/path3 _
httpからhttpsへのリダイレクトも、ドメインのみの移動と見なされます。
対照的に、URLパスが変更された移行は、ドメインの後の文字列の変更を意味します。
ドメインとURLパスの変更
- www.domain.com/path1からwww.new-domain.com/new-path1 _
- www.domain.com/path2からwww.new-domain.com/new-path2 _
- www.domain.com/path3からwww.new-domain.com/newfolder/newstringsfornewpath3 _
URLパスが変更されない移行の場合、通常、Webサイトのページごとに1つのリダイレクトを記述せずに、リダイレクトのドメイン文字列を自動的に変更する技術的な方法があります。
URLパスが実際に変更される移行の場合、ページレベルの301リダイレクトを作成する必要があります。 これは間違いなくもっと面倒です。
何千ものページがあるサイトに情報アーキテクチャの変更がある場合、すべてに対してページレベルのリダイレクトを作成することは現実的ではない可能性があります。 トラフィックのしきい値を決定する必要がある場合があります。 たとえば、検索エンジンと総トラフィックランキングに基づいて、175,000ページすべてではなく、上位5,000ページのみをリダイレクトしたい場合があります。
同じコンテンツまたは異なるコンテンツ
古いドメインと同じコンテンツを新しいドメインに効果的に配置する場合、内部リンク、コンテンツグループの意味の確保などに関して、考慮すべきことはそれほど多くありません。
ただし、コンテンツの重要なチャンクを追加または削除する場合は、それを慎重にマッピングする必要があります。
- 変更するカテゴリはありますか?その過程でページを「孤立」させますか? それらのページは、新しい家を見つけるか、他のページに折りたたまれる必要があるかもしれません。 それはあなたの計画の一部である必要があります。
- 新しいコンテンツを考慮しても、メインメニューは意味がありますか? 移動後にアクセスするのが難しい重要なページであるセクションがある場合は、コンテンツの変更が行われた後、それらに追加の経路を提供することを検討してください。
新しいCMSまたは同じCMS
www.example.comからwww.new-example.comに移動し、CMSを変更しない場合、コンテンツの実際の移行は非常に簡単です。
あるCMSから別のCMSに切り替える場合、同じ移動は簡単な作業ではない可能性があります。 あなたは…する必要があります
- 古いサイトのレイアウトとテンプレートが新しいシステムで適切にサポートされることを確認してください。
- CMSコンテンツを新しいコンテンツ管理システムが受け入れるものにエクスポートする方法があるかどうかを判断します(これが100%でなくても、コンテンツ移行の部分的な自動化が役立つ場合があります)。
- CMSの変更により手動で行われるコンテンツ移行の部分に時間を割いてください。
新しいツールまたは同じツール
実際のツールとツールの展開方法は、古いドメインと新しいドメインで異なる場合があります。
あなたはいくつかのことを考える必要があります:
- 新しいシステムには、独立して、またはタグ管理ツールの一部として、ツールに必要なスクリプトのプラグインに似たマスターページなどがありますか? または、サイト全体でスクリプトを複数回プラグインする必要がありますか? 後者の場合は、十分な時間を確保してください。
- ツールごとの実装からGoogleタグマネージャーなどのタグ管理ツールに切り替える場合は、このシナリオをテストするための十分な時間を確保してください。 タグ管理ツールは便利ですが、慣れるまでに時間がかかる可能性があるため、ドメイン切り替えのタイムラインに含める必要があります。
- ツールを追加する場合は、回帰テストの時間を確保してください。 新しいツールは古いツールとすぐにうまく機能しない可能性があり、デバッグする時間が必要になります。
サイト移行計画の完了
さまざまな種類のサイト移行を理解したら、次はサイト移行計画を立てます。
かなり複雑なシナリオの例を作成して、不要な部分を取り除くことができます。
古いCMSから新しいCMSに移行するとします。 また、新しいサイトの情報アーキテクチャは少し異なります。一部のURLパスは新しい場所に移動されます。
リダイレクトの観点から、早い段階で実行する必要があるいくつかのことを次に示します。
1.ページレベルの301リダイレクトを処理する方法があることを確認します
「手動」ページレベルのリダイレクトを設定するには、いくつかの方法があります。 構成ファイルの編集を伴うものもあれば、XMLをモジュールにドロップすることを伴うものもあります。また、これを処理する基本的なCMS関数を備えているものもあります(古いCMSに引き続きアクセスできると仮定します)。 早い段階でどの道を進むかを決めてください。そうすれば、将来の頭痛の種を避けることができます。
2.ワイルドカードまたは条件付きリダイレクトを処理できるかどうかを確認します
.htaccessファイルまたは同様の構成ファイルを微調整できる場合は、各リダイレクトを個別に設定するのではなく、条件を介して一部のリダイレクトを管理できます。 これにより、時間を節約できます。
3.古いサイトのトップページをエクスポートします
ランクの決定要因として、総トラフィックとオーガニックトラフィックのどちらかを選択します。 (有機トラフィックはこれにかなり適しているので、移行前に検索エンジンの紹介を実際に促進するページをリダイレクトすることを知っています。)
- サイトのサイズを考慮して、意味のあるしきい値を選択してください。 上位100ページは、トラフィックのほとんどが上位80ページに向けられている500URL程度のサイトに最適です。 ただし、数万のURLがあるサイトの上位5,000ページが必要になる場合があります。
4.トップページを新しい場所にマップします
これは、時間を節約するために実行できる手動の手順です。 スプレッドシートのトップページのリストを並べて、古いURLとしてマークし、その横に新しいURLを追加します。 何を構築するか(XMLファイルなど)がわかっている場合は、開始できるファイルがあります。
301リダイレクトの利点
新しいドメインに移動するときに、最も価値のあるページに301(または「永続的」)ページレベルのリダイレクトを追加すると、次の2つのことが行われます。
- ユーザーエクスペリエンス(UX)のメリットのために、ユーザーを正しいページに移動します
- SEOのメリットのために、検索エンジンのスパイダーに移動について通知します
サイトの一部のみで情報アーキテクチャが変更された場合、通常、同じURLパスを持つサイトの部分で条件付きリダイレクトまたはワイルドカードリダイレクトを実行し、小さい方には1つずつページレベルのリダイレクトのみを使用できます。絶対に必要なユースケースの数。
たとえば、新しいサイトでは/product/の下にあるすべてのものが/products/に変更される可能性があります。 ワイルドカード置換を使用して、移動のその部分を処理できます。 ただし、 / about /の下のすべてが新しい「パス」を取得するため、 /about/の後の実際の文字列が変更されるとしましょう。 / about /の下にあるすべてのものについて、古いURLを新しいURLにマップし、301ページレベルのリダイレクトを追加する必要があります。
このようにして、リダイレクトを管理するチームを圧倒することなく、古いドメインからのリンクエクイティ転送のメリットを享受できます。
一般的な落とし穴を回避する
ドメインの移行が失敗する可能性のある方法はたくさんあります。
ここにあなたが注意する必要がある一般的なもののほんの一部があります:
1.自由に使用できるリダイレクトツールは、スイッチに対して十分な堅牢性を備えていません。
- 一部のリダイレクトツールはhttpURLのみを管理し、httpsURLを処理できません。 したがって、httpsURLを処理する他の方法を見つける必要があります。
- 一部のリダイレクトツールはCMSのネイティブ部分であり、セットアップに膨大な時間がかかります。 数百または数千のURLがある場合、これは問題になります。
- 一部のリダイレクトツールはワイルドカードを処理できないため、手動リダイレクトを計画する必要があります。 そして、あなたは必要な余分な時間を考慮する必要があります。
ウェブサイトの移行を成功させるには、マーケターが自由に使用できるリダイレクトツールを完全に理解し、可能なことだけを計画する必要があります。
上記のような説明を使用して、開発者が利用できるものを早い段階で明確にします。
発売日のかなり前に制限があることに注意してください。 手動の手順がたくさんある場合は、それらの手順に取り組むために十分な時間を確保してください。
これにより、切り替えの日が来ても、この領域に驚きがないことが保証されます。
2.チームは成功または失敗を適切に評価できません。
チームが満たすベンチマークを確立していない場合(サイトのランク付けされた検索用語、総オーガニックトラフィック、総訪問数、サイトの満足度と成功率など)、移行がスムーズに進んだかどうかを判断するのは非常に難しい場合があります。
全体的なトラフィックはほぼ同じかもしれませんが、成功率は低下し始めました。 満足度スコアは同じかもしれませんが、サイトがランク付けする検索用語が少なくなり、オーガニックトラフィックが減少しています。
あなたが見ている数字の範囲がない場合、ウェブサイトが実際にヒットしている間にドメインの切り替えがスムーズに進んだように見えるかもしれません。 パフォーマンスが悪く、それを認識している方が、パフォーマンスが悪く、うまくやっていると考えるよりも望ましいです。
この問題を回避するために、サイトの複数の側面のベンチマークがあることを確認してください。
3.チームは移行する重要なページを見逃しています。
情報アーキテクチャが変更されたドメインの場合、検索エンジンでランク付けされているページや、複数のソースから大量のトラフィックを取得しているページを簡単に失う可能性があります。
すべてのトップページを確実に移行するためにトップページのエクスポートを行った人がいない場合、チームは通常、移動後にトラフィックが減少します。
これが発生した場合、チームはレポートをまとめてスクランブリングし、古いコンテンツがまだどこかのファイルに残っているかどうかを確認して、新しいドメインに持ち込むことができるか、トラフィックの損失に耐えられるかどうかを確認する必要があります。 この種の計画の失敗は、トラフィック全体に大きな打撃を与える可能性があります。
リダイレクトトリガーを引く前に、分析ツールを確認してトップページをエクスポートしたこと、およびコンテンツプランが良好な状態であることを確認する必要があります。
4.タスクの量が多すぎて、チームが処理できなくなります
ドメインの移行に必要なタスクの量を変更できるものはたくさんあります。
サイトには相対リンクではなく絶対リンクがある可能性があり、当初の予想よりもはるかに多くの内部リンク調整を行う必要があります。
リダイレクトツールにはワイルドカードをサポートする機能がない可能性があり、計画よりも多くの手動リダイレクトを管理する必要があります。
オンサイト検索の注目の結果など、新しいCMSに移行する必要のあるページコンテンツ以外のアイテムが存在する可能性があり、リリース後にそれに時間を費やす必要があります。
通常、切り替えが発生したときにサイトに追加のリソースを割り当てるのが最善です。そのため、計画どおりに物事が進まない場合は、余裕ができます。
切り替え当日のタスクの管理
すべてのリダイレクトが期待どおりに機能するとします。
移動したいすべてのコンテンツが移動されました。 404エラーの急増は発生せず、すべてのツールが以前と同じように起動し、ページコンテンツ以外のすべての構成が適切に移行します。
それは素晴らしいスタートですが、それでもローンチ日にSEOタスクのためのいくつかのタスクを残します:
1.robots.txtで許可されていない条件を正しく取得する
robots.txtファイルは、検索エンジンのスパイダーにサイト上でクロールすべきものとすべきでないものを伝えます。
設定されたrobots.txtファイルがあることを開発者とSEOに確認し、それを移動します。 持っていない場合は、少なくともrobots.txtファイルが次のように読み取られないようにしてください。
- ユーザーエージェント: *
- 禁止:/
その組み合わせは、グーグルと他の検索エンジンにあなたのウェブサイト上の何も索引付けしないように伝えます。 これは避けるべきシナリオです。
2.新しいGoogle検索コンソールアカウントの作成と検証
新しいドメインが確立されたら、それをGoogle Search Consoleに登録し、ドメインを所有していることを証明する必要があります。 これは、Googleがルートで認識するファイルをドロップする方法から、Google Tag Managerを使用する方法まで、さまざまな方法で実行できます。
- フォルダのGoogle検索コンソールアカウントを設定します。 ドメインを検証したら、サイトのセクションを追加のプロパティとして追加できます。 これにより、「製品」セクションだけ、または「会社概要」セクション(ある場合)につながる検索を確認するなどのことができます。 これにより、追加のレイヤーを取得して、オーガニックトラフィックがドメインの移行を生き延びたかどうかを確認できます。
3.サイトマップの提出
コンテンツ管理システムに応じて、CMS、クロールツール、またはメモ帳から手動でURLリストを使用してサイトマップを生成できます。
ここでできることの1つは、サイトのセクションごとに個別のサイトマップを生成することです(「製品」セクション用に1つのサイトマップ、「会社概要」用に1つのサイトマップなど)。Googleが製品ページの90%をインデックスに登録する場合しかし、あなたのアバウトページのわずか5%で、インデックスが不十分なセクションだけを修正することがわかります。 この問題は、Webサイトのセクションごとに個別のサイトマップがある場合にのみ発生します。
さまざまなウェブサイトセクションのサイトマップを生成したら、検索コンソールを介してそれらをGoogleに送信する必要があります。
4.ドメインスイッチについてGoogleに通知する
これは、ベテランのマーケターでさえ見逃しているステップです。 Google Search Consoleには、「住所の変更」を宣言できるツールがあります。 これを使用するには、新旧のドメインのGoogle Search Consoleプロパティを検証してから、GoogleSearchConsoleにリストされている手順に従う必要があります。
起動後の統計の監視
これまでにこの投稿のアドバイスに従っている場合は、比較するための定量的および定性的なベンチマークがあります。
- 調査ツールのデータ。 満足度の大幅な低下と、必要なものを見つける人々の能力は、サイトの新しい構造が訪問者を混乱させる可能性があることを意味する可能性があります。 新しいアーキテクチャを再考する必要があります。
- Google検索コンソールと分析ツールのデータ。 いくつかのランキングの損失と有機的なトラフィックの落ち込みと組み合わされた404エラーの急増は、通常、少なくともいくつかのリダイレクトが失敗していることを意味します。 リダイレクト方法を調査する必要があります。
- 分析ツールのデータ。 検索エンジンのトラフィックが大幅に減少することなく、合計トラフィックと参照トラフィックが大幅に減少した場合は、他のWebサイトがリンクしているコンテンツに移動しなかったことを意味します。 そのコンテンツを再検討する必要があります。
トラフィックのリアルタイム監視もここで役立ちます。 サイトの同時訪問者数がリリース前の数値を大幅に下回っている場合(たとえば、半分未満)、何かがオフになっていることがわかり、さらに深く掘り下げる必要があります。
ドメイン移行での過剰な準備などはありません
ドメインの移動は、面倒なプロセスになる可能性があります。
プロセスがあなたのサイトにとってうまくいかない可能性がある多くの方法があります。 そして、成功への道はほとんどありません。
とはいえ、ドメインを変更する必要がある場合は、準備をしすぎるのが最善です。 もし、あんたが …
- リダイレクトツールで何ができるかを早い段階で学びましょう。
- 穴がなくなるまでコンテンツプランにこだわる、そして
- データを使用して移行を管理する
…新しいドメインにシームレスに移行できる可能性が高くなります。
特定の種類の移動では、計画にこだわると、切り替え後にトラフィックとコンバージョンが増える可能性があります。