22 Ocak 2019 – Google Help Hangout Notları

Bu hafta John, Big Apple, NYC'de. Google'daki Java Script ekibinden Martin Splitt, Chris Love, Lily Ray, Marie Haynes, Dave Minchala ve Quason Carter tarafından soldan sağa IRL'ye katıldı. Bu hafta Cloudfare, The QRG ve The New Page Speed ​​Tool hakkında harika sorular vardı. Videoya bağlantı ve tam transkript aşağıda bulunabilir!

Cloudflare bazen Googlebot'u engeller mi?

7:58

"Evet, şu anda Cloudflare ile bunun nasıl kurulduğunu bilmiyorum, ama geçmişte Googlebot'u taklit eden insanları engellediklerini biliyorum. Yani, eğer kendinizinkini kullanırsanız, bilmiyorum, Screaming Kurbağa ya da başka bir şey-- diyorsun ki, ben Googlebot kullanıcı aracısı kullanıyorum, o zaman bunu engellerler çünkü bunun meşru bir Googlebot olmadığını söyleyebilirler. Bunu engelleyebiliriz. Ama bence çoğunlukla, normal Googlebot'ları tanımak ve normal şekilde taramasına izin vermek için yeterli uygulama."

Özet: Bazen, test sırasında Cloudflare, Googlebot'u engelliyor gibi görünebilir. Muhtemelen burada olan şey, Cloudflare'ın Googlebot gibi davranan kişileri engellemesidir. Dolayısıyla, Screaming Frog gibi bir araç kullanır ve kullanıcı aracınız olarak Googlebot'u seçerseniz, Cloudflare kullanarak siteleri tarayamayabilirsiniz .

Doğal olmayan bağlantılar yine de bir siteye algoritmik olarak zarar verebilir mi? Öyleyse, reddetme aracı yardımını kullanabilir mi?

14:01

"Bence bu iyi bir soruydu. Benim bakış açıma göre, orada bakacağım şey, bir yandan kesinlikle manuel bir işlemin olduğu durum. Ama aynı zamanda, sizin de yapmak istediğiniz durumlar. bir sürü manuel işlem görüyorsanız, eğer web spam ekibi buna şimdi bakarsa, size manuel bir işlem yapacaklarını söylerdi. zaman ve yapılmış bir şeye dayalı gibi değil-- bilmiyorum-- birkaç yıl önce açıkça yapıldığı ve sınırda değildi. ve diyelim ki, web spam ekibinden biri bunu bir ipucu olarak alırsa, manuel bir işlem yapacaktır ve bu kesinlikle onu temizleyeceğim ve bunun için bir reddetme gibi yapacağım türden bir şey. belirli bir zaman çizelgesi olup olmadığını söylemek zor ama genel olarak, webspam ekibi buna bakıp şöyle derse, işler değişti. bir kaç yıl önce. Tamamen kötü niyetli değildi. O zaman muhtemelen bunun için manuel işlem yapmazlar. "

Ve muhtemelen buna cevap veremeyeceğinizi varsayıyorum, ama bunun bir yolu var mı-- mesela, diyelim ki, biz manuel bir işlem yapmadık veya onlar manuel bir işlem yapmadı. Bu bağlantılar onlara algoritmik olarak zarar verebilir mi? Çünkü reddettikten sonra bazı sitelerde bazı iyileştirmeler gördüğümüzü hissediyoruz. Yani, yine biliyorum ki her zaman-- asla siyah beyaz değil.

Bu kesinlikle böyle olabilir. Algoritmalarımıza baktığımızda, burada bir grup gerçekten kötü bağlantı olduğunu görüyorlar, o zaman belki de genel olarak web sitesi bağlantılarına ilişkin olarak biraz daha temkinli olacaklardır. Bunu temizlerseniz, algoritmalar ona bakar ve der ki, ah, orada-- bir çeşit-- sorun değil. Fena değil.

Özet: Yalnızca SEO için özel olarak yapılmış bağlantılarınız varsa ve birçoğunuz varsa, bunlar Google algoritmalarının tüm bağlantılarınıza güvenmemesine neden olabilir. Bu gibi durumlarda reddetmek en iyisidir.

Google'ın algoritmaları yayıncıların EAT'sini nasıl ölçer?

33:40

"Bilmiyorum. Bunu algoritmik olarak anlamanın muhtemelen zor olduğunu düşünüyorum. Ve yapmanız gereken herhangi bir tür teknik şey olsaydı, o zaman size bildirirdik. Yani yazarlık işaretlemesi gibi şeyler varsa, Bunun gibi bir şey için faydalı olacağını düşündüğümüz bazı noktalar olsaydı, bunu kesinlikle ortaya çıkarırdık.Fakat birçok şey gerçekten daha çok yumuşak kalite faktörleridir ve biz çözmeye çalışıyoruz ve bu teknik bir şey değil sizin anladığınız gibi. "ya yapıyor ya da yapmıyorsunuz. Daha çok, bir kullanıcının buna nasıl bakabileceğini anlamaya çalışmak gibi. Yani gösterebileceğim belirli bir şey değil."

Özet: Google'ın baktığı birçok "yumuşak kalite faktörü" vardır. Olaylara bir kullanıcının bakış açısından bakın. Ayrıca, yazarlık işaretlemesi, Google'ın işleri daha iyi anlamasına yardımcı olabilir.

Kalite Değerlendirici Yönergelerinde bir şey varsa, Google'ın bunun algoritmalarına yansıtılmasını istediğini varsaymak mantıklı mı?

34:44

Genel olarak, bunu hedeflemenin muhtemelen iyi bir uygulama olduğunu düşünüyorum. Google'ın algoritmik bir faktör olarak ne kullanabileceğine çok fazla odaklanmaktan kaçınıyorum ve buna daha çok şu şekilde bakıyorum-- bunun web için iyi olduğunu düşünüyoruz ve bu nedenle, o yöne gitmeye çalışacağız ve bunları yapacağız. çeşitli şeyler. Yani daha iyi bir sıralama elde etmek için iyi bir web sitesi yapıyorum gibi değil, ama iyi bir web sitesi yapıyorum çünkü aramada göründüğümde insanların iyi bir deneyim yaşamasını istiyorum. Sonra web siteme geri dönecekler ve belki bir şeyler satın alacaklar. Bu benim göreceğim yönlerden biri, bunu sıralamak için değil, internette sağlıklı, uzun vadeli bir ilişki kurmak için yapın.

Özet: Kullanıcılar için en iyisinin ne olduğunu düşünün. QRG'deki her şey şu anda Google'ın algoritmalarına yansıtılmasa da, bunların tümü genel olarak kaliteyi iyileştirmeye yönelik büyük adımlardır.

Sitelerin sesli arama sonuçlarında daha yüksek görünmesine yardımcı olacak bir şema var mı?

36:10

Bilmiyorum. Önemsiz bir şey düşünemiyorum. Dolayısıyla, kullanabileceğiniz konuşulabilir bir işaretleme var, ki bu muhtemelen makul olan-- bir sayfada bunun nerelerde anlamlı olabileceğini görmek için bir göz atın. Bunu henüz tüm konumlarda kullanacağımızı sanmıyorum.

Özet: Konuşulabilir işaretleme henüz tüm coğrafi konumlarda kullanılmamaktadır. Ancak, bu başlamak için iyi bir yer.

Öne çıkan snippet'leri kazanmayla ilgili bazı ipuçları

38:03

Ancak özellikle öne çıkan snippet'ler, buna özgü herhangi bir işaretleme türüne sahip olduğumuzu düşünmüyorum. Bu, sayfada net bir yapıya sahip olmanızın bize çok yardımcı olduğu bir şey. Bir sayfadaki benzer tabloları tanıyabilirsek, bunu çok daha kolay çıkarabiliriz. Oysa bir tablo gibi görünmesi için süslü HTML ve CSS kullanırsanız, ancak bu aslında bir tablo değilse, o zaman bunu çıkarmak bizim için çok daha zordur.

Özet: Öne çıkan bir snippet kazanmak için ekleyebileceğiniz bir işaretleme yoktur. Ancak h etiketlerinin ve normal HTML tablolarının iyi kullanımı gerçekten yardımcı olabilir.

Konum şeması tüm sayfalara eklenmeli mi?

50:47

Cevap 51:42 - Bildiğim kadarıyla bu sadece ana sayfa. Bilmiyorum. aranızda bilen var mı

Cevap Liz 51:4 7 - Genellikle kurumsal ve kurumsal olan tek bir sayfa olması gerekiyordu. Genelde tavsiye budur.

MARTIN SPLITT 52:00 - Sanırım hangisi olduğu önemli değil-- hangi sayfalar olduğu kadar önemli değil, tıpkı sahip olduğunuz her sayfaya koymamanız gibi, sanırım daha önemli olan kısım. Sanırım buna bağlı-- eğer bir haber sitesiyseniz, bunu iletişim sayfasına veya hakkında sayfasına veya başka bir şeye koymak muhtemelen mantıklıdır. Oysa bir mağaza veya restoran web sitesinde, ana sayfaya koymak muhtemelen sorun değil.

JOHN 52:20 - Bence bu durumda da bizim için o kadar önemli değil çünkü onu ana sayfa veya iletişim sayfası gibi bir yerde bulabilmemiz gerekiyor. Ama başka bir yerde olması bizim için hiçbir şeyi değiştirmez. Bu yüzden, bunu karşılaştırmamak için en büyük şey, bazen insanların sitelerindeki her sayfa için yıldızları ve arama sonuçlarını alma umuduyla web sitesinin tüm sayfalarına şirket incelemesi gibi koyduğunu gördüğümüz inceleme işaretlemesidir. Ve bu bizim için kötü olurdu. Ama iletişim bilgileri, eğer bunu işaretlemişseniz, bu-- Bunda bir sorun görmüyorum.

Özet: Gerçekten önemli değil. İletişim sayfasında ve muhtemelen hakkında sayfanızda ve ana sayfanızda olmalıdır. Site genelinde konum şemasına sahip olmak bir sorun değildir, ancak muhtemelen gerekli de değildir.

Lighthouse'a dayalı yeni PageSpeed ​​Insights aracı neden web sitelerini puanlarken çok daha sert?

53:05

Marie Haynes: Bu benim sorum değil, ancak biraz bağlam vermek gerekirse, sayfa hızı için yeni Deniz Feneri verileri, Sayfa Hızı İstatistikleri'nin eskisinden çok daha sert. Yani Page Speed ​​Insights'ta 80 gibi bir puanı olan bir şey Lighthouse'da kırmızı 29 olabilir. Bu iyi bir soru. Bunun nedeni olabilir mi-- çünkü mobilde çok yavaş sitelerin sıralamasının düşürülebileceğini biliyoruz. Öyleyse, Deniz Feneri testinde kırmızıdaysanız, gerçekten bir şeyleri iyileştirmemiz gerektiğini çünkü bir düşüşe neden olabileceğini söylesek iyi mi, yoksa bir kesinti mi var?

Cevap 54:07 - Yani harici araçların ve sosyal amaçlı kullandığımız her şeyin bire bir eşleştirilmesine sahip değiliz. Evet, bunu söylemeyi gerçekten zorlaştırıyor, ancak aramada, gerçek, ne olduğu, laboratuar testi verilerinin bir karışımını kullanmaya çalışıyoruz, bu bir tür Deniz Feneri testi gibi ve Chrome UX rapor verileri, esasen ne ölçtüğümüz şey, web sitesinin kullanıcılarının göreceği şeydir.

MARTIN SPLITT 55:37 - Örneğin, Lighthouse'un özellikle orta uçta bir 3G bağlantısı için ölçüm yaptığını veya orta performanslı bir telefon gibi, evet, görmek önemlidir. Yani, temel olarak, ofisinizde gerçekten iyi bir kablolu bağlantıya veya gerçekten iyi bir Wi-Fi bağlantısına sahip yeni bir Apple McIntosh veya yeni bir hızlı Windows bilgisayarındaysanız, elbette, iki saniyelik bir yükleme süresi görüyorsunuz, ancak Telefonu vahşi doğada olan gerçek bir kullanıcı muhtemelen bunu görmez. Bu, web sitenizi daha hızlı hale getirmekten asla zarar gelmez gibi durumlardan biridir, ancak bunun içeriden bakış açısından nasıl görüneceğini söylemek gerçekten çok zor, çünkü mutlaka birini eşleştirmek zorunda olmayan çok özel metrikler kullanıyoruz. Araçların ortaya çıkardığı şeylerden biri... Elbette bunu düzeltmek önemlidir, çünkü kullanıcılarınızın web sitenizde sonsuza kadar beklemesini istemezsiniz. Bu sana zarar verecek. Bu, kullanıcılarınıza zarar verecek. Bu sadece aramada sana zarar verecek. Ama ben ödeme yapmıyorum-- Sadece araçlara bakın derim. Araçlar size iyi olduğunuzu söylüyorsa, bunun için çok fazla endişelenmemelisiniz. Araçlar size gerçekten iyi olmadığınızı söylüyorsa, o zaman neden söylediğini bulmak için harcanan zaman bence-- eğer söylediği şey alakalıysa, boşa gitmiş demektir. Siteyi daha hızlı hale getirmeyi tercih etmelisiniz.

