Teknoloji

Görsel SEO: WebP/AVIF, CDN ve Görsel Site Haritası

Görsel SEO ve Hosting Altyapısı Arasındaki Doğrudan Bağlantı

Görsel SEO çoğu zaman sadece dosya isimleri, alt etiketler ve schema işaretlemeleri üzerinden konuşuluyor. Ancak arka plandaki hosting altyapısı; görsel formatı, dağıtımı ve site haritası üretimi için kullanabileceğiniz seçenekleri etkiler. Google Görseller’de görünürlük, Core Web Vitals skorları ve dönüşüm oranları ise yalnızca sunucu kararlarına değil; içerik, sayfa tasarımı ve istemci tarafındaki uygulamaya da bağlıdır.

E-ticaret, büyük katalog ve içerik sitelerinde WebP/AVIF, CDN üzerinden dağıtım ve düzenli üretilen görsel site haritaları birlikte planlanabilir. Amaç, görsellerin aktarım yükünü azaltmak ve keşfedilmesini kolaylaştırmaktır; organik trafik artışı garanti değildir. Bu yazıda görsel SEO ile hosting altyapısının nerede kesiştiğini ve bu bileşenleri pratikte nasıl bir araya getirebileceğinizi adım adım anlatacağız.

Odak noktamız üç başlık olacak: WebP/AVIF gibi modern görsel formatları, CDN alt alan adları (img.site.com, cdn.site.com gibi) ile içerik dağıtımı ve görsel site haritaları (image sitemap). Bunların her birini tek tek optimize etmek yerine, aynı mimaride bir araya getirdiğinizde ortaya güçlü bir görsel SEO altyapısı çıkıyor.

WebP ve AVIF ile Görsel Boyutunu Küçültüp Kaliteyi Korumak

Görsel SEO tarafında ilk büyük kazanım, dosya boyutunu azaltırken kaliteyi korumaktan geçiyor. Burada iki modern format öne çıkıyor: WebP ve AVIF. İkisi de JPEG/PNG’ye göre daha küçük dosyalar üretebilir; avantajın büyüklüğü görsel içeriğine, kalite hedefine ve kodlama ayarlarına bağlıdır.

WebP ve AVIF Arasındaki Temel Farklar

  • WebP: Google’ın geliştirdiği, hem kayıplı hem kayıpsız sıkıştırmayı destekleyen, tarayıcı desteği çok geniş bir format.
  • AVIF: AV1 video codec temelli, özellikle düşük bitratelerde WebP’ye göre daha iyi kalite sunabilen, fakat encoding süresi daha uzun olabilen yeni nesil bir format.

Gerçek projelerde genellikle şu stratejiyi öneriyoruz:

  • Destekleyen tarayıcılara önce AVIF, desteklemeyenlere WebP, hiçbirini desteklemeyenlere ise JPEG/PNG fallback sunmak.
  • Bunu ya <picture> etiketi ile front-end seviyesinde, ya da Accept header kontrolüyle Nginx/Apache veya CDN tarafında içerik pazarlığı yaparak gerçekleştirmek. Aynı URL altında farklı formatlar sunuluyorsa, önbelleğin bu yanıtları ayırt etmesi de gerekir; aksi halde istemciye desteklemediği bir format gönderilebilir.

Sunucu ve CDN taraflı dönüşüm işini derinlemesine ele aldığımız WebP/AVIF’i kırmadan sunmak ve SEO uyumlu dönüşüm rehberine de mutlaka göz atmanızı öneririz.

WebP/AVIF’in SEO’ya Teknik Etkisi

Bu formatların SEO’ya katkısı sadece ‘dosya boyutu küçüldü, sayfa hızlandı’ seviyesinde değil. Özellikle:

  • LCP (Largest Contentful Paint) öğesi bir görselse, dosya boyutunu azaltmak LCP süresini iyileştirebilir. Büyük kahraman görselini (hero image) WebP/AVIF’e geçirmek bu nedenle değerlendirilebilir; kazanım, görselin ne zaman istendiğine ve sayfanın diğer darboğazlarına da bağlıdır.
  • CLS (Cumulative Layout Shift) açısından önemli olan, görseller yüklenmeden önce doğru alanı ayırmaktır. Doğru width/height değerleri buna yardımcı olur; dosya boyutunu küçültmek tek başına yerleşim kaymalarını önlemez.
  • Daha hızlı görsel yükleme, kullanıcı deneyimini iyileştirebilir. Kullanıcı etkileşim oranları (scroll, tıklama, sepete ekleme) üzerindeki etki ölçülmelidir; bu davranışları otomatik bir SEO kazanımı olarak yorumlamamak gerekir.

Sunucu tarafının Core Web Vitals üzerindeki etkisini daha geniş çerçevede görmek isterseniz, Core Web Vitals ve hosting altyapısı rehberimiz görsel optimizasyon kararlarınızı da besleyecektir.

Görsel Dönüşüm İçin Boru Hattı (Pipeline) Kurmak

Tek tek görsel dönüştürmek yerine, staging/canlı ortam arasında otomatik bir görsel optimizasyon boru hattı kurmak işleri çok kolaylaştırır. Örnek bir akış şöyle kurulabilir:

  1. Kaynak görseli orijinal formatında (çoğunlukla JPEG/PNG) yüklemek.
  2. Arka planda çalışan bir job ile WebP ve AVIF versiyonlarını üretmek.
  3. Boyuta göre farklı kırpma/boyutlandırma profilleri (küçük/orta/büyük) oluşturmak.
  4. Sunucu veya CDN tarafında kullanıcıya en uygun format + boyutu dinamik seçmek.

Bunu sadece “daha küçük dosya” hedefiyle değil, disk, bant genişliği ve CDN faturası tarafını da düşünerek ele aldığımız detaylı bir senaryoyu görüntü optimizasyonu boru hattı rehberimizde adım adım anlattık.

CDN Alt Alan Adları: img.site.com mu, www.site.com mu?

Görselleri bir CDN üzerinden alt alan adıyla (örneğin img.ornek.com veya cdn.ornek.com) servis etmek bir seçenektir; CDN kullanmak için ayrı bir alt alan adı şart değildir. Ancak burada SEO ve hosting tarafında dikkat edilmesi gereken kritik noktalar var.

CDN Kullanımının ve Ayrı Alt Alan Adının Olası Avantajları

  • Coğrafi dağıtım: CDN, görselleri kullanıcıya yakın bir edge sunucudan sunarak gecikmeyi azaltabilir; sonuç yönlendirmeye ve önbellek durumuna bağlıdır.
  • Önbellek isabet oranı (cache hit ratio): Uygun önbellek kuralları ve tekrar kullanılan görseller, origin (ana sunucu) yükünü azaltabilir. Ayrı alt alan adı kullanmak tek başına isabet oranını artırmaz.
  • Cookie-less domain yaklaşımıyla (aynı kökte çerez set etmeyerek) her istekle gereksiz cookie taşınmasının önüne geçilebilir.

CDN seçim ve maliyet optimizasyonu tarafını ayrı bir başlıkta ele aldığımız CDN ne zaman gerekir, nasıl karar verilir? rehberi bu noktada iyi bir tamamlayıcı kaynaktır.

Alt Alan Adı Kullanırken SEO Açısından Dikkat Edilecekler

