Görsel SEO Rehberi: Resim Optimizasyonu ve Google Görseller

Google Görseller aramaları, web sitelerine gelen trafiğin ciddi bir bölümünü oluşturuyor; buna rağmen çoğu site bu kaynağı, bu SEO rehberi olmadan neredeyse tamamen boşa harcıyor. Rastgele dosya adları, eksik alt metin, sıkıştırılmamış PNG dosyaları ve lazy loading uygulanmadan yüklenen onlarca görsel hem Core Web Vitals skorunu hem de görsel arama görünürlüğünü düşürüyor. Bu rehber, görselleri hem hızlı hem de aranabilir hale getirmek için gereken adımları sırayla anlatıyor.

E-ticaret sitelerinde bu konu özellikle önemli, çünkü ürün görseli hem satın alma kararının hem de görsel arama trafiğinin merkezinde yer alıyor. Blog ve haber sitelerinde de infografik ve kapak görselleri, Google Görseller sekmesinden gelen ziyaretçi sayısını doğrudan etkiliyor. Aşağıdaki başlıklar, dosya adından yapılandırılmış veriye kadar bu zinciri baştan sona kapsıyor.

Görsel dosya adı ve alt metin nasıl yazılır

Dosya adı ve alt metin, Google için bir görselin kimlik kartı gibi çalışıyor; ikisi de görselin ne olduğunu makineye anlatan tek yol. Dosya adı, Google'ın bir görseli indekslemeden önce okuduğu ilk sinyaldir. "IMG_4821.jpg" görselin içeriği hakkında hiçbir bilgi taşımaz. "kirmizi-deri-koltuk-oturma-odasi.jpg" gibi tire ile ayrılmış, açıklayıcı bir ad ise görselin ne olduğunu net biçimde söyler. Kelimeler alt çizgi yerine tire ile ayrılmalı, çünkü Google dosya adını bu şekilde ayrıştırıyor. Türkçe karakterler (ç, ğ, ı, ö, ş, ü) dosya adında kullanılmamalı; sunucu ve CDN katmanında bazen kodlama sorununa yol açıyor.

Alt metin ise hem SEO hem erişilebilirlik açısından zorunludur. Ekran okuyucular, görme engelli kullanıcılara sayfayı bu metin üzerinden anlatır; Google da görselin bağlamını buradan çıkarır. Alt metni anahtar kelime listesine çevirmemek gerekir. "Koltuk, kırmızı koltuk, ucuz koltuk, koltuk modelleri" yazmak spam sayılır ve cezalandırılabilir. Bunun yerine görsel gerçekten tarif edilmeli: "Kırmızı deri üç kişilik koltuk, ahşap ayaklı, oturma odasında" gibi.

Alt metin yazarken uyulması gereken birkaç kural var:

• Görselde ne olduğunu 8-12 kelimeyle net biçimde anlatın, gereksiz sıfat eklemeyin.
• Aynı anahtar kelimeyi sayfadaki her görselde tekrarlamayın; her görsel farklı bir açıdan tarif edilmeli.
• Dekoratif görsellere (arka plan deseni, ayraç çizgisi gibi) boş alt metin bırakın, ekran okuyucu bunları atlasın.
• Görselin içinde metin varsa (banner, infografik başlığı), o metni alt metnin içine de ekleyin.

<img
  src="/images/kirmizi-deri-koltuk-oturma-odasi.webp"
  alt="Kırmızı deri üç kişilik koltuk, ahşap ayaklı, oturma odasında"
  width="1200"
  height="800"
  loading="lazy"
/>

width ve height niteliklerini asla atlamayın. Tarayıcı bu değerleri okuduğunda, sayfa yüklenmeden önce görsel için doğru alanı ayırıyor; bu da Cumulative Layout Shift'i (CLS) sıfıra yakın tutuyor. Değerler boş bırakılırsa görsel geç yüklendiğinde sayfa aşağı yukarı zıplıyor, kullanıcı da yanlış yere tıklıyor.

CSS ile responsive yapıp width ve height niteliklerini atlayanlar var, ama bu doğru bir çözüm değil. Tarayıcı bu iki niteliği ve görselin gerçek en-boy oranını kullanarak aspect-ratio hesaplıyor; bu da CSS'teki max-width: 100% kuralıyla birlikte çalıştığında hem responsive hem de kaymasız bir sonuç veriyor.

WebP ve AVIF formatları neden önemli

