PageSpeed Insights वर्षों से प्रदर्शन, एक्सेसिबिलिटी, सर्वोत्तम प्रथाओं और SEO को स्कोर कर रहा है। 2026 में उस पंक्ति में चुपचाप पाँचवाँ आइटम जुड़ गया: Agentic Browsing। यह वह एक सवाल जवाब देता है जिसे बाकी चार श्रेणियाँ अनदेखा करती हैं — क्या कोई AI एजेंट वाकई इस पेज के साथ काम कर सकता है?
यह गाइड उस जाँच को आपकी अपनी साइट पर लगाने के बारे में है: इसे चलाना, हर जाँच असल में क्या कहती है यह पढ़ना, और एक फ़िक्स सूची लेकर निकलना।
अंत में आपके पास क्या होगा
यह किसके लिए है: उन SEO टीमों, डेवलपर्स और साइट मालिकों के लिए जो जानना चाहते हैं कि जब किसी इंसान की जगह एजेंट उनके पेज ब्राउज़ करता है तो क्या होता है।
काम पूरा होने पर आपके पास: आपकी साइट का असली Agentic Browsing नतीजा, हर जाँच के हिसाब से यह पढ़ना कि क्या पास हुआ, फेल हुआ या लागू नहीं होता, और प्राथमिकता के क्रम में लगी फ़िक्स सूची।
पूर्वापेक्षाएँ: सार्वजनिक रूप से पहुँचने योग्य URL, पहली बार चलाने के लिए लगभग दस मिनट, और कोड एक्सेस अगर आप उसी दिन कुछ ठीक करने की सोच रहे हैं।
पूर्णता की परिभाषा: आप अपना भिन्नात्मक स्कोर जाँच-दर-जाँच समझा सकते हैं, और बता सकते हैं कि कौन-सी विफलताएँ वाकई एजेंट को आपके पेज पर कोई काम पूरा करने से रोकती हैं।
यह जाँच कहाँ से आई, और अब क्यों
Agentic Browsing श्रेणी एक साल पहले नहीं थी। रोलआउट तीन चरणों में हुआ, और सब Google द्वारा प्रलेखित हैं:
- 7 मई 2026: Lighthouse 13.3 इस श्रेणी को अपनी डिफ़ॉल्ट कॉन्फ़िगरेशन में जोड़ता है, यानी यह मानक रन का हिस्सा बन जाती है।
- 22 जून 2026: Chrome for Developers ब्लॉग इसे एजेंट-रेडी वेबसाइट बनाने की डेवलपर टूलकिट वाली पोस्ट में DevTools for agents और WebMCP मार्गदर्शन के साथ घोषित करता है।
- 20 जुलाई 2026: Lighthouse 13.4.1 इस श्रेणी को PageSpeed Insights API पथ के लिए चालू करता है और कहता है कि यह रिलीज़ दो हफ्तों के भीतर PageSpeed Insights तक पहुँचेगी। इसका मतलब सार्वजनिक शुरुआत अगस्त 2026 की शुरुआत में।
जब मैंने 11 सितंबर 2026 को यह जाँच चलाई, तो रिपोर्ट के फुटर में एमुलेटेड मोटो G पावर डिवाइस और Lighthouse 13.4.1 लिखा था, और Agentic Browsing ठीक SEO के बगल में था।
यानी सुविधा लाइव है, सिर्फ़ कैनरी में नहीं। यह साफ़ तौर पर अधूरी भी है — रिपोर्ट में श्रेणी का विवरण सीधे कहता है कि यह श्रेणी अब भी विकास के दौर में है और बदल सकती है।
शुरू करने से पहले एक व्यावहारिक बात: PSI यह श्रेणी आपके लिए, Google की तरफ़ से चलाता है। पेज-स्तरीय जाँचों के लिए आपको Chrome 150 या origin trial की ज़रूरत नहीं है। Chrome DevTools में लोकल रन ही वे हैं जिन पर वर्शन की शर्तें लागू होती हैं।
अपनी साइट पर जाँच चलाएँ
- pagespeed.web.dev खोलें और अपना URL पेस्ट करें। पहले मोबाइल के लिए चलाएँ, फिर डेस्कटॉप के लिए दोहराएँ, क्योंकि दोनों लैब रन अलग-अलग स्कोर होते हैं।
- लैब डेटा पूरा होने का इंतज़ार करें। ऊपर का फ़ील्ड डेटा Chrome UX Report से आता है और जल्दी लोड होता है। नीचे का Lighthouse रन ज़्यादा समय लेता है और श्रेणियाँ वहीं होती हैं।
- स्कोर पंक्ति खोजें। आपको प्रदर्शन, एक्सेसिबिलिटी, सर्वोत्तम प्रथाएँ, SEO, और फिर 0–100 स्कोर की जगह भिन्न के रूप में Agentic Browsing दिखेगा।
- श्रेणी खोलें। जाँचों की सूची Agent Accessibility, WebMCP और पास तथा लागू-न-होने वाले सामान्य समूहों में बँटी होती है।
- हर फेल जाँच खोलें। हर पंक्ति फैलकर वह नियम, एलिमेंट या फ़ाइल दिखाती है जो विफलता के पीछे है — फ़िक्स टिकट के लिए आपको यही चाहिए।
पाँचवीं श्रेणी उसी पंक्ति में है जिसे SEO टीमें हर दिन देखती हैं। 11 सितंबर 2026 को PageSpeed Insights में कैप्चर किया गया।
गुणवत्ता जाँच: किसी साथी के साथ नतीजों की तुलना करने से पहले रन विवरण में Lighthouse वर्शन की पुष्टि करें। PSI, Lighthouse को अपने शेड्यूल पर अपडेट करता है, और यह श्रेणी वर्शनों के बीच अब भी बदल रही है।
अगर फेल हो: PSI भारी पेजों पर कभी-कभी RPC टाइमआउट लौटाता है। शोध के दौरान एक बड़ी साइट पर मेरे साथ भी हुआ। फिर से कोशिश करें, या पेज को लोकल Lighthouse में टेस्ट करें।
भिन्नात्मक स्कोर सही तरीके से पढ़ें
Agentic Browsing का कोई भारित 0–100 स्कोर नहीं है, और यह जानबूझकर है। Lighthouse का दस्तावेज़ कहता है कि एजेंटिक वेब के मानक अभी बन रहे हैं, इसलिए ध्यान रैंकिंग की जगह काम लायक संकेतों पर है।
असल में मायने यह गणित रखता है:
प्रदर्शन | इसका मतलब |
|---|---|
3/3 | स्कोर होने योग्य हर जाँच पास। लागू-न-होने वाली जाँचें शामिल नहीं। |
1/3 | एक पास, दो फेल। हर में सिर्फ़ पास और फेल जाँचें हैं। |
0/3 | अभी कोई स्कोर होने योग्य जाँच पास नहीं। विज्ञापनों वाले भारी पेज पर पहले रन में आम। |
कोई भिन्न नहीं | सारी जाँचें लागू नहीं थीं या श्रेणी चली ही नहीं। रन विवरण देखें। |
जाल यह है कि 1/3 को "33 प्रतिशत एजेंट-तैयार" पढ़ लिया जाए। यह किसी चीज़ का प्रतिशत नहीं है। यह एक गिनती है: उस पेज पर स्कोर हो सकने वाली तीन जाँचों में से एक पास हुई, और लागू-न-होने वाली जाँचें गणना से पूरी तरह बाहर रहीं। जो रिपोर्ट मैंने कैप्चर की, उसमें छह जाँचें चलीं, तीन लागू नहीं थीं, और बाकी तीन ने 1/3 बनाया।
स्कोर उसी पेज पर रन के बीच भी बदलते हैं। Lighthouse जो तीन कारण बताता है वे हैं: गतिशील टूल पंजीकरण (JavaScript से रजिस्टर किए WebMCP टूल समय के हिसाब से पकड़े या छूट सकते हैं), DOM में बदलाव जो एक्सेसिबिलिटी ट्री को बदल देते हैं, और विज्ञापनों, बिना साइज़ वाली इमेजों या इंजेक्ट किए गए कंटेंट से लेआउट शिफ्ट। आपका नंबर डगमगाता है तो वजह आम तौर पर यही होती है।
छह जाँचों को एक-एक कर देखें
मौजूदा PSI बिल्ड छह जाँचें चलाता है। एक और आने वाली है: Lighthouse की डेवलपमेंट ब्रांच एक नए Agent Discoverability समूह के तहत ai-catalog.json जाँच (Agent Resource Discovery) पहले ही जोड़ रही है, इसलिए इस सूची को वर्शन पर निर्भर मानें।
जाँच | क्या जाँचती है | "लागू नहीं" का मतलब |
|---|---|---|
एक्सेसिबिलिटी ट्री ठीक नहीं है | एजेंट पर केंद्रित एक्सेसिबिलिटी नियमों का एक हिस्सा: प्रोग्रामेटिक नाम और लेबल, वैध ARIA ढाँचा, और ऐसे एलिमेंट जो ट्री से छिपे होने पर भी इंटरैक्टिव रहते हैं | कभी नहीं; यह हमेशा स्कोर होती है |
llms.txt सिफ़ारिशों का पालन नहीं करता | कि | फ़ाइल ने 404 लौटाया। llms.txt का न होना वैकल्पिक माना जाता है, विफलता नहीं |
क्यूमुलेटिव लेआउट शिफ्ट | दृश्य स्थिरता, ताकि एलिमेंट की पोज़िशन पर काम करने वाले एजेंट शिफ्ट के बीच ग़लत चीज़ पर क्लिक न करें | कभी नहीं; यह हमेशा स्कोर होती है |
WebMCP टूल रजिस्टर्ड | क्या पेज डिक्लेरेटिव या इम्परेटिव API से कोई WebMCP टूल रजिस्टर करता है | कोई WebMCP टूलिंग नहीं मिली |
WebMCP फ़ॉर्म कवरेज | ऐसे डिक्लेरेटिव फ़ॉर्म जिनमें टूल एनोटेशन नहीं हैं | ऊपर जैसा ही |
WebMCP स्कीमा वैध हैं | कि रजिस्टर्ड टूल वैध इनपुट और आउटपुट स्कीमा प्रकाशित करते हैं | ऊपर जैसा ही |
श्रेणी का खुला दृश्य: दो विफलताएँ, एक पास और तीन लागू-न-होने वाली जाँचें। फेल सूची किसी काम तक पहुँचने का सबसे छोटा रास्ता है।
तीन WebMCP जाँचों का "लागू नहीं" दिखाना 2026 में सामान्य है। WebMCP एक प्रस्तावित मानक है, origin trial और शुरुआती प्रीव्यू में, जिसके दो API हैं: एक डिक्लेरेटिव जो मानक HTML फ़ॉर्म पर एनोटेशन लगाता है, और एक इम्परेटिव जो JavaScript से टूल रजिस्टर करता है। ज़्यादातर साइटें अभी इनमें से कोई नहीं भेजतीं, इसलिए ज़्यादातर रिपोर्टों में वहाँ तीन ग्रे गोले दिखते हैं। ग्रे लाल नहीं है। इसे विफलता मत मानें।
जाँच जो बताए उसे ठीक करें
चार फ़िक्स थीम छह जाँचों को कवर करती हैं। तीन WebMCP पंक्तियों पर ध्यान तभी चाहिए जब आप वाकई एजेंट टूल भेजते हों।
एक्सेसिबिलिटी ट्री को एजेंट के पढ़ने लायक बनाएँ
एजेंट आपके पेज के मुख्य नक़्शे के तौर पर एक्सेसिबिलिटी ट्री पर निर्भर करते हैं। उसमें भूमिकाएँ, नाम और अवस्थाएँ होती हैं। बिना एक्सेसिबल नाम वाला बटन उनके लिए बंद रास्ता है, और स्क्रीन रीडर इस्तेमाल करने वालों के लिए भी।
क्या करें: खुली जाँच से फेल नियमों पर काम करें। आम आरोपी हैं सिर्फ़ आइकन वाले बटन, बिना लेबल वाले फ़ॉर्म फ़ील्ड, वे लिंक जिनका टेक्स्ट सिर्फ़ "यहाँ क्लिक करें" है, अवैध ARIA रोल संयोजन, और ARIA द्वारा संदर्भित डुप्लिकेट ID। सिमैंटिक HTML को प्राथमिकता दें, लेबल में for एट्रिब्यूट जोड़ें, और जब नेटिव एलिमेंट संभव न हो तो कस्टम विजेट को स्पष्ट रोल और tabindex दें।
अपेक्षित नतीजा: जाँच पास हो जाती है, और आपका सामान्य एक्सेसिबिलिटी स्कोर भी आम तौर पर साथ ही सुधरता है, क्योंकि Agentic Browsing वाला संस्करण उन्हीं जाँचों का केंद्रित उपसमूह है।
रिकवरी रास्ता: अगर फ़िक्स सूची सैकड़ों एलिमेंट तक पहुँच जाए, तो एक-एक को पकड़ने मत दौड़ें। साझा कंपोनेंट ठीक करें, जैसे हेडर का सिर्फ़ आइकन वाला बटन, फिर दोबारा चलाएँ। एक कंपोनेंट अक्सर दर्जनों पंक्तियाँ साफ़ कर देता है।
ऐसा llms.txt भेजें जो फ़ॉर्मेट जाँच पार करे
इसमें एक जाल है जो सावधान लोगों को भी फँसाता है। जाँच सिर्फ़ यह नहीं देखती कि /llms.txt मौजूद है। यह फ़ाइल की सामग्री देखती है, और सिर्फ़ नंगे URL गिनाने वाली फ़ाइल फेल होती है, क्योंकि जाँच Markdown शैली के लिंक ढूँढती है।
क्या करें: अपने रूट डोमेन पर H1 हेडिंग और असली Markdown लिंक के साथ /llms.txt बनाएँ:
# Your Company
Short description of what the site covers and how it should be used.
## Key pages
- [Product overview](https://example.com/product)
- [Pricing](https://example.com/pricing)
- [Documentation](https://example.com/docs)अपेक्षित नतीजा: जाँच हरी हो जाती है। वहीं 404 लागू नहीं के रूप में दिखता है, जो आज स्वीकार्य है। 500 श्रेणी का जवाब, या कोई फ़ेच एरर, असली विफलता है जिसके लिए सर्वर सुधार चाहिए।
गुणवत्ता जाँच: अपना /llms.txt टर्मिनल में मँगाएँ और लिंक गिनें। अगर वे https://example.com/pricing जैसे बिना कोष्ठक के दिखें, तो फ़ाइल लाइव और इंसानों के पढ़ने लायक होने पर भी जाँच फेल होगी।
एक ईमानदार चेतावनी: Google Search, llms.txt का इस्तेमाल नहीं करता। Google की ख़ुद की AI ऑप्टिमाइज़ेशन गाइड कहती है कि यह फ़ाइल Google Search में आपकी साइट की विज़िबिलिटी या रैंकिंग को न नुक़सान पहुँचाएगी और न मदद करेगी, क्योंकि Google Search इसे अनदेखा करता है। इसे उन एजेंट टूल्स के लिए लिखें जो यह परंपरा पढ़ते हैं, रैंकिंग के लिए नहीं।
लेआउट स्थिर करें ताकि एजेंट निशाना लगा सकें
लेआउट शिफ्ट अब पहले से ज़्यादा मायने रखता है। जो एजेंट पहले बटन ढूँढता है और फिर उसके निर्देशांक पर क्लिक करता है, वह चूक जाएगा अगर कोई विज्ञापन, बैनर या देर से लोड होती इमेज उन दो पलों के बीच बटन को 200 पिक्सल नीचे धकेल दे।
क्या करें: इमेज और एम्बेड पर स्पष्ट चौड़ाई और ऊँचाई (या aspect-ratio) सेट करें, विज्ञापन स्लॉट और सहमति बैनर के लिए तय जगह छोड़ें, लोड के बाद मौजूद कंटेंट के ऊपर कंटेंट डालने से बचें, और लेआउट ट्रिगर करने वाली प्रॉपर्टी की जगह transform से एनिमेट करें।
अपेक्षित नतीजा: लैब रन में क्यूमुलेटिव लेआउट शिफ्ट 0.1 से नीचे, वही सीमा जो Core Web Vitals इस्तेमाल करते हैं।
गुणवत्ता जाँच: प्रदर्शन के तहत Layout shift culprits इनसाइट ज़िम्मेदार एलिमेंट के नाम सीधे बताती है। अंदाज़ा लगाने की जगह वहीं से शुरू करें।
WebMCP पर बाद में फ़ैसला करें
तीन WebMCP जाँचें तभी स्कोर होती हैं जब आपकी साइट टूल रजिस्टर करती है। अगर आप बुकिंग फ़्लो, चेकआउट, सपोर्ट फ़ॉर्म या कोई ऐसा संरचित काम चलाते हैं जो एजेंट पूरा कर सके, तो WebMCP एक प्रोटोटाइप के लायक है: यह एजेंट को बताता है कि कौन-सा टूल कॉल करना है, DOM से अंदाज़ा लगाने की जगह। Chrome यह सुविधा origin trial और लोकल टेस्टिंग फ़्लैग के पीछे भेजता है, यानी यह असली विकल्प है, सोच का प्रयोग नहीं।
अगर ऐसा कोई काम नहीं है जिसे ऑटोमेट करना बनता हो, तो WebMCP को छोड़ दें। तीन ग्रे गोलों में कोई दिक्कत नहीं। सिर्फ़ एक काम न करें: सिर्फ़ भिन्न बेहतर दिखाने के लिए कोई सजावटी टूल रजिस्टर करना। यह श्रेणी तैयारी का संकेत है, और इसमें हेराफेरी उसका मक़सद ही ख़त्म कर देती है।
फ़िक्स सत्यापित करें
वही URL PSI में दोबारा चलाएँ और एक नहीं, तीन चीज़ें तुलना करें: भिन्न, हर जाँच की स्थिति, और डिवाइस का प्रकार। कोई फ़िक्स भिन्न को हिला सकता है बिना आपकी असली चिंता ठीक किए, और मोबाइल तथा डेस्कटॉप अलग लैब नतीजे देते हैं।
तेज़ पुनरावृत्ति के लिए PSI का इंतज़ार करने की जगह Lighthouse लोकल चलाएँ। यह श्रेणी Lighthouse 13.3 और उसके बाद में है, इसलिए लोकल इंस्टॉल उसे उठा लेता है। DevTools पैनल वाला संस्करण चाहिए तो Google का दस्तावेज़ कहता है कि श्रेणी को टेस्ट करने के लिए Chrome 150 या उससे नया चाहिए, और WebMCP जाँचों के लिए origin trial रजिस्टर्ड होना भी ज़रूरी है।
छोटा पहले-बाद का रिकॉर्ड रखें। "2026-09-11: मोबाइल 1/3, फेल a11y ट्री + llms.txt" जैसी तारीख़ वाली एक पंक्ति काफ़ी है। यह बताती है कि बाद में आई कोई गिरावट असली है या सिर्फ़ रन-दर-रन डगमगाहट।
यह जाँच क्या नहीं है
तीन चीज़ें जो यह नहीं करती, क्योंकि भ्रम बहुत फैला है:
- यह रैंकिंग कारक नहीं है। Chrome की घोषणा इसे सूचनात्मक और बिना बेंचमार्क बताती है। Google Search रैंकिंग आपके Agentic Browsing भिन्न से प्रभावित नहीं होती।
- यह AI विज़िबिलिटी स्कोर नहीं है। यह नापती है कि कोई एजेंट आपका पेज चला सकता है या नहीं। ChatGPT या Perplexity किसी जवाब में आपका हवाला देते हैं या नहीं, इस पर यह कुछ नहीं कहती।
- यह आपकी साइट पर पास/फेल का फ़ैसला नहीं है। किसी सादे मार्केटिंग पेज पर कम भिन्न आम तौर पर मतलब है कि स्कोर करने को कम था, यह नहीं कि एजेंट बाहर बंद हैं।
जो नज़रिया मदद करता है: यह श्रेणी जाँचती है कि जब आगंतुक इंसान न हो तो आपकी साइट टिकती है या नहीं। यह जो कुछ भी इनाम देती है, वह वैसे भी करने लायक है: सिमैंटिक HTML, स्थिर लेआउट, लेबल वाले कंट्रोल। Google की ख़ुद की एजेंट-फ़्रेंडली गाइड भी इसी बात पर ख़त्म होती है: जो साइट को एजेंट के लायक बनाता है वही उसे इंसानों के लिए भी बेहतर बनाता है।
इसे अपने रिव्यू लूप में रखें
एजेंट तैयारी उन क्षेत्रों में से है जहाँ प्लेटफ़ॉर्म चेकलिस्ट से तेज़ चलता है। दो आदतें आपको बिना प्रोजेक्ट बनाए अपडेट रखती हैं:
- किसी भी टेम्पलेट, नेविगेशन, फ़ॉर्म या चेकआउट बदलाव के बाद जाँच दोबारा चलाएँ। एक्सेसिबिलिटी ट्री और लेआउट स्थिरता को हिलाने वाले संपादन यही हैं।
- भिन्न को URL के हिसाब से नहीं, टेम्पलेट के हिसाब से ट्रैक करें। दस प्रोडक्ट पेज जो एक जैसा स्कोर करते हैं, वह टेम्पलेट की समस्या है, और एक फ़िक्स सबको ठीक कर देता है।
PSI जाँच जानबूझकर संकरी है: छह जाँचें, एक बार में एक पेज। अगर आपको बड़ा चित्र चाहिए — जिसमें यह भी शामिल है कि आपके robots नियम, MCP सर्वर कार्ड, OAuth डिस्कवरी और एजेंट कॉमर्स संकेत मौजूद हैं या नहीं — Auspia एक मुफ़्त Agent Readiness जाँच चलाता है जो URL को उन प्रोटोकॉल-स्तरीय मानकों पर स्कैन करती है और तुलना के लिए लीडरबोर्ड दिखाती है।
सामान्य प्रश्न
क्या Agentic Browsing स्कोर Google रैंकिंग को प्रभावित करता है? नहीं। Google इस श्रेणी को सूचनात्मक बताता है और यह Search रैंकिंग सिस्टम का हिस्सा नहीं है। इसे एजेंट के लिए तैयारी की जाँच मानें, SEO स्कोर नहीं।
एक ही पेज पर दो रन के बीच मेरा भिन्न क्यों बदल गया? गतिशील टूल पंजीकरण, एक्सेसिबिलिटी ट्री बदलने वाले DOM परिवर्तन, और देर से होने वाले लेआउट शिफ्ट — ये सब रन-दर-रन अंतर पैदा करते हैं। दोबारा टेस्ट करें, और सिर्फ़ भिन्न नहीं, जाँचों की सूची की तुलना करें।
तीनों WebMCP जाँचें लागू नहीं क्यों दिख रही हैं? क्योंकि आपका पेज WebMCP टूल रजिस्टर नहीं करता। 2026 में ज़्यादातर साइटों के लिए यही अपेक्षित स्थिति है, और यह विफलता नहीं है।
क्या llms.txt न होना समस्या है? इस जाँच के लिए, नहीं। 404 को लागू नहीं माना जाता। जो फ़ाइल मौजूद है पर ख़राब बनी है वह फेल होती है, इसलिए अगर आप इसे प्रकाशित करें, तो सही तरीके से करें।
क्या मैं इसे CI में चला सकता हूँ? हाँ, जब यह श्रेणी आपके Lighthouse वर्शन में हो। जाँचें डिज़ाइन से नियतात्मक हैं, और यही उन्हें पाइपलाइन जाँचों के लायक बनाता है। ध्यान रखें कि WebMCP वाले हिस्से ब्राउज़र समर्थन और origin trial नामांकन पर निर्भर हैं, इसलिए ज़्यादातर CI वातावरणों में उन्हें लागू नहीं के रूप में पढ़ने की उम्मीद रखें।
क्या इसके लिए Chrome 150 चाहिए? नहीं। PageSpeed Insights इसे सर्वर की तरफ़ चलाता है। Chrome 150 की शर्त DevTools में श्रेणी को लोकल चलाने पर लागू होती है।
लेखक: Alice Monroe, Auspia में 150+ टूल्स कवर करने वाली AI SEO टूल्स विश्लेषक। Alice SEO और AI सर्च टूलिंग, कौन-सी जाँचें आपके समय के लायक हैं, और उन्हें काम की दिनचर्या में कैसे पिरोया जाए — इन विषयों पर लिखती हैं।