Mobil performans her şey için olduğu gibi kullanıcılarınız için de çok önemli bir faktör. Bu yüzden web sitenizin gerçek dünya koşullarında iyi performans gösterdiğinden emin olun derim. Hatta belki ucuz bir telefon alıp ara sıra web sitesini deneyin ve eğer-- bu yapmayı sevdiğim bir şeydi ve birlikte çalıştığım geliştirme ekibiyle Google'a katılmadan önce de yapardım. Ben de, bak, bu web sitesini bu telefonda kullanmak istiyor musun? Sanki, oh, bu korkunçtu. Ben, mhm, evet, belki bu konuda bir şeyler yapmalıyız.

JOHN - Chrome'da ayarlayabilir ve farklı bağlantı hızlarını deneyebilirsiniz. Mobil emülatör. Bence bunlara bakmak gerçekten güzel şeyler ve ayrıca kullanıcı tabanınıza bakın. İnsanların web sitenizi yalnızca ileri teknoloji bir iPhone ile kullandığını görüyorsanız, analitik verilerinize bakın. yavaş ve düşük kaliteli cihazlara sahipler, o zaman belki bu daha fazlasıdır.

Özet: Lighthouse, 3G bağlantısı için hızları ölçer, bu nedenle çoğu site, oturumların çoğunda burada görüntülenenden çok daha hızlı çalışır. Not: Bu videoyla sohbet sona erdikten sonra Martin, potansiyel sıralama düşüşleri açısından en önemli şeyin "ilk içerik dolu boya" olduğunu söylemeye devam etti.

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.

Video ve Tam Transkript

Soru 1:32 - SEO'ların daha kesin olmak ve işletmeye daha güvenli raporlama yapmak için kullanabileceği şekilde test etme konusunda daha fazla rehberliğiniz veya başka bir bakış açınız olup olmadığını merak ediyordum. Bu şeyi denedik ve etkisini gösterdi. Ve bunu kesinlikle Google'ın önereceği şekilde yaptık.

Cevap 3:20 - Benim bakış açıma göre, daha teknik türdeki şeyleri kalite türü değişikliklerinden ayırmaya çalışıyorum. Yani gerçekten net bir teknik şey olan herhangi bir şeyin işe yarayıp yaramadığını hemen hemen test edebilirsiniz. Bu, bir tür işe yarayıp yaramadığı meselesi değil, ancak bu teknik şeylerin çoğu, özellikle de işlemeye bakarken veya bakarken, Google gerçekten bu içeriği dizine ekleyebilir mi, yani çalışan veya çalışmayan bir şey. İşin zorlaştığı yer, ilgili olduğu her şey-- dizine eklenmiş, ancak sıralamalarda nasıl görünüyor? Ve bence bunların çoğu için bunu gerçekten test etmenin mutlak bir yolu yok. Çünkü bunu izole bir durumda test ederseniz, tıpkı bir test sitesi yaptığınız gibi ve onu tavsiyeleriniz ne olursa olsun ayarlarsanız, bir test sitesinin normal bir web sitesiyle aynı şekilde performans göstereceğini gerçekten varsayamazsınız. Bazen basit şeyler vardır, örneğin bu bir test sitesiyse, o zaman belki de buna ve buna çok fazla zaman harcamanın mantıklı olmadığını düşündüğümüz için tam render yapmayacağız, çünkü kimse ona bakmıyor. Arama sonuçlarında hiç görünmüyor, neden bunun arkasına bu kadar çok kaynak koymakla uğraşalım? Oysa bunu normal bir web sitesinde yapsaydınız, bu çok farklı şekilde çalışırdı. Yani bu, ne yapmanız ya da ne yapmamanız gerektiği konusunda gerçekten net bir rehberliğe sahip olmadığım bir şey. Daha çok, o web sitesinin göründüğünü gördüğünüz genel eğilimlere, bu sorgular için gördüğünüz sıralamalardaki değişikliklere baktığınız ve oradaki en iyi uygulamaları uygulamaya çalıştığınız türden bir şeye benziyor.

Soru 5:21 - Yani belki eğer-- somut bir örnek belki bunu şu şekilde kullanabilirsiniz-- belki bu yardımcı olabilir, yani başlık etiketi testi gibi bir şey, değil mi? Eğer bunu yapıyor olsaydınız-- eğer bir şey varsa, neye bakmalıyız? Veya çözülmesi gereken bir şey var mı-- bu bizim testimizden mi kaynaklanıyor, yoksa sunucu, algo, rekabet dinamikleri ile ilgili bir şeylerin değişmesinden mi kaynaklanıyor? [Gülüşmeler] Bu dışsallıklara bakmak için başka şeyler yaptığımızı varsayarsak.

Cevap 5:56 - Bence bir başlık etiketi değişikliği aslında bizim açımızdan oldukça karmaşık, çünkü Google'ın bir yandan sıralama için sağladığınız bir başlık etiketini kullanıyor mu, diğer yandan diğer yandan, arama sonuçlarında gösterilmek için. Masaüstü ve mobil cihazlarda olduğu gibi, farklı miktarda yerimiz var, bu nedenle biraz farklı başlık etiketleri gösterebiliriz. Kullanıcılar buna farklı şekillerde yanıt verebilir. Siz de aynı şekilde sıralama yapıyor olabilirsiniz, ancak kullanıcılar, ah, bu harika bir sayfa diye düşünebilir. Daha yüksekte göstereceğim-- ya da harika bir sayfaya benzediği için arama sonuçlarında üzerine tıklayacağım. Ve sonra daha fazla trafiğiniz var. Ama sıralama aslında aynı. Yani bu iyi bir şey gibi mi? Muhtemelen, sanırım. Sadece sıralamaya bakıyorsanız, o zaman bu, hiçbir şeyi değiştirmemişsiniz gibi görünebilir ve sadece daha fazla trafik aldık.

Ama bu, orada akan birçok farklı yönün olduğu bir şey. Bu, bir SEO uzmanı olarak, bir yandan ne olduğuna dair teknik bir anlayışa sahip olmanın, aynı zamanda kullanıcıların değişime nasıl tepki verdiğine dair daha fazla pazarlama ve kalite anlayışına sahip olmanın faydalı olduğunu düşündüğüm bir şey. kullanıcılarla etkileyebileceğimiz uzun vadeli değişikliklerdir, insanların bununla ilgili bir şey aradığı durumlarda sitemizin en alakalı site olarak görülmesini sağlamak için bunu nasıl sürdürebilirsiniz. Ve bence bu, test edilmesi gerçekten zor bir şey. Yıllarca pratik yaptıkları geleneksel pazarlamada bile test etmek gerçekten zor, bunun gerçekten büyük bir etkisi var mı, yok mu? Bu, büyük resme bakmaları veya SEO olarak da yapabileceğiniz kullanıcı çalışmaları yapmaları gereken bir şeydir. Afedersiniz. [Gülüşmeler]

Soru 7:58 - Daha doğrudan bir sorum var. Yani birkaç sitemiz, bilirsiniz, Cloudflare kullanıyor ve onların Googlebot'u doğrudan engellediğini fark ettik, değil mi? Ancak sıralamalarımıza, görünürlüğümüze vb. pek bir etkisi olmadı. Googlebot'un dışındaki bir dizini doğrudan taramak için başka bir botu nasıl kullandığınızı anlamaya çalışıyorsunuz ve CDN'ler botu engellemek için kendi yollarından çıktığında bunu nasıl düşünmeliyiz?

Cevap 8:33 - Evet, şu anda Cloudflare ile nasıl kurulduğunu bilmiyorum, ama geçmişte Googlebot'u taklit eden insanları engellediklerini biliyorum. Yani, kendi aracınızı kullanırsanız, bilmiyorum, Screaming Frog veya başka bir şey-- diyorsun ki, Googlebot kullanıcı aracısı kullanıyorum, o zaman bunu engellerler çünkü bunun meşru olmadığını söyleyebilirler. Googlebot. Bunu engelleyebiliriz. Ancak çoğunlukla, normal Googlebot'ları tanımak ve normal şekilde taramasına izin vermek için yeterli uygulamaları olduğunu düşünüyorum.

Soru 9:02 - Evet, ilginçti. Çünkü diğer ajanslardaki bir grup meslektaşıma ulaştılar ve benzer durumları kendi sitelerinde bile tekrarlıyorlardı. Mesela Cloudflare içinde bir destek bileti vardı ve bu da doğrudan Googlebot veya Googlebot akıllı telefonundan görüntü oluşturmaya çalışırken engelleniyordu.

Cevap 9:21 - Tamam, evet. Pekala, herhangi bir işimiz yok. Mesela, web siteleri bizi engelliyorsa, bir şekilde sıkışıp kaldık. Ancak genellikle Cloudflare gibi bir hizmet bizi varsayılan olarak engelliyorsa, bu birçok web sitesini etkilerdi. Ve biz bunu fark ederdik. Muhtemelen böyle bir şey için Cloudflare'a ulaşırdık. Belki de farklı hizmet katmanlarına sahip olabilirler. Yani, daha düşük seviyedeyseniz, bu ücretsiz bir hizmet gibidir, ancak trafik miktarıyla ilgili bir sınırımız var. Onlarda öyle bir şey var mı bilmiyorum. Bu, diğer bazı barındırıcılarda gördüğüm bir şey, eğer bir tür ücretsiz varsayılan barındırma kurulumunuz varsa, bazen sadece bir trafik sınırına sahipler ve bir şeyleri engelliyorlar.

MARTIN SPLITT: Bunu, sıralamanız ve diğer şeylerle ilgili istatistiklerde hemen göremeyebilirsiniz. Çünkü temel olarak, sizden içeriğimiz varsa ve temel olarak, web sitesi-- neyin engellendiğine bağlı olarak, bu durumda, bunu görmediğim için anlamına gelir. Ve Cloudflare'in arkasında birkaç web sitesi işletiyorum ve herhangi bir sorun yaşamadım. Ama sonra tekrar, devasa bir web sitem yok ya da büyük miktarda trafik sevmiyorum çünkü ücretsiz plandayım. Bu-- ama bizim tarafımızda bir hata almıyorsanız, bu-- sadece son gördüğümüz içeriği tutuyor olabiliriz. Ve bu sadece iyi sıralanıyor ve sorun değil.

Cevap 12:09 - Evet, sanırım sizinki gibi bir durumda ne olurdu, emeklemeyi yavaşlatırdık. Ve daha fazlasını getirebileceğimiz içeriği dizinde tutmaya çalışırdık ve biraz daha uzun süre yeniden tarardık. Ancak bu aynı zamanda web sitenizde değişiklik yaparsanız, bunu almamızın daha uzun süreceği anlamına gelir. Bilmiyorum, AMP gibi şeyleri önemli ölçüde yeniden taramamız gerekirse veya sitenin tamamına şu veya bu tür şeyler eklerseniz, bu çok daha uzun sürer. Dolayısıyla, normal bir Googlebot ile tarama yapamayacağımızı gerçekten düzenli olarak görüyorsanız, bu, görebilmemiz için ana bilgisayarla yaptığım bir şeydir.

Soru 14:01 - Harika. Bu yüzden reddetme aracıyla ilgili bir sorum var. Böylece her zaman bağlantı denetimleri yapmamızı isteyen insanlara rastlarız. Ve Penguin 4.0'dan beri, yani Eylül 2016'da, Gary Illyes'in dediği gibi ve sanırım siz de söylediniz, Google doğal olmayan bağlantıları görmezden gelmekte oldukça iyi. O zamanki düşüncem, doğal olmayan bağlantılar için manuel bir işlem yapmadığınız sürece, Google'dan zaten görmezden geldikleri bağlantıları yok saymasını istemek için reddetme aracını kullanmamamız gerektiğiydi. Bu yüzden, onu yalnızca aktif olarak, bilirsiniz, bağlantılar oluşturan, bir şeyleri manipüle etmeye çalışan, doğal olmayan bağlantılar olan siteler için tavsiye ediyoruz. Ama bence web yöneticileri arasında çok fazla kafa karışıklığı var çünkü insanları her zaman görüyorum, bilirsiniz, denetlemek için tonlarca para alıyorlar -- bağlantıları reddetmek için -- onların görmezden gelindiğini biliyorum. Bu yüzden biraz daha açıklığa kavuşturabilirsek çok sevinirim. Belki size bir örnek verebilirsem, örneğin, birkaç yıl önce bir SEO şirketi kiralayan bir işletme sahibi olsaydı ve o SEO şirketi sadece bağlantılar için bir sürü misafir ilanı yaptıysa ve bilirsiniz, bunun gibi şeyler. biraz orta kaliteydi, ne demek istediğimi anlıyorsan ultra spam değil, Google'ın bu bağlantıları görmezden geldiğinden emin olabilir miyiz? Yoksa içeri girip reddetmeli miyiz?

