डायरेक्टरी वेबसाइटें जो 28,000 पेजों को थिन-कंटेंट पेनल्टी के बिना संभाल लेती हैं।

किसी भी निर्देशिका संरचना के लिए, एक सुव्यवस्थित डेटा स्रोत दिया जाए। पिछले दो साल में, जो पैटर्न मैंने ship किए हैं, वे चार व्यापक प्रकारों में विभाजित होते हैं, और अधिकांश क्लाइंट परियोजनाएँ इनमें से किसी एक का कोई flavour हैं।

इंडस्ट्री डायरेक्टरीज़ किसी वर्टिकल में कंपनियों को सूचीबद्ध करती हैं, जिन्हें कैटेगरी, लोकेशन, साइज़ और फीचर सेट से विभाजित किया जाता है। HostList.io वह canonical उदाहरण है जिसे मैं खुद चलाता हूँ—लगभग अट्ठाईस हज़ार वेब होस्टिंग कंपनियों को होस्टिंग टाइप, रीजन, प्राइस बैंड और यूज़ केस से स्लाइस किया गया है। खरीदार प्रोवाइडर खोजते हैं, प्रोवाइडर को ट्रैफिक मिलता है, और डायरेक्टरी खुद स्पॉन्सर्ड प्लेसमेंट, एफिलिएट लिंक्स, या पेड प्रीमियम लिस्टिंग्स के ज़रिए पैसे बनाती है—यह इस बात पर निर्भर करता है कि वर्टिकल के लिए क्या उपयुक्त है।

लोकल और लोकेशन डायरेक्टरीज़ दूसरा पैटर्न हैं। रेस्तरां गाइड्स, पब गाइड्स, डेंटिस्ट डायरेक्टरीज़, कॉन्ट्रैक्टर डायरेक्टरीज़। हर लिस्टिंग LocalBusiness schema के साथ आती है, जिसमें geo कोऑर्डिनेट्स, ऑपनिंग ऑवर्स और रेटिंग्स होती हैं (जहाँ आपको डेटा राइट्स हैं)। प्रोग्रामैटिक सिटी-एंड-कैटेगरी पेजेस—"Manchester में सर्वश्रेष्ठ Italian रेस्तरां" या "Stoke Newington में पब्स"—इन साइट्स पर अधिकतर long-tail SEO सर्फेस एरिया देते हैं।

टूल और सॉफ्टवेयर डायरेक्टरीज़ किसी कैटेगरी में सॉफ्टवेयर प्रोडक्ट्स सूचीबद्ध करती हैं। CRM टूल्स। प्रोजेक्ट मैनेजमेंट ऐप्स। No-code प्लेटफॉर्म्स। AI टूल्स। इन साइट्स पर ट्रैफिक इंजन comparison पेजेस है—Notion बनाम Linear बनाम ClickUp—और feature-matrix पेजेस हैं, जहाँ सर्चर पहले ही नाम जानता है और बस एक tiebreaker चाहता है।

People और service directories चौथा पैटर्न हैं। Agencies। Freelancers। Consultants। Photographers। Lawyers। इसका चुनौती यह है कि अधिकांश people directories मर जाती हैं क्योंकि listings stale हो जाती हैं और कोई उन्हें update नहीं करता। हम project के पहले दिन से ही expiry workflows और self-service profile editing build करते हैं बजाय इसके बाद retrofit करने के।

HostList.io वह directory है जिसे मैंने solo build किया है पूरे web hosting industry को catalogue करने के लिए। लगभग अठ्ठाईस हजार hosting company pages, spring 2024 से live, उसी Next.js plus Supabase plus Vercel stack पर जिसे हम अब client directory builds के लिए use करते हैं।

HostList जो करता है वह हर वेब होस्टिंग कंपनी को कैटलॉग करना है जिसे हम verify कर सकते हैं, टाइप से विभाजित—shared, VPS, managed WordPress, cloud, dedicated, reseller—रीजन, प्राइस बैंड और यूज़ केस से। specific होस्ट्स के बीच comparison पेजेस हैं, हर सेगमेंट के लिए कैटेगरी पेजेस, एक search और filter UI जो बीस-आठ-हज़ार-पंक्ति डेटासेट को क्वेरी latency के बिना हैंडल करता है, हर लिस्टिंग पर schema markup, और एक streaming sitemap क्योंकि URL कवंट पहले ही उस जगह पास हो चुका है जहाँ single sitemap.xml hold नहीं कर सकता।

