ウェブサイトは美しいデザインで、SEOプラグインの表示も緑色なのに、メインコンテンツが読み込まれる前に訪問者を失うことがあります。あるいは、Googleが想定とは異なるURLをインデックス登録することもあります。注文は正常に処理されても、計測では二重に送信されることもあります。
だから私は、1つのテストで100点を取ることから技術監査を始めません。まず、ビジネス、インデックス登録、ウェブサイトの利用を妨げるエラーを探します。細かな部分を整えるのは、その後です。
1。重要なURLが正しいステータスを返すことを確認する
主要なサービスページ、トラフィックを獲得している記事、問い合わせページ、コンバージョンまでの導線を確認します。重要なページは 200 を返す必要があります。恒久的に移転したコンテンツには、直接の 301 リダイレクトを1回だけ設定します。削除したページを、何気なくホームページへ誘導してはいけません。
HTTPとHTTPS、wwwありとwwwなし、末尾のスラッシュ、パラメータも確認します。結果は1つの正規URLになるべきです。Googleは、リダイレクトを強い正規化シグナルと説明し、一貫したcanonicalとサイトマップを組み合わせることを推奨しています。詳しくは正規URLに関するドキュメントをご覧ください。
2。実際のページの視点からインデックス登録を確認する
Robots.txt、meta robots、canonical、サイトマップは連携して機能する必要があります。よくある間違いは、検索に表示する必要のないページをインデックス登録しながら、重要なコンテンツをブロックしてしまうことです。Search ConsoleのURL検査を、代表的な複数のURLで使用してください。Googleがそのページについて把握している内容を確認でき、ライブ版のテストも行えます。
- canonical URLは、意図したものになっていますか？
- サインインやブロックなしでページを利用できますか？
- サイトマップには、インデックス登録可能な 200 件の URL だけが含まれていますか？
- 内部リンクはリダイレクトを避けていますか？
- 重要なページが孤立していませんか？
Googleは、これらの領域についてクロールとインデックス登録に関するドキュメントで概要をまとめています。
3。実際のユーザー環境で速度を測定する
PageSpeed InsightsとLighthouseは便利な診断ツールです。しかし、ラボテストは実際の訪問者の体験と同じではありません。現在のCore Web VitalsはLCP、INP、CLSです。フィールドデータは実際のデバイスと接続環境を使用します。Web Vitals公式ドキュメントでは、概要とフィールドデータとラボデータの違いを説明しています。
優先順位は次のように考えます。
- LCP：メインコンテンツが表示されるまでの時間。
- INP：操作に対してページが応答する速さ。
- CLS：読み込み中に要素が移動するかどうか。
- TTFBとネットワーク：そもそも何かがすぐに動き始めるかどうか。
Googleも、良いスコアが上位表示を保証するものではないと明確に述べています。1つの数字を追いかけるより、全体的な使いやすさが重要です。ページエクスペリエンスに関するドキュメントをご覧ください。
4。読み込みの本当の原因を見つける
ウォーターフォールとDevToolsで、長いサーバー処理時間、CSSやJavaScriptによるブロック、大きすぎる画像、フォント、重複リクエスト、サードパーティを探します。「すべてのファイルを結合する」という古いルールは、もはや常に正しいわけではありません。最新のプロトコルでは、未使用コードの量やメインスレッドのブロックのほうが重要になる場合があります。
- メイン画像を適切なサイズと最新の形式で読み込みます。
- コンテンツがずれないよう、画像の寸法を指定します。
- 最初のビューポートより下のコンテンツには、ネイティブの遅延読み込みを使用できます。
- 必要なフォントウェイトと文字セットだけを読み込みます。
- マーケティングスクリプトは非同期で、目的に必要な場所でのみ読み込みます。
- テキストリソースを圧縮し、バージョン管理されたファイルには長いキャッシュ期間を設定します。
サードパーティのコストは、ミリ秒単位の速度だけにとどまりません。すべてのピクセル、チャットウィジェット、ヒートマップが、運用とデータに関するさらなる責任を生みます。誰もレポートを使っていないなら、そのスクリプトを削除してください。
5。キーボードとスマートフォンを使い、顧客としてウェブサイトを確認する
モバイルで、ナビゲーション、フォーム、Cookieダイアログ、注文までを確認します。文字を拡大し、画像を無効にし、キーボードを使います。見出しは理解しやすい構造を作り、フォームにはラベルが必要です。エラーメッセージには、何を修正すべきかを記載します。
すべてのページには主要なタスクが必要です。何としてもボタンを1つ置くという意味ではなく、明確な階層を作るということです。実践的なさらなるポイントは、基本UXチェックリストで確認できます。
6。リソースとJavaScriptのエラーを修正する
画像、フォント、スクリプトの 404 は、見た目だけの問題ではありません。外観、計測、機能を壊す可能性があります。ブラウザーコンソールのエラー、失敗したネットワークリクエスト、サーバー上で繰り返される5xxレスポンスを確認します。デプロイのたびに重要な導線をテストしてください。
7。真実のコンテンツにのみ構造化データを使用する
Schemaは星評価を無理に表示させる手段ではありません。実際にページに掲載されている内容を、機械が読み取れる形で説明するものです。サポートされているタイプを使用し、リッチリザルトテストでテストしてください。Googleは、現在サポートされている形式とテストツールを構造化データに関するドキュメントで一覧にしています。
8。計測対象のウェブサイト自体を壊さない計測にする
GA4、広告プラットフォーム、その他のスクリプトは、ブロックしない方法で読み込みます。イベント名は、すべてのクリックではなく意思決定に基づけます。重複、同意、そして実際に誰かがデータを使っているかを確認します。実践的な基盤については、Google Tag ManagerとGoogle Analytics 4に関する記事をご覧ください。
9。修正の順序はお金とリスクで決める
- 壊れた注文、フォーム、サインイン。
- 利用できない、またはインデックス登録できない重要なページ。
- セキュリティ上の問題と、古いコンポーネント。
- モバイルの使いやすさとCore Web Vitalsに関する重大な問題。
- 誤った判断につながる計測エラー。
- 細かなスコアや見た目の問題は、その後です。
技術的なSEOはスタートラインです。それだけでレースに勝てるわけではありませんが、壊れたウェブサイトは号砲が鳴る前にレースを終えてしまう可能性があります。技術的な発見をビジネス上の優先事項に変えたい場合は、ウェブサイトと向き合っている意思決定について説明してください。