SPA/CSR'li Projelerde SEO Stratejisi

Herkese merhabalar, Zeo takipçileri. Bugün biraz daha geliştiricilerin ve proje yöneticilerinin ilgisini çekecek bir konuyla daha karşınızdayız. Bugün birazcık daha teknik bir konudan bahsedeceğiz: yukarıda görülen "single page apps" ve "client-side framework" söylemleri size biraz yabancı gelebilir, eğer geliştiricilik dünyası içerisinde değilseniz. Bunların hepsini yavaş yavaş size açıklayacağız, en basitinden yola çıkarak. Şimdi aslında burada gördüğünüz bu iki kavram, sizin hemen hemen birbirine yakın kavramlar zaten. Sizin daha akıcı bir web deneyimi yaşamanızı sağlamak adına, yeni nesil geliştiriciler tarafından hazırlanan kavramlar. Burada aslında bu sistemin nasıl çalıştığını anlayabilmemiz için önce sistemin temeline inelim. Normal koşullarda siz web'de bir sayfayı açtığınız zaman, aslında "zeo.org" yazıp enter'a bastığınız zaman tarayıcınızda, tarayıcınız bir DNS sunucusuna gidiyor ve diyor ki: "Bana zeo.org'un IP adresini ver."

Yani bana yerini söyle. O da ona dört noktalık bir satırla dönüyor ve diyor ki: "Şu IP'de, git oraya sor." Sonra gidiyor benim tarayıcım, oraya bir istek atıyor: "Bana zeo.org'un bilgilerini verir misin? Burada olduğunu söylediler." diyor. O da ona cevap veriyor. Dolayısıyla burada bir sunucu var, burada bir tarayıcı var; ikisi birbirleriyle konuşuyorlar ve veri transferini tamamlayıp sizin gördüğünüz web sayfasını oluşturuyorlar. Bu güzel bir çalışma, gayet web'in bugüne kadar gelmesini sağlayan ve neredeyse web'deki sitelerin %90'ından fazlasının kullandığı bir teknoloji. Ancak günümüzde daha akıcı sayfa geçişleri vs. isteyen kullanıcılar, şey, geliştiriciler, yeni bir katman daha koyuyorlar buraya. Diyorlar ki: "Burada bir sunucu var, burada bir tarayıcı var; ben araya bir app yapayım, bir app yaratayım." Ama bu app, böyle mobil uygulamalardaki app'imiz gibi düşünmeyin bunu; tarayıcımızın içerisinde yaşayan bir uygulama gibi.

Ve ben burada, sayfada değişen ne varsa, bunu bu app'e yükleyeyim, kullanıcı da buradan bunu alsın. Aslında bana ilk başta diyor ki: "Yiğit, ben sana bir app gönderiyorum, 550 kilobaytlık. Bunu bir al, sonra ben sana bütün değişimleri söyleyeceğim, sen onu app'in üzerinde değiştir." diyor aslında. Ve böylece ben her sayfayı tekrar yüklemiyorum ve çok akıcı bir şekilde bir deneyim elde etmiş oluyorum. İşte o yüzden bunun adı "single page apps". Çünkü tek bir sayfa var, bir kere yükledim; sadece değişen şey, benim sayfada yaptığım işlemlere göre, tıkladığım yerlere göre, bana sistemden gelen dönüşler.

Burada da API sistemi kullanılıyor; yani uygulamaların kendi aralarında konuştukları bir dil. JSON olabilir, XML olabilir. Bu formatta, sadece sayfanın değişen kısmını sunucu gönderiyor. Böylece ne oluyor? Her sayfa arası geçişte neredeyse 20-25 kat daha az veri transferi oluyor ve inanılmaz akıcı bir deneyim oluyor. Bunun avantajlarını konuşacak olursak, tabii ki boyutun azalmasından ötürü en büyük avantajı mobil görüyor. Çünkü neden? Mobil telefonlarımız aslında eskimiş bilgisayarlar, yavaş bilgisayarlar ve her zaman harika internet hızına sahip olamayan ortamda olabiliyorlar. Çünkü yerleri sürekli değişiyor. Öyleyse mobil deneyimde bu "single page apps"ler bize inanılmaz bir avantaj sağlıyor, her şeyden önce. Bunlar nasıl uygulamalardır? Bunları nerede bulabilirim, nasıl test edebilirim diyorsanız, aşağıya sizin için serpiştirdik bunları: React'ler var, Backbone var, Vue.js var, muhtemelen duydunuz; Angular.js var, Ember, Meteor, Knockout gibi birçok farklı şey var.