Cevap 15:22 - Bence bu iyi bir soruydu. Yani benim açımdan, orada bakacağım şey, bir yandan kesinlikle manuel bir eylemin olduğu durum. Ama aynı zamanda, çok sayıda manuel işlem görmek istediğiniz durumlar da, eğer web spam ekibi buna şimdi bakarsa, size manuel bir işlem yapacaklarını söyler. Elle eylemin daha çok zaman meselesi olduğunu ve yapılmış bir şeye dayanması gibi değil-- bilmiyorum-- birkaç yıl içinde yapıldığı açıkça belli olan durumlar gibi. önceydi ve sınırda değildi. Ama buna baktığınız ve söylediğiniz türden şeyler, eğer web spam ekibinden biri bunu bir ipucu olarak alırsa, manuel bir işlem yapacaktır ve kesinlikle bunu temizleyip yapacağım türden bir şey. bunun için bir reddetme gibi. Evet, belirli bir zaman çizelgesi olup olmadığını söylemenin zor olduğunu düşünüyorum. Ancak genel olarak, web spam ekibi buna bakıp şöyle derse, işler ilerledi. Bu açıkça birkaç yıl önce yapıldı. Tamamen kötü niyetli değildi. O zaman muhtemelen bunun için manuel işlem yapmazlar.

Soru 16:43 - Ve muhtemelen buna cevap veremeyeceğinizi varsayıyorum, ama bunun bir yolu var mı-- diyelim ki, biz manuel bir işlem yapmadık veya onlar manuel bir işlem yapmadı. Bu bağlantılar onlara algoritmik olarak zarar verebilir mi? Çünkü reddettikten sonra bazı sitelerde bazı iyileştirmeler gördüğümüzü hissediyoruz. Yani, yine biliyorum ki her zaman-- asla siyah beyaz değil.

Cevap 17:03 - Kesinlikle böyle olabilir. Algoritmalarımıza baktığımızda, burada bir grup gerçekten kötü bağlantı olduğunu görüyorlar, o zaman belki de genel olarak web sitesi bağlantılarına ilişkin olarak biraz daha temkinli olacaklardır. Bunu temizlerseniz, algoritmalar ona bakar ve der ki, ah, orada-- bir çeşit-- sorun değil. Fena değil.

Soru 17:24 - Sadece manuel bir işlemi önlemek için temelde reddetmek hala iyi, değil mi?

Cevap 17:29 - Web spam ekibinin mevcut duruma göre size manuel bir işlem vereceğinin gerçekten açık olduğu bir durumdaysanız, o zaman bunu reddederdim.

Soru 17:37 - Yani, Google'daki gibi düşünmek güzel-- Google spam ekibindeki birinin düşünmesi gibi.

Cevap 17:47 - Evet.

Soru 17:48 - Sorun şu ki çoğu insan bilmiyor. Yani, ortalama bir işletme sahibi, web spam ekibinin hangi bağlantıları yapacağını bilmiyor-- Yani, yönergeler var, ama bu çok-- bilirsiniz, bunları yorumlamak zor. Yani bence-- demek istediğim, birkaç endişem var, ama asıl endişem, bağlantı denetimlerine değmeyeceğini düşündüğüm tonlarca para harcayan insanlar var. Öte yandan, bağlantı denetimleri yapmıyor ve bundan yararlanabilecek bazı siteler için reddediyor olabiliriz. Bu yüzden çok isterim, bilirsin, bence söylediklerinin çok yardımı oldu, bu yüzden biz-- bilirsin, bu iyi.

Cevap 18:22 - Evet, sanırım geçmişte bazı kötü tavsiyeleri takip etmişsiniz gibi normal şeyler karışımına sahip sitelerin büyük çoğunluğu için ve sanki devam etmişsiniz gibi ve şu anda işler oldukça doğal, o zaman gerçekten bunu yapmak zorunda değiller. Tüm bunlarla ilgili amaç bu tür ve reddetme aracının Search Console'daki ana özellik gibi olmamasının nedeni budur. Açıkça arıyorsun. Bunların hepsi bilerek yapılıyor çünkü çoğu site için bağlantılara çok fazla odaklanmanız gerekmiyor. Reddetme aracıyla ilgili hoşuma giden şey, bununla ilgili endişeleriniz varsa, yine de oraya gidip şöyle diyebilirsiniz, Tamam, biliyorum birkaç yıl yaptığımız bu bir avuç şey var. önce ve bunun için gerçekten endişeleniyorum. O zaman onları reddetmek benim açımdan sorun değil. Dışarı çıkıp tüm bu şeyleri özellikle aramazdım. Ama eğer biliyorsan ve gerçekten endişeleniyorsan, o zaman bir bakıma onunla ilgilenebilirsin.

Soru 19:27 - Müşteri web sitelerimizden biri hakkında bir sorum var. Yeni Güney Galler'de üç şehirde kulüpleri var. Ve her kulübün web sitesinde bir alt alan adı vardır. Artık web sitelerine herhangi bir sayfa eklediklerinde, her bir alt alan için sayfa oluşturuyorlar. Son zamanlarda kulüp faaliyetleriyle ilgili bir sayfa eklediler ve bu sayfayı tüm alt alan adlarına eklediler. Bu, sayfa başlığının farklı olması dışında tüm alt alanların aynı içeriğe sahip olduğu anlamına gelir. Çünkü Sydney'e eklediklerinde, başlık etiketine konum adlarını eklerler. Newcastle için eklediklerinde, başlık etiketine Newcastle'ı eklerler, ancak sayfadaki içeriğin geri kalanı aynıdır. Yani 50 alt alana sahip oldukları ve başlık dışında aynı içeriğe sahip 50 sayfa oluşturdukları için sorun olur mu?

Cevap 20:36 - Bu kulağa biraz verimsiz gibi geliyor, sanırım. Yani, zaten konuyu gündeme getiriyorsunuz ve sanki bu farklı şekilde yapılabilecek bir şey gibi görünüyor. Hepsi aynı içeriğe sahip 50 alt alan adınız varsa ve yalnızca başlık etiketini değiştiriyorsanız, muhtemelen bize çok fazla yararlı içerik sağlamıyorsunuz demektir. Bu yüzden diyeceğim ki, işleri daha da fazla alt etki alanında seyreltmek yerine, bir şeyleri birleştirmek ve gerçekten güçlü sayfalar yapmak daha mantıklı.

Soru 21:44 - Bir sayfa oluşturup ardından diğer konum sayfalarına standart URL kullanmaya ne dersiniz? Sadece etkinliklerinden bahsedeceğimiz bir sayfa oluşturmak istiyorum ve bağlantıyı diğer konum sayfalarının standart URL'si olarak kullanacağım.

Cevap 22:10 - Konum-- evet. Bence bu mantıklı olabilir çünkü o zaman bir şeyleri tekrar birleştiriyorsun. O zaman bir sürü seyreltilmiş sayfa yerine güçlü bir sayfa hazırlıyorsunuz.

Soru 22:20 - Çünkü birisi web sitesini ziyaret ettiğinde ve konumunu seçtiğinde ne oluyor, o kişiyi otomatik olarak belirli konumu için belirttiği alt alana yönlendiriyor. Bu nedenle, o alt alandaki sayfaya ihtiyaç duymalarının nedeni budur. Sanırım bu yüzden tek sayfayı tutup standart URL'yi eklersek, şu anda sahip olduğumuz tek seçenek bu.

