Google Search Console分析・改善管理ツール「10yendama SEO Watch」|十円玉ドットコム

Google Search Consoleには、ユーザーが実際に検索したキーワード、クリック数、表示回数、CTR、平均掲載順位など、SEO改善に役立つデータが大量に蓄積されてるね。

しかし、Search Consoleの画面を眺めているだけやと、

どの記事を優先して修正すべきか
どの検索語に伸びしろがあるか
順位は高いのにクリックされていない記事はどれか
どの改善案が未対応なのか
記事修正後に数値がどう変化したか

といった判断や管理を行うのは、なかなか大変＞＜

そこで、Search Consoleの実データから、伸ばすべき記事や改善候補を発見し、実際の修正作業と結果確認まで管理できるセルフホスト型SEO管理ツールを作ったで！

最新版・ダウンロード
10yendama SEO Watchとは
Search Consoleデータの分析
SEO改善作業の管理
記事修正前後の数値を比較
Search Performance Alerts
データ取得と同期
安定運用を支える機能
WordPressとの連携
アカウントと権限
1. スーパーユーザーと閲覧ユーザー
メール配送とアカウントメール
アカウント回復
主なセキュリティ対策
動作要件
インストール方法
1. 基本的な流れ
2. Google OAuth設定
現在の開発状況
GitHub
バージョン変更履歴

10yendama SEO Watchとは

10yendama SEO Watchは、Google Search Consoleの実検索データを蓄積し、次の情報を可視化するセルフホスト型SEO管理ツールや。

伸ばすべき記事
狙い目検索語
改善候補
記事修正前後の変化
検索パフォーマンスの変動通知

外部のSEO分析サービスへデータを預けるのではなく、自分のWebサーバーとMySQLで運用できる。

ComposerやNode.jsは使わず、PHPとMySQLだけで動作する構成や。

Search Consoleデータの分析

伸ばすべき記事を優先度順に表示

SEO Watchは、Search Consoleから取得したデータを記事・検索語ごとに集計する。

主に扱う指標は次のとおり。

クリック数
表示回数
CTR
平均掲載順位
検索語ごとの順位推移
前期間との変化

これらのデータを基に、

記事単位の「伸ばすべき記事」
検索語単位の「狙い目検索語」

を表示する。

改善優先度の考え方

改善優先度は、主に次の3項目から判断している。

指標	見ている内容
表示回数	その検索語にどの程度の検索需要があるか
平均掲載順位	比較的少ない改善で上位を狙えそうか
CTR	現在どれくらいクリックを取りこぼしているか

例えば、

表示回数が多い
すでに検索結果の比較的上位へ入っている
それでもCTRが低い

という検索語は、タイトル、説明文、見出しを見直すことでクリック数が伸びる可能性がある。

補足
改善Scoreは、ページ品質を断定する絶対評価やない。限られた作業時間の中で、どの記事から確認するかを決めるための優先順位や。

記事詳細から具体的な改善案を確認

記事詳細画面では、Search Consoleの数値と記事本文の構造を一緒に確認できる。

日別クリック数
日別表示回数
平均掲載順位
前期間比較
検索語ごとの順位推移
改善アクション
タイトル改善候補
追加見出し候補
WordPress記事の更新日時
既存のH2・H3

例えば、

「この検索語をタイトルへ自然に含める」
「この検索意図に対応するH2を追加する」

といった、具体的な修正方針を立てやすくしている。

URLを正規化して同じ記事へ統合

次のようなURLは、実際には同じ記事を示していても、Search Console上では別URLとして記録される場合がある。

/example
/example/
/example#toc1
/example?utm_source=example

SEO Watchでは、

URLフラグメント
末尾スラッシュ
主要な計測用パラメーター

を正規化し、同一記事のデータとして集計する。

カニバリ候補

同じ検索語で複数の記事が表示されている場合は、カニバリゼーションの可能性があるページとして確認できる。

補足
URL正規化は、元のSearch Consoleデータを削除する処理ではない。分析用の正規化URLを使って集計する仕組みや。

SEO改善作業の管理

