Görsel SEO'da Ne Yapılır, Ne İşe Yarar?

Görsel SEO, bir sitedeki görsellerin arama motorları tarafından bulunmasını, bağlamının doğru anlaşılmasını, sayfa hızına zarar vermemesini ve yapılandırılmış veriyle makine okunur hale gelmesini kapsayan altı teknik karardan oluşur. Bu kararlar dosya adı ve format seçimi, alt metin, responsive kurulum, lazy loading, ImageObject şeması ve görsel sitemap’tir. Her karar çalışan kodla, kaynaklı bir yüzdeyle veya gerçek bir hesapla gösterilir; örneğin WebP’ye geçişin 500 KB (kilobayt) büyüklüğündeki bir ürün görselini kaç KB’a düşürdüğü adım adım hesaplanır. Bu tekniklerin etkisi her sitede aynı değildir. E-ticaret, tarif ve haber gibi görsel yoğun sitelerde etki büyük, metin ağırlıklı bir hizmet blogunda küçüktür; TechnoRadical’ın kendi sitesi ikinci gruba girdiği için bu altı teknik kendi sitesinde düşük öncelikli kalır.

Görsel SEO nedir, ne işe yarar

Görsel SEO, bir görselin arama motoru tarafından keşfedilmesini, bağlamının doğru okunmasını, sayfa performansını bozmamasını ve yapılandırılmış veriyle makine okunur hale gelmesini sağlayan teknikler bütünüdür. Dört işlevi de aynı görselde aynı anda çalışır; biri eksikse görsel aranabilir, hızlı veya zengin sonuca uygun olmaktan birini kaybeder.

Keşif katmanı, görselin HTML’de nasıl yer aldığına bağlıdır. Google Search Central’ın görsel SEO dokümantasyonu, standart <img> elementlerinin ve yapılandırılmış veri işaretlemesinin görsellerin bulunup işlenmesine yardımcı olduğunu, buna karşılık CSS background-image ile eklenen görselleri Google’ın indekslemediğini yazar (Mart 2026 itibarıyla). Bu fark pratik bir sonuç üretir: bir ürün fotoğrafı CSS arka planı olarak eklenirse Google Images’ta hiç görünmez, aynı görsel <img> etiketiyle eklenirse görünür.

Performans katmanı ise görsellerin toplam sayfa ağırlığına katkısıyla ilgilidir. Bir sayfanın en büyük görseli genellikle LCP (Largest Contentful Paint, en büyük içerik boyaması) elemanıdır ve bu görselin ağır veya yanlış sıralanmış olması sayfanın hız metriğini doğrudan düşürür. Görsellerin sayfa ağırlığına ve dolayısıyla LCP’ye katkısını her sayfayı elle test ederek anlamak pratik değildir; TechnoRadical’ın hız ölçümü aracı saha ve laboratuvar verisini ayırarak görsellerin ağırlığının hangi metriğe ne kadar yansıdığını gösterir.

Teknik SEO denetimlerinin hız katmanı sayfanın toplam ağırlığına bakar ama görselin dosya adını, alt metnini, formatını veya şemasını tek tek denetlemez; bu kararlar görsele özeldir ve kod örnekleriyle verilir.

Görsel dosya adı ve format seçimi hangi kurala göre yapılır

Dosya adı betimleyici ve tire ayraçlı olmalı, format seçimi ise görselin türüne ve hedef tarayıcı desteğine göre JPEG, PNG, WebP veya AVIF arasında yapılmalıdır.

Google Search Central’ın görsel SEO dokümantasyonu, dosya adı için somut bir karşılaştırma verir: “my-new-black-kitten.jpg” türünde betimleyici bir ad, “IMG00023.JPG” türünde otomatik üretilen bir addan daha iyidir. Aynı sayfa, dosya adına veya alt metne anahtar kelimeleri art arda dizmenin önerilmediğini, bunun yerine içeriğin bağlamına uygun bilgilendirici bir isimlendirmenin tercih edilmesi gerektiğini ekliyor.

Format seçimi dosya boyutunu doğrudan belirler. Google’ın WebP dokümantasyonu, kayıpsız WebP görsellerin eşdeğer PNG’ye göre %26 daha küçük olduğunu, kayıplı WebP görsellerin ise eşdeğer SSIM kalite indeksinde JPEG’e göre %25-34 arası daha küçük olduğunu yazar. Şeffaflık (alfa kanalı) gereken görsellerde kayıplı WebP, aynı işi gören PNG’ye göre tipik olarak 3 kat daha küçük dosya üretir.