Cevap 23:08 - Tamam, ancak sitede teknik nedenlerle olması gereken ayrı sayfalarınız varsa ve standart koyarsanız, bu iyi bir yaklaşım.

Soru 23:21 - Bu, farklı yerlerde birden fazla franchise'ı olan ve her franchise için esasen aynı içeriğe sahip olan bir işletmenin farklı bir şehir veya ilçede ya da her neyse, ve sizin bakış açısı tek bir sayfaya geri mi dönüyor?

Cevap 23:34 - Bunun her zaman biraz zor olduğunu düşünüyorum çünkü belirli bir yerde bu tür bir işletme arayan insanları doğrudan o işletmeyle ilgili bir tür bilgi sayfasıyla dengeliyorsunuz. Yani bu, bazen bir iş için ayrı tutmanın mantıklı olduğu bir şey. Bazen genel bilgilerin merkezi bir yerde olması ve adrese, açılış saatlerine, bu tür şeylere daha fazla odaklanan konum açılış sayfaları gibi olması mantıklıdır.

Soru 24:12 - Evet, benim-- Yaptığınız kurallı noktayla ilgili bir sorum var. Bu, ekibim ve benim birkaç yıldır sahip olduğumuz bir soru. Ve hala çözümü tam olarak bilmiyoruz. Yani çok, çok ürün ve çok, çok kategori içeren büyük bir e-ticaret sitesiyle uğraşıyorsanız. Diyelim ki sayfa içeriğini biraz değiştiren, ancak belki de kendi URL'sine sahip olmak için yeterli olmayan pek çok farklı filtre ve yön ve bu tür şeyler içeren bir kategori sayfasındasınız. Ancak bazı durumlarda belirli filtrelerle, bir site URL'sine sahip olmayı haklı gösterebilir. Peki bu durumda sürünerek nasıl başa çıkıyorsunuz? Kurallı bir etiket işe yarıyor mu? Dizine alınmış tek bir sayfa oluşturmak kapsamlı bir çözüm mü? Veya belirli yönler ve filtreler indekslememeye veya robot kullanmaya bakmalı mısınız, yoksa büyük e-ticaret siteleri için bunu nasıl kontrol ediyorsunuz?

Cevap 24:57 - Bu çok zor. Şu anda bu konuda gerçekten net bir rehberimiz olduğunu düşünmüyorum. Yani bu, tüm bu farklı türdeki yöntemlerin anlamlı olabileceği bir şey. Genel olarak, bunun için robots.txt kullanmaktan kaçınmaya çalışıyorum çünkü URL'leri bulabiliriz. Sadece orada ne olduğunu bilmiyoruz. Bu nedenle, sunucuda çok fazla yüke neden olan sorunları gerçekten görmüyorsanız, indeks yok, rel kanonik gibi şeyler kullanmaya çalışıyorum. Belki robots.txt kullanmak yerine bir dizini ne taramamız gerektiğini biraz daha net hale getirmek için huni türlerine yönelik dahili bağlantılarla birlikte rel no-follow kullanırsınız. Ancak, şeyleri ne zaman dizin düzeyinde bir sayfada birleştireceğinize ve ne zaman dizine eklenmesini engelleyeceğinize, ne zaman yumuşak bir şekilde tek bir kurallı URL'ye yönlendireceğinize dair karar, bu-- bu bazen gerçekten zor.

Soru 25:53 - Çünkü bazen sayfa içeriği çok farklı olduğunda standartlar göz ardı ediliyor.

Cevap 25:57 - Kesinlikle. İçerik farklıysa bu sayfalar farklı diyebiliriz. Kanonik kullanmamalıyız. Oysa diyebilirsiniz ki, bu gerçekten dizine eklemek istemediğim bir şey. Belki de indekssiz bir kuraldan daha anlamlı olabilir. Ayrıca ikisini birleştirebilirsiniz. Bunları birleştirmeyi önermiyoruz çünkü bizim için gerçekten zor, peki, ne demek istiyorsun? Bunların aynı olduğunu mu söylüyorsunuz, ancak biri indekslenebilir ve diğeri indekslenebilir değil, o zaman aynı değiller. Ancak, yıl boyunca orada neyin işe yarayabileceği konusunda net bir rehberliğe sahip olacağını hayal ettiğim bir şey. Ancak özellikle gerçekten büyük e-ticaret sitelerinde gezinme tarafı oldukça zorlayıcı olabiliyor.

Soru 26:46 - Son zamanlarda birkaç müşterimle birlikte çözmeye çalıştığım bir senaryo var. Hâlâ HTTP kullanan ve sayfa bir süredir güncellenmediği ve içeriğin eski, modası geçmiş ve genel olarak eski olduğu için aşağı yukarı terk edilmiş görünen bir siteyi neden temelde çöpe atamadığımızı anlamaya çalışıyoruz. biraz zayıf ve bu yüzden bu konuda birkaç teorim var. Bunun bir kısmı, sanırım, belki de dizide o kadar uzun süredir var ki, hepiniz bir tür güven faktörü oluşturmuşsunuzdur. And it's kind of hard to unseat them. That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

Soru 42:29 - Seyahat acentalarının web siteleri ile ilgiliydi. Arama kentindeki en ucuz 10 otel gibi dinamik içeriği göstermek için dahili aramayı seçiyoruz, tamam mı? Böylece sayfa çerçevesi anında yüklenir. Ancak, web sitesinin bu aramayı arkada gerçekleştirmesi gerektiğinden ve ardından aramayı yapan kişi için en ucuz 10 oteli listelemek için sonuçları karşılaştırıp hassaslaştırdığından, en ucuz 10 otel sonucu, arama yapıldıktan sonra 30 saniye gibi dinamik olarak yüklenir. oteller. Bu yüzden onları listelemek biraz zaman alıyor. Yani şu anda Googlebot sadece sayfanın arka planını görüyor. Ardından, bu 10 boş yer tutucu, dahili arama yapıldıktan kısa bir süre sonra sonuçların yükleneceği yerdi. Bu, seyahat web sitelerinin bilgileri olabildiğince taze ve olabildiğince doğru getirme eğilimi olduğundan, Google'ın bu konuda ne yaptığını düşünüyorum. Tabii bu sayfalarda diğer tüm web sitelerinin bugünlerde Google'a yaptığı gibi bir miktar statik içerik sıralayabiliriz, eğer söyleyebilirsem. Ancak bu, çoğu kullanıcının şu anda görmek istediği şeyin taze ve ucuz olması amacını ortadan kaldırıyor.