Hatta ve hatta burada boşluk bulunca bir de Yiğit JS yazdık. Her gün yeni bir client-side framework hayatımıza giriyor ve bununla alakalı bir standardizasyon henüz oluşmuş durumda değil. Aslında problem de biraz burada başlıyor. Avantajlarda temelde mobil deneyim dedik. Buradaki yapıyı hatırlarsanız, app'i bir kere bir browser'ıma ben yüklemiştim. Hani bu sizin böyle fark ederek yüklediğiniz bir şey değil ama, o sitenin çekirdeğini yüklemiştim ve bütün sayfada değişen veriyi bana API dediğimiz sistem aracılığıyla geliyordu. Evet, bu da ne anlama geliyor? Daha hızlı bir sayfa geçiş deneyimi yaşayacağım. Çok akıcı olacak bütün sayfalar arası geçiş. Böyle olunca ne olacak? İnsanlar sitede daha fazla kalacak ya da bir kullanıcı, bir oturum başına daha fazla sayfada gezecek.

Çünkü bir sayfayı tıkladığı zaman, birkaç yarım saniye içerisinde o sayfanın içeriği onun için yüklenmiş oluyor. İnanılmaz bir sayfa hızı demek. Bu sayede kullanıcı dostu, çok akıcı ve de bakım maliyeti nispeten daha ucuz. Bir kere ürettikten sonra. Çünkü bütün data API'ler aracılığıyla sunuluyor ve çok rahat bir şekilde bunu yönetebiliyorsunuz. Şimdi gelelim bunun dezavantajlarına. Dezavantajlar noktasına geldiğimiz zaman, en temel problem ilk yüklenme hızı. Ne demiştik? Sunucu bana önce bir app gönderiyor ve diyor ki: "Yiğit, sen bu app'le konuş, ben bu app'e bilgileri gönderirim API aracılığıyla."

Okey, peki bu app ne kadar? Bu app'ler gerçekten büyük, boyut olarak. Dolayısıyla bu sistemlerin ilk yüklenme hızları gerçekten yavaş oluyor ve bu çok arzu etmediğimiz bir durum. Maalesef bu bir dezavantaj. Öte yandan SEO implementasyonu. SEO sürecinde Google Bot, bir sayfaya geldiği zaman sayfaları tıklayarak geziyor ve buradaki bilgiyi kendi veri tabanına kaydediyor demiştik. İşte burada SEO için bir negatif durum söz konusu. Çünkü standart yaklaşım diyor ki: "Google Bot, JavaScript olan sayfaları çalıştıramaz." Yani bu bir web teknolojisi ve bu web teknolojisini kullanan sayfalarda ben diyor, bu teknolojiyi çalıştıramıyorum diyor.

Öyle olduğu zaman ne yapıyor? Aslında benim app'imi çalıştıramıyor. Çünkü Google Browser Server, Browser Server eski tip bu yapıya alışmış ve eskiden bunu indeksleyemiyordu. Çünkü JavaScript zorunlu. Bir diğer dezavantaj. İkisi çünkü birbiriyle ilişkili. İşte Google artık bunu çözdü. Nasıl çözdü? Nasıl bir aksiyon alacağım? Bunu ilerleyen adımlarda daha rahat konuşacağız. Öte yandan bu sistemler genellikle tek sayfa olduğu için, geri butonuna basıldığı zaman bütün app'ten bir adım geriye gidebiliyor. Bunun için push state gibi farklı farklı çözümlerimiz var ama basit implementasyonlarda bu da bir negatif durum. Öte yandan geliştirme maliyeti. Şu aşağıda yazılı olan teknolojilerin hepsini yazan harika developer'lar hem çok pahalılar hem de nesilleri tükenmek üzere.

Çünkü çok az sayıdalar. Onların çoğalması için çaba sarf ediyoruz ama az sayıda bulunmaları geliştirme maliyetlerini de yükseltmiş oluyor. Şimdi bu konuyla alakalı aslında burada bu kadar güzel avantajım varken, bizim SEO danışmanları olarak, "Siz single page apps kullanmayın, siz client-side framework kullanmayın" demek gibi bir özgürlüğümüz bence yok. Çünkü biz aslında SEO'nun temelinde kullanıcıların deneyimini artırmak ve onları daha iyi bir noktaya, daha iyi bir deneyime taşımak istiyoruz. Burada harika avantajlar var. Evet, burada dezavantajlar olabilir. Peki ben bu dezavantajları nasıl elimine edebilirim ki bu avantajları kullanmak hâlâ benim için kârlı ve mantıklı olsun?

