SEO Çalışma Saatleri – 8 Ekim 2021

Bu, 8 Ekim 2021'de John Mueller ile Google SEO Çalışma Saatleri'nden alınan en ilginç soruların ve yanıtların bir özetidir .

Dizine eklenen sayfaların sayısı ve site otoritesi

03:52 “Yani geçmişte birkaç kez büyük sitelerin […] daha küçük sayfalara odaklanmasını önerdiniz […]. Şu anda üzerinde çalıştığım sitede, hiç trafik almayan, eski […] 1.000 sayfa var, bu yüzden onları kaldırmanızı öneriyorum. Ancak, geliştirici ekibimizin, Google'ın sitenizi dizine eklediği sayfaların sayısı arttıkça siteye daha fazla yetki atfettiği ve herhangi bir sayfayı kaldırma konusunda isteksiz olduğu izlenimi altında olduklarına dair bir soru var. Buna biraz ışık tutabilir misin?”

John'un dediği gibi, “Dizine eklenmiş daha fazla sayfanız varsa, web sitenizin daha iyi olduğunu düşünmemiz kesinlikle doğru değil. […] Bazen çok sayıda sayfanın dizine eklenmesi mantıklıdır. Bazen, bu şekilde dizine eklemek için yararlı sayfalardır. Ancak, dizine eklenen sayfaların sayısıyla ilgili bir kalite işareti değildir. Ve özellikle […] 1.000, 2.000, 5.000 sayfadan bahsediyorsanız, bu genel olarak sistemlerimiz için oldukça düşük bir sayı. Ve 5.000 sayfanın 1.000 sayfadan daha iyi olduğunu söyleyemeyiz. Bizim için her şey bir nevi küçük bir web sitesi gibi ve oradan çıkarabildiklerimizle yetiniyoruz. Ve elbette, küçük web sitesi görecelidir. Alakasız bir web sitesi olduğunu söylemek gibi değil. Küçük olabilir, ancak yine de çok yararlı olabilir […]”.

Bir web sitesinin birincil amacını değerlendirmek

10:03 “En son web sitesiyle ilgili bazı sorunlardan bahsetmiştik […] – bu, bilgi ve işlem öğelerine sahip olduğumuz bir e-ticaret sitesi. […] Tavsiyeniz, bu içeriği biraz işlem odaklı ve bilgi odaklı sayfalar olarak ayırmaktı. Bu yüzden bununla ilgili başka bir sorum var. Diyelim ki bir e-ticaret web siteniz varsa ve büyük bir blogunuz, bir derginiz veya bunun gibi bir sürü bilgi malzemeniz varsa, ancak bu eski bir bölüm. Öte yandan, tüm bu ürün sayfalarına, kategorilere vb. sahipsiniz. Öyleyse, saf bilgi içerikli bu büyük blok, tüm web sitesine bir tür bilgilendirici dokunuş veya karakter verir mi, böylece Google, oh, emin değiliz […] insanların bir şeyler satın almak yerine bilgi alabilecekleri bir şey mi, yoksa bu değerlendirme sayfa bazında mı yapılıyor?”

John şunları söyledi: “[…] Anladığım kadarıyla bu daha çok sayfa düzeyinde bir şey. […] Pek çok web sitesinde farklı içerik türlerinin bir karışımı bulunur. Ardından, bu sayfalardan hangisinin arama yapan kişinin amacına uygun olduğunu bulmaya ve bunları uygun şekilde sıralamaya çalışırsınız. […]

Demek istediğim, bunu haber sitelerinde sık sık görürsünüz. […] Son olaylara sahipler, ama aynı zamanda daha eski olaylar için bölümlere sahipler veya […] diğer büyük olaylar için izole edilmiş bir arşiv bölümlerine sahipler. Ve bunlar, gerçekten şu anda olan bir şey istiyorsanız veya bir tür bilgi araştırması, her zaman yeşil tip içerik istiyorsanız, çok farklı niyetlerdir.

[…] Sayfa bazında bakmamız gerekiyor ve ah, burası bir araştırma sitesi, çünkü burada araştırma içeriği var” demiyoruz.

Bağlantıların yeniden yönlendirilmesi

