再設計後にウェブサイトの状態を確認する方法

公開: 2022-09-08

再設計プロセスは複雑で、多くの人員と時間が必要です。デザイナーはサイトを美しくしたい、開発者はサイトをすばやくコーディングしたい、SEO はサイトを最適化したいと考えています。これら 3 つの意図は、必ずしも互いに補完し合うわけではありません。

再設計は、CMS、カスタムコード、フレームワーク、ページビルダーなどを使用してさまざまな方法で行うことができます。ただし、すべての方法が SEO に適しているわけではないため、SEO のベストプラクティスを使用して再設計を実装することをお勧めします。この記事では、SEO Web サイトの再設計を実行する方法と、完了後に Web サイトの状態を確認する手順について説明します。

Web サイトの再設計後に発生する可能性がある SEO の問題

Web サイトの開発がベストプラクティスに基づいていない場合、SEO に関しても多くの問題が発生する可能性があります。インデックス作成の問題、ページの破損、ウェブサイトの速度、メディアの最適化の悪さ、応答性の問題など。これらの問題はすべてランキングに確実に影響を与え、オーガニックトラフィックの減少につながります.

リニューアル前にホームページをチェック

新しいデザインを公開する前にできる素晴らしいことは、後で比較できるように、Web サイトのヘルスチェックを実行することです。まず、すべてのページのリストをクロールして保存し、それらが新しいサイトに表示されていることを確認します。 URL に加えて、それらに関連付けられた重要なデータ (メタタグ、コンテンツなど) を保存して、更新されたサイトで重要なものが失われていないことを検証する必要があります。特に大規模な Web サイトの場合、手動で収集するのは難しい場合がありますが、自動 Web サイトヘルスチェックソフトウェアを使用するより簡単な方法があります。たとえば、SE ランキング Web サイト監査ツールは、サイトの各ページの統計をチェックして保存するため、現在の状態と変更履歴を確認できます。Web サイト全体または各ページを前回のクロールと比較できます。必要です。このツールを使用して、120 を超える条件で Web サイトを一度にチェックするプロセスを示します。これにより、必要なすべてのデータが 1 か所にまとめられます。

ウェブサイトの健全性をチェックし、再設計後に問題を検出する方法

新しいサイトバージョンを公開した後にサイトの状態を確認する最善の方法は、古いバージョンと比較することです。そのためには、SE Ranking Website Audit で 2 回のクロールを実行する必要があります。1 回は変更前、もう 1 回は変更後です。これら 2 つのクロールを使用すると、重要なものがまだ利用可能であり、古い問題が修正されていることを確認できます。詳しく調べてみましょう。

クロール可能性とインデックス可能性に関する基本的な問題

再設計後、最初に確認することの 1 つは、すべてのページにアクセスでき、新しいバージョンで再インデックスできることです。ページのクロールとインデックス作成に影響する主な問題は次のとおりです。

200 以外の応答コード (1)
Web サイトにそのような URL がない場合、応答コードは 4xx です。ページがリダイレクトされた場合、応答コードは 3xx です。サーバー側のエラーが発生した場合、応答コードは 5xx です。これらのいずれの場合でも、ページを読み込んでユーザーに表示することはできないため、クロールしたり、Google インデックスに追加したりすることはできません。すべての重要なページに 200 応答コードがあることを確認してください。
ページが robots.txt でブロックされている (2)
ページに「noindex」メタロボットタグが含まれている (3)
正規の URL が別のページを参照している (4)

これらすべての問題を同時に検証するには、Web サイト監査 → クロールされたページに移動し、適切な列を選択して、クロール可能性とインデックス可能性の問題を 1 つの画面で確認します。

URL 構造

再設計は必ずしもフロントエンドに関するものではありません。場合によっては、バックエンドやサーバーの構成にも影響を与えることがあります。別の CMS に移動するか、変更が URL 構造に影響を与える場合は、新しい URL が古い URL と同じであることを確認するか、それに応じてリダイレクトを構成する必要があります。これを行わないと、古い URL に 404 応答コードが含まれ、新しいページは新しいページとして扱われるため、古いページから信頼を継承しません。

また、ページパスに関係なく、いくつかの問題が発生する可能性があります。

