एजेंट-रीडेबल वेबसाइटें: AI एजेंट्स के लिए स्ट्रक्चर

एक क्लाइंट ने मुझे पिछले अक्टूबर में फोन किया, घबराया हुआ। उसकी ई-कॉमर्स साइट को उसके एनालिटिक्स द्वारा "डायरेक्ट" विज़िट के रूप में दिखाई गई बहुत सारी ट्रैफिक मिल रही थी, लेकिन कनवर्शन्स गिर गए थे। लगभग एक घंटे सर्वर लॉग्स को खोदने के बाद, मुझे एहसास हुआ कि उस ट्रैफिक का एक महत्वपूर्ण हिस्सा बिल्कुल भी इंसान नहीं था। यह AI एजेंट्स था, विशेष रूप से शॉपिंग असिस्टेंट्स और LLM-पावर्ड कम्पेरिज़न टूल्स, उसके प्रोडक्ट पेजों को क्रॉल कर रहे थे और बाउंस कर रहे थे क्योंकि वे कंटेंट को सही से पार्स नहीं कर सकते थे। स्ट्रक्चर्ड डेटा एक गड़बड़ था। कीमतें JavaScript में दबी हुई थीं। प्रोडक्ट के नाम <h3> टैग्स में रहते थे जो <h2> की तरह स्टाइल किए गए थे। एजेंट्स आ रहे थे, शोर पा रहे थे, और चले जा रहे थे।

यह वह जगह है जहां हम अब हैं। AI एजेंट्स आने वाले नहीं हैं। वे पहले से ही यहां हैं, पहले से ही आपकी साइटों को पढ़ रहे हैं, पहले से ही फैसले ले रहे हैं कि वे क्या निकाल सकते हैं या नहीं निकाल सकते। और Seahawk में मेरे द्वारा बनाई गई या छुई गई 12,000 से अधिक साइटें इसे ध्यान में रखते हुए नहीं बनाई गई हैं। शायद आपकी भी नहीं।

"एजेंट-रीडेबल" का वास्तव में क्या मतलब है

मुझे कुछ के बारे में सीधा कहने दें। एजेंट-रीडेबल का मतलब अस्पष्ट मार्केटिंग अर्थ में "AI-फ्रेंडली" नहीं है। इसका मतलब है कि एक मशीन एक URL पर आ सकती है, तीन परतों के JavaScript को एक्सीक्यूट किए बिना कंटेंट को पार्स कर सकती है, जो कुछ वह ढूंढ रही है उसे निकाल सकती है, और उस पर कार्रवाई कर सकती है। बस।

इंसान क्षमाशील हैं। हम स्कैन करते हैं। हम अनुमान लगाते हैं। हम एक प्राइसिंग पेज पर एक बड़ी संख्या देखते हैं और हम जानते हैं कि यह कीमत है, भले ही यह <div class="fancy-number"> में लपेटी हो। एक AI एजेंट जो एक स्ट्रक्चर्ड वर्कफ्लो का पालन कर रही है? इतना क्षमाशील नहीं। इसे सिग्नल्स, हायरार्की, और प्रेडिक्टेबिलिटी की जरूरत है।

इस काम को अभी जो एजेंट्स कर रहे हैं उनमें OpenAI का browsing tool, Perplexity का online mode, और LangChain और AutoGen जैसे frameworks से बनाए गए दर्जनों custom agents शामिल हैं। सभी का एक समान जरूरत है: साफ-सुथरा, parse करने योग्य, semantically meaningful HTML supporting structured data के साथ।

असली समस्या: JavaScript-First Architecture

यह वह है जो मुझे सबसे ज्यादा दिखता है। एजेंसीज और फ्रीलांसर React या Next.js (या Vue, या Svelte, ठीक है) पर साइट्स बनाते हैं, वे client-side rendering करते हैं, और सोचते हैं कि काम हो गया। साइट शानदार दिखती है। Google इसे crawl कर सकता है, कमोबेश, क्योंकि Googlebot के पास अब headless Chrome renderer built-in है।

लेकिन ज्यादातर AI agents headless Chrome नहीं चला रहे हैं। वे HTTP के जरिए raw HTML fetch कर रहे हैं। अगर आपका content सिर्फ JavaScript execute होने के बाद मौजूद है, तो वे agents को blank page या loading spinner serialised as text मिलता है।

2022 में Seahawk के पास एक fintech client था जिसने अपने पूरे rates और product comparison section को React SPA में बनाया था। कोई SSR नहीं, कोई static fallback नहीं। हमने उनके URL के खिलाफ एक साधारण curl चलाया और literal रूप से 14 lines HTML मिले: एक <div id="root"> और कुछ script tags। यही एक agent को दिखता है। चौदह लाइनें।

