株式会社バーニングトライブ

17サイトのDRを毎日測る仕組み ― 階段状下落を自動検知するPDCAダッシュボード

この記事の結論

  • 増えたサイトを見張る負担を抑えるため、被リンクやDRの状態を毎日自動で確認する仕組みを自社開発しました。
  • PDCAの4工程: 毎日のバッチは次の4工程で構成しています。
  • 「階段状下落検知」を作った理由: 7日・30日の窓では急落が移動平均に埋もれるため、前日比だけを見るアラートを足しました。

17サイトを毎日見張ると、何が壊れているか分かる

SEOのためにサイトを増やすと、次第に「増やしたサイトを見張るコスト」が本業になっていきます。弊社では現在17〜18のドメインを運用しており、被リンク・サイトマップ・DR(Ahrefsのドメインレーティング)の状態を毎日自動で確認する仕組み(dr-boost)を自社開発し、launchdで毎朝9:30に自動実行しています。この記事では、その設計と、実際に事故を検知できた実例を紹介します。

最終更新日: 2026-09-02

PDCAの4工程

毎日のバッチは次の4工程で構成しています。

  1. Do: 18サイト分のAhrefs DRを無料公開APIから取得し、履歴に追記
  2. Check(被リンク): 登録済みの掲載ページを実際に取得し、自サイトへのリンクが生きているか・dofollowかを検証
  3. Check(検索健全性): robots.txt→sitemap→公開URLの順にたどり、4xx/5xxが出ていないかをサンプリング確認
  4. Plan/Act: 残っている登録タスクから次の1件を優先度順に決め、日次レポート(pdca.md)を更新

直近の実行結果では、被リンク検証368本すべて生存(dofollow 321本)、sitemap掲載URL 10,894件のうちサンプリング283件をHTTP確認して4xx/5xxともに0件でした。数字が大きいほど「異常なし」を毎日目で確認するのは非現実的になるため、この監視は人間が読む前に機械が一次選別する前提で作っています。

「階段状下落検知」を作った理由

DRの推移は7日・30日といった窓で見るのが一般的ですが、この窓には弱点があります。1日で急落しても、その後なだらかに動けば移動平均やトレンド表示に埋もれて見逃される、という弱点です。実際に弊社のburningtribe.tokyoでDRが8から1へ一気に落ちる事故が発生したことがあり、これを教訓に、7日/30日のトレンド計算とは別に「前日比」だけを見る専用のアラートを追加しました。

検知条件はシンプルです。

  • 前日比で-2ポイント以上下落した
  • または前日のDR値に対して30%以上下落した

このどちらかを満たした場合のみ、日次レポートの先頭に「🔴 要対応: DR階段状下落」として出力します。実装は以下のような考え方です(要旨)。

// 前日比-2以上、または前日DRに対し30%以上の下落を検知
// 7日/30日窓では急落がなだらかな下落に埋もれて見逃されるため、
// 「1日で」という条件に固定する
const delta = cur.dr - prev.dr;
const pct = prev.dr > 0 ? delta / prev.dr : null;
const isDrop = delta <= -2 || (pct !== null && pct <= -0.3);

閾値を絶対値(-2)と相対値(30%)の両方で持たせているのは、DRの絶対値が小さいサイト(DR1〜3程度)ではポイント差だけでは検知が鈍く、逆にDRが大きいサイトでは30%基準だと反応が遅すぎるためです。両方をORで評価することで、サイトの規模を問わず1日単位の急落を拾えるようにしています。

Checkを厳しくする理由: 「消えたリンク」は新規登録より痛い

このツールで最も工数を割いているのは新規のリンク獲得ではなく、Check工程です。プラットフォーム側のプロフィール編集の巻き戻し、アカウント凍結、仕様変更などにより、登録済みのつもりのリンクが後から消えることがあります。新しく1本獲得するより、既存の参照ドメインを1本失うほうが被リンクプロフィール全体への影響が大きいため、運用ルールとして「要対応が出たら、新規登録より先に復旧を優先する」を徹底しています。検索健全性監査で4xx/5xxが検出された場合も同様に、新規施策よりURL復旧・301設定・サイトマップ除外の判断を先に行います。

運用ルールとしての抑制

DR向上のツールというと登録数を増やす方向に振れがちですが、抑制の設計も同じくらい重視しています。

  • 月5〜10ドメインのペースを厳守し、一気に大量登録しない
  • 同一ドメインへの2本目のリンクはほぼ加算されないため、参照ドメイン数を優先する
  • アンカーテキストはブランド名・URL・自然文に限定し、完全一致キーワードの反復はしない
  • リンク購入・PBN・サテライトサイトの量産・コメントスパムは行わない

自動化しているのはあくまで「計測」と「異常検知」であり、登録作業自体(アカウント作成・フォーム送信)は人間が行い、ログイン後の入力補助のみをAIが担う設計にしています。

まとめ

  • 複数サイトのSEO運用では、施策そのものより先に「壊れていないか」を毎日機械的に確認する体制が要る
  • DRのようなスコアはトレンド表示だけでは急落を見逃す。1日単位の専用アラートを別途持つ価値がある
  • 新規獲得より既存資産の維持(Check工程)を優先する運用ルールが、長期的な被リンクプロフィールの安定につながる

Burning Tribeでは、こうした計測・監視の自動化を含むAI導入支援を行っています。自社サイトの運用体制を見直したい方は、無料相談をご利用ください。

無料相談はこちら

よくある質問

DRとは何ですか?

Ahrefs社が提供する、ドメインの被リンクプロフィールの強さを0〜100で示す指標です。検索順位を直接決めるものではありませんが、被リンクの健全性を確認する目安として利用しています。

この仕組みは特定のツールに依存していますか?

Ahrefsの無料公開APIとGoogle Search Consoleのデータを使っていますが、判定ロジック(1日単位の急落検知、4xx/5xx監視)自体は自社実装のNode.jsスクリプトで、他の計測元にも応用できる設計です。

他にAIを使った運用の自動化事例はありますか?

弊社ではClaude Codeの並列セッションを可視化するダッシュボードや、Search Consoleの全クエリをサブエージェントで監査する手順も紹介しています。あわせてご参照ください。


投稿日

カテゴリー:

投稿者:

タグ: