Gerry White ile SEO için Günlük Dosyalarını Kullanmanın 5 Yolu

SEO'nuzu geliştirmek için günlük dosyalarından nasıl yararlanıyorsunuz?

BBC, Just Eat ve Rise at Seven dahil olmak üzere marka ve ajanslarda çalışan SEO endüstrisinde 20 yılı aşkın deneyime sahip bir adamla bugün konuşacağımız konu bu. Arama İçi SEO podcast'ine sıcak bir karşılama, Gerry White.

Bu bölümde Gerry, SEO için günlük dosyalarını kullanmanın beş yolunu paylaşıyor:

• Google'ın sitenize nasıl baktığını görme
• parametreler
• Tarama bütçenizi tüketen alt alanlar var mı?
• JavaScript ve CSS dosyaları
• Yanıt kodları

Gerry: Hey, burada olduğum için mutluyum.

D: İyi ki varsın. Gerry'yi LinkedIn'de Gerry White'ı arayarak bulabilirsiniz. Öyleyse Gerry, her SEO günlük dosyası kullanmalı mı?

G: Hayır, günlük dosyalarını söylediğimde bunun kulağa tartışmalı geldiğini biliyorum, çok büyük miktarda bilgiye sahibiz. Ama dürüst olmak gerekirse, çoğu zaman getirileri azalıyor. Ve genellikle günlük dosyalarına girmeden önce pek çok bilgi bulabilirsiniz. Demek istediğim, Google Search Console bilgilerine bakarsanız, orada çok büyük miktarda bilgi var. Günlük dosyalarına baktığımda, diğer birçok yeri ilk kez tükettiğim zamandı. Her zaman Screaming Frog gibi bir şey veya sahip olduğunuz herhangi bir masaüstü tarayıcısını kullanarak bir siteyi taramanızı ve ardından günlük dosyalarına bakmaya başlamadan önce Google Search Console'a bakmanızı öneririm.

Bunu söylememin ve ne kadar yararlı olduklarından bahsederken neredeyse günlük dosyalarına karşı olmamın nedeni, aslında başlangıçta onlarla çalışmanın oldukça zorlayıcı olmalarıdır. Ve onları gerçekten ele geçirmek ve hatta onlara erişmek biraz beceri, bilgi ve deneyim gerektirir. Ancak bugünle ilgili harika bir şey şu ki, artık günlük dosyalarına neredeyse her zamankinden daha fazla erişimimiz var. Başlangıçta, ben başladığımda, bugün sahip olduğumuz gibi Google Analytics veya herhangi bir analitik yazılımımız yoktu. Günlük dosyası analizi, insanların web sitelerini nasıl ziyaret ettiğine nasıl baktığımızdı. Şimdi, InfoSec ile bir şey yapmadığımız sürece, insanların web sitelerine nasıl baktıklarını anlamak için nadiren günlük dosyalarına bakmıyoruz. Ya da gerçekten garip ve harika bir şeyi teşhis etmek için bir şeyler yapıyoruz.

Ama aslında çoğu zaman çok daha iyi analitik yazılımlarımız var. Bu değişebilir, çünkü aslında, garip bir şey, birçok web sitesinin bir 404 sayfasına kaç kişinin gittiğini takip edememesidir, çünkü çoğu zaman, bir 404 sayfasında çerezleri kabul edeceğinizi asla tıklamazsınız. . Aniden, bunun gibi bazı çok garip soruları yanıtlamak için günlük dosyaları tekrar geri geliyor.

Ancak bugün günlük dosyalarından bahsetmemin ana nedeni SEO amaçlarıdır. Yani evet, eğer büyük sitelerde sorun yaşıyorsanız, büyük bir e-ticaret siteniz varsa, uluslararası, çok dilli, çok yönlü navigasyona sahip devasa bir siteniz varsa, logfiles kesinlikle alınması gereken bir şeydir. dikkate alınmalı ve kesinlikle bir an önce incelenmelidir.

D: Bugün, SEO'nun günlük dosyalarını kullanması gereken beş yolu paylaşıyorsunuz. Bir numaradan başlayarak, Google'ın sitenize nasıl baktığını görün.

1. Google'ın Sitenize Nasıl Baktığını Görmek

