CMS Geçişi ve Platform Değişikliği için SEO

TL;DR — Bir CMS geçişi, web sitenizi farklı bir sisteme taşır; örneğin yayın platformunu, ticaret platformunu veya ön uç mimarisini değiştirmek gibi. Arama motorlarının ve kullanıcıların zaten güvendiği şeyleri koruyun: URL’ler, içerik, başlıklar, kanonikler, robots kuralları, yapılandırılmış veri, iç bağlantılar, görseller ve işlenmiş sayfalar. URL’ler değişmek zorundaysa, her eski URL’yi en yakın karşılığına eşleyin ve yönlendirin. Yeni platformu hazırlık ortamında test edin, mevcut siteyle karşılaştırın, lansmanı prova edin ve hem uygulamayı hem de verilerini geri yükleyen bir geri alma planı bulundurun.

CMS geçişi nedir?

Bir CMS geçişi, bir web sitesini oluşturan ve sunan içerik yönetim sistemini veya platformunu değiştirir. WordPress’ten headless bir sisteme, Drupal’dan başka bir kurumsal CMS’e veya bir e-ticaret platformundan diğerine geçiş yaygın örneklerdir.

Görünür tasarım benzer kalabilirken teknik çıktı tamamen değişebilir. Yeni platform farklı URL’ler, HTML, meta veriler, gezinme, filtreler, sayfalama, görseller, yapılandırılmış veri, yönlendirmeler ve robots yönergeleri üretebilir.

Tüm CMS geçişleri URL geçişi midir?

Hayır. Bir CMS geçişi her genel URL’yi aynı tutabilir. Mevcut URL yapısı çalışıyorsa bu genellikle daha güvenli seçenektir.

Bir şema, ana bilgisayar adı, yol, sondaki eğik çizgi kuralı, dosya adı veya anlamlı bir parametre değiştiği anda proje aynı zamanda bir URL geçişine dönüşür. Site geçişleri rehberindeki eşleme, yönlendirme, iç bağlantı, canonical ve site haritası çalışmalarını da ekleyin.

“SEO paritesi” ne anlama gelir?

SEO paritesi, yeni platformun eski platformdaki arama sonuçlarında görünür olan yararlı davranışları koruması anlamına gelir. Tasarımın piksel düzeyinde birebir aynı olması demek değildir.

Her önemli sayfa türü için şunları karşılaştırın:

• dizine eklenebilir URL ve durum kodu;
• başlık, açıklama, alt başlıklar ve ana içerik;
• canonical, robots yönergeleri ve hreflang;
• yapılandırılmış veri;
• taranabilir iç bağlantılar ve gezinme;
• görseller, videolar, PDF’ler ve diğer medya;
• mobil ve işlenmiş çıktı;
• performans ve sunucu güvenilirliği.

Parite ayrıca kasıtlı iyileştirmeleri de içerir. Bunları ayrıca belgeleyin ki yararlı bir değişiklik bir geçiş hatasıyla karıştırılmasın.

CMS geçişleri neden trafik kaybeder?

CMS geçişleri genellikle trafik kaybeder çünkü yeni platform önemli bir davranışı yeniden üretmez. Yaygın örnekler arasında eski URL’lerin 404 döndürmesi, kanoniklerin hazırlık ortamını göstermesi, kategori bağlantılarının kaybolması, gövde içeriğinin yalnızca bir tıklamadan sonra yüklenmesi, ürün varyantlarının dizine eklenebilir kopyalar haline gelmesi veya eski yönlendirmelerin asla aktarılmaması yer alır.

Sorunun nedeni nadiren platformun adıdır; genellikle platformun ürettiği sitedir.

Temel süreç nedir?

1. Mevcut sitenin URL’lerinin, şablonlarının, içeriğinin, sinyallerinin, bağlantılarının, varlıklarının, yönlendirmelerinin ve entegrasyonlarının envanterini çıkarın.
2. URL’lerin aynı kalıp kalmayacağına karar verin.
3. Her şablon ve sistem davranışı için ölçülebilir parite gereksinimleri yazın.
4. İçerik alanlarını eşleyin ve verileri yeni CMS’e taşıyın.
5. Hazırlık ortamını tarayıp işleyin, ardından kaydedilmiş referans durumuyla karşılaştırın.
6. Herhangi bir URL değişiyorsa yönlendirmeleri test edin.
7. İçerik dondurma, son veri senkronizasyonu, dağıtım, önbellek temizleme ve geri alma süreçlerini prova edin.
8. Yayına alın, üretim ortamını hemen doğrulayın ve şablon ile URL kohortuna göre izleyin.

Web Sitesi Geçiş Kontrol Listesi paylaşılan aşama tabanlı proje sırasını sağlar. Bu rehber, yeni bir CMS’in her aşamada neleri değiştirebileceğine odaklanır.

Geçiş sırasında her eski SEO sorununu düzeltmeli misiniz?

Yeni platform aksi takdirde bunları yeniden üretecekse yüksek güvenilirlikli kusurları düzeltin, ancak her yeniden tasarımı, içerik yeniden yazımını, mimari değişikliğini ve URL temizliğini tek bir sürüme birleştirmeyin. Google, site taşıma rehberliğinde mümkün olduğunda aynı anda tek büyük şeyi değiştirmeyi önerir.

