Web サイトの再設計 SEO: SEO を失わずに Web サイトを再設計する方法

公開: 2022-12-02

ウェブサイトの再設計はストレスの多い作業です。 最もやりたくないことは、たくさんのお金、時間、労力を再設計に費やして、輝かしい新しいサイトのオーガニック トラフィックが古いバージョンと比べて減少していることを確認することです。

SEO の不快感を回避し、一歩先を行くために、SEO を失わずに Web サイトを再設計するために知っておくべきことと実行する必要があることの概要をまとめました。

また、この最後に、再設計の SEO 要件とベスト プラクティスのダウンロード可能なチェックリストがあり、各ステップを順を追って説明するために使用できます。 開発サイトに meta noindex タグがあり、robots.txt がサイト全体で許可されていないことを確認してから、サイトの構築時に Google のインデックス登録を開始してください。

  • 再設計プロセスで重要なこと
  • SEO要素の変更
  • サイトの基盤技術の変更
  • ウェブサイトの再設計 SEO 悪い考え

再設計プロセスで重要なこと

Web サイトを再設計するときは、SEO の潜在的な長所と短所を考える必要があります。 それで、それはどういう意味ですか?

たとえば、コンテンツを変更したい場合があります (たとえば、サイトのセクションの名前など)。 「青」という名前のページがあり、「青」クエリで 1 位にランク付けされている場合、そのページの名前を「赤」に変更すると、おそらく「青」クエリでのランキングを停止することになります。 また、「赤」のクエリで上位にランクされるかどうかもわからない可能性があります。


大まかに言うと、これが再設計について考える方法です。SEO を変更するのでしょうか? もしそうなら、どのように?

これを理解するには、次のようないくつかの質問に答えて、再設計の主な目標と、更新または追加する KPI を概説する必要があります。

  • なぜ再設計を行うのですか?
  • 名前変えてる?
  • URL は変更されていますか?
  • ビジュアルのリデザインですか? どれくらい速いですか? 正しくレンダリングされますか?
  • 情報アーキテクチャを変更していますか?
  • この再設計中に対処したい技術的負債はあります?

すべての変更には、なぜそれを行うのか、それによって何を達成したいのかという目的が必要です。 さらに、サイトのどの側面が変化しているかを理解することで、プロセスの複雑さと、成功を測定するために後で何を探すべきかについての洞察が得られます.

たとえば、サイトのインフラストラクチャを変更する場合は、より多くのテストを行いたいと思うでしょうが、ブランド名を変更する場合は、ブランド クエリをより綿密に追跡する必要があります。

SEO要素の変更

サイトの SEO が再設計によってどのように影響を受けるかを理解する上で最も重要な側面の 1 つは、個々の SEO 要素を掘り下げて、変更されているものに注目することです。

SEO 要素には次のようなものが含まれます。

  • ページの内容
  • ページの命名方法
  • ページ上のコピー
  • ページに含まれる画像
  • ページの URL とは

どの要素が変化しているかを正確に把握すると、SEO の影響がより明確になります。

たとえば、ページのコピーを変更する場合、優先ページが現在どの用語でランク付けされているかを把握し、新しいコピーが古いページによく似ているか、新しいコンテンツ戦略に適切に沿っているかを確認する必要があります。

同様に、ページ上の画像を変更する場合は、その画像が現在 Google SERP 機能でランク付けされているかどうか、変更する前にどのクエリで表示されているかを確認する必要があります。

次に、次のようないくつかの質問について検討する必要があります。

  • サイトの構造をどのように変更していますか?
  • ページやセクションを削除または追加していますか?
  • 内部リンクを変更またはクリーンアップしていますか?
  • 内部リンクを追加していますか?

これらはすべて、SEO にプラスまたはマイナスの影響を与える可能性があります。

たとえば、いくつかのページを削除したり、それらを統合したりしているとしましょう。 ページをマージする主な理由の 1 つは、ページがあまりにも似ていて、キーワードの共食いやクロールの肥大化などの重複コンテンツの悪影響を避けたいということです。

