Web Sitesi Yenilerken İçerik Nasıl Taşınır? Kayıpsız İçerik Göçü Stratejisi

Web sitesi yenileme projelerinde herkes en çok tasarımı konuşur; oysa sitenin asıl değeri yıllar içinde biriken metinlerde, görsellerde ve belgelerde durur. Web sitesi içerik taşıma işini planlamadan başlarsanız yeni sitede eksik sayfalar, bozuk tablolar ve kayıp PDF'lerle karşılaşırsınız. Bu yazıda 2012'den beri yürüttüğüm yenileme projelerinden edindiğim yöntemi, envanterden son kontrole kadar adım adım anlatıyorum.

Web sitesi içerik taşıma nedir ve yenilemede neden ayrı bir iş kalemidir?

Web sitesi içerik taşıma, eski sitedeki metin, görsel, belge ve sayfa verilerini envanterleyip her biri için tut, birleştir, yeniden yaz veya sil kararı vererek yeni sitenin içerik modeline aktarma sürecidir. Tasarım ve kodlamadan ayrı bir plan, ayrı bir sorumlu ve ayrı bir takvim ister.

Bu işi çoğu teklifte tek satırlık bir "içerik girişi" olarak görürsünüz. Ancak pratikte yenileme bütçesinin önemli bir bölümünü sessizce tüketen iş budur. Eski sitede kimsenin hatırlamadığı kampanya sayfaları, farklı editörlerin farklı biçimde girdiği ürün açıklamaları ve sunucuda kimsenin açmadığı belgeler vardır. Bunları yeni sisteme körlemesine kopyalamak, eski düzensizliği yeni tasarımın içine taşımak demektir.

Bu yazı teknik SEO tarafını, yani yönlendirme haritasını ve Search Console takibini derinlemesine anlatmıyor. O konu için web sitesi yenilerken SEO nasıl korunur yazısına bakabilirsiniz. Veri tabanı, üyelik ve sipariş kayıtları da ayrı bir konudur. Burada odak, editoryal içeriğin kendisidir.

İçerik göçü ile SEO migration arasındaki fark nedir?

İki kavram birbirine karışıyor, bu yüzden işe ayrımı netleştirerek başlıyorum. SEO migration, arama motorunun sitenizi yeni adreslerde ve yeni yapıda sorunsuz tanımasını hedefler: URL'ler, yönlendirmeler, kanonik etiketler, site haritası ve indeksleme. İçerik göçü ise "neyi, hangi hâliyle ve nereye taşıyoruz?" sorusunun cevabıdır.

Örneğin 400 sayfalık bir kurumsal sitede SEO ekibi her eski adresin yeni karşılığını ister. Bu karşılığı üretebilmek içinse önce içerik kararlarını vermeniz gerekir. Hangi sayfanın yaşayacağını bilmeden yönlendirme hedefi yazamazsınız. Dolayısıyla içerik göçü, SEO migration'ın girdisini üretir. Sıralı ilerleyen bu iki işin ayrıntılı kontrol listesini SEO migration kontrol listesi yazısında topladım.

Kısacası içerik ekibi karar verir, SEO ekibi bu kararları adres düzeyinde güvenceye alır. Aynı kişi ikisini de yapabilir; yine de iki ayrı çıktı üretmesi gerekir.

Taşımaya başlamadan önce hangi ekip ve rolleri belirlemelisiniz?

İçerik göçünde en sık gördüğüm sorun teknik değil, sahipsizliktir. Herkes birinin sayfaları kontrol ettiğini varsayar, sonunda kimse kontrol etmez. Bu nedenle ilk toplantıda rolleri isimle yazmanızı öneririm.

• İçerik sahibi: Her bölüm için tut veya sil kararını veren kişi. Genellikle ilgili departmanın yöneticisidir.
• Göç sorumlusu: Envanteri, eşleme tablosunu ve takvimi yöneten kişi. Ajans tarafında veya sizin ekibinizde olabilir.
• Editör: Yeni baştan yazacağınız ve birleştireceğiniz metinleri hazırlayan kişi.
• Geliştirici: Otomatik aktarım betiklerini yazan ve yeni içerik modelini kuran kişi.
• Onaylayıcı: Hukuki, marka veya teknik doğruluk gereken sayfalarda son sözü söyleyen kişi.

