कोर वेब वाइटल्स और लेटेंसी: क्या तेज़ पेजों को अधिक आर्टिफिशियल इंटेलिजेंस उद्धरण मिलते हैं?
परिचय
एक तेज़ वेबसाइट लोगों के लिए उपयोग करना आसान है। यह खोज इंजनों और आर्टिफिशियल इंटेलिजेंस प्रणालियों के लिए भी इसे प्राप्त करना, रेंडर करना और समझना आसान बना सकता है।
लेकिन एक महत्वपूर्ण अंतर अक्सर छूट जाता है:
एक तेज़ पेज क्रॉलिंग और सामग्री की उपलब्धता में सुधार कर सकता है। इसका मतलब यह नहीं है कि केवल गति ही किसी आर्टिफिशियल इंटेलिजेंस प्रणाली को पेज का उद्धरण देने का कारण बनती है।
2 अगस्त, 2026 तक, Google का कहना है कि स्थिर सर्वर प्रतिक्रिया समय और कम लेटेंसी किसी साइट की क्रॉल क्षमता को बढ़ा सकते हैं। Google यह भी कहता है कि उसकी आर्टिफिशियल इंटेलिजेंस खोज सुविधाएँ पारंपरिक खोज के समान ही बुनियादी खोज और अनुक्रमण प्रणालियों का उपयोग करती हैं और उन्हें विशेष आर्टिफिशियल इंटेलिजेंस मार्कअप या गति अनुकूलन की आवश्यकता नहीं होती है। (developers.google.com)
यह लेख एक साक्ष्य-आधारित परीक्षण योजना प्रस्तुत करता है, न कि यह दावा करता है कि एक पूर्ण प्रयोग पहले ही चलाया जा चुका है। कोई साइट, पेज सेट, सर्वर लॉग या उद्धरण डेटासेट प्रदान नहीं किया गया था। लक्ष्य एक नियंत्रित अध्ययन को परिभाषित करना है जो माप सके:
- क्या कम टाइम टू फर्स्ट बाइट क्रॉलिंग आवृत्ति को बढ़ाता है।
- क्या कम लार्जेस्ट कंटेंटफुल पेंट खोज या अनुक्रमण में सुधार करता है।
- क्या कम क्युमुलेटिव लेआउट शिफ्ट क्रॉलिंग या आर्टिफिशियल इंटेलिजेंस पुनर्प्राप्ति को प्रभावित करता है।
- क्या प्रदर्शन में सुधार से उन पेजों की दर बढ़ती है जिन्हें आर्टिफिशियल इंटेलिजेंस खोज प्रणालियों द्वारा स्पष्ट रूप से उद्धृत किया जाता है।
संक्षिप्त उत्तर
सही परिस्थितियों में कम टाइम टू फर्स्ट बाइट क्रॉलिंग में सुधार कर सकता है
Google के वर्तमान क्रॉल दस्तावेज़ में कहा गया है कि जब किसी साइट में स्थिर या बेहतर प्रतिक्रिया समय होता है, जिसमें टाइम टू फर्स्ट बाइट भी शामिल है, तो उसकी क्रॉल क्षमता सीमा बढ़ सकती है। यदि प्रतिक्रिया समय बढ़ता है, या यदि कोई साइट बहुत अधिक सर्वर त्रुटियाँ या दर-सीमा प्रतिक्रियाएँ लौटाती है, तो Google क्रॉलिंग को कम कर सकता है। (developers.google.com)
हालांकि, तेज़ प्रतिक्रिया समय अधिक क्रॉलिंग की गारंटी नहीं देता है। क्रॉल की मांग भी इन कारकों पर निर्भर करती है:
- साइट कितनी बार बदलती है।
- साइट और उसके पेज कितने लोकप्रिय हैं।
- क्या सामग्री उपयोगी और अनूठी है।
- कितने डुप्लिकेट या कम मूल्य वाले यूआरएल मौजूद हैं।
- क्या अद्यतन यूआरएल साइटमैप में शामिल हैं।
इसका मतलब है कि कम लेटेंसी का सबसे मजबूत प्रभाव बड़ी, अक्सर अपडेट की जाने वाली, या सर्वर-बाधित वेबसाइटों पर होना चाहिए, न कि सीमित नई सामग्री वाली छोटी साइट पर।
कम लार्जेस्ट कंटेंटफुल पेंट अप्रत्यक्ष रूप से मदद कर सकता है
लार्जेस्ट कंटेंटफुल पेंट मापता है कि उपयोगकर्ता के लिए मुख्य दृश्यमान सामग्री कब दिखाई देती है। Google यह भी कहता है कि सर्वर प्रतिक्रिया समय और पेजों और एम्बेडेड संसाधनों को रेंडर करने के लिए आवश्यक समय दोनों क्रॉलिंग दक्षता को प्रभावित कर सकते हैं। (developers.google.com)
संभावित संबंध अप्रत्यक्ष है:
कम लेटेंसी → तेज़ संसाधन वितरण → अधिक कुशल रेंडरिंग या फ़ेचिंग → कम क्रॉल टाइमआउट या अधूरी फ़ेच।
प्रभाव सबसे मजबूत तब होना चाहिए जब महत्वपूर्ण सामग्री इन पर निर्भर करती हो:
- धीमा जावास्क्रिप्ट।
- बड़ी छवियां।
- रेंडर-ब्लॉकिंग स्टाइलशीट।
- क्लाइंट-साइड रेंडरिंग।
- भारी एम्बेडेड संसाधन।
केवल एक तेज़ लार्जेस्ट कंटेंटफुल पेंट स्कोर सीधे आर्टिफिशियल इंटेलिजेंस उद्धरण संकेत होने की संभावना नहीं है।
कम क्युमुलेटिव लेआउट शिफ्ट का शायद सीधे क्रॉलिंग पर बहुत कम प्रभाव पड़ता है
क्युमुलेटिव लेआउट शिफ्ट दृश्यमान सामग्री की अप्रत्याशित गति को मापता है। यह मुख्य रूप से एक उपयोगकर्ता अनुभव मीट्रिक है। सामान्य कारणों में बिना आयाम वाली छवियां, गतिशील रूप से डाले गए विज्ञापन, एम्बेडेड सामग्री और वेब फ़ॉन्ट शामिल हैं। (web.dev)
एक क्रॉलर उस तरह से लेआउट शिफ्ट का अनुभव नहीं करता है जिस तरह एक मानव आगंतुक करता है। इसलिए, कम क्युमुलेटिव लेआउट शिफ्ट और अधिक क्रॉलिंग के बीच सीधा संबंध असंभव है।
एक अप्रत्यक्ष संबंध हो सकता है जब एक उच्च लेआउट शिफ्ट के कारण होता है:
- जावास्क्रिप्ट द्वारा देर से डाली गई सामग्री।
- स्क्रिप्ट चलने तक छिपी हुई महत्वपूर्ण सामग्री।
- छवियां या एम्बेड जो पेज निर्माण में देरी करते हैं।
- अस्थिर टेम्पलेट जो विभिन्न फ़ेच के दौरान अलग-अलग सामग्री उत्पन्न करते हैं।
उन मामलों में, वास्तविक समस्या लेआउट शिफ्ट स्कोर नहीं है। वास्तविक समस्या यह है कि पेज को संसाधित करना मुश्किल हो सकता है या महत्वपूर्ण सामग्री को बहुत देर से उजागर कर सकता है।
तेज़ पेजों को स्वचालित रूप से अधिक बार उद्धृत नहीं किया जाता है
Google का कहना है कि आर्टिफिशियल इंटेलिजेंस सुविधाओं में दिखाई देने वाले पेजों को पहले अनुक्रमित किया जाना चाहिए और स्निपेट के साथ सामान्य खोज परिणामों में दिखाई देने के योग्य होना चाहिए। Google यह भी कहता है कि उसकी आर्टिफिशियल इंटेलिजेंस ओवरव्यू और आर्टिफिशियल इंटेलिजेंस मोड के लिए कोई अतिरिक्त तकनीकी आवश्यकताएँ या विशेष आर्टिफिशियल इंटेलिजेंस अनुकूलन नहीं हैं। (developers.google.com)
OpenAI भी इसी तरह कहता है कि ChatGPT खोज रैंकिंग कई कारकों पर निर्भर करती है और उसके खोज क्रॉलर, OAI-SearchBot को अनुमति देना शामिल करने के लिए महत्वपूर्ण है। यह नहीं कहता है कि कम कोर वेब वाइटल्स सीधे उद्धरण संभावना को बढ़ाते हैं। (help.openai.com)
यह चार-चरणीय मॉडल का सुझाव देता है:
- खोज (Discovery) — क्या सिस्टम को पता चलता है कि यूआरएल मौजूद है?
- प्राप्ति और प्रसंस्करण (Fetching and processing) — क्या सिस्टम पेज को पुनः प्राप्त और समझ सकता है?
- अनुक्रमण और पुनर्प्राप्ति (Indexing and retrieval) — क्या पेज को किसी विशेष क्वेरी के लिए चुना गया है?
- उद्धरण चयन (Citation selection) — क्या पेज को उत्तर में एक दृश्यमान स्रोत के रूप में दिखाया गया है?
पेज की गति पहले दो चरणों को प्रभावित कर सकती है। इसे चौथे चरण का सीधा कारण स्थापित नहीं किया गया है।
हालिया शोध यह भी दर्शाता है कि आर्टिफिशियल इंटेलिजेंस सिस्टम कई प्रासंगिक पेज पढ़ सकते हैं लेकिन उनमें से केवल कुछ को ही उद्धृत करते हैं। दूसरे शब्दों में, पुनर्प्राप्ति और उद्धरण अलग-अलग घटनाएँ हैं। (cambridge.org)
क्या परीक्षण किया जाना चाहिए?
अध्ययन को "आर्टिफिशियल इंटेलिजेंस दृश्यता" को एक मीट्रिक मानने के बजाय दो अलग-अलग प्रश्नों का परीक्षण करना चाहिए।
प्रश्न 1: क्या प्रदर्शन क्रॉलिंग को प्रभावित करता है?
प्राथमिक परिणाम:
- प्रकाशन से पहली क्रॉलर अनुरोध तक का समय।
- प्रति दिन प्रति पेज क्रॉलर अनुरोधों की संख्या।
- सफल पुनर्कुंजीकरण के बीच का समय।
- प्रति 1,000 प्रकाशित पेजों पर क्रॉल किए गए पेजों की संख्या।
- सफल फ़ेच का प्रतिशत।
- सर्वर त्रुटियों और दर-सीमा प्रतिक्रियाओं की दर।
- प्रकाशन से अनुक्रमण तक का समय।
प्रश्न 2: क्या प्रदर्शन उद्धरण चयन को प्रभावित करता है?
प्राथमिक परिणाम:
- परीक्षण की गई क्वेरीज़ का प्रतिशत जो एक दृश्यमान उद्धरण उत्पन्न करती हैं।
- प्रति पात्र पेज पर उद्धरण दर।
- एक क्वेरी के भीतर उद्धरण हिस्सेदारी।
- पुनः प्राप्त पेजों का प्रतिशत जो दृश्यमान उद्धरण बन जाते हैं।
- समय के साथ उद्धरण की निरंतरता।
- आर्टिफिशियल इंटेलिजेंस सिस्टम द्वारा उद्धरण दर।
इन परिणामों को प्रदाता द्वारा अलग किया जाना चाहिए। Google आर्टिफिशियल इंटेलिजेंस ओवरव्यू, ChatGPT खोज परिणाम, Microsoft Copilot उत्तर, Perplexity उत्तर और Claude खोज प्रतिक्रिया विभिन्न इंडेक्स, क्रॉलर, रैंकिंग सिस्टम और ताज़ा शेड्यूल का उपयोग कर सकते हैं।
प्रायोगिक डिज़ाइन
1. एक नियंत्रित पेज सेट बनाएँ
पर्याप्त बड़ा पेज सेट उपयोग करें ताकि सार्थक क्रॉलर और उद्धरण डेटा उत्पन्न हो सके।
एक व्यावहारिक प्रारंभिक डिज़ाइन में शामिल होगा:
- 240 से 800 पेज।
- प्रति पेज टेम्पलेट में कम से कम 20 पेज।
- तीन से पाँच सामग्री श्रेणियां।
- सदाबहार और नियमित रूप से अद्यतन पेजों का मिश्रण।
- प्रत्येक उपचार समूह में पेजों की समान संख्या।
प्रत्येक पेज में होना चाहिए:
- समान HTML संरचना।
- समान सामग्री की लंबाई।
- एक ही प्रकाशन प्रणाली।
- एक ही आंतरिक लिंकिंग पैटर्न।
- एक ही कैनोनिकल नियम।
- एक ही साइटमैप उपचार।
- एक ही robots.txt अनुमतियाँ।
- एक अनूठा, उपयोगी विषय।
केवल प्रयोग के लिए सैकड़ों पतले या लगभग-डुप्लिकेट पेज न बनाएँ। Google का मार्गदर्शन चेतावनी देता है कि डुप्लिकेट और कम-मूल्य वाले यूआरएल क्रॉल संसाधनों को बर्बाद कर सकते हैं और एक साइट की दक्षता को कम कर सकते हैं। (developers.google.com)
एक युग्मित-जोड़ी डिज़ाइन उपयोगी है। उदाहरण के लिए, समान पेजों को युग्मित करें:
- सामग्री की लंबाई।
- विषय की मांग।
- अद्यतन आवृत्ति।
- आंतरिक लिंक गणना।
- बाहरी लिंक गणना।
- ऐतिहासिक ट्रैफिक।
- खोज रैंकिंग स्थिति।
फिर प्रत्येक जोड़ी से एक पेज को नियंत्रण समूह में और दूसरे को उपचार समूह में रखें।
2. एक फैक्टोरियल उपचार डिज़ाइन का उपयोग करें
मुख्य प्रदर्शन उपचारों का स्वतंत्र रूप से और एक साथ परीक्षण किया जाना चाहिए।
| उपचार कारक | नियंत्रण | उपचार |
|---|---|---|
| HTTP प्रोटोकॉल | HTTP/2 | HTTP/3, HTTP/2 फ़ॉलबैक के साथ |
| एज कैशिंग | मूल वितरण या बाईपास किया गया पेज कैश | एज कैश से सार्वजनिक सामग्री परोसी गई |
| छवि वितरण | मौजूदा छवि फाइलें | रिस्पॉन्सिव WebP या AVIF छवियां |
| लेआउट स्थिरता | मौजूदा लेआउट व्यवहार | आरक्षित छवि, विज्ञापन, और एम्बेड आयाम |
यह तीन अनुरोधित अनुकूलन के लिए एक नियंत्रित प्रयोग बनाता है:
- HTTP/3।
- कंटेंट डिलीवरी नेटवर्क एज कैशिंग।
- छवि संपीड़न।
लेआउट स्थिरता उपचार आवश्यक है क्योंकि पहले तीन अनुकूलन क्युमुलेटिव लेआउट शिफ्ट को विश्वसनीय रूप से अलग नहीं करते हैं। छवि संपीड़न लेआउट स्थिरता को बिल्कुल भी बदले बिना लार्जेस्ट कंटेंटफुल पेंट को कम कर सकता है।
HTTP/3 को अपने स्वयं के माप की आवश्यकता क्यों है
HTTP/3 QUIC ट्रांसपोर्ट प्रोटोकॉल का उपयोग करता है और स्वतंत्र स्ट्रीम प्रदान करता है, जो TCP पर HTTP/2 में पाए जाने वाले ट्रांसपोर्ट-लेवल हेड-ऑफ-लाइन ब्लॉकिंग से बच सकता है। इसके लाभ इस बात पर निर्भर करते हैं कि क्लाइंट या क्रॉलर वास्तव में HTTP/3 पर बातचीत करता है या नहीं। (rfc-editor.org)
इसलिए, प्रत्येक अनुरोध के लिए बातचीत किए गए प्रोटोकॉल को रिकॉर्ड करें:
- HTTP/1.1।
- HTTP/2।
- HTTP/3।
यह न मानें कि HTTP/3 को सक्षम करने का मतलब है कि हर क्रॉलर इसका उपयोग करता है। यदि Googlebot, OAI-SearchBot, या कोई अन्य क्रॉलर HTTP/2 का उपयोग करना जारी रखता है, तो HTTP/3 उस क्रॉलर के अनुरोधों को प्रभावित नहीं कर सकता है।
एज कैशिंग का सावधानी से परीक्षण क्यों किया जाना चाहिए
एक कंटेंट डिलीवरी नेटवर्क अनुरोधकर्ता के करीब सामग्री परोसकर टाइम टू फर्स्ट बाइट को कम कर सकता है। यह मूल सर्वर तक पहुंचने वाले अनुरोधों की संख्या को भी कम कर सकता है। (web.dev)
कम से कम तीन कैश स्थितियों का परीक्षण करें:
- कोल्ड कैश — एज को मूल से संपर्क करना होगा।
- वार्म कैश — एज मूल से संपर्क किए बिना पेज परोसता है।
- पुनर्मूल्यांकित कैश — एज या क्रॉलर एक
ETagयाLast-Modifiedमान का उपयोग करता है और304 Not Modifiedप्रतिक्रिया प्राप्त करता है।
Google विशेष रूप से कुशल HTTP कैशिंग की सिफारिश करता है और अनावश्यक प्रसंस्करण और बैंडविड्थ को कम करने के लिए 304 Not Modified प्रतिक्रियाओं के उपयोग का समर्थन करता है। (developers.google.com)
क्रॉलरों को बासी या गलत सामग्री परोसने के लिए कैशिंग की अनुमति न दें। रिकॉर्ड करें:
- कैश हिट या मिस।
- कैश आयु।
- एज स्थान।
- मूल प्रतिक्रिया समय।
- सामग्री संस्करण।
- स्थिति कोड।
- मान्यता हेडर।
छवि संपीड़न को लार्जेस्ट कंटेंटफुल पेंट से क्यों जोड़ा जाना चाहिए
WebP और AVIF आम तौर पर पुराने छवि प्रारूपों की तुलना में बेहतर संपीड़न प्रदान करते हैं। छोटी छवियां स्थानांतरण समय को कम कर सकती हैं और लार्जेस्ट कंटेंटफुल पेंट में सुधार कर सकती हैं जब छवि लार्जेस्ट कंटेंटफुल पेंट तत्व होती है। (web.dev)
परीक्षण में इसका उपयोग किया जाना चाहिए:
- समान छवि आयाम।
- समान दृश्य गुणवत्ता लक्ष्य।
- रिस्पॉन्सिव
srcsetछवियां। - उपयुक्त फ़ॉलबैक के साथ एक आधुनिक प्रारूप।
- स्पष्ट
widthऔरheightमान। - लार्जेस्ट कंटेंटफुल पेंट छवि के लिए कोई लेज़ी लोडिंग नहीं।
- प्रारंभिक HTML में दिखाई देने वाला एक छवि URL।
यदि वास्तविक देरी जावास्क्रिप्ट या देर से संसाधन खोज से आती है, तो केवल छवि संपीड़न लार्जेस्ट कंटेंटफुल पेंट में सुधार नहीं कर सकता है। Google का प्रदर्शन मार्गदर्शन बताता है कि यदि लार्जेस्ट कंटेंटफुल पेंट तत्व देर से प्रकट होता है, तो छवि डाउनलोड समय को कम करने से देरी पेज के दूसरे हिस्से में स्थानांतरित हो सकती है। (web.dev)
3. परीक्षण को पर्याप्त समय तक चलाएँ
एक छोटा परीक्षण क्रॉल शेड्यूलिंग और इंडेक्स रिफ्रेश के प्रभावों को याद कर सकता है।
एक व्यावहारिक डिज़ाइन है:
- बेसलाइन माप के दो सप्ताह।
- उपचार माप के छह से बारह सप्ताह।
- यदि संभव हो तो एक अंतिम रिवर्सल या क्रॉसओवर अवधि।
एक क्रॉसओवर परीक्षण के लिए, मिलान किए गए पेज समूहों के बीच उपचार बदलें। यदि उपचार हटाने पर प्रदर्शन प्रभाव गायब हो जाता है, तो परिणाम एक साधारण पहले और बाद की तुलना से अधिक मजबूत होता है।
कोर वेब वाइटल्स फील्ड डेटा का उपयुक्त अवधि में मूल्यांकन किया जाना चाहिए। क्रोम उपयोगकर्ता अनुभव रिपोर्ट एक रोलिंग 28-दिवसीय एकत्रीकरण का उपयोग करती है, इसलिए इसे डिप्लॉयमेंट के बाद तत्काल परिवर्तन दिखाने के लिए डिज़ाइन नहीं किया गया है। (developer.chrome.com)
4. संपूर्ण क्रॉलर जनसंख्या को मापें
सभी स्वचालित ट्रैफिक को एक समूह के रूप में न मानें।
कम से कम, अलग करें:
खोज क्रॉलर
- Googlebot।
- Bingbot।
आर्टिफिशियल इंटेलिजेंस खोज क्रॉलर
- OAI-SearchBot।
- PerplexityBot।
- Claude-SearchBot।
उपयोगकर्ता-अनुरोधित फ़ेचर
- Perplexity-User।
- Claude-User।
- ChatGPT उपयोगकर्ता फ़ेचर जहाँ पहचान योग्य हो।
प्रशिक्षण क्रॉलर
- GPTBot।
- ClaudeBot।
- Google-Extended नियंत्रण।
प्रशिक्षण क्रॉलरों का उपयोग आर्टिफिशियल इंटेलिजेंस खोज उद्धरणों के लिए प्रॉक्सी के रूप में नहीं किया जाना चाहिए। Anthropic, OpenAI और Google प्रशिक्षण, खोज या उपयोगकर्ता-अनुरोधित पुनर्प्राप्ति के लिए उपयोग किए जाने वाले क्रॉलरों के बीच अंतर करते हैं। Google यह भी कहता है कि Google-Extended Google खोज में शामिल होने या रैंकिंग को प्रभावित नहीं करता है। (help.openai.com)
Perplexity भी इसी तरह PerplexityBot, जो खोज अनुक्रमण का समर्थन करता है, और Perplexity-User, जो उपयोगकर्ता के अनुरोध के जवाब में एक पेज को पुनः प्राप्त कर सकता है, के बीच अंतर करता है। (docs.perplexity.ai)
प्रकाशित IP सीमाओं या रिवर्स DNS का उपयोग करके क्रॉलर पहचान को सत्यापित करें जहाँ प्रदाता इसका समर्थन करता है। उपयोगकर्ता-एजेंट स्ट्रिंग को असंबंधित क्रॉलरों द्वारा कॉपी किया जा सकता है। Google विशेष रूप से चेतावनी देता है कि Googlebot उपयोगकर्ता-एजेंट स्ट्रिंग को स्पूफ किया जा सकता है। (developers.google.com)
एकत्र किए जाने वाले मेट्रिक्स
प्रदर्शन मेट्रिक्स
प्रयोगशाला और वास्तविक-उपयोगकर्ता दोनों डेटा एकत्र करें:
- टाइम टू फर्स्ट बाइट।
- फर्स्ट कंटेंटफुल पेंट।
- लार्जेस्ट कंटेंटफुल पेंट।
- क्युमुलेटिव लेआउट शिफ्ट।
- इंटरेक्शन टू नेक्स्ट पेंट।
- कुल पेज वजन।
- प्रारंभिक HTML आकार।
- छवि स्थानांतरण आकार।
- अनुरोधों की संख्या।
- सर्वर प्रोसेसिंग में व्यतीत समय।
- लार्जेस्ट कंटेंटफुल पेंट संसाधन की प्रतीक्षा में व्यतीत समय।
- HTTP प्रोटोकॉल।
- कैश स्थिति।
Google 800 मिलीसेकंड या उससे कम के मोटे तौर पर टाइम टू फर्स्ट बाइट लक्ष्य की सिफारिश करता है, लेकिन टाइम टू फर्स्ट बाइट स्वयं एक कोर वेब वाइटल नहीं है। (web.dev)
75वें पर्सेंटाइल पर वर्तमान कोर वेब वाइटल्स "अच्छा" थ्रेशोल्ड हैं:
- लार्जेस्ट कंटेंटफुल पेंट: 2.5 सेकंड या उससे कम।
- क्युमुलेटिव लेआउट शिफ्ट: 0.1 या उससे कम।
- इंटरेक्शन टू नेक्स्ट पेंट: 200 मिलीसेकंड या उससे कम। (web.dev)
क्रॉल मेट्रिक्स
प्रत्येक सत्यापित क्रॉलर अनुरोध के लिए, रिकॉर्ड करें:
text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer
गणना करें:
text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index
आर्टिफिशियल इंटेलिजेंस उद्धरण मेट्रिक्स
प्रत्येक प्लेटफ़ॉर्म पर क्वेरीज़ का एक निश्चित सेट उपयोग करें। क्वेरी सेट में शामिल होना चाहिए:
- प्रत्यक्ष तथ्यात्मक प्रश्न।
- तुलनात्मक प्रश्न।
- "सर्वश्रेष्ठ" या अनुशंसा प्रश्न।
- ताजगी-संवेदनशील प्रश्न।
- ऐसे प्रश्न जहाँ परीक्षण किया गया पेज सबसे मजबूत उत्तर है।
- ऐसे प्रश्न जहाँ परीक्षण किया गया पेज प्रासंगिक है लेकिन प्रभावी नहीं है।
प्रत्येक क्वेरी के लिए, रिकॉर्ड करें:
text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash
क्वेरीज़ को दोहराएँ क्योंकि आर्टिफिशियल इंटेलिजेंस उत्तर भिन्न हो सकते हैं। एक निश्चित शेड्यूल का उपयोग करें, जैसे प्रति सप्ताह तीन बार, और इंजन या मॉडल में परिवर्तनों को रिकॉर्ड करें।
Microsoft Bing वेबमास्टर टूल्स अब एक आर्टिफिशियल इंटेलिजेंस प्रदर्शन रिपोर्ट प्रदान करता है जो समर्थित Microsoft आर्टिफिशियल इंटेलिजेंस अनुभवों में उद्धृत पेज, ग्राउंडिंग क्वेरीज़ और उद्धरण प्रवृत्तियों को दर्शाता है। Microsoft चेतावनी देता है कि डेटा एकत्रित, नमूनाकृत और अवलोकन संबंधी है; यह साबित नहीं कर सकता कि किसी विशेष पेज परिवर्तन के कारण उद्धरण परिवर्तन हुआ। (bing.com)
Google ने जून 2026 में सर्च कंसोल में समर्पित जनरेटिव आर्टिफिशियल इंटेलिजेंस प्रदर्शन रिपोर्ट भी जारी करना शुरू कर दिया। रिपोर्टें शुरू में वेबसाइटों के केवल एक उपसमूह के लिए उपलब्ध थीं, इसलिए पहुंच भिन्न हो सकती है। (developers.google.com)
सांख्यिकीय विश्लेषण
क्रॉलिंग आवृत्ति
एक मिश्रित-प्रभाव गणना मॉडल का उपयोग करें, जैसे एक नकारात्मक द्विपद मॉडल:
text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)
पेज और क्रॉलर प्रभाव मायने रखते हैं क्योंकि कुछ पेजों को स्वाभाविक रूप से दूसरों की तुलना में अधिक ध्यान मिलता है, और विभिन्न क्रॉलरों के अलग-अलग शेड्यूल होते हैं।
खोज और अनुक्रमण
इसके लिए अस्तित्व विश्लेषण का उपयोग करें:
- प्रकाशन से पहली फ़ेच तक का समय।
- प्रकाशन से पहले इंडेक्स तक का समय।
- अपडेट से पुनर्कुंजीकरण तक का समय।
मुख्य परिणाम केवल यह नहीं है कि एक पेज अंततः क्रॉल किया गया था या नहीं। यह है कि क्या उपचार ने पेज को खोजने और संसाधित करने के लिए आवश्यक समय को कम कर दिया।
आर्टिफिशियल इंटेलिजेंस उद्धरण चयन
एक पदानुक्रमित लॉजिस्टिक मॉडल का उपयोग करें:
text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)
दो अलग-अलग मॉडल चलाएँ:
- पुनर्प्राप्ति मॉडल — क्या पेज को पुनः प्राप्त किया गया या एक उम्मीदवार के रूप में दिखाया गया?
- उद्धरण मॉडल — यदि पुनः प्राप्त किया गया, तो क्या पेज को स्पष्ट रूप से उद्धृत किया गया था?
यह अंतर आवश्यक है। एक प्रदर्शन सुधार जो क्रॉलिंग को बढ़ाता है लेकिन पुनर्प्राप्ति को नहीं, वह आर्टिफिशियल इंटेलिजेंस उद्धरण प्रभाव नहीं है। एक प्रदर्शन सुधार जो पुनर्प्राप्ति को बढ़ाता है लेकिन उद्धरणों को नहीं, यह बताता है कि पेज पर विचार किया जा रहा है लेकिन स्रोत चयन के दौरान वह हार जाता है।
अपेक्षित निष्कर्ष
ये कार्यशील परिकल्पनाएँ हैं, न कि दावा किए गए प्रायोगिक परिणाम।
परिकल्पना 1: टाइम टू फर्स्ट बाइट का सबसे स्पष्ट क्रॉल प्रभाव होगा
कम टाइम टू फर्स्ट बाइट और क्रॉल क्षमता के बीच एक सकारात्मक संबंध की उम्मीद करें जब:
- साइट में कई पेज हैं।
- पेज अक्सर बदलते रहते हैं।
- मूल सर्वर धीमा या अतिभारित है।
- साइट 5xx या 429 प्रतिक्रियाएँ लौटाती है।
- क्रॉलर प्रतिक्रियाओं की प्रतीक्षा में महत्वपूर्ण समय व्यतीत करता है।
कम क्रॉल मांग वाली एक छोटी साइट पर बहुत कम मापने योग्य प्रभाव की उम्मीद करें।
परिकल्पना 2: लार्जेस्ट कंटेंटफुल पेंट रेंडरिंग और संसाधन वितरण के माध्यम से मायने रखेगा
कम लार्जेस्ट कंटेंटफुल पेंट से मदद की उम्मीद करें जब:
- पेज ब्राउज़र रेंडरिंग पर निर्भर करता है।
- महत्वपूर्ण सामग्री जावास्क्रिप्ट के पीछे है।
- अनुक्रमण के लिए बड़ी छवियां या स्टाइलशीट आवश्यक हैं।
- क्रॉलर कई पेज संसाधनों को फ़ेच करता है।
- धीमा उपचार टाइमआउट या अधूरा रेंडरिंग उत्पन्न करता है।
कमजोर संबंध की उम्मीद करें जब पेज का महत्वपूर्ण पाठ पहले से ही प्रारंभिक HTML में मौजूद हो।
परिकल्पना 3: क्युमुलेटिव लेआउट शिफ्ट का बहुत कम सीधा प्रभाव होगा
पेज संरचना और जावास्क्रिप्ट व्यवहार को नियंत्रित करने के बाद क्युमुलेटिव लेआउट शिफ्ट और क्रॉल आवृत्ति या उद्धरण दर के बीच कोई सार्थक सीधा संबंध की उम्मीद न करें।
यदि क्युमुलेटिव लेआउट शिफ्ट उद्धरणों की भविष्यवाणी करता प्रतीत होता है, तो जांच करें कि क्या यह इसके लिए एक प्रॉक्सी के रूप में कार्य कर रहा है:
- क्लाइंट-साइड रेंडरिंग।
- देर से सामग्री डालना।
- अस्थिर विज्ञापन।
- छिपा हुआ या विलंबित पाठ।
- खराब संरचित HTML।
परिकल्पना 4: केवल गति से अधिक आर्टिफिशियल इंटेलिजेंस उद्धरण उत्पन्न नहीं होंगे
उद्धरण चयन के सबसे मजबूत भविष्यवक्ता संभवतः बने रहेंगे:
- क्वेरी से प्रासंगिकता।
- सामग्री की गुणवत्ता।
- स्पष्ट उत्तर।
- ताजगी।
- अधिकार और विश्वास।
- खोज अनुक्रमण पात्रता।
- पुनर्प्राप्ति रैंक।
- क्या पेज किए जा रहे दावे का सीधे समर्थन करता है।
Google का मार्गदर्शन उपयोगी, विश्वसनीय, लोगों-के-लिए-सर्वोत्तम सामग्री पर जोर देता है और कहता है कि आर्टिफिशियल इंटेलिजेंस खोज सुविधाएँ मौजूदा खोज और अनुक्रमण प्रणालियों पर आधारित हैं। (developers.google.com)
आर्टिफिशियल इंटेलिजेंस पुनर्प्राप्ति के लिए ट्यून किया गया प्रदर्शन बजट
निम्नलिखित एक प्रस्तावित परिचालन बजट है। यह एक प्रकाशित आर्टिफिशियल इंटेलिजेंस रैंकिंग सूत्र नहीं है।
| क्षेत्र | अनुशंसित लक्ष्य | कारण |
|---|---|---|
| नेविगेशन टाइम टू फर्स्ट बाइट, 75वां पर्सेंटाइल | 800 मिलीसेकंड या उससे कम | मोटे वेब प्रदर्शन गाइड के साथ संरेखित करता है |
| नेविगेशन टाइम टू फर्स्ट बाइट, 95वां पर्सेंटाइल | 1.5 सेकंड या उससे कम | धीमी क्रॉलर प्रतिक्रियाओं के खिलाफ आंतरिक सुरक्षा |
| लार्जेस्ट कंटेंटफुल पेंट, 75वां पर्सेंटाइल | 2.5 सेकंड या उससे कम | वर्तमान “अच्छा” कोर वेब वाइटल थ्रेशोल्ड |
| आंतरिक लार्जेस्ट कंटेंटफुल पेंट लक्ष्य | 2.0 सेकंड या उससे कम | नेटवर्क भिन्नता के लिए जगह छोड़ता है |
| क्युमुलेटिव लेआउट शिफ्ट, 75वां पर्सेंटाइल | 0.1 या उससे कम | वर्तमान “अच्छा” थ्रेशोल्ड |
| आंतरिक क्युमुलेटिव लेआउट शिफ्ट लक्ष्य | 0.05 या उससे कम | लेआउट अस्थिरता और देर से गति को कम करता है |
| इंटरेक्शन टू नेक्स्ट पेंट, 75वां पर्सेंटाइल | 200 मिलीसेकंड या उससे कम | वर्तमान “अच्छा” थ्रेशोल्ड |
| प्रारंभिक HTML | अधिमानतः 150 किलोबाइट या उससे कम संपीड़ित | महत्वपूर्ण सामग्री को फ़ेच करना और संसाधित करना आसान बनाता है |
| असंपीड़ित प्रारंभिक HTML | 2 मेगाबाइट से काफी नीचे रखें | Googlebot वर्तमान में पहले HTML फ़ेच को 2 मेगाबाइट तक सीमित करता है |
| महत्वपूर्ण सामग्री स्थिति | टाइटल, कैनोनिकल, हेडिंग, सारांश और संरचित डेटा HTML में जल्दी | महत्वपूर्ण जानकारी के देर से प्रकट होने के जोखिम को कम करता है |
| लार्जेस्ट कंटेंटफुल पेंट छवि | प्रारंभिक HTML में खोजने योग्य | जावास्क्रिप्ट खोज देरी से बचा जाता है |
| लार्जेस्ट कंटेंटफुल पेंट छवि | जहाँ उपयुक्त हो, रिस्पॉन्सिव WebP या AVIF का उपयोग करें | स्थानांतरण आकार को कम करता है |
| छवियां और एम्बेड | हमेशा आयाम आरक्षित करें | लेआउट आंदोलन को रोकता है |
| सार्वजनिक HTML कैश हिट दर | 70 प्रतिशत या उससे अधिक का आंतरिक लक्ष्य निर्धारित करें | मूल लेटेंसी को कम करता है |
| स्टैटिक एसेट कैश हिट दर | 90 प्रतिशत या उससे अधिक का आंतरिक लक्ष्य निर्धारित करें | दोहराने वाले स्थानांतरण लागत को कम करता है |
| सत्यापित क्रॉलरों को 5xx और 429 प्रतिक्रियाएँ | जितना संभव हो शून्य के करीब; किसी भी निरंतर वृद्धि पर अलर्ट करें | ये प्रतिक्रियाएँ क्रॉलिंग को कम कर सकती हैं |
| रीडायरेक्ट | शून्य अनावश्यक रीडायरेक्ट; कभी भी लंबी श्रृंखलाओं का उपयोग न करें | रीडायरेक्ट श्रृंखलाएँ क्रॉल और उपयोगकर्ता समय बर्बाद करती हैं |
| ताज़ा सामग्री प्रतिक्रिया | ETag और Last-Modified का समर्थन करें | कुशल सत्यापन और 304 प्रतिक्रियाओं की अनुमति देता है |
Google के वर्तमान दस्तावेज़ में कहा गया है कि Googlebot एक समर्थित फ़ाइल के पहले 2 मेगाबाइट को फ़ेच करता है और बाहरी स्क्रिप्ट और स्टाइलशीट को अलग से फ़ेच करता है। यह महत्वपूर्ण मेटाडेटा और संरचित डेटा को HTML में जल्दी रखने की भी सिफारिश करता है। (developers.google.com)
कार्यान्वयन अनुशंसाएँ
HTTP/3
HTTP/3 का उपयोग करें जब यह होस्टिंग प्रदाता और कंटेंट डिलीवरी नेटवर्क द्वारा समर्थित हो।
मापें:
- HTTP/3 बातचीत दर।
- HTTP/2 फ़ॉलबैक दर।
- कनेक्शन सेटअप समय।
- टाइम टू फर्स्ट बाइट।
- भौगोलिक क्षेत्र द्वारा प्रदर्शन।
- क्रॉलर द्वारा प्रदर्शन।
HTTP/3 को एक गारंटीकृत खोज या आर्टिफिशियल इंटेलिजेंस अनुकूलन के रूप में न मानें। यह एक परिवहन सुधार है जो केवल उन क्लाइंट्स की मदद कर सकता है जो इसका उपयोग करते हैं।
कंटेंट डिलीवरी नेटवर्क एज कैशिंग
सार्वजनिक, गैर-व्यक्तिगत पेजों के लिए:
- स्पष्ट
Cache-Controlनियम निर्धारित करें। - संस्करणित स्थिर संपत्तियों के लिए दीर्घकालिक कैशिंग का उपयोग करें।
- अक्सर अपडेट किए जाने वाले HTML के लिए छोटी लेकिन उपयोगी कैशिंग का उपयोग करें।
- अनावश्यक क्वेरी पैरामीटर से कैश विखंडन से बचें।
- कैनोनिकल यूआरएल को संरक्षित करें।
ETagऔरLast-Modifiedका समर्थन करें।- कोल्ड, वार्म और पुनर्मूल्यांकित कैश स्थितियों का परीक्षण करें।
- पुष्टि करें कि क्रॉलर अनुरोधों को वही महत्वपूर्ण सामग्री प्राप्त होती है जो मानव अनुरोधों को मिलती है।
एक कंटेंट डिलीवरी नेटवर्क को बासी, असंगत या बॉट-विशिष्ट पेज संस्करण बनाए बिना लेटेंसी को कम करना चाहिए।
छवि संपीड़न
छवियों के लिए:
- AVIF या WebP का उपयोग करें जब दृश्य गुणवत्ता स्वीकार्य हो।
- रिस्पॉन्सिव छवि आकार प्रदान करें।
- एक छोटे मोबाइल स्क्रीन पर डेस्कटॉप आकार की छवि न परोसें।
- लार्जेस्ट कंटेंटफुल पेंट छवि को लेज़ी-लोड न करें।
- छवि आयाम शामिल करें।
- लार्जेस्ट कंटेंटफुल पेंट छवि को प्रारंभिक HTML में रखें।
fetchpriority="high"का उपयोग केवल तभी करें जब उपयुक्त हो।- महत्वपूर्ण स्पष्टीकरणों को छवियों के अंदर एम्बेड करने के बजाय पाठ में रखें।
छवि संपीड़न सबसे मूल्यवान होता है जब छवि लार्जेस्ट कंटेंटफुल पेंट तत्व होती है। यह उस पेज को ठीक नहीं करेगा जिसकी मुख्य देरी सर्वर रेंडरिंग या जावास्क्रिप्ट निष्पादन से आती है। (web.dev)
लेआउट स्थिरता
क्युमुलेटिव लेआउट शिफ्ट को कम करने के लिए:
- छवियों पर चौड़ाई और ऊंचाई गुण निर्धारित करें।
- विज्ञापनों के लिए जगह आरक्षित करें।
- एम्बेडेड वीडियो और सामाजिक सामग्री के लिए जगह आरक्षित करें।
- मौजूदा पाठ के ऊपर बैनर डालने से बचें।
- स्थिर फ़ॉन्ट लोडिंग रणनीतियों का उपयोग करें।
- पेज लोड होने के बाद सर्वर-रेंडर की गई सामग्री के बड़े ब्लॉक को बदलने से बचें।
ये परिवर्तन उपयोगकर्ता अनुभव में सुधार करते हैं, भले ही उनका क्रॉलिंग या उद्धरणों पर कोई मापने योग्य प्रभाव न हो। (web.dev)
टूलींग और निगरानी
प्रदर्शन उपकरण
उपयोग करें:
- वास्तविक-उपयोगकर्ता कोर वेब वाइटल्स के लिए क्रोम उपयोगकर्ता अनुभव रिपोर्ट।
- स्वचालित फील्ड डेटा संग्रह के लिए क्रोम उपयोगकर्ता अनुभव रिपोर्ट एप्लिकेशन प्रोग्रामिंग इंटरफेस।
- प्रयोगशाला ऑडिट और फील्ड डेटा के लिए पेजस्पीड इनसाइट्स।
- दोहराने योग्य प्रयोगशाला परीक्षणों के लिए लाइटहाउस।
- पुल-रिक्वेस्ट प्रदर्शन बजट के लिए लाइटहाउस कंटीन्यूअस इंटीग्रेशन।
- बहु-स्थान परीक्षणों, कैश स्थितियों और प्रोटोकॉल तुलनाओं के लिए वेबपेजटेस्ट।
- लार्जेस्ट कंटेंटफुल पेंट और लेआउट शिफ्ट डिबगिंग के लिए क्रोम देवटूल्स।
- वास्तविक-उपयोगकर्ता निगरानी के लिए वेब-वाइटल्स जावास्क्रिप्ट लाइब्रेरी।
क्रोम उपयोगकर्ता अनुभव रिपोर्ट एप्लिकेशन प्रोग्रामिंग इंटरफेस पेज-स्तरीय और मूल-स्तरीय एकत्रित फील्ड डेटा प्रदान करता है, जिसमें लार्जेस्ट कंटेंटफुल पेंट, क्युमुलेटिव लेआउट शिफ्ट, इंटरेक्शन टू नेक्स्ट पेंट, और प्रायोगिक टाइम टू फर्स्ट बाइट शामिल हैं। (developer.chrome.com)
लाइटहाउस कंटीन्यूअस इंटीग्रेशन हर कोड परिवर्तन पर प्रदर्शन जांच चला सकता है और जब बजट पार हो जाता है तो बिल्ड को विफल कर सकता है। (github.com)
क्रॉलर निगरानी
सर्वर लॉग, एज लॉग और सिंथेटिक प्रोब के एक छोटे सेट का उपयोग करें।
उदाहरण प्रोब:
bash
curl --http3 -sS -o /dev/null -D - \
-w 'status=%{http_code}
http_version=%{http_version}
namelookup=%{time_namelookup}
connect=%{time_connect}
starttransfer=%{time_starttransfer}
total=%{time_total}
size=%{size_download}
' \
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)' \
https://example.com/page
इसी परीक्षण को इसके साथ चलाएँ:
- Googlebot।
- Bingbot।
- OAI-SearchBot।
- PerplexityBot।
- Claude-SearchBot।
- एक सामान्य ब्राउज़र उपयोगकर्ता-एजेंट।
परीक्षण को सत्यापित करना चाहिए:
- स्टेटस कोड।
- रोबोट्स अनुमति।
- प्रतिक्रिया हेडर।
- HTML सामग्री।
- HTTP संस्करण।
- कैश स्थिति।
- प्रतिक्रिया समय।
- क्या महत्वपूर्ण पाठ जावास्क्रिप्ट के बिना मौजूद है।
खोज और अनुक्रमण निगरानी
उपयोग करें:
- Google सर्च कंसोल क्रॉल आंकड़े।
- Google सर्च कंसोल पेज अनुक्रमण रिपोर्ट।
- Google सर्च कंसोल यूआरएल निरीक्षण।
- Google सर्च कंसोल साइटमैप डेटा।
- उपलब्ध होने पर Google सर्च कंसोल जनरेटिव आर्टिफिशियल इंटेलिजेंस रिपोर्ट।
- बिंग वेबमास्टर टूल्स क्रॉल अनुरोध और अनुक्रमित पेज।
- बिंग वेबमास्टर टूल्स आर्टिफिशियल इंटेलिजेंस प्रदर्शन।
- दैनिक साइटमैप और
lastmodजांच।
सर्च कंसोल एप्लिकेशन प्रोग्रामिंग इंटरफेस पेज, क्वेरी, तिथि, डिवाइस और खोज उपस्थिति के अनुसार प्रदर्शन डेटा पुनः प्राप्त कर सकता है, जो उसकी डेटा सीमाओं के अधीन है। (developers.google.com)
उद्धरण निगरानी
प्रति विषय 50 से 200 स्थिर क्वेरीज़ वाला एक उद्धरण पैनल बनाएँ। पैनल को एक निश्चित शेड्यूल पर चलाएँ और रिकॉर्ड करें:
- क्या प्लेटफ़ॉर्म ने खोजा।
- कौन से स्रोत दिखाई दिए।
- क्या परीक्षणित यूआरएल को उद्धृत किया गया था।
- उद्धरण क्रम।
- उत्तर की तिथि और समय।
- क्या पेज बदला।
- क्या मॉडल या खोज अनुभव बदला।
विभिन्न प्रणालियों से उद्धरण गणना की तुलना इस तरह न करें जैसे वे समकक्ष हों। Microsoft का कहना है कि उद्धरण गतिविधि एक रैंकिंग स्कोर, अधिकार स्कोर, ट्रैफिक माप या गुणवत्ता स्कोर नहीं है। (bing.com)
अलर्ट नियम
इसके लिए अलर्ट बनाएँ:
- टाइम टू फर्स्ट बाइट में 25 प्रतिशत से अधिक की वृद्धि।
- 75वें पर्सेंटाइल पर लार्जेस्ट कंटेंटफुल पेंट का 2.5 सेकंड से ऊपर जाना।
- क्युमुलेटिव लेआउट शिफ्ट का 0.1 से ऊपर जाना।
- 5xx या 429 प्रतिक्रियाओं में निरंतर वृद्धि।
- क्रॉलर सफलता दर में गिरावट।
- एक robots.txt परिवर्तन।
- एक साइटमैप त्रुटि।
- अनुक्रमित पेजों में अचानक गिरावट।
- कई प्लेटफ़ॉर्मों पर आर्टिफिशियल इंटेलिजेंस उद्धरणों में अचानक गिरावट।
- उद्धरण मात्रा में परिवर्तन जो केवल एक प्लेटफ़ॉर्म को प्रभावित करता है।
एक प्लेटफ़ॉर्म को प्रभावित करने वाली उद्धरण गिरावट किसी पेज के प्रदर्शन समस्या के बजाय एक मॉडल, इंडेक्स, क्वेरी या उत्पाद परिवर्तन के कारण हो सकती है। Microsoft स्पष्ट रूप से चेतावनी देता है कि उद्धरण प्रवृत्तियाँ अवलोकन संबंधी हैं और सामग्री अपडेट, उपयोगकर्ता मांग, और सिस्टम या मॉडल परिवर्तनों के कारण बदल सकती हैं। (bing.com)
अंतिम निष्कर्ष
सबसे बचाव योग्य निष्कर्ष है:
तेज़ पेज क्रॉल दक्षता में सुधार कर सकते हैं, खासकर जब सर्वर लेटेंसी, संसाधन आकार, त्रुटियां, या रेंडरिंग में देरी सीमित कारक हों। लेकिन वर्तमान में कोई मजबूत सबूत नहीं है कि कम कोर वेब वाइटल्स सीधे आर्टिफिशियल इंटेलिजेंस सिस्टम को एक पेज को उद्धरण के रूप में चुनने का कारण बनते हैं।
अपेक्षित कारण श्रृंखला है:
text Lower latency → better server capacity → fewer failed or delayed fetches → faster discovery and processing → improved chance of being indexed and retrieved → possible increase in citations
अंतिम चरण अनिश्चित बना हुआ है क्योंकि उद्धरण चयन प्रासंगिकता, गुणवत्ता, ताजगी, अधिकार, क्वेरी इरादे, पुनर्प्राप्ति रैंक और प्रत्येक आर्टिफिशियल इंटेलिजेंस सिस्टम के व्यवहार पर निर्भर करता है।
अधिकांश वेबसाइटों के लिए, सही प्रदर्शन रणनीति इसलिए अकेले "आर्टिफिशियल इंटेलिजेंस उद्धरणों के लिए अनुकूलन" नहीं है। यह है:
- महत्वपूर्ण सामग्री को प्रारंभिक HTML में उपलब्ध रखें।
- टाइम टू फर्स्ट बाइट को स्थिर रखें।
- सार्वजनिक सामग्री के लिए एज कैशिंग का उपयोग करें।
- महत्वपूर्ण छवियों को संपीड़ित करें और प्राथमिकता दें।
- लेआउट शिफ्ट को रोकें।
- विश्वसनीय स्थिति कोड लौटाएँ।
- साइटमैप और आंतरिक लिंक को अद्यतन रखें।
- सही खोज क्रॉलरों को अनुमति दें।
- क्रॉलिंग, अनुक्रमण, पुनर्प्राप्ति और उद्धरण को अलग-अलग चरणों के रूप में मापें।
वह दृष्टिकोण लोगों के लिए एक तेज़ वेबसाइट, खोज क्रॉलरों के लिए एक स्वस्थ साइट, और आर्टिफिशियल इंटेलिजेंस दृश्यता को समझने के लिए एक परीक्षण योग्य नींव तैयार करता है।
Auto