Çok dilli bir sitenin içerik varlıkları yalnızca HTML sayfalardan oluşmaz. Teknik raporlar, ürün katalogları, kullanım kılavuzları, yasal belgeler — bunların önemli bir bölümü PDF formatında yayınlanır ve birden fazla dil sürümüne sahip olabilir. Bir İngilizce teknik kılavuzun Almancası ve Japonca sürümü ayrı URL'lerde duruyor, Google bu dosyaları tarayıp indeksliyorsa, hreflang sorusu kaçınılmaz biçimde gündeme gelir.
Ama PDF'ler HTML sayfaların teknik olanaklarını taşımaz. <head> bölümü yoktur; dolayısıyla <link rel="alternate" hreflang="x"> etiketi yerleştirilemez. Hreflang'ın standart uygulaması bu dosya türünde doğrudan geçersizdir. Bu kısıt, PDF'ler için yalnızca iki yolun açık olduğu anlamına gelir: HTTP yanıt başlıkları ve XML sitemap. Her iki yöntem de işe yarar; ama hangisinin ne zaman tercih edilmesi gerektiği ve hangi koşullarda hreflang uygulamanın anlamsız hale geldiği, pratikte çoğu zaman yeterince tartışılmaz.
PDF hreflang meselesi yalnızca teknik bir uygulama sorusu değildir. Önünde kısmen stratejik bir soru yatar: bu PDF'ler gerçekten arama motorları tarafından dil bazında hedeflenmeli mi? Bu sorunun yanıtı hayırsa, uygulama yükü boşa harcanmış demektir. Evetse, hangi yöntemin hangi altyapıyla uygulanabileceği teknik değerlendirmeyi belirler.
PDF'ler için neden farklı bir yaklaşım gerekiyor?
HTML sayfalarında hreflang bildirimi sayfanın içinde yaşar — Googlebot sayfayı taradığında etiketi doğrudan içerikle birlikte alır. PDF dosyalarında böyle bir yapı yoktur. PDF, belge formatının kendi iç standardını taşır; bu standartta HTTP yanıt başlıklarını ya da XML sitemap'i karşılayan bir hreflang mekanizması bulunmaz. Dosyanın kendisine hiçbir şey eklenmez; bildirim tamamen dış kaynaklara taşınır.
Bu dışsallık önemli bir sonuç doğurur: PDF'in hreflang bilgisi ile PDF'in kendisi birbirinden bağımsız olarak yaşar. HTML sayfasında sayfa kaldırıldığında etiket de gider; PDF'de ise dosya kaldırılsa da HTTP başlık yapılandırması veya sitemap kaydı yerinde durabilir. Senkronizasyon riski HTML yönteminden çok daha yüksektir ve bu risk sessizdir — Search Console'da bir uyarı olarak değil, yanlış dil sürümünün yanlış pazarda sıralanmasıyla kendini gösterir.
Üç hreflang yöntemini karşılaştırdığımızda HTTP header yönteminin tam olarak bu senaryo için tasarlandığını görürüz: HTML olmayan içerikler. PDF hreflang uygulaması, HTTP header yönteminin gerçek anlamda zorunlu olduğu nadir durumlardan biridir. Sitemap yöntemi ise bu zorunluluğun alternatifi olarak çalışır — ayrı bir sunucu yapılandırması gerekmeden merkezi bildirim sağlar.
Google bir PDF'i taradığında ne görür?
Google, PDF dosyalarını yıllar içinde giderek daha iyi işler hale geldi. Metin tabanlı PDF'lerdeki içeriği okur, başlıkları ve paragraf yapısını yorumlar, hatta tablo içeriklerini kısmen çıkarır. Taranan PDF'ler arama sonuçlarında görünür; URL'leri .pdf uzantısıyla SERP'te listelenebilir. Büyük kurumların teknik dokümanları, akademik makaleler, yıllık raporlar bu şekilde arama trafiği alır.
Ama PDF taraması HTML taramasından önemli farklılıklar taşır. Birincisi, Googlebot PDF'i taramak için önce erişilebilir olması gerekir — şifreli veya erişim kısıtlı PDF'ler taranamaz. İkincisi, görüntü tabanlı PDF'ler — yani metin katmanı olmayan, taranmış belgelerden üretilen dosyalar — içerik olarak işlenemez; yalnızca bir dosya olarak görülür. Üçüncüsü, PDF'lerin tarama önceliği HTML sayfalardan düşüktür; büyük sitemap'lerin içinde kaybolabilir ve taranma sıklıkları öngörülemez.
Hreflang açısından kritik nokta şudur: Google PDF'in hreflang bilgisini yalnızca HTTP yanıt başlığında veya sitemap üzerinden alabilir. Bu bildirim olmadığında, farklı dil sürümlerinin birbirleriyle ilişkisini bağımsız olarak kuramaz. İngilizce PDF ile Almanca PDF aynı belgenin farklı dil sürümleri olsa bile, Google bunu yalnızca URL benzerliğinden çıkarmaya çalışır — bu da güvenilir bir mekanizma değildir. Açık bir hreflang bildirimi olmadan dil hedefleme belirsizleşir.
HTTP header ile hreflang: sunucu yapılandırması nasıl kurulur?
HTTP header yönteminde sunucu, PDF dosyasına yapılan her isteğe yanıt olarak Link başlığı ekler. Bir Türkçe PDF için yapılandırma şöyle görünür: sunucu Link: <https://example.com/rapor-tr.pdf>; rel="alternate"; hreflang="tr", <https://example.com/rapor-en.pdf>; rel="alternate"; hreflang="en" başlığını döndürür. Her dil sürümü bu listeye eklenir; karşılıklı referans kuralı burada da geçerlidir — her dosya diğer tüm sürümlere işaret etmelidir.
Apache yapılandırmasında bu .htaccess veya sanal sunucu bloğu içinde Header set Link direktifiyle yapılır. Nginx'te add_header Link ile eklenir. Her iki durumda da URL eşleşmesi dosya bazında veya dizin bazında tanımlanabilir. 50 PDF dosyasına ayrı ayrı başlık eklemek yönetilebilir; 500 dosyada bu yaklaşım hızla karmaşık hale gelir. Dinamik olarak üretilen PDF'lerde ise başlık uygulama katmanından — PHP, Python, Node.js — eklenebilir; bu durumda yapılandırma dosyası yerine kod üzerinden yönetilir.
HTTP header yönteminin kritik dezavantajı görünmezliktir. Bir hata olduğunda — yanlış URL, eksik dil, karşılıklı referans kopukluğu — bunu fark etmek için HTTP yanıt başlığını incelemek gerekir. Kaynak kodu açmak yeterli değildir; başlık orada görünmez. curl -I komutu veya tarayıcı geliştirici araçlarının ağ sekmesi bu kontrolü sağlar. Hreflang hata tespitinde HTTP header bildirimleri en çok gözden kaçan katmandır; denetim süreçleri bunu sıkça atlar.
Sitemap yoluyla PDF hreflang: operasyonel denge
XML sitemap yöntemi PDF dosyaları için HTTP header'a makul bir alternatif sunar. Sitemap'te PDF URL'leri HTML sayfalarla aynı sözdiziminde listelenir; xhtml:link elementleri her dosyanın dil alternatifleri kümesini tanımlar. Sunucu yapılandırmasına dokunmak gerekmez; hreflang bildirimi tamamen sitemap katmanında yaşar.
Bu yaklaşım özellikle iki durumda avantajlıdır. Birincisi, sunucu yapılandırmasına erişim kısıtlıysa — paylaşımlı hosting, CDN katmanında kontrol eksikliği veya devops süreçlerinin yavaşlığı. İkincisi, PDF'lerin sayısı çoksa ve merkezi yönetim tercih ediliyorsa. Uluslararası sitemap hazırlamanın standart kuralları PDF'ler için de geçerlidir: 50.000 URL ve 50 MB sınırı aşılmamalı, büyük kataloglarda sitemap index dosyası kullanılmalıdır.
Sitemap yönteminin PDF'lere özgü bir riski vardır: PDF dosyaları HTML sayfalardan daha sık değiştirilmeden silinir ve yeniden adlandırılır. Bir belge revize edildiğinde eski URL kaldırılır, yeni URL eklenir — ama sitemap güncellenmezse eski URL hreflang kümesinde kalmaya devam eder. Google bu durumu bir hata olarak işaretler; karşılıklı referans kopukluğu oluşur. Sitemap ve dosya yönetiminin aynı iş akışında senkronize tutulması, PDF tabanlı bir sitemap hreflang yapısının sürdürülebilirliği için zorunludur.
Hreflang değerini hak eden PDF türleri
Her çok dilli PDF için hreflang uygulamak gerekli değildir. Bazı PDF'ler organik arama trafiği almaz veya almayı hedeflemez; bu dosyalar için hreflang uygulama yükü boşa harcanmış operasyonel çabadır.
Hreflang uygulamanın anlamlı olduğu PDF türleri belirli özellikleri paylaşır: kullanıcıların doğrudan arama motorlarından bulmasını beklediğiniz belgeler, konuya özgü sorgularla erişilebilir içerikler, birden fazla dilde düzenli güncellenen ve uzun süreli yayında kalan dosyalar. Teknik veri sayfaları, standart raporlar, kapsamlı kılavuzlar bu kategoriye girer. Bu belgeler için hreflang, arama motorunun doğru dil sürümünü doğru pazarda göstermesini sağlar.
Hreflang uygulamanın anlamsız olduğu durumlar da net biçimde çizilebilir. Yalnızca dahili dağıtım için hazırlanan belgeler, tekrarlayan işlem formları, çok kısa süreli geçerliliği olan belgeler ve zaten noindex etiketiyle arama motorlarından gizlenen dosyalar bu kapsama girer. Ayrıca içeriği yalnızca rakamsal verilerden oluşan, metinsel arama değeri taşımayan dosyalar da hreflang yatırımını karşılamaz. Arama motorunun o PDF'i hangi sorguda döndüreceğini öngöremiyorsanız, dil hedeflemenin değeri sorgulanabilir.
Özel bir senaryo: aynı belgenin HTML ve PDF sürümleri bir arada yayınlanıyorsa, önce HTML sayfası için hreflang kurulmalı ve PDF sürümlerinin canonical'ı HTML sayfalarına işaret etmesi düşünülmelidir. Bu yapıda PDF'ler bağımsız dil hedefleme gerektirmez; canonical yönlendirmesi dil sinyalini HTML katmanına taşır.
Canonical ve noindex: PDF'lerde sık atlanan iki karar
Hreflang uygulamadan önce — ve hatta yerine — PDF'ler için iki temel karar verilmesi gerekir: bu dosyanın indekslenmesini istiyor musunuz ve canonical olarak neyi işaret etmesini istiyorsunuz?
PDF dosyalarına canonical etiketi HTML sayfaları gibi yerleştirmek mümkün değildir; bu bildirim de HTTP header üzerinden yapılır. Link: <https://example.com/sayfa.html>; rel="canonical" başlığı, PDF'in belirli bir HTML sayfasının türev sürümü olduğunu bildirir. Bu yapı kurulduğunda Google, içerik sinyalini canonical URL'de toplar; PDF bağımsız bir arama sonucu olarak öne çıkmaz ama içerik otoritesini HTML sayfasına aktarır.
Noindex kararı da aynı kanaldan iletilir: X-Robots-Tag: noindex HTTP başlığı PDF'in arama sonuçlarında görünmesini engeller. Bu, yalnızca dahili kullanım için hazırlanan ama erişime açık URL'lerde duran dosyalar için yaygın bir tercih olmalıdır. Noindex olan bir PDF için hreflang uygulamak anlamsızdır; indekslenmeyecek bir dosyanın dil hedeflenmesi yapılmaz.
Pratikte bu üç kararın — hreflang, canonical, noindex — birlikte ve tutarlı biçimde verilmesi gerekir. Hreflang uygulanmış ama aynı zamanda başka bir sayfaya canonical işaret eden bir PDF, çelişen sinyaller gönderir. Noindex olan bir PDF hreflang kümesine dahil edilirse kümenin bütünlüğü bozulur; Google diğer küme URL'leri için de güvensizlik yaratabilir.
PDF'lerde hreflang, HTML sayfalarına kıyasla daha dar bir kullanım alanı olan, daha yüksek operasyonel dikkat gerektiren ve uygulanmadan önce stratejik değerlendirme isteyen bir yapıdır. İki teknik yol net: HTTP header ya da sitemap. Hangisini seçeceğinizi altyapı erişiminiz ve PDF sayısı belirler. Ama daha temel soru şudur: o PDF arama motorlarında dil bazında sıralanmalı mı? Bu soruya verilecek yanıt, teknik uygulama kararından önce gelir.
Çok dilli bir siteyi yönetiyorsanız PDF varlıklarını sistematik biçimde gözden geçirmek, her birinin indeksleme ve dil hedefleme statüsünü netleştirmek, teknik yükü gerçekten değer üreten dosyalara odaklamak uzun vadede çok daha verimli bir yaklaşımdır. Hreflang uygulanmayan ama indekslenen PDF'ler için bile canonical kararı verilmesi gerekir; bu karar atlandığında Google kendi yorumunu yapar ve bu yorum her zaman öngörülebilir değildir.