SEO Hakkında Bilmeniz Gereken 5 Şey Chris Green ile Uçta

Bugün, kahve ve viski yudumlarken sakalını kaşımaktan hoşlanan bir atlama ipi ile işinizin daha fazlasını uçlarda yürüterek SEO yaşam kalitenizi nasıl artırabileceğinize bir göz atacağız. belki ideal olarak bir İrlanda Kahvesi. Arama problemlerinin eğiticisi, konuşmacısı ve çözücüsüdür. Kıdemli SEO danışmanı Chris Green, In Search SEO podcast'ine sıcak bir karşılama.

Beş görev şunlardır:

• Bölünmüş test
• Yönlendirme yönetimi
• Bot erişim günlüğü
• Site haritası oluşturma/yönetimi
• İçerik enjekte etme

Chris: Bana sahip olduğun için teşekkür ederim, David.

D: Chris'i chris-green.net'te bulabilirsiniz. Chris, öyle gelmiyorsun ama her zaman uçlarda mısın?

C: bilmiyorum. Onlarca yıldır SEO yapan herkesin biraz gergin olacağını düşünüyorum. Kısa cevap, evet. Uzun cevap, buna bağlı. Bekle, bu başka bir kısa cevap. Penguenler ve pandaların tekmelemeye başladığı zamanlarda SEO'ya girdim, bu yüzden evet, yeterince bıçak kenarında olduğuma inanıyorum. Tamamen dürüst olmam gerekirse, bundan kurtulduğumu hiç sanmıyorum.

D: Bir süre önce kenar hakkında sohbet ettiğinizi hatırlıyorum. Kesinlikle bu konuda önde gelen düşünürlerden birisiniz. Bu yüzden bunu tartışmak için sizinle birlikte olmak harika. Ve bugün, uçta daha iyi ele alınan beş SEO görevini paylaşacaksınız. Bir numara ile başlayarak, SEO bölünmüş testi.

1. SEO Bölünmüş Testi

C: Yani SEO içinde testler sonunda biraz daha fazla kazandı. Ve SEO'yu test etmenin gerçek basitliğinden, Analytics ile kontrol etmekten, işe yarayıp yaramadığını kontrol etmenin birçok yolu vardır. Bu, teorik olarak SEO'da hepimizin yapması gereken en kolay yoldur. Ancak "uç"un işe yaradığı yol, bir grup içindeki sayfaların %50'sine bir değişikliği etkili bir şekilde dağıtmak ve Google'ın test sayfalarını ve ardından kontrol/değiştirilmemiş sayfaları ziyaret etmesine izin vermektir. Bu, web sitenizdeki sayfa gruplarında değişiklik yapmadan değişiklik yapmanıza yardımcı olur. aslında kod tabanını değiştirmek veya sunucuya veya CMS'ye herhangi bir ek gereksinim eklemek.Bu, bu sayfalarda insanlara sürecin çeşitli noktalarında yapabileceğiniz farklı sürümleri göstereceğimizi söyleyen ekstra bir katman eklemek gibidir.

Bu nedenle kenar, sunucudan geliyormuş gibi görünmesini sağlar, bu da dizine eklemek için harikadır çünkü Google onu yalnızca kodmuş gibi alır. Bu testi istemcide de yapabilirsiniz. Bu nedenle, temelde daha az güvenilir olan JavaScript'i kullanmak işe yarayabilir, ancak Google'a çok daha fazla önem verir. Böylece avantaj daha hızlı hale getirir ve aldığınız sonuçlara daha fazla güvenebilirsiniz. Mükemmel değil, ama çok daha iyi ve çok daha sağlam.

D: Pek çok SEO uzmanı kendi komut dosyalarını mı oluşturuyor yoksa bu bölünmüş testleri çalıştırmak için basit komut dosyaları mı kullanıyor? Veya Edge ile birlikte kullanmanızı tavsiye edeceğiniz uzman bir split test yazılımı var mı?