Görsellerinizi alt alan adı üzerinden sunarken şu noktalara özellikle dikkat ediyoruz:

  • Alan adı kontrolü: CDN sağlayıcısının alan adı yerine kendi subdomain’inizi (örneğin img.siteniz.com) kullanmak, sağlayıcı değiştirirken görsel URL’lerini korumayı kolaylaştırabilir. Bunu bağlantı otoritesinin korunacağına dair bir garanti olarak değerlendirmeyin.
  • robots.txt: CDN alt alan adınız için ayrı bir robots.txt gerekebilir. Çoğu senaryoda engellemek istemezsiniz; fakat CDN’nin otomatik oluşturduğu teknik yolların (örneğin test path’leri) taranmamasını isteyebilirsiniz.
  • HTTPS ve HTTP/2/3: Görselleri de HTTPS üzerinden sunun. HTTP/2 ve HTTP/3 desteğini ayrıca değerlendirin; bunlar HTTPS’in alternatifi değildir. Sayfa ile görsellerin farklı HTTP sürümleri kullanması tek başına yavaşlama nedeni sayılmaz.

CDN Alt Alan Adı ile Görsel Site Haritası Uyumu

Önemli bir detay: Görsel site haritanızda sayfalarda kullandığınız güncel görsel URL’lerini tercih edin. Örneğin HTML içinde görselleri https://img.siteniz.com/urun1.webp şeklinde çağırıyorsanız, image sitemap’te de bu URL’yi kullanmak tutarlılık sağlar.

Aynı görsel için farklı alan adları veya protokoller kullanan URL’ler üretmek, URL yönetimini karmaşıklaştırabilir; bunun tek başına Google’ın tarama önceliğini düşürdüğü sonucuna varılamaz. Bu yüzden CDN geçişlerinde yapımızı gözden geçirirken, görsel site haritası üretiminde kullanılan base URL’i de güncellemeyi ihmal etmemek gerekiyor.

Cache-Control ve CDN Kuralları ile Görsel SEO’yu Desteklemek

Görseller için doğru Cache-Control başlıklarını ayarlamak, hem SEO hem maliyet tarafında kritik. İdeal senaryoda:

  • Versiyonlanmış dosya isimleriyle (örn. urun1.v3.webp) uzun süreli cache kullanmak,
  • Değişen görsellerde dosya adını veya önbellek anahtarına dahil edildiği doğrulanmış query string’ini güncelleyerek cache busting yapmak,
  • CDN tarafında HTML ve görseller için farklı cache politikaları tanımlamak gerekiyor.

Bu konuyu özellikle WordPress ve WooCommerce üzerinden örneklediğimiz CDN önbellekleme ve edge kuralları rehberinde görsel özelinde detaylandırıyoruz.

Görsel Site Haritası (Image Sitemap) ile Google’a Net Sinyaller Vermek

Görsel site haritası, sayfalarla ilişkili görsel URL’lerini arama motorlarına bildirerek keşfe yardımcı olur; tarama önceliği veya dizine eklenme garantisi vermez. Özellikle:

  • Büyük e-ticaret kataloglarında,
  • Stok fotoğraf veya ikon sitelerinde,
  • Tarif, gezi, mimari gibi görsel ağırlıklı bloglarda

görsel site haritası, başka yollarla keşfedilmesi zor görselleri bildirmek için yararlı olabilir. Google Görseller trafiğine etkisi, görsellerin taranabilirliği ve içerikle ilişkisi gibi başka etkenlere de bağlıdır.

Görsel Site Haritası Nasıl Yapılandırılır?

Image sitemap’ler genellikle ya mevcut sitemap.xml’in içine gömülü şekilde, ya da ayrı bir dosya (örneğin image-sitemap.xml) olarak hazırlanır. Aşağıdaki örnek, tek bir sayfanın görsel kaydını gösteren bir XML parçasıdır; tek başına kullanılabilecek tam bir sitemap dosyası değildir:

<url>
  <loc>https://www.siteniz.com/urun/ayakkabi-123</loc>
  <image:image>
    <image:loc>https://img.siteniz.com/urunler/ayakkabi-123.webp</image:loc>
  </image:image>
</url>