Küçük bir işletmede bu rollerin üçü aynı kişide toplanabilir. Önemli olan, her sayfanın yanında bir sorumlu adının yazması ve kararın kime ait olduğunun tartışma konusu olmamasıdır.

Web sitesi içerik taşıma için envanteri nasıl çıkarırsınız?

Envanter, sitedeki her içerik parçasının tek bir tabloda listelenmesidir. Ben üç kaynağı birleştirerek çalışıyorum: sitenin kendi site haritası, bir tarayıcı aracının taraması ve CMS'in yönetim panelindeki içerik listesi. Tek kaynağa güvenirseniz mutlaka bir şey kaçırırsınız; çünkü site haritası yayında olmayan taslakları, tarayıcı ise iç link almayan yetim sayfaları göremez.

Bunun yanında analitik ve Search Console verisini de envantere ekleyin. Trafik alan ama menüde olmayan sayfaları çoğu zaman yalnızca bu kaynaklar gösterir. Google Search Console rehberinde sayfa raporlarını nasıl dışa aktaracağınızı anlattım.

Envanteri çıkarırken şu içerik türlerini ayrı ayrı sayın:

1. Kurumsal sayfalar: hakkımızda, ekip, iletişim, kariyer.
2. Hizmet ve ürün sayfaları.
3. Blog yazıları, haberler ve duyurular.
4. İndirilebilir belgeler: PDF katalog, teknik föy, fiyat listesi.
5. Medya kütüphanesi: görseller, videolar, logolar.
6. Sayfa parçaları: sık sorulan sorular, referans kutuları, yorumlar.
7. Yasal metinler: KVKK, çerez politikası, sözleşmeler.

Son iki madde en çok unutulan gruptur. Özellikle yasal metinlerin güncel sürümünü hukuk tarafıyla doğrulamadan taşımayın.

Envanter tablosunda hangi sütunlar olmalı?

Envanter tablosu ne kadar sade olursa o kadar uzun yaşar. Yine de karar vermeye yetecek bilgiyi tek satırda görmeniz gerekir. Benim kullandığım temel sütunlar şunlardır: eski URL, sayfa başlığı, içerik türü, bölüm, sorumlu, son güncelleme tarihi, kelime sayısı, son 12 ayın organik tıklaması, gelen iç link sayısı, dönüşüm katkısı ve karar.

Kelime sayısını elle saymak yerine toplu tarama çıktısından alabilirsiniz. Tek tek kontrol edeceğiniz metinler için kelime ve karakter sayacı işinizi hızlandırır. Dönüşüm katkısı için analitikte sayfa bazlı hedef raporuna bakın; form gönderen ziyaretçinin hangi sayfadan geldiği, bir sayfayı silme kararında belirleyici olur.

Ayrıca "notlar" adında serbest bir sütun ekleyin. Bir ürün sayfasının bayi sözleşmesinde referans verildiğini ya da bir PDF'in basılı katalogdaki QR kodla açıldığını ancak bu sütun sayesinde hatırlarsınız. Bu tür bağımlılıklar tabloda görünmezse silme kararları beklenmedik yerlerden geri döner.

Hangi içeriği tutmalı, birleştirmeli, yeniden yazmalı veya silmelisiniz?

Envanter hazır olduğunda her satıra bir karar etiketi verirsiniz. Ben dört karar kullanıyorum ve aşağıdaki tabloda hangi durumda hangisini seçtiğimi özetledim.

Kararları tek başınıza vermeyin; her bölümün içerik sahibiyle kısa bir gözden geçirme toplantısı yapın. Bu toplantıda yalnızca tartışmalı satırları konuşun, net olanları ise listeden onaylayın. Böylece yüzlerce satırlık bir tablo birkaç saatlik bir çalışmayla karara bağlanır ve ekip, kendi alanındaki silme kararlarını sonradan sürpriz olarak öğrenmez. Örneğin insan kaynakları ekibi eski ilanların kaldırılmasına buradan onay verir.

