記事を公開したのに、トップページの「公開記事は○本」が増えていない。僕のブログでも、2026年10月23日の公開後チェックでこの食い違いが見つかりました。
残っていたのは「39記事公開」「公開記事は39本」という2か所の固定文です。既存の集計用ショートコードに置き換えると40本になり、次の記事を公開した後は、トップページを再編集せず41本へ変わりました。
結論:現在の公開数は自動集計に寄せ、過去の実験時点の数は日付付きで残す。この2つを分けると、最新情報と運営記録を両立できます。
この記事では、39→40→41の確認記録、置き換えた箇所、同じ症状が出たときの確認順をまとめます。収益や検索順位が改善したという検証ではありません。
記事を公開しても、固定文の数字は増えない
今回、最新記事の一覧は自動更新されていました。一方、「現在の運営メモ」とページ下部の案内文には、記事数を直接入力した文字列が残っていました。
つまり「最新記事が出ている」と「紹介文の記事数が合っている」は、別の確認項目でした。どちらも同じトップページにあるので、一覧だけ見て確認を終えると見落とします。
| 10月23日に確認した場所 | 状態と対応 |
|---|---|
| 更新情報の投稿リスト | 新着記事が自動反映。変更なし |
| 現在の運営メモ | 固定の39を、登録済みの集計コードへ変更 |
| ページ下部の案内文 | 同じく固定の39を置き換え |
| 8月24日時点の実験記録 | 36本のまま保持。過去の数字だから |
固定表記がいつ・どの編集で戻ったのかまでは、今回特定していません。確認できたのは、保存本文に固定の「39」があり、その2か所を変更したことです。
39→40→41:一度直して、次の公開でも確認した
時系列を分けると、何を確かめたのかがはっきりします。
| 確認したタイミング | トップページの表示 |
|---|---|
| 10月23日、OpenRouter記事の公開後 | 固定表記は39のまま。公開投稿は40本 |
| 固定表記2か所の修正後 | 両方とも40本を表示 |
| 同日、プラン診断記事の公開後 | トップを再編集せず、両方とも41本へ |
まず、修正直後の40本表示を公開画面で確認しました。

その後、エックスサーバーのプラン診断記事を公開。トップページ側の数字は手入力せず、41本になりました。翌24日にも表示を再確認しています。

「40に直した」で終わらず、次の公開で増えるところまで確認できたのが、今回の作業の区切りです。
使ったのは、このサイトに登録済みのショートコード
ショートコードは、角括弧で囲んだ短い呼び出し文です。対応する処理がサイト側に登録されていれば、公開画面では処理結果に置き換わります。
このサイトでは、2026年5月24日に公開投稿数を返す独自コードを登録した記録があります。今回は新しい集計機能を作らず、その既存の仕組みを再利用しました。
注意:fukuro_published_post_count はWordPressやSWELLの標準機能ではありません。未登録のサイトに同じ文字列を貼っても、この記事のような集計はできません。
実際に変えた本文の例は次のとおりです。下の表示は説明用のコードで、実行する入力欄ではありません。
変更前:39記事公開、読む順番・AdSense改善・収益化導線を整理済み
変更後:[fukuro_published_post_count]記事公開、読む順番・AdSense改善・収益化導線を整理済み
5月の実装記録では、WordPressの wp_count_posts('post') が返す件数のうち、公開済みを示す publish を使っています。集計対象は通常の投稿で、固定ページや下書きを足した「サイト内コンテンツ全部」ではありません。
今回は子テーマのPHP、プラグイン、サイト設定を変更していません。既存の呼び出しが公開画面で動くことと、次の公開で件数が変わることを確認しました。
同じ症状が出たときの確認は3ステップ
まずは、数字が古い場所と、その数字の意味を切り分けます。
投稿一覧の公開済み件数と、トップの紹介文・運営メモ・新着一覧を比較。下書きや固定ページを混ぜません。
数字の直接入力と、集計処理の登録状況を確認。未登録のショートコードをそのまま貼らないようにします。
変更前を保存しPC・スマホで確認。次の通常公開でも件数が追従するか記録します。空のテスト記事を公開する必要はありません。
登録済みのショートコードを単独で置く場合は、WordPressの「ショートコード」ブロックが選択肢です。テーマなどによって処理される場所が違うため、文字列を入れたことではなく、プレビューで数値に置き換わることを確認します。
未登録なら、本番の functions.php にコードを急いで貼らないでください。バックアップと復旧方法を用意し、検証環境で対応するか、管理担当者へ依頼します。当面は「○月○日時点」と日付を付けて手動管理する、件数表示を外す、という選択でも構いません。
過去の36本まで、最新の数字に変えない
トップページには「2026年8月24日時点で公開36記事」という実験記録もあります。これは更新漏れではなく、その時点の状況を説明する数字です。
ここまで自動集計へ変えると、過去の判断をしたときの記事数が後から変わってしまいます。今回も36本の記録は残し、「現在の公開記事数は下の運営メモ」と案内する構成を維持しました。
僕が自動化したいのは、現在の状態を毎回書き直す作業です。比較の土台になる過去の実測まで、最新値で上書きしたいわけではありません。
数字が合わないときは、固定入力だけでなく、集計対象の違いやキャッシュによる古い表示も確認候補になります。ただし今回、キャッシュ削除をして解消したという記録はありません。原因を一律にキャッシュと決めつけないようにしています。
まとめ:公開後チェックに「紹介文の数字」も入れる
今回直したのは、トップページの固定表記2か所です。既存の集計処理を使うことで40本を表示し、次の記事公開後には再編集なしで41本になりました。
新着一覧、現在の記事数、過去の実験記録は、それぞれ更新の扱いが違います。まず自分のトップページで「いま何本です」と書いている場所を探す。それだけでも、公開後の見落としを減らす確認になります。
公開URL・画像・内部リンクまで含めた確認順は、ブログ記事公開後のチェックリストにまとめています。新記事への案内も整える場合は、内部リンクを公開後に確認する手順も参考にしてください。
公式の参考資料
公式資料の確認日:2026年10月24日。本文の39→40→41は、10月23日の作業と24日の再確認に基づく記録です。