C: Yüce olandan gülünç olana gidebilirsiniz. Sadece avantajdan bahsediyorsanız, muhtemelen bu alanda kurulmuş bir avuç oyuncu olduğunu söyleyebilirim. Yani Search Pilot, resmi olarak ODN, kelimenin tam anlamıyla uç altyapı üzerine inşa edilmiştir. Tüm bunları kontrol etmenizi sağlayan bir meta CMS oluşturdular. Ve sonra bunun üzerine gerçekten akıllı analitik ve analiz metodolojisini çektiler. Buna sahip olmak veya buna başlamak için kesinlikle hiçbir iddiada bulunamam; ne münasebet. Onlar en büyük öncülerden bazıları. Ancak, Akamai, Cloudflare ve Fastly gibi tüm farklı uç altyapı türlerinde uç ile yapabileceğiniz şey, bunu kendiniz yapmak için komut dosyalarını yazabilmenizdir. Ve uçtan bahsederken, bu testleri yapmak için ihtiyacınız olan şey, kontrol sayfaları olacak, bunlar test olacak olan sayfalardır. Ardından, test sürümünde etkili bir şekilde değişiklik yapan komut dosyası. Ve bununla ilgili karmaşıklıklar, testin ne kadar karmaşık olduğuna bağlıdır. Örneğin, yalnızca sayfa başlıklarını yeniden yazıyorsanız, bu gerçekten yapılacak oldukça basit bir şey haline gelir. Ben mühendis değilim. Bazen kendi iyiliğim için fazla meraklı olan bir SEO uzmanıyım, ancak bu şeyler, özellikle Cloudflare'de, muhtemelen oradaki en erişilebilir öğelerden biridir. Ben ve Simon Thompson yıllar önce, ikimiz de Tool Spark adlı bir ajans yapımı aracındayken, bu daha çok bir beta ve bir kavram kanıtı olarak ortaya çıktı. Ancak bu, Cloudflare altyapısının üstündeydi. Ve bu, yine, ayrık testleri bir uçta, esasen, o noktada ücretsiz olarak dağıtmanıza izin verir, ancak bu, daha çok bir sanal alan haline geldi. Böylece, kendinizinkini oluşturmak için kurumsal düzeydeki yazılımı doğrudan geçebilirsiniz. Ve sonra bunu çalıştırabileceğiniz bazı yeni ortaya çıkan platformlar var. Ama bence bir SEO uzmanı olarak, oluşturduğunuz yığının ne olduğunu düşünmeniz gerekiyor. Başka kimlere katılmanız gerekiyor? Riski azaltmanız ve hakları yayınlamanız ve geçmişleri değiştirmeniz gerekiyorsa, Enterprise seçeneğine geçersiniz. Önyükleme yapan ancak gerçekten test etmek isteyen birini bulduysanız, doğrudan uçta inşa edin. İşçiler için kod yazabilecek birini bulun ve bir şeyler test edebilirsiniz.

D: Uçta yaklaşık üç saat boyunca bölünmüş test hakkında konuşabileceğimizi hissediyorum. Ancak uçta daha iyi ve daha etkili olarak önereceğiniz ikinci alana, yönlendirme yönetimine geçelim.

2. Yönlendirme Yönetimi

C: Evet, yönlendirmeleri yönetmek genellikle zahmetlidir çünkü büyük web siteleriniz veya çok sayıda farklı altyapınız varsa, farklı yönlendirmelerin nerede kontrol edildiğini ve yönetildiğini, hangi sırayla tetiklendiğini, karmaşık olup olmadıklarını vb. bilmek bir kabustur. . Ve neredeyse her büyük organizasyonda bu sorun var. Karşılaştığınız en büyük sorunlardan biri, insanları farklı sunucular veya farklı CDN katmanları arasında tek bir yönlendirme işlemiyle geçirmenizdir, bu da verimsizdir. Yani CDN'den geçerseniz, sunucuya giderseniz, sunucu başka bir yere gitmeniz gerektiğini söyler ve sonra başka bir yere gidersiniz ve sonra başka bir yere yönlendirilirsiniz, bu gerçekten verimsizdir, biraz maliyetlidir ve yönetmek için kabus.

Şimdi, CDN'nin veya kenarın oturduğu yer nedeniyle, kullanıcının karşılaşacağı ilk şey budur. Tüm yönlendirmelerinizi oradan yönetirseniz ve o noktada değişiklikleri düzleştirdiğinizden emin olursanız, ki bu nispeten kolaydır... İlk olarak, yönlendirme sayısını azaltabilirsiniz. İkincisi, sizi yeniden yönlendirmeden önce onu Origin sunucusuna yapmazsınız. Böylece, aslında Origin'e giden trafik seviyesini azaltırsınız ve yönlendirme, doğrudan o sunucudan çok daha hızlı gerçekleşir. Ve son olarak, disiplininiz varsa ve bunu doğru bir şekilde uyguladıysanız, tüm farklı platformlardan bağımsız olarak tüm yönlendirmeleri gözden geçirmeniz gereken tek bir yeriniz var. Ve bu basitlik, takıma disiplin aşıladığınızda, dürüst olmak gerekirse, bunu biraz zahmetsiz kılıyor.

