【ITニュース解説】if (!$meta_tags) was never true — and Google noticed before we did
2026年09月09日に「Dev.to」が公開したITニュース「if (!$meta_tags) was never true — and Google noticed before we did」について初心者にもわかりやすく解説しています。
ITニュース概要
ウェブサイトで削除・非表示にしたページが200 OKで表示され、タイトルなどのメタ情報が欠落していた。これによりGoogle検索はそれらを重複コンテンツと誤解し、インデックスしなかった。原因は、メタデータがない場合にリダイレクトする条件が正しく機能しなかったため。必要なメタデータの有無を直接チェックするよう修正し解決した。
ITニュース解説
あるウェブサイトのリリース後、Google Search Consoleというツールで複数の異常な警告が報告され始めた。具体的には「ユーザーが選択した正規URLなしの重複」「クロール済み – 現在インデックス未登録」「検出 – 未インデックス」といったメッセージが大量に表示されたのだ。これは、Googleがウェブサイトの特定のページについて、その内容を正しく理解できていない、あるいは不適切だと判断していることを示していた。
不思議なことに、この間もウェブサイト自体は正常に動作しており、ログにもエラーの記録はなかった。しかし、Googleは本来インデックスすべきではないURLを大量にクロールし続けており、その数は週ごとに増えていった。通常のウェブサイト監視レポートではこの異常は発見できず、Google Search Consoleのカバレッジレポートでのみ、この問題の広がりが確認された。
問題のURLを詳しく調べてみると、それらはすべてデータベースから削除された、または非アクティブに設定された過去のデータ（例えば、公開停止になったポートフォリオ項目など）を指していることがわかった。本来であれば、このようなURLにアクセスがあった場合、ウェブサイトは「302リダイレクト」という仕組みを使って、ユーザーを関連する一覧ページへ自動的に転送するべきだった。これは一時的なページの移動を示すHTTPステータスコードである。
しかし、実際にこれらの問題のURLにアクセスすると、「200 OK」というステータスコードが返ってきた。これは「ページが正常に表示されました」という意味で、リダイレクトが機能していないことを示していた。さらに、表示されたページはナビゲーションやフッターなど通常のウェブサイト要素をすべて含んでおり、見た目上は有効なコンテンツのように見えた。だが、そのページのHTMLコードの<head>（ヘッド）部分には、タイトルやメタディスクリプション、そして検索エンジンにそのページの正規のURLを伝えるための<link rel="canonical">タグが全く含まれていなかったのだ。
この<head>が空っぽであることが、Google Search Consoleで大量の警告が発生した根本原因だった。Googleはコンテンツがあるように見えるページをクロールしたが、それが何のページなのか、どのURLが本当の所有者（正規URL）なのかを知る手掛かりがなかったため、内容が重複しているとみなしたり、インデックス登録の対象外と判断したりしたのである。
この問題の原因はウェブサイトのプログラムコードの中にあった。ウェブサイトでは、各ページのメタデータをデータベースから取得した情報に基づいて生成する仕組みになっていた。レコードが存在しないか非アクティブの場合、メタデータ生成関数は「空の配列」を返すように設計されていた。
問題は、この空の配列が、ページのメタデータをまとめる処理で誤作動を起こしたことだ。具体的なコードの一部は次のようになっていた。
$meta_tags = array_merge($data_page, get_meta_data($data_page));
if (!$meta_tags) { // ここがリダイレクトの判定部分
redirect_to_listing(); // リストページへ転送する処理
}
get_meta_data()関数は、削除されたレコードの場合に空の配列[]を返していた。しかし、array_merge($data_page, [])という処理が原因だった。$data_pageは常にpost_idやsectionなどの情報を含む「空ではない配列」だったため、これに空の配列を結合しても、結果の$meta_tagsは「空ではない配列」のままになった。
PHPというプログラミング言語では、空ではない配列は「真（true）」と評価される。したがって、リダイレクトの条件文if (!$meta_tags)の!$meta_tagsの部分は、「$meta_tagsが真ではない」という意味になるが、実際には$meta_tagsが真と評価されてしまうため、この条件文は常に「偽（false）」となり、リダイレクト処理が実行されなかったのである。
さらに、この$meta_tagsにはタイトルなどのキーが存在しないにもかかわらず、ページの<head>タグを生成する別の関数に渡されていた。この関数には、タイトルなどの情報が揃っている場合にのみHTMLタグを出力する条件文があったが、渡された$meta_tagsには'title'というキー自体が存在しないため、この条件文も偽と評価され、<head>タグの中身が何も出力されないままページが完成し、「200 OK」で応答されていた。
この一連の処理では、プログラムの実行中に何のエラーも警告もログにも記録されなかった。問題が発生していることに開発者は全く気づかず、唯一この異常を検知できたのはGoogle Search Consoleであり、それもGoogleが独自にウェブサイトをクロールする数週間後にようやく確認できたのだった。
この問題を解決するため、リダイレクトの条件文をif (!$meta_tags)からif (empty($meta_tags['title']))へと変更した。empty()関数は、変数が空であるかどうかを厳密にチェックするため、新しい条件文は「もし$meta_tags配列の中に'title'というキーが存在しない、またはその値が空であるならば、リダイレクトを実行する」という意味になる。これにより、削除されたり非アクティブになったりしたレコードに対応するページでは、'title'キーが存在しないため、正しくリダイレクト処理が実行されるようになった。
この修正は、共通のヘルパー関数ではなく、ページの表示を制御する7つの特定の「コンテンツコントローラ」に個別に適用された。これは、ヘルパー関数には、メタデータが不要な場合など、他の正当な理由でリダイレクトを必要としない呼び出し元が存在するため、不必要な変更を避けるための判断だった。
修正がデプロイされた後、検証を行った結果、非アクティブなアイテムへのアクセスは、以前は200 OKを返していたのが、正しく302リダイレクトで一覧ページへ転送されるようになったことを確認した。Google Search Consoleのカバレッジレポートの数値が改善されるまでには、Googleのクロールサイクル（およそ2〜4週間）があるため、しばらく時間がかかる見込みだ。
この経験から得られた教訓は非常に重要である。一つは、プログラムで条件チェックを行う際、「値が存在するかどうか」だけでなく、「必要な値が、期待する形で存在するかどうか」を厳密に確認するべきだということだ。array_mergeで空の配列が結合されるような特殊な状況では、技術的には「空ではない」が、肝心な中身が欠けている配列が生成されることがあるため、注意が必要となる。
二つ目の教訓は、SEOに関連するバグは、サーバーエラーやログへの記録がないことが多く、通常の監視システムでは検知できない場合が多いことだ。このようなバグを唯一発見できるのはGoogle Search Consoleのカバレッジレポートであり、しかもGoogleのクロールスケジュールに依存するため、問題発覚までに数週間かかることがある。
そして三つ目は、Google Search Consoleのカバレッジレポートは、あくまで「症状」の一覧であり、問題の「根本原因」を直接示しているわけではないことだ。複数の異なる警告が同時に発生していても、その裏にはたった一つのプログラミング上のミスが隠されている場合があるため、レポートのメッセージだけにとらわれず、深く原因を探ることが重要となる。