最後にスラッシュ
「…/example-url」は「…/example-url/」と同じではありません。正規 URL の末尾にスラッシュがない場合、スラッシュで終わる URL にアクセスすると、404 応答コードが返され、SEO には適していません。すべての新しい URL が古い URL と同じように終わるようにするか、それに応じて canonical とリダイレクトを構成する必要があります。
HTTP(秒)
前の問題と同様に、SSL 接続の有効化/無効化も URL 構造に影響し、正しく構成されていないと重大な問題が発生する可能性があります。
www
「www.example.com」は「example.com」と等しくありません。この接頭辞は、Web リソースがパブリックにアクセスされることを意図していたことを示すために、World Wide Web の初期の時代に一般的に使用されていました。
技術的に言えば、「www.」はサブドメインであり、Google はサブドメインをフォルダではなく別のドメインとして扱います。適切に構成されていないドメインまたはサブドメインにアクセスしようとすると、エラーが発生し、ボットが検索されます。このような問題を回避するには、リダイレクトを設定するか、Web サイトの優先バージョンを指す rel=canonical タグを追加してください。

メタタグ

Web サイトの新しいバージョンを公開するときは、古いページのすべての最適化されたメタタグが配置されていることを確認する必要があります。そうしないと、タイトルや説明の欠落や誤りにより、ランキングやトラフィックが大幅に低下する可能性があります。 Web サイトの健全性を確認し、メタタグが欠落しているか間違っているページがないことを確認するには、Web サイト監査の問題レポートのタイトルと説明のセクションに進んでください。

メタタイトルと説明が再設計前と同じであることを確認するには、クロールされたページレポートを使用して、対応する列を有効にします。次に、それらを再設計前のものと比較します。

コンテンツ

複数のページに同じコンテンツが含まれている場合、Google は SERP でどのページを表示すべきかを判断するのが難しくなり、重複したすべてのページのランキングが低下します。

特に大きなウェブサイトの場合は、コンテンツを比較するのが難しい場合があります。良いニュースは、そのような問題を自動的に検出できることです。

複製ページ

重複ページとは、同じ内容のページです。 URL が異なる場合があるため、見つけにくい場合がありますが、識別に役立つパラメーターがあります。 [コンテンツハッシュ] 列を有効にすると、ページのコンテンツの一意のハッシュ (暗号化されたコンテンツの同等物) が表示されます。 2 つのページのハッシュが同じ場合、それらは 100% 同一であることを意味します。それらの出現を調べて、ページのコピーを 1 つだけ残します。

メタタグ

もう 1 つの重複シナリオは、同一のメタタグです。タイトルとメタディスクリプションは、検索エンジンがページの関連性を評価する際に大きな影響を与えます。 Google と同一のメタタグを持つページを混同しないでください。上位にランクされることはありません。

これらのページを見つけるには、Web サイト監査ツールのクロールされたページレポートで [重複するタイトル] 列と [重複する説明] 列を有効にするか、問題レポートの対応するセクションに移動します。

見出し H1

メタタグと同様に、検索エンジンがページの内容を判断する際に、ページの見出しが他の (サブ) ヘッダーよりも優先されます。どのページにも同一の H1 がないことを確認して、互いに盗用しないようにする必要があります。メタタグチェックと同様に、レポートの [H1 の重複] 列を有効にします。

コア Web バイタル

新しいデザインを実装する場合は、ユーザーエクスペリエンスが向上することを確認する必要があります。そうでなければ、それを行う意味がありません。幸いなことに、Google は Core Web Vitals を開発しました。これは、開発者が UX を評価するのに役立つ一連の指標です。

SE ランキングでは、ウェブサイト監査がすべてのページで必要なすべてのページエクスペリエンスメトリックをチェックするため、Web.dev または Chrome の Lighthouse の各ページをチェックする必要はありません。それらを見てみましょう。

最初に、Core Web Vitals (LCP、FID、および CLS) を確認します。これらは、Web サイトが UX に関してどれだけうまく機能しているかを反映する 3 つのパラメーターです。

Largest Contentful Paint は、ユーザーのブラウザーで最初のビューポートが印刷される速度を意味します。この指標は、ウェブサイトの読み込み速度と密接に関連しています。これについては、数秒で説明します.
First Input Delay は、ユーザーがページと対話する速度 (リンクやボタンのクリックなど) を測定します。このパラメーターは、サイトの速度にも関連しています。
Cumulative Layout Shift は、読み込み中のコンテンツの安定性を示します。ページの読み込み中にコンテンツ要素のサイズと位置が変わると、非常に厄介です。

この情報は、概要ダッシュボードまたは [問題レポート] -> [パフォーマンス] セクションで確認できます。素晴らしい点は、このレポートが実際のユーザーとラボ環境でのテストのデータに基づいていることです。これは、さらなる最適化の出発点です。

ウェブサイトの速度

Core Web Vitals の 3 つのうち 2 つが読み込み時間に関連しています。それだけでなく、統計によると、ユーザーの 3 分の 1 は、ページの読み込みに 3 秒以上待たされることはありません。したがって、ウェブサイトの速度は、ユーザーエクスペリエンスに関する重要なパラメータであると言っても過言ではありません。読み込み時間の問題を特定して解決するために、SE Ranking がどのように役立つかを見てみましょう。

