डायरेक्टरी साइट बनाना

डायरेक्टरी साइट्स और लिस्टिंग प्लेटफॉर्म्स प्रोग्रामेटिक-एसईओ प्रोजेक्ट्स की एक विशिष्ट श्रेणी हैं जिन्हें मैंने सार्थक स्केल पर शिप किया है। HostList.io में कुल मिलाकर लगभग 28,000 वेब होस्टिंग कंपनियां हैं जो श्रेणियों, क्षेत्रों और प्राइसिंग टियर्स में इंडेक्स हैं, सभी एक संरचित डेटा मॉडल से प्रोग्रामेटिकली जनरेट की गई हैं। Not Another Sunday में 137,000 यूके पब्स, बार्स, और रेस्तरां हैं। दोनों एक ही आर्किटेक्चरल पैटर्न पर चलते हैं: एक क्लीन डेटा मॉडल, एक टेम्प्लेटेड पेज रेंडरर, एक सख्त इंडेक्सेबिलिटी गेट, और एक प्रोग्रामेटिक आंतरिक-लिंक ग्राफ।

यह गाइड एक डायरेक्टरी या लिस्टिंग प्लेटफॉर्म बनाने का ऑपरेटर दृष्टिकोण है जो 2026 में सर्च इंजन की जांच के तहत टिका रहे, क्या बचना चाहिए, और परंपरागत सलाह के कौन से हिस्से व्यावहारिक रूप से गलत हैं। व्यक्तिगत रूप से और Seahawk Media क्लाइंट एनगेजमेंट्स में कई डायरेक्टरी प्लेटफॉर्म्स शिप करने के अनुभव से।

एक डायरेक्टरी साइट जीतती है जब तीन चीजें एक साथ सच हों: बहुत सारी प्रतिस्पर्धी या समान इकाइयों वाला एक खंडित बाजार, तुलनात्मक इरादे के साथ खोज करने वाली दर्शक (सेरा, शीर्ष, बनाम, सबसे सस्ता), और एक एकल प्रभावशाली एग्रीगेटर की अनुपस्थिति जो पहले से एसईआरपीएस पर कब्जा कर लेता है।

जो उदाहरण काम करे: वेब होस्टिंग कंपनियां (खंडित, तुलनात्मक, कोई एक Google-स्वामित्व वाला एकत्रिकर्ता नहीं), लंदन रेस्तरां (खंडित, क्वेरी आशय तीव्र है, मौजूदा एकत्रिकर्ता कमजोर हो रहे हैं), श्रेणी के अनुसार विशिष्ट सॉफ़्टवेयर टूल (खंडित, तुलना साइटें गुणवत्ता में असंगत हैं)।

जो उदाहरण काम नहीं किए: कुछ भी जहां Google स्वयं प्रमुख एकत्रिकर्ता है (नौकरियां, उड़ानें, कुछ बाजारों में बंधक), कुछ भी जहां हजारों पृष्ठों को समर्थित करने के लिए इकाइयां बहुत कम हैं (उदाहरण के लिए, एक एकल शहर में शीर्ष स्तरकी कानून फर्में), कुछ भी जहां तुलना मानदंड डेटा मॉडल में एन्कोड करने के लिए बहुत व्यक्तिपरक हैं।

शुरुआत से कड़ाई से सामान्य करें

प्रत्येक इकाई (कंपनी, स्थान, उत्पाद) को एक एकल विहित पंक्ति मिलती है जिसमें एक स्थिर ID और एक स्लग होता है जो कभी नहीं बदलता। प्रत्येक विशेषता (श्रेणी, मूल्य स्तर, क्षेत्र, विशेषता) को अपनी स्वयं की तालिका या enum मिलती है, कभी भी मुक्त पाठ क्षेत्र नहीं। अनेक-से-अनेक संबंध junction तालिकाएं प्राप्त करते हैं। पहले दिन इसे गलत करने की लागत वर्षों की स्लग अस्थिरता और टूटे हुए रीडायरेक्ट हैं।

स्लग हमेशा के लिए

