एक काम करने वाले काउंटर के लिए एक सर्वर रूट और एक छोटा कंपोनेंट चाहिए। यह गाइड दोनों बनाती है, उन फेल्योर स्टेट्स के साथ जिन्हें ज्यादातर पहली वर्जन भूल जाता है।
AlfaLinks editorial team ·
इस गाइड की सीमा
हम एक Node या Python बैकएंड और किसी भी फ्रंट-एंड फ्रेमवर्क की कल्पना करते हैं। नीचे दिया गया हर रिक्वेस्ट दस्तावेज़ API को हिट करता है, और बेस URL आपकी ब्रांड की अपनी है: alfalinks.net/api.php.
पांच चरण, उसी क्रम में जिसे हम शिप करते
01
1. की बनाएं और इसे सीक्रेट के रूप में स्टोर करें
/auth/google.php पर Google से साइन इन करें, अकाउंट पेज से sk_ की कॉपी करें और इसे अपने सर्वर एनवायरनमेंट में डालें। फ्रंट एंड इसे कभी नहीं देखता।
02
2. एक प्रॉक्सी रूट जोड़ें
कुछ ऐसा एक्सपोज़ करें जैसे /internal/links?domain=... जो डोमेन की वैलिडेशन करता है, हमारी API को कॉल करता है, और केवल उन फील्ड्स को रिटर्न करता है जो आपका UI उपयोग करता है। वैलिडेशन मायने रखता है क्योंकि यूज़र्स कुछ भी टाइप करते हैं।
03
3. फ्री एक्शन से शुरू करें
overview एक्शन की कोई लागत नहीं है, इसलिए काउंटर का पहला वर्जन बिलिंग रिस्क से पूरी तरह मुक्त है। जब एक स्क्रीन को पेड एक्शन्स की जरूरत हो, तब जाएं।
04
4. तीन स्टेट्स रेंडर करें
लोडिंग, डेटा, और अनअवेलेबल। अनअवेलेबल HTTP 401, HTTP 402 और नेटवर्क फेल्योर को कवर करता है, और इसे कभी ज़ीरो नहीं दिखना चाहिए।
05
5. फ्रेशनेस लेबल जोड़ें
हमारा इंडेक्स लगभग मासिक अपडेट होता है। 'लिंक डेटा मासिक रूप से अपडेट किया गया' लिखती एक ग्रे लाइन उस सपोर्ट टिकेट को रोकती है जो 'मैंने कल एक लिंक जोड़ा' से शुरू होता है।
प्रॉक्सी रूट, Node में
पढ़ने में इतना छोटा कि एक स्क्रीन में आ जाए। कैश यहाँ एक साधारण Map है; एक से ज्यादा प्रोसेस चलाने पर Redis में बदल दें।
js
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);
});
एक DR बैज जोड़ना जब काउंटर काम करे
काउंटर आधा आसान हिस्सा है। बैज के लिए एक अतिरिक्त कॉल चाहिए।
ग्राहक डोमेन की एक टेबल के लिए, एक-एक कॉल की जगह bulk_dr रिक्वेस्ट भेजें जिसमें 2,000 डोमेन तक हो सकते हैं। यह पंक्तियों की संख्या चाहे जो भी हो, 1 क्रेडिट का खर्च करता है, और रिस्पॉन्स हर डोमेन को उसकी 0-100 फिगर से मैप करता है, जिसे आप कैश ओवरव्यू के बगल में स्टोर करते हैं।
डोमेन को नॉर्मलाइज्ड होस्टनेम पर मैच करें। स्कीम, पाथ और एक लीडिंग www को हटा दें, वरना आधी पंक्तियां लुकअप मिस कर देंगी और खाली दिखाएंगी।
लेबल वर्डिंग के लिए स्कोर नोट्स पढ़ें, और इन कॉल्स के लिए TTL के लिए कैश रेसिपी देखें।
पहले एक वैल्यू दिखाएं, फिर सेटअप मांगें
नए यूज़र्स दुर्लभ ही सेटअप पेज पढ़ते हैं। वे देखना चाहते हैं कि फीचर मेहनत के लायक है या नहीं, और एक बैकलिंक्स काउंटर जो एक रियल फिगर दिखाता है, उससे तेज़ी से उसका जवाब देता है। वैल्यू को पहले रखें। कॉन्फ़िगरेशन दूसरे नंबर पर आता है।
क्योंकि फ्री ओवरव्यू एक्शन के लिए किसी की की जरूरत नहीं है, आपकी पहली स्क्रीन एक फिगर दिखा सकती है यूज़र द्वारा कुछ भी कॉन्फ़िगर करने से पहले।
पहले रेंडर को क्या चाहिए?
केवल एक डोमेन और एक फ्री कॉल। एक नए यूज़र की कल्पना करें जो ऑनबोर्डिंग में अपनी साइट टाइप करता है और काउंटर उसी पेज व्यू में दिखाई देता है। वह एकल फिगर सेटअप शुरू करने में चरणों की लिस्ट से ज्यादा असरदार है, इसलिए सेटअप का बाकी हिस्सा उसके पीछे रखें।
यूज़र देखता है कि उसे क्या मिलेगा, किसी के द्वारा कार्ड, की या दूसरा फॉर्म मांगे जाने से पहले। पहले रेंडर पर कुछ भी गेट जैसा नहीं दिखना चाहिए।
सेटअम प्रॉम्प्ट कहाँ होना चाहिए?
फिगर के ठीक बाद, उसके पहले नहीं। 'इसे हर माह ट्रैक करने के लिए एक डोमेन कनेक्ट करें' जैसी एक छोटी लाइन काउंटर के नीचे फिट बैठती है। अगर वही प्रॉम्प्ट फिगर के ऊपर है, तो यूज़र्स उसे गेट के रूप में पढ़ते हैं और चले जाते हैं।
ट्रैक करें कि कौन से यूज़र्स हर सेटअप स्टेप पूरा करते हैं। एक छोटा फनल दिखाता है कि लोग कहाँ रुकते हैं, और वर्डिंग में बदलाव अक्सर उस नंबर को नए फीचर से ज्यादा बदल देता है।
लॉन्च से पहले टेस्टिंग
अनहैपी पाथ्स पहले टेस्ट करें। हैपी पाथ्स खुद को टेस्ट करते हैं।
स्टेजिंग में की रिवोक करें और पुष्टि करें कि कार्ड 'unavailable' दिखाता है ज़ीरो की जगह। फिर एक टेस्ट बैलेंस ड्रेन करें ताकि 402 ट्रिगर हो, और एक मालफॉर्म्ड इनपुट पेस्ट करें जैसे कि स्कीम और ट्रेलिंग पाथ वाला डोमेन, यह साबित करने के लिए कि वैलिडेटर इसे किसी क्रेडिट खर्च होने से पहले रिजेक्ट कर देता है।
एक छोटा स्मोक टेस्ट CI में होना चाहिए। nytimes.com पर एक फ्री overview कॉल, रोज़ाना चलाया गया, आपको बताता है कि रूट और की अभी भी काम कर रहे हैं।
कौन किस डोमेन का लुकअप कर सकता है, और किस लागत पर
कोई भी स्ट्रिंग स्वीकार करने वाला काउंटर आपके बैलेंस के लिए खुला दरवाज़ा है। रूट लाइव जाने से पहले तय करें कि कौन क्या मांग सकता है, और जवाब को किसी वकी पेज की जगह कोड में लिखें जिसे कोई खोलता नहीं।
हर बार तीन सवाल आते हैं: कौन से डोमेन, क्या कैप, और की कहाँ है।
यूज़र को कौन से डोमेन टाइप करने की अनुमति होनी चाहिए?
केवल उन डोमेन को जिनका दावा वर्कस्पेस के पास है, और उन पब्लिक लुकअप्स को जिन्हें आपने ऑफर करने का चुनाव किया है। मान लें कि वर्कस्पेस दो साइट्स का मालिक है। रूट उन दो को स्वीकार कर सकता है और किसी और चीज़ को स्पष्ट संदेश के साथ रिजेक्ट कर सकता है, जिससे एक टेनेंट अपने न होने वाले डोमेन पर क्रेडिट खर्च नहीं करता।
रूट में होस्टनेम चेक न्यूनतम है। यह साबित करता है कि इनपुट एक डोमेन जैसा दिखता है, न कि यूज़र के पास उसका मालिकाना हक है, इसलिए क्लेम लिस्ट को अपने डेटाबेस में एक अलग टेबल के रूप में रखें।
आप एक यूज़र को बैलेंस ड्रेन करने से कैसे रोकते हैं?
अपने स्टोर में प्रति वर्कस्पेस एक क्वाटा डालें और वहां कॉल्स को काउंट करें। हमारी ओर से बैलेंस एक सिंगल प्रीपेड पूल है, इसलिए यह आपको नहीं बता सकता कि किस ग्राहक ने क्या खर्च किया। लुकअप पेज नोट्स उसी समस्या के पब्लिक साइड को कवर करते हैं। जब एक वर्कस्पेस अपनी कैप पर पहुंच जाता है, तो एक साधारण संदेश रिटर्न करें और कैश को उसी डेटा के साथ जवाब देने दें जो उसके पास पहले से है।
कैप पर-सीट नोट्स में अंकगणित से चुनें, अनुमान से नहीं, और जब प्लान बदले तो उसे दोबारा देखें। क्वाटा पर भरोसा करने से पहले रूट को एक दूसरे वर्कस्पेस के साथ टेस्ट करें।
क्या ब्राउज़र को कभी की रखनी चाहिए?
नहीं। की आपके सर्वर पर रहती है, और ब्राउज़र आपकी रूट को कॉल करता है। वह स्प्लिट ही वह भी है जो क्वाटा को संभव बनाता है, क्योंकि हर बिलेड कॉल आपके द्वारा नियंत्रित कोड से गुजरती है। अगर कभी की एक शिप किए गए बंडल में आ जाती है, तो उसी दिन उसे रोटेट करें और बैलेंस लॉग में चेक करें कि आपने न की गई कॉल्स। कुछ टीमों की की एक कॉन्फ़िग फाइल में स्टोर करती है जिसे फ्रंट एंड बिल्ड टाइम पर पढ़ता है, और वह फाइल बंडल में समाप्त हो जाती है। की को उस कुछ भी से बाहर रखें जिसे बिल्ड स्टेप देख सकता है, और रिलीज से पहले शिप किए गए फाइल्स को एक बार चेक करें।
फ्री एक्शन्स की बिना की के एक पब्लिक पेज से कॉल किया जा सकता है, और यही वह केस है जहां ब्राउज़र API से सीधे बात कर सकता है।
काउंटर को क्या कहना चाहिए, और क्या नहीं
जितना पता है, उससे कम कहें। 'बैकलिंक्स' लेबल वाला काउंटर सवाल खड़ा करता है 'Ahrefs एक अलग नंबर क्यों दिखाता है?', और ईमानदार जवाब यह है कि दो क्रॉलर्स वेब के दो हिस्से देखते हैं।
इसके स्रोत और महीने के साथ फिगर को लेबल करें। 'Referring domains, AlfaLinks index, October 2026' जैसी कुछ लंबी है, लेकिन यह बहस को शुरू होने से पहले खत्म कर देती है और यह एक छोटे कार्ड में अच्छी लगती है।
डिस्प्ले के लिए राउंड करें। एक यूज़र जो सोमवार को 12,481 और शुक्रवार को 12,481 देखता है, उस टूल पर ज़्यादा भरोसा करता है जिसके पास ज़िटर दिखता है, और हमारा मासिक रिफ्रेश आपको वह स्थिरता मुफ्त में देता है।
अगर आप इसके बगल में 0-100 फिगर चाहते हैं, तो पहले बैकलिंक्स स्कोर पर नोट्स पढ़ें। यह हमारा अपना मेट्रिक है, इसलिए नामकरण मायने रखता है।
फेल्योर स्टेट्स और UI क्या करता है
HTTP कोड वे हैं जो API रिटर्न करता है; UI कॉलम हमारी सलाह है।
सिग्नल
मतलब
यूज़र क्या देखता है
आप क्या करते हैं
HTTP 401
गुम या खराब की
'लिंक डेटा उपलब्ध नहीं है'
पेज खुद को डिप्लॉय करें: बग
HTTP 402
क्रेडिट खत्म हो गया
'लिंक डेटा उपलब्ध नहीं है'
USDT (TRC-20) से टॉप अप करें
ok: false
रिक्वेस्ट रिजेक्ट किया गया
इनलाइन रीट्राई लिंक
डोमेन और एक्शन लॉग करें
टाइमआउट
नेटवर्क ट्रबल
अगर आपके पास है तो कैशेड वैल्यू
एक बार रीट्राई करें, फिर बैक ऑफ करें
सपोर्ट और लॉग में काउंटर को ईमानदार रखना
काउंटर शोर मचाने से कहीं ज्यादा अक्सर चुपचाप फेल होता है। लॉग में पर्याप्त डेटा रखें ताकि ग्राहक का अगला सवाल जवाब हो सके, और पर्सनल डेटा को लॉग से पूरी तरह बाहर रखें। छोटी लाइनें जीतती हैं। एक लाइन जो सपोर्ट सवाल का जवाब देती है, किसी भी अलर्ट से ज्यादा समय बचाती है।
काउंटर के बारे में ज्यादातर सपोर्ट थ्रेड्स तीन सवालों में से एक होते हैं, इसलिए लॉग को उनके आसपास प्लान करें। उन तीन सवालों को अपने रनबुक में रखें, की रोटेट करने के चरणों के बगल में।
प्रत्येक लॉग लाइन को क्या रिकॉर्ड करना चाहिए?
एक्शन, डोमेन, स्टेटस कोड, कैश एज और बैलेंस जो वापस आया। वे पांच फील्ड ज्यादातर सपोर्ट सवालों का जवाब देते हैं। मान लें यूज़र पूछता है कि उसका काउंटर पुरानी फिगर क्यों दिखा रहा है। कैश एज और इंडेक्स महीना आपको बताते हैं कि समस्या कैश में है या लेबल में।
API की को हर लाइन से बाहर रखें, एरर ट्रेस सहित। लॉगर पर इसे मैस्क करें, क्योंकि एक लीक लाइन पूरे अकाउंट को ड्रेन कर सकती है।
आप जानते हैं कि काउंटर हर हफ्ते स्वस्थ है कैसे?
तीसरे नंबरों को देखें: अनअवेलेबल स्टेट्स का शेयर, क्रेडिट बैलेंस ट्रेड और कैश हिट रेट। अनअवेलेबल स्टेट्स में अचानक बढ़ाव आमतौर पर की या बैलेंस की समस्या की ओर इशारा करता है। बैलेंस में धीमी गिरावट आमतौर पर एक बहुत विशिष्ट कैश की ओर इशारा करती है।
प्रत्येक रीडिंग का अलग फिक्स है, इसलिए तीनों के लिए एक सिंगल डैशबोर्ड टाइल दुर्लभ ही किसी की मदद करती है। तीनों रीडिंग्स को अपनी वीकली नोट में एक लाइन पर डालें, आखिरी वैल्यू और पिछले हफ्ते से बदलाव के साथ। अकेले पढ़े गए नंबर अनुमानों को आमंत्रित करते हैं, जबकि एक छोटी ट्रेड बातचीत को एक ही तथ्यों पर रखती है।
