WordPressページ診断プラグインを自作した理由と制作過程｜ToshiLab Page Diagnostics

WordPressを運営していると、ひとつのページを修正したあとに確認したいことが増えていきます。

タイトル、description、canonical、H1、OGP、構造化データ、HTTPステータス。ひとつずつ見れば確認できますが、記事数が増えるほど、確認方法と記録がばらばらになっていきました。

外部の診断サービスも便利です。ただ、ToshiLabで日常的に確認したい項目を、毎回同じ順番で見て、必要な時だけ履歴に残し、サイトマップ単位でも確認できる形が欲しくなりました。

そこで制作したのが、WordPress管理画面から使うページ診断プラグイン
「ToshiLab Page Diagnostics」です。

この記事では、完成した機能の紹介だけではなく、なぜ必要になったのか、どのように範囲を決め、安全性を確認しながら本番100ページ診断そしてv1.1.2更新後・本番188ページ診断まで進めたのかを記録します。

この記事で分かること

• ToshiLab Page Diagnosticsを作ろうと考えた理由
• v1.0.0で実装する機能と、実装しない機能の分け方
• 単一ページ診断・履歴比較・サイト全体診断の設計
• ローカル環境から本番環境へ進めた確認手順
• 10→25→50→100ページと段階的に検証した理由
• 最大1000ページ化、停止・再開、途中結果保存、本番188ページ診断
• 長時間の診断を停止・再開できるようにした理由
• 本番環境で188ページを診断して分かったこと
• 診断によって実際のcanonical異常を発見・修正した事例
• 個人用WordPressプラグインを作って分かったこと

作ろうと思った理由

きっかけは、サイトの状態を確認する作業が、いくつもの場所に分かれていたことです。

ブラウザのソース、WordPress管理画面、サイトマップ、外部の診断サービス、保存したCSV。どれも役立ちますが、確認する場所が違うため、前回と同じ条件で見たのかが分かりにくくなります。

特に困っていたのは、次のような場面でした。

• 記事修正後にtitleやcanonicalが正しく出ているか確かめたい
• OGPやTwitter Cardの設定漏れをまとめて見たい
• H1や構造化データの状態をページごとに確認したい
• 前回の診断結果と現在を比較したい
• サイトマップ内の複数ページを同じ基準で点検したい
• 結果をCSVやJSONで残し、後から見直したい

単に「点数を出すツール」が欲しかったわけではありません。

欲しかったのは、問題を自動で直す仕組みではなく、自分で判断するための情報を同じ形式で集める仕組みでした。

最初に決めたのは「何をしないか」

機能を考え始めると、やりたいことは増えていきます。

しかし、最初の版で多くを自動化すると、何が原因で問題が起きたのか分かりにくくなります。そこでv1.0.0では、診断と記録に範囲を絞りました。

この区切りを先に決めたことで、「便利そうだから追加する」のではなく、本当に必要な機能から順に作れるようになりました。

v1.0.0でまとめた機能

ToshiLab Page Diagnostics v1.0.0では、機能を5つに分けました。

1．単一ページ診断

URLを1件入力し、公開ページを取得して、基本的な状態を確認します。

主な確認対象は次のとおりです。

• HTTPステータス
• リダイレクト回数
• title
• meta description
• canonical
• robots・インデックス可否
• H1
• OGP
• Twitter Card
• JSON-LD
• SEO・AIOの基礎確認に使う補助情報

診断結果は、エラー・警告・情報に分けて表示します。

ここで大切にしたのは、警告を「故障」として扱わないことです。たとえばH1が見つからない場合、プラグインが壊れているのではなく、対象ページ側に見直し候補があるという意味です。

2．診断履歴と変更比較

診断結果は、すべて自動保存するのではなく、残したい結果だけを手動で保存する形にしました。

保存した結果と現在を比べると、次の変化を確認できます。