D: Ve üç numara, bot erişim günlüğü.

3. Bot Erişim Günlüğü

C: Bot erişim günlüğü ilginç bir tanesidir. Daha önce bir günlük dosyası denetimi yapmayı denediyseniz ve analizi yapmak için erişim günlüklerime ihtiyacım olduğunu söylediyseniz, DevOps'a ya da hernere gidin, ya size şaşkın bir görünüm verecekler ya da diyecekler ki hayır, bu çok büyük, tutmuyoruz ya da bir günlük değerinde saklıyoruz ya da alabilirsin ama lütfen uzun bir kuyruğa katıl. Bu gerçekten zorlayıcı. Dahası, önbelleğe almada CDN kullanıyorsanız, sunucu erişim günlükleriniz zaten tüm bot trafiğini almayabilir. Yani günlükleriniz tamamlanmayacak. CDN'den geçen her şey, önbelleğe alınmış olsun veya olmasın tüm trafik tarafından alınır. Ve bu günlük verilerini etkin bir şekilde depolamak ve onu Sumo mantığı veya başka bir depolama türü gibi bir hizmete aktarmak için kenarı kullanıyorsanız, bulmaya çalışmak yerine tüm bu verileri uçta sifonlama fırsatına sahipsiniz. sunucularınızdan. Ancak, çalışanları doğru türde bir mantıkla veya bu noktada mantıkla yazıyorsanız, bunu yalnızca istediğiniz bot trafiğini yakalayacak şekilde ayarlayabilirsiniz. Bu nedenle, genellikle Googlebot veya arama motoru botları kullanır, ancak insanların sahtekarlık yapmadığından emin olmak için IP adreslerini doğrulama gibi şeyler yapabilir ve yalnızca ihtiyacınız olan erişim verilerini toplayabilirsiniz, bu da depolama alanını büyük ölçüde azaltır. Ve örneğin Content King gibi bazı araçlar, doğrudan bu seviyeden veri toplamak için bazı CDN'lerle doğrudan arayüz oluşturabilir. Doğru erişim düzeyine sahip olduğunuzu ve DevOps'un evet dediğini varsayarsak, bu günlükleri doğrudan toplamaya başlayabilirsiniz, bu da nispeten az kaldırma ile bazı teknik SEO analizleri yapabileceğiniz anlamına gelir.

D: Yalnızca günlük dosyalarına bakmanın faydalı olduğu sayfalar açısından belirli bir boyutta web sitesi var mı yoksa her SEO'nun günlük dosyalarına mı bakması gerekir?

C: Genel bir kural olarak, web siteniz 10.000 sayfanın altındaysa, günlüklere güvenmeme veya hemen günlüklere gitme eğilimindeyim. Esas olarak, çünkü onlara erişmek bir kabus. Bu verilere kolayca erişebilirsem ve kolayca analiz edebilirsem… yani Deep Crawl gibi büyük SaaS tarayıcılarından herhangi birinin günlük dosyası analizi var. Eğer o verileri alıp analiz edebilirsem, hadi yapalım. Ancak 10.000 sayfanın altındaysam ve bu verileri almak acı vericiyse, o zaman çok üzülmem. Şimdi bu sayfa sayısı biraz keyfi ama eğer bir milyondan fazla sayfanız varsa, logfile size bazı güzel artımlı kazançlar sağlayacak çok fazla bilgi ve içgörüye sahip olacaktır. Bunun altında, muhtemelen buna değmez. D: Ve dördüncüsü, uçta yapılması daha etkili olan görevler, site haritası oluşturma/yönetimi.

4. Site Haritası Oluşturma/Yönetim

C: Bu eşsiz bir tanesidir. Son zamanlarda site haritası oluşturmanın farklı hizmetlerden, farklı sistemlerden sayfalar alması gereken, güncelliğini yitirmiş, çalışmıyor, inanılmaz derecede zor olan her şeyi yeniden inşa etmek için mühendislik vb. API verilerini bir SaaS tarayıcısından alan bir hizmet oluşturdu. Dizine eklenebilir sayfaları çeker ve ardından kenarda bir XML site haritası oluşturur ve onu bu kenar noktasında barındırır. Her gün siteleri taramak için tarayıcıyı etkin bir şekilde kullanıyoruz, her gün yeni site haritasını oluşturuyor ve yeniden oluşturuyor ve onu en son noktaya kadar yayınlıyor. Bazıları bunun, üçüncü bir tarafa ek bir gereksinim getiren aşırı mühendislik ürünü bir çözüm olduğunu söyleyebilir. Ben de aynı fikirdeyim, ancak bazı durumlarda, diğer içerik API'lerini ve çoğu zaman bu verilerin temiz olmadığı, filtrelemeye ihtiyaç duyduğu diğer hizmetleri talep etmeden, tek doğru noktanızı, site haritalarını tek bir yerde oluşturmak çok anlamlıydı. Ve onları uçta barındıran etkili mikro hizmetler yazmak çok daha ucuz, çok daha hızlı ve daha sağlamdı. Açıkçası, buna doğru cevap, onu ilk seferde doğru yapmaktır, ancak bu sadece bir seçenek değildi.

