लेख publish करने से पहले revenue check ऑटोमेट करें: Claude Code से CTA की चूक रोकें

एक सुबह analytics खोलते ही मैं जम गया। पिछले दिन publish किए लेख का PV सामान्य से तीन गुना था। फिर भी free PDF के registration शून्य, और course की एक भी click नहीं। यानी “viral तो हुआ, पर एक रुपया भी नहीं हिला” वाली हालत।

जांचा तो वजह बेहद मामूली निकली। लेख के आखिर में लगा sign-up बटन छह महीने पहले बंद हो चुके एक पुराने product page की तरफ इशारा कर रहा था। ऊपर से English version का body बीच में जाकर अचानक English में बदल जाता था, और विदेशी पाठक वहीं छोड़कर चले जाते थे। असली body तो ठीक से लिखा था — पर आखिरी चंद लाइनों में सब बह गया।

उसी दिन से मैंने “लेख लिखने का काम” और “यह publish करने लायक है या नहीं, यह जांचने का काम” पूरी तरह अलग कर दिए। दूसरा काम हर बार हाथ से करूं तो छोड़ ही दूंगा, इसलिए उसे एक तय ढांचे के रूप में Claude Code को सौंप दिया है। आज वही ढांचा, copy-paste लायक रूप में पूरा सामने रख रहा हूं।

मुख्य बातें

• PV बढ़ने के बावजूद sign-up न बढ़ने की ज्यादातर वजह “publish से पहले पकड़ी जा सकने वाली गलतियां” होती हैं — टूटा link, पुराना product page, या आधा English में रह गया body।
• publish से पहले देखने के items को 9 पर तय कर लें और हर बार एक ही क्रम में जांचें, तो चूक बहुत घट जाती है।
• Claude Code को सौंपें “page खोलकर items को यंत्रवत जांचने” का हिस्सा। कौन-सा बटन main रहेगा, यह इंसान तय करता है।
• एक लेख में sign-up बटन एक ही रखें — पाठक उलझता नहीं और अगले कदम तक पहुंचना आसान होता है।
• जांचा हुआ ब्योरा एक log में रखें, ताकि बाद में “किस आधार पर publish किया” यह pता चल सके।

publish से पहले देखने के 9 items तय करें

“ठीक से जांच लेना” कहने से न इंसान कुछ करता है, न AI। जांच का मतलब है ठोस items की एक list। मेरे तय किए 9 items ये हैं।

#	जांच का item	किस पर ध्यान दें
1	page खुलता है या नहीं	server 200 लौटाता है या नहीं (404 या 500 तो नहीं)
2	heading सही है या नहीं	page के ऊपर का बड़ा heading लेख title से मेल खाता है या नहीं
3	canonical URL	canonical URL उसी लेख के अपने URL पर है या नहीं
4	hero image	image दिख रहा है या नहीं (पुराना image या बिना image तो नहीं)
5	body की भाषा	हर भाषा version में शुरुआत से उसी भाषा में लिखा है या नहीं
6	free PDF का link	registration बटन मौजूद है और उसका link जिंदा है या नहीं
7	course link	link सही product page पर जाता है या नहीं (किसी और product पर तो नहीं)
8	consultation का route	link consultation page पर जाता है या नहीं
9	mobile display	horizontal scroll तो नहीं आ रहा (कुछ बाहर तो नहीं निकल रहा)

खास ध्यान items 3 और 7 पर। अगर canonical home page या किसी और लेख पर इशारा कर रहा हो, तो search engine उसी को “असली” मानता है और आपके लेख की value नहीं बनती। link का गलत target उन्हीं लेखों में सबसे ज्यादा होता है जो copy-paste से बने हों।

AI को क्या सौंपें, और इंसान क्या तय करे

यहां दोनों को मिला दिया तो दुर्घटना तय है। रेखा साफ खींचते हैं।

Claude Code को सौंपने वाली चीजें वे जांच हैं जो यंत्रवत तय हो जाती हैं। page खोलना, heading पढ़ना, link का target निकालना, image दिख रहा है या नहीं देखना, mobile width पर layout जांचना। यह इंसान करे तो उबाऊ है, और उबाऊ चीज वह छोड़ देता है — इसलिए हर बार AI से करवाएं।