Karar verirken yalnızca trafiğe bakmayın. Az ziyaret alan ama satış ekibinin tekliflerde gönderdiği bir teknik sayfa, trafik tablosunda önemsiz durur; fakat satış sürecinde kritik rol oynar.

Düşük trafikli sayfaları silmek her zaman doğru mu?

Hayır. Son yıllarda "içerik budama" moda oldu ve bazı projelerde sitenin yarısının tek hamlede silindiğini gördüm. Google'ın yararlı içerik rehberi önce insanlara hizmet eden, özgün ve güvenilir içeriği öne çıkarır. Bu, az okunan her sayfanın zararlı olduğu anlamına gelmez.

Silme kararından önce üç soruyu sorun. Birincisi: bu sayfa başka bir kanalda işe yarıyor mu, örneğin e-posta şablonunda veya basılı materyalde? İkincisi: başka sitelerden bu sayfaya bağlantı geliyor mu? Üçüncüsü: sayfanın konusu, ileride büyütmek istediğiniz bir alanla ilgili mi?

Üç sorunun cevabı da hayırsa silebilirsiniz. Öte yandan cevaplardan biri evetse sayfayı birleştirmeyi veya yeniden yazmayı düşünün. Bu sayede hem arşiv şişkinliğinden kurtulursunuz hem de birikmiş değeri çöpe atmazsınız. İçeriğin güncel tutulmasıyla ilgili daha geniş bakış için web sitesini güncel tutmak yazısını okuyabilirsiniz.

Web sitesi içerik taşıma için eşleme tablosunu nasıl hazırlarsınız?

Eşleme tablosu, envanterin kararları içeren hâlidir. Her eski içeriğin yeni sitede nereye düştüğünü, hangi şablonu kullanacağını ve hangi alanlara bölüneceğini gösterir. Envanter "ne var?" sorusuna, eşleme tablosu ise "ne olacak?" sorusuna cevap verir.

Tabloya şu sütunları eklemenizi öneririm: yeni URL, yeni şablon adı, hedef içerik türü, alan eşlemesi, taşıma yöntemi (otomatik veya elle), durum ve kontrol eden kişi. Yeni URL'leri üretirken tutarlılık için slug oluşturucu gibi bir araç kullanabilirsiniz.

Birleştirilen sayfalarda birden fazla eski satır aynı yeni satırı gösterir. Bu ilişkiyi tabloda açıkça göstermezseniz yönlendirme aşamasında hangi sayfanın nereye gittiği tartışmaya döner. Google da URL değişikliği içeren site taşıma rehberinde eski ve yeni adreslerin eşlemesini hazırlamayı taşımanın temel adımları arasında sayar. Yönlendirme türlerinin ayrıntısına bu yazıda girmiyorum.

Eski içeriği yeni içerik modeline nasıl oturtursunuz?

Yeni sitelerin çoğu artık tek bir büyük metin kutusu yerine alan bazlı bir yapıyla çalışır: başlık, özet, ana görsel, teknik özellik tablosu, SSS bloğu, ilgili ürünler gibi. Eski sitede ise bu bilgilerin tamamı çoğu zaman tek bir HTML gövdesinin içinde karışık hâlde durur.

Bu nedenle içerik modelini tasarım bitmeden, taşıma başlamadan önce kesinleştirin. Ardından her eski içerik türü için alan eşlemesi yazın. Örneğin eski ürün sayfasındaki ilk paragraf yeni "özet" alanına, madde işaretli liste "özellikler" alanına, sayfa sonundaki tablo ise "teknik veri" alanına gider.

Alan eşlemesi yapılmayan projelerde editörler her sayfayı yeniden kurgulamak zorunda kalır. Sonuçta aynı türdeki iki sayfa birbirinden farklı bir görüntü verir ve tasarım sisteminin sağladığı tutarlılık daha ilk günden bozulur. Alan bazlı yapının bir başka avantajı da yapısal veriyi kolaylaştırmasıdır; bu konuyu schema markup yazısında ayrıca işledim.

