Secrets to Success in Migration Processes

— Herkese merhaba, Zeo Talks'a hoş geldiniz. Bugün Can'la beraber migration'ı konuşacağız; aslında SQL çalışmalarındaki en önemli konulardan bir tanesi de site birleştirme ya da site taşıma gibi işlemlerde migration süreçlerinin doğru yönetimi olacaktır. O yüzden aslında bugünkü konumuz, dediğim gibi, genel hatlarıyla migration'ı konuşmak; bunun üzerine Can'la beraber aslında bir sohbet edelim istedim. Can, bana göre zaten Zeo'da en çok migration projesi yöneten arkadaşlarımızdan bir tanesi; o yüzden bence yorumları da oldukça kıymetli olacaktır.

— Teşekkürler.

— Can, hızlıca aslında konu başlığımıza girelim mi, ne dersin?

— Girelim bence de.

— Hem uzatmak da açar, o şekilde devam ederiz ya.

— Aynen öyle yaparız.

— Aynen. Şimdi ilk benim notumda şey var: klasik, yani migration nedir, neden yapılır; hani onunla aslında bizi izleyenlere biraz onunla ilgili bilgi verebiliriz. Aslında migration, site taşıma, site birleştirme ya da URL değişikliği gibi konularda yaptığımız işlemler; SQL tarafıyla alakalı bunları tabii ki konuşacağız biz. Bunların temel yapılma nedenleri de aslında örneğin sitelerin birleştirilmesi; farklı bir domain'de olan bir sitenin tek bir domain'e getirilmesi ya da daha farklı domain'lere taşınması gibi, hani farklı dillere bölünme gibi birçok farklı senaryo olabiliyor burada. URL yapısı değişebiliyor; bu yüzden de aslında eski URL'lerde güzel bir performansımız varsa, onların yeni URL'lere aktarılması çok önemli. Çünkü eğer biz bu migration işini doğru bir şekilde yapmazsak, bu sefer biz eski trafiğimizden de olabiliriz.

O yüzden bunlar oldukça önemli. Henüz, yani kullanan var mı bilmiyorum ama işte HTTP'den HTTPS'e geçiş işlemleri eskiden çok daha fazla yapılıyordu. Yine separate URL'de işte mobile sürümü ayrı bir şekilde sunulan web sitelerinin yine responsive yapıya geçtikleri senaryoda biz bu migration işlemlerini yapmaya çalışıyoruz ve markaların da minimum hasarla buradan atlatmasına aslında yardımcı olmaya çalışıyoruz, deyip topu sana atayım.

— Ya, çok güzel özetledin aslında süreci. Yani biraz markaların ya da web site yöneticilerinin, sahiplerinin çekindiği süreçler; haliyle SEO performans ya da sitenin overall çalışma yapısı, e-ticaretse entegrasyonlar, işte B2B siteyse form entegrasyonları, işte analytics'ler, GTM kodları, her şey aslında yeni yapıya taşınması. Yani aslında taşınma süreci diyebiliriz buna; bir ev taşımak gibi düşünebiliriz bu süreci temelde. Bir sitenin taşınması. Birçok faktör var bunun içinde; sadece tasarım değişikliği yapılan migration'lar var, hem URL hem tasarım değişikliği yapılanlar var. CMS'in arka tarafta değiştiği, tasarımla birlikte değişen var; tasarımın hiç değişmediği, CMS'in değiştiği, URL yapısının kontrol edilmesi gereken. Bir sürü farklı migration'lar var aslında. Temelde en çok yapılan, tasarım değişikliği; yani tasarım değişikliği nedeniyle yapılan migration'lar.

Uzun süreli web sitelerinin kullanılması, yeni teknolojiye geçme süreçleri, yeni CMS'e geçme süreçleri ya da altyapı değişiklikleri; ki e-ticaret tarafında oldukça fazla yaşadığımız ya da istenilen durum, altyapı değişikliği, CMS değişikliği tarafı. Bununla birlikte biz de zaten SEO tarafında işte kategori yapısı düzgün değilse, kategori yapısının düzeltilmesi. Halihazırda değişecek bir denge var, bir yapı var; bu yapıyı doğru şekilde kurma süreçleri var. Migration yapılmalı ya da yapılmamalı; sanırım bununla ilgili senin bir madden var. Biraz o tarafa doğru da kaymak isterim, zaten üstüne de konuşuruz. Bir site nasıl migration yapmalı süreci aslında? Neden migration yapmalı ya da ne zaman yapmalı süreci aslında? Yani bu tarafta genellikle bu marka kararı oluyor benim çalıştığım süreçlerde.

Çoğunluğu işte eski yapının artık elverişli olmaması, birçok teknik task'ların eski yapıda yapılamıyor olması, bununla birlikte tasarımın eski kalması, daha light bir tasarıma geçiş yapılması. Çünkü corporate lightness metriklerinin etkilenmesi bu durumdan. CMS tarafındaki yapılacak büyük bir değişiklik nedeniyle URL yapılarının, structure'ın yeni CMS'e taşınma süreçleri gibi süreçler aslında temelde. Bir web sitesinin buna karar verme süreci ve karar verdikten sonraki süreç bence en kritik olan süreç. Sen de bana burada katılırsın diye düşünüyorum. Migration kararı alındığı andan itibaren tasarım süreçleri dahil bence SEO ile çok entegre çalışılması gereken bir durum. Genellikle markaların, ya bize direkt migration projesi olarak gelen markalar da var; işte kendi projelerimizin migration süreçlerini yönettiğimiz markalar da var.

Genellikle markalar tasarım sürecini bitirdikten sonra SEO ihtiyacı duyulduğunu düşünüyor. Ama bence eğer mümkünse tasarım süreciyle birlikte SEO süreçlerini yönetmek gerekiyor. Çünkü tasarıma eklenecek yeni widget'lar, komponentler ya da işte heading kurgularının listelenmesi, arka taraftaki CMS'te yoksa ya buraya bir text editor koyalım, text editor'den heading'leri versin, bu yapının kurgulanması, CMS'e bunların entegre edilmesi gibi süreçler SEO'yu oldukça ilgilendiriyor gelecek dönem için, diye düşünüyorum.

— Orada şeyi netleştirmek için mesela sana şu soruyu sormak isterim: Örneğin ben markada çalışıyorum ve dedim ki işte ya da bir karar aldık markada, biz sadece front-end tarafında bir geliştirme yaptık ve bununla ilgili migration yapmalı mıyız aklımızda soru işareti aslında. Hani bununla ilgili markalara ya da kişilere öneride bulunabilir misin? Yani işte biz front-end tarafındaki geliştirmelerin mutlaka site altyapısını etkilediği ve burada migration'ın olması ya da olmaması gerektiği noktasında düşüncelerin nelerdir? Nasıl yönlendirirsin?

— Bu çeşit durumlarda, yani içinde migration geçen her kelimede SEO'nun olması gerekiyor. Bu sadece tasarım değişikliği de olabilir. Yani hiçbir şey değiştirmeyeceğiz, tasarım değiştiririz. Evet, güzel.

— En azından check ederiz yani.

— Aynen. Tasarım değişikliği demek aslında bir sitenin performans değişikliği demek. Yani bütün JavaScript yapıların, CSS yapıların değişecek. Evet, senin sayfanın URL'i aynı kalabilir ya da heading kurguların, içeriğin internal link'leri ne kadar aynı kalabilir ama o sayfanın yüklendiği, yani botların request attığı öğe sayısı değişecek, JavaScript'lerin boyutları değişecek. Bunun için bir hız optimizasyonu yapılması lazım, page speed optimizasyonu. Çünkü belki eski sitenden çok daha yavaş bir yapıya bürünecek. Genelde tema seçimlerinde şöyle bir durum oluyor: Custom bir tasarım yoksa, işte tema test demosundan site hızı yapılıyor.

Evet, oldukça hızlı. Aslında bu çok doğru bir yaklaşım değil. Özellikle WordPress tarafında bunu oldukça yaşıyoruz. Çünkü o temanın içerisinde sizin GTM kodlarınız yok, sizin add-on'larınız eklenmemiş durumda. Sizin işte çalıştıracağınız başka third party, işte örnek veriyorum Insider gibi third party araçların JavaScript kodları yok. Bunların hepsinin test sürecinde SEO ile birlikte optimize edilmesi gerekiyor. Ne kadar sadece tasarım değişecekse. Bununla birlikte sayfanın içindeki işte test sitesine geçirilen içeriklerde heading kurguları doğru çalışıyor mu, işte bu kurgular önceki siteyle aynı mı ya da eksik bir içerik taşınmış mı?