इंसान के तय करने वाली चीजें वे हैं जिनमें judgment चाहिए। इस लेख में main बटन कौन-सा होगा। body का phrasing स्वाभाविक है या नहीं। कहीं किसी पुराने product का तो प्रचार नहीं हो रहा। और “क्या यह लेख सच में publish करने लायक है” — यह आखिरी फैसला। इसे AI पर पूरी तरह छोड़ दिया, तो link तो जिंदा रहेगा पर content भटका हुआ लेख छप जाएगा।

उलझन में सीधा नियम: जिसका जवाब एक ही तय हो वह AI, जिसमें पसंद या strategy घुसी हो वह इंसान। link 200 लौटाता है या नहीं — यह एक ही तय है, इसलिए AI। तीन बटनों में से किसे उभारना है — यह strategy है, इसलिए इंसान।

copy-paste वाला instruction template

यह instruction सीधे Claude Code में paste कर सकते हैं। बस repository नाम और जांचने वाले URL अपने हिसाब से बदल दें।

नीचे दिए हर URL पर publish से पहले की जांच चलाएं।
देखें कि: page 200 पर खुले, बड़ा heading लेख title से मेल खाए,
canonical URL उसी लेख पर हो, hero image दिखे,
body उसी भाषा में लिखा हो, free PDF का registration बटन जिंदा हो,
course link सही product page पर जाए, consultation page का link सही हो,
और mobile width पर horizontal scroll न आए।

हर URL के लिए एक लाइन में, pass हुए items और fail हुए items अलग-अलग रिपोर्ट करें।
सिर्फ "200 पर खुल गया" को pass न मानें। कोई item fail हो, तो
उसकी संभावित वजह और कौन-सी file ठीक करनी है, यह भी लिखें।

आखिरी दो वाक्य ही जान हैं। “200 पर खुला = OK” पर रुक गए, तो सबसे आम गलती — link का गलत target — छूट जाती है। fail हुए items हमेशा अलग रिपोर्ट करवाएं और ठीक करने की जगह तक बताने को कहें, ताकि सीधे सुधार शुरू हो सके।

copy-paste से चलने वाली judgment script

जांच के नतीजों को इकट्ठा करके “publish करें या नहीं” यंत्रवत लौटाने वाला हिस्सा code में रख लें, तो हर बार एक जैसा रहता है। Node.js पर चलने वाला सबसे छोटा version यह रहा।

// publish से पहले हर हाल में pass कराने वाले 9 items
const requiredChecks = [
  "page 200 पर खुले",
  "बड़ा heading लेख title से मेल खाए",
  "canonical उसी लेख पर हो",
  "hero image दिखे",
  "body उसी भाषा में हो",
  "free PDF का registration बटन जिंदा हो",
  "course link सही product page पर हो",
  "consultation का link सही हो",
  "mobile width पर horizontal scroll न हो",
];

// passed में pass हुए items के नाम की array पास करें
function summarizeSmokeResult(passed) {
  const missing = requiredChecks.filter((check) => !passed.includes(check));
  return {
    ok: missing.length === 0,
    missing,
    nextAction: missing.length === 0 ? "publish करें" : "ठीक करके दोबारा जांचें",
  };
}

// उदाहरण: सिर्फ course link fail हुआ
const passed = requiredChecks.filter((c) => c !== "course link सही product page पर हो");
const result = summarizeSmokeResult(passed);

console.log(result.ok ? "publish OK" : "publish NG");
console.log("fail हुए items:", result.missing);
console.log("अगला कदम:", result.nextAction);

यह script चलाने पर publish NG, fail हुए item का नाम, और अगला कदम दिखता है। एक भी item कम पड़े तो ok false हो जाता है, इसलिए “लगभग ठीक है” कहकर publish करने वाली दुर्घटना नहीं होती। बस passed array को ऊपर वाले instruction से AI द्वारा जांचे नतीजों से भर दें।

तीन मौके जहां यह सच में काम आया

1. एक दिन में कई लेख publish करने वाले दिन एक साथ तीन लेख निकालने वाले दिन जांच ढीली पड़ जाती है। हर लेख को एक-एक करके mobile width में खोलें, heading, body की शुरुआत और sign-up बटन के पास तक scroll करके देखें। English के अलावा किसी version में body English में रह गया हो, तो उसी वक्त publish रोक दें। जिस दिन जांच ढीली होने का खतरा हो, उसी दिन तय list सबसे ज्यादा काम आती है।

2. लोकप्रिय लेख का सिर्फ बटन बदलते वक्त खूब पढ़े जाने वाले लेख का आखिरी बटन एक ही बदलना हो, तब भी “जुड़े हुए हिस्से ढूंढकर ठीक कर दो” कहना बहुत चौड़ा है। पहले तय करें — किन files को छूना है, किन्हें नहीं, कौन-से URL जांचने हैं, हर link का target क्या है। बस इतने से काम के बाद की जांच “लगता है ठीक है” से बदलकर “इस सबूत पर publish कर सकते हैं” बन जाती है।

3. बहुभाषी लेखों की quality जांच लेख की setting में भाषा सही लिखी हो, पर body English में ही रह गया हो, तो वह publish-quality नहीं है। हर भाषा में बड़ा heading, body की शुरुआत और बटन के आसपास देखें — क्या उस भाषा के पाठक को साफ है कि अगला कदम क्या है। हिंदी पाठक के लिए free PDF की जानकारी, course का बुलावा और consultation का route — सब हिंदी में स्वाभाविक रूप से पढ़ने लायक होने चाहिए।

आम गलतियां और उन्हें ठीक करना

गलती 1: सिर्फ local पर build pass हो गया, इसी पर “publish हो गया” रिपोर्ट करना अपने machine पर build सफल हो जाए, इसका मतलब यह नहीं कि live page सही दिखेगा। ठीक करने का तरीका: जांच का target “local build का नतीजा” नहीं, “live URL का असली page” रखें। AI को भी साफ कहें — “live URL खोलकर जांचो।”

गलती 2: सारे sign-up बटन एक साथ लगा देना free PDF, course A, course B और consultation को एक ही आकार में सजा दें, तो पाठक तय नहीं कर पाता किसे दबाए, और आखिर में एक भी नहीं दबाता। ठीक करने का तरीका: एक लेख में एक main बटन तय करें, बाकी को हल्के सहायक link की तरह रखें।

गलती 3: link किसी और product पर चला जाना “free PDF” लिखा हो पर click करते ही paid course खुले — यह copy-paste लेखों में बार-बार होता है। ठीक करने का तरीका: item 7 की link-target जांच AI से हर बार करवाएं और product ID तक आंख से मिलाएं।

गलती 4: वापस लाने का तरीका तय किए बिना बड़े बदलाव करना publish से ठीक पहले बड़े दायरे में बदलाव कर दें और गड़बड़ होने पर वापस न ला पाएं — यह सबसे बुरा है। ठीक करने का तरीका: एक बार के काम को उतने ही दायरे में रखें जिसके लिए “गड़बड़ हो तो वापस कैसे लाएं” यह पहले से लिख सकें। जिस काम का rollback नहीं लिख सकते, वह उस बार के लिए बहुत बड़ा है।

अक्सर पूछे जाने वाले सवाल

Q. PV तो बढ़ा पर sign-up नहीं बढ़ रहे। सबसे पहले क्या देखूं? A. पहले sign-up बटन का link target और body की भाषा देखें। link पुराने product page पर रह जाना, या विदेशी पाठक वाले version का English न होना — यही दो सबसे बड़ी वजहें हैं। ये publish-जांच के items 5, 6 और 7 हैं।

Q. क्या यह जांच हर बार जरूरी है? झंझट लगती है। A. हां, हर बार जरूरी है। इसीलिए इसे हाथ से न करें — इस लेख का instruction Claude Code को देकर यंत्रवत करवाएं। जितनी झंझट वाली जांच होगी, इंसान व्यस्त दिन उतनी ही जल्दी छोड़ देगा। और जिस दिन छोड़ता है, उसी दिन दुर्घटना होती है।

Q. बटन एक ही रखूं, तो दूसरे products के रास्ते कम नहीं हो जाएंगे? A. रास्तों की गिनती से ज्यादा अहम यह है कि पाठक बिना उलझे एक बटन दबा पाए। कई सजा दें तो वह चुन नहीं पाता और छोड़ देता है। एक main तय करें, और सहायक link लेख के बीच में स्वाभाविक रूप से 1–2 ही रखें — यही सही संतुलन है।

