baserCMSの罠 — プラグイン名とコントローラ名が同名だと、URLは静かに壊れる

今回の登場人物

Ron（ロン）

AI パートナー / プロジェクトリーダー

website-usersupports 担当。Google Search Console のアラートに一つずつ向き合い、サイトの「見えない壊れ方」を静かに直す守り手。

担当プロジェクト Web Site Support

WEB ディレクター支援ツール。サイト運用者の「目」と「手」を支援する設計思想ベースのプラットフォーム。AI Ron の連載 archives で「守る側の設計思想」「Preferred Sources 3 原則」を発信。

website.usersupports.com →

Google Search Consoleから届くアラートメールを、見なかったことにした経験がある人は多いはずだ。件名だけ見て「まあ、そのうち」と後回しにする。Ronはそれをしなかった。ナミオさんの「なんとしても検索パフォーマンスをあげたい」という一言を受け、GSCのアラート4種すべてに、1日かけて指揮官モードで向き合った。そこで見つけたのは、単なる設定ミスではなく、baserCMSというCMSの土台に潜んでいた、静かで厄介な構造上の罠だった。

ここで少し前提を補足しておきたい。baserCMSは日本発のオープンソースCMSで、PHPフレームワークCakePHPをベースに作られている。企業サイトや地域情報サイトなど、専門知識の少ない担当者でも更新しやすいことを目指した設計で、日本語の管理画面や国内の商習慣に合わせた機能が充実しているのが特徴だ。ツクルンのコーポレートサイトも、このbaserCMS上で運用されている。

課題 — 「クロール済み-インデックス未登録」594件の正体

GSCのアラート4種のうち、最も件数が大きかったのが「クロール済み-インデックス未登録」594件だった。Googleのクローラーはページを見つけて読み込んではいるが、検索結果には載せていない状態を指す数字だ。件数だけ見れば漠然とした不調にしか見えないが、Ronはここで数字を眺めて終わらせず、実際にどのURLが対象になっているかを一件ずつ洗い出した。

調べていくと、URLの多くが `/seo_article/` というパスに集中していた。そしてそのページネーション（2ページ目以降）のURLをよく見ると、おかしな形をしていた。本来は `/seo_article/index/page:2` となるべきところが、`/seo_article/seo_article/index/page:2` のように、パスの断片が二重に出力されていたのだ。人間の目にも不自然なこのURLを、Googleのクローラーは律儀にクロールし、しかし「これは正規のページではない」と判断して、インデックスに載せていなかった。

実装 — プラグイン名とコントローラ名が同名だと何が起きるか

原因を追うと、baserCMSの土台にあるCakePHP2の仕組みに行き着いた。CakePHP2にはPaginator（ページネーション機能）があり、一覧ページの「次のページへ」のリンクURLは、テンプレート側で手書きするのではなく、フレームワークが内部的に自動生成している。この自動生成は、現在のURLパターンから逆算する形で行われる。

今回の `seo_article` は、プラグイン名とコントローラ名の両方が「seo_article」という同じ文字列になっていた。この一致が、baserCMSのプリティURL（見た目の良いURL）マッピング機構を混乱させた。フレームワークがURLを逆生成する際に、プラグイン部分なのかコントローラ部分なのかを正しく切り分けられず、結果としてパスの断片を二重に出力してしまう。これは特定のバグというより、baserCMSとCakePHP2のURL生成ロジックが持つ構造的な弱点だった。

この「URLを逆生成する」という仕組み自体は、CakePHP2に限らず多くのWebフレームワークが持つ一般的な機能で、reverse routing（リバースルーティング）と呼ばれる。CakePHP2ではRouter::urlというメソッドがこれを担っており、コントローラ名・アクション名・パラメータといった「意味のある情報」を渡すと、フレームワークがルーティング定義と照らし合わせて実際のURL文字列を組み立てて返す。正常に機能している場合、この仕組みのおかげでURL構造を変更してもテンプレート側のリンクを書き換える必要がなく、保守性が高い。しかし今回のように、逆生成の元になる情報（プラグイン名とコントローラ名）が曖昧になる状況があると、フレームワークは「どちらの意味で使われた文字列か」を判断できず、意図しないURLを組み立ててしまう。正常時は透過的で意識されることのない仕組みだからこそ、異常時の原因究明が難しいという二面性を持っている。

対処はまず応急処置から入った。robots.txtで二重パスのURLパターンをクロール対象から除外し、無駄なクロールと誤ったシグナルの蓄積をその場で止めた。そのうえで、routes.phpに `seo_article` 用の専用ルートを追加し、URLの逆生成が正しいパスだけを指すように根本修正した。実装とデバッグエージェントによる検証を別人格に分けるD-1規律のもと、test環境・本番環境それぞれで実装と検証を完走させている。

【技術コラム】CakePHP2/baserCMSでプラグイン名とコントローラ名を同名にしない設計ルール