D: İlk seferde doğru inşa etmekten bahsediyorum. XML site haritalarının oluşturulmasını otomatikleştirmenin bir tehlikesi var mı? Çok fazla çöp içermesi için mi?

C: Evet. Aslında, bunun her yerde olduğunu buldum. Daha önce bir CMS'de çalıştıysanız, bir site haritasını taramış ve birinin bazı sayfaları oluşturduğu, site yapısına koymadığı ve orada bıraktığı test sayfalarını görmüş olabilirsiniz. Ve site haritasını oluşturan mantık, dizine eklenebilir olup olmadığını ve diğer tüm öğeleri ve filtreleri kontrol etmiyorsa, yine de başka bir şekilde yayınlanabilir. WordPress kullanıyorsanız biliyorum, Yoast sizin için bu ağır işlerin çoğunu yapıyor. WordPress'in özünde eskisinden çok daha fazlasını yaptığını düşünüyorum. Ama açıkçası, Drupal gibi bir CMS bununla ilgilenmiyor. Ve çoğu zaman insanlar başka nedenlerle site haritasına dahil etmek istemediğiniz sayfaları isteyecektir. Yine, sadece bunun üstesinden geldiğinizden emin olmak ve sınırda olsun ya da olmasın önemli olduğunu düşündüğüm filtreleri inşa ediyorsunuz. Fantezide, yine de Google'a görmesini istemediğiniz verileri besliyor olabilirsiniz. Ama yine de, bunu kenarda yapmak, bunun için çok hızlı ve hafif bir çözüm.

D: Ve beş numara içerik enjekte ediyor. Ne tür bir içerikten bahsediyorsunuz?

5. İçerik Enjekte Etme

C: Web ve dijital odaklı her şey. Bu, daha fazla içerik eklemek için kenarı kullandığınız ve bu içeriğin istemciden ziyade sunucudan geliyormuş gibi göründüğü anlamında, bölünmüş testle biraz örtüşüyor. Örneğin, bloglar hakkında bir alt alan veya alt dizin tartışmasına daha önce dahil olduysanız ve blogu doğru altyapıdan çekemiyorsanız, içeriği etkili bir şekilde birleştirmek için CDN'leri kullanabilirsiniz. İstediğinizi söyleyebilirsiniz. başlığı bu sistemden çekmek, ancak blog içeriğini o sistemden çekmek için. Ve kenarda çok hızlı ve verimli bir şekilde yapılabilir. Birçoğu önbelleğe alınır ve kenarda birbirine dikilir. Ve kullanıcıya gösterildiği zaman, bu hibrit içeriği iki farklı sistemden etkili bir şekilde almış olursunuz. Ve adil olmak gerekirse, bu, doğru eğilim ve inşa edilebilirlik ile köken üzerinde yapabileceğiniz bir şeydir. Ama bunu uçta yapmak, çektiğiniz farklı sistemler neredeyse hiç önemli değil. Neyi çekmeniz gerektiğini açıkça tanımlayabildiğiniz sürece. Ve bunu etkili bir şekilde yapmak için kodu yazabilirsiniz. Çok performanslı, çok hızlı gerçekleşir ve ihtiyacınız olanı size verir.

D: Uzun zaman önce çerçeveleri ve PHP'yi kullanarak içeriği birleştirdiğimi hatırlıyorum. Ve bunların ikisi de bunu yapmanın çok eski moda yolları. Diğer kaynaklardan veya diğer web sunucularından içerik enjekte etmenin herhangi bir dezavantajı var mı? Bunu yapmanın herhangi bir potansiyel SEO dezavantajı olacak mı?