असली fix जरूरी नहीं कि आप अपना JS framework abandon कर दें। यह server-side rendering (SSR) या static site generation (SSG) है। Next.js के साथ getServerSideProps या getStaticProps। Vue के लिए Nuxt। SvelteKit। या अगर आप किसी legacy setup में फंसे हैं तो Prerender.io जैसी चीज़ से key pages को pre-render करना भी। Content को initial HTML payload में होना चाहिए।

Semantic HTML अब वैकल्पिक नहीं है

मुझे पता है। आपने 2009 से "semantic HTML use करो" सुना है। लेकिन मैं इसे SEO कारणों से नहीं कह रहा हूँ। मैं इसलिए कह रहा हूँ क्योंकि agents semantic tags का उपयोग करते हैं यह समझने के लिए कि वे किस तरह की चीज़ को देख रहे हैं।

<article>, <nav>, <main>, <aside>, <header>, <footer>, ये सजावटी नहीं हैं। ये signals हैं। एक agent जो एक page का main content निकालने की कोशिश कर रहा है वह पहले <main> को देखेगा। अगर आपने अपना layout nested <div>s से बनाया है और कुछ और नहीं है, तो agent को guess करना पड़ेगा। Agents जो बुरे तरीके से guess करते हैं वे users को गलत जवाब देते हैं।

यहाँ वह है जो मैं हर साइट में audit करता हूँ:

क्या हर पृष्ठ पर बिल्कुल एक <main> एलीमेंट है?
क्या हेडिंग्स एक तार्किक पदानुक्रम का पालन करती हैं (<h1> से <h2> से <h3>) बिना स्तर छोड़े?
क्या नेविगेशन मेनू <nav> एलीमेंट्स में हैं?
क्या अतिरिक्त कंटेंट (साइडबार, संबंधित पोस्ट) <aside> में है?
क्या आइटम की सूचियाँ वास्तव में <ul> या <ol> हैं, न कि <div class="item"> s की एक श्रृंखला?

ये बुनियादी चीजें लगती हैं। लेकिन मैं कहूँ तो जिन WordPress साइट्स की मैं समीक्षा करता हूँ उनमें से 60% कम से कम तीनों में विफल होती हैं। हेडिंग पदानुक्रम वाली तो लगभग हर जगह ऐसी है — डिज़ाइनर <h3> को बड़ा दिखाने के लिए स्टाइल करते हैं और <h2> को छोटा, और कोई भी नीचे मार्कअप को ठीक नहीं करता।

Schema Markup: यहाँ असली काम करें

यह वह जगह है जहाँ ज्यादातर गाइड्स सामान्य हो जाती हैं। मैं कोशिश करूँगा कि ऐसा न हो।

Schema.org संरचित डेटा एजेंट्स को न सिर्फ यह बताता है कि पृष्ठ पर क्या है, बल्कि यह भी कि यह किस प्रकार की चीज़ है। एक उत्पाद। एक रेसिपी। एक स्थानीय व्यवसाय। एक FAQ। एक इवेंट। और यह डेटा उस प्रारूप में देता है जिसे एजेंट्स बिना गद्य को पार्स किए उपभोग कर सकते हैं।

जो प्रकार अभी सबसे अधिक मायने रखते हैं, मेरे अनुभव में:

उत्पाद (हमेशा ऑफर, कीमत, और उपलब्धता, तीनों के साथ)
LocalBusiness (सिर्फ पता स्ट्रिंग नहीं, openingHoursSpecification और geo निर्देशांक के साथ)
Article (datePublished, dateModified, और author को Person प्रकार के रूप में, सादे स्ट्रिंग के रूप में नहीं)
FAQPage (इस पर नीचे और जानकारी)
BreadcrumbList (कम आंका हुआ, आपकी साइट के पदानुक्रम का मानचित्र देता है)
HowTo (अगर आप ट्यूटोरियल या प्रक्रिया दस्तावेज़ प्रकाशित करते हैं)

WordPress साइटों के लिए मैं मूल बातों के लिए Yoast SEO या Rank Math का उपयोग करता हूँ, फिर जो वे कवर नहीं करते उसके लिए <script type="application/ld+json"> ब्लॉक में कस्टम स्कीमा के साथ मैन्युअल रूप से विस्तार करता हूँ। JSON-LD फॉर्मेट वह है जिसे उपयोग करना है। RDFa नहीं, microdata नहीं। JSON-LD। यह मार्कअप को स्वच्छ रखता है और एजेंट इसे आपकी प्रस्तुति परत को छुए बिना प्राप्त कर सकते हैं।

