प्रोग्रामेटिक SEO जो Helpful Content Update को सहन करता है — HostList.io के पीछे के ऑपरेटर द्वारा बनाया गया।

मैंने HostList को 2024 की शुरुआत में एक साइड प्रोजेक्ट के रूप में शुरू किया। विचार सीधा था: इंटरनेट पर हर वेब होस्टिंग कंपनी की सूची बनाएँ, प्रत्येक को एक असली पेज और असली रिव्यू के साथ दें, और लोगों को होस्ट की तुलना करने दें जिस तरह से वे वास्तव में करना चाहते हैं। डेढ़ साल बाद साइट पर करीब अट्ठाईस हजार पेज हैं, हर एक structured data source से प्रोग्रामेटिकली जेनरेट किया गया है, और मैंने व्यक्तिगत रूप से साइट को हर Google update Helpful Content के माध्यम से जाते हुए देखा है।

जब आप एक प्रोग्रामेटिक साइट शुरू करते हैं तो कोई आपको नहीं बताता कि काम ज्यादातर संपादकीय होता है, तकनीकी नहीं। Next.js वाला हिस्सा कुछ हफ्तों में तैयार हो जाता है। Supabase schema, ingestion pipeline, streaming sitemap, schema.org emitter — यह सब हल की गई इंजीनियरिंग है। बाकी साल यह पता लगाने में जाता है कि आपकी अट्ठाईस हजार rows में से कौन सी वास्तव में index में होने के लायक है, और template में क्या जोड़ना है ताकि कोई भी row एक असली पेज की तरह पढ़े, न कि SEO野心 के साथ एक डेटाबेस प्रिंटआउट की तरह।

मैं प्रोग्रामेटिक SEO को घटाव के अनुशासन के रूप में सोचने लगा हूँ। डिफ़ॉल्ट मूव हर row को ship करना है। सही मूव सिर्फ उन rows को ship करना है जिन्होंने एक जगह अर्जित की है, और फिर उन्हें इतने संपादकीय संदर्भ में लपेटना है कि पेज एक sitemap भरने के अलावा किसी कारण के लिए मौजूद हो। इन दोनों चीजों को सही करो और Google core updates के दौरान आपको अकेला छोड़ देता है। दोनों में से कोई एक गलत करो और आप दो quarters के भीतर अपने ज्यादातर indexed pages खो दोगे।

जो आगे आता है वह playbook है जो मैं HostList पर हर दिन चलाता हूँ, client work पर उसी रूप में लागू किया जाता है। यह marketing pitch नहीं है। यह असली checklist है।

मुझे प्रोग्रामेटिक के रूप में pitch किए गए अधिकांश ideas प्रोग्रामेटिक नहीं होने चाहिए। मैं इसे कॉल पर sort करने का तरीका यह है कि dataset वास्तव में दिलचस्प है या नहीं और क्या searches वास्तव में long tail में fragmented हैं। दोनों सच होने चाहिए। अगर dataset सिर्फ SEO bait है और searches वास्तव में long tail में नहीं हो रहीं जो आप कल्पना करते हैं, तो प्रोग्रामेटिक गलत shape है और वैसे भी आगे बढ़ने से आप छह महीने के भीतर indexed pages खो दोगे।

2026 में कुछ पैटर्न काम करते हैं, और वे काफी narrow हैं। Comparison sites काम करते हैं क्योंकि searcher पहले से ही शामिल नामों को जानता है और सिर्फ एक tiebreaker चाहता है; Notion versus Linear, Stripe versus Adyen, Cloudways versus Kinsta। Location pages काम करते हैं क्योंकि local intent fundamentally fragmented है और लगभग कोई भी इसे scale पर हाथ से नहीं लिखता है। Industry directories काम करती हैं जब entity-times-filter combination real volume के साथ queries produce करता है; HostList itself इसी shape के चारों ओर बनाया गया है, जिसका कारण मुझे उन्हें चलाने से failure modes पता हैं। Glossary pages काम करते हैं जब term तकनीकी काफी हो कि web पर मौजूदा answers बुरे हों। Calculator pages काम करते हैं जब calculation itself plus underlying methodology page असली value होता है searcher के लिए।

