ご報告ありがとうございます。詳しい情報のおかげである程度切り分けができたかもしれません。

先に結論として、今回はテーマの不具合ではなく、wp_cocoon_accesses テーブルのデータ不整合が原因の可能性が高いと考えています。

■ 前提の補足（2点）

• 集計用のCronは元々ありません。 Cocoonの記事一覧PVは、表示のたびに wp_cocoon_accesses を直接合計する「ライブ集計」です。Amazon/Rakutenイベントだけが見えているのは正常です。
• wp_cocoon_item_rankings は無関係です。 これは手動で作る「商品ランキング」用のテーブルで、PVとは関係ありません。0件のままで正常です。

■ 推測される原因

「全期間」のPVまで0という点が手がかりです。全期間は日付条件なしで合計するため、ここが全記事0ということは、accessesのレコードの post_id / post_type が現在の記事と一致していない状態を示します。

ご経緯（Search Regexで一括置換 → UpdraftPlusで復元）の過程で、post_id または post_type が wp_posts 側とズレてしまった可能性が高いです。

■ ご確認いただきたいSQL

phpMyAdmin等で実行してみてください（読み取りのみで安全です）。

-- (1) post_typeの分布（'post'があるか）
SELECT post_type, COUNT(*) AS rows, SUM(count) AS pv
FROM wp_cocoon_accesses GROUP BY post_type;

-- (2) 実在の投稿と結合できない孤立行の数
SELECT COUNT(*) AS orphan_rows
FROM wp_cocoon_accesses a
LEFT JOIN wp_posts p ON p.ID = a.post_id
WHERE p.ID IS NULL;

• (1)で post 行が無い／PVが別タイプに偏る → post_typeの不一致
• (2)の orphan_rows が多い → post_idの不整合

■ 対処

必ず事前にDBバックアップを取得のうえ、

• post_typeのズレなら UPDATE wp_cocoon_accesses SET post_type='post' WHERE post_type='（誤った値）'; で復旧します。
• post_idのズレの場合は過去分の完全復旧は難しいですが、新規アクセスは正常に記録されているとのことなので、今後は再び正しく蓄積されていきます。

まず(1)(2)の結果を教えていただけますと、原因をかなり絞れるかと思います。よろしくお願いいたします。

@yhira 

ご返信ありがとうございます。

ご案内いただいたSQLを実行しました。

① post_type の分布

page  row_count:63    total_pv:181
post  row_count:11546 total_pv:39366

② orphan_rows

80

post_type は post が正常に記録されており、アクセスも約11,500件保存されていました。

orphan_rows は80件ありましたが、全体件数からすると一部のみのようです。

そのため、wp_cocoon_accesses のデータ自体は概ね正常に見えますが、記事一覧の「日・週・月・全期間」のPVはすべて0のままです。

この場合、他に確認すべき箇所はありますでしょうか。

件数がグレーアウトされてますので、勝手ながら、貼ってみます。

① post_type の分布

page row_count:63 total_pv:181
post row_count:11546 total_pv:39366

② orphan_rows

80

上手くいったみたいですね。

出先で、スマホからなもので、調べたりはあまりできないため、もし誤りがあればご指摘ください。

どんなサイトなのかによって、数値の評価は変わると思いますけれど。

私は、この数値（以下）は異常ではないかと思います。

投稿者:: @hiro089853

↑

投稿数：7165

固定ページ数：18

投稿者:: @mk2_mk2

↑

① post_type の分布

page row_count:63 total_pv:181
post row_count:11546 total_pv:39366

② orphan_rows

80

wp_cocoon_accessesは、以下の単位でレコードが作成されると思います。

• post_id
• date

つまり、同一post_idに対して、アクセスのあった日付別に、レコードを作成します。
（post_id別・日付別に、レコード作成し、アクセス数を格納する）

例えば、私のテスト環境だと、以下のような感じです。

• id: 3 2019-07-27
• id: 8 2019-07-28
• id: 9 2019-07-29
• id:12 2019-08-01

• 1つの投稿に対して、1～2日しかアクセスがない？
• もしくは、アクセスのある投稿が、とても偏っていて、全くアクセスのない投稿がある？ 

@mk2_mk2 

失礼しました。大事な情報が抜けておりました。Cocoonへテーマを変更したのは約1週間前です。

そのため、wp_cocoon_accesses のレコード数が投稿数（7,165件）に対して少ないのは、Cocoonでアクセス集計を開始してから日が浅いことが理由だと思われます。

Cocoon導入後は wp_cocoon_accesses のレコードは現在も増え続けており、アクセスの記録自体は正常に行われています。

ただ、記事一覧のPV表示（日・週・月・全期間）はすべて0のまま更新されない状況です。

hiro089853さん

投稿者:: @hiro089853

↑

Cocoonへテーマを変更したのは約1週間前です。

上記なら、十分有り得ると思います。

その場合、今度は以下が気になりますが。

投稿者:: @mk2_mk2

↑

② orphan_rows

80

公開済みだった投稿を、削除等なさいましたか？

約1週間で「80」なら複数投稿消えていることになりそうな・・・。

投稿者:: @hiro089853

↑

記事一覧のPV表示（日・週・月・全期間）はすべて0のまま更新されない状況です。

さすがに全部「0」なのは、問題ですね。

もし、phpMyAdminを普通にご利用できるのでしたら。

特定の投稿について、データベースの値を確認しても良いような気はします。

（csvで、当該テーブルをエクスポートして、Excelでいくつかの投稿を確認する等）