Burada dikkat etmeniz gerekenler:

  • URL’ler mutlaka mutlak (absolute) olmalı.
  • CDN alt alan adınız kullanılıyorsa, image:loc içinde de aynı alt alan adını kullanmalısınız.
  • Google, image:title ve image:caption etiketlerini görsel sitemap belgelerinden kaldırdı; yeni dosyalarda bunlara dayanmayın. Her sayfa URL kaydında en fazla 1.000 image:image öğesi kullanabilirsiniz.
  • Görsel başka bir alan adında veya CDN alanında barınıyorsa ilgili alanların Search Console doğrulamasını ve robots.txt erişimini kontrol edin.

robots.txt ve standart site haritası yapılandırmasını görüntü tarafıyla birlikte ele aldığımız robots.txt ve sitemap.xml doğru kurulumu rehberine mutlaka göz atın; görsel site haritalarını da o mimariye nasıl entegre edeceğinizi daha net göreceksiniz.

Görsel Site Haritasını Ne Sıklıkta Güncellemelisiniz?

Görselleriniz sık değişiyorsa veya her gün yeni ürün/gönderi ekliyorsanız, görsel site haritasının otomatik ve düzenli güncellenmesi gerekiyor. Burada tipik yaklaşım:

  • CMS tarafında (WordPress, Laravel admin, özel panel vb.) içerik veya görsel eklendiğinde, değiştirildiğinde ya da silindiğinde sitemap güncellemesini tetiklemek,
  • ve/veya sunucu tarafında cron job ile periyodik olarak sitemap dosyalarını yeniden oluşturmak.

cron job’ları güvenli ve kontrollü kurmak için Linux tarafında neleri gözden geçirmeniz gerektiğini, Linux crontab en iyi uygulamalar rehberimizde detaylı anlattık. Görsel site haritası üretimi de aslında tam olarak bu kategoride: düzenli ama kontrolsüz büyümemesi gereken bir görev.

Hosting Tarafında Görsel Sitemap Dosyalarının Yönetimi

Çok büyük sitelerde görsel site haritaları tek dosya olmaktan çıkar, parçalı (index) yapıya geçersiniz. Örneğin:

  • image-sitemap-index.xml: parça dosyalarını listeleyen sitemap index.
  • image-sitemap-1.xml: ilk sayfa URL kayıtları ve bunlara bağlı görseller.
  • image-sitemap-2.xml: kalan sayfa URL kayıtları ve bunlara bağlı görseller.
  • Her parça hem en fazla 50.000 sayfa URL kaydı hem de sıkıştırılmamış en fazla 50 MB dosya boyutu sınırına uymalıdır. Görsel öğeleri dosyayı büyüttüğü için 50.000 kayda ulaşmadan da bölmeniz gerekebilir. Buradaki URL sayısı, her sayfanın altındaki ayrı görsel URL sayısıyla aynı değildir; sayfa başına 1.000 görsel sınırını da ayrıca uygulayın.

Bu durumda hosting tarafında:

  • Sitemap’lerin tutulduğu dizine gereksiz yazma/okuma izinleri verilmemeli,
  • Statik dosya sunucusunda (Nginx/Apache) sitemap’ler için güncelleme sıklığına uygun önbellek süreleri belirlenmeli; dosya değiştiğinde eski kopyaların ne zaman yenileneceği planlanmalı,
  • Disk kullanımını izleyerek gereksiz eski sitemap dosyalarının temizlenmesi için bir bakım politikası belirlenmeli.

Hosting Seviyesinde İnce Ayarlar: HTTP/2/3, TTFB ve Disk Performansı

Görsel SEO deyince sadece format ve site haritası konuşmak eksik kalır. Arka planda web sunucusu, disk tipi, ağ kapasitesi ve HTTP protokol sürümleri de doğrudan oyunun içinde.

HTTP/2 ve HTTP/3 ile Paralel İstek Yönetimi

