सामग्री पर जाएं
SEOBlogBotसाइन अप करें

रनबुक

GitHub Actions या साधारण cron के साथ पोस्ट-प्रकाशन लिंक ऑडिट

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

SEOBlogBot रिसर्च टीम ·

लो-पोली शैली में शेड्यूल व्हील, क्रेडिट टोकन और अलर्ट बेल वाले वर्कशॉप बेंच

प्रकाशन के बाद ऑडिट क्यों करें

एक गेट एक ड्राफ्ट देखता है। एक ऑडिट देखता है कि लाइव साइट वास्तव में क्या करती है। प्लगइन्स लिंक रीराइट कर सकते हैं, एडिटर साफ़ URL के ऊपर एफिलिएट रीडायरेक्ट पेस्ट कर सकते हैं, और एक CDN माइग्रेशन एक होस्ट को दूसरे में बदल सकता है। इनमें से कोई भी चीज़ ड्राफ्ट चरण में मौजूद नहीं होती, इसलिए पोस्ट-प्रकाशन रन वह पहली जगह है जहाँ यह सामने आ सकता है।

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

सामान्य उपयोग के लिए कोई आधिकारिक Google बैकलिंक चेकर API नहीं है, इसलिए टीमें एक थर्ड-पार्टी लिंक इंडेक्स का उपयोग करती हैं। यह हमारा अपना क्रॉलर है। Search Console आपके अपने लिंक्स के Google के नज़ारे को दिखाता है, और ऑडिट इसे बदलने के बजाय पूरक है।

जॉब कहाँ चलती है

ट्रिगर को लिखें। तीन सेटअप अधिकांश टीमों को कवर करते हैं, और हर एक समान कॉल चलाता है। लॉग ट्रिगर से ज़्यादा मायने रखता है, क्योंकि तारीख, URL और उपयोग किए गए क्रेडिट्स हर बार वहां आने चाहिए।

एक रिपॉजिटरी के लिए GitHub Actions

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

एक साधारण सर्वर के साथ cron

वे टीमें जो पहले से ही अपने बिल्ड के लिए एक मशीन रखती हैं, वहां समान कमांड शेड्यूल कर सकती हैं। n8n जैसी टूल उन्हें Execute Command स्टेप के माध्यम से चला सकती है, या एक crontab लाइन उन्हें सीधे चला सकती है। किसी भी स्थिति में, जॉब एक ऐसे यूजर के रूप में चलनी चाहिए जो कुंजी को पढ़ सके और कुछ नहीं।

आपके CMS से एक वेबहुक

कुछ CMS सेटअप एक पोस्ट लाइव आने पर एक वेबहुक फायर करते हैं, और वह इवेंट ऑडिट शुरू कर सकता है। चेक तब चलता है जब पोस्ट पब्लिक होती है। एक शेड्यूल्ड रन भी रखें, क्योंकि एक अकेला मिस हुआ वेबहुक एक पोस्ट को चेक किए बिना छोड़ देता है।

रनबुक, क्रम में

01

प्रकाशन पर ट्रिगर करें और 30 दिन बाद फिर से

एक रन पोस्ट लाइव आने के ठीक बाद आउटबाउंड होस्ट्स की जांच करता है। एक दूसरा रन एक महीने बाद आपके साइट के लिए refdomains पढ़ता है, क्योंकि इंडेक्स लगभग मासिक रीफ्रेश होता है और एक जल्दी पढ़ने से कुछ नया नहीं दिखेगा।

02

पहले फ्री ओवरव्यू कॉल करें

action=overview साइट के हेडलाइन नंबर बिना किसी लागत के लौटाता है। उन्हें इस रन के लिए बेसलाइन रो के रूप में स्टोर करें, उसके साथ तारीख के साथ।

03

केवल बदलाव पर पेड लिस्ट्स खींचें

यदि ओवरव्यू पिछले महीने से अलग है, तो refdomains (2 क्रेडिट) और anchors (2 क्रेडिट) कॉल करें और स्टोर की गई लिस्ट्स के खिलाफ डिफ करें।

04

लॉग में एक पंक्ति लिखें

तारीख, पोस्ट URL, किए गए कॉल, _credits बैलेंस। एक साधारण CSV जो निजी रिपो में कमिट किया गया है, काफी है।

05

केवल अपवादों पर अलर्ट

HTTP 401, HTTP 402, पिछले महीने में पंक्तियां होने वाले एक साइट के लिए खाली परिणाम, या 10 अंक या उससे अधिक की रेटिंग में गिरावट।

एक बड़े पौधे के खिलाफ दो छोटे समान पौधों को संतुलित करने वाली ब्रास स्केल

किस साइट्स का ऑडिट करना है

