Site taşıma sonrası hatalar, WordPress veya özel yazılım projelerinde en stresli teknik SEO problemlerinden biridir. Site yeni sunucuya taşınır, dosyalar aktarılır, veritabanı içe alınır; fakat canlıya geçtikten sonra 404 sayfaları, SSL uyarıları, karışık içerik hataları, bozuk görseller veya yavaş açılan sayfalar ortaya çıkabilir.
Bu rehberde site taşıma sonrası hataları 9 ana başlıkta ele alıyorum. Amacımız paniğe kapılmadan, önce erişim ve DNS’i doğrulamak, sonra WordPress, veritabanı, yönlendirme ve SEO kontrollerini sırayla tamamlamaktır.
- Site Taşıma Sonrası Hatalar Neden Oluşur?
- Site Taşıma Kontrol Listesi: İlk 9 Adım
- DNS ve SSL Hatalarını Kontrol Edin
- WordPress 404 ve Kalıcı Bağlantı Sorunları
- Veritabanı Bağlantısı ve URL Değişimi
- Bozuk Görsel ve Karışık İçerik Hataları
- Cache, CDN ve PHP Sürümü Kontrolleri
- SEO ve Search Console Kontrolleri
- Canlıya Alma Öncesi Test Planı
- Geri Dönüş Planı Hazırlayın
- Taşıma Sonrası 7 Günlük İzleme
- SSS: Site Taşıma Sonrası Hatalar
- Sonuç: Site Taşıma Sonrası Hataları Sırayla Çözün
Site Taşıma Sonrası Hatalar Neden Oluşur?

Taşıma işlemi sadece dosya kopyalamaktan ibaret değildir. DNS kayıtları, PHP sürümü, veritabanı bağlantısı, dosya izinleri, SSL sertifikası, cache, CDN ve kalıcı bağlantılar aynı anda değişebilir. Bu nedenle tek bir küçük eksik, sitenin tamamında büyük bir sorun gibi görünebilir.
Özellikle WordPress sitelerinde eski alan adı izleri, yanlış siteurl değeri, bozuk .htaccess dosyası ve cache katmanı en sık görülen problemlerdir. Laravel veya özel PHP projelerinde ise .env, dosya izinleri ve veritabanı bağlantı bilgileri daha kritik hale gelir.
Site Taşıma Kontrol Listesi: İlk 9 Adım
Aşağıdaki tabloyu taşıma sonrasında ilk kontrol listesi olarak kullanabilirsiniz. Sorunu rastgele çözmeye çalışmak yerine bu sırayı takip etmek daha güvenlidir.
| # | Kontrol | Belirti | Çözüm |
|---|---|---|---|
| 1 | DNS | Site eski sunucuya gidiyor | A ve CNAME kayıtlarını kontrol edin |
| 2 | SSL | Güvenli değil uyarısı | SSL sertifikasını yenileyin |
| 3 | Veritabanı | Bağlantı hatası | DB adı, kullanıcı ve şifreyi doğrulayın |
| 4 | Kalıcı bağlantı | İç sayfalar 404 veriyor | Permalink ayarını yeniden kaydedin |
| 5 | Dosya izinleri | Görsel yükleme hatası | Klasör izinlerini kontrol edin |
| 6 | Cache/CDN | Eski içerik görünüyor | Sunucu, eklenti ve CDN cache temizleyin |
| 7 | URL değişimi | Bozuk link ve görsel | Search replace işlemi yapın |
| 8 | Yönlendirme | Trafik eski URL’de kalıyor | 301 yönlendirmeleri test edin |
| 9 | SEO indeks | Google sayfaları düşürüyor | Search Console ile tarama kontrolü yapın |
DNS ve SSL Hatalarını Kontrol Edin

