始まりはプライバシーポリシーの修正。プライバシーポリシーのページを整えたのをきっかけに、ついでに全ページをひと通り見直してみることにしました。そしたら、公開してからずっと気づかずに放置してたSEO周りの不具合が、ポロポロと4つも出てきました。今日はその棚卸しです。
トップページ、公開日からずっとnoindexだった
一番焦ったのがこれです。トップページのソースを何気なく見たら、robotsのメタタグにnoindexが入ったままになっていました。確認したら、公開作業の初期段階で一時的にオンにした「検索エンジンによるインデックスを許可しない」設定を、そのまま戻し忘れていたのが原因でした。
ヒヤリとした瞬間でした。正直、しばらく検索経由のアクセスが少ないのを「まあ新しいサイトだしこんなものか」くらいにしか思っていなかったので、そもそも検索結果に出るはずがなかったという事実に気づいたときは、ちょっと血の気が引きました。設定をオンに戻して事なきを得ましたが、こういう「公開前だけのつもりで触った設定を戻し忘れる」やつ、他にも潜んでいそうで怖いです。
著者アーカイブが、人アイコン+NOT FOUNDになっていた
これは自分では気づかず、記事を読んでもらったときに「著者アーカイブのページ、なんか変じゃない?」と指摘してもらって発覚しました。見に行ってみると、プロフィール写真の代わりに人型のシルエットアイコンが出て、その下に記事が1件も表示されず「見つかりませんでした」的な表示になっていました。
原因は投稿者ID。調べてみたら、全記事の投稿者IDが0のまま保存されていました。記事の投稿をClaude Codeにwp eval-file経由のスクリプトでまとめて作ってもらっていたんですが、これはWordPressの管理画面にログインした状態ではなく、ユーザーの文脈を持たないままwp_insert_post()を呼んでいたので、投稿者が指定されずに0のまま保存されていたんです。既存の記事は一旦手動でIDを振り直して直しましたが、これだけだと同じ方法で記事を作るたびにまた0に戻ってしまいます。実際、今回この記事を書くために新しく投稿を作った直後にもう一度同じ状態になっているのを見つけて、「あ、また出た」となりました。さすがに毎回手で直すのは非効率なので、保存時に投稿者が0だったら自動的に管理ユーザーを補うようにする処理を足して、根っこから止めることにしました。
meta descriptionが、三重にエスケープされていた
今度は表示崩れでした。記事の抜粋文をSNSでシェアしてみたとき、descriptionの表示がCat's Handのように、HTMLの特殊文字がそのまま文字として出てしまっていることに気づきました。
犯人は多重エスケープでした。原因を追うのに、使っているテーマ(Cocoon)本体のソースを直接読みに行きました。すると、meta descriptionを組み立てる関数の中でhtmlspecialchars()が2箇所で呼ばれていて、さらに出力する側でもう一度esc_attr()がかかる、という3段階のエスケープが重なっていることが分かりました。アポストロフィのような記号が入っていると、1段階目でエスケープされた結果がさらにもう1段階エスケープされて、最終的に元の記号まで戻らなくなる、という仕組みでした。
直し方は、エスケープが解けなくなるまでデコードを繰り返してから、最後の出力側のesc_attr()だけに任せる、という力技です。テーマ本体を直接書き換えるのは今後のアップデートで消えてしまうので避けて、子テーマ側のフィルターで挟む形にしました。
JSON-LDの中まで、律儀にHTMLエスケープされていた
まだありました。似たような話がもう一つありました。ページのソースに埋め込まれる構造化データ(JSON-LD)を見てみたら、サイト名がCat's Handのまま出力されていました。JSONの中身なのでHTMLエスケープはそもそも不要なはずなのに、テーマ側が著者名やタイトルをesc_attr()(HTML属性用のエスケープ関数)に通してしまっていたのが原因でした。JSONパーサーからすると、これは単なる文字列としてそのまま読み込まれるので、Cat's HandがCat's Handに戻ることは一生ありません。
対応はピンポイントでした。ここも同じ理由でテーマ本体は直接触らず、<script type="application/ld+json">のブロックだけを狙って、出力された後にHTMLエンティティをデコードし直す、という形で対応しました。地味ですが、ピンポイントで直せて気持ちよかったです。
Cocoonのソースを直接読みに行くことについて
食わず嫌いは損でした。今回の4つのうち後半2つは、症状を見ただけでは原因が分からず、結局テーマ本体のPHPファイルを直接開いて読みに行きました。最初は「人のテーマのコードを読むの、ちょっと気が引けるな」と思っていたんですが、実際に読んでみると、想像していたよりずっと素直に書かれていて、原因まで辿り着くのにそんなに時間はかかりませんでした。不具合の原因が分からないときは、外側からあれこれ推測するより、実際のコードを読みに行った方が結局早い、というのを改めて実感しました。
まとめ
教訓は定期的な見直しでした。4つとも、見た目には何も崩れていないタイプの不具合だったので、自分で気づけたのは1つだけで、残りは指摘やたまたまの気づきがきっかけでした。公開して終わりじゃなく、ある程度動き出したタイミングで一度ちゃんと全ページを見直す、というのは今後も定期的にやった方がよさそうです。地味な作業ですが、放置してるとじわじわ効いてくるやつだなと思いました。
