WordPress WebP Görseller Görünmüyorsa 8 Teknik Kontrol

WordPress WebP görseller görünmüyor sorununda ilk yapılması gereken, bozuk görsel dosyasının gerçek URL’sini bulmaktır.

Görselin WordPress medya kütüphanesinde kayıtlı olması, dosyanın sunucuda hâlâ bulunduğunu kesin olarak göstermez.

Kontrol adımları

1. Görünmeyen görsele sağ tıklayın. Görsel adresini kopyalayın veya geliştirici araçlarında seçin.
2. Gerçek URL’yi yeni sekmede açın. Görsel yükleniyor mu?
3. Network sekmesini inceleyin. Görselin HTTP yanıt kodunu kontrol edin.
4. URL’nin uploads yolu ile eşleştiğini doğrulayın. Dosya adı ve klasör doğru mu?
5. Sunucudaki gerçek dosyayı kontrol edin. Özellikle site taşıma sonrası eksik dosya olup olmadığını araştırın.

Örnek dosya adresi

https://example.com/wp-content/uploads/2026/11/ornek-gorsel.webp

Terminal ile HTTP kontrolü

curl -I \
https://example.com/wp-content/uploads/2026/11/ornek-gorsel.webp

Bu komut sunucunun HEAD isteğine verdiği HTTP başlıklarını kontrol eder.

Sunucu HEAD ve GET isteklerine farklı davranabileceği için gerçek görsel isteğini de inceleyin.

Yaygın HTTP yanıtları

• 200: Sunucu isteğe yanıt verdi; içeriği ayrıca kontrol edin.
• 301/302: Görsel başka adrese yönleniyor.
• 403: Erişim engelleniyor olabilir.
• 404: İstenen dosya bulunamadı.
• 500/502/503: Sunucu veya ara servis hatası bulunabilir.

WebP görseller sunulurken sunucunun doğru içerik türünü belirtmesi önemlidir.

WebP için kullanılan MIME türü:

Content-Type: image/webp

Sunucuda yanlış MIME eşleştirmesi varsa tarayıcı görseli beklenen biçimde işlemeyebilir.

Ancak her görüntüleme hatasını yalnızca MIME sorununa bağlamak da doğru değildir.

Kontrol edilecekler

• Görsel yanıtı image/webp içeriyor mu?
• Dosya uzantısı gerçekten .webp mi?
• Dosyanın içeriği WebP biçiminde mi?
• Sunucu HTML hata sayfası mı döndürüyor?
• CDN farklı Content-Type gönderiyor mu?
• Görsel isteği HTTPS üzerinden mi yapılıyor?

MIME kontrol komutu

curl -sS -D - -o /dev/null \
https://example.com/wp-content/uploads/2026/11/ornek.webp

Yanıt başlıklarında HTTP kodunu ve Content-Type değerini inceleyin.

Dosyanın gerçek biçimi

Sunucu erişimi varsa dosyanın gerçek formatı şu komutla incelenebilir:

file /path/to/ornek.webp

Komut, dosyanın gerçek içeriğini tanımlamaya yardımcı olur.

Yalnızca JPG dosyasının adını .webp olarak değiştirmek gerçek format dönüşümü değildir.

WordPress, görsellerin farklı boyutlarını oluşturmak ve düzenlemek için sunucu tarafında görüntü işleme kütüphanelerinden yararlanır.

Bunların başlıcaları GD ve Imagick altyapılarıdır.

WordPress WebP desteği mevcut olsa da sunucunun WebP işleme yetenekleri eksik veya yanlış yapılandırılmış olabilir.

WordPress Site Sağlığı kontrolü

1. WordPress yönetimine girin. Araçlar → Site Sağlığı bölümünü açın.
2. Bilgi sekmesini inceleyin. Sunucu ve medya işleme bilgilerini bulun.
3. GD/Imagick durumuna bakın. Kullanılan PHP kütüphanesini kontrol edin.
4. WebP işleme desteğini doğrulayın. Sunucuya bağlı destek farkı var mı?
5. Test WebP dosyası yükleyin. Küçük boyutların oluşup oluşmadığını inceleyin.

GD WebP desteği nasıl test edilir?

Teknik ekip, yalnızca güvenli sunucu ortamında aşağıdaki PHP kontrollerini değerlendirebilir.

function_exists('imagewebp');

function_exists('imagecreatefromwebp');

Bunlar, ilgili GD fonksiyonlarının mevcut olup olmadığını kontrol eden örneklerdir.

Gerçek bir görselin okunması veya yazılması için yalnızca fonksiyonun bulunması yeterli olmayabilir.

Imagick WebP desteği

Imagick::queryFormats('WEBP');

Bu örnek, Imagick’in WebP biçimini tanıyıp tanımadığını incelemek amacıyla kullanılabilir.