Format	Sıkıştırma türü	Tipik kullanım	Tasarruf (kaynaklı)
JPEG	Kayıplı	Fotoğraf, karmaşık renk geçişi	Referans noktası
PNG	Kayıpsız	Logo, şeffaflık gereken düz renk	Referans noktası
WebP	Kayıplı veya kayıpsız	Fotoğraf ve logo, şeffaflık destekli	Kayıpsızda PNG’ye göre %26, kayıplıda JPEG’e göre %25-34
AVIF	Kayıplı veya kayıpsız	Fotoğraf yoğun sayfa	JPEG’e göre %50’nin üzerinde (kaynak zinciri doğrulanmadı, hedge’li)

AVIF’in tasarruf rakamı farklı bir güvenilirlik katmanındadır. web.dev’in performans rehberi, AVIF’in JPEG’e kıyasla belirli koşullarda %50’den fazla tasarruf sağlayabildiğini yazıyor, ama bu sayıyı kendi ölçümü olarak değil Netflix’in testlerine atıfla aktarıyor; zincirin başındaki Netflix verisi bu araştırmada doğrudan doğrulanmadı. Bu yüzden AVIF rakamı, WebP’nin Google tarafından doğrudan ölçülmüş yüzdesinden ayrı tutulmalı ve “web.dev’in aktardığı, kaynağı ayrıca izlenmesi gereken bir gözlem” olarak okunmalıdır.

Bir JPEG veya PNG görseli WebP’ye çevirmek cwebp komut satırı aracıyla tek satırda yapılır.

cwebp -q 80 urun-mavi-gomlek.jpg -o urun-mavi-gomlek.webp

-q parametresi kaliteyi 0-100 arasında ayarlar; varsayılan değer 75’tir, 80 civarı çoğu ürün fotoğrafında görsel kalite kaybını fark edilmez seviyede tutar.

Alt metin nasıl yazılır

Alt metin, görsel bilgi taşıyorsa bağlamına uygun kısa bir açıklama, görsel dekoratifse boş bir değer (alt="") olmalıdır.

Bilgilendirici bir görsel, sayfanın anlamına katkı sağlar; ürün fotoğrafı, grafik veya ekran görüntüsü bu gruba girer. Bu görseller için Google Search Central’ın erişilebilirlik rehberi, anahtar kelimeleri art arda dizmek yerine görselin içerikteki rolünü anlatan bilgilendirici bir metin yazılmasını önerir.

<img src="mavi-gomlek.jpg" alt="Mavi pamuklu erkek gömlek, önden görünüm">

Kötü alt metin iki kalıpta görülür: dosya adının kopyalanması (“IMG00023.JPG”) ve içeriksiz genel kelime (“resim”). İkisi de görselin ne olduğu hakkında hiçbir bilgi taşımaz.

<img src="IMG00023.JPG" alt="resim">

Dekoratif bir görsel, sayfanın anlamını değiştirmeden kaldırılabilen görseldir; bir ayırıcı çizgi veya süsleme buna örnektir. Google’ın erişilebilirlik rehberi, dekoratif görsellere boş alt metin verilmesini ve bu görsellerin ekran okuyucular tarafından atlanmasını öngörür. Belgenin anlamı görsel olmadan da aynıysa doğru seçim boş alt metindir, uzun bir açıklama değildir.

<img src="ayirici-cizgi.png" alt="">

Bir sayfada tek görselin alt metnini elle kontrol etmek kolaydır; yüzlerce sayfalık bir sitede her görseli tek tek açıp kontrol etmek pratik değildir. TechnoRadical’ın ücretsiz site denetimi aracı görsel alt metinlerini ve formatını teknik SEO katmanının bir parçası olarak otomatik tarar.

Responsive görseller srcset ve sizes ile nasıl kurulur

Responsive görsel kurulumu, srcset ile farklı genişliklerdeki dosyaları tanımlar, sizes ile tarayıcıya hangi genişliğin kullanılacağını söyler; src ise bu ikisini desteklemeyen tarayıcılar için geri dönüş sağlar.

