5 Mart 2019 – Google Help Hangout Notları

Bu Web Yöneticisi Yardım Hangout'unda John Mueller'e evinde eşlik ediyoruz. Sayfa Hızı, hreflang ve Geri Bağlantılar hakkında bazı harika sorularımız vardı. Video ve tam bir transkripsiyon yaz tatilimizin ardından bulunabilir. Bunu beğendiyseniz, haftalık bültenimize kaydolmayı düşünün! Haftanın en iyi SEO makalelerini kolay sindirilebilir parçalar halinde özetliyoruz.

Bir etiket yöneticisi aracılığıyla json - ld kullanma sorununu açıklayabilir misiniz ?

11:18

Bu yüzden, konuştuğumuz şeyin oldukça fazla olduğunu ve bu hangout'ların da bir sürü olduğunu düşünüyorum ve Barry de dahil olmak üzere çeşitli insanlardan bu konuda yazılmış yeni blog yazıları var. Ancak bu esasen geri dönüyor, bizim için etiket yöneticisinden içerik çekebilmemiz, JavaScript sürecini etiket yöneticisinden komut dosyası dosyalarını oluşturabilmemiz ve oradaki yazının çıktısını alabilmemiz ve indeksleme tarafını dahil edebilmemiz gerektiği anlamına geliyor. Bu, sistemlerimiz için her zaman çok fazla çalışma gerektiren bir şey ve her zaman tüm sayfalar için yaptığımız bir şey değil, özellikle sayfanın aksi halde aynı olacağını gördüğümüzde, sistemlerimizin bunu haklı çıkarması biraz zor. tüm bu JavaScript'i de işlememiz gerekiyor. Üstelik test araçlarının çoğu, etiket yöneticisini ve çıktısını işlemezler, bu nedenle araçların bu işaretlemenin düzgün çalıştığını doğrulaması gerçekten zordur. Aramada işlenmesi daha uzun sürer, biraz lapa lapa olabilir ve herhangi bir zamanda tam olarak ne indekslendiğini tam olarak bilmiyorsunuz. Yani bunlar, benim bakış açıma göre etiket yöneticisini başka herhangi bir şey için kullanmamın nedenlerinin hepsi. Arama için yapılandırılmış veriler için JsonLD için de bunun için kullanmak iyidir, ancak bunun özellikle aramadaki yapılandırılmış veriler için harika bir yaklaşım olmadığını akılda tutmakta fayda var. Yapı verilerini doğrudan web sayfasında sağlamanın çok daha basit yolları, bakımı kolaylaştırır ve tüm bunları test etmek için izlemeyi kolaylaştırır. Yani bunu yapmanızı tavsiye ederim, bunun için etiket yöneticisini burada kullanamazsınız demiyorum, kesinlikle kullanabilirsiniz ve onu alıp kullanmak için elimizden gelenin en iyisini yapacağız ve bunun gibi ama tam olarak değil aynı düzeyde hız ve esneklik, yapı verilerinin doğrudan sayfalarda sağlanması söz konusu olduğunda güvenlik.

Özet: Google Etiket Yöneticisi aracılığıyla JSON-LD ve diğer yapılandırılmış verileri kullanmak mümkün olsa da, bu en iyi yaklaşım değildir. Google'ın içerik formunu Etiket Yöneticisi çekmesi ve JavaScript'i oluşturması gerekir. Komut dosyasını Etiket Yöneticisinden işleyin ve yazının çıktısını alın ve ardından dizin. Yapılandırılmış verileri doğrudan sayfada sağlamanın, Google'da işleri kolaylaştıran basit yolları vardır.

Google, Arama'da gösterilecek bir URL'yi nasıl seçer?

15:20

Bu, Google'ın aramada göstermek için bir URL'yi nasıl seçtiğine ilişkin genel soruya girer ve bir yandan bu durumda, tüm sayfayı görüntülemek için rel kanonik bir ayara sahip olan 1. resim için açılış sayfası gibi bir yönü vardır. bu sayfaların eşdeğer olmadığı anlamına gelir. Bu yüzden, bu kurallı olanı alıp kullanacağımız bir tür isabet ya da ıskalama, bence akılda tutulması gereken bir yön bu. Akılda tutulması gereken diğer bir şey de, bu sayfaların eşdeğer olarak görülebileceğini anladığımızda bile, bu sayfalardan hangisinin gerçek standart olduğunu belirlemek için birden fazla faktör kullanmamız gerektiğidir. Bunun için bir rel canonical kullanıyoruz, bir şeyimiz varsa yönlendirmeleri kullanıyoruz. Dahili harici bağlantılar kullanıyoruz, site haritaları, hreflang bağlantıları gibi şeyler kullanıyoruz, bunların tümü, bu URL'lerden hangisini göstermemiz gerektiğini anlamamıza yardımcı oldu ve belirttiğiniz kurallı URL'nin geri kalanında asla kullanmadığınız bir URL olup olmadığını anlamamıza yardımcı oldu. Web siteniz için, o zaman, bu bağlantıyı standart hale getirmenin bir hata olduğunu, web yöneticisinin aslında böyle demek istemediğini ve belki de standart olarak farklı bir URL seçmemiz gerektiğini söyleyebiliriz. Tahminimce burada olacak şey, ya rel canonical'i görmezden geleceğiz çünkü bunlar aynı şey değiller ya da bunun yerine mevcut diğer sayfalardan birini seçeceğiz çünkü bu, içinde güçlü bir şekilde bağlantılı olan sayfalardan biri. internet sitesi. Bu nedenle, bu özel kurulumun sizin durumunuzda o kadar yararlı olacağını düşünmüyorum.

Özet: Google , Google'ın göstermesi gereken URL'yi anlamak için rel canonical, yönlendirmeler, dahili bağlantı, site haritaları, hreflang kullanır. Ancak belirtilen kurallı URL sitenizin geri kalanında hiç kullanılmayan bir URL ise, Google kurallı kuralı yok sayabilir ve dahili olarak yoğun şekilde bağlantılı başka bir sayfa seçebilir.

Blog gönderilerine genel bir editör kullanıcısı yerine yazarları dahil etmek iyi bir fikir mi?

17:38

Özellikle makaleyi orijinal olarak kimin yazdığını biliyorsanız ve ona bir yazar açılış sayfası gibi davranabiliyorsanız, bunun iyi bir hamle olduğunu düşünüyorum. Sadece saf bir kullanıcı bakış açısından bile, birisi web sitenize giderse ve aniden bu makalelerin sadece editör yerine Barry tarafından yazıldığını görürse ve o yazar için bir açılış sayfanız varsa, o zaman bu onun için daha iyi olduğunun bir işareti olabilir. Kullanıcıların anlayabileceği veya yazarın açılış sayfasına gittikleri ve oh bu yazar aslında bu alanda uzman ve birkaç yıldır orada aktif olduğunu gördükleri bir kullanıcı olabilir. geneldir ve Google sıralamasıyla ilgili olarak, bunun herhangi bir doğrudan etkisi olup olmayacağını söylemek zor. Ancak en azından dolaylı etkiler, kullanıcıların içeriğinize daha çok önerildiği gibi güvenebilecekleri veya bunun beklenen bir şey olduğunu düşünüyorum.

Özet: Evet! Bir yazar açılış sayfasına sahip olmak, yazarlarınızın EAT'sini göstermenin bir yoludur. Ayrıca, genel bir "Editör" veya "Yönetici" yerine genel olarak kullanıcı deneyimini iyileştirecektir.

Kullanıcı arayüzünüz diğer dillere çevrilebiliyorsa ancak kullanıcı tarafından oluşturulan içerik gibi ek içerik başka bir dilde kalıyorsa öneri nedir?

21:48

Bu, özellikle kullanıcı tarafından oluşturulan içerik için oldukça fazla olan bir şey. Yani bir forumunuz veya blogunuz veya başka bir şeyiniz varsa ve insanlar bir dilde yorum yapıyorsa, ancak kullanıcı arayüzünün diğer dillere değişebilmesi için kurulumunuz var. Ardından, kullanıcı arayüzünün Fransızca veya Almanca olabileceği, ancak örneğin herkesin İspanyolca yorum yapması nedeniyle içeriğin yine de İspanyolca olabileceği ve bu aslında birçok şekilde ele alabileceğiniz bir durum olduğu bir durumla karşılaşırsınız. Yani benim standart versiyonumun İspanyolca versiyonu olduğunu ve her şeyin tıpkı İspanyolca versiyonu gibi olduğunu söyleyebilirsiniz, bu da yapabileceğiniz bir seçenek. Bu sürümler arasında hreflang ek açıklamalarını kullanabilirsiniz, bunun içeriğimin en Fransızca sürümü olduğunu, ana içeriğin Fransızca olmadığını, ancak kullanıcı arayüzünün Fransızca olduğunu, böylece sayfayı ziyaret eden kullanıcının etrafta gezinebileceğini söyleyebilirsiniz. web sitem, yapabileceğiniz bir şey. Ve esasen bunlar, tercihlerinizin ne olacağı hakkında bize biraz daha bilgi vermek için sağlayabileceğiniz farklı varyasyonlardır. Pratik bir bakış açısından, aramada nasıl görünmek istediğinizle ilgili olarak nihayetinde size kalmış. Bu nedenle, bir Fransız kullanıcının sitenize gelip içeriğin İspanyolca ve kullanıcı arayüzünün Fransızca olduğu sayfaya gelmesinin ve sonra elbette bu sürümler arasında hreflang ek açıklamalarını kullanmanın yararlı olduğunu düşünüyorsanız. Fransa'daki bir kullanıcının, ana içerik İspanyolca olsa bile, kullanıcı arayüzü Fransızca olsa bile sitenizde gezinmede sorun yaşayacağını düşünüyorsanız, o zaman belki de İspanyolca sürümünü, İspanyolca kullanıcı arayüzü ile dizine eklenmiş halde tutmak mantıklı olabilir. Bu, sonuçta size kalmış, bence bunların hiçbiri mükemmel çözümler değil. Bazen, içeriğinizin ne kadar tekdüze olduğu, hangi dil sürümlerini dizine eklemek istediğinizi ve kullanıcıların arama sonuçlarında hangi sürümleri görmeyi beklediğini ne kadar net anladığınıza bağlıdır. Örneğin, çok uluslararası bir forumsanız ve insanlar her türden farklı dilde gönderiler yayınlıyorsa, yalnızca bu UI sürümünün dizine eklenmesini istediğinizi söylemek muhtemelen zor olabilir, belki de tüm UI sürümlerinin dizine eklenmesi mantıklı olabilir. Elbette tüm UI sürümlerinin dizine eklenmesinin dezavantajı, sitenizin birdenbire sahip olduğu url'lerinizin sayısını çarpmasıdır. Bu, çok daha fazla taramamız gerektiği anlamına gelir ve bu, taramamız gerektiği anlamına gelen, kullanıcı tarafından oluşturulan büyük bir içerik sitesiyse, bir yandan kullanıcı tarafından oluşturulan içeriğin tümü ve ardından her biri için bunun katlarını taramamız gerekir. yararlı olup olmadığını bilmediğim bir dil sürümü, eğer web siteniz için çok fazla tarama yapıyorsa, bu, daha yeni içeriğin arama sonuçlarında hızlı bir şekilde görünmesini engelliyorsa. Orada ağırlığını koyacak başka bir şey var. Sadece birkaç bin makaleden bahsediyorsanız, belki bu daha az sorun yaratır.

Özet: Standart sürüm olarak bir dil sürümünü seçebilir veya bu dil sürümleri arasına hreflang ek açıklamaları ekleyebilirsiniz.

Siteme bağlanan çok sayıda rastgele url'yi reddetmeli miyim?

27:58

Hayır, bu esasen yapılacak doğru hareket ve özellikle de gerçekten endişelendiğiniz bir şeyse. Bu yüzden, çoğu web sitesi için oraya gidip şüpheli ve tuhaf şeyleri reddetmenin mantıklı olmadığını düşünüyorum çünkü çoğunlukla bunları görmezden geliyoruz. Bu nedenle, özellikle bağlantılarla ilgili olarak, baktığınız zaman iyi dediğiniz bir şeyse, bu bağlantıların bizim tarafımızdan satın alındığı, doğal olarak bizim tarafımızdan oraya yerleştirildiği gibi, web sitesi ekibinden biri bir şey alacaksa, bu görülebilir. buna manuel olarak bakın ve bunun bizim aptalca bir şey yaptığımızı varsayarlar, bu, muhtemelen onları reddetmenin veya kaldırmanın doğru hareket olacağını söylediğim türden bir şeydir, ancak aksi takdirde bu sadece şüpheli bir bağlantıysa ve Görünüşe göre orada milyonlarca başka bağlantı var gibi biri bir aracı çalıştırdı ve bu foruma tonlarca bağlantı bıraktı, o zaman bu bizim algoritmalarımızın zaten çözdüğü bir şey. Yani bu endişe etmeyeceğim bir şey değil.

