2023 की शुरुआत में, एक travel client मेरे पास एक सपने जैसे setup के साथ आया। उनके पास 14,000 location pages थे, UK का हर शहर, हर borough, हर postcode district, सब कुछ hotel और restaurant data के database से auto-generate था। Clean template। अच्छी internal linking। और यह rank करता था। करीब चार महीने के लिए।
फिर मार्च 2024 का कोर अपडेट आया। उन्हें छह हफ्तों में 71% ऑर्गनिक ट्रैफिक का नुकसान हुआ। मैंने तीन हफ्ते फोरेंसिक्स करने में लगाए। कंटेंट गलत बिल्कुल नहीं था। लेकिन यह खोखला था। हर पेज वही तीन चीजें कहता था, थोड़ा शफल किए हुए ऑर्डर में, और Google ने साफ तौर पर तय किया था कि यह किसी को सर्व करने लायक नहीं है। हमने प्रॉपर क्वालिटी गेट्स के साथ पाइपलाइन को दोबारा बनाया और पाँच महीनों में पीक के 60% तक रिकवर किया। परफेक्ट नहीं। लेकिन एक सबक जो मेरे साथ रहा है।
प्रोग्रामेटिक SEO अभी भी एजेंसी टूलकिट में सबसे ताकतवर टूल्स में से एक है। लेकिन स्लॉप के लिए मार्जिन बेसिकली गायब हो गया है।
प्रोग्रामेटिक SEO पाइपलाइन में "क्वालिटी गेट" का असल मतलब क्या है
लोग इस टर्म को ढीलेढाले से फेंकते हैं, इसलिए मैं यहाँ साफ करता हूँ कि मैं इसे Seahawk पर कैसे इस्तेमाल करता हूँ।
Quality gate एक checkpointed rule या test है जो एक page को publish होने से पहले, या published रहने से पहले pass करना होता है। यह एक vibe check नहीं है। यह एक specific, measurable threshold है जो या तो page को आगे बढ़ाता है या उसे revision के लिए वापस भेजता है (या उसे पूरी तरह खत्म कर देता है)।
इसे content के लिए continuous integration की तरह समझो। Developers ऐसा code push नहीं करते जो unit tests fail करे। तुम्हें ऐसे pages publish नहीं करने चाहिए जो content tests fail करें। यह analogy perfect नहीं है, लेकिन useful होने के लिए काफी करीब है।
Quality gates के बिना एक pipeline बस एक content spam machine है। और 2024 में, Google का classifier उसे scale पर spot करने के लिए काफी अच्छा है।
तीन Layers जहाँ Gates को होना चाहिए
मैं gates को तीन moments पर structure करता हूँ:
- Pre-generation, किसी भी content लिखे जाने से पहले। Data quality checks। क्या इस entity के पास एक distinct page को support करने के लिए काफी unique attributes हैं?
- Post-generation, AI या template के content produce करने के बाद। Length, uniqueness, entity coverage के लिए automated scoring।
- Post-publish monitoring, चलता रहता है। Pages जो impressions या click-through rate में गिरते हैं, उन्हें human review के लिए flag किया जाता है।
ज्यादातर teams सिर्फ middle layer build करते हैं। इसीलिए उन्हें जलन होती है।
The Data Sufficiency Problem (ज्यादातर लोग यह Skip करते हैं)
बात यह है, programmatic content की सबसे बुरी problems एक भी word लिखे जाने से पहले शुरू हो जाती हैं। वह spreadsheet में शुरू होती हैं।
अगर आपके source data में प्रति entity 12 attributes हैं और उनमें से 9 आपके 80% records में identical हैं, तो आप चाहे जितने clever prompts use करें, near-duplicate pages ही produce करेंगे। मैंने यह Seahawk में 2021 में एक solicitors directory पर सीखा। हमारे पास 6,000 law firm entries थीं। उनमें से लगभग 4,200 के पास name, postcode और practice area के अलावा कुछ distinctive नहीं था। हमने सभी 6,000 publish किए। Google ने शायद 1,800 को index किया।
Pre-generation gate: data richness scoring। मैं अब हर dataset को एक simple Python script के through run करता हूँ template को touch करने से पहले। यह हर record में non-null, non-generic fields की संख्या count करता है और threshold से कम कुछ भी flag करता है, मैं आमतौर पर 12 में से 7 को minimum के रूप में use करता हूँ। जो records यह clear नहीं करते, वे एक "stub" category में जाते हैं जो एक thin page के साथ आता है noindex के साथ, या कोई page नहीं।
यह glamorous नहीं है। लेकिन यह एकमात्र बदलाव है जिसका सबसे बड़ा प्रभाव हमारे builds में crawl efficiency पर पड़ा है।
Generation के बाद Uniqueness Scoring
तो आपका data पहले gate को clear कर गया। Content generate हो गया। अब क्या?
Publish मत करो जब तक आप इसे uniqueness के लिए score न कर दो, web के खिलाफ नहीं, बल्कि अपने खुद के page corpus के खिलाफ। Near-duplicate internal content ज्यादा common problem है, और यह वह है जो तुरंत तुम्हारे नियंत्रण में है।
मैं इसके लिए दो tools का combination use करता हूँ:
- [Copyscape's batch API](https://www.copyscape.com/api.php) उन pages को flag करने के लिए जो existing indexed URLs के लिए बहुत similar हैं
- एक custom cosine similarity script (Python में sentence-transformers का use करते हुए) जो हर नए page को same template family में 50 सबसे structurally similar pages के विरुद्ध score करता है
मेरी threshold 0.82 cosine similarity है। इससे ऊपर कुछ भी manual review के लिए जाता है। 0.91 से ऊपर कुछ भी kill हो जाता है या भारी रीवर्क होता है।
हाँ, यह pipeline में friction जोड़ता है। अच्छा है। Friction ही तो मकसद है।
"Unique" असल में क्या मायने रखता है
Genuinely unique का मतलब सिर्फ shuffled sentences नहीं है। इसका मतलब है कि page एक ऐसा सवाल जवाब देता है जो केवल यह entity जवाब दे सकता है। एक city landing page के लिए, वह hyper-local data है, real event listings, actual local statistics, local source से एक specific quote। एक product comparison page के लिए, वह data points हैं जो इन दोनों specific products को differentiate करते हैं, न कि boilerplate intro with swapped nouns।
Google की अपनी guidance helpful content पर हमेशा ही यह कहती आई है। Classifier बस इसे enforce करने में aggressive हो गया।
Entity Coverage: वह Gate जिस पर कोई बात नहीं करता
इसे समझने में मुझे ज्यादा समय लगा, और मुझे इस बात से खीझ है।
एक प्रोग्रामेटिक बिल्ड के हर पेज का नाम की दृष्टि से कुछ न कुछ "बारे में" होता है — कोई जगह, कोई प्रोडक्ट, कोई व्यक्ति, कोई सेवा। इस एंटिटी और इसकी विशेषताओं को कंटेंट में सुसंगत तरीके से नाम के जरिए, सिमांटिक एसोसिएशन के माध्यम से, और स्ट्रक्चर्ड डेटा से दर्शाया जाना चाहिए। अगर ऐसा नहीं है, तो पेज थिन दिखता है, चाहे वह 800 शब्दों लंबा हो।
मैं अब हर generated page पर spaCy का उपयोग करके एक lightweight NLP pass चलाता हूँ यह check करने के लिए कि:
- Primary entity पहले 100 words में name किया गया है
- कम से कम 4 शब्दार्थी रूप से संबंधित इकाइयाँ या विशेषताएँ बॉडी में दिखाई देती हैं
- पृष्ठ में कम से कम एक तथ्य है जो इकाई के लिए अद्वितीय है (स्रोत डेटा से खींचा गया, मॉडल द्वारा हल्लुसिनेट नहीं किया गया)
वह अंतिम जाँच अभी के लिए मैनुअल है। मैं इसे स्वचालित करना चाहता हूँ लेकिन मैंने बहुत सारे गलत सकारात्मक के बिना स्केल पर क्रॉस-संदर्भ सत्यापन करने के लिए कोई विश्वसनीय तरीका नहीं बनाया है। अगर आपने इसे सुलझाया है, तो मैं सच में जानना चाहता हूँ।
Thin-Page Trap: कब Noindex करें बनाम कब Delete करें
मान लीजिए एक पृष्ठ जनरेशन से गुजरता है लेकिन फिर भी पतला लगता है। शायद डेटा विरल था, इकाई अस्पष्ट है, और आउटपुट तकनीकी रूप से अद्वितीय है लेकिन विशेष रूप से उपयोगी नहीं है।
आप क्या करते हैं?
यहां मेरा डिसीजन ट्री है, सरल बनाया हुआ, लेकिन मैं इसके बारे में कमोबेश इसी तरह सोचता हूं:
- अगर GSC में 90 दिनों के बाद पृष्ठ के पास शून्य सर्च इंप्रेशन हैं: निकटतम प्रासंगिक पैरेंट को डिलीट करें और 301 करें।
- अगर पृष्ठ के पास इंप्रेशन हैं लेकिन 0.5% से कम CTR और कोई बैकलिंक नहीं हैं: noindex करें और किसी पैरेंट या कैटेगरी पृष्ठ में समेकित करें।
- अगर पृष्ठ के पास इंप्रेशन हैं, उचित CTR (1%+), लेकिन कम औसत पोजीशन (40+): रखें, लेकिन सामग्री समृद्धि के लिए प्राथमिकता दें।
- अगर पेज अच्छा परफॉर्म कर रहा है तो उसे अकेले छोड़ दो और अपने आप पर शक करना बंद करो।
मैं आपको नहीं बता सकता कि मैंने कितनी बार एजेंसी के मालिकों को उन पेजेस को noindex करते हुए देखा है जो चुपचाप कन्वर्ट कर रहे थे। जो टूटा नहीं है उसे ठीक मत करो।
Structured Data को क्वालिटी सिग्नल के रूप में (सिर्फ रिच रिजल्ट के लिए नहीं)
ज्यादातर लोग pSEO पेजेस पर स्कीमा सिर्फ रिच रिजल्ट्स के लिए जोड़ते हैं। यह ठीक है। लेकिन मैंने स्कीमा की पूर्णता को क्वालिटी गेट के तौर पर भी इस्तेमाल करना शुरू किया है।
अगर किसी पेज के स्कीमा में 30% से ज्यादा null या प्लेसहोल्डर वैल्यूज हैं, तो यह मुझे बताता है कि अंतर्निहित डेटा इतना विरल है कि कोई उपयोगी पेज बनाया ही नहीं जा सकता। तो हमने अपने पाइपलाइन में एक स्कीमा वेलिडेटर बनाया है, जो रिक्वायर्ड और रिकमेंडेड प्रॉपर्टीज को Schema.org स्पेक के विरुद्ध चेक करता है जो भी टाइप हम इस्तेमाल कर रहे हों। जो पेज इस चेक में फेल हो जाते हैं, वे एनरिचमेंट क्यू में वापस चले जाते हैं।
क्या Google स्कीमा पूर्णता को डायरेक्ट रैंकिंग सिग्नल के रूप में इस्तेमाल करता है? लगभग निश्चित रूप से किसी सरल तरीके में नहीं। लेकिन कंप्लीट, सटीक स्कीमा वाले पेज आमतौर पर कंप्लीट, सटीक डेटा वाले पेज होते हैं, और वे पेज रैंक करते हैं। कोरिलेशन इतना मजबूत है कि मैं स्कीमा क्वालिटी को एक उपयोगी डायग्नोस्टिक मानता हूं, भले ही यह मैकेनिज्म न हो।
पब्लिश के बाद मॉनिटरिंग: वह गेट जो काम करती रहती है
क्वालिटी गेट एकबारगी चीज नहीं है। पेजेस खराब होते हैं। डेटा पुराना हो जाता है। जो पेज जनवरी में ठीक था, अक्टूबर तक पतला हो सकता है क्योंकि दुनिया आगे बढ़ गई लेकिन कंटेंट नहीं।
मैं हर बड़ी pSEO प्रॉपर्टी के लिए जिसे हम मैनेज करते हैं, महीने में एक बार Screaming Frog का इस्तेमाल करके क्रॉल करता हूँ, और फ्लैग करता हूँ:
- 350 शब्दों से कम वाले पेजेस (boilerplate हटाने के बाद)
- साइट पर 3 से ज्यादा अन्य पेजों से मेल खाने वाले title tag वाले पेज
- उनकी ओर इंटरनल लिंक न होने वाले पेज (orphan रिस्क)
मैं इन्हें GSC डेटा के साथ क्रॉस-रेफरेंस करता हूं जो API के माध्यम से एक्सपोर्ट किया जाता है, विशेषकर उन पेजों को खोज रहा हूं जिन्होंने पिछले 60 दिनों में 40% से ज्यादा इंप्रेशन खो दिए हैं। यह इंटरसेक्शन (Screaming Frog के माध्यम से फ्लैग किया गया और GSC में घट रहा है) हाई-प्रायोरिटी रिव्यू क्यू है।
ईमानदारी से कहूँ तो यह monitoring step वह जगह है जहाँ ज्यादातर agencies corners काटते हैं क्योंकि यह किसी स्पष्ट तरीके से billable नहीं है। लेकिन यही वह चीज है जो एक pSEO build को sustain करती है और वह जो अगले core update के बाद crumble हो जाता है के बीच फर्क करती है।
FAQ
क्या AI से content generate करना automatically Google penalty trigger करता है?
नहीं। Google ने स्पष्टता से कहा है कि AI-जेनरेटेड कंटेंट उनकी गाइडलाइन्स के खिलाफ नहीं है, यह अनहेल्पफुल कंटेंट है जो समस्या है, इसे कैसे बनाया गया इससे कोई फर्क नहीं पड़ता। सिग्नल क्वालिटी है, ऑरिजिन नहीं। मैन्युअल रूप से लिखा गया पेज जो थिन और डुप्लिकेटिव है, उसे वही ट्रीटमेंट दिया जाएगा। जो मायने रखता है वह यह है कि क्या पेज यूजर की क्वेरी को विकल्पों से बेहतर तरीके से सर्व करता है। अगर नहीं करता, तो प्रोडक्शन की विधि प्रासंगिक नहीं है।
एक programmatic build के लिए कितने पेज "too many" हैं इससे पहले कि Google को suspicious लगने लगे?
कोई hard number नहीं है, और कोई भी specific figure जो आपने online देखी है वह बनी हुई है। जो मायने रखता है वह indexed pages का ranking pages से ratio है। अगर आपके पास 20,000 पेज हैं और 400 impressions ले रहे हैं, तो यह एक crawl budget और quality problem है। Google बाकी को ignore करने लगेगा। मैं 20,000 mediocre pages की जगह 3,000 strong pages publish करना ज्यादा पसंद करता हूँ। Index coverage rate वह metric है जिसे watch करना चाहिए, absolute page count नहीं।
क्या मैं AI slop penalty से recover कर सकता हूँ एक बार hit होने के बाद?
हां, लेकिन इसमें समय लगता है और यह लीनियर नहीं है। शुरुआत में मेंशन किया गया ट्रैवल क्लाइंट रिकवर हो गया, लेकिन इसमें पांच महीने का सुसंगत काम लगा: सबसे खराब पेजों को डिलीट करना, मिड-टायर वालों को कंसोलिडेट करना, टॉप परफॉर्मर्स को एनरिच करना। सबसे ज्यादा असर डालने वाली एक्शन इंडेक्स को 14,000 पेजों से घटाकर लगभग 4,200 पर लाना था। काउंटरइंटुइटिव है, लेकिन यह डेटा से पता चला है।
एक बड़े build में यह identify करने का सबसे तेज़ तरीका क्या है कि कौन से pages "slop" हैं?
अपना पूरा GSC performance data पिछले 16 हफ़्तों का निकालें। उन pages के लिए filter करें जिनके 0 से ज़्यादा impressions हों लेकिन 0.8% से कम CTR हो और average position 35 से ख़राब हो। यह cohort आपकी problem set है। इसे word count और internal link count के साथ cross-reference करें। low-CTR, low-word-count, और orphaned pages के overlap को almost हमेशा किसी भी programmatic build का सबसे कमज़ोर हिस्सा होता है।
---
स्केल पर बिल्ड करना आपको खराब तरीके से बिल्ड करने की अनुमति नहीं देता। मेंशन किए गए गेट्स एक नए pSEO प्रोजेक्ट में शायद दो से तीन दिन का सेटअप टाइम जोड़ते हैं। विकल्प यह है कि कोई कोर अपडेट आपको पूरी तरह खत्म करने के बाद रीबिल्ड करो, जो उससे ज्यादा खर्च होता है। मैं जानता हूं क्योंकि मैंने दोनों तरीकों से किया है।