एक बार जब एक निर्देशिका पृष्ठ Google द्वारा अनुक्रमित हो जाता है, तो स्लग नहीं बदलना चाहिए। slug-of-record पैटर्न का उपयोग करें: इकाई नाम से नियतात्मक पीढ़ी, संख्यात्मक suffix के माध्यम से टकराव प्रबंधन, और एक लुकअप तालिका जो किसी भी ऐतिहासिक स्लग को वर्तमान स्लग पर स्थायी 301 रीडायरेक्ट के लिए मैप करती है। हमारे पास HostList.io पर एक स्लग-स्थिरता नियम है जो तीन वर्षों से नहीं बदला है।

स्कीमा डिज़ाइन जो स्केल करता है

Supabase पर: master रिकॉर्ड के साथ एक entities तालिका, एक categories तालिका, एक attributes तालिका, अनेक-से-अनेक के लिए junction तालिकाएं, और एक generated computed_slug जो अद्वितीय है। RLS नीतियां प्रकाशित पंक्तियों के लिए सार्वजनिक पढ़ने की अनुमति देती हैं, केवल व्यवस्थापक लेखन। हर उस स्तंभ पर सूचकांक जिसे आप पृष्ठ स्तर पर क्वेरी करते हैं। HostList.io की स्कीमा मोटे तौर पर बारह तालिकाएं हैं और launch के बाद से संरचनात्मक परिवर्तनों की आवश्यकता नहीं है।

एक टेम्पलेट, कई रूप

एक डायरेक्टरी साइट के छः मुख्य पेज आर्कटाइप होते हैं: एंटिटी पेज, कैटेगरी लिस्टिंग, क्रॉस-कैटेगरी तुलना, रीजनल पेज, होम पेज, और सर्च पेज। हर एक के लिए एक टेम्पलेट होता है जो हज़ारों पेज रेंडर करता है। अनुशासन यह है: टेम्पलेट को इतना अच्छा बनाएँ कि किसी भी व्यक्तिगत पेज को विशेष ट्रीटमेंट की जरूरत न हो, और विशेष मामलों को हैंडल करने की इच्छा का विरोध करें।

फोल्ड के ऊपर अनन्यता

हर एंटिटी पेज के फोल्ड से ऊपर यूनिक कंटेंट होना चाहिए: एक यूनिक ओपनिंग पैराग्राफ, यूनिक मुख्य फैक्ट्स, यूनिक प्राइसिंग या फीचर डेटा। यूनिक कंटेंट डेटा मॉडल से प्रोग्रामेटिक तरीके से जनरेट किया जा सकता है (HostList.io ऐसा करता है टेम्पलेटेड ओपनिंग्स के साथ जो कंपनी का नाम, फाउंडिंग साल, प्राइमरी मार्केट, और एक अलग विशेषता इंटरपोलेट करते हैं), लेकिन उसे ऐसा पढ़ना चाहिए जैसे कि वह उस एंटिटी के लिए विशेष रूप से लिखा गया हो, ब्लैंक भरने वाले टेम्पलेट की तरह नहीं।

स्केल पर स्कीमा मार्कअप

हर एंटिटी पेज Organization या LocalBusiness स्कीमा एमिट करता है नाम, url, एड्रेस (जहाँ लागू हो), aggregateRating (जहाँ वास्तव में उपलब्ध हो), और सत्यापित सोशल प्रोफाइल्स को sameAs लिंक्स के साथ। हर कैटेगरी और एंटिटी पेज पर BreadcrumbList। हर कैटेगरी लिस्टिंग पर ItemList। स्कीमा लेयर ही है जो डायरेक्टरी को गूगल और AI सर्फेसेस दोनों के लिए मशीन-रीडेबल बनाता है।

Helpful Content Update एक डायरेक्टरी साइट के लिए सबसे बड़ा खतरा है, और प्रोग्रामेटिक साइट्स पर डोमेन-व्यापी रैंकिंग कोलैप्स का सबसे आम कारण है। उपाय है एक पर-पेज इंडेक्सेबिलिटी गेट जो तय करता है कि कौन से पेज इंडेक्स करने लायक हैं।

पेज प्रति क्वालिटी थ्रेसहोल्ड्स

कंटेंट क्वालिटी थ्रेसहोल्ड के नीचे वाले पेज्स को पेज ही पर noindex मिलता है, भले ही बाकी साइट कैसे भी कॉन्फ़िगर हो। क्वालिटी थ्रेसहोल्ड्स के उदाहरण जो हम लागू करते हैं: यूनिक कंटेंट के मिनिमम वर्ड काउंट (HostList.io पर 300 शब्द), स्ट्रक्चर्ड डेटा फील्ड्स की मिनिमम संख्या भरी हुई (होस्टिंग कंपनियों के लिए 12 में से 8), पेज की ओर पॉइंट करने वाले इंटरनल लिंक्स की मिनिमम संख्या (दूसरे एंटिटी या कैटेगरी पेज्स से 3 इनकमिंग लिंक्स)।