Özet: Google, hangi bağlantıların yok sayılacağını bulmakta iyidir. Ancak konu reddetmeye geldiğinde üzgün olmaktansa güvende olmak daha iyidir.

Sayfa hızı Google için ne kadar önemli?

42:30

Mevcut politika nedir? Yani hız bizim için biraz önemli bir şey ve kullanıcılar üzerinde büyük bir etkisi var, bu yüzden kişisel olarak oldukça ciddiye alacağım bir şey ve bence hızın güzel yanı, size oldukça nesnel önlemler veren çeşitli araçlar var. aslında üzerinde çalışabileceğiniz. Birçoğumuz veya SEO ile ilgili diğer konularla ilgili olarak, içeriklerinin kalitesini bilmiyorum, bu hız gibi şeyler oldukça ölçülebilir ve üzerinde çalışabileceğiniz bir şeydir ve aynı zamanda olmalıdır. Web sitenizdeki kullanıcı davranışınızdan doğrudan bir etki olarak kullandığımız bir şey. Yani bu sadece Google'ın bakış açısından, hızın önemli olduğunu söylediğimiz bir şey değil, aynı zamanda kullanıcılar web sitenize geldiğinde doğrudan göreceğiniz bir şey ve web sitenizin aniden bu kullanıcıları yüklemesi birkaç saniye daha uzun sürüyor. web sitenizde oldukça farklı tepkiler verecek ve web sitenizde müşterileri nasıl tanımlarsanız tanımlayın onları müşteriye dönüştürmekte daha fazla sorun yaşayacaksınız.

Özet: Google söz konusu olduğunda hız son derece önemlidir. Kolayca izlenebilir ve kolayca uygulanabilir bir metriktir. Sitenizin nasıl performans gösterdiği ve sayfa hızını artırmaya yardımcı olmak için neler yapabileceğiniz konusunda harika bilgiler veren harika araçlar var.

Google Ads için ödeme yaparsam sıralamam daha mı iyi olur yoksa daha mı kötü?

47:24

Arada sırada bu soruyu alıyoruz ve buradaki soru şu, sıralamam etkilenecek mi, ancak daha iyi veya en kötü yanı, bazı kişilerin de söylediğini duyduğumuz bir şey, Google Ads'ü kullanırsanız sıralamanız daha iyi olmayacak. Bazı insanlar, daha fazla reklam satın almanızı istediğimiz için Google reklamlarını kullanırsanız sıralamanızın düşeceğini söylüyor ve bunların hiçbiri doğru değil. Bu nedenle, arama sonuçlarımız Google Ads kullanıp kullanmadığınız konusunda tamamen bağımsızdır ve web sitenizde kullandığınız teknolojilerden tamamen bağımsızdır. Dolayısıyla, analitik gibi bir şey kullanıyorsanız veya tamamen size kalmış başka bir izleme aracı kullanıyorsanız. Adsense veya bu diğer reklam ağlarından herhangi biriyle para kazanmanız tamamen size kalmış. Dolayısıyla web siteniz içerisinde Google ürünlerini kullanıp kullanmamak, web siteniz için diğer Google hizmetlerini kullanıp kullanmamak tamamen size kalmış. Bu, bu hizmetlerin kendi başına ayakta durmasını tercih ettiğimiz bir şey ve bunu belirli bir nedenle Google hizmetinin harika olmadığını söylüyorsanız, onu kullanmak istemiyorum, o zaman başka bir şey kullanmaktan çekinmeyin. Sizi, web sitenize odaklanmak ve kullanıcılarınız için doğru olduğunu düşündüğünüz şeyi yapmak ve bu belirli ürünü kullanmak arasında sıkışıp kaldığınız bir kutuya koymak istemiyoruz. Bu nedenle, gerçekten bunları birbirine bağlamıyoruz ve bunu açıkça yapıyoruz ve bu şeylerin iyi çalıştığından emin olmak için çok çalışıyoruz.

Özet: Google Ads'ün organik sıralamalar üzerinde hiçbir etkisi yoktur.

Bunun gibi şeylerden hoşlanıyorsanız, bültenimi seveceksiniz!

Ekibim ve ben her hafta en son Google algoritma güncellemeleri, haberler ve SEO ipuçları hakkında rapor veriyoruz.

Tam Video ve Transkript

Soru 1:14 - İki hafta önce web sitemiz bir gecede Google trafiğinin %94'ünü kaybetti. Son 20 yıldır tutarlı arama trafiği ve büyük bir değişiklik olmaması nedeniyle, bulut faresi gibi bir CDN aracılığıyla IPS veya SSL'yi paylaşan teknik bir şeyin trafikte algoritmik olarak büyük bir düşüşe neden olabileceğini varsayıyoruz. Daha derine indik ve aynı IP üzerinde son derece riskli görünen bazı siteler bulduk. Temamızı değiştirebilir ve özel bir sertifika alabiliriz, ancak yine de trafikte olacağız, burada ne olabilir?

Cevap 2:01 - Ancak genel olarak, diğer sitelerin aynı ip adresinde barındırılması genellikle endişe nedeni değildir. Bu nedenle, özellikle daha büyük hosting sunucuları ile paylaşılan IP adresleri, CDN'ler ile oldukça yaygın bir paylaşılan IP adresidir. Ve bu değişen bir şey çünkü birçok CDN'nin farklı ülkelerde uç noktaları var ve bu uç noktaları orada aktif olan farklı web siteleriyle bir şekilde paylaşıyorlar. Bu nedenle, esasen kullanıcı ve Almanya, örneğin ABD'deki bir kullanıcıya karşı farklı IP adresi görebilir, ancak genel olarak bu, IP adreslerini paylaşmak, son derece yaygın bir uygulamadır ve sorun yaratacak bir şey değildir. İlk günlerde bu, bazen tarihleri ​​ve ev sahiplerini tanımak için çok yararlı olan bir şeydi. Statik adresleri olan bir IP adresi ve 9000 site görürsek ve bunların hepsi spam içerikliyse ve aynı ana bilgisayar üzerinde başka iki web sitesi daha varsa, o zaman bizim için anlamamız zor olabilir, bu iki site gerçekten tamamen mi geliyor? bu 9.000 diğer siteye kıyasla ayrı siteler. Bu, algoritmalar için biraz zor bir durum. Ancak bunun gibi çoğu durumda, farklı hedef kullanıcıları olan farklı ülkeler için farklı dillerde farklı siteler gibi her türden farklı sitelerin karışımını göreceğiz. . Yani bu, bu IP adresinde spam içerikli bir site olduğu için bunun sorun olacağını söylememiz için bir neden olmaz. Bu nedenle, burada bu web sitesiyle özel olarak ne olduğunu bilmiyorum, genel olarak bir göz atıyorum, ayrıca web sitemizin bu yönünün uzun yıllar boyunca aramalarda iyi performans gösterdiğini söylemeden önce bunun sizin için iyi olduğunu söyleme eğilimindeyim. site ama bu mutlaka her zaman böyle tutacağımız bir şey değil.