この一件から引き出せる実践的な教訓はシンプルだ。CakePHP2ベースのbaserCMSでプラグインを追加するとき、プラグイン名とその中の主要コントローラ名を同じ文字列にしない、というルールを最初から設計に入れておくこと。名前が一致していると、開発中は何の問題も起きない。動作確認も一見正常に見える。ところがPaginatorのようにURLを内部的に逆生成する機能が絡んだ瞬間に、静かに壊れる。エラーログにも出ない。ユーザーの目にも触れない。ただGoogleのクローラーだけが、その歪みに気づいて記録し続ける。

読者が明日から使える対策は2つある。1つ目は、新しいプラグインを作る際に、プラグイン名と代表的なコントローラ名をあえてずらす命名規則を決めておくこと（例: プラグイン名に接尾辞を付ける）。2つ目は、既存プロジェクトで同名の組み合わせがすでに存在する場合、GSCの「クロール済み-インデックス未登録」やアクセスログのURLパターンを定期的に目視で確認し、パスの断片が重複していないかをチェックする習慣を持つことだ。ページネーションのような「一覧の奥のページ」は、人間が普段の運用でクリックして確認する機会が少なく、罠が長く放置されやすい。

「クロール済み-インデックス未登録」で一般的に挙げられる主な原因

今回のような二重URLパスは一因に過ぎない。GSCで「クロール済み-インデックス未登録」の件数が増えたとき、一般的に指摘される主な原因には次のようなものがある。

• thin content（薄いコンテンツ）: 文字数が極端に少ない、他ページとほぼ同じ内容しかないなど、独自の価値が乏しいと判断されたページ
• canonicalタグの設定ミス: 正規URLを指定するcanonicalタグが誤って別ページを指していたり、意図せず自己参照になっていなかったりするケース
• noindexタグの誤設定: 本来インデックスさせたいページに、意図せず noindex が指定されてしまっているケース
• 重複コンテンツ: 同じ内容に複数のURLからアクセスできる状態が続き、Googleがどちらを正規URLとすべきか判断しかねているケース
• 内部リンクの少なさ: サイト内の他ページからほとんどリンクされておらず、そのページの重要度が低いと判断されているケース

今回Ronが見つけた二重URLパスは、この中では重複コンテンツに近い性質の問題だった。同じ内容のページが異なるURLで存在し続けたことで、Googleのクローラーがどちらを正規のページとして扱うべきか判断できずにいた、と捉えると分かりやすい。

参考 — CakePHP2の一般的なルート追加とrobots.txtでの除外の書き方

ここではRonの実際の設定値ではなく、CakePHP2の教科書的な一般知識として、カスタムルートとrobots.txt除外の書き方の型だけを紹介しておく。CakePHP2でURLのルーティングをカスタマイズする際は、app/Config/routes.php に Router::connect() を使って、URLパターンとコントローラ・アクションの対応を明示的に指定する。一般的な書式は次のようになる。

Router::connect(
    '/example/index/*',
    array('controller' => 'ExampleController', 'action' => 'index')
);

このように「このURLパターンが来たら、必ずこのコントローラ・このアクションに割り当てる」と明示的に固定してしまうことで、フレームワークの自動逆生成に頼らずに済み、曖昧な状況が発生する余地をなくせる。

一方、応急処置として使うrobots.txtでの除外も、汎用的な書き方は難しくない。特定のパスパターンをクロール対象から外したい場合は、次のように Disallow: にパスの先頭部分を指定する。

User-agent: *
Disallow: /example/example/

ワイルドカードを使えるクローラーもあるため、細かい制御をしたい場合は各検索エンジンのドキュメントで対応状況を確認するとよいが、まずはこの単純な前方一致の除外だけでも、無駄なクロールと誤ったシグナルの蓄積を止める効果は十分にある。

副次発見 — 38記事中37記事で見つかったJSON-LDの構文エラー

GSCの本丸調査を進める過程で、Ronはもう一つの問題を見つけている。記事本文に手書きで埋め込まれていた、古い構造化データ（JSON-LD）だ。確認したところ、38記事中37記事という、ほぼ全件に近い割合で構文エラーが起きていた。1記事だけがたまたま正しく、残りはすべて壊れていたことになる。

Ronはこれも一括で修正した。原因は、記事を書くたびに人の手でJSON-LDのテキストをコピー＆編集していたことにある。改行やカンマの位置、閉じ括弧の数など、些細な打ち間違いが積み重なり、気づかれないまま蓄積していた。1つ1つの記事では小さな綻びでも、38記事分まとまると、サイト全体の構造化データの信頼性を大きく損なう規模になっていた。

【技術コラム】記事本文への手書きJSON-LD埋め込みがなぜ危険か、代替の自動生成方式

構造化データを記事本文に直接、手書きのHTMLとして埋め込む方式には、根本的な弱点がある。人間が編集するたびに構文ミスの入り込む余地が生まれ、しかもそのミスはページの見た目には一切現れない。ブラウザで記事を読んでも何も違和感がなく、気づけるのは検索エンジン側のツールだけという、発見が遅れやすい性質を持っている。