srcset genişlik tanımlayıcılarıyla (400w, 800w gibi) kullanıldığında sizes özelliği zorunludur. web.dev’in responsive görsel rehberi bu ilişkiyi açıkça belirtir: tarayıcı, sizes özelliğinden geçerli viewport genişliğini öğrenir, kendi piksel yoğunluğunu da hesaba katarak srcset listesindeki en küçük yeterli dosyayı seçer.

<img
  src="urun-800.jpg"
  srcset="urun-400.jpg 400w, urun-800.jpg 800w, urun-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Mavi pamuklu gömlek, önden görünüm">

Bu örnekte tarayıcı, 600 piksel ve altındaki ekranlarda görselin tam genişlikte (100vw) gösterileceğini, daha büyük ekranlarda yarım genişlikte (50vw) gösterileceğini öğrenir. Bir telefon ekranında bu yüzde viewport’a çevrildiğinde tarayıcı genellikle urun-400.jpg veya urun-800.jpg dosyasını seçer, masaüstünde ise urun-1200.jpg devreye girer. src özelliği, srcset/sizes çiftini tanımayan eski tarayıcılarda devreye giren tek dosyalık yedek yoldur.

Lazy loading görsel SEO’yu nasıl etkiler, ne zaman kullanılmaz

Native loading="lazy" özelliği veya IntersectionObserver tabanlı bir uygulama doğru kullanıldığında görselin indekslenmesini engellemez; ama ilk görüntüde görünen içeriğe ve LCP elemanına lazy loading verilmemelidir.

Tarayıcının yerleşik yöntemi tek nitelikle kurulur.

<img src="urun-detay.jpg" alt="Ürün detay fotoğrafı" loading="lazy" width="800" height="600">

Daha ince kontrol gereken durumlarda (örneğin görsel bir kaydırma bileşeninin içindeyse) IntersectionObserver API’siyle elle tetiklenen bir yükleme kurulabilir; eski tarayıcı desteği gerekiyorsa bir polyfill eklenir. Google Search Central’ın JavaScript ve lazy loading dokümantasyonu, hangi yöntem seçilirse seçilsin bir sınırı açıkça koyar: kullanıcı etkileşimine, yani tıklama veya kaydırmaya bağlı yükleme yöntemleri önerilmez, çünkü “Google Search sayfayla etkileşime girmez” (Google Search does not interact with your page). Googlebot tıklamadığı veya kaydırmadığı için bu tür bir yükleme tetiklenmez ve görsel hiç indekslenmez.

Aynı dokümantasyon, ilk görüntüde (above-the-fold) görünecek içeriğe lazy loading eklenmemesi gerektiğini de yazar; ilk görüntüdeki içerik zaten sayfa açılır açılmaz görünür olmalıdır, geciktirilmesi hem kullanıcı deneyimini hem de LCP ölçümünü bozar. LCP elemanına lazy loading verilmemesi gerektiğini bilmek yeterli değildir; o elemanın indirmesini fetchpriority ve preload ile erken başlatmak ayrı bir karardır ve kardeş yazıda çalışan kodla gösterilir.

Görsellere yapılandırılmış veri (ImageObject) nasıl eklenir

ImageObject, bir görseli lisans, üretici ve kredilendirme bilgisiyle genişleten yapılandırılmış veri türüdür; Article veya Product şemasındaki genel image alanı bu alanları taşımaz.

Google’ın Article yapılandırılmış veri sayfası, şemada zorunlu alan olmadığını ama author, dateModified, datePublished, headline ve image alanlarının önerildiğini yazar. Buradaki image alanı sadece bir görsel adresi veya genel bir ImageObject referansıdır; lisans ve kredilendirme bilgisi taşımaz. Bu bilgiler için görsele özel, ayrı bir ImageObject bloğu gerekir.

{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://example.com/gorseller/urun-mavi-gomlek.webp",
  "license": "https://example.com/lisans",
  "acquireLicensePage": "https://example.com/gorsel-lisans-satin-al",
  "creator": {
    "@type": "Organization",
    "name": "Örnek Marka"
  },
  "creditText": "Örnek Marka",
  "copyrightNotice": "© 2026 Örnek Marka"
}