Mobil öncelikli tarafta, yani responsive yapılarda mobil tarafta bir eksiklik var mı, MFI problemleri var mı? Sadece tasarım değişikliğinde bile süreç oldukça yoğun geçen bir süreç oluyor.

— Kesinlikle.

— O yüzden mutlaka destek alınmalı.

— Bence de. Yani çok önemli çünkü. Sen zaten aslında az önce de biraz buna pas attın; hani ne zaman yapılmalı migration süreçleri. Bu tamamen aslında markanın kendine, hani gerek ekip anlamında gerekse diğer kendi içlerindeki kurgu anlamında buna hazır oldukları zaman, bir SEO uzmanı ya da bir SEO ajansıyla çalışmaya bence karar vermeliler burada. Hani bunun zamanı da dediğin gibi, hani ben migration yapmaya karar verdim ama önce senin ekibin hazır mı? Çünkü biz hani burada onlara bir roadmap hazırlayacağız, bir işte yönlendirme listesi hazırlayacağız. Bunlar çok daha değerli. Zaten az sonra da konuşacağız bunları.

O yüzden aslında dediğim gibi, ne zaman yapılması gerektiği, yani siz kendinizi hazır hissediyorsanız kendinizi arka planda birçok işlemin yapılma noktasında, benim naçizane önerim; evet, hani buna başlayın ama bizim migration yapmamız lazım, tamam ama mesela sen buna hazır mısın? İşte developer ekiplerinin bunun için bir kaynağı var mı? İşte marketing ekibin buna hazır mı? Ya da bu migration'ı yaptıktan sonraki süreçleri değiştirebilecek bir iş yüküne sahip misin? Aslında bir sürü farklı konu devreye giriyor. Bu tür şeyler var. Bir de mesela ne zaman yapılmalı? Aklıma geldi hemen Can, bunu söylemen bence güzel olur. Sanırım Google çalışanları bunu demiş olabilir, bu söyleyeceğimi. Migration ne zaman yapılmamalıyı biraz söyleyeyim ben mesela. Benim de görüşüm, trafiğinizin çok yüksek olduğu bir dönemde bu işe kalkışmayabilirsiniz.

Ya da çok böyle kısa, az sayfa sayısına sahipseniz, belki hani hafta sonuna doğru bunu yapabilirsiniz. Atıyorum işte pazar akşamı gibi, hani çok böyle trafiğin yüksek olduğu günlerde. Çünkü her sitenin kendine göre bir trend grafiği vardır. O yüzden ne zaman yapılmamalı sorusuna belki bu şekilde cevaplayabiliriz.

— Yani doğru söylüyorsun. Bu tarafta zaten yaptığımız çoğu migration süreçleri ya gece geçilen ya çok hafta sonu sabah erken saatlerde. Kullanıcıların siteye gelmeyeceğini düşündüğümüz view olarak daha az view aldığımız saatler olmasına dikkat ediyoruz. Hem bu açıdan hem de sonuç olarak markanın e-ticaretse mesela satış grafiği düşüyor bu arada. Çok trafiğin yoğun olduğu saatlerde bunu yapıldığında. Ne zaman yapılmaması gerektiği bence çok daha kritik bu arada söylediğin. İyi oldu. Çünkü şöyle bir nokta var; yani markalar şunu düşünüyor: Migration süreci SEO ile çalışıldığında sorunsuz geçecek ve işte sitenin düşmeyeceği bir süreçtir diye bir algı var bu tarafta.

Zaten istenilen bu. Biz bunu kusursuz şekilde yapmaya çalışıyoruz. Yani her şeyi kontrol ediyoruz. Migration süreci bir sitenin A'dan Z'ye içerik teknik off-page, sitenin dışına verilen external link'lerin no follow olması süreçlerine kadar her şeyin incelendiği bir durum. Yani aslında o süreç yeni sitenin audit süreci gibi bir süreç diyebiliriz buna. Şimdi sitenin çok iyi performans gösterdiği bir dönemde, gün olarak söylemiyorum, saat olarak da söylemiyorum. İşte örnek veriyorum; yazın, yaz sezonu sizin sezonuysa, bu dönemde geçiş yapmak oldukça riskli bir durum. Çünkü işte e-ticaretseniz entegrasyon problemleri çıkabilir test süreçlerinde, canlıya çıkılan süreçlerde. Ya da işte istenmeyen bir durum yaşanmış olabilir. Google gözünde sizin yeni tasarımınız çok daha etkili bir tasarım değildir. Katma değeri daha düşüktür.

Tasarım anlamında söylüyorum. Ya da işte yapınız daha yavaş çalışıyordur. Ya da attığı isteklerde işte API call'larınız yavaş gelmeye başlamıştır, sunucu sayısı istek arttıkça. Bunları tabii ki düzenli olarak takip ediyoruz ama genellikle benim önerim ki sen de buna katılacaksındır; iyi performans gösteriyorsa bir site, tabii ki migration planlanabilir. Ama bu migration planının daha uzun soluklu, yani bu performansı kaybetmemek için daha uzun soluklu olması gerekiyor. Yani sen de çok yaşadın bunu, ben de yaşadım, biliyoruz. Genelde markalar migration için bir deadline belirleyip bu deadline'a kadar geçme düşüncesiyle hareket ediyor.

Evet, bu doğru bir yaklaşım. Evet, bir deadline sonuç olarak belirlenmesi lazım ama benim her migration yaptığım markaya söylediğim durum bu. Şu an halihazırda çalışan bir sitemiz var. Yani aktif olarak çalışıyor. Deadline geldi, bu işleri faz 2'ye atalım diyebileceğimiz işler tabii ki oluyor ama must dediğimiz işleri mutlaka yapmamız gerekiyor. Deadline geldi diye bu işlerden vazgeçemeyiz. Yani günün sonunda şöyle bir durumla karşı karşıya kalıyoruz: Şu an sitenin performansı normal. Yani tasarım eski ya da işte CMS değişecek. Yeni sitede de işte belli başlı teknik problemler var, çözülemedi ama deadline geldi, hadi canlıya çıkalım.

Şimdi burada sadece şunu yapmış oluyoruz: Tasarımı değiştirmek için çalışmayan bir yapıya geçmiş oluyoruz. Şimdi günün sonunda hiç migration yapmadığımızı varsayalım, şu an sitemizde çalışan bir yapıyı bozar mıyız? Bozmayız. Tam olarak bu şey hakim oluyor. O yüzden benim de markalara söylediğim, yani gerçekten evet, deadline'lar önemli. Zaten genellikle o deadline'lar sarkıyor migration süreçlerinde. Çünkü birçok ekip bir arada çalışıyor. Sadece SEO ve yazılım ekibi değil. Birçok ekip aynı anda çalışıyor. Bir yerde mutlaka sekteye uğruyor. Ama günün sonunda canlıya çıkarttığımız sitenin, evet, tamam, herkes, bütün ekiplerin tamam artık hazırız dediği anda canlıya çıkması oldukça kritik. Bu durumlarda zaten migration'da yaşanan kayıplar yok denecek seviyeye geliyor.

Hatta bu durumlarda migration ardından site gerçekten yükselişe geçiyor. Bunu birlikte yaşamıştık. Hatta bir markamızda uzun bir migration sürecinin ardından güzel bir yükseliş trendine geçmişti marka bu tarafta.

— Kesinlikle. Orada bazı büyük markalarda, örneğin işte Almanya'daki CMS değişiyor. Ondaki performansa göre, atıyorum işte Türkiye'deki tarafındaki site bir deadline'a uygun şekilde geçirilmeye çalışıyor ama uzuyor falan. Kesinlikle söylediklerinin yani ben de katılıyorum. Şimdi istersen ufak ufak biraz daha aksiyon tarafına geçelim. Çünkü migration'a okey, karar verdik. Neden yapılması gerektiği noktasını da konuştuk. Peki işte migration öncesinde biz nelere dikkat etmemiz gerekiyor? Aslında biraz daha buna değinebiliriz. Çünkü en başta da demiştim, hani migration farklı türlerde olabiliyor. İşte site merger ya da site move gibi birçok farklı türde yapılabiliyor. O yüzden hani ben migration yapmaya karar verdim ama önce sen nelere dikkat etmek gerekiyor, istersen konuşabiliriz.