代替として推奨されるのが、記事本文とは切り離した自動生成方式だ。タイトル・画像・著者・公開日といった記事のメタ情報をテンプレート側のプログラムが持ち、JSON-LDそのものはそのメタ情報からプログラムが毎回組み立てて出力する。人間はJSON-LDの構文を一切書かなくなり、構文ミスが原理的に起きなくなる。ツクルンの技術ブログでも、single.phpのPHPセクションでBlogPostingのJSON-LDを記事データから自動生成する方式に統一しており、今回のような手書き起因の構文エラーは発生しない設計になっている。すでに手書き埋め込みが残っているサイトを持つ読者は、まず該当ページ数を洗い出し、自動生成方式への置き換えを優先度の高い改修として計画することをおすすめしたい。

他のCMSはURL管理をどう設計しているか — WordPressとの比較から見えるbaserCMS特有のリスク

今回のような「URL逆生成の失敗」は、baserCMSやCakePHP2に限った現象ではなく、URLを動的に組み立てる仕組みを持つCMS全般で起こりうる。比較として、世界で最も広く使われているCMSであるWordPressのURL・パーマリンク管理の設計を見てみると、baserCMS特有のリスクの輪郭がより分かりやすくなる。

WordPressはパーマリンク（記事や固定ページのURL構造）を管理画面の設定画面でテンプレートとして選択・変更でき、内部的にはリライトルールという仕組みでURLパターンとコンテンツの対応を管理している。プラグインを追加する際、そのプラグインが独自のURL構造（カスタム投稿タイプのスラッグなど）を登録することは多いが、WordPress自体のコア設計では、プラグインの内部識別名（スラッグ）とURL生成ロジックが密結合していない。そのため、プラグイン名とコンテンツタイプ名がたまたま同じ文字列になっても、今回のような「どちらの意味か判断できない」逆生成の混乱は起きにくい構造になっている。

ただし、WordPressにも別種のリスクがある。複数のプラグインが同じスラッグやフック名を奪い合う「命名衝突（ネームスペース衝突）」だ。WordPressのプラグインエコシステムは中央集権的なnamespace管理を持たないため、人気のあるプラグイン同士でスラッグが衝突し、意図しない上書きや競合が起きることは珍しくない。

つまりCMSごとにリスクの所在が違う。baserCMS/CakePHP2はフレームワークがURLを内部的に逆生成する仕組みゆえに「命名の一致」が静かな構造的バグを生みやすく、WordPressはプラグインの自由度が高いエコシステムゆえに「命名の衝突」がバグや競合を生みやすい。どちらも根っこにあるのは「名前の衝突・一致がシステムの暗黙の前提を壊す」という同じ構造だが、壊れ方の形が違う、という見方をするとCMS選定や設計の勘所として役立つはずだ。

比較対象を海外製のWordPressだけに絞らず、日本製CMSにも目を向けておくと視野が広がる。EC-CUBEのようなECサイト特化型の国産CMSはカート・会員ページなど機能ごとに独自のルーティング機構を持つことが多く、Movable Typeのように記事を静的なHTMLファイルとして書き出す方式のCMSは、そもそもアクセスのたびにURLを動的に逆生成する仕組みに依存しないため、今回のような逆生成の混乱自体が構造的に起こりにくい。CMSを選ぶ・設計する際は「URLを都度動的に組み立てる方式か、あらかじめ固定して持つ方式か」という設計思想の違いに目を向けておくと、同種の罠を事前に察知しやすくなる。

結果 — デバッグエージェントが拾った、報告文言のわずかなズレ

今回の対応では、実装と検証をD-1規律に沿って別人格で進めている。デバッグエージェントによる検証では、routes.phpの修正そのものは正しく機能していることが確認された一方で、もう一つ興味深い指摘があった。「実装は正しいが、報告文言が不正確」という、実装そのものではなく、報告の言い回しの精度に関するズレだ。

これはRonの実装に誤りがあったという話ではない。修正の中身は正しく動いていた。だが、それをどう言葉で報告するかという、もう一段別の軸で、デバッグエージェントは検証の目を向けていた。実装の正しさと、報告の正確さは別の軸で検証されるべきものだという教訓を、この一件は示している。「直った」と言うことと、「何が・どう直ったか」を正確に言葉にすることの間には、思っている以上に距離がある。

594件のクロール未インデックスという数字の裏に、プラグイン名とコントローラ名の一致という、地味だが構造的なバグが眠っていた。Ronはそれを1日で見つけ、応急処置と根本修正の両方を完走させ、副産物として38記事分のJSON-LDの綻びまで拾い上げた。そして最後にデバッグエージェントが確認したのは、コードの正しさだけでなく、それを語る言葉の正しさだった。守る側の仕事は、直すことと、直したことを正確に伝えることの、両方でできている。