Bu nedenle, sitenin geçmişte iyi performans göstermesi ve aramanın bir yandan aramada iyi yapmaya devam edeceği anlamına gelmez, evet kullanıcı beklentileri değişir, diğer yandan Google'ın algoritmaları değişir. Dolayısıyla bu şeyler her zaman değişebilir ve bazı şeyler bazen önemli ölçüde değişebilir ve hedefimiz bu belirli bir web sitesinin kötü algoritmalar olduğu gibi daha az şey söylemekten ziyade, kullanıcı beklentilerine hizmet etmeyi kaçırdığımızı fark ettiğimizi veya İşleri artık kullanıcıların beklentileriyle eşleşmeyen şekillerde yapıyoruz, bu nedenle algoritmalarımız, örneğin kullanıcılar ve alakalı olan sonuçları arama sonuçlarına geri getirmeye çalışmak için değişiyor. Yani bu, web sitesinin türüne bağlı olarak her zaman oynayabilecek bir şey.

Soru 5:49 - Bir süre önce, içeriğimizi çalmaya ve ardından telif hakkını ihlal etmeyecek şekilde değiştirmeye ve ardından bizi geride bırakmaya dayalı olarak bizi geride bırakan site hakkında. Geriye dönüp baktığımızda ve bazı araştırmalar yaptığımızda kalıbı fark ettik, öyle görünüyor ki sitemizi yeniden tasarlayacak, kalitemizi artıracak, sıralamaları iyileştirecek, sonra kopyalayacaklar ve bir veya iki ay içinde bir süre sonra sıralamaya başlayacaklar. bize ve bize öyle geliyor ki, algoritmalar bir şekilde karıştı ve o siteye bizim yerimize içerik oluşturucu olduğu için kredi veriyor ve sonuç olarak bizi sıralamada bastırıyor.

Cevap 6:37 - Bilmiyorum, orada tam olarak neler olduğunu görmek için sitelere bakmam gerekir. Algoritmik açıdan bunu söylemek biraz zor, tıpkı algoritmalarımızın bu sorgular için her zaman siteniz yerine o siteyi seçmesi gibi. Ancak, genel olarak orada yapmayı hedefleyeceğim şey, eğer bu siteler içeriğinizi kopyalıyorsa, o zaman onları içeriğinizi kopyalamamaya teşvik etmek için kökten çözmenin yollarını bulmaya çalışın. Bu nedenle, belki bir DMCA şikayeti gibi şeylere bakabilirsiniz, bunun sizin durumunuzla ilgili olup olmadığını bilmiyorum, ancak bunu, aramanın bu sürümlerden hangisinde bu tahminde bulunmak zorunda kalmayacak şekilde ele almaya çalışmak için herhangi bir şey içerik bu sorgular için sıralanmalıdır.

Soru 11:18 - Bir etiket yöneticisi aracılığıyla json-ld kullanma sorununu açıklayabilir misiniz? Etiket yöneticisi, arama konsolunu ve muhtemelen analitiği doğrulamak için kullanılır, bu nedenle kesinlikle yeterince kararlıdır.

Cevap 11:33 - Sanırım bahsettiğimiz şey birkaç kez ve bu hangout'ların bir kısmı ve Barry de dahil olmak üzere çeşitli insanlardan bu konuda yazılmış yeni blog yazıları var. Ancak bu esasen geri dönüyor, bizim için etiket yöneticisinden içerik çekebilmemiz, JavaScript sürecini etiket yöneticisinden komut dosyası dosyalarını oluşturabilmemiz ve oradaki yazının çıktısını alabilmemiz ve indeksleme tarafını dahil edebilmemiz gerektiği anlamına geliyor. Bu, sistemlerimiz için her zaman çok fazla çalışma gerektiren bir şey ve her zaman tüm sayfalar için yaptığımız bir şey değil, özellikle sayfanın aksi halde aynı olacağını gördüğümüzde, sistemlerimizin bunu haklı çıkarması biraz zor. tüm bu JavaScript'i de işlememiz gerekiyor. Üstelik test araçlarının çoğu, etiket yöneticisini ve çıktısını işlemezler, bu nedenle araçların bu işaretlemenin düzgün çalıştığını doğrulaması gerçekten zordur. Aramada işlenmesi daha uzun sürer, biraz lapa lapa olabilir ve herhangi bir zamanda tam olarak ne indekslendiğini tam olarak bilmiyorsunuz. Yani bunlar, benim bakış açımdan etiket yöneticisini başka herhangi bir şey için kullanmamın nedenlerinin hepsi. Arama için yapılandırılmış veriler için JsonLD için de bunun için kullanmak iyidir, ancak bunun özellikle aramadaki yapılandırılmış veriler için harika bir yaklaşım olmadığını akılda tutmakta fayda var. Yapı verilerini doğrudan web sayfasında sağlamanın çok daha basit yolları, bakımı kolaylaştırır ve tüm bunları test etmek için izlemeyi kolaylaştırır. Yani bunu yapmanızı tavsiye ederim, bunun için etiket yöneticisini burada kullanamazsınız demiyorum, kesinlikle kullanabilirsiniz ve onu alıp kullanmak için elimizden geleni yapacağız ve bunun gibi ama değil yapı verilerinin doğrudan sayfalarda sağlanması söz konusu olduğunda oldukça aynı düzeyde hız ve esneklik, güvenlik.

Soru 14:00 - Bir istemci 301 yerine 302 kullanarak hareket ederek HTTPs geçişi yaptı, bunu 301 olarak değiştirmeleri gerekiyor mu? Google'ın bunun kalıcı bir yönlendirme olduğunu anlaması ne kadar sürer?

