2022 में मैंने एक UK-based property aggregator के लिए एक programmatic site लॉन्च किया। हमने एक Google Sheets data source से लगभग 11,000 pages generate किए, सभी को live push किया, एक sitemap submit किया, और wait किया। छह हफ़्ते बाद, Google ने उनमें से लगभग 4,200 को index किया। Rankings scattered, thin, और embarrassing थे। Client ने ऐसे सवाल पूछने लगा जिनके स्पष्ट जवाब मेरे पास नहीं थे।
मैंने classic mistake कर दी थी। मैंने "generate" और "publish" को एक ही step माना। वे नहीं हैं।
वह project वह वजह था कि मैंने जो कुछ अब "quality gates" कहता हूँ उसे Seahawk में हर programmatic SEO build में बनाना शुरू किया। आज मैं किसी भी pSEO project में लगभग 15% pages को index से बाहर रखता हूँ, चाहे मुझे data के बारे में कितना भी confidence क्यों न हो। बुरे pages के लिए सज़ा के रूप में नहीं। बल्कि एक filter के रूप में जो अच्छे pages की सुरक्षा करता है।
यह actually कैसे दिखता है, और मुझे क्यों लगता है कि programmatic sites बना रहे ज़्यादातर लोग इस step को skip करके ranking potential की एक बड़ी बर्बादी कर रहे हैं।
---
प्रोग्रामेटिक संदर्भ में "Quality Gate" का वास्तव में क्या मतलब है
एक quality gate वह थ्रेशोल्ड है जिसे किसी पेज को index directive मिलने से पहले पार करना होता है। विचार सरल है। कार्यान्वयन में यह दिलचस्प हो जाता है।index directive. Simple idea. The execution is where it gets interesting.
एक मानक संपादकीय साइट के लिए, गुणवत्ता नियंत्रण संपादकीय होता है। कोई लेख को पढ़ता है और हाँ या नहीं कहता है। प्रोग्रामेटिक SEO के साथ आप एक डेटाबेस से एक दिन में 500 पेज जेनरेट कर सकते हैं। कोई उन्हें नहीं पढ़ रहा है। तो gate को mechanical होना चाहिए, और इसे प्रकाशन से पहले कॉन्फ़िगर किया जाना चाहिए, न कि बाद में जब आप देखते हैं कि Google आपके साइटमैप के आधे हिस्से को ignore कर रहा है।before you publish, not after you notice Google ignoring half your sitemap.
मैं जो gates का उपयोग करता हूँ वे लगभग हमेशा इनका संयोजन हैं:
- Content density score। केवल word count बहुत blunt है। मैं template के प्रति populated unique data fields मापता हूँ। अगर किसी page template में 14 data fields हैं और कोई दिया गया row केवल 6 को भरता है, तो वह fail हो जाता है। Word count alone is too blunt. I measure unique data fields populated per template. If a page template has 14 data fields and a given row only fills 6, it fails.
- Duplicate risk score। मैं rendered body text पर एक quick cosine similarity pass करता हूँ। जो पेज एक ही category में किसी अन्य page के लिए 0.82 से अधिक similarity स्कोर करते हैं, वे hold back हो जाते हैं। I run a quick cosine similarity pass on the rendered body text. Pages that score above 0.82 similarity to any other page in the same category get held back.
- Search intent signal। क्या इस पेज को target करने वाले keyword के पास कोई measurable search volume है? अगर Ahrefs या SEMrush primary और सभी secondary variants के लिए flat zero दिखाते हैं, तो पेज एक holding pool में जाता है। Does the keyword this page targets have any measurable search volume? If Ahrefs or SEMrush shows a flat zero for the primary and all secondary variants, the page goes into a holding pool.
- Thin content flag। जो पेज boilerplate हटाने के बाद 320 words से कम visible body text को render करते हैं, वे automatically flagged हो जाते हैं। Pages that render under 320 words of visible body text after stripping boilerplate get flagged automatically.
यह सब क्रांतिकारी नहीं है। इसे actually enforce करने का अनुशासन है।
---
हर चीज़ को इंडेक्स करना सक्रिय रूप से नुकसानदेह क्यों है
मैं विरोधाभासी तर्क जानता हूँ। "Google बस पतले पन्नों को अनदेखा कर देगा। क्या नुकसान है?"
नुकसान क्रॉल बजट है। और क्रॉल बजट बड़ी प्रोग्रामेटिक साइटों पर ज़्यादातर लोगों से कहीं ज़्यादा मायने रखता है।
Google के अपने क्रॉलिंग दस्तावेज़ इस बारे में काफ़ी सीधे हैं: Googlebot किसी साइट के क्रॉल हेल्थ सिग्नल के आधार पर क्रॉल क्षमता आवंटित करता है। अगर आपका सर्वर नियमित रूप से पतने, कम मूल्य वाले पन्ने लौटा रहा है, तो Googlebot पीछे हट जाता है। यह आपकी साइट पर कम समय बिताता है। आपके उच्च-गुणवत्ता वाले पन्नों को कम बार क्रॉल किया जाता है। is pretty direct about this: Googlebot allocates crawl capacity based on a site's crawl health signals. If your server is regularly returning thin, low-value pages, Googlebot pulls back. It spends less time on your site. Your high-quality pages get crawled less frequently.
मैंने यह 2023 की शुरुआत में Seahawk में बनाई गई एक SaaS डायरेक्टरी पर वास्तविक समय में देखा। लगभग 9,000 पन्ने, सभी इंडेक्स किए गए, जिनमें से लगभग 2,100 वास्तव में कमज़ोर थे (विरल डेटा, लगभग-डुप्लिकेट विवरण, शून्य बैकलिंक इक्विटी)। Google के Search Console में एक क्रॉल दर दिखाई दे रही थी जो आठ हफ़्तों में लगभग 40% गिरी थी। जिस क्षण हमने 2,100 पन्नों को noindex पर स्थानांतरित किया और एक अपडेट की गई sitemap जमा की, क्रॉल दर तीन सप्ताह में ठीक हो गई। कई पन्ने जो पेज 4 या 5 पर अटके हुए थे, सुधार के छह हफ़्तों के भीतर शीर्ष 15 परिणामों में चले गए।noindex and submitted an updated sitemap, crawl rate recovered within three weeks. Several pages that had been stuck on page 4 or 5 moved into the top 15 results within six weeks of the fix.
यह कोई संयोग नहीं है। यह क्रॉल बजट है जो तब काम करता है जब आप इसे बर्बाद करना बंद कर देते हैं।
---
मैं वास्तव में 15% होल्ड-बैक को कैसे संरचित करता हूँ
15% की संख्या मनमानी नहीं है, लेकिन यह पवित्र भी नहीं है। यह वह संख्या है जिस पर मैं पिछले कुछ वर्षों में शायद 60-ऑड प्रोग्रामेटिक प्रोजेक्ट्स पर गुणवत्ता गेट्स चलाने के बाद पहुँचा हूँ। कुछ प्रोजेक्ट्स 8% होल्ड बैक करते हैं। पिछले साल एक ई-कॉमर्स pSEO बिल्ड ने शुरुआती लॉन्च पर 23% होल्ड बैक किया क्योंकि सप्लायर डेटा वास्तव में अधूरा था।
यहाँ रफ़ प्रक्रिया है, शुरू से अंत तक:
- पहले पूरा डेटासेट बनाएँ। हर पेज जिसे आप अंततः पब्लिश करना चाहते हैं, जेनरेट करें। अगर आप कर सकते हैं तो डेटा स्टेज पर प्री-फिल्टर न करें। Generate every page you intend to eventually publish. Don't pre-filter at the data stage if you can avoid it.
- रेंडर टाइम पर गेट चेक चलाएँ। मैं एक Python स्क्रिप्ट का इस्तेमाल करता हूँ जो रेंडर किए गए HTML (रॉ टेम्पलेट नहीं) को कॉल करती है और वर्ड काउंट, फील्ड पॉपुलेशन रेट, और SentenceTransformers का इस्तेमाल करके एक बेसिक सिमिलेरिटी हैश चेक करती है। हर पेज पर करीब 4 सेकंड लगते हैं। I use a Python script that calls the rendered HTML (not the raw template) and checks word count, field population rate, and a basic similarity hash using SentenceTransformers. Takes about 4 seconds per page.
- हर पेज को एक स्टेटस फील्ड के साथ टैग करें। index, hold, या review। Hold का मतलब अभी के लिए noindex है। Review का मतलब है कि एक इंसान (आमतौर पर मैं, या Seahawk टीम का कोई) को 48 घंटे के भीतर इसे देखना होगा।
index,hold, orreview.Holdmeansnoindexfor now.Reviewmeans a human (usually me, or someone on the Seahawk team) needs to look at it within 48 hours. - सब कुछ पब्लिश करें, लेकिन टेम्पलेट लेवल पर डायरेक्टिव को कंट्रोल करें। सभी पेज मौजूद हैं। अगर कोई URL खोज ले तो सभी पेज एक्सेस किए जा सकते हैं। सिर्फ index पेज को robots मेटा टैग में ग्रीन लाइट मिलता है। यह मायने रखता है: आप ऐसे पेजों पर 404s नहीं चाहते जो दूसरी जगहों से लिंक या ट्रैफिक कमा सकते हैं। All pages exist. All pages are accessible if someone finds the URL. Only
indexpages get the green light in the robots meta tag. This matters: you don't want 404s on pages that might earn links or traffic from other channels. - महीने में एक बार hold pool को फिर से आकलन करें। जैसे-जैसे डेटा बेहतर होता है, पेज आगे बढ़ते हैं। कभी-कभी मैं डेटा एनरिचमेंट पास को चलाता हूँ स्पार्स फील्ड को भरने के लिए, और पहले से होल्ड किया गया पेज ऑटोमेटिकली गेट को क्लीयर कर देता है। As data improves, pages graduate. Sometimes I push a data enrichment pass to fill sparse fields, and a previously held page clears the gate automatically.
आखिरी स्टेप वह है जिसे लोग स्किप करते हैं। वे पेज को noindex करते हैं और फिर भूल जाते हैं। ये पेज रैंकिंग एसेट हो सकते हैं अगर उसके पीछे का डेटा बेहतर हो जाए। उन्हें अकेला न छोड़ें।
---
भारी लिफ्टिंग करने वाले टूल्स
मैं यहाँ टूलिंग को लेकर ढिठाई नहीं करता। जो भी आपके स्टैक के साथ साफ-साफ इंटीग्रेट हो।
सिमिलेरिटी चेक के लिए जिनका मैंने जिक्र किया, SentenceTransformers को लोकली चलाना करीब 15,000 पेजों तक बैच के लिए काफी तेज़ है इससे पहले कि मैं कुछ और स्केलेबल पर विचार करूँ। बड़े डेटासेट के लिए मैंने Pinecone को वेक्टर स्टोर के रूप में इस्तेमाल किया है ताकि एप्रॉक्सिमेट नियरेस्ट-नेबर क्वेरीज़ चलाई जा सकें, जो कम्पेरिजन टाइम को ड्रामैटिकली कम कर देता है।Pinecone as a vector store to run approximate nearest-neighbour queries, which cuts the comparison time dramatically.
लॉन्च के बाद निगरानी के लिए, मैं एक Search Console प्रॉपर्टी रखता हूँ जो विशेष रूप से इंडेक्स किए गए पूल बनाम पूरे URL इन्वेंटरी को ट्रैक करने के लिए सेगमेंटेड होती है। Screaming Frog शेड्यूल पर चलता है (मैं DigitalOcean ड्रॉपलेट पर एक cron जॉब के माध्यम से उनके CLI संस्करण का उपयोग करता हूँ) मुझे साप्ताहिक रूप से यह दिखाता है कि कौन से पेज की स्थिति बदली। अगर कोई पेज जिसे मैंने जानबूझकर noindex किया था वह किसी तरह इंडेक्स हो जाए, तो मुझे 48 घंटे के भीतर जानना चाहिए।
Ahrefs Site Audit वर्कफ़्लो में भी है, मुख्यतः कैनिबलाइजेशन सिग्नल पकड़ने के लिए। अगर दो पेज जिन्हें मैंने index के लिए मार्क किया है एक ही कीवर्ड क्लस्टर के लिए प्रतिस्पर्धा कर रहे हैं, तो वह एक gate failure है जो मुझसे छूट गई। यह होता है। ऑडिट इसे पकड़ लेता है।index are competing for the same keyword cluster, that's a gate failure I missed. It happens. The audit catches it.
---
सामान्य आपत्तियाँ (और वे क्यों अधिकतर टिकी नहीं हैं)
"क्या पेजों को रोककर रखने से मेके ट्रैफ़िक वृद्धि में देरी नहीं होगी?"
बहुत ही कम समय के लिए हल्के-फुल्के तरीके से। लेकिन एक crawl budget जो 850 सच में मजबूत पेजों की ओर इशारा करता है, वह 1,000 मिश्रित-गुणवत्ता वाले पेजों में फैली बजट से उन्हें तेजी से इंडेक्स करेगा। मैंने इसे कई प्रोजेक्ट पर मापा है। जब आप चयनात्मक होते हैं तो शुद्ध ट्रैफ़िक वक्र तीव्र होता है।
"Google स्मार्ट है कि कौन से पेज अच्छे हैं यह पता लगा सकता है।"
कभी-कभी। विश्वसनीय रूप से नहीं। और निश्चित रूप से नई डोमेन पर या सीमित अथॉरिटी वाली साइटों पर नहीं। मैं किसी क्लाइंट के ऑर्गेनिक चैनल को Google की उदारता पर नहीं लगाऊँगा।
"यह मेली पब्लिशिंग पाइपलाइन में जटिलता जोड़ता है।"
हाँ। यह करता है। एक staging चेक जो प्रत्येक पब्लिशिंग बैच से पहले लगभग 20 मिनट के लिए चलता है। वह जटिलता है। लायक है।
Seahawk के पास एक फिनटेक तुलना प्रोजेक्ट था जहाँ क्लाइंट ने गेट स्टेप जोड़ने के लिए कड़ी नापसंदगी दिखाई। वे पहले दिन ही सब कुछ इंडेक्स करवाना चाहते थे। हमने पहले दो महीने उनके तरीके से काम किया। तीसरे महीने में, जब Search Console के इम्प्रेशन कर्व को समतल देखा, तो वे गेट रेट्रोफिट के लिए राजी हो गए। noindex लॉजिक को रेट्रोफिट करने में दो हफ्ते लगे और रिकवरी देखने में एक महीना और। हमने लगभग पाँच महीने की कंपाउंडिंग खो दी। मैं उस प्रोजेक्ट के बारे में अक्सर सोचता हूँ।
---
एक पेज को "Hold" से ग्रैजुएट करने के लिए क्या तैयार बनाता है
यह समझाने लायक है क्योंकि यह सिस्टम का वह हिस्सा है जो इसे केवल एक बार के फिल्टर की जगह टिकाऊ बनाता है।
एक होल्ड किया गया पेज तब ग्रैजुएट होता है जब वह उन्हीं गेट्स को क्लियर करता है जो उसने मूल रूप से फेल किए थे, साथ ही एक अतिरिक्त चेक: इंटरनल लिंक इक्विटी। एक पेज जिसे साइट पर किसी और ने भी इंटरनली लिंक नहीं किया, भले ही उसकी कंटेंट बेहतर हो गई हो, फिर भी एक भूत ही रहता है। इंडेक्स में पेज लाने से पहले, उसे कम से कम दो इंटरनल लिंक्स की जरूरत होती है जो पहले से परफॉर्म कर रहे पेजेस से आएँ।plus one additional check: internal link equity. A page that nobody else on the site links to internally is still a ghost, even if its content has improved. Before I let a page into the index, it needs at least two internal links pointing to it from pages that are already performing.
यह एक सदाबहार लूप बनाता है। मजबूत पेजेस लिंक्स जमा करते हैं। होल्ड किए गए पेजेस तब तक इंतजार करते हैं जब तक वे साइट स्ट्रक्चर से सच में जुड़े न हों। जब वे ग्रैजुएट करते हैं, तो वे ऐसे कंटेक्स्ट में फिट होते हैं जिसे Googlebot वास्तव में फॉलो कर सकता है।
जिस तरीके से मैं इसे हैंडल करता हूँ: एक बार पेज कंटेंट गेट्स क्लियर कर दे, मैं एक जल्दी इंटरनल लिंक इंजेक्शन पास चलाता हूँ। मैं 10-15 सबसे प्रासंगिक इंडेक्स्ड पेजेस ढूँढता हूँ और एक्जैक्ट या नियर-एक्जैक्ट एंकर टेक्स्ट का इस्तेमाल करके संदर्भगत लिंक्स जोड़ता हूँ। फिर पेज को इंडेक्स के लिए फ्लिप किया जाता है। फिर मैं इसे Indexing API के जरिए सबमिट करता हूँ अगर यह ताजगी-संवेदनशील विषय है (और ज्यादातर pSEO कंटेंट के लिए, यह नहीं होता, तो मैं बस अगले क्रॉल साइकल का इंतजार करता हूँ)।index. Then I submit it via the Indexing API if it's a freshness-sensitive topic (and for most pSEO content, it isn't, so I just wait for the next crawl cycle).
---
फैसेटेड पेजेस और पैरामीटर ट्रैप्स पर एक नोट
एक विशेष स्थिति जो अपना खुद का जिक्र पाने लायक है: फैसेटेड नेविगेशन। अगर आपकी pSEO साइट URL पैरामीटर्स के जरिए पेजेस जेनरेट करती है (सोचिए /listings?city=london&bedrooms=2), तो गेट लॉजिक को कंटेंट क्वालिटी तक पहुँचने से पहले ही पैरामीटर डीडुप्लिकेशन को अकाउंट करना चाहिए।/listings?city=london&bedrooms=2), the gate logic needs to account for parameter deduplication before you even get to content quality.
फेसेटेड पैरामीटर पेज वह जगह हैं जहाँ प्रोग्रामैटिक साइटें क्रॉल बजट को सबसे आक्रामक तरीके से खर्च करती हैं। मैं rel=canonical और पैरामीटर वेरिएंट्स पर explicit noindex का संयोजन इस्तेमाल करता हूँ जो meaningfully distinct content को represent नहीं करते। इस पर Google Search Central की guidance URL parameters पर canonical reference है (कोई पन इंटेंडेड नहीं)। कोई भी faceted pSEO स्ट्रक्चर बनाने से पहले इसे ध्यान से पढ़ें।rel=canonical and explicit noindex on parameter variants that don't represent meaningfully distinct content. The Google Search Central guidance on URL parameters is the canonical reference here (no pun intended). Read it carefully before you build any faceted pSEO structure.
---
FAQ
मुझे यह कैसे decide करना चाहिए कि पेजों का कितना प्रतिशत रोकना है?
कुछ भी publish करने से पहले अपने पूरे डेटासेट पर content density audit चलाएँ। उन पंक्तियों का प्रतिशत गिनें जो एक भी gate criterion को fail करती हैं। वह आपकी starting hold-back rate है। स्वच्छ डेटासेट पर मैंने इसे 6% तक कम देखा है। scraped या third-party-sourced डेटा पर यह नियमित रूप से 20-25% होता है। 15% की वह संख्या जो मैं cite करता हूँ वह reasonably clean data वाली projects में मेरी औसत है।
क्या pages को noindex करने से वह links waste हो जाते हैं जो उन्हें मिल सकते हैं?
नहीं। वह page अभी भी exist करता है और अभी भी अपने outbound links के through PageRank pass करता है। noindex directive Google को बताता है कि page को search results में शामिल न करें, लेकिन यह page को मिलने वाले links से link equity को strip नहीं करता। वह links अभी भी domain की ओर count करते हैं। Page बस SERPs में compete नहीं कर रहा है।noindex directive tells Google not to include the page in search results, but it doesn't strip link equity from links to the page. Those links still count toward the domain. The page just isn't competing in SERPs.
Quality gates कहाँ से उपयोगी बन जाते हैं — minimum site size क्या है?
सच कहूँ तो, 300 programmatically generated pages से ऊपर कहीं भी। उससे नीचे, आप शायद pages को manually review कर सकते हैं। 300 से ऊपर, automation पहले महीने में अपने लिए payment कर लेता है।
मुझे held pages को delete करना चाहिए या बस उन्हें noindex करना चाहिए?
Noindex करें, डिलीट न करें। डिलीट किया गया पेज 404 रिटर्न करता है, जो Googlebot को बताता है कि वह कभी मौजूद था ही नहीं। Noindex किया गया पेज बाद में रैंक कर सकता है, इस बीच लिंक अर्जित कर सकता है, और सीधा ट्रैफिक स्वीकार कर सकता है। डिलीशन आखिरी उपाय है, सिर्फ उन पेजों के लिए जिनका अंतर्निहित डेटा सचमुच में ठीक नहीं किया जा सकता।
क्या यह non-English pSEO साइटों के लिए काम करता है?
Gate लॉजिक भाषा-निरपेक्ष है। समानता जांचें फ्रेंच, जर्मन, स्पेनिश में ठीक काम करती हैं। मैंने इसे एक फ्रेंच-भाषा की रियल एस्टेट pSEO प्रोजेक्ट पर चलाया है और cosine similarity स्कोर अंग्रेजी कंटेंट जितने ही विश्वसनीय थे। जो बदलता है वह है आपके थ्रेशहोल्ड कैलिब्रेशन, क्योंकि कुछ भाषाएं संरचना में स्वाभाविक रूप से अधिक दोहराव वाली होती हैं।
---
Programmatic SEO मुख्यतः एक डेटा क्वालिटी समस्या है जो SEO की पोशाक पहने हुई है। जो साइटें अच्छा परफॉर्म करती हैं वे वे नहीं हैं जिन्होंने सबसे ज्यादा पेज जेनरेट किए। वे हैं जो इस बारे में निर्दय थीं कि कौन से पेज दिखने लायक थे। 15% पीछे रखना निराशावाद नहीं है। यह सिर्फ एक ईमानदार हिसाब है कि आपने वास्तव में क्या बनाया है।