İşte tam olarak bu noktada, burada farklı çözüm önerileriyle geliyoruz. Bu çözümlerden ilki, Ajax Scrolling dediğimiz sistem. Aslında Google diyor ki: "Okey, web değişiyor, ben bunu biliyorum ve bu web'in değişimine karşılık olarak da benim bu JavaScript'leri indekslemem lazım." Ama Google'ın bu JavaScript denilen sistemi çalıştırmak için bir yeterliliği yok diyemeyiz. Çünkü dünyanın en büyük teknoloji şirketinden bahsediyoruz. Bizim basit cep telefonlarımızda bile yorumlanabilir bir JavaScript'i Google nasıl çalıştıramaz? Buradaki temel problem aslında taramanın genelinden başlıyor. Google web'i genel olarak tarıyorken aslında bu JavaScript'lerin hepsini çalıştırıyor olsa, bu sefer bu tarama işlemi inanılmaz yavaşlayacak. Çünkü bu inanılmaz derecede kaynak isteyen bir şey, işlemci gücü gerektiren bir şey ve Google buna girişmek istemiyor.

Bu tarihlerde, 2015'lerden, 2014'lerden bahsediyorum. Bu durumda Google diyor ki: "Tamam, ben JavaScript'i crawl edemiyor olabilirim. Siz bana JavaScript'le oluşan sayfanın benim okuyabildiğim şu ikili sistem vardı ya, sunucudan browser'a, o sisteme göre bana HTML çıktılarını verin." Yani bir nevi screenshot'ları gibi düşünün bunu siz. Bunun snapshot'ları, HTML şeklinde tabii ki. Buradan serve edilsin, buradan servis edilsin ve bana diyor ki: "Bunu escape fragment adında bir parametreyle bana bunu push edin." diyor Google. Bu, Google'ın çok önerdiği bir çözümdü. Uzun yıllar boyunca kullanıldı. Böylece Google JavaScript'i indekslemek zorunda kalmadı. Kullanıcılar kendi JavaScript'leriyle indeksleterek oluşan sayfaları Google'a verdiler. Ama bunun da birçok dezavantajı var.

Teknik bir konu, çok detaylarına girmeyeceğim ama sayfa her değiştiğinde burada tuttuğum cache'i de değiştirmem gerekiyor ki Google bunu görebilsin gibi tonla problem var ve bu Google'ın uzun vadede tercih edeceği bir sistem değil. İşte bu noktada Ajax Scrolling aslında şu an hâlâ SEO uzmanları tarafından sıkça öneriliyor olsa da, aslında mükemmel bir sistem değil. Neden derseniz, tamamen ve tamamen kullanıcıya bırakıyor işi. Yüksek bir oranda implementasyon yapmak gerekiyor, teknik bir tarafı da var bu işin ve bunu herkes uygulayamaz. Öyleyse Google'ın buna bir alternatif bulması gerekiyordu ve 2015 yılının sonunda dedi ki: "Hayır, ben artık burayı depreşe ediyorum, yani burayı kapatıyorum.

Yakın tarihte bunu tamamen yayından kaldıracağım." Ama hâlâ kullanıyorsanız, bir şey değiştirmenize gerek yok. Eğer bunu yapmak zorundasanız da yapın, ama ben zaten JavaScript'lerinizi indeksleyebiliyorum, dedi. Öyleyse client-side framework'ler ve altta gördüğünüz sonu JS ile biten her şey, madem Google tarafından indekslenebiliyor, öyleyse hiçbir problem yok. Aslında Google'ın bütün problemi çözmüş olması lazım, değil mi? Beklediğimiz durum bu. Ama aslında hayır. Oluşan gerçeklik bu değil. Google, bu JavaScript framework'leri hâlâ etkili bir şekilde indeksleyemeyebiliyor. Çünkü bunu bütün dünya scale'ında yapıyor. Çok büyük bir oranda yapıyor ve belli hatalar olabilir. Biz SEO'lar olarak bizim görevimiz de bu hataları elimine etmek. Öyleyse farklı çözümler bulmamız gerekiyor. Önerilen temel değişikliklerden birisi, "Gelin bu sistemi biz responsive yapalım."

Yani üçlü yapıdan çıkarıp ikili yapıya çevirelim. Bu bence çok noob, çok basit ve olmaması gereken bir öneri. Çünkü zaten bu sistemin kullanmamızın sebebi burada görülen avantajlar. Standart responsive bir sitede arada bir app share olmadığı için aslında bu performans değerini kaybediyorum. Dolayısıyla burada responsive'e geçelim, bence bir çözüm değil. Öte yandan Google'ın yeni, işte ortaya koyduğu progressive web apps gibi çözümler, teorik olarak client-side framework sayılsa da, Google tarafından desteklenen ve bizim için avantajlı olabilecek seçenekler olabilir. Bu da güzel bir sistem aslında. Kullanmak adına birçok artı avantajı da var ama bunun da geliştirme maliyeti çok yüksek ve biz şu an bir sistemi değiştirerek bu işin dışına çıkmak istemiyoruz. Mevcut sistemi SEO uyumlu hale getirmek istiyoruz.