G: Evet, Google oldukça tahmin edilemez, neredeyse asi bir çocuk gibi. Garip, çünkü Google'ın siteye nasıl bakması gerektiğine bakmak için sitelere bakabileceğimizi ve tarama araçlarını kullanabileceğimizi söylesem de, Google'ın bir dizi sayfaya veya siteye devam etmeye takıntılı olduğunu öğrendiğimizde genellikle şaşırıyoruz. bir yerlerde garip bir yoldan aşağı. Ya da daha yakın bir zamanda, Odor adlı bir süpermarket için son bir yıldır birlikte çalışıyorum ve bulduğumuz şeylerden biri, Google botunun bir tür analitik yapılandırmasına çok baktığı ve ondan yapay bağlantılar oluşturduğuydu. Google bozuk linkleri buluyor. Ve uzun zamandır neden sayfada olmayan 1000'lerce 404'ü neden bulduğunu anlamaya çalışıyordum. Ancak, analitik yapılandırmasına baktığı ve bundan bir bağlantı oluşturduğu ortaya çıktı. Bu yüzden bunun ne kadar etkisi olduğuna bakıyoruz. Ve Google'ın tüm bu 404'leri bulduğu gerçeğine bakarsak, bu büyük bir sorun olmayabilir. Ama şimdi bu 404'lere ne kadar zaman harcandığını bilmek istiyoruz ve bu küçücük sorunu çözersek, bu sitenin geri kalanının taranmasının %20-30 oranında artacağı anlamına mı gelecek? Orada düzeltirsek fırsat nedir? Her şey, Google'ın siteye neden bu şekilde baktığına ve bulmaması gereken şeyleri bulduğuna bakmakla ilgili.

2. Parametreler

Sıklıkla baktığımız diğer şey ise parametrelerdir. Biliyor musunuz bilmiyorum ama SEO uzmanları her zaman sayfanın kanonik versiyonuna bağlanır. Demek istediğim, genellikle bir sayfanın bazen bir tür dahili izleme veya harici izleme içeren birden çok sürümü vardır. Bir sayfaya bağlantı kurabileceğimiz pek çok yol vardır ve örneğin bir ürün genellikle bir sitede birden çok yerde bulunabilir. Buna iyi bir örnek, Magento olan bir sitede çalıştım. Ve her ürün, her bir kategorinin altında oturuyor gibiydi, bu nedenle, her ürünün yaklaşık 20 versiyonunun olduğunu ve her ürünün taranabilir olduğunu öğrendiğimizde inanılmazdı. Böylece, Google'ın sitede gezinmek için de çok fazla zaman harcadığını biliyorduk. Ve ilginç olan şu ki, bir ürünü kaldırırsanız, Google bir nevi "Ah, ama bende bu ürünün 19 farklı versiyonu var" der ve bu nedenle, kullandıysanız gerçek sayfanın neredeyse kaybolması biraz zaman alır. Google'ın çalışma şeklinden dolayı bir 404 veya buna benzer bir şey. Google, bunun bu sayfanın standart bir sürümü olduğunu görecek. Ancak standart sürümü kaldırırsanız, o zaman farklı olanları kullanmaya başlayacak. günlük dosyasının bize verdiği bilgiler Siteye Google'ın olduğu gibi bakma yeteneği.

Ayrıca durum kodları gibi şeylere bakmamızı da sağlar. Bunun harika bir örneği, değiştirilmediğimi söyleyen bir durum kodu olmasıdır. Ve şu an hayatım boyunca, bunun ne olduğunu düşünemiyorum, bunu bu podcast'ten önce yazmalıydım. Ama temel olarak, "Değiştirilmedim" ifadesi bir web sitesinin tarama hızını büyük ölçüde artırır. Bunun Google'ın saygı duyduğu bir şey olduğunu öğrendiğimde, tüm resimlerle, tüm ürünlerle yapabileceğim şey oldu. , ve çok düzenli olarak değiştirilmeyen tüm bu parça ve parçalar, eğer değiştirilmemiş özelliğini kullanabilirsek ve Google'ın tarama hızını artırabilir, etkinliği artırabilir ve sunucu üzerindeki yükü azaltabilirsek, şunları yapabiliriz: ardından, Google'ın tüm farklı ürünleri bulma yöntemini önemli ölçüde iyileştirin.

Google'ın olaylara bakış açısı, biz istiyoruz, sunucu yöneticileri istiyor ve herkes sunucunun olabildiğince hızlı ve verimli olmasını istiyor. Yine logfiles tarafına dönecek olursak, bugünlerde logfiles'ı uzun yıllar verimli bir şekilde kullanamadık. Çünkü CDN'lerde, genellikle bir sayfanın vurulacağı birden çok yer olduğunu görürsünüz. Ve CDN'nin genellikle bir günlük dosyası yoktu. Bu yüzden tüm bu farklı yerlere bakacağız ve bu sunucuda ne kadar yük olduğunu ve o sunucuda ne kadar yük olduğunu göreceğiz. Ve her şeyi bir araya getirmeye çalışıyoruz ve günlük dosyaları farklı bir formatta olacak. Artık CDN'lerle, bir CDN'nin etkinliğini gerçekten anlamaya başlayabiliriz. Aniden, Sayfa Hızı gibi şeyler, günlük dosyalarını kullanırsak, görüntünün, örneğin görüntülerin kurallaştırılmasıyla, yani birden çok sayfada kullanılan bir görüntü varsa, şu gerçeği anlamaya başlayabileceğimiz gerçeğinden büyük ölçüde etkilendi ve geliştirildi: URL'ler tutarlı olduğu sürece, CDN çalışır ve Google onu daha iyi tarar. Evet, günlük dosyalarının Sayfa Hızını, önbelleğe almayı ve kullanıcılara ve arama motorlarına çok daha verimli bir şekilde hizmet vermeyi iyileştirmeye yardımcı olduğu pek çok farklı yol vardır.

D: Paylaşacağınız beş noktayı inceliyorum. Ve zaten paylaştığınız farklı unsurları var. Bana sadece bir soru sorabileceğim birini hatırlatıyorsun ve bana başka soru sormadan 15 dakikalık bir podcast bölümü veriyorlar. Yani muhtemelen bunu senden daha fazla yapabilecek bir kişi var. Ve bu muhtemelen Duane Forrester'dır. Duane ve ben onun bunu yapması hakkında şaka yaptık, ona sadece bir soru sordum ve ben çekip gittim ve bölümün geri kalanının içeriğini paylaşması için onu yalnız bıraktım. Ama biraz parametrelerden bahsettin. Olmaması gerektiği gibi, tarama bütçesini tüketen alt alan adları olup olmadığını keşfetmek olan üçüncü noktaya değindiniz mi bilmiyorum.

3. Tarama bütçenizi tüketen alt alanlar var mı?

G: Bu aslında Just Eat'e kadar gidiyor. Bir noktada, web sitesinin birden çok farklı alt alan adına kopyalandığını ve bunların hepsinin taranabilir olduğunu keşfettik. Şimdi, ilginç bir şekilde, Citrix gibi araçlara göre bunların görünürlüğü yoktu. Ve yapmamalarının nedeni, hepsinin kanonikleştirilmesiydi. Dolayısıyla, bu kopyaların her yerde olmasına rağmen, Google'ın bu alt alanları taramak için bütçesinin %60 ila %70'inden biraz daha azını harcadığını öğrendiğimizde. Bunların CDN'ler ve diğer teknolojiler nedeniyle aynı şekilde önbelleğe alınmaması nedeniyle, bu aslında çok fazla sunucu yükü oluşturuyordu. Bu bizim için büyüleyici bir şeydi, çünkü bunu gelecekte düzeltilmesi gereken bir sorun olarak görmezden geliyorduk. Çünkü sorunu biliyorduk. Bir tür sorun olduğunu biliyorduk ve bunun hakkında konuşmuştum. Ama günlük dosyalarına bakmaya başlayana kadar önceliğimi kaldırmıştım.

Google'ın burada çok fazla enerji, zaman ve kaynak harcadığını gördük. Ne kadar sunucu yükü yaratıyor? Ne kadar etkisi oldu? Ve sunucunun farklı kaynakları yorumlayamaması nedeniyle ne kadar sunucu yükü olduğunu anlayamadık. Bu nedenle, günlük dosyalarını aldığımızda web sitesinin güvenilirliğini önemli ölçüde artırabilmemiz büyüleyiciydi. Yani alt alan adlarını biliyorduk, sadece günlük dosyalarına bakmaya başlayana kadar bunun ne kadar büyük bir sorun olduğunu bilmiyorduk. Ve sonra aniden, bunun bir an önce düzeltilmesi gerektiğini gördük. Nasıl düzelteceğimizi bildiğimiz şeylerden biriydi, sadece önceliklendirmeydi. Sıranın en altındaydı ve ikinci sıraya yükseldi.