उस डोमेन से शुरू करें जो पोस्ट होस्ट करता है। फिर उसी ऑडिट को दो या तीन प्रतिद्वंद्वियों पर चलाएं जिनके साथ आप बेंचमार्क करना चाहते हैं। इसके लिए compare का उपयोग करें। यह 1 क्रेडिट के लिए 20 डोमेन तक लेता है, इसलिए पीयर चेक लगभग मुफ्त है।

लंबी टेल को छोड़ दें। हर अतिरिक्त साइट एक ऐसे लॉग में शोर मिलाती है जिसे एक व्यक्ति को पढ़ना होता है। बीस असंबंधित डोमेन का बेंचमार्क आपके अपने बारे में बहुत कम बताता है।

लॉग में कुंजी को बाहर रखना

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

रिपो में एक फ़ाइल के बजाय सीक्रेट स्टोर का उपयोग करें

कुंजी को अपने CI प्रोवाइडर के सीक्रेट स्टोर में पेस्ट करें, या एक एन्वायरनमेंट फ़ाइल में जहाँ केवल जॉब का यूजर पढ़ सके। इसे कभी कमिट न करें। एक स्टेप जो अपने एन्वायरनमेंट को इको करता है, उसे प्रिंट कर देगा, इसलिए एक न लिखें।

हेडर में कुंजी भेजें

Bearer हेडर कुंजी को अधिकांश एक्सेस लॉग से बाहर रखता है, क्योंकि URLs रिकॉर्ड किए जाते हैं और हेडर आमतौर पर नहीं। क्वेरी-स्ट्रिंग फॉर्म भी काम करती है, लेकिन यह हर उस प्रॉक्सी में एक कॉपी छोड़ देती है जो अनुरोध देखती है।

स्टोर को पढ़ने वाले लोगों को सीमित करें

जॉब को बनाए रखने वालों को रीड एक्सेस दें और किसी और को नहीं। जब जॉब बदलता है तो उस लिस्ट की समीक्षा करें।

एक कुंजी जिसे कई लोग पढ़ सकते हैं, एक ऐसी कुंजी है जो एक दिन चैट विंडो में पेस्ट हो जाएगी।

इसे लिखने से पहले जवाब की पुष्टि करें

आया एक जवाब अभी तक एक ऐसा जवाब नहीं है जिसे आप उपयोग कर सकें। हर बार एक ही ऑर्डर का उपयोग करें। केवल वही लिखें जो पास होता है, और शेष को लॉग करें। एक रिजेक्टेड जवाब सबूत है, और अगला व्यक्ति जो जॉब डिबग करेगा, उसे इसे देखना पसंद करेगा।

पहले स्टेटस और ok की जांच करें

HTTP स्टेटस कोड पढ़ें, फिर बॉडी में ok फ़ील्ड। ok के फॉल्स सेट होने पर भी 200 एक फेल कॉल है, और लॉग को ऐसा कहना चाहिए।

लिखने से पहले JSON पार्स करें

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

एक खाली सूची को एक प्रश्न मानें

पिछले महीने में पंक्तियां होने वाले एक साइट के लिए एक खाली परिणाम एक तथ्य नहीं, बल्कि एक प्रश्न है। किसी अलर्ट से पहले डोमेन की वर्तनी, включая एक लीडिंग www., की जांच करें।

शुरू करने के लिए एक वर्कफ़्लो फ़ाइल

कुंजी को SBB_KEY नामक एक रिपॉजिटरी सीक्रेट के रूप में स्टोर करें। क्रोन एक्सप्रेशन हर महीने के पहले दिन 06:00 UTC पर चलता है।

yaml
name: monthly-link-audit
on:
  schedule:
    - cron: '0 6 1 * *'
  workflow_dispatch: {}
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Overview (free)
        run: |
          curl -fsS "https://seoblogbot.com/api.php?action=overview&q=example.com" > overview.json
      - name: Refdomains (2 credits)
        env:
          SBB_KEY: ${{ secrets.SBB_KEY }}
        run: |
          curl -fsS -H "Authorization: Bearer $SBB_KEY" \
            "https://seoblogbot.com/api.php?action=refdomains&q=example.com&per=500" > refdomains.json
      - name: Log credits
        run: jq -r '._credits' refdomains.json >> credits.log

क्या गलत होता है और लॉग क्या दिखाता है

लक्षणसंभावित कारणपहला कदम
HTTP 401सिक्रेट गायब है या रोटेट हो गया हैसिक्रेट को फिर से बनाएं, workflow_dispatch चलाएं
HTTP 402क्रेडिट खत्म हो गएअकाउंट पेज से टॉप अप करें, फिर से चलाएं
एक ज्ञात साइट के लिए खाली पंक्तियाँइंडेक्स रिफ्रेश चल रहा है या डोमेन में टाइपो हैएक दिन बाद पुनः प्रयास करें; www. के लिए जांचें
रेटिंग में कुछ अंक की बदलावमासिक रिफ्रेशकुछ न करें; ट्रेंड पर ध्यान दें
रेटिंग में 10+ की गिरावटलिंक्स खो गए या बड़े रिफ्रेश में बदलावrefdomains खींचें और diff करें
साधारण सर्वर पर Cron