Otomatik taşıma mı, elle taşıma mı daha doğru?

İkisinin karışımı. Yüzlerce benzer yapıdaki blog yazısını elle kopyalamak hem yavaş hem hataya açıktır; üstelik editör birkaç saat sonra dikkatini kaybeder. Öte yandan ana sayfa, hizmet sayfaları ve dönüşüm getiren açılış sayfaları gibi az sayıdaki kritik içeriği otomatik betiğe bırakmak da risklidir.

Benim pratiğim şu: aynı şablonu paylaşan ve karar etiketi "tut" olan içerikler için geliştirici bir aktarım betiği yazar. Betik önce küçük bir örnek grupta çalışır, editör sonucu kontrol eder, sorunlar giderildikten sonra geliştirici tüm grubu aktarır. "Yeniden yaz" ve "birleştir" etiketli içerikler ise her zaman elle, editörün elinden geçer.

Bir de saha tecrübesine dayalı bir uyarı ekleyeyim, garanti değil: otomatik aktarımın ilk denemesinde neredeyse her projede bir biçim sorunu çıkıyor. Bu yüzden takvime en az bir düzeltme turu koyun ve betiği tek seferde bitecek bir iş gibi planlamayın.

Metin taşırken biçim ve kod kirliliğini nasıl temizlersiniz?

Eski CMS'lerden gelen metinler gözle fark etmediğiniz yüklerle gelir: satır içi stil etiketleri, Word'den yapıştırılmış biçimler, eski tema kısa kodları, boş paragraflar ve iç içe geçmiş gereksiz etiketler. Bunlar yeni tasarımda beklenmedik yazı tipleri, bozuk boşluklar ve kırık bileşenler olarak ortaya çıkar.

• Satır içi stil ve yazı tipi etiketlerini kaldırın; biçimi yeni tasarım sistemi versin.
• Eski temaya ait kısa kodları listeleyin ve her birinin yeni karşılığını belirleyin.
• Başlık hiyerarşisini düzeltin; kalın biçimli paragrafları gerçek başlığa çevirin.
• Tabloları kontrol edin; mobilde okunmayan geniş tabloları sadeleştirin.
• Gömülü video ve harita kodlarının hâlâ çalıştığını doğrulayın.

Bu temizliği betiğin içine koyabilirsiniz; ancak son kararı her zaman bir insan gözü vermeli. Özellikle tablolarda otomatik temizlik, sütun sırasını veya birleşik hücreleri bozabilir.

Görselleri ve medya dosyalarını kayıpsız nasıl taşırsınız?

Medya kütüphanesi, içerik göçünün en dağınık bölümüdür. Aynı görselin beş farklı boyutu, hiçbir sayfada kullanılmayan yüklemeler ve dosya adı "IMG_4432" olan fotoğraflar sık rastladığım durumlardır. Önce kullanılan ve kullanılmayan dosyaları ayırın; yalnızca en az bir içerikte geçen dosyaları taşıyın.

Taşınan her görsel için üç kontrol yapın: dosya boyutu, dosya adı ve alternatif metin. Büyük dosyaları yeni sitede sorun çıkarmadan önce küçültün; tek tek işler için resim küçültme aracını kullanabilirsiniz. Anlamsız dosya adlarını içeriği tarif eden adlarla değiştirin.

Alternatif metin konusunda iki kaynağı temel alıyorum. W3C'nin görsel erişilebilirliği eğitimi hangi görselin açıklama gerektirdiğini, hangisinin dekoratif sayılacağını anlatır. Google'ın Google Görseller için SEO rehberi ise açıklayıcı dosya adı ve alt metnin görselleri anlamaya yardım ettiğini belirtir. Taşıma, eksik alt metinleri tamamlamak için iyi bir fırsattır.

PDF, katalog ve indirilebilir belgeleri nasıl ele almalısınız?

İndirilebilir belgeler çoğu envanterde yer almaz; çünkü sayfa değil, dosyadır. Oysa sanayi, sağlık ve hukuk gibi sektörlerde en çok indirilen içerik çoğu zaman PDF kataloglardır. Bu belgelerin adresleri müşterinin e-posta kutusunda, bayilerin sunumlarında ve basılı materyallerde yıllarca yaşar.