Cevap 14:14 - Muhtemelen, birçok insanın site hareketleri için yanlış yönlendirme etiketi kullandığını da anlayacağız ve hala bunu doğru bir şekilde çözmeye çalışıyoruz. Neler olduğunu görmenin hızlı bir yolu, işlerin doğru şekilde dizine eklenip eklenmediğini görmek için arama konsolunda kontrol etmektir. Bu nedenle, yeni alan adı iyi çalışıyorsa, muhtemelen zaten sorun yoktur. Bununla birlikte, bir web sitesinde bunun gibi sorunları veya düzeltilmesi kolay diğer teknik sorunları fark ettiyseniz ve büyük bir etkisi olabileceğini hissediyorsanız, devam edip düzelteceğiz. Özellikle yanlış yönlendirme türü, çoğu web sitesindeki htaccess dosyasındaki tek satırlık değişiklik gibidir. Yani bu, düzeltilmesi gerçekten kolay bir şey. Böylece arama motorlarının bunu yanlış yorumlaması konusunda endişelenmenize gerek kalmaz.

Soru 15:20 - Resim galerilerimizin /gallery/image1 veya /image2 veya /image 3 gibi benzersiz bir URL'si var ve galeri eklemek /tümünü görüntüle ve bunu standart URL olarak kullanmak istiyoruz ancak bu bağlantıya sahip değiliz sitenin herhangi bir yerinde bunu yapabilir miyiz? Görünümün tamamının okuyucu için görünür olması gerekiyor mu?

Cevap 15:46 - Bu, Google'ın aramada göstermek için bir URL'yi nasıl seçtiğine ilişkin genel soruya giriyor ve bir yandan bu durumda, resim 1'in açılış sayfasının bir rel kanonik ayarına sahip olması gibi bir yönü var. tüm sayfayı görüntüle, bu sayfaların eşdeğer olmadığı anlamına gelir. Bu yüzden, bu kurallı olanı alıp kullanacağımız bir tür isabet ya da ıskalama, bence akılda tutulması gereken bir yön bu. Akılda tutulması gereken diğer bir şey de, bu sayfaların eşdeğer olarak görülebileceğini anladığımızda bile, bu sayfalardan hangisinin gerçek standart olduğunu belirlemek için birden fazla faktör kullanmamız gerektiğidir. Bunun için bir rel canonical kullanıyoruz, bir şeyimiz varsa yönlendirmeleri kullanıyoruz. Dahili harici bağlantılar kullanıyoruz, site haritaları, hreflang bağlantıları gibi şeyler kullanıyoruz, bunların tümü, bu URL'lerden hangisini göstermemiz gerektiğini anlamamıza yardımcı oldu ve belirttiğiniz kurallı URL'nin geri kalanında asla kullanmadığınız bir URL olup olmadığını anlamamıza yardımcı oldu. Web siteniz için, o zaman, bu bağlantıyı standart hale getirmenin bir hata olduğunu, web yöneticisinin aslında böyle demek istemediğini ve belki de standart olarak farklı bir URL seçmemiz gerektiğini söyleyebiliriz. Tahminimce burada olacak şey, ya rel canonical'i görmezden geleceğiz çünkü bunlar aynı şey değiller ya da bunun yerine mevcut diğer sayfalardan birini seçeceğiz çünkü bu, içinde güçlü bir şekilde bağlantılı olan sayfalardan biri. internet sitesi. Bu nedenle, bu özel kurulumun sizin durumunuzda o kadar yararlı olacağını düşünmüyorum.

Soru 17:38 - Diğer diller ve ülkeler için sağlamak istedikleri çok fazla içeriğe sahip olan ancak şu ana kadar sadece arayüzü çevirmiş, yani ana içeriği olmayan siteler için tavsiyeniz nedir?

Cevap 17:55 - Bu, özellikle kullanıcı tarafından oluşturulan içerik için oldukça fazla olan bir şey. Yani bir forumunuz veya blogunuz veya başka bir şeyiniz varsa ve insanlar bir dilde yorum yapıyorsa, ancak kullanıcı arayüzünün diğer dillere değişebilmesi için kurulumunuz var. Ardından, kullanıcı arayüzünün Fransızca veya Almanca olabileceği, ancak örneğin herkesin İspanyolca yorum yapması nedeniyle içeriğin yine de İspanyolca olabileceği ve bu aslında birçok şekilde ele alabileceğiniz bir durum olduğu bir durumla karşılaşırsınız. Yani benim standart versiyonumun İspanyolca versiyonu olduğunu ve her şeyin tıpkı İspanyolca versiyonu gibi olduğunu söyleyebilirsiniz, bu da yapabileceğiniz bir seçenek. Bu sürümler arasında hreflang ek açıklamalarını kullanabilirsiniz, bunun içeriğimin en Fransızca sürümü olduğunu, ana içeriğin Fransızca olmadığını, ancak kullanıcı arayüzünün Fransızca olduğunu, böylece sayfayı ziyaret eden kullanıcının etrafta gezinebileceğini söyleyebilirsiniz. web sitem, yapabileceğiniz bir şey. Ve esasen bunlar, tercihlerinizin ne olacağı hakkında bize biraz daha bilgi vermek için sağlayabileceğiniz farklı varyasyonlardır. Pratik bir bakış açısından, aramada nasıl görünmek istediğinizle ilgili olarak nihayetinde size kalmış. Bu nedenle, bir Fransız kullanıcının sitenize gelip içeriğin İspanyolca ve kullanıcı arayüzünün Fransızca olduğu sayfaya gelmesinin ve sonra elbette bu sürümler arasında hreflang ek açıklamalarını kullanmanın yararlı olduğunu düşünüyorsanız. Fransa'daki bir kullanıcının, ana içerik İspanyolca olsa bile, kullanıcı arayüzü Fransızca olsa bile sitenizde gezinmede sorun yaşayacağını düşünüyorsanız, o zaman belki de İspanyolca sürümünü, İspanyolca kullanıcı arayüzü ile dizine eklenmiş halde tutmak mantıklı olabilir. Bu, sonuçta size kalmış, bence bunların hiçbiri mükemmel çözümler değil. Bazen, içeriğinizin ne kadar tekdüze olduğu, hangi dil sürümlerini dizine eklemek istediğinizi ve kullanıcıların arama sonuçlarında hangi sürümleri görmeyi beklediğini ne kadar net anladığınıza bağlıdır. Örneğin, çok uluslararası bir forumsanız ve insanlar her türden farklı dilde gönderiler yayınlıyorsa, yalnızca bu UI sürümünün dizine eklenmesini istediğinizi söylemek muhtemelen zor olabilir, belki de tüm UI sürümlerinin dizine eklenmesi mantıklı olabilir. Elbette tüm UI sürümlerinin dizine eklenmesinin dezavantajı, sitenizin birdenbire sahip olduğu url'lerinizin sayısını çarpmasıdır. Bu, çok daha fazla taramamız gerektiği anlamına gelir ve bu, taramamız gerektiği anlamına gelen, kullanıcı tarafından oluşturulan büyük bir içerik sitesiyse, bir yandan kullanıcı tarafından oluşturulan içeriğin tümü ve ardından her biri için bunun katlarını taramamız gerekir. yararlı olup olmadığını bilmediğim bir dil sürümü, eğer web siteniz için çok fazla tarama yapıyorsa, bu, daha yeni içeriğin arama sonuçlarında hızlı bir şekilde görünmesini engelliyorsa. Orada ağırlığını koyacak başka bir şey var. Sadece birkaç bin makaleden bahsediyorsanız, belki bu daha az sorun yaratır.