WordPress, bir görselin farklı ekran boyutlarına uygun varyasyonlarını oluşturabilir.

Tarayıcı srcset ve sizes bilgilerine göre farklı dosya boyutları seçebilir.

Ana WebP dosyası mevcut olsa bile küçük boyutlardan biri eksikse görsel yalnızca bazı cihazlarda görünmeyebilir.

Örnek dosya yapısı

ornek.webp
ornek-300x200.webp
ornek-768x512.webp
ornek-1024x683.webp

Bu dosya adları temsili örneklerdir. Gerçek boyutlar WordPress ve tema ayarlarına göre değişebilir.

HTML srcset örneği

<img
  src="/uploads/ornek.webp"
  srcset="
    /uploads/ornek-300x200.webp 300w,
    /uploads/ornek-768x512.webp 768w,
    /uploads/ornek.webp 1200w
  "
  sizes="(max-width: 767px) 100vw, 800px"
  width="1200"
  height="800"
  alt="Örnek görsel"
>

Hangi dosya gerçekten yükleniyor?

Tarayıcı geliştirici araçlarında Elements veya Console üzerinden görselin currentSrc değerini inceleyebilirsiniz.

// Tarayıcı konsolunda
// seçili img öğesi için:

$0.currentSrc

Bu ifade geliştirici araçlarında seçili görsel öğesinin gerçekten kullandığı URL’yi gösterebilir.

Eksik boyutlar nasıl düzeltilir?

1. Orijinal görselin sunucuda bulunduğunu doğrulayın.
2. Sunucunun WebP işleme desteğini kontrol edin.
3. Medya boyutlarının eksik olup olmadığını belirleyin.
4. Yedek alarak eksik boyutları yeniden oluşturun.
5. Responsive srcset çıktısını yeniden test edin.

LiteSpeed Cache kullanan WordPress sitelerinde JPG veya PNG görseller WebP formatına dönüştürülebilir.

Ancak WebP dosyasının oluşturulmasıyla HTML içinde kullanılmaya başlanması farklı aşamalardır.

LiteSpeed’in resmî belgeleri özellikle bu iki sürecin ayrı kontrol edilmesini önerir.

LiteSpeed kontrol sırası

1. LiteSpeed Cache → Image Optimization bölümüne girin. Görsel optimizasyon durumunu açın.
2. İşlem durumunu kontrol edin. Başarısız optimizasyon veya bekleyen işlem var mı?
3. Next-Gen Image Format ayarını inceleyin. WebP veya AVIF seçimi doğru mu?
4. WebP dosyasının fiziksel olarak oluştuğunu doğrulayın. Orijinal görselin karşılığı mevcut mu?
5. Önyüzde hangi formatın sunulduğunu inceleyin. Tarayıcı JPG mi WebP mi indiriyor?
6. Gerekliyse optimizasyon hatasını yeniden işleyin. İşlemi resmî LiteSpeed yönergelerine göre yürütün.

LiteSpeed tarafından oluşturulan dosya adları

LiteSpeed sisteminde dönüştürülen bir JPG dosyasının WebP karşılığı bazı yapılandırmalarda şu biçimde bulunabilir:

Orijinal dosya:
ornek.jpg

LiteSpeed WebP karşılığı:
ornek.jpg.webp

Bu isimlendirme LiteSpeed’in optimizasyon yöntemine özgüdür.

Doğrudan WordPress’e yüklenmiş gerçek WebP dosyası yalnızca ornek.webp olarak adlandırılmış olabilir.

WebP dosyası neden oluşturulmamış olabilir?

• WebP seçeneği optimizasyondan sonra açılmış olabilir.
• QUIC.cloud optimizasyon bağlantısı başarısız olabilir.
• Görsel sunucudan alınamıyor olabilir.
• Geri gönderilen optimize dosyalar indirilememiş olabilir.
• WebP sürümü orijinal dosyadan daha büyük olduğu için atılmış olabilir.
• Bazı thumbnail boyutları henüz üretilmemiş olabilir.

Görsel doğru oluşturulmuş olsa bile CDN veya sunucu önbelleği eski dosya yolunu kullanabilir.

Özellikle web sitesi taşıma sonrasında www ve www olmayan adresler arasında tutarsızlık oluşabilir.

LiteSpeed’in resmî açıklamasına göre WebP/AVIF değiştirme işlemi bazı durumlarda görsel URL’sinin WordPress site adresiyle eşleşmesine bağlıdır.

Örnek alan adı uyuşmazlığı

WordPress site adresi:
https://www.example.com

HTML görsel adresi:
https://example.com/uploads/ornek.jpg

Olası sorun:
WebP değiştirme işlemi
beklenen şekilde yapılmayabilir.

Kontrol edilecekler

