Site Taşıdıktan Sonra Tasarım Bozuldu mu? CSS ve Görsel Çözümü

Taşıma bitti, alan adını yeni sunucuya yönlendirdiniz ve siteyi açtınız: sayfa geliyor, yazılar okunuyor, linkler çalışıyor — ama site 1998'den kalma gibi görünüyor. Menü alt alta dizilmiş, renkler gitmiş, logonun yerinde kırık resim ikonu var. "Site taşıdım tasarım bozuldu" cümlesi, taşıma sonrası en çok aranan ifadelerden biri, çünkü bu hata en görünür olanı: site tamamen kapansa insan "sunucu gelmemiş" der ve bekler; ama açılıp çirkin görünmesi doğrudan panik yaratır.

İyi haber şu: sitenin HTML'i geliyorsa PHP çalışıyor, veritabanı bağlantısı kurulmuş ve dosyalar sunucuda demektir. Yani asıl iş bitmiş, geriye yalnızca statik dosyaların (CSS, JS, görsel, font) tarayıcıya ulaşmasını engelleyen tek bir katman kalmıştır. Bu yazıda o katmanı bulmanın 60 saniyelik teşhis yöntemini, ardından gerçek altı sebebi — veritabanında kalan mutlak URL'ler, dosya izinleri, Linux'un büyük-küçük harf duyarlılığı, karışık içerik bloğu, MIME türü ve yarım kalan yükleme — tek tek ve çözümleriyle birlikte anlatacağım. Türkçe kaynakların çoğu bu sorunu "önbelleği temizle" diye özetliyor; önbellek listenin en sonunda ve genelde suçlu değil.

Önce Teşhis: 60 Saniyede Hangi Dosyanın Gelmediğini Bulun#

Tahmin etmeyin, tarayıcıya sorun. Sorunlu sayfada F12 ile geliştirici araçlarını açın, Console ve Network sekmelerine bakıp sayfayı Ctrl+F5 ile yenileyin. Network sekmesinde kırmızı satırlar, Console'da kırmızı yazılar çıkacaktır. Gördüğünüz metin doğrudan sebebi söyler:

Bir ikinci hızlı test daha var ve çok işe yarar: kırık gelen CSS dosyasının adresine tarayıcıdan doğrudan gidin (örneğin https://siteniz.com/wp-content/themes/tema/style.css). Ekrana CSS kodu geliyorsa dosya sunucuda ve erişilebilir demektir — sorun sayfanın onu yanlış adresle çağırmasındadır. "Not Found" geliyorsa dosya yolu yanlış ya da dosya yok. "Forbidden" geliyorsa dosya var ama izinler engelliyor. Bu üç cevap, aşağıdaki altı sebebi zaten ikiye üçe indirir.

Sebep 1: Veritabanında Kalan Eski Mutlak URL'ler#

En yaygın sebep budur ve tam olarak şu şekilde davranır: sayfa açılır, metinler gelir, hiçbir görsel gelmez. WordPress, OpenCart, PrestaShop gibi sistemler tema ve eklenti dosyalarını mutlak adresle (https://eskisite.com/wp-content/...) üretir; bu adresin kökü wp_options tablosundaki siteurl ve home kayıtlarından gelir. Alan adı aynı kalıp yalnızca sunucu değiştiyse bu sorun çıkmaz. Ama geçici test alan adında çalıştıysanız, www durumu değiştiyse ya da http'den https'e geçtiyseniz, veritabanı hâlâ eski adresi söyler ve tarayıcı olmayan bir sunucudan CSS istemeye devam eder.

Hızlı doğrulama için sayfanın kaynağına bakın (Ctrl+U) ve <link rel="stylesheet" satırındaki adrese dikkat edin. Orada eski alan adı ya da http:// görüyorsanız teşhis kesindir. WordPress'te acil çözüm wp-config.php içine geçici olarak iki satır eklemektir:

define('WP_HOME','https://yenisite.com');
define('WP_SITEURL','https://yenisite.com');

Bu satırlar veritabanını değiştirmez, yalnızca üzerine yazar; tema ve menü hemen düzelir. Ancak yazı içeriklerine, sayfa kurucu verilerine ve galeri kayıtlarına gömülü eski adresler yerinde kalır — bu yüzden geçici çözümdür. Kalıcı çözüm veritabanındaki tüm eski adresleri serileştirilmiş veriyi bozmadan değiştirmektir; bunun doğru yöntemleri site taşıma sonrası veritabanındaki eski URL'leri değiştirme yazısında adım adım anlatılıyor. Kısa yolu deneyip UPDATE ... REPLACE çalıştırmayın: Elementor, ACF ve Divi verisi serileştirilmiş saklandığı için bu komut siteyi tamamen çökertir.

Sebep 2: Dosya ve Dizin İzinleri Yanlış Geldi#

Konsolda 403 görüyorsanız sebep neredeyse kesin olarak izinlerdir. Bu, arşivi Windows'ta açıp FTP ile yükleyen veya farklı bir panelden gelen yedeği elle çıkaran herkesin başına gelir: Windows dosya sisteminde POSIX izni diye bir şey yoktur, aktarım sırasında izinler 000, 600 ya da 640 olarak yeniden atanır. wp-content/uploads klasörü 000 olduğunda tüm görseller 403 döner ve site tam olarak "kırık resim tarlası" hâline gelir.

SSH erişiminiz varsa doğru izinleri tek seferde şöyle kurarsınız:

cd ~/public_html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

Dizinler 755, dosyalar 644, hassas yapılandırma dosyası 600. Klasörlerde çalıştırma (x) bitinin bulunması şart: bir dizinde x yoksa web sunucusu içine giremez ve içindeki her dosya 403 döner — dosyanın kendi izni doğru olsa bile. cPanel Dosya Yöneticisi'nde de aynı işi yapabilirsiniz: klasörü seçin, Permissions düğmesine basın, Recurse into subdirectories kutusunu işaretleyip yalnızca dizinlere 755 uygulayın, sonra aynısını dosyalar için 644 ile tekrarlayın.

İzinler doğru göründüğü hâlde 403 devam ediyorsa sahiplik (ownership) bakılmalıdır. Dosyalar root:root ya da başka bir kullanıcıya aitse PHP-FPM onları okuyamaz:

ls -l public_html | head
chown -R kullaniciadi:kullaniciadi ~/public_html

Sahiplik komutu root yetkisi ister; paylaşımlı hostingte bu işlemi destek ekibi yapar. Konunun tamamı için linux dosya izinleri ve WordPress'e özel değerler için wordpress dosya izinleri yazılarına bakabilirsiniz.

Sebep 3: Linux Büyük-Küçük Harfe Duyarlıdır — "Logo.png" ile "logo.png" Aynı Dosya Değildir#

Bu, yerelde Windows veya macOS kullanıp Linux sunucuya taşıyan herkesin er geç yakalandığı, teşhisi en can sıkıcı sorundur: dosya FTP'de gözünüzün önünde durur, adresi kopyalarsınız, tarayıcı 404 der. Sebep tek harftir. Windows'ta Logo.PNG ile logo.png aynı dosyadır; ext4 veya XFS üzerinde çalışan Linux sunucuda ise iki ayrı dosyadır ve tema logo.png istiyorsa Logo.PNG ona cevap vermez.

Aynı tuzak klasör ve tema adlarında da vardır. wp-content/themes/MyTheme klasörünü barındıran bir yedek, veritabanında mytheme yazan bir siteye yüklendiğinde tema hiç yüklenmez ve WordPress varsayılan temaya düşer — kullanıcı bunu "tasarım tamamen gitti" diye tarif eder.

Sunucuda büyük harf içeren dosyaları tek komutla listeleyip görebilirsiniz:

find wp-content/uploads -name "*[A-Z]*" | head -50

Toplu düzeltmede acele etmeyin: dosya adını küçük harfe çevirirseniz veritabanındaki kayıt hâlâ büyük harfli adı gösterecektir. Doğru sıra şudur — önce dosyaları küçük harfe çevirin, ardından veritabanında aynı değişikliği yapın. Küçük ölçekte tek tek yeniden adlandırmak en güvenlisidir; büyük bir arşivde rename aracı iş görür ama mutlaka önce yedek alın:

rename 's/(.*)\/([^\/]*)/$1\/\L$2/' wp-content/uploads/2026/*/*

En sağlıklısı bu sorunu kaynağında bitirmektir: geliştirme yaparken tüm dosya adlarını küçük harf, boşluksuz ve Türkçe karaktersiz tutun. ürün-görseli.jpg gibi bir ad hem büyük-küçük harf hem de URL kodlaması sorunu üretir.

Sebep 4: Karışık İçerik (Mixed Content) Bloğu#

Konsolda Mixed Content uyarısı görüyorsanız sebep şudur: sayfanın kendisi HTTPS ile geliyor, ama içindeki CSS, JS veya görseller http:// ile çağrılıyor ve tarayıcı bunları güvenlik gereği indirmeyi reddediyor. Bu, taşımayla birlikte SSL'e geçen sitelerin klasik hâlidir — dosyalar sunucuda tamdır, izinler doğrudur, sadece tarayıcı onları getirmez.

Ayırt etmesi kolaydır: kırık gelen CSS dosyasının adresini kopyalayıp https:// ile açın, gayet güzel gelir. Yani dosya iyi, çağrı yanlış. Kalıcı çözüm veritabanındaki http://siteniz.com geçen tüm değerleri https://siteniz.com yapmaktır. Geçici olarak sunucu tarafında da yükseltebilirsiniz; .htaccess içine eklenen şu başlık, tarayıcıya "içerideki http isteklerini https'e çevirerek dene" der:

Header always set Content-Security-Policy "upgrade-insecure-requests"

Bu yalnızca bir yamadır; kaynak verisi düzeltilmediği sürece sayfa kaynağı kirli kalır ve bazı eklentiler yine http üretir. Konunun tamamı ve tarayıcı bazlı davranış farkları için mixed content hatası yazısına bakın. Ayrıca sertifikanın gerçekten yeni sunucuda kurulu olduğundan emin olun; taşıma sonrası sık görülen bir varyant, alan adının yeni sunucuya geçmesi ama sertifikanın eski sunucuda kalmasıdır.

Sebep 5: MIME Türü ve Kaybolan .htaccess Dosyası#

Konsolda Refused to apply style from ... because its MIME type ('text/plain') is not a supported stylesheet MIME type yazıyorsa dosya sunucudan 200 ile geliyor ama tarayıcı onu stil olarak kabul etmiyor demektir. Bu, sunucunun .css uzantısını tanımadığı ya da bir yönlendirme kuralının CSS isteğini index.php'ye çevirdiği durumlarda olur.

Buradaki en sık gerçek sebep, .htaccess dosyasının taşınmamış olmasıdır. FTP istemcileri nokta ile başlayan dosyaları varsayılan olarak gizler; FileZilla'da Sunucu → Gizli dosyaları göstermeye zorla seçeneği kapalıysa .htaccess, .env ve .user.ini gibi kritik dosyalar taşınmadan atlanır. WordPress'te bu, güzel bağlantıların (permalink) çalışmaması ve bazı isteklerin yanlış işlenmesi olarak görünür. Çözüm basittir: WordPress panelinde Ayarlar → Kalıcı Bağlantılar ekranına girip hiçbir şey değiştirmeden Değişiklikleri Kaydet deyin; WordPress .htaccess'i yeniden yazar.

MIME türü gerçekten eksikse Apache tarafında elle tanımlayabilirsiniz:

AddType text/css .css
AddType application/javascript .js
AddType font/woff2 .woff2
AddType image/svg+xml .svg

woff2 ve svg satırları özellikle önemlidir: eski yapılandırmalarda tanımlı olmadıkları için taşıma sonrası "ikonlar kutucuk olarak geliyor" şikâyeti üretirler. Ayrıca .htaccess içinde eski sunucuya özgü php_value satırları varsa, LiteSpeed veya PHP-FPM kullanan yeni sunucuda bunlar 500 hatası verebilir — o durumda dosyayı geçici olarak htaccess.eski diye yeniden adlandırıp siteyi test edin.

Sebep 6: Dosyalar Eksik — Yükleme Sessizce Yarım Kalmış#

FTP ile binlerce küçük dosya yüklerken bağlantı düşer, birkaç yüz dosya aktarılmaz ve istemci bunu bir uyarı satırında geçiştirir. Site açılır, çünkü PHP dosyaları genelde ilk sıralarda aktarılmıştır; ama wp-content/uploads içindeki son klasörler veya tema alt klasörleri eksik kalır.

Bunu tahminle değil sayarak doğrulayın. Eski sunucuda ve yeni sunucuda aynı komutu çalıştırıp sonucu karşılaştırın:

find public_html -type f | wc -l
du -sh public_html

İki sayı arasında kayda değer bir fark varsa aktarım eksiktir. Bu noktada FTP ile tekrar denemek yerine yöntemi değiştirin: dosyaları eski sunucuda tek bir arşive alıp aktarmak hem çok daha hızlı hem de bütünlük açısından güvenlidir.

tar -czf site-yedek.tar.gz public_html

Arşivi yeni sunucuya taşıyıp orada açtığınızda hem dosya sayısı hem izinler büyük ölçüde korunur. SSH erişiminiz yoksa cPanel Dosya Yöneticisi'nin Compress ve Extract işlevleri aynı işi tarayıcıdan yapar. Sunucular arası doğrudan kopyalama seçeneğiniz varsa rsync en sağlamıdır, çünkü yarım kalan aktarımı kaldığı yerden sürdürür; ayrıntılar için rsync ile yedekleme yazısına bakabilirsiniz.

Önbellek Gerçekten Suçluysa Nasıl Anlaşılır#

Önbellek listenin en sonunda, çünkü çoğu vakada suçlu değil. Suçlu olup olmadığını tek testle anlarsınız: siteyi gizli sekmede ve mümkünse mobil veriyle açın. Orada düzgün görünüyorsa sorun tarayıcı önbelleğidir ve zaten kendiliğinden geçecektir. Gizli sekmede de bozuksa önbelleği suçlamayı bırakın.

Yine de taşıma sonrası temizlenmesi gereken dört ayrı önbellek katmanı vardır ve sırayla ele alınmalıdır:

1. Tarayıcı önbelleği — Ctrl+Shift+R ile sert yenileme.
2. Eklenti/sayfa önbelleği — LiteSpeed Cache, WP Rocket, W3 Total Cache gibi araçların birleştirilmiş (minify) CSS dosyaları eski adresleri gömmüş olabilir. Bunlarda yalnızca "önbelleği temizle" yetmez; birleştirilmiş CSS/JS dosyalarını da temizleyin.
3. Nesne önbelleği ve OPcache — Redis veya Memcached kullanan bir kurulumda eski siteurl değeri bellekte kalabilir. WP-CLI ile wp cache flush çalıştırın.
4. CDN önbelleği — Cloudflare kullanıyorsanız panelden Purge Everything yapın ve taşıma günü Development Mode'u birkaç saat açık bırakın.

Bu dört katmanı temizlediğiniz hâlde sorun sürüyorsa mesele önbellek değil, yukarıdaki altı sebepten biridir. Değişikliklerin neden ekrana yansımadığı konusunun tamamı yaptığım değişiklik sitede görünmüyor yazısında ele alınıyor.

Sırayla Uygulanacak Kontrol Listesi#

Panik hâlinde rastgele müdahale etmek, hatanın üzerine ikinci bir hata koymak demektir. Sıra şudur:

1. F12 → Console ve Network'ü açın, hatanın metnini okuyun. Sebebi metin söyler.
2. Kırık dosyanın adresini tarayıcıda doğrudan açın: 404 mü, 403 mü, düzgün mü?
3. Sayfa kaynağında <link rel="stylesheet"> satırındaki alan adına ve protokole bakın.
4. Eski alan adı görüyorsanız önce wp-config.php ile geçici düzeltin, sonra veritabanını kalıcı olarak güncelleyin.
5. 403 görüyorsanız dizin 755 / dosya 644 izinlerini ve sahipliği kontrol edin.
6. 404 ama dosya duruyor görüyorsanız büyük-küçük harfe bakın.
7. .htaccess var mı diye bakın; yoksa kalıcı bağlantıları yeniden kaydedin.
8. Dosya sayısını iki sunucuda karşılaştırın.
9. En son önbellekleri temizleyin ve gizli sekmede doğrulayın.
10. Her müdahaleden sonra tek bir sayfayı test edin; iki değişikliği aynı anda yapmayın.

Taşıma sırasında DNS henüz geçmemişken siteyi yeni sunucuda test etmek isterseniz, bilgisayarınızın hosts dosyasını kullanarak bunu güvenle yapabilirsiniz; yöntem hosts dosyası ile site test etme yazısında anlatılıyor. Bu, tasarım sorunlarını ziyaretçiler görmeden yakalamanın en pratik yoludur.

Sıkça Sorulan Sorular#

Site taşıdıktan sonra tasarım bozulması kalıcı bir hasar mı#

Hayır, neredeyse hiçbir zaman kalıcı değildir. Sitenin HTML'i geliyorsa dosyalar sunucuda ve veritabanı bağlantısı kuruludur; bozulan yalnızca statik dosyaların adreslenmesi veya erişilebilirliğidir. Bu, veri kaybı değil yapılandırma sorunudur. Doğru sebebi bulduğunuzda düzeltme çoğu zaman birkaç dakika sürer, tasarımı yeniden yapmanız gerekmez.

Görseller neden kırık geliyor ama yazılar duruyor#

Yazılar veritabanından gelir, görseller ise dosya sisteminden HTTP isteğiyle çekilir. Veritabanı bağlantısı kurulduğu için metin sorunsuz basılır; ancak görsel isteği yanlış alan adına gidiyorsa, dosyanın izni engelliyorsa ya da dosya adında büyük-küçük harf farkı varsa tarayıcı görseli alamaz. Bu yüzden "yazı var, resim yok" tablosu neredeyse her zaman URL, izin veya dosya adı sorununu işaret eder.

wp-config.php içine WP_HOME yazmak kalıcı çözüm olur mu#

Hayır, yalnızca geçici bir yamadır. Bu tanımlar veritabanındaki siteurl ve home değerlerinin üzerine yazar, böylece tema ve menü hemen düzelir; ancak yazı içeriklerine, galeri kayıtlarına ve sayfa kurucu verilerine gömülü eski adresler yerinde kalır. Siteyi tam olarak düzeltmek için veritabanındaki tüm eski adresleri serileştirilmiş veriyi bozmayan bir yöntemle değiştirmeniz gerekir.

Dosya izinlerini 777 yaparsam sorun çözülür mü#

Çözülmüş gibi görünür ama bu ciddi bir güvenlik hatasıdır ve pek çok sunucuda tam tersi sonuç verir. 777 izinli dosya ve dizinleri suEXEC veya PHP-FPM güvenlik denetimi çoğu zaman doğrudan reddeder, yani 403 hatası geçmez hatta yayılır. Doğru değerler dizinler için 755, dosyalar için 644'tür; yapılandırma dosyaları 600 olmalıdır.

Taşımadan sonra ne kadar bekleyip sonuç almalıyım#

Dosya ve veritabanı kaynaklı bozulmalar için beklemenin faydası yoktur, çünkü bunlar zamanla düzelmez. Beklemek yalnızca DNS yayılımı için anlamlıdır ve o da tipik olarak birkaç saat içinde tamamlanır. Site bazı cihazlarda düzgün bazılarında bozuk görünüyorsa hâlâ eski sunucuya düşen ziyaretçiler olabilir; bu durumda gizli sekme testi ve hosts dosyası yöntemiyle hangi sunucuya bağlandığınızı netleştirin.

CSS dosyası açıldığında geliyorsa neden sayfada uygulanmıyor#

Bu genellikle MIME türü sorunudur: sunucu dosyayı text/plain gibi yanlış bir türle gönderiyorsa tarayıcı, katı MIME denetimi nedeniyle onu stil olarak uygulamayı reddeder ve konsola bir uyarı düşer. Sunucuda AddType text/css .css tanımını eklemek ya da yanlış yönlendirme yapan .htaccess kuralını kaldırmak sorunu çözer. Aynı belirtiyi, CSS isteğini index.php'ye yönlendiren hatalı bir yeniden yazma kuralı da üretebilir.

Fontlar ve ikonlar kutucuk olarak geliyorsa sebep nedir#

Çoğunlukla woff2 ve svg MIME türlerinin sunucuda tanımlı olmaması ya da font dosyalarının farklı bir alan adından çağrılması nedeniyle CORS bloğuna takılmasıdır. Konsolda font isteğinin yanında bir CORS uyarısı görüyorsanız, fontları sitenin kendi alan adından sunmak en hızlı çözümdür. Dosya adında büyük harf bulunması da aynı belirtiyi verir, bu yüzden 404 dönen font adreslerini harf harf karşılaştırın.

Bozulmayı önceden engellemenin bir yolu var mı#

Evet, en etkilisi taşıma sırasında alan adını hiç değiştirmemek ve testi hosts dosyası üzerinden yapmaktır; böylece veritabanında geçici bir adres hiç oluşmaz. İkinci olarak dosyaları FTP ile tek tek değil, arşivleyerek taşımak izin ve eksik dosya sorunlarının çoğunu baştan keser. Üçüncüsü, geliştirme aşamasında tüm dosya adlarını küçük harf ve Türkçe karaktersiz tutmak, Linux sunucuda ortaya çıkan büyük-küçük harf hatalarını tamamen ortadan kaldırır.

Kapanış#

Taşıma sonrası bozulan tasarım, korkutucu görünmesine rağmen dar bir sorun kümesidir: eski alan adı, dosya izni, büyük-küçük harf, karışık içerik, MIME türü ve eksik dosya. Bu altısının hangisi olduğunu tarayıcı konsolu size ilk 60 saniyede söyler; asıl hata, konsola bakmadan önbellek temizleyip eklenti kapatarak vakit kaybetmektir. Sıralı ilerleyin, her müdahaleden sonra tek bir sayfayı test edin ve veritabanına dokunmadan önce mutlaka yedek alın.

Taşımayı kendiniz yapmak yerine devretmek isterseniz site taşıma hizmeti dosya, veritabanı, e-posta ve DNS tarafını uçtan uca üstlenir; taşınacak site WordPress ise sunucu tarafı önbellek ve PHP ayarları hazır gelen WordPress hosting paketleri bu yazıdaki izin ve MIME sorunlarının çoğunu baştan ortadan kaldırır. Karışık içerik uyarısı alıyorsanız sertifikanın yeni sunucuda doğru kurulduğundan emin olun; SSL tarafındaki kurulum ve otomatik yenileme adımları oradan takip edilebilir. Taşıma öncesi elinizde sağlam bir kopya bulunması için yedekleme çözümlerini de aynı gün devreye almanızı öneririm — çünkü bu yazıdaki adımların hepsi, geri dönebileceğiniz bir yedek varken çok daha rahat uygulanır.