मेरे बैकलिंक ने कुछ नहीं लौटाया: एक त्रुटि तालिका

वह नियम जो अधिकांश मामलों को कवर करता है

नेटवर्क दोषों को पुनः प्रयास करें। 401 या 402 को कभी पुनः प्रयास न करें। पहला प्रकार सेकंडों में स्वयं ठीक हो जाता है; दूसरे के लिए एक मानव की आवश्यकता होती है, और उसे बार-बार धकेलने से केवल आपके लॉग भरे जाते हैं।

हर JSON प्रतिक्रिया में एक ok फ़ील्ड होती है, और प्रमाणीकृत प्रतिक्रियाओं में कॉल की लागत और शेष संतुलन के साथ _credits जोड़ा जाता है। HTTP स्थिति ठीक दिखने पर भी बॉडी में ok की जाँच करें।

नीचे दिए गए पुनः प्रयास के समय हमारी इंजीनियरिंग सलाह हैं, दस्तावेज़ीकृत सीमाएँ नहीं। हमारे पास मौजूद API दस्तावेज़ों में कोई दर सीमा (rate limit) प्रकाशित नहीं की गई है, इसलिए अपनी एक छत बनाएं और उसे संयमित रखें।

401 और 402 को पुनः प्रयास क्यों नहीं किया जाता

401 एक कुंजी की समस्या है, और 402 एक शेष राशि की समस्या है। न तो एक दूसरे प्रयास के बीच सेकंड के अंतर पर स्वयं ठीक होते हैं, इसलिए पुनः प्रयास केवल आपके लॉग में शोर मिलाता है और कुछ नहीं।

प्रतीक्षा करने से 402 भी ठीक नहीं होता। संतुलन वहीं रहता है जब तक कि कोई खाता पृष्ठ से इसे अपडेट न करे, इसलिए एकमात्र उपयोगी प्रतिक्रिया एक स्पष्ट संदेश और बजट के मालिक को अलर्ट भेजना है।

401 हेडर या कुंजी पैरामीटर की जाँच का हकदार है, और यह जाँच कि कुंजी बदली तो नहीं गई है। उसी गलत कुंजी को कई बार पुनः प्रयास करने से कुछ साबित नहीं होता।

एक खराब कुंजी और एक खाली संतुलन आपके डैशबोर्ड में अलग दिखते हैं। उन्हें अलग-अलग अलर्ट पर रखें, ताकि अपडेट करने वाले व्यक्ति को कुंजी टाइपो के कारण नींद न टूटे, और कुंजी बदलने वाले व्यक्ति को संतुलन के लिए पेज न किया जाए।

नेटवर्क दोष और बैकऑफ

टाइमआउट या कनेक्शन रीसेट स्वयं ठीक हो सकते हैं, इसलिए वे ही मामले हैं जिनके लिए दूसरा प्रयास करना मूल्यवान है। 1, 2, 4 और फिर 8 सेकंड प्रतीक्षा करें, थोड़ा ज़िटर जोड़ें, और चौथे प्रयास के बाद रुक जाएं।

वे समय हमारी सलाह हैं, दस्तावेज़ीकृत सीमा नहीं। अपनी छत बनाए रखें, हर पुनः प्रयास को लॉग करें, और जब पुनः प्रयास बढ़ें तो अलर्ट करें, क्योंकि बढ़ता हुआ पुनः प्रयास दर आमतौर पर अपस्ट्रीम समस्या का पहला संकेत होता है।

अपनी ओर से टाइमआउट को स्पष्ट रखें, एक नामांकित स्थिरांक में। एक अंतर्निहित डिफ़ॉल्ट जो लाइब्रेरी अपग्रेड के साथ बदल जाता है, एक आम कारण है कि एक नाइटली जॉब केवल एक मशीन पर फेल होने लगती है।

अपस्ट्रीम प्रतिक्रिया समय को विफलता दर के साथ देखें। एक धीमी प्रतिक्रिया जो कभी फेल नहीं होती, फिर भी आपके वर्करों को बांधे रख सकती है, और एक पुनः प्रयास लूप उस धीमेपन को और खराब कर देता है।

कॉल से पहले डोमेन को सामान्य करें

अधिकांश विफल कॉल्स नेटवर्क में नहीं, बल्कि इनपुट बॉक्स में शुरू होती हैं। उपयोगकर्ता जो भी कॉपी किया है वह पेस्ट करते हैं, और आपके कोड को उस API तक पहुँचने से पहले उसे एक नंगे डोमेन में बदलना होगा।

स्कीम और पथ हटाएं

स्कीम, किसी भी पथ और क्वेरी स्ट्रिंग हटा दें। एक पेस्ट किए गए आर्टिकल पता उसके होस्ट बन जाता है, और केवल होस्ट अपस्ट्रीम जाता है।

होस्ट को भी छोटे अक्षरों में करें। सफाई को एक फ़ंक्शन में रखें, ताकि एक ही नियम फॉर्म, बैच जॉब और परीक्षणों में चले।

