WordPress'te Resimler Görünmüyor: Kırık Görselleri Geri Getirme

WordPress'te resimler görünmüyor diye panik yapmadan önce şunu bilin: bu ifade tek bir arıza değil, en az üç farklı arızanın ortak belirtisidir. Sitede kırık görsel simgesi çıkması, dosyanın gerçekten silindiği anlamına gelmez. Çoğu vakada dosyalar sunucuda sapasağlam durur; WordPress onlara yanlış adresten ulaşmaya çalışır ya da tarayıcı isteği engeller. Bu yüzden "eklenti önbelleğini temizleyin" tavsiyesi vakaların büyük bölümünde hiçbir işe yaramaz — çünkü sorun önbellekte değildir.

Bu yazıda kırık görselleri tahminle değil, teşhisle çözeceğiz. Önce tarayıcının ağ sekmesinden görselin döndürdüğü HTTP kodunu okuyup arızayı üç kutudan birine koyacağız: dosya sunucuda yok (404), dosya var ama yol yanlış (veritabanında eski alan adı), dosya ve yol doğru ama tarayıcı engelliyor (karma içerik / izin / hotlink). Ardından her kutunun kendi çözümünü — SQL sorgusu, wp-cli komutu, rsync ile eksik uploads aktarımı, chown ile sahiplik düzeltme — sırayla uygulayacağız. Sonunda taşıma sonrası tekrar yaşamamak için bir kontrol listesi bırakıyorum.

Önce Teşhis: Kırık Bir Görsel Size Ne Söylüyor#

Kırık görselin nedenini öğrenmenin en hızlı yolu, o görselin döndürdüğü HTTP durum kodunu okumaktır. Sitenizi tarayıcıda açın, kırık görselin üzerinde sağ tık yapıp İncele'yi seçin, ardından geliştirici araçlarında Ağ (Network) sekmesine geçip sayfayı yenileyin. Listede kırmızı satırlar göreceksiniz; o satırın "Status" sütunundaki üç haneli sayı, arızanın hangi kutuya girdiğini söyler.

Terminalden bakmayı tercih ediyorsanız aynı bilgiyi tek komutla alırsınız:

curl -I https://ornek.com/wp-content/uploads/2026/03/urun-fotografi.jpg

Dönen ilk satır HTTP/2 200 ise dosya oradadır ve sunucu onu veriyordur — sorun tarayıcı tarafındadır. 404 ise dosya o yolda yoktur. 403 ise dosya vardır ama sunucu erişimi reddetmektedir.

Bir başka hızlı ipucu: medya kütüphanesine girin (/wp-admin/upload.php). Orada da gri kutular görüyorsanız arıza dosya/yol düzeyindedir. Medya kütüphanesinde küçük önizlemeler düzgün çıkıp yazı içinde kırık görünüyorsa, arıza büyük olasılıkla yazı içeriğine gömülü eski adreslerdedir. Bu ayrım tek başına sizi doğru bölüme götürür.

Durum 1: Dosya Sunucuda Yok — 404 Dönen Görseller#

404 alıyorsanız cevap nettir: WordPress'in aradığı yolda fiziksel dosya yoktur. Taşıma yapıldıysa neredeyse her zaman wp-content/uploads klasörü eksik veya hiç kopyalanmamıştır. FTP ile taşıma yapan kullanıcılarda bu çok sık görülür, çünkü binlerce küçük dosyanın aktarımı yarıda kesilir ve istemci hatayı sessizce geçer.

Önce dosyaların gerçekten orada olup olmadığını doğrulayın. SSH erişiminiz varsa:

cd /home/kullanici/public_html/wp-content/uploads
du -sh .
find . -type f | wc -l
ls -la 2026/03 | head -20

du -sh . çıktısı birkaç megabayt gösteriyorsa ve sitenizde yıllardır görsel yüklüyorsanız, klasör eksik demektir. Eski sunucuda aynı komutu çalıştırıp iki sayıyı karşılaştırın. Aradaki fark size ne kadarının aktarılmadığını söyler.

Eksik dosyaları taşımanın en güvenilir yolu FTP değil, rsync'tir. Yarıda kesilse bile kaldığı yerden devam eder ve neyin kopyalandığını doğrular:

rsync -avz --progress -e ssh \
  eskikullanici@eski-sunucu-ip:/home/eskikullanici/public_html/wp-content/uploads/ \
  /home/kullanici/public_html/wp-content/uploads/

Sondaki eğik çizgiler önemlidir: kaynak yolun sonundaki / "bu klasörün içindekileri" demektir. Onu unutursanız uploads/uploads gibi iç içe bir klasör oluşur ve tüm görseller yine 404 döner — taşıma sonrası en sık yaptığım hata budur.

SSH yoksa ve cPanel kullanıyorsanız, eski sunucuda Dosya Yöneticisi'nden uploads klasörünü seçip Sıkıştır deyin, oluşan .zip dosyasını indirip yeni sunucuya yükleyin ve orada çıkartın. Tek büyük dosya aktarmak, on binlerce küçük dosyayı FTP ile aktarmaktan hem daha hızlı hem daha güvenilirdir. Taşıma sürecinin tamamını adım adım görmek istiyorsanız wordpress manuel site taşıma yazısı bu bölümün genişletilmiş hâlidir.

Klasör var ama alt klasörler eksikse#

Bazı taşımalarda yalnızca son yılın klasörü gelir. Şu komutla hangi yılların eksik olduğunu görürsünüz:

ls -1 /home/kullanici/public_html/wp-content/uploads

Çıktıda 2024 ve 2026 var ama 2025 yoksa, o yılın tüm görselleri kırıktır ve bu tam olarak "eski yazılardaki resimler gitmiş" şikâyetini üretir.

Durum 2: Dosya Var Ama Yol Yanlış — Veritabanındaki Eski Alan Adı#

Bu, taşıma sonrası kırık görsellerin bir numaralı sebebidir ve Türkçe kaynaklarda en az anlatılan durumdur. WordPress, yazı içeriğine gömülü <img> etiketlerinde görselin tam adresini saklar. Yani ornek.com alan adıyla yüklediğiniz bir görsel veritabanına https://ornek.com/wp-content/uploads/... olarak yazılır. Alan adını değiştirdiğinizde ya da geçici bir test adresinde çalıştıysanız, Ayarlar ekranındaki site adresini güncellemeniz yazı gövdelerindeki bu adresleri değiştirmez. Sonuç: ana sayfa açılır, tema görselleri gelir, ama yazı içindeki resimler eski adresi aramaya devam eder.

Kaç kaydın etkilendiğini önce sayın. phpMyAdmin'in SQL sekmesinde:

SELECT COUNT(*) FROM wp_posts
WHERE post_content LIKE '%eski-alanadi.com%';

Sayı sıfırdan büyükse teşhis kesinleşmiştir. Ancak düz bir UPDATE ... REPLACE sorgusuyla değiştirmeye kalkmayın. WordPress bazı verileri (özellikle tema ayarları, sayfa oluşturucu içerikleri, widget verileri) PHP'nin serialize biçiminde saklar ve bu biçim her metnin karakter uzunluğunu da içinde tutar. Alan adı uzunluğu değiştiğinde uzunluk bilgisi bozulur, veri okunamaz hâle gelir ve genellikle sayfa oluşturucuyla yapılmış tüm düzeniniz çöker. Bu kaybı geri almanın tek yolu yedektir.

Doğru yöntem, seri hâle getirilmiş veriyi çözüp yeniden kuran bir araç kullanmaktır. En temizi wp-cli:

cd /home/kullanici/public_html
wp search-replace 'https://eski-alanadi.com' 'https://yeni-alanadi.com' \
  --all-tables --precise --dry-run

--dry-run hiçbir şeyi değiştirmez, sadece kaç satırda kaç değişiklik olacağını raporlar. Çıktıyı okuyup mantıklı bulduğunuzda komutu --dry-run olmadan tekrar çalıştırın. Öncesinde mutlaka veritabanı yedeği alın:

wp db export ~/yedek-$(date +%F-%H%M).sql