इसे run करने से तीन सीख अब हर client directory build को shape देती हैं। पहली, data quality पूरा खेल है। तीन unique data points वाले pages entity name से beyond survive करते हैं Google updates; केवल name और generic description वाले pages de-indexed हो जाते हैं। दूसरी, internal linking इस scale पर backlinks से अधिक matter करती है। Listings, categories, और comparison pages के बीच link graph decide करता है कि किन leaf pages को indexed रहने के लिए बार-बार crawl किया जाता है। तीसरी, programmatic मतलब lazy नहीं है। हर page को exist करने का एक कारण चाहिए, और "हमारे पास database में एक row है" एक कारण नहीं है।

हमने database का लगभग पंद्रह प्रतिशत index से रोका क्योंकि unique-data threshold उन rows पर meet नहीं हुआ था। हमने category pages cut किए जिनके पास पाँच से कम strong listings थीं क्योंकि वे thin पढ़ते थे भले ही underlying schema सही था। हमने named competitors के बीच comparison pages जोड़े एक अलग page type के रूप में, और वह template site पर सबसे अधिक converting traffic में से कुछ बन गया। यही playbook अब हर directory पर standard है जिसे हम clients के लिए ship करते हैं।

अधिकांश directories मर जाती हैं survival से अधिक, और failure modes इतने predictable हैं कि मैं पहली call पर ही आमतौर पर बता सकता हूँ कि project किस ओर जा रहा है।

Thin-content de-indexing सबसे common फेलियर है। एक डायरेक्टरी पाँच हज़ार लिस्टिंग्स के साथ लॉन्च होता है, उनमें से आधी के पास सिर्फ एक नाम और एक-लाइन की डिस्क्रिप्शन होती है, और Google पहली पंद्रह सौ को index करता है फिर रुक जाता है। साइट low-effort scrape की तरह पढ़ी जाती है। छह महीने बाद indexed पेजेस के अधिकतर एक core update में de-indexed हो जाते हैं। fix को data-collection के समय होना चाहिए—हर पंक्ति के पास sitemap के लिए qualify करने से पहले तीन unique डेटा पॉइंट्स होने चाहिए, यह नहीं कि "हम इसे बाद में भर देंगे"।

स्टेल डेटा ड्रिफ्ट दूसरा पैटर्न है। एक डायरेक्टरी जो 2023 में सटीक व्यवसायों को लिस्ट करती थी, 2026 में आधे-अधूरे व्यवसायों को लिस्ट करती है क्योंकि किसी ने पंक्तियों को अपडेट नहीं किया, संपर्क जानकारी पुरानी पड़ जाती है, वेबसाइटें पार्किंग पेजों पर रीडायरेक्ट होती हैं, और डायरेक्टरी Google और मानव विजिटर दोनों के साथ ट्रस्ट सिग्नल खो देती है। हम या तो क्राउड-सोर्स्ड एडिटिंग फ्लो्स बनाते हैं जहाँ लिस्ट किया गया व्यवसाय अपनी प्रोफाइल को दावा और एडिट कर सके, ऑटोमेटेड फ्रेशनेस चेक्स जो डेड लिस्टिंग्स को डिसेबल करें, या दोनों। फ्रेशनेस लेयर के बिना डायरेक्टरी चाहे मूल डेटा कितना भी अच्छा हो, प्रासंगिकता से बाहर हो जाती है।

No moat तीसरा पैटर्न है। तीन competing डायरेक्टरीज़ same वर्टिकल को similar डेटा के साथ कवर करती हैं। किसी के पास unique डेटा नहीं है, तो किसी के पास exist करने का defensible कारण नहीं है। Search-share फ्रैगमेंट होता है और उनमें से कोई भी rank नहीं करता। fix editorial लेयर है—original analysis, scoring, recommendations, comparison frameworks—जो underlying डेटा अकेला provide नहीं कर सकता। HostList अपने scoring rubric पर compete करता है, न कि hosting list पर, क्योंकि hosting list खुद particularly defensible नहीं है।

