2022 में मैंने एक क्लाइंट को £40,000 एक लोकल सर्विसेज़ डायरेक्टरी बनाने में खर्च करते देखा। शानदार डिज़ाइन। 80,000 पेजेज़ एक क्लीन Airtable बेस से ऑटो-जेनरेट किए गए। मार्च में लॉन्च हुआ। जून तक इसके 214 इंडेक्स पेजेज़ थे और यह बिल्कुल कुछ भी रैंक नहीं कर रहा था। समस्या आइडिया की नहीं थी -- डायरेक्टरीज़ अभी भी उन कुछ प्रोग्रामेटिक SEO प्ले में से हैं जो सीरियस ऑर्गेनिक ट्रैफिक में बदल सकती हैं। समस्या यह थी कि उन्होंने सब कुछ तकनीकी रूप से सही और रणनीतिक रूप से गलत किया था।
यह पोस्ट वह गलती न करने के बारे में है।
---
2026 में डायरेक्टरी के लिए "प्रोग्रामेटिक SEO" असल में क्या मायने रखता है
लोग इस फ़्रेज़ को इस तरह फेंकते हैं जैसे यह एक चीज़ है। ऐसा नहीं है। एक डायरेक्टरी के लिए विशेष रूप से, प्रोग्रामेटिक SEO का अर्थ है सैकड़ों या हज़ारों लोकेशन-, कैटेगरी-, या एट्रिब्यूट-स्कोप्ड पेजेज़ को एक ही टेम्पलेट और एक स्ट्रक्चर्ड डेटा सोर्स से जेनरेट करना -- और इसे इस तरीके से करना कि हर पेज Google को इसे हाथ से लिखे गए कॉम्पिटिटर के ऊपर रैंक करने का कारण दे।
वह आखिरी हिस्सा है जहाँ ज्यादातर डायरेक्टरीज असफल हो जाती हैं।
इस गेम का 2026 वर्ज़न 2019 की तुलना में कठिन है। Google की Helpful Content सिस्टम देर 2023 से कोर रैंकिंग एल्गोरिदम में बेक किया जा चुका है, जिसका अर्थ है कि थिन टेम्पलेट्ड पेजेज़ को पेज लेवल पर नहीं, साइट लेवल पर डाउनवेट किया जाता है। एक बुरा बैच आपके पूरे डोमेन को टैंक कर सकता है। मैंने इसे देखा है। Seahawk के पास देर 2023 में एक ट्रैवल एग्रीगेटर प्रोजेक्ट था जहाँ 12,000 सिटी पेजेज़ -- हर एक में लगभग 90 शब्द और एक लिस्टिंग्स टेबल -- लॉन्च के आठ हफ्तों के भीतर पूरे डोमेन के क्रॉल बजट को फर्श तक खींच गई।Google's Helpful Content system has been baked into the core ranking algorithm since late 2023, which means thin templated pages get downweighted at a site level, not just a page level. One bad batch can tank your whole domain. I've seen it. Seahawk had a travel aggregator project in late 2023 where 12,000 city pages -- each with roughly 90 words and a listings table -- dragged the entire domain's crawl budget into the floor within eight weeks of launch.
तो बेसलाइन बार ऊँचा है। लेकिन मौका अभी भी बहुत बड़ा है।
---
डेटा लेयर ही सब कुछ है
ऐसे स्रोत से शुरुआत करें जिसमें गहराई हो, सिर्फ व्यापक न हो
ज्यादातर डायरेक्टरी बिल्डर यह पूछते हैं "मैं 50,000 लिस्टिंग्स कैसे पाऊँ?" उन्हें यह पूछना चाहिए "मैं वास्तव में हर लिस्टिंग के बारे में क्या जानता हूँ जो किसी और को नहीं पता?"
मैं छोटे-मझोले प्रोजेक्ट्स के लिए (100k records से कम) Airtable इस्तेमाल करता हूँ और बड़े प्रोजेक्ट्स के लिए Supabase या एक straightforward PostgreSQL setup। टूल का मायने कम है — schema ही मायने रखता है। आपके डेटाबेस में हर listing में ऐसे fields होने चाहिए जो differentiated page content जनरेट कर सकें। सिर्फ नाम, पता, फोन नहीं। सोचिए: स्थापना का साल, कीमत की रेंज, औसत review sentiment, verified reviews की संख्या, specialisms, आखिरी बार verify किया गया दिन, शहर के केंद्र से दूरी, physical location है या remote-only।Supabase or a straightforward PostgreSQL setup for anything larger. The tool matters less than the schema. Every listing in your database should have fields that can generate differentiated page content. Not just name, address, phone. Think: year founded, price range, average review sentiment, number of verified reviews, specialisms, last verified date, distance from city centre, whether they have a physical location vs. remote-only.
ज्यादा फील्ड्स = ऑन-पेज डिफरेंशिएशन के लिए ज्यादा एंगल्स। बस इतना ही।
स्क्रेपिंग बनाम लाइसेंस्ड डेटा बनाम यूजर-सबमिटेड
ईमानदारी से कहूँ तो तीनों की अपनी भूमिका है, और मैंने तीनों का इस्तेमाल किया है।
- Scraped data तेज़ और सस्ता है लेकिन जल्दी ही degraded हो जाता है। मैंने 2021 में एक UK accountants directory चलाया था जो Companies House data को scrape करता था। 14 महीनों में 23% records stale हो गए। is fast and cheap but degrades quickly. I ran a UK accountants directory in 2021 that scraped Companies House data. Within 14 months, 23% of the records were stale.
- Licensed डेटा फ़ीड्स (Dun & Bradstreet, Yext, या वर्टिकल-स्पेसिफिक APIs सोचें) महँगे होते हैं लेकिन सटीक होते हैं। लायक़ है अगर आपका monetisation मॉडल इसे सपोर्ट करता हो।(think Dun & Bradstreet, Yext, or vertical-specific APIs) are expensive but accurate. Worth it if your monetisation model supports it.
- User-submitted listings धीरे शुरू होती हैं लेकिन freshness signals बनाती हैं जिन्हें Google reward करता है। पहले दिन से ही "claim your listing" flow जोड़ें, भले ही आपके पास दो सौ listings हों। start slow but create the freshness signals Google rewards. Add a "claim your listing" flow from day one, even if you have two hundred listings total.
जो डायरेक्टरीज़ 18-24 महीनों में ट्रैफिक को कंपाउंड करती हैं, वे लगभग हमेशा वह होती हैं जो लाइसेंस्ड सीड डेटा को चल रहे यूज़र कंट्रिब्यूशन के साथ मिक्स करती हैं।
---
Template Architecture: जिस बारे में कोई बात नहीं करता
यहाँ वह चीज़ है जो अधिकांश ट्यूटोरियलस स्किप करते हैं। एक प्रोग्रामेटिक डायरेक्टरी के बीच का फर्क जो रैंक करती है और एक जो इट्सेल्फ में फिल्टर हो जाती है, आमतौर पर डेटा लेवल पर नहीं, टेम्पलेट लेवल पर होता है।
एक टेम्पलेट काफी नहीं है
आपको कम से कम तीन टेम्पलेट टियर्स की ज़रूरत है:
- Hub पेजेज़ -- "Best Solicitors in London" स्टाइल। हाई कॉम्पिटिशन, एडिटोरियल टोन, मैनुअली क्यूरेटेड या हेविली एनरीच्ड। ये वह पेजेज़ हैं जिन पर आप लिंक पॉइंट करते हैं। -- "Best Solicitors in London" style. High competition, editorial tone, manually curated or heavily enriched. These are the pages you point links at.
- Category × location पेजेज़ -- "Family Law Solicitors in Manchester"। Mid-tail। ये अधिक टेम्पलेटेड हो सकते हैं लेकिन कम से कम एक डायनामिक सेक्शन की जरूरत है जो गेन्युइनली यूनिक डेटा पुल करे (रिव्यू काउंट्स, एवरेज फी ब्रैकेट, नोटेबल लिस्टिंग्स)। -- "Family Law Solicitors in Manchester". Mid-tail. These can be more templated but need at least one dynamic section that pulls genuinely unique data (review counts, average fee bracket, notable listings).
- Individual listing पेजेज़ -- लीफ नोड्स। ये डेटा रिचनेस के आधार पर लाइव या डाई होते हैं। अगर हर listing पेज के पास एक ही 60-वर्ड का डेस्क्रिप्शन और एक फोन नंबर है, तो Google को यह तेज़ी से फिगर आ जाएगा। -- The leaf nodes. These live or die by data richness. If every listing page has the same 60-word description and a phone number, Google will figure that out fast.
मैंने इस split को पिछले दो साल में चार directory प्रोजेक्ट्स पर test किया है। जिनके पास clear three-tier hierarchy था वो flat architectures से consistently बेहतर प्रदर्शन करते रहे Google Search Console impression data में पहले 90 दिनों में। कोई coincidence नहीं है।Google Search Console impression data within the first 90 days of indexing. Not a coincidence.
डायनामिक कंटेंट ब्लॉक जो असल में मदद करते हैं
पेजों को AI-जेनरेटेड बॉयलरप्लेट से भरना बंद करो। इसकी जगह टेम्पलेट लॉजिक बनाओ जो यह खींचे:
- एक ही पोस्टकोड डिस्ट्रिक्ट में रिलेटेड लिस्टिंग
- आपनी एनालिटिक्स से "Also viewed" कैटेगरी
- एक "last updated" टाइमस्टैम्प जो सच में एक्यूरेट हो (JS द्वारा इंजेक्ट किया गया आज की तारीख नहीं)
- यूज़र रिव्यू स्निपेट्स, भले ही आपके पास सिर्फ तीन रिव्यूज़ हैं -- तीन रियल अॉनेज़ ज़ीरो फेक अॉनेज़ को बीट करते हैं
इसका मकसद यह है कि जो कोई भी किसी लीफ-नोड लिस्टिंग पेज पर आए, वह ऐसी कोई चीज़ लेकर जाए जो वह Google पर खुद से नहीं खोज सकता था।
---
Internal Linking: आपका सबसे कम इस्तेमाल किया जाने वाला Ranking Lever
मैं साफ कहूँ। ज़्यादातर programmatic directories में आंतरिक linking बहुत ख़राब होती है। पेज मौजूद होते हैं। वे कहीं उपयोगी की ओर इशारा नहीं करते। Google का crawler एक बार आता है, एक dead-end देखता है, और पूरी subdirectory को कम प्राथमिकता देता है।
एक directory के लिए सही internal linking architecture कुछ इस तरह दिखता है:
- होमपेज → शीर्ष हब पेज (मैन्युअली क्यूरेटेड, 8-15 लिंक)
- Hub pages → category × location pages (dynamic, listing count के आधार पर)
- श्रेणी × स्थान पेज → व्यक्तिगत लिस्टिंग (पेजिनेटेड, अधिकतम 20-25 प्रति पेज)
- व्यक्तिगत लिस्टिंग → संबंधित श्रेणी × स्थान पेज (2-3 संदर्भ लिंक)
- Individual listings → "nearby" listings एक distance-based query के ज़रिए
वह आखिरी वाला -- पास की लिस्टिंग -- कम आंका गया है। यह आपके लीफ नोड्स के अंदर एक क्रॉल करने योग्य वेब बनाता है जो गूगलबॉट को साइट के माध्यम से आगे बढ़ाए रखता है बजाय हब तक वापस उछलने के। मैंने इसे 2024 की शुरुआत में बर्मिंघम में एक डेंटल डायरेक्टरी क्लाइंट के लिए लागू किया था और GSC से क्रॉल दर छह हफ्तों में 3.4x बढ़ गई थी।
लॉन्च करने से पहले Screaming Frog से अपने link graph को audit करें, बाद में नहीं। free tier 500 URLs तक handle करता है, जो आपके templates पर एक sanity check के लिए काफी है।Screaming Frog to audit your link graph before you launch, not after. The free tier handles up to 500 URLs, which is plenty for a sanity check on your templates.
---
बड़े पैमाने पर इंडेक्सेशन को संभालना बिना जले-कटे
Google आपके 80,000 पेजों में से सभी को इंडेक्स नहीं करेगा। इसे स्वीकार करें। इसके साथ काम करें।
जो व्यावहारिक दृष्टिकोण मैं उपयोग करता हूँ:
- लॉन्च के दिन sitemap में केवल अपने hub और category × location पेज सबमिट करें
- Google को लीफ नोड्स को sitemap के माध्यम से नहीं, इंटरनल लिंक्स के माध्यम से खोजने दें
- noindex का इस्तेमाल aggressively करें thin, duplicate, या low-data listing pages पर जब तक आप उन्हें enrich न कर सकें।
noindexaggressively on thin, duplicate, or low-data listing pages until you can enrich them - GSC में एक क्रॉल बजट रिपोर्ट सेट अप करें (Settings → Crawl Stats) और पहले तीन महीनों में सप्ताह में एक बार इसे देखें
noindex की सलाह को हमेशा pushback मिलती है। "लेकिन मैं चाहता हूँ कि सभी पेज indexed हों!" हाँ। और Google भी चाहता है कि सभी अच्छे हों। आप 40,000 thin pages indexed नहीं रख सकते और साथ ही एक healthy domain authority भी नहीं रख सकते। एक चुनो।noindex advice always gets pushback. "But I want all my pages indexed!" Yeah. And Google wants all of them to be good. You can't have 40,000 thin pages indexed and also have a healthy domain authority. Pick one.
एक बात और: pagination। जहाँ उपयुक्त हो वहाँ proper rel="next" और rel="prev" इस्तेमाल करें, लेकिन यह भी सोचें कि क्या आपको paginated category pages की जरूरत है। तीन हालिया प्रोजेक्ट्स पर मैंने paginated listings को JS-loaded "show more" approach से बदला (crawlers के लिए static fallback के साथ) और 60 दिनों में GSC में cleaner indexation patterns देखे।rel="next"and rel="prev"where appropriate, but also consider whether you need paginated category pages at all. On three recent projects I replaced paginated listings with a JS-loaded "show more" approach (with a static fallback for crawlers) and saw cleaner indexation patterns in GSC within 60 days.
---
स्केल पर कंटेंट एनरिचमेंट अपना दिमाग खोए बिना
सही है। तो आपने स्वीकार कर लिया कि पतले पेजें मौत हैं। आप वास्तव में 20,000 लिस्टिंग पेजों को कंटेंट राइटर्स की टीम के बिना कैसे समृद्ध करते हैं?
कुछ अप्रोचेज जो व्यावहारिक रूप से काम करती हैं:
- संरचित समीक्षा एकत्रीकरण। Google Business Profile डेटा को उनके API के माध्यम से खींचें, या जहाँ ToS अनुमति दे वहाँ Trustpilot या Yelp से (सावधानी से) स्क्रैप करें। संरचित डेटा के रूप में प्रदर्शित एक स्टार रेटिंग + समीक्षा गणना भी मापने योग्य अंतर जोड़ता है।Pull from Google Business Profile data via their API, or scrape (carefully) from Trustpilot or Yelp where ToS allows. Even a star rating + review count displayed as structured data adds measurable differentiation.
- स्वचालित ताजगी सिग्नल। एक स्क्रिप्ट लिखें जो साप्ताहिक रूप से आपकी लिस्टिंग को हिट करे और जांच करे कि क्या व्यवसाय की वेबसाइट, फोन या पता बदल गया है। रिकॉर्ड को अपडेट करें। पेज पर "अंतिम सत्यापित" तारीख दिखाएं। इसी ने एक कानूनी डायरेक्टरी पर हमारे बाउंस दर को 18% तक कम कर दिया -- लोग मौजूदा डेटा पर भरोसा करते हैं।Write a script that hits your listings weekly and checks whether the business website, phone, or address has changed. Update the record. Show the "last verified" date on the page. This alone reduced our bounce rate on a legal directory by 18% -- people trust current data.
- एलएलएम-सहायता प्राप्त सारांश, सावधानीपूर्वक उपयोग किया गया। मैं जीपीटी-4 का उपयोग संरचित सारांश उत्पन्न करने के लिए करता हूं जहां हमारे पास पर्याप्त कच्चा डेटा है। लेकिन प्रॉम्प्ट उस लिस्टिंग के लिए विशिष्ट डेटा फील्ड तक कसकर सीमित है -- यह सामान्य विवरण उत्पन्न नहीं कर रहा है। और प्रत्येक सारांश एक समानता जांच के माध्यम से फ़िल्ट किया जाता है (मैं पूर्ण कॉर्पस के विरुद्ध एक बुनियादी कोसाइन समानता स्क्रिप्ट का उपयोग करता हूं) लाइव होने से पहले निकट-डुप्लिकेट आउटपुट को पकड़ने के लिए।I do use GPT-4 to generate structured summaries for listings where we have enough raw data. But the prompt is tightly constrained to the specific data fields for that listing -- it's not generating generic blurb. And every summary is filtered through a similarity check (I use a basic cosine similarity script against the full corpus) to catch near-duplicate outputs before they go live.
---
आपका मुद्रीकरण मॉडल SEO आर्किटेक्चर को परिभाषित करता है
यह बात लोगों को हैरान करती है। आप निर्देशिका से पैसे कमाने की योजना कैसे बनाते हैं, इसका सीधा असर इस बात पर पड़ता है कि आप किन पृष्ठों को प्राथमिकता देते हैं, आपको कितनी डेटा गहराई चाहिए, और क्या आप वह सामग्री समृद्धि करने का खर्च उठा सकते हैं जो रैंकिंग के लिए आवश्यक है।
मैंने तीन मॉडल देखे हैं जो लगातार काम करते हैं:
- सशुल्क सूचियाँ / विशेष प्लेसमेंट। सरल। व्यवसाय उच्च दिखाई देने या बेहतर प्रोफाइल के साथ दिखाई देने के लिए भुगतान करते हैं। इसे मार्केटप्लेस डायनामिक्स बनाने के लिए फ्री टियर को बढ़ाने के लिए प्रोत्साहित करता है।Simple. Businesses pay to appear higher or with enhanced profiles. Incentivises you to grow the free tier to create the marketplace dynamic.
- लीड जेनरेशन। आप पूछताछ फॉर्म सबमिशन कैप्चर करते हैं और उन्हें व्यवसायों को बेचते हैं। प्रति कन्वर्ज़न में अधिक राजस्व मिलता है, लेकिन फॉर्म भरवाने के लिए आवश्यक विश्वास अर्जित करने के लिए काफी समृद्ध लिस्टिंग पेजों की जरूरत पड़ती है।You capture enquiry form submissions and sell them to businesses. Higher revenue per conversion but requires significantly richer listing pages to earn the trust needed for form fills.
- सहयोगी / रेफरल। सॉफ्टवेयर, वित्त या आतिथ्य जैसी वर्टिकल में अच्छी तरह से काम करता है जहां स्थापित सहयोगी कार्यक्रम हैं। SaaS टूल श्रेणियों में आला डायरेक्टरी इस मॉडल पर £10k-£30k/माह तक पहुंच सकती हैं यदि कीवर्ड लक्ष्यीकरण सही है।Works well in verticals like software, finance, or hospitality where there are established affiliate programmes. Niche directories in SaaS tool categories can hit £10k-£30k/month on this model with under 5,000 pages if the keyword targeting is right.
अपने टेम्पलेट डिज़ाइन करने से पहले अपना मॉडल चुनें। एक लीड-जेन डायरेक्टरी को दिन एक से हर लिस्टिंग पेज में विश्वास सिग्नल और रूपांतरण तत्व बेक किए गए चाहिए -- बाद में उन्हें जोड़ना हमेशा लगता है उससे अधिक गड़बड़ होता है।
---
FAQ
क्या Google के 2024 एल्गोरिदम अपडेट के बाद प्रोग्रामेटिक SEO अभी भी काम करता है?
हाँ, लेकिन "काफी अच्छा" की सीमा दो साल पहले की तुलना में काफी अधिक है। मार्च 2024 के Google कोर अपडेट ने बहुत सारे पतली प्रोग्रामेटिक साइटों को कठोर प्रभावित किया -- विशेष रूप से टेम्पलेटेड AI सामग्री पर कोई अद्वितीय डेटा के बिना निर्भर करने वाले। अद्वितीय डेटा गहराई और स्पष्ट इकाई संबंधों के साथ साइटें इसे ठीक से सह सकीं। कुछ वर्टिकल में, वे साइटें वास्तव में जमीन हासिल करीं जब पतले प्रतियोगियों को फ़िल्ट किया गया।March 2024 Google core update hit a lot of thin programmatic sites hard -- particularly those relying on templated AI content with no unique data. Sites with genuine data depth and clear entity relationships weathered it fine. In some verticals, those sites actually gained ground as thin competitors got filtered out.
मुझे पहले दिन कितने पेज लॉन्च करने चाहिए?
जितने की जरूरत हो Google को concept दिखाने के लिए। मैं 50,000 पतले पेजों की तुलना में 500 सच में अच्छे पेज लॉन्च करना पसंद करूँ। पहले अपने hub pages और टॉप 20 category × location combinations बनाएँ। उन्हें indexed करवाएँ, कुछ शुरुआती ranking signals पाएँ, फिर बाकी को बैच में roll out करें। पहले महीने में 100,000 पेजों तक जल्दबाजी करना लगभग हमेशा गलती होती है।
मुझे कौन सा CMS या tech stack इस्तेमाल करना चाहिए?
अधिकांश क्लाइंटों के लिए मैं अभी भी WordPress का उपयोग करता हूं एक कस्टम पोस्ट प्रकार के साथ और ACF Pro डेटाबेस से खींचते हुए। यह ग्लैमरस नहीं है लेकिन यह निर्माण के लिए तेज़ है, हाथ से उतारना आसान है, और SEO के लिए प्लगइन इकोसिस्टम (विशेष रूप से Rank Math) परिपक्व है। उच्च-स्केल परियोजनाओं के लिए -- 50,000 पेज से अधिक -- मैं आमतौर पर Next.js के साथ headless जाता हूं और PostgreSQL या Supabase बैकएंड के साथ। Next.js में SSG/ISR क्षमताएं स्केल पर क्रॉल व्यवहार को स्वच्छ रखने के लिए वास्तव में उपयोगी हैं।WordPress with a custom post type and ACF Pro pulling from a database. It's not glamorous but it's fast to build, easy to hand off, and the plugin ecosystem for SEO (Rank Math, specifically) is mature. For higher-scale projects -- over 50,000 pages -- I'll typically go headless with Next.js and a PostgreSQL or Supabase backend. The SSG/ISR capabilities in Next.js are genuinely useful for keeping crawl behaviour clean at scale.
एक programmatic directory ranking करने से पहले कितना समय लगता है?
वास्तविकता में? मतलब की ट्रैफिक के लिए छह से नौ महीने, यह मानते हुए कि आपने आर्किटेक्चर सही किया है और आप ऐसे वर्टिकल में हैं जहाँ Google स्पष्ट रूप से बड़े प्रतिष्ठित ब्रांड्स को प्राथमिकता नहीं दे रहा है। मैंने असाधारण मामले चार महीने में गति पकड़ते देखे हैं और निराशाजनक मामले 18 महीने लगाते देखे हैं। सबसे महत्वपूर्ण वेरिएबल, ईमानदारी से कहूँ तो, टॉपिकल अथॉरिटी है -- आपकी साइट दिन एक से ही किसी विशिष्ट वर्टिकल में दक्षता कितनी स्पष्टता से स्थापित करती है।
---
डायरेक्टरी SEO प्लेबुक मर नहीं गया है। इसे Google ने सही तरीके से प्राइस-डिस्क्रिमिनेट कर दिया है। जो ऑपरेटर 2023-24 में जल गए थे वे ज्यादातर वॉल्यूम के लिए बिल्डिंग कर रहे थे, वैल्यू के लिए नहीं। पहले वैल्यू के लिए बिल्डिंग करें -- गहरा डेटा, ईमानदारी से एनरिचमेंट, एक लिंक आर्किटेक्चर जो इस बात का सम्मान करता है कि Google वास्तव में कैसे क्रॉल करता है -- और वॉल्यूम समय के साथ खुद ही ठीक हो जाता है। यह हमेशा से ऐसा ही रहा है।