• エラー件数の増減
• 警告件数の増減
• 情報件数の増減
• 新しく追加された問題
• 解消された問題
• 変更がなかった項目

履歴数は、1つのURLにつき最大10件、全体で最大50件です。

無制限に記録を増やさず、「変更前」「変更後」「大きな更新時」など、意味のある地点を残す使い方にしています。

3．サイト全体診断

XMLサイトマップを読み込み、複数ページを同じ条件で診断します。

診断上限は、プルダウンから次の4段階を選べます。

• 10ページ
• 25ページ
• 50ページ
• 100ページ

最初から100ページだけを想定せず、少ない件数から段階的に試せるようにしました。

結果画面では、診断完了数、取得エラー、HTTP 200以外、要修正、警告あり、合格、AIO基礎確認ありなどを集計し、ページごとの結果も一覧で確認できます。

4．CSV・JSON出力

サイト全体診断の結果は、CSVとJSONで保存できます。

CSVはExcelで扱いやすいUTF-8 BOM付きにし、日本語が文字化けしないことを確認しました。JSONには集計情報とページごとの診断結果を入れ、あとからプログラムで扱える形にしています。

画面を見るだけで終わらず、診断時点の記録を手元に残せるようにしたかったためです。

5．運用状態の確認

本番導入後に「動いているように見える」だけでは不安が残ります。

そこで、プラグインの動作前提をまとめて確認できる「運用状態」画面を用意しました。

初版v1.0.0を本番環境へ導入した時点では、次の内容を確認できました。

• 本番環境モード
• PHP 8.4.23
• WordPress 7.0.2
• PHP DOM拡張
• PHP libxml拡張
• プラグイン 1.0.0
• API契約 1.2（後方互換）
• home_url と許可ホスト
• HTTPS
• SSL検証
• 公開API制限
• 診断キャッシュ
• サイト全体診断の上限
• 履歴保存数
• 同名プラグインによる自動上書き防止

その後、v1.1.2へ更新し、運用状態画面でもプラグイン1.1.2、API契約1.2、最大1000ページ対応、本番環境でのSSL検証有効を確認しました。

この一覧にある「プラグイン1.0.0」は、初版本番導入時の記録として残しています。

安全性で優先したこと

ページを取得する機能は、URLを受け取ってサーバーから通信します。便利な反面、入力先を自由にしすぎると、個人用プラグインとしては不要な危険が増えます。

そのため、制作時は機能数だけでなく、次の制限も重視しました。

許可ホストをToshiLabに限定する

このプラグインは、ToshiLabの運用を目的にしています。

入力されたURLが自分のサイトに属しているかを確認し、外部サイトを自由に診断する用途に広げない設計にしました。

HTTPSとSSL検証を有効にする

本番ではHTTPSを使用し、SSL証明書の検証を無効にしないことを前提にしています。

ローカル環境では自己署名証明書や開発用URLの都合がありますが、本番の安全基準まで緩めないよう、環境の違いを分けて扱いました。

診断件数を最大100ページに制限する

大量ページを一度に取得できるようにすると、WordPress管理画面やサーバーへの負荷が読みづらくなります。

v1.0.0では最大100ページとし、さらに10・25・50ページから選べるようにしました。

ここで設定した最大100ページは、初版v1.0.0の安全上限です。

その後、記事数が100ページを超えたため、単純に上限値だけを変更するのではなく、1ページずつ順番に診断する仕組み、停止・再開、途中結果の一時保存、有効期限、一覧のページ分割を追加しました。

これらの仕組みをローカル環境で検証したうえで、v1.1.2では最大1000ページまで選択できるようにしています。

診断結果を自動保存しない

サイト全体診断は、実行するたびに多くの情報を扱います。これをすべてデータベースへ保存すると、確認のための機能がWordPress側の負担になる可能性があります。

そのため、サイト全体診断は自動保存せず、必要な時にCSV・JSONとして書き出します。単一ページの履歴だけを、上限つきで手動保存する形に分けました。