Öncelikle lütfen her zaman olduğu gibi yedek alın. Sitenizin yedeğini alın. Bir kenarda dursun. Bunlar çok değerli çünkü. Veri kaybı yaşamamak için bence bunu mutlaka her zaman yapmaya çalışın deyip, migration öncesinde nelere dikkat etmek gerekiyorla ilgili topu sana atayım.

— Söylediğin ilk nokta yedek alma noktası. Yani o canlıdaki sitenin yedeği çok önemli. Çünkü çok geçiş anında yaşayacağınız bir teknik problemle o siteye geri dönmeniz gerekebilir. Çoğu süreçlerde artık alınıyor. Önceden bununla ilgili problemler yaşıyorduk. Backup problemi yaşıyorduk ama artık genellikle yazılımcılar ve yazılım ajansları bu konuda tecrübeliler. Ben uzun zamandır bu sorunu yaşamadım yani. Yani uzun zamandır zaten backup'a dönmedik hiç. Nadir yaşanacak bir durum ama geçmişten bir dataya da ihtiyacınız olabilir o web sitesinde. Yani eski web sitenizde bu nasıldı dediğiniz. O yüzden backup önemli. Yani migration'dan önce, yani migration'a karar verdik. Şimdi adımlarımız ne olmalı süreçte? Az önce biraz bahsettim. Migration kararının hemen ardından bence bir SEO desteği almanız gerekiyor.

Bu sürekli bir SEO desteği de olabilir, migration desteği de olabilir. O anlık ihtiyaçlarınız doğrultusunda nasılsa alınması gerekiyor. Ardından migration tarafında bence ilk adım tasarımın belirlenmesi ya da custom bir tasarım çalışılması. Bu tasarımın çalışılırken SEO'ya uygun şekilde çalışılması. Yani gerçekten yeni kütüphanelerin kullanılması JavaScript tarafında, yeni CSS yapılarının kullanılması, işte text compression'ların yapılması, yazı daha yazılırken. Çünkü günün sonunda dönüp baktığımızda, ya burada text sıkıştırma işi var dediğimizde test sürecinde yazılım ekibi de artık bir daha oraya geri dönüp yapma sürecini onlar için zor oluyor.

Çünkü önlerinde hala madde var. Onun dışında işte DOM boyutlarının optimize edilmiş bir şekilde yazılması. Ki buna bence sen de katılırsın. Bence yazılım tarafında en az dikkat edilen nokta bu. Yani DOM boyutları, derinliği daha az dikkat ediliyor. Oraya erişebilmek adına, yani bitirebilmek adına daha az dikkat ediliyor. Çünkü genellikle sayfanın hızlı yüklenmesi ve doğru yapıda olması front-end tarafında yeterli görülüyor. Ama gerçekten DOM boyutlarını optimize edebilmek, çünkü canlıdaki bir sitede bunu yapmak neredeyse imkansıza yakın bir süreç. Oturup tüm kodun tekrar yazılması lazım. Aslında migration yapmak oluyor. Bu süreçlerin tasarımdan front-end giydirmeye kadarki süreçlerin hepsinin özenle yapılması gerekiyor. Ardındaki süreç bizim ihtiyacımız olan bir test sitesi. Yani test domaini.

Lokalde çalışacak bir test. Artık testi nerede yapılıyorsa, nerede yapılacaksa bir test sitesi. Bu test sitesinden önce, yani bu test sitesi ile birlikte bizim tüm içeriklerimizin taşınma süreci var. Yani bunu bir API koluyla otomatik sistemle de yapılabilir, manuel olarak da yapılabilir. Bunların taşınma süreçleri var. Yani ihtiyacımız olan şey içeriklerimizi taşımak. Bu içerikleri taşırken en az bence sitenin yalnız front-end tarafının giydirme süreçlerinin SEO önemi kadar önemli bir süreç. Eksik içerik taşımamak, içerik yapılarını doğru kurgulamak. Ki bu tarafta bu da aslında biraz SEO temelli bir task diyebiliriz. Çünkü biz temelde migration'da tüm sitenin, eski sitenin yapısını, crawl'unu, ağacını çıkartıp bu tarafa taşınacak içerikler ve taşınmayacak içerikler. Aslında bir nevi migration'ı ben şey olarak da görüyorum.

Samet, sen burada bana katılır mısın bilmiyorum. Temizlik gibi de görüyorum yani.

— Kesinlikle. Yani yapamadığın birçok şeyi en azından migration'la halledebiliyorsun. Atıyorum mesela internal link işim var. Az önce bahsettin içeriklerin taşınması noktasında. Orada link final adresi 301'lenmemiş de araya farklı bir redirect'ler girmiş. Hani orada direkt aslında içeriği taşırken bile oradaki, hani burada da sana pas atacağım, URL yapısına da aslında dikkat ederek taşımak gerekiyor. Şimdi hani onu en başta migration öncesinde belki halledebilirsek o internal linkleri, bir daha sırasına ve sonrasına uğraşmamış oluruz. Zaten URL yapısına da bence değineceksindir burada öncesinde dikkat etmek için.

— Yani bir de burada şey, temizlikten şeyi kastım. Yani mesela bir daha önceden trafik almış bir path kategori içeriğimiz var ya da işte blok içeriğimiz var. Biz bunları oturup, yani normalde temizlenmesi gereken süreçler. Çok eski içerikse trafik almıyorsa, güncelliğini yitirmişse artık bizim için bir anlamı yok. Tamamen bir yük oluşturuyor. Hem crawl açısından hem sunucu açısından hem o sayfayı ayakta tutmaya çalışıyoruz çünkü ister istemez. Bunların temizlik süreçleri migration için önemli. Şimdi bu içerik taşıma süreçleri noktasıyla birlikte tabii ki URL structure var.

Bu genellikle marka kararı ve işte SEO çalışmasıyla birlikte. Kategori ağacımız değişecekse, yani URL yapımız değişecekse ya da işte eski yapıya yeni bir şeyler ekleyeceksek, eskiden yapımız çok kötüdür URL yapımız. Yani ki genellikle kullandığımız yapılar işte root domain altındaki kategoriler, kategorilerin altında final URL'lerin olması, her şeyin root domain'e bağlı olmaması, bir ağacın bulunması, site structure'ının belli olması istenir. Ki Google'da sayfalarınızın yapısını takip edebilsin, kategori ağaçlarını bulabilsin. Kullanıcılar da artık buna çok alıştı. Kategori yapılarına. Final adresten bir önceki kategoriye gidip bunu kullanmaya. Özellikle e-ticaret sitelerindeki yapı kullanıcıları buna aşırı alıştırdı.

Eğer bu yapı yoksa, SEO tarafında işte bu yapıyı kuralım dediğimiz nokta var. Yani bu sitenin structure'ı ki bu SEO danışmanı olarak bizim söylememiz gereken bir nokta. Markanın belki SEO URL yapısında bir problem görmeyeceği ama bizlerin problem göreceği noktalar. Varsa işte bu kategori yapısının böyle olması lazım. Bu URL'in böyle olması lazım. Ama buradaki dipnot şu olması lazım. Bizim gerçekten bu sayfaları yönlendireceğimizi unutmamamız gerekiyor. Yani bu custom yönlendirmesi yapmak değil. Bu sayfanın URL'i değişecek. Bu sayfa aylık 1 milyon click alıyorsa, bu sayfa bir yönlendirme yiyecek. Yani URL'i tüm akışı kayacak bu sayfanın. Tüm otoritesini diğer sayfaya aktarmaya çalışacağız. %100 bir aktarım olmayabilir burada. Burada bir trafik kaybı yaşanabilir.