• WordPress Adresi ve Site Adresi tutarlı mı?
• Görseller doğru HTTPS alan adından mı yükleniyor?
• CDN URL yeniden yazımı doğru mu?
• Dosya origin sunucuda gerçekten bulunuyor mu?
• CDN eski 404 yanıtını önbelleğe almış mı?
• Görselin Cache-Control başlıkları uygun mu?
• CDN farklı kullanıcılar için yanlış format sunuyor mu?

CDN ile kaynak sunucuyu ayırma

1. Canlı görsel URL’sini kaydedin. CDN üzerinden gelen yanıtı inceleyin.
2. Origin sunucudaki dosyanın varlığını doğrulayın. Hosting dosya yöneticisi veya güvenli sunucu erişimini kullanın.
3. CDN hata günlüklerini inceleyin. İstek engelleniyor veya eski yanıt dönüyor mu?
4. Doğrulanmış cache sorununu hedefleyin. Yalnızca ilgili görsel veya yolun önbelleğini temizleyin.
5. Farklı tarayıcı oturumlarında doğrulayın. Sonuç tutarlı mı?

Görsel dosyası sorunsuz açıldığı hâlde web sayfasında görünmüyorsa HTML ve CSS katmanı incelenmelidir.

Bunun nedeni WebP formatının kendisi değil, görselin sayfa içinde kullanılma biçimi olabilir.

Yaygın sorunlar

• İki farklı eklentinin aynı görsele lazy-load uygulaması
• Görsel src yerine yalnızca data-src içinde bulunması
• picture içindeki source yolunun hatalı olması
• CSS ile görselin display:none yapılması
• Mobil media query’nin görseli gizlemesi
• Görsel kapsayıcısının yüksekliğinin sıfır olması
• CSS background-image yolunun yanlış olması
• JavaScript hatasının lazy-load başlatmasını engellemesi

HTML görseli ile CSS arka planı farkı

LiteSpeed’in resmî belgelerinde standart WebP/AVIF değiştirme işleminin HTML img etiketleri üzerinde çalıştığı, CSS veya JavaScript ile oluşturulan görsellerde aynı davranışın garanti edilmediği belirtilir.

Örnek HTML

<img
  src="/uploads/ornek.webp"
  alt="Örnek görsel"
  width="1200"
  height="800"
>

Örnek CSS arka planı

.ornek-hero {
  background-image:
    url("/uploads/ornek.webp");
  background-size: cover;
  background-position: center;
}

CSS arka planındaki URL doğrudan WebP dosyasını işaret edebilir.

Ancak JPG adresinin otomatik olarak WebP’ye dönüştürülmesi, kullanılan optimizasyon sisteminin teknik yeteneklerine bağlıdır.

Lazy-load teşhisi

1. Görselin gerçek src değerini inceleyin. Dosya yolu doğru mu?
2. data-src ve lazy-load sınıflarını kontrol edin. Görsel gerçekten yüklemeyi başlatıyor mu?
3. Tarayıcı Console bölümünü kontrol edin. JavaScript hatası var mı?
4. Computed CSS değerlerine bakın. Görsel gizleniyor mu?
5. Mobil ve masaüstünü karşılaştırın. Responsive stil farkı var mı?

Görsellerin yüklenmesi ve sunulması WordPress’te birden fazla bileşenden etkilenebilir.

Tema, sayfa oluşturucu, CDN eklentisi, görsel sıkıştırma eklentisi ve LiteSpeed Cache aynı görsel URL’lerini değiştirmeye çalışabilir.

Bu tür çakışmalarda sorunu doğru katmana indirgemek önemlidir.

Kontrol edilecekler

• Birden fazla WebP dönüştürme sistemi var mı?
• Tema kendi lazy-load veya görsel optimizasyonunu kullanıyor mu?
• CDN eklentisi resim yollarını değiştiriyor mu?
• Hotlink koruması görsel erişimini engelliyor mu?
• Sunucu rewrite kuralları hatalı dosyaya yönlendiriyor mu?
• Eklenti güncellemesinden sonra sorun başladı mı?
• Dosya izinleri ve ownership doğru mu?

Güvenli test yaklaşımı

1. İlk hatalı URL ve tarayıcı yanıtını kaydedin. Test için başlangıç verisi oluşturun.
2. WordPress ve sunucu yedeği alın. Özellikle uploads dizinini koruyun.
3. Staging ortamı kullanın. Canlı site üzerinde toplu eklenti kapatmayın.
4. Aktif görsel optimizasyonlarını listeleyin. Çift dönüştürme veya lazy-load var mı?
5. Tek bir bileşeni izole edin. Sonuç değişiyor mu?
6. Kök nedeni düzeltin. Kalıcı ayar değişikliğini doğrulayın.
7. Tüm cihazlarda yeniden test edin. WebP ve gerekli JPG/PNG geri dönüşlerini kontrol edin.