13:21 “İnsanların bizim, diyelim ki sayfa alt kategorimize […] bağlantı verdiğini görüyoruz. Ve sorun şu ki […] içeriğimiz gelir ve gider, bu da bazen bazı kategorilerde görünen daha fazla içerik olduğu anlamına gelir. Bazen içerik silinir. Ve böylece alt kategoriler oluşturulabilir ve aynı zamanda kaybolabilir. Ve artık var olmayan alt kategorilere bağlandıkları için geri bağlantılardan bir sürü yönlendirme görüyoruz. Buradaki sorum şu: Bu bağlantıları ana kategoriye yönlendirmek uygun mu? Ve eğer yaparsak, bunu nasıl yaparız – örneğin 302 ile? Geçici bir yönlendirme gibi, çünkü gelecekte bu alt kategori tekrar içerikle doldurulabilir, […] bu kalıcı bir yönlendirme değil”.

John yanıtladı: "Yani, ebeveyn düzeyine yönlendirdiğiniz daha büyük bir ölçekte bunun gerçekleştiğini görürsek, muhtemelen bunu yumuşak bir 404 olarak görürüz. […] Ve 404 kodu yerine, yeniden yönlendiriyorsunuz ve belki de bu kullanıcılar için daha iyi, ama biz onu 404 olarak görüyoruz. [...] Eğer yönlendirmek kullanıcı açısından mantıklıysa, o zaman bunu tercih ederim.

[…] 301 veya 302 ile ilgili olarak, orada önemli olduğunu düşünmüyorum, çünkü bunu ya yumuşak bir 404 olarak görürdük ya da bir kurallılaştırma sorusu olarak görürdük. Yumuşak bir 404 ise, kodun önemi yoktur. Bu bir kurallılaştırma sorusuysa, arama sonuçlarında hangi URL'yi gösterdiğimize bağlıdır. Ve genellikle, daha yüksek seviyeli olanın daha güçlü sinyalleri olacaktır ve biz daha yüksek seviyeli olana odaklanacağız. Yani bu durumda bunun 301 veya 302 olması önemli değil.

[…] Bunu bir soft 404 olarak görürsek […] o belirli URL'nin taranmasını yavaşlatırdık çünkü burada hiçbir şey yok […]. Bunu bir yönlendirme olarak görürsek […], birincil URL'ye odaklandığımız için bunu her gün taramamız gerekmez. Bence bu iki durumda da, bize yeni sinyaller gelene kadar bu URL'nin taranmasını yavaşlatırız, aslında, bu belki de yeniden yeni bir şey. […] Bu, dahili bağlantı veya site haritası dosyası […] gibi olurdu. Ve bu, yeniden emeklememiz için daha güçlü bir işaret olurdu. Ama bence bu durumların hepsinde emeklemenin yavaşlaması benzer olacaktır.

[…] Site haritalarının tek başına [güncellenmesinin] muhtemelen yeterli olmadığını düşünüyorum. İç bağlantının da net olduğundan gerçekten emin olurdum ”.

Çekirdek güncellemelerden kurtarma

18:34 “Yaklaşık bir yıl önce trafikte önemli bir düşüş gördük. Denetimden sonra […] tüm sinyaller sitenin site kalitesi sorunları yaşadığını gösteriyordu. Bu yıl şubat ayına kadar bu sorunları çözebildik. Haziran çekirdek güncellemesiyle birlikte bazı artışlar gördük. Ama yine de yaklaşık bir yıl önceki düşüşten önceki seviyede değil. Öyleyse sorum şu, site kalitesi sorunları, eğer durum buysa, bu beklediğimiz bir iyileşme mi, yoksa tanımlanan tüm sorunları ele aldığımızı düşünürsek daha fazla iyileşme bekleyebilir miyiz […]?”

John şunları söyledi: “[…] Bunu, bir şeyi düzeltmeniz gereken bir durum olarak değerlendirecek kadar değil. Ama bunun yerine […] web sitenizin alaka düzeyini artırmaya çalışırsanız, o zaman […] daha iyi bir web siteniz olur. Yani […] önceki durumuna geri çevireceğiz değil. […] Daha öncekiyle aynı veya karşılaştırılabilir değil, bu nedenle önceki durumuna değişmesini beklemek biraz zor olabilir [...].