Cevap 44:00 - Yani orada yüklenmezse dizine ekleyemiyoruz. Ancak genellikle, bu daha çok JavaScript'i işleyemememiz veya belki de oradaki içeriğe gerçekten erişmemizin engellenmesiyle ilgili bir meseledir. Yani işe yarayacak bir şekilde yapabileceğiniz bir şey. Asla işe yaramayacağı tasarım gereği değil. Bu, JavaScript hatalarının olup olmadığını, bir şeylerin engellenip engellenmediğini görmek için mobil uyumlu test gibi şeyleri kullanarak ayrıntılara girebileceğiniz ve oradan bir tür hassaslaştırabileceğiniz bir şey. Yani imkansız değil ama biraz uğraş gerektiriyor.

Soru 44:42 - John, Google'dan hiçbir şeyin engellenmediğinden emin olmak için bunu araştırdım. Google'ın yapmasını istediğimiz tek şey, dinamik içeriğin sayfalara yüklenmesi için biraz beklemek, biliyor musunuz? Bu bir sonraki adım, eğer söyleyebilirsem, çünkü bu sayfa sonsuz bir kaydırma gibi olmasa da, diyelim ki Facebook, sınırlı bir 10 sonuç sayfası. Yani sonlu. Sınırlı. Mesele şu ki, Google dinamik içerik için biraz beklemeli. Sana sadece bir örnek veriyorum. Ama eminim vahşi doğada başka birçok örnek vardır. Ve bu, insanların dinamik içeriği görme eğilimi olduğu için, bir şekilde işleri sıraladıkları ve harcadıkları zaman giderek azaldığı için-- insanlar web sitelerinde daha az zaman harcıyorlar ve mümkün olduğunca hızlı bir şekilde bulmak istiyorlar. mükemmel sonuçlar, eğer söyleyebilirsem. Bu donanıma bakıp bakmadığınızı merak ediyordum.

Cevap 45:55 - Yani render için biraz bekleyeceğiz. Ancak insanlar sabırsızsa, bu yine de daha hızlı olmanız gerektiğinin bir işaretidir. Yani yine de buna bakacağım bir şey. Ama sanırım ekran görüntüsüne bakıyorum, oradaki tüm öğeler sadece gri kutularda bloke edilmiş. Bu, muhtemelen bir zaman aşımından ziyade daha çok teknik bir sorun gibi geliyor.

MARTIN SPLITT : Evet. Söylemek üzereydim ki, JavaScript ve benzeri şeyler kullanıyor olsa bile, sorunsuz dizine alınan birçok dinamik içerik görüyoruz. Dolayısıyla, zaman aşımına uğradıysak, aramaların ne kadar sürdüğü konusunda bir sorununuz olabilir ve bu aslında başka bir yere de yansıyabilir. İçeriğin bitmesi için epey bir süre bekliyoruz.

Soru 46:48 - Bana bir zaman aralığı verebilir misiniz? ne kadar bekliyorsun

MARTIN SPLITT : Bu gerçekten, gerçekten zor çünkü temelde-- yani, size bir zaman çerçevesi veremememizin nedeni, zaman-- ve bu kulağa gerçekten tuhaf gelecek ve bir saniyeliğine bana katlanacak. . Googlebots oluşturma işleminde geçirilen süre özeldir ve Einstein'ın ilkelerine uyması gerekmez. [Gülüşmeler] Yani pek bir şey söyleyemem. Söyleyebileceğim, ağ meşgulse ve ağ darboğaz ise, muhtemelen bekliyoruz, ancak sadece bu kadar uzun süre bekliyoruz. Yani bir dakika veya 30 saniye sürerseniz, muhtemelen aradaki zaman aşımına uğradık demektir. Ama hiç zor değil-- size 10 saniye söylersem, işe yarayabilir de yaramayabilir de. Size 30 saniye söylersem, bu işe yarayabilir de çalışmayabilir de. Bu yüzden bir rakam söylememeyi tercih ederim. Ne diyeceğim, mümkün olduğunca çabuk içeri girmeye çalış. Ve bunu hızlı yapamıyorsanız, arama sonuçlarını önbelleğe almak gibi bir şey deneyin, böylece arama az ya da çok gerçekleşir - veya sayfadaki sonuçların üretilmesi giderek daha fazla veya daha az anında olur. Veya bunun için bir geçici çözüm olabilecek dinamik oluşturmayı deneyin. Ayrıca deneyebileceğiniz şey, onu sunucu tarafına koymayı deneyebilir ve temel olarak ilk geçişte mümkün olduğunca fazla içerik oluşturmaya çalışabilirsiniz. Bu, özellikle yavaş ağlardalarsa, kullanıcılarınıza da yarar sağlayan bir şeydir. Yani evet. Maalesef basit bir cevabım yok, ancak Googlebot'ta vakit geçirmek çok eğlenceli.

Cevap 49:29 - Bunun muhtemelen web sitesinin gerçekte ne yaptığına bağlı olduğunu düşünüyorum. Oluşturma hızıyla ilgili zor olan şeylerden biri, bir sunucudan gönderilen birçok şeyi bir tarayıcıda olduğundan daha fazla önbelleğe alabilmemizdir, çünkü dizinimizi bu şeylerin çoğu için kullanabiliriz. Bu nedenle bazen JavaScript bizim tarafımızda önbelleğe alınırsa, onu getirmemiz gerekmez. Ardından, süreleri tekrar karşılaştırırsanız, kullanıcının gördüğüyle eşleşmeyecektir. Webpagetest.org'da gördüklerinizle eşleşmeyecek. Bu yüzden gerçekten biraz zor ve daha uzun sürdüğünü bildiğimiz kısımlar için biraz daha sabırlı olacağız. Ama test etmeyi zorlaştırıyor. İşte bu yüzden, şu anda mümkün olduğu kadar çok hata gösteren tüm bu test araçlarına sahibiz, bu, örneğin, hiç çalışmıyor mu? Bazen işe yarıyor mu ve bazen ortaya çıkan sorunlar nerede?

Soru 50:29 - Çok büyük web siteleri için, XML site haritalarındaki URL'lerin sırası önemli mi?

Cevap 50:34 - Hayır. Umurumuzda değil. Bu bir XML dosyasıdır. Tüm verileri çekiyoruz. Hepsini aynı anda işliyoruz.

Soru 50:44 - Peki ya site haritalarındaki öncelik parametresi?