制作はローカル環境から始めた

本番サイトでコードを書き換えながら試すことは避けました。

初版v1.0.0を制作した時に使用した主な環境は、次のとおりです。

v1.1.2への更新も、同じLaragon環境へ本番サイトを復元して検証しました。PHP構文確認、プラグインの有効化、REST API、単一ページ診断、停止・再開、外部ホスト拒否などを確認してから、本番用ZIPを作成しています。

ローカル環境には、本番のサイトデータとデータベースを復元し、URLを開発用ドメインへ置き換えました。

先に本番に近いページ構成を用意できたことで、実際のtitle、OGP、構造化データ、サイトマップを対象に確認できました。

制作を進めた順番

実際の作業は、機能を一度に完成させる形ではなく、小さく確認しながら進めました。

手順1．診断項目と判定基準を整理する

最初に、「取得できたか」と「改善候補があるか」を分けました。

HTTP 200でページを取得できたとしても、H1やcanonicalが不足していることがあります。反対に、警告が表示されていても、ページの目的によっては直ちに修正しなくてよい場合があります。

そこで、取得失敗、明確な問題、確認候補、補助情報を同じ扱いにしないよう、エラー・警告・情報へ分けました。

手順2．単一ページ診断を先に作る

サイト全体診断より先に、1ページ分の取得・解析・表示が正しく動くことを確認しました。

単一ページで判定が安定していなければ、100ページに増やしても誤判定が増えるだけです。

この段階で、title、description、canonical、H1、OGP、Twitter Card、JSON-LDなどが、実際のページから取得できるかを確認しました。

手順3．履歴保存と比較を追加する

次に、診断結果を保存し、現在との違いを比較する機能を追加しました。

同じページを変更せずに比較した時は「変更なし」になること、問題が追加・解消された時に差分として扱えることを確認しました。

手順4．サイトマップから複数ページを診断する

単一ページの結果が安定したあと、サイトマップを読み込み、複数URLへ同じ診断を適用しました。

一覧では、ページ数だけでなく、取得エラーやHTTP 200以外の件数がすぐ分かるようにしています。

手順5．CSV・JSONの出力を確認する

画面の集計と、出力ファイルの件数が一致することを確認しました。

初回の本番10ページ診断では、CSVに10ページ・22列が入り、JSONにも同じ10ページ分が収録されました。日本語の文字化けがなく、URLと集計値が一致することも確認しています。

手順6．運用状態をまとめて見られる画面を作る

PHPやWordPressのバージョンだけでなく、必要なPHP拡張、HTTPS、許可ホスト、保存上限などを1画面で確認できるようにしました。

これは、あとから環境を変更した時にも役立ちます。

ZIP化する前に確認したこと

ローカル検証が終わったあと、WordPress管理画面からインストールできるZIPを作成しました。

ZIPでは、ファイルが存在するだけでなく、プラグインフォルダーの階層が正しいことが重要です。

今回の最終確認結果は次のとおりです。

ZIP：toshilab-page-diagnostics-v1.0.0.zip
容量：79.9KB
格納エントリー数：36
ルート階層：正常
メインPHPファイル：確認済み
SHA-256：B65178F81ABE2CA852A7B4A44FBC1F3DF43FF3F65F36D89402638FA9E962A8C1

SHA-256は、今回確認したZIPを識別するための値です。別の環境でZIPを作り直した場合は、内容が同じように見えても値は変わることがあります。

本番では、すぐに100ページを診断しなかった

ZIPが正しくても、本番で同じように動くとは限りません。

そのため、次の順番で確認しました。

1. プラグインをインストールする
2. WordPressとPHPの要件を確認する
3. 有効化する
4. 運用状態を確認する
5. トップページを1件だけ診断する
6. 履歴保存と現在との比較を行う
7. サイト全体を10ページ診断する
8. CSV・JSONを保存する
9. 25ページへ増やす
10. 50ページへ増やす
11. 最後に100ページを診断する