Soru 21:25 - Blog yazıları jenerik editör kullanıcısı tarafından yazılmış olarak işaretlendiğinden beri e-ticaret sitemizin yanında çalışan bir blogumuz var. Kalite yönergelerine ve EAT'ye baktığımızda, düzenleyiciyi gönderi yazarının gerçek adıyla değiştirmek istiyoruz, bu tür bir işlem olumlu mu yoksa potansiyel olarak spam görüyor olabilir mi?

Cevap 21:48 - Özellikle makaleyi orijinal olarak kimin yazdığını biliyorsanız ve ona bir yazar açılış sayfası gibi davranabiliyorsanız, bunun iyi bir hamle olduğunu düşünüyorum. Sadece saf bir kullanıcı bakış açısından bile, birisi web sitenize giderse ve aniden bu makalelerin sadece editör yerine Barry tarafından yazıldığını görürse ve o yazar için bir açılış sayfanız varsa, o zaman bu onun için daha iyi olduğunun bir işareti olabilir. Kullanıcıların anlayabileceği veya yazarın açılış sayfasına gittikleri ve oh bu yazar aslında bu alanda uzman ve birkaç yıldır orada aktif olduğunu gördükleri bir kullanıcı olabilir. geneldir ve Google sıralamasıyla ilgili olarak, bunun herhangi bir doğrudan etkisi olup olmayacağını söylemek zor. Ancak en azından dolaylı etkiler, kullanıcıların içeriğinize daha çok önerildiği gibi güvenebilecekleri veya bunun beklenen bir şey olduğunu düşünüyorum.

Soru 22:58 - Masaüstü ve amfi versiyonu ile şema işaretlemesi, masaüstü versiyonu mikro veriler kullanılarak uygulanıyorsa ama amp versiyonu json-ld kullanıyorsa sorun olur mu?

Cevap 23:09 - Elbette bu gayet iyi. Orada kullanılan biçim veya biçimle ilgili olarak, bununla ilgili bir sorun görmüyorum, akılda tutulması gereken tek şey, bildiğim kadarıyla bazı yapılandırılmış verilerin yalnızca json-ld'de mevcut olmasıdır. Bu, kullandığınız yapılandırılmış veri türlerini iki kez kontrol etmeniz gereken bir şey olabilir, ancak sitenizin bir sürümünün bir tür yapı verisini diğer sürümde farklı bir tür kullanarak, hatta aynı masaüstü mobil cihazında kullanmasını sağlayın. uygulama varyasyonu, bu kesinlikle mümkün, örneğin bir blogunuz varsa, web sitenizde ve e-ticaret sitenizde bir, bilmiyorum, ürün dizini varsa ve e-ticaret sitesinde json-ld kullanan incelemeler varsa ve blogunuz kullanır mikro verileri kullanan makale işaretlemesi, bunu yapmanın doğru yolu olup olmadığını bilmiyorum ama bu kesinlikle iyi olurdu.

Soru 24:19 - Gizli içerik görüntülemeyle ilgili olarak:none Google desteği sorun değil ve beyaz arka plan beyaz yazı tipinin veya sıfır yazı tipi boyutunun yönergelere aykırı olacağından bahsetti, peki ya display:none?

Yanıt 24:32 - Gizli içerik genellikle takdir ettiğimiz bir şey değildir. Özellikle, sitenin aslında sayfanın kendisinde görünmeyen anahtar kelimeleri Google'ın dizinine göndermeye çalışması olarak karşımıza çıkıyor. Yani bu gerçekten kaçındığım bir şey. Duyarlı tasarımdan bahsettiniz ve sorunuzun geri kalanı, bence burada devreye giren tek yön bu. Dolayısıyla, bu içeriği mobil kullanıcılar veya masaüstü kullanıcıları için görünür kılmak için duyarlı tasarım kullanıyorsanız, bu tamamen sorun değil. Ancak bu içerik esasen sıfırdan yapılmış yazı tipleri veya beyaz arka planda beyaz yazı tipi veya siyah arka plan üzerinde siyah yazı tipi gibi her zaman görünmezse, bunlar sistemlerimizin alacağı ve iyi diyebileceği türden şeylerdir, belki buradaki bu metin o kadar alakalı değildir aksi takdirde olabileceği gibi ve pratik bir bakış açısından, muhtemelen böyle bir şey için manuel bir işlem yapmayacaksınız. Ancak bunu anlamaya çalışmaktan başka ve konu arama olduğunda bu içeriği bir nevi değersizleştirmeye çalışacaklar. Bu nedenle, snippet'te gösterilme olasılığı daha düşüktür ve bu sayfalarda gerçekten önemli olarak ele alınma olasılığı daha düşüktür.

Soru 25:55 - Bağlantılardan sonra manuel işlem, yeniden değerlendirme isteği kabul edildikten, ancak trafikteki potansiyel sıralamalarını geri kazanmadıktan sonra Google etki alanını ne kadar süreyle ele alır?

