WordPress Sitesini Taşıma: Veri ve Yönlendirme

WordPress sitesini yeni bir hosta ya da alan adına taşırken iki ayrı iş yürür: dosya ve veritabanının sağlam aktarılması, arama motoruna adres değişikliğinin doğru anlatılması. Kısa cevap: Önce yedek alın, taşıma türünü belirleyin, veritabanındaki eski adresi serileştirilmiş veriyi bozmayan bir araçla değiştirin, guid sütununa dokunmayın, .htaccess ve kalıcı bağlantıları yeniden yazıp yönlendirmeleri test edin, sonra Search Console'dan izleyin. Alan adı değiştiren bir blog, mağaza ya da kurumsal site yönetiyorsanız bu sıra, eski sitedeki sıralamayı koruma şansınızı artıran ve veri kaybını önleyen çerçevedir. DNS geçişi ve TTL gibi barındırma tarafı için ayrı bir yazı vardır: hosting değiştirirken SEO ve DNS geçişi.

Önce taşıma türünü belirleyin

WordPress taşıma belgesi (yeni sekmede açılır) işe iki ayrım yaparak başlar. Adresler değişmiyorsa, yani yalnızca hosting değişiyorsa, dosyaları ve veritabanını kopyalarsınız; veritabanı adı ya da kullanıcısı değişirse yeni sunucuda wp-config.php güncellenir. Alan adı ya da adres yolu değişiyorsa belge dokuz adımlı bir sıra tarif eder. Hangi türde olduğunuzu bilmek, serileştirilmiş veri ve yönlendirme adımlarının gerekip gerekmediğini belirler.

Arayüzü Türkçe kullanıyorsanız panel ve eklenti ekranlarındaki adlar buradaki karşılıklardan farklı görünebilir.

Taşımayı bölmek

Google'ın URL değişikliğiyle site taşıma belgesi (yeni sekmede açılır) ilk olarak genel bir uyarı verir: sıralamada dalgalanma bekleyin, aynı anda tek şeyi değiştirin, taşımayı bölmeyi düşünün ve trafiğin düşük olduğu bir zamana denk getirin. Uygulama önerisi: hosting ve alan adı değişikliğini aynı gün yapmayın. Önce hosting'i taşıyıp birkaç gün izleyin, sonra alan adını değiştirin. Böylece bir sorun çıktığında hangi değişikliğin neden olduğunu ayırt edebilirsiniz.

Yedek ve veritabanı aktarımı

Taşıma belgesi yedeği tavsiye değil gereklilik olarak sunar: WordPress dizinini, görselleri, eklentileri ve diğer dosyaları, ayrıca veritabanını yedekleyin. Alan adı değişikliği sırasındaki dokuz adım şu mantığı izler: dosyaları indirin, veritabanını dışa aktarın, bunları ayrı bir klasöre site yedeği olarak koyun, eski sitede Ayarlar, Genel ekranından adresleri değiştirin ve bir 404 sayfası göreceğinizi bekleyin, dosyaları ve veritabanını yeniden indirin, wp-config.php içine yeni sunucunun veritabanı bilgilerini yazın, dosyaları yükleyin ve veritabanını yeni sunucuda içe aktarın.

İki yedek neden gerekir

Belgenin sırasına göre ilk indirdiğiniz kopya, hiçbir şeyi değiştirmeden aldığınız saf yedektir. İkinci kopya adresleri değiştirdikten sonra alınır ve yeni sunucuya gider. Bu iki ayrı kopya, arama-değiştirme yanlış giderse eski haline dönmenizi sağlar. Belge, bir değiştirme yanlış giderse yedekten veritabanını geri yükleyip adımları dikkatle yinelemeyi önerir.

Taşımadan önce sınama için geçici adres

Belge, yeni sunucuyu canlıya almadan sınamak için wp_options tablosundaki siteurl ve home değerlerini geçici olarak değiştirebileceğinizi söyler. Sınama ortamı arama motorlarına açık kalmamalıdır; ayrıntı için test ortamı indekslenmesini önleme yazısına bakın.

Serileştirilmiş veriyi bozmadan arama-değiştirme

Veritabanında eski adresi yenisiyle değiştirmek taşımanın en riskli adımıdır. Belge, düz bir bul-ve-değiştir işleminin veri serileştirmesinde sorun çıkarabileceğini söyler: bazı temalar ve widget'lar dizge uzunluklarını saklar ve adres değişince uzunluk da değişir. Belgenin önerdiği üç yol şunlardır: Dashboard'a erişiminiz varsa Velvet Blues Update URLs ya da Better Search Replace gibi bir eklenti, WP-CLI'ın search-replace komutu ya da veritabanı yönetimine alışkın kullanıcılar için üçüncü taraf bir arama-değiştirme betiği.

Üçüncü satırdaki silme önerisi bir uygulama önerisidir; belgede betik temizliğiyle ilgili ifade yok.

guid kuralı

Belge guid sütunu için en sert cümlesini kurar: hiçbir koşulda guid sütununun içeriğini değiştirmeyin. Guid, besleme okuyucularının öğeyi izlemek için kullandığı gönderi tanımlayıcısıdır. Bu yüzden arama-değiştirme sırasında bu sütunu atlayın. WP-CLI örneği bunu açıkça gösterir: komuta guid sütununu atlayan seçenek eklenir. Eklentiyle yapıyorsanız aracın guid'i dışarıda bıraktığını doğrulayın.

Arama kapsamı ve belgedeki çelişki

Belge, eski adresin görsel bağlantılarında, eklenti seçeneklerinde, yükleme yollarında ve widget'larda kalabileceğini anlatır ve tam veritabanı araması yapılmasını önerir, ama aynı sayfada yalnızca wp_posts tablosunda arama-değiştirme yapılması gerektiğini de söyler. İki ifade birbiriyle çelişir. Uygulama önerisi: değiştirmeden önce arama kapsamını kendiniz belirleyin ve her tabloda neyi değiştirdiğinizi bilin. Geçici veri kayıtları (transient) silinebilir. WordPress bunları yeniden oluşturur.

.htaccess, kalıcı bağlantılar ve yönlendirme testi

Belge .htaccess dosyasının yedeğini almayı bir öneri değil bir zorunluluk olarak anlatır. Sıra şöyledir: dosyayı yedekleyin, özel yeniden yazma ya da yönlendirme kurallarını güvenli bir yere kopyalayın, Kalıcı Bağlantılar ayarını yeniden kaydederek dosyayı yeniden oluşturun, özel kuralları yeni adrese göre güncelleyerek geri ekleyin ve tüm yönlendirmeleri test edin.

Sunucu tarafı kalıcı yönlendirme

Google'ın yönlendirmeler sayfası (yeni sekmede açılır) kalıcı yönlendirmeleri (301, 308) hedef sayfayı arama sonuçlarında gösteren yöntem olarak tanımlar; geçici yönlendirmelerde (302, 303, 307) ise kaynak sayfa sonuçlarda kalır. Uygulama yöntemlerinde sunucu tarafını tercih eder; örnekleri arasında Apache .htaccess kuralları yer alır. Anında meta yenilemeyi kalıcı yönlendirme sayar, JavaScript yönlendirmesini ise son çare olarak anar. WordPress taşımasında sunucu tarafı yönlendirmeyi eski alan adının .htaccess dosyasında ya da eski barındırmanın yapılandırmasında kurarsınız.

Eşleme listesi ve canonical

Google'ın taşıma belgesi, eski adreslerin yenilerine eşlendiği bir liste hazırlamanızı, yeni sitede canonical etiketlerini, hreflang işaretlerini ve iç bağlantıları güncellemenizi ister. WordPress'te iç bağlantılar için arama-değiştirme, canonical için SEO eklentisinin adres ayarı kontrol noktasıdır. Eski sitede kalan bir canonical yeni siteye değil eski adrese işaret ediyorsa, taşıma sinyalleri çelişir.

Sitemap ve robots

Belgeye göre yeni sitemap'i Search Console'a göndermeli, sonra eskisini kaldırmalısınız. Geliştirme sırasında konmuş noindex etiketlerini ya da robots.txt engellerini yeni sitede kaldırın. Sitemap'in denetimi için XML sitemap denetimi ve hata çözümü yazısı kullanılabilir.

Yönlendirme testi nasıl yapılır

Yönlendirmeyi kurmak işin yarısıdır; ikinci yarısı bunu bilerek sınamaktır. Uygulama önerisi: eşleme listesinden rastgele değil, farklı türlerden örnek seçin ve her biri için yanıt kodunu ve hedef adresi yazın.

Zincir ve döngü belirtisi görürseniz adresin sunucu kuralıyla WordPress ayarı arasındaki çatışmaya bakın. Yönlendirme zinciri konusunda Google'ın taşıma belgesi, mümkün olduğunda zincirden kaçınmayı önerir.

Yönlendirmeleri ne kadar süre tutmalı

Google'ın taşıma belgesi yönlendirmeleri mümkün olduğunca uzun tutmanızı ister ve genel olarak en az bir yıl önerir. Alan adı değiştirirken Taşıma Adresi Değişikliği aracını yalnızca alan adları ya da alt alan adları arasında taşıma yaparken kullanmanızı söyler; http'den https'ye geçiş, aynı alan adında www değişikliği ya da yol değişikliği için gerekli değildir. Belgenin eşleme ve zincir tavsiyesi de vardır: mümkün olduğunda sunucu tarafı kalıcı yönlendirme kullanın ve zincirden kaçının. TTL konusunda bu belgede ifade yok.

Süre konusunda yönlendirmeyi geri alamayacağınızdan emin değilseniz kalıcı yönlendirme kurmayın. Belge, kalıcı yönlendirmeyi yalnızca değişikliğin geri alınmayacağından emin olunca önerir; kısa süreli kesintilerde geçici yönlendirme, özgün adresin arama sonuçlarındaki yerini değiştirmez.

Taşıma sonrası izleme

Google belgesi, hem eski hem yeni siteyi Search Console'da doğrulayıp izlemenizi ve sunucu günlüklerine bakmanızı ister. Eski sitedeki trafiğin düşmesini, yeni sitedeki trafiğin artmasını bekleyin; belgeye göre sıralamada geçici dalgalanma olur ve orta ölçekli sitelerde yeni adreslerin eskilerin yerini alması birkaç hafta ya da daha uzun sürebilir. Bu süre belgenin ifadesidir; sitenize özgü bir tahmin değildir.

Taşıma sonrası ilk haftalar için takvim

Google belgesi izlemeyi öğütler ama gün gün bir takvim vermez. Uygulama önerisi: izlemeyi gün, hafta ve ay olmak üzere üç aşamaya bölün ve her aşamaya yalnızca birkaç soru koyun.

Tablonun aşama adları bir öneridir. Google belgesi yönlendirmeleri en az bir yıl tutmayı ve orta ölçekli sitelerde yeni adreslerin eskilerin yerini almasının birkaç hafta ya da daha uzun sürebileceğini söyler. Dalgalanma sürerken değişiklik yapmak, hangi etkinin nereden geldiğini ayırt etmeyi zorlaştırır.

Taşıma sırasında yapılmaması gerekenler

Aynı anda tasarım değiştirmek, adres yapısını yeniden kurmak ve içeriği toplu yeniden yazmak, taşıma belgesinin "aynı anda tek şeyi değiştirin" uyarısına ters düşer. Bu işleri taşıma tamamlandıktan ve izleme sakinleştikten sonraya bırakın. Sitemap'e eski adresleri koymayın, yeni sitede eski adreslere iç bağlantı bırakmayın ve geliştirme sırasında konmuş noindex etiketlerini kaldırmayı unutmayın.

İçe aktarmadan sonra komutlar ve kalan izler

Taşıma belgesinin WP-CLI örnekleri komutların şeklini gösterir: eski adresten yeni adrese bir search-replace komutu, guid sütununu atlayan bir seçenekle birlikte, ve home ile siteurl değerlerini ayarlayan iki wp option update komutu. Her iki ayar için de adres tam https:// önekini taşımalı ve sonunda eğik çizgi bulunmamalıdır. Eski adres başka yerlerde de kalmış olabilir: görsel bağlantılarında, eklenti seçeneklerinde, yükleme yollarında ve widget'larda. Bunların bir kısmı yönetim panelinden, örneğin Görünüm altındaki Widget'lar ekranından düzeltilir. Eklentiye özgü seçenek değerleri elle güncelleme isteyebilir. Belge ayrıca Duplicator gibi bir taşıma eklentisinin siteyi iki konum arasında taşıyabileceğini söyler; bu yolu tercih edecekseniz de yedek ve sınama adımlarını atlamayın.

Eklenti ayarlarında eski adres

Uygulama önerisi: taşımadan sonra form, rezervasyon, SEO ve önbellek eklentilerinin ayar ekranlarını tek tek açıp adres içeren alanlara bakın. Arama-değiştirme serileştirilmiş değerleri doğru güncellese bile, eklentinin kendi önbelleğinde eski adres kalmış olabilir. Önbellek eklentisini temizlemek, kaynak kodunu çıkış yapmış tarayıcıda yeniden okumak ve sitemap adresini açmak üç ucuz kontroldür.

Geri dönüş planı

Taşıma planı, geri dönüşü de içermelidir. Eski sunucuyu taşıma biter bitmez kapatmayın; yeni sitede ciddi bir sorun çıkarsa eski siteye dönebilmek için eski kopyayı ve veritabanı yedeğini bir süre tutun. Uygulama önerisi: eski barındırma hesabını, yönlendirmeleri doğruladığınız ve Search Console'da yeni sitenin dizinlendiğini gördüğünüz tarihe kadar açık bırakın. Geri dönüş kararını önceden yazın: hangi belirti, hangi eşikte geri dönüşü tetikler? Örneğin yeni adreslerin büyük bölümü 404 dönüyorsa ya da ödeme akışı çalışmıyorsa, eski siteye dönmek makuldür.

Taşıma günü iletişim

Taşıma günü ekip içinde kimin neyi yaptığını açık yazın: yedeği kim alıyor, arama-değiştirmeyi kim çalıştırıyor, yönlendirmeleri kim sınıyor? Tek kişilik sitede bile bu liste, yorgunlukla atlanan adımları görünür kılar. Taşıma bittiğinde yapılan her işlemi tarihle bir belgeye geçirin; ay sonra yaşanan bir sorunda hangi adımın hangi sonucu doğurduğunu bu belge anlatır.

Karar kuralı

Taşımadan önce üç soru yeterlidir.

1. Adres değişiyor mu? Değişmiyorsa arama-değiştirme ve yönlendirme gerekmez.
2. Veritabanı değeri serileştirilmiş veri içeriyor mu? İçeriyorsa düz bul-değiştir yapmayın; belgenin önerdiği üç yoldan birini kullanın.
3. Eski adresler yeni adreslere eşleniyor mu? Eşleme listesi yoksa taşımaya başlamayın.

Karar tablosu: hangi taşıma yolu

Örnek senaryo: yerel bir peyzaj ofisinin sitesi

Örnek senaryo: Yerel bir peyzaj ofisi, adını değiştirip yeni bir alan adına geçmek ve aynı zamanda hosting'ini yenilemek ister. Sitede iç sayfa bağlantıları, görsel galerisi ve bir randevu eklentisi vardır. Ofis, hosting ve alan adı değişikliğini iki aşamaya böler.

Ofis, yönlendirmeleri bir yıl boyunca takvim notuyla korur ve süre dolmadan kaldırmaz.

Örnek senaryo: bir ders kitabı yazarının sitesi

Yazarın sitesi yeni bir alan adına ve yeni bir hosting hesabına geçiyor. İlk deneme, eklentiler etkinken alınan bir dışa aktarma dosyasıyla yapılıyor ve dosya boş çıkıyor. Düzeltme sırası: eklentileri devre dışı bırakıp yeniden dışa aktarmak, yeni sunucuda yükleme sınırını sormak, arama-değiştirmeyi guid sütununu atlayarak çalıştırmak, kalıcı bağlantıları yeniden kaydetmek ve eski adresten yeni adrese sunucu taraflı yönlendirme yazmak. Her adım sonunda bir iç sayfa ve ana sayfa test edilir. Bu senaryo kurgusaldır.

Taşıma öncesi envanter ve içerik dondurma

Taşımaya başlamadan önce sitede neyin bulunduğunu yazın: eklentiler, temalar, özel içerik türleri, formlar, rezervasyon ya da ödeme akışları, zamanlanmış görevler ve harici servis bağlantıları. Bu liste, taşıma sonrası sınama listenizin de iskeletidir. Uygulama önerisi: veritabanını dışa aktardığınız andan yeni sitede yayına çıktığınız ana kadar içerik girişini durdurun. Aksi halde bu aralıkta yazılan yazı, yorum ya da sipariş yeni sunucuya taşınmaz ve sonradan elle birleştirmek gerekir.

Veri üreten bölümler

Üyelik, yorum, form girişi ve sipariş gibi veri üreten bölümler taşıma penceresinde özel dikkat ister. Bu verilerin taşıma sırasında kaybolmadığını anlamanın en kolay yolu, taşımadan önce her türden bir kayıt örneğini not almak ve taşımadan sonra aynı kaydı bulmaktır. Belgelerde bu konuda ifade yok; bu bir uygulama önerisidir ve siteye özgü sınama senaryosunu sizin kurmanız gerekir.

Taşımada kullanılan araçların seçimi

Üç arama-değiştirme yolundan hangisini seçeceğiniz, erişiminize ve rahat ettiğiniz araca bağlıdır. Panel erişimi varsa eklenti en kolay yoldur; ancak eklentinin serileştirilmiş veriyi doğru işlediğini ve guid sütununu dışarıda bıraktığını doğrulamanız gerekir. Komut satırı erişiminiz varsa WP-CLI'ın search-replace komutu, guid sütununu atlayan seçenekle birlikte, belgenin örnek verdiği yoldur. Veritabanı yönetimine alışkınsanız üçüncü taraf betik de bir seçenektir, ama betiği işiniz bitince sunucudan silmek bir uygulama önerisidir.

Hangi aracı seçerseniz seçin, işlemi önce hazırlık ortamında çalıştırın ve sonucu iki kez okuyun: eski adres kaldı mı, yeni adres doğru yazıldı mı, guid değişmedi mi? Bu üç soru sonucu anlamlı biçimde sınar.

Hazırlık ortamında deneme

Taşımayı canlı sitede ilk kez denemeyin. Veritabanı yedeğini ayrı bir ortamda içe aktarıp tüm adımları orada çalıştırın, sorunları orada bulun ve düzelttikten sonra aynı sırayı canlı taşımada uygulayın. Hazırlık ortamı arama motorlarına kapalı olmalıdır. Hazırlıkta bulduğunuz her sorunu ve çözümünü bir listeye yazın; canlı taşıma günü bu liste kontrol listenizin başına gelir. Böylece taşıma günü, ilk kez çözülen bir sorunla değil, daha önce çözülmüş bir sorunun tekrarıyla karşılaşma ihtimaliyle geçer.

Hazırlıkta bir adımın ne kadar sürdüğünü de not edin. Veritabanı büyükse içe aktarma ve arama-değiştirme beklediğinizden uzun sürebilir; bu süre, içerik dondurma penceresinin ne kadar olacağını belirler ve taşıma saatini trafiğin düşük olduğu bir zamana yerleştirmenize yardım eder.

Kontrol listesi

Taşımadan önce:

• Dosya ve veritabanı yedeği alındı mı
• .htaccess dosyasının kopyası saklandı mı
• Eski adreslerin yeni adreslere eşleme listesi hazır mı
• Arama-değiştirme aracının guid'i atladığı doğrulandı mı
• Hazırlık ortamı arama motorlarına kapalı mı

Taşımadan sonra:

• Kalıcı bağlantılar yeniden kaydedildi mi
• Yönlendirmeler test edildi mi
• Yeni sitemap gönderildi mi, noindex ve robots engelleri kaldırıldı mı
• Eski ve yeni site Search Console'da izleniyor mu
• Yönlendirmeler için en az bir yıllık takvim notu var mı

Taşıma gecesi için kısa liste

• Eklenti durumu yazıldı mı, dışa aktarma boş değil mi?
• Arama-değiştirmede guid sütunu dışarıda mı?
• Kalıcı bağlantılar yeniden kaydedildi mi, kural dosyası özel kuralları taşıyor mu?
• Eski adreslerden yeni adreslere sunucu taraflı kalıcı yönlendirme çalışıyor mu?
• Eski sitenin yedeği dışarıda mı?

Ajanslar için notlar

Müşteri sitelerini taşırken bu kontrol listesini teslim belgesine ekleyin ve her adımı tarihle kaydedin. Taşıma sonrası trafiğin geçici dalgalanacağını müşteriye taşıma öncesinde yazılı bildirin. Google belgesinin ifadesiyle dalgalanma beklenir. Backlink kaybını önleme yönü için site taşıma sırasında backlink değerini koruma yazısına bakın. Belgelerdeki adımlar ve eşikler değişebilir; uygulamadan önce güncel sayfalara bakın.

Dışa aktarma dosyası neden boş ya da eksik çıkar

Taşıma belgesi dışa aktarma ile taşımayı da anlatır. Dışa aktarmadan önce tüm eklentileri devre dışı bırakmanın akıllıca olduğunu söyler; çünkü bazı eklentiler dışa aktarma işlemiyle çakışıp boş bir dosya üretebilir. Aynı belge, PHP yapılandırmasının dosya yükleme sınırının dışa aktarma dosyası için çok küçük kalabileceğini de belirtir. Uygulama önerisi: dışa aktarma dosyasını almadan önce eklenti durumunu not edin, işlemden sonra dosyanın boyutuna bakın.

Çok siteli kurulum ve tablo ön eki uyarıları

Taşıma belgesi çok siteli kurulum için açık bir uyarı verir: arama-değiştirme betiği olmadan topluca arama-değiştirme yapmaya çalışmayın. Tablo ön ekini değiştiriyorsanız belge, usermeta tablosundaki ön ekli anahtarların da güncellenmesi gerektiğini söyler. Çok siteli bir taşımada belgenin ilgili bölümündeki sıralı adımları izleyin.

Yanlış anlaşılan noktalar

İlk yanlış anlama, alan adı korunduğunda taşımanın karmaşık olacağı düşüncesidir. Belgeye göre adres ve alan adı aynı kalıyorsa taşıma çok basittir ve dosyaları taşımakla yapılabilir. İkincisi, veritabanını kopyalayınca bağlantıların kendiliğinden güncelleneceği düşüncesidir; adres değişiyorsa belge sıralı adımlar ister. Üçüncüsü, yönlendirmenin sunucu dışında yazılabileceği düşüncesidir. Google yönlendirme sayfası mümkün olduğunda kalıcı sunucu taraflı yönlendirme önerir ve JavaScript yönlendirmesini yalnızca diğer yollar kullanılamıyorsa anar.

Sık Sorulan Sorular

Hosting değiştirirken arama-değiştirme gerekir mi?

Adresler değişmiyorsa taşıma belgesi dosyaları ve veritabanını kopyalamayı, veritabanı bilgisi değişirse wp-config.php'yi güncellemeyi anlatır. Arama-değiştirme alan adı ya da adres yolu değiştiğinde gündeme gelir.

Serileştirilmiş veri neden sorun çıkarır?

Belgeye göre bazı temalar ve widget'lar dizge uzunluklarını saklar. Adres değişince uzunluk değiştiği için düz bul-ve-değiştir veriyi bozabilir.

guid sütununu neden değiştirmemeliyim?

Belge hiçbir koşulda guid sütununun içeriğinin değiştirilmemesini söyler. Guid, besleme okuyucularının gönderiyi izlemek için kullandığı tanımlayıcıdır.

Yönlendirmeleri ne kadar tutmalıyım?

Google'ın taşıma belgesi yönlendirmeleri mümkün olduğunca uzun, genel olarak en az bir yıl tutmayı önerir. Belgeler değişebilir; güncel sayfaya bakın.

Taşıma Adresi Değişikliği aracı her taşımada gerekli mi?

Hayır. Belgeye göre yalnızca alan adları ya da alt alan adları arasında taşıma yaparken kullanılır; http'den https'ye geçiş, www değişikliği ve yol değişikliği için gerekli değildir.

Taşıma sonrası trafik düşerse ne yapmalıyım?

Belge sıralamada geçici dalgalanma beklenmesini söyler. Yönlendirmeleri, canonical etiketlerini ve sitemap'i kontrol edin; Search Console'daki dizin kapsamı raporuna bakın.

Sonuç

WordPress taşıması, dosya ve veritabanı aktarımıyla arama motoruna adres değişikliğini anlatmanın birleşimidir. Taşıma türünü belirleyin, iki ayrı yedek alın, serileştirilmiş veriyi bozmayan bir araçla arama-değiştirme yapın, guid sütununa dokunmayın, sunucu tarafı kalıcı yönlendirmeleri kurup test edin ve yönlendirmeleri mümkün olduğunca uzun, genel olarak en az bir yıl tutun. Sonrasında iki siteyi Search Console'da izleyin.

Taşıma tamamlandığında, geriye siteyi taze içerikle beslemek kalır.

Düzenli ve özenli içerik akışı için makale yazımı hizmetimize göz atabilirsiniz.