改善提案をタスクとして登録

記事詳細に表示された改善提案は、実際の作業タスクとして登録できる。

状態は次の5種類。

未対応
対応中
完了
保留
対象外

タスクには、次の情報を記録できる。

担当者
メモ
記事修正日
作成日時
更新日時
完了日時

基本的な流れは次のとおりや。

ダッシュボードや記事詳細で改善候補を確認
改善提案をタスクへ追加
状態、担当者、メモを管理
WordPressなどで記事を修正
記事修正日を記録
タスクを完了
修正前後のSearch Consoleデータを確認

自動的に「改善済み」になる機能ではない

日数が経過しただけで、SEO Watchが記事を自動的に改善済みと判定するわけではない。

完了
＝ 記事の修正作業を終えた状態

効果測定
＝ 修正後のSearch Consoleデータを確認する処理

記事を修正した利用者が、タスクの状態と記事修正日を記録する仕組みや。

改善履歴を追記専用で保存

次の操作は履歴として保存される。

タスク作成
状態変更
担当者変更
メモ更新
記事修正日の設定
完了
再開
対象外への変更

履歴は追記専用で、Web画面から過去の記録を削除・改ざんできない設計にしている。

ユーザー権限

操作	スーパーユーザー	閲覧ユーザー
ダッシュボード・分析画面を見る	○	○
改善タスクを見る	○	○
改善履歴を見る	○	○
変動通知を見る	○	○
自分の通知を既読・非表示にする	○	○
タスクを作成・更新する	○	―
状態・担当者・メモを変更する	○	―
変動通知から改善タスクを作成する	○	―
変動ルール・検知設定を変更する	○	―
Google OAuthやシステム設定を変更する	○	―

閲覧ユーザーはメニューが非表示になるだけではなく、更新URLへ直接アクセスした場合もサーバー側で拒否される。

記事修正前後の数値を比較

記事修正日を基準に28日間を比較

記事修正日を登録すると、次の期間を比較できる。

修正前：28日間
修正後：28日間

比較対象は、

クリック数
表示回数
CTR
平均掲載順位

や。

データ不足時は測定待ちとして表示

修正後のデータが28日分揃っていない場合は、確定結果として扱わず、

効果測定まで残り17日
現在取得済み：11日 / 28日

のように測定待ちとして表示する。

注意
修正前後で数値が変化しても、その修正だけが原因とは限らへん。季節変動、検索需要、競合ページ、Googleアップデートなどの影響を含む可能性がある。比較結果は因果関係を断定するものではない。

Search Consoleの日付基準

Search Consoleの検索実績日は、America/Los_Angeles基準のDATEとして扱う。

日本時間へ変換して、検索実績日を翌日へずらす処理は行わない。

一方で、同期日時、認証監査日時、ユーザー操作日時などはUTCで保存し、利用者向け画面では設定されたIANAタイムゾーンへ変換する。

Search Performance Alerts

重要な変化を自動検知

Search Performance Alertsは、Search Consoleの検索実績を前期間と比較し、設定した条件を満たす変化を通知する機能や。

例えば、次のような変化を管理画面へ表示できる。

検索順位が大きく下がった
検索順位が大きく上がった
クリック数が急に減った
クリック数が急に増えた
表示回数が急に減った
表示回数が急に増えた
十分な表示回数があるのにCTRが大きく下がった
指定順位以内へ入った
指定順位から外れた

機械学習が原因を推測する方式ではなく、最低表示回数、変化量、変化率、順位閾値などを組み合わせた説明可能なルール方式や。

注意
変動通知はSearch Consoleデータの変化を示すものであり、記事修正、競合ページ、季節変動、検索需要、Googleアップデートなどとの因果関係を断定するものではない。

7日比較と28日比較

変動ルールでは、主に次の比較期間を利用する。

直近7日間  vs その前の7日間
直近28日間 vs その前の28日間

比較基準日は、サーバーの現在日付ではなく、対象プロパティについてDBへ保存済みの最新Search Console検索実績日から決定する。