Cevap 50:47 - Bunu hiç kullanmıyoruz. Bu, başlangıçta, ah, bu, sayfaları ne sıklıkta taramamız gerektiğini bulmak için yararlı olabilir diye düşündük. Ama web yöneticilerine sorarsanız, her şeyin öncelikli olduğunu söylüyorlar. Bu çok önemli. Ve sanırım, site haritalarındaki değişiklik sıklığıyla da benzer şekilde, insanların bize her zaman bir şeylerin değiştiğini söylediğini, ancak en son geçen yıl güncellendiğini fark ediyoruz. Yani değişiklik sıklığı ve tarihi varsa, o bilgiyi yine de tarihten alırız. Yani değişim frekansını görmezden geliyoruz.
Soru 51:35 - Kurumsal şema sadece ana sayfaya mı, iletişim sayfasına mı yoksa tüm sayfalara mı eklenmeli?

Cevap 51:42 - Bildiğim kadarıyla bu sadece ana sayfa. Bilmiyorum. aranızda bilen var mı

Cevap Liz 51:4 7 - Genellikle kurumsal ve kurumsal olan tek bir sayfa olması gerekiyordu. Genelde tavsiye budur.

MARTIN SPLITT 52:00 - Sanırım hangisi olduğu önemli değil-- hangi sayfalar olduğu kadar önemli değil, tıpkı sahip olduğunuz her sayfaya koymamanız gibi, sanırım daha önemli olan kısım. Sanırım buna bağlı-- eğer bir haber sitesiyseniz, bunu iletişim sayfasına veya hakkında sayfasına veya başka bir şeye koymak muhtemelen mantıklıdır. Oysa bir mağaza veya restoran web sitesinde, ana sayfaya koymak muhtemelen sorun değil.

JOHN 52:20 - Bence bu durumda da bizim için o kadar önemli değil çünkü onu ana sayfa veya iletişim sayfası gibi bir yerde bulabilmemiz gerekiyor. Ama başka bir yerde olması bizim için hiçbir şeyi değiştirmez. Bu yüzden, bunu karşılaştırmamak için en büyük şey, bazen insanların sitelerindeki her sayfa için yıldızları ve arama sonuçlarını alma umuduyla web sitesinin tüm sayfalarına şirket incelemesi gibi koyduğunu gördüğümüz inceleme işaretlemesidir. Ve bu bizim için kötü olurdu. Ama iletişim bilgileri, eğer bunu işaretlemişseniz, bu-- Bunda bir sorun görmüyorum.
Soru 53:05 -Kullandığımız Google web sitesi hız testi çok yavaş sayfa yükleme süreleri kaydetti, ancak yurtdışındaki meslektaşlarımızla yaptığımız bağımsız testler çok hızlı bir sayfa yükleme süresi gösterdi. Bu yanlış kayıt Google önlemleri, sitemizin Google algoritmasında nasıl sıralandığını etkiler mi?

Marie Haynes: Bu benim sorum değil, ancak biraz bağlam vermek gerekirse, sayfa hızı için yeni Deniz Feneri verileri, Sayfa Hızı İstatistikleri'nin eskisinden çok daha sert. Yani Page Speed ​​Insights'ta 80 gibi bir puanı olan bir şey Lighthouse'da kırmızı 29 olabilir. Bu iyi bir soru. Bunun nedeni olabilir mi-- çünkü mobilde çok yavaş sitelerin sıralamasının düşürülebileceğini biliyoruz. Öyleyse, Deniz Feneri testinde kırmızıdaysanız, gerçekten bir şeyleri iyileştirmemiz gerektiğini çünkü bir düşüşe neden olabileceğini söylesek iyi mi, yoksa bir kesinti mi var?

Cevap 54:07 - Yani harici araçların ve sosyal amaçlı kullandığımız her şeyin bire bir eşleştirilmesine sahip değiliz. Evet, bunu söylemeyi gerçekten zorlaştırıyor, ancak aramada, gerçek, ne olduğu, laboratuar testi verilerinin bir karışımını kullanmaya çalışıyoruz, bu bir tür Deniz Feneri testi gibi ve Chrome UX rapor verileri, esasen ne ölçtüğümüz şey, web sitesinin kullanıcılarının göreceği şeydir.

MARTIN SPLITT 55:37 - Örneğin, Lighthouse'un özellikle orta uçta bir 3G bağlantısı için ölçüm yaptığını veya orta performanslı bir telefon gibi, evet, görmek önemlidir. Yani, temel olarak, ofisinizde gerçekten iyi bir kablolu bağlantıya veya gerçekten iyi bir Wi-Fi bağlantısına sahip yeni bir Apple McIntosh veya yeni bir hızlı Windows bilgisayarındaysanız, elbette, iki saniyelik bir yükleme süresi görüyorsunuz, ancak Telefonu vahşi doğada olan gerçek bir kullanıcı muhtemelen bunu görmez. Bu, web sitenizi daha hızlı hale getirmekten asla zarar gelmez gibi durumlardan biridir, ancak bunun içeriden bakış açısından nasıl görüneceğini söylemek gerçekten çok zor, çünkü mutlaka birini eşleştirmek zorunda olmayan çok özel metrikler kullanıyoruz. Araçların ortaya çıkardığı şeylerden biri... Elbette bunu düzeltmek önemlidir, çünkü kullanıcılarınızın web sitenizde sonsuza kadar beklemesini istemezsiniz. Bu sana zarar verecek. Bu, kullanıcılarınıza zarar verecek. Bu sadece aramada sana zarar verecek. Ama ben ödeme yapmıyorum-- Sadece araçlara bakın derim. Araçlar size iyi olduğunuzu söylüyorsa, bunun için çok fazla endişelenmemelisiniz. Araçlar size gerçekten iyi olmadığınızı söylüyorsa, o zaman neden söylediğini bulmak için harcanan zaman bence-- eğer söylediği şey alakalıysa, boşa gitmiş demektir. Siteyi daha hızlı hale getirmeyi tercih etmelisiniz.

Mobil performans her şey için olduğu gibi kullanıcılarınız için de çok önemli bir faktör. Bu yüzden web sitenizin gerçek dünya koşullarında iyi performans gösterdiğinden emin olun derim. Hatta belki ucuz bir telefon alıp ara sıra web sitesini deneyin ve eğer-- bu yapmayı sevdiğim bir şeydi ve birlikte çalıştığım geliştirme ekibiyle Google'a katılmadan önce de yapardım. Ben de, bak, bu web sitesini bu telefonda kullanmak istiyor musun? Sanki, oh, bu korkunçtu. Ben, mhm, evet, belki bu konuda bir şeyler yapmalıyız.

JOHN - Chrome'da ayarlayabilir ve farklı bağlantı hızlarını deneyebilirsiniz. Mobil emülatör. Bence bunlara bakmak gerçekten güzel şeyler ve ayrıca kullanıcı tabanınıza bakın. İnsanların web sitenizi yalnızca ileri teknoloji bir iPhone ile kullandığını görüyorsanız, analitik verilerinize bakın. yavaş ve düşük kaliteli cihazlara sahipler, o zaman belki bu daha fazlasıdır.