साइटमैप गेट के अनुसार चलता है

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

Robots और noindex परतों में हैं

हम robots.txt का उपयोग इंडेक्सेबिलिटी निर्णयों को ब्लॉक करने के लिए नहीं करते; robots.txt पूरी तरह क्रॉल को ब्लॉक करता है, जो Google की noindex हेडर को सम्मानित करने की क्षमता को हटा देता है। सही पैटर्न है: क्रॉल की अनुमति दें, मेटा robots हेडर के माध्यम से गेटेड पेजों पर noindex सेट करें, साइटमैप से बाहर करें।

प्रोग्रामेटिक रूप से लिंकिंग, प्रोग्रामेटिक रूप से

डायरेक्टरी स्केल पर, आंतरिक लिंकिंग को जेनरेट किया जाना चाहिए, न कि हाथ से तैयार किया जाना चाहिए। प्रत्येक एंटिटी पेज अपनी पैरेंट श्रेणियों, अपनी सहोदर एंटिटी (समान श्रेणी, समान विशेषताएं), लागू होने वाले क्षेत्रीय पेज, और होम से लिंक करता है। प्रत्येक श्रेणी पेज अपनी चाइल्ड एंटिटी, पैरेंट श्रेणियों, और पार्श्व श्रेणियों से लिंक करता है। ग्राफ बिल्ड समय पर कंप्यूट किया जाता है और जब भी एंटिटी जोड़े या हटाए जाते हैं तो अपडेट किया जाता है।

एंकर टेक्स्ट विविधता

आंतरिक एंकर टेक्स्ट को भिन्न होना चाहिए। 8,000 पेजों को एक श्रेणी पेज से एक ही एंकर टेक्स्ट के साथ लिंक करना एक मजबूत नकारात्मक सिग्नल है। हम एंकर टेक्स्ट को टेम्पलेट के एक सेट में घुमाते हैं: "[category] companies", "best [category] services", "[category] at [region]", "[entity] alternatives"। रोटेशन स्रोत पेज के लिए नियतात्मक है ताकि ग्राफ रीबिल्ड के दौरान स्थिर रहे।

प्रति पैराग्राफ तीन से अधिक आंतरिक लिंक नहीं

भारी आंतरिक लिंकिंग ठीक है; लेकिन लिंक को क्लस्टर करने से पेज़ ऑटो-जेनरेट दिखने लगते हैं। हम प्रति पैराग्राफ तीन आंतरिक लिंक और प्रति पेज तीस लिंक तक सीमित रखते हैं, बाकी पेज भर में बिखरे होते हैं। यह अनुशासन संपादकीय है, टेम्पलेट स्तर पर लागू किया जाता है।

आवधिक पुनः सत्यापन के साथ स्थिर रेंडरिंग

Next.js पर: बिल्ड समय पर स्थिर जनरेशन, entity पेजों के लिए 24-घंटे की पुनः सत्यापन विंडो के साथ ISR, जब कोई entity एडमिन के माध्यम से अपडेट होता है तो ऑन-डिमांड पुनः सत्यापन। Vercel 28,000 पेजों को आराम से संभालता है; लागत का लीवर ISR राइट इवेंट्स हैं, जिन्हें हम entity परिवर्तनों तक सीमित करके प्रबंधनीय रखते हैं, प्रत्येक content ट्विक के लिए नहीं।

डेटाबेस कनेक्शन पूलिंग

पेज टेम्पलेट से सीधे Supabase क्वेरीज़ स्केल नहीं होती; पूर्ण रीबिल्ड के दौरान आप कनेक्शन सीमा तक पहुँच जाते हैं। हम स्थिर-जनरेशन पैटर्न का उपयोग करते हैं: बिल्ड समय पर, कुछ बड़ी क्वेरीज़ में सभी पेज फेच करें, इन-मेमोरी डेटा से पेज जेनरेट करें। पेज रेंडर कभी भी सीधे डेटाबेस को hit नहीं करते। HostList.io के लिए 28,000 पेजों पर रीबिल्ड समय दस मिनट से कम रहता है।

