Base64 kodlu resimler ve Googlebot için meta verilerinin kullanılabilirliği


9

Bir şekilde bir sayfa içine bir görüntü katıştırırsanız img- srcbase64 veri URI ile Google'ın ImageBot için hala kullanılabilir resmin meta (EXIF, IPTC, XMP) nerede?


1
Muhtemelen değil. Googlebot muhtemelen sıralayabileceği ve kullanıcıları yönlendirebileceği bir URL'ye ihtiyaç duyar.
John Conde

1
EXIF verilerini unutun, Google görüntülerinin kendi URL'si olmayan bir resmi bile dizine ekleyeceğinden emin değilim.
Stephen Ostermiller

@StephenOstermiller: soru şu: eğer bu tür görüntüleri endeksliyorsa, bu yüzden EXIF ​​de okur
Evgeniy

@Evgeniy olarak Stephen işaret veri URI'ler kendi içeren belgeden ayrı değildir (bakınız bu daha fazla). Böylece sadece içeren belge dizine olur, motorları indeksi URL'ler arama ve onlar meta içeriyordu endeks edip içinde (hatta daha büyük yapma, bunu da içeriyordu gerçekten varsa) bir veri URI'sında dilsiz noktasıdır. Onay için, bir veri URI'sini aramak için bir kaynak kodu arama motoru kullanabilir ve ardından bu görüntünün dizine eklenip eklenmediğini ve Google'da EXIF ​​bilgilerini içerip içermediğini görebilirsiniz. Bu oldukça imkansız görünüyor.
dan

@Evgeniy Aynı sorunun birden fazla Stack Exchange sitesine çapraz gönderilmesinin göz ardı edilmediğini unutmayın .
dan

Yanıtlar:


6

Google, Google resim araması için veri URI resimlerini dizine eklemez. Google'dan John Mueller burada ve aşağıdaki yorumlarda bunu söylüyor . Veri URI görüntüleri Google resim aramasında dizine eklenmediğinden, içindeki EXIF ​​verileri önemsizdir.

Bu görüntülerin dizine eklenmediğini doğrulayabilirsiniz. Google görüntülerinde "data uri" araması yaptım ve sonuçları kontrol ettim. İzlediğim tüm görüntüler base64 kodlu görüntü URI'si değil, görüntü dosyalarıydı. Google veri URI resimlerini dizine ekleyebiliyorsa, bazılarının bu terim için arama sonuçlarında görüneceğini düşünürdünüz.

Google, veri URI görüntülerini dizine eklemeye karar verirse, bunlardan EXIF ​​verilerini alabilmelidir. Veri uri, data:image/png;base64,önek ile kodlanmış tüm dosya base64 kodludur (boşluk veya yeni satır yok) . Dosyadaki tüm meta veriler hala base64 kodlu veri URI sürümünde mevcut olacaktır.

Web sitelerimden birinde veri URI görüntüleri kullanıyorum. Bunu yapıyorum çünkü kullanıcılar ihtiyaç duydukları tüm bilgileri almak için sitede yalnızca bir sayfayı görüntülüyorlar. Tüm CSS, JS ve resim verilerini satıriçi sayfaya dahil etmek performansı önemli ölçüde düzeltir. Görüntülerin hepsi küçük, bu nedenle teknik özellikle iyi çalışıyor.

Sitem, Internet Explorer 7 ve önceki sürümlerden veri URI görüntülerini desteklemeyen makul miktarda trafik alıyor. Bu nedenle onlara şartlı olarak hizmet etmek zorundayım. Sunucuda da görüntüler var ve User-Agentbaşlığa göre normal resim URL'lerini veya veri URI'sini seçiyorum . Botlara (Googlebot dahil) IE 7 ile aynı şekilde davranıyorum, yani görüntüleri HTTP URL'leri olarak sunuyorum. Bunu yapmak çünkü veri uri görüntüleri dahil sayfa boyutunu önemli ölçüde artırır. Çoğu botun görüntüleri indirmesi gerekmez, bu yüzden onlar için daha verimlidir. Google Web Yöneticisi Araçları'nın, Googlebot'un, etkinleştirilmiş veri URI resimleriyle sitemi çok daha yavaş taradığını bildirdiğini de fark etmiştim. Bu teknik olarak gizleme olarak düşünülebilir, ancak veri URI resimlerinizi dizine eklemenin bir yolu olacaktır.