Site taşıma sonrası ilk kontrol DNS olmalıdır. Alan adınız yeni sunucu IP’sine yönlenmiyorsa, WordPress tarafında yaptığınız hiçbir düzeltme sonucu değiştirmez. Bu nedenle önce A kaydı, CNAME kaydı ve nameserver bilgilerini kontrol edin.
DNS yayılımı bazı durumlarda birkaç saat sürebilir. Ancak 24 saati geçen kararsızlık varsa DNS tarafında yanlış kayıt olma ihtimali yüksektir. Farklı cihazlardan, mobil internetten ve DNS kontrol araçlarından test yapın.
SSL tarafında ise en sık hata, sertifikanın yeni sunucuda aktif olmamasıdır. Tarayıcı “güvenli değil” uyarısı veriyorsa Let’s Encrypt veya hosting panelindeki SSL bölümünden sertifikayı yeniden kurun. Ardından HTTP’den HTTPS’ye 301 yönlendirme olduğundan emin olun.
WordPress 404 ve Kalıcı Bağlantı Sorunları
Site ana sayfası açılıyor ama iç sayfalar 404 veriyorsa sorun çoğu zaman kalıcı bağlantı kurallarındadır. WordPress panelinde Ayarlar > Kalıcı bağlantılar ekranına gidin ve hiçbir değişiklik yapmadan “Değişiklikleri kaydet” butonuna basın. Bu işlem rewrite kurallarını yeniler.
Apache sunucularda .htaccess dosyası eksik veya bozuk olabilir. Nginx sunucularda ise WordPress rewrite kuralları server block içinde tanımlanmalıdır. Daha detaylı kontrol için WordPress 404 hatası çözüm rehberi yazısına bakabilirsiniz.
- Ana sayfa açılıyor mu?
- Kategori ve etiket sayfaları çalışıyor mu?
- Yazı detay sayfaları 200 OK dönüyor mu?
- Eski URL’lerden yeni URL’lere 301 yönlendirme var mı?
Veritabanı Bağlantısı ve URL Değişimi
WordPress’te “Veritabanı bağlantısı kurulurken hata oluştu” mesajı görüyorsanız wp-config.php içindeki veritabanı adı, kullanıcı adı, parola ve sunucu bilgisi yanlış olabilir. Bazı hostinglerde veritabanı sunucusu localhost değil, farklı bir host adresidir.
Alan adı değiştiyse veritabanında eski URL’ler kalabilir. Bu durumda görseller, CSS dosyaları veya dahili bağlantılar eski alan adına gider. Güvenli bir search replace işlemi yapmak gerekir. Bunu yapmadan önce mutlaka veritabanı yedeği alın.
Eski URL: https://eskisite.com
Yeni URL: https://yenisite.com
Kontrol: wp_options, post_content, postmeta, guid
Laravel projelerinde benzer kontrol .env dosyasında yapılır. APP_URL, DB_HOST, DB_DATABASE, DB_USERNAME ve DB_PASSWORD değerleri yeni sunucuya göre güncellenmelidir.
Bozuk Görsel ve Karışık İçerik Hataları
Taşıma sonrası görseller görünmüyorsa önce dosyaların gerçekten yeni sunucuya taşınıp taşınmadığını kontrol edin. WordPress için wp-content/uploads klasörü eksikse medya kütüphanesi boş görünür veya görseller 404 döner.
Karışık içerik hatası ise HTTPS sayfada HTTP kaynakların çağrılmasıdır. Tarayıcı geliştirici konsolunda “mixed content” uyarısı görürsünüz. Bu sorun genellikle eski URL’lerin veritabanında kalmasından kaynaklanır.
uploadsklasörü eksiksiz mi?- Görsel URL’leri HTTPS ile mi başlıyor?
- CDN eski alan adına mı bağlı?
- Lazy load veya cache eklentisi eski dosya mı çağırıyor?
Cache, CDN ve PHP Sürümü Kontrolleri
Yeni sunucuya geçtikten sonra eski cache katmanları yanıltıcı sonuç verebilir. WordPress cache eklentisi, LiteSpeed Cache, Cloudflare, tarayıcı cache’i ve sunucu cache’i ayrı ayrı temizlenmelidir. Aksi halde siz yeni dosyaları yüklemiş olsanız bile ziyaretçi eski çıktıyı görebilir.
PHP sürümü de önemlidir. Eski sunucuda çalışan bir eklenti, yeni sunucuda farklı PHP sürümünde hata verebilir. Beyaz sayfa, fatal error veya admin paneline girememe gibi belirtiler varsa debug log açıp hatanın hangi eklenti veya temadan geldiğini kontrol edin. Bu konuda WordPress eklenti çakışması tespiti rehberi yardımcı olur.
SEO ve Search Console Kontrolleri