[…] Temel güncellemelerle, yalnızca bireysel konulara değil, web sitesinin genel olarak alaka düzeyine odaklanıyoruz . Bu, kullanılabilirlik ve bir sayfadaki reklamlar gibi şeyleri içerebilir , ancak esasen genel olarak web sitesidir. Ve genellikle, bu aynı zamanda içeriğin odak noktası, bir şeyleri sunma şekliniz, kullanıcılara içeriğin arkasında ne olduğunu, kaynakların neler olduğu gibi netleştirme şekliniz anlamına gelir [...] . Google'ın web sitenizi çok daha iyi bir şey olarak görmesini gerçekten istiyorsanız, muhtemelen içerik tarafında da çalışmanız gerekir .

[…] Düşük kaliteli içeriğin nerede olabileceğini, kullanıcıların web siteme gittiklerinde nerede kafalarının karışabileceğini düşünün. Ve bu karışıklık, UX değişiklikleriyle teknik sorunlarla çözebileceğimiz bir şey mi? Yoksa sunduğumuz içeriğin bir kısmını gerçekten değiştirmek zorunda mıyız?”

Konuk gönderilerindeki bağlantılar

28:24 “[…] Eğer [bir web sitesinde] bir misafir gönderisi varsa ve Google bunun ödenip ödenmediğini bilmiyorsa, Google bu bağlantıyı almaları veya yakmaları gerektiğini nasıl belirleyecek? Tüm açılardan güvende olmamız için cevap nedir?”

John'a göre, “[…] Bağlantılar ve misafir gönderileri için rehberliğimiz, bunların takip edilmemesi gerektiğidir . […] Bilinirliği artırmak için bağlantıların izlenmediğinden emin olmak için gerçekten dikkat ederdim, yaptığınız şey hakkında konuşuyorsunuz, bunu kullanıcılar sizin sayfanıza gidebilsin diye yapıyorsunuz. sayfa. Ama aslında, bu işletmeniz için bir reklamdır. Bu bakış açısından, onları takip etmemelerini sağlardım”.

Bir sıralama faktörü olarak ürün fiyatı

32:25 “Tam olarak aynı ürünü satan iki rakip e-ticaret sitesi varsa – bir web sitesi ürünü 500$'dan, diğeri 100$'dan sunuyorsa, tüm SEO sinyalleri eşittir. Aynı ürün için bu kadar fiyat farkı olduğu için daha ucuz web sitesinin sıralama şansı daha mı yüksek olur?”.

John şunları söyledi: “Yani tamamen web araması açısından, hayır. Bir sayfada bir fiyatı tanımaya çalışmamız ve bunu bir sıralama faktörü olarak kullanmamız söz konusu değildir. Dolayısıyla, ucuz olanı alıp daha üst sıralarda yer alacağız diyeceğimiz bir durum değil […].

Bununla birlikte, bu ürünlerin çoğu aynı zamanda ürün arama sonuçlarında da yer alır; bunun nedeni, bir besleme göndermeniz veya bu sayfalardaki ürün bilgilerini tanımamız olabilir. Ve ürün arama sonuçları, nasıl sıralandıklarını bilmiyorum. Fiyatı hesaba katmaları veya müsaitlik durumu gibi şeyler olabilir […].

Web araması açısından, fiyatı hesaba katmıyoruz. Ürün arama açısından bu mümkün . Ve bence zor olan kısım, bir SEO olarak, aramanın bu farklı yönlerinin genellikle tek bir arama sonuçları sayfasında birleştirilmesidir, burada normal web sonuçlarını görürsünüz ve belki yanda bazı ürün sonuçları görürsünüz, ya da belki bunun bir karışımını göreceksiniz […]”.

URL'leri site haritaları arasında taşıma

34:04 “200 site haritası dosyamız varsa ve URL'lerin %20 ila %30'u her hafta bir dosyadan diğerine atlıyorsa, bu ne kadar kötü olabilir? Yoksa URL'lerimizi kesinlikle sonsuza kadar aynı dosyada mı tutmalıyız?"

“[…] Önerimiz genellikle aynı URL'yi aynı site haritası dosyasında tutmaktır . Bunun temel nedeni site haritası dosyalarını farklı oranlarda işlememizdir. Dolayısıyla, bir URL'yi bir site haritası dosyasından diğerine taşırsanız, sistemlerimizde birden fazla site haritası dosyasından aynı URL'ye sahip olabiliriz. Ve bu tek URL için farklı bilgileriniz varsa – örneğin farklı değişiklik tarihleri ​​gibi – o zaman gerçekte hangi özelliği kullanacağımızı bilemeyiz.

Bu açıdan, eğer her zaman aynı site haritası dosyasında bulunuyorsa, o zaman bizim için, oh, bu URL için bilgiye sahibiz ve bu bilgiye güvenebiliriz, çünkü sadece oradadır, demek bizim için çok daha kolaydır. Bu, URL'lerin rastgele karıştırılmasından […] kaçınmaya çalıştığım bir şey. Ancak aynı zamanda, genellikle site haritası dosyanızın işlenmesini bozmaz. Ve kesinlikle web sitenizde bir sıralama etkisi olmayacak. Yani site haritası sistemimizde bir web sitesinin kalitesiyle ilgili bu tür bir harita yok ”.

Çok bölgeli içerik

38:13 “Ben haber sektöründe çalışıyorum. Ekibim uluslararası varlığımızı genişletmek istiyor ve çok bölgeli alt dizinler oluşturmak için çalışmalar yaptı. Çoğunlukla, farklı çok bölgeli baskılardaki sayfalar aynı görünecek. Politika veya yaşam tarzı gibi ana sayfa ve bölüm sayfaları, bölgeye özgü birkaç parça dışında benzer içeriğe sahip olacaktır.

Makaleler sıkıntılı. İlgili bağlantılara sahip modüller dışında çok bölgeli alt dizinler arasında ayırt edebileceğimiz pek bir şey yok, bu da bizi yinelenen içerik sorunları konusunda endişelendiriyor. Google, haber alanında yinelenen içeriği nasıl ele alıyor? […] İçerik aynı kalır, ancak şablonun öğeleri farklıdır. Tüm çok bölgeli web sitelerinde yalnızca bir standart mı olmalı?”

John'un yanıtı şuydu: “[…] Görünüşe göre bunlar aynı ülke içindeki farklı bölgeler ve aynı dil içeriği. […] Bunlar farklı ülkelerse, bu diller farklıysa rol oynayan coğrafi hedefleme özelliğine sahipsiniz. Yani, diyelim ki Avrupa'da çalışıyorsanız ve Almanya'yı, Fransa'yı ve İtalya'yı veya başka bir şeyi kapsıyorsanız, o zaman farklı dilleriniz de var demektir.

[…] Ama aynı ülke içinde, aynı dil içeriğinden bahsediyorsanız, o zaman […] biraz daha kolay çünkü tüm bu teknik bağlantılar için endişelenmenize gerek yok. Ancak öte yandan, yinelenen içerik sorunları çok daha görünür. Yinelenen içerik söz konusu olduğunda, bunun gibi sitelerin zor yanı, aslında kendinizle rekabet etmenizdir. Beş veya altı farklı bölgesel web sitesinde yayınladığınız bir haber makaleniz varsa, bu farklı bölgesel web sitelerinin tümü tam olarak aynı makaleyi sıralamaya çalışır. Ve bu, o makalenin başka türlü olabileceği kadar iyi sıralama yapmamasına neden olabilir.

Bu nedenle, bu makaleler için standart URL'ler bulmaya çalışmanızı tavsiye ederim, böylece gerçekten 'peki, bu bir makalem beş bölgesel web sitemde var, ancak bu benim tercih ettiğim sürüm, görmek istediğim sürümdür. Ara'. Ve sonra tüm enerjimizi, tüm sinyallerimizi o tercih edilen versiyon üzerinde yoğunlaştırabiliriz ve onu biraz daha iyi sıralamaya çalışabiliriz. Sürekli aynı sürüm olmak zorunda değil. Bu nedenle, bir bölge içindeki bir haber makaleniz kesinlikle standart olabilir, farklı bir haber makaleniz başka bir bölge için daha standart olabilir. Kanonik olarak hangi bölgeyi seçeceğiniz tamamen size kalmış. […] Genellikle, bunun en alakalı olduğu yeri bulmaya çalışır ve bunu standart sürüm olarak seçersiniz. Yani bu bireysel makaleler için.

