Base64 ने Googlebot के लिए छवियों और उनके मेटाडेटा की उपलब्धता को एन्कोड किया


9

अगर मैं एक के रूप में एक पेज में एक छवि एम्बेड img- srcबेस 64 डेटा यूआरआई के साथ, चित्र के मेटाडेटा (EXIF, IPTC, XMP) अभी भी गूगल के imagebot के लिए उपलब्ध हैं?


1
शायद ऩही। Googlebot को संभवतः एक ऐसा URL चाहिए जो उपयोगकर्ताओं को रैंक और संदर्भित कर सके।
जॉन कोंडे

1
EXIF डेटा को भूल जाइए, मुझे यह भी पक्का नहीं है कि Google छवियां ऐसी छवि को भी इंडेक्स करेगी जिसके पास अपना URL नहीं है।
स्टीफन Ostermiller

@StephenOstermiller: यह सवाल है: यदि यह इस तरह की छवियों को अनुक्रमित करता है, तो यह EXIF ​​भी पढ़ता है
इवगेनी

@Evgeniy स्टीफन बताते हैं, डेटा URI उनके दस्तावेज़ से अलग नहीं हैं ( इसे और देखें )। खोज इंजन इंडेक्स यूआरएल, इसलिए केवल युक्त दस्तावेज़ अनुक्रमित हो जाएगा, और क्या वे डेटा यूआरआई के भीतर निहित मेटाडेटा को इंडेक्स करेंगे (यदि वास्तव में इसमें निहित है, तो इसे और भी बड़ा बनाना) एक मूक बिंदु है। पुष्टि के लिए, आप किसी डेटा URI को देखने के लिए स्रोत कोड खोज इंजन का उपयोग कर सकते हैं और फिर देख सकते हैं कि क्या वह छवि अनुक्रमित थी और Google में EXIF ​​जानकारी सम्‍मिलित थी। हालांकि यह बहुत अनुचित लगता है।
दिन

@Evgeniy ध्यान दें कि एक से अधिक स्टैक एक्सचेंज साइट पर एक ही प्रश्न को क्रॉस-पोस्ट नहीं किया जाता है।
दान

जवाबों:


6

Google Google छवि खोज के लिए यूआरआई छवियों को डेटा इंडेक्स नहीं करता है। Google के जॉन मुलर यहां और नीचे टिप्पणी में ऐसा कहते हैं। क्योंकि Google छवि खोज में डेटा URI छवियों को अनुक्रमित नहीं किया गया है, उनमें मौजूद EXIF ​​डेटा अप्रासंगिक है।

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

यदि Google कभी भी डेटा URI छवियों को अनुक्रमित करने का निर्णय लेता है, तो उन्हें उनसे EXIF ​​डेटा प्राप्त करने में सक्षम होना चाहिए। डेटा यूरी एक data:image/png;base64,उपसर्ग के साथ पूरी फ़ाइल बेस 64 एनकोडेड (कोई रिक्त स्थान या नई लाइनें) नहीं है । फ़ाइल में कोई भी मेटा डेटा अभी भी बेस 64 एनकोडेड डेटा यूआरआई संस्करण में मौजूद होगा।

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

मेरी साइट को Internet Explorer 7 और उससे पहले के ट्रैफ़िक की उचित मात्रा मिलती है जो डेटा URI छवियों का समर्थन नहीं करते हैं। इसलिए मुझे सशर्त उनकी सेवा करनी होगी। मेरे पास सर्वर पर भी छवियां हैं और मैं User-Agentहेडर के आधार पर नियमित छवि URL या डेटा URI का चयन करता हूं । मैं बॉट्स (Googlebot सहित) को IE 7 के समान मानता हूं, अर्थात, मैं छवियों को HTTP URL के रूप में सेवा करता हूं। मैं ऐसा इसलिए करता हूं क्योंकि डेटा उड़ी छवियों सहित नाटकीय रूप से पृष्ठ का आकार बढ़ जाता है। अधिकांश बॉट को छवियों को डाउनलोड करने की आवश्यकता नहीं है, इसलिए यह उनके लिए अधिक कुशल है। मैंने यह भी देखा था कि Google वेबमास्टर टूल ने रिपोर्ट किया था कि Googlebot मेरी साइट को बहुत धीरे-धीरे क्रॉल कर रहा था, इसके लिए डेटा URI चित्र सक्षम था। इसे तकनीकी रूप से क्लोकिंग माना जा सकता है, लेकिन यह आपके डेटा को यूआरआई छवियों को अनुक्रमित करने का एक तरीका होगा।


