— 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.
— Hi everyone. Welcome to Zeo Talks. Today, Can and I are discussing migrations. Managing migrations is crucial for SEO. This applies to site merges or site moves. So, our topic today is migration. I wanted to chat with Can about it. He manages the most migration projects at Zeo. His insights will be incredibly valuable.
— Thanks.
— Can, should we dive right into our topic? What do you think?
— Let's do it.
— It’ll open up as we go. Let's keep it moving.
— Exactly. Let's do that.
— Right. My first note is about the basics. What is a migration? Why do we do it? Let's give our viewers some context. Migration covers site moves, merges, or any URL değişikliği. We'll definitely cover the technical side of this. We do this for many reasons. Maybe merging sites. Moving sites from different domains to one. Or splitting into different languages. There are many scenarios here. The URL yapısı often changes. If your old URLs perform well, you must map them correctly. If you mess up the migration, you will lose your traffic.
These are critical. I don't know who still does it, but HTTP to HTTPS moves were huge. We also handle migrations when moving from separate mobile sites to responsive designs. We help brands get through this with minimal damage. Over to you.
— You summarized that perfectly. These processes scare site owners. It affects SEO performance and overall site health. Think e-commerce integrations, B2B form tracking, analytics, and GTM codes. Everything must move to the new structure. Think of it like moving houses. It’s a site migration. There are many factors involved. Some migrations involve only design changes. Others change both the design and the URL structure. Sometimes the CMS changes too. Or the CMS changes while the design stays the same. You must always check the URL structure. There are many types of migrations. Design-led migrations are the most common.
Sites age and need new tech. They move to a new CMS or change infrastructure. In e-commerce, we see infrastructure and CMS changes all the time. From an SEO perspective, we fix the category structure if it’s broken. You have an existing balance to maintain. You need to set up the new structure correctly. Should you migrate or not? I think you have a point on that. Let’s shift to that. We can discuss it further. How should a site handle a migration? Why or when should they migrate? In my experience, that’s usually a brand decision.
Usually, the old structure isn't working anymore. They can't handle technical tasks. The design feels dated. They want a lighter design. It helps with Core Web Vitals metrics. Major CMS changes often force a new URL yapısı. Moving to a new CMS is a huge deal. The decision-making process is the most critical part. I think you’ll agree. Migration needs to be integrated with SEO from day one. Brands often come to us after the design phase. We also manage migrations for our own clients.
Brands usually think about SEO only after the design is finished. You should really manage SEO alongside the design process if possible. New widgets or components affect SEO. You need to plan heading structures in the CMS. If the CMS lacks a text editor, you must build one. These technical details are vital for future SEO.
— To clarify, let me ask you this. Say I’m at a brand and we only updated the front-end. Should we treat this as a full migration? What do you suggest to brands? Does a front-end update always require a migration? What are your thoughts on when a migration is actually necessary? How do you handle redirects?
— Any migration needs SEO involvement. Even a simple redesign counts. You might think nothing is changing. But you still need to check.
— At the very least, verify it.
— Exactly. A redesign changes site performance. Your JavaScript and CSS structures will shift. Your URL structure might stay the same. Your internal links might look identical. But the load process changes. The number of requests and JavaScript sizes will fluctuate. You need page speed optimization. The new site might be slower than the old one. People often pick themes based on demo speeds. They look fast. But that approach is flawed. We see this a lot with CMS platforms. The demo lacks your GTM tags. It doesn't have your add-ons. It misses your third party scripts. It ignores tools like Insider.
Test these with SEO in mind. Even for simple design changes. Check if your heading structures work. Are they the same as the old site? Did any content get lost during the move? Check mobile responsiveness. Are there any MFI issues? Even a simple design change is a heavy process.
— Absolutely.
— That’s why you need support.
— I agree. It’s crucial. You touched on when to start migration. It depends on the brand. Are they ready internally? They should hire an SEO expert or agency when they are. Is your team ready? We’ll build a roadmap and a redirect list. These are incredibly valuable. We’ll cover that shortly. Like I said, timing is everything. You need to feel ready. There is a lot happening in the background. My humble advice? Start the process. But ask yourself, are you actually ready for a migration?
Do your dev teams have the bandwidth? Is your marketing team ready? Can you handle the workload after the migration? There are so many moving parts here. It’s a lot to manage. Also, when should you do it? Can, this is a great point to bring up. I think even Google folks have mentioned this. Let’s talk about when NOT to migrate. My take? Don't do it during peak traffic. If you have a small site, maybe try the weekend. Sunday night works well. Avoid those high-traffic days. Every site has its own unique traffic trends.
That’s the best way to answer when not to do it.
— You’re right. We usually push migrations late at night. Or early on weekend mornings. We target times with the lowest traffic. We want to avoid impacting real users. E-commerce sales drop during high-traffic hours. Timing is everything. Knowing when not to migrate is critical. Brands think SEO makes migration seamless. They expect zero traffic loss. That’s a common misconception. That’s the goal, though. We aim for perfection. We control every variable. Migration covers everything from content to technical SEO. We even audit external links and no-follow tags.
It’s basically a full site audit. Don't migrate during your peak season. If summer is your high season, avoid it. It’s way too risky. E-commerce sites often hit integration issues. Live launches can go sideways. Maybe Google dislikes your new design. It might offer less value than the old one. Design-wise, it could be a step back. Or the site might run slower. API calls might lag under heavy load. We track this, but I have a rule. If a site performs well, plan the migration carefully.
You need a longer runway to protect that performance. We’ve both seen this happen. Brands set a hard deadline and rush the migration. That’s usually a mistake. That’s the right approach. Deadlines are necessary. But here is what I tell every brand. Your site is already live and working. You can push some tasks to phase two. But you must finish the critical tasks. Don't skip essentials just because of a deadline. You end up with a broken site. The current performance is fine. Maybe the CMS is changing. But if the new site has unresolved technical issues, don't go live.
You’re just trading a working site for a broken one. If you hadn't migrated, the site would still work. Why break what isn't broken? That’s the mindset you need. Deadlines matter, sure. But they always slip during a migration. Too many teams are involved. It’s not just SEO and dev. Everyone is working at once. Something always hits a snag. But you must wait until every team says they are ready. That is critical. When you do that, migration traffic loss becomes negligible. In fact, the site often surges after a proper migration. We’ve seen it happen. One of our brands hit a massive growth trend after a long migration process.
— Exactly. Big brands often change their CMS. They might migrate the German site first. Then they try to hit a deadline for the Turkey site. It often drags on. I totally agree with you. Let’s move to the action plan. We’ve decided on the migration. We covered the "why." Now, what should we watch out for before the migration? Let’s dive into that. Like I said, migrations vary. You have site mergers or site moves. There are many types. I’ve decided to migrate. What should I look out for first? Let’s talk about that.
First, always take a backup. Back up your site. Keep it safe. These are valuable. Don't lose your data. Always do this. I’ll toss the ball to you on pre-migration steps.
— Your first point is spot on. A live site backup is crucial. You might hit a technical snag during the switch. You may need to roll back. Most teams do this now. We used to have issues with this. We had backup issues before. But developers and agencies are experienced now. I haven't seen this problem in a long time. We rarely roll back to backups. It’s rare, but you might need historical data. You need to know how your old site worked. That’s why backups are key. Once you decide on a migration, what are the next steps? I touched on this. You need SEO support right after deciding to migrate.
This could be ongoing SEO or just migration support. Get whatever fits your current needs. The first step is defining the design or building a custom one. Design it with SEO in mind. Use modern libraries for JavaScript. Use new CSS structures. Handle text compression while writing the code. If you wait until testing. The dev team will struggle to go back and fix it. They have too many other tasks. Also, optimize your DOM size. I think you’d agree with me here. It’s the most overlooked part of development. DOM size and depth get very little attention.
Teams rush to finish the project. They think fast loading and a clean front-end are enough. But optimizing DOM size later is nearly impossible on a live site. You’d have to rewrite the entire codebase. That’s basically another migration. Every step from design to front-end implementation needs care. Next, you need a test site. You need a test domain. Run a local test. Set up a test site wherever you prefer. Before going live, we need to migrate all our content. You can automate this via API or do it manually.
Content migration is key. It’s just as important as the front-end SEO. Don’t lose any content. Map your structures correctly. This is an SEO-heavy task. During migration, we map the old site’s crawl and tree. We decide what to keep and what to drop. I see migration as a fresh start. Samet, do you agree? I see it as a deep clean.
— Absolutely. Migration lets you fix old issues. Take internal links. If you didn't 301 them properly, you might have messy redirect chains. You must watch your URL yapısına during the move. Fixing internal links before migration saves you a massive headache later. I assume you'll cover URL yapısı here too. It's crucial to address it early.
— By cleaning up, I mean something specific. Take old content or categories with past traffic. If it's outdated and gets no traffic, it's useless. It’s just dead weight. It hurts crawl budget and server load. We waste resources keeping those pages alive. Cleaning this up is vital for migration. URL structure matters here too. This is usually a brand decision paired with SEO. Maybe we change the category tree or the URL yapısı. Maybe the old URL yapısı was terrible. We want a clear hierarchy. Categories should sit under the root domain. Final URLs belong under categories. A clear site structure is a must.
Google needs to follow your page structure. It needs to find your category trees. Users are used to this now. They navigate back to parent categories constantly. E-commerce sites have trained users to expect this. If that structure is missing, we push to build it. As SEOs, we define the site structure. The brand might not see an issue with the URL yapısı. We see the problems they miss. This is how the category structure should look. This is how the URL should look. But here is the catch. We must remember we are redirecting these pages. This isn't just a custom redirect. The page URL is changing.
If this page gets 1 million clicks a month, it will get redirected. The URL flow for this page will shift. We will try to pass all its authority to the new page. It might not be a 100% transfer. You might see some traffic loss here. Two main concerns worry us during migrations. First, changing the URL yapısı. Second, fully optimizing site speed. Samet, I think you agree with me here. When these two go smoothly, the whole migration usually goes well. I'm not talking about test sites. I'm talking about SEO right now. These are the versions that go smoothly. I think we need to be much more careful with URL redirects and URL değişiklikleri.
— Absolutely. I can add something else regarding the URL yapısı. We SEOs always adapt to the URL yapısı. For example, I mentioned Germany. If your parent company websites in Germany have already migrated to a specific URL path. We adapt to it as SEOs. It also happens that clients ask us to suggest a new URL yapısı. We can adapt to the URL yapısı in both of these ways. My general advice to everyone would be this. Take parameters, for example. I’m talking about non-indexed and non-crawl parameters. Let’s say we use new parameters in the new structure. Maybe to scale our ads.
This is just an example. We’ll block them for SEO anyway. Especially pages with no search volume. People often say. "But site X doesn't do it this way." There are too many variables. First, I’m giving you the most optimal SEO solution. Second, those brands might be mid-migration. They might have managed it poorly. Or it’s just sitting in their backlog. You need to compare things correctly. You have to trust the SEO process. We want your site to succeed even more than you do. These edge cases happen all the time.
We’ve dealt with tons of filtered URL'ler and parameters before. You know how it is. We just need to stay sharp on those. I wanted to mention that while it’s on my mind.
— Yeah, that reminds me of something. Since you brought up URL structure and parameters. Think about a migration where the entire URL yapısı changes. You’ll have redirects everywhere. Site owners often miss one critical thing here. We build test sites with the new structure. We face internal link issues during migration. If we move content with old internal links, they all trigger 301s. This happens once we go live. You must map this flow for the new site during migration. Remember that brand we worked with? We warned them, but the team forgot. We had to go back and change every single URL.
They couldn't automate the changes. That’s why it was necessary. If the URL yapısı changes, I treat it differently. I tell brands this. It’s your new site, but it’s a totally different site. Don't compare it to the old one. Don't think like the old site. Everything is new. The product page URL is different now. Treat it like a brand new entity. That’s how it should be done. If we just bring over old stuff, why migrate? I don't mean the content. I mean the structure. Having 300 URLs hitting 301s on a new site is bad. It shouldn't happen. The site must be flawless before going live. That’s my take.
— Exactly. Totally agree. Plus, you mentioned URL age. We’ve served that product on the same URL for five years. Now it’s a brand new URL. Google and other bots need time to trust it. Building that history takes time. As you mentioned, backlink signals and requests reset. Everything starts from scratch. Our job is to minimize risk. We need to handle this fast.
— Let me jump in, Samet. URL değişikliği isn't always site-wide. You can change them category by category. Maybe your product URL yapısına is fine. But your blog URL yapısı might be tied to the root. You can change the structure there. Add some paths. URL değişikliği doesn't mean changing the whole site. Sometimes specific paths have typos. Maybe you used Turkish characters by mistake. But those pages have built authority. You can still change them. I wanted to clarify that point.
— Exactly. I totally agree. So, the brand decides on a migration. We discussed the pre-migration steps. We had the meetings. The reports are ready. We prepped the rule sets. We simulated and checked the redirect lists. Like you said, nofollow tags and content are set. We're ready. We decide with the brand at 9:30 AM. We say. "We're going live at 10:00 AM." Let's talk about what to watch for during the actual migration. When we launch a migration, we use GTM. Tracking codes and third party scripts must fire immediately. Those scripts need to be fully operational right away.
We cannot afford any data loss. I think we should dive deeper into these topics.
— Yeah. That migration moment keeps me up at night. It’s incredibly stressful. I’ve done it countless times, but it’s always nerve-wracking. Even though we’re the ones who should be the least stressed. Google bot starts crawling the moment we go live. We’re the ones who can actually make changes. It’s not just an instant reflection. I’ve noticed something in my recent migrations. Teams often work too independently. Our last migration wasn't like that. Everyone was synced up. That’s crucial. I don't mean physically. I mean everyone staying in touch online for instant checks.
Migration time depends on site size. Some go live in ten minutes. Servers move, CMS updates, and that’s it. Others take an hour. If your site is massive, the CMS migration takes much longer. I think a phased migration is much healthier. Don't migrate the whole site at once. Migrate specific structures in stages. There are key points we must check during this transition. First, check your redirects. Since we work on a test site, check HTTP to HTTPS. Check trailing slashes. Check www vs non-www. If the test site is a subdomain, we can't verify these.
You must check these during the migration. I'm not listing these in order of priority. Just keep them on your checklist. You should handle this on the test site anyway. Second, check robots.txt. Did the original robots.txt carry over? Is the test site version working correctly? Also, is your search console code active? Is your analytics code firing? Is it tracking data? Any issues there? Search console data used to lag. It took three days to show up. Now we see the last 24 hours. We get faster feedback now.
Use URL inspect to ping the page. Does Google see the page correctly? Is the structure right? Any issues? This ties back to my previous point. It's crucial. We skipped one. SSR is a huge issue on test sites. Server-side rendering matters. Is your content actually in the HTML? Modern stacks push this to JavaScript. True. It’s faster. JavaScript frameworks are faster. But Google insists on HTML. We discussed this recently. AI bots have poor JavaScript support. They crawl from HTML. AI bots need your HTML content. Google bot needs it too. JavaScript-rendered content is at a disadvantage. Your site might be a single page application.
It might be full JavaScript. But serving content via HTML boosts performance. I had to add that note. I didn't want to skip it.
— Good call. You touched on it earlier. Run a live test with Google bot. Check the rendered view. We simulate this in other tests. But check the live site too. How’s the screenshot? Check for failed resources. Sometimes Google bot gets overloaded and skips them. Like robots.txt issues. Do we have indexing or crawl issues in the live test? We check these, but are the structured data correct? Are there errors or warnings? You need to check these. The most overlooked thing is this. I'll tie it back to structured data. When testing with Rich Results tools, it flags errors.
But it doesn't catch everything. Take e-commerce. There is a name field in the product schema. If someone puts "name" in the name field, the tool won't flag it. It sees data there, so it thinks it's fine. That's why we SEOs need to do manual checks. Also, we started the migration. We went live today. You should add a note on both sides. I did my migration today. I went live at this time. If the situation is specific, or you report to Europe, add the time zone. Search console uses California time.
But Google Analytics uses the property's local time. Watch out for reporting discrepancies. Also, consider this. We are migrating to the new site now. Keep the old sitemaps and add the new ones too. Google will see the redirects. It will discover the new URL'ler faster. Mixing them in search console is a smart move.
— Agreed on sitemaps. If you need fast indexing, keep your old sitemaps active. Ensure they return a 200 status code. Google bot is used to visiting those specific URLs. It will keep coming back to crawl. It follows the normal flow. Google bot increases crawl rate during migrations. It wants to cache resources and map your new URL yapısı. First priority is your redirect list. If you have rows of redirects, check them. Assuming your URL yapısı changed, verify everything. Do your redirects actually work?
Check your status codes. Are you using 301, 307, or 308? We usually stick to 301. Test them live. Once you confirm 301s, wait for the new pages to index. Authority and page age transfer rely entirely on redirects. Moving content is important. But without redirects, Google bot treats everything as a brand new page. Broken redirects will kill your rankings. Also, check your canonical tags. They often point to the test site by mistake. Don't let that happen. The structure doesn't fix itself at launch. These tags stay inside the HTML. No rules are written for them automatically. The old test site canonicals remain. You must check these cases. We'll see them all when we crawl the new site.
When we crawl the site, we check for issues. Are there problems with canonicals? Titles? Descriptions? These are quick win tasks. You should check them manually. But these are the things to check quickly. That summarizes the process.
— Exactly, Can. We're nearing the end. We're live now based on our case. Some time has passed. Let's talk about post-migration best practices. We planned and developed all these steps during the migration. We finished the migration successfully. Let's talk about what comes next. I'll try to share my screen. It helps keep the conversation focused. Here is my first point. If you're changing domains, use the Change of Address tool in Google Search Console. This applies to your new URL and international URLs too. If you moved, using the Change of Address tool is vital.
You must verify the property for the new URL first. That’s a mandatory step. You don't need this tool for a simple URL değişikliği. But use it if you’ve moved to a new domain. That just occurred to me. Let me try to show you something else. One second. Let me share Screaming Frog. Can, is it showing up?
— Yes, it is.
— Great. Here is what you can do. We’re diving into technical stuff, but this should help visualize things. Run a crawl of your site before the migration. Back it up in Screaming Frog. Keep a previous crawl as a baseline. Then, run another one after going live. Screaming Frog handles this perfectly. Use compare mode to run both crawls and spot the differences. You can even use the compare tab to filter results. Tell it to show high similarity changes or hide specific details. Testing this is super helpful. Also, once you exit this mode, this section will become active.
Use list or spider mode. Enable always follow redirects. You will get a crawl result that tracks all 301s. Ensure these settings are on in Screaming Frog. It prevents missing technical issues. Especially during post-migration tasks.
— These are valuable insights. Screaming Frog is our go-to for migrations. It crawls fast and pulls all data. Marketing needs this data too. We keep our own backups this way. We store titles, descriptions, canonicals, and content. We keep every SEO-critical field. If possible, increase your server bandwidth during the migration. Google bot knows you migrated. It starts sending more requests. You can see this clearly in Search Console Crawl Stats. It starts crawling every resource again. It re-evaluates every URL structure. It needs to cache and index pages quickly. It must update index status if URL'ler change. Increase your bandwidth to handle the server load.
Low bandwidth spikes your server response times. This directly hits your crawl requests. Slower response times mean fewer crawl requests. I’ve mentioned server optimization for crawlers before. Faster response times help everything, not just migrations. It’s a win across the board.
— Exactly. Let’s circle back to robots.txt. Sometimes new parameters pop up that we missed in testing. Filtered URL'ler create so many combinations. Don't just assume you blocked them during testing. You need to check those parameters later. As webmasters, we are responsible for the site in Google's eyes. We must optimize all of them. We see this all the time. We simulate Google bot, but we aren't Google bot. We can't analyze or crawl pages exactly like them. Check your Search Console index coverage reports. Look at your logs for a day or two. You might find new parameters or a different URL yapısı.
Are they showing up in your logs? A few requests are fine. If it crosses a certain threshold, you have a problem. Checking even two days of logs is huge for optimizing your crawl budget. You'll see these pages once Google indexes them. Google Search Console even flags them with yellow warnings. You might see errors like "Indexed. Though blocked by robots.txt." Catching these early is vital for site health. It's crucial for the final migration phase.
— I totally agree. Your robots.txt must be configured correctly. You might accidentally open a parameter that was blocked for years. It will get indexed. Removing it from the index is a huge pain.
— You think you'll just open it, but then the requests flood in. You might need to de-index 100,000 URL'ler. The volume of requests will be massive.
— Unfortunately, that increases server load. It also spikes your workload. Managing the client and the dev team becomes a nightmare. It's a tough part of the migration process. We check site speed right after migration. You rarely get the same speed as the test site. Every pro knows this. Speed will drop. Your server is under heavy load during the switch. Testing immediately won't give you accurate results. Expect lower scores initially. Your server is working overtime. Response times will be longer. Don't forget that. GTM tags might have worked on the test site, but now they're live.
Your site speed scores might drop due to the sudden load. Don't expect Core Web Vitals reports to improve immediately. Google bot needs to crawl the entire site first. It also needs to collect enough user data. Users must visit your site first. Then Core Web Vitals scores are calculated. It takes time to get that data. Development never really ends on our sites. You need to spread these improvements out over time.
— Exactly, Can. I have nothing else to add. We covered it all. Let's move to our final topic. Performance tracking after migration is crucial for SEO. We finished the migration, but what actually happened? KPIs vary here. As you mentioned, you might work with an SEO agency for a while. Brands often ask for help during a 2 or 3-month migration window. They want support to ensure everything goes smoothly. What should we track after the migration? What are the key steps? Like I said before, keep notes. You really need to monitor average positions.
You mentioned not to expect instant Core Web Vitals fixes. But check your Time to First Byte. Even minor backend changes affect server load. Any code update impacts server performance. Keep a close eye on that metric. Don't check traffic on day two. It’s not accurate. Maybe schools opened and you sell backpacks. You might get a huge traffic spike. The timeline depends entirely on your brand. Track SEO metrics like organic keywords, top 3 keywords, and organic traffic. Also, review your technical changes. We just performed a redirect.
Check your server status codes. What’s your 301 rate? How many pages return 304? Did your 200 status page count change? Use pie charts to visualize this technical data.
— I agree. That’s why we say don't migrate during peak season. It makes measuring performance incredibly difficult. Say you sell ski gear. If you migrate mid-winter, you’ll see traffic shifts. It’s impossible to tell if it’s the migration or the season. Analyzing that impact becomes a nightmare for SEO. Your structure might be perfect. Sales and payments work fine. But your traffic dropped. For example, your ski gear page traffic is down. Did the drop come from the migration? Is the rank loss due to the migration? Or is it just a trend? Did the SERP change? It’s hard to tell. We need to compare specific periods. Let’s say we migrate on January 30th.
We migrate at 1 AM on January 30th. After that, we compare it to the same season last year. We look at the previous period. We check average traffic. Note that average position isn't for the whole site. You must analyze it keyword by keyword. Category by category. An overall rise doesn't mean everything is up. An overall drop doesn't mean everything is down. If your URL yapısı changed, your average position will likely drop. You are indexing new pages. That is totally normal. My last client didn't have a blog. We integrated a new blog structure. New content arrived. We can't expect instant top rankings. So, the average position trends downward.
Tracking and measuring this is vital. Is the blog really causing this position drop? You need regular checks. Not just the next day, of course. Samet, we talked about this in a meeting. You explained how long it takes for Google to settle after a migration. Was it a year? If I remember correctly.
— They said keep the URL'ler for a year. The idea is to update them in your database. It depends on site size, of course. If you have 2 million URL'ler, it might take longer. But that was the general advice.
— Exactly. You'll see it yourself. I check crawl stats after a migration. Google still hits the old URL'ler. It periodically checks to confirm the 301 redirects are still there.
— It even hits 301s. It’s rare, but it happens. Google doesn't want to miss anything. It thinks there might be valuable content there. It doesn't crawl them constantly. Don't worry if you see it. It might even check something from three years ago. You’ve seen this in SEO tools, right? Set Ahrefs to five years. You’ll see old URL'ler. If Ahrefs has them, Google definitely has them in its data.
— Google thinks just like us. We double-check our top pages to ensure a smooth transition. Google does the same thing. It remembers that page was a high-traffic authority page. It wants to check if anything changed. That’s a totally normal process. It’s actually a good sign during a migration. It shows those pages were authoritative. It proves your brand has real authority. That’s the summary.
— Exactly. One last question comes to mind. We hear this a lot. Will my traffic go up after the migration? Here is the honest answer. If you prioritize user experience during the migration, it can go up. This includes handling 301s correctly and fixing other technical issues. It depends on Google and the experience you provide. I can't give you a definitive answer. I can't promise your site will skyrocket. We covered different migration types at the start for a reason. You might have a URL değişikliği or just a frontend change. Every case is unique. You must evaluate them individually based on the number of URLs. Google bot might take 6-7 months to process 2 million URLs. A 200-page site might only take 1-2 months.
So, will traffic rise? If you build a technically sound site and prioritize user experience, why not? But we are responsible for any mistakes. If Google sees a pattern of errors, it will hurt your site. This rarely happens when you work with an expert. They run extensive tests. I wanted to mention that as a final point.
— Exactly as you said. We have seen many cases. That is why we can say this clearly. When the user experience is seamless and everything works perfectly, we see results. When we say a site is ready for SEO, it usually grows. In 99% of cases, we see a rise unless something goes wrong. Let me clarify this growth. It’s not an overnight spike on January 31st. Google bot needs to crawl, index, and see the value. It’s a gradual process. You’ll see performance climb steadily over time.
We usually fear this. A bad migration can tank stable traffic. But I prefer a migration over an update. If traffic drops, at least you know it’s from the migration.
— At least you know the cause.
— The issues are clear. You can roll back to a backup or fix things fast. It’s less risky. An algorithm update can hit you overnight without warning. That’s a total surprise. So, I don’t think migrations are that risky.
— I totally agree. We’ve covered the topic, Can. I’m out of ideas too. We’ve explained these processes well. There are many migration types. I hope you reach your target structure and boost your organic traffic. Be careful with this. It can cause major headaches. That’s my final take. Can, do you have any last thoughts? Let’s wrap this up.
— We covered a lot. We might have missed some things. That’s normal. It’s a huge topic. It even touches on CDN optimization. We wanted to give you the big picture. The key is working with an SEO expert. Your team must be ready. Both backend and frontend devs need to be on board.
— Let’s wrap it up. If you liked the video, hit like and subscribe. See you at the next Zeo Talks. Take care. Bye.
— Goodbye.
This transcript was generated using AI speech recognition and verified against subtitle style rules.