एक गलती जो मैंने 2021 में की: मैंने एक क्लाइंट के उत्पाद पृष्ठों पर स्कीमा डाला लेकिन price फील्ड खाली छोड़ा क्योंकि उनकी कीमतें "उद्धरण के लिए संपर्क करें" थीं। स्कीमा वैलिडेटर इसे पास कर दिया। लेकिन एजेंट एक खाली कीमत निकाल रहे थे और उसे उपयोगकर्ताओं को "price: unknown" के रूप में वापस कर रहे थे, जिसने विश्वास को नष्ट कर दिया। फिक्स था minPrice / maxPrice के साथ एक यथार्थवादी मूल्य सीमा शामिल करना, या फिर offers ब्लॉक को पूरी तरह से हटा देना। आंशिक डेटा कोई डेटा नहीं होने से बदतर हो सकता है।

सामग्री संरचना: स्कैन करने योग्य निष्कर्षण के लिए लिखें

यहाँ बात यह है कि एजेंट कैसे गद्य पढ़ते हैं। वे इसे उसी तरह नहीं पढ़ते जैसे आप करते हैं। वे प्रश्नों के उत्तर, ऐसे तथ्य जो निकाले जा सकें, और दावों के बीच स्पष्ट संबंध खोज रहे हैं।

इसका मतलब है कि आपकी कंटेंट स्ट्रक्चर को जवाब को सामने रखना चाहिए। अगर कोई (या कुछ) पूछता है "डिलीवरी में कितना समय लगता है?", तो आपके पेज में एक हेडिंग होनी चाहिए जो कुछ इस तरह कहे "डिलीवरी समय" और उसके नीचे पहला सेंटेंस असली संख्या बताए। आपके वेयरहाउस ऑपरेशन के बारे में पूरा पैराग्राफ नहीं। पहले संख्या, फिर संदर्भ।

मैंने क्लाइंट साइट्स पर कंटेंट को इस तरह स्ट्रक्चर करना शुरू कर दिया है, लगभग हर सबसेक्शन के लिए एक उलटे पिरामिड की तरह:

हेडिंग के नीचे पहले सेंटेंस में तथ्य या जवाब सीधे दें
एक या दो सपोर्टिंग संदर्भ के सेंटेंस जोड़ें
अगर टॉपिक को गहरे संसाधन की जरूरत है तो उसका लिंक दें

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

एक ट्रैवल साइट जिसे हमने पिछली वसंत में दोबारा तैयार किया, हमने लगभग छह हफ्तों में 80 आर्टिकल्स को इस तरह से पुनर्गठित किया। उन पेजों के लिए Perplexity citations में ध्यान देने योग्य वृद्धि हुई। इससे भी महत्वपूर्ण बात यह है कि जिन जवाबों की ओर ये citations इशारा करते थे वे वास्तव में सटीक थे, क्योंकि प्रासंगिक तथ्य खोजने योग्य था।

Robots.txt, llms.txt, और Access Control

यह एक नई चीज है। एक बढ़ता हुआ कन्वेंशन है, अभी तक कोई स्टैंडर्ड नहीं है, जिसमें llms.txt नाम की एक फाइल आपके डोमेन के रूट में रखी जाती है। यह विचार, Jeremy Howard द्वारा प्रस्तावित, LLMs को आपकी साइट के सबसे महत्वपूर्ण कंटेंट और किसी भी एक्सेस प्राथमिकताओं का सादा-पाठ नक्शा देना है। इसे robots.txt की तरह सोचें लेकिन क्रॉल बॉट्स की जगह लैंग्वेज मॉडल एजेंट्स के लिए सादी अंग्रेजी में लिखा गया।

क्या आपको इसे लागू करना चाहिए? ईमानदारी से कहूं तो, हां। इसे लिखने में 20 मिनट लगते हैं। यह संकेत देता है कि आपकी साइट एजेंट-सचेत है, और जैसे-जैसे अधिक एजेंट्स को इसे खोजने के लिए प्रशिक्षित किया जाएगा, यह एक सार्थक संकेत बन जाएगा।

robots.txt के बारे में विशेष रूप से: जानबूझकर निर्णय लें। कुछ साइट मालिक अभी सभी AI क्रॉलर्स को रोकने के लिए तुरंत प्रतिक्रिया दिखा रहे हैं। यह आपकी पसंद है, लेकिन व्यापक ब्लॉकिंग का मतलब है कि आपकी सामग्री AI-जनित उत्तरों में भी दिखाई नहीं देगी, जो एक वितरण चैनल है जिसे आप छोड़ रहे हैं। इसके बारे में उसी तरह सोचें जैसे आपने 2005 में Googlebot को ब्लॉक करने के बारे में सोचा था। संभवतः एक बुरा विचार नहीं है।

आंतरिक लिंकिंग और क्रॉल आर्किटेक्चर