2
आपका पहला उदाहरण इस URL पर अनुक्रमित है: photos.topicshow.com/… और इस पर आपका दूसरा: images5.fanpop.com/image/photos/30600000/… सभी मामलों में मैं पा सकता हूं, छवि के लिए एक http URL है भी।
स्टीफन Ostermiller

1
@StephenOstermiller एन्कोडेड स्ट्रिंग में सामग्री रिक्त स्थान हो सकती है: goo.gl/RF8r07 । मैं EXIF ​​के साथ एक छवि को आबाद करूँगा, इसे सांकेतिक शब्दों में बदलना, प्रकाशित करना और देखना, चाहे वह सूचकांक में आए।
एवगेनी

3
जॉन मुलर (Google से) यहां इंगित करता है कि Google आमतौर पर डेटा URI से छवियों को अनुक्रमित नहीं करता है। इनको एनकोड करने के लिए उपयोग किए जाने वाले कई ऑनलाइन टूल भी मेटाडेटा को स्ट्रिप-ऑफ करेंगे, इसलिए यह वास्तव में इस बात पर निर्भर करता है कि यह कैसे एन्कोड किया गया है कि क्या EXIF ​​जानकारी को बनाए रखा गया है ... लेकिन यह देखते हुए कि वे वैसे भी अनुक्रमित नहीं हैं, यह एक मूट बिंदु है। हमें अपने परिणाम बताएं (सुनिश्चित करें कि URL को छवि को अनुक्रमित नहीं करने दिया जाए - Google छवि मान्यता का भी उपयोग करता है ताकि EXIF ​​जानकारी का मिलान छवियों से किया जा सके)।
दान

1
@ आप का शुक्रिया! जॉन मुलेर्स के लिए आपका लिंक एक ही बार में कई चीजों का जवाब देता है! यदि G छवियों को अनुक्रमणित नहीं करता है, जहां इसे URI नहीं मिल सकता है, तो किसी को इस बारे में विचार करने की आवश्यकता नहीं है कि EXIF ​​अंदर छोड़ा गया है या नहीं।
इवगेनी

3
जैसा कि ऊपर जोड़ा गया है, वर्तमान में हम छवियों के रूप में इन्हें अलग से अनुक्रमणित नहीं करते हैं। यह भविष्य में बदल सकता है, लेकिन कम से कम उस समय के लिए आप अलग छवि URL का उपयोग करना चाहते हैं यदि आप चाहते हैं कि वे चित्र छवि खोज में अनुक्रमित हों।
जॉन मुलर

2

जबकि Google छवियों को बेस 64 एनकोडेड डेटा यूआरआई के रूप में अपने स्वयं के SERP पर उपयोग करता है, यह अन्य वेबसाइटों पर ऐसी छवियों को अनुक्रमित नहीं करता है। @Dan के लिए धन्यवाद, जिन्होंने मुझे Google समूह चर्चा में बताया, जहां जॉन मुलर ने इस मुद्दे की व्याख्या की । इसका मतलब यह भी है, कि इस तरह की छवियों में EXIF ​​डेटा के अस्तित्व के बारे में सवाल प्रासंगिक नहीं है।

यह स्पष्टीकरण स्पष्ट करता है कि किस चित्र के लिए यह प्रदर्शन अनुकूलन तकनीक लागू करना बेहतर है: छोटी छवियां, जैसे चिह्न, फ़ेविकॉन और बटन, और वे छवियां, जो साइट की सामग्री के लिए कोई अतिरिक्त मूल्य नहीं देती हैं।

दूसरी साइट पर, यदि किसी को अतिरिक्त सामग्री मान के साथ एक छवि को एम्बेड करना होगा जैसे कि बेस 64 एन्कोडेड डेटा यूआरआई, तो छवि का मेटाडेटा प्रदान करने के लिए एकमात्र सबसे अच्छा अभ्यास स्कीमाओ के मार्कअप का उपयोग करना है, जहां एक्सक्लूजिव डेटा पर बातचीत करना संभव है, जैसे कि इसके साथ। मार्कअप की तरह।

"संपत्ति: मान" की तरह दिखने वाले डेटा पर बातचीत करने के लिए मार्कअप का एक और आशाजनक प्रकार , जैसे EXIF ​​है, फिलहाल एक प्रस्ताव की स्थिति है। लेकिन Google के ब्लॉग के इस लेख में संरचित स्निपेट्स दिखाए गए हैं, जो ऊपर दिए गए मार्कअप प्रस्ताव द्वारा उत्पन्न किए जा सकते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.