キーワードのカニバリゼーションとは、同じキーワードで 2 つのページがランク付けされている場合を指します。つまり、これらのページのトピックに対する SEO 権限が分割されていることを意味します。

弱くて薄いページと、トピックが統一された強力なページを組み合わせることで、ランキングにプラスの影響を与えることができます。

この場合、最初に各ページに関連付けられたオーガニック トラフィックの相対的なレベルを確認し、それらがランク付けされているキーワードを確認して、どちらがより強力なページであるかを判断し、次に、より弱いページが入る正規バージョンを選択します。合併する。

これを行う際には、それぞれのページの要素を考慮して、コンテンツ、コピー、画像などがトピックに効果的に対応し、内部リンクを使用してサイトの関連部分に適切にリンクしていることを確認する必要があります。

サイトの構造を変更する場合は、ページのブレッドクラム リンクと BreadcrumbList スキーマが機能し、Web サイトの新しい情報アーキテクチャを正確に反映していることも確認する必要があります。

サイトの基盤技術の変更

サイトのコンテンツ管理システム (CMS) を変更する場合は、追加の考慮事項がいくつかあります。 ほとんどのコンテンツ管理システムには、すぐに使える機能とそうでない機能を正確に理解するために、いくつかの基本的な SEO 機能が標準で備わっています。

さらに、これらの新しいページを作成する方法を選択しても、マシンがそれらを簡単に見つけて読み取ることができることを確認することをお勧めします.

新しい Web サイトのレンダリングの問題を確認する

レンダリングとサイトの速度は、Web サイトの再設計の大きな部分を占めます。 たとえば、 Google は JS をレンダリングするのに HTML よりも 9 倍の時間がかかる場合があるため、JS レンダリングは、Google が新しいページを見つけてインデックスを再作成するのにかかる時間に大きな影響を与える可能性があります。

過去に LSG が協力した自動車会社は、JS を使用して内部のファセット検索とページ付けを再設計したときに、この問題を抱えていました。 以前は、検索フィルターは、Google がクロール可能なパスを作成して、メーカー、モデル、年などのさまざまなカテゴリを検索するためのリンクで構成されていました。

しかし、リスト ページを再設計したとき、JS を使用してこれらのリンクなしで検索ファセットを入力したため、車両のメーカー、モデル、年式へのクロール パスがありませんでした。 ページネーション (「?page=2」、「?page=3」などのコンテンツ) で同じ問題が発生し、適切な <a href> リンクを使用せず、代わりに <span> と < の場合に JS を使用しました。 button> タグがクリックされて、新しいリストが読み込まれ、URL が変更されました。 Google は <a href> リンクと XML サイトマップの送信を通じてのみ URL を検出するため、これらの URL の書き換えの原因となったページネーションの <span> タグをクリックすることはありません。

実際の <a href> リンクなしで JS を使用してコンテンツを読み込むと、Googlebot がページを読み取ってインデックスに登録しようとするため、大きな問題が発生する可能性があります。ユーザーはクリックして新しいページを読み込む場所を知っていますが、Google は知らないためです。

また、慣例にとらわれないレンダリングにより、ユーザーと Google にとって異なるページが表示される可能性もあります。 この背後にある原因としては、コンテンツ生成スクリプトの読み込みに時間がかかりすぎる、robots.txt ファイルでレンダリングに不可欠なアセットが許可されていない、ブラウザーがクローラーよりも適切に解析できる CSS エラー、ページ ファイル サイズが大きすぎることが考えられます。

この問題が発生していないことを確認するには、Google サーチ コンソールの「 Test live URL 」ツールを使用して、ページが Google に対してどのように表示されるかを確認します。 このようにして、Google が認識しているページのスクリーンショットを表示し、レンダリングの問題を確認できます。

また、Google が認識する HTML をコピーしてテキスト エディターに貼り付け、それを HTML ファイルとして保存し、そのローカル HTML ファイルをブラウザーで開いて、基本的に Google と同じようにページを表示することもできます。 完全にレンダリングされた DOM に表示されないコンテンツは、ページを完全にレンダリングする Google の機能に問題がある可能性があります。

