आपने अपना कंटेंट ऑप्टिमाइज़ किया है। आपकी साइट में विशेषज्ञता, अथॉरिटी और भरोसे के संकेत हैं। लेकिन जब कोई AI क्रॉलर आपके पेज पर पहुंचता है और टाइमआउट से टकराता है, जब आपका सर्वर जवाब देने में 6 सेकंड लेता है, या जब LCP 5 सेकंड तक रेंडर नहीं हो पाता, तो क्रॉलर आगे बढ़ जाता है। आपका कंटेंट कभी इंडेक्स नहीं होता। आपके कोट कभी नहीं मिलते।
स्पीड विज़िबिलिटी को खत्म कर देती है। धीरे-धीरे नहीं। एक झटके में, रुककर।
AI क्रॉलर ऐसी बंदिशों में काम करते हैं जो पारंपरिक सर्च इंजन पर नहीं होतीं। उनकी टाइमआउट की खिड़कियां सख़्त होती हैं, कंप्यूट बजट सीमित होता है और सब्र कम। जो पेज Google के लिए पूरी तरह रैंक करता है, वह ChatGPT, Perplexity या Claude को पूरी तरह अदृश्य हो सकता है, क्योंकि वह क्रॉलर की डेडलाइन के भीतर लोड नहीं हो पाता। यह चैप्टर बताता है कि AI के लिए Core Web Vitals कैसे काम करते हैं, कौन-से मेट्रिक सबसे ज़्यादा मायने रखते हैं और आपको क्या बदलाव करने होंगे।
Core Web Vitals क्या मापते हैं और क्यों बने
Core Web Vitals तीन मेट्रिक हैं जिन्हें Google ने असली यूज़र अनुभव मापने के लिए बनाया। वे उस पल को पकड़ते हैं जब ब्राउज़र कंटेंट दिखाना शुरू करता है, उस पल को जब यूज़र पेज से इंटरैक्ट कर सकते हैं, और इसे कि लोड के दौरान लेआउट कितना स्थिर रहता है। Google इन्हें रैंकिंग फ़ैक्टर मानता है। लेकिन AI क्रॉलर के लिए ये जीवित रहने के फ़ैक्टर हैं।
तीन मेट्रिक ये हैं:
Largest Contentful Paint (LCP): सबसे बड़ा विज़ुअल एलिमेंट लोड होने में कितना समय लगता है। लक्ष्य 2.5 सेकंड से कम है। यही वह चीज़ है जो यूज़र को सबसे पहले दिखती है: अगर आपकी हीरो इमेज, हेडलाइन या मुख्य कंटेंट सेक्शन को दिखने में 4 सेकंड लगते हैं, तो इंसानों और क्रॉलर, दोनों को इंतज़ार करना पड़ता है।
Interaction to Next Paint (INP): यूज़र के किसी चीज़ पर क्लिक करने के बाद ब्राउज़र को जवाब देने में कितना समय लगता है। लक्ष्य 200 मिलीसेकंड से कम है। यह मेट्रिक परखता है कि आपका JavaScript भारी है या क्रॉलर के इंटरैक्शन की नकल करने पर आपका पेज अटक जाता है।
Cumulative Layout Shift (CLS): लोड होते समय पेज कितना उछलता है। लक्ष्य 0.1 से कम है। जब एलिमेंट अचानक खिसकते हैं, तो क्रॉलर गड़बड़ या अधूरा कंटेंट निकालते हैं। आपके ध्यान से लिखे पैराग्राफ़ क्रॉलर की पार्सिंग में उलझ जाते हैं।
पारंपरिक सर्च के लिए ये संकेत हैं। AI क्रॉलर के लिए ये कड़ी सीमाएं हैं।
AI क्रॉलर की स्पीड की ज़रूरतें Google से अलग क्यों हैं
Google का क्रॉलर काम बांट देता है। वह हज़ारों सर्वर पर लाखों URL क्रॉल करता है। वह किसी पेज के लोड होने का 10 सेकंड इंतज़ार कर सकता है, क्योंकि यह इंतज़ार एक विशाल इंफ़्रास्ट्रक्चर में बंट जाता है।
AI क्रॉलर हर क्वेरी पर इन्फ़रेंस के हिसाब से काम करते हैं। जब कोई यूज़र ChatGPT या Perplexity से सवाल पूछता है, तो जवाब बनना शुरू होने से पहले उनके पास आपका कंटेंट खोजने, उठाने और पार्स करने के लिए 3 से 5 सेकंड होते हैं। हर सेकंड मायने रखता है। हर मिलीसेकंड क्रॉल बजट से गिना जाता है।
AI क्रॉलर के व्यवहार के अध्ययन बताते हैं कि जिन साइट का First Contentful Paint 0.4 सेकंड से कम है, उन्हें औसतन 6.7 कोट मिलते हैं, जबकि 1.13 सेकंड से ज़्यादा में लोड होने वाली साइट को औसतन 2.1 कोट। यह सिर्फ़ सहसंबंध नहीं है। यह कारण है। धीमे पेज छोड़ दिए जाते हैं।
ChatGPT के रिट्रीवल क्रॉलर की एक दर्ज की हुई टाइमआउट सीमा है। जो पेज उस खिड़की के भीतर जवाब नहीं देते, उन्हें पहुंच से बाहर चिह्नित कर दिया जाता है और आगे के क्रॉल प्रयासों में कम प्राथमिकता मिलती है। Perplexity का बॉट भी यही करता है। जो साइट जवाब देने में 6 सेकंड लेती है, उसे दूसरा मौक़ा नहीं मिलता।
Time to First Byte (TTFB): वह मेट्रिक जिसकी AI क्रॉलर सबसे ज़्यादा परवाह करते हैं
TTFB अनुरोध भेजने और सर्वर से पहला बाइट वापस मिलने के बीच का पल मापता है। यह सर्वर की प्रतिक्रिया का सबसे शुद्ध माप है।
AI क्रॉलर के लिए TTFB तय करता है कि वे रेंडर की कोशिश भी करेंगे या नहीं। अगर आपका सर्वर जवाब देने में 700 मिलीसेकंड लेता है, तो क्रॉलर अपनी 3 से 5 सेकंड की खिड़की के 700 मिलीसेकंड गंवा चुका है। क्रॉलर रेंडर करना पूरी तरह छोड़ देता है और सिर्फ़ HTML पार्स करने पर लौट आता है, जिसका मतलब है कि आपका JavaScript से रेंडर होने वाला कंटेंट अदृश्य हो जाता है।
पैमाने साफ़ हैं। 200 मिलीसेकंड से कम का TTFB असाधारण माना जाता है। 200 से 500 मिलीसेकंड स्वीकार्य है पर आदर्श नहीं। 600 मिलीसेकंड से ऊपर, आपके सर्वर इंफ़्रास्ट्रक्चर में समस्या है।
ज़्यादातर परफ़ॉर्मेंस लेख TTFB को विज़ुअल मेट्रिक से कम अहम मानते हैं। AI क्रॉलर के लिए यह द्वारपाल है। अगर TTFB फ़ेल हो जाए, तो बाकी कुछ मायने नहीं रखता।
धीमे TTFB के आम कारणों में हर पेज लोड के पीछे धीमी डेटाबेस क्वेरी, हर सर्वर पर बहुत ज़्यादा साइट वाली ओवरलोड होस्टिंग, अनुरोधों की खराब भौगोलिक रूटिंग और कंटेंट डिलीवरी नेटवर्क (CDN) कैशिंग की कमी शामिल हैं। ये डिज़ाइन की समस्याएं नहीं हैं। ये इंफ़्रास्ट्रक्चर की समस्याएं हैं।
Largest Contentful Paint (LCP): बड़े एसेट का इंतज़ार
LCP उस समय को मापता है जब सबसे बड़ा विज़ुअल एलिमेंट पूरी तरह लोड होता है। यह आम तौर पर हीरो इमेज, बैकग्राउंड इमेज या टेक्स्ट का बड़ा ब्लॉक होता है। कंटेंट से भरे पेज के लिए यह मुख्य कंटेंट का इलाका होता है।
2.5 सेकंड से कम का LCP "अच्छी" सीमा है। AI क्रॉलर इस दायरे के पेज को धीमे LCP वाले पेज से 2.8x ज़्यादा बार कोट करते हैं। फ़र्क़ हल्का नहीं है।
क्रॉलर हर एसेट के लोड होने का इंतज़ार नहीं करता। लेकिन वह मुख्य कंटेंट के दिखने का इंतज़ार करता है। अगर आपकी हीरो इमेज 4 मेगाबाइट की है और आपने उसे वेब के लिए ऑप्टिमाइज़ नहीं किया, तो इमेज डाउनलोड होते समय क्रॉलर खाली बैठा रहता है। जब तक इमेज लोड होती है, आप क्रॉलर की टाइमआउट सीमा पार कर चुके होते हैं।
धीमे LCP के आम कारणों में बिना कंप्रेशन की बहुत बड़ी इमेज, रेंडरिंग रोकने वाले ऑप्टिमाइज़ न किए गए वीडियो एम्बेड, वेब फ़ॉन्ट जो सबसेट नहीं किए गए और तेज़ लोड नहीं होते, और फ़ोल्ड के ऊपर रेंडर होने वाली थर्ड-पार्टी स्क्रिप्ट शामिल हैं। इनमें से हर एक LCP में सेकंड जोड़ता है।
इसका समाधान ज़्यादा इंतज़ार करना नहीं है। समाधान है LCP को तेज़ी से होने देना। इसका मतलब है इमेज ऑप्टिमाइज़ेशन, फ़ोल्ड के नीचे के कंटेंट की लेज़ी लोडिंग, स्क्रिप्ट की एसिंक्रोनस लोडिंग, और भारी थर्ड-पार्टी एम्बेड को स्थिर HTML विकल्पों से बदलना।
Interaction to Next Paint (INP): JavaScript के चलने का प्रदर्शन
INP प्रतिक्रिया की गति मापता है। जब कोई यूज़र (या यूज़र की नकल करने वाला क्रॉलर) पेज से इंटरैक्ट करता है, तो स्क्रीन पर कुछ बदलने में कितना समय लगता है? लक्ष्य 200 मिलीसेकंड से कम है।
AI क्रॉलर के लिए INP बताता है कि आपका JavaScript ऑप्टिमाइज़ है या भारी। खराब INP स्कोर का संकेत है कि आपके पेज में मुख्य थ्रेड पर बहुत ज़्यादा कोड चल रहा है, या कोड ठीक से टुकड़ों में बंटा और टाला नहीं गया।
जो क्रॉलर इंटरैक्शन की नकल करते हैं, वे डायनामिक कंटेंट निकालने के लिए ऐसा करते हैं। अगर आपका पेज स्थिर HTML लोड करता है पर फ़ॉर्म, शर्त वाला कंटेंट या इंटरैक्टिव एलिमेंट रेंडर करने के लिए JavaScript पर निर्भर है, तो क्रॉलर को वह JavaScript चलाना होगा। अगर JavaScript धीमा है, तो क्रॉलर को खराब INP स्कोर मिलता है और वह आपके पेज को अकुशल चिह्नित करता है।
क्लाइंट-साइड रेंडरिंग की छिपी समस्या यह है कि ज़्यादातर AI क्रॉलर JavaScript रेंडर ही नहीं करते। रिसर्च बताती है कि स्कीमा मार्कअप वाला स्थिर HTML 94% पार्सिंग सफलता पाता है, जबकि JavaScript से रेंडर हुआ कंटेंट 23% पर आता है। इसका मतलब है कि अगर आपका कंटेंट JavaScript के पीछे छिपा है, तो AI क्रॉलर उसे कभी देख ही न पाएं।
अगर आपकी साइट क्लाइंट-साइड रेंडरिंग इस्तेमाल करती है, तो INP की समस्या विज़िबिलिटी की समस्या बन जाती है। क्रॉलर JavaScript के चलने का इंतज़ार नहीं कर सकता, इसलिए वह JavaScript पर निर्भर कंटेंट छोड़ देता है।
Cumulative Layout Shift (CLS): जानकारी निकालते समय स्थिरता
CLS विज़ुअल अस्थिरता मापता है। जब लोड के दौरान पेज के एलिमेंट इधर-उधर खिसकते हैं, तो Cumulative Layout Shift बढ़ता है। लक्ष्य 0.1 से कम है।
क्रॉलर के लिए CLS यूज़र अनुभव के बारे में नहीं है। यह पार्सिंग की सटीकता के बारे में है। जब क्रॉलर के जानकारी निकालते समय DOM खिसकता है, तो वह गलत एलिमेंट पकड़ सकता है। एक हेडलाइन किसी दूसरी हेडलाइन की जगह में खिसक सकती है। साइडबार मुख्य कंटेंट को जगह से बाहर धकेल सकता है। क्रॉलर वही टेक्स्ट निकालता है जो किसी पोज़िशन पर है, वह नहीं जो तर्क से वहां होना चाहिए।
ऊंचे CLS के आम कारणों में देर से लोड होकर कंटेंट को नीचे धकेलने वाली विज्ञापन की जगहें, बिना तय आकार की इमेज जो लोड होकर लेआउट खिसकाती हैं, वेब फ़ॉन्ट जो बदलकर स्पेसिंग बदलते हैं, और ऑटो-प्ले कैरोसेल जो कंटेंट खिसकाते हैं, शामिल हैं। हर एक लेआउट को हिलाता है।
समाधान है हर उस चीज़ के लिए जगह आरक्षित करना जो लोड होगी। HTML में इमेज का आकार तय करें। font-display को swap पर तय करें ताकि फ़ॉन्ट रेंडरिंग न रोकें। विज्ञापन और डायनामिक कंटेंट को आरक्षित कंटेनर में लोड करें जो लेआउट शिफ़्ट न करें।
AI क्रॉलर की स्पीड के लिए ऑप्टिमाइज़ कैसे करें
AI क्रॉलर की स्पीड का ऑप्टिमाइज़ेशन इंसानों की स्पीड के ऑप्टिमाइज़ेशन से अलग है। यूज़र को परवाह होती है कि पेज कब दिखता है और कब वे उससे इंटरैक्ट कर सकते हैं। क्रॉलर को परवाह होती है कि सर्वर कब जवाब देता है और पूरा कंटेंट रेंडर हो जाता है या नहीं।
TTFB से शुरू करें। अगर आपका सर्वर जवाब देने में 500 मिलीसेकंड से ज़्यादा लेता है, तो बाकी कुछ मायने नहीं रखता। अपनी डेटाबेस क्वेरी ऑडिट करें, ज़्यादा तेज़ होस्टिंग प्रोवाइडर पर जाएं, एप्लिकेशन स्तर पर कैशिंग लागू करें या CDN इस्तेमाल करें। TTFB में निवेश का फ़ायदा क्रॉलर कवरेज में तुरंत मिलता है।
इमेज ऑप्टिमाइज़ करें। आपके पेज की हर इमेज कंप्रेस, अपने दिखाने के आकार में रीसाइज़ और WebP जैसे आधुनिक फ़ॉर्मैट में PNG फ़ॉलबैक के साथ दी जानी चाहिए। इमेज कंप्रेशन टूल इस्तेमाल करें। हीरो इमेज के लिए ऑटोमैटिक ऑप्टिमाइज़ेशन वाला CDN इस्तेमाल करें।
गैर-ज़रूरी JavaScript टालें। सिर्फ़ वही JavaScript लोड करें जो क्रॉलर को कंटेंट देखने के लिए बिल्कुल ज़रूरी है। जो स्क्रिप्ट एनालिटिक्स ट्रैक करती हैं, विज्ञापन लोड करती हैं या इंटरैक्टिव फ़ीचर चलाती हैं, उन्हें टालना या एसिंक्रोनस रूप से लोड करना चाहिए। इससे मुख्य थ्रेड खाली रहता है और निष्पादन तेज़।
ज़रूरी कंटेंट सर्वर-साइड रेंडर करें। अगर आपकी साइट क्लाइंट-साइड फ़्रेमवर्क इस्तेमाल करती है, तो ज़रूरी रास्ते को सर्वर पर रेंडर करें और क्लाइंट पर हाइड्रेट करें। इससे पक्का होता है कि क्रॉलर को कंटेंट तुरंत दिखे। स्टैटिक साइट जनरेशन (SSG) और भी बेहतर है: डिप्लॉय के समय अपने पेज HTML में बना लें।
बड़े थर्ड-पार्टी एम्बेड से बचें। अगर आप वीडियो या म्यूज़िक प्लेयर या बड़े बाहरी विजेट एम्बेड करते हैं, तो वे रेंडरिंग रोकते हैं। उन्हें ऐसे प्लेसहोल्डर से बदलें जो क्लिक पर लेज़ी-लोड हों, या ज़रूरी जानकारी स्थिर HTML में निकाल लें।
डायनामिक कंटेंट के लिए जगह आरक्षित करें। इमेज, विज्ञापनों और डायनामिक सेक्शन के लिए साफ़ आकार तय करें। इससे लेआउट शिफ़्ट रुकता है और क्रॉलर सही कंटेंट निकालता है।
CDN इस्तेमाल करें। कंटेंट डिलीवरी नेटवर्क अनुरोधों को भौगोलिक रूप से सबसे नज़दीकी सर्वर तक भेजता है, जिससे लेटेंसी और TTFB घटते हैं। ज़्यादातर CDN ऑटोमैटिक इमेज ऑप्टिमाइज़ेशन और कंप्रेशन भी देते हैं।
स्पीड और क्रॉलर ऑप्टिमाइज़ेशन के लिए WEMASY के साथ क्या करें
WEMASY के वेबसाइट बिल्डर से आप अपनी वेबसाइट खुद बनाते हैं और अपने पेजों का कंटेंट जब चाहें बदलते हैं।
ऊपर की सलाह आपके अपने हाथ में है: इमेज छोटी और कंप्रेस करके डालें, भारी एम्बेड हटाएं और ज़रूरी कंटेंट सादे टेक्स्ट में रखें। अपनी साइट की स्पीड Google PageSpeed Insights से नियमित जांचते रहें।
जानिए WEMASY के प्राइसिंग प्लान में क्या शामिल है।
अक्सर पूछे जाने वाले सवाल
क्या पेज की स्पीड पारंपरिक SEO से ज़्यादा AI कोट पर असर डालती है?
AI क्रॉलर स्पीड के प्रति ज़्यादा संवेदनशील हैं, क्योंकि वे ज़्यादा तंग समय की सीमाओं में काम करते हैं। पारंपरिक Google क्रॉलर किसी पेज के लोड होने का 10 सेकंड इंतज़ार कर सकते हैं। AI क्रॉलर आम तौर पर 3-5 सेकंड के बाद टाइमआउट हो जाते हैं। पारंपरिक SEO में स्पीड एक रैंकिंग संकेत है। GEO में स्पीड एक सीमा है। अगर आप इसमें फ़ेल होते हैं, तो कोट होते ही नहीं। WEMASY के वेबसाइट बिल्डर से आप इसे सीधे अपनी वेबसाइट पर सेट कर सकते हैं।
मुझे कैसे पता चले कि मेरा TTFB AI क्रॉलर के लिए काफ़ी तेज़ है?
Google PageSpeed Insights इस्तेमाल करें (डेस्कटॉप वर्शन जांचकर इसे ऐसे चलाएं जैसे वह क्रॉलर हो)। 500ms से कम का TTFB देखें। अगर वह ज़्यादा है, तो आपको अपनी होस्टिंग, डेटाबेस या एप्लिकेशन कोड की जांच करनी होगी। दूसरे मुफ़्त स्पीड टेस्टिंग टूल भी TTFB दिखाते हैं। अगर आपका TTFB लगातार 600ms से ऊपर है, तो अपने होस्टिंग प्रोवाइडर से संपर्क करें या ज़्यादा तेज़ होस्ट पर जाने पर विचार करें।
अगर मैं पारंपरिक Google रैंकिंग ट्रैक नहीं कर रहा, तो क्या मुझे Core Web Vitals के लिए ऑप्टिमाइज़ करना चाहिए?
हां। Core Web Vitals सीधे AI विज़िबिलिटी पर असर डालते हैं। अध्ययन बताते हैं कि AI प्लेटफ़ॉर्म से कोट होने वाली 85% साइट तीनों Core Web Vitals की सीमाएं पार करती हैं। भले Google रैंकिंग आपके बिज़नेस के लिए मायने न रखे, AI विज़िबिलिटी रखती है। ऑप्टिमाइज़ेशन वही है।
क्या सिर्फ़ Core Web Vitals के लिए तेज़ होस्टिंग प्रोवाइडर पर जाना सही है?
अगर आपका मौजूदा TTFB 600ms से ऊपर है, तो हां। बुनियादी होस्टिंग और तेज़ होस्टिंग की लागत का फ़र्क़ आम तौर पर $5-15 प्रति माह है। बेहतर AI कोट और क्रॉलर कवरेज से मिलने वाला ROI इससे काफ़ी ज़्यादा है। तेज़ होस्टिंग सिर्फ़ क्रॉल होने की क्षमता नहीं, यूज़र अनुभव और कन्वर्ज़न रेट भी सुधारती है।
क्या कैशिंग Core Web Vitals सुधारती है?
कैशिंग ज़रूरी है। ब्राउज़र कैशिंग विज़िटर के ब्राउज़र को बताती है कि इमेज और स्थिर फ़ाइलें लोकल में रखें, ताकि उन्हें दोबारा डाउनलोड न करना पड़े। सर्वर कैशिंग पूरे रेंडर हुए पेज को मेमोरी में रखती है, ताकि उन्हें शुरू से दोबारा न बनाना पड़े। दोनों TTFB और LCP को काफ़ी घटाती हैं। कैश हेडर ज़ोर से लागू करें और ऑटोमैटिक कैशिंग वाला CDN इस्तेमाल करें।
क्या AI क्रॉलर की स्पीड के लिए ऑप्टिमाइज़ करने से यूज़र अनुभव खराब होगा?
नहीं। क्रॉलर की स्पीड के ऑप्टिमाइज़ेशन, यानी तेज़ सर्वर, इमेज कंप्रेशन, JavaScript को टालना, पूरे यूज़र अनुभव को सुधारते हैं। जो पेज क्रॉलर के लिए तेज़ लोड होते हैं, वे इंसानों के लिए भी तेज़ लोड होते हैं। इकलौता अपवाद तब है जब आप इमेज हटाकर या कंटेंट छांटकर सिर्फ़ क्रॉलर के लिए ऑप्टिमाइज़ करने की कोशिश करें, जिससे यूज़र को नुकसान होगा। ऐसा न करें। वैल्यू हटाए बिना स्पीड के लिए ऑप्टिमाइज़ करें।