この順番なら、問題が起きた時に、どの段階で発生したのかを切り分けやすくなります。

本番100ページ診断の結果

最終的に、100ページ診断は正常に完了しました。

100ページの中には警告やAIO基礎確認が表示されたページもあります。

ただし、それらはプラグインの異常ではなく、ページ側の改善候補です。診断機能の動作確認では、「100件を取得できたか」「取得エラーやHTTP異常がなかったか」を分けて判定しました。

v1.0.0公開後、v1.1.2まで発展させた
├─ 100ページ上限では足りなくなった
├─ 最大1000ページへ広げるために追加した仕組み
├─ 停止・再開と途中結果保存への対応
├─ ローカル環境で安全性を再検証
├─ 本番環境で188ページを診断
└─ canonical異常を発見して修正

v1.0.0公開後、v1.1.2まで発展させた

v1.0.0で最大100ページの診断まで確認できたことで、初版として必要な機能はそろいました。

しかし、実際のToshiLabには公開ページが100ページ以上ありました。今後の記事追加も考えると、100ページだけではサイト全体を確認できません。

そこで、v1.0.0を作り直すのではなく、安全性を保ちながら診断件数を増やす方向で改良しました。

100ページ上限では足りなくなった

v1.1.2では、サイト全体診断の上限として次の件数を選べます。

• 10ページ
• 25ページ
• 50ページ
• 100ページ
• 250ページ
• 300ページ
• 400ページ
• 500ページ
• 750ページ
• 1000ページ

ただし、1000ページを一度にサーバー側で処理する設計にはしていません。

診断対象を1ページずつ順番に取得し、進捗と途中結果をブラウザ側で管理することで、WordPressやサーバーへ急激な負荷をかけない形にしています。

停止・再開と途中結果保存を追加した

ページ数が増えると、診断完了まで数分以上かかる可能性があります。

そのため、v1.1.2では次の機能を追加しました。

• 実行中の診断を停止する
• 停止した位置から再開する
• 前回完了した診断結果を再表示する
• 不要になった途中結果を削除する
• 診断結果の一覧をページ分割して表示する

途中復旧用データはWordPressのデータベースへ自動保存せず、診断を実行したブラウザへ24時間だけ保存します。

単一ページの診断履歴は、これまでどおり必要な結果だけを手動保存します。サイト全体診断の詳細結果は、CSVまたはJSONとして手元へ保存します。

ローカル環境で安全性を再確認した

最大1000ページ対応後も、いきなり本番環境で全ページ診断は行いませんでした。

Laragonへ復元したローカル環境で、次の内容を確認しています。

• プラグイン有効化時にFatal errorやWarningが表示されない
• 公開ページを正常に診断できる
• 診断結果のキャッシュが動作する
• 存在しないページのHTTP 404を保持できる
• 外部ホストを拒否できる
• WordPress管理系パスを拒否できる
• 不正なURLを拒否できる
• 外部サイトへ転送されるURLを拒否できる
• エラー内容へサーバー内部のパスを表示しない

確認用スクリプトでも、Laragon向けの主要7項目と本番環境向けの8項目がすべてPASSになりました。

v1.1.2の本番更新用ZIPを確認した

ローカル環境での検証が完了したあと、本番WordPressへ更新するためのv1.1.2パッケージを作成しました。

初版v1.0.0と同様に、ZIPファイルが作成できただけでは本番へ導入せず、フォルダー階層、メインPHPファイル、格納ファイル数、SHA-256を確認しています。

今回確認したv1.1.2のZIP情報は、次のとおりです。

ZIP：ToshiLab_Page_Diagnostics_1.1.2.zip
容量：90,899バイト（約88.8KB）
格納ファイル数：38
ルート階層：正常
メインPHPファイル：確認済み
SHA-256：7171FA2DEC8EE9EEB5EAA6B4253A45AEA5B75AB2DC306527D39A88A1C0FDAEF7