wp-cli yoksa, aynı işi yapan "Better Search Replace" türü bir eklenti kurup seri veri desteğini açık bırakarak çalıştırabilirsiniz. Mantık aynıdır: önce kuru çalıştırma, sonra gerçek değiştirme.

http → https geçişi de aynı sorunu üretir#

SSL kurduktan sonra görsellerin kırılmasının sebebi çoğunlukla budur. Veritabanındaki adresler hâlâ http:// ile başlar. Aynı komutu protokol için çalıştırın:

wp search-replace 'http://ornek.com' 'https://ornek.com' --all-tables --precise

Bunu yaptıktan sonra hâlâ uyarı alıyorsanız bir sonraki bölüme geçin; orada tarayıcının neden hâlâ engellediğini anlatıyorum. Konunun tamamı için mixed content hatası yazısına da bakın.

wp-config.php ile geçici sabitleme#

Adresleri kalıcı değiştirmeden önce siteyi ayağa kaldırmanız gerekiyorsa, wp-config.php içine şu iki satırı ekleyip yönetim paneline erişimi geri kazanabilirsiniz:

define( 'WP_HOME', 'https://yeni-alanadi.com' );
define( 'WP_SITEURL', 'https://yeni-alanadi.com' );

Bu satırlar yalnızca site ve yönetim adresini sabitler; yazı içindeki görsel adreslerini düzeltmez. Geçici bir köprüdür, çözüm değildir. Kalıcı düzeltmeden sonra kaldırın, aksi hâlde ileride alan adını yine değiştirdiğinizde panelden değiştirilemeyen bir sitede kalırsınız.

Durum 3: Dosya ve Yol Doğru Ama Tarayıcı Engelliyor#

curl -I ile 200 alıyorsunuz, adres doğru, dosya orada — ama tarayıcıda görsel yok. Bu, karma içerik (mixed content) engelidir. Site HTTPS ile açılıyor fakat görsel http:// adresinden isteniyorsa, modern tarayıcılar bu isteği güvenlik gerekçesiyle sessizce iptal eder. Ağ sekmesinde istek "blocked" ya da hiç görünmez; asıl kanıt Konsol sekmesindedir:

Mixed Content: The page at 'https://ornek.com/urun/' was loaded over HTTPS,
but requested an insecure element 'http://ornek.com/wp-content/uploads/2026/03/foto.jpg'.
This content should also be served over HTTPS.

Bu satırı gördüğünüz an teşhis biter. Çözüm, önceki bölümdeki protokol değiştirme komutudur. Onu çalıştırdıktan sonra hâlâ birkaç görsel kırıksa, kalan adresler muhtemelen tema ayarlarında ya da bir sayfa oluşturucunun kendi tablosundadır; --all-tables bayrağını kullandığınızdan emin olun.

Bir de şu incelik var: HTTPS'e geçtikten sonra sitede tek bir http:// kaynağı kalsa bile tarayıcı adres çubuğundaki kilidi kırar. Görselleri geri getirdikten sonra HTTPS zorlamasını da doğru kurmak isterseniz wordpress https zorlama yazısındaki yönlendirme kuralları işinizi görür.

İzin ve Sahiplik Sorunları: 403 Dönen Görseller#

403 Forbidden dönen bir görselde dosya oradadır ama web sunucusu okumasına izin verilmemiştir. Bu genellikle taşımadan sonra dosyaların root kullanıcısıyla açılmasından ya da yanlış chmod denemelerinden kaynaklanır.

Doğru durumu görün:

ls -la /home/kullanici/public_html/wp-content/uploads/2026/03/ | head

Beklenen çıktı, dosyaların site kullanıcısına ait olması ve 644 izniyle durmasıdır:

-rw-r--r-- 1 kullanici kullanici 184320 Mar 12 09:41 urun-fotografi.jpg

root root ya da başka bir kullanıcı görüyorsanız sahipliği düzeltin. Kullanıcı adını kendi hesabınıza göre değiştirin:

chown -R kullanici:kullanici /home/kullanici/public_html/wp-content/uploads
find /home/kullanici/public_html/wp-content/uploads -type d -exec chmod 755 {} \;
find /home/kullanici/public_html/wp-content/uploads -type f -exec chmod 644 {} \;

777 vermeyin. Yıllardır gördüğüm en zararlı "çözüm" budur: sorunu bazen geçici olarak kapatır, karşılığında sunucuda dosya yazma yetkisi olan herkese sitenizi teslim eder. Klasörler için 755, dosyalar için 644 doğru değerlerdir; hangi dizinde neyin neden farklı olduğunu wordpress dosya izinleri yazısında ayrıntılı anlattım.

.htaccess ve Hotlink Koruması Kaynaklı Engeller#

Bazı 403'ler izinden değil, kural dosyasından gelir. wp-content/uploads içine yerleştirilmiş bir .htaccess, ya da kök dizindeki hotlink koruma bloğu görselleri kendi sitenize bile kapatabilir. Kontrol edin:

find /home/kullanici/public_html/wp-content -name ".htaccess" -exec echo "--- {}" \; -exec cat {} \;

Tipik hatalı hotlink kuralı şuna benzer ve www ile wwwsuz adresi ayrı sitelermiş gibi görür:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://ornek\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC]

Siteniz https://www.ornek.com üzerinden açılıyorsa bu kural kendi sayfalarınızdan gelen istekleri de reddeder. İkinci bir RewriteCond satırıyla www biçimini de izin listesine ekleyin ya da kuralı geçici olarak yorum satırına alıp görsellerin döndüğünü doğrulayın. Kural yazımının mantığı için htaccess yönlendirme yazısı iyi bir başlangıçtır.

Nginx kullanıyorsanız aynı iş location bloğunda yapılır ve .htaccess hiç okunmaz — Nginx'te bu dosyanın hiçbir hükmü yoktur. Sunucu bloğunuzda görselleri engelleyen bir valid_referers yapısı olup olmadığına bakın.

Görsel Var Ama Küçük Boyutlar Yok: Thumbnail Sorunu#

Bazen tam boyutlu görsel açılır, ancak listeleme sayfalarındaki küçük görseller kırıktır. Sebep basittir: WordPress her yüklemede birkaç farklı boyutu ayrı dosya olarak üretir (urun-300x200.jpg gibi) ve taşımada yalnızca ana dosyalar kopyalanmışsa ya da tema yeni bir boyut tanımlamışsa bu türevler yoktur.

Önce eksikliği doğrulayın:

ls /home/kullanici/public_html/wp-content/uploads/2026/03/ | grep "urun-fotografi"

Tek satır dönüyorsa türevler yok demektir. wp-cli ile hepsini yeniden üretebilirsiniz:

wp media regenerate --yes --only-missing

--only-missing bayrağı var olan dosyalara dokunmaz, yalnızca eksikleri üretir; binlerce görselli bir sitede bu fark saatler kazandırır. İşlem uzun sürüyorsa screen ya da nohup ile arka planda çalıştırın, aksi hâlde SSH oturumu düştüğünde işlem yarıda kalır. Medya kütüphanesinin nasıl çalıştığına ve boyutların nereden geldiğine dair ayrıntı için wordpress medya kütüphanesi yazısına bakabilirsiniz.

CDN, Önbellek ve Optimizasyon Eklentileri#

Sıralamada en sona bıraktım çünkü en az görülen ama teşhisi en çok zorlaştıran durum budur. Bir CDN ya da görsel optimizasyon eklentisi kullanıyorsanız, görsel adresleri artık kendi alan adınızı değil CDN adresini gösteriyor olabilir. Taşımadan sonra CDN hâlâ eski sunucuyu çektiği için kırık kalır.

Şu üç kontrolü yapın:

1. Sayfa kaynağında görselin src değerine bakın. Kendi alan adınız değilse yönlendirme CDN üzerindedir.
2. CDN panelinden önbelleği tamamen boşaltın (purge) ve kaynak (origin) sunucu adresinin yeni IP'yi gösterdiğini doğrulayın.
3. Optimizasyon eklentisini geçici olarak devre dışı bırakıp sayfayı özel/gizli pencerede açın. Görseller geliyorsa suçlu bulunmuştur.