4. JavaScript ve CSS dosyaları

D: Standartlaştırmaya değindiniz ama aynı zamanda özellikle JavaScript ve CSS dosyalarının sorun olabileceğini de söylediniz. Nedenmiş?

G: Sıklıkla yaptığımız şeylerden biri, CSS dosyasına bir parametre ekleyerek önbelleği kırmak. Bunu yapmamızın nedeni, bir CDN veya benzeri bir şey kullanırsanız olan şeydir, CSS'yi her güncellediğinizde, yeni sayfalar veya başka bir şey oluşturuyorsanız, o zaman sorun, önbelleğe alınmış bir CSS dosyanızın olmasıdır. yeni sayfalar bunu kullanamayacak. Ve tüm bu farklı JavaScript ve CSS dosyalarında uzun önbellek sürelerimiz var. Sayfa içinde, JavaScript veya CSS'nin güncellenmesini gerektiren bir şey eklediğimiz anda, içindeki parametreyi biraz değiştirmeniz yeterlidir. Oradan, tüm farklı sunucuların bundan sonra aynı parametre sürümünü kullandığından emin olmamız gerekiyordu. Ve bu, birden çok farklı ekipte, birden çok farklı web sitesinde çalışıyorsanız, her şeye güç veren daha iyi bir JavaScript'te, her zaman bunun doğru sürüm olduğundan emin olduğumuz bir şeydi. Ve günlük dosyaları, belki bir API anahtarını veya benzer bir şeyi güncellememiz gerektiğinden, tüm farklı sayfaların tutarlı bir şekilde doğru JavaScript sürümünü kullandığından emin olmamızın bir yoluydu. Bunu yapmak zorunda olduğumuz pek çok farklı yol vardı. Ve bu, geliştiriciler için çok büyük bir görev olan bir şeydi.

Günlük dosyalarında baktığımız şeylerden biri, eskisinin vurulup vurulmadığı, nereden vurulduğu ve onu düzeltebilir miyiz? JavaScript dosyasının yolunu yazmanın birçok farklı yolu olduğunu da bulduk. Örneğin, bir alt etki alanındaydı, farklı bir ana bilgisayar adı kullandık mı, çünkü ilginç bir şekilde, birden çok farklı web sitesinde çalışıyorsanız, genellikle aynı sunucuya gerçekten erişen farklı URL'ler veya farklı alan adları olduğunu görürsünüz. Ve genellikle bir CDN kullanıyorsanız veya bir alt dizin kullanıyorsanız, bazen çok tutarsız olabilir. Kullanıcı açısından bakıldığında, bir yolculukta aynı JavaScript dosyasına altı veya yedi farklı şekilde basarsanız, onu altı veya yedi farklı şekilde yüklersiniz. Ve bu, kümülatif olarak çok fazla görünmese de, yolculuğunuza birkaç megabayt ekler. Ve bu, elbette, tüm deneyimi yavaşlatır ve sunucuları daha az verimli hale getirir. Ve çok daha fazlası var. Bu nedenle, JavaScript'in, CSS'nin ve diğer parçaların doğru sürümünün her zaman isabet aldığından emin olun. Ayrıca, JavaScript'in parametrelerle veya başka bir şeyle gizlenmesi için bir neden olmadığından da emin olun. Örümcek tuzaklarının oluşturulabileceği pek çok yol vardır; bunlara JavaScript dosyaları dahildir, örneğin içinde bir şeyin etiketlendiği, belki de JavaScript'e doğru mutlak referansı kullanmadıkları yerler. Yani diğer zamanlardan farklı bir dizinde bulunur. JavaScript'in birden çok farklı sayfa tarafından biraz farklı şekilde yüklendiğini fark edebileceğiniz tüm farklı yollar şaşırtıcıdır. Yani evet, çok basit bir şey. Ancak analiz söz konusu olduğunda şaşırtıcı derecede pahalıdır.

5. Yanıt kodları

D: Ayrıca, yanıt kodlarının istediğiniz şekilde iletilmesini sağlamak. Bunun bir örneği, TOS aracılığıyla Google tarafından bazen görülmesi veya görülmemesi gereken veya olmaması gereken bir durumdur. Peki bu neden olur?

