APIを介してページのバックリンクを確認し、誠実にキャッシュする

短いTTLは単にクレジット残高への寄付に過ぎない理由

リンクデータに不慣れなチームは、ラック追跡ツールの習慣をコピーしがちです。習慣その1：ポジションは変動するため、1時間ごとのキャッシュ。リンクグラフはほとんど変動しません。

2クレジットのbacklinks呼び出しは$0.0002です。これは一見些細な金額に思えますが、1ページ読み込みごとに400のアクティブなワークスペースで50回の呼び出しが発生し、同じ回答に対して1時間ごとに繰り返されるとなると話は別です。

以下の計算例は、誰かの実際のトラフィックを測定したものではありません。400のワークスペース、1日あたり20回のドメインビュー、1回のビューあたり2クレジット、1時間のキャッシュがたまたま20%の確率でヒットすると仮定します。ほとんどのビューは依然としてAPIにアクセスします。月単位のキーを使用した場合、同じトラフィックでも1ドメイン・1ヶ月あたり1回しかAPIにアクセスしないため、この差がレシピの真の価値です。

キーワード調査ツールにはより新鮮なデータが必要であり、そのような用途では大手スイートが依然として最適な選択肢です。リンクの文脈においては、月次データが製品として最適です。

古いデータは製品上の選択なのか、それともバグなのか？

リンクの数値は1ヶ月前のものであっても、それが由来するインデックスに対しては正確である場合があります。画面がそれを示しているかどうかこそが真の問題です。古い数値に関するサポートチケットの多くは、ラベル付けの問題です。ラベルは通常、これらを修正します。

各数値にインデックス月を付与し、ユーザーに表示してください。日付が見えるようになると、その数値は壊れたフィードのように見えなくなり、この小さな表示はTTLを短くする以上の効果を持ちます。

リンクの数値にとって古すぎるのはどのくらいか？

当社のインデックスは月1回程度更新されるため、月初めにキャッシュされた数値は、月末にキャッシュされたものと同じインデックスを表します。月内は回答の内容は変化しません。問題は、ユーザーが「昨日」のリンクを期待したときに始まります。その場合の修正は、スコアラベルで説明されているように、明確なラベルです。

無料の概要呼び出しにはキャッシュが必要か？

概要アクションにはクレジットがかからないため、ここでのキャッシュは残高ではなく速度を保護します。サーバーは依然としてすべての往復に対して課金され、1分間に50回開かれるページはその影響を受けます。無料の回答も同じ月のキーでキャッシュに保存し、ページを高速に保ちながらプロキシを静かに保ってください。公開ルックアップのノートは、訪問者に対して同じアイデアを説明しています。

新しいリンクはキャッシュをバイパスすべきか？

通常はいいえ。バイパスは、おそらくキャッシュされたものと同じ答えに対してクレジットを消費します。顧客がそれを望む場合は、インデックス月を説明し、誰でもループで押せる開いたボタンではなく、ワークスペースごとに月1回の手動更新を提供してください。

リンクチェックにおいてキャッシュがスクレイピングに勝る理由

大規模にページバックリンクをチェックする必要があるチームは、しばしば検索エンジンに直接クエリを実行するスクリプトから始めます。それらのスクリプトは停止します。それらは1日目は安価に見えるため、チームはそれらを必要以上に長く維持しがちです。安定したAPIの前にキャッシュを配置することは、通常、より安価な設計であり、管理すべき可動部品も少なくなります。

その差は、最初の請求書よりもエンジニアリングの時間において顕著になります。キャッシュを退屈な状態に保てば、これらの時間の多くは発生しません。

自作のリンクチェッカーはなぜ常に停止するのか？

検索エンジンは自動クエリを制限するため、50件のURLで正常に動作するスクリプトでも、5万件で停止する可能性があります。リトライ、プロキシプール、ランダムな遅延はすべて、クレジット明細には現れないコストを追加し、ターゲットのレスポンスが変更された際に警告なしに失敗します。

長時間実行されるジョブを再開可能に保つにはどうすればよいでしょうか？

完了したドメインをその都度キャッシュに書き込みます。ジョブが途中で停止した場合、再開時にすでに回答が保存されているドメインはスキップされ、中断した場所から再開されます。同じ月の同一ドメインに対する料金は二重に請求されません。キーにはすでに回答が保持されているためです。

一度にバーストさせるのではなく、一定のペースでジョブを実行します。呼び出しの間隔を空けることでログが読みやすくなり、クレジット使用量の変化も説明しやすくなります。

キャッシュを使用した場合、22,000件のURLリストの費用はいくらですか？

あるクライアントのために22,000件のリンクURLを確認する必要があるとします。それらの多くは同じドメインを共有しているため、まずドメイン単位で重複を除外します。その22,000件のリンクは、数千件の一意なドメインにまで減少する可能性があります。1回のbulk_dr呼び出しで最大2,000件を処理でき、クレジットは1つで済みます。各結果をドメインと月ごとに保存すれば、このリストはURL単位のジョブではなくなります。ジョブの隣に短い計算メモを残しておけば、次の人が異なるリストサイズで再実行できるようになります。計算過程が示された数字は、単なる合計値よりも信頼しやすくなります。

ここでの関連性

キャッシュはカウント設定の中間層です。これが機能すれば、ユーザーあたりのコストが予測可能になり、ユーザーあたり比較を使ってプランの価格設定が可能になります。短いページには明確な終了が必要です。このページにもそれがあります。

ページネーションとキャッシュキー

ページネーションは誰にでも一度は痛い目を見せます。キーに含めてください。

backlinksとrefdomainsアクションは、1回の呼び出しで最大1,000行を返します。pageとperは10〜5000の間で設定でき、ディープページネーションは50,000行に制限されます。そのため、これらのパラメータを含まないキーは、すべてのリクエストに対して1ページ目を返します。

ソートもキーに含まれるべきです。DR降順からアルファベット順に切り替えたユーザーは異なるリストを期待するため、キャッシュはフルセットがすでに保存されている場合でも、新しいアップストリーム呼び出しなしでそれに応える必要があります。

簡単なテストでほとんどのキーのミスが検出できます。2ページ目をリクエストし、ソートを変更してから、キャッシュされた2ページ目がキャッシュされた1ページ目と異なるか確認します。もし異ならない場合、キーにパラメータが不足しています。早期に発見されれば、コストは数分で済みます。顧客はこれに気づきません。新しいソートオプションがキーを壊す主な理由であるため、リリース前にテストを再実行してください。リリースチェックリストに組み込んでください。

エクスポートボタンは別途計画してください：1つのバックグラウンドジョブ、1つの保存済みファイル、完了時の1つの通知です。