WebP dönüştürme yapan eklentiler ayrı bir tuzak barındırır: dönüştürülmüş .webp dosyaları taşımada kopyalanmadıysa, eklenti orijinali değil olmayan .webp'yi sunmaya çalışır. Bu durumda eklentinin kendi ayarlarından toplu yeniden dönüştürme çalıştırmak gerekir.

Taşıma Sonrası Kırık Görsel Yaşamamak İçin Kontrol Listesi#

Aşağıdaki sırayı taşımanın son adımı olarak uygularsanız bu yazıya bir daha ihtiyacınız olmaz:

1. uploads klasörünü rsync ile aktarın, sonra iki tarafta find . -type f | wc -l çalıştırıp dosya sayılarını karşılaştırın.
2. Veritabanını aktardıktan sonra wp search-replace ile hem alan adını hem protokolü --dry-run ile sınayın, sonra uygulayın.
3. chown -R ile sahipliği site kullanıcısına verin; klasör 755, dosya 644.
4. wp media regenerate --only-missing çalıştırın.
5. Ana sayfa, bir kategori sayfası ve en eski yazılarınızdan birini açıp konsolda karma içerik uyarısı olup olmadığına bakın.
6. Varsa CDN ve önbellek eklentisinin tamamını boşaltın.

Bu altı adımın hepsini yapmak beş dakika sürer; atlanan tek adım genellikle günler sonra "eski yazılardaki resimler gitmiş" şikâyeti olarak geri döner.

Sıkça Sorulan Sorular#

Medya kütüphanesi boş görünüyor ama dosyalar sunucuda duruyor#

Bu, dosyaların değil veritabanı kayıtlarının eksik olduğunu gösterir. WordPress medya kütüphanesini wp_posts tablosundaki attachment türü kayıtlardan çizer; dosya sunucuda olsa bile kaydı yoksa kütüphanede görünmez. Taşımada veritabanı eksik ya da eski bir yedekten geri alınmışsa bu olur. Doğru çözüm veritabanını doğru yedekten geri yüklemektir; bu mümkün değilse "Add From Server" benzeri bir araçla mevcut dosyalar için yeni kayıt oluşturulabilir, ancak yazı içindeki bağlantılar yine elle kontrol edilmelidir.

Görsel adresini tarayıcıya yapıştırınca açılıyor ama sayfada çıkmıyor#

Bu durumda dosya ve izinler sağlamdır, engel tarayıcı tarafındadır. En yaygın sebep karma içeriktir: sayfa HTTPS ile açılırken görsel http:// adresinden isteniyordur ve tarayıcı isteği iptal eder. Geliştirici araçlarında Konsol sekmesini açıp "Mixed Content" satırını arayın. İkinci ihtimal, reklam engelleyici ya da içerik güvenlik politikasının görseli engellemesidir; siteyi gizli pencerede eklentisiz açarak bunu hızla ayırt edersiniz.

Veritabanında toplu arama değiştirme yapmak güvenli mi#

Doğru araçla yapıldığında güvenlidir, düz SQL ile yapıldığında değildir. WordPress bazı verileri seri hâle getirilmiş (serialized) biçimde saklar ve bu biçim metinlerin karakter uzunluğunu da içerir; düz bir UPDATE ... REPLACE sorgusu uzunluk bilgisini güncellemediği için veri okunamaz hâle gelir ve genellikle tema ayarlarıyla sayfa oluşturucu içerikleri bozulur. wp search-replace ya da seri veri destekli bir eklenti bu veriyi çözüp yeniden kurduğu için sorun çıkarmaz. Her koşulda işlemden önce veritabanı yedeği alın ve mümkünse kuru çalıştırma yapın.

Sadece bazı yazılardaki resimler kırık, diğerleri sorunsuz#

