Helpful Content Update को सहते हुए Programmatic SEO, जिसे HostList.io के पीछे के ऑपरेटर ने बनाया है।

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

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

मैं प्रोग्रामेटिक 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 सलाह पढ़ते हैं उसके खिलाफ है।

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

Data layer Postgres पर बैठता है, चाहे Supabase के माध्यम से हो या self-hosted हो जो टीम पहले से चला रही हो। हर facet column को properly indexed किया जाता है, क्योंकि स्केल पर filter query पर full-table scans पेज ही slow होने से पहले bottleneck बन जाते हैं। हर content type को एक dedicated entities table मिलता है जिसमें quality-gate columns actual content के साथ हों, uniqueness score, completeness percentage, last-verified timestamp। एक sitemap-eligibility view threshold से नीचे की rows को automatically filter कर देता है, इसलिए sitemap और underlying data manual curation के बिना sync रहते हैं।

टेम्पलेट चार आकार में आते हैं। प्रत्येक 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 वह हिस्सा है जिसे ज़्यादातर टीमें स्केल पर underestimate करती हैं। Sitemap प्रति template chunks में streams करता है, क्योंकि एक single sitemap.xml पचास हज़ार URLs पर maxes out करता है और ज़्यादातर programmatic projects पहले साल में ही वह limit पार कर देते हैं। Internal linking data ही से generate होता है, हर leaf अपने category, location, named competitors, और feature overlap वाली similar entities को link करता है। हर deploy पर एक build-time SEO linter pages का एक slice sample करता है और किसी भी H1 count anomaly, meta description out of range, JSON-LD validity error, या hreflang cluster integrity issue पर build को fail कर देता है। Launch के बाद, AI Overview citation tracking via Otterly या Profound हर हफ़्ते run होता है ताकि यह देख सकें कि कब एक generative search engine domain पर एक page को 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 होता है।