Belgeler için ayrı bir envanter sekmesi açın. Her dosya için şunları yazın: eski adres, belge sürümü, sorumlu departman, hâlâ geçerli olup olmadığı ve yeni adres. Eski sürümleri taşımak yerine güncel sürümü yükleyin, ancak eski adresin yeni belgeye ulaşmasını sağlayın.

Ayrıca her belge için bir karşılama sayfası düşünün. Yalnızca PDF'e giden bir bağlantı, arama motoru ve kullanıcı için bağlam sunmaz. Kısa bir açıklama, belgenin kapsamı ve indirme butonu içeren bir sayfa, hem ziyaretçiye hem de satış ekibinize daha net bir giriş noktası sağlar.

İç linkler ve gömülü bağlantılar taşımada neden bozuk kalır?

Metnin içindeki bağlantılar, taşıma sonrası en sessiz bozulan unsurdur. Eski URL yapısını kullanan yüzlerce iç link, yönlendirme sayesinde çalışmaya devam eder gibi görünür. Ancak her tıklama bir ara adım üretir ve zamanla yönlendirme zincirleri oluşur.

Bu yüzden taşıma sırasında gövde metnindeki bağlantıları eşleme tablosuna göre doğrudan yeni adreslere güncelleyin. Otomatik betiğe bu adımı eklemek genellikle kolaydır; çünkü eşleme tablosu zaten elinizdedir. Birleştirilen veya silinen sayfalara giden bağlantıları ise editör gözüyle gözden geçirin; bazen bağlantıyı tamamen kaldırmak daha doğru olur.

Taşıma sonrası örnek sayfalarda yönlendirme denetleyici ile zincir olup olmadığını kontrol edebilirsiniz. İç link mimarisini yeniden kurgulamak istiyorsanız iç linkleme stratejisi yazısı iyi bir başlangıç noktasıdır.

Meta başlıkları, açıklamaları ve yapısal verileri de taşımalı mısınız?

Evet, ama kontrol ederek. Eski sitede yıllar içinde editörlerin elle yazdığı meta başlık ve açıklamalar, çoğu zaman bir editörün emeğidir ve aramada tıklama getiriyordur. Yeni CMS'in bunları otomatik şablonla ezmesine izin vermeyin; eşleme tablosuna "meta başlık" ve "meta açıklama" sütunlarını ekleyin.

Bununla birlikte her meta verisini körlemesine taşımak da doğru değildir. Birleştirilen sayfalarda yeni bir başlık yazmanız gerekir; yeniden yazılan sayfalarda ise meta açıklama yeni metinle uyumlu olmalıdır. Uzunluk ve görünümü kontrol etmek için Google SERP önizleme aracı pratik bir yardımcıdır.

Yapısal veriler için de aynı mantık geçerlidir. Eski sitede elle eklediğiniz SSS veya ürün işaretlemeleri varsa, yeni sitede bunların şablon düzeyinde üretilip üretilmediğini kontrol edin. Aksi hâlde zengin sonuçlarınızı sessizce kaybedebilirsiniz.

İçerik dondurma dönemini nasıl yönetirsiniz?

İçerik dondurma, taşıma sürerken eski sitede yeni içerik yayınlamayı veya mevcut içeriği değiştirmeyi durdurduğunuz dönemdir. Dondurma olmazsa envanterdeki bilgiler eskir ve lansman günü bazı güncellemeler kaybolur.

Ancak uzun bir dondurma, pazarlama ekibini haftalarca sessiz bırakır. Bu yüzden dondurmayı olabildiğince kısa tutun ve istisna kuralı yazın. Örneğin acil duyurular ve yasal güncellemeler dondurma sırasında da yayınlanabilir; fakat bu değişiklikler aynı gün yeni sitede de yer alır ve envantere not düşülür.

Pratikte ben dondurmayı iki aşamada kuruyorum. İlk aşamada yalnızca yeni sayfa açmak durur, küçük düzeltmeler serbesttir. İkinci aşamada, yani son aktarımdan hemen önce, tüm değişiklikler durur. Böylece son aktarımdaki içerik ile eski sitedeki içerik birebir aynı olur.

Taşınan içeriğin kalitesini nasıl kontrol edersiniz?

Kalite kontrolü, "sayfa açık mı?" sorusundan çok daha fazlasıdır. Ben kontrolü üç katmanda yapıyorum: sayısal eşleşme, örneklem incelemesi ve kritik sayfa incelemesi.

Sayısal eşleşmede eşleme tablosundaki "tut" ve "yeniden yaz" satırlarının sayısı ile yeni sitedeki yayındaki içerik sayısını karşılaştırırsınız. Fark varsa hangi içeriğin eksik olduğunu bulana kadar lansmanı ertelersiniz. Örneklem incelemesinde her içerik türünden rastgele sayfaları açıp başlık, görsel, tablo, bağlantı ve meta alanlarını kontrol edersiniz.

Kritik sayfa incelemesi ise en çok trafik ve dönüşüm getiren sayfaların tamamının elle gözden geçirilmesidir. Bu listeyi envanterdeki trafik ve dönüşüm sütunlarından çıkarırsınız. Kontrolde bulunan her sorunu eşleme tablosundaki durum sütununa işleyin; böylece hangi sorunun çözüldüğünü herkes aynı yerde görür.

Lansmandan sonraki ilk haftalarda neyi izlemelisiniz?

Lansman, içerik göçünün bitişi değil, doğrulama döneminin başlangıcıdır. İlk haftalarda üç sinyale bakıyorum: bulunamayan sayfa hataları, arama sorgularında görünürlük değişimi ve form dönüşümleri.

Bulunamayan sayfa hataları, eşleme tablosunda kaçan içeriği gösterir. Görünürlük değişimi, birleştirilen veya yeniden yazılan sayfaların beklenen etkiyi yaratıp yaratmadığını anlatır. Form dönüşümleri ise içerik kararlarının iş sonucuna etkisini ölçer. Taşıma sonrası teknik takibin ayrıntılı listesi için yeniden SEO migration yazısına dönebilirsiniz.

Eski sitenin yedeğini ve eşleme tablosunu lansmandan sonra da saklayın. Birkaç ay sonra bir müşteri eski bir kataloğu sorduğunda veya bir sayfanın neden silindiği sorulduğunda cevabı bu iki kaynakta bulursunuz.

Web sitesi içerik taşıma takvimini nasıl planlarsınız?

Takvimi tarihten değil, bağımlılıklardan kurmanızı öneririm. Envanter bitmeden karar veremezsiniz, kararlar bitmeden eşleme tablosu tamamlanmaz, içerik modeli kesinleşmeden de otomatik aktarım başlayamaz. Bu zinciri görünür kılmak, ekibin hangi işin kimi beklettiğini anlamasını sağlar.

1. Envanter ve veri toplama.
2. Karar etiketleri ve içerik sahiplerinin onayı.
3. İçerik modeli ve alan eşlemesi.
4. Yeniden yazım ve birleştirme.
5. Deneme aktarımı ve düzeltme turu.
6. İçerik dondurma ve son aktarım.
7. Kalite kontrol ve lansman.

Yeniden yazım adımını tasarım süreciyle paralel yürütün. Böylece tasarımcı gerçek metinle çalışır, editör de yeni şablonun hangi uzunlukta metin kaldırdığını erkenden görür. Örneğin hizmet kartına sığmayan bir özet, lansmandan bir hafta önce değil, tasarım aşamasında ortaya çıkar.

Çok dilli sitelerde içerik göçünü nasıl ele almalısınız?

Çok dilli sitelerde envanter bir tablo değil, dil sayısı kadar tablodur. Türkçe sayfanın İngilizce karşılığı var mı, Almanca sürümü güncel mi, hangi dilde hangi sayfa hiç çevrilmemiş? Bu soruları dil bazında cevaplamadan karar vermeye başlarsanız, bir dilde sildiğiniz sayfanın diğer dildeki karşılığı ortada kalır.