Genellikle migration süreçlerinde bizi düşündüren iki tane kaygı var. Bir, URL yapısının değiştirilmesi. İki, site hızının tamamıyla optimize edilmesi. Samet, burada sen de bana katılırsın diye düşünüyorum. Bu ikisinin sorunsuz olduğu versiyonda zaten genellikle problemsiz geçen versiyonlar. Test sites açısından konuşmuyorum. SEO açısından konuşuyorum şu anda. Problemsiz geçen versiyonlar. Genellikle URL yönlendirme işlemlerinde, işte URL değişiklik yapılarında çok daha hassas davranılması gerekiyor diye düşünüyorum ben bu taraftan.

— Kesinlikle. Ya orada ek şey ekleyebilirim yine URL yapısıyla alakalı. Biz SEO'lar her zaman URL yapısına zaten uyum sağlarız. Örneğin işte Almanya'dan örnek verdim ama yine Almanya'da sizin ana şirketlerinizin web siteleri belli bir URL path'iyle artık migration'a girmişse, zaten biz SEO olarak ona uyum sağlarız. Ya da şey de olabiliyor. Hani Samet, biz yeni bir URL yapısına geçeceğiz. Bize burada yeni URL yapısını önerin şeklinde de gelebiliyor aslında. Biz URL yapısına bu iki tür şekilde de uyum sağlayabiliyoruz. Hani burada benim genel herkese de tavsiyem şu olur.

Mesela bazen şey olabiliyor. Ya Samet, mesela parametrelerden örnek verelim. İndeksenmeyen ve crawl edilmeyen parametrelerden bahsediyorum. Burada yeni yapıda biz yeni parametreler de kullanacağız diyelim ki. Örneğin ads tarafına daha fazla reklam verebilmek için. Örnek veriyorum tamamen bunu. Hani SEO'da kapatacağız zaten. İlgili sayfalar nerede search volume yoksa. Şey gelebiliyor. İşte sen burada bu parametresini şunu dedin ama örneğin ben X sitesine baktığımda böyle değil. Şimdi çok detay var orada. Bir, ben zaten en optimal çözümü sana sunmaya çalışıyorum burada SEO olarak. Bir de o örnek verilen markaların bazıları migration sürecinde olabilir. O süreçleri kötü yönetmiş olabilir. Ya da backlog'larına böyle bir değiştirme işlemleri de olabilir.

O yüzden aslında her zaman bu tür karşılaştırmaları yaparken doğru bir şekilde karşılaştırma yapmak ve aslında SEO'ya biraz burada güvenmek gerekiyor. Çünkü burada zaten o da sizin istediğinizden daha fazla istiyor o sitenin başarısını. O yüzden bu tür farklı case'ler de olabiliyor. Çünkü filtreli URL'ler, yeni parametreler zaten bir sürü parametreyle biz uğraştık yani sen de biliyorsun. Bunlara da biraz dikkat etmek gerekiyor. Hani aklıma gelmişken söyleyeyim dedim.

— Evet, yani bu konuda benim de aklıma bir şey geldi. Sen parametre ve URL deyince. Şimdi URL structure'ının değiştiği bir migration düşünelim. Tüm URL yapısının değiştiği bir yönlendirme oluşacak da. Şimdi bu tarafta atladığımız ya da kullanıcıların yani web site yöneticilerinin atladığı nokta şu. Test sitesi oluştururken yeni structure ile oluşturuyoruz zaten. İçerikleri taşırken internal link problemleri yaşıyoruz. Şimdi eski sitedeki internal link ile birlikte taşıdığımızda bunu, bu içeriklerdeki internal linklerin hepsi 301 çevirmeye başlayacak biz siteyi canlıya çıktığımızda. O yüzden bu akışı yeni siteye göre kurgulamak gerekiyor içerik taşıma süreçlerinde. Bunu böyle yapmadığımızda ki hatırlarsın bir markada bu problemi yaşamıştık. Biz söylemiştik fakat unutulmuştu taşınan ekip tarafında. Tekrar içeriklere geri dönüp tüm URL'leri değiştirmek gerekiyor.

Otomatik bir yapıda değiştirilemediği için, değiştiremedikleri için bu gerekmişti. O yüzden yeni sitenin yeni URL yapısı ve taşınan şeyler artık özellikle URL yapısı değişiyorsa ben şey gözüyle bakıyorum. Markalara da söylüyorum bunu. Bu sizin yeni siteniz ama çok başka bir site. Yani eski siteyle kıyaslamayın. Eski site gibi düşünmeyin. Her şey yeni. Bu sitenin ürün sayfasının URL'i artık farklı. Başka bir markaymış gibi düşünerek hareket edin diyorum. Ki bence öyle de yapılması gerekiyor. Eskiden bir şey getireceksek migration yapmamıza gerek yok. İçerik anlamında söylemiyorum bunu. Yani bu da böyle olsun işte. Yeni sitede işte örnek veriyorum 300 tane URL 301 çeviriyor. Mesela bunun olmaması gerekiyor bence. O sitenin gerçekten kusursuz bir yapıda çalışması lazım. O noktada canlıya çıkılması lazım diye düşünüyorum.

— Aynen. Kesinlikle. Bir de sen de bahsettin ya. Aslında o sayfalarımızın bir URL age'i var. O atıyorum 5 yıldan beri aynı URL'den biz o ürünü sunmaya çalışıyoruz. Ama şimdi sıfırdan aslında bir URL olmuş oluyor. O yüzden Google'ın da ya da diğer arama motoru botlarının da o URL'e güvenmesi, o URL'in historisini elde etmesi bir süreç. Zaten sen de bahsettin. İşte backlinkler geliyor, atılan istekler falan aslında bir sürü süreç yeniden sıfırlanmış oluyor. Bizlerin de görevi bunları hani minimum riskle daha hızlı bir şekilde halledebilmek aslında.

— Araya gireyim Samet. Yani şimdi burada URL değişikliği derken tüm sitedeki URL değişikliklerinden de bahsediyoruz ama genellikle kategori bazlı da URL değişikliği yapılabilir. Yani örnek veriyorum ürün kategorisinin altındaki URL structure'nız düzgündür ama blok altındaki structure'nızın hepsi route'a bağlıdır. Burada bir structure değişikliği yapılabilir. Yani path'ler eklenir. URL değişikliği dediğimiz kısım tüm sitenin değiştirmek zorunda değil. Belli path'lerde ya da belli URL'lerde gerçekten yazım hatası vardır. İşte yanlışlıkla Türkçe karakter kullanılmıştır, unutulmuştur. Ama gerçekten otorite de kazanmıştır. Buralarda değişiklik yapılabilir. Söylemek istedim bu noktayı da.

— Evet, evet. Kesinlikle. Yani sana burada da katılıyorum. Şimdi marka migration'a karar verdi. Dikkat edilmesi gerekenleri migration öncesinde konuştuk. Toplantı yapıldı. Raporlar. Her şey bizim tarafta hazır. Biz rule set'leri hazırladık. Yönlendirme listelerini tekrar tekrar simüle ettik, kontrol ettik. İşte senin de bahsettiğin gibi nofollow'lar, content'ler. Biz hazırız. Sabah 9.30'da karar verdik. Dedik ki marka ile beraber. Samet Can, biz sabah 9.30'da ya da 10'da artık canlıya çıkıyoruz. İşte bu migration sırasında dikkat edilmesi gerekenler neler aslında biraz da bunu konuşabiliriz. Çünkü migration'a çıktığımız anda biz bir GeoForce kullanıyorsak bunun işte track edilmesiyle alakalı kodlar ya da farklı third party kodların mutlaka hemen o sürede devreye girmesi lazım yenilerinin. Ya da yenileri derken hani o kodların tekrar çalıştırılabilmesi lazım.

Çünkü orada bir veri kaybının olmaması gerekiyor. Aslında bu tür konulara biraz daha değinebiliriz diye düşünüyorum ben.

— Evet ya. Benim genellikle uykularımı kaçıran an bu an zaten. Yani migration'ın geçiş anı. Oldukça stresli bir an. Defalarca yaptık ama her seferinde stres oluyorum nedense. Ki bu burada yani belki stres yapacak en son kişi bizler olabiliriz yani. Çünkü canlıya çıktığı anda Google bot evet gelmeye başlayacak ama orada değişiklik yapabilme ihtimali olan kişileriz yani. Anında bir yansımadan ziyade. Ya bu süreçte benim son dönemlerde yaptığım migration'larda dikkat ettiğim şey noktası var. Ekipler çok bağımsız çalıştığı noktalar var. Yani gerçekten en son yaptığımız geçişte böyle bir durum yoktu. Herkes bir aradaydı. Bence oldukça önemli bir durum bu arada. Yani fiziksel olaraktan bahsetmiyorum. Yani online olarak herkesin iletişimde olması anlık kontrollerde.