SHA-256は、本番環境へ導入したv1.1.2のZIPを識別するための値です。

同じバージョン名でも、ファイルを修正したりZIPを作り直したりするとSHA-256は変わります。そのため、ここに記載した値は、今回検証して本番へ導入したパッケージの記録として残しています。

本番環境では、サイト本体とデータベースのバックアップを取得してから、既存のv1.0.0を無効化し、「アップロードしたもので現在のものを置き換える」を使用してv1.1.2へ更新しました。

このZIPは、ToshiLabの環境に合わせて制作・検証した個人運用用パッケージです。現在は一般配布しておらず、本記事からのダウンロードも提供していません。ZIP情報とSHA-256は、今回本番環境へ導入したパッケージを識別するための制作記録として掲載しています。

本番環境でサイト全体を診断した

ローカル検証後にv1.1.2を本番WordPressへ導入し、最初に単一ページと10ページ診断を確認しました。

問題がないことを確認してから診断範囲を広げ、拡張後の初回診断ではサイトマップに含まれる188ページを診断しました。

その後、リダイレクトやサイトマップの内容を見直した最新の再診断では、184ページを次の状態で完了しています。

• 診断完了：184ページ
• 取得エラー：0件
• HTTP 200以外：0件
• 途中停止：なし
• 管理画面のFatal error・Warning：なし
• CSV保存：成功
• JSON保存：成功

診断ページ数が188ページから184ページへ変わったのは、プラグインが途中でページを見失ったという意味ではありません。サイトマップやリダイレクト設定を見直したあとの対象URL数の違いです。

実際のページ設定の問題も発見できた

サイト全体診断では、プラグイン自体の動作確認だけでなく、実際の記事設定の問題も見つかりました。

対象記事のcanonicalには、本来のURLではなく文字化けしたハッシュタグが出力されていました。

JIN:Rの記事編集画面を確認したところ、canonical欄へハッシュタグが入力されていました。canonical欄を空欄にして記事を更新すると、現在の記事URLが正しく出力されるようになりました。

修正後に単一ページ診断を行った結果は、次のとおりです。

• HTTP：200
• エラー：0件
• 警告：0件
• 情報：2件
• 総合判定：合格

また、Redirectionプラグインの転送先へ本番ドメインを含む絶対URLが保存されていたことで、ローカル環境から外部ホストへの転送と判定された例もありました。

転送先を「/privacy-policy/」のような同一サイト内の相対パスへ修正することで、ローカル環境と本番環境の両方で正しい転送先を使用できるようになりました。

この経験から、診断結果はプラグインの不具合を探すだけでなく、記事編集画面やリダイレクト設定に残った見落としを見つけるためにも役立つと分かりました。

制作して分かったこと

診断結果と修正判断は別にした方がよい

ツールが警告を出しても、すべてを機械的に直せばよいとは限りません。

固定ページ、記事、カテゴリーハブでは、必要な見出しや構造化データが異なることがあります。プラグインは見落としを減らす役割にとどめ、最終判断はページの目的を見ながら行う方が安全です。

機能より先に上限を決めると扱いやすい

履歴数、診断ページ数、保存方法を先に制限したことで、個人サイト向けの道具として扱いやすくなりました。

無制限にできることより、「ここまでなら安全に試せる」と分かることの方が、日常運用では大切でした。

ページ数を増やすなら、停止と再開を先に考える

100ページまでは、診断が終わるまで画面を開いて待つ方法でも運用できました。

しかし、500ページや1000ページを想定すると、通信状況、ブラウザ操作、誤クリックなどで処理が中断する可能性が高くなります。

そのため、上限値だけを増やすのではなく、停止、再開、途中結果の保存、有効期限、削除までをひとつの機能として考える必要がありました。

大量ページ対応では、「何ページ処理できるか」だけでなく、「途中で止まっても安全に続けられるか」が重要でした。