Site taşıma sonrası teknik olarak her şey çalışsa bile SEO tarafı ayrıca kontrol edilmelidir. Robots.txt dosyası, sitemap, canonical etiketleri, 301 yönlendirmeleri ve Search Console mülk ayarları gözden geçirilmelidir.
Google’ın resmi URL değişiklikli site taşıma dokümanı, büyük taşımalarda izlenmesi gereken temel adımları açıklar. Özellikle alan adı değişimi yaptıysanız Search Console’daki adres değişikliği aracını kullanmanız gerekir.
Search Console’da şu raporları kontrol edin:
- Sayfa dizine ekleme raporu
- Sitemap gönderim durumu
- 404 ve soft 404 hataları
- Yönlendirme hataları
- Tarama istatistikleri
Canlıya Alma Öncesi Test Planı
Site taşıma işlemini mümkünse doğrudan canlı sitede test etmeyin. Yeni sunucuda geçici URL, hosts dosyası veya staging alanı üzerinden ön kontrol yapmak daha güvenlidir. Böylece DNS’i değiştirmeden önce tema, eklenti, PHP sürümü, veritabanı bağlantısı ve görsel yolları test edilebilir.
Basit bir test planı şu adımlardan oluşabilir:
- Ana sayfa, kategori, yazı detayı ve iletişim sayfasını açın.
- Admin paneline giriş yapıp yeni bir taslak kaydedin.
- Medya kütüphanesine küçük bir görsel yükleyin.
- İletişim formu veya sipariş formu varsa test gönderimi yapın.
- PHP hata günlüğünde yeni uyarı oluşup oluşmadığını kontrol edin.
- Mobil görünümde menü, tablo ve görselleri kontrol edin.
Bu testlerden biri bile başarısızsa DNS değişikliğini ertelemek daha doğrudur. Çünkü canlıya geçtikten sonra kullanıcılar, Googlebot ve reklam botları aynı hataları görmeye başlar. Özellikle e-ticaret sitelerinde ödeme, sepet ve sipariş e-postası test edilmeden taşıma tamamlanmış sayılmamalıdır.
Geri Dönüş Planı Hazırlayın
Profesyonel bir site taşıma sürecinde sadece geçiş planı değil, geri dönüş planı da bulunmalıdır. Yeni sunucuda beklenmeyen hata çıkarsa eski sunucuya nasıl döneceğinizi önceden bilmelisiniz. Bu, panik anında yanlış müdahale yapmanızı engeller.
Geri dönüş planında şu bilgiler hazır olmalıdır:
- Eski sunucu IP adresi
- Son sağlam dosya yedeği
- Son sağlam veritabanı yedeği
- DNS TTL süresi
- Eski ve yeni nameserver bilgileri
- Taşıma öncesi çalışan sitemap ve robots.txt çıktısı
DNS TTL değerini taşıma öncesinde düşürmek de iyi bir pratiktir. Örneğin TTL değeri 24 saat ise hatalı geçişte geri dönüş yavaş olur. Taşıma öncesi TTL değerini 300 saniye gibi düşük bir seviyeye almak, olası geri dönüşleri daha yönetilebilir hale getirir.
Taşıma Sonrası 7 Günlük İzleme
Site taşıma sonrası kontrol sadece ilk gün bitmez. İlk hafta boyunca trafik, hata logları, Search Console uyarıları ve sunucu kaynak kullanımı izlenmelidir. Çünkü bazı hatalar ilk anda değil, Google yeniden tarama yaptıkça veya kullanıcılar farklı sayfalara girdikçe ortaya çıkar.
İlk 7 gün için pratik takip planı şöyledir:
- Her gün Search Console kapsama ve 404 raporlarını kontrol edin.
- Sunucu error log dosyasını inceleyin.
- En çok trafik alan 20 URL’yi manuel açın.
- Analytics tarafında ani trafik düşüşü olup olmadığını izleyin.
- Form, yorum, üyelik ve ödeme gibi etkileşimleri test edin.
- CDN ve cache istatistiklerinde anormal durum var mı bakın.
Bu izleme süreci sayesinde küçük hatalar büyümeden yakalanır. Özellikle WordPress sitelerinde taşımadan birkaç gün sonra ortaya çıkan eklenti lisans hataları, cron problemleri veya otomatik yedekleme sorunları bu şekilde fark edilir.
Son olarak, taşıma sürecinde yaptığınız her değişikliği kısa notlarla kaydedin. Hangi DNS kaydının değiştiği, hangi cache’in temizlendiği, hangi eklentinin kapatıldığı ve hangi URL’nin yönlendirildiği bilinirse sorun çıktığında geri izleme çok daha kolay olur. Bu kayıtlar sonraki taşımalarda da hazır kontrol listesi görevi görür. Ayrıca ekip içinde kimin hangi adımı yaptığı netleşir ve gereksiz tekrarların önüne geçilir. Böylece taşıma süreci ölçülebilir, geri alınabilir ve daha güvenli hale gelir.
SSS: Site Taşıma Sonrası Hatalar
Site taşıma sonrası ilk neyi kontrol etmeliyim?
İlk olarak DNS kaydının yeni sunucuya yönlendiğini ve SSL sertifikasının aktif olduğunu kontrol edin. Bu iki temel doğru değilse diğer kontroller yanıltıcı olur.
Taşıma sonrası iç sayfalar neden 404 verir?
Genellikle kalıcı bağlantı kuralları bozulduğu, .htaccess eksik olduğu veya Nginx rewrite ayarları yapılmadığı için iç sayfalar 404 döner.
Görseller taşımadan sonra neden görünmez?
Uploads klasörü eksik taşınmış olabilir, dosya izinleri hatalı olabilir veya veritabanında eski alan adıyla kayıtlı görsel URL’leri kalmış olabilir.
Site taşıma SEO kaybına neden olur mu?
Doğru 301 yönlendirme, sitemap, robots.txt ve Search Console kontrolleri yapılmazsa geçici veya kalıcı trafik kaybı olabilir. Planlı taşımalarda risk azalır.
Taşıma sonrası eski cache’i temizlemek gerekir mi?
Evet. Sunucu cache’i, CDN cache’i, WordPress cache eklentisi ve tarayıcı cache’i temizlenmelidir. Aksi halde eski sayfa çıktıları görüntülenebilir.
Sonuç: Site Taşıma Sonrası Hataları Sırayla Çözün
Site taşıma sonrası hatalar genellikle tek bir büyük problemden değil, birkaç küçük eksikten oluşur. Bu nedenle rastgele müdahale etmek yerine DNS, SSL, veritabanı, URL, cache ve SEO kontrollerini sırayla yapmak gerekir.
Özetle önce sitenin doğru sunucuya gittiğini doğrulayın. Sonra SSL, 404, veritabanı, görsel ve cache sorunlarını temizleyin. En son Search Console üzerinden indeks ve yönlendirme hatalarını izleyin. Eğer taşıma sonrası hangi adımda takıldığınızı yorumlara yazarsanız, birlikte netleştirebiliriz.
Bir Cevap Yaz
E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir.