ChatGPT, Gemini, Perplexity और Copilot प्रोडक्ट कैसे चुनते हैं, GEO की कौन-सी सलाह असली है, प्रोडक्ट डेटा और फ़ीड में क्या सुधारें, AI रेफ़रल कैसे नापें, और दस बिंदुओं की चेकलिस्ट।
Author
Anichur Rahaman
इस सीरीज़ के पहले भाग में हमने एक छोटी आउटडोर-गियर दुकान की मालिक को देखा था, जिनका सबसे ज़्यादा बिकने वाला जैकेट AI shopping agent ने कभी दिखाया ही नहीं। उन्होंने अपना product data ठीक किया और agent से order आने लगे। अब मंगलवार सुबह 8:40 पर वे दूसरा दरवाज़ा आज़माती हैं। ख़रीदार जैसे लिखते हैं, वैसे ही वे एक आम AI assistant से पूछती हैं, "150 dollar से कम का waterproof जैकेट चाहिए, जो शुक्रवार तक पहुँच जाए।" जवाब में चार जैकेट आते हैं, हर एक के साथ वजह और link। उनका सबसे ज़्यादा बिकने वाला 129 dollar का जैकेट उनमें नहीं है।
वजह ढूँढ़ने बैठती हैं तो पता चलता है कि दिक़्क़त ranking की नहीं है। page पर क़ीमत 129 dollar है, पर product feed में अब भी पिछले महीने की 159 dollar, और जो साइज़ page पर ख़त्म दिखता है, feed में stock में है। assistant को एक ही product के दो सच मिले, वह किसी की पुष्टि नहीं कर पाया, इसलिए उसने किसी का नाम नहीं लिया। (संख्याएँ सिर्फ़ उदाहरण के लिए हैं, किसी असली दुकान की नहीं।)
इसीलिए दुकानदार का सवाल अब बदल गया है। पहले सवाल था, "मैं रैंक कैसे करूँ?" अब सवाल है, "क्या assistant को पता है कि मेरा product मौजूद है? क्या वह मेरे data पर भरोसा करता है? क्या वह उसका नाम लेगा?" इसी सवाल के इर्द-गिर्द जो काम खड़ा हुआ है, उसे generative engine optimization यानी GEO कहा जाता है। आगे देखेंगे कि assistant सिफ़ारिशें कैसे बनाते हैं, GEO की कौन-सी सलाह टिकती है, product data में क्या सुधारना है, नतीजा कैसे नापना है, और अंत में दस बिंदुओं की चेकलिस्ट।
यह "AI agent को बेचना" नाम की तीन भागों की सीरीज़ का दूसरा भाग है। पहले भाग में बताया था कि agentिक कॉमर्स क्या है और अगस्त 2026 तक क्या सचमुच चालू था। तीसरे भाग में है agent के लायक़ checkout और payment।
हर assistant अलग ढंग से बना है, पर प्रक्रिया का ढाँचा लगभग एक-सा है। वह पहले अनुरोध समझता है, फिर कई तरह के स्रोतों से उम्मीदवार product जुटाता है, जिनकी पुष्टि नहीं कर पाता उन्हें छोड़ देता है, और आख़िर में एक छोटा, क्रम से लगा जवाब लिखता है।
स्रोत चार तरह के हैं:
असली मोड़ तीसरा चरण है। जिस product की क़ीमत ग़ायब है, stock के आँकड़े आपस में टकराते हैं, या return policy नहीं लिखी है, वह नीचे की रैंक पर नहीं जाता। आम तौर पर उसे जवाब में रखा ही नहीं जाता, क्योंकि जो assistant बिना सबूत के सिफ़ारिश करे, उसकी अपनी साख गिरती है। पहले भाग में जिस "अदृश्य हो जाने" के जोखिम की बात थी, यह वही है।
GEO के नाम पर जो कुछ बिक रहा है, उसका बड़ा हिस्सा नया label चिपका हुआ पुराना SEO है। Google ख़ुद यह साफ़ कहता है। search में AI feature्स पर अपने guidance में उसने लिखा है कि AI Overviews या AI Mode में आने के लिए कोई अलग शर्त नहीं है, जोड़ने लायक़ कोई ख़ास फ़ाइल या markup नहीं है, और SEO की जानी-पहचानी best practices अब भी लागू हैं (Google Search Central)।
जो बदला है, वह है ज़ोर की जगह। नीचे की table में दोनों की comparison है।
| सवाल | क्लासिक SEO | दुकानों के लिए GEO |
|---|---|---|
| लक्ष्य क्या है? | किसी keyword पर page को रैंक कराना | link के साथ जवाब में नाम आना |
| आपका page कौन पढ़ता है? | पहले crawler, फिर इंसान | retrieval system, जो page को उद्धृत या सारांशित करता है |
| जीतता क्या है? | relevance, link, page experience | जाँचने लायक़ तथ्य, एकरूप data, स्वतंत्र प्रमाण |
| कौन-सा content सबसे काम आता है? | किसी search फ़्रेज़ को निशाना बनाने वाले page | comparison और "किसके लिए सबसे अच्छा" सवालों के सीधी भाषा में जवाब देने वाले page |
| नापते कैसे हैं? | ranking, क्लिक | assistant से referral, ज़िक्र, स्रोत के हिसाब से order |
| क्या जमा करते हैं? | siteमैप | siteमैप, और जहाँ platform लेते हैं वहाँ product feed |
SEO की बुनियादी चीज़ें करते रहिए, और उनके ऊपर product data और स्वतंत्र प्रमाण की दूसरी परत जोड़िए।
search इंजन product page पढ़ना कई साल पहले सीख चुके हैं, और assistant उन्हीं संकेतों पर टिके हैं। चार चीज़ें सबसे अहम हैं।
GTIN (बारकोड के नीचे छपा नंबर), या जिस product पर वह नहीं है उसके लिए ब्रांड के साथ MPN, system को यह पहचानने देता है कि आपकी लिस्टिंग और प्रतिस्पर्धी की लिस्टिंग असल में एक ही आइटम है। identifier न हो तो मिलान टाइटल से होता है, और टाइटल अक्सर बेतरतीब होते हैं।
JSON-LD में schema.org markup इस्तेमाल कीजिए। दुकान के काम के टाइप हैं Product, Offer (क़ीमत, मुद्रा, उपलब्धता), AggregateRating और Review, और policy के लिए MerchantReturnPolicy व OfferShippingDetails। Google इन्हें product, merchant लिस्टिंग और return policy के structured data के रूप में दर्ज करता है। markup कोई ranking की तरकीब नहीं है। page पर जो पहले से लिखा है, यह उसी की मशीन-पठनीय कॉपी है।
markup, page और feed की क़ीमत एक होनी चाहिए, और वही होनी चाहिए जो कार्ट में कटती है। बेमेल क़ीमत feed ख़ारिज होने और product पर से भरोसा घटने की सबसे आम वजह है। यह मार्केटिंग से ज़्यादा data-आर्किटेक्चर की समस्या है: क़ीमत और stock तीन जगह एडिट होंगे तो वे अलग-अलग हो ही जाएँगे।
"30 दिन में मुफ़्त return, आपको कुछ नहीं देना, पाँच कार्यदिवस में मूल payment तरीक़े से refund" एक तथ्य है। "आसान return" तथ्य नहीं है। इलाक़े के हिसाब से डिलीवरी का ख़र्च और समय, कट-ऑफ़ टाइम और return की अवधि सीधे वाक्यों में लिखिए, और markup में भी वही रखिए।
feed आपके product की सूची वाली एक फ़ाइल है, जो तय अंतराल पर किसी platform पर अपलोड होती है। अगस्त 2026 में तस्वीर साल भर पहले से कहीं ज़्यादा खुली है, पर assistant के हिसाब से अलग-अलग है। किसी पर भी भरोसा करने से पहले हर प्रोग्राम की मौजूदा शर्तें देख लीजिए, क्योंकि वे अक्सर बदलती रहती हैं।
| platform | product data कैसे पहुँचता है | आपको क्या करना है |
|---|---|---|
| Google AI Mode, AI Overviews, Gemini shopping | Google का Shopping Graph, जिसे Merchant Center और page का markup data देते हैं | Merchant Center चालू कीजिए, फ़्री लिस्टिंग ऑन कीजिए, feed ताज़ा रखिए |
| ChatGPT | OpenAI का merchant प्रोग्राम product feed लेता है, अपने JSONL फ़ॉर्मैट में या Google से मेल खाते CSV या TSV में | merchant प्रोग्राम में आवेदन कीजिए और उपलब्धता अपडेट रखिए। होस्टेड platform कई बार आपकी तरफ़ से data दे देते हैं |
| Perplexity | Google जैसी feed पर चलने वाला Merchant Program | नामांकन कीजिए और अपनी Merchant Center feed ही दोबारा इस्तेमाल कीजिए |
| Microsoft Copilot | Microsoft Merchant Center पर आधारित Copilot Merchant Program | return और support policy के साथ साफ़-सुथरी feed जमा कीजिए |
दो बातें ग़ौर करने लायक़ हैं। पहली, Google वाली product स्पेक अब सबकी साझा भाषा बन गई है। ऊपर के ज़्यादातर platform इसे ले सकते हैं, इसलिए एक अच्छी तरह सँभाली गई feed से ज़्यादातर काम निपट जाता है। दूसरी, OpenAI की अपनी feed specification में हर पंक्ति के लिए नौ फ़ील्ड ज़रूरी हैं: आइटम ID, टाइटल, विवरण, URL, ब्रांड, विक्रेता का नाम, इमेज URL, उपलब्धता, और मुद्रा कोड के साथ क़ीमत (OpenAI की developer डॉक्यूमेंटेशन)। अगर आप पूरे catalog के लिए ये नौ फ़ील्ड भरोसे के साथ नहीं भर पाते, तो पहले यही ठीक कीजिए।
पहले भाग में बताया था कि मार्च 2026 में ChatGPT के भीतर वाला checkout घटा दिया गया। फिर भी feed मायने रखती है, क्योंकि ख़रीदारी आपकी अपनी site पर होने पर भी वह product खोजे जाने में मदद करती है।
लोग assistant से पूछते हैं "छोटी रसोई के लिए सबसे अच्छा क्या है", "फ़लाँ ब्रांड का alternative क्या है", "कौन-सा सबसे ज़्यादा चलता है"। इन सवालों के जवाब आपकी site किसी से बेहतर दे सकती है, क्योंकि product को आप जानते हैं।
एक आसान परीक्षा: अपने product page को बिना तस्वीरों के, assistant की नज़र से पढ़िए। क्या समझ आता है कि product किसके लिए है, कितने का है, कब पहुँचेगा, और फ़िट न हुआ तो क्या होगा?
आपको सलाह मिलेगी कि site पर llms.txt फ़ाइल जोड़ दीजिए। अगस्त 2026 तक की स्थिति यह है।
llms.txt एक प्रस्ताव है, स्टैंडर्ड नहीं। इसे 2024 में Jeremy Howard ने सुझाया था, एक markdown फ़ाइल के रूप में, जो AI system को site के सबसे काम के pageों तक पहुँचाती है। इसका ब्योरा llmstxt.org पर है। कोई मानक संस्था इसे संचालित नहीं करती। Google के guidance कहते हैं कि उसके AI feature्स में दिखने के लिए नई मशीन-पठनीय फ़ाइलें या AI टेक्स्ट फ़ाइलें ज़रूरी नहीं हैं, और Google के John Mueller सार्वजनिक रूप से कह चुके हैं कि फ़िलहाल कोई भी AI system llms.txt इस्तेमाल नहीं करता। क़रीब 3 लाख डोमेन पर SE Ranking के एक विश्लेषण में भी इस फ़ाइल के होने और AI assistant द्वारा ज़्यादा उद्धृत किए जाने के बीच कोई मापने लायक़ संबंध नहीं मिला।
इसे छापने में लागत मामूली है, और डॉक्यूमेंटेशन siteों के लिए यह ठीक भी हो सकता है। लेकिन दुकान के लिए समय लगाने की सबसे अच्छी जगह यह नहीं है। असली फल product data, feed और स्वतंत्र प्रमाण में मिलता है।
assistant विज़िटर भेजते हैं, पर हमेशा साफ़ label के साथ नहीं। व्यावहारिक तरीक़े के चार हिस्से हैं।
शुरू में आँकड़े छोटे ही होंगे। tracking का असली फ़ायदा यह जानना है कि assistant को कौन-से page और product पसंद आते हैं, ताकि जो चल रहा है उसे बाक़ी जगह दोहरा सकें।
product जवाबों से ग़ायब हो तो चार जाँचें क्रम से कीजिए। हर जाँच अगली का दरवाज़ा है: जो page index ही नहीं हुआ, उस पर बेहतरीन markup से भी कुछ नहीं बदलता।
तीसरी जाँच बार-बार लौटती है, क्योंकि क्रॉलिंग और markup एक बार सेट होते हैं, जबकि क़ीमत और stock रोज़ बदलते हैं। शुरुआती दृश्य का जैकेट इसी तरह feed की एक पुरानी पंक्ति की वजह से छूटा था।
इसे क्रम से कीजिए। हर क़दम अगले को सहारा देता है।
सिर्फ़ एक से पाँच तक के क़दम भी उठा लें तो आप कई दुकानों से आगे होंगे, क्योंकि बाक़ी हर क़दम जिस data पर टिका है, वह इन्हीं पाँच में ठीक होता है।
अब वापस उसी दुकानदार और 129 dollar के जैकेट पर। product रिकॉर्ड को page, markup और feed का इकलौता स्रोत बनाते ही 159 dollar वाली पुरानी पंक्ति ग़ायब हो गई। एक महीने बाद उन्होंने वही सवाल दोबारा पूछा, तो चार में उनका जैकेट तीसरे नंबर पर था, सही क़ीमत और return की अवधि के साथ। जैकेट वही था, बदला सिर्फ़ data। (यह भी उसी काल्पनिक दृश्य का हिस्सा है।)
सिफ़ारिश में नाम आना आधा काम ही है। जब assistant किसी ख़रीदार को आपके पास भेजता है, या ख़रीदारी ख़ुद पूरी करने की कोशिश करता है, तब checkout और payment को इंसान के साथ-साथ agent के लिए भी चलना होगा। तीसरे भाग में यही है: agent payment कैसे करते हैं, कौन-सी सुरक्षा-सीमाएँ मौजूद हैं, और धोखाधड़ी व refund को क़ाबू में कैसे रखें।
अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, data की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।
About the Author
Anichur Rahaman
Continue Reading