बाकी सब कुछ जो मुझे pitch किया जाता है वह बुरा version है। "हम एक मिलियन pages generic content के साथ अपने brand के साथ चाहते हैं" version, आमतौर पर एक growth experiment के रूप में packaged होता है जो एक quarter में organic traffic को ten-x करने का है। Google particularly aggressive है इस पर late 2022 में Helpful Content Update के बाद, और de-indexing waves तब से तेज हो गई हैं। मैंने पिछले दो सालों में पाँच अलग-अलग teams को lazy programmatic play करते हुए देखा है; सभी पाँचों ने दो quarters के भीतर अपने ज्यादातर indexed pages खो दिए। मैं अब इस काम को turn down करता हूँ न कि ship करूँ, जो sales call पर असहज है लेकिन लंबे समय में सभी के लिए ज्यादा दयालु है।

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

पहला गेट यूनिक डेटा है। मान लीजिए HostList पर Cloudways की मैनेज्ड WordPress होस्टिंग के बारे में एक पेज। इसमें कम से कम तीन चीजें Cloudways के लिए खास होनी चाहिए। एक प्राइस बैंड। फीचर्स की लिस्ट। एक रीजन। एक पैरेंट कंपनी। एक यूज केस। कोई भी ऐसी चीज जो Kinsta या WP Engine के लिए भी सच नहीं है। अगर पेज में सिर्फ एक नाम, एक लोगो और एक जेनेरिक डिस्क्रिप्शन है, तो वह गेट फेल करता है। सिटमैप से रोक दिया जाता है। सोर्स में नोइंडेक्स किया जाता है। डेटा लेयर भरती रहती है जब टीम रो को समृद्ध करती है, फिर पेज इंडेक्स में वापस जाने का हकदार हो जाता है। HostList पर अभी, डेटाबेस का करीब पंद्रह प्रतिशत इसी वजह से सिटमैप से बाहर रहता है।

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

तीसरा गेट असली क्वेरी इंटेंट है। हर यूआरएल को ऐसी क्वेरी से मैप करना चाहिए जिसे कोई समझदारी से खोज रहा है, काफी वॉल्यूम के साथ कि इंडेक्स करना लायक हो। पचास मासिक सर्च से कम को टार्गेट करने वाले पेज आमतौर पर नोइंडेक्स हो जाते हैं, भले ही वे पहले दो गेट पास करें, क्योंकि वे सिटमैप को प्रदूषित करते हैं और उसी डोमेन पर मजबूत पेजों के लिए क्रॉल बजट को पतला करते हैं। थ्रेशहोल्ड इंडस्ट्री के हिसाब से बदलता है; हम हर प्रोजेक्ट में उसी वर्टिकल में आसपास की साइटों पर Search Console डेटा देखने के बाद कैलिब्रेट करते हैं।

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

जिसे मैंने रखा और बढ़ाया वह कंपेयरिजन था। नाम की गई होस्ट्स के बीच हेड-टु-हेड पेजें साइट पर सबसे ज्यादा कन्वर्ट करने वाली पेज टाइप बन गईं, यूआरएल काउंट के पांच प्रतिशत से कम होने के बावजूद सभी कन्वर्जन्स का करीब तीस प्रतिशत जेनरेट कर रहीं। मैंने कंपेयरिजन को एक अलग टेम्पलेट के रूप में जोड़ा और इसे जानबूझकर स्केल किया। मजबूत यूनिक डेटा वाली कैटेगरी पेजें भी जेनेरिक वर्जन्स से काफी बेहतर परफॉर्म करीं। सिर्फ "best WordPress hosting" नहीं, बल्कि "best WordPress hosting for WooCommerce stores under ten thousand products"। खास। क्वेरी करने योग्य। उपयोगी। जितना सीमित क्वालिफायर, पेज उतना बेहतर परफॉर्म करता था, जो ऑनलाइन आप जो SEO सलाह पढ़ते हैं उसके खिलाफ है।

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