पाँच या छह वास्तविक पेस्ट किए गए इनपुट के साथ सफाई का परीक्षण करें, जिसमें एक ट्रेलिंग स्लैश वाला और एक क्वेरी स्ट्रिंग वाला शामिल हो। वे मामले बग को सामने लाते हैं जिन्हें एक साफ उदाहरण कभी नहीं दिखाता।

www. के साथ क्या करना है, यह एक बार तय करें

www. के लिए एक नियम चुनें और एक एकल फ़ंक्शन में इसे लागू करें, ताकि एक ही साइट कभी दो वर्तनी के तहत खोजी न जाए।

नियम को फ़ंक्शन के बगल में लिखें। अगला डेवलपर जो एक अकेले www से मिलता है, तो उसे निर्णय मिलेगा, न कि एक दूसरी राय।

आप जो भी नियम चुनते हैं, उसे एक फ़ाइल में रखें और उसके लिए एक परीक्षण लिखें। परीक्षण निर्णय का रिकॉर्ड है, और यह छोटा है।

जो डोमेन नहीं हो सकता, उसे अस्वीकार करें

स्पेस या खाली लेबल वाले इनपुट को अस्वीकार करें, और फॉर्म में एक छोटा संदेश दिखाएं। एक अस्वीकृत स्ट्रिंग का कोई खर्च नहीं है, जबकि एक खराब कॉल की विफलता और एक भ्रमित उपयोगकर्ता का खर्च है।

ट्रेलिंग डॉट एक अजीब मामला है। होस्ट के अंत में एक को हटा दें और कुछ भी अन्य को अमान्य मानें।

अस्वीकृति को फ़ील्ड के बगल में दिखाएं, एक टोस्ट के रूप में नहीं जो गायब हो जाता है। एक उपयोगकर्ता जो देख सकता है कि गलत क्या था, उसे एक ही प्रयास में ठीक कर देता है।

खाली परिणाम और इंडेक्स की आयु

जब कोई अपने फॉर्म में 'check my backlink' टाइप करता है और कुछ नहीं मिलता, तो एक खाली उत्तर हमेशा त्रुटि नहीं होता। इसका अक्सर मतलब है कि डोमेन नया है, बहुत छोटा है, या बस इंडेक्स में अभी नहीं है, और स्क्रीन को यह बताना चाहिए।

एक बिल्कुल नई साइट

पिछले सप्ताह लॉन्च की गई साइट के इंडेक्स में कोई रेफरिंग डोमेन नहीं हो सकता है। 'अभी इंडेक्स नहीं हुआ' दिखाएं, इंडेक्स तारीख के साथ, और एक क्रॉस-चेक के रूप में मुफ्त overview कॉल की पेशकश करें।

उस खाली उत्तर को लंबे समय तक कैश न करें। कुछ घंटे काफी हैं, और अगली रीबिल्ड साइट को ला सकती है।

आगंतुक को बताएं कि इंडेक्स को आखिरी बार कब रीबिल्ड किया गया था, सादे शब्दों में। एक खाली उत्तर के बगल में एक तारीख लंबे संदेश से बेहतर खालीपन को समझाती है।

अपने UI में एक लाइन नोट यहाँ काफी है। कोई लाइव इंडेक्स की उम्मीद नहीं करता है, और इंडेक्स तारीख के बगल में एक सादे वाक्य को ईमानदार पढ़ा जाता है।

एक संख्या जो किसी अन्य टूल से असहमत है

अलग-अलग क्रॉलर वेब के अलग-अलग हिस्से देखते हैं। DR फ़ील्ड को एक टूल के भीतर एक स्थिति के रूप में पढ़ें, और फॉर्मूला के लिए पाठकों को DR संदर्भ की ओर इशारा करें।

संख्या के नीचे एक छोटा नोट किसी भी माप के माफी से अधिक सपोर्ट समय बचाता है।

यदि दो रीडिंग अलग हैं, तो पहले रेफरिंग-डोमेन गिनती की तुलना करें। DR फॉर्मूला सरल है, इसलिए अधिकांश असहमतियाँ गिनती तक ही सीमित होती हैं।

50,000 पर रुकने वाली पंक्तियाँ

जब एक सूची छत पर रुक जाती है, तो उत्तर API की अनुमति के लिए सही है। कट-ऑफ को लेबल करें और पेजिंग नोट्स लिंक करें, एक गहरे पेज की कोशिश करने के बजाय।

उस बिंदु के बाद गहरे पेज पुनः प्रयास नहीं हैं। वे एक अलग क्वेरी हैं, और उन्हें एक मानना ​​कैसे है कि एक लूप घंटों तक चलता है।

कट-ऑफ को एक्सपोर्ट में भी दिखाए रखें, ताकि एक महीने बाद खोली गई स्प्रेडशीट अभी भी दिखाए कि सूची को कैप किया गया था।

टेबल के बगल में पंक्ति गिनती दिखाना एक कट-ऑफ को एक दृश्यमान तथ्य बना देता है। एक पाठक जो 50,000 पंक्तियाँ देखता है, यह जानता है कि एक संकीर्ण प्रश्न मांगना है।