Google’ın görsel lisans metadata dokümantasyonu (son güncelleme Aralık 2025), bir görselin arama sonucunda “Licensable” rozetiyle işaretlenmesi için license alanının zorunlu olduğunu, acquireLicensePage eklenmesinin ayrıca önerildiğini yazar. creator, creditText ve copyrightNotice bu ikisini tamamlayan ek alanlardır; rozetin görünmesi için şart değildir ama görselin kime ait olduğunu makineye bildirir. Sayfanın ana görselini işaretlemek için WebPage şemasına eklenen primaryImageOfPage özelliği, bu ImageObject bloğuna işaret eder ve sayfadaki hangi görselin birincil olduğunu ayırt eder.

ImageObject alanlarını (license, creator, creditText) elle JSON-LD’ye yazmak hataya açıktır; TechnoRadical’ın şema aracı öne çıkan görsel alanını girdiğinizde temel görsel şemasını otomatik üretir.

Görsel sitemap nasıl kurulur

Görsel sitemap, her sayfa adresinin altına o sayfadaki görsellerin adreslerini ekleyen bir XML uzantısıdır ve asıl gerekli olduğu durum, JavaScript ile yüklenip normal taramada bulunamayan görsellerdir.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://example.com/urunler/mavi-gomlek/</loc>
    <image:image>
      <image:loc>https://example.com/gorseller/mavi-gomlek-on.webp</image:loc>
    </image:image>
    <image:image>
      <image:loc>https://example.com/gorseller/mavi-gomlek-arka.webp</image:loc>
    </image:image>
  </url>
</urlset>

Google Search Central’ın görsel sitemap dokümantasyonu bir sınır koyar: her <url> etiketi en fazla 1.000 <image:image> etiketi taşıyabilir. Görseller ayrı bir domainde, örneğin bir CDN’de barındırılıyorsa bu geçerlidir; Google bu durumda her iki domainin de Search Console’da doğrulanmasını önerir, aksi halde CDN’deki görseller sahiplik doğrulaması olmadan değerlendirilebilir.

Çoğu site için görseller zaten standart taramada bulunur ve ayrı bir görsel sitemap gerekmez; mevcut sayfa adresi <url> etiketine <image:image> eklemek, bağımsız bir görsel sitemap dosyası oluşturmakla eşdeğer sonucu verir. Görsel sitemap’in gerçek karşılığı, bir görselin <img> etiketi olmadan, örneğin bir JavaScript çerçevesinin arka planında yüklenmesi ve normal taramanın bu adresi hiç görmemesidir; bu durumda sitemap, Googlebot’un göremediği adresi doğrudan bildirir.

Bir görselin WebP’ye çevrilmesi dosya boyutunu ne kadar küçültür

500 KB’lık tipik bir JPEG ürün görseli, WebP’ye çevrildiğinde yaklaşık 330-375 KB’a düşer; bu aralık Google’ın belgelediği %25-34 tasarruf oranından çıkar.

Hesap basittir: %25 tasarrufla 500 KB’lık görsel 375 KB’a, %34 tasarrufla 330 KB’a düşer. Aynı oranı 10 ürün görseli taşıyan bir sayfaya uygulamak, toplam görsel ağırlığının nereden nereye geldiğini gösterir. 10 görsel JPEG olarak toplam 5.000 KB (5 MB) tutuyorsa, WebP’ye geçiş bu ağırlığı 3,3-3,75 MB’a indirir; yani sayfa yaklaşık 1,25-1,7 MB daha hafif olur.

Bu hesap bir projeksiyondur, bir garanti değildir. Gerçek sonuç görselin içeriğine göre değişir: düz renk alanlı bir grafik veya basit bir logo, karmaşık renk geçişi taşıyan bir fotoğraftan farklı bir sıkıştırma oranı verir. %25-34 aralığı Google’ın kendi ölçümüdür ama her görsel için aynı çıkmaz.

Görsel SEO hangi site tipinde fark eder, hangisinde fark etmez

Görsel SEO’nun etkisi görsel yoğun sitelerde büyük, metin ağırlıklı sitelerde küçüktür; bu fark her teknikten önce sorulması gereken bir dürüstlük sorusudur.

Etkinin büyük olduğu site tipleri, görselin kendisinin birincil içerik olduğu yerlerdir: e-ticaret ürün sayfaları (görsel kalitesi ve hızı doğrudan dönüşümü etkiler), tarif siteleri (adım adım fotoğraflar Google Images trafiğinin asıl kaynağıdır), stok görsel pazaryerleri (ürün görselin kendisidir) ve haber veya fotoğraf siteleri (Google Images ve Top Stories görünürlüğü ciddi trafik üretir). Bu sitelerde alt metin, format ve ImageObject şeması gözden kaçırılırsa doğrudan görünürlük kaybı olur.

