ランブック
記事は公開済みですが、パイプラインはまだ完了していません。このランブックは、サイトごとにリンクデータを記録し、何か問題がある場合にのみ人間に通知するスケジュール付き監査を追加します。
SEOBlogBot研究チーム ·
ゲートは下書きを確認しますが、監査はライブサイトが実際にどう動作するかを確認します。プラグインはリンクを書き換え、編集者はクリーンなURLの上にアフィリエイトリダイレクトを貼り付け、CDNの移行により1つのホストが別のホストに変わることがあります。これらはすべて下書きの段階では存在しないため、公開後の監査がそれらが現れる最初の場所となります。
有用な監査は意図的に退屈なものです。スケジュールに従って実行され、1行だけ記録し、例外が発生した場合のみ沈黙を破ります。沈黙が目標です。1ヶ月間ログが静かであれば、ジョブがアイドル状態なのではなく、正常に機能していることを意味します。
一般公開用の公式なGoogleバックリンクチェッカーAPIはないため、チームはサードパーティのリンクインデックスを呼び出します。これは当社の独自クローラーです。Search ConsoleはGoogleが自身のリンクをどのように見ているかを示しますが、監査はそれを置き換えるものではなく補完するものです。
トリガーを記録してください。3つのセットアップがほとんどのチームをカバーしており、それぞれが同じ呼び出しを実行します。トリガーよりもログが重要なのは、日付、URL、使用されたクレジットが毎回そこに記録されるべきだからです。
サイトがリポジトリからビルドされる場合、スケジュール付きワークフローは最も摩擦が少ない追加となります。ジョブはコードの隣に存在し、キーはリポジトリのシークレットストアに保存されます。以降のワークフローファイルは必要な最小限のものです。リポジトリに保持し、他のコードと同様にレビューし、依存しているアクションのバージョンを固定してください。
ビルド用にすでにマシンを維持しているチームは、同じコマンドをそこでスケジュールできます。n8nなどのツールはExecute Commandステップを通じてこれらを実行できますが、crontabの行で直接実行することもできます。いずれにせよ、ジョブはキーを読み取ることができ、それ以外のことはできないユーザーとして実行すべきです。
一部のCMS設定では、記事が公開された際にWebhookがトリガーされ、そのイベントで監査を開始できます。これにより、記事が公開された瞬間にチェックが実行されます。単一のWebhookの欠落により記事がチェックされない可能性があるため、スケジュール付きの実行も維持してください。
記事が公開された直後の1回の実行は、送信先ホストをチェックします。2回目の実行は1ヶ月後に行い、サイトのrefdomainsを読み取ります。インデックスは約1ヶ月ごとに更新されるため、早期の読み取りでは何も新しいものが表示されません。
action=overviewは、コストなしでサイトの主要な数値を返します。日付を添えて、この実行のベースライン行として保存してください。
概要が前月と異なる場合は、refdomains（2クレジット）とanchors（2クレジット）を呼び出し、保存されたリストとの差分を取ります。
日付、記事URL、実行した呼び出し、_credits残高。プライベートリポジトリにコミットされたプレーンなCSVで十分です。
HTTP 401、HTTP 402、前月に行があったサイトに対する空の結果、または10ポイント以上の評価低下。
記事がホストされているドメインから開始します。その後、ベンチマークしたい2〜3のピアに対して同じ監査を実行します。それにはcompareを使用します。最大20ドメインを1クレジットで処理できるため、ピアチェックのコストはほぼゼロです。
ロングテールをスキップする。余分なサイトごとにログにノイズが加わり、人間が読むべき内容が増えます。無関係な20ドメインのベンチマークは、自身のサイトについてほとんど何も教えてくれません。
スケジュール付きジョブは毎回キーを読み取るため、サインインステップは不要です。保護すべきはキー自体のみです。キーには3つの明らかな漏洩経路があります：コミット、印刷された環境変数、プロキシが記録するURL。それぞれを閉じてください。
キーをCIプロバイダーのシークレットストア、またはジョブのユーザーのみが読み取れる環境ファイルに貼り付けてください。決してコミットしないでください。環境変数をエコーするステップはキーを出力するため、そのようなステップは書かないでください。
Bearerヘッダーを使用すると、URLは記録されるがヘッダーは通常記録されないため、キーはほとんどのアクセスログから除外されます。クエリ文字列形式も機能しますが、リクエストを見るすべてのプロキシにコピーが残ります。
ジョブを保守する人々にのみ読み取り権限を与え、他には与えないでください。ジョブの担当者が変わった際には、そのリストを見直してください。
多くの人々が読み取れるキーは、いつの日かチャットウィンドウに貼り付けられるキーです。
届いた返信が、すぐに使用できる返信であるとは限りません。常に同じ順序を使用してください。合格したものだけを書き、残りはログに記録してください。却下された返信は証拠であり、次のデバッグ担当者はそれを見たいと思うでしょう。
HTTPステータスコードを読み取り、次に本文のokフィールドを確認してください。okがfalseに設定された200は依然として失敗した呼び出しであり、ログにはそう記録すべきです。
解凍、解析、または追加を行う前に、本文が有効なJSONであることを確認してください。不安定なランナーではダウンロードが切り捨てられる可能性があります。壊れたファイルがログに書き込まれても、誰かが開くまでは正常に見えることがあります。
前月に行があったサイトに対する空の結果は、事実ではなく質問です。アラートが発生する前に、ドメインのスペルミス、特にwww.の付与を確認してください。
キーをリポジトリシークレットSBB_KEYとして保存します。cron式は毎月の1日の06:00 UTCに実行されます。
name: monthly-link-audit
on:
schedule:
- cron: '0 6 1 * *'
workflow_dispatch: {}
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Overview (free)
run: |
curl -fsS "https://seoblogbot.com/api.php?action=overview&q=example.com" > overview.json
- name: Refdomains (2 credits)
env:
SBB_KEY: ${{ secrets.SBB_KEY }}
run: |
curl -fsS -H "Authorization: Bearer $SBB_KEY" \
"https://seoblogbot.com/api.php?action=refdomains&q=example.com&per=500" > refdomains.json
- name: Log credits
run: jq -r '._credits' refdomains.json >> credits.log| 症状 | 考えられる原因 | 最初の対応 |
|---|---|---|
| HTTP 401 | シークレットの欠落またはローテーション | シークレットを再作成し、workflow_dispatchを実行 |
| HTTP 402 | クレジットが枯渇 | アカウントページからチャージし、再実行 |
| 既知のサイトに対する空の結果 | インデックスの更新中またはドメインのタイプミス | 1日後に再試行；www.を確認 |
| 評価が数ポイント変動 | 月次更新 | 何もしない；傾向を見る |
| 評価が10以上低下 | リンクの喪失または大きな更新変更 | refdomainsを取得し、差分を取る |
同じコマンドをcrontabの行から実行します。キーをジョブのユーザーのみが読み取れる環境ファイルに保持し、ローテーションするファイルにログを記録してください。
両方のリストを取得する場合、1サイトの月次監査には4クレジットかかり、それは$0.0004です。概要呼び出しは無料です。変更がない月は、それ自体のコストのみがかかります。
チームが複数のサイトで1日10記事を投稿する場合でも、監査は記事ごとではなく、サイトごとの月次ジョブです。これによりカウントが小さく保たれ、ログが読みやすくなります。
2番目のサイトを追加する際は、ジョブを拡張するのではなくコピーしてください。ドメインごとに1つのワークフローにすることで、サイトごとのログが維持され、失敗の原因を所有者に簡単に遡ることができます。
より大きなコストは通常、当社のクレジットではなくCIプロバイダーの分です。コスト表では両方のラインを並べて表示しているため、どちらをまず最適化するかを決定できます。
最初のランで_creditsを印刷させます。どの表よりも返信を信頼してください。ゲートガイドでは、これに先行する下書き側のチェックをカバーしています。
GitHubのスケジュールはUTCで実行されるため、06:00の開始はチームごとに異なる現地時間になります。ログに誰も驚かないよう、タイムゾーンをランブックに書き込んでください。
これらの質問の多くは、ジョブを初めてスケジュールしたチームから寄せられます。
これはGoogle製品ではなく、当社の独自APIを基に構築された監査です。Googleは一般的なバックリンクAPIを公開していないため、数値は当社の独自クローラーとインデックス由来です。
可能です。ただし、月次のrefdomainsプルはすべてのビルドで実行する必要はありません。各公開時に無料の概要を実行し、有料プルは月1回実行してください。
プラグインやCDNを介して公開する場合はいえ、必要です。ゲートは下書きを確認し、監査はライブページを確認します。それぞれが他では見えない障害を検出します。
各ステップの結果を個別のファイルに書き込むため、プルが失敗しても概要は維持されます。トップから再実行するのではなく、失敗したステップから再実行してください。これにより、同じプルに対して2回請求されるのを防げます。
2つの有料プルに対してサイトごとに月4クレジットを予算に組み込み、ゲートが下書きで使用する分を加算してください。無料の概要はこの数字には追加されず、ログが実際の合計を示します。
インデックスは約1ヶ月ごとに更新されるため、日次の変化は通常ノイズです。インシデントを開く前に、今月のスナップショットを前月のスナップショットと比較してください。
_creditsが記録されている。