Cevap 26:08 - Bence burada bir yandan manuel işlem çözülürse, o zaman hemen hemen doğrudan o site, bu manuel işlem olmadan aramada görünür olacak iki husus var. Dolayısıyla burada bir istisna var ki, bir site saf spam nedenleriyle kaldırılırsa, o zaman esasen dizinimizden tamamen kaldırılacaktır. Bu yüzden, onu tekrar açıp tekrar gösterebileceğimiz için değil, gerçekten yeniden taramamızı gerektirecek ve bu siteyi bazen birkaç hafta sürebilen, ancak diğer tüm manuel işlemler için işleyeceğiz, bu, bir kez bu manuel işlemin çözüldüğü ve diğer şeylerin olduğu şeydir. önceki duruma geri döndük, Google'ın kin beslediği ve burada manuel bir işlem olduğunu söylediği için değil, bu yüzden gerçekten çözüldü, çözüldü. Bağlantılarla ilgili olarak, siteniz doğal olmayan bağlantılar nedeniyle arama sonuçlarında yapay olarak sıralanıyorsa ve manuel bir işlem yaptıysanız ve bu doğal olmayan bağlantıları kaldırarak bunu düzeltirseniz, elbette siteniz yapay olarak daha üst sıralarda olmayacaktır. bu doğal olmayan bağlantılar şimdi gitti. Bu, böyle bir şeyi çözdükten sonra görünürlükte bir değişiklik görmenin tamamen normal olacağı bir şeydir, benzer şekilde, eğer bir site web sitenizdeki başka şeyler nedeniyle doğal olmayan bir şekilde görünürse ve bu diğer şeyleri kaldırarak bunu çözerseniz, siteniz açıkça görünür olacaktır. tekrar doğal olarak görünür olun, ancak kaldırdığınız şeyler nedeniyle doğal olmayan bir şekilde görünür olmayacak, bu yüzden bu akılda tutulması gereken bir şey.

Question 27:59 - In looking at some of our backlink profile we had found, I don't even know how our links ended up on these pages, like on pages that have just like 7,000 links and things like that. We disavowed them when we found them. Is there anything we need to be concerned about other than doing that with when we find stuff like that?

Answer 28:20 - No that's that's essentially the right move to do and especially if it's something that you're really worried about. So I think for most websites it doesn't make sense to go out there and disavow things that are just like iffy and weird because for the most part we just ignore those. So in particular with regards to links, if it's something that when you look at it you say well this could be seen as these links be being bought by us, like naturally placed there by us, if someone from the website team were to take a look at this manually and they would assume that, this is us doing something stupid, that's the kind of thing where I'd say probably disavowing them or getting them removed would be the right move there but otherwise if it's just an iffy link and it looks like it's something like there are millions of other links on there someone ran a tool and dropped tons of links into this forum then that's something our algorithms have figured out already. So that's not something I wouldn't worry about.

Question 30:06 - What do you suggest to tackle a low traffic, low quality pages on a site? There lots of suggestions regarding content pruning what recommendations do you have regarding that?

Answer 30:20 - So I think first off the assumption that a page that has low traffic is also low quality is something that I would question and sometimes pages just have low traffic because a lot of people search for them but they're still a really good truck pages. So II would question kind of the assumption that you can just go into analytics and sort of your pages by a number of page views and delete all of the lowest pages there because I don't think that necessarily picks up like that these pages are really low quality or not. So that's kind of a first assumption there, if you know your website then obviously you can combine different metrics to try to figure out where the low quality pages are but I would still recommend making sure that these are really low quality pages before you take any kind of harsh action on those pages. And then as a next step if you do know that these are low quality pages when whenever I talk to our engineers from the quality team they tell us not to tell web masters to just go off and delete those pages but instead to going to improve them. So if you know that they're low quality pages that probably means you know what is missing and that probably means you know there are ways to kind of make these higher quality pages. So that's kind of the direction I would take there and not just delete things that are low quality but figure out a way to make them more high quality instead. So that could be by combining pages maybe it's something where you see this one-page, its kind of thin but it matches this your page and you have otherwise on your website maybe combining them makes sense. So 301 redirecting them to kind of one shared URL instead that might be an option. Rewriting them to be higher quality is obviously a good idea obviously takes work so it's not this one simple magic trick to make number one. Then finally if it's really something that you can't resolve at all or that is such a big mass of pages that are low quality that you can't really fix then maybe deleting them is it right. So those are kind of the different variations there that are available but again I would strongly question the the assumption that low traffic equals low quality. So if you're looking even looking at a larger site don't just assume that because something has low traffic is sign that it's not important for your website or for the rest of the web.

Answered Cont' 34:03 - Yeah so I think one way you could look at this is to say given this state of content that you have what would be your preferred new website look like? So kind of saying like assuming I had all of this content and I had to create a new website out of it what would it look like and then to try to find a way to migrate your existing content into this new structure that you have in mind and like I said it could improve include combining pages, combining maybe tens of different pages together into one stronger page, it could be deleting pages where you say, well these don't make any sense for my website anymore maybe it was something that users cared about a couple years ago but now, I don't know, nobody is playing ingress anymore so all of those ingress pages on my website I have to make a hard decision and delete them. I can see the shocked faces everywhere in here now. But these kind of things happen over time and it makes sense to clean things up over time and sometimes it means deleting, sometimes that means combining, sometimes that just means rewriting and cleaning up. So it's it's hard to have one one answer that works for every side in every situation.

Question 36:36 - How to fix the crawl frequency of low priority pages within a website? Will Google crawl more of such pages because the quantity of these pages is more compared to the important pages?

Answer 36:49 - So I think this was your question as well in general you don't need things the the crawl rate of pages unless these are pages that are being changed more frequently than the crawl rate. So if you have an article that you wrote and it's being crawled once every three months and you're never changing this article that's that's perfectly fine we don't need to crawl it more often. There is no ranking bonus for being crawled more often. So crawling from our site is more of a technical thing where we say, this page has changed we should find a way to pick up this change as quickly as possible. It's not that we would say well the stage has been crawled twice in the last week therefore we will rank it higher those are completely separate parts of our algorithms.

Question 37:48 - I was checking the log files and 90% of our crawl budget is going to those specific URLs only and only 10% is crawling my product pages. So I was wondering I could make them crawl less frequently for those specific sections and maybe Google can start crawling or kind of giving more importance to my other sections of a set?