CDN और edge कैशिंग

मूल के सामने हमेशा Cloudflare। फ्री टियर डायरेक्टरी ट्रैफिक को आराम से संभालता है; paid टियर global routing के लिए Argo जोड़ते हैं अगर ट्रैफिक इसके लायक हो। CDN कैशिंग एक विशिष्ट डायरेक्टरी ट्रैफिक प्रोफाइल पर origin लोड को सार्वजनिक ट्रैफिक के लगभग 5% तक कम कर देता है।

तीन मेट्रिक्स जो मैं हर सप्ताह हर डायरेक्टरी साइट पर चेक करता हूँ जो मैं चलाता हूँ:

अनुक्रमित पृष्ठ बनाम प्रकाशित पृष्ठ

Search Console > Pages > Indexed की तुलना आपकी sitemap गणना से करें। स्वस्थ: 90%+। 80% के नीचे: Google को सिग्नल-गुणवत्ता संबंधी चिंताएं हैं; gating थ्रेसहोल्ड की समीक्षा करें। 70% के नीचे: संरचनात्मक समस्या, संभवतः thin content या duplicate intent।

टेम्पलेट archetype द्वारा औसत स्थिति

Search Console को URL पैटर्न द्वारा फ़िल्टर किया गया, entity / category / regional द्वारा विभाजित। यह बताता है कि कौन सा टेम्पलेट काम कर रहा है और कौन सा domain को घसीट रहा है। हमने इस मीट्रिक का उपयोग करके HostList.io पर 7 दिनों के भीतर टेम्पलेट regressions को पकड़ा है।

अनुक्रमित पृष्ठ प्रति क्लिक

कुल क्लिकों को अनुक्रमित पृष्ठों से विभाजित करें, साप्ताहिक। स्वस्थ directory sites: 0.3 से 1.5। 0.2 के नीचे: index बहुत व्यापक है और बिना ट्रैफ़िक वाले पृष्ठ domain को कमजोर कर रहे हैं। Gate को कसें।

पाँच गलतियाँ जिन्होंने मेरे द्वारा audit की गई directory sites को मार डाला है:

1. Hand-curated internal linking जो content addition के बाद जीवित नहीं रह सकी। ग्राफ को दिन एक से ही programmatic होना चाहिए।

2. Slugs जो entity names के सुधार के समय बदल गए। एक भी slug परिवर्तन बिना 301 के महत्वपूर्ण ranking signal की cost करता है; दस slug परिवर्तन terminal हो सकते हैं।

3. अद्वितीय कंटेंट के बिना इंडेक्स किए जा सकने वाले पेज। Helpful Content Update उन डायरेक्टरीज के प्रति बेरहम है जहाँ सभी कैटेगरी पेज एक जैसे बॉयलरप्लेट की तरह पढ़े जाते हैं।

4. नकली या अप्रमाणित रेटिंग के साथ AggregateRating स्कीमा। Google इसे पहचानता है और स्कीमा को विश्वव्यापी स्तर पर कम मूल्य देता है। AggregateRating का उपयोग केवल तभी करें जब रेटिंग वास्तविक और सत्यापित हों।

5. डायरेक्टरी को एक लॉन्च प्रोजेक्ट के बजाय एक चल रहे ऑपरेशनल मामले के रूप में न मानना। डायरेक्टरीज को सक्रिय रखरखाव की जरूरत होती है: पुरानी एंटिटीज हटाई जाएं, नई एंटिटीज जोड़ी जाएं, टूटे हुए बाहरी लिंक हटाए जाएं, स्कीमा सिंक्रोनाइज रहे। इसके बिना, डायरेक्टरीज 12 से 24 महीने में गिरावट आती है।

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

आपको दिन एक पर सब कुछ करने की जरूरत नहीं है। आपको पता होना चाहिए कि आपने इनमें से कौन-सा अभी तक नहीं बनाया है, और Google को ध्यान देने से पहले अगले को ठीक करना चाहिए।

हम Seahawk Media पर 18,000 USD से शुरू करके डायरेक्टरी और लिस्टिंग प्लेटफॉर्म बनाते हैं। HostList.io केस स्टडी पैमाने पर पैटर्न को दिखाती है; आपकी विशिष्ट डायरेक्टरी कैसी दिखनी चाहिए, इस बारे में बातचीत मुफ्त है।