Düzeltilmesi gereken kusurları isteğe bağlı iyileştirmelerden ayırın. Lansmandan sonra ne olduğunu teşhis etmek için istikrarlı bir temele ihtiyacınız var.

TL;DR — Platform değişikliği, iki sayfa oluşturma sistemi arasındaki sözleşmenin taşınmasıdır. Mevcut her URL kaynağının, şablonun, içerik alanının, iç bağlantı kuralının, dizin kontrolünün, canonical’ın, hreflang ek açıklamasının, schema nesnesinin, medya URL’sinin, fasetin, yönlendirmenin ve entegrasyonun envanterini çıkarın. Platform yapılandırması kesinleşmeden önce URL’lerin aynı kalacağı veya değişeceği kapsamı belirleyin. Envanteri genel bir kontrol listesine değil, parite testlerine dönüştürün. Verileri taşıyın; hazırlık ortamında ham HTML’i ve işlenmiş DOM’u tarayın; şablona ve korunan URL kohortuna göre farkları belirleyin; geçiş anını ve veri geri alma sürecini prova edin. Ardından kohortları ayrı ayrı izleyerek bozuk bir şablonun site genelindeki toplamların içinde gizlenmesini önleyin.

Planı seçmeden önce platform değişikliğini sınıflandırın

Bir CMS geçişi birkaç değişiklik içerebilir:

Her katmanı kapsama yazın. URL yapısını, barındırmayı, işlemeyi ve gezinmeyi de değiştiren bir “CMS geçişi”, tek bir lansmanı paylaşan dört geçiştir.

URL’lerin aynı kalmasına veya değişmesine erkenden karar verin

Mevcut URL’ler kullanışlı olduğunda ve yeni platform bunları destekleyebildiğinde URL koruması genellikle varsayılandır. Yönlendirmelerin, yeniden taramanın, güncellenen entegrasyonların, kaybolan derin bağlantıların ve operasyonel karmaşıklığın maliyetini ölçmeden “platform bunu yapamaz” ifadesini kabul etmeyin.

Mevcut yapı istikrarsız olduğunda, eski teknolojiyi açığa çıkardığında, yinelenenler oluşturduğunda veya yeni bilgi mimarisini temsil edemediğinde URL değişikliği yine de haklı görülebilir. Karar, temalar, yollar, içe aktarmalar ve akışlar yeni bir desen etrafında oluşturulmadan önce verilmelidir.

Değişen URL’ler, eksiksiz bir URL yapısı geçişi çalışma akışı gerektirir: ana envanter, her URL için açıkça belirlenmiş sonuç, bire bir veya gerekçelendirilmiş çoktan bire eşleme, kalıcı yönlendirmeler, doğrudan iç bağlantılar, güncellenmiş ek açıklamalar, yeni site haritaları ve izleme.

Mevcut durum envanterini birden fazla sistemden oluşturun

Mevcut CMS veritabanı web sitesi envanteri değildir. Şunları birleştirin:

• bir veya daha fazla taramadan elde edilen taranabilir URL’ler;
• XML site haritaları ve akış dışa aktarımları;
• analiz araçlarındaki açılış sayfaları ve Search Console sayfaları;
• tarayıcıların hâlâ istediği sahipsiz veya eski URL’ler dahil olmak üzere sunucu günlükleri;
• geri bağlantı alan sayfalar ve kampanya açılış sayfaları;
• medya kitaplıkları, PDF’ler, görseller, videolar ve indirilebilir varlıklar;
• site içi arama, fasetli gezinme, sayfalama ve sıralama kalıpları;
• CMS, sunucu, CDN ve uygulama kodundaki yönlendirme kuralları;
• API, uygulama, e-posta, ücretli trafik, satış ortaklığı, yerelleştirme ve akış tüketicileri.

Her URL’ye bir içerik varlığı, şablon, dizinlenebilirlik durumu, canonical hedefi, trafik/bağlantı önemi ve amaçlanan hedef atayın. Envanter, içe aktarmadan sonraki mutabakat defteridir.

Yalnızca sayfa metninin değil, içerik modelinin de envanterini çıkarın

İçerik modeli eşlemesi, alanların ve ilişkilerin nasıl taşındığını açıklar. Şunları içerir:

• başlıklar, özetler, gövde blokları, yazarlar, tarihler ve güncellenme tarihleri;
• taksonomiler, üst öğeler, koleksiyonlar, kategoriler ve etiketler;
• slug’lar, yerel ayar varyantları, canonical geçersiz kılmaları ve robots kontrolleri;
• görsel kaynağı, alternatif metin, açıklamalar, boyutlar, kırpmalar ve odak noktaları;
• ilgili içerik, içerik haritaları, birincil gezinme ve bağlamsal bağlantılar;
• ürün tanımlayıcıları, fiyatlar, stok durumu, incelemeler, varyantlar ve teklifler;
• yapılandırılmış veri özellikleri ve varlık ilişkileri;
• yönlendirmeler, takma adlar, yayımlanmamış durumlar, zamanlama ve izinler.

Alanın varlığı yeterli değildir. Dönüşüm kurallarını, null davranışını, kodlamayı, Markdown veya zengin metin dönüşümünü, gömülü bileşenleri ve referansları test edin. Boş görünen bir taşınmış alan yine de kayıp içeriktir.

Pariteyi kabul kriterlerine dönüştürün