Index bloat from filters चौथा पैटर्न है। आठ filter dimensions वाली डायरेक्टरी technically लाखों URL combinations जनरेट कर सकती है। अगर हर combination indexable है, तो आप Google को thin पेजेस से भर देते हैं और strong वाले को dilute करते हैं। हम हमेशा thin filter combinations को index से ब्लॉक करते हैं—तीन से कम लिस्टिंग्स वाली कोई भी चीज़ noindex पाती है, real query intent जैसे sort orders या page-2 onwards के बिना कोई भी noindex पाती है, और सिर्फ canonical filter combinations जो real searches को map करते हैं, indexable रहते हैं।

एक डायरेक्टरी के लिए रेफरेंस आर्किटेक्चर पाँच लेयर्स के साथ आता है। हर प्रोजेक्ट स्पेसिफिक्स को फ्लेक्स करता है, लेकिन स्पाइन बिल्ड्स के आर-पार दोहराता है।

डेटा लेयर Supabase के ज़रिए Postgres है या self-hosted, हर facet column पर proper indexes के साथ। हर entity type के लिए एक dedicated listings table है—companies, products, locations, people—और content के साथ quality-gate columns (uniqueness score, completeness percentage, last-verified timestamp)। एक sitemap-eligibility view quality threshold के नीचे की पंक्तियों को automatically filter करता है।

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

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

एसईओ स्कैफोल्डिंग वह लेयर है जो तय करती है कि डायरेक्टरी जीवित रहती है या नहीं। स्ट्रीमिंग साइटमैप टेम्पलेट-पर-चंक पैटर्न के साथ, स्कीमा.आर्ग Organization या Product या Place या Service या LocalBusiness हर लिस्टिंग पर जैसा उपयुक्त हो, CollectionPage कैटेगरी पेजेस पर ItemList के साथ, BreadcrumbList हर जगह, कैनोनिकल यूआरएल एकल सत्य स्रोत से उत्सर्जित (डेटाबेस, टेम्पलेट नहीं), और एक बिल्ड-टाइम एसईओ लिंटर जो बिल्ड को फेल करता है मिसिंग H1, ओवरसाइज़्ड मेटा डिस्क्रिप्शन्स, या इनवैलिड JSON-LD पर।

मोनेटाइजेशन फीचर्ड लिस्टिंग्स (एक बूलियन फ्लैग एक पंक्ति को कैटेगरी पेजेस के शीर्ष पर प्रमोट करता है), स्पॉन्सर्ड कैटेगरी प्लेसमेंट्स (एक ब्रांड एक बिलिंग पीरियड के लिए एक कैटेगरी के शीर्ष का मालिक बन जाता है), एफिलिएट-लिंक ट्रैकिंग प्रॉपर rel="sponsored" एट्रिब्यूशन के साथ, और लिस्ट किए गए एंटिटीज के लिए पेड प्रीमियम टियर्स बेहतर प्लेसमेंट, अधिक रिच डेटा फील्ड्स, और एनालिटिक्स एक्सेस पाने के लिए के माध्यम से आते हैं।

डायरेक्टरी प्रोजेक्ट में सबसे बड़ा चर डेटा स्रोत ही होता है। ज्यादातर एनगेजमेंट्स एक ही सवाल के जवाब पर जीते या मरते हैं: डे वन पर डेटा कहाँ से आएगा, और लॉन्च के बाद यह ताजा कैसे रहेगा?

मैनुअल एडिटोरियल का मतलब है कि एक टीम हर लिस्टिंग लिखती है। धीमा, महंगा, लेकिन बचाव योग्य। एक हजार से कम लिस्टिंग्स के लिए उपयुक्त। मैंने जो उदाहरण देखे हैं वे काम करते हैं: हाई-एंड होटल गाइड्स, क्यूरेटेड एजेंसी डायरेक्टरीज, निश लॉकेशन साइट्स जहाँ लिस्ट किया जाना ही वैल्यू है।