डेटा लेयर Postgres पर बैठता है, या तो Supabase के जरिए या सेल्फ-होस्टेड, इस बात पर निर्भर करता है कि टीम पहले से क्या चला रही है। हर फेसेट कॉलम को सही तरीके से इंडेक्स किया जाता है, क्योंकि स्केल पर फिल्टर क्वेरी पर फुल-टेबल स्कैन पेज के खुद धीमे होने से पहले बॉटलनेक बन जाता है। हर कंटेंट टाइप को डेडिकेटेड एंटिटीज़ टेबल मिलता है जिसमें असली कंटेंट के साथ क्वालिटी-गेट कॉलम्स हों — यूनिकनेस स्कोर, कंप्लीटनेस प्रतिशत, लास्ट-वेरिफाइड टाइमस्टैम्प। एक सिटमैप-एलिजिबिलिटी व्यू थ्रेशहोल्ड से नीचे की रोज़ को अपने आप फिल्टर करता है, तो सिटमैप और अंतर्निहित डेटा मैनुअल क्यूरेशन के बिना सिंक में रहते हैं।

टेम्पलेट चार आकार में आते हैं। प्रत्येक entity type के लिए एक detail टेम्पलेट, जिसमें unique data के लिए explicit slots होते हैं और editorial wrapping होता है। एक comparison टेम्पलेट named entities के बीच head-to-head के लिए, FAQPage schema attached होता है, कभी AggregateRating नहीं जब तक कि first-party reviews actually exist न हों। एक category और filter टेम्पलेट CollectionPage का उपयोग करते हुए ItemList के साथ qualifying entities के, paginated होता है proper canonical handling के साथ ताकि filter combinations infinite duplicate URLs create न करें। और Article schema का उपयोग करते हुए editorial टेम्पलेट, hand-written, lower volume, higher topical weight, link graph के spine के रूप में treated होते हैं न कि leaves के।

SEO scaffolding वह हिस्सा है जिसे ज़्यादातर teams scale पर underestimate करती हैं। sitemap chunks में stream होता है per template, क्योंकि एक single sitemap.xml पचास हज़ार URLs पर max out होता है और अधिकांश programmatic projects उसे first year के अंदर pass कर जाते हैं। Internal linking data itself से generate होती है — हर leaf अपने category को, अपने location को, अपने named competitors को, और feature overlap से similar entities को link करती है। एक build-time SEO linter हर deploy पर pages के एक slice को sample करता है और किसी भी H1 count anomaly, meta description out of range, JSON-LD validity error, या hreflang cluster integrity issue पर build को fail करता है। Launch के बाद, Otterly या Profound के via AI Overview citation tracking हर हफ़्ते चलता है यह spot करने के लिए कि कब एक generative search engine domain पर एक page को cite करना शुरू करता है या cite करना बंद करता है।

ईमानदार ranges, real recent engagements से लिए गए हैं न कि sales deck पर aspirational pricing से। एक हज़ार से कम entities का एक small programmatic build छह से नौ हफ़्तों में अठारह से तीस हज़ार US dollars चलता है। एक और दस हज़ार entities के बीच mid-sized work, एक structured data import के साथ, तीस से साठ हज़ार में आठ से चौदह हफ़्तों पर चलता है। दस से एक लाख entities के बीच बड़े projects, एक custom ingestion pipeline के साथ एक external API या scraping source के विरुद्ध, पचास से नब्बे हज़ार में बारह से अठारह हफ़्तों पर चलते हैं। Ongoing operation, content refresh, और quality-gate maintenance के लिए care plans launch के बाद पाँच सौ से तीन हज़ार एक महीने चलती हैं।

हर range में data scaffolding, templates, SEO linter, और एक basic admin dashboard editorial overrides के लिए शामिल है। इनमें data acquisition itself शामिल नहीं है। Manual editorial, scraping infrastructure, third-party API costs, और original brand और design work सभी separate line items हैं। Paid traffic acquisition भी out of scope है; programmatic SEO एक organic play है और हम paid media को engagement में bundle नहीं करते। अधिकांश projects comfortably हर band के lower half में बैठते हैं; upper half genuinely complex builds के लिए मौजूद है जहाँ data ingestion या editorial layer unusually heavy होता है।