2
İlk örneğiniz şu URL'de dizine eklenmiştir: photos.topicshow.com/… ve ikinciniz şu adrestedir : images5.fanpop.com/image/photos/30600000/… Bulabildiğim her durumda, resim için bir http URL'si var de.
Stephen Ostermiller

1
@StephenOstermiller kodlu dize, boşluklar içerebilir: goo.gl/RF8r07 . Ben bir görüntü EXIF ​​ile dolduracak, kodlamak, yayımlamak ve bakmak, eğer endeks geliyor.
Evgeniy

3
John Mueller (Google'dan) burada Google'ın genellikle veri URI'lerinden görüntüleri dizine eklemediğini belirtir . Bunları kodlamak için kullanılan birçok çevrimiçi araç da meta verileri çıkarır, bu nedenle EXIF ​​bilgilerinin korunup korunmadığına göre nasıl kodlandığına bağlıdır ... ancak yine de dizine eklenmedikleri göz önüne alındığında, bu bir tartışma noktasıdır. Sonuçlarınızı bize bildirin (resmin URL'sinin dizine eklenmesine izin vermediğinizden emin olun. Google, eşleşen resimlerden EXIF ​​bilgilerinin kullanılabilmesi için resim tanıma da kullanır).
dan

1
@dan teşekkür ederim! John Muellers cevapla bağlantınız şimdi bir çok şeyi temizliyor! G, bir URI elde edemediği görüntüleri endekslemiyorsa, EXIF'in içeride bırakılıp bırakılmadığı hakkında bir düşünmeye gerek yoktur.
Evgeniy

3
Yukarıda bağlantılı olarak, şu anda bunları ayrı ayrı resim olarak dizine eklemiyoruz. Bu gelecekte değişebilir, ancak en azından Görsel Arama'da bu resimlerin dizine eklenmesini istiyorsanız ayrı resim URL'leri kullanmak istersiniz.
John Mueller

2

Google, görüntüleri kendi SERP'sinde base64 kodlu veri URI'leri olarak kullanırken, bu tür görüntüleri diğer web sitelerinde dizine eklemez. John Mueller'in bu sorunu açıkladığı Google Grupları tartışmasına beni yönlendiren @dan'a teşekkürler . Bu tür görüntülerde EXIF ​​verilerinin varlığına ilişkin sorunun ilgili olmadığı anlamına da gelir.

Bu açıklama, bu performans optimizasyon tekniğinin hangi görüntülere uygulanacağının daha iyi olduğu açıktır: simgeler, favicons ve düğmeler gibi küçük görüntüler ve sitenin içeriği için herhangi bir ek değer sağlamayan görüntüler.

Diğer sitede, kategorik olarak ek içerik değeri olan bir görüntüyü base64 kodlu veri URI'si olarak gömmek zorunda kalırsanız, görüntünün meta verilerini sağlamak için en iyi uygulama, Schema.org'un işaretlemesini kullanmaktır, burada EXIF ​​verileri, örneğin bununla pazarlık yapmak mümkündür bir çeşit biçimlendirme.

EXIF gibi "property: value" gibi veri pazarlığı yapmak için gelecek vaat eden başka bir tür işaretleme şu anda bir teklif statüsüne sahiptir. Ancak Google'ın blogundaki bu makale, yukarıda bağladığım biçimlendirme teklifi tarafından oluşturulabilen yapılandırılmış snippet'leri gösterir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.