Etkinin küçük olduğu site tipleri, görselin tamamlayıcı kaldığı yerlerdir: metin ağırlıklı SaaS dokümantasyonu veya hizmet/bilgi blogu. Bu sitelerde arama trafiği zaten metinden, görselden değil geliyor; görsel SEO’ya ayrılan zaman, metnin kapsamına veya kaynak kalitesine ayrılan zamandan daha düşük getiri sağlar.

TechnoRadical’ın kendi sitesi bu ikinci gruba giriyor. 8 Ekim 2026’da yapılan tek seferlik bir dosya sistemi incelemesi, sitenin yayındaki blog gövdelerinde gömülü bir ürün veya içerik fotoğrafı taşımadığını gösterdi; barındırılan görseller yalnızca paylaşım (OG) görseli (og-image-1200x630.png, 48 KB) ve marka logosu (logo-technoradical.png, 64 KB), ikisi de PNG formatında ve henüz WebP’ye çevrilmemiş. Bu bir ölçüm veya örneklem değil, tek bir anlık incelemedir; ama sonucu açık: bu altı teknik kendi sitesinde düşük öncelikli kalıyor, çünkü dönüştürülecek, alt metni yazılacak veya şemalanacak bir içerik görseli yok.

Görsel SEO’da verilecek altı karar: kontrol listesi

Görsel SEO önce bir site tipi sorusuyla başlar, sonra altı teknik kararla devam eder. Site görsel yoğun bir türdeyse (e-ticaret, tarif, stok görsel, haber) aşağıdaki altı karar öncelikli; metin ağırlıklı bir bilgi veya hizmet sitesindeyse bu kararlar düşük öncelikli ama yine de doğru verilmelidir.

1. Alt metin: görsel dekoratif mi, bilgilendirici mi? Dekoratifse alt="", bilgilendiriciyse kısa ve bağlama uygun metin.
2. Format: görsel JPEG/PNG’de mi kalmalı, yoksa WebP veya AVIF’e mi çevrilmeli? Karar, hedef tarayıcı desteğine ve dosya boyutu kazancına bakar.
3. Responsive kurulum: görsel farklı ekran genişliklerinde gösteriliyor mu? Gösteriliyorsa srcset ve sizes eklenmeli.
4. Lazy loading: görsel ilk görüntüde mi, yoksa sayfanın altında mı? İlk görüntüdeyse veya LCP elemanıysa lazy loading verilmemeli.
5. Yapılandırılmış veri: görsel lisanslanabilir mi veya telif bilgisi taşıması gerekiyor mu? Gerekiyorsa ImageObject’e license, creator, creditText eklenmeli.
6. Görsel sitemap: görsel standart <img> ile mi yükleniyor, yoksa JavaScript arkasında mı? JavaScript arkasındaysa görsel sitemap gerekli.

Lazy loading, Google’ın görseli indekslemesini engeller mi?

Hayır, doğru kurulmuş native loading="lazy" veya IntersectionObserver tabanlı lazy loading görselin indekslenmesini engellemez; engelleyen şey, data-src gibi standart olmayan özelliklere bağlı kötü kurulumlardır. Google Search Central’ın dokümantasyonu, Googlebot’un kullanıcı etkileşimi gerektiren yükleme yöntemlerini tetikleyemediğini yazar; data-src gibi tarayıcının yerleşik olarak tanımadığı bir özelliğe bağlı, yalnızca JavaScript’in elle tetiklediği bir yükleme, Googlebot’un görseli hiç görmemesine yol açabilir. Standart loading="lazy" niteliği veya doğru kurulmuş bir IntersectionObserver bu riski taşımaz.

JPEG veya PNG görseller WebP’ye nasıl çevrilir?

Google’ın cwebp komut satırı aracı, bir klasördeki tüm JPEG veya PNG dosyalarını tek komutla WebP’ye çevirir; -q parametresi kaliteyi 0-100 arasında ayarlar. Tek dosya yerine bir klasördeki tüm görselleri topluca çevirmek için bir döngü yeterlidir.

for dosya in *.jpg; do
  cwebp -q 80 "$dosya" -o "${dosya%.jpg}.webp"
done