एक ही कमांड्स crontab लाइन से चलाए जाते हैं। की को एक एन्वायरनमेंट फाइल में रखें जिसकेवल जॉब के यूजर तक ही पढ़ने योग्य हो, और लॉग को एक फाइल में लिखें जिसे आप रोटेट कर सकते हैं।

पैस्टल लाइटिंग में एक भारी वजन और एक खाली डिश वाली स्टोन स्केल

लागत और उन्हें कहाँ पढ़ें

एक साइट के लिए मासिक ऑडिट की लागत 4 क्रेडिट्स है जब आप दोनों लिस्ट्स खींचते हैं, जो कि $0.0004 है। ओवरव्यू कॉल फ्री है। इसलिए बिना किसी बदलाव वाले महीने की लागत इससे अधिक नहीं होती है।

यदि आपकी टीम कई साइट्स पर दिन में दस पोस्ट्स प्रकाशित करती है, तो ऑडिट अभी भी पोस्ट के बजाय प्रति साइट एक मासिक जॉब है। यह गिनती को छोटा रखता है और लॉग को पठनीय बनाता है।

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

बड़ी लागत आमतौर पर आपके CI प्रोवाइडर के मिनट्स की होती है, न कि हमारे क्रेडिट्स की। लागत तालिका दोनों पंक्तियों को एक साथ रखती है, ताकि आप तय कर सकें कि किस एक को पहले ट्यून करना है।

पहली रन से _credits प्रिंट करने को कहें। किसी भी तालिका पर भरोसा करने के बजाय जवाब पर भरोसा करें। गेट गाइड उस ड्राफ्ट-साइड चेक को कवर करता है जो इससे पहले आता है।

GitHub शेड्यूल UTC में चलता है, इसलिए 06:00 की शुरुआत हर टीम के लिए एक अलग स्थानीय घंटे पर आती है। लॉग में किसी को भी हैरानी न हो, इसलिए समय क्षेत्र को रनबुक में लिखें।

ऑडिट चलाने के बारे में प्रश्न

इनमें से अधिकांश प्रश्न उन टीमों से आते हैं जिन्होंने अभी-अभी जॉब को पहली बार शेड्यूल किया है।

क्या यह एक google backlink checker API है?

यह हमारी अपनी API पर बनाया गया एक ऑडिट है, कोई Google उत्पाद नहीं। Google एक सामान्य backlink API प्रकाशित नहीं करता है, इसलिए संख्याएं हमारे अपने क्रॉलर और हमारे अपने इंडेक्स से आती हैं।

क्या ऑडिट हर बिल्ड के साथ चल सकता है?

यह चल सकता है, लेकिन एक मासिक refdomains पुल को हर बिल्ड पर चलने की आवश्यकता नहीं है। हर पब्लिश पर फ्री ओवरव्यू चलाएं, और मासिक एक बार पेड पुल्स चलाएं।

क्या मेरे पास गेट होने के बावजूद मुझे ऑडिट की आवश्यकता है?

हाँ, यदि आप प्लगइन्स या CDN के माध्यम से प्रकाशित करते हैं। गेट आपके ड्राफ्ट को देखता है, और ऑडिट लाइव पेज को देखता है। प्रत्येक वह विफलता पकड़ता है जिसे दूसरा नहीं देख सकता।

अगर जॉब आधे में विफल हो जाए तो?

प्रत्येक चरण के परिणाम को अपनी अलग फाइल में लिखें, ताकि एक विफल पुल ओवरव्यू को अछूता छोड़ दे। शीर्ष से पुनः चलाने के बजाय विफल चरण से पुनः चलाएं, जिससे उसी पुल के लिए दो बार पैसे देने से बचा जा सके।

प्रति साइट मुझे कितने क्रेडिट्स का बजट बनाना चाहिए?

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

कुछ दिनों के अंतर से दो रन एक-दूसरे से असहमत क्यों हैं?

इंडेक्स लगभग मासिक रूप से रिफ्रेश होता है, इसलिए दैनिक बदलाव आमतौर पर शोर होते हैं। किसी इंसिडेंट को खोलने से पहले इस महीने की स्नैपशॉट की तुलना पिछले महीने की स्नैपशॉट से करें।

रनबुक साइन-ऑफ

  • सिक्रेट मौजूद है और वर्कफ्लो एक बार हाथ से चल चुका है।
  • लॉग फाइल में तारीख, URL, कॉल्स और _credits रिकॉर्ड होते हैं।
  • किसी के पास अलर्ट चैनल की मालिकाना है।
  • जॉब मासिक डेटा को मासिक मानता है।
  • ऑडिट की स्वयं की विफलता एक व्यक्ति को पेज करती है।