Googlebot lar siteleri gezerken Lynx browserını kullanmaktadır. Adını bir çoğunuz duymamış olabilir bira bu prowserın niteliklerinden bahsedelim.
1- Javascript kullanmaz : Yani ajaxla çağırılan sayfaları göz ardı eder.
2- CSS kullanmaz : herşeyi düztex olarak ekrana basar.
3- HTML taglarına önem verir h1,table.... önemlidir.
O halde dikkat etmemiz gereken hususlarda kendiliÄŸinden beliriyor.
Sitemizi aktif olarak tasarlıyorsak bile table ların düzgün açılıp kapatıldığını linklerin doğru olduğunu ve bu gibi hususları dikkatlice oluşturmalıyız. Artık browserlar bazı küçük html hatalarını göz ardı edebiliyor. ama google için bu geçerli değildir. Sayfamızın kodlamasının en iyi şekilde yapılmış olması gereklidir.
Tasarımda bir diğer önemli husussa h1 tagıdır.Şimdi buna geçelim.
h1 tagı ve google
Belki hepinize komik gelecek ama doğru kullanılan bir h1 tagı sitenizin google da üst sıralarda çıkmasını %7 ile %10 arasında etkilemektedir. h1 tagı html de yazı başlığı anlamına gelmektedir ve google da bu şekilde yorumlamaktadır. Bu alana yazacağınız yazılar google aramasında değer kazanacaktır.
Resimler ve google uyumu
Yine size saçma gelecek ama google sitenizdeki resimlerin width ve height tanımlarının yapılıp yapılmadığına dikkat eder bunun dışında her resimde alt tagı ile resim hakkında bilgi bulunmalıdır
Title,description ve keywords un içerikle bağı nedir ?
Google bot sayfamıza geldiğinde en fazla dikkat ettiği konulardan biridir. Sayfa başlığı içeriğe uyuyormu, koywords'taki kelimeler içerikte varmı ve sayfa tanımı olan description içerikle uyumlumu yani özetle bu üç tag içinde kullanılan kelimeler içerikte yer alıyormu demektedir. yer almıyorsa googlebot sayfayı dikkate almayacak ve yanıltıcı görecektir. %100 uyumu esas alın
Özgün İçerik
Google ın en önem verdiği şeydir özgün içerik . metaları ve tüm tasarım kurallarını ihlal ederek gerçekten insanlığa faydalı bir site yapmış olabilirsiniz . O zaman google beni bulurmu diye düşünmenize gerek yok . Mutlaka bulur ve sizi en başa yerleştirir.
önceki yazı Google Sizi Sevsin 3 : Title |
sonraki yazı ASP İle TCKimlik No Kontrolü |
son madde kesinlikle doğru. özgün içerik şart.
ancak image height olayı biraz şüpheli. kaynağınız var mı?
lazaronnie :Domaintools seo konusunda en doğru analizi yapan sitedir(bana göre ) . domaintools ile birkaç siteyi analiz edersen resim boyutlarını tanımlamanın ne kadar önemli olduğunu görebilirsin. Zaten tasarım yapan arkadaşlarda birlirlerki resim boyutu tanımlamak ve resimlere title vermek tasarım kalitesinin bir sonucudur. SEO içinde tasarım kalitesi önemlidir. emek olduğunu işaret eder.
DoÄŸru bir nokta.
Bir röportajda goole dan bir yetkili bunu bizzat belirtmişti.
W3C nin koyduğu standartlara uygun site kodlamaları bizden artı puan alır diye bir cümle geçiyordu.
Bunun bir diğer nedeni de "goole image search". Google bot dolaşırken sitenin text tabanlı içeriğini indexler, imajlara vs dokunmaz.
Google dan resim aramaya girdiğinizde detaylı aramada resim boyutları vs. bilgileri ile filtreleme yapabiliyorsunuz.
Google'ın resim dosyalarını tek tek download edip incelemediği için bu türde bilgileri image tagındaki değerlerden alıyor.
Bu sebeple kodlama standardına sadık siteler google için velinimet, ve google bu çabayı da boş çıkarmayıp artı puan veriyor bu sitelere.
image konusunda ben de hala şüpheliyim ki ufak resim aradığımda yada büyük resim aradığımda hiç bir hatayla karşılaşmadım. sadece html'e bakmış olsaydı ufak resimleri filtrelerken zaman zman büyük imagelar'da görecektik. ama böyle birşey olmuyor. o yüzden html width ve height'leri ile yetindiğimi zannetmiyorum.
@vectro
Herhangi bir dosyayı bilgisayara kaydetmeden sunucu üzerinden dosya boyutu (KB, MB olarak) bilgisi alabiliyorsunuz.
işi tek bir değişkene bırakmıyorlar.
Birkaç tane alan var inceledikleri.
ZZombie: nasıl alınıyor?
lazaronnie alma şekli kullandığın dile göre değişir . ben asp de bu işler için persits jpeg kullanıyorum . yada kb boyut alacaksam asp nin bileşenlerini.
şenol bir detayı gözden kaçırmışsın. Biz yabancı sunuculardan bahsediyorduk. Kendi sunucumuzdaki dosyaların boyutunu FSO ile alıyoruz zaten sorun diğer sunucudaki dosya boyutunu download etmeden öğrenebilmek!
Herhangi bir indirme yöneticisi kullanıyorsanız zati dosyanın tamamı gelmeden boyutunu görürsünüz.
Sunucu size bu bilgileri yükleme başlamadan yollamakta.
Şu aralar Python ile uğraştığım için (ve de kod hammallığı çok daha az olduğu için :) ) örnek bir kod vereyim. Sisteminize Python kurup deneyebilirsiniz.
----------------------
import urllib2
dosya = urllib2.urlopen('http://www.rarlab.com/rar/wrar392.exe')
print dosya.info().items().__getitem__(0)[1]
1364434
----------------------
Buradaki sonuc byte olara dönüyor.
Ufak bir fonksiyon yazarak sonucu Kb , MB, GB olarak çıkartabilirsiniz.
dosya boyutu http head bilgisinde geliyormuş. kullanılan bileşene göre head'ın da geri döndürülmesini sağlayabiliyoruz. asp için bakacak olursak sanırım msxml'in böyle bir özelliği yok. zira kendisi dosyalar için değil xml veya web sayfaları için tasarlanmış her ne kadar binary desteklese de. bir de tear'a bakmak lazım.
edit
----------------
|
|
Dönen sonuç
|
|
gerisi regular expressions'un kerametine kalıyor.
Evet.
Belirtmeyi unuttum.
HEAD bilgisinde geliyor dosya boyutu.
Dediğin gibi regular expressions ile, veya kullanacak kişinin en hakim olduğu dildeki karakter arama fanksiyonları ile değerleri alabilirler.
konuya dönecek olursak,
google resim değişkenlerini kontrol eder diyorsunuz da resim aramada gördüğümüz thumbların tamamı google sunucularında barınıyor.
bazı resimler kaynağından kaldırılmış bile olsa ön izlemesi googleda bulunduğu için sürekli görüyoruz.
Demek ki google resimleri download ediyor. Bence hazır download etmişken kendi bileşenleriyle analiz etmez mi? Ederleer. Hatta analize başlamadan resimde virüs taraması bile yapılabilir. Böylece bazı siteleri resimler konusunda dolandırıcı diye işaretlemek kolaylaşabilir. (ki bence çoğu zararlı içerik dağıttığı gerekçesiyle uyarı verilen siteleri bu yöntemle de tespit ettiklerine inanmaktayım ben.)
Olabilir tabii...
Okadar geniş imkanlar elimin altında olunca ben de her tür kontrolü elime almayı tercih ederim.
Ama bir analist gözü ile bakarsak google bot un dolaştığı sitedeki her veriyi anında indirdiğini düşünmek yanlış olur.
Sayfalardan topladğı bilgileri, ve içlerindeki imaj bilgilerini bir veritababına yazıp 2. bir uygulama da bu veriler ile iş yapiyor olmalı.
Ki olması gereken yapı da bu.
Ama google bile resimlerin sadece ufaltılmış hallerini tutmakta. Bu da oluşan verinin nekadar büyük olduğunu, ve de yapılan işlemlerin aslında ne büyüklükte bir veri trafiğine yol açtğını göz önüne sermeye yetecektir.
zzombie google web'i arşivlerken bitmap algoritmasını uyguluyor. sanıldığı kadar büyük, tahmin edilmeyecek kadar şişkin veritabanları yok aslında. google bilinen bütün maharetini bu minimal veritabanı yapısına borçlu. (bunun parasal maliyeti devede pira kadar kalıyor)
sunucu sayısının bolluğu gelse gelse ikinci sırada gelir. (parasal maliyeti uçuk rakamlara varıyor)
bu iki önemli noktayı başarılı bir biçimde birleştirirseniz 950 milyon sonucu 0.3 saniyede bulabilir, üstelik bunu günlük 800 milyonu aşkın insana istisna yaratmadan sunabilirsiniz
Ne bileyim bir "pagerank" olsun, bir "kişiye özel arama sonucu" olsun böyle tuz biberlerle yatırımınızı birleştirebilirseniz ortaya google gibi bir site çıkıyor.
Thumb boyutuna gelince; varsayalım ki google şimdiye dek 2 milyar resim taramış olsun. Kaplayacağı alana bakarsak (bir thumb ortalama 3.5KB yer kaplasın) : 2.000.000.000 x 3.5 = 7milyar KB yer tutar.
7.000.000.000 / 1024 = 6.835.937,5 MB
6.835.937,5 / 1024 = 6.675,7 GB
6.675,7 / 1024 = 6,51 TB yer tutar.
Hadi bilemedin 12 TB yer tutsun.
Bu rakam normal bir ev kullanıcısının güçlü ve donanımlı bir pc ile erişebileceği bir değer günümüzde. Google'ın güçlü ve devasa sunucu tarlalarının bu verilerle uğraşması çok da zor olmasa gerek.
Google ın bir roportajında mühendislerininden birinin "ideal bir arama motoru veritabanı en fazla 50GB olmalı." gibisinden bir cümle kurmuştu. Performans için bu bir sorun değil.
Yazımda "Ama google bile resimlerin sadece ufaltılmış hallerini tutmakta. Bu da oluşan verinin nekadar büyük olduğunu, ve de yapılan işlemlerin aslında ne büyüklükte bir veri trafiğine yol açtğını göz önüne sermeye yetecektir."
diye bahsetmiÅŸtim.
Google ın asıl resimleri tutmasına bir gerek yok. Bu yüzden de sadece ufaltılmışları elinde barındırıyor.
Örneğinizde 2.000.000.000 ufaltılmış resimde bahsettik. Artık günümüzde dijital fotoğraf makinelerinin özellikleri ile ortalama 2-3MB arası değişiyor resimler.
Fakat biz ortalama bir hesap olması açısından her resmi 1MB olarak hesaplarsak toplamda 1.907 TB lık bir veri çıkıyor ortaya. Bahsettiğim yoğun veri akışı ve veri miktarı budur.
@lazaronnie & @ZZombie, yorumlarınızı okurken çalan "Moby - Hymn" şarkısındanmıdır, benim yorgunluğumdanmıdır bilinmez sanki üçümüz bir kafede oturmuş sizin konuşmalarınızı dinliyormuşum gibi bir his yaşadım. yorumlarınızı okumak çok keyifliydi, çok teşekkürler.
konuya gelirsek;
arama motorlarının ilk iş olarak resimlerdeki title ve boyut bilgilerine baktığını zannetmiyorum @lazaronnie nın belirttiği gibi arama motoru sunucuları her halukarda bilgiyi kendi haznesine kaydediyor sonrasında resimle ilgili işlemleri yapıyor. bunları indexlerken genelde içerikteki yazıya baktığını düşünüyorum, zira örnek bir aramada ilk karşınıza çıkan sonuçlar resimdeki title değeri değil içerikteki değer.
50gb lik bir db ... mysql mi kullanıyorlarki?
bu arada, tasarımlarımı yaparken resim boyutlarını tasarıma uydurur html içinde bir resim kodlarına boyut değerleri girmem. bu bir kayıpmıdırki?
@cxc
Yorumlara teşekkürler. Bu türde tartışmaları severim, bilgilendirici oluyor. Gelelim sorularına :
50GB DB nin ideal olduÄŸunu belirtiyordu adam. Kendi DB lerinin 50GB olduÄŸunu deÄŸil.
Ayrıca sürekli yaşanan bir yanlış anlama mevcut. google domaini altındaki tüm servislerin sanki aynı sunucularda çalıştığı izlenimine sahip oluyor insanlar. Oysa goole aramaları farklı, resim aramaları farklı, haber grubu aramaları farklı sunucular ve de farklı uygulamalar. Ayrıca .tr .nl .gr vs domainleri de farklı sunucularda.
Bir google belgeseli vardı. Adamlar 3D olarak dünya üzerindeki sunucularına gelen istekleri görüyorlardı. Orada yapılarını görebilirsiniz.
Resimler ile ilgili olarak içerikteki yazıya, resme verilen linkin text içeriğine (bill in resimleri) ve resim dosyasının adına (ki verdiğin linkte dikkat etti sen çıkan resimlerin dosya isimlerinde Turkiye yazisi geciyor) dikkat ediyor.
Resim boyutunu girmemek aslında bir kayıptır.
Tabii bu tasarım şekline göre de değişmekte. Eğer resme göre kendini otomatik şekillendiren alanların mevcut ise (tablo gibi), birkaç resim dosyasını silip html deki yerlerini bırakırsan tasarımıda kaymalar oldğunu görürsün. Ama resim boyutlarını verdiğinde dosya fiziki olarak sunucuda olmasa bile browserler verilen değerlere göre tasarımda boşluk yaratacaktır. Bu da tasarımında kaymaları engelleyecektir.
cxc : güzel yorumun için ben teşekkür ederim.
mySQL'in 50gb dolaylarında veri salayabilecek bir tablosu yok. Benim bildiğim tablolar 4-10 GB arasında veri saklayabiliyor mySQL'de.
Ancak google elbetteki mySQL kullanmıyor. Google gibi bir firmanın kendi dosya sistemini (ntfs, fat, cdfs gibi) ve server'larında da kendi yazdığı işletim sistemini kullandığını göz önüne alırsak, kullandıkları veritabanı hakkında az çok bir tahmin yürütme şansımız olur.
Prrogramcılarına "hazır işletim sistemi yazdınız eliniz değimişken bi de veritabanı attırın ortaya" dediklerini duyar gibiyim :))
web sayfamızda kullanıcağımız imajları interneten tedarik ettiysek o resmi photoshop da veya herhangi bir imaj edidörü ile üzerinde ufak oynamalar yapın ve tekrar keydetin ve ondan sonra web de yayınlayın. bunun nedeni google daha önce sizin kullanaçak olduğunuz imajı saden indexlemiş olmasıdır. sizin imajda yapmış olduğunuz değişiklikler google indexlemelerinde özgün imaj olarak yerini alacaktır...
Bu fikir tamamen kendi düşüncemdir.
pillinetwork sitelerine yorum ekleyebilmek ve daha fazlası için, üye olun ya da giriş yapın.
Nokta ve pilli ortak yapımı olan kodaman.org hep birlikte içerik üretip gelirini yazarları ile paylaştığımız kolektif bir kod yazarları blogudur. Siz de katılabilirsiniz.