JPEG ve PNG hâlâ yaygın kullanılıyor ama artık en verimli seçenek değiller. WebP, Google'ın kendi geliştirdiği format; hem kayıplı hem kayıpsız sıkıştırma sunuyor ve şeffaflığı da destekliyor. AVIF ise daha yeni bir format, genellikle WebP'den de küçük dosya boyutu üretiyor ama kodlama süresi daha uzun, eski tarayıcı desteği de daha sınırlı. Hangi formatın seçileceğine görselin türü karar veriyor: fotoğraf ağırlıklı bir galeri için AVIF avantajlı, ama sık güncellenen binlerce ürün görseli varsa kodlama maliyeti WebP'yi daha pratik kılıyor.

En güvenli yol, picture etiketiyle katmanlı bir fallback kurmaktır. Tarayıcı AVIF'i destekliyorsa onu, desteklemiyorsa WebP'yi, o da yoksa JPEG'i gösteriyor. Bu sayede eski bir Safari sürümü bile kırık görsel görmüyor.

<picture>
  <source srcset="/images/urun-gorseli.avif" type="image/avif">
  <source srcset="/images/urun-gorseli.webp" type="image/webp">
  <img src="/images/urun-gorseli.jpg" alt="Ürün görseli, beyaz arka plan üzerinde" width="800" height="600" loading="lazy">
</picture>

Format dönüşümü için sunucu tarafında cwebp veya avifenc gibi araçlar kullanılabilir; WordPress'te ise ShortPixel veya Imagify gibi eklentiler işi otomatikleştiriyor. Google'ın WebP hakkındaki resmi dokümantasyonu format detaylarını ve araçları listeliyor: developers.google.com/speed/webp.

AVIF'e tam geçiş yapmadan önce build sürecini kontrol etmek gerekiyor, çünkü kodlama süresi WebP'ye göre belirgin biçimde daha uzun. Yüzlerce görseli olan büyük bir katalog sitesinde bu, deploy süresini uzatabilir. Bu yüzden çoğu ekip önce WebP'ye geçip AVIF'i sonradan, trafiği yüksek sayfalarda kademeli olarak ekliyor.

Görsel boyutlandırma ve sıkıştırma nasıl yapılır

En sık yapılan hata, 4000 piksel genişliğindeki bir kamera çıktısını doğrudan sunucuya yükleyip CSS ile 400 piksele küçültmektir. Tarayıcı yine de orijinal dosyayı indiriyor, bant genişliği boşa gidiyor. Görsel, gösterileceği maksimum genişlikte üretilmelidir. Genel kural olarak, en büyük ekranda görselin kaplayacağı piksel genişliğinin üzerine yüzde 20-30 pay bırakmak yeterlidir; bunun çok üzerine çıkmak dosya boyutunu gereksiz büyütüyor.

srcset ve sizes nitelikleri, farklı ekran boyutlarına farklı dosya sunmayı sağlıyor. Mobilde küçük bir görsel, masaüstünde daha büyük bir versiyon indiriliyor; ikisi aynı dosya olmuyor.

<img
  src="/images/manzara-800.webp"
  srcset="/images/manzara-400.webp 400w, /images/manzara-800.webp 800w, /images/manzara-1600.webp 1600w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px"
  alt="Dağ manzarası, gün batımında"
  width="1600"
  height="900"
  loading="lazy"
/>

sizes niteliği tarayıcıya, bu ekran genişliğinde görselin kaç piksel kaplayacağı bilgisini önceden veriyor; tarayıcı da srcset listesinden en uygun dosyayı seçiyor. Bunu elle yazmak yerine Next.js Image bileşeni veya WordPress'in kendi responsive image üretimi gibi araçlar otomatik hallediyor. Yine de üretilen HTML çıktısını tarayıcı geliştirici araçlarından kontrol etmek, yanlış dosyanın indirilmediğinden emin olmak için gerekiyor.

Sıkıştırma tarafında birkaç pratik kural var:

• Fotoğraflarda JPEG/WebP kalitesini yüzde 75-85 aralığında tutun, göz farkı genelde çok azdır.
• İkon ve logo gibi keskin kenarlı grafikleri SVG olarak tutun, raster formata çevirmeyin.
• Yükleme öncesi TinyPNG, Squoosh veya sunucu taraflı sharp kütüphanesiyle toplu sıkıştırma yapın.
• CDN kullanıyorsanız Cloudflare Polish veya benzeri otomatik görsel optimizasyon özelliğini açın.

Squoosh gibi araçlar, aynı görselin farklı format ve kalite ayarlarındaki dosya boyutunu yan yana gösteriyor; karar vermeden önce gözle kıyaslamak işe yarıyor.

Lazy loading ve Core Web Vitals etkisi

loading="lazy" niteliği artık tüm modern tarayıcılarda destekleniyor ve tek satırlık bir çözüm. Ekranın dışındaki görseller, kullanıcı kaydırana kadar yüklenmiyor; ilk sayfa yükü küçülüyor. Bir istisna var: sayfanın en üstündeki, katlama üstü (above the fold) görsele bu nitelik asla eklenmemeli.

Katlama üstündeki görsel genellikle Largest Contentful Paint (LCP) metriğini belirleyen öğedir. Bu görsel lazy yüklenirse tarayıcı onu geç keşfediyor. LCP süresi uzuyor. Core Web Vitals skoru düşüyor. Bunun yerine o görsele fetchpriority="high" eklemek ve erken yüklenmesini sağlamak daha doğru bir yaklaşımdır. Chrome DevTools'un Performance panelindeki LCP işaretçisi, tam olarak hangi öğenin bu metriği belirlediğini gösteriyor; tahmin etmeye gerek kalmıyor.

<img
  src="/images/hero-gorseli.webp"
  alt="Ana sayfa kapak görseli, ürün vitrini"
  width="1920"
  height="1080"
  fetchpriority="high"
/>

Web.dev'in görsel servis rehberi bu dengeleri ve WebP'ye geçiş sürecini detaylı örneklerle anlatıyor: web.dev/articles/serve-images-webp. Sayfada onlarca ürün görseli varsa, ilk ekranda görünen 2-3 tanesini eager, gerisini lazy yapmak genelde en iyi dengeyi sağlıyor.

Karusel veya galeri bileşenlerinde dikkat edilmesi gereken bir tuzak var. Bazı JavaScript kütüphaneleri tüm slaytları DOM'a aynı anda ekliyor; lazy loading tanımlansa bile tarayıcı hepsini keşfediyor. Bu durumda gerçek bir lazy loading için görünür olmayan slaytların kaynak değeri bir placeholder ile değiştirilmeli, kullanıcı o slayta geldiğinde gerçek dosya yüklenmelidir. Kütüphane seçerken bu davranışı test etmek, sonradan performans sorunu yaşamamak için önemlidir.

Görsel sitemap ve structured data ile Google Görseller'de görünürlük

Google, sayfayı tararken JavaScript ile geç yüklenen veya CSS arka planında gizli kalan görselleri bazen atlıyor. Görsel sitemap, bu görselleri açıkça listeleyerek Google'a bunların da var olduğunu ve indekslenmesi gerektiğini bildiriyor. Özellikle React veya Vue gibi client-side render eden sitelerde bu ekleme fark yaratıyor.

<url>
  <loc>https://ornek-site.com.tr/urunler/kirmizi-koltuk</loc>
  <image:image>
    <image:loc>https://ornek-site.com.tr/images/kirmizi-deri-koltuk.webp</image:loc>
    <image:title>Kırmızı deri koltuk</image:title>
  </image:image>
</url>

Ürün, tarif veya makale sayfalarında ImageObject şeması eklemek, Google'a görselin lisans durumu, boyutu ve başlığı gibi ek meta veriyi taşıyor. Bu, zengin sonuçlarda görselin daha büyük veya daha öne çıkan biçimde gösterilme ihtimalini artırıyor. Tarif sitelerinde Recipe şeması içine, makalelerde Article şeması içine gömülü görsel alanı da aynı mantıkla çalışıyor.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Kırmızı Deri Koltuk",
  "image": [
    "https://ornek-site.com.tr/images/kirmizi-deri-koltuk-1x1.webp",
    "https://ornek-site.com.tr/images/kirmizi-deri-koltuk-4x3.webp"
  ]
}

Google Görseller ve arama görünürlüğü için resmi kılavuz, hangi sinyallerin öncelikli olduğunu ve teknik gereksinimleri listeliyor: developers.google.com/search/docs/appearance/google-images. Sitemap'i Search Console'a gönderdikten sonra "Sayfalar" raporunda görsel URL'lerinin indekslenip indekslenmediğini kontrol etmek gerekiyor. İndekslenmeyen görseller genelde ya robots.txt tarafından engellenmiş ya da çözünürlüğü çok düşük oluyor; ikisi de kolayca düzeltilebilen sorunlar.

Bütün bu adımlar arasında tek başına en yüksek getiriyi sağlayan iş, katlama üstü LCP görselini doğru formatta, doğru boyutta ve fetchpriority="high" ile sunmaktır. Diğer adımlar kademeli iyileştirme sağlıyor, ama bu tek görsel hem Core Web Vitals skorunu hem de kullanıcının ilk izlenimini doğrudan belirliyor.

Yazan Celil Uyanikoglu

25 yıldır bilgi işlem piyasasında farklı dallarda uzmanlaşan bir Bilgisayar Mühendisi