40本の予定済み投稿、1つの不良リンクソース：ポストモーテム

根本原因、重み順

キューをブロックするものはなく、これが最初の失敗でした。ブラウザを持つ人間は5つのドメインしか確認できませんが、35ドメインなので、チェックがバッチ全体をカバーすることは決してありませんでした。

2つ目の原因はルール不足でした。不良ソースがどのようなものか誰も書き残していなかったため、すべての編集者が直感で判断し、その直感は木曜日には疲弊していました。

3つ目の原因は他の2つの背後に隠れています。スケジューリング後の結果を責任を持つ人がいませんでした。投稿は完了したように見える状態にあり、これが最も危険なキューの形態です。

3つの原因のいずれも、単独では人的な問題ではありませんでした。それぞれが誰もが見えない欠落したルールでした。それは記憶に依存して動作していました。これは修正が最も難しい種類の失敗です。なぜなら、誰かが意図的に間違ったことをしたわけではないからです。

4つ目の小さな原因は、バッチが投入された方法でした。40本の投稿を一括で読み込むと、誰も自然な一時停止を持って確認する機会がなかったため、キューは単に増大しました。解決策はシンプルです。バッチを小さなスライスに分けて読み込み、次のスライスを読み込む前に各スライスのチェックが完了するようにします。

数値がどのように見えたか

この物語のすべての数値は架空ですが、算術は現実的です。各ドラフトに1回のbulk_dr呼び出しを行う場合、40クレジット、つまり$0.004になります。

編集者の手動チェック（5ドメイン）には10分かかりました。スクリプトであれば、残りの35ドメインをそのfractionの時間でカバーできました。

金銭は物語の最も小さな部分です。真のコストは、読者がすでに確認済みの6本の投稿と、チェックであれば数秒で検出できたものを修正するために費やされた時間でした。時間は請求書に載ることはめったにありません。

ここに示すものは、Googleが投稿をどのように扱ったかを予測するものではありません。ランキングに関する主張は行わず、読者が遭遇する引用の品質のみについて述べています。この境界を維持してください。

キューのチェック方法

修正はキューが満たされる前に始まります。3つの判断により、読者が投稿を見る前に大半の投稿を捕捉できました。いずれも新しいソフトウェアを必要としません。リスト、1文、名前が必要であり、チームはこれら3つを午後の間にすべて書き出すことができます。

ドラフトあたりのホスト数を数える

誰がチェックするかを決定する前に、すべてのドラフトの外部ホストを数えます。ホストが6つのドラフトにはスクリプトが必要ですが、ホストが1つのドラフトは手動で素早く確認できます。

Semrush無料バックリンクチェッカーのタブは、ホスト1つのケースには適しています。しかし、他の40本のドラフトを処理するには不十分です。

ルールを1文で書く

「ホストが3つ以下の場合、投稿をHOLDにする」といったルールはテスト可能です。「ソースを注意深く確認する」のような曖昧なガイダンスはテストできず、疲れた編集者も適用できません。

各ルールには、設定するステータス（HOLDやPASSなど）と、それを見る人物を記載します。出口のないルールは、編集者に推測を強います。

公開前に所有者を名乗らせる

最初の投稿が読み込まれる日に、HOLDキューを責任を持つ人がいなければなりません。その名前がなければ、最初のアラートは共有チャンネルに届き、そこで待機します。

所有者はすべてのドラフトを読む必要はありません。毎日HOLDリストを確認し、各エントリに対して何を行うかを決定する必要があります。

遅すぎたシグナル

クリーンアップの前にチームには3つのシグナルがありましたが、それぞれが本来あるべき時より遅れて到着しました。シグナルは隠れていませんでした。それらは受信トレイ、キュービュー、編集者自身のノートにありましたが、誰もそれらを1か所にまとめませんでした。

読者の苦情は遅れたシグナルです

死んだ引用を発見した読者は、すでにそれを目にしています。そのメッセージは有用ですが、被害が発生してから到着するため、主要な警報にはなり得ません。

類似ソースのクラスターはより早いシグナルです

同じアウトラインからスパースなドメインを引用する11本のドラフトは、単なる確認では示されなかったパターンです。ホストでグループ化するのは安価で、読者が発見する前にパターンを特定できます。

静かなキューは健全なキューではありません

スケジューラが40本の投稿を表示し、アラートがない場合、誰も何も確認していません。沈黙は成功として読まれます。これが、完了したように見えるキューが弱いソースを隠す方法です。

シンプルなカウンターが役立ちます。今日スケジューリングされた投稿数と、今日チェックされた投稿数を数えます。これらの2つの数値が異なる場合、キューは健全ではありません。

編集者の次の行動

編集者の最初の行動は、残りのキューを引き上げ、スケジューラを停止することでした。これには数分かかりました。それが、その週で計画通りに進んだ唯一の部分でした。その後、ルールが書き留められ、所有者が名乗られるまで、スケジューラは新しいドラフトに対して閉じたままになりました。誰もそれを早期に再開しませんでした。

次に書き直しが行われました。影響を受けた各引用は、編集者が開いて読めるソースに置き換えられ、投稿は2人目の人物が確認した後にのみスケジューラに戻されました。速度は目標ではありませんでした。なぜなら、同じミスを繰り返す高速な修正は誰の役にも立たないからです。

その後、チームは自分自身のために短いメモを書きました。そこにはルール、所有者、チェックの順にリストされていました。それ以外は何もありません。そのメモは責任追及の演習ではなく、誰も無料ツールを信頼した理由を説明させられませんでした。

週末までに、チームには2つの新しい習慣と1つの古い習慣がありました。新しい習慣はホスト数とHOLDリストでした。古い習慣は、公開前に編集者がすべての引用を読むことでした。その部分は機能することがわかりました。

自身のレビューで尋ねる質問

率直になりなさい。

スケジューリングと公開の間にキューを見たのは誰ですか？実際に何を見たのですか？同僚がテストできる1文として書かれたルールはどれがトリガーされたでしょうか？答えが肩すくめである場合、次の40本の投稿は同じ結末を迎えます。今週中にその答えをランブックに書き込んでください。