必要な日数のデータが揃っていない場合や、Search Console同期中の場合は、無理に通知を作らず「データ不足」「取得待ち」「同期中」として扱う。

通知ルール

主な変動ルールは次のとおり。

ルール	確認する内容
掲載順位の上昇・下落	ページと検索語の平均掲載順位が、設定値以上変化したか
クリック数の急増・急減	絶対差と変化率が設定条件を満たしたか
表示回数の急増・急減	検索需要や露出に大きな変化があったか
CTRの大幅低下	十分な表示回数がある状態でCTRが何ポイント下がったか
低CTR改善候補	比較的上位なのにCTRが設定値を下回っているか
順位閾値への進入・離脱	10位以内など、設定した順位境界をまたいだか

少ない表示回数から発生するノイズを抑えるため、最低表示回数、最低クリック数、絶対変化量、相対変化率、cooldown期間などを設定できる。

変動通知センター

管理画面の「変動通知」では、検知された変化を一覧で確認できる。

未読・既読
重要度
変動種別
対象ページ
対象検索語
比較期間
前期間と現期間の値
変化量
初回・最終検知日時
発生回数
改善タスクとの関連

利用者ごとに既読・未読・非表示を管理するため、1人が既読にしても、別のユーザーの未読状態は変わらない。

発生履歴と判定根拠

同じページや検索語で変動が繰り返し検知された場合は、通知を無制限に重複作成せず、同じ通知へ発生履歴を追記する。

発生履歴には、次の情報を保存する。

検知基準日
前期間・現期間
クリック数
表示回数
CTR
平均掲載順位
変化量
検知時点の閾値
判定理由

後からルール設定を変更しても、「当時なぜ通知されたのか」を確認できる。

改善タスクへ追加

通知内容を確認して対応が必要と判断した場合は、その通知から改善タスクを作成できる。

タスクには、対象ページ、検索語、比較期間、前後の数値、変化量、確認すべき内容を引き継ぐ。

通知を検知しただけでタスクを自動作成するわけではなく、スーパーユーザーが内容を確認して明示的に追加する。

即時通知と日次メールダイジェスト

確認済みメールアドレスと有効なメール配送設定がある場合は、変動通知をメールでも受け取れる。

メールを送信しない
検知後に即時通知
日次ダイジェストとしてまとめて通知

即時通知も1件ずつ大量送信するのではなく、1回の検知処理で発生した通知をユーザー単位にまとめる。

メール配送を無効にしている場合や確認済みメールがない場合でも、管理画面の変動通知は利用できる。

重複通知とcooldown

同じ基準日・同じルール・同じ対象について検知処理を再実行しても、通知、発生履歴、メールを二重生成しない設計にしている。

また、同じ対象で似た通知が連続する場合はcooldown期間でメールの連続送信を抑えつつ、発生履歴は残す。

データ取得と同期

Web・CLI・Cronから取得

Search Consoleデータは、次の方法で取得できる。

Web管理画面から手動取得
CLIから取得
Cronによる定期取得

CLI例：

php bin/import.php --days=3

期間指定：

php bin/import.php \
  --start=2026-07-01 \
  --end=2026-07-21

変動検知：

php bin/detect-alerts.php

日次メールダイジェスト：

php bin/send-alert-digest.php

Search Console同期、変動検知、日次ダイジェストの順でCron実行する構成を推奨している。

同期の多重実行を防止

Web、CLI、Cronから同じSearch Consoleプロパティを同時に取得すると、重複処理や同期状態の混乱が起こる可能性がある。

SEO Watchでは、プロパティ単位のDB leaseを利用し、多重実行を防止する。

同期状態は次のように記録される。

実行中
成功
一部成功
失敗
中断

同期ロックの安全性

同期leaseの所有者情報はハッシュとして保存し、画面やログには表示しない。

異常終了などでleaseが残った場合は、有効期限と所有者を検証し、安全にstale lockを処理する。

同期ロックの所有権確認

同期処理では、ロック取得時に生成した所有者情報と有効期限を検証する。

