【KUSANAGI9 × PHP8】FacebookでOGPが更新されない? 原因はbcacheだった

WordPress

KUSANAGI9(CentOS Stream 9)でWordPressを運用していると、FacebookやX(旧Twitter)などのSNSに記事をシェアした際、OGPが最新のものに更新されないという現象に遭遇することがあります。

今回は、PHP8環境で実際に発生したこの問題を検証し、原因と再現性のある解決策をまとめました。

とにかくPHP8は記述が厳しくなっているので、そのぶん最初はエラーが多くなりやすくなっている印象ですね。

環境構成

KUSANAGI 9.6.x(CentOS Stream 9)
Nginx129 / PHP-FPM 8.1 / MariaDB 10.6
WordPressマルチサイト構成
プロファイル名:*****
キャッシュ設定
bcache:ON(データベースキャッシュ方式)
fcache:OFF(静的キャッシュ無効)
症状
Facebook DebuggerでURLを再取得しても、古いタイトル・サムネイルのまま。
og:title や og:image が最新記事に更新されない。

一見するとFacebook側のキャッシュのように見えますが、実際にKUSANAGI側のキャッシュ構成が関係していました。

原因の特定

KUSANAGIには「fcache」と「bcache」という2種類のキャッシュ機構が存在します。

参考 :
https://www.prime-strategy.co.jp/column/archives/column_7079

fcache

Nginxレイヤー 静的HTMLキャッシュ。PHPやDBを経由せず高速に配信。

bcache

WordPressレイヤー WP内部のデータベースキャッシュ。PHP実行後に保存。

このうち、bcacheがSNSクローラにも古いデータを返していたことが確認されました。

つまり「Facebookexternalhit」「Twitterbot」といったクローラが、既にキャッシュされた旧OGPを受け取っていたわけです。

検証方法

実際のFacebookクローラUAを指定してOGPメタを確認しました。

curl -sL -A 'facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)' \
'https://example.com/最新記事URL/' | grep -i 'og:'

bcache ON時:古い記事のOGPを返す
bcache OFF時:最新の記事OGPが即反映

この結果から、bcacheが原因で最新データをクローラが取得できていなかったことが明確になりました。

直接Facebookのシェアデバッガーを叩いて確認した方が直感的でわかりやすいかもしれません。

https://developers.facebook.com/tools/debug/

ページのURLを入れてデバッグして、もう一度スクレイピングボタンを押す。

解決手順

以下の手順で問題は解消されました。

# bcacheを停止

kusanagi bcache off

# fcacheを有効化(静的キャッシュを利用)

kusanagi fcache on

その後、検証コマンドで確認すると:

HTTP/2 200
x-b-cache: BYPASS
x-f-cache: HIT

Facebook・Twitter両方で最新のOGPを即時取得できるようになりました。
SNSシェア時のサムネイル更新遅延も解消しています。

もう一度、fcacheをoffにしたい場合は、次の手順で戻せます。

kusanagi fcache off
kusanagi nginx --reload

ちなみに、Kusanagi9のコマンド一覧ページは以下です。
https://kusanagi.tokyo/document/commands/

運用上のポイント

ここは人それぞれ環境によって違うと思いますが、自分の場合はbcacheとfcacheを同時にONにしないことでうまくいきました。

→ 二重キャッシュとなり、古い内容が残るリスクが高まった。
fcache単体運用でも、十分高速で安定。

→ 静的HTMLを直接返すため、PHPやDBへの負荷を大幅に減らせます。

まとめ

今回の検証では、PHP8環境下でのOGP更新遅延は bcacheによるデータキャッシュの残留 が原因でした。

bcache off / fcache on の構成にすることで、FacebookやXクローラが常に最新OGPを取得し、ページ更新後のシェアでも正しい情報が反映されるようになりました。

ただし、KUSANAGI環境やWebサーバー構成は多様です。

テーマ・プラグイン・権限設定によって挙動が異なる場合もあるため、同様の現象が出た場合は 一時的にbcacheをOFFにして挙動を切り分ける ことをおすすめします。

補足メモ(今回の安定構成)

KUSANAGI9 / CentOS Stream9
Nginx129 / PHP-FPM8.1 / MariaDB10.6
fcache: on
bcache: off
Facebook・Twitterクローラ共にHTTP200 + x-f-cache:HIT 確認済み

コメント

タイトルとURLをコピーしました