Geçiş süreci sitenin çok ebatına göre değişkenlik gösterebilir. Bazısı 10 dakika içerisinde tüm siteyi yayına alabilir. İşte sunucular taşınır, CMS eklenir vesaire. Bazı sitelerin geçişi bir saat sürer. Yani çok büyük ebatlı bir siteniz varsa haliyle sunucudaki CMS'in değişmesi oldukça uzun sürer. Ki bence bu noktalarda etap etap geçiş çok daha sağlıklıdır. Yani komple tüm siteyi aynı anda geçirmektense etap etap belli yapıları geçirmektir. Bu süreçte bizim temelde geçiş ile birlikte kontrol etmemiz gereken, mutlaka kontrol etmemiz gereken noktalar var. Bunlardan ilki. Şimdi genellikle test sitesinde çalıştığımız için işte test sitesinin versiyon yönlendirmeleri. HTTP'nin HTTPS'e işte sonundaki slash'ın yönlendirmesi. W var mı yok mu? Eğer bir subdomain ise test sitemiz bunu kontrol edemiyoruz.

Öncelikle geçişle birlikte bunun kontrol edilmesi gerekiyor. Bu arada düzen sırasına göre söylemiyorum ama kontrol edilmesi gerekenleri liste olarak söylüyorum. Bu kesin ilk birinci sırada demiyorum. Bununla birlikte zaten bunu test sitesinde yapmamız gerekiyor. İkincisi robust.txt. Gerçekten bizim robust.txt'miz origin hali geldi mi? Yani test sitesindeki hali çalışıyor mu? Doğru bir yapıda çalışıyor mu? Bununla birlikte senin az önce söylediğin search console kodu aktif çalışıyor mu? Analytics kodu aktif çalışıyor mu? Saymaya başladı mı? Bir problem var mı bu tarafta? Şimdi search console datası geç yansıyordu bundan önce. Yani 3 günlük data geliyordu. Ama şimdi artık son 24 saatin datasını görebiliyoruz. En azından daha hızlı sonuç verebiliyoruz. Ve şey var.

Inspect. URL inspect'ten sayfaya hemen istek atmamız gerekiyor. Gerçekten o sayfayı doğru görüyor mu Google? Yani yapısı doğru mu? Bir problem var mı? Bu arada sayfayı doğru görüyor mu deyince bir önceki maddeye geri döneceğim. Bu bence çok önemli. Onu atladık. Test sitesinde bence en çok dikkat edilmesi gereken şeylerden biri SSR sorunu. Yani server side rendering tarafındaki sorunlar. Yani gerçekten content'iniz HTML'de görünüyor mu? Şimdi yeni yapılarda bunu JavaScript'e getiriyoruz. Evet. Daha hızlı olduğu için. JavaScript yapılarının daha hızlı olmasından kaynaklı. Ama Google tarafı da bunu HTML'de gelmesi gerektiğini söylüyor. Hatta son dönemde bunu konuşmuştuk. AI botlarının JavaScript yetkinlikleri çok az olduğu için bu botlar da HTML'den tarama yapıyor.

Yani AI botları da sizin content'inizi HTML'den görmeli. Google bot gibi arama motoru botları da HTML'den görmeli. JavaScript'le getirilen content'ler HTML'le getirilen content'lere göre dezavantajlı content'ler. Siteniz single page application olabilir. Full JavaScript yapısıyla çalışan bir site olabilir. Ama content'inizi HTML tarafta getirmek oldukça size performans anlamında olumlu katkıda bulunacaktır diye bir not düşeyim. Bir önceki maddeye. Onu atlamak istemedim.

— İyi yaptın. Sen de az önce biraz değindin aslında da. Örneğin Google botu bir çağırıp live testten bir görünüme bakılabilir. Zaten hani şeyde de daha farklı testlerde de biz bunu simüle ediyoruz zaten. Ama hani canlı sitede de bir bakmak lazım. Hani screenshot ne durumda? Ya da diğer hatalar yüklenemeyen kaynaklar bölümünde. Hani diğer hataya da geçtim. Bazen Google bot çok yüklendiği için o kaynakları yükleyemeyebiliyor ama. Bahsettiğin işte robust.txt gibi. Yani bizim o live testte bir indekslenme ve taranma sorunumuz var mı? Zaten biz bunları kontrol ediyoruz ama atıyorum işte structure data'lar doğru gelmiş mi? Hatasız ya da uyarısız gelmiş mi? Bunlara bakmak gerekiyor. Bir de en çok gözden kaçan şey şu bence. Structure data'ları yine burada ona bağlayacağım ama analiz ederken ya da test ederken Şamork ya da Zengin Sonuçlar test aracı eğer bir hata varsa belirtiyor ya.

Ama şunu söylemiyor. Örneğin e-ticaretten gidelim. Name kısmı var product şema içerisinde. Name'in yanına ben örneğin işte kontrol etmemiş kimse name yazıyor. Hani bunu şey görmüyor. Zengin Sonuçlar test aracı. Çünkü orada bir data var diye görüyor. O yüzden buna biz SEO'cuların da biraz manuel kontrollerle bakmaları faydalı olacak kanaatindeyim. Bir de migration'ı biz başladık. Bugün yayına çıktık ya. Hemen bence her iki tarafa bir not eklemek lazım. Ben bugün migration'ımı yaptım. Hani bu saatte çıktım. Hatta çok böyle spesifik bir durum varsa ya da sizin Avrupa ya da diğer ülkelere bir raporlama yapmanız da gerekiyorsa belki saat dilimini bile yazmanız faydalı olabilir. Çünkü biliyorsunuz search console işte Kaliforniya saat dilimini kullanıyor.

Ama Google Analytics o mülkün kendi saat dilimini kullanıyor. O yüzden buradaki raporlama farklılıklarına da dikkat etmek gerekiyor. Bir de belki şey mantıklı olabilir. Şimdi biz yeni siteye şu anda geçiyoruz. Migration'a geçirdik. Belki sitemap'lerimizi oluştururken eski sitemap'ler durup yeni sitemap'leri de eklemek faydalı olabilir. Çünkü eski sitemap'ler olursa en azından Google onların redirect yediğini görebilir ve yeni URL'leri daha kolay keşfedebilir. Hani bunları mix'leyip search console'da sunmak daha faydalı olabilir diye düşünüyorum.

— Evet. Bu arada sitemap konusuna katılıyorum. Eğer bir sitenizin hızlı indekslenmesi noktasında kaygınız varsa mutlaka eski sitemap'lerinizi yeni yapıda 200 çevirecek versiyonda bırakmanızı öneririm. Çünkü o sitemap'lere sürekli olarak gelmeye alışmış bir Google bot var. Mutlaka gelecek ve sayfaları gezmeye başlayacaktır. Normal akışta da gezecektir. Crawl edecektir. Çünkü migration yapıldığını anladığında zaten Google bot o siteye daha fazla istek atmaya başlıyor. Kaynakları cache'leyebilmek ve yeni sitenin yeni yapısını görebilmek adına. Bir de geçişle birlikte mutlaka yani ilk madde diyebileceğim madde yönlendirme listenizin doğru çalışması. Yani eğer satırlarca yönlendirme listeniz var. URL yapısının değiştiğini varsayıyorum. Bunu mutlaka kontrol etmeniz gerekiyor. Gerçekten yönlendirmeleriniz doğru çalışıyor mu?

