PV तो आ रहा है पर बिक्री नहीं: हर article को अगले एक कदम से जोड़ने वाला routing map
PV बढ़ रहे पर PDF और consultation नहीं चल रहे? हर article के लिए सिर्फ एक 'next offer' तय करने वाला routing table, copy-paste code के साथ.
पिछले महीने मेरे ब्लॉग पर सबसे ज्यादा पढ़ा गया article था “Claude Code परिचय”. पूरे महीने में 3,200 PV. आंकड़ा बुरा नहीं है. लेकिन उस article से free PDF download करने वाले लोग सिर्फ 4 थे. पूरे महीने में, सिर्फ 4.
कुछ गड़बड़ लगी तो मैंने article के आखिर में जाकर देखा, और वजह तुरंत समझ आ गई. आखिरी paragraph में free PDF, paid template pack, setup guide, consultation form, और product list — पांचों link एक ही size में, एक साथ खड़े थे.
ऐसे में reader कुछ चुन ही नहीं पाता. परिचय article तक पहुंचा इंसान बस इतना जानना चाहता है कि “अब अगला कदम क्या है”, पर उसके सामने अचानक 5 विकल्प रख दिए जाते हैं. नतीजा यह कि वह कुछ भी click नहीं करता, tab बंद करता है, और बात खत्म.
Article पढ़ा जा रहा है फिर भी बिक्री नहीं हो रही. यह रुकावट न तो लेखन की quality की वजह से है, न Claude Code की समझदारी की. असली वजह है — एक ही article में 5-5 offers रख देना. आज हम इसी को बदलेंगे: हर article के लिए सिर्फ एक “अगला कदम” तय करने वाला routing table बनाएंगे.
मुख्य बातें
- PV होने के बावजूद PDF या consultation न चलने की वजह है — article के आखिर में बहुत ज्यादा offers. 5 विकल्प सामने आते ही reader कुछ नहीं चुनता.
- हल है: article के “search intent” को देखकर, हर article के लिए सिर्फ एक offer तय करने वाला routing table बनाना.
- परिचय article के लिए free PDF, request लिखने में अटके लोगों के लिए prompt pack, setup और permissions वाले article के लिए paid guide, team rollout के लिए consultation — हर intent के लिए अलग exit.
- Claude Code को सौंपिए सिर्फ “कौन सी intent पर कौन सा exit” वाला mechanical routing. “इस reader को क्या suggest करना चाहिए” — यह आखिरी फैसला इंसान करता है.
- Publish के बाद पूरा article दोबारा मत लिखिए. सिर्फ शुरुआत का bounce और पहले link का click देखिए, और कमजोर एक जगह को ठीक कीजिए.
”अगला एक कदम” सिर्फ एक रखने से असर क्यों होता है
जितने ज्यादा विकल्प हों, इंसान उतना ही फैसला नहीं कर पाता. behavioral economics में इसे “paradox of choice” कहते हैं. एक मशहूर experiment है — जिस shelf पर jam के 24 flavors रखे थे, उससे ज्यादा बिक्री उस shelf से हुई जहां सिर्फ 6 flavors थे.
Article के आखिर के link भी ठीक ऐसे ही हैं. Free PDF, template pack, setup guide, consultation, product list — सब अच्छी नीयत से एक साथ रख देने पर, reader के दिमाग में “इनमें से मेरे लिए कौन सा है?” वाली तुलना शुरू हो जाती है. तुलना झंझट का काम है, इसलिए ज्यादातर लोग वहीं छोड़कर चले जाते हैं.
इसलिए exit हर article पर सिर्फ एक रखिए. पर इसका मतलब “हमेशा free PDF” जैसा कोई fix नियम नहीं है. हर article पर आने वाले reader की अगली ज़रूरत अलग होती है. परिचय पढ़ने वाला और permissions setup में अटका इंसान — दोनों को suggest करने लायक चीज़ बिलकुल अलग है. इसी “article की intent के हिसाब से exit बदलने” वाले सिस्टम को आज हम table और code से बनाएंगे.
search intent के हिसाब से exit तय करने वाला routing table
पहले अपने ब्लॉग के article को इस आधार पर बांटिए कि “reader किस परेशानी में यहां आया”. इस परेशानी को मैं यहां search intent कह रहा हूं. मैंने इसे 5 हिस्सों में बांटा है.
| search intent (reader की परेशानी) | उदाहरण article | अगला एक offer |
|---|---|---|
| बस शुरू करना है (beginner) | परिचय, install steps | free PDF |
| हर बार वही request लिखना झंझट है | prompt की टिप्स, request का format | prompt pack (paid) |
| setup, permissions, safe operation में अटकता हूं | permissions setup, CLAUDE.md लिखना | setup guide (paid) |
| team या company में production में लाना है | team operation, production risk, cost estimate | consultation |
| इनमें से कोई नहीं | random posts, news | free PDF (default exit) |
असली बात दायीं तरफ के column में है. एक article के लिए यहां सिर्फ एक चीज़ आएगी. अगर एक से ज्यादा लिखने का मन हो, तो यह सबूत है कि उस article का reader अभी धुंधला है.
मान लीजिए permissions वाले article में “free PDF भी, paid guide भी, consultation भी” — सब रखने का मन हुआ, तो रुकिए. permissions में फंसे इंसान को अगली चीज़ लगभग पक्का “और detail वाली setup की guide” ही चाहिए. वहां free PDF मिला देने से, paid guide के लिए एकदम सही reader को आप सस्ते वाले विकल्प की तरफ भगा देते हैं.
यह table बन जाने के बाद, बस हर article की “कौन सी intent है” — एक तय कीजिए और exit लगा दीजिए. जिन article पर फैसले में झिझक हो, उनमें आमतौर पर एक ही article में दो विषय मिले होते हैं. ऐसे में article को अलग कर देना routing और पढ़ने — दोनों के लिए बेहतर है. अगर reader image साफ नहीं हो रहा, तो non-engineers के लिए Claude Code पढ़ने वाले audience को ध्यान में रखकर सोचिए — वे “अगला क्या” सबसे ज्यादा खोजते हैं.
AI को क्या सौंपें, और इंसान क्या तय करे
यहां एक आम गलती है — पूरी routing Claude Code पर छोड़ देना. “ठीक-ठाक हर article पर CTA लगा दो” बोल दीजिए, तो वह context को हद से ज्यादा पढ़कर अजीब exit लगा देता है.
बंटवारा ऐसे कीजिए.
- Claude को सौंपें: routing table के हिसाब का mechanical काम. article का intent label लेकर उससे जुड़ा exit लगाना. article के आखिर का text तय किए गए एक exit के हिसाब से लिखना. कहीं 2 या ज्यादा CTA तो नहीं बचे, यह mechanically check करना.
- इंसान तय करे: उस article की search intent कौन सी है, यह आखिरी फैसला. कीमत या presentation बदलना. नई intent category जोड़ना. यह reader की भावना पढ़ने का काम है, इसलिए इंसान करेगा.
यानी “कौन सी intent” — एक शब्द में इंसान तय करे, और “तो कौन सा exit” व “text का draft” Claude से करवाए. इस बंटवारे में हादसा नहीं होता. वैसे, Claude Code को इस तरह के तय-शुदा काम एक साथ सौंपने का basic तरीका Anthropic की आधिकारिक Claude Code documentation में भी समझाया गया है.
Request करते समय मेरा prompt format ऐसा रहता है. इसे copy कीजिए और सिर्फ कोट्स के अंदर का हिस्सा अपने article के हिसाब से बदल दीजिए.
नीचे दिए article पर सिर्फ एक exit (अगला suggest करने वाली चीज़) लगाओ.
- article का slug: "claude-code-permissions-guide"
- search intent: "setup, permissions, safe operation में अटकना"
- routing table में इससे जुड़ा exit: "setup guide (paid)"
- exit के link का URL: "https://example.com/setup-guide"
शर्तें:
1. article के आखिर में exit सिर्फ एक. कोई और link मत लगाओ.
2. "खरीद लीजिए" मत लिखो; बल्कि इस article का काम कल भी
दोहराने में वह guide कैसे काम आती है, यह 1-2 वाक्य में लिखो.
3. कहीं 2 या ज्यादा exit तो नहीं बचे, आखिर में खुद check करके report करो.
आखिरी बात नंबर 3 सबसे ज़रूरी है. Claude को self-check करने का निर्देश शब्दों में दे देने पर link गिनना भूलने की गलती बहुत कम हो जाती है.
copy-paste से चलने वाली script: CTA की गिनती करके चेतावनी देती है
सिर्फ इंसानी नज़र पर भरोसा करेंगे, तो busy दिन में पक्का चूक होगी. इसलिए “article के आखिर में 2 या ज्यादा exit तो नहीं” — यह mechanically गिनने वाला एक छोटा darbaan लगाते हैं. Node.js पर चलने वाली, बिना किसी dependency library वाली script है.
import { readFile } from "node:fs/promises";
// exit मानी जाने वाली link patterns (अपने routing के हिसाब से जोड़ें)
const offerPatterns = [
{ name: "free PDF", re: /\/thanks\// },
{ name: "prompt pack", re: /gumroad\.com\/l\/huqrgo/ },
{ name: "setup guide", re: /gumroad\.com\/l\/ceyhda/ },
{ name: "consultation", re: /\/training\// },
];
// सिर्फ article का आखिरी हिस्सा (आखिरी heading के बाद) देखें
function tailSection(markdown) {
const idx = markdown.lastIndexOf("\n## ");
return idx === -1 ? markdown : markdown.slice(idx);
}
async function checkOffers(filePath) {
const text = await readFile(filePath, "utf8");
const tail = tailSection(text);
const found = offerPatterns.filter((p) => p.re.test(tail));
if (found.length === 0) {
console.log(`⚠ ${filePath}: एक भी exit नहीं है. अगला कदम न देने वाला article है.`);
} else if (found.length > 1) {
const names = found.map((f) => f.name).join(", ");
console.log(`⚠ ${filePath}: ${found.length} exit हैं (${names}). सिर्फ एक रखें.`);
} else {
console.log(`OK ${filePath}: exit सिर्फ एक है — "${found[0].name}".`);
}
}
// इस्तेमाल: node check-offers.mjs <article file का path>
const target = process.argv[2];
if (!target) {
console.error("इस्तेमाल: node check-offers.mjs <article file>");
process.exit(1);
}
checkOffers(target);
इसे check-offers.mjs नाम से save कीजिए और ऐसे चलाइए.
node check-offers.mjs ./content/blog/claude-code-permissions-guide.mdx
अगर 2 या ज्यादा exit बचे हों, तो वहीं चेतावनी मिल जाती है. Publish से पहले इसे हर article पर चला दीजिए, तो “गलती से 5 link एक साथ रख छोड़ना” physically हो ही नहीं पाएगा. मैं publish flow के आखिर में यह एक line लगाता हूं, और इसी वजह से ऊपर बताए जैसे हादसे रुक गए.
जिन 3 जगहों पर मैंने असल में इस्तेमाल किया
1. परिचय article का exit सिर्फ free PDF कर दिया 3,200 PV वाले परिचय article से paid template और consultation link हटाकर, सिर्फ free PDF छोड़ा. वजह सीधी है — परिचय पर आया इंसान अभी पैसे देने वाले stage पर है ही नहीं. नतीजा: PDF download महीने के 4 से बढ़कर 31 हो गए. पहले free में list में जोड़ लो, फिर आगे के email से paid material बताओ — यह शुरू से बेचने की तुलना में ज्यादा चलता है.
2. prompt वाले article को सीधे paid template pack से जोड़ा request लिखने का तरीका खोजते हुए आया इंसान Claude Code खुद तो चला ही लेता है. इसलिए उसे free PDF की ज़रूरत नहीं. इस audience को prompt में महारत वाले article से, सिर्फ paid template pack को exit बनाया. “कल भी उसी quality की request दोहराने में काम आएगा” — यह एक वाक्य जोड़ते ही click rate बढ़ गया.
3. permissions और setup वाले article को consultation से जोड़ा team rollout या production operation के risk छूने वाले article में self-serve material काफी नहीं. क्योंकि reader जानना चाहता है “मेरे environment में यह safe है या नहीं” — यह उसका अपना individual फैसला है. permissions guide जैसे article में consultation form को इकलौता exit बनाया. यहां free PDF मिला देने से, असल में consultation तक पहुंचने वाले company के ज़िम्मेदार को आप एक मुफ्त booklet से संतुष्ट करके खो देते हैं.
अक्सर होने वाली गलतियां, और उन्हें ठीक करने का तरीका
गलती 1: कमजोर link दिखते ही पूरा article दोबारा लिख देना “PDF का click कम है” — यह दिखते ही पूरा article rewrite करने का मन होता है. पर यह धीमा भी है और सही निशाने पर लगने की संभावना भी कम. ठीक सिर्फ कमजोर एक जगह कीजिए. PDF कमजोर है, तो body में उठाए गए काम को “PDF में कैसे दोहराया जाए” — यह 1-2 वाक्य आखिर में जोड़ देना. ज्यादातर इतना ही काफी होता है.
गलती 2: local build pass होते ही publish हो गया मान लेना अपने यहां build pass होने पर भी, public URL पर कोई और article या homepage दिख रहा हो सकता है. सिर्फ HTTP 200 लौटना काफी नहीं. Publish के बाद असली URL खोलकर heading, hero image, body की शुरुआत, और exit link — ये “उसी article के” हैं या नहीं, आंख से देख लीजिए.
गलती 3: क्या try किया, यह record न करना exit बदलकर click कैसे बदला — यह note में न रखने पर अगले महीने फिर वही try करते रह जाते हैं. “इस article की intent ○○ की, exit △△ किया, नतीजा click □ बार” — बस एक line रख दीजिए. इतने से ही फैसले जमा होते जाते हैं.
ठीक करने का basic नियम हमेशा एक ही है: गलती दिखे तो पूरा article नहीं, पहले failure example के पास सबूत लाओ, exit की गिनती घटाओ, और अगले action को measurable बनाओ. बस इस क्रम का पालन करने से सुधार की रफ्तार बदल जाती है.
अक्सर पूछे जाने वाले सवाल
Q. क्या सच में हर article में सिर्फ एक exit रखना चाहिए? मैं free और paid — दोनों रखना चाहता हूं. A. आखिर का main exit एक ही रखिए. अगर free वाला safety net रखना ही है, तो paid exit को उभारिए और free को उसके नीचे छोटे में सिर्फ एक line में जोड़िए. एक ही size में 2 रखेंगे, तो reader लगभग पक्का सस्ते वाले या कुछ-न-करने वाले रास्ते बह जाएगा.
Q. routing table की intent categories 5 से ज्यादा कर सकते हैं? A. कर सकते हैं, पर शुरुआत 5 से ही करने की सलाह है. जितनी ज्यादा categories, उतना समय कौन सा article किसमें जाए — यह तय करने में लगता है. चलाते-चलाते जब “किसी भी हाल में 5 में न समाने वाला article group” दिखे, तभी एक जोड़ना सही रहता है.
Q. क्या Claude Code से सारे article की CTA एक साथ करवा सकते हैं? A. एक साथ करवाना खतरनाक है. article का intent label सिर्फ इंसान एक-एक article के लिए तय करे, उसके बाद text generation और check Claude को सौंपे. intent का फैसला तक सौंप देने पर वह context हद से ज्यादा पढ़कर गलत exit लगा सकता है. पहले कुछ article पर try करके फिर बढ़ाइए.
Q. मेरे पास click मापने का कोई setup नहीं है. शुरुआत कैसे करूं?
A. शुरू में perfect measurement का लक्ष्य मत रखिए — link में एक निशान वाला parameter (जैसे ?from=intro-article) लगा देने भर से पता चल जाता है कि click किस article से आया. access analytics की basics Claude Code की शुरुआत में बताए steps वाली ही सोच से शुरू की जा सकती है.
Q. कम PV वाले article का exit बाद में देखूं तो चलेगा? A. हां. सबसे ज्यादा PV वाले top 10 article से शुरू कीजिए. routing का सुधार PV के अनुपात में असर करता है, इसलिए कम access वाले article ठीक करने का असर दिखना मुश्किल है. पहले कमाई लाने वाले मुख्य entry points को संवारिए.
मैंने इसे आज़माकर क्या पाया
यह routing table अपने ब्लॉग के पूरे 23 article पर लगाकर देखा, तो सबसे ज्यादा असर “exit गिनने वाली darbaan script” का रहा. चलाया तो पता चला — पूरे 8 article में 2 या ज्यादा exit बचे थे, और 3 article में exit बिलकुल शून्य था. मैं खुद को लगता था कि एक पर सीमित कर दिया है, पर पुरानी template के link delete करना भूल जाने से बचे रह गए थे.
intent label दोबारा लगाने का काम मैंने Claude Code पर नहीं छोड़ा — खुद एक-एक article के लिए “यह beginner वाला”, “यह permissions में फंसे लोगों वाला” — तय किया. 23 article में करीब 30 मिनट. उसके बाद text का draft और गिनती की आखिरी check भर Claude को सौंपी, तो आधे दिन में सारे article के exit एक पर आ गए.
एक महीने बाद के आंकड़ों में मैंने पक्का किया — परिचय article का PDF download 4 से बढ़कर 31 हुआ, और कुल PV लगभग वैसा ही रहा. यानी मैंने access नहीं बढ़ाई, बस पहले से आ रहे reader को खोना बंद किया. article बढ़ाने से पहले exit ठीक करना ज्यादा तेज़ है — यही इस बार सबसे ज्यादा समझ आया.
routing से पहले अगर article बनाने का तरीका ही संवारना है, तो Claude Code की शुरुआत से पढ़ना अच्छा रहेगा. company के ब्लॉग या owned media पर team के तौर पर revenue routing design करना हो, तो हम individual training / consultation में साथ बैठकर बनाते हैं.
मुफ़्त PDF: Claude Code cheatsheet
Email डालें और commands, review habits तथा safe workflow वाली एक-page PDF पाएँ.
हम आपका data सुरक्षित रखते हैं और spam नहीं भेजते.
लेखक के बारे में
Masa
Claude Code workflow और team adoption पर काम करने वाला engineer.
संबंधित लेख
Obsidian के पुराने नोट को Claude Code के ब्रीफ में बदलने की 10 मिनट की रूटीन
Obsidian के पुराने नोट को तथ्य, फैसले और अनिश्चित में बाँटकर Claude Code के सीधे काम का ब्रीफ बनाने की 10 मिनट की रूटीन।
लेख publish करने से पहले revenue check ऑटोमेट करें: Claude Code से CTA की चूक रोकें
PV बढ़ा पर sign-up शून्य? वजह अक्सर टूटा link या आधा English body होता है। Claude Code से publish से पहले CTA जांच का तरीका।
Obsidian के नोट को Claude Code आज लागू कर सके, ऐसे request में बदलने का तरीका
बिखरे हुए Obsidian नोट से सिर्फ goal, न छूने वाला हिस्सा और जांच का तरीका निकालकर, Claude Code को सीधे देने लायक छोटी request बनाएं।