Parite gereksinimleri her şablon için ayrı ayrı yazılmalıdır. Bir ürün sayfası ile bir makale aynı içerik, schema, sayfalama veya iç bağlantı sözleşmesini paylaşmaz.

Her şablon için şunları tanımlayın:

• beklenen durum ve dizine eklenebilirlik;
• canonical oluşturma kuralı;
• robots meta ve X-Robots-Tag davranışı;
• başlık, açıklama, H1 ve ana içerik kaynak alanları;
• gerekli yapılandırılmış veri türleri ile görünür özelliklerin uyumu;
• içerik haritası, gezinme, ilgili bağlantı ve sayfalama kuralları;
• hreflang ve yerel ayar davranışı;
• varlık davranışı ve görsel meta verileri;
• ham HTML ve işlenmiş DOM gereksinimleri;
• performans ve erişilebilirlik eşikleri;
• analiz ve izin davranışı.

Koruma, kaldırma ve iyileştirme kararlarını ayırın. Bu, QA ekibinin bilinen bir hatayı geri yüklemesini veya kazara bir kaybı iyileştirme olarak kabul etmesini önler.

Ham HTML ve işlenmiş çıktıyı test edin

İşleme stratejisi, geliştiriciye ait bir uygulama ayrıntısı değil, platform değişikliği kararıdır. Google’ın JavaScript SEO belgeleri, JavaScript sayfalarını taradığını, işlediğini ve ardından dizine eklediğini açıklar. Belgeler ayrıca sunucu tarafında işlemenin veya ön işlemenin, kullanıcılara ve tarayıcılara yardımcı olması ve tüm botların JavaScript çalıştırmaması nedeniyle hâlâ iyi bir yaklaşım olduğunu belirtir.

Korumalı her şablon için ham HTML’i işlenmiş DOM ile karşılaştırın:

• Ana içerik kullanıcı etkileşimi olmadan mevcut mu?
• Bağlantılar çözümlenebilir hedeflere sahip gerçek <a href> öğeleri mi?
• Durum kodları hata durumlarıyla eşleşiyor mu, yoksa her rota yumuşak 404 kabuğu mu döndürüyor?
• canonical ve robots yönergeleri mevcut ve tutarlı mı?
• Gerekli JavaScript, CSS, API’ler ve varlıklar taranabilir mi?
• Hidrasyon veya API hataları içeriği kaldırıyor mu?
• Mobil işleme eşdeğer birincil içerik ve meta veriler içeriyor mu?

Google, noindex ile karşılaştığında işlemeyi atlayabileceği konusunda uyarır, bu nedenle ilk noindex’i kaldırmak için JavaScript kullanmak başarısız olabilir. Amaçlanan dizine eklenebilirliği orijinal yanıta koyun.

Canonical ve dizin kontrol mantığını koruyun

Canonical kuralları çoğu zaman bilinçli şablon mantığından gerileyerek “her şeyi kendine canonical olarak işaretle” yaklaşımına dönüşür. Bu durum filtrelerin, izleme parametrelerinin, sayfalamanın, yazdırma görünümlerinin veya varyantların oluşturduğu kopyaları açığa çıkarabilir.

Her kuralı girdiler ve beklenen çıktılar olarak belgeleyin. Test edin:

• canonical’ın mutlak ana bilgisayarı, şeması, yolu, eğik çizgisi ve kodlaması;
• dizine eklenmesi amaçlanan sayfalardaki kendine referans veren canonical’lar;
• yinelenen varyantların canonical hedefleri;
• robots meta ve X-Robots-Tag etkileşimleri;
• 200 dışındaki yanıtlarda canonical davranışı;
• site haritasına yalnızca amaçlanan canonical URL’lerin dahil edilmesi;
• masaüstü, mobil ve işlenmiş çıktılar arasındaki tutarlılık.

Temsili sayfalarda Canonicalization Checker kullanın, ardından şablonları bir tarayıcıyla toplu olarak doğrulayın.

Yapılandırılmış verileri yeni kaynak modelinden yeniden oluşturun

Yapılandırılmış veriler nadiren otomatik olarak aktarılır çünkü yeni şablonlar ve alanlar değişir. Her özelliği yeni kaynağına eşleyin, ardından işaretlemenin görünür sayfa içeriğini açıkladığını doğrulayın.

Google, yapılandırılmış verilerin geliştirme sırasında Zengin Sonuçlar Testi ile test edilmesini ve dağıtımdan sonra zengin sonuç raporlarının izlenmesini önerir; çünkü şablon oluşturma veya sunum sorunları bunu bozabilir. Google’ın yapılandırılmış veri tanıtımına bakın.

Hem sözdizimini hem de uygunluğu doğrulayın. Geçerli bir doğrulayıcı zengin bir sonucu garanti etmez ve sözdizimsel olarak geçerli bir nesne yine de yanlış ürünü, makaleyi, içerik haritasını, yazarı, fiyatı veya stok durumunu tanımlayabilir.

İç bağlantı işlevini koruyun, yalnızca bağlantı sayısını değil

İç bağlantı paritesi, önemli sayfaların eşdeğer veya daha iyi tarama yollarıyla keşfedilebilir kalması anlamına gelir. Karşılaştırın:

• birincil ve yardımcı gezinme;
• içerik haritaları ve kategori ataları;
• ilgili ürünler, ilgili makaleler ve bağlamsal bağlantılar;
• sayfalama ve daha fazla yükleme alternatifleri;
• alt bilgi, yerel ayar ve pazar seçicileri;
• taşınan gövde içeriğindeki bağlantılar;
• öksüz sayıları, tıklama derinliği ve gelen bağlantı dağılımı.

Yeni bir tasarım, derin sayfaları gerçekten destekleyen bağlantıları kaldırırken aynı toplam bağlantı sayısını koruyabilir. Değişiklikleri hedefe ve şablona göre analiz edin.

Fasetleri, parametreleri ve dahili aramayı ürün gereksinimleri olarak ele alın

Platformlar genellikle yeni filtreleme ve sıralama davranışları dayatır. Hangi kombinasyonların taranabilir, dizine eklenebilir, canonical ile ilişkilendirilmiş, bağlantı verilmiş veya engellenmiş olması gerektiğini belgeleyin. Parametre sıralamasını, boş sonuçları, çoklu seçimleri, sayfalamayı ve mobil davranışı test edin.

Yeni platform farklı yollar oluşturuyorsa, eski platformdan kapsamlı bir robots kuralını kopyalamayın. Robots hariç tutma taramayı azaltabilir, ancak sinyalleri birleştiremez veya önceden dizine eklenmiş URL’leri kendi başına kaldıramaz.

Parametre modellerini keşfetmek için Fasetli Gezinme Denetçisini kullanın, ardından sitenin seçtiği tarama ve dizin kontrollerini doğrulayın.

Medyayı birinci sınıf URL’ler olarak taşıyın

Medya taşıma, dosyaları kopyalamaktan daha fazlasını kapsar. Şunları koruyun veya açıkça eşleyin:

• görsel, video, PDF ve indirme URL’leri;
• alternatif metin, açıklamalar, başlıklar ve çevresindeki bağlam;
• görsel boyutları, biçimleri, duyarlı varyantlar ve kararlı kaynak URL’leri;
• video oynatıcılar, küçük görseller, transkriptler ve yapılandırılmış veri;
• PDF durumu, canonical üst bilgileri, bağlantılar ve erişim kontrolleri;
• CDN yolları, imzalı URL’ler, hotlink kuralları ve önbellek davranışı.

Google’ın güncel mobil öncelikli yönergeleri, önemli mobil ve masaüstü içeriğini, meta verileri, yapılandırılmış verileri ve taranabilir kaynakları eşdeğer tutmayı önerir. Ayrıca, resim URL’lerini değiştirmenin, yeni URL’ler işlenirken geçici görsel arama kaybına neden olabileceği konusunda uyarır. Mobil öncelikli dizin oluşturma en iyi uygulamalarına bakın.

Yönlendirmeleri ve hata davranışını aktarın

Eski yönlendirmeler CMS’de, .htaccess’te, nginx’te, uygulama ara katmanında, yük dengeleyicilerde ve CDN kurallarında yaşayabilir. Bunları lansmandan önce dışa aktarın ve düzleştirin. Yeni bir platform genellikle boş bir yönlendirme tablosuyla başlar ve yıllarca biriken URL geçmişini sessizce düşürür.

Gerçek eksik içeriği de test edin. Platform, “bulunamadı” metni içeren bir 200 şablonu değil, gerçek bir 404 veya 410 döndürmelidir. HTTP sonucunu maskelemeden özel hata deneyimlerini koruyun.

URL’ler değişirse, eşlenen her eski URL’yi test edin. İnceleme defteri için Yönlendirme Haritası Oluşturucuyu ve dağıtılmış doğrulama için Toplu HTTP Durum Kodu Denetleyicisini kullanın.

Hazırlık ortamını gizli ve test edilebilir tutun

Hazırlama erişimi, koruma ile yetkili taramayı dengelemelidir. Kimlik doğrulamayı, VPN’i veya ağ kontrollerini tercih edin ve QA sistemlerine açık erişim verin. Geçici robots veya noindex kontrolleri varsa, bunları bir lansman kaldırma defterine kaydedin ve üretimde bulunmadıklarını kanıtlayın.

Hazırlık ortamı taramasını yalnızca gezinme öğelerinden değil, eksiksiz hedef envanterinden oluşturun. Taramayı şablona ve önem kohortuna göre referans durumuyla karşılaştırın. Staging vs. Production SEO Diff eşleştirilmiş örneklere yardımcı olur; sistem genelindeki kapsamı ise eksiksiz bir tarama sağlar.

Yayına almadan önce geçiş mutabakatını tamamlayın

Mutabakat dört soruyu yanıtlar:

1. Taşınması amaçlanan her içerik varlığı içe aktarıldı mı?
2. Her varlık beklenen herkese açık URL’yi veya bilinçli olarak belirlenen URL’siz durumu üretti mi?
3. Beklenen her hedef, şablon sözleşmesindeki testleri geçti mi?
4. Her eski URL için onaylanan işlem uygulandı mı?

İçerik türüne, yerel ayara, duruma, dizine eklenebilirliğe ve şablona göre sayıları kullanın. Site genelindeki toplamlar eşleşebilirken tüm bir dil, kategori, yazar arşivi veya medya sınıfı eksik olabilir.

Geçişi ve geri almayı prova edin

Prova, üretim benzeri bir veri hacmini ve gerçek sırayı içermelidir:

• içerik dondurmanın veya fark senkronizasyonunun başlatılması;
• son veritabanı ve medya içe aktarımı;
• yönlendirmelerin ve uç katman kurallarının dağıtımı;
• uygulamanın, önbelleğin, kuyruğun, arama dizininin ve akışların etkinleştirilmesi;
• altyapı değişiyorsa DNS veya yük dengeleyici geçişi;
• üretim ortamında hızlı doğrulama testleri ve tarama;
• kodun, yapılandırmanın, veritabanı şemasının ve yazma işlemlerinin geri alınması.

Veritabanı geri alması zor kısımdır. Kullanıcılar yeni şemada siparişler, hesaplar, yorumlar veya içerik oluşturduktan sonra uygulama kodunu geri almak veri kaybına veya bozulmaya neden olabilir. Teknik geri almanın yanında ileri alma düzeltmelerini ve mutabakatı tanımlayın.

Üretimi bağımlılık sırasına göre doğrulayın

Üretim doğrulaması sistemik arızadan sayfa ayrıntısına doğru ilerlemelidir:

1. DNS, TLS, durum ve ana bilgisayar kullanılabilirliği.
2. Robots.txt, kimlik doğrulama, WAF ve genel robots yönergeleri.
3. Ana sayfa artı korumalı her şablondan bir sayfa.
4. Kanonikler, hreflang, şema, bağlantılar, varlıklar ve işleme.
5. Tam yönlendirme ve hedef envanterleri.
6. Analitik, onay, formlar, ödeme, beslemeler, API’ler ve arama.
7. Tarama, dizine ekleme, trafik ve dönüşüm kohortları.

Tek tek URL’lerden önce şablon kusurlarını düzeltin. Canonical üreten tek bir hatalı şablon parçası milyonlarca sayfayı etkileyebilir.

Yayından sonra kohorta göre izleyin

Kohort izleme, URL’leri neyin değiştiğine göre gruplar. Yararlı kohortlar arasında aynı URL’li sayfalar, yönlendirilmiş sayfalar, ürünler, kategoriler, makaleler, yerel ayarlar, işlenmiş şablonlar, medya, fasetler ve en çok bağlantı verilen sayfalar bulunur.

Başarılı yanıtları, yönlendirme hatalarını, kanonik uyumsuzluklarını, dizine eklenebilirliği, işleme bütünlüğünü, iç bağlantıları, site haritası durumunu, Google tarafından seçilen kanonikleri, tıklamaları, gösterimleri, dönüşümleri ve tarayıcı etkinliğini izleyin. Eşdeğer dönemleri karşılaştırın ve ilgisiz kampanyaları, mevsimselliği, algoritma değişikliklerini ve ölçüm güncellemelerini not edin.

Toplam trafik çizgisi, bir yeni şablonun başarısız olup diğerinin büyüdüğünü söyleyemez.

AI özeti

• Bir CMS geçişi, sayfaları üreten sistemi değiştirir; URL’leri, işlemeyi, tasarımı, mimariyi, barındırmayı ve entegrasyonları da değiştirebilir.
• Platformun yönlendirme yapısı ve içe aktarma süreçleri oluşturulmadan önce URL’lerin aynı kalacağı veya değişeceği kapsamı belirleyin.
• Envanteri taramalardan, site haritalarından, günlüklerden, analiz araçlarından, Search Console’dan, geri bağlantılardan, medyadan, yönlendirmelerden ve sistemi kullanan diğer tüketicilerden oluşturun.
• Yalnızca gövde metnini değil, içerik alanlarını, ilişkileri, taksonomiyi, meta verileri, medyayı, schema’yı ve iş akışı durumlarını eşleyin.
• Durum, dizine eklenebilirlik, canonical, robots, içerik, bağlantılar, schema, hreflang, varlıklar, işleme ve performans için her şablona özel, test edilebilir sözleşmeler tanımlayın.
• Ham HTML ile işlenmiş çıktıyı karşılaştırın. Birincil içerik ve taranabilir bağlantılar kullanıcı etkileşimine bağlı olmamalıdır.
• Fasetleri, sayfalamayı, site içi aramayı, eski yönlendirmeleri ve gerçek 404 davranışını platform gereksinimleri olarak ele alın.
• Yayına almadan önce içe aktarılan varlıkları, oluşturulan hedefleri, şablon testlerini ve her eski URL için belirlenen işlemi mutabakata bağlayın.
• Son senkronizasyonu, dağıtımı, doğrulamayı ve verileri de kapsayan geri alma sürecini prova edin.
• Yayından sonra yalnızca site genelindeki trafiği değil, şablon ve değişiklik kohortlarını ayrı ayrı izleyin.

Resmi dokümantasyon

Google

• Site moves with URL changes URL eşleme, yönlendirmeler, ek açıklamalar, bağlantılar, site haritaları ve izlemeyi kapsar.
• Changing your hosting altyapı değiştiğinde ancak genel URL’ler değişmediğinde geçerlidir.
• JavaScript SEO basics tarama, işleme, dizine ekleme, canonical ve robots davranışını açıklar.
• Mobile-first indexing best practices içerik, meta veriler, şema, medya ve kaynak eşitliğini kapsar.
• Structured-data introduction geliştirme ve yayın sonrası doğrulama önerir.
• General structured-data guidelines teknik ve kalite gereksinimlerini açıklar.

Bing

• Website Migration with Bing CMS geçişlerini, denetimleri, yönlendirmeleri, günlükleri ve izlemeyi kapsar. Site Move Tool referansı güncel değildir; güncel Bing Webmaster Tools ve IndexNow kullanın.
• IndexNow Bing’i ve katılımcı motorları eklenen, güncellenen veya silinen URL’ler hakkında bilgilendirir.

Kaynaktan alıntılar

• “Plan your changes to your site one after the other, not everything at the same time.” Google Search Central. İlgili bölüme git
• Başka sözcüklerle: Google’ın taşıma belgelerine göre, değişen URL’lerin her bir hedefi kendisini canonical olarak tanımlamalıdır. Canonical rehberi
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution” Google Search Central. noindex rehberindeki ilgili bölüme git
• Başka sözcüklerle: Google, kullanıcılar ve tarayıcılar için performansa uygun bir sunum seçeneği olarak sunucu tarafında işlemeyi veya ön işlemeyi hâlâ önerir. İşleme rehberi
• “Be sure to check your structured data using the Rich Results Test during development”. Google Search Central. Doğrulama rehberindeki ilgili bölüme git

CMS geçiş kontrol listesi

Kapsam ve kararlar

• Tüm değişiklik katmanları listelendi: CMS, veri, şablonlar, işleme, mimari, URL, altyapı, analiz ve entegrasyonlar.
• Yönlendirme yapısı uygulanmadan önce URL’lerin aynı kalacağı veya değişeceği kapsam onaylandı.
• Koruma, kaldırma ve iyileştirme kararları birbirinden ayrıldı.
• Her şablon için sorumlular ve geçti/kaldı eşikleri belirlendi.

Envanter ve geçiş

• Taramalar, site haritaları, günlükler, analiz verileri, Search Console, geri bağlantılar ve akışlar birleştirildi.
• Medyanın, fasetlerin, sayfalamanın, site içi aramanın, yönlendirmelerin, API’lerin ve uygulamaların envanteri çıkarıldı.
• Her içerik alanı, ilişki, taksonomi, yerel ayar ve iş akışı durumu eşlendi.
• Varlık sayıları ve URL’ler içerik türüne, yerel ayara, şablona ve duruma göre mutabakata bağlandı.

Hazırlık QA’sı

• Herkese açık keşif engellenirken yetkili tarayıcılar hazırlık ortamına erişebiliyor.
• Her korunan şablonda ham HTML ve işlenmiş DOM test edildi.
• Durum, başlıklar, alt başlıklar, içerik, canonical’lar, robots, hreflang ve schema farklılıkları karşılaştırıldı.
• Gezinme, içerik haritaları, ilgili bağlantılar, sayfalama ve gövde bağlantıları karşılaştırıldı.
• Fasetler, parametreler, arama, boş sonuçlar, varyantlar ve gerçek hatalar test edildi.
• Medya URL’leri, meta veriler, biçimler, gömülü öğeler ve yapılandırılmış veri test edildi.
• Eski yönlendirmeler içe aktarıldı, zincirleri düzleştirildi ve test edildi.
• Analiz, izin, formlar, ödeme, akışlar, API’ler ve arama test edildi.

Yayına alma ve izleme

• Son içerik/veri senkronizasyonu ve dondurma sırası prova edildi.
• Uygulama ile veritabanı için geri alma veya ileriye dönük düzeltme planı prova edildi.
• Geçici hazırlık ortamı kontrolleri kaldırma defterine eklendi.
• Üretim ortamı, sistem genelinden şablona ve ardından URL’ye ilerleyen sırayla doğrulandı.
• Site haritaları, başarıyla yanıt veren ve dahil edilmesi amaçlanan canonical URL’leri içeriyor.
• İzleme; şablona, yerel ayara, öneme ve değişiklik kohortuna göre bölümlendirildi.

Platform değiştirme sözleşmesi

Dört bağlantılı defter kullanın:

1. Varlık defteri: taşınması gereken her içerik kaydı ve ilişki.
2. URL defteri: her eski URL ve aynı, taşınmış, birleştirilmiş, kullanımdan kaldırılmış veya hariç tutulmuş sonucu.
3. Şablon sözleşmesi: her oluşturulan sayfa davranışı ve geçti/kaldı testleri.
4. Bağımlılık defteri: platformun desteklediği her akış, entegrasyon, varlık, doğrulama, yönlendirme, iş ve iş süreci.

Geçiş, yalnızca defterler uyumlu olduğunda mutabık kabul edilir. Beklenen bir URL’si olmayan bir içerik varlığı veya sahip olan bir varlığı ya da bilinçli bir sistem davranışı olmayan herkese açık bir URL inceleme gerektirir.

Parite matrisi

CMS geçişinin bir URL taşıma iş akışına ihtiyacı var mı?

Kayıplara yol açan platform değiştirme hataları

Platform oluşturulduktan sonra URL’leri seçmek. Neden başarısız olur: rota yapısı, içe aktarmalar, şablonlar, akışlar ve yönlendirmeler rastlantısal varsayılanlar etrafında kesinleşir. Bunun yerine: URL’leri koruma veya değiştirme kararını uygulamadan önce verin.

Görsel eşleşmeyi SEO paritesi saymak. Neden başarısız olur: durum, ham HTML, canonical’lar, robots, bağlantılar, schema, mobil içerik ve hatalar aynı tasarımın arkasında farklı olabilir. Bunun yerine: şablon sözleşmelerini ham ve işlenmiş yanıtlarda test edin.

Yalnızca site haritasını taşımak. Neden başarısız olur: site haritaları, hâlâ trafik veya bağlantı alan yetim, yönlendirilmiş, eski, parametreli ve varlık URL’lerini atlar. Bunun yerine: taramaları, günlükleri, analitiği, Search Console’u, geri bağlantıları ve akışları birleştirin.

Yayında her iyileştirmeyi yapmak. Neden başarısız olur: eşzamanlı içerik, mimari, işleme, URL ve tasarım değişiklikleri, gerileme teşhisini zorlaştırır. Bunun yerine: gerekli kusurları daha sonraki iyileştirmelerden ayırın ve değişiklikleri uygun olduğunda aşamalı hale getirin.

Geri almayı kod dağıtımı olarak ele almak. Neden başarısız olur: yeni şema yazımları, siparişler, yüklemeler ve içerik düzenlemeleri bir uygulama geri almasından sağ çıkamayabilir. Bunun yerine: veri mutabakatı ve ileri alma düzeltmelerini de planlayın.

Yaygın platform değiştirme hataları

Hedef sayımları kaynak envanterinden daha düşük

Olası neden: başarısız içe aktarmalar, hariç tutulan durumlar, yerel ayar boşlukları, desteklenmeyen içerik türleri veya varlık tekilleştirmesi. Düzeltme: tek bir toplamı karşılaştırmak yerine içerik türüne, yerel ayara, iş akışı durumuna ve şablona göre mutabakat sağlayın.

Sayfalar 200 döndürüyor ancak taramalarda içerik kayboluyor

Olası neden: istemci tarafı işleme, engellenen kaynaklar, API hataları, yalnızca etkileşimle yüklenen içerik veya hidrasyon hataları. Düzeltme: temsili sayfalarda ham ve işlenmiş HTML’yi, konsol/ağ hatalarını ve URL İnceleme’nin işlenmiş görünümünü karşılaştırın.

Google beklenmeyen canonical URL’leri seçiyor

Olası neden: kopyalanmış canonical kuralları, eski siteyi veya hazırlık ortamını gösteren hedefler, yinelenen rotalar, iç bağlantı çakışmaları, site haritası çakışmaları ya da önemli ölçüde değişmiş içerik. Düzeltme: şablondaki canonical’ı, doğrudan bağlantıları, yönlendirmeleri ve site haritasını amaçlanan URL ile uyumlu hâle getirin; ardından yeniden taramaya zaman tanıyın.

Kategori veya ürün sayfaları tarama tuzakları haline geliyor

Olası neden: yeni fasetli yollar, parametre sıralaması, sonsuz kombinasyonlar, takvim yolları veya taranabilir dahili arama. Düzeltme: izin verilen kombinasyonları tanımlayın, yalnızca yararlı sayfalara bağlantı verin, boş sonuç durumlarını doğru biçimde döndürün ve ürün gereksinimine göre canonical veya dizin kontrolleri uygulayın.

Eski bağlantılar 404 döndürmeye başlıyor

Olası neden: yönlendirmeler eski CMS dışında mevcuttu veya yeni kural motoru sıralamayı değiştirdi. Düzeltme: her eski katmandan kurallar derleyin, zincirleri düzleştirin ve eksiksiz tarihsel URL envanterini test edin.

Yapılandırılmış veri geçiyor ancak yanlış varlığı tanımlıyor

Olası neden: hatalı alan eşlemesi veya üst varlığın verilerini, yer tutucu değerleri ya da güncelliğini yitirmiş önbelleği işleyen bir şablon. Düzeltme: işaretlemeyi görünür içerikle ve kaynak kayıtlarla karşılaştırın. Sözdizimi doğrulaması tek başına anlamsal doğruluğu kanıtlayamaz.

CMS geçişi kalite güvencesi için araçlar

• SEO Migration Planner & Validator harita incelemesini, yönlendirme doğrulamasını, eski URL durumunu ve site haritası karşılaştırmasını birleştirir.
• Redirect Map Builder yollar değiştiğinde birebir, belirsiz, birleştirilmiş, eşleşmeyen ve kullanımdan kaldırılmış URL sonuçlarını gözden geçirmeye yardımcı olur.
• Staging vs. Production SEO Diff durumları, yönlendirmeleri, canonical’ları, yönergeleri, seçili üst bilgileri, schema’yı ve içeriği karşılaştırır.
• Canonicalization Checker temsili bir sayfadaki gözlemlenebilir canonical sinyallerini teşhis eder.
• Schema Validator yapılandırılmış veri sözdizimini ve çıkarılan varlıkları kontrol eder; Google özelliklerine uygunluğu denetlemek için Google’ın Zengin Sonuçlar Testi’ni kullanın.
• Faceted Navigation Auditor yeni filtrelerin getirdiği tarama ve parametre risklerini araştırır.
• Link Analyzer temsili şablonlardaki işlenmiş iç bağlantıları kontrol eder.
• Bulk HTTP Status Code Checker dağıtımdan sonra hedef URL ve geçmiş URL kohortlarını doğrular.