多くの場合、サイトの機能がユーザーにとって、Google に表示されるものと多少異なっていても問題ありませんが、ナビゲーション バーのセクションのように、重要なリンク、スタイル、および Google にクロールしてもらいたい要素を表示できる必要があります。ページの上部、SEO クリティカルな <head> 要素、画像、および主要なコンテンツは、ブラウザーまたは検査ツールを使用してレンダリングされた DOM で表示されます。

結論:複雑なロジックに基づいて要素が大きく変化する非常に動的な Web サイトがある場合、ページのコンテンツをレンダリングするために JavaScript を使用する必要がある可能性があります。 Web サイトの主要な基盤としての Javascript レンダリング ライブラリは、SEO の観点からは逆効果になることがよくあります。

ウェブサイトの速度とパフォーマンスの問題

ウェブサイトの速度は、再設計中のもう 1 つの重要な考慮事項です。 Google は、Core Web Vitals (CWV) と呼ばれる、実際の G​​oogle Chrome ユーザーからの実世界のデータに基づいてページ速度を決定するために、3 つの主要な指標を使用します。 CWV メトリックを渡す能力はランキング要因であり、Google とユーザーの両方がサイトのパフォーマンスをどのように見るかに影響します。 これらの CWV メトリックは次のとおりです。

  • LCP (最大のコンテンツ ペイント): ユーザーが画面に表示される最大のコンテンツ要素の URL を要求してから、スクロールする前 (「スクロールせずに見える部分」と呼ばれるもの) にレンダリングしてビューポートに表示されるまでにかかる時間。 巨大なブロック レベルのテキスト要素、画像、またはビデオは、多くの場合、最大の要素です。

  • FID (初回入力遅延): ユーザーが初めてページを操作してから (リンクをクリックする、ボタンをタップする、またはスクロールするなど)、ブラウザがその操作に反応するまでの時間。 この評価は、ユーザーが初めてクリックしたインタラクティブな要素に基づいています。 ブラウザーのコンピューティング スレッドが遅い読み込み JavaScript によって占有されていると、FID に悪影響を与える可能性があります。

  • CLS ( Cumulative Layout Shift ):ページ読み込みプロセス全体で発生する予期しないレイアウトの変更。 ボタンをクリックしようとすると、そのボタンの上に新しい要素が突然読み込まれ、そのボタンが押し下げられて、間違った場所をクリックするように強制されることが、CLS の問題の非常に一般的な例です。 CLS メトリックは、個々のレイアウト シフト スコアをすべて加算することによって計算されます。 スコアの範囲は 0 から任意の正の数値で、0 はシフトがないことを示し、数値が大きいほどページ レイアウトのシフトが多いことを示します。

再設計中にサイトの速度に対処し、ページのパフォーマンスを向上させる方法たくさんありますが、主な方法は次のとおりです。

  • 過剰なコード(CSS や JS など) を取り除きます。 ページに 6MB の JS があり、450kb しか使用していない場合でも、ページが使用している 450kb を見つけるために 6MB をすべてロードする必要があります。 スクリプトの数とそれらのスクリプトのサイズを最適化すると、3 つの CWV メトリックすべてに役立ちます。
  • 重要なアセットを最初に読み込みます。 ページ上のコード、画像、またはその他の要素の読み込み方法に優先順位を付けて、最も負荷の高い要素が最後に読み込まれ、重要な要素が最初に読み込まれるようにします。 スクロールせずに見えるコンテンツのレンダリングに不可欠なスクリプトと画像を事前に読み込み、それ以外はすべて遅延または遅延読み込みします。 ブラウザーが可視コンテンツを表示する前に解析する必要があるレンダリング ブロッキング スクリプトは、LCP に深刻な損害を与える可能性があります。
  • ページのスクロールせずに見える部分の CSS の最小高さを設定します ヒーロー画像が他の要素よりも後で読み込まれる場合、その画像を読み込むための空きスペースを確保しておくと、その画像が最後に読み込まれたときに CLS がシフトするのを防ぐことができます。
  • スクロールせずに見えるコンテンツのスタイル設定に重要な CSS を<head> 内にインラインで配置し、後で読み込まれる CSS ファイルと競合しないようにします。