Genellikle o yazıların görselleri farklı bir yıl klasöründe durur ve taşımada yalnızca o klasör eksik kalmıştır. wp-content/uploads altındaki yıl klasörlerini listeleyip eski sunucudakiyle karşılaştırın. İkinci ihtimal, o yazıların içeriğine gömülü adreslerin farklı bir biçimde yazılmış olmasıdır: bazı yazılarda http://, bazılarında // ile başlayan protokolsüz adres bulunabilir. Arama değiştirme işlemini her iki biçim için ayrı ayrı çalıştırmak bunu çözer.

Öne çıkarılan görseller görünmüyor ama yazı içindekiler geliyor#

Öne çıkarılan görsel yazının içeriğinde değil, ayrı bir ilişki kaydında tutulur ve bu kayıt dosyanın kendisini değil ek (attachment) kimliğini gösterir. İçerideki görseller geliyorsa dosyalar yerindedir; öne çıkarılanların kırık olması genellikle küçük boyut türevlerinin eksik olmasından kaynaklanır, çünkü tema listeleme sayfasında tam boyutu değil türevi ister. wp media regenerate --only-missing komutu bu vakaların büyük bölümünü tek seferde kapatır.

Görselleri yükleyebiliyorum ama yükledikten sonra kırık görünüyorlar#

Yükleme başarılıysa yazma izni tamamdır, sorun okuma yolundadır. Önce yüklenen dosyanın adresini tarayıcıda doğrudan açın: 404 dönüyorsa WordPress'in kaydettiği yol ile dosyanın gerçekte oturduğu yol farklıdır ve genellikle wp-config.php içindeki UPLOADS sabiti ya da Ayarlar bölümündeki özel yükleme yolu suçludur. 403 dönüyorsa yeni dosyalar yanlış sahiplikle oluşuyordur; PHP'nin hangi kullanıcı olarak çalıştığını kontrol edip klasör sahipliğini o kullanıcıya hizalayın.

Site taşındıktan sonra tüm görseller aynı anda kırıldıysa nereden başlamalıyım#

Tek bir görselin HTTP durum koduna bakarak başlayın; hepsi aynı anda kırıldıysa hepsi aynı nedeni paylaşır. 404 alıyorsanız uploads klasörü eksiktir ve önce dosyaları taşırsınız. 200 alıp da görsel çıkmıyorsa neden karma içeriktir ve veritabanındaki protokolü düzeltirsiniz. 403 alıyorsanız sahiplik ya da .htaccess kuralıdır. Bu tek kontrol, saatlerce sürebilecek deneme yanılmayı beş dakikaya indirir.

Kapanış#

Kırık görsel sorununun tamamı üç soruya iner: dosya orada mı, WordPress doğru adresi mi arıyor, tarayıcı isteği geçiriyor mu. curl -I ile durum kodunu okumak bu üç kutudan hangisinde olduğunuzu tek adımda söyler ve gerisi mekanik bir işlemdir — eksik dosyalar için rsync, yanlış adresler için wp search-replace, engellenen istekler için protokol düzeltmesi. Deneme yanılmayla eklenti kapatıp açmak yerine önce teşhis koymak, bu arızada en çok zaman kazandıran alışkanlıktır. Taşımanın son adımı olarak yukarıdaki altı maddelik kontrol listesini uygulamak da sorunun tekrar etmesini büyük ölçüde engeller.

Bu işlemleri kendiniz yapmak istemiyorsanız ya da taşımanın bu ayrıntıları sizi aşıyorsa, site taşıma hizmetinde uploads aktarımı, veritabanı adres düzeltmesi ve SSL sonrası karma içerik kontrolü baştan sona bizim tarafımızda yürütülür. Sitesini WordPress ile yürüten ve bu tür arızalarla uğraşmak istemeyen kullanıcılar için WordPress hosting paketleri hazır yapılandırmayla gelir; düzenli güncelleme, yedek ve arıza takibini de devretmek isterseniz WordPress bakım hizmeti bu işi üstlenir. Taşıma öncesi düzenli yedek almayı alışkanlık hâline getirmek isteyenler için yedekleme çözümleri, bu yazıdaki senaryoların çoğunu en baştan önlemsiz bırakmaz.