heartbeatの更新内容が既存値と同じ場合でも、DB上の所有者とlease期限を明示的に確認し、正しい同期処理を所有権喪失として誤判定しない設計にしている。

安定運用を支える機能

DBマイグレーション管理

DB更新には、マイグレーション管理を使用している。

確認できる情報は次のとおり。

適用済みマイグレーション
適用日時
適用状態
定義のchecksum
アプリとDBスキーマの対応状態

既存環境からアップデートする場合も、既存データを維持したまま現在のDBをbaselineとして登録する。

maintenance CLI

期限切れトークンや古い同期履歴など、運用上不要になったデータはCLIから整理できる。

確認のみ：

php bin/maintenance.php --dry-run

実行：

php bin/maintenance.php \
  --execute \
  --target=import-runs

既定動作はdry-runで、削除予定件数を確認するだけや。

削除対象外

maintenance CLIは、次のデータを削除しない。

Search Console分析データ
改善タスク
改善履歴
改善タスクへ関連付いた変動通知
ユーザーの通知設定
ユーザー
OAuth設定
アプリ設定

Web管理画面からmaintenanceを任意実行する機能も用意していない。

環境診断

管理画面とCLIから、次の状態を確認できる。

PHPバージョン
必須PHP拡張
DB接続
DBセッションタイムゾーン
アプリ表示タイムゾーン
Search Console基準日
マイグレーション状態
Cron設定例
メール配送設定
SMTP接続・認証テストの状態
変動通知用マイグレーションの状態
有効な変動ルール数
最終検知日時と実行状態
Search Consoleの最新取得日
変動検知・ダイジェストのCron例

CLI：

php bin/doctor.php

WordPressとの連携

WordPressサイトの場合、REST APIから次の情報を取得できる。

記事タイトル
投稿日時
最終更新日時
H2見出し
H3見出し

取得した情報はDBへキャッシュし、Search Consoleデータと一緒に記事詳細画面へ表示する。

補足
WordPress管理画面へプラグインを追加する方式ではない。SEO Watch側からWordPress REST APIを読み取る構成や。

アカウントと権限

スーパーユーザーと閲覧ユーザー

インストール時に作成したユーザーはスーパーユーザーになる。

スーパーユーザーは、閲覧専用ユーザーを複数作成できる。

閲覧ユーザーは分析結果や改善タスクを閲覧できるが、次の操作は実行できない。

Google OAuth設定
Search Consoleプロパティ変更
データ取り込み
URL正規化
ユーザー管理
環境診断
Cron設定
改善タスク更新
メール配送設定
変動ルール設定
手動変動検知
変動通知からの改善タスク作成
システム設定変更

メール配送とアカウントメール

利用環境に合わせて配送方式を選択

SEO Watchでは、メール配送方法を次の3種類から選択できる。

使用しない
PHP mail()
SMTP

メールを使用しない場合でも、Search Console分析、改善管理、Cronなどの主要機能は利用できる。

パスワード再設定、メールアドレス確認、閲覧ユーザーのメール招待などを利用する場合は、PHP mail()またはSMTPを設定する。

PHP mail()

PHPが提供するmail()関数を利用する方式や。

共有レンタルサーバーなどで簡単に導入できる一方、サーバーやDNSの設定によっては、送信元認証や迷惑メール判定の面で制約がある。

mail()が成功を返しても、受信者のメールボックスへ到達したことまで保証するものではない。

SMTP

指定したメールサーバーへ接続し、認証して送信する方式や。

設定できる主な項目は次のとおり。

SMTPホスト
SMTPポート
STARTTLS・TLS・暗号化なし
SMTP認証
SMTPユーザー名
SMTPパスワード
送信元名称
Fromアドレス
Reply-To
Envelope-From
接続タイムアウト

SMTPパスワードは平文のまま保存せず、アプリの暗号化キーを使ってAES-256-GCMで暗号化保存する。

設定画面から、

SMTP接続テスト
TLS接続の確認
SMTP認証の確認
テストメール送信

を実行できる。

SPF・DKIM・DMARCについて

