शुरुआती 2023 में, एक ट्रैवल क्लाइंट मेरे पास एक सपने जैसी सेटअप के साथ आया। उनके पास 14,000 लोकेशन पेजेस थे — हर शहर, हर बोरो, UK का हर पोस्टकोड डिस्ट्रिक्ट — सब होटल और रेस्तरां डेटा के डेटाबेस से ऑटो-जेनरेटेड। क्लीन टेम्पलेट। अच्छा इंटरनल लिंकिंग। और यह रैंक करता था। करीब चार महीने के लिए।
फिर मार्च 2024 का कोर अपडेट आया। उन्हें छह हफ्तों में 71% ऑर्गनिक ट्रैफिक का नुकसान हुआ। मैंने तीन हफ्ते फोरेंसिक्स करने में लगाए। कंटेंट गलत बिल्कुल नहीं था। लेकिन यह खोखला था। हर पेज वही तीन चीजें कहता था, थोड़ा शफल किए हुए ऑर्डर में, और Google ने साफ तौर पर तय किया था कि यह किसी को सर्व करने लायक नहीं है। हमने प्रॉपर क्वालिटी गेट्स के साथ पाइपलाइन को दोबारा बनाया और पाँच महीनों में पीक के 60% तक रिकवर किया। परफेक्ट नहीं। लेकिन एक सबक जो मेरे साथ रहा है।March 2024 core update hit. They lost 71% of their organic traffic in six weeks. I spent three weeks doing the forensics. The content wasn't wrong exactly. But it was hollow. Every page said the same three things in slightly shuffled order, and Google had clearly decided it wasn't worth serving to anyone. We rebuilt the pipeline with proper quality gates and recovered to 60% of peak within five months. Not perfect. But a lesson that's stayed with me.
प्रोग्रामेटिक SEO अभी भी एजेंसी टूलकिट में सबसे ताकतवर टूल्स में से एक है। लेकिन स्लॉप के लिए मार्जिन बेसिकली गायब हो गया है।
प्रोग्रामेटिक SEO पाइपलाइन में "क्वालिटी गेट" का असल मतलब क्या है
लोग इस टर्म को ढीलेढाले से फेंकते हैं, इसलिए मैं यहाँ साफ करता हूँ कि मैं इसे Seahawk पर कैसे इस्तेमाल करता हूँ।
एक quality gate एक checkpoint rule या test होता है जिससे एक page को publish होने से पहले — या published रहने के लिए — गुजरना पड़ता है। यह कोई vibe check नहीं है। यह एक specific, measurable threshold है जो या तो एक page को आगे बढ़ने देता है या उसे revision के लिए वापस भेज देता है (या पूरी तरह हटा देता है)।checkpointed rule or test that a page must pass before it gets published — or before it stays published. It's not a vibe check. It's a specific, measurable threshold that either lets a page through or sends it back for revision (or kills it entirely).
इसे 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 के पास एक अलग page को support करने के लिए काफी unique attributes हैं? — before any content is written. Data quality checks. Does this entity have enough unique attributes to support a distinct page?
- Post-generation — AI या template के content produce करने के बाद। Automated scoring length, uniqueness, entity coverage के लिए। — after the AI or template has produced content. Automated scoring for length, uniqueness, entity coverage.
- Post-publish monitoring — ongoing। Pages जो impressions या click-through rate में drop होते हैं, उन्हें human review के लिए flag किया जाता है। — ongoing. Pages that drop in impressions or click-through rate get flagged for human review.
ज्यादातर teams सिर्फ middle layer build करते हैं। इसीलिए उन्हें जलन होती है।
The Data Sufficiency Problem (ज्यादातर लोग यह Skip करते हैं)
बात यह है — सबसे बुरी programmatic content की समस्याएँ एक शब्द लिखे जाने से पहले ही शुरू हो जाती हैं। वे 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। मैं अब template को touch करने से पहले हर dataset को एक simple Python script से run करता हूँ। यह प्रत्येक record में non-null, non-generic fields की संख्या count करता है और threshold से नीचे आने वाली चीजों को flag करता है — मैं आम तौर पर minimum के रूप में 12 में से 7 use करता हूँ। जो records इसे clear नहीं करते वे एक "stub" category में जाते हैं जिन्हें noindex के साथ एक thin page मिलता है, या कोई page बिल्कुल नहीं मिलता। I now run every dataset through a simple Python script before we touch a template. It counts the number of non-null, non-generic fields per record and flags anything below a threshold — I typically use 7 out of 12 as a minimum. Records that don't clear it go into a "stub" category that gets a thin page with noindex, or no page at all.
यह glamorous नहीं है। लेकिन यह एकमात्र बदलाव है जिसका सबसे बड़ा प्रभाव हमारे builds में crawl efficiency पर पड़ा है।
Uniqueness Scoring After Generation
तो आपका data पहले gate को clear कर गया। Content generate हो गया। अब क्या?
publish मत करिए जब तक आप इसे uniqueness के लिए score न कर लें — web के विरुद्ध नहीं, बल्कि अपने own page corpus के विरुद्ध। Near-duplicate internal content ज्यादा common समस्या है, और यह वह है जिस पर आपका immediate control है।
मैं इसके लिए दो tools का combination use करता हूँ:
- [Copyscape's batch API](https://www.copyscape.com/api.php) उन pages को flag करने के लिए जो existing indexed URLs के लिए बहुत similar हैं for flagging pages that are too similar to existing indexed URLs
- एक 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" असल में क्या मायने रखता है
सच में unique सिर्फ वाक्यों को shuffle करना नहीं है। इसका मतलब है कि page ऐसा सवाल का जवाब देता है जिसका जवाब सिर्फ यह entity दे सकता है। City landing page के लिए, वह है hyper-local data — असली event listings, वास्तविक local statistics, किसी local source से specific quote। Product comparison page के लिए, ऐसे data points हैं जो इन दोनों specific products को अलग करते हैं, न कि swapped nouns वाला boilerplate intro।this entity can answer. For a city landing page, that's hyper-local data — real event listings, actual local statistics, a specific quote from a local source. For a product comparison page, it's data points that differentiate these two specific products, not a boilerplate intro with swapped nouns.
Google की अपनी guidance helpful content पर हमेशा ही यह कहती आई है। Classifier बस इसे enforce करने में aggressive हो गया। has always said this. The classifier just got aggressive about enforcing it.
Entity Coverage: वह Gate जिस पर कोई बात नहीं करता
इसे समझने में मुझे ज्यादा समय लगा, और मुझे इस बात से खीझ है।
Programmatic build में हर page nominally "about" कुछ न कुछ है — एक जगह, एक product, एक व्यक्ति, एक service। Entity और उसके attributes को content में consistently represent होना चाहिए named mentions के जरिए, semantic associations के जरिए, और structured data के जरिए। अगर ये नहीं हैं, तो page thin पढ़ा जाता है भले ही वह 800 words लंबा हो।
मैं अब हर generated page पर spaCy का उपयोग करके एक lightweight NLP pass चलाता हूँ यह check करने के लिए कि:spaCy to check that:
- Primary entity पहले 100 words में name किया गया है
- कम से कम 4 शब्दार्थी रूप से संबंधित इकाइयाँ या विशेषताएँ बॉडी में दिखाई देती हैं
- पृष्ठ में कम से कम एक तथ्य है जो इकाई के लिए अद्वितीय है (स्रोत डेटा से खींचा गया, मॉडल द्वारा हल्लुसिनेट नहीं किया गया)
वह अंतिम जाँच अभी के लिए मैनुअल है। मैं इसे स्वचालित करना चाहता हूँ लेकिन मैंने बहुत सारे गलत सकारात्मक के बिना स्केल पर क्रॉस-संदर्भ सत्यापन करने के लिए कोई विश्वसनीय तरीका नहीं बनाया है। अगर आपने इसे सुलझाया है, तो मैं सच में जानना चाहता हूँ।
Thin-Page Trap: कब Noindex करें बनाम कब Delete करें
मान लीजिए एक पृष्ठ जनरेशन से गुजरता है लेकिन फिर भी पतला लगता है। शायद डेटा विरल था, इकाई अस्पष्ट है, और आउटपुट तकनीकी रूप से अद्वितीय है लेकिन विशेष रूप से उपयोगी नहीं है।
आप क्या करते हैं?
यहाँ मेरा निर्णय वृक्ष है — सरलीकृत, लेकिन यह मोटे तौर पर है कि मैं इसके बारे में सोचता हूँ:
- अगर GSC में 90 दिनों के बाद पृष्ठ के पास शून्य सर्च इंप्रेशन हैं: निकटतम प्रासंगिक पैरेंट को डिलीट करें और 301 करें।delete and 301 to the nearest relevant parent.
- अगर पृष्ठ के पास इंप्रेशन हैं लेकिन 0.5% से कम CTR और कोई बैकलिंक नहीं हैं: noindex करें और किसी पैरेंट या कैटेगरी पृष्ठ में समेकित करें।noindex and consolidate into a parent or category page.
- अगर पृष्ठ के पास इंप्रेशन हैं, उचित CTR (1%+), लेकिन कम औसत पोजीशन (40+): रखें, लेकिन सामग्री समृद्धि के लिए प्राथमिकता दें।keep, but prioritise for content enrichment.
- अगर पेज अच्छा परफॉर्म कर रहा है तो उसे अकेले छोड़ दो और अपने आप पर शक करना बंद करो।leave it alone and stop second-guessing yourself.
मैं आपको नहीं बता सकता कि मैंने कितनी बार एजेंसी के मालिकों को उन पेजेस को noindex करते हुए देखा है जो चुपचाप कन्वर्ट कर रहे थे। जो टूटा नहीं है उसे ठीक मत करो।
Structured Data को क्वालिटी सिग्नल के रूप में (सिर्फ रिच रिजल्ट के लिए नहीं)
ज्यादातर लोग pSEO पेजेस पर स्कीमा सिर्फ रिच रिजल्ट्स के लिए जोड़ते हैं। यह ठीक है। लेकिन मैंने स्कीमा की पूर्णता को क्वालिटी गेट के तौर पर भी इस्तेमाल करना शुरू किया है।
अगर किसी पेज के स्कीमा में 30% से ज्यादा null या प्लेसहोल्डर वैल्यूज हैं, तो इससे मुझे पता चलता है कि अंतर्निहित डेटा बहुत कमजोर है और उससे कोई उपयोगी पेज नहीं बनेगा। इसलिए हमने अपनी पाइपलाइन में एक स्कीमा वैलिडेटर बनाया है — यह हम जिस भी टाइप का इस्तेमाल कर रहे हैं उसके Schema.org spec के खिलाफ रिक्वायर्ड और रिकमेंडेड प्रॉपर्टीज को चेक करता है। इस चेक में फेल होने वाले पेजेस एनरिचमेंट क्यू में वापस चले जाते हैं।Schema.org spec for whatever type we're using. Pages that fail this check go back into the enrichment queue.
क्या Google स्कीमा की पूर्णता को सीधे रैंकिंग सिग्नल के रूप में इस्तेमाल करता है? सरल तरीके से तो लगभग निश्चित रूप से नहीं। लेकिन पूर्ण और सटीक स्कीमा वाले पेजेस आमतौर पर पूर्ण और सटीक डेटा वाले पेजेस होते हैं — और ऐसे पेजेस रैंक करते हैं। सहसंबंध इतना मजबूत है कि मैं स्कीमा क्वालिटी को एक उपयोगी डायग्नोस्टिक टूल मानता हूँ, भले ही यह सीधा तंत्र न हो।those pages tend to rank. The correlation is strong enough that I treat schema quality as a useful diagnostic even if it's not the mechanism.
पब्लिश के बाद मॉनिटरिंग: वह गेट जो काम करती रहती है
क्वालिटी गेट एकबारगी चीज नहीं है। पेजेस खराब होते हैं। डेटा पुराना हो जाता है। जो पेज जनवरी में ठीक था, अक्टूबर तक पतला हो सकता है क्योंकि दुनिया आगे बढ़ गई लेकिन कंटेंट नहीं।
मैं हर बड़ी pSEO प्रॉपर्टी के लिए जिसे हम मैनेज करते हैं, महीने में एक बार Screaming Frog का इस्तेमाल करके क्रॉल करता हूँ, और फ्लैग करता हूँ:Screaming Frog on every large pSEO property we manage, flagging:
- 350 शब्दों से कम वाले पेजेस (boilerplate हटाने के बाद)
- साइट पर 3 से ज्यादा अन्य पेजों से मेल खाने वाले title tag वाले पेज
- उनकी ओर इंटरनल लिंक न होने वाले पेज (orphan रिस्क)
मैं इन्हें GSC डेटा के साथ cross-reference करता हूँ जो API के जरिए export किया गया हो — खास तौर पर उन पेजों को ढूंढता हूँ जिन्होंने पिछले 60 दिनों में impressions का 40% से ज्यादा खो दिया हो। यह intersection (Screaming Frog द्वारा flagged और GSC में घट रहा) high-priority review queue है।and declining in GSC) is the high-priority review queue.
ईमानदारी से कहूँ तो यह monitoring step वह जगह है जहाँ ज्यादातर agencies corners काटते हैं क्योंकि यह किसी स्पष्ट तरीके से billable नहीं है। लेकिन यही वह चीज है जो एक pSEO build को sustain करती है और वह जो अगले core update के बाद crumble हो जाता है के बीच फर्क करती है।
FAQ
क्या AI से content generate करना automatically Google penalty trigger करता है?
नहीं। Google ने explicitly कहा है कि AI-generated content उनकी guidelines के खिलाफ नहीं है — unhelpful content ही समस्या है, चाहे वह कैसे भी produce हुआ हो। Signal quality का है, origin का नहीं। एक manually written पेज जो thin और duplicative है, उसे भी same तरीके से treat किया जाएगा। जो मायने रखता है वह यह है कि क्या पेज genuinely user के query को alternatives से बेहतर serve करता है। अगर नहीं, तो production की method irrelevant है।unhelpful content that's the problem, regardless of how it was produced. The signal is quality, not origin. A manually written page that's thin and duplicative will get treated the same way. What matters is whether the page genuinely serves the user's query better than the alternatives. If it doesn't, the method of production is irrelevant.
एक 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 होने के बाद?
हां, लेकिन इसमें समय लगता है और यह linear नहीं है। मैंने जिस travel client का ऊपर ज़िक्र किया था, वह recover हो गया — लेकिन पांच महीने की consistent मेहनत के बाद: सबसे ख़राब pages को delete करना, mid-tier वाले को consolidate करना, top performers को enrich करना। सबसे ज़्यादा असर वाली चीज़ थी index को 14,000 pages से घटाकर क़रीब 4,200 करना। Counterintuitive है, लेकिन data यही दिखा रहा था।
एक बड़े 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 का सबसे कमज़ोर हिस्सा होता है।
---
बड़े पैमाने पर building करना आपको ख़राब तरीके से building करने की permission नहीं देता। मैंने जो gates describe किए हैं, वह एक नए pSEO project के setup time में शायद दो-तीन दिन जोड़ते हैं। विकल्प यह है कि — एक core update के बाद rebuild करना जब यह आपको wipe कर दे — इससे कहीं ज़्यादा खर्चीला है। मैं जानता हूं क्योंकि मैंने दोनों तरीके से किया है।