स्ट्रक्चर्ड इंपोर्ट का मतलब है आप किसी विश्वसनीय जगह से CSV या डेटाबेस एक्सपोर्ट लाते हो, और हम इसे क्लीन, डेडुप, एनरिच और इंजेस्ट करते हैं। एक हजार से एक लाख लिस्टिंग्स के लिए उपयुक्त। उदाहरण: पब्लिक डेटा वाली इंडस्ट्री डायरेक्टरीज, गवर्नमेंट रजिस्टर इंपोर्ट्स, कंपनीज-हाउस स्टाइल एक्सपोर्ट्स।

ऑटोमेटेड स्क्रेपिंग या API का मतलब है लिस्टिंग्स किसी थर्ड-पार्टी API या सम्मानजनक स्क्रेपिंग पाइपलाइन से पॉप्युलेट होती हैं। कानूनी और नैतिक रूप से स्रोत पर निर्भर करता है। दस हजार से लाखों लिस्टिंग्स के लिए उपयुक्त जहाँ डेटा किसी ज्ञात कैनोनिकल जगह पर रहता है। उदाहरण: GitHub से पुल की गई डेवलपर टूल डायरेक्टरीज, कंपनी साइट्स पर पब्लिक रिव्यूज से स्क्रैप किए गए होस्टिंग रिव्यूज।

यूजर-सबमिटेड का मतलब है लिस्टिंग्स उन लोगों से आती हैं जो लिस्ट किए जा रहे हैं। लॉन्च के लिए सस्ता, मॉडरेशन के लिए महंगा। एडिटोरियल सीड डेटा के ऊपर एक लेयर के रूप में सबसे अच्छा, केवल स्रोत के रूप में नहीं। हाइब्रिड पैटर्न (एडिटोरियल सीड प्लस स्ट्रक्चर्ड इंपोर्ट प्लस वार्षिक एडिटोरियल रिव्यू) वह है जो HostList चलाता है और वह है जो ज्यादातर असली डायरेक्टरीज करती हैं चाहे उन्होंने इसकी योजना बनाई हो या नहीं।

पहली कॉल पर हम पूछेंगे कि कौन सा कॉम्बिनेशन आपके डेटा रियलिटी से मेल खाता है। अगर आपके पास साफ जवाब नहीं है, तो डेटा सवाल ही काम का पहला फेज है; बिल्ड के बाद आता है।

Real recent engagements पर आधारित honest ranges, sales deck पर aspirational pricing नहीं। एक छोटी editorial डायरेक्टरी जिसमें हज़ार से कम लिस्टिंग्स हों, वह अठारह से पैंतीस हज़ार US डॉलर छह से नौ सप्ताह में लगती है। एक mid-sized डायरेक्टरी एक से दस हज़ार लिस्टिंग्स की, structured डेटा import के साथ, तीस से साठ हज़ार दस से चौदह सप्ताह में लगती है। एक बड़ी डायरेक्टरी दस से एक लाख लिस्टिंग्स की, programmatic scale पर, पचास से नब्बे हज़ार बारह से अठारह सप्ताह में लगती है। एक marketplace शेप, two-sided, bookings या transactions के साथ, साठ से एक सौ पचास हज़ार चौदह से बाईस सप्ताह में लगती है।

सभी रेंज्स में SEO स्कैफोल्डिंग (स्कीमा, साइटमैप, लिंटर), सर्च-एंड-फिल्टर लेयर, और एक बेसिक एडमिन डैशबोर्ड शामिल है। इसमें डेटा एक्विजीशन (मैनुअल एडिटोरियल, स्क्रेपिंग इंफ्रास्ट्रक्चर, थर्ड-पार्टी API कॉस्ट्स), ऑरिजिनल ब्रांड और डिज़ाइन वर्क, या पेड ट्रैफिक एक्विजीशन शामिल नहीं है। लॉन्च के बाद चलने वाली केयर प्लान्स पाँच सौ से तीन हजार अमेरिकी डॉलर प्रति महीना चलती हैं।