Kategoriler, bölümler ve ana sayfalar için, içeriğin daha benzersiz ve bireysel bölgelere daha özgü olduğu bir şey olacak gibi görünüyor. Ve bu nedenle, bu indeks seviyesini ayrı tutmaya çalışırdım. Dolayısıyla, beş farklı bölgesel web siteniz, ana sayfanız, kategori bölümleriniz varsa, hepsi ayrı ayrı dizine eklenir. Ve haber makalelerinin kendileri bu farklı bölgelerden birine eşlenecekti. Yani orada önerdiğimiz yaklaşım bu tür […].

Ve bu yaklaşım aynı zamanda […] farklı alan adlarında da çalışır. Dolayısıyla, tek tek bölgeler için farklı alan adınız varsa, ancak bunların tümü aynı haber grubunun bir parçasıysa, bu standart geçişi farklı sürümler arasında yine de yapabilirsiniz. Bunu alt dizinlerle aynı etki alanı içinde yapıyorsanız, bu da sorun değil”.

Site taşımada yönlendirme

44:34 “Tüm URL'leri yeni bir URL kümesine 301 yönlendirmeniz gerektiğinde atılacak en iyi yol nedir? Sayfa sayısı bir milyonun üzerinde olacak ve sandbox etkisini en aza indirmek mi istiyorsunuz? Bir sandbox etkisi varsa, ne kadar sürebilir? Asla kurtaramayacağımız sıralamayı kaybeder miyiz? Bire bir yönlendirme yapmayı planlıyoruz ve toplu yönlendirmeler talep etmiştik, ancak bu bir olasılık değil, bu nedenle sayfalar, resimler, URL'ler vb.'nin aynı anda çevrilmesi gerekecek”.

John'un dediği gibi: "Bana göre bu, geleneksel bir site taşıma durumu gibi görünüyor. Bir etki alanından diğerine geçiyorsunuz ve eski sitenizdeki tüm URL'leri yeni bir siteye yönlendiriyorsunuz ve bununla bizim ilgilenmemiz gerekiyor […]. Site taşıma söz konusu olduğunda bizim tarafımızda sandbox etkisi olarak tanımlanan bir şey kesinlikle yoktur . Bu nedenle, bir site taşımanız gerekiyorsa, bir site taşıma işlemi yapın ve tüm sayfalarınızı yeniden yönlendirin. Genellikle en kolay yaklaşım, tüm sayfaları bir kerede yeniden yönlendirmektir. Sistemlerimiz de bunu fark etmeye çalışmak için biraz buna ayarlanmıştır. Bu nedenle , bir web sitesinin tüm sayfaları farklı bir web sitesine yönlendirmeye başladığını gördüğümüzde, site hareketini olabildiğince çabuk işleyebilmek için bunu biraz daha hızlı yeniden işlemeye çalışacağız. Ve kesinlikle ah, site taşıma yapıyorlar, bu yüzden işleri yavaşlatacağız diyeceğimiz gibi değil […]”.

API ve tarama bütçesi

46:13 “Veri almak için istemci tarafında API'lere bağlanan bir web sitem var. Bu URL'ler tarama bütçesine dahil ediliyor mu? Bu URL'lere izin vermezseniz, bu herhangi bir sorun yaratır mı?"

“[…] Bir sayfa oluşturulduğunda bu API'ler dahil edilirse, evet, taramaya dahil edilirler ve esasen sayfayı oluşturmak için bu URL'leri taramamız gerektiğinden tarama bütçenize dahil edilirler. Oluşturma sırasında taranmamalarını veya kullanılmamalarını tercih ederseniz bunları robots.txt dosyasıyla engelleyebilirsiniz. Bunu yapmayı tercih ederseniz tamamen size kalmış. Özellikle bakımı maliyetli veya çok fazla kaynak gerektiren bir API'niz varsa, bazen bu mantıklı olur.