301 ile yönlendirirseniz 307 ya da 308 ne ile yönlendirdiyseniz status code'larınız doğru çalışıyor mu? Ki genellikle 301 ile yönlendiriyoruz. Doğru çalışıyor mu canlıda? Yani yeni sitenizde bu sayfaların 301 çevirdiğinden emin olduktan sonra artık yeni sayfaların indekslenmesini bekleyebiliriz. Az önce başından beri bahsettiğimiz otorite işte sayfanın yaşının aktarılması, o bilginin aktarılma süreci yönlendirme sitesinden geçiyor tamamıyla bu. Evet. Sayfanın birebir taşınması da önemli ama yönlendirme listesi olmadığı sürece onu Google bot yeni bir sayfaymış gözüyle bakmaya devam edecek. O yüzden oradaki sıralamalarınızı kaybetmenize neden olacaktır bu yönlendirme sitesinin hatalı olması durumu. Diğer bir nokta canonical etiketleri mutlaka mutlaka kontrol etmeniz gerekiyor. Çünkü test sitesindeki bazı versiyonlarda canonical etiketleri de test sitesinde kalıyor.

Canlıya geçtiğinde otomatik yapı düzelmiyor. Bunlar HTML tag'inin içinde kalıyor. Onlara otomatik bir rule yazılmıyor. Eski test sitesinin canonical'ı kalıyor. Bu gibi durumlarda mutlaka kontrol etmeniz lazım. Zaten siteyi mutlaka yeni siteyi bir crawl aldığımızda bunların hepsini görüyor olacağız. Yani anlık bir crawl listeye atıldığında tüm siteyi taradığımızda canonical'larda problem var mı? Title'larda var mı? İşte description'larda var mı? Bunlar quick win task'lar. Tabii ki manuelde kontrol edilmesi gerekiyor ama quick olarak kontrol etmemiz gereken şeyler bence bunlar. Bu süreçte diye özetleyebilirim.

— Kesinlikle Can. Ufak ufak sona doğru geliyoruz zaten. Şimdi hemen şu anda zaten canlıdayız bu case'imize göre. Bir süre geçti. Şu anda migration sonrasında aslında dikkat edilmesi gerekenleri belki konuşabiliriz. Çünkü migration'ı biz karar verdik ve tam o sırada geliştirdik biz bu tüm işlemlerimizi. Ve başarılı bir şekilde migration sürecimizi tamamladık. Aslında biraz daha sonrasına dair konuşabiliriz. Hatta ben bununla ilgili ufak da bir ekran paylaşımı yapmaya çalışayım. Hani hem konu da aklımıza gelir hani konuşurken. Şimdi öncelikle benim söyleyeceğim şeylerden bir tanesi. Eğer siz bir domain değiştiriyorsanız Google Search Console'daki adres değişikliği aracını kullanabilirsiniz. Yeni URL'inize bu farklı ülkelere ait URL'ler de olabilir. Eğer taşındıysa burada mutlaka adres değişikliği aracını kullanmanız faydalı olur.

Zaten yeni URL'ye ait mülkü de doğrulamanız gerekiyor. O yüzden öncelikle bunu yapmanız gerekiyor. Tabii ki bir URL değişikliği yaptıysanız bu aracı kullanmanıza gerek yok. Ama hani burada yeni bir domain'e geçtiyseniz bunu kullanabilirsiniz. Bu benim aklıma geldi. Bir de şeyi gösterebilirim belki. Gösterebilirsem. Bir saniye. Hemen şu Scrum Frog'u paylaşmaya çalışayım. Geldi mi Can Scrum Frog?

— Evet geldi.

— Tamam süper. Burada da aslında şu şunu yapabilirsiniz. Hani biz neler yaptığımızla alakalı biraz teknik konulara girmiş olacağız ama en azından bazı şeyler aklınızda canlanır diye düşünüyorum. Şimdi migration öncesinde sitemizin bir crawl'unu alalım. Scrum Frog'dan bir yedeğini alalım. Burada en azından previous bir yedeğimiz olsun. Ardından da canlı geçtikten sonraki bir yedeğimiz olsun. Burada da aslında Scrum Frog bunu çok güzel bir şekilde gösteriyor. Scrum Frog'u açtığınız zaman compare modunda bu iki crawl'ı çalıştırabilir ve ardından da nelerde değişiklik olduğunu görebilirsiniz. Hatta compare kısmından da şeyleri yapabilirsiniz. İşte similarity change'i şu kadar fazla olanı bana göster ya da bazı detayları gösterme gibisinden. Bunları test etmeniz bence faydalı olur. Bir de şeyi söyleyebilirim belki. Şu an bu moddan çıktığınız zaman şu kısım aktif olacaktır.

List moduna geldiğiniz zaman ya da siteyi spider moduna taradığınız zaman always follow redirects seçeneğine tıkladığınız zaman da aslında redirect'leri 301'leri tekrardan takip eden bir crawl sonucu elde edeceksiniz. O yüzden bence Scrum Frog'da bu tür ayarların da açık olduğundan ve siteniz bu şekilde taradığından emin olmanız teknik olarak birçok şeyin de gözden kaçmasını engelleyecektir. Şeyde migration sonrası işlemlerde.

— Bir de migration sonrası tarafında bu arada çok kıymetli bilgiler. Scrum Frog zaten migration sürecindeki elimiz ayağımız bizim. Siteyi hızlı taramak ve tüm dataları çekebilmek için. Çünkü market tarafına da bazı datalar lazım oluyor. Onların hepsini de çekip işte biz de kendi backup'ımızı tutuyoruz diyebiliriz bu tarafta. İşte sayfanın title, description, canonical'ları, content'i işte varsa SEO için kıymetli bir alan içeride bunları tutuyoruz. Geçiş ile birlikte daha doğrusu geçiş döneminde eğer mümkünse sonucu genişliğinizi, sonucu bandwidth'inizi genişletmenizi tavsiye ederim. Çünkü az önce de söyledim. Google bot sizin sitenizin yeni bir yapıya geçtiğini, migration'la başladığını anladığı süreçte daha çok istek atmaya başlıyor. Bunu Search Console Crawl Stats tarafında zaten görebilirsiniz çok net bir şekilde. Her kaynağınızı yeni taramaya başlıyor.

Her URL'inizin içindeki yapıları yeni görmeye başlıyor. Haliyle hızlıca cache'leyip pozisyon verecekse pozisyonların, sayfaların indeksle değiştirmesi gerekiyor. URL'ler değişiyorsa bunları indeksle değiştirmesi gerekiyor. O yüzden sunucu tarafınızdaki yükü azaltmak adına band genişliğinizi arttırmanızı öneririm. Çünkü bunun negatif olduğu yani bandın dar olduğu bir durumda sunucu yanıt süreleriniz oldukça fazla artacaktır. Bu da sizin crawl isteklerine, request'lerinize etki edecektir. Sunucu yanıt süreniz ne kadar artarsa crawl isteğiniz de o kadar düşecektir. Hatta bununla ilgili bir sunucu optimizasyonu ile ilgili bir gelecek dönemle ilgili ne yapılması gerekiyor eğer crawler'lar tarafında belirtmiştim bunu da. Sunucu yanıt sürenizin az olması sadece migration için değil her anlamda sizi olumlu etkileyecektir diyorum.

— Kesinlikle. Orada Can şeye belki pas atabilirim. Tekrardan konuşabiliriz daha doğrusu. Robust.txt'den sen zaten bahsetmiştin. Şu da olabiliyor. Bizim test sürümünde bazen görmediğimiz yeni parametreler bir anda ortaya çıkmış olabiliyor. Çünkü çok fazla kombinasyonla beraber oluşuyor ya bu filtreli URL'ler. Aslında bunları da gerçekten test aşamasında kontrol edip ben bunu zaten engellemiştim deyip geçmek yerine sonrasındaki dönemde tek tek o parametreleri çünkü Google'ın gözünde biz webmasterlar olarak bu siteden sorumluyuz. O yüzden bunların hepsini optimize etmemiz gerekiyor. Şu da çok fazla sık gördüğümüz detaylardan bir tanesi. Biz her ne kadar Google bot gibi simüle etsek bile sayfalarımızı biz bir Google bot değiliz ya da onun gibi analiz edemiyoruz. Sayfalara tarayamıyoruz. O yüzden burada mutlaka Search Console'daki dizin kapsamı raporlarına bakabilir ve mutlaka en azından bir günlük, iki günlük loglara bakıp ya ben zaten bu parametreleri engellemiştim ama farklı bir parametre ya da farklı bir URL yapısı da olabilir.