C: Önemli olanlar, bu varlıklar başka URL'lerde mevcutsa ve bunlara endekslenebiliyorsa, doğal bir risk vardır. Bunu yapmaya çalıştığınızın farkındaysanız, bunun olmasını önlemek de aynı derecede kolaydır. Bazı durumlarda, başlığı bir sayfada, gövdeyi başka bir sayfada tutmak ve bunları aynı sayfada göstermek gibi eski çerçeve kümesi yöntemi yerine, diğer hizmetlerden veri beslemelerini kullanıyor ve bunları birleştiriyor olabilirsiniz. Bunun olmasını durdurmak için bunu oldukça kolay bir şekilde oluşturabilirsiniz. Bence önemli olan, bu iki kaynaktan güvenilir bir şekilde içerik almanız ve güvenilir bir şekilde önbelleğe alınması gerektiğidir. CDN düşerse ne olacağı konusunda çok fazla avantaj ve daha karmaşık mühendislik görevleri olduğunu düşünüyorum. Geri dönüş nedir? Ve bu karmaşıklık açısından değişebilir. Büyük bir kuruluşsanız ve 99.99 gibi önemli bir çalışma süresi istiyorsanız, geri çekilmek için başka CDN'ler oluşturabilirsiniz. Ancak, örneğin, birleştirme işlemini birlikte yapmak için CDN'nize güveniyorsanız, bazı CDN sorunları vardır ve bu sayfalardan bazılarının çalışmadığını görebilirsiniz. Ama Cloudflare düşerse, internetin yarısı da gider. Bu durumlarda soru şu ki, aksaklık ortadan kalktığında daha sonra gelip tekrar kontrol etmelerini sağlamak için Google'a uygun yanıtı sunuyor muyuz?

Bence uçla ilgili herhangi bir şey söz konusu olduğunda, en büyük endişe, bu üçüncü taraf hizmetinin devre dışı kalması durumunda ne olacağından kaynaklanmaktadır. Ancak bu, herhangi bir web altyapısının kabusu. Kendi ofisinizde sunucu olsa bile bunu asla koruyamazsınız ve bundan mutlu olursunuz. Bu zaten oldukça eski moda bir yaklaşım. Ancak barındırma için sıfır riskli bir yöntem yoktur. Başkalarına düşebilirsin. Böylece ikili bir CDN stratejiniz olabilir. Bir katmanda Akamai, diğerinde Fastly olabilir. Akamai başarısız olursa Fastly'ye geçer veya tam tersi. Bu inanılmaz derecede sofistike. Ve bu bir Edge vakasının bir Edge vakası. Ancak ne yaptığınızı biliyorsanız ve doğru ayarlarsanız, bunların çoğuna karşı korunmak mümkündür.

D: Gerçekte %100 çalışma süresinin nasıl garanti edileceğine dair bir web semineri tartışma paneli bekliyorum. Bu ilginç olurdu.

C: Mümkün, hiç olmadığı kadar mümkün, bence Cloudflare ve Akamai veya Cloudflare ve Fastly veya Similarweb'i birleştirirseniz, oldukça yakınlaşabilirsiniz ki bu çok ilginç olurdu.

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

Pareto Turşu - Değişiklikleri Yayınla

C: Bu neredeyse benim uç listeme girdi, ama tam olarak değil ve biraz zor. Bu yüzden bazı insanlar doğası gereği bundan hoşlanmayacak, ancak bir şeyler yapmak için kenarı kullanacak. Bu yüzden kısaca Meta CMS'den bahsettik. Bu, Search Pilot ekibinin ve aralarındaki John Avildsen'in dünyaya göstermesine yardımcı olduğu bir şey, ancak aksi takdirde geliştirme kuyruklarında sıkışıp kalacak değişiklikleri yayınlamak için uç noktayı kullanabilirsiniz. Ve bunu yapma fikri, hayata geçirme, konsepti kanıtlama, teknoloji borcu riskini göz ardı etme ve can sıkıcı DevOps'u bir anlığına görmezden gelme fikri, çünkü her ikisi de etkendir. Ancak SEO'daki tüm değer, canlı olması, eyleme geçen içeriğin ve kenarın bunu kısaltabilmesidir. Ve bu güzel değil ve doğru yol değil. Ancak, bazı içerik değişikliklerini canlı olarak yayınlamak ve sıraları atlamak, alternatif altı ay beklemekse ve bu gerçekleşmiyorsa, harika sonuçlar doğurur.

D: Ev sahibiniz David Bain oldum. Chris, In Search SEO podcast'inde olduğun için çok teşekkürler.

C: Bana sahip olduğun için teşekkürler, David.

D: Ve dinlediğiniz için teşekkür ederim. Önceki bölümlerin tümüne göz atın ve rankranger.com'da Rank Ranger platformunun ücretsiz deneme sürümüne kaydolun.