İşin zor yanı, API uç noktanızın taranmasına izin vermezseniz, indeksleme için API getirileri hakkında herhangi bir veri kullanamayacağımızdır. Bu nedenle, sayfanızın içeriği tamamen API'den geliyorsa ve API'nin taranmasına izin vermiyorsanız, bu kişiyle iletişime geçemeyiz. […] API sadece sayfaya ek bir şey yapıyorsa, örneğin bir harita veya […] bir sayfada sahip olduğunuz sayısal bir tablonun grafiğini çiziyorsa, […] indekslemeye dahil değildir. Diğer bir şey de, bazen, API engellendiğinde bir sayfanın nasıl çalıştığı önemsizdir. Özellikle JavaScript kullanıyorsanız ve API çağrıları robots.txt nedeniyle engelleniyorsa, bu istisnayı bir şekilde halletmeniz gerekir. JavaScript'i sayfaya nasıl yerleştirdiğinize, API ile ne yaptığınıza bağlı olarak, hala çalıştığından emin olmanız gerekir. Dolayısıyla, bu API çağrısı işe yaramazsa ve ardından sayfanın geri kalanının oluşturulması tamamen bozulursa, oluşturulacak hiçbir şey kalmadığından çok fazla dizine ekleyemeyiz.

Ancak, API çağrısı bozulursa ve sayfanızın geri kalanını dizine eklemeye devam edersek, bu tamamen iyi olabilir. […] Başkaları için bir API çalıştırmanın daha zor olduğunu düşünüyorum, çünkü o zaman taramaya izin vermezseniz, bir başkasının web sitesinin sizin API'nize bağımlı olabileceği gibi ikinci dereceden bir etkiye sahip olursunuz. API'nizin ne yaptığına bağlı olarak, birdenbire web sitelerinde dizine eklenebilir içerik yoktur. Ve fark etmeyebilirler bile çünkü farkında değiller, oraya birden bir izin vermeme eklemişsin. Bu da benzer dolaylı etkilere neden olabilir […]”.

JavaScript ve Google önbelleği

49:36 “Yani aynı alandan gelen iki sayfa var. URL, aynı dizin yapısının bir parçası olan biraz farklıdır. Ve […] NextJS tarafından üretilirler. Yani NextJS, sunucu tarafında oluşturulmuş bir tepki çerçevesidir. Ve dizine ekleniyorlar, ancak Google önbelleğinde bir sayfa görüyorum ve ikinci sayfa Google önbelleğinde değil. Ve sayfayı nasıl oluşturduğuma bakılmaksızın aynı kalıbı görüyorum […]. Sayfalarımın çoğu Google önbelleğinde, ancak şimdi endişeliyim çünkü şu anda tüm bu sayfaları oluşturan Java tabanlı teknoloji yığınımdan Google NextJS'ye geçiyorum. […] Hata ayıklarken, bunun kullandığımız eski Java yığınında da bir sorun olduğunu gördüm.

Yani soru iki kısımdır. Temel olarak, neden bu davranış? İkincisi, bu davranış sıralamamı etkiler mi? Google önbelleğinde olmayan arama sonuçlarında görünen o sayfaları görüyorum”.

John yanıtladı: “[…] Önbellek sayfaları, indekslediklerimizden tamamen ayrıdır. Yani önbellek sayfası olup olmaması, sıralama için hiç önemli değil, indeksleme için hiç önemli değil . Bazen önbellek sayfamızın olmamasının teknik nedenleri olabilir. Bazen, tek tek URL'ler için bir önbellek sayfamız olmayabilir. Diğer bir şey ise, sayfa bir JavaScript çerçevesi kullanıyorsa, bu durumda JavaScript'in bir önbellek sayfasında çalışıp çalışmadığı bazen zor olabilir, çünkü önbellek sayfası bir Google etki alanında barındırılır. Ne tür bir JavaScript'e sahip olduğunuza ve JavaScript dosyalarını nereden aldığına bağlı olarak, JavaScript bazen Google etki alanında çalışamaz.

[…] Önbellek sayfası işlenen sayfa değil. Esasen sadece istediğimiz HTML dosyası ve bunun bir kopyası. Ve HTML dosyası bir şey gösteriyorsa, sorun değil. JavaScript kullanıyorsa ve JavaScript bir önbellek sayfası olduğu için çalışmıyorsa, bu aynı derecede iyidir. Sadece önbellek sayfasında görmüyorsunuz. Yani önbellek sayfası görünmüyorsa, bunun için endişelenmezdim. Bu herhangi bir sorunun işareti değil. Ve çoğu zaman, bir önbellek sayfası olup olmadığını kontrol edemezsiniz. Bunu görmezden gelirdim” dedi.

https://www.youtube.com/watch?v=Vd0rEQrwHDc