Modern tarayıcılar HTTP/2 ve HTTP/3 ile aynı bağlantı üzerinden çok sayıda görsel isteğini paralel taşıyabiliyor. Bu da özellikle çok görselli sayfalarda yararlı olabilir; etkisi bağlantı koşullarına ve sunum mimarisine bağlıdır. Yapılandırmada değerlendirilecek noktalar:

  • Doğrudan origin’den sunum yapıyorsanız hosting ortamınızın HTTP/2 ve mümkünse HTTP/3 desteği,
  • SSL yapılandırmanızın modern şifre kümeleriyle uyumlu olması,
  • CDN kullanıyorsanız, tarayıcıya bakan uçtaki protokol desteğinin ve CDN–origin bağlantısındaki protokol seçiminin ayrı ayrı değerlendirilmesi.

Bu konuda ayrıntılı bir kontrol listesine ihtiyacınız varsa, HTTP/2 ve HTTP/3 desteğinin SEO ve Core Web Vitals’a etkisini detaylı incelediğimiz rehberimiz tam size göre.

Disk Performansı, IOPS ve Büyük Görsel Kütüphaneleri

On binlerce ürün görseli, orijinal ve optimize edilmiş haller, farklı boyut varyasyonları… Bu dosyaların okunması ve dönüştürülmesi, erişim desenine ve önbellek kullanımına bağlı olarak disk üzerinde rastgele okuma/yazma yükü oluşturabilir. Özellikle:

  • Büyük e-ticaret siteleri,
  • Haber/medya portalları,
  • Portfolyo ve fotoğrafçılık siteleri

için kullandığınız depolama türü kritik hale geliyor. NVMe SSD, SATA SSD ve HDD farklarını; web hosting, yedek ve arşiv senaryoları üzerinden karşılaştırdığımız disk seçimi rehberimiz görsel ağırlıklı siteler için hangi yolu tercih etmeniz gerektiğini netleştirmenize yardımcı olacaktır.

Görsel Ağırlıklı Siteler İçin Özel Hosting Stratejisi

Görsel odaklı projelerde yük ve maliyet gereksinimlerine göre şu üç bileşen birlikte değerlendirilebilir:

  • Disk I/O ihtiyacına uygun bir origin (VPS veya dedicated sunucu seçerken NVMe SSD gibi disk seçeneklerini ve planın IOPS sınırlarını değerlendirmek),
  • Üzerine binen yükü azaltmak için iyi kurgulanmış bir CDN,
  • Arşiv veya orijinal görselleri mümkünse ayrı bir depolama (object storage vb.) üzerinde tutmak.

Bu mimariyi hem teknik hem maliyet açısından tartıştığımız görsel ağırlıklı siteler için hosting stratejisi rehberimizde pratik örneklerle nelerin değiştiğini anlattık. Özellikle WebP/AVIF dönüşümünü origin’de mi, CDN’de mi yapacağınıza karar verirken o makaledeki senaryolar çok işe yarıyor.

WordPress ve Diğer CMS’lerde Pratik Uygulama Örnekleri

WordPress ve WooCommerce için aşağıdaki iki varsayımsal senaryo, bu stratejinin nasıl kurulabileceğini gösterir. Ardından PHP/Laravel tabanlı özel uygulamalar için bir tasarım seçeneği ele alınır.

Senaryo 1: WordPress + WooCommerce + CDN + WebP/AVIF

Örnek bir WooCommerce mağazası için şu akış tasarlanabilir:

  1. Ürün görselleri önce orijinal formatta (örneğin yüksek kaliteli JPEG) yükleniyor.
  2. WordPress içinde kullanılan bir eklenti veya sunucu tarafı script, arka planda WebP ve AVIF versiyonlarını üretiyor.
  3. CDN, img.siteniz.com alt alan adı üzerinden bu görselleri cache ediyor.
  4. Temada <picture> etiketi kullanılarak AVIF → WebP → JPEG sıralı fallback tanımlanıyor.
  5. WooCommerce ürün ve kategori sayfaları, otomatik üretilen bir image sitemap’e ekleniyor.