SEO Watchでは、From、Envelope-From、SMTP認証ユーザーのドメインに明らかな不一致がないか確認できる。

ただし、実際のSPF・DKIM・DMARCの認証結果は、利用するSMTPサーバーとDNS設定によって決まる。

補足
SEO WatchがSPFレコードやDKIM鍵、DMARCポリシーを作成するわけではない。利用するメールサービスまたはサーバー側で、適切な送信ドメイン認証を設定する必要がある。

スーパーユーザーのメールを後から追加

インストール時にメールアドレスを登録しなかったスーパーユーザーも、ログイン後のアカウント画面から追加できる。

基本的な流れは次のとおり。

アカウント画面でメールアドレスを入力
現在のパスワードで本人確認
メールアドレスを確認待ちとして保存
確認メールを送信
メール内の確認URLを開く
確認済みメールアドレスとして登録

メール配送がまだ設定されていない場合でも、メールアドレスを確認待ちとして先に保存できる。

その後、設定画面でSMTPなどを構成し、接続テストとテストメール送信を確認してから、確認メールを送信する。

確認待ちと確認済み

未登録
→ メールアドレスなし

確認待ち
→ 登録されたが、本人確認は未完了

確認済み
→ 確認URLによる本人確認が完了

パスワード再設定やセキュリティ通知には、確認済みメールアドレスだけを使用する。

アカウント回復

次の機能に対応している。

パスワード変更
パスワード再設定
メールアドレスの追加
メールアドレス確認
メールアドレス変更
閲覧ユーザーのメール招待
アカウント無効化
全セッション無効化
認証監査ログ
セキュリティ通知

パスワード再設定や確認メールは、設定されたPHP mail()またはSMTPを通して送信される。

メール確認用URLやパスワード再設定URLには有効期限があり、ワンタイムトークンの生データはDBへ保存しない。

メール配送を利用できない場合でも、CLIからスーパーユーザーのパスワードを再設定できる。

php bin/reset-password.php --user=admin

パスワードはコマンド引数へ直接記述せず、ターミナル上で対話入力する。

主なセキュリティ対策

OAuthトークンをAES-256-GCMで暗号化保存
SMTPパスワードをAES-256-GCMで暗号化保存
SMTP接続時のTLS証明書検証
CSRF対策
セッション固定攻撃対策
認証レート制限
メール送信・再送のレート制限
変動通知・発生履歴・メール配送の重複防止
変動検知処理のDB leaseによる排他
認証監査ログ
サーバー側の権限確認
メールヘッダーへのCRLFインジェクション対策
機密ディレクトリへのWebアクセス拒否
同期エラーへ秘密情報を表示しない
ワンタイムトークンをハッシュで保存
SMTP認証情報やメール本文を監査ログへ保存しない

注意
config/local.php、OAuthシークレット、DBパスワード、本番DBダンプ、Cronログなどは、公開リポジトリへ追加しないでな。SMTPパスワードはDBへ暗号化保存されるため、DBバックアップとアプリの暗号化キーも安全に管理する必要がある。

動作要件

PHP 8.1以上
MySQLまたは互換DB
HTTPSで公開できるWeb環境
Google Search Consoleへ登録済みのサイト

必要なPHP拡張：

pdo_mysql
curl
openssl
json
mbstring

ComposerやNode.jsは不要や。

Apache系共有サーバーへ直接設置でき、Nginxでも適切なアクセス制御を設定すれば利用できる。

インストール方法

基本的な流れ

空のMySQLデータベースを作成
GitHub ReleaseからZIPを取得
HTTPS公開ディレクトリへ展開
install.phpを開く
DB情報を入力
スーパーユーザーを作成
スーパーユーザーのメールアドレスを任意で入力
メール配送方法を選択
Google OAuth情報を入力
SEO Watchへログイン
Googleアカウントと連携
Search Consoleプロパティを選択
初回データを取得

メール配送は、

使用しない
PHP mail()
SMTP

から選択できる。

インストール時にメールを設定しなくても、後から設定画面で配送方法を構成し、アカウント画面からスーパーユーザーのメールアドレスを追加できる。

