Laravel SEOチェッカー：URLとメタデータを診断

LaravelのSEOチェックでは、実際のコンテンツページ、存在しないルート、認証が必要なアカウントページの3つにリクエストします。そのレスポンスから、アプリケーションが公開コンテンツ、存在しないリソース、非公開の機能を区別できているのか、それともすべてに同じ枠組みを返しているのかが分かります。

クライアントのスクリプトが動く前のレスポンスを調べる

公開URLにリクエストし、タイトル、canonicalの宣言、意味のある本文コンテンツを探します。ルート要素が空の場合は、クライアント側のメタデータ用スクリプトをさらに追加する前に、レンダリングのアーキテクチャを見直す必要があります。HTMLのみのクロールは、Googleのレンダリング処理を完全に再現するものではありません。検索エンジンがそのページをどう扱ったかの根拠が必要な場合は、URL検査を使ってください。

ホスト、プロトコル、ステータスの扱いをテストする

HTTPSページのcanonicalを、CDNを経由した後の本番アドレスと比較します。遷移先がステージング環境やlocalhostになっている場合は、URL生成またはプロキシの設定に問題があります。データベースにないスラッグにリクエストしてください。not foundのメッセージを含む200のレスポンスが返る場合は、コントローラーの修正が必要です。クローラーを成功させるためだけにアクセスを開放するのではなく、アカウント用のルートが引き続き認証を必要とすることを確認します。

サイトマップの項目を公開レコードと一致させる

最近公開した記事と、下書きに戻した記事を1件ずつ選びます。前者はインデックス可能であれば検出用フィードに含まれるべきで、後者はもう通知されてはいけません。実際の状態が異なる場合は、リポジトリのフィルタとキャッシュを調べてください。コードを変更した後は、元のリクエスト一式を繰り返し、ステータス、canonicalの遷移先、デプロイ時刻を記録します。これにより、古いキャッシュのレスポンスと、未解決のアプリケーションのバグを具体的に区別できます。

公開シナリオの実例

例として、記事はHTTPSで読み込まれるのに、そのcanonicalがHTTPになっているとします。テンプレートを1つずつ、HTTPSの文字列を直接書き込んで修正するのではなく、信頼するプロキシの扱いとアプリケーションのURL生成の方針を比較してください。修正後は、記事、リダイレクトされる旧URL、別の公開ルートにリクエストし、それぞれの最終的なホストとスキームを記録します。これにより、ログイン済みのブラウザーで1つの記事が正しく見えるようになっただけでなく、共通のルーティング層に修正が反映されているかどうかを確かめられます。

チェックを実行して根拠を読み解く

下の無料SEOチェッカーに、代表的な公開URLを1つ入力します。ステータス、タイトル、ディスクリプション、canonicalを、チェックしたアドレスと時刻とあわせて記録してください。繰り返し現れる問題は、原因となるテンプレートや設定ごとにまとめると、的を絞った1回の修正を複数のページで再テストできます。項目が欠けている場合と、意図的に除外している場合とでは、必要な判断が異なります。

HTTP/HTMLの監査が観測するのは、公開されたレスポンスです。プラットフォームにサインインして管理画面の設定をすべて調べたり、クライアント側のレンダリングの挙動をすべて再現したり、Googleがページをインデックスしたことを証明したりするものではありません。検索エンジン側の根拠としては、Search ConsoleのURL検査とその後のクロールデータを比較してください。スコアが変わったことだけで根本の問題が解決した証拠とみなさず、公開とキャッシュ更新の後に、元のURLをもう一度確認しましょう。

ツールと関連ガイド

• Laravelの設定ガイドを読む
• 公開URLをチェックする
• リダイレクトチェーンを調べる

公式リファレンス

• Laravel：HTTPレスポンス
• Laravel：URLの生成