एक कार्यप्रवाह का पालन करने वाला एजेंट केवल एक पृष्ठ पर नहीं उतरता है। यह लिंक का पालन करता है। आपकी आंतरिक लिंकिंग संरचना की गुणवत्ता यह निर्धारित करती है कि एजेंट वास्तव में आपकी साइट के कितने हिस्से को ट्रैवर्स कर सकता है और समझ सकता है।

खराब आंतरिक लिंकिंग का मतलब है कि एजेंट आपकी साइट के एक या दो पृष्ठों को इंडेक्स करते हैं और रुक जाते हैं। उन्हें आप जो कुछ भी प्रदान करते हैं उसकी पूरी तस्वीर नहीं मिलती है।

अच्छी आंतरिक लिंकिंग का मतलब है:

होमपेज से हर महत्वपूर्ण पृष्ठ तीन क्लिक के भीतर पहुंचने योग्य है
एंकर टेक्स्ट वर्णनात्मक है, "यहाँ क्लिक करें" या "और पढ़ें" नहीं
संबंधित सामग्री बॉडी में संदर्भ के अनुसार लिंक की गई है, केवल विजेट साइडबार में नहीं
अनाथ पृष्ठ मौजूद नहीं हैं (या यदि वे हैं, तो आप उनके बारे में जानते हैं और उन्हें इस तरह रखने का विकल्प चुना है)

मैं किसी भी एजेंट-पठनीयता कार्य से पहले क्लाइंट साइटों पर Screaming Frog क्रॉल चलाता हूं। अकेले अनाथ पृष्ठ रिपोर्ट आमतौर पर ऐसी सामग्री को प्रकट करती है जिसे क्लाइंट सोचते हैं कि प्रकाशित और खोजने योग्य है, लेकिन नहीं है। एक क्लाइंट के पास 34 अनाथ पृष्ठ थे, जिसमें उने मुख्य केस स्टडीज भी शामिल थीं। कोई भी उनसे लिंक नहीं कर रहा था। न ही एजेंट, न ही मनुष्य।

FAQ

क्या मुझे अपनी पूरी साइट को एजेंट-पठनीय बनाने के लिए पुनर्गठित करना होगा?

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

क्या स्कीमा मार्कअप वास्तव में एआई एजेंट प्रतिक्रियाओं में मदद करता है?

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

पेवॉल किए गए कंटेंट वाली साइट्स के बारे में क्या?

अपने Article टाइप पर isAccessibleForFree स्कीमा प्रॉपर्टी का उपयोग करें, और hasPart / isPartOf पैटर्न का उपयोग करके यह चिन्हित करें कि कौन से सेक्शन पेवॉल किए गए हैं। यह एजेंट्स को बताता है कि वे क्या उपयोग करने की अनुमति है। Google के पेवॉल किए गए कंटेंट स्ट्रक्चर्ड डेटा पर डॉक्यूमेंटेशन यह स्पष्ट रूप से कवर करता है, और यही तर्क गैर-Google एजेंट्स पर लागू होता है।

क्या llms.txt व्यापक रूप से समर्थित है?

सार्वभौमिक रूप से नहीं। लेकिन इसे लागू करना लगभग कुछ भी नहीं खर्च करता है, और इस जैसे कन्वेंशन्स का प्रारंभिक अपनाना आमतौर पर भुगतान करता है। मैंने 2024 की शुरुआत से Seahawk क्लाइंट साइट्स में इसे जोड़ा है। यह अभी एक छोटा सिग्नल है। यह 12 महीने में अधिक महत्वपूर्ण होगा।

मैं कैसे परीक्षण करूं कि क्या एजेंट मेरी साइट को पढ़ सकता है?

टर्मिनल में curl -A "Mozilla/5.0" [your URL] से शुरू करें और देखें कि क्या वापस आता है। अगर आपकी मुख्य content उस आउटपुट में नहीं है, तो आपको एक rendering समस्या है। फिर अपने पेजों को Google के Rich Results Test से schema validation के लिए चलाएं। और Chrome Lighthouse accessibility audit को भी देखें, क्योंकि agent-readability और accessibility एक-दूसरे से ज्यादा overlap करते हैं जितना ज्यादातर लोग समझते हैं।

---

वेब को मनुष्यों के लिए बनाया गया था और फिर सर्च इंजन के लिए पुनर्निर्माण किया गया। अब इसे एक बार फिर से पुनर्निर्माण की जरूरत है, इस बार उन agents के लिए जो किसी भी मानव तरीके से browse नहीं करते। यह कोई संकट नहीं है। यह बस काम का अगला दौर है। और सच कहूं तो, इसका ज्यादातर हिस्सा अच्छी प्रैक्टिस है जो sites को मनुष्यों के लिए भी बेहतर बनाता है। साफ markup, स्पष्ट content, कम JavaScript sprawl। आपको शायद यह पहले ही करना चाहिए था।