Google OAuth設定

利用開始時には、Google CloudでOAuthクライアントを作成する。

大まかな流れは次のとおり。

Google Cloudでプロジェクトを作成
Google Search Console APIを有効化
Webアプリケーション用OAuthクライアントを作成
SEO Watchに表示されたコールバックURLを登録
クライアントIDとシークレットをSEO Watchへ設定
Googleアカウントと連携
分析対象プロパティを選択

アクセストークンや更新トークンを、利用者が手動で生成・入力する必要はない。

詳しい手順は

GitHubのドキュメント

へ掲載している。

現在の開発状況

現在は、v1.0.0正式版へ向けたプレリリース段階や。

自分のサイトでは、次の機能について動作を確認している。

Search Consoleデータ取得
記事分析
改善タスク管理
修正前後比較
Web・CLI・Cron同期
Search Performance Alerts
7日・28日の変動比較
変動通知センター
通知発生履歴
変動通知からの改善タスク作成
即時メール通知
日次メールダイジェスト
変動検知CLI・Cron
SMTP接続・認証
テストメール送信
管理者メールの後付け
メールアドレス確認
パスワード再設定
閲覧ユーザー招待
認証監査
タイムゾーン表示
同期排他
maintenance
DBマイグレーション

今後は新機能を大幅に増やすより、

実運用による不具合修正
新規インストール試験
旧バージョンからの更新試験
大量データでの動作確認
権限・OAuth・認証の再監査
ドキュメントの最終確認
配布ZIPの検証

を優先し、v1.0.0候補版へ進める予定や。

GitHub

ソースコード、インストール手順、Google OAuth設定、Cron、アカウント回復、SMTPメール配送、Search Performance Alerts、改善タスク、同期ロック、maintenance、DBマイグレーションの説明はGitHubで公開してるで。

GitHubリポジトリ

不具合報告や改善案はこちら。

GitHub Issues

Search Consoleのデータから、

次に何を直すかを見つけ、実際の改善作業と結果確認まで管理する

道具として育てていく予定や＾＾

バージョン変更履歴

主なバージョン変更履歴を見る

v0.12.1

Search Performance Alertsを搭載したv0.12系の最新パッチ版。v0.12.1固有の修正内容はGitHub ReleaseとCHANGELOG.mdを参照。

v0.12.0

掲載順位、クリック数、表示回数、CTRの変動検知、7日・28日比較、順位閾値への進入・離脱、変動通知センター、発生履歴、利用者ごとの既読・非表示、改善タスク連携、即時通知、日次メールダイジェスト、CLI・Cronを追加。

v0.11.1

スーパーユーザーのメールアドレス追加時に発生していたSQLパラメーター処理の不具合を修正。メール追加、確認待ち保存、確認メール送信の動作を確認。

v0.11.0

メール機能の無効化、PHP mail()、SMTP配送に対応。STARTTLS・TLS接続・SMTP認証、暗号化されたSMTPパスワード保存、接続テスト、テストメール、管理者メールの後付け、メール確認・変更、ユーザー招待を追加。

v0.10.2

Search Consoleデータ同期時の、同期ロック所有権確認に関する不具合を修正。

v0.10.1

改善管理、同期排他、DBマイグレーション、maintenanceに関するドキュメントを整理。アプリ機能やDBスキーマの追加変更はなし。

v0.10.0

改善タスク、追記専用履歴、記事修正日、修正前後28日比較、同期DB lease、maintenance CLI、DBマイグレーション管理を追加。

v0.9.0

UTC保存とローカル表示を分離し、IANAタイムゾーン、MySQL UTC固定、Search ConsoleのPT基準日へ対応。

v0.8.0

パスワード再設定、メール確認、ユーザー招待、セッション無効化、認証レート制限、認証監査ログを追加。

v0.7.0以前

インストーラー、Google OAuth、Search Console分析、記事詳細、URL正規化、非同期ページング、複数ユーザー、環境診断、Cron支援を段階的に追加。

詳細な変更内容はGitHubのCHANGELOG.mdを参照してください。