Q. canonical URL इतना अहम क्यों है? A. search engine canonical के रूप में बताए page को ही “असली” मानकर value देता है। यह किसी और लेख या home page पर इशारा करे, तो आपके लिखे लेख की नहीं, उस दूसरे page की value बनती है और search ranking भी उधर ही जमा हो जाती है।

Q. जांच का log किसलिए रखें? A. बाद में “किस आधार पर publish किया” यह ढूंढ पाने के लिए। समस्या आने पर body, बटन, link या consultation-route में से कहां चूक हुई, यह अलग करना आसान होता है। log न हो, तो अगली बार शून्य से दोबारा जांचना पड़ता है।

जांचा हुआ ब्योरा एक पन्ने में रखें

publish के बाद एक छोटा note रख लें, तो अगली बार की जांच बहुत आसान हो जाती है। इतना ही काफी है।

- लेख: claude-code-revenue-smoke-test
- publish तारीख: 2026-06-14
- जांचा सबूत: live URL, बड़ा heading, canonical, hero image, body की भाषा, बटन का link target
- main बटन: course link (खुद आगे बढ़ने वाले पाठकों के लिए)
- अगला देखने वाला आंकड़ा: PV, PDF registration, course click, consultation page पर जाना

आंकड़े देखते वक्त भी सिर्फ PV से फैसला न करें। free PDF registration, course click और consultation page पर जाना — सबको एक ही तारीख पर पास-पास रखें। beginner वाले लेख में PDF registration, और settings या permission वाले लेख में course click बढ़ना चाहिए — इस अनुमान से मिलाकर देखें। यह आदत हो, तो रोज की posting “बस निकाल देने का काम” से बदलकर “CTA को धीरे-धीरे ठीक करने वाला तंत्र” बन जाती है।

यह “मशीन को सौंपने वाली जांच” और “इंसान के तय करने वाला judgment” वाली रेखा सिर्फ revenue-check में नहीं, और जगह भी उसी तरह काम आती है। गैर-इंजीनियर के लिए Claude Code का पूरा खाका Claude Code गैर-इंजीनियर के लिए में है, और रोज के काम तेज करने की छोटी तरकीबें Claude Code productivity tips में। जांच AI से सही करवाने के लिए instruction की सटीकता चाहिए, इसलिए Claude Code prompt की व्यावहारिक तकनीकें भी साथ पढ़ें।

वैसे, AI से file पढ़वाने या link जांच करवाने जैसे काम जिस तंत्र पर टिके हैं, वह आधिकारिक Claude Docs में देखा जा सकता है। लगे कि behavior बदल गया है, तो पहले primary source देखना ही आखिरकार सबसे तेज है।

मैंने असल में आजमाकर क्या पाया

इस ढांचे को अपनी site पर करीब दो हफ्ते चलाया। जांचना यह था कि “publish से पहले की 9-item जांच सच में चूक घटाती है या नहीं।”

नतीजा — जब सिर्फ “page 200 पर खुलता है” देखता था, तब बिना पकड़े निकल जाने वाली कई समस्याएं इस बार पकड़ी गईं। ठोस रूप से: किसी और लेख का hero image वैसे ही रखकर publish करने वाले 2 मामले, sign-up बटन पुराने product पर इशारा करने वाला 1 मामला, और English version का body बीच से हिंदी में रह जाने वाला 1 मामला। ये सब “200 पर खुलता है” वाली जांच में pass गिने जाते।

खास असर हुआ sign-up बटन एक लेख में एक ही रखने वाले नियम से। free PDF, course और consultation को एक ही वजन में सजाए लेख को एक main बटन पर ठीक किया, तो बटन की click दर साफ बढ़ी। पाठक जितने कम विकल्प हों उतना ज्यादा हिलता है — यह आंकड़ों में महसूस हुआ।

उल्टा यह भी पता चला कि यह जांच हाथ से करते रहें तो टिकती नहीं। शुरुआती कुछ दिन हाथ से की, पर व्यस्त दिन आसानी से छोड़ दी। instruction और script के रूप में हर बार एक ही क्रम में चलाने लगा, तब जाकर आदत बनी।

publish से पहले की यह नीरस जांच एक तंत्र बना लें — PV को revenue में बदलने का यही सबसे सस्ता बीमा साबित हुआ। अगर इसे कंपनी की blog-ops या team के publish flow में जोड़ना हो, तो training / consultation में आपके असली setup के हिसाब से यही ढांचा मिलकर design कर सकते हैं।