Hani bunlar loglarda görünüyor mu? Atıyorum bir iki tane event geldiyse, bir iki tane request varsa tamam o zaten çok büyük sorun değil ama belli bir eşiğin üstündeyse tabii ki bu siteye göre değişir. Burada onu gördükten sonra log analizinde de bir iki günlük logları bile kontrol etseniz oradaki ilk aşamada tarama bütçenizi optimize etmek için çok faydalı olur. Çünkü bu sayfalar Google dizine girdikten sonra siz onları göreceksiniz. İşte Google Search Console hatta sarı uyarı şeklinde de veriyor. İndeksten Google dizinde ama Robust.txt ile engellendi şeklinde de hatalarla karşılaşabiliyoruz. O yüzden bunları en başta görüp buna göre aksiyon almak bence sitenin sağlığı için migration aşamasının en sonundaki süreç için çok daha kıymetli.

— Evet katılıyorum kesinlikle. Robust.txt'nin doğru çalışıyor olması, parametrelerin doğru kapatılmış yani eski sitede yıllardır kapattığınız bir parametreyi bir anda açmış olabilirsiniz farkına varmadan. İndekse girecek. Çünkü onu indeksten kaldırma süreci de çok zor bir süreç.

— Evet içinde şey olmuyor böyle diyorsun ki bunu açacağım ama bir sürü request gelecek. Tamam belki atıyorum işte 100.000 URL'yi kaldıracağım dizinden ama bir sürü de istek gelecek diye düşünüyorsun.

— Maalesef o nokta orada hem sitenin yükünü arttırıyor hem de sizin taraftaki eforu arttıracak. Yani müşteri yönetimi yazılım tarafındaki eforu arttıracak bir süreç oluyor migration süreci. Bir de migration sürecinde değineceğim noktalardan biri. Şimdi migration yapar yapmaz sitenin test sitesi hızını kontrol ediyoruz haliyle. Burada genellikle test sitesinde aldığımız hızı almamız mümkün değil. Zaten her migration yapan bunu biliyor. Bu hızı düşecektir diye. Bir de anlık alınan isteklerde sizin o an tüm sayfalarınız sunucuda değişmeye başladığı için yani geçer geçmez test sitesi hızı almak her zaman sağlıklı sonuç vermeyecektir.

Daha düşük sonuçlar da verecektir bu tarafta. Çünkü o sunucunuz çalışıyor. Ona cevap verme süreci uzayacaktır. Bunu unutmayalım. Bu tarafta yine işte GTM kodları test sitesinde çalışıyordu belki ama aktif olarak canlıda çalışmaya başlayacak. Anlık olarak yükünüz artacağı için site hızı skorlarınız aşağıda olabilir. Yine bununla birlikte Core Web Vitals raporları. O gün sizin Core Web Vitals raporlarınızın düzelmesini bekleyemezsiniz. Çünkü tüm siteyi önce bir taraması lazım. Ki kullanıcı verileri datasının da alması lazım bu tarafta. Sitenize kullanıcı gelecek. Core Web Vitals skorları belirlenecek. Buna göre size bir data sunacak. Tabii ki bu tarafta geliştirme hiç bitmeyecek. Sizin siteniz tarafında yani sitelerimiz tarafında. Bunu zamana yayarak düzenlemek gerekecektir diye düşünüyorum.

— Kesinlikle Can. Benim de zaten bununla ilgili ekstra diyeceğim bir şey yok. Hepsini konuştuk. Son konu başlığımıza gelelim. Migration sonrasında performans ölçümlemesi SEO'da en önemli konulardan birisi aslında. Evet biz bu migration'ı yaptık ama hani ne oldu ne bitti. Tabii ki burada KPI'lar farklı. Şu da olabilir. Sen de az önce de bahsettin. Belli bir süre için de SEO ajansıyla çalışabilirsiniz. Örneğin işte benim 2 aylık, 3 aylık bir sürem var ve bu sürede ben bu migration'ı yapacağım. O yüzden bana burada yardımcı olun da diyebilir markalar.

Burada migration süreci sonunda performans ölçümlemesinde nelere dikkat etmek gerekiyor? Neler yapmak gerekiyor? Örneğin işte benim aklıma gelen ilk konulardan bir tanesi hani not ekleyin demiştim ya. Burada gerçekten average pozisyonlara bakmak gerekiyor. Sen de bahsettin işte Core Web Vitals'ta hemen bir düzelme beklemem gerekiyor. Ama onun haricinde işte time to first byte metriğini eğer sunucu değişikliği olsa ya da sunucu diye bırak bir backend geliştirmesi dahi olsa oradaki kodların hepsi zaten bu sunucu üzerindeki yükü etki edebildiği için oradaki time to first byte metriğine bakılabilir.

Trafiğe direkt böyle ikinci günde bakmak doğru olmayacaktır. Çünkü belki o gün bir atıyorum tamam okullar açıldı bir trend sorgu oldu ve okul çantası satıyorsunuz ve çok büyük bir trafik almış olabilirsiniz. Yani o yüzden o süreç belli bir geçtikten sonra tamamen markaya göre değişebilir bu. Hani buradaki hem SEO performansı noktasında belirli işte organic keywords, top 3 keywords, organic traffic gibi metriğe bakabilir. Hem de teknik anlamda ben neleri değiştirdim buna bakmak faydalı olabilir diye düşünüyorum. Çünkü biz bir sürücü direct yaptık. Acaba sunucu all sunucu datasında, all status code'da benim 301 oranım ne? Ya da 304 veren yani değişmeyen statik kodunu veren sayfa sayım ne kadar? 200 sayfa sayım arttı mı azaldı mı gibi bence teknik olarak tüm bunları düşündüğümüzde pasta grafiğine bunlara bakmak faydalı olabilir.

— Evet katılıyorum bu tarafta. İlk başta söylediğimiz migration'ı ne zaman yapmalıyız konusunda. Aslında bizim trend sezonumuzda yani sitenin trend sezonunda migration yapmayın dememizin temel sebebi bu. Bunu ölçümlemek sizin için oldukça zor olacak. Yani çok aktif çalıştığınız işte kamp malzemeleri işte kış kayak takımı sattığınızı varsayalım. Kayak takımı sitesini kış ayının kış mevsiminin ortasında geçirdiğinizde sitenizde yaşanacak trafik artışı ya da düşüşü pozisyon bağımlı bağımsız bunları analiz etmek migration'ın etkisi mi değil mi hem SEO tarafı için hem sizin için oldukça zor bir hal alacak.

Evet belki yapınız tamamıyla doğru çalışıyor. İşte satış süreçleriniz çok iyi. Ödeme sistemleriniz çok iyi. Hiçbir problem yok. Arka tarafta alışveriş yapılabiliyor. Ama trafiğiniz düştü. Kayak takımı sayfanızın trafiği düştü. Örnek veriyorum. Bu taraftakinin işte migration'dan mı düştü? Pozisyon kaybı migration'dan mı? Yoksa trend oldu. Trendde işte serp değişti. Buna göre mi? Bunu karşılaştırmak oldukça zor. O yüzden değişiklik yapıldığı dönemler yani örnek veriyorum işte bugün 30 Ocak'ta biz geçiş yapıyoruz. Migration yapıyoruz. 30 Ocak gece 1'de. Artık 30 Ocak gece 1'den sonraki süreç o site için bir önceki yılın aynı sezon trendinin karşılaştırılması, bir önceki periyodun karşılaştırılması işte bunlara göre average trafik ki bu average position'dan kastımız tüm sitenin average position'ı değil.

Gerekirse kelime kelime, kategori kategori hepsinin incelenmesi gerekiyor bu tarafta. Yani overall bir yükseliş her şeyin yükseldiği anlamına gelmez. Overall düşüş bir her şeyin düştüğü anlamına gelmez. Zaten migration'la birlikte eğer URL yapınız değiştiyse ve yeni URL'ler eklendiyse average position'ınızın yükselmesi yani negatif anlamda düşmesi beklenir. Çünkü yeni sayfaları indekse sokuyorsunuz çok normal bir şekilde. Son migration sürecimde blok yapısı yoktu müşterimizin. Yeni bir blok yapısı entegre ettik. Haliyle yeni blok içerikleri geldi ve bu içeriklerin bir anda ilk sıralarda listelenmesini bekleyemediğimiz için average position aşağı doğru geliyor.