サイトを設計するときは、ユーザーにとって最も重要な要素は何か、CSS または JS がそれらをどのようにレンダリングして遅くなりすぎないようにするか、より重要なコンテンツのレンダリングをブロックするか、ペナルティを受ける方法でパフォーマンスが低下しないかを検討してください。または、コンテンツを完全にレンダリングする前に、Google が退屈して先に進む原因となります。

Google 検索コンソールを使用してページのパフォーマンスを確認し、「 Core Web Vitals 」セクションで潜在的な問題を特定できます。

ウェブサイトの再設計 SEO 悪い考え

上記およびダウンロード可能なステップバイステップ ガイドに記載されているベスト プラクティス以外にも、再設計中に避けるべきことがいくつかあります。

  1. オーガニック トラフィックを獲得しているかどうかや、それを維持する方法を考慮せずに、サイトのセクションを削除する

これは、あなたが思っているよりもよくある間違いです。 サイトのどのセクションがオーガニック トラフィックの観点から優先されているか、および各セクションの相対的なトラフィック レベルを確認してから、それらを削減またはリダイレクトすることを開始します。

例: LSG は、すべてのモバイル ページにモバイル サブドメインを使用している大規模な e コマース サイトと連携しており、それを削除したいと考えていました。

私たちが持ち込まれたとき、彼らはすでに1年間再設計に取り組んでいました. そこで、「この 1,000 万の URL を削除する場合は、関連するデスクトップ ページまたは www ページにリダイレクトする必要があります」と伝えました。

残念ながら、彼らの IT コンサルタントは次のように述べています。 そして、さまざまな理由で理解するのに時間がかかりすぎます。 だから私たちはそれをするつもりはありません。」

私たちは彼らに災害が起こるだろうと伝えましたが、彼らは耳を傾けず、最終的にモバイル ページの SEO をすべて壊してしまいました。 これにより、トラフィックが失われただけで、最初の 1 か月で約 500 万ドルの費用がかかりました。

  1. ページごとのリダイレクトなしでバックリンク プロファイルを確認せずにページを削除する

重要なページが常に最大のトラフィックを獲得するとは限りません。 ページに関連付けられたリンクは、バックリンク プロファイルにとって重要になる可能性があるため、削除する前に確認する必要があります。 現在のサイトの古い 301 リダイレクトはすべて新しい再設計に移行する必要があり、SEMrush や Ahrefs 301 などの SEO ツールで見つかった破損したバックリンクは関連する新しい URL にリダイレクトされます。

例:プライバシー ポリシー ページのように、多くのバックリンクを取得するトラフィックの少ないページがあるとします。 これは、他の Web サイトに表示されるものを構築するベンダーによく見られます。

サイトを再設計し、そのプライバシー ポリシー ページを忘れると、トラフィックがなくなる可能性がありますが、すべてのリンクの 90% がそのプライバシー ページを通過する可能性があるため、サイトの残りの部分に対して多くの SEO を失う可能性があります。

したがって、個々のページのトラフィックが少ないからといって、それらが重要でないというわけではありません。 SEO を失わないように、再設計によってバックリンク プロファイルがどのように変化するか、または変化してはならないかを確認する必要があります。 大量のトラフィックを受け取るサイトのセクションへの変更、または削除されるバックリンクは、ページごとに 301 リダイレクトして、検索者の意図を 1 対 1 で置き換えることができるサイトの新しいセクションにリダイレクトする必要があります。

  1. サイトがインデックス可能であることを確認するのを忘れている

開発用サーバーでサイトを構築している場合、そのサイトのインデックス作成をブロックする可能性があります。 これはいい。 ビルド中にインデックスを付けたくありません。 これらのブロック、meta noindex タグ、または robots.txt の禁止を解除することを忘れないでください。

これで、ウェブサイトの再設計に関連する推奨事項と禁止事項の概要を理解できたので、チェックリストをプロセスの段階的なガイドとして使用できるはずです Webサイトの再設計SEOについてご不明な点がございましたら、お気軽にお問い合わせください。