Bu yapıyı kurarken, sunucu tarafı optimizasyonları (PHP-FPM, OPcache, MySQL/Redis vb.) da hesaba katmanız gerekiyor. WordPress için sunucu ayarlarını nasıl kademeli optimize edeceğinizi WordPress için sunucu tarafı optimizasyon rehberinde detaylarıyla anlattık.

Senaryo 2: WordPress Medyayı S3/Uyumlu Depolamaya Taşıma

Görsel sayısı milyonları bulan projelerde tüm medyayı tek VPS’in diskinde tutmak, kapasite ve yönetim gereksinimleri açısından sınırlayıcı olabilir. Bir seçenek, medyayı S3 uyumlu bir object storage’a taşımak ve önüne bir CDN katmanı koymaktır.

Bu mimaride dikkat edilmesi gerekenler:

  • WordPress içinde medya URL’lerinin tam alan adıyla (örneğin https://media.siteniz.com/...) güncellenmesi,
  • Image sitemap’lerin de aynı URL’leri kullanacak şekilde yeniden üretilmesi,
  • CDN önbelleği ile origin (S3/object storage) arasındaki cache invalidation akışının iyi kurgulanması.

Tüm bu adımları teknik detaylarıyla anlattığımız WordPress medyanı S3’e taşıma rehberimiz, görsel SEO tarafını bozmadan altyapıyı nasıl ölçekleyebileceğinize dair net bir yol haritası sunuyor.

Laravel, Headless ve Özel Uygulamalarda Yaklaşım

Laravel veya benzeri framework’lerle geliştirilen headless yapılarda aşağıdaki bileşenlerden oluşan bir mimari tasarlanabilir:

  • Medya yönetimini API katmanından bağımsız tutan bir storage katmanı (local + S3 uyumlu depolama hibriti),
  • Görsel dönüşümlerini kuyruğa atan ve arka planda çalışan queue job’ları,
  • Front-end tarafında (React, Next.js, Vue, Nuxt vb.) <picture> ve sizes/srcset destekli bileşenler.

Bu tür mimarilerde en kritik nokta, görsel URL’lerinin istikrarlı olması ve image sitemap üretiminin veritabanındaki kayıtlarla birebir senkron çalışması. Endpoint veya path yapılarında yaptığınız her değişikliğin image sitemap’e de yansıdığından emin olmalısınız.

Bu Yapı İçin Hangi Altyapı Bileşenleri Değerlendirilmeli?

Görsel ağırlıklı projelerde görsel SEO ve hosting altyapısını birlikte planlarken, iş yüküne göre şu bileşenler değerlendirilebilir:

  • Görsel dönüşüm job’larını ve CDN ile konuşan uygulamayı taşıyan NVMe SSD’li VPS veya dedicated sunucular,
  • HTTP/2 ve HTTP/3 destekli, modern TLS yapılandırmasına sahip web sunucuları,
  • Görsel cache ve CDN loglarını takip eden izleme ve alarm sistemleri,
  • Görsel site haritaları, cron job’lar ve log analizleri için ayrı test/staging ortamları.

Mevcut görsel yapıyı analiz ederken WebP/AVIF dönüşümü, CDN alt alan adı planlaması ve image sitemap stratejisini birlikte ele alın. SEO ajansınızın önerdiği adımları da sunucu kaynakları ve bakım gereksinimleri açısından değerlendirerek gerçekçi ve sürdürülebilir bir mimari planlayın.

Sonuç ve Uygulanabilir Yol Haritası

Görsel SEO’yu gerçekten ileri taşımak istiyorsanız, tek tek alt etiketleri düzeltmekten çok daha fazlasına ihtiyacınız var. WebP/AVIF gibi modern formatlar ve uygun bir CDN yapılandırması görsel yükleme performansını iyileştirebilir; güncel bir görsel site haritası ise görsellerin keşfini destekleyebilir. Bunlar tüm Core Web Vitals metriklerinde iyileşme veya Google Görseller trafiğinde artış garantisi değildir; etkilerini ölçerek değerlendirin.

Pratikte izleyebileceğiniz özet yol haritası şöyle:

  1. Mevcut görsellerinizi analiz edin: Boyut, format, LCP’yi etkileyen kritik görseller.
  2. WebP/AVIF dönüşümü için bir boru hattı planlayın; dönüşümü sunucuda mı, CDN’de mi yapacağınıza karar verin.
  3. Görselleri CDN üzerinden sunuyorsanız, kendi alt alan adınızı (img.siteniz.com gibi) kullanma seçeneğini URL sürekliliği ve yönetim ihtiyaçlarınıza göre değerlendirin.
  4. Image sitemap yapınızı tasarlayın; gerekiyorsa parçalı (index) yapıya geçin.
  5. Sitemap üretimini cron job veya CMS hook’ları ile otomatikleştirin.
  6. HTTP/2/3, disk performansı ve bant genişliği tarafında hosting altyapınızı gözden geçirin.

Seçtiğiniz hosting planının kaynaklarını ve destek kapsamını bu yol haritasıyla karşılaştırın; altyapı analizi, kurulum ve bakım sorumluluklarını netleştirin. Hedef, görsellerinizi arama motorları ve kullanıcılar için hızlı, tutarlı ve sürdürülebilir şekilde sunmak olmalı.

Yeni bir proje planlıyor, mevcut sitenizi yeniden platforma taşıyor veya sadece görsel tarafını toparlamak istiyorsanız; görsel SEO ve hosting altyapısı mimarisini daha yayına almadan netleştirin.

Sıkça Sorulan Sorular

WebP ve AVIF, görsele ve kodlama ayarlarına bağlı olarak JPEG/PNG’den daha küçük dosyalar üretebilir. LCP öğesi bir görselse aktarım yükünün azalması LCP’yi iyileştirebilir; ancak sıralama veya trafik artışı garanti değildir. CLS için görsel alanını önceden ayırmak gerekir. Format fallback’leri ve önbellekte format ayrımı da doğru kurulmalıdır.

CDN alt alan adı kullanmak tek başına SEO sorunu değildir; CDN kullanmak için ayrı alt alan adı da şart değildir. Kendi alt alan adınız, sağlayıcı değiştirirken URL’leri korumayı kolaylaştırabilir; otorite veya sıralama garantisi vermez. Görsel site haritasındaki URL’leri, robots.txt erişimini, Search Console doğrulamasını, HTTPS ve önbellek kurallarını birlikte kontrol edin.

Zorunlu değildir; özellikle büyük kataloglarda ve görsel ağırlıklı sitelerde başka yollarla keşfedilmesi zor görselleri bildirmeye yardımcı olabilir. Sayfalarla ilişkili görsel URL’lerini bildirir, tarama önceliği veya dizine eklenme garantisi vermez. Google’ın belgelerinden kaldırılan image:title ve image:caption etiketlerine dayanılmamalıdır.

Güncelleme sıklığını içerik ve görsel değişikliklerine göre belirleyin. Ekleme, değiştirme veya silme işlemlerinde CMS tetikleyicileriyle ya da periyodik cron görevleriyle üretimi otomatikleştirebilirsiniz. Her dosya en fazla 50.000 sayfa URL kaydı ve sıkıştırılmamış 50 MB sınırına uymalıdır. Ayrıca her sayfa kaydında en fazla 1.000 görsel bulunabilir.

Seçimi iş yükü ve maliyet gereksinimlerine göre yapın. Disk I/O ihtiyacına uygun bir origin, gerektiğinde NVMe SSD’li VPS veya dedicated sunucu, uygun CDN ve orijinaller için ayrı nesne depolama birlikte değerlendirilebilir. Planın IOPS sınırlarını, bant genişliğini, protokol desteğini ve bakım sorumluluklarını kontrol edin; yazı belirli bir DCHost planının kaynak veya destek kapsamını doğrulamıyor.
↑