CMS geçişinin doğru gönderildiğini kanıtlayın

Varlıktan URL’ye mutabakat testi

• Çalıştırılacak test: Kaynak varlık dışa aktarımını, hedef varlık dışa aktarımını, beklenen URL defterini ve hedef taramayı kararlı içerik kimliğine göre birleştirin.
• Beklenen sonuç: Kapsamdaki her varlığın onaylanmış durumu ve URL’si vardır; her genel hedefin sahip olan bir varlığı veya belgelenmiş bir sistem amacı vardır.
• Hata yorumu: İçe aktarma boşlukları, yinelenenler, yol çakışmaları veya hariç tutulan durumlar içeriğin eksik kalmasına veya istenmeyen sayfaların oluşmasına neden olmuştur.
• İzleme penceresi: Lansmandan önce, son senkronizasyondan sonra ve herhangi bir içe aktarma onarımından sonra.
• Geri alma tetikleyicisi: Korunan bir içerik türü veya yerel ayar, lansman kararından önce mutabakat sağlanamıyor.

Şablon sözleşme testi

• Çalıştırılacak test: Her korumalı şablondan katmanlı bir örneklem tarayın ve işleyin; durum, içerik, meta veriler, kanonikler, yönergeler, şema, bağlantılar, varlıklar ve mobil çıktıyı karşılaştırın.
• Beklenen sonuç: Her koruma gereksinimi karşılanır ve her fark onaylanmış kasıtlı bir değişikliğe karşılık gelir.
• Başarısızlık yorumu: Bir bileşen, alan eşlemesi, rota veya işleme katmanı arama tarafından görülebilir çıktıyı sistematik olarak değiştiriyor.
• İzleme penceresi: Hazırlık aşamasında, lansmandan hemen sonra ve şablon düzeltmelerinden sonra.
• Geri alma tetikleyicisi: Site genelinde veya yüksek değerli bir şablon dizine eklenebilirliğini, içeriğini, kanonik bütünlüğünü veya kritik işlevini kaybeder ve pencerede onarılamaz.

Yönlendirme ve hata durumu testi

• Çalıştırılacak test: Her eski URL’yi Bulk HTTP Status Code Checker veya eksiksiz bir tarayıcıyla test edin ve eksik olduğu bilinen rotaları da denetleyin.
• Beklenen sonuç: Taşınan URL’ler tek bir kalıcı yönlendirmeyle onaylanan eşdeğerlerine ulaşır; korunan URL’ler başarılı yanıt vermeyi sürdürür; kullanımdan kaldırılan URL’ler planlanan 404 veya 410 yanıtını döndürür.
• Başarısızlık yorumu: Eksik kurallar, hatalı sıralama, zincirler, soft 404’ler veya tüm yolları yakalayan yönlendirme, amaçlanan işlemi belirsizleştiriyor.
• İzleme penceresi: Mümkünse hazırlık ortamı, yayına alma saati ve her kural değişikliğinden sonrası.
• Geri alma tetikleyicisi: Sistem genelindeki bir kural hatası, korunan URL’leri erişilemez hâle getiriyor veya ilgisiz hedeflere gönderiyor.

Veri bilinçli geri alma provası

• Çalıştırılacak test: Belgelenmiş geri alma sürecini, geçişten sonra oluşturulan yazma işlemlerini de kapsayan üretim benzeri bir provada uygulayın.
• Beklenen sonuç: Kod, schema, içerik, siparişler, oturumlar, yüklemeler, kuyruklar ve entegrasyonlar, fark edilmeden veri kaybı yaşanmadan tanımlanmış ve tutarlı bir duruma ulaşır.
• Başarısızlık yorumu: Plan yazılımı geri yükleyebiliyor, ancak yeni platformun ürettiği verileri mutabakata bağlayamıyor.
• İzleme penceresi: Yayına almadan önce ve önemli schema veya geçiş değişikliklerinden sonra.
• Geri alma tetikleyicisi: Kritik yazma işlemleri için güvenli bir geri alma veya ileriye dönük düzeltme yolu bulunmuyor.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• A Website Migration Takes More Than a Checklist to Be Successful paylaşılan proje sürecini, hazırlığı, pariteyi ve izlemeyi kapsar.
• Redirects for SEO yönlendirme katmanını kapsar; bu katman, platform değişikliği rotaları değiştirdiğinde aktarılmalı veya yeniden oluşturulmalıdır.

Bu sitedeki ilgili rehberler

• Site Migrations göç türlerini, ortak riskleri ve evrensel süreci kapsar.
• Website Migration Checklist projeye hazır bir sıra sağlar.
• Website Redesign SEO Checklist URL’ler sabit kalırken şablonlar değiştiğinde geçerlidir.
• JavaScript SEO işleme ve keşfi daha derinlemesine kapsar.

Sektörden

• Google: Site moves with URL changes
• Google: JavaScript SEO basics
• Google: Mobile-first indexing
• Google: Structured data
• Bing: Website Migration with Bing
• Bing: IndexNow

Kendinizi test edin: CMS Geçişi ve Platform Değişikliği SEO’su

Kapsam, parite, işleme, uzlaştırma ve geri alma hakkında beş soru. Her biri için bir cevap seçin, ardından kontrol edin.

Değişiklik günlüğü