セットアップガイド
動作するカウンターには、1つのサーバールートと1つの小さなコンポーネントが必要です。このガイドでは、初期バージョンでよく見落とされる失敗状態も含めて両方を作成します。
NodeまたはPythonのバックエンドと、任意のフロントエンドフレームワークを想定しています。以下のすべてのリクエストは文書化されたAPIを呼び出し、ベースURLはブランド独自のものです：alfalinks.net/api.php。
/auth/google.phpでGoogleにサインインし、アカウントページからsk_キーをコピーしてサーバー環境に配置します。フロントエンドからはこのキーは見えません。
ドメインを検証し、APIを呼び出し、UIで必要なフィールドのみを返す、/internal/links?domain=...のようなルートを公開します。ユーザーは任意の文字列を入力するため、検証が重要です。
overviewアクションは無料なので、カウンターの最初のバージョンには課金リスクが全くありません。画面が必要とする場合にのみ、有料アクションに切り替えてください。
読み込み中、データ、利用不可。利用不可はHTTP 401、HTTP 402、ネットワーク障害をカバーし、ゼロを表示してはいけません。
インデックスは約毎月更新されます。「リンクデータは毎月更新されます」と表示するグレーのラインは、「昨日リンクを追加しました」というサポートチケットを防ぎます。
1画面で読める長さです。キャッシュはここでは単純なMapです。複数のプロセスを実行する場合は、Redisに切り替えてください。
const cache = new Map();
const MONTH = 30 * 24 * 3600 * 1000;
app.get('/internal/links', async (req, res) => {
const domain = String(req.query.domain || '').toLowerCase().trim();
if (!/^[a-z0-9.-]+\.[a-z]{2,}$/.test(domain)) return res.status(400).json({ok:false});
const hit = cache.get(domain);
if (hit && Date.now() - hit.t < MONTH) return res.json(hit.v);
const r = await fetch(`https://alfalinks.net/api.php?action=overview&q=${domain}`);
if (!r.ok) return res.status(502).json({ok:false});
const v = await r.json();
cache.set(domain, {t: Date.now(), v});
res.json(v);
});
カウンターは簡単な半分です。バッジには1つの追加呼び出しが必要です。
顧客ドメインのテーブルには、行ごとに1回呼び出すのではなく、最大2,000ドメインまで対応する1回のbulk_drリクエストを送信してください。行数に関係なく1クレジットの費用で、レスポンスは各ドメインを0-100の数値にマッピングします。この数値は、キャッシュされた概要の横に保存します。
正規化されたホスト名でドメインを一致させます。スキーム、パス、先頭のwwwを削除してください。そうしないと、行の半分が検索に失敗し、空白になります。
新規ユーザーはセットアップページを読まないことがほとんどです。彼らは、その機能が努力に見合うかどうかを確認したいと考えており、実際の数値を表示するバックリンクカウンターは、どのフォームよりも早くその答えを示します。値を先に表示してください。設定は2番目です。
無料の概要アクションにはキーが必要ないため、最初の画面ではユーザーが何も設定する前に数値を表示できます。
ドメイン1つと1回の無料コールだけで十分です。オンボーディングで自分のサイトを入力し、同じページビュー内でカウンターが表示される新規ユーザーを想像してください。その1つの数値は、ステップのリストよりもセットアップを開始するのに効果的なので、残りのセットアップはその背後に配置してください。
ユーザーは、カードやキー、2番目のフォームを要求される前に、自分が得られるものを見ます。最初のレンダリングには、ゲートのように見えるものは何もありません。
数値の直後、その前ではありません。「このサイトを毎月追跡するにはドメインを接続してください」のような短い行をカウンターの下に配置します。同じプロンプトが数値の上にある場合、ユーザーはそれをゲートとして読み、離脱します。
各セットアップステップを完了したユーザーを追跡してください。小さなファンネルは、ユーザーがどこで止まるかを示し、表記の変更は新しい機能よりもその数字を動かすことが多いです。
ハッピーパスよりもまずアンハッピーパスをテストしてください。ハッピーパスは自分自身でテストされます。
ステージング環境でキーを取り消し、カードがゼロではなく「利用不可」を表示することを確認します。次に、テスト残高を枯渇させて402をトリガーし、スキームと末尾のパスを含むドメインのような不正な入力を貼り付けて、クレジットが消費される前にバリデーターがそれを拒否することを実証してください。
短いスモークテストはCIに含めるべきです。nytimes.comに対して1回の無料overviewコールを毎晩実行することで、ルートとキーがまだ機能していることがわかります。
任意の文字列を受け付けるカウンターは、残高への開放された扉です。ルートが公開される前に、誰が何を要求できるかを決定し、誰も開かないWikiページではなく、コードにその答えを書き込んでください。
毎回3つの質問が上がります：どのドメイン、何の制限、キーはどこにあるか。
ワークスペースが権限を持つドメインのみ、および公開検索を提供することにしたもののみ。ワークスペースが2つのサイトを所有している場合、ルートはそれら2つを受け入れ、それ以外は明確なメッセージで拒否できます。これにより、1つのテナントが自分のドメインではないドメインのクレジットを消費するのを防げます。
ルートでのホスト名チェックは最小限です。これは入力がドメインのように見えることを証明しますが、ユーザーがそれを所有していることを証明するものではありません。そのため、権限リストは別のテーブルとして独自のデータベースに保持してください。
独自のストアにワークスペースごとのクォータを配置し、そこでコールをカウントしてください。こちら側の残高は単一のプリペイドプールなので、どの顧客がいくら消費したかを示すことはできません。検索ページノートは、同じ問題の公開側をカバーしています。ワークスペースが上限に達した場合は、プレーンなメッセージを返し、キャッシュが既に保持しているもので応答し続けます。
1席あたりのノートの算出に基づいて上限を選択し、プランが変更されたら再検討してください。クォータを信頼する前に、2番目のワークスペースでルートをテストしてください。
いいえ。キーはサーバーにあり、ブラウザはあなたのルートを呼び出します。この分離は、すべての課金コールがあなたが制御するコードを通過するため、クォータを可能にするものです。キーがバンドルに含まれる場合、その日に回転させ、あなたが行っていないコールについて残高ログを確認してください。一部のチームは、フロントエンドがビルド時に読み取る構成ファイルにキーを保存しますが、そのファイルはバンドルに含まれます。ビルドステップで確認できるものからキーを除外し、各リリースの前に送信されたファイルを1回確認してください。
無料アクションはキーなしで公開ページから呼び出すことができ、それがブラウザがAPIに直接通信できる唯一のケースです。
知っていることよりも少なく言う。「バックリンク」とラベル付けされたカウンターは「なぜAhrefsは異なる数値を表示するのか？」という質問を誘発し、正直な答えは、2つのクローラーがウェブの異なるスライスを見ていることです。
代わりに、ソースと月で数値にラベルを付けてください。「参照ドメイン、AlfaLinksインデックス、2026年10月」のようなものは長くなりますが、議論が始まる前にそれを終わらせ、小さなカードでも読みやすいです。
表示用に丸める。月曜日に12,481、金曜日に12,481を見るユーザーは、揺れを見るユーザーよりもツールをより信頼し、私たちの月次更新は無料でその安定性をもたらします。
隣に0-100の数値を表示したい場合は、バックリンクスコアのノートをまずお読みください。これは独自の指標なので、命名が重要です。
| シグナル | 意味 | ユーザーの表示 | あなたの対応 |
|---|---|---|---|
| HTTP 401 | キーの欠落または不正 | 「リンクデータは利用できません」 | 自身でページをテスト：デプロイバグ |
| HTTP 402 | クレジットが枯渇 | 「リンクデータは利用できません」 | USDT (TRC-20)でチャージする |
| ok: false | リクエスト拒否 | インライン再試行リンク | ドメインとアクションをログに記録 |
| タイムアウト | ネットワークの問題 | キャッシュされた値（ある場合） | 1回再試行し、その後バックオフ |
カウンターは、大きく失敗するよりも静かに失敗することがはるかに多いです。顧客が次に尋ねる質問に答えるのに十分なログを残し、個人データをログから完全に除外してください。短い行が勝ります。サポートの質問に答える1行は、書けるどのアラートよりも多くの時間を節約します。
カウンターに関するサポートスレッドのほとんどは3つの質問のいずれかなので、ログをそれらに合わせて計画してください。キーの回転の手順の横に、その3つの質問をランブックに保持してください。
アクション、ドメイン、ステータスコード、キャッシュの年齢、そして返ってきたクレジット残高。これらの5つのフィールドは、ほとんどのサポートの質問に答えます。ユーザーがなぜカウンターが古い数値を表示するのかと尋ねたとします。キャッシュの年齢とインデックスの月が、問題がキャッシュにあるのかラベルにあるのかを教えてくれます。
エラートレースを含むすべての行からAPIキーを除外してください。ロガーでマスクしてください。1行漏洩するとアカウント全体が枯渇する可能性があるためです。
3つの数字を監視してください：利用不可状態の割合、クレジット残高のトレンド、キャッシュヒット率。利用不可状態の急増は通常、キーまたは残高の問題を指します。残高の緩やかな低下は、通常、キャッシュキーが過度に具体的であることを指します。
各読み取りには異なる修正が必要なので、それらすべてにわたる単一のダッシュボードタイルが誰にも役立たないのはそのためです。3つの読み取り値を週次メモの1行に配置し、最後の値と前週からの変更を含めてください。孤立して読まれた数字は推測を誘発しますが、短いトレンドは会話を同じ事実に保ちます。