Bunların kontrolünün yapılması, ölçümlenmesi oldukça önemli. Evet bunu söylüyoruz ama gerçekten blok tarafı nedeniyle mi average position böyle? Bunların düzenli kontrolü. Tabii ki bu kontrolden kastım ertesi gün değil. Yani bu migration süreci ki bununla ilgili Samet sanırım bir toplantımızda konuşmuştuk. İşte bir sitenin sen anlatmıştın diye hatırlıyorum. Migration süresinin ne kadarda bir Google'un artık migration'a oturduğu süreci. Yanlış hatırlamıyorsam bir yıl mıydı?

— Bir yıl saklayın diyordu URL'leri. Hani sonunda ben zaten onları veri tabanımda yenileriyle güncelleyeyim diyordu. Aslında bu tabii ki sitenin büyüklüğüne göre değişiyor. Atıyorum 2 milyon URL'im varsa bu daha da uzun olabilir ama 3 aşağı 5 yukarı öyle bir açıklama vardı.

— Aynen öyle. Zaten şeyde bunu da göreceksiniz yani. Ben işte migration yaptığım sitelere gidiyorum. Crawlstats'tan attığı request'lere bakıyorum. Gerçekten migration'dan önceki URL'lere de istek atıyor. Dönem dönem gidip onu 301 çevirdiğini teyit etmeye çalışıyor.

— 301 bile atabiliyor ya. Tamam bu süre çok az ama hani nedeni şu. Ben bir şey kaçırmayayım. Hani belki de orada değerli bir içerik vardır. Gidip görüyorum. Hani diğerleri gibi çok sürekli atmaz ama en azından atar ve bunu görürseniz de çok endişelenmeyin. Belki de 3 yıl önceki bir şeyi görüyordur. Çünkü SEO tool'larında bile Can fark etmişsindir. Son 5 yılı seç mesela Ahrefs'te. Bir bakıyorsun farklı URL'ler var orada. Halbuki o 5 sene öncesinin URL'i ya. O bile Ahrefs'te varsa Google datasında olmama ihtimali çok az zaten yani.

— Tam olarak bizim gibi düşünüyor aslında Google. Biz hani çok iyi listelenen bir sayfamızı sorunsuz geçtiğinden emin olmak için defalarca kontrol ediyoruz ya. Google da onu yapıyor. Yani bu sayfa 3 yıl önce çok iyi listeleniyordu ve trafik alıyordu. Yani otoriter bir sayfaydı. Bu sayfada bir değişiklik var mı diye haliyle gelip gelip kontrol etmek istiyor. Çok da normal bir süreç bu tarafta. Geçiş süreciyle yaşanması ki bence iyi de bir süreç. Bence eski sayfalar geliyor olması o sayfaları otoriter kıldığını ve markanızı da otoriter kıldığını düşündürtebilir bu tarafta bize. Diye özetleyebilirim.

— Aynen. Benim aklıma bir de şey son sorusu geldi. Çok sık duyabiliyoruz. Ya Samet işte tamam biz migration yapacağız ama benim trafiğim yükselir mi? Yani net cevap şöyle verebilirim. Eğer siz kullanıcı deneyimini düşünerekten bir migration yaptıysanız sorunsuz hiçbir şekilde işte 301'lerin sıkıntı yaşamadığı bir süreç ya da birçok farklı konuyu da düzeltip bu migration işlemini yaptıysanız artabilir. Bu tamamen şey yani Google'a bağlı ve sizin sunduğunuz deneyime bağlı. Hani burada size net bir şey cevap vermek doğru olmaz. Evet migration yaptıktan sonra siten kesinlikle uçar gider. Çünkü yani burada migration türlerini bile ilk giriş kısmında anlattık.

URL değişikliği olabiliyor. Sadece frontend değişikliği olabiliyor. O yüzden hepsi çok farklı case'ler. Bu case'leri kendi özelinde değerlendirmek gerekiyor ve URL sayısı olarak değerlendirmek gerekiyor. 2 milyon URL'deki o değişimi Googlebot'un görmesi gerçekten belki de işte 6-7 ay alabilirken 200 sayfalık bir sitede bu belki de 1-2 ayda olabilecek bir şey durumuna gelebiliyor. O yüzden trafiğim yükselir mi? Eğer iyi bir siteye geçiş yaparsan teknik olarak ve kullanıcı deneyimini de düşünerekten bir geçiş yaparsan neden yükselmesin? Ama diğer türlü yapılacak her hatadan dediğim gibi biz webmasterlar olarak sorumluyuz ve Google'da eğer burada bir düzenli hata silsilesi görürse orada maalesef bizim sitemize kötü etki edebilir.

Tabii ki bu uzmanla çalıştığınız seneler çok olacak şeylerden biri değil. Çünkü çok fazla test yapıyor. Buna da değinmek istedim son olarak.

— Tamamen senin dediğin gibi. Biz birçok case yaşadık burada. O yüzden bunu net bir şekilde söyleyebiliyoruz. Yani sorunsuz kullanıcı deneyiminin yüksek olduğu ve gerçekten her şeyin güzel çalıştığı. Yani bizim SEO tarafı için mesela kendimiz adına bizim gerçekten evet bu site hazır dediğimiz noktalarda yapılan geçişlerden sonra genellikle o sitelerin genellikle dediğim %99 seviyesinde o sitelerin aksi bir durum olmadığı sürece yükselişe geçtiğini görüyoruz. Bu şu yükselişten kastımız yine hatırlatayım. 30'unda geçtik. 31 Ocak günü tavan yaptı değil. Bu zaten sizin sitenizi tarayıp indeksleyip sonra katma değerini görüp devam edecek bir süreç olduğu için zamana eğri bir şekilde yükselişe geçtiğini o performansı almaya başladığını ve o noktaya geldiğini göreceksiniz.

Ama bunu genellikle kötü çağırıyoruz bu durumlarda. Daha kötü bir geçişte de stabil giden bir trafiğinizin düşme ihtimali var. Ben ama şeyi yeğlerim yani. Update'de mi düşecek migration'da mı dersen ben migration'ı yeğlerim bu arada. Çünkü genel migration'dan düştüğünü bildiğin.

— Biliyorsan en azından.

— Bakman gereken noktalar daha belli ve yani gerekiyorsa backup'a dönelim ya da işte daha iyi bir şey yapalım hemen hızlıca diyebileceğin şeyler var. O yüzden ben daha az risk yani. Bugün sabah uyandığımızda yarın sabah uyandığımızda update olmuş ve siteniz düşmeye başlamış olabilir. Bu daha büyük yani hiç beklenmedik bir durum. O yüzden migration o kadar da riskli bir nokta değil bence.

— Kesinlikle. Ben de sana katılıyorum. Konu başlığımızı bitirdik Can. Benim de aklıma başka bir şey gelmedi vallahi. Çok iyi. Hani ben anlattığımızı düşünüyorum bu süreçleri. Dediğim gibi çok farklı migration çeşitleri var. Umarım hani eğer bu sürece girdiyseniz umarım çok istediğiniz bir yapı haline edersiniz ve trafiğiniz, organik trafiğiniz çok iyi seviyelere gelir. Mutlaka dikkatli çalışmakta fayda var. Hani son olarak bunu da belirteyim. Çünkü bayağı bir sıkıntı olabiliyor. Vallahi benim aklıma gelenler bunlar. Can senin varsa son böyle aklına gelen bir şey. Onu söyleyelim ve ufaktan kapatalım.

— Gayet güzel konuştuk. Unuttuğumuz bir noktalar olabilir yani. Bunlar çok normal. Çok geniş kapsamlı. CDN optimizasyonlarına kadar giden bir süreç bu. Genel biz hatlarıyla bahsetmek istedik. Bilgilendirmek istedik. Burada önemli olan şey bir SEO uzmanıyla çalışmak. Ekibin buna hazır olması. Yani hem yazılım ekibinin hem backend hem frontend'in bu yapıya hazır olması.

— O zaman ufaktan videoyu kapatalım. Eğer videoyu beğendiyseniz like tuşuna basmayı ve kanalımıza abone olmayı unutmayın. Bir sonraki Zeo Talks'ta görüşmek üzere. Kendinize iyi bakın. Hoşçakalın.

— Hoşçakalın.