WordPress公開後のチェック実例：5ページで確認したこと・測れないこと

サイトを公開した後、どこまでを機械的に確認できるのでしょうか。AIサイト運営ラボでは、自分たちのWordPressの公開ページ5件に対して、認証なしの読み取りチェックを実行しました。この記事は当サイトの観測記録であり、サーバーの性能比較ではありません。

対象と確認条件

対象はトップページ、運営・編集方針、公開実験の計画、既存エックスサーバーの構成記録、人間の作業時間を減らす運用チェックリストです。2026年9月4日14時58分（日本時間）に、各URLへ順番に1回ずつGETリクエストを送りました。最大10ページ、各リクエストの待ち時間上限15秒、リダイレクトは追わない条件です。画像や広告リンクへのアクセスは行っていません。

初回チェックの結果

その時点で本文を取得できたことは確認できました。ただし「障害が起きない」「SEOに強い」「表示が速い」という評価には使っていません。

広告をクリックせずに確認する

構成記録の記事では、公開HTMLに含まれる広告コードが、このサイト向けに取得したコードと一致することを別途確認しました。確認のために広告をクリックする操作は行っていません。広告表示やコードの存在を確かめることと、広告先へアクセスすることは分けています。

通信失敗をサイト障害と決めつけない

最初の実行環境では通信に失敗しました。その後、外部通信を許可した環境で同じ確認を行うと5ページとも取得できました。最初の失敗も記録に残していますが、それだけでサイトが停止したとは判断していません。

自動チェックには確認元のネットワーク条件も影響します。失敗したらすぐ本番設定を変えるのではなく、確認側の通信とサイト側の状態を切り分けます。

追加した機械チェック

同日23時00分（日本時間）には、意図しないnoindex、広告リンクのサイト識別コードの不一致、構成記録の記事での広告リンク欠落、「広告リンク未設置」という古い表記を確認する項目を追加して実行しました。対象5ページで、今回実装したチェックに該当する警告はありませんでした。

広告リンクがあるページでは「広告・PR」という文字列の有無も確認しています。ただし、文字列が存在するだけで広告表示が十分とは判定できません。表示位置や読みやすさ、広告主の条件との整合は別に確認する必要があります。

まだ測れていないこと

ブラウザー描画速度、Core Web Vitals、長期間の稼働率、収益、人間の月間作業時間は、このチェックでは測っていません。本文取得にかかった時間も測定元や通信条件を含む単発値なので、サーバー比較の根拠にはしていません。

読み取りチェックは実行済みですが、定期実行はまだ設定していません。警告がなかったことを、安全性や正確性の全面的な保証として扱わない方針です。

同じ確認を試すときの順序

1. 自分が管理する公開ページを少数だけ対象にする。
2. 確認日時、URL、HTTP応答、確認項目を記録する。
3. 確認元の通信失敗と、サイト側のエラーを分ける。
4. 広告リンクをクリックせず、掲載コードと説明を照合する。
5. 目視や内容の確認が必要な項目を残す。

今回の環境構成は既存エックスサーバーで実験サイトを分けた記録にまとめています。検証と広告の扱いは運営・編集方針をご覧ください。

記録日：2026年9月4日。観測対象は当サイトのみ。他サービスや他サーバーとの比較は行っていません。

追記：記事公開後に見つかった自動チェックの弱点

23時04分の確認で、この記事が引用している「広告リンク未設置」という文字列を、古い説明が残っていると機械判定する誤警告が発生しました。文字列だけでは引用と現状説明を区別できないため、文脈確認が必要な候補として記録する方式に変更しました。検出を削除したのではなく、確定した不具合と要確認を分けています。

また、トップページから新着記事だけをたどると、記事が増えた際に広告掲載記事が確認対象から外れることが分かりました。広告掲載記事のURLを固定の確認対象に追加し、23時05分には6ページを取得できました。HTTP応答・タイトル・h1・広告コードの今回のチェックは通過し、この記事の引用表現は文脈確認候補として残しています。

この修正は、AIが記事を増やすだけでなく、確認方法自体の抜けや誤警告を検証する必要があることを示した当サイトの事例です。