その結果（Excelと管理画面の投稿一覧）を見せていただくとかすると、第三者にも、分かりやすいのかなと思います。

（Excelがあれば、orphan_rowsの方も分かるかも）

ただ、phpMyAdminに慣れてない場合、怖いですよね。

ふと思いました。

投稿者:: @hiro089853

↑

Cocoon導入後は wp_cocoon_accesses のレコードは現在も増え続けており、アクセスの記録自体は正常に行われています。

上記だとすると・・・。

投稿者:: @hiro089853

↑

Search Regexで一括置換を実施

例え上記操作で、いくつかのレコードが壊れていても。

その操作後に、追加されたレコード分は、PVが表示されても良いような気がします。

（例えば、本日(7/8)分のPVは）

どういう状態なのか、気になりますね。

@mk2_mk2 

ご確認ありがとうございます。

私も同じ点が気になっております。

Search Regexや復元の影響で過去データが一部壊れていたとしても、その後に追加されたアクセスについてはPV表示されても良いように思っています。

実際、wp_cocoon_accesses のレコード数は現在も増え続けていますが、記事一覧では本日分を含め「日・週・月・全期間」がすべて0のままです。

必要でしたら、特定の記事について wp_cocoon_accesses のレコード内容（post_id・date・countなど）を確認してご報告いたします。

hiro089853さん

わいひらさん、ご提示のSQLを、今のタイミングで実行した場合。

値に変化はありますか？（特に2つめ）

先にわいひらさんがお書きになっていますが、post_typeに誤更新（誤置換）があるかも、気にはなりますね。

（そうだとしても、本日分はPV表示されても良さそうな・・・）

@mk2_mk2

ご確認ありがとうございます。

私も同じ点が気になっております。

Search Regexや復元の影響で過去データが一部壊れていたとしても、その後に追加されたアクセスについてはPV表示されても良いように思っています。

ご提案いただいた通り、特定の記事（投稿ID:48343）で確認してみました。

wp_cocoon_accesses には以下のレコードが存在していました。

• 2026-07-08　count:23
• 2026-07-07　count:65

post_type は post で、現在もアクセスレコードは正常に追加されています。

しかし、WordPress管理画面の記事一覧では、この投稿を含め「日・週・月・全期間」のPVはすべて0のままです。

添付画像のとおり、同じ投稿ID（48343）について確認しています。

wp_cocoon_accesses にはアクセスが記録されている一方で、管理画面ではPVが0のままとなっています。

この結果からすると、アクセスの記録自体は正常に行われているように見えるのですが、このような場合はどのような点を確認すればよいでしょうか。

スクリーンショットを添付いたします。

hiro089853さん

そうだとすると、親テーマに切り替えて、管理画面の投稿一覧のPVが表示されるかを、確認しても良いと思います。

以下プラグインを、使用すれば、非ログインユーザーの閲覧に影響を与えません。
（ログインユーザーのみ影響する）

Health Check & Troubleshooting
https://ja.wordpress.org/plugins/health-check/

使い方は、検索いただければ、いくつか見つかると思います。

念のため、わいひらさんが、お書きになったものを。

WordPressのトラブルシューティングを劇的に楽にする「Health Check ＆ Troubleshooting」プラグインの使い方。
https://nelog.jp/health-check-and-troubleshooting-plugin

　　
　
ただ・・・。
このプラグイン、WordPress.org公式なのですが。
脆弱性が見つかっていて、お勧めしづらくなりました。

WordPress.orgは、問題ない（差し迫った危険はない）として修正してくれないんですよね。

詳細は、以下をご参照いただければと。

プラグイン「Health Check & Troubleshooting」の脆弱性について（2025/12発覚分）
https://wp-cocoon.com/community/postid/88514/

　
検証確認時のみ、インストール＆有効化
検証確認が終わったら、アンインストールする

上記のような使い方はアリかとは思うのですが・・・。

無理にはお勧めできない感じではあります。

@hiro089853 さん

●確認

[Cocoon設定]→[管理画面]→インデックス設定のエントリード「アクセス集計方法」は「テーマ独自」になっていますか？

wp_cocoon_accessesが正しく更新されているなら、表示されないことに原因があると推測しますが？

プラグイン「Jetpack」がインストール（有効でない）されてないのにオンした場合、投稿一覧のPV表示は全てゼロ表示になります。

@chu-ya 

ご指摘ありがとうございました。

原因は単純な設定ミスでした。

同時期に、Search Regexでの一括置換やUpdraftPlusでの復元、さらに不要プラグインの整理やJetpackの無効化など、いろいろと環境を触っていたため、すっかり見落としていました。

確認したところ、[Cocoon設定] → [管理画面] → インデックス設定 のアクセス集計方法が「Jetpack」になっておりました。

「テーマ独自」に変更したところ、記事一覧のPV（日・週・月・全期間）が正常に表示されるようになりました。

wp_cocoon_accesses にアクセスが記録され続けていたことや、Search Regex・UpdraftPlusの作業時期が重なっていたことから、完全に別の原因だと思い込んでしまっていました。

お忙しい中、SQLの確認方法まで丁寧にご教示いただき、本当にありがとうございました。
同じ症状で困った方の参考にもなると思います。

hiro089853さん

解決したようで何よりです。

ということは。

投稿者:: @hiro089853

↑

問題が発生したためUpdraftPlusでバックアップから復元

復元後からCocoonの記事一覧PVが更新されなくなったことに気付きました。

上記のリストア前後で、Cocoon設定が変わったということなんですかね。

なお、本トピックは「解決済」とさせていただきました。