G: Yine aynı tarayıcıyı, aynı teknolojiyi, aynı deneyimi ve her şeyi kullanarak web sayfalarını ziyaret ediyoruz. Herkes Screaming Frog denetimi yaptığı için, genellikle kullandıklarımın dışında başka araçlar kullandığımdan emin olmaya çalışıyorum, bu yüzden her türden ufak tefek şeyi kullanmaya çalışıyorum. Ama her zaman bir tür bilgisayar gibiymişiz gibi davranırız. Bu yüzden asla Googlebot'muşuz gibi davranmıyoruz, asla tüm bu farklı şeylermişiz gibi davranmıyoruz. Dolayısıyla, Google botlarının belirli bir dosyaya farklı bir IP adresinden nasıl eriştiğine bakarsanız… CloudFlare gibi birçok teknoloji, Googlebot'muş gibi davranırsanız ve ona Screaming Frog kullanarak erişmeye çalışırsanız, o sizin Googlebot değil, aslında sen busun. Ve bu nedenle, size Googlebot'a nasıl davranacağınızdan farklı davranır. Ve çoğu zaman sunucular, tüm parçaları ve parçaları yapmak için işleri önceden oluşturacak şekilde yapılandırılır. Ve o noktada herkesin sunucudan doğru yanıt kodunu aldığından emin olmaktır.

Ve oldukça basit görünüyor, ancak uluslararası ölçekte ölçeklendirdiğinizde… Coğrafi yönlendirmeleriniz olduğunda, bir kullanıcı veya arama motoru belirli bir sayfaya erişemezse, çünkü birisi bunu ziyaret ederseniz bunu söylemek için bir coğrafi yönlendirme yerleştirmiştir. İspanya'dan web sitesi, sonra gidin ve bu alt dizini yükleyin... Bu nedenle, kök sürümlere veya alternatif sürümlere bakamaz. Bu nedenle, yanıt kodlarının doğru olması gibi şeyler kesinlikle kritiktir. Ve bu şeyleri ne kadar sıklıkla gözden geçirmeniz ve her şeyin doğru bir şekilde kurulduğunu varsaymanız şaşırtıcı. Çünkü defalarca nasıl kurulması gerektiğini biliyoruz. Bunu birine veriyoruz, biri yorumluyor, başkası uyguluyor, başkası da geçiyor. Ve sonra başka biri CDN'de "Oh, belirli bir yerde birinin coğrafi konumunu belirleyebiliriz" yazan bir düğmeyi tıklar. Herhangi bir kişinin yanlış bir şey yapmış olması o kadar da fazla değildir ki, zincirin aşağısında onu etkili bir şekilde hafifçe kıran bir şey vardır.

Pareto Turşusu - Düşük Sarkan Meyve

D: Pareto Turşu ile bitirelim. Pareto, sonuçlarınızın %80'ini çabalarınızın %20'sinden alabileceğinizi söylüyor. Mütevazi düzeyde bir çaba için inanılmaz sonuçlar sağlayan tavsiye edeceğiniz bir SEO etkinliği nedir?

G: Şu anda en sevdiğim şey, çok temel bir Google Data Studio kontrol paneline sahip olmam ve bu da benim alçak meyve dediğim şeye bir göz atmamı sağlıyor. Şimdi, herkes moda tombaladan nefret ediyor. Ama bu benim işim, olması gerektiği kadar iyi sıralamaya sahip olmayan şeylere baktığım yer. Belirli bir sayfa grubu, tarifler, ürünler veya başka bir şey için sıralandıkları tüm anahtar kelimelere bakıyorum. İyi bir örnek, şu anda onlarca 1000'lerce ürün üzerinde çalışıyorum, yüksek gösterim alan tüm sayfalara bakıyorum ama altıncı konumda olabilir ve onları 3. konuma kadar çalıştırabilirim. Ve onda dokuz kez, bunu sadece başlık etiketlerinin ve dahili bağlantıların iyileştiğinden emin olarak yapabilirsiniz. Arama hacmi yüksek olan anahtar kelimelerden hangisinin tıklanma oranını artırmak için biraz daha öne çıkabileceğini bulmak için çok basit şeyler.

D: Sunucunuz oldum, David Bain. Gerry'yi LinkedIn'de Gerry White'ı arayarak bulabilirsiniz. Gerry, Arama İçi SEO podcast'inde olduğunuz için çok teşekkürler.

G: Zevkle. Zaman ayırdığın için teşekkürler.

D: Ve dinlediğiniz için teşekkür ederim. Önceki tüm bölümlere göz atın ve Rank Ranger platformunun ücretsiz denemesi için kaydolun.