Answer 38:18 - Okay so you actually want to do the opposite which is I think a good move too. To have those pages crawled less frequently. So from from our point of view there's really no way to do that. So it's something that you would need to almost attack from the other way around to say, that I think these are other pages that are important on my website and therefore I'll link them prominently within my website. I'll make sure that all of my other pages refer to those pages, that they're specifying the sitemap file with the last modification page that we can confirm. So all of those signals to help us understand we need to be able to crawl these pages more frequently because there are changes on these pages. On the other hand if there are no changes on these pages we don't really to recall them for more free company so that's kind of be the other aspect there. If these are pages that are important for you but they are not changing frequently then there's no need to artificially force them to be crawled more often.

Question 40:11 - Can you tell if with redirection only link penalty passes or link penalty and content penalties both pass for example at website with pure spam manual action is redirected to another site so technically the URLs will be a soft 404, will it affect the redirected website?

Question 40:37 - So I'm not quite sure with which part of this question you're you're kind of focusing on. On the one hand if a random spammy website redirects to your website that's usually something we can recognize and just ignore. On the other hand if yours is that spammy website and you're redirecting to another website to try to escape that penalty then probably we will be able to follow that site migration and apply that manual action or algorithmic action to the new website as well. So my recommendation there would be instead of trying to get away by doing fancy redirects or other types of site moves. I would recommend just cleaning up the issues so that you don't have to worry about those anymore. So if there are link actions with regards to that website then clean up those those links so that you're in a clean state again. The reconsideration process is great for that because someone from the web spam team will take a manual look at your website and they'll say, this looks good this is fine like. You did good work and clean things up it's clear that you understand what you should be doing now so we can remove them. So I think that's really useful to have there from a practical point of view. So that would be kind of my recommendation if you're the website that has this problem. On the other hand if like I mentioned some random website redirects to your website and that's usually something that we can recognize, this is not a normal site move this is just the read website redirecting to you to another website and we can get that.

Question 42:30 - John two quick general questions one related to site load speed, we've read and heard various things including recently people saying that like every microsecond counts and things like that, what is the current policy I know in the past you said as long as it's not ridiculously long to load you're fine?

Answer 42:53 - What is the current policy? So speed is something that does matter quite a bit to us and it has a big effect on users so that's something that I would personally take quite seriously and I think the the nice part about speed is there various tools that gives you pretty objective measures there that you can actually work on. With regards to a lot of us or other issues around SEO like, I don't know the quality of their content things like that speed is something that that is quite measurable and something that you can kind of work on, and it should also be something we're used a direct effect from your users behavior within your website. So it's not just something that from from Google's point of view like we say speed is important it is rank tracker but it's something that you will see directly when users come to your website and your website is suddenly taking a couple seconds longer to load those users will react quite differently on your website and you'll have more trouble converting them into customers however you define customers on your website.

Question 44:08 - From the standpoint of like if it's 1.1 seconds versus 1.2 second that kind of thing would would you say that that's very important to try to really optimize those?

Answer 44:21 - I think the tricky part with speed is there's so many different measures in the meantime that it's hard for me to say like, load time is the only thing you should be thinking about, but there ways to to kind of determine how quickly the page is is generally accessible. How quickly they the content is visible on the page, even kind of ignoring the aspect that maybe the rest of the page below the fold is still rendering and still takes a bit of time to actually be ready, maybe the part that users care about is actually visible fairly quickly. So from from that point of view usually small differences are less of a thing but kind of like I mentioned speed is something where you can use these different tools who could come up with a different metrics and you can focus on those metrics and try to improve those and you can measure that yourself and you can kind of work on that without having to go through various Google tools and waiting for things to update in the index in these tools.

Question 45:47 - Can I use Google official videos in my blog or can I only link to them for example Matt Cutts videos about SEO. I will use Adsense on the blog when I have enough adsense my blog will be complete in 6 months.

Answer 46:03 - I don't think there are any restrictions with regards to embedding videos for a channel but if there were no restrictions then I think the embed option YouTube wouldn't be available there. So if the embed option is there then then go for it. I think in in general I'd be cautious about using just a video as the primary piece of content on a web page and you should really work to kind of use the video in a way that supports your primary content but not that it replaces your primary. So for example I wouldn't take any of these videos and just put them on a blog post and add a title to them and expect them to show up highly in search. But if you have specific content around that video if you have a transcription of that many don't you have some comments to that transcription to the content that are shown in the video or you're using that video as kind of a point of reference with regards to your content and I think that's a perfectly fine approach. But just purely using a video on a page is something that atleast in a web search point view makes it really hard for us to determine what is actually useful on this page and why should we show it in the search results.

Question 47:27 - If I pay for Google Ads will my ranking be better or worse?

Cevap 47:34 - Arada sırada bu soruyu alıyoruz ve buradaki soru şu, sıralamam etkilenecek mi, ancak daha iyi ya da en kötü kısım, bazı insanların söylediğini duyduğumuz bir şey, sıralamanız değişmeyecek. Google Ads kullanırsanız daha iyi olur, bazı insanlar daha fazla reklam satın almanızı istediğimiz için Google reklamlarını kullanırsanız sıralamanızın düşeceğini söylüyor ve bunların hiçbiri doğru değil. Bu nedenle, arama sonuçlarımız Google Ads kullanıp kullanmadığınız konusunda tamamen bağımsızdır ve web sitenizde kullandığınız teknolojilerden tamamen bağımsızdır. Dolayısıyla, analitik gibi bir şey kullanıyorsanız veya tamamen size kalmış başka bir izleme aracı kullanıyorsanız. Adsense veya bu diğer reklam ağlarından herhangi biriyle para kazanmanız tamamen size kalmış. Dolayısıyla web siteniz içerisinde Google ürünlerini kullanıp kullanmamak, web siteniz için diğer Google hizmetlerini kullanıp kullanmamak tamamen size kalmış. Bu, bu hizmetlerin kendi başına ayakta durmasını tercih ettiğimiz bir şey ve bunu belirli bir nedenle Google hizmetinin harika olmadığını söylüyorsanız, onu kullanmak istemiyorum, o zaman başka bir şey kullanmaktan çekinmeyin. Sizi, web sitenize odaklanmak ve kullanıcılarınız için doğru olduğunu düşündüğünüz şeyi yapmak ve bu belirli ürünü kullanmak arasında sıkışıp kaldığınız bir kutuya koymak istemiyoruz. Bu nedenle, gerçekten bunları birbirine bağlamıyoruz ve bunu açıkça yapıyoruz ve bu şeylerin iyi çalıştığından emin olmak için çok çalışıyoruz.