Bu yüzden envantere bir "dil grubu" sütunu ekleyin ve aynı içeriğin farklı dillerdeki sürümlerini tek bir kimlikle bağlayın. Kararı dil grubu düzeyinde verin; ardından her dil için ayrı durum bilgisi tutun. Çeviri ekibinin takvimini de ana takvime bağlayın, aksi hâlde lansman günü bazı dillerde boş şablonlar görürsünüz.

Dil sürümlerinin arama motoruna nasıl bildirileceği ayrı bir teknik konudur. Bunu çok dilli web sitesi SEO yazısında ayrıntılı anlattım.

Taşıma sırasında marka dilini ve anahtar kelime odağını nasıl güncellersiniz?

Yenileme projeleri çoğu zaman bir marka güncellemesiyle birlikte gelir. Yeni logo ve renkler gelir, ancak metinler on yıl önceki tonla konuşmaya devam eder. İçerik göçü, bu tutarsızlığı gidermek için en uygun andır; çünkü her sayfayı zaten tek tek ele alıyorsunuz.

Bunun için kısa bir yazım kılavuzu hazırlayın: hitap biçimi, ürün adlarının yazımı, sık kullanılan terimler ve kaçınılacak ifadeler. Editörler yeniden yazdıkları her metinde bu kılavuzu temel alır. Öte yandan "tut" kararı verdiğiniz sayfalara da hızlı bir dil taraması yapın; eski slogan veya kaldırılan ürün adları sıklıkla bu sayfalarda saklanır.

Anahtar kelime odağı için de benzer bir fırsat vardır. Birleştirdiğiniz sayfalar tek bir aramaya odaklanır ve iki sayfanın aynı sorgu için yarışması sona erer. Bu eşleştirmeyi planlamak için anahtar kelime haritalama yazısındaki yöntemi eşleme tablonuza uygulayabilirsiniz.

Kayıpsız içerik göçü için en sık yapılan hatalar nelerdir?

Yıllar içinde farklı ölçekte projelerde aynı hataların tekrarlandığını gördüm. Hepsi planlama aşamasında önlenebilir hatalardır.

• Envanteri yalnızca site haritasından çıkarmak ve yetim sayfaları atlamak.
• İçerik modelini taşıma başladıktan sonra değiştirmek.
• Tüm içeriği otomatik betiğe bırakıp kritik sayfaları elle kontrol etmemek.
• PDF ve medya dosyalarını ayrı bir envantere almamak.
• Gövde metnindeki eski iç linkleri güncellememek.
• Yeni metinleri lansmandan birkaç gün önce istemek.
• İçerik dondurmayı hiç uygulamamak veya haftalarca uzatmak.

Bu listedeki maddelerin çoğu teknik bilgi değil, disiplin gerektirir. Bu nedenle içerik göçünü bir yan görev olarak değil, kendi sorumlusu ve takvimi olan bir alt proje olarak ele almanızı öneririm.

İçerik taşıma işini ajansa mı vermeli, ekip içinde mi yapmalısınız?

Bu kararın cevabı içeriğinizin hacmine ve bilgisinin kimde olduğuna bağlıdır. Ürün ve hizmet bilgisini en iyi sizin ekibiniz bilir; dolayısıyla tut veya sil kararlarını dışarıya tamamen devretmek doğru olmaz. Öte yandan envanter çıkarma, otomatik aktarım ve kalite kontrol süreci deneyim isteyen, tekrarlanabilir işlerdir.

Benim önerdiğim model şu: kararları siz verin, süreci ve teknik aktarımı deneyimli bir ekip yönetsin. Yeni site tasarımıyla birlikte içerik göçünü de planlamak istiyorsanız web tasarım hizmeti sayfama, arama görünürlüğünü koruma tarafı için ise SEO danışmanlığı sayfama göz atabilirsiniz.

Hangi modeli seçerseniz seçin, envanter, karar etiketi, eşleme tablosu ve kalite kontrol adımlarını atlamayın. Bu dört çıktı, yenileme sonrasında "hangi içerik nereye gitti?" sorusunun kalıcı cevabıdır.