HTML

すべての Web ページは HTML で記述されているため、再設計後に最初に検証する必要があるのは HTML です。問題はかなり基本的なものですが、さらに微調整するための基本的なものです。この点で、レンダリングが困難になり、全体的な読み込み時間に影響を与える可能性があるため、HTML サイズが大きすぎて大きな DOM サイズを除外できないようにする必要があります。また、ドキュメントのサイズとバックエンドの処理時間を最小限に抑えるために、HTML が圧縮されてキャッシュされていることを確認してください。

JS と CSS

最新の Web は JavaScript と CSS と絡み合っています。これらのテクノロジーは、機敏な機能を備えた美しい Web サイトの作成に役立ちます。ただし、これらの機能がサイトのパフォーマンスに悪影響を及ぼす場合があるため、新しいデザインを展開するときにリソースが最適化されているかどうかを確認することが重要です。

JS ファイルと CSS ファイルの最適化手法は似ています。

縮小化
すべてのコメント、改行、余分なスペースなどを除外します。重要な文字のみを残します。
組み合わせる
できるだけ少ないファイルを提供するようにしてください (理想的には、ページごとに 1 つの JS と 1 つの CSS)。各ファイル要求には、サーバーが応答し、ブラウザーがダウンロードするのに時間がかかります。単一のファイルの方がはるかに便利な方法です。
キャッシング
サーバー側のキャッシュを有効にすると、ユーザーがページをリクエストするたびにファイルが最初から生成されなくなります。代わりに、それらの保存されたコピーが提供されます。これにより、サーバーから多くの不要な負荷が取り除かれ、読み込み時間が改善されます。

一般的な推奨事項を次に示します。

フレームワークとテーマの使用を避ける
JS フレームワークと事前に作成された CSS を使用すると時間を節約できますが、速度の最適化を念頭に置いて作成されていないことがよくあります。必要のない多くの機能があり、それらの追加機能はすべてロードするには重すぎる場合があります。
JS ファイルのマージに注意してください
JS ファイルに 1 つのエラーがある場合、ファイル内の他の機能が動作しない可能性があります。したがって、単一の JS ファイルがある場合、すべての機能が動作しなくなる可能性があります。コア機能とフロントエンドの美しさのために別々のファイルを作成するのは賢い決断かもしれません。

画像

SEO に関しては、画像の最適化も不可欠です。

画像には代替テキストが必要です。これにより、検索エンジンやスクリーンリーダーを使用しているユーザーが画像の内容を理解できるようになります。再設計後、すべての画像に意味のある代替テキストが含まれていることを確認してください。
画像サイズ
ベストプラクティスは、親コンテナーと同じ解像度で画像を提供することです。ただし、コンテナーのサイズが変更される可能性があるレスポンシブデザインのため、考えられるすべてのコンテナーに適合するイメージコピーを作成することはほとんど不可能です。できることは、サイトのさまざまな場所で使用するために、いくつかの画像のバリエーション (つまり、元のサイズ、幅 300px、幅 100px) を作成することです。たとえば、記事のアイキャッチ画像は元のサイズである必要がありますが、アーカイブページのサムネイルには幅 300px 以下の小さい画像を使用することをお勧めします。
画像圧縮
画像の圧縮は、画像で使用される固有の色の数を減らすプロセスです。中程度の圧縮は人間の目にはほとんど見えませんが、最大 30% のファイルサイズを節約できます。特に、他のページリソースに比べて画像のファイルサイズが大きいことを考えると、これはかなりの量です。

レスポンシブデザイン

トラフィックの大部分はモバイルデバイスから来ており、Google はモバイルファーストインデックス作成に切り替えたため、モバイル最適化の問題を確認することが必須です。 SEランキングもこれをカバーしています。

問題レポートのモバイル最適化カテゴリに移動すると、Web サイトが基本的なレスポンシブデザインの原則に沿っていることを検証できます。

まとめ

再設計は複雑なプロセスです。特に、再設計されたサイトを SEO に最適化する必要があることを考えると. それを達成するための最善の方法は、to2e SEO とパフォーマンスの実践を念頭に置くことです。

変更を公開したら、すべてが正常かどうかを確認する必要があります。ここで、Web サイトのヘルスチェックツールが役立ちます。新しいサイトがより優れていること、または SEO およびパフォーマンスの面で何も問題がないことを確認するには、以前のバージョンと比較する必要があります。 SE Ranking は、Web サイトの監査データをクロール、チェック、および保存するため、結果を日付別に簡単に監視および比較できます。このような監査を使用すると、再設計後の Web サイトの状態を比較して改善することができます。