Resmi Google Webmaster Bloğu
Google Arama Motoru hakkında resmi duyurular, Search Console ile ilgili tüm detaylar ve web sitesi sahiplerine öneriler.
#NoHacked 3.0: Ek kaynaklar
27 Aralık 2017 Çarşamba
#NoHacked
kampanyamızı başlatmamızın üzerinden neredeyse 3 haftadan fazla bir süre geçti ve bu süreçte web sitelerinin güvenliğini arttırma konusunda farkındalık yaratabilmek adına birçok paylaşımda bulunduk. Bunlari hızlıca hatırlamak gerekirse:
Tespit:
Sitemin saldırıya uğrayıp uğramadığını nasıl anlayabilirim?
Önleme:
Saldırıları önlemeye ilişkin ipuçları
Kurtarma:
Yaygın görülen saldırı tiplerini düzeltme
Bugün itibariyle de kampanyamızın dördüncü ve son ayağında, sitelerinizi güvende tutmanıza yardımcı olabilecek ilave birkaç kaynağı daha sizlerle paylaşarak bu çalışmamıza şimdilik bir nokta koymak istiyoruz.
Bazı ilginç araştırma dokümanları:
Saldırı davranışları sürekli olarak değişmektedir. Bu nedenle yapılan araştırmalar, en son trendleri daha etkili bir şekilde takip edip bunlarla mücadele etmemiz için oldukça büyük önem taşıyor. Bilgi Güvenliği Araştırma sitemizden, bu konuda yapılan en güncel araştırma yayınlarımız hakkında bilgi edinebilirsiniz. Web sitesi güvenlik ihlallerine özel bazı çalışma örneklerimiz şu şekilde:
Görünürlüğün Gizlenmesi: Makinelerin Farklı Bir Sayfaya Gittiğini Tespit Etme
Ticari Yükleme Başına Ödemeyi ve İstenmeyen Yazılım Dağıtımını Araştırma
Yüksek Ölçekte Reklam Yerleştirme: Yanıltıcı Reklam Değişikliklerini Değerlendirme
Saldırıya uğramış siteler için
sıkça sorulan sorular (SSS)
ve
s
özlük
:
SSS, bilgisayar korsanlarının saldırılarıyla ilgili Google'da en sık duyduğumuz soruların yanıtlarından oluşmaktadır. Sözlükte ise, güvenlik dokümanlarımızda bahsedilen teknik terimler derlenmiştir.
Dediğimiz gibi #NoHacked 3.0 kampanyamız artık sona eriyor! Fakat endişelenmeyin, yakında daha fazla içerikle geri döneceğiz. Bu esnada, sorularınız olursa bunları
Webmaster Yardım Forumlarımız
aracılığı ile bizlere iletebilirsiniz. Geri bildiriminiz veya güvenliği ihlal edilmiş sitelerle ilgili sorularınız burada, Google çalışanları ve teknik konularda katkılarda bulunan kullanıcılar tarafından yanıtlanacaktır.
Kampanya boyunca sunduğumuz içerikleri beğendiğinizi umuyoruz. Bilgisayar korsanlarına karşı güvende kalmanız dileğiyle!
Yayınlayan: Arama kalitesi ekibi adına
Fatih Özkösemen
#NoHacked 3.0: Yaygın görülen saldırı tiplerini düzeltme
20 Aralık 2017 Çarşamba
Şimdiye kadar
#NoHacked
kampanyamızda, saldırıları tespit etme ve önleme üzerine bazı ipuçları paylaştık. Artık bilgisayar korsanlarının saldırılarını tespit edebildiğinize göre yaygın görülen bazı saldırı tekniklerini tanıtmak ve bunların nasıl düzeltileceğiyle ilgili yol gösterici bilgiler sağlamak istiyoruz!
🔗 Gizlenmiş Anahtar Kelimeler ve Bağlantılar Saldırısını Düzeltme
Gizlenmiş anahtar kelimeler ve bağlantı saldırısı, anlamlı olmayan cümle, bağlantı ve resimlerin olduğu çok sayıda sayfayı otomatik olarak oluşturur. Bu sayfalar bazen orijinal sitedeki temel şablon öğelerini içerir. Böylece, ilk bakışta sayfalar içerik okununcaya kadar hedef sitenin normal parçaları gibi görünebilir. Bu saldırı türünde, bilgisayar korsanları genellikle kötü amaçlı içeriği gizlemek ve yerleştirilen sayfanın orijinal sitenin veya bir 404 hata sayfasının parçası olarak görünmesini sağlamak için gizleme tekniklerini kullanır.
🔗 Anlamsız Kelime Saldırısını Düzeltme
Anlamsız kelimeler saldırısı, hedef sitede anahtar kelimelerle dolu, anlamlı olmayan cümlelerin olduğu çok sayıda sayfayı otomatik olarak oluşturur. Bilgisayar korsanları, bunu saldırıya uğramış sayfaların Google Arama'da gösterilmesi için yapar. Daha sonra, kullanıcılar bu sayfaları ziyaret etmeye çalıştıklarında alakasız bir sayfaya, örneğin pornografik içerikli bir siteye yönlendirilirler.
🔗 Japonca Anahtar Kelime Saldırısını Düzeltme
Japonca anahtar kelime saldırısı genellikle hedef sitede rastgele oluşturulmuş dizin adlarında Japonca metin içeren yeni sayfalar oluşturur. Bu sayfalar, sahte markalı ürünler satan mağazaların satış ortağı bağlantıları kullanılarak para kazandıracak hale getirilir ve daha sonra, Google aramada gösterilir. Bazen bilgisayar korsanlarının hesapları da Search Console'a site sahibi olarak eklenmektedir.
Son olarak, sitenizi temizleyip sorunu düzelttikten sonra ekiplerimizin sitenizi incelemelerini sağlamak için bir
yeniden değerlendirme isteğinde
bulunmayı unutmayın.
Her zaman olduğu gibi sorularınızı
Webmaster Yardım Forumlarımız
aracılığıyla bize iletebilirsiniz. Görüşmek üzere!
Yayınlayan: Arama kalitesi ekibi adına
Fatih Özkösemen
Sitenizi mobil öncelikli dizine eklemeye (mobile first indexing) hazırlama
18 Aralık 2017 Pazartesi
Neredeyse bir yıl önce, mobil öncelikli dizine ekleme (mobile first indexing) ile ilgili denemeler yaptığımızı
duyurduğumuzda
, yayıncıları bu süreçteki gelişmeler konusunda bilgilendireceğimizi söylemiştik. Bu doğrultuda yapılan
canlı Hangouts ofis saatleri
ve
Pubcon
gibi konferanslarla son birkaç aydır bunu gerçekleştiriyoruz.
Konuyu özetlemek gerekirse, tarama (crawling), dizine ekleme (indexing) ve sıralama (ranking) sistemlerimiz şu anda genellikle bir sayfa içeriğinin masaüstü sürümüne bakmaktadır. Bu durum, masaüstü sürüm mobil sürümden önemli ölçüde farklı olduğunda mobil cihazlardan arama yapan kullanıcılar açısından sorunlara yol açabilmektedir. Mobil öncelikli dizine ekleme, kullanıcılarımızın (özellikle de mobil olanların) aradıkları içeriği bulmalarına daha iyi bir şekilde yardımcı olmak amacıyla dizine ekleme ve sıralama için içeriğin mobil sürümünü kullanacağımız anlamına gelmektedir. Bu geçiş sürecinde site sahiplerinin, sitelerine gelen
Akıllı Telefon Googlebot
trafiğinde önemli bir artış görmeleriyle birlikte; arama sonuçlarındaki
snippet
'ler ve
Google önbellek (cache) sayfaları
da bu sayfaların mobil sürümü baz alınarak oluşturulacaktır.
Önceden
söylediğimiz
gibi,
duyarlı (responsive) web tasarımdan
yararlanan ve tüm masaüstü içerik ve işaretlemelerini içerecek şekilde
dinamik sunumu
(dynamic serving) doğru şekilde uygulayan sitelerin genel olarak herhangi bir şey yapmalarına gerek yoktur. Aşağıda, bir sitenin mobil öncelikli dizine eklemeye hazır olduğundan emin olmanıza yardımcı olacak bazı ekstra ipuçları verilmiştir:
Sitenin mobil sürümünün de önemli, yüksek kaliteli içeriğe sahip olduğundan emin olun. Buna metin, resim (alt özellikleriyle) ve videolar gibi bilenen taranabilir ve dizine eklenebilir tüm biçimler dahildir.
Dizine ekleme ve kullanıcıların sevdiği arama özellikleri açısından yapısal veriler oldukça önemlidir. Bunları sitenin hem mobil hem de masaüstü sürümünde olduğundan emin olun. Ayrıca, mobil sayfalarda bulunan yapısal veri işaretlemeleri içerisinde bulunan URL'lerin de mobil versiyonları ile değiştirildiğinden emin olun.
Dizine ekleme ve sunum için bir sayfadaki içerikle ilgili ipuçları sağlayan meta veriler sitenin her iki sürümünde de bulunmalıdır. Örneğin, meta başlık (title) ve açıklamalarının (description) sitedeki tüm sayfaların her iki sürümünde de eşdeğer olarak bulunduklarından emin olun.
Ayrı mobil URL'ler (m. veya m-dot olarak da bilinen) ile bağlantı kurmak için değişiklik yapılmasına gerek yoktur.
Ayrı mobil URL'ler kullanan sitelerde
, bu sürümler arasında mevcut link rel=canonical ve link rel=alternate öğelerini koruyun.
hreflang bağlantılarını ayrı mobil URL'lerde kontrol edin.
link rel=hreflang
öğelerini
uluslararasılaştırma
(internationalization) için kullanırken mobil ve masaüstü URL'leri arasındaki bağlantıyı ayrı olarak oluşturun. Mobil URL'lerinizin hreflang öğesi, diğer mobil URL'lerdeki diğer dil/bölge sürümlerine işaret etmelidir. Benzer şekilde, masaüstü URL'sini oradaki hreflang bağlantı öğelerini kullanarak diğer masaüstü URL'leriyle bağlayın.
Siteyi barındıran sunucuların artması muhtemel
tarama sayısını
karşılamak için yeterli kapasiteye sahip olduğundan emin olun. Bu durum, duyarlı web tasarımı ve dinamik sunumu kullanan siteleri etkilemez; yalnızca mobil sürümün, m.example.com gibi ayrı bir ana makinede bulunduğu siteleri etkiler.
Siteleri bireysel ve bağımsız olarak yukarıdaki ölçütler dahilinde ve mobil öncelikli dizine eklemeye hazır olma durumlarına göre değerlendirip, hazır olduklarında geçişlerini sağlayacağız. Bu süreç az sayıda site için şimdiden başladı ve arama ekibi tarafından da yakından izlenmektedir.
Mobil öncelikli dizine eklemeyi dikkatli bir şekilde devreye almaya devam ediyoruz. Bu sürecin yavaş yürütülmesinin, sitelerini mobil kullanıcılar için hazırlamaları konusunda web yöneticilerine yardımcı olacağını düşünüyoruz ve bu yüzden, şu anda sürecin ne zaman tamamlanacağına dair bir zaman çizelgemiz yok. Sorularınız varsa
Webmaster forumlarımıza
yazabilir veya herkese açık
etkinliklerimize
uğrayabilirsiniz.
Hazirlayan:
Gary Illyes
#NoHacked 3.0: Saldırıları önlemeye ilişkin ipuçları
15 Aralık 2017 Cuma
Geçtiğimiz hafta
#NoHacked
kampanyamızda, saldırıların tespit edilmesiyle ilgili bilgiler ve sitelerin saldırıya uğrama nedenlerini paylaşmıştık. Bu hafta ise bu tip saldırıları önlemeye odaklanıyoruz. Sizin için hazırladığımız bazı ipuçlarını bu yazımızda bulabilirsiniz!
Spam yapanların web sitelerine saldırmak için en çok kullandığı yöntemler
Sitenizin güvenliğinin nasıl ihlal edildiğini anlamak, sitenizi saldırılara karşı korumak için oldukça önemlidir. Spam yapanların sitelerin güvenliğini ihlal etmek için kullandığı
en yaygın yöntemlerden
bazılarını aşağıda bulabilirsiniz.
Kaynaklarınıza dikkat edin! Ücretsiz premium tema ve eklentiler konusunda çok dikkatli olun!
Ücretsiz premium eklentileri muhtemelen duymuşsunuzdur. Normalde satın almanız gereken eklentileri size ücretsiz olarak sunan bir siteyle karşılaşırsanız çok dikkatli olun. Birçok bilgisayar korsanı, popüler bir eklentiyi kopyalayıp buna arka kapılar (backdoor) veya sitenize erişmelerine olanak tanıyacak kötü amaçlı yazılımlar ekledikten sonra sizi kandırmaya çalışır.
Sucuri Blog
üzerinden daha önce yaşanmış benzer bir durum hakkında daha fazla bilgi edinebilirsiniz. Buna ek olarak, yasal, iyi kalitedeki eklentiler ve temalar bile aşağıdaki durumlarda tehlikeli hale gelebilir:
Yeni bir sürüm kullanıma sunulur sunulmaz güncelleme yapılmaması.
Tema veya eklentinin geliştiricisi artık güncelleme yapmayacağını söyleyip tema ya da eklentiyi zaman içersinde eskimeye terk etmesi.
Her durumda, sitenizin tüm yazılımlarının modern olmasını ve güncel kalmasını sağlamak, bilgisayar korsanlarını web sitenizden uzak tutmak için çok önemlidir.
Wordpress'teki botnet
Genellikle spam kampanyaları, otomatik tıklama botları veya DDoS saldırıları gibi kötü amaçlı eylemler için kullanılan ve bir üçüncü tarafın (3rd party) denetimi altındaki çok sayıda bilgisayar, sunucu, cihaz veya web sitelerinden oluşan kümeye
botnet
denir. Çoğu zaman bu tip saldırılar sitenizde gözle görülür bir değişiklik yaratmadıkları için sitenize bir botnet bulaşıp bulaşmadığını tespit etmek oldukça zor olabilir. Ancak siteniz bir botnette yer alıyorsa haliyle sitenizin itibarı, kaynaklarınız ve verileriniz de risk altında olacaktır. Botnetler, bunların nasıl tespit edilebileceği ve sitenizi nasıl etkileyebilecekleri hakkında daha fazla bilgiyi
wordpress ve joomla'daki botnet makalesinden
edinebilirsiniz.
Her zaman olduğu gibi sorularınızı
Webmaster Yardım Forumlarımız
aracılığıyla bize iletebilirsiniz. Haftaya görüşmek üzere!
Yayınlayan: Arama kalitesi ekibi adına Fatih Özkösemen
Yenilenen SEO Başlangıç Kılavuzumuz
13 Aralık 2017 Çarşamba
Başarılı bir web sitesi oluşturmanıza yardımcı olacak halihazırda pek çok kaynak bulunuyor. Bununla birlikte web sitesi sahipleri, sitelerinin arama motoru dostu bir yapıda olabilmesi için çoğu zaman Google olarak bizim önerilerimizi de merak ediyorlar. Bugüne kadar, yeni başlayanlar için bu doğrultuda önerdiğimiz kaynaklar SEO Başlangıç Kılavuzu ve Web Yöneticisi Akademisiydi. Web sitesi sahiplerinin modern ve arama motoru dostu web siteleri oluşturmasına daha fazla yardımcı olabilmek için bugün itibariyle
yeni ve güncellenmiş bir SEO Başlangıç Kılavuzunu
sizlere sunuyoruz.
Geçmişte kullandığımız SEO Başlangıç Kılavuzu'nda, arama motorlarının web sitelerindeki içeriği taramasını, dizine eklemesini ve anlamasını kolaylaştıran en iyi uygulamalar listelenmekteydi. Web Yöneticisi Akademisi'nde ise, bir web sitesinin nasıl oluşturulacağı ve Google Arama'da bulunabilirliğinin nasıl sağlanacağı ile ilgili bilgiler ve araçlar bulunmaktaydı. Açıkçası, bu iki kaynak amaç ve içerik bakımından bazı noktalarda örtüşmekle birlikte; kullanıcı dostu ve güvenli bir web sitesi oluşturma konusunu daha da ayrıntılı olarak ele alabilmek adına birçok fırsat barındırıyorlardı. Bu nedenle Web Yöneticisi Akademisi'ni ve eski SEO Başlangıç Kılavuzu PDF dosyasını kullanımdan kaldırıyoruz.
Güncellenen SEO Başlangıç Kılavuzu, bugün itibariyle hem eski Başlangıç Kılavuzu'nun hem de Web Yöneticisi Akademisi'nin yerini alacaktır. Güncellenen sürüm, önceden kullanımda olan bu iki kaynağa yapılan eklemeler ile birlikte, arama motoru optimizasyonu ihtiyacı, yapısal veri biçimlendirmesi (structured data markup) eklenmesi ve mobil uyumlu web siteleri oluşturmayla ilgili ek bölümler de içermektedir.
Bu yeni kılavuz, bugünden itibaren dokuz dilde (Almanca, Fransızca, İngilizce, İspanyolca, İtalyanca, Japonca, Portekizce, Rusça ve Türkçe) kullanıma sunulmuştur ve çok yakında da bunlara on altı dil daha eklenecektir.
Bir an önce Yeni SEO Başlangıç Kılavuzu'na göz atmanızı ve düşüncelerinizi bizlerle paylaşmanızı tavsiye ediyoruz. Her zaman olduğu gibi, sorularınızı
Webmaster Yardım Forumlarımız
üzerinden bize iletebilirsiniz.
Hazırlayan: Abhas Tripathi, Arama Kalitesi Stratejisti
#NoHacked 3.0: Sitemin saldırıya uğrayıp uğramadığını nasıl anlayabilirim?
11 Aralık 2017 Pazartesi
Geçtiğimiz hafta itibariyle
#NoHacked
kampanyamıza,
G+
ve
Twitter
kanallarımız üzerinden tekrar başlamış bulunuyoruz! #NoHacked, bilgisayar korsanlarının saldırılarıyla (hacking) ilgili farkındalık oluşturmayı amaçlayan ve sitelerinizi bilgisayar korsanlarına karşı nasıl güvende tutacağınızla ilgili ipuçlarının sunulduğu sosyal kampanyamızdır. Bu yıl ise, #NoHacked kampanyasını bu blog aracılığı ile ilk kez Türkçe olarak sizlerle paylaşmak istiyoruz!
Siteler neden saldırıya uğrarlar? Bilgisayar korsanlarının bir web sitesinin güvenliğini ihlal etmek için
farklı nedenleri vardır
ve bu doğrultuda birçok farklı saldırılar gerçekleştirebilirler. Bu yüzden bu tip saldırıları her zaman kolayca tespit etmek mümkün olmayabilir. Burada, saldırıya uğramış sitelerin tespit edilmesinde size yardımı olacak bazı ipuçlarını sizlerle paylaşacağız!
Başlarken
Google veya diger üçüncü taraflardan bir güvenlik uyarısı aldıysanız "Sitemin saldırıya uğrayıp uğramadığını nasıl anlayabilirim?"
rehberimize
göz atarak işe başlayabilirsiniz. Bu rehber, sitenizde güvenlik ihlali olduğunu düşündürecek belirtileri nasıl kontrol edeceğinizi gösteren temel adımlar sunmaktadır.
Google Arama'daki uyarıyı anlama
Google'da, farklı saldırı senaryolarıyla başa çıkmak için farklı süreçlerimiz vardır. Tarama araçları genellikle kötü amaçlı yazılımları (malware) tespit eder ancak bazı spam oluşturma amaçlı saldırıları (spamming hacks) gözden kaçırabilir. Güvenli Tarama sitenizin temiz olduğuna karar verse de, siteniz spam dağıtmak üzere saldırıya uğramış olabilir.
"
Bu site saldırıya uğramış olabilir
" uyarısını görürseniz siteniz, spam içerik görüntülemek üzere saldırıya uğramış olabilir. Aslında, siteniz ücretsiz reklamlar yayınlamak amacıyla saldırıya uğramıştır.
Site URL'sinin altında gösterilen "
Bu site bilgisayarınıza zarar verebilir
" uyarısı, ziyaret etmek üzere olduğunuz sitedeki bazı programların bilgisayarınıza kötü amaçlı yazılımlar yüklenmesine neden olabileceğini düşündüğümüzü gösterir.
Sitenizden önce büyük kırmızı bir ekran görmeniz
çeşitli anlamlara
gelebilir:
"Girmek üzere olduğunuz site kötü amaçlı yazılım içeriyor" uyarısını görürseniz Google, sitenizin
kötü amaçlı yazılım (malware)
dağıttığını tespit etmiştir.
"Girmek üzere olduğunuz site zararlı programlar içeriyor" uyarısını görürseniz site,
istenmeyen yazılım (unwanted software)
dağıttığı için işaretlenmiştir.
"Yanıltıcı bir siteye girmek üzeresiniz" uyarıları,
sitenin kimlik avı (phising) veya sosyal mühendislik (social engineering)
saldırıları yayınlıyor olabileceğini belirtir. Siteniz aşağıdakilerden birini yapmak üzere saldırıya uğramış olabilir.
Zararlı Reklamlar ve Saldırı
Zararlı reklamlar (malvertising) olarak adlandırılan durum, siteniz kötü bir reklam yüklediğinde gerçekleşir. Örneğin bu reklam, ziyaretçilerinizi otomatik olarak baska yerlere yönlendirerek (redirect) sitenizin saldırıya uğramış gibi görünmesine yol açabilir ama gerçekte, bu yalnızca kötü davranan bir reklamdır.
Açık yönlendirmeler: Sitenizin açık yönlendirmeler sağlayıp sağlamadığını kontrol edin
Bilgisayar korsanları, URL'lerini maskelemek için iyi bir siteden yararlanmak isteyebilirler. Bunu yapmalarının bir yolu da açık yönlendirmeleri (open redirects) kullanmaktır. Açık yönlendirmeler, bilgisayar korsanlarının kullanıcıları kendi istedikleri bir URL'ye yönlendirmek için sitenizi kullanmalarına olanak tanır. Daha fazla bilgiyi
burada
bulabilirsiniz!
Mobil kontrol
ü
: Sitenizi bir mobil tarayıcı ile gizli modda görüntülediğinizden emin olun. Kötü amaçlı mobil reklam ağlarını kontrol edin.
Bazen reklamlar veya üçüncü taraflar tarafından yüklenen öğeler (third party elements) gibi kötü içerikler
sizden habersiz olarak mobil kullanıcıları yönlendirebilirler
. Bu davranış, yalnızca belirli tarayıcılardan görülebildiği için kolayca gözden kaçabilir. Bu nedenle sitenizin mobil ve masaüstü sürümlerinin aynı içeriği gösterdiğinden emin olun.
Search Console'u kullanma ve mesaj alma
Search Console, Google'ın web sitenizle ilgili olarak sizinle iletişim kurmak için kullandığı bir platformdur. Ayrıca, web sitenizi iyileştirmenize ve yönetmenize yardımcı olabilecek birçok farklı aracı da bünyesinde barındırır. Sitenizin yazılımından sorumlu bir geliştirici olmasanız bile
sitenizin Search Console'da doğrulandığından
emin olun. Search Console'daki uyarılar ve mesajlar, Google'ın sitenizde kritik hatalar tespit edip etmediğini size bildirir.
Eğer saldırı belirtilerini hâlâ bulamıyorsanız, bir güvenlik uzmanına danışabilir veya ikinci bir kontrol için
Webmaster Yardım Forumumuz
üzerinden sorunuzu bize iletebilirsiniz.
#NoHacked kampanyası önümüzdeki 2 hafta boyunca devam edecektir. Bizi
G+
ve
Twitter
kanallarımızdan takip edebilir veya bu blogdaki güncellemelere zaman zaman göz atabilirsiniz. Her haftanın özetini, hafta başında yine burada yayınlayacağız!
Güvenle kalın!
Yayınlayan: Arama kalitesi ekibi adına Fatih Özkösemen
AJAX tabanlı sayfaları tarama
4 Aralık 2017 Pazartesi
AJAX tarama şemasını
, Googlebot'un JavaScript tabanlı web sayfalarına erişebilmesi için bir yöntem olarak geçmişte kullanıma sunmuş ve yakın zamanda da
bunu kullanımdan kaldırma planlarımızı
duyurmuştuk. Zaman içerisinde, Google mühendisleri Googlebot için JavaScript oluşturma sürecini önemli ölçüde iyileştirdiler. Bu ilerlemeler göz önüne alındığında, 2018'in ikinci çeyreğinde, sitelerin bu sayfaları kendilerinin oluşturmasını (rendering) zorunlu tutmak yerine Google tarafında oluşturmaya başlayacağız. Kısacası, AJAX tarama şemasını artık kullanmayacağız.
Hatırlatmak gerekirse, AJAX tarama şeması URL'sinde bir "#!" bulunan veya kendisi bir "
fragment meta etiketi
" içeren sayfaları kabul edip, ardından bunları, URL'de bir "?_escaped_fragment_=" parametresiyle taramaktaydı. Bu sürümün de (escaped version), sayfanın tam olarak oluşturulmuş ve/veya eşdeğer sürümü olması ve bunun web sitesinin kendisi tarafından oluşturulması gerekmekteydi.
Bu değişiklikle Googlebot, #! URL'sini doğrudan oluşturacak (render edecek) ve böylece, web sitesi sahibinin, sayfanın oluşturulmuş (render edilmiş) bir sürümünü sağlamasına gerek kalmayacaktır. Arama sonuçlarımızda da bu URL'leri desteklemeye devam edeceğiz.
Bu güncellemeyle, çoğu AJAX tabanlı web sitesinde önemli değişiklikler görmeyi beklemiyoruz. Web yöneticileri aşağıda belirtilen şekilde sayfalarını tekrar kontrol edebilecekleri gibi; ayrıca, olası sorunları bulunan sitelere de önümüzdeki süreçte çeşitli bildirimler göndereceğiz.
Siteniz şu anda #! URL'lerini veya fragment meta etiketini kullanıyorsa aşağıdakileri yapmanızı öneririz:
Google Search Console
'daki araçlara erişebilmeniz ve Google'ın bulabileceği sorunlarla ilgili olarak size bilgi verebilmemiz için Google Search Console'da web sitesinin sahibi olduğunuzu doğrulayın.
Sayfalarınızı Search Console'un
Google Gibi Getir Aracıyla
test edin. #! URL'si ile escaped sürüm URL'sinin sonuçlarını karşılaştırıp herhangi bir fark olup olmadığına bakın. Bunu, web sitesinin önemli ölçüde farklı olan tüm bölümleri için yapın. Desteklenen API'ler hakkında daha fazla bilgi için
geliştirici dokümanlarımıza
göz atın ve gerektiğinde
hata ayıklama (debug) kılavuzumuza
bakın.
Bağlantıların
"a" HTML öğeleri
kullandığını onaylamak için Chrome'un
Öğeyi İncele (Inspect Element)
işlevini kullanın ve uygun yerlerde (örneğin, kullanıcı tarafından oluşturulan içerikler gibi)
rel=nofollow
parametresini ekleyin.
Sayfanın başlık ve açıklama meta etiketini
, robots meta etiketlerini ve diğer meta etiketleri kontrol etmek için Chrome'un
Öğeyi İncele (Inspect Element)
işlevini kullanın. Ayrıca,
yapısal verilerin
tamamının oluşturulmuş sayfada da (rendered version) bulunduğundan emin olun.
Flash, Silverlight veya diğer eklenti tabanlı teknolojilerle hazırlanan içeriklerin arama dizinine eklenmeleri gerekiyorsa, bunların JavaScript'e veya "normal" HTML'ye dönüştürülmeleri gerektiğini unutmayın.
Bu değişikliğin, web sitenizle ilgili çalışmaları biraz daha kolaylaştıracağını ve sizin tarafınızda sayfaları oluşturma gereksinimini azaltacağını umuyoruz. Sorularınız veya yorumlarınız için çekinmeden
web yöneticisi yardım forumlarımızı
ziyaret edebilir veya
JavaScript siteleri çalışma grubumuza
katılabilirsiniz.
Gönderen: John Mueller, Google İsviçre
"Etkinlik" yapısal veri işaretlemesiyle ilgili hatırlatma
27 Kasım 2017 Pazartesi
Son zamanlarda kullanıcılardan, "etkinlikler" snippet'lerinin göründüğü arama sonuçlarında kuponlar veya indirimler gibi aslında etkin olmayan öğeler gördüklerine dair geri bildirimler alıyoruz. Bu durum, kullanıcılar açısından gerçekten kafa karıştırıcı olduğu gibi
ilave açıklamalar
eklediğimiz yönergelerimize de aykırıdır.
Peki tam olarak sorun nedir?
Bazı yayıncıların, indirim tekliflerini tanımlamak için kuponlar alanında "etkinlik" işaretlemesini kullandıklarını gördük. İndirim kuponları bir kullanıcı için son derece önemli bir şey olsa da, bu durum, kuponların etkinlik veya “saleEvents” olduğu anlamına gelmez. Etkinlik olmayan bir şeyi tanımlamak için
etkinlik işaretlemesini
kullanmak, ortada gerçek bir etkinlik olmamasına rağmen belirli bir zamanda gerçekleşecek bir şey için arama sonuçlarında "zengin sonucları (rich results)" tetiklediğinden kötü bir kullanıcı deneyimine neden olur.
Sorunu açıklamak için aşağıda bazı örnekler verilmiştir:
Bu, kullanıcıyı yanıltan bir deneyime neden olduğu için bu gibi durumlarda ilgili siteye manuel işlem uygulayabiliriz. Web sitenizin bu tür bir manuel işlemden etkilenmesi halinde, Search Console hesabınıza konuyla ilgili bir bildirim gönderilir. Bu manuel işlemin uygulanması, ilgili sitede bulunan diğer tüm yapısal veri işaretlemelerinin de arama sonuçlarında gösterilmemesine neden olabilir.
Bu blog yayınında özel olarak indirimlerin ve kuponların altını çizsek de, bu durum, "etkinlik" işaretlemesiyle açıklanan diğer tüm etkinlik dışı öğeler; ve hatta genel anlamda herhangi bir yapısal verinin belirtilen amacı dışında kullanıldığı durumlar için de geçerlidir.
Daha fazla bilgi edinmek için
geliştirici dokümantasyonlarımıza
bakabilir veya diğer tüm sorularınız için
Webmaster Forumumuzu
ziyaret edebilirsiniz.
Gönderen: Sven Naumann, Trust & Safety Search Team
Yüksek kaliteli AMP sayfaları ile kullanıcıların etkileşimini sağlama
24 Kasım 2017 Cuma
Kullanıcılarımızın AMP sonuçlarıyla olan deneyimini iyileştirmek amacıyla AMP ile içerik denkliğine ilişkin politikamızı uygulama biçimimizde değişiklikler yapıyoruz. 1 Şubat 2018'den itibaren, politika, AMP sayfa içeriğinin (orijinal) standart sayfa içeriğiyle benzer olmasını zorunlu hale getirecektir. Tekrar hatırlatmak gerekirse AMP, bir sıralama sinyali değildir ve sıralama politikasında AMP açısından herhangi bir değişiklik yoktur.
2015'te hayata geçirilen
açık kaynak Accelerated Mobile Pages (AMP) projesi,
25 milyonu aşkın alan adının
AMP formatını uygulamasıyla birlikte muazzam bir büyüme kaydetmektedir. Bu hızlı ilerleme, kullanıcılarımızın içerik tüketiminde en iyi deneyimi yaşamaya devam etmelerini ve bu şekilde yayıncının sunduğu içerikle daha fazla etkileşimde bulunmalarını sağlama sorumluluğunu da beraberinde getirmektedir.
Bazı durumlarda web yöneticileri, içeriklerini iki sürüm halinde yayınlamaktalar: AMP'ye dayalı olmayan bir standart sayfa ve bir AMP sayfası şeklinde. İdeal senaryoda her iki sayfa da eşdeğer içeriğe sahip olmalı ve kullanıcı, AMP aracılığıyla aynı içeriğe daha hızlı ve daha sorunsuz bir şekilde ulaşabilmelidir. Ancak bazı durumlarda AMP sayfasındaki içerik, orijinal (standart) sayfadaki içerikle uyuşmamaktadır.
Bazı nadir durumlarda da AMP sayfaları, tanıtım sayfaları olarak kullanılmaktadır. Bu sayfalar çok az içeriğe sahip oldukları için bu durum özellikle kullanıcıların kötü bir deneyim yaşamasına yol açabilir. Böyle durumlarda, kullanıcılar gerçek içeriğe ulaşmak için iki kez tıklama yapmak zorunda kalmaktadır. Aşağıda bu durumun nasıl görünebileceğine ilişkin bir örnek verilmiştir: Ana makaleden kısa bir metin verilerek kullanıcıdan makalenin devamını okuması için tıklayıp başka bir sayfayı ziyaret etmesi istenmektedir.
AMP, web'in performansını önemli ölçüde artırmak ve içerik tüketiminde hem hızlı hem de tutarlı bir deneyimi sağlamak amacıyla kullanıma sunulmuştur. Bu hedef doğrultusunda, Google Arama'da AMP olarak gösterilmek istenen sayfalar için AMP sayfası ve standart sayfa arasında
yakın denklik sağlanması şartını
zorunlu hale getireceğiz.
AMP sayfasının, AMP olmayan muadiliyle aynı önemli içeriğe sahip olmadığını tespit ettiğimiz durumlarda kullanıcılarımızı AMP olmayan sayfaya yönlendireceğiz. Bu işlem, Arama sıralamasını etkilemez. Ancak bu sayfalar, AMP ile En Çok Okunanlar bölumu gibi AMP gerektiren Arama özelliklerinde dikkate alınmayacaktır. Buna ek olarak, web yöneticisini
Search Console
üzerinden manuel işlem mesajıyla bilgilendirecek ve yayıncıya, AMP sayfasını tekrar dikkate alabilmemiz için sorunu düzeltme şansı verilecektir. Ayrıca
AMP açık kaynak web sitesinde
hızlı, güzel ve yüksek performans gösteren AMP sayfaları oluşturmanıza yardımcı olacak faydalı kılavuzlar bulabilirsiniz.
Bu değişikliğin, web yöneticilerini standart ve AMP muadili arasında içerik denkliği sağlamaya teşvik etmesini umuyoruz. Bunun gerçekleşmesi halinde siteniz daha iyi bir deneyim sunacak, dolayısıyla kullanıcılar da daha mutlu olacaktır.
Gönderen: Ashish Mehta, Ürün Yöneticisi
Tanıtım yazıları gibi geniş ölçekli makale kampanyalarındaki bağlantılarla ilgili bir hatırlatma
13 Kasım 2017 Pazartesi
Tanıtım yazıları, sponsorlu yayınlar, misafir yayınları veya iş ortağı yayınları olarak adlandırılan makalelerin, son dönemde artan bir şekilde spam içerikli bağlantılar (link) içerdiğini gözlemlemekteyiz. Bu makaleler genellikle bir web sitesi tarafından veya onun adına yazılıp farklı bir veya birden çok web sitesinde yayınlanmaktadırlar.
Google, kullanıcıları bilgilendirdiği, başka bir sitenin kitlesini eğittiği veya amacınıza ya da şirketinize farkındalık sağladığı durumlarda bu makale türlerine karşı olumsuz yaklaşımda bulunmaz. Ancak, yazarın sitesine geri dönen geniş ölçekte bağlantılar (backlink) oluşturmanın öncelikli amaç olduğu durumlar, Google'ın
bağlantı düzenleri
ile ilgili kurallarını ihlal etmektedir. Uç noktada kullanıldığında, bir makalenin bu kuralları ihlal ettiğini gösterebilen faktörleri aşağıda bulabilirsiniz:
Makalelerinizi sitenize ilişkin anahtar kelime açısından zengin bağlantılarla doldurma.
Makalelerin birçok farklı sitede yayınlanmasını sağlama; veya, çok sayıda makalenin az sayıda büyük, farklı sitelerde yer alması.
Yazdıkları konular hakkında bilgi sahibi olmayan makale yazarlarını kullanma veya çalıştırma.
Bu makalelerde aynı veya benzer içeriği kullanma; alternatif olarak, kendi sitenizde bulunan makalelerin tam içeriğini kopyalama (bu durumda
rel=”nofollow”
etiketinin yanı sıra
rel=”canonical”
etiketinin de kullanılması önerilir)
Bir web sitesinin spam içerikli bağlantıların bulunduğu makaleler yayınladığını tespit ettiğimizde, Google'ın sitenin kalitesiyle ilgili algısı değişebilir ve bu durum, sitenin sıralamasını olumsuz etkileyebilir. Bu tür makaleleri kabul eden ve yayınlayan siteler, bunları dikkatli bir şekilde araştırmalı ve şuna benzer sorular sormalıdır:
Bu kişiyi veya web sitesini tanıyor muyum?
Bu kişinin mesajı sitemdeki kitle için uygun mu?
Makale yararlı bir içeriğe sahip mi?
Makalede şüpheli amaçlı bağlantılar varsa yazar bunlarda rel=”nofollow” etiketini kullanmış mı?
Bağlantı için makale oluşturmak genel olarak web açısından kötü bir davranış olduğundan, Google bunu yapan web sitelerine yönelik olarak bazı işlemler gerçekleştirir. Bağlantı oluşturmak öncelikli amaç haline geldiğinde, makalelerin kalitesi düşebilir ve kullanıcılar için kötü bir deneyim ortaya çıkabilir. Ayrıca, web yöneticileri agresif veya sürekli tekrarlayan "Makalemi yayınla!" istekleri almayı genellikle tercih etmezler (bu tür durumların,
spam bildirme
formumuz aracılığıyla bize bildirilmesini öneririz).
Son olarak, eğer web uzerinde bulunan bağlantılar bir öneri biçimiyse ve kendi sitenizle ilgili en çok öneriyi de yine kendiniz oluşturuyorsanız; sitenizle ilgili iyi bir izlenim oluşturmak için bunun inandırıcı ve doğru bir yöntem olduğu söylenebilir mi? Bağlantı oluşturmayla ilgili en iyi tavsiyemiz sitenizin içeriğini iyileştirmeye ve kullanıcılarınızın beklentilerine odaklanmanızdır. Bunu yaptığınızda bağlantılar da dahil olmak üzere her şey kendiliğinden gelecektir. Her zaman olduğu gibi, konuyla ilgili tüm sorularınızı bize
yardım forumlarımız
uzerinden iletebilirsiniz.
Google webspam ekibi adina
Fatih Özkösemen
Kullanıcılar için daha yüksek kaliteli içerik sağlama
7 Kasım 2017 Salı
Google’ın dünyadaki bilgileri düzenleme
misyonu
çerçevesinde, kullanıcılarımızı en yüksek kaliteye sahip içeriklere yönlendirmek istiyoruz. Bu ilke,
kalite ölçme yönergelerimizde
de örneklendirilmiştir. Kullanıcılara yarar sağlayan kaliteli içerikte en büyük pay profesyonel yayıncılara ait. Biz de onların başarısını teşvik etmek istiyoruz.
Söz konusu ekosistem, iki ana gelir kaynağıyla sürdürülmektedir: Reklamlar ve abonelikler. Aboneliklerin Arama'da etkili olması için hassas bir denge gerekir. Abonelik gerektiren içerikler genellikle ödeme duvarının arkasına gizlenir. Böylece abone olmayan kullanıcılar içeriğe erişemezler. Değerlendirmelerimiz, ödeme duvarının arkasındaki yüksek kaliteli içeriğe aşina olmayan kullanıcıların genellikle ücretsiz içerik sunan diğer sitelere yöneldiğini gösteriyor. Kullanıcı karşılaştığı içeriğin ne kadar değerli olduğunu bilmiyorsa, abone olmak için sebep bulması zor olmaktadır. Hatta, deneylerimiz kullanıcıların bir kısmının abonelik gerektiren sitelerden kaçındığını göstermiştir. Bu nedenle, sundukları içeriğin değerini kullanıcıların anlamaları için sitelerin, içeriklerinin bir kısmını ücretsiz örnek olarak sağlamaları son derece önemlidir.
Hem Google
web arama
hem de
Haberler
'e yönelik İlk Tıklama Ücretsiz (First Click Free - FCF) yaklaşımı, bu sorunu ele almak amacıyla tasarlanmıştı. Bu özellik, abonelik gerektiren içeriğe sahip yayıncıların kendilerini tanıtabilmeleri ve kullanıcılar tarafından keşfedilebilmeleri için fırsat sunarken, Google kullanıcılarına da söz konusu içeriği bulabilmeleri olanağı sunar. Geçtiğimiz yıl FCF'nin kullanıcı memnuniyeti ve yayıncılık ekosisteminin sürdürülebilirliği üzerindeki etkilerini araştırmak için yayıncılarla birlikte çalıştık. FCF'nin makul bir örnek sunma modeli olduğunu, ancak yayıncıların kendileri için en uygun örnek sunma stratejisini daha iyi belirleyebileceklerini keşfettik. Bu nedenle, FCF'yi Arama için bir zorunluluk olmaktan çıkarıyoruz ve yayıncıların güncellenmiş
web yöneticisi yönergelerini
ihlal etmemek koşuluyla farklı ücretsiz örnek sunma projelerini denemelerini destekliyoruz. Buna Esnek Örnekleme (Flexible Sampling) diyoruz.
FCF'yi oluşturmamızın arkasındaki asıl nedenlerden biri, Googlebot'a gönderilen içeriğin kullanıcılara sunulan içerikten farklı olduğu
gizleme (cloaking)
ile ilgili sorunları ele almaktı. Spam yapanlar genellikle arama motoruna ilginç içerik göstererek arama motorunu kandırmayı amaçlarlar. Örneğin, önce arama motoruna sağlıklı yemek tarifleri, ardından da kullanıcılara zayıflama haplarıyla ilgili teklif gösterirler. Bu “sağ gösterip sol vurma” planı, kullanıcılar umdukları içeriği göremedikleri için kötü bir kullanıcı deneyimine neden olur. Ödeme duvarı olan sitelere, yeni kullanıma sunulan
yapılandırılmış veri (structured data)
özelliğini uygulamaları kesinlikle önerilir. Zira aksi takdirde, ödeme duvarının bir çeşit gizleme olduğu düşünülerek sayfaların arama sonuçlarından kaldırılmasına neden olabilir.
Araştırmalarımıza dayanarak, esnek örnekleme uygulanmasına ilişkin
en iyi pratikleri
ayrıntılarıyla hazırladık. Örnekleme ile ilgili iki yöntem öneriyoruz:
Ölçme yöntemi (metering)
, kullanıcılara okuyabilecekleri ücretsiz makaleler için bir kota koyar, ödeme duvarları bundan sonra görünmeye başlar.
Tanıtım girişi (lead-in)
yöntemi ise, bir makalenin içeriğini tam olarak göstermeden bir kısmını kullanıcıya sunar.
Ölçme yöntemi (metering) konusunda, günlükten ziyade aylık ölçmenin daha fazla esneklik ve test için daha güvenli bir ortam sağlayacağına inanıyoruz. 10 tane aylık örnekte bir tam sayı değerinden diğerine geçişin kullanıcı açısından etkisi, 3 tane günlük örnekte olduğundan daha azdır. Yayıncılar ve kitleleri farklı olduğu için ücretsiz örnekleme açısından tüm yayıncılara uyan tek bir değer yoktur. Ancak, yeni potansiyel abonelere iyi bir kullanıcı deneyimi sağlamak üzere yayıncıların Google arama kullanıcılarına ayda 10 ücretsiz tıklama hakkı sunarak başlamalarını öneririz. Yayıncılar daha sonra denemeler yaparak işletmeleri açısından keşif ile dönüşüm arasındaki en uygun dengeyi optimize etmelidir.
Tanıtım girişi yöntemi (lead-in) genellikle içeriğin bir kısmı kesilerek uygulanır. Örneğin, makalenin ilk birkaç cümlesini veya 50-100 kelimesini göstermek gibi. Tanıtım girişi yöntemi, kullanıcıların içeriğin ne kadar değerli olabileceği konusunda fikir edinmelerine olanak tanır. İçeriği tamamen engellenmiş bir sayfaya kıyasla tanıtım girişi yöntemi, kullanıcılara açık bir şekilde daha fazla fayda ve katma değer sağlar.
Bu değişiklik ücretli içerik ekosisteminin büyümesine olanak tanıdığı, sonuç olarak da kullanıcılara yarar sağladığı için bizi heyecanlandırmaktadır. Kullanıcılara daha yüksek kaliteli içerik sunmak için sabırsızlanıyoruz!
Gönderen: Cody Kwok, Principal Engineer
rel=canonical ile ilgili yaygın olarak yapılan 5 hata
3 Kasım 2017 Cuma
Web sayfanıza
rel=canonical bağlantısı
eklemek, arama motorlarına
web'deki yinelenen sayfalar
arasında dizine alınmasını tercih ettiğiniz sürümü gösteren güçlü bir ipucu sağlar. Bu kullanım, aralarında
Yahoo!
,
Bing
ve Google'ın da bulunduğu çok sayıda arama motoru tarafından desteklenir. rel=canonical bağlantısı, yinelenen içerikler için dizine ekleme özelliklerini (gelen bağlantılar gibi) birleştirir ve aynı zamanda arama sonuçlarında görüntülenmesini istediğiniz URL'yi belirtir. Ancak, yanlış bir yapılandırma olduğunda bu durum çok da kolay fark edilemediği için, rel=canonical kullanımı bazen karmaşık olabilmektedir:
Web yöneticisi kendi tarayıcısında sol taraftaki "red velvet" (kirmizi renkli kek) sayfasını görürken, arama motorları sağ tarafta web yöneticisinin kazara oluşturduğu “blue velvet” (mavi renkli başka bir kek) rel=canonical ifadesini görür.
rel=canonical kullanımında “best practice” olarak da bilinen şu uygulamaları öneriyoruz:
Yinelenen sayfanın içeriğinin büyük bir bölümü standart sürümde de bulunmalıdır. (Bu durumu test edebilmek adına, mesela bu sayfalardaki içeriğin dilini bilmediğinizi varsayalım. Yinelenen içerik ile standart içeriği yan yana getirdiğinizde, yinelenen sayfadaki kelimelerin çok büyük bir yüzdesi standart sayfada da bulunuyor mu? Sayfaların benzer olduğunu anlayabilmek için bu dili anlamanız gerekiyorsa eğer (örneğin sadece genel anlamda konular benzerken, birebir kelimelerde büyük ölçüde farklılık varsa) arama motorları standart olarak belirtilen URL’yi dikkate almayabilir.)
rel=canonical hedefinizin gerçekten var olduğunu (hata veya “
soft 404
” olmadığını) bir kez daha kontrol edin.
rel=canonical hedefinde
noindex robots meta etiketi
bulunmadığını doğrulayın.
Arama sonuçlarında, tekrarlanan URL'nin değil, rel=canonical URL'sinin görüntülenmesini tercih ettiğinizden emin olun.
rel=canonical bağlantısını ya sayfanın <head> bölümüne ya da HTTP üstbilgisine (HTTP header) ekleyin.
Bir sayfa için birden fazla rel=canonical belirtmeyin. Birden fazla belirtirseniz tüm rel=canonical ifadeleri yok sayılır.
Hata 1: Sayfalara ayrılmış bir serinin ilk sayfası için rel=canonical kullanılması
Birden fazla sayfaya yayılan bir makaleniz olduğunu düşünün:
example.com/article?story=cupcake-news&page=1
example.com/article?story=cupcake-news&page=2
Vb.
2. veya daha sonraki bir sayfadan 1. sayfaya bir rel=canonical belirtmek doğru bir rel=canonical kullanımı değildir, çünkü bu sayfalar yinelenen sayfalar değildir. Bu örnekte rel=canonical kullanılması, 2. ve sonraki sayfalardaki içeriğin dizine hiç eklenmemesi sonucunu doğurur.
Bir serinin bileşen sayfalarından ilk sayfaya rel=canonical ifadesi belirtildiğinde, yararlı içerik (ör. “cookies are superior nutrition" (kurabiyenin faydaları) ve “to vegetables” (sebzelerden fazladır)) kaybolur.
Sayfalara ayrılmış içerik
olduğu durumlarda, bileşen sayfalarından makalenin tek sayfalık bir sürümüne rel=canonical ifadesinin belirtilmesini veya rel="prev" ve rel="next" sayfalara ayırma işaretlerinin kullanılmasını öneririz.
Bileşen sayfalarından "view all" (tümünü gör) sayfasına rel=canonical kullanımı
View all (tümünü gör) sayfasına bir rel=canonical belirtilmemişse, sayfalara ayrılmış içerikte rel=”prev” ve rel=”next” işaretlemesi kullanılabilir.
Hata 2: Yanlışlıkla göreli (relative) URL'ler olarak yazılan mutlak (absolute) URL'ler
Pek çok HTML etiketi gibi <link> etiketi de hem göreli hem de mutlak URL'leri kabul eder. Göreli URL'ler geçerli sayfaya "göreli" bir yol içerir. Örneğin, “images/cupcake.png” ifadesi, “geçerli dizinden “images” alt dizinine ve sonra cupcake.png'ye git” anlamına gelir. Mutlak URL'ler, http:// gibi bir şema da dahil olmak üzere tam yolu belirtir.
<link rel=canonical href=“example.com/cupcake.html” /> şeklinde bir ifade (“http://” olmadığından bu göreli bir URL'dir) belirtmek, istenilen standart URL'nin http://example.com/example.com/cupcake.html olduğu imasında bulunur; oysa büyük olasılıkla amaçlanan bu değildir. Böyle durumlarda, algoritmalarımız belirtilen rel=canonical ifadesini yok sayabilir. Sonuç olarak bu rel=canonical ifadesiyle ulaşmayı umduğunuz şey gerçekleşmeyecektir.
Hata 3: Yanlışlıkla yapılan veya birden fazla olan rel=canonical ifadeleri
Zaman zaman, yanlışlıkla eklendiğini düşündüğümüz rel=canonical ifadeleri görüyoruz. Bunlar çok seyrek durumlarda basit yazım hataları olabilirken, çoğunlukla rel=canonical ifadesinin hedefini değiştirmeyi düşünmeden bir sayfa şablonunu kopyalayan bir web yöneticisi nedeniyle de olabilmektedir. Bu durumda, site sahibinin sayfaları, şablonu hazırlayan kişinin sitesine yönelik bir rel=canonical belirtebilir.
Şablon kullanıyorsanız rel=canonical ifadesini de kopyalamadığınızdan emin olun.
Diğer bir sorun da, sayfalarda farklı URL'lere yönelik birden fazla rel=canonical bağlantısı bulunmasıdır. Genellikle varsayılan bir rel=canonical bağlantısı yerleştiren SEO eklentileriyle ilişkili olarak ortaya çıkan bu durumdan eklentiyi yükleyen web yöneticisinin de haberi olmayabilir. Birden fazla rel=canonical ifadesi bulunduğu durumlarda Google büyük olasılıkla tüm rel=canonical ipuçlarını yok sayacaktır. Geçerli bir rel=canonical ifadesinin sağlayabileceği tüm yararlar kaybolacaktır.
Sayfanın kaynak koduna bakarak eklentilerin davranışını kontrol edin.
Bu iki tür durumda da, sayfanın kaynak kodunu yeniden kontrol etmek sorunun düzeltilmesine yardımcı olur. rel=canonical bağlantıları dağınık yerleştirilmiş olabileceğinden <head> bölümünün tamamını kontrol ettiğinizden emin olun.
Hata 4: Kategori veya açılış sayfası, öne çıkan bir makaleye yönelik rel=canonical belirtiyor
Tatlılar hakkında bir site yayınladığınızı varsayalım. Tatlı sitenizde “pasta” ve “dondurma” gibi kullanışlı kategori sayfaları bulunsun ve her gün bu kategori sayfaları belirli bir makaleyi öne çıkarsın. Örneğin, pasta açılış sayfanızda “red velvet cupcakes” öne çıkarılmış olabilir. "Pasta" kategori sayfası “red velvet cupcake” sayfasıyla neredeyse tamamen aynı içeriğe sahip olduğu için, kategori sayfasından öne çıkan bağımsız makaleye bir rel=canonical eklemiş olabilirsiniz.
Bu rel=canonical ifadesini kabul edecek olsaydık, pasta kategori sayfanız arama sonuçlarında görünmezdi. Çünkü rel=canonical ifadesi, arama motorlarının yinelenen yerine standart URL'yi görüntülemelerini tercih ettiğinizi işaret eder. Bununla birlikte, kullanıcıların hem kategori sayfasını, hem de öne çıkan makaleyi bulabilmesini istiyorsanız, en iyisi ya sadece kategori sayfasında kendine referans veren bir rel=canonical bulunması, ya da hiç rel=canonical olmamasıdır.
Standart ifadenin aynı zamanda tercih edilen görüntüleme URL'sini ima ettiğini unutmayın. Bir kategori veya açılış sayfasından öne çıkan bir makaleye rel=canonical eklemekten kaçının.
Hata 5: <body> içindeki rel=canonical
rel=canonical bağlantı etiketi bir HTML dokümanının yalnızca <head> bölümünde görünmelidir. Ayrıca, HTML ayrıştırma (parsing) sorunlarından kaçınabilmek için de rel=canonical ifadesini <head> içinde olabildiğince başta bir yere eklemek iyi olur. <body> bölümünde rel=canonical ifadesine rastladığımızda bunu dikkate almayız.
Bu, düzeltmesi kolay bir hatadır. rel=canonical bağlantılarınızın her zaman sayfanızın <head> bölümünde olduğunu ve yapabildiğiniz ölçüde başta kullanıldığını yeniden kontrol etmeniz yeterlidir.
<head> bölümündeki rel=canonical ifadeleri işlenir, <body> bölümündekiler işlenmez.
Sonuç
Yararlı rel=canonical ifadeleri oluşturmak için:
Yinelenen bir sayfanın ana metin içeriğinin büyük bölümünün standart sayfada da bulunduğunu doğrulayın.
rel=canonical ifadesinin (varsa) yalnızca bir defa ve sayfanın <head> bölümünde belirtildiğini kontrol edin.
rel=canonical ifadesinin varolan ve yararlı içeriğe sahip bir URL'yi işaret ettiğini (yani, 404 veya daha kötüsü, soft 404 olmadığını) kontrol edin.
Açılış veya kategori sayfalarından öne çıkan makalelere yönelik rel=canonical ifadesi belirtmekten kaçının; çünkü bu durumda, öne çıkan makale, arama sonuçlarında tercih edilen URL olacaktır.
Yine her zamanki gibi, tüm sorularınızı
Web Yöneticisi Yardım Forumu
uzerinden bize iletebilirsiniz.
Arama kalitesi ekibi adına yayınlayan:
Fatih Özkösemen
Not: Bu makale ilk olarak 8 Nisan 2013 tarihinde İngilizce Google Webmaster Bloğunda Allan Scott tarafından
yayınlanmıştır
.
Yinelenen içerikler ve standart URL'nin belirlenmesi
26 Eylül 2017 Salı
Yinelenen içerikler (duplicate content) ve bunların arama sonuçlarında doğru şekilde indekslenebilmesi ile ilgili endişelerinizi giderebilmek için, 2009 yılından beri desteklediğimiz Standart URL (Canonical URL) yapısı hakkında bilgilerinizi tazelemek istedik. En basit tabirle Canonical URL yapısı, tercih ettiğiniz bir URL sürümünü herkese açık şekilde belirtmenize olanak tanıyan bir web standardıdır. Sitenizde eğer birden çok URL üzerinden erişilebilen, birbirinin aynı veya büyük ölçüde benzer içerikler varsa bu yapı, arama sonuçlarında gösterilen URL üzerinde size daha fazla denetim sağlar. Ayrıca, bağlantı (link) popülerliği gibi özelliklerin de tercih ettiğiniz sürümde birleştirildiğinden emin olmanıza da yardımcı olur.
Şekerleme satan bir siteyle
ilgili geçmişte verdiğimiz bir örneğe tekrar göz atalım dilerseniz. Tercih ettiğiniz URL sürümünün ve içeriğinin aşağıdaki gibi göründüğünü düşünün:
http://www.example.com/product.php?item=swedish-fish
Ancak, kullanıcılar (ve Googlebot) İsveç balığı (Swedish fish) şekerlemesine ait içeriğe birden çok (basit olmayan) URL üzerinden erişebilmektedir. Bu URL'lerdeki önemli bilgiler tercih ettiğiniz sürümle aynı olsa bile, sıralama parametreleri veya kategoride gezinme gibi unsurlar nedeniyle biraz farklı içerik çeşitleri gösterebilir:
http://www.example.com/product.php?item=swedish-fish&category=gummy-candy
Tamamıyla aynı içeriğe sahip ancak izleme parametreleri veya oturum kimliği gibi nedenlerle farklı URL'lere sahip de olabilirler:
http://www.example.com/product.php?item=swedish-fish&trackingid=1234&sessionid=5678
Bu durumlarda yapmanız gereken, tercih ettiğiniz standart (canonical) URL’i belirtmek için şu
<link>
etiketini:
<link rel="canonical" href="http://www.example.com/product.php?item=swedish-fish" />
aşağıdaki yinelenen içerik URL'lerinin
<head>
bölümüne eklemek olacaktır:
http://www.example.com/product.php?item=swedish-fish&category=gummy-candy
http://www.example.com/product.php?item=swedish-fish&trackingid=1234&sessionid=5678
daha sonra, Google tüm yinelene URL’lerin, bu standart (canonical) URL'ye referans gösterdiğini anlayacaktır:
http://www.example.com/product.php?item=swedish-fish
. PageRank ve ilgili diğer sinyaller gibi ek URL özellikleri de bu URL’ye aktarılacaktır.
Bu standart, sitenizi tarama ve dizine ekleme işlemleri sırasında herhangi bir arama motoru tarafından da benimsenebilir.
Son olarak, bu konuda aklınıza gelmesi muhtemel diğer bazı sorulara da cevap vermeye çalışacağız:
rel="canonical" bir ipucu mu yoksa bir direktif mi?
Bu, oldukça önem verdiğimiz bir ipucudur. Arama sonuçlarında en alakalı sayfayı görüntülemek için hesaplamalar yaparken diğer sinyallerle birlikte bu tercihinizi de dikkate alırız.
Standart sayfayı belirtmek için
<link rel="canonical" href="product.php?item=swedish-fish" />
gibi göreli bir yol (relative path) kullanabilir miyim?
Evet, göreli yollar (relative path)
<link>
etiketiyle birlikte alışılageldik şekilde tanınır. Ayrıca, dokümanınıza bir
<base>
bağlantısı eklerseniz göreli yollar, temel URL'ye göre çözümlenecektir.
Standart URL’in, içeriğin tam bir yinelemesi olmaması sorun yaratır mı?
Örneğin, bir ürün listesinin sıralama düzeninde küçük farklılıklara izin veriyoruz. Ayrıca, standart ve yinelenen sayfaları farklı zamanlarda tarayabileceğimizi, bu nedenle de zaman zaman içeriğinizin farklı sürümlerini görebileceğimizi biliyoruz. Tüm bunlar bizim için sorun teşkil etmiyor.
rel="canonical"
sayfası bir 404 hatası döndürürse ne olur?
İçeriğinizi dizine eklemeye ve bir standart URL bulabilmek adına mantık yürütmeye devam ederiz, ancak her zaman standart URL olarak mevcut ve aktif URL'leri belirtmenizi tavsiye ediyoruz.
rel="canonical"
henüz dizine eklenmemişse ne olur?
Web'deki herkese açık tüm içeriklerde olduğu gibi belirtilen standart URL'yi de hızlı bir şekilde keşfedip taramaya çalışıyoruz. İçeriği dizine ekler eklemez
rel="canonical"
ipucunu yeniden değerlendiriyoruz.
rel="canonical"
bir yönlendirme olabilir mi?
Evet, standart URL olarak yönlendirme yapan bir URL belirtebilirsiniz. Google, yönlendirmeyi normal bir şekilde işler ve bunu dizine eklemeye çalışır.
Çelişkili
rel="canonical"
ifadeleri varsa ne olur?
Algoritmamız bu konuda esnektir: Standart URL zincirlerini takip edebiliriz ancak bağlantılarınızı, en iyi verimi alabilmek adına tek bir standart URL’i işaret edecek şekilde güncellemenizi öneririz.
Bu bağlantı etiketi, tamamıyla farklı bir alan adındaki bir standart URL'yi önermek için kullanılabilir mi?
Evet,
cross-domain (farklı alan adları arası) rel="canonical"
bağlantı öğesini destekliyoruz.
Bu standart URL yapısı diğer arama motorları tarafından da destekleniyor mu?
Evet,
Bing
ve
Yahoo!
bu yapıyı destekleyen diğer arama motorlarından bazıları.
Bu konuda daha detaylı bilgi almam mümkün mü?
Tabii ki. Daha fazla bilgi için lütfen
Standart URL'ler kullanma
hakkında hazırladığımız Yardım Merkezi makalemize bakın.
Pekala; canlı bir örnek görebilir miyim?
Evet, bu süreçte güvenilir bir test kullanıcısı olarak bize yardımcı olan
wikia.com
sitesine göz atabilirsiniz. Örneğin,
http://starwars.wikia.com/wiki/Nelvana_Limited
URL'sindeki kaynak kodun
rel="canonical"
değerini
http://starwars.wikia.com/wiki/Nelvana
şeklinde belirttiğini fark edeceksiniz. Bu örnekte verilen iki URL neredeyse birbirinin aynısıdır; ancak ilk Nelvana_Limited URL'sinde başlığının yakınında kısa bir mesaj vardır. Bu, bahsedilen Standart URL özelliğinin kullanımına iyi bir örnektir.
rel="canonical"
ile iki URL'nin özellikleri dizinimizde birleşir ve arama sonuçlarında, wikia.com'un hedeflenen sürümü görüntülenir.
Bunlara ek olarak, aşağıdaki yorum bölümü aracılığı ile diğer sorularınızı da çekinmeden bize iletebilirsiniz. Eğer herhangi bir sebeple standart URL yapısını uygulayamazsanız da sakın endişelenmeyin; biz yine de yinelenen içeriklerinize ait URL'ler içerisinden uygun olabilecek bir standart URL seçebilmek için önceden de olduğu gibi şimdi de elimizden geleni yapmaya devam edeceğiz.
Arama kalitesi ekibi adına yayınlayan:
Fatih Özkösemen
Not: Bu makale ilk olarak 12 Şubat 2009 tarihinde İngilizce Google Webmaster Bloğunda
Joachim Kupke
ve Maile Ohye tarafından
yayınlanmıştır
.
E-posta ile abone ol:
Hizmet sağlayıcı:
FeedBurner
RSS ile abone ol
Kayıtlar
Atom
Kayıtlar
Tüm Yorumlar
Atom
Tüm Yorumlar
Önceki Yayınlar
2020
Kas
Eyl
Ağu
Tem
Haz
May
Nis
Mar
Şub
2019
Kas
Eki
Eyl
2018
Tem
Şub
Oca
2017
Ara
Kas
Eyl
Ağu
Etiketler
amp
1
chrome
2
dizin
1
google analytics
1
google görseller
1
güvenlik
5
hız
2
kalite yönergeleri
3
kullanıcı deneyimi
4
mobil
3
search console
2
sıralama
2
tarama
1
yapısal veri
2
yardımcı araçlar
2
Türkçe Kaynaklar
Webmaster Portalı
Search Console Yardım Merkezi
YouTube Yayınları
Webmaster Forumu
İngilizce Kaynaklar
Google Developers for Search
Webmaster Portalı
Search Console Yardım Merkezi
YouTube Kanalı
Webmaster Forumu