ローカルで動いたあとが本番検証の始まり

ローカルでエラーがないことは大切ですが、それだけで本番導入完了とは判断できません。

WordPress・PHP・SSL・サイトマップ・キャッシュなど、本番固有の条件があります。少ない件数から段階的に確認したことで、プラグインを有効にしたまま運用できる状態まで確かめられました。

AIとの協力も、判断と検証が必要

今回の制作では、設計の整理やコード作成、確認用コマンドの準備にAIも使用しました。

ただし、AIに依頼しただけで完成したわけではありません。何を診断するか、どこまで自動化するか、どの順番で本番へ進めるかを決め、実際のWordPress環境で結果を確かめる作業が必要でした。

AIは制作を進める助けになりますが、最終的に「動いた」と判断できるのは、実環境で記録を残しながら確認したあとです。

今後の扱い

v1.0.0は、ToshiLabの運用に必要な基本機能をまとめた最初の完成版です。

その後、実際の運用で100ページ上限では足りないことが分かり、停止・再開、ブラウザへの途中結果保存、一覧のページ分割などを追加しました。現在の安定版はv1.1.2です。

現時点では、次の状態まで確認できています。

今後は診断件数を増やすことだけを目的にせず、実際の運用で見つかった改善点をもとに更新します。

特にAIOについては、AIがページ内容を直接評価する機能ではなく、著者情報、公開日・更新日、構造化データ、本文構造など、検索エンジンやAIが内容を理解するための基礎情報を確認する方向で発展させる予定です。

まとめ

ToshiLab Page Diagnosticsは、「高機能なSEOツールを作る」ことから始めたものではありません。

自分のサイトで繰り返していた確認作業を、毎回同じ基準で行い、必要な時に記録へ残す。そのための小さな仕組みとして制作を始めました。

初版v1.0.0では機能の範囲を決め、ローカルで確認し、ZIPの中身を検証したうえで、本番環境を1ページから100ページまで段階的に診断しました。

その後、記事数の増加に合わせて、停止・再開、途中結果の一時保存、一覧のページ分割を追加し、v1.1.2では最大1000ページまで選択できるようになりました。

本番環境でもサイト全体診断を完了し、取得エラー0件・HTTP 200以外0件を確認しています。診断結果から実際のcanonical異常を発見し、記事設定を修正したあとに合格へ変わることも確認できました。

今回の制作で分かったのは、診断ツールは問題を自動で直すためのものではなく、見落としを減らし、自分で修正を判断するための情報をそろえる道具だということです。

個人開発では、完成したコードだけでなく、どの環境で、どの件数まで、どのような失敗を含めて確認したのかを残すことも大切です。この制作記録を、今後の更新やAIO基礎診断へ発展させるための基準点として残します。

次に読む

ここまで、ToshiLab Page Diagnosticsを作ろうと思った理由と、初版v1.0.0から最大1000ページ対応のv1.1.2まで発展させた制作過程を振り返りました。

実際のインストール方法、単一ページ診断、履歴比較、サイト全体診断、停止・再開、CSV・JSON保存の手順は、次の記事でまとめています。

導入・使い方編を読む

ToshiLab Page Diagnosticsの導入方法と使い方｜最大1000ページ診断・CSV／JSON保存まで

関連記事

PHPロードマップを見る

PHPロードマップ｜WordPressにもつながるサーバー側プログラミングの入口

PHP実行環境を用意する

PHPの実行環境を用意する｜LaragonでPHPを動かす準備

ToshiLab Tools制作メモ

WEBプログラミング番外編：ToshiLab Toolsを作った流れ｜学習中に使える便利ツールを自作する考え方

toshi

フルスタックエンジニア

XFacebookInstagramContact

C型肝炎や感染症の闘病を経て現在通院中
フリーランスとして今日を生きる、それがすべて。
静かな光の中で、歩みを止めずに生きていく。
実験大好きなので色々とやっていきます。