Okey, o zaman burada üçüncü ve asıl bugün anlatmak istediğim çözüme odaklanmamız gerekiyor ki bu da isomorphic apps. Yani kullanıcıların kendi bilgisayarlarında, kendi tarayıcılarında bu app'ten gelen veriyi her seferinde almaları yerine, ufak bir trick'le bu durumu birazcık daha değiştirme durumundan bahsediyorum aslında. Detaylarına gireceğim. Bu durum server-side rendering olarak da biliniyor. Bu şekilde araştırabilirsiniz. Şimdi şu aşağıda gördüğünüz framework'lerin tamamı, React'ler, Backbone'lar, Angular'lar, Ember'lar, hepsi bu yapıyla çalışıyorlar temelde, mantıken ve bu app üzerinden bana bilgileri veriyorlar. Ama en temel dezavantaj neydi? İlk yüklenme hızı. Çünkü burada görülen bu app'i yüklememiz ciddi manada 2-3 saniyelik bir zaman alabiliyor iyi hızlı bir internette. Ve bu birçok kullanıcı için yüksek bir rakam. Ben bunu beklemek istemiyor olabilirim ve bu ilk yüklenme hızının yavaş olması beni rahatsız ediyor olabilir.

İşte burada aslında progressive enhancement adı verilen bu yaklaşım bize şunu söylüyor. Diyor ki: "Yiğit, madem app'in bu kadar büyük, sen önce kullanıcının ana ekranında göreceği alanı bir yükle." Yani bu mobil telefonumun ekranı olabilir, bilgisayarımsa bilgisayarımın ilk açıldığı ekrandaki görüntüsü olabilir. "Sen," diyor, "bunu kullanıcıya gönder. Sen bunu gönderdikten sonra kullanıcı burayı anlamaya çalışıyorken zaten diğer kalan app'i yükleyebilirsin. Bu senin için bir avantaj. Sen adamı orada bütün app'i yükletene kadar bekletme. İlk görmesi gereken veriyi göster, ilk yüklemede, initial load'da. Daha sonra o aşağıya doğru inerken sen zaten app'in kalanını yüklersin." İşte buna isomorphic apps deniyor. Airbnb biliyorsunuz, işte ev kiralama konusunda dünya lideri. Bu konuda çok ciddi emekleri var. Harika da bir yazıları var. Zaten araştırdığınızda mutlaka göreceksiniz.

Ve yaklaşım olarak diyor ki: "Google JavaScript'i indeksliyor ya da indekslemiyor. Biz isomorphic apps denilen sistemle kullanıcının ilk göreceği şeyi, standart ikili sistemdeki gibi, sunucu browser'daki gibi kullanıcıya verelim. Kullanıcı sayfayı geziyorken biz arkada app'i yükleriz ve app kullanıma hazır olduğu zaman sağdaki bütün avantajları bana sağlar." Böylece ne oldu? Ben bu sistemi kullanarak ilk yüklenme hızını arttırdım mı? Arttırdım. Standart ikili yapıdaki gibi bir sayfa açtığım için Google için bir problem var mı? Artık yok. Hayır, SEO implementasyonum da iyi durumda. Evet, JavaScript hâlâ zorunlu ama neredeyse artık crawler'lar dışında bütün tarayıcılar JavaScript destekliyor.

Evet, API ihtiyacım hâlâ var mı? Var. Modern ihtiyaçlardan birisi. Geri butonu problemini çözüyor muyum? Zaten bunu uygulayan bir yazılımcı muhtemelen push state'i de uyguluyor ve çözüyor. Tek sıkıntım geliştirme maliyeti olmuş oluyor. Dolayısıyla bu isomorphic apps yapısını işin içerisine entegre ettikten sonra hem buradaki avantajların tamamını kullanabiliyorum hem dezavantajlardan kaçınabiliyorum hem de harika bir SEO performansı sağlayabiliyorum. Biz SEO'cular her ne kadar bugüne değin JavaScript sistemlerinden kaçınmış olsak da, web'in geleceği, kullanıcının ihtiyaçları, ona hızlı tepki verebilmek, hızlı cevap verebilmek gibi nedenlerden ötürü kendimizi artık pivot etmek ve birazcık da olsun JavaScript öğrenerek front-end developer'ların yanına oturduğumuzda onlara derdimizi anlatıyor olabilmemiz gerek.

Şimdilik bu konuyla ilgili anlatmak istediklerim bunlar. Bu konuyla ilgili isomorphic apps yazarsanız, Medium'da harika yazılar var, Airbnb'de mükemmel yazılar var. Bunların hepsini inceleyerek projenize ya da müşterinize destek verirken çok daha manalı yaklaşımlar getirebilirsiniz. Şimdilik anlatmak istediklerim bu kadar. Bir sonraki videoda görüşmek üzere. Kolay gelsin.