Yapısal Çoklu Dil Destekli (Multi-Language) Site Haritası Mimarisi

Bir web sitesini ikinci bir dile açmak ilk bakışta birkaç yeni URL oluşturmak kadar basit görünebilir. Ancak birkaç dil, farklı ülkeler, değişen para birimleri ve bölgesel içerikler devreye girdiğinde teknik yapı hızla daha fazla planlama ister. Yapısal Çoklu Dil Destekli (Multi-Language) Site Haritası Mimarisi tam olarak bu noktada önem kazanır. Buradaki amaç yalnızca XML dosyasına URL eklemek değildir. Asıl amaç, arama motorlarının hangi URL'nin hangi dil ve pazara ait olduğunu, hangi sayfaların birbirinin karşılığı olduğunu ve hangi sürümün indekslenmesini istediğinizi açık biçimde anlayabileceği tutarlı bir sistem kurmaktır.

Yaklaşık on yıldır teknik web projelerinde gördüğüm en yaygın sorun, sitemap, hreflang ve canonical yapılarını birbirinden bağımsız özellikler gibi ele almaktır. Oysa çok dilli web sitesi XML sitemap yapısı nasıl oluşturulur sorusunun doğru cevabı URL mimarisinden başlar ve içerik yayın süreciyle devam eder. Multi-language sitemap hreflang etiketleri nasıl yapılandırılır konusu da yalnız XML üretmekle çözülemez. Dil seçici, canonical, internal linkler, yayın durumu ve sitemap aynı veri modelinden beslenmelidir. Bu rehberde bu parçaların nasıl birlikte çalışması gerektiğini geliştirici gözüyle ele alacağız.

Çok Dilli Site Haritası (Multilingual Sitemap) Nedir?

Çok dilli site haritası, farklı dil veya bölge sürümlerine sahip URL'lerin arama motorları tarafından keşfedilmesini kolaylaştıran yapılandırılmış XML mimarisidir. Standart sitemap yalnızca erişilebilir URL listesini verebilirken çok dilli bir yapı locale ilişkilerinin doğru yönetilmesini de gerektirir. Burada sitemap dosyasının kendisinden daha önemli konu hangi URL'lerin sitemap'e girmeye uygun olduğudur. Canonical olmayan, yönlenen, noindex taşıyan veya henüz yayına çıkmamış çeviriler sitemap'e alınmamalıdır. Sağlıklı model, gerçek kullanıcıya açık ve indekslenmesini istediğiniz URL'leri sistematik biçimde üretir.

XML Sitemap Nedir?

XML sitemap, arama motorlarına sitenizde keşfedilmesini istediğiniz URL'leri yapılandırılmış biçimde sunar. Büyük projelerde crawler'ın yalnız internal linklere bağlı kalmadan önemli URL'leri bulmasına yardımcı olur. Sitemap bir içerik envanteri gibi düşünülebilir ancak sitenin gerçek veri kaynağı olmamalıdır. Asıl veriler CMS, ürün sistemi veya locale registry içinde tutulmalıdır. Sitemap bu verilerden otomatik olarak üretilen bir çıktı olduğunda bakım maliyeti ciddi biçimde azalır.

Çok Dilli XML Sitemap Nedir?

Çok dilli XML sitemap, farklı locale sürümlerinin aynı içerik ailesi içinde tanımlanmasını sağlayabilir. Örneğin Türkçe bir hizmet sayfası ile İngilizce karşılığı aynı content entity altında eşleştirilir. XML içerisinde hreflang alternatifleri kullanılıyorsa iki sayfa arasındaki ilişkinin karşılıklı olması gerekir. Türkçe URL İngilizce URL'yi gösterirken İngilizce sürüm de Türkçe URL'yi göstermelidir. Böylece sistem yalnız URL keşfi yapmaz, aynı içeriğin uluslararası sürümleri arasındaki bağlantıyı da ifade eder.

Sitemap Arama Motorlarına Ne Söyler?

Sitemap esas olarak hangi URL'lerin sitenin yayınlanan ve keşfedilmesini istediğiniz bölümüne ait olduğunu bildirir. Bir URL'nin sitemap içinde bulunması onun site sahibi açısından önemli ve geçerli görüldüğüne dair sinyallerden biridir. Bununla birlikte sitemap tek başına canonical, indexability veya içerik kalitesi problemlerini çözmez. URL 200 yanıt vermeli, indekslenebilir olmalı ve tercihen kendi canonical adresiyle tutarlı çalışmalıdır. Bu nedenle sitemap'i bağımsız XML dosyası yerine teknik SEO mimarisinin çıktısı olarak görmek daha sağlıklıdır.

Sitemap Bir Indexleme Garantisi midir?

Hayır, sitemap içerisinde bulunmak indekslenme garantisi vermez. Arama motoru URL'yi keşfettikten sonra sayfanın yanıt kodu, canonical sinyalleri, robots direktifleri, içerik niteliği ve diğer teknik göstergeleri birlikte değerlendirir. Örneğin sitemap'e eklenmiş bir URL noindex taşıyorsa iki farklı mesaj verilmiş olur. Benzer biçimde URL başka sayfaya canonical veriyorsa sitemap ile canonical sinyali çelişir. Bu yüzden sitemap başarısını yalnız gönderilen URL sayısıyla değil, gönderilen ve gerçekten indekslenen URL'lerin ilişkisiyle izlemek gerekir.

Çok Dilli Sitelerde Normal Sitemap Neden Yetersiz Kalabilir?

Normal sitemap farklı dillerdeki URL'leri listeleyebilir ancak bu URL'lerin birbirinin eşdeğer sürümleri olduğunu tek başına açıklamayabilir. Örneğin /tr/hizmetler/ ve /en/services/ adreslerinin aynı içerik ailesine ait olduğunu locale mapping olmadan sistematik biçimde yönetmek zorlaşır. Dil sayısı arttıkça manuel eşleştirme daha fazla hata üretir. Hreflang, canonical ve language switcher arasında ayrışma başladığında yanlış dil URL'sinin arama sonucunda görünmesi gibi sorunlar ortaya çıkabilir. Bu nedenle çok dilli sitelerde sitemap'in locale kayıt sistemiyle birlikte tasarlanması daha güvenli bir yöntemdir.

Multilingual ve Multi-Regional Site Arasındaki Fark

Multilingual ve multi-regional kavramları sık sık aynı anlamda kullanılır fakat teknik olarak farklı ihtiyaçları ifade eder. Multilingual yapı temel olarak birden fazla dili hedeflerken multi-regional yapı belirli ülke veya bölgeler için ayrı deneyimler oluşturur. İngilizce ve Türkçe sürümler multilingual örneğidir. ABD ve Birleşik Krallık için ayrı İngilizce sürümleri ise multi-regional yapıya örnek verilebilir. Çok dilli sitelerde sitemap index dil ve bölge URL yapısı nasıl olmalı sorusuna doğru yanıt verebilmek için önce bu ayrımı netleştirmek gerekir.

Multilingual Site

Multilingual site aynı marka veya içeriğin birden fazla dilde sunulduğu yapıdır. Türkçe için /tr/, İngilizce için /en/ gibi klasörler kullanılabilir. Burada temel farklılık dil olduğu için hreflang değerleri tr ve en seviyesinde tutulabilir. İçeriklerin gerçekten çevrilmiş olması da önemlidir. Yalnız navigasyonu çevirip ana içeriği aynı bırakmak sağlam bir yerelleştirme modeli oluşturmaz.

Multi-Regional Site

Multi-regional site aynı dili kullanan farklı pazarlara özel fiyat, ürün, teslimat veya içerik sunabilir. ABD için en-US, Birleşik Krallık için en-GB gibi locale değerleri kullanılabilir. Buradaki fark yalnız dil değildir. Ürün bulunabilirliği, para birimi ve hukuki içerikler de pazara göre değişebilir. Bu nedenle region bilgisinin gerçekten iş gereksinimi olduğunda kullanılması gerekir.

Hem Çok Dilli Hem Çok Bölgeli Site

Büyük uluslararası projelerde iki model birlikte bulunabilir. Örneğin Kanada için Fransızca ve İngilizce, başka bir pazar için yalnız İngilizce sunulabilir. Böyle bir yapıda yalnız dil koduna bakarak URL üretmek yeterli olmaz. Locale, market ve yayın durumu ayrı alanlar halinde tutulmalıdır. Mimari baştan bu modele göre tasarlanırsa yeni ülke veya dil eklemek çok daha kontrollü hale gelir.

Dil ile Ülke Hedeflemesini Birbirinden Ayırmak

Dil kullanıcının içeriği hangi dilde okuyacağını açıklar, ülke ise içeriğin hangi pazara göre düzenlendiğini ifade eder. Türkçe konuşan herkes Türkiye'de değildir ve İngilizce konuşan herkes ABD'de yaşamaz. Bu nedenle yalnız ülke üzerinden dil varsayımı yapmak yanlış yönlendirmelere yol açabilir. Aynı şekilde yalnız browser diline dayanarak kullanıcıyı zorunlu yönlendirmek de iyi bir kullanıcı deneyimi sunmayabilir. Kullanıcının locale seçimini değiştirebildiği açık bir yapı daha güvenlidir.

Mimariyi Locale Kavramı Üzerinden Kurmak

Pratik projelerde benim tercih ettiğim yaklaşım dili değil locale'i merkezi nesne olarak ele almaktır. Locale kaydı URL prefix'i, hreflang kodu, market, para birimi ve yayın durumunu birlikte taşıyabilir. Böylece sitemap generator ile language switcher aynı veriyi kullanır. Canonical ve hreflang üretimi de aynı kayda bağlanır. Yeni pazar eklenirken onlarca farklı dosyada manuel değişiklik yapmak yerine tek bir kayıt güncellenir.

Locale Nedir?

Locale, yalnız dil kodundan daha geniş bir kullanıcı ve pazar bağlamıdır. Sistem tasarımında dil, bölge, market ve gerektiğinde para birimi gibi alanları aynı kullanıcı deneyimi altında bir araya getirir. Örneğin en-US ile en-GB aynı dili kullanır ancak fiyatlandırma, yazım tercihleri ve sunulan hizmetler değişebilir. Locale kavramını doğru modellemek sitemap ve hreflang üretimini daha öngörülebilir hale getirir. Özellikle çok pazarlı e-ticaret ve içerik platformlarında bu ayrım ileride yapılacak geliştirmelerin temelidir.

Language

Language alanı içeriğin ana dilini ifade eder. SEO tarafında bu değer hreflang kodunun temel bölümünü oluşturur. Türkçe için tr, İngilizce için en gibi değerler kullanılabilir. Dil seçimi gerçek sayfa içeriğiyle uyumlu olmalıdır. Sadece URL'de bir dil kodu bulunması sayfanın o dile ait olması için yeterli değildir.

Region

Region belirli ülke veya bölge hedeflemesi gerektiğinde locale'e eklenir. Örneğin İngilizce içerik ABD ve Birleşik Krallık için farklı sürümlere sahipse en-US ve en-GB tercih edilebilir. Her dile zorla bölge eklemek doğru değildir. Bölge ancak gerçekten farklı kullanıcı deneyimi bulunduğunda anlamlıdır. Aksi halde gereksiz URL çoğalması ve bakım yükü oluşur.

Market

Market, teknik locale kodundan farklı bir iş kavramı olabilir. Bir market birden fazla dili destekleyebilir veya aynı dil birden fazla markette kullanılabilir. Ürün stokları, teslimat bölgeleri ve fiyat kuralları market düzeyinde değişebilir. Bu nedenle market verisini hreflang koduyla bire bir eşitlemek yerine ayrı alan olarak modellemek iyi sonuç verir. Böylece SEO ile ticari kurallar birbirine bağımlı hale gelmez.

Currency

Currency doğrudan hreflang'ın parçası değildir fakat pazar deneyiminin önemli alanlarından biridir. Aynı İngilizce içerik farklı bölgelerde USD, GBP veya CAD gösterebilir. E-ticaret projelerinde URL ve yapılandırılmış veri bu farklılıktan etkilenebilir. Currency değerinin locale registry içinde tutulması tutarlı fiyat çıktıları üretmeyi kolaylaştırır. Ancak para birimi değişiyor diye otomatik olarak yeni hreflang sürümü oluşturmak doğru yaklaşım değildir.

Locale ile Dil Aynı Şey midir?

Hayır, locale ve dil aynı şey değildir. Dil yalnızca içeriğin hangi dilde olduğunu ifade ederken locale daha geniş bağlama sahiptir. Örneğin en genel İngilizceyi, en-US ise ABD pazarına yönelik İngilizce sürümü gösterebilir. Bu fark URL mimarisi tasarlanırken önemlidir. Locale'i doğru modellemek ileride gereksiz URL yeniden yapılandırmalarını önleyebilir.

Örnek Locale'ler

Locale kodlarını seçerken gerçek içerik stratejinizi temel almak gerekir. Her olası kombinasyonu üretmek yerine yalnız yayınlanan ve kullanıcıya sunulan sürümler oluşturulmalıdır. Sistem tarafında locale kodlarının tek bir mapping tablosundan gelmesi yazım hatalarını önler. CMS'nin kullandığı dahili kod ile SEO tarafındaki hreflang değeri farklıysa açık eşleme yapılmalıdır. Bu yaklaşım özellikle çok sayıda dili yöneten projelerde bakım kolaylığı sağlar.

tr

tr genel Türkçe içerik sürümünü temsil eder. Yalnız Türkiye'deki kullanıcılarla sınırlı olmak zorunda değildir. İçerik belirli bir ülkeye göre farklılaşmıyorsa yalnız dil kodu yeterli olabilir. URL mimarisinde /tr/ gibi açık bir prefix kullanılabilir. Bu yapı hem kullanıcı hem geliştirici açısından anlaşılırdır.

en

en genel İngilizce sürümü tanımlamak için kullanılabilir. Belirli bir ülkeye ait olmayan içerikler için pratik bir seçenektir. Bölgesel sürümler de bulunuyorsa genel İngilizce bir catch-all sürüm olarak değerlendirilebilir. Bunun gerçekten yayınlanmış bağımsız bir sayfa olması gerekir. Var olmayan bir generic sürümü yalnız hreflang doldurmak amacıyla üretmemek gerekir.

en-US

en-US ABD pazarına yönelik İngilizce sürümünü ifade eder. Fiyat, ürün bulunabilirliği veya hukuki içerikler gibi alanlar ABD'ye göre değişebilir. Böyle bir sürümün ayrı URL'si varsa hreflang cluster içinde gerçek alternatif olarak tanımlanabilir. Canonical adresi de normal koşullarda kendi locale URL'si olmalıdır. Başka bir İngilizce bölgesel sürüme canonical vermek hreflang sinyaliyle çatışabilir.

en-GB

en-GB Birleşik Krallık için İngilizce sürüm anlamına gelir. Aynı ürün veya hizmetin metni ABD sürümüne yakın olsa bile fiyat ve pazar bilgileri değişebilir. Arama motorlarının bu iki sürüm arasındaki ilişkiyi anlaması için doğru hreflang bağlantıları kullanılmalıdır. Her iki URL de gerçek kullanıcıya açık olmalıdır. Sitemap içerisinde canonical URL'lerin yer alması gerekir.

fr-CA

fr-CA Kanada'daki Fransızca deneyimi için kullanılabilecek locale örneğidir. Burada dil fr, bölge ise CA bilgisidir. Aynı sitede en-CA da bulunuyorsa iki sürüm içerik entity'si üzerinden eşleştirilebilir. Kullanıcı dil seçicisinde bu seçeneklere ulaşabilmelidir. UI ile sitemap farklı locale kayıtları kullanmamalıdır.

de-CH

de-CH İsviçre pazarı için Almanca içerik örneğidir. Yerel para birimi veya ülkeye özgü hizmet koşulları gibi farklar bulunabilir. Kod tek başına sayfanın doğruluğunu sağlamaz. İçerik, canonical, hreflang ve URL davranışı aynı hedeflemeyi desteklemelidir. Bu yüzden locale mimarisi bir isimlendirme konusu değil, veri bütünlüğü konusudur.

Çok Dilli SEO Mimarisi Hangi Katmanlardan Oluşur?

Sağlıklı çok dilli SEO mimarisi tek bir etikete veya XML dosyasına dayanmaz. URL Architecture, Content Localization, Canonical, Hreflang, XML Sitemap, Internal Linking, Language Switcher, Indexability ve Search Console Monitoring aynı sistemin farklı katmanlarıdır. Bunlardan biri diğerlerinden farklı veri kullanırsa zamanla drift oluşur. Örneğin language switcher yeni İngilizce URL'yi gösterirken sitemap eski URL'yi taşımaya devam edebilir. Bu nedenle Yapısal Çoklu Dil Destekli (Multi-Language) Site Haritası Mimarisi veri kaynağı, üretim mekanizması ve doğrulama testleriyle birlikte tasarlanmalıdır.

URL Architecture

URL Architecture locale'in kullanıcıya ve arama motoruna nasıl sunulduğunu belirleyen ilk katmandır. Alt klasör, subdomain veya ülke alan adı gibi farklı modeller kullanılabilir. Buradaki en önemli özellik URL'lerin kalıcı, benzersiz ve tahmin edilebilir olmasıdır. Kullanıcının seçtiği dil tek bir URL üzerinde cookie ile gizlice değişmemelidir. Her indekslenebilir locale sürümünün ayrı ve paylaşılabilir URL'si bulunmalıdır.

Content Localization

Localization yalnız kelime kelime çeviri değildir. Arama niyeti, terminoloji, para birimi, ölçü birimleri ve gerektiğinde pazara özel bilgiler de değişebilir. Aynı content entity altında bulunan iki sayfanın kullanıcı amacını benzer biçimde karşılaması gerekir. Birbiriyle ilgisiz sayfaları hreflang ile eşleştirmek doğru değildir. Teknik bağlantının arkasında gerçek içerik eşdeğerliği bulunmalıdır.

Canonical

Canonical bir URL grubunda tercih edilen temsilci URL konusunda sinyal verir. Çok dilli sayfalarda genel yaklaşım her yayınlanmış locale'in kendisini canonical göstermesidir. Türkçe sayfanın İngilizce karşılığına canonical vermek, Türkçe sürümün bağımsız indekslenmesini zayıflatabilir. Hreflang hedeflerinin de canonical URL'lere işaret etmesi tercih edilir. Böylece farklı teknik sinyaller aynı adres üzerinde birleşir.

Hreflang

Hreflang aynı veya karşılık gelen içeriğin farklı dil ve bölge sürümlerini ilişkilendirir. Yapı karşılıklı olmalı ve her sürüm kendisini de alternatif listesinde göstermelidir. Kullanılmayan locale'ler yalnız listeyi tamamlamak amacıyla eklenmemelidir. Hedef URL'ler erişilebilir ve gerçek kullanıcı deneyimi sunmalıdır. Hreflang doğru sayfayı kullanıcıya sunmaya yardımcı olan bir sinyaldir, hatalı site mimarisini onaran bir araç değildir.

XML Sitemap

XML Sitemap yayınlanan canonical ve indekslenebilir URL'lerin otomatik çıktısı olarak düşünülmelidir. Büyük projelerde locale veya içerik tipi bazında bölünebilir. Hreflang XML üzerinden yönetiliyorsa locale cluster bilgileri de aynı registry'den üretilmelidir. Manuel XML düzenlemek ilk aşamada kolay görünse de ölçek büyüdükçe hataya açıktır. Otomatik generation ve validation daha sürdürülebilir sonuç verir.

Internal Linking

Internal linking, crawler'ın locale içindeki sayfalar arasında gezinmesine yardımcı olur. Türkçe navigasyonun sebepsiz yere İngilizce canonical sayfalara bağlanması kullanıcı deneyimini bozabilir. Normal içerik bağlantıları çoğunlukla aynı locale içinde kalmalıdır. Dil değişimi ise language switcher üzerinden doğru eşdeğer URL'ye yapılmalıdır. Bu yapı sitemap sinyallerini sitenin gerçek navigasyonuyla destekler.

Language Switcher

Language switcher gerçek kullanıcıya sunulan locale seçeneklerinin görünür arayüzüdür. SEO hreflang verisiyle aynı mapping kaynağını kullanması özellikle önemlidir. Bir dil seçicide bulunmayan ancak hreflang içerisinde görünen gizli locale'ler veri tutarsızlığına işaret edebilir. Kullanıcı bir sayfanın İngilizce karşılığına tıkladığında ana sayfaya değil aynı content entity'nin İngilizce sürümüne gitmelidir. Bu davranış hem kullanıcı deneyimini hem locale modelinin doğruluğunu güçlendirir.

Indexability

Indexability sitemap üretiminden önce kontrol edilmesi gereken temel kapıdır. Sayfanın robots meta direktifi, HTTP durumu ve canonical hedefi sitemap davranışını belirler. noindex bir URL'nin sitemap'e eklenmesi çelişkili sinyal oluşturur. Redirect veren URL'ler de aktif sitemap envanterinde tutulmamalıdır. Generator yalnız indekslenmeye uygun yayın durumlarını seçmelidir.

Search Console Monitoring

Search Console sonrası izleme katmanıdır ve üretim kadar önemlidir. Locale bazlı sitemap'ler gönderilen ve indekslenen URL oranlarını ayrı ayrı incelemeyi kolaylaştırabilir. Yanlış canonical seçimi, keşif sorunları ve indeksleme düşüşleri burada daha erken fark edilebilir. Büyük projelerde verileri locale ve içerik tipine göre segmentlemek teşhis süresini kısaltır. Sitemap yalnız üretilmemeli, sonuçları da düzenli olarak ölçülmelidir.

Sitemap ile Hreflang Aynı Şey midir?

Sitemap ile hreflang aynı görevi yerine getirmez. Sitemap esas olarak URL keşfini desteklerken hreflang farklı locale URL'leri arasındaki ilişkiyi açıklar. Canonical ise tercih edilen URL konusunda ayrı bir sinyal üretir. Hreflang canonical ve XML sitemap birlikte nasıl kullanılır sorusunun özeti, üç yapının aynı URL gerçekliğini desteklemesidir. Bir sistem diğerinin yerine kullanılmamalı, her biri kendi görevini yerine getirirken ortak veri kaynağına dayanmalıdır.

Sitemap URL Discovery Sağlar

Sitemap, arama motorlarına sitenizde hangi URL'leri keşfetmesini istediğinizi bildirir. Özellikle büyük veya derin link yapısına sahip projelerde URL discovery sürecine yardımcı olur. Ancak sitemap'te yer almak bir URL'yi otomatik olarak değerli veya indekslenebilir yapmaz. Sayfanın kendi teknik durumu hâlâ belirleyicidir. Bu nedenle generator'a health kontrolleri eklemek iyi bir mühendislik uygulamasıdır.

Hreflang Locale İlişkilerini Tanımlar

Hreflang URL'lerin aynı içeriğin hangi dil veya bölge sürümleri olduğunu ifade eder. Örneğin Türkçe hizmet sayfası İngilizce karşılığıyla aynı cluster içinde tanımlanabilir. Bu cluster içinde yalnız gerçekten var olan sürümler bulunmalıdır. Sayfaların eşdeğer olması gerekir. Bir blog yazısını başka dildeki kategori sayfasıyla eşleştirmek geçerli bir locale bağlantısı oluşturmaz.

Canonical Preferred URL Sinyali Verir

Canonical belirli bir içerik için tercih edilen URL hakkında arama motoruna sinyal gönderir. Parametreli veya kopya URL'lerin kontrolünde önemli rol oynar. Çok dilli sürümlerde ise her gerçek locale'in kendisini canonical göstermesi çoğu yapı için doğru başlangıçtır. Böylece Türkçe içerik Türkçe URL olarak, İngilizce içerik İngilizce URL olarak kalır. Hreflang bu bağımsız canonical sayfalar arasındaki locale ilişkisini tanımlar.

Bu Üç Yapının Birlikte Çalışması

En sağlıklı modelde sitemap canonical URL'leri listeler, hreflang yine canonical URL'leri birbirine bağlar ve sayfanın canonical etiketi aynı URL'yi gösterir. Bu yaklaşım teknik sinyaller arasında çatışma oluşmasını azaltır. Language switcher da aynı hedeflere bağlanırsa kullanıcı tarafı ile SEO tarafı eşleşir. CMS tarafında content entity ID kullanılması bu bağlantıları üretmeyi kolaylaştırır. Böylece URL değişikliği olduğunda tüm katmanlar merkezi kayıttan güncellenebilir.

Birini Diğerinin Yerine Kullanmamak

Sitemap eklemek hreflang ihtiyacını ortadan kaldırmaz. Hreflang kullanmak da canonical sorunlarını çözmez. Canonical ise farklı dillerdeki sayfaları tek URL altında toplamak için kullanılmamalıdır. Her yapının amacı farklı olduğu için hata ayıklarken de ayrı kontrol edilmelidir. En iyi sonuç, bu sinyalleri birbiriyle uyumlu fakat görev açısından bağımsız tasarlamaktan gelir.

Hreflang Nedir?

Hreflang, aynı veya eşdeğer içeriğin farklı dil ve bölgesel URL sürümlerini tanımlamak için kullanılan alternates ilişkisidir. Küçük sitelerde HTML head içinde üretilebilirken büyük yapılarda XML sitemap üzerinden merkezi şekilde yönetmek daha uygun olabilir. Teknik ekip açısından kritik nokta tüm alternatiflerin aynı mapping sisteminden üretilmesidir. Kodların geçerli olması, URL'lerin tam adres olarak kullanılması ve bağlantıların karşılıklı kurulması gerekir. Bu nedenle hreflang yalnız etiketi eklemek değil, bütün cluster'ın doğruluğunu sağlamak anlamına gelir.

rel="alternate"

rel="alternate" bağlantının mevcut sayfanın alternatif bir sürümünü temsil ettiğini ifade eder. Hreflang uygulamasında locale bilgisi bu ilişkiye eklenir. Alternatif URL'nin canonical ve erişilebilir olması beklenir. Aynı cluster içindeki sayfalar birbirlerini tutarlı biçimde göstermelidir. Otomatik üretim burada manuel şablonlardan daha güvenilir olabilir.

hreflang="tr"

hreflang="tr" Türkçe içerik sürümünü belirtir. Bu değer ülke değil dil hedefidir. Sayfanın içeriği gerçekten Türkçe olmalı ve kullanıcı tarafından erişilebilir olmalıdır. Türkçe URL kendi cluster'ında kendisini de tr olarak göstermelidir. Böylece self-reference koşulu sağlanır.

hreflang="en"

hreflang="en" genel İngilizce sürüm için kullanılabilir. Eğer belirli pazarlara göre ayrı İngilizce sürümleriniz yoksa bu kullanım yeterli olabilir. ABD veya Birleşik Krallık için farklı sayfalar varsa daha ayrıntılı locale kodları tercih edilebilir. Genel en sürümü de gerçek bir URL olmalıdır. Yalnız fallback üretmek için sahte sayfa açılmamalıdır.

Dil–Bölge Kombinasyonu

Dil ve bölge birlikte kullanıldığında önce dil, sonra ülke kodu yazılır. en-US ve en-GB buna örnektir. Bölge eklemek sitenin gerçekten o pazara özel deneyim sunduğu durumlarda anlamlıdır. Aynı içerik ve aynı ürün deneyimini onlarca ülkeye kopyalamak bakım yükünü artırabilir. URL stratejisi gerçek iş ihtiyacına göre tasarlanmalıdır.

Hreflang'ın Kullanıcıya Doğru Locale'i Sunmadaki Rolü

Hreflang arama motorunun farklı locale sürümleri arasındaki ilişkiyi anlamasına yardımcı olur. Böylece İngilizce arama yapan kullanıcıya Türkçe URL yerine uygun İngilizce sürümün sunulması kolaylaşabilir. Bununla birlikte sonuç seçimi yalnız hreflang'a bağlı değildir. Canonical, içerik ve teknik erişilebilirlik gibi başka sinyaller de değerlendirilir. Bu nedenle hreflang uygulaması kapsamlı international SEO mimarisinin bir parçasıdır.

Hreflang Bir Direktif midir?

Hreflang mekanizmasını katı bir yönlendirme kuralı gibi düşünmek doğru değildir. Arama motorları farklı sinyalleri birlikte değerlendirerek hangi URL'yi göstereceklerine karar verir. Bu nedenle doğru hreflang kullanmak faydalıdır ancak yanlış canonical veya indekslenemez sayfaları tek başına düzeltemez. Teknik ekip önce URL health ve canonical durumunu sağlamlaştırmalıdır. Ardından locale ilişkileri hreflang ile açık biçimde ifade edilmelidir.

Search Engine Sinyali

Hreflang bir locale ilişkisi sinyalidir. Sayfaların birbirinin dil veya bölgesel alternatifi olduğunu açıklar. Bu sinyal kullanıcıya daha uygun URL'nin seçilmesine yardımcı olabilir. Ancak crawler erişimi veya indexability problemi varsa ilişki sağlıklı çalışmayabilir. Hreflang kalite kontrolünde bu yüzden önce URL durum kodlarına bakılır.

Google'ın Nihai URL Seçimi

Google hangi URL'nin arama sonucunda gösterileceğine kendi sistemleri üzerinden karar verir. Site sahibi canonical ve hreflang gibi araçlarla tercihlerini açıklar. Fakat teknik sinyaller çeliştiğinde beklenmeyen URL seçilebilir. Search Console URL Inspection bu tür durumları incelemek için yararlıdır. Özellikle aynı dilde bölgesel içeriklerde canonical ve hreflang birlikte değerlendirilmelidir.

Canonicalization ile İlişkisi

Canonicalization kopya veya çok benzer URL'ler arasından temsilci URL'nin belirlenmesiyle ilgilidir. Hreflang ise uygun locale sürümünün ilişkilendirilmesiyle ilgilidir. Aynı dilde farklı ülke sayfaları birbirine çok benzediğinde iki kavramın uyumu daha da önemli olur. Her aktif locale'in kendi canonical adresi olması genellikle daha anlaşılır bir yapı oluşturur. Cross-language canonical yalnız gerçekten aynı URL'nin temsilci olarak seçilmesi isteniyorsa düşünülmelidir ve çoğu normal çeviri mimarisinde doğru seçim değildir.

Doğru Hreflang'ın Yanlış Teknik SEO'yu Düzeltememesi

Bir URL 404 veriyorsa doğru hreflang onu kullanılabilir hale getirmez. Sayfa noindex ise hreflang onun indekslenmesini sağlayamaz. Canonical başka dile gidiyorsa hreflang çelişkiyi otomatik olarak çözmez. Bu nedenle debug sırası HTTP durumundan başlayıp indexability ve canonical üzerinden ilerlemelidir. Locale mapping ancak temel URL sağlığı doğrulandıktan sonra değerlendirilmelidir.

Hreflang Uygulama Yöntemleri

Hreflang HTML head, HTTP Header veya XML Sitemap üzerinden uygulanabilir. Her yöntemin teknik yönetim şekli farklıdır fakat mantıksal ilişki aynıdır. Üç yöntemi aynı anda kullanmak zorunlu değildir. Hatta büyük projelerde aynı bilgiyi üç farklı sistemde üretmek drift riskini artırabilir. Bu yüzden kurumun teknoloji yapısına uygun tek ve güvenilir kaynak belirlemek daha kullanışlıdır.

HTML Head

HTML head yöntemi az sayıda locale ve URL bulunan projelerde oldukça anlaşılırdır. Template render edilirken content entity'nin diğer locale URL'leri link etiketleri olarak üretilebilir. Sorun dil sayısı arttıkça head bölümünün büyümesidir. Mapping kodu farklı frontend'lerde tekrarlandığında bakım yükü de artabilir. Merkezi registry kullanılıyorsa bu yöntem yine güvenli biçimde otomatikleştirilebilir.

HTTP Header

HTTP Header özellikle HTML olmayan kaynakların locale alternatiflerini tanımlamak gerektiğinde kullanılabilir. PDF gibi dosyalarda bu yaklaşım yararlı olabilir. Header üretiminin backend veya edge katmanında doğru yapılması gerekir. Debug sırasında response header'ların kontrol edilmesi unutulmamalıdır. HTML ve sitemap verisinden farklı registry kullanılması yine tutarsızlık doğurabilir.

XML Sitemap

XML Sitemap yöntemi çok sayıda URL ve locale bulunan projelerde merkezi yönetim avantajı sağlar. Hreflang cluster bilgileri sitemap generation sırasında locale registry'den çekilebilir. Böylece sayfanın HTML head bölümünü yüzlerce alternatif bağlantıyla büyütmeye gerek kalmaz. Generator self-reference ve reciprocal ilişkiyi programatik olarak kurabilir. Özellikle çoklu domain ve büyük içerik platformlarında bu yaklaşım operasyonel açıdan güçlüdür.

Üç Yöntemin Birlikte Kullanılması Gerekir mi?

Hayır, üç yöntemi birlikte kullanmak şart değildir. Aynı bilgiler birden fazla yöntemde sunulacaksa tamamen tutarlı olmaları gerekir. Bir yerde eski URL, diğer yerde yeni URL bulunması debug sürecini zorlaştırır. Bu nedenle ekiplerin tek source of truth oluşturması daha önemlidir. Uygulama kanalı ihtiyaçlara göre seçilebilir.

Kurum İçin Tek Kaynak Yaklaşımı Seçmek

Kurum içinde en önemli karar hreflang'ın nerede yazıldığından önce verinin nereden geldiğidir. Content entity ve locale registry merkezi veri kaynağı olarak kullanılabilir. Sitemap, head etiketleri ve language switcher bu kaynağın farklı çıktıları olabilir. Böylece yeni locale yayınlandığında bütün kanallar aynı anda güncellenebilir. Yapısal Çoklu Dil Destekli (Multi-Language) Site Haritası Mimarisi için sürdürülebilir yaklaşım budur.

Hangi Durumda Sitemap Tabanlı Hreflang Tercih Edilebilir?

Sitemap tabanlı hreflang özellikle çok fazla dil, URL veya domain bulunan yapılarda avantaj sağlar. HTML head'in her sayfada onlarca alternate bağlantısı üretmesi yerine mapping merkezi XML üretim katmanına taşınabilir. Çoklu domain sistemlerinde locale registry bütün domainleri tek content entity etrafında birleştirebilir. Otomatik sitemap generation, hata kontrolü ve atomik yayın bu yaklaşımın güvenilirliğini artırır. Büyük kurumsal platformlarda merkezi model ekipler arası koordinasyonu da kolaylaştırır.

Çok Fazla Dil

İki veya üç dilde HTML hreflang yönetmek genellikle kolaydır. Dil sayısı onlarca seviyesine çıktığında her sayfadaki alternatif bağlantı sayısı hızla büyür. Merkezi generator bütün cluster'ı programatik olarak oluşturabilir. Böylece eksik locale bağlantıları daha kolay test edilir. Yeni bir dil eklemek de template değişikliği gerektirmeyebilir.

Çok Fazla URL

Milyonlarca URL bulunan sistemlerde manuel mapping yaklaşımı uygulanabilir değildir. URL ile content entity ilişkisi veri tabanında veya registry servisinde tutulmalıdır. Sitemap generator yalnız yayınlanmış ve indekslenebilir kayıtları çekebilir. Partitioning ile XML dosyaları yönetilebilir büyüklükte tutulur. Monitoring sistemi de URL sayısındaki beklenmedik değişiklikleri yakalayabilir.

Çoklu Domain

Birden fazla domain kullanan uluslararası yapılarda locale ilişkileri farklı hostlar arasında kurulabilir. Bu yapı özellikle ccTLD kullanan markalarda görülür. Merkezi URL registry domain bilgisini locale kaydıyla birlikte tutabilir. Sitemap üretimi site bazında ayrılırken content entity ilişkisi ortak kalır. Böylece farklı domainler arasında yanlış pairing riski azaltılır.

HTML Head'in Aşırı Büyümesi

Locale sayısı arttıkça head bölümünde üretilen alternate etiketleri de artar. Bu durum tek başına bir SEO sorunu olmak zorunda değildir fakat bakım ve render maliyetini artırabilir. XML tabanlı yönetim ilişkileri merkezi bir katmana taşıyabilir. Frontend template'leri daha basit kalır. Özellikle farklı frontend teknolojileri kullanan kurumlarda bu ayrım yararlı olabilir.

Merkezi Locale Registry

Merkezi locale registry her content entity için yayınlanmış locale URL'lerini tutar. Bu kayıt canonical URL, hreflang code, publication state ve last modified gibi alanları içerebilir. Sitemap generator buradan veri okuyarak deterministik çıktı üretir. Language switcher aynı registry'yi kullandığında UI ile SEO verisi senkron kalır. Sistem büyüdükçe bu yapı büyük operasyonel avantaj sağlar.

Otomatik Sitemap Generation

Otomatik generator XML'i manuel dosya olmaktan çıkarıp üretim çıktısına dönüştürür. Yeni içerik yayınlandığında veya URL değiştiğinde sitemap otomatik yenilenebilir. Generation aşamasında canonical ve HTTP health testleri çalıştırılabilir. Hatalı çıktı production'a geçmeden engellenebilir. Böylece stale sitemap riski ciddi biçimde azalır.

Büyük Kurumsal Platformlar

Büyük yapılarda SEO, engineering, localization ve content ekipleri aynı URL verisine ihtiyaç duyar. Her ekip kendi mapping tablosunu oluşturursa zamanla farklar ortaya çıkar. Merkezi platform bu veriyi ortaklaştırır. Sitemap ve hreflang kuralları kodlanabilir ve test edilebilir hale gelir. Teknik SEO böylece manuel kontrol görevi olmaktan çıkıp platform özelliğine dönüşür.

XML Sitemap İçinde Hreflang Nasıl Çalışır?

XML sitemap içinde hreflang kullanılırken standart urlset yapısına gerekli XHTML namespace eklenir. Her url kaydı altında ana URL loc ile belirtilir ve alternatif locale sürümleri xhtml:link öğeleriyle tanımlanır. Her alternatif için rel="alternate", uygun hreflang ve tam href adresi gerekir. Aynı cluster'daki bütün sayfaların aynı alternatif setini göstermesi güvenli modeldir. Generator bu ilişkileri merkezi veriden oluşturduğunda manuel XML hataları azalır.

urlset

urlset sitemap URL kayıtlarının ana kapsayıcısıdır. Hreflang kullanılan XML'de gerekli namespace tanımlarının doğru eklenmesi gerekir. Generator bu alanı sabit template olarak üretebilir. Namespace yanlışsa XML teknik olarak parse edilse bile beklenen extension işlenmeyebilir. Bu nedenle XML validation release sürecinin parçası olmalıdır.

loc

loc elemanı sitemap kaydının ana URL'sini taşır. Buradaki URL mutlak ve canonical olmalıdır. Redirect olan veya noindex URL'lerin buraya girmesi uygun değildir. URL'nin HTTP 200 yanıtı verdiği otomatik testlerle kontrol edilebilir. Böylece sitemap gerçek yayın durumuyla uyumlu kalır.

xhtml Namespace

Hreflang alternate ilişkileri XML sitemap içerisinde XHTML namespace üzerinden ifade edilir. Namespace generator'ın kök elementinde doğru tanımlanmalıdır. Manuel yazılan XML'lerde namespace unutulması sık karşılaşılan hatalardan biridir. Schema ve parser testleri bu hatayı build aşamasında yakalayabilir. Büyük projelerde elle kontrol yerine otomatik test tercih edilmelidir.

xhtml

xhtml prefix'i alternate link öğelerinin doğru namespace altında bulunduğunu gösterir. Her locale alternatifi ayrı link öğesi olarak üretilir. Cluster'ın büyüklüğüne göre tek URL kaydı altında çok sayıda öğe bulunabilir. Bu nedenle generator performansı ve çıktı boyutu izlenmelidir. Deterministik sıralama debug sürecini kolaylaştırabilir.

rel="alternate"

rel="alternate" linkin mevcut URL'nin alternatif sürümünü temsil ettiğini belirtir. Hreflang uygulamasında bu ilişki locale koduyla tamamlanır. Her URL kendisini de alternatifler arasında göstermelidir. Alternatiflerin gerçek, canonical ve erişilebilir URL'ler olması gerekir. Kullanıcıya sunulmayan sahte locale adresleri bu listeye eklenmemelidir.

hreflang

hreflang alternatife ait dil veya dil-bölge kodunu taşır. Kodların merkezi mapping tablosundan gelmesi yazım hatalarını azaltır. CMS'nin dahili locale isimleri doğrudan SEO kodu olarak kullanılmamalıdır. Örneğin kurum içindeki english_uk değeri SEO çıktısında en-GB olarak eşlenebilir. Mapping açık biçimde tutulduğunda platform değişiklikleri daha güvenli yapılır.

href

href ilgili locale sürümünün tam URL'sidir. Relative URL yerine protokol ve host içeren mutlak adres kullanılmalıdır. Domainler farklıysa doğru host bilgisi özellikle önemlidir. URL değişikliklerinde registry güncellenmeli ve sitemap yeniden üretilmelidir. Eski adresler cluster içinde bırakılmamalıdır.

Bir Hreflang Cluster Nedir?

Hreflang cluster, aynı content entity'nin farklı locale URL'lerinden oluşan ilişkili sayfa grubudur. Bir hizmet sayfasının Türkçe, İngilizce ve Almanca sürümleri aynı cluster'a ait olabilir. Buradaki kritik kavram URL değil içerik kimliğidir. URL'ler değişebilir fakat content entity sabit kaldığında eşleşmeler yeniden güvenle üretilebilir. Bu nedenle büyük sitelerde URL metninden tahmin yapmak yerine kalıcı content ID kullanmak daha doğru sonuç verir.

Aynı İçeriğin Locale Sürümleri

Cluster'a yalnız aynı kullanıcı amacını karşılayan locale sürümleri alınmalıdır. Çeviriler bire bir kelime karşılığı olmak zorunda değildir. Yerel pazara göre bazı bölümler değişebilir. Ancak sayfaların temel konusu ve görevi aynı kalmalıdır. Aksi halde yanlış content pairing oluşur.

Content Entity

Content entity URL'den bağımsız mantıksal içerik kimliğidir. Örneğin hizmet sayfasının CMS içinde 4832 ID'sine sahip olduğunu düşünelim. Türkçe ve İngilizce URL'ler aynı ID'nin locale varyantları olabilir. Sitemap generator bu ID üzerinden alternatifleri toplar. Böylece slug değişikliği hreflang ilişkisinin kaybolmasına neden olmaz.

tr URL

Türkçe URL cluster'ın tr sürümüdür. Kendi canonical adresini göstermeli ve diğer yayınlanmış alternatifleri listelemelidir. Türkçe içerik kaldırıldığında registry durumu güncellenir. Sitemap generator bu URL'yi cluster'dan çıkarır. Diğer locale sayfalarındaki return ilişkileri de aynı generation sırasında yenilenir.

en URL

İngilizce URL aynı content entity'nin en karşılığıdır. Gerçek çeviri yayınlanmadan URL'nin hreflang cluster'a eklenmemesi gerekir. Preview veya QA sayfaları production sitemap'e dahil edilmemelidir. Yayın durumu PUBLISHED olduğunda generator URL'yi otomatik ekleyebilir. Böyle bir state modeli içerik operasyonunu SEO kurallarıyla birleştirir.

de URL

Almanca URL yalnız gerçekten mevcutsa cluster'a eklenmelidir. Her sayfanın tüm dillerde karşılığı olmak zorunda değildir. Almanca çevirisi bulunmayan bir sayfa için boş veya otomatik placeholder oluşturmak yanlış olur. Partial translation normal ve yönetilebilir bir durumdur. Cluster yalnız mevcut locale'leri içermelidir.

Tüm Alternatiflerin Tek Cluster'da Bağlanması

Sağlıklı cluster içinde her locale sürümü diğer yayınlanmış sürümleri bilir. Bu karşılıklı yapı return link şartını sağlar. Cluster büyüdükçe manuel bağlantı sayısı hızlı biçimde artar. Bu nedenle merkezi registry ve otomatik generator önem kazanır. Graph tabanlı validation eksik kenarları tespit etmek için kullanılabilir.

Hreflang Cluster İçin Self-Reference

Self-reference her locale sayfasının alternatif listesinde kendisini de kendi locale koduyla göstermesidir. Türkçe URL tr, İngilizce URL en olarak kendi adresine referans verir. Bu davranış cluster'ın tam tanımlanmasına yardımcı olur. x-default self-reference yerine geçmez çünkü amacı farklıdır. Otomatik validator her cluster için self-reference kontrolü yapmalıdır.

Türkçe Sayfanın Kendisini tr Olarak Göstermesi

Türkçe sayfa cluster içindeki kendi canonical URL'sini tr alternate olarak taşımalıdır. Aynı URL'nin farklı parametreli sürümünü kullanmak doğru değildir. Generator canonical URL alanını kullanarak bu kaydı oluşturabilir. Böylece self-reference ile canonical aynı adres üzerinde birleşir. Testlerde bu ilişki kolayca doğrulanabilir.

İngilizce Sayfanın Kendisini en Olarak Göstermesi

İngilizce sürüm de aynı kuralı uygular. Kendi canonical URL'si en alternatifi olarak listelenir. Bölgesel İngilizce sürüm kullanılıyorsa kod buna göre değişir. Generic en ile en-US birbirinin yerine rastgele kullanılmamalıdır. Locale registry hangi kodun geçerli olduğunu belirlemelidir.

Self-Reference ile x-default Arasındaki Fark

Self-reference mevcut URL'nin kendi locale kimliğini ifade eder. x-default ise belirli bir dil veya bölgeye ait olmayan fallback deneyimini gösterebilir. Bu yüzden x-default eklemek self-reference gereksinimini ortadan kaldırmaz. Bir global dil seçim sayfası x-default olabilir. Aynı cluster'daki Türkçe sayfa yine kendisini tr olarak göstermelidir.

Eksik Self-Reference Hatası

Eksik self-reference çoğu zaman manuel hreflang üretiminde ortaya çıkar. Geliştirici yalnız diğer dilleri listeler ve mevcut sayfayı atlar. Merkezi generator bunu otomatik ekleyebilir. CI testi her URL'nin kendi locale koduyla cluster içinde bulunup bulunmadığını kontrol edebilir. Böylece hata production'a çıkmadan yakalanır.

Reciprocal Hreflang Nedir?

Reciprocal hreflang, iki locale URL'sinin birbirine karşılıklı referans vermesi anlamına gelir. A sayfası B sayfasını alternatif olarak gösteriyorsa B sayfasının da A sayfasına return link vermesi gerekir. Bu ilişki cluster bütünlüğünün temel kontrollerinden biridir. Yüzlerce locale bağlantısını manuel incelemek yerine graph validation kullanılabilir. Her URL node, her alternate bağlantısı ise locale edge olarak modellenebilir.

A Sayfası B'yi Gösteriyorsa B de A'yı Göstermeli

Karşılıklı ilişki hreflang cluster'ın aynı veri kaynağından üretildiğini gösteren güçlü bir kalite göstergesidir. Türkçe sayfa İngilizce sürümü gösteriyorsa İngilizce sayfa da Türkçe sürümü göstermelidir. İki farklı sistemden üretim yapıldığında bu eşleşme kolayca bozulabilir. Merkezi generator bu riski azaltır. Validation ise kalan hataları otomatik raporlayabilir.

Return Link

Return link alternatif sayfanın ilk sayfaya geri verdiği hreflang referansıdır. Bu ilişki olmadan cluster eksik kalabilir. Özellikle yeni locale yayınlarında return link kontrolü yapılmalıdır. Yeni URL yalnız kendi tarafına eklenip eski sayfalar güncellenmezse tek yönlü ilişki oluşur. Event-driven generation bu güncellemeyi otomatikleştirebilir.

Eksik Reciprocal Link

Eksik reciprocal link genellikle senkronizasyon problemine işaret eder. Bir locale farklı CMS veya deployment kullanıyorsa güncelleme zamanları ayrışabilir. Registry bütün locale durumlarını merkezi tuttuğunda generator yalnız tamamlanan yayın kayıtlarını kullanabilir. Böylece kısmi deployment riski azalır. Production smoke test yine gerçek çıktıyı kontrol etmelidir.

Cluster Integrity

Cluster integrity yalnız return link sayısıyla ölçülmemelidir. URL'lerin aynı content entity'ye ait olması, canonical olması ve HTTP 200 dönmesi de gerekir. Bir cluster teknik olarak tam bağlantılı olup içerik açısından yanlış eşleştirilmiş olabilir. Bu nedenle content contract testi ayrıca yapılmalıdır. Ürün ID, makale ID veya page ID gibi kalıcı kimlikler burada yardımcı olur.

Otomatik Reciprocity Testi

Otomatik test bütün alternate bağlantılarını graph olarak okuyabilir. Her A→B edge için B→A edge aranır. Eksik bağlantı bulunduğunda build warning veya fail kararı verilebilir. Büyük sitelerde kritik locale'ler için fail, daha düşük öncelikli durumlar için warning politikası uygulanabilir. Bu test manuel spreadsheet kontrollerinden çok daha ölçeklenebilir olur.

x-default Nedir?

x-default belirli bir dil veya bölge hedeflemeyen fallback URL'yi tanımlamak için kullanılabilir. Örneğin global ana sayfa kullanıcıya dil ve ülke seçtiriyorsa x-default adayı olabilir. Her projede x-default kullanmak zorunlu değildir. Generic bir dil sürümünü de ancak gerçekten uygun fallback deneyimi sunuyorsa değerlendirmek gerekir. x-default'ın normal locale self-reference yerine kullanılmaması özellikle önemlidir.

Belirli Bir Locale'e Ait Olmayan Fallback

Fallback URL belirli bir dil veya pazara bağlanmadığında x-default ile tanımlanabilir. Kullanıcı buradan kendi dil veya ülke seçimini yapabilir. Sayfanın gerçekten böyle bir global deneyim sunması gerekir. Yalnız teknik alanı doldurmak amacıyla rastgele ana sayfa seçilmemelidir. Kullanıcı deneyimi ile SEO bildirimi aynı anlamı taşımalıdır.

Dil Seçim Sayfası

Dil seçim sayfası x-default için sık kullanılan modellerden biridir. Kullanıcıya desteklenen locale seçenekleri açık biçimde gösterilir. Otomatik yönlendirme yerine seçim hakkı korunabilir. Seçim cookie ile hatırlanabilir fakat URL'ler yine ayrı kalmalıdır. Bu yaklaşım botların locale sürümlerini bağımsız olarak keşfetmesini kolaylaştırır.

Global Homepage

Global homepage belirli bir ülke veya dile ait değilse x-default olarak değerlendirilebilir. Ancak global URL'nin kullanıcıya mantıklı içerik sunması gerekir. Tüm ziyaretçileri zorla tek ülkeye yönlendirmek iyi bir fallback değildir. Locale switcher açık görünmelidir. Global sayfanın canonical davranışı da kendi rolüyle tutarlı olmalıdır.

Generic Language Version

Generic language version belirli bir bölgeye ait olmayan dil sürümüdür. Örneğin en genel İngilizce içerik olarak kullanılabilir. Bölgesel eşleşme bulunmadığında bu sürüm yararlı olabilir. Ancak generic dil ile x-default aynı kavram değildir. Generic İngilizce hâlâ belirli bir dil hedefidir.

x-default Self-Reference Değildir

x-default mevcut locale'in kendi referansı yerine geçmez. Türkçe sayfa kendi tr kaydını yine taşımalıdır. x-default yalnız ek bir fallback ilişkisidir. Bu ayrım validator kurallarında açık biçimde modellenmelidir. Aksi halde self-reference testleri yanlış pozitif sonuç verebilir.

x-default Hangi Durumlarda Kullanılmalı?

x-default gerçek bir global veya locale seçici deneyim bulunduğunda kullanılmalıdır. Kullanıcının dili bilinmediğinde hangi sayfanın uygun fallback olduğu iş gereksinimine göre belirlenebilir. Her cluster'a mekanik biçimde eklemek gerekmez. URL kullanıcıya anlamlı içerik sunmalıdır. Bu nedenle karar yalnız SEO ekibi değil ürün ve localization ekipleriyle birlikte verilmelidir.

Canonical ile Hreflang Nasıl Birlikte Kullanılmalı?

Canonical ve hreflang birbirine rakip sinyaller değildir. Canonical belirli URL'nin temsilci niteliğini, hreflang ise farklı locale sürümlerinin ilişkisini açıklar. Normal çok dilli mimaride her yayınlanmış locale kendisini canonical göstermelidir. Hreflang hedefleri de bu canonical URL'lere işaret etmelidir. Böylece sitemap, canonical, language switcher ve hreflang aynı URL'leri kullanarak tutarlı bir teknik yapı oluşturur.

Her Locale Kendisini Canonical Göstermeli

Türkçe, İngilizce ve Almanca içerikler gerçek bağımsız locale sayfalarıysa her biri kendi canonical URL'sini gösterebilir. Bu yaklaşım her sürümün bağımsız olarak indekslenmesine izin verir. Canonical URL sitemap içinde de bulunmalıdır. Internal linkler aynı canonical URL'yi kullanmalıdır. Böylece arama motoruna farklı yerlerden aynı tercih aktarılır.

Türkçe Sayfayı İngilizceye Canonical Etmemek

Türkçe sayfanın canonical adresini İngilizce sürüme vermek çoğu standart çeviri senaryosunda yanlış sinyal oluşturur. Bir tarafta hreflang Türkçe URL'nin ayrı locale olduğunu söylerken canonical İngilizce URL'yi tercih eder. Bu çelişki Türkçe URL'nin indeks davranışını etkileyebilir. Doğru model her gerçek locale'in kendisini canonical göstermesidir. Alternatif dil ilişkisi hreflang ile kurulmalıdır.

Hreflang'ın Canonical URL'lere İşaret Etmesi

Hreflang hedeflerinin redirect veya parametreli kopyalara gitmemesi gerekir. Her target doğrudan tercih edilen canonical URL olmalıdır. Böylece crawler ek yönlendirme zincirleriyle uğraşmaz. URL health validation bu hedefleri otomatik test edebilir. Non-canonical target bulunduğunda deployment öncesinde hata üretilebilir.

Non-Canonical URL'leri Cluster'a Almamak

Cluster yalnız aktif canonical locale URL'lerden oluşturulmalıdır. Filtre parametreleri, tracking URL'leri veya yönlenen eski adresler cluster dışında kalmalıdır. Aksi halde aynı locale için birden fazla URL ortaya çıkabilir. Bu durum duplicate locale ve canonical conflict hataları üretir. Registry canonical URL alanını tek değer olarak tutmalıdır.

Sitemap'e Hangi URL'ler Dahil Edilmeli?

Sitemap'e yalnız arama sonuçlarında görünmesini gerçekten istediğiniz URL'ler dahil edilmelidir. Bu URL'ler canonical, indekslenebilir, HTTP 200 dönen ve production ortamında yayınlanmış sayfalar olmalıdır. Çok dilli yapılarda her locale bağımsız olarak bu kriterleri sağlamalıdır. İngilizce sürüm hazır olduğu için Türkçe taslak otomatik olarak sitemap'e girmemelidir. Generator'ın publication state ile indexability kurallarını birlikte değerlendirmesi en güvenli yaklaşımdır.

Canonical URL

Sitemap URL'sinin sayfanın tercih edilen canonical adresi olması gerekir. Aynı içerik için parametreli ve temiz URL'yi birlikte listelemek gereksiz sinyal üretir. Registry her locale için tek canonical URL tutabilir. Generator yalnız bu alanı kullanır. Canonical değiştiğinde sitemap aynı event üzerinden yeniden oluşturulabilir.

Indexable URL

Indexable URL robots meta veya HTTP header üzerinden noindex taşımamalıdır. robots.txt engeli de crawler erişimini etkileyebilir. Generator yalnız statik veriye bakmak yerine gerekiyorsa production health kontrolü yapabilir. Böylece CMS'de yayınlanmış fakat frontend'de noindex kalan sayfalar yakalanır. Bu özellikle migration sonrasında faydalıdır.

HTTP 200

Sitemap'teki aktif URL'lerin başarılı HTTP yanıtı vermesi beklenir. Redirect URL'ler doğrudan yeni hedefleriyle değiştirilmelidir. 404, 410 ve 5xx yanıtları aktif sitemap'e ait değildir. Büyük sitelerde bütün URL'leri her build'de kontrol etmek maliyetli olabilir. Incremental health checks ve periyodik full crawl birlikte kullanılabilir.

Gerçek Yayındaki İçerik

Preview, draft veya staging içerikleri sitemap'e dahil edilmemelidir. Bir çeviri tamamlanmış olsa bile QA süreci bitmediyse production locale olarak değerlendirilmemelidir. Publication state bunun için açık model sunar. PUBLISHED durumu generator'ın temel kapısı olabilir. Böylece içerik operasyonu ile SEO çıktısı otomatik senkronize edilir.

Arama Sonuçlarında Görünmesini İstediğimiz URL'ler

Sitemap teknik olarak erişilebilir her URL'nin dökümü değildir. Search sonuçlarında kullanıcıya sunmak istediğiniz sayfaların seçilmiş envanteridir. Filtre kombinasyonları veya iç arama URL'leri gibi gereksiz adresler dışarıda bırakılabilir. Bu yaklaşım submitted URL raporlarının da daha anlamlı olmasını sağlar. Sitemap kalitesi URL sayısından daha önemlidir.

Sitemap'e Hangi URL'ler Dahil Edilmemeli?

noindex, 3xx, 404, 410, 5xx, non-canonical duplicate, draft, preview ve staging URL'leri normal production sitemap'te bulunmamalıdır. Bu kurallar generator tarafında kodlanabilir. Böylece içerik ekibi yanlışlıkla bir sayfayı yayınladığında bile sitemap release gate problemi yakalayabilir. Özellikle çok dilli projelerde aynı content entity'nin locale'leri farklı durumlarda olabileceği için kontrol locale bazında yapılmalıdır. Bir dilde yayınlanmış olmak diğer tüm dillerin sitemap'e girmesi anlamına gelmez.

noindex

noindex URL arama sonuçlarında görünmesini istemediğinizi belirtir. Böyle bir adresi sitemap'e koymak tutarsız sinyaldir. Generator robots meta durumunu mümkünse veri katmanından bilmelidir. Production crawl da son kontrol olarak kullanılabilir. noindex URL oranı monitoring dashboard üzerinde sıfıra yakın tutulmalıdır.

3xx Redirect

Redirect veren eski URL aktif sitemap'te tutulmamalıdır. Sitemap doğrudan yeni canonical hedefi göstermelidir. URL migration sırasında kısa süreli teşhis için eski sitemap ayrı tutulabilir fakat normal yeni sitemap'in amacı güncel adresleri bildirmektir. Internal linkler de aynı anda güncellenmelidir. Böylece crawler gereksiz redirect zincirlerine yönlendirilmez.

404

404 URL artık bulunmayan kaynağı ifade eder. Aktif sitemap içinde böyle bir URL bulunması stale inventory belirtisidir. Generator veri kaynağında silinen kaydı sitemap'ten çıkarmalıdır. İçeriğin yerine eşdeğer yeni sayfa varsa uygun redirect ayrıca planlanabilir. Ancak yalnız sitemap'ten silmek yanlış yönlendirme kararının yerine geçmez.

410

410 bilinçli biçimde kaldırılan kaynaklarda kullanılabilir. Böyle URL sitemap'te tutulmamalıdır. Locale retirement süreçlerinde bazı URL'ler 410 ile kapatılabilir. Diğer locale cluster'larından da bağlantıları kaldırılmalıdır. Language switcher aynı güncellemeden etkilenmelidir.

5xx

5xx sunucu veya uygulama hatasını gösterir. Geçici hata yaşayan canonical URL hemen registry'den silinmek zorunda değildir. Ancak sitemap endpoint'inin kendisi 5xx veriyorsa sistemin last known good dosyayı sunması yararlı olabilir. Monitoring bu durumu hızlı biçimde bildirmelidir. Generator'ın hata sırasında boş XML yayınlamaması özellikle önemlidir.

Non-Canonical Duplicate

Non-canonical duplicate aynı içeriğin tercih edilmeyen URL sürümüdür. Sitemap yalnız canonical sürümü göstermelidir. Parametreli URL, slash farkı veya tracking varyantı listeye eklenmemelidir. Generator canonical normalization kurallarını merkezi kullanmalıdır. Böylece farklı uygulamalar farklı URL formatları üretmez.

Draft

Draft henüz kullanıcıya yayınlanmamış içeriktir. Sitemap discovery mekanizmasına girmemelidir. Çeviri ekipleri draft URL'leri preview ortamında inceleyebilir. Production registry'de durum ayrı tutulmalıdır. Publish event gerçekleştiğinde sitemap'e eklenmelidir.

Preview URL

Preview URL editörlerin içerik incelemesi için kullanılır. Genellikle indekslenmemesi gerekir. Token veya özel path içeren preview adreslerinin sitemap'e düşmesi ciddi teknik hata sayılabilir. Generator yalnız production route üretmelidir. CI testleri /preview/ gibi bilinen pattern'leri engelleyebilir.

Staging URL

Staging ortamındaki URL'ler production sitemap'e kesinlikle karışmamalıdır. Ortam bazlı domain allowlist kullanmak etkili bir güvenlik kuralıdır. Production generator yalnız onaylı hostları kabul edebilir. robots.txt tek başına bu hataya karşı yeterli koruma olarak görülmemelidir. Veri ve deployment katmanında açık ayrım yapılmalıdır.

Translation Pending URL Sitemap'e Girmeli mi?

Çevirisi tamamlanmamış URL normal şartlarda sitemap'e girmemelidir. Draft translation, machine-generated preview veya QA bekleyen çeviri gerçek yayınlanmış locale değildir. Kullanıcıya sunulacak kalite kontrolünden geçtikten sonra PUBLISHED durumuna alınması daha güvenlidir. Publish olduğu anda cluster yeniden oluşturulur ve bütün return linkler güncellenir. Bu publish gate yaklaşımı düşük kaliteli veya yarım içeriklerin yanlışlıkla indekslenmesini önlemeye yardımcı olur.

Draft Translation

Draft translation editoryal çalışma aşamasındaki çeviridir. URL teknik olarak üretilebilse bile SEO açısından yayınlanmış sayfa kabul edilmemelidir. Language switcher da bu sürümü kullanıcıya sunmamalıdır. Locale registry durumu TRANSLATION_PENDING veya benzer bir değer olabilir. Generator yalnız PUBLISHED kayıtlarını seçmelidir.

Machine-Generated Preview

Otomatik oluşturulan preview metni insan kontrolü bekliyorsa production sitemap dışında tutulmalıdır. Bu yaklaşım özellikle yüksek hacimli çeviri süreçlerinde önemlidir. Kullanıcıya hazır olmayan içerik indekslenme sürecine girmemelidir. QA tamamlandığında yayın kapısı açılır. Sitemap ve language switcher aynı event ile güncellenebilir.

QA Bekleyen Çeviri

QA_PENDING durumu metnin üretildiğini fakat kalite onayının bitmediğini gösterebilir. Sayfa staging veya preview üzerinde incelenebilir. Bu durum production locale olarak görülmemelidir. SEO QA sırasında canonical, hreflang ve metadata da kontrol edilebilir. Onaydan sonra tek publish işlemi bütün teknik çıktıları güncellemelidir.

Published Locale

PUBLISHED locale gerçek kullanıcıya açık sürümdür. Canonical, indexability ve HTTP health kriterleri sağlanıyorsa sitemap'e dahil edilebilir. Hreflang cluster da bu URL'yi alternatif olarak kullanabilir. Language switcher aynı URL'yi göstermelidir. Böylece yayın durumu tek source of truth haline gelir.

Publish Olduğunda Cluster'a Eklemek

Yeni locale yayınlandığında yalnız yeni sayfanın hreflang çıktısını değiştirmek yeterli değildir. Cluster'daki mevcut bütün locale sürümleri yeni alternatifi bilmelidir. Event-driven generator bütün cluster'ı yeniden oluşturabilir. Sitemap partition değişen dosyalar atomik biçimde yenilenebilir. Böylece return link problemi oluşmaz.

Content Entity ID Nedir?

Content Entity ID aynı içeriğin farklı URL ve locale sürümlerini tek mantıksal kimlik altında bağlayan değerdir. URL slug'ları veya domainler zamanla değişebilir fakat entity ID sabit kalabilir. Örneğin bir hizmet sayfasının Türkçe, İngilizce ve Almanca sürümleri aynı content ID'yi paylaşabilir. Sitemap ve hreflang generator bu ID üzerinden cluster oluşturduğunda yanlış eşleştirme riski azalır. Özellikle çok dilli headless CMS sistemlerinde bu model güçlü bir temel sağlar.

URL'den Bağımsız İçerik Kimliği

URL içerik kimliği için güvenilir anahtar değildir çünkü slug değişebilir. Locale'e göre slug zaten farklı olabilir. Kalıcı ID bu değişikliklerden etkilenmez. Registry content ID ile locale URL'sini eşleştirir. Migration sırasında yalnız URL alanları güncellenir.

Tek İçeriğin Farklı Dil Sürümleri

Aynı content ID altında farklı locale varyantları tutulabilir. Her varyantın bağımsız publication state ve last modified değeri olabilir. İngilizce sürüm güncellenirken Türkçe sürüm eski kalabilir. Bu durumda iki URL'nin lastmod değerleri aynı olmak zorunda değildir. Veri modeli gerçek yayın durumunu yansıtmalıdır.

Locale Mapping

Locale mapping content entity ile locale sürümünü bağlar. Bu kayıtta canonical URL ve hreflang code gibi alanlar bulunabilir. Generator yalnız geçerli mapping'leri okur. Eksik locale doğal olarak cluster dışında kalır. Sahte fallback URL üretmeye gerek kalmaz.

CMS ID

CMS ID doğrudan content entity olarak kullanılabilir veya ayrı global ID ile eşlenebilir. Çoklu CMS kullanılan kurumlarda merkezi ID daha yararlı olabilir. Amaç her içeriğin platformlar arasında benzersiz biçimde tanımlanmasıdır. ID değişmez olmalıdır. URL mapping ve translation workflow bu kimliğe bağlanabilir.

Sitemap ve Hreflang Üretiminde Entity ID Kullanmak

Generator önce content ID'leri toplar, sonra her ID için yayınlanmış locale varyantlarını bulur. Böylece cluster programatik biçimde kurulur. Her varyant canonical URL'sini ve hreflang kodunu registry'den getirir. XML output bu veri üzerinden deterministik oluşturulur. Bu yaklaşım manuel eşleştirmeye göre çok daha güvenlidir.

Merkezi Locale Registry Mimarisi

Merkezi locale registry çok dilli platformun SEO ve kullanıcı deneyimi açısından en önemli veri katmanlarından biri olabilir. Registry içinde content_id, locale, canonical_url, publication_state, indexability, last_modified, hreflang_code ve market gibi alanlar tutulabilir. Sitemap generator, hreflang generator ve language switcher bu veriyi paylaşır. Böylece üç ayrı mapping tablosunun zamanla farklılaşması önlenir. Uluslararası ölçekte sürdürülebilir teknik SEO için merkezi source of truth yaklaşımı güçlü bir temeldir.

content_id

content_id içeriğin locale'den bağımsız ana kimliğidir. Bütün çeviri varyantlarını aynı aile altında toplar. URL değişse bile ID sabit tutulabilir. Hreflang cluster bu alan üzerinden oluşturulur. Yanlış content pairing testleri de ID üzerinden yapılabilir.

locale

locale içeriğin hangi kullanıcı veya pazar varyantına ait olduğunu belirtir. Bu değer yalnız dil olmayabilir. en-US gibi dil ve bölge kombinasyonları kullanılabilir. CMS locale'i ile SEO hreflang kodu gerektiğinde ayrı tutulur. Mapping açık biçimde registry'de yapılır.

canonical_url

canonical_url ilgili locale için tercih edilen gerçek production URL'sidir. Sitemap ve hreflang bu alanı kullanmalıdır. Internal link üretimi de aynı değere bağlanabilir. URL migration sırasında alan tek noktadan güncellenir. Böylece eski URL'nin farklı sistemlerde kalma riski azalır.

publication_state

publication_state locale varyantının yaşam döngüsünü belirtir. Draft, QA ve published durumlarını birbirinden ayırır. Generator yalnız izin verilen durumları sitemap'e dahil eder. Dil seçici aynı gate'i kullanabilir. Bu alan translation lifecycle ile SEO lifecycle'ı birbirine bağlar.

indexability

indexability URL'nin arama motorunda indekslenmesinin istenip istenmediğini açıklar. PUBLISHED olsa bile bazı sayfalar noindex olabilir. Generator publication state ile bu alanı birlikte kontrol etmelidir. Böylece noindex URL sitemap'e girmez. Monitoring canlı sayfada bu beklentinin gerçekten karşılandığını doğrulayabilir.

last_modified

last_modified locale sürümünün son anlamlı değişikliğini taşır. Her locale için bağımsız tutulması daha doğrudur. Kaynak içerik güncellendi diye bütün çevirilerin tarihi değiştirilmemelidir. Çeviri gerçekten güncellendiğinde ilgili locale timestamp'i yenilenir. Sitemap lastmod değeri bu gerçek veriden üretilebilir.

hreflang_code

hreflang_code SEO çıktısında kullanılacak normalize locale değeridir. CMS farklı isimlendirme kullanıyorsa mapping burada çözülebilir. Kod geçerliliği kayıt oluşturulurken doğrulanabilir. Böylece runtime sırasında hatalı locale üretilmez. Tek standart bütün uygulamalara dağıtılır.

market

market ticari hedef bölgeyi veya pazar grubunu ifade edebilir. Locale ile bire bir olmak zorunda değildir. Aynı market birden fazla dili destekleyebilir. Sitemap partition veya analytics segmentasyonu market bilgisinden yararlanabilir. SEO veri modeli iş sistemleriyle böylece daha rahat entegre olur.

Locale Registry Neden Gerekli?

Locale registry'nin ana faydası sitemap drift'i, hreflang drift'i ve kullanıcı arayüzü drift'ini azaltmasıdır. Aynı URL ilişkileri farklı ekipler tarafından farklı dosyalarda tutulduğunda hata kaçınılmaz hale gelir. Merkezi registry canonical tutarlılığı sağlar ve language switcher ile SEO çıktılarının aynı veriyi kullanmasına izin verir. Böylece yeni bir dil veya URL değişikliği tek noktada yönetilir. Çok dilli site haritası ve uluslararası teknik SEO optimizasyon hizmeti kapsamında en yüksek getirili teknik iyileştirmelerden biri çoğu zaman bu veri modelinin kurulmasıdır.

Sitemap Drift'ini Önlemek

Sitemap drift, XML dosyasındaki URL envanterinin gerçek production durumundan kopmasıdır. Silinen URL'lerin listede kalması veya yeni URL'lerin eklenmemesi buna örnektir. Registry generator için güncel veri sağlar. Event veya batch süreçleri XML'i yeniden üretir. Regression testleri beklenmeyen farkları kontrol eder.

Hreflang Drift'ini Önlemek

Hreflang drift farklı locale sürümlerinin birbirinden farklı alternatif listeleri üretmesiyle ortaya çıkabilir. Özellikle manuel head etiketlerinde bu hata sık görülür. Merkezi cluster generation bütün sayfalar için aynı ilişki setini üretir. Self-reference ve reciprocity otomatik sağlanır. Validator yine production çıktısını doğrular.

Language Switcher ile SEO Verisini Eşitlemek

Kullanıcı arayüzünde görünen locale seçenekleri ile hreflang alternatifleri aynı content entity'yi temel almalıdır. Türkçe sayfanın İngilizce karşılığı yoksa dil seçici kullanıcıyı ilgisiz İngilizce ana sayfaya göndermemelidir. Aynı şekilde hreflang da var olmayan eşdeğer üretmemelidir. Ortak registry iki sistemi senkron tutar. Bu yapı gerçek kullanıcı deneyimi ile search sinyallerini birleştirir.

Canonical Tutarlılığı

Canonical URL farklı uygulamalarda ayrı ayrı hesaplanırsa slash, host veya path farkları oluşabilir. Registry canonical adresi tek değer halinde sunabilir. Sitemap, hreflang ve internal linkler bu değeri kullanır. Böylece normalization bir kere yapılır. Contract testleri canlı HTML canonical'ının registry ile aynı olduğunu kontrol edebilir.

Merkezi Source of Truth

Source of truth, locale ve URL ilişkilerinin kurumsal olarak tek yetkili kaynaktan gelmesi anlamına gelir. Bu kaynak mutlaka tek veri tabanı olmak zorunda değildir. API veya platform servisi de olabilir. Önemli olan farklı ekiplerin farklı gerçeklikler üretmemesidir. Bu yaklaşım ölçek büyüdükçe teknik SEO bakım maliyetini azaltır.

Sitemap Generator Nasıl Çalışmalı?

İyi bir sitemap generator önce published locale kayıtlarını çeker, ardından indexability ve canonical kontrollerini uygular. Sonra content entity bazında hreflang cluster'ları oluşturur ve XML çıktısını üretir. XML yayınlanmadan önce schema, URL ve cluster validation testlerinden geçmelidir. Başarılı dosya atomik şekilde production'a alınmalı, hata durumunda son sağlıklı sürüm korunmalıdır. Bu akış sitemap'i manuel SEO dosyası olmaktan çıkarıp güvenilir bir platform bileşenine dönüştürür.

Published Locale'leri Çekmek

İlk aşama yalnız production yayın durumuna sahip kayıtları seçmektir. Draft ve QA bekleyen içerikler bu sorgunun dışında kalır. Locale retirement durumları da hariç tutulur. Böylece generator başlangıçta temiz veriyle çalışır. Filtre kuralları kod içinde test edilebilir olmalıdır.

Indexability Kontrolü

Published olmak tek başına sitemap'e girmek için yeterli değildir. noindex veya özel robots kuralı bulunan sayfalar hariç tutulmalıdır. Veri katmanındaki beklenen durum ile canlı HTML karşılaştırılabilir. Kritik farklar alert üretebilir. Böylece CMS ve frontend arasındaki hatalar fark edilir.

Canonical URL Kontrolü

Her registry kaydının canonical URL'si bulunmalıdır. URL doğru host ve protokolü kullanmalıdır. Aynı locale için duplicate canonical kayıtları engellenmelidir. Gerekirse canlı sayfadaki canonical etiketi de doğrulanır. Bu kontrol sitemap ile sayfa sinyallerini uyumlu tutar.

Hreflang Cluster Oluşturmak

Generator content ID bazında bütün yayınlanmış locale varyantlarını toplar. Her varyant için self-reference ekler. Sonra diğer varyantlara reciprocal bağlantıları üretir. x-default varsa registry kurallarına göre eklenir. Böylece cluster matematiksel olarak tam bir bağlantı setine dönüşür.

XML Üretmek

Temiz veri doğrulandıktan sonra sitemap XML oluşturulur. URL'ler anlamlı partition kurallarına göre dosyalara dağıtılabilir. Çıktının sırası deterministik tutulursa iki build arasındaki farkları okumak kolaylaşır. XML UTF-8 olarak üretilmelidir. Namespace ve entity escaping kuralları generator tarafından yönetilmelidir.

Validate Etmek

Validation yalnız XML syntax kontrolü değildir. URL status, canonical, locale code, self-reference ve reciprocity de test edilebilir. Büyük sitelerde testlerin bir kısmı build sırasında, kapsamlı tarama ise periyodik çalışabilir. Hata seviyeleri severity'ye göre sınıflandırılabilir. Kritik sitemap bozulmaları release'i engelleyebilir.

Atomik Olarak Yayına Almak

Yeni sitemap doğrudan production dosyasının üzerine parça parça yazılmamalıdır. Önce geçici dosyada tamamen oluşturulabilir. Validation başarıyla sonuçlandığında yeni sürüm tek işlemle aktif edilir. Hata yaşanırsa önceki çalışan sürüm sunulmaya devam eder. Bu model boş veya yarım XML'in crawler'a sunulmasını önler.

Sitemap Index Nedir?

Sitemap index çok sayıda sitemap dosyasını tek üst dosyada gruplamaya yarar. Çok dilli büyük sitelerde locale, market veya içerik tipi bazlı child sitemap'ler bu index altında düzenlenebilir. Örneğin ürünler ve makaleler farklı güncelleme hızına sahipse ayrı partition kullanmak debug sürecini kolaylaştırır. Search Console tarafında belirli locale sitemap'lerini ayrıca izlemek teşhis avantajı sağlayabilir. Çok dilli sitelerde sitemap index dil ve bölge URL yapısı nasıl olmalı sorusunun cevabı sitenin büyüklüğü, organizasyon yapısı ve raporlama ihtiyacına göre verilmelidir.

Çok Sayıda Sitemap'i Tek Dosyada Gruplamak

Sitemap index child sitemap dosyalarının adreslerini listeler. Böylece yüzlerce dosyanın ayrı ayrı manuel yönetilmesi gerekmez. Generator partition listesine göre index dosyasını otomatik oluşturabilir. Yeni locale eklendiğinde ilgili sitemap de index'e eklenir. Silinen partition otomatik çıkarılır.

Sitemap Index URL

Sitemap index için sabit ve öngörülebilir bir URL kullanmak operasyonu kolaylaştırır. Örneğin /sitemap-index.xml tercih edilebilir. robots.txt bu index adresini gösterebilir. Search Console'a ana index gönderilebilir. Child sitemap'ler yine bağımsız olarak erişilebilir kalır.

lastmod

Sitemap index içerisindeki lastmod child dosyanın son anlamlı değişiklik zamanını yansıtmalıdır. Her generation çalıştığında tüm tarihleri otomatik olarak bugüne çekmek doğru değildir. Gerçek içerik değişikliği yoksa timestamp sabit kalabilir. Bu davranış event-driven sistemlerde daha doğal biçimde yönetilebilir. Deterministik lastmod gereksiz değişiklik gürültüsünü azaltır.

Dil Bazlı Partitioning

Dil bazlı partition her locale'i ayrı sitemap dosyasına ayırır. sitemap-tr.xml, sitemap-en.xml ve sitemap-de.xml gibi dosyalar oluşturulabilir. Bu model locale bazında submitted ve indexed metriklerini yorumlamayı kolaylaştırır. Ancak çok büyük tek locale yine kendi içinde bölünmek zorunda kalabilir. Bu nedenle partition kuralı ölçeğe göre genişletilebilir olmalıdır.

İçerik Tipi Bazlı Partitioning

Ürün, kategori, makale ve sayfa gibi içerik tiplerini ayrı sitemap'lerde tutmak operasyonel görünürlük sağlar. Ürünler sık güncellenirken kurumsal sayfalar seyrek değişebilir. Ayrı dosyalar update frequency ve ownership ayrımını destekler. Çok dilli büyük e-ticarette dil ile içerik tipi birlikte kullanılabilir. Örneğin sitemap-tr-products.xml oldukça anlaşılır bir partition olur.

Çok Dilli Sitemap Partitioning Stratejileri

Partitioning tek bir doğru modele sahip değildir. Dil bazlı, ülke bazlı, içerik tipi bazlı veya dil ve içerik tipini birleştiren modeller seçilebilir. Karar verirken URL sayısı, locale sayısı, güncelleme sıklığı ve ekip sahipliği birlikte düşünülmelidir. Çok küçük bir sitede onlarca sitemap dosyası gereksiz operasyon üretir. Çok büyük bir platformda ise tek dev XML teşhis ve dağıtım işlerini zorlaştırır.

Dil Bazlı

Dil bazlı model en kolay anlaşılır seçeneklerden biridir. Her locale kendi URL envanterini taşır. Search Console'da locale bazındaki farklar daha rahat incelenebilir. Yeni dil eklemek yeni partition oluşturmak anlamına gelir. Locale registry bu dosya listesini otomatik üretebilir.

sitemap-tr.xml

sitemap-tr.xml Türkçe canonical ve indekslenebilir URL'leri içerir. URL'lerin yalnız tr locale'ine ait olması teşhisi kolaylaştırır. Hreflang alternates yine diğer locale URL'lerini gösterebilir. Dosya adı operasyonel anlam taşır ancak ranking faktörü değildir. Önemli olan içeriğin doğru olmasıdır.

sitemap-en.xml

sitemap-en.xml genel İngilizce URL envanterini taşıyabilir. Bölgesel İngilizce sürümleri bulunuyorsa bunun yerine daha ayrıntılı partition kullanılması düşünülebilir. Generator locale kodunu dosya adına güvenli biçimde dönüştürmelidir. URL sayısı limitlere yaklaştığında dosya otomatik bölünebilir. Index dosyası child sitemap'leri bir arada tutar.

sitemap-de.xml

sitemap-de.xml Almanca sürüm için benzer rol oynar. Partial translation bulunduğunda URL sayısının diğer dillerden az olması normaldir. Monitoring bunu otomatik hata saymamalıdır. Beklenen locale kapsamı iş kurallarıyla birlikte yorumlanmalıdır. Ani ve büyük URL düşüşleri ise alert üretmelidir.

Ülke Bazlı

Multi-regional yapıda ülke veya locale bazlı partition daha anlamlı olabilir. Aynı dilin farklı pazar sürümleri birbirinden ayrılır. Bu yaklaşım market bazlı raporlamayı kolaylaştırabilir. Dosya adlandırma standardı merkezi tutulmalıdır. Locale ve market kavramları yine veri modelinde ayrı alanlar olarak kalmalıdır.

sitemap-en-us.xml

sitemap-en-us.xml ABD pazarına yönelik İngilizce URL'leri taşıyabilir. Ürün bulunabilirliği ve fiyat koşulları bu pazara göre değişebilir. Sitemap yalnız aktif market URL'lerini içermelidir. Stokta olmayan tek ürünün davranışı ise ürün lifecycle politikasına göre belirlenir. Her markette var olmayan ürün için sahte URL oluşturulmamalıdır.

sitemap-en-gb.xml

sitemap-en-gb.xml Birleşik Krallık locale'ini ayrı izlemeye yardımcı olabilir. Aynı content entity'nin ABD ve Birleşik Krallık URL'leri hreflang ile bağlanabilir. İki sürüm birbirine canonical verilmemelidir. Her biri kendi pazar URL'sini canonical gösterebilir. Sitemap dosyaları bu canonical URL'leri listeler.

İçerik Tipi Bazlı

İçerik tipi partitioning özellikle e-ticaret ve yayın platformlarında güçlüdür. Ürünlerin, kategorilerin ve makalelerin farklı lifecycle süreçleri vardır. Hata oranlarını ayrı takip etmek sorun kaynağını daha hızlı bulmayı sağlar. Her içerik tipi farklı ekip tarafından sahipleniliyorsa operasyonel sorumluluk da netleşir. Locale sayısı büyüdüğünde bu model dil boyutuyla birleştirilebilir.

products

Product sitemap aktif ve indekslenebilir ürün URL'lerini taşır. Market availability burada önemli bir filtre olabilir. Ürün bir locale'de satılmıyorsa zorla hreflang alternatifi oluşturulmamalıdır. Parent product ve variant canonical kuralları açık biçimde tanımlanmalıdır. Product lifecycle event'leri sitemap generation'ı tetikleyebilir.

categories

Category sitemap kategori ve koleksiyon sayfalarını ayrı izlemeyi sağlar. Kategori URL'leri locale'e göre çevrilebilir. Breadcrumb ve internal link yapıları da aynı mapping'i kullanmalıdır. Kategori kaldırıldığında sitemap ve language switcher birlikte güncellenmelidir. Redirect gerekiyorsa en yakın anlamlı hedef seçilmelidir.

articles

Article sitemap makale ve içerik sayfalarını ayrı gruplar. Çeviri oranları ürünlerden farklı olabilir. Bazı makaleler yalnız belirli dillerde yayınlanabilir. Partial translation burada son derece normaldir. Her makalenin content ID'si locale varyantlarını güvenle eşleştirmelidir.

pages

Pages sitemap kurumsal veya statik sayfalar için kullanılabilir. Hakkımızda, hizmetler ve iletişim gibi içerikler bu gruba girebilir. Değişim sıklığı ürünlerden daha düşük olabilir. lastmod gerçek anlamlı güncellemeyi göstermelidir. Template deploy'u yüzünden bütün tarihleri değiştirmek gereksizdir.

Dil + İçerik Tipi Bazlı

Dil ve içerik tipi birlikte kullanıldığında çok büyük envanterler daha anlaşılır parçalara bölünebilir. Örneğin Türkçe ürünler ve Türkçe makaleler farklı sitemap'lerde tutulabilir. Search Console teşhisi bu ayrımdan yararlanabilir. Generator partition key'i locale ve content type alanlarından hesaplayabilir. Yeni içerik tipi eklendiğinde sistem aynı kurala göre genişleyebilir.

XML Sitemap Boyut ve URL Limitleri

Büyük sitelerde sitemap dosyalarını otomatik olarak bölmek gerekir. Tek bir sitemap dosyası sınırsız URL taşımaz ve sıkıştırılmamış dosya boyutunun da teknik sınırı vardır. Bu nedenle generator limitlere yaklaşmadan yeni child sitemap oluşturmalıdır. Gzip transfer maliyetini azaltabilir ancak XML'in kendisi yine doğru biçimde üretilmelidir. UTF-8, mutlak URL ve XML escaping kontrolleri release aşamasında doğrulanmalıdır.

Tek Dosya Limitleri

Sitemap generator tek dosyanın kapasitesini aşmayacak şekilde tasarlanmalıdır. Büyük URL envanterlerini tek XML'e sıkıştırmaya çalışmak doğru değildir. Partition ve rolling file numaraları kullanılabilir. Limit yaklaşırken yeni child sitemap otomatik açılır. Böylece büyüme sırasında manuel müdahale gerekmez.

Sitemap Index

Sitemap index bölünmüş XML dosyalarının tek giriş noktasıdır. Child sitemap sayısı arttıkça yönetimi kolaylaştırır. Index üretimi de generator'ın parçası olmalıdır. Eski child dosyalar kaldırıldığında index güncellenir. Stale dosya referansları validation sırasında yakalanabilir.

Gzip

Gzip sitemap dosyalarının ağ üzerinden daha verimli taşınmasına yardımcı olabilir. Büyük XML çıktılarında bant genişliği avantajı sağlar. Ancak sıkıştırma bozuk XML'i düzeltmez. Önce raw XML validate edilmeli, sonra sıkıştırma uygulanmalıdır. Monitoring sıkıştırılmış endpoint'in de başarılı yanıt verdiğini kontrol edebilir.

UTF-8

Sitemap dosyaları UTF-8 biçiminde üretilmelidir. Türkçe veya diğer dillerdeki URL karakterleri encoding kurallarına uygun işlenmelidir. XML special character escaping ayrıca uygulanmalıdır. Generator kütüphanesi bu işlemleri güvenli şekilde yapmalıdır. Elle string birleştirmek özellikle büyük projelerde risklidir.

Büyük Sitelerde Otomatik Bölme

Otomatik bölme URL sayısına veya tahmini dosya boyutuna göre yapılabilir. Partitioning önce locale ve content type gibi anlamlı anahtarlarla başlayabilir. Aynı partition hâlâ büyükse numaralı child dosyalara ayrılır. Bu yöntem Search Console görünürlüğünü korurken teknik limitleri yönetir. Generator her build'de deterministik dosya isimleri üretmelidir.

lastmod Nasıl Yönetilmeli?

lastmod gerçek ve anlamlı içerik değişikliğini yansıtmalıdır. Her sitemap generation sırasında bütün URL'lerin tarihini bugüne çekmek yanlış bir kullanım olur. Çeviri güncellemesi yalnız ilgili locale'in lastmod değerini değiştirmelidir. Structured data veya önemli internal link değişiklikleri sayfanın kullanıcı ve arama davranışını etkiliyorsa anlamlı güncelleme olarak değerlendirilebilir. Footer copyright yılının değişmesi gibi genel template değişikliklerini tüm içeriklerin güncellendiği şeklinde işaretlemek doğru değildir.

Son Önemli İçerik Güncellemesi

lastmod içerikteki son anlamlı değişikliğin tarihini taşımalıdır. Başlık, ana metin veya önemli ürün bilgisi değişmişse güncellenmesi mantıklıdır. Küçük teknik deploy'ların tamamı içerik güncellemesi değildir. CMS revision sistemi bu tarihi sağlayabilir. Generator değeri locale varyantından okumalıdır.

Çeviri Güncellemesi

İngilizce kaynak değiştiğinde Türkçe çeviri hemen güncellenmemiş olabilir. Bu durumda İngilizce lastmod değişirken Türkçe değer sabit kalmalıdır. Türkçe çeviri QA sonrasında yayınlandığında kendi timestamp'i yenilenir. Böylece her locale gerçek güncelliğini taşır. Kaynak tarihi bütün dillere kopyalamak bilgi kalitesini düşürür.

Structured Data Değişikliği

Structured data'da önemli içerik bilgileri değişmişse lastmod politikasında bunun nasıl değerlendirileceği önceden tanımlanabilir. Ürün fiyatı veya bulunabilirlik gibi sayfayı etkileyen güncellemeler anlamlı olabilir. Her schema formatting değişikliğini içerik güncellemesi saymak gerekmez. Kurallar içerik tipi bazında farklılaşabilir. Bu yaklaşım lastmod verisini daha güvenilir tutar.

Internal Link Değişikliği

Önemli navigasyon veya breadcrumb değişikliği sayfanın crawl yapısını etkileyebilir. Ancak küçük link sıralaması değişiklikleri için bütün lastmod değerlerini yenilemek gereksiz olabilir. Politika ekip içinde açık tanımlanmalıdır. Generator değişikliğin kaynağını bilirse daha doğru karar verebilir. Event metadata bu noktada yararlı olur.

Copyright Tarihini Değişiklik Saymamak

Yıl değişiminde footer tarihinin otomatik güncellenmesi bütün sayfaların içeriğinin değiştiği anlamına gelmez. Buna rağmen lastmod değerlerinin topluca yenilenmesi arama motoruna düşük kaliteli metadata sunar. Timestamp gerçek içerik revision tarihinden alınmalıdır. Global template deploy zamanı kullanılmamalıdır. Bu basit ayrım büyük sitelerde milyonlarca gereksiz tarih değişikliğini önleyebilir.

URL Slug'ları Çevrilmeli mi?

URL slug'larının çevrilmesi özellikle kullanıcı anlaşılabilirliği ve yerel arama niyeti açısından faydalı olabilir. Türkçe /tr/hizmetler/ ile İngilizce /en/services/ birbirinden bağımsız, anlaşılır URL'lerdir. Ancak slug çevirisi yapılıyorsa content entity mapping şarttır çünkü URL metninden karşılık tahmin etmek güvenilir olmaz. URL değişikliklerinde eski adres yeni canonical'a 301 ile yönlendirilmelidir. Hreflang, sitemap, internal link ve language switcher aynı release içinde yeni URL'ye güncellenmelidir.

/tr/hizmetler/

/tr/hizmetler/ Türkçe kullanıcı için anlamlı ve açık bir path örneğidir. Locale prefix'i URL'de görünür olduğu için debug süreci kolaydır. Internal navigation doğal olarak aynı locale altında kalabilir. Sitemap partition locale'i kolayca belirleyebilir. URL'nin content ID ile eşleştirilmesi yine gereklidir.

/en/services/

/en/services/ aynı content entity'nin İngilizce sürümü olabilir. Türkçe ve İngilizce slug'ların bire bir kelime yapısı kullanması şart değildir. Yerel arama niyeti ve doğal dil tercih edilmelidir. Hreflang ilişkisinin kurulması URL string benzerliğine bağlı olmamalıdır. Registry iki URL'yi aynı content ID altında birleştirmelidir.

Lokal Arama Niyeti

Yerelleştirme yapılırken yalnız çeviri sözlüğüne değil kullanıcıların gerçekten aradığı ifadelere bakmak gerekir. Bir hizmet adı farklı pazarlarda farklı terminolojiyle kullanılabilir. URL slug'ı da bu doğal terminolojiye göre seçilebilir. Bu karar teknik SEO, içerik ve localization ekiplerinin ortak çalışmasını gerektirir. URL bir kere yayınlandıktan sonra gereksiz değişikliklerden kaçınılmalıdır.

Slug Translation Mapping

Slug mapping locale varyantlarının birbirini bulmasını sağlar. Mapping content ID üzerinden kurulduğunda slug değişiklikleri güvenli yapılabilir. Eski ve yeni URL kayıtları migration tablosunda tutulabilir. Generator yalnız güncel canonical adresi sitemap'e koyar. Redirect service eski adresi yeni canonical'a yönlendirir.

URL Değişikliklerinde Redirect

Slug değiştiğinde eski URL için kalıcı yönlendirme uygulanmalıdır. Sitemap yeni URL'yi kullanmalı ve eski adresi çıkarmalıdır. Hreflang cluster bütün locale sayfalarında yeni URL'yle yenilenmelidir. Internal linkler ve language switcher da doğrudan yeni adrese bağlanmalıdır. Böylece redirect yalnız eski dış bağlantılar veya eski kullanıcı kayıtları için geçiş mekanizması olarak kalır.

WordPress Çok Dilli Sitemap Mimarisi

WordPress projelerinde çok dilli sitemap'in davranışı kullanılan tema, çeviri katmanı ve SEO eklentisine göre değişebilir. Buradaki temel kural platforma güvenip çıktıyı kontrol etmeden bırakmamaktır. Generated sitemap gerçekten yalnız canonical ve indekslenebilir URL'leri içeriyor mu, locale eşleşmeleri doğru mu ve birden fazla eklenti aynı hreflang verisini farklı biçimde üretiyor mu kontrol edilmelidir. Plugin çakışmaları özellikle canonical ve sitemap tarafında beklenmeyen sonuçlar üretebilir. Bu nedenle production crawl ve XML validation WordPress projelerinde de uygulanmalıdır.

WordPress Sitemap

WordPress kendi URL envanterinden sitemap üretebilir. Çok dilli yapı eklendiğinde hangi locale'lerin bu sitemap'e girdiği kontrol edilmelidir. Taslak veya noindex içerikler yanlışlıkla dahil olmamalıdır. Büyük sitelerde sitemap index çıktısı incelenmelidir. Otomatik üretim var diye doğrulama atlanmamalıdır.

WPML

WPML gibi locale yönetim katmanları içerik eşleştirmesi için veri sağlayabilir. Ancak SEO tarafında üretilen final hreflang ve sitemap davranışı ayrıca test edilmelidir. Çeviri publish state'i ile gerçek URL'nin indexability durumu aynı olmayabilir. URL mapping doğru çalışsa bile canonical çakışması bulunabilir. Bu nedenle final HTML ve XML çıktısı esas alınmalıdır.

Polylang

Polylang kullanılan yapılarda da aynı prensip geçerlidir. Locale bağlantılarının içerik entity'leriyle doğru eşleştirildiği doğrulanmalıdır. Slug çevirileri ve language switcher hedefleri incelenmelidir. SEO katmanının sitemap çıktısıyla uyumu test edilmelidir. Sistem değiştirildiğinde regression crawl çalıştırmak yararlı olur.

Weglot

Weglot benzeri çeviri çözümleri kullanıldığında URL üretimi ve indeksleme davranışı uygulama modeline göre değerlendirilmelidir. Gerçek ayrı locale URL'lerinin oluşup oluşmadığı kontrol edilmelidir. Canonical ve hreflang final DOM veya response içinde doğrulanmalıdır. Sitemap bu URL'lerle aynı mapping'i kullanmalıdır. Çeviri katmanı SEO mimarisinin geri kalanından bağımsız bırakılmamalıdır.

Yoast / SEO Plugin

SEO eklentisi canonical ve sitemap üretebilir fakat çok dilli eklenti başka bir veri modeli kullanabilir. Bu iki katman arasında uyuşmazlık olup olmadığı test edilmelidir. Özellikle custom post type ve taxonomy URL'leri unutulmamalıdır. noindex ayarları sitemap'le karşılaştırılmalıdır. Production output teorik ayarlardan daha güvenilir kontrol kaynağıdır.

Plugin'ler Arası Çakışma

Birden fazla eklentinin aynı canonical veya hreflang alanını üretmesi sorun oluşturabilir. HTML head içinde duplicate etiketler görülebilir. Sitemap'ler farklı URL normalizasyonu kullanabilir. Bu nedenle sahiplik net olmalıdır. Her SEO sinyalini hangi bileşenin ürettiği dokümante edilmelidir.

Generated Sitemap'i Test Etmek

Generated sitemap düzenli olarak parse edilmelidir. Child sitemap'lerin tamamı başarılı HTTP yanıtı vermelidir. Örnek URL'lerde canonical, indexability ve hreflang karşılaştırması yapılmalıdır. URL sayısındaki ani değişimler takip edilmelidir. Böylece eklenti güncellemelerinden doğan regresyonlar erken fark edilir.

Next.js ve React Projelerinde Çok Dilli Sitemap

Next.js ve React tabanlı projelerde sitemap üretimini frontend route mimarisinden bağımsız düşünmemek gerekir. Static ve dynamic route'lar aynı locale registry üzerinden modellenebilir. Server-side generation büyük ve sık değişen sitelerde güncel veri sunarken build-time generation daha küçük ve stabil projelerde yeterli olabilir. Cache kullanılıyorsa publication event sonrası invalidation süreci tanımlanmalıdır. Sitemap endpoint'i runtime hatasında boş XML üretmek yerine son sağlıklı çıktıyı sunabilmelidir.

i18n Routing

i18n routing locale URL'lerinin route katmanında nasıl üretileceğini belirler. URL prefix'leri config veya registry üzerinden tanımlanabilir. Dil kodlarını uygulamanın farklı yerlerine hard-code etmek ileride bakım problemi oluşturur. Route generator ve sitemap aynı locale listesine bağlanmalıdır. Böylece yeni dil eklendiğinde iki yapı senkron kalır.

Static Routes

Static routes hakkında, hizmetler veya kategori landing page'leri gibi sabit sayfalardan oluşabilir. Her locale için karşılık olup olmadığı registry'de açık şekilde tutulmalıdır. Her static route otomatik olarak bütün dillerde var sayılmamalıdır. Partial translation desteklenmelidir. Sitemap yalnız gerçekten yayınlanan locale route'larını üretmelidir.

Dynamic Routes

Dynamic routes ürün, makale veya profil gibi içeriklerden oluşabilir. URL sayısı yüksek olduğu için build-time sitemap pahalı hale gelebilir. Veri kaynağından streaming veya batch generation uygulanabilir. Content ID ile locale mapping özellikle önemlidir. Generator route parametresinden eşleşme tahmin etmemelidir.

Server-Side Sitemap Generation

Server-side generation güncel sitemap'i request sırasında veya cache arkasında üretmeye izin verir. Ancak her request'te milyonlarca URL üretmek performans açısından doğru değildir. Precompute ve CDN cache birlikte kullanılabilir. Regeneration başarısız olduğunda last known good çıktı korunmalıdır. Endpoint monitoring 5xx durumunu izlemelidir.

Locale Registry

Locale registry frontend router ile SEO generator arasında ortak sözleşmedir. Route prefix, domain ve hreflang code burada tutulabilir. Content variant URL'si bu kurallardan deterministik olarak üretilebilir. Registry bir API olarak farklı servislerce tüketilebilir. Schema değişiklikleri versioning ile yönetilebilir.

Build-Time vs Runtime Generation

Build-time model deployment sırasında sitemap üretir ve statik dosya olarak sunar. Runtime model içerik değiştikçe daha hızlı güncellenebilir. Çok sık yayın yapan platformlarda hybrid model daha uygun olabilir. Ana index statik, belirli yüksek frekanslı child sitemap'ler dinamik tutulabilir. Seçim trafik, içerik sıklığı ve altyapı kapasitesine göre yapılmalıdır.

Cache

Cache sitemap endpoint'inin yükünü önemli ölçüde azaltabilir. Ancak stale sitemap riski iyi yönetilmelidir. Content publish event cache invalidation tetikleyebilir. Regeneration sırasında eski sağlıklı sürüm sunulmaya devam edebilir. Cache TTL tek başına güncellik mekanizması olarak kullanılmak zorunda değildir.

Sitemap Generator İçin En İyi Programlama Dili Var mı?

Sitemap generator için tek bir en iyi programlama dili yoktur. Node.js ve TypeScript, Python, PHP, Java veya .NET aynı işi doğru mimariyle yapabilir. Seçimde mevcut backend stack, veri erişimi ve ekip yetkinliği daha önemlidir. Generator'ın hangi dilde yazıldığından çok canonical, publication state ve locale mapping verisini doğru kullanması gerekir. Test edilebilirlik ve production monitoring programlama dili tercihinden daha büyük etkiye sahiptir.

Tek Bir En İyi Dil Neden Yok?

XML üretmek birçok programlama dilinde kolaydır. Asıl problem XML syntax değil doğru URL envanteridir. Bir dil güçlü kütüphaneye sahip olsa bile yanlış registry verisiyle hatalı sitemap üretir. Mevcut platformla yakın entegrasyon bakım maliyetini düşürür. Bu nedenle teknoloji tercihi sistem bağlamında yapılmalıdır.

Node.js / TypeScript

Node.js ve TypeScript JavaScript tabanlı platformlarda doğal seçim olabilir. Type sistemleri locale registry sözleşmelerini açık biçimde modellemeye yardımcı olur. Streaming XML generation büyük envanterlerde kullanılabilir. Next.js ekosistemiyle entegrasyon kolaydır. Yine de runtime memory ve cache davranışı dikkatle tasarlanmalıdır.

Python

Python veri işleme ve validation görevlerinde güçlü bir seçenektir. Sitemap audit ve graph analiz scriptleri hızlı geliştirilebilir. Büyük XML dosyalarında streaming parser kullanmak bellek kullanımını kontrol eder. CI pipeline içinde bağımsız validator olarak çalışabilir. Backend Python ise generator aynı servis katmanına entegre edilebilir.

PHP

PHP özellikle WordPress veya PHP tabanlı CMS sistemlerinde pratik olabilir. Sitemap verisine doğrudan uygulama modelleri üzerinden ulaşabilir. Uzun süren generation işlemleri web request'inden ayrılıp background job yerine planlı komut veya deployment aşamasında çalıştırılabilir. XML kütüphaneleri kullanılmalı ve string concatenation hatalarından kaçınılmalıdır. Cache üretimi ayrıca planlanmalıdır.

Java / .NET

Java ve .NET kurumsal backend sistemlerinde locale registry veya ürün servisleriyle güçlü entegrasyon sunabilir. Büyük veri setleri batch job olarak işlenebilir. Tip güvenliği contract modellerini destekler. Monitoring ve deployment altyapısıyla mevcut standartlar kullanılabilir. Yeni bir programlama dili eklemek yerine mevcut platformdan yararlanmak çoğu zaman daha sürdürülebilirdir.

Mevcut Backend Stack'iyle Entegrasyon

Generator mümkün olduğunca canonical URL ve publication state'in üretildiği sisteme yakın olmalıdır. Ayrı veri kopyaları kullanmak senkronizasyon problemi doğurur. Backend zaten locale mapping'i biliyorsa generator bu API'yi tüketebilir. Yeni bir bağımsız spreadsheet oluşturmaya gerek yoktur. Source of truth kavramı teknoloji seçiminden önce gelir.

Dilden Çok Veri Tutarlılığı ve Test Önemlidir

Sağlam generator deterministik veri okur, doğrular ve güvenli biçimde XML üretir. Programlama dili bunun yalnız uygulama aracıdır. Canonical contract, reciprocity ve indexability testleri kaliteyi belirler. CI ve production smoke test bu sistemi tamamlar. Teknik başarı veri tutarlılığıyla ölçülmelidir.

Sitemap Cache Stratejisi

Sitemap statik XML, dinamik endpoint veya ikisinin birleşimi olarak sunulabilir. Büyük projelerde CDN cache response maliyetini azaltabilir. Ancak içerik yayınlandıktan sonra cache'in ne zaman yenileneceği açık biçimde tanımlanmalıdır. Stale sitemap günlerce eski URL envanteri göstermemelidir. Fail-safe olarak son sağlıklı sitemap sürümünü tutmak, generation hatasında boş veya bozuk XML sunmaktan daha güvenlidir.

Static XML

Static XML hızlı ve güvenilir şekilde sunulabilir. Generation deployment veya event sonrası yapılır. Dosya CDN üzerinden kolayca cache edilebilir. İçerik çok sık değişmiyorsa oldukça basit bir modeldir. Güncelleme pipeline'ının düzenli çalışması gerekir.

Dynamic Endpoint

Dynamic endpoint güncel veriyi runtime'da üretebilir. Yüksek URL sayısında her request'te full generation pahalı olabilir. Cache veya precomputed response kullanılmalıdır. Endpoint timeout ve memory limitleri izlenmelidir. Hata durumunda fallback stratejisi bulunmalıdır.

CDN Cache

CDN cache sitemap'in origin'e sürekli yük bindirmesini önleyebilir. Cache key locale veya child sitemap path'ine göre ayrılabilir. Publish event belirli dosyanın purge işlemini tetikleyebilir. Full cache purge her zaman gerekli değildir. Selective invalidation daha kontrollü olabilir.

Cache Invalidation

Cache invalidation content publish, URL change veya retirement event'lerine bağlanabilir. Her küçük içerik değişikliğinin bütün sitemap'leri yenilemesi gerekmez. Hangi partition'ın etkilendiği belirlenebilir. Örneğin Türkçe makale değişikliği yalnız ilgili article sitemap'i güncelleyebilir. Index lastmod buna göre yenilenebilir.

Stale Sitemap Riski

Stale sitemap eski URL'leri göstermeye veya yeni URL'leri kaçırmaya devam eder. Bu durum deployment ile cache süreçleri birbirinden kopunca ortaya çıkar. Dashboard child sitemap generation zamanlarını izleyebilir. Beklenen süreden eski dosya alert üretebilir. Registry ile sitemap URL sayıları karşılaştırılabilir.

Fail-Safe Son Sağlıklı Sitemap

Generator hata verdiğinde mevcut çalışan XML hemen silinmemelidir. Yeni sürüm geçici alanda oluşturulup doğrulanmalıdır. Başarısız generation durumunda son sağlıklı dosya hizmet vermeye devam eder. Monitoring ekibe hata bildirir. Böylece teknik sorun crawler tarafına bozuk output olarak yansımaz.

XML Sitemap Validation

XML Sitemap Validation yalnız dosyanın açılıp açılmadığını kontrol etmekten daha geniştir. XML well-formed olmalı, UTF-8 kullanılmalı, namespace değerleri doğru olmalı ve URL'ler mutlak adresler olarak yazılmalıdır. Dosya ve URL limitleri de generator tarafından takip edilmelidir. Entity escaping hataları özellikle query karakterleri bulunan URL'lerde sorun oluşturabilir. Bu kontroller CI/CD ve production smoke test aşamalarında otomatikleştirilebilir.

XML Well-Formed mı?

Parser dosyayı hata almadan okuyabilmelidir. Kapanmamış tag veya bozuk entity bütün sitemap'i etkileyebilir. Generator güvenilir XML library kullanmalıdır. Build sırasında parser ile output tekrar okunabilir. Böylece syntax hatası production'a çıkmadan yakalanır.

UTF-8

Encoding standardı açık biçimde UTF-8 olmalıdır. Türkçe karakterler ve diğer alfabeler güvenli şekilde işlenmelidir. URL encoding ile XML encoding birbirine karıştırılmamalıdır. Generator her iki aşamayı ayrı yönetmelidir. Test fixture'larında farklı dillerden örnekler bulunmalıdır.

Namespace Doğru mu?

Hreflang, image, video veya news extension kullanılıyorsa ilgili namespace tanımları doğru olmalıdır. Gereksiz namespace eklemek şart değildir. Kullanılan extension'ın XML şemasıyla uyumlu output üretilmelidir. Parser testleri namespace varlığını kontrol edebilir. Snapshot testleri template değişikliklerini yakalayabilir.

Mutlak URL'ler

Sitemap ve hreflang hedeflerinde tam URL kullanmak gerekir. Protokol, host ve path açık biçimde yazılmalıdır. Relative path üretimi deployment ortamına göre hatalı hostlara dönüşebilir. Production allowlist bu riski azaltır. Testler staging domain'lerini ayrıca engellemelidir.

URL Limitleri

Generator dosyadaki URL sayısını takip etmelidir. Limit yaklaşınca otomatik yeni child sitemap oluşturulabilir. Sayım yalnız ana URL kayıtları üzerinden yapılmalıdır. Partitioning algoritması deterministik olmalıdır. Böylece aynı içerik gereksiz yere farklı dosyalar arasında sürekli taşınmaz.

File Size

Dosya boyutu URL sayısından bağımsız olarak da büyüyebilir. Hreflang cluster'ları geniş olduğunda her URL kaydı daha fazla XML üretir. Generator byte size ölçümü yapabilir. Güvenlik payı bırakmak iyi uygulamadır. Limit aşılmadan yeni dosya açılmalıdır.

Entity Escaping

XML'de özel karakterler doğru escape edilmelidir. Özellikle query string içeren URL'lerde ampersand karakteri sorun yaratabilir. XML library bu işi otomatik yapmalıdır. Elle replace zinciri kullanmak risklidir. Validation parser hataları bu tür sorunları yakalayabilir.

Hreflang Validation

Hreflang validation geçerli dil kodu, geçerli region kodu, self-reference, reciprocal reference, duplicate locale, x-default davranışı ve fully qualified URL kontrollerini kapsamalıdır. Bir cluster yalnız XML olarak geçerli olduğu için SEO açısından doğru sayılmaz. Alternatiflerin aynı content entity'ye ait olması ayrıca doğrulanmalıdır. URL'lerin canonical ve HTTP 200 olması gerekir. Graph-based validator büyük locale kümelerinde bu kontrolleri otomatik biçimde çalıştırabilir.

Geçerli Dil Kodu

Language code merkezi allowlist üzerinden doğrulanmalıdır. Serbest metin kabul etmek yazım hatalarına yol açabilir. CMS locale'i SEO koduna mapping ile dönüştürülmelidir. Hatalı kod build aşamasında reddedilebilir. Böylece production XML'de geçersiz değer oluşmaz.

Geçerli Region Kodu

Region kullanılıyorsa gerçek desteklenen bölge kodu olmalıdır. Her locale'e zorla ülke eklenmemelidir. Generic dil sürümü yalnız dil koduyla kalabilir. Registry region alanını opsiyonel tutabilir. Hreflang code generator bu alanları standart sırada birleştirir.

Self-Reference

Her locale URL kendi hreflang değerini cluster içinde göstermelidir. Validator canonical URL ile self target'ı karşılaştırabilir. URL normalization farkları da kontrol edilmelidir. x-default bu testten bağımsızdır. Eksik self-reference açık hata olarak raporlanabilir.

Reciprocal Reference

Her alternatif bağlantının geri dönüş bağlantısı bulunmalıdır. Graph modelinde her edge'in karşı yönlü eşinin varlığı kontrol edilir. Büyük cluster'larda bu işlem otomatik yapılmalıdır. Eksik bağlantı hangi iki locale arasında olduğunu açık raporlamalıdır. Böylece içerik ekibi değil doğru teknik ekip sorunu çözebilir.

Duplicate Locale

Aynı cluster içinde aynı hreflang kodunun iki farklı URL'ye bağlanması veri problemi göstergesidir. Registry locale başına tek aktif canonical kaydı zorunlu tutabilir. Migration dönemlerinde eski ve yeni URL aynı anda aktif bırakılmamalıdır. Duplicate locale release'i engelleyecek seviyede hata sayılabilir. Bu kural cluster bütünlüğünü korur.

x-default

x-default varsa gerçek fallback URL'ye işaret etmelidir. Aynı cluster içinde birden fazla çelişkili x-default kaydı bulunmamalıdır. URL canonical ve erişilebilir olmalıdır. x-default kullanmak zorunlu olmadığı için validator yokluğunu otomatik hata saymamalıdır. Ancak varsa davranışını doğrulamalıdır.

Fully Qualified URL

Hreflang target tam URL olmalıdır. Protokol ve domain belirtilmelidir. Farklı domainler kullanan yapılarda bu özellikle önemlidir. Staging veya localhost adresleri build sırasında engellenmelidir. Domain allowlist güçlü ve basit bir kontroldür.

CI/CD İçinde Sitemap Testleri

Sitemap ve hreflang testlerini CI/CD içine almak international SEO'yu sürekli denetlenebilir mühendislik özelliğine dönüştürür. XML Validation, URL Format Validation, Locale Validation, Self-Reference, Reciprocity, Canonical Check ve Indexability Check otomatik çalışabilir. Her hata build'i durdurmak zorunda değildir. Kritik hatalar fail, düşük riskli değişimler warning olarak sınıflandırılabilir. Regression testi önceki build ile yeni build arasındaki URL ve cluster farklarını da raporlayabilir.

XML Validation

Üretilen fixture veya örnek sitemap her pull request'te parser ile doğrulanabilir. XML template değişiklikleri böylece güvenli biçimde test edilir. Namespace hataları erken yakalanır. Test küçük örnek veri seti üzerinde hızlı çalışabilir. Production full generation ayrı pipeline olabilir.

URL Format Validation

URL format testi HTTPS beklentisi, izin verilen domainler ve path kurallarını kontrol edebilir. Double slash veya yanlış locale prefix gibi sorunlar yakalanabilir. URL builder fonksiyonunun unit testleri bulunmalıdır. Locale bazlı route fixture'ları kullanılabilir. Bu yaklaşım mapping hatalarını production'dan önce ortaya çıkarır.

Locale Validation

Locale code registry şemasına uymalıdır. Yeni locale eklenen pull request gerekli mapping bilgileri olmadan merge edilmemelidir. Hreflang code, route prefix ve market ilişkisi doğrulanabilir. Test missing configuration durumunu açık raporlamalıdır. Böylece yeni dil lansmanı daha kontrollü olur.

Self-Reference

Test her generated cluster içinde mevcut locale URL'sini arar. Bulamazsa hata verir. URL karşılaştırması normalize edilmiş canonical adresler üzerinden yapılmalıdır. Query veya trailing slash farkı yanlış sonucu engelleyecek biçimde ele alınmalıdır. Bu test çok hızlıdır ve büyük değer sağlar.

Reciprocity

Reciprocity testi cluster graph üzerinde çalışır. Her edge'in karşılık gelen reverse edge'i olup olmadığı kontrol edilir. Eksik bağlantılar locale çiftiyle raporlanır. Yeni locale eklemelerinde bu test özellikle değerlidir. Manuel return link kontrolünü ortadan kaldırır.

Canonical Check

Generated hreflang hedeflerinin registry canonical URL'siyle aynı olması gerekir. Fixture veya integration test bu sözleşmeyi doğrulayabilir. Canlı canonical etiketi için production smoke test ayrıca çalıştırılabilir. Cross-language canonical bulunduğunda yüksek önem seviyesi verilebilir. Böylece sitemap ile page-level sinyal ayrışmaz.

Indexability Check

Registry'de noindex olarak işaretlenmiş kayıtların sitemap'e girmemesi gerekir. Unit test generator filter'ını doğrular. Production test rastgele örnek URL'lerin gerçek robots durumunu kontrol edebilir. Büyük sitelerde bütün URL'leri her deployment'ta taramak gerekmez. Risk bazlı sampling uygulanabilir.

Build Fail / Warning

Her test hatasının deployment'ı durdurması operasyonu gereksiz yere yavaşlatabilir. Kritik XML bozukluğu, staging URL veya duplicate locale fail sebebi olabilir. Küçük lastmod sapmaları warning olarak değerlendirilebilir. Severity politikası SEO ve engineering ekipleri tarafından birlikte belirlenmelidir. Böylece otomasyon gerçek risk düzeyine göre davranır.

Çok Dilli Sitemap'te En Sık Yapılan Hatalar

En sık sorunlar her locale'i sitemap'e koyup hreflang mapping yapmamak, draft translation yayınlamak, redirect veya noindex URL'leri listede tutmak ve non-canonical adresleri cluster'a eklemektir. Eksik self-reference, eksik return link ve yanlış locale kodları da çok yaygındır. Stale sitemap ise çoğu zaman otomasyon eksikliğinin sonucudur. Bu hataların ortak noktası verinin farklı yerlerde manuel tutulmasıdır. Merkezi registry, otomatik generator ve regression testleri bu problemlerin büyük bölümünü sistem seviyesinde önleyebilir.

Her Locale'i Sitemap'e Koyup Hreflang Mapping Yapmamak

Farklı dillerdeki URL'leri sitemap'e eklemek tek başına locale ilişkisini açıklamaz. Arama motorunun hangi sayfaların birbirinin karşılığı olduğunu anlaması için tutarlı hreflang yapısı gerekir. Content ID mapping olmadan bu ilişkiyi büyük ölçekte yönetmek zordur. Sitemap generator cluster bilgisini de üretebilir. Böylece discovery ve locale mapping aynı veri kaynağına bağlanır.

Draft Translation'ı Yayınlamak

Draft çeviri yalnız URL mevcut olduğu için production'a açılmamalıdır. İçerik QA ve SEO QA tamamlanmalıdır. Publication state sitemap gate olarak kullanılabilir. Dil seçici de aynı gate'i takip eder. Böylece kullanıcı ve crawler yarım içeriğe ulaşmaz.

301 URL'yi Sitemap'te Tutmak

301 veren eski URL'nin aktif sitemap'te bulunması gereksizdir. Yeni canonical adres doğrudan listeye alınmalıdır. Redirect eski dış bağlantıları ve bookmark'ları korumaya devam eder. Internal linkler yeni URL'ye güncellenmelidir. Hreflang da doğrudan yeni URL'yi göstermelidir.

noindex URL'yi Sitemap'te Tutmak

noindex ile sitemap inclusion birbirine zıt niyetler ifade eder. Bu URL generator filtresinden çıkarılmalıdır. Dashboard sitemap içindeki noindex sayısını izleyebilir. Sıfırdan farklı değer alert oluşturabilir. Bu basit metrik büyük sitelerde yararlıdır.

Non-Canonical URL Kullanmak

Hreflang ve sitemap'te non-canonical URL kullanmak sinyal tutarlılığını bozar. Her iki sistem registry canonical URL alanını kullanmalıdır. URL normalization merkezi yapılmalıdır. Migration sırasında yeni canonical aktif olduğunda generator aynı anda güncellenmelidir. Eski URL cluster'dan çıkarılmalıdır.

Eksik Self-Reference

Eksik self-reference manuel mapping hatalarının klasik örneğidir. Her locale kendisini kendi koduyla listelemelidir. Generator bunu otomatik ekleyebilir. CI testi eksikliği anında yakalar. Böylece sorun production'a ulaşmaz.

Eksik Return Link

Tek yönlü hreflang ilişkisi cluster bütünlüğünü bozar. Yeni locale yayınlandığında bütün eski locale'ler de güncellenmelidir. Merkezi generation bunu tek işlemde sağlar. Graph testi eksik reverse edge'i raporlar. Bu yaklaşım on veya daha fazla dilde özellikle gereklidir.

Yanlış Locale Code

Locale kodlarını serbest metin olarak tutmak yazım hatalarına yol açabilir. Merkezi enum veya validation schema kullanılmalıdır. CMS dahili kodları mapping üzerinden SEO koduna dönüştürülmelidir. Yeni locale pull request aşamasında doğrulanmalıdır. Böylece typo production output'a ulaşmaz.

Stale Sitemap

Stale sitemap içerik sistemi ile XML generation arasındaki kopukluğu gösterir. Yeni URL'ler eksik, silinen URL'ler hâlâ mevcut olabilir. Event-driven veya düzenli batch generation bu riski azaltır. Monitoring sitemap generation timestamp'lerini takip etmelidir. Son sağlıklı sürüm ile registry URL sayısı karşılaştırılabilir.

İyi Bir Web Yazılımcısı Çok Dilli Mimariyi Nasıl Tasarlar?

İyi tasarlanmış sistem dil kodlarını kod tabanının farklı noktalarına hard-code etmez. Locale registry kullanır, URL'leri deterministik üretir ve canonical ile hreflang'ı aynı veri kaynağına bağlar. Sitemap generation otomatik çalışır ve regression testlerle korunur. Production monitoring yalnız endpoint'in 200 dönmesini değil URL ve cluster bütünlüğünü de izler. Bu düşünce biçimi SEO'yu sonradan eklenen bir eklenti olmaktan çıkarıp web mimarisinin doğal parçası haline getirir.

Dil Kodunu Hard-Code Etmez

if language == "tr" benzeri kurallar kodun her yerine yayıldığında yeni locale eklemek zorlaşır. Config veya registry modeli daha güvenlidir. Locale özellikleri veri üzerinden okunur. Frontend, sitemap ve backend aynı listeyi kullanabilir. Bu yaklaşım deployment riskini azaltır.

Locale Registry Kullanır

Registry bütün locale bilgisini merkezi hale getirir. URL prefix, domain, hreflang ve market bilgileri aynı modelde tutulabilir. Sistemler bu veriyi API üzerinden tüketebilir. Yeni locale eklemek kontrollü configuration değişikliği olur. Testler schema kurallarını otomatik doğrular.

URL'yi Deterministik Üretir

Aynı content ID ve locale her zaman aynı canonical URL'yi üretmelidir. URL builder ortak library veya service olarak sunulabilir. Sitemap farklı, frontend farklı URL üretmemelidir. Deterministik yapı cache ve regression testlerini de kolaylaştırır. URL migration ayrı açık mapping olarak yönetilir.

Canonical ve Hreflang'ı Aynı Veriden Üretir

Canonical bir mapping tablosundan, hreflang başka dosyadan gelirse drift riski oluşur. İkisi de registry canonical URL alanını kullanmalıdır. Böylece alternate target her zaman canonical olur. Contract test bu beklentiyi doğrular. Teknik sinyaller aynı adres üzerinde birleşir.

Sitemap'i Otomatikleştirir

Manuel sitemap küçük projede bile zamanla unutulabilir. Generator publication event veya batch job üzerinden çalışmalıdır. XML validation ve partitioning otomatik yapılabilir. Yeni URL envantere eklenir, retired URL çıkarılır. SEO ekibinin dosyayı elle düzenlemesine gerek kalmaz.

Regression Test Ekler

Her yeni release sitemap davranışını değiştirebilir. Önceki build ile yeni build arasındaki URL sayısı ve cluster farkları kontrol edilmelidir. Beklenmeyen büyük silinmeler deployment'ı durdurabilir. Snapshot test küçük fixture'larda hızlı çalışır. Production smoke test canlı endpoint'i tamamlar.

Production Monitoring Kurar

Testlerin geçmesi production'ın her zaman doğru olduğu anlamına gelmez. Deployment, cache veya veri sorunları canlı çıktıyı değiştirebilir. Monitoring sitemap endpoint, child dosyalar ve örnek URL cluster'larını kontrol etmelidir. Missing hreflang ve non-canonical URL gibi metrikler dashboard'a taşınabilir. Alert eşikleri sitenin normal davranışına göre belirlenmelidir.

Diyarbakır Yazılım Topluluğu İçin Örnek Açık Kaynak Hreflang Validator

Bu konuyu öğrenmenin iyi yollarından biri gerçek bir validator geliştirmektir. Diyarbakır Yazılım Topluluğu içinde sitemap URL'si alan, XML'i parse eden, locale'leri çıkaran ve hreflang graph oluşturan açık kaynak bir proje geliştirilebilir. Araç self-reference, reciprocity, HTTP status ve canonical testlerini otomatik çalıştırabilir. Sonuçları okunabilir HTML raporu olarak sunmak geliştiricilerin hatayı hızlı anlamasını sağlar. Benzer topluluk projeleri için mevcut çalışmalara https://www.diyarbakiryazilim.com.tr/projects adresinden göz atılabilir.

Sitemap URL Girdisi

Validator kullanıcıdan sitemap veya sitemap index URL'si alabilir. Önce endpoint'in HTTP durumu kontrol edilir. Index ise child sitemap'ler keşfedilir. Domain allowlist opsiyonel güvenlik özelliği olabilir. Tarama sınırları kullanıcı tarafından ayarlanabilir.

XML Parse

XML parser streaming modunda çalışarak büyük dosyalarda bellek kullanımını azaltabilir. Namespace bilgileri doğru biçimde okunmalıdır. Parser hatası kullanıcıya dosya ve satır bilgisiyle raporlanabilir. Bozuk child sitemap diğer dosyaların analizini tamamen durdurmak zorunda değildir. Sonuç raporu partial failure bilgisini gösterebilir.

Locale Extraction

Her URL kaydındaki hreflang alternate değerleri çıkarılır. Locale kodları normalize edilir ancak hatalı değerler sessizce düzeltilmemelidir. Validator hatayı olduğu gibi raporlamalıdır. Duplicate locale kayıtları aynı aşamada tespit edilebilir. x-default ayrı kategori olarak tutulabilir.

Graph Oluşturma

Her URL bir node, hreflang ilişkisi directed edge olarak modellenebilir. Content cluster'lar bağlantı kümelerinden çıkarılabilir. Graph yapısı reciprocity testini basitleştirir. Missing edge ve broken node sorunları görselleştirilebilir. Büyük sitemap'lerde bu model güçlü analiz imkânı sunar.

Self-Reference Test

Her node'un kendi locale koduyla kendisine edge içerip içermediği kontrol edilir. Locale bilgisi registry'den bilinmiyorsa sitemap verisindeki ilişki üzerinden çıkarılabilir. Belirsizlik raporda ayrıca belirtilmelidir. x-default self-reference olarak sayılmamalıdır. Eksik kayıt yüksek öncelikli uyarı olabilir.

Reciprocity Test

Her A→B ilişkisi için B→A bağlantısı aranır. Eksik reverse edge açık şekilde raporlanır. Cluster boyutu arttığında manuel kontrolden çok daha hızlıdır. Sonuçlar locale çifti bazında gruplanabilir. En fazla hata üreten locale dashboard'da gösterilebilir.

HTTP Status Test

Validator hreflang target URL'lerine kontrollü HTTP istekleri gönderebilir. 3xx, 4xx ve 5xx target'lar ayrı hata sınıflarına ayrılır. Büyük sitelerde concurrency limiti uygulanmalıdır. Sunucuya gereksiz yük vermemek için rate limiting gerekir. Cache aynı URL'nin tekrar sorgulanmasını önleyebilir.

Canonical Test

Her target sayfanın canonical etiketi okunabilir. Hreflang URL'si ile canonical target karşılaştırılır. Cross-language canonical durumları ayrıca raporlanabilir. Redirect sonrası final URL de kaydedilebilir. Bu test hreflang canonical ve XML sitemap birlikte nasıl kullanılır sorusunu somut mühendislik kuralına dönüştürür.

HTML Rapor

Rapor toplam URL, locale ve cluster sayısını gösterebilir. Hatalar severity ve tür bazında filtrelenebilir. Her problem için kaynak URL ile target URL yan yana sunulabilir. CSV veya JSON export geliştirici entegrasyonlarını kolaylaştırabilir. Açık kaynak katkısı için kullanım ve test fixture'ları belgelenebilir.

Diyarbakır Yazılım Topluluğunda International SEO Atölyesi

International SEO konusu yalnız SEO uzmanlarının değil web geliştiricilerin de doğrudan çalışabileceği teknik bir alandır. XML temelleriyle başlayıp sitemap, hreflang, canonical ve çoklu dil URL mimarisi üzerinde uygulama yapılabilir. Ardından küçük bir validator geliştirerek öğrenilen kurallar kod üzerinde test edilebilir. Gerçek site audit çalışmaları HTTP, frontend ve backend bilgilerini aynı problem üzerinde birleştirir. Diyarbakır Yazılım Topluluğu'nun yaklaşımı ve topluluk yapısı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alınabilir.

XML Temelleri

XML öğrenmek sitemap yapısını anlamanın en doğrudan yoludur. Element, attribute, namespace ve encoding kavramları temel düzeyde öğrenilmelidir. Daha sonra gerçek sitemap dosyaları parser ile okunabilir. XML hatalarının nasıl oluştuğu örneklerle incelenebilir. Bu bilgi yalnız SEO değil birçok entegrasyon alanında işe yarar.

Sitemap

Atölyede önce küçük bir sitemap generator yazılabilir. Ardından içerik listesi locale bazında partition edilebilir. lastmod ve sitemap index kavramları eklenebilir. Hatalı URL fixture'ları test amacıyla kullanılabilir. Böylece teori doğrudan kodla ilişkilendirilir.

Hreflang

Hreflang için iki veya üç locale'lik cluster oluşturmak iyi başlangıçtır. Self-reference ve return link kuralları test edilebilir. Daha sonra x-default eklenebilir. Hatalı locale code senaryosu hazırlanabilir. Graph yaklaşımıyla validator geliştirilebilir.

Canonical

Canonical örneklerinde duplicate URL ve self-canonical davranışı incelenebilir. Cross-language canonical hatası özellikle gösterilebilir. Sitemap ile canonical listesi karşılaştırılabilir. Redirect target'ları test edilebilir. Böylece canonical yalnız HTML etiketi değil URL mimarisi olarak anlaşılır.

Çoklu Dil URL Mimarisi

Alt klasör, subdomain ve farklı domain modelleri örneklenebilir. Her modelin deployment ve Search Console etkileri tartışılabilir. Locale registry örnek şeması tasarlanabilir. URL builder fonksiyonu geliştirilebilir. Yeni bir locale eklemenin sistemde hangi noktaları değiştirdiği uygulamalı olarak görülebilir.

Validator Geliştirme

Validator projesi XML parse ile başlayabilir. Sonra HTTP, canonical ve hreflang graph testleri eklenebilir. Test-driven development yaklaşımı bu proje için oldukça uygundur. Her hata türü fixture ile temsil edilebilir. CI pipeline her katkıda testleri çalıştırabilir.

GitHub Contribution

Açık kaynak proje yeni geliştiricilerin gerçek workflow öğrenmesine yardımcı olur. Issue, branch, pull request ve code review süreçleri uygulanabilir. Her contribution küçük ve anlaşılır görevlerden başlayabilir. Dokümantasyon katkıları da teknik katkı kadar değerlidir. Proje zamanla gerçek sitelerde kullanılabilir hale gelebilir.

Gerçek Site Audit'i

Gerçek site audit'i teoride görünmeyen sorunları ortaya çıkarır. Redirect zinciri, canonical çakışması veya stale sitemap gibi örnekler canlı sistemde incelenebilir. Audit izinsiz sistemlere agresif crawl yapmadan, erişim ve etik kurallara uyarak yürütülmelidir. Bulgular issue listesine dönüştürülebilir. Sonrasında otomatik testlerle aynı hataların tekrar oluşması engellenebilir.

AI ile Çeviri Yapılan Sitelerde Sitemap Kontrolü

Otomatik çeviri üretimi yayınlama sürecini hızlandırabilir fakat sitemap'e girecek URL'nin kalite kapısından geçmesi gerekir. Otomatik Translation, Human QA, Translation State, Publish Gate ve Sitemap Gate birbirinden ayrılmalıdır. Üretilen ilk taslak doğrudan indekslenebilir production sayfasına dönüşmemelidir. İnsan kontrolü veya belirlenmiş kalite süreci tamamlanınca locale PUBLISHED durumuna geçirilmelidir. Uygulama geliştirme ve otomasyon tarafındaki benzer teknik yaklaşımlar için https://www.diyarbakiryazilim.com.tr/posts/dusuk-kodlu-low-code-araclarla-ai-uygulama-gelistirme içeriği de incelenebilir.

Otomatik Translation

Otomatik translation başlangıç taslağı üretmek için kullanılabilir. Çıktı kalite kontrolünden bağımsız olarak yayınlanmamalıdır. Terminoloji ve yerel bağlam değerlendirilmelidir. Teknik metadata da ayrıca kontrol edilmelidir. Translation state bu aşamayı açık biçimde işaretlemelidir.

Human QA

Human QA dil akıcılığı ve doğru anlam aktarımını kontrol eder. Kritik sayfalarda marka ve hukuki ifadeler ayrıca incelenebilir. Hreflang pairing'in doğru content entity'ye bağlandığı da SEO QA kapsamında doğrulanabilir. Onay tamamlanmadan publication gate açılmaz. Böylece sitemap yalnız kullanıcıya hazır içeriği gösterir.

Translation State

Translation state sürecin hangi noktada olduğunu makine tarafından okunabilir hale getirir. NOT_CREATED, TRANSLATION_PENDING, QA_PENDING ve PUBLISHED gibi açık durumlar kullanılabilir. Sitemap generator bu state'i filtre kriteri yapar. Language switcher da aynı kurala bağlanabilir. Böylece farklı sistemlerde farklı yayın tanımı oluşmaz.

Düşük Kaliteli Draft'ın Indexlenmesini Önlemek

Draft URL public olarak erişilebilir olmak zorunda değildir. Preview auth veya noindex ile korunabilir. Daha güçlü çözüm sitemap ve internal navigation'a hiç dahil etmemektir. Production route yalnız publish sonrası aktif hale getirilebilir. Bu yaklaşım kazara indekslenme riskini azaltır.

Publish Gate

Publish gate içeriğin production kullanıcılarına açılmasından önceki kontrol noktasıdır. Dil QA, SEO metadata ve URL bilgileri burada doğrulanabilir. Başarılı olduğunda publication state PUBLISHED olur. Event sitemap regeneration tetikler. Language switcher yeni locale'i göstermeye başlar.

Sitemap Gate

Sitemap gate yayınlanmış kaydın ayrıca canonical ve indexable olduğundan emin olur. PUBLISHED fakat noindex olan özel sayfalar XML'e girmez. HTTP health problemi varsa warning üretilebilir. Generator yalnız bütün temel kriterleri geçen URL'leri dahil eder. Böylece sitemap kontrollü envanter olarak kalır.

Çok Dilli Sitemap Audit Kontrol Listesi

Audit sırasında sitemap endpoint'in HTTP 200 dönmesi, XML'in geçerli olması, UTF-8 kullanımı, URL'lerin canonical ve indekslenebilir olması ilk kontrollerdir. Ardından hreflang locale kodları, self-reference, reciprocal mapping, x-default ve lastmod davranışı incelenmelidir. Translation state ile sitemap'in senkron olması özellikle çok sık içerik yayınlayan sitelerde önemlidir. Kontroller yalnız tek bir URL üzerinde değil farklı locale ve içerik tiplerinden örnekler üzerinde yapılmalıdır. Büyük sitelerde crawler çıktısı ve registry verisi karşılaştırılarak sistematik farklar bulunabilir.

Sitemap 200 Dönüyor mu?

İlk kontrol sitemap ve index endpoint'lerinin HTTP 200 vermesidir. Child sitemap'ler de ayrı kontrol edilmelidir. Redirect veya 5xx durumları raporlanmalıdır. CDN ile origin yanıtları farklıysa ikisi de incelenebilir. Monitoring bu kontrolü düzenli aralıklarla otomatik yapabilir.

XML Geçerli mi?

XML parser dosyayı sorunsuz okuyabilmelidir. Namespace ve encoding hataları kontrol edilmelidir. Bozuk tek child sitemap belirli URL grubunun keşfini etkileyebilir. CI validation ve production parse birlikte kullanılmalıdır. Hata raporunda problemli dosya açıkça belirtilmelidir.

UTF-8 mi?

Encoding metadata ile gerçek byte encoding uyumlu olmalıdır. Çok dilli URL'ler farklı karakterler içerebilir. Test fixture'larında Türkçe ve farklı alfabeler kullanılabilir. XML parser warning'leri göz ardı edilmemelidir. Standardizasyon generator katmanında yapılmalıdır.

Canonical URL'ler mi?

Sitemap URL'leri live page canonical etiketleriyle karşılaştırılabilir. Farklı canonical target bulunan adresler raporlanmalıdır. Cross-language canonical ayrıca yüksek önem taşıyabilir. Redirect target canonical olarak listelenmemelidir. Registry ve live output arasında contract testi kurulabilir.

Indexable URL'ler mi?

noindex veya robots engeli bulunan URL'ler tespit edilmelidir. Sitemap inclusion ile indexability beklentisi aynı olmalıdır. Örnekleme küçük sitelerde tam taramaya dönüşebilir. Büyük sitelerde yüksek riskli partition'lara öncelik verilebilir. Dashboard noindex count metriği gösterebilir.

HTTP 200 URL'ler mi?

Sitemap'teki URL'lerin HTTP durumları kontrol edilmelidir. 3xx, 4xx ve 5xx ayrı raporlanmalıdır. Redirect zincirleri ayrıca incelenebilir. Rate limiting uygulanarak sunucuya gereksiz yük verilmemelidir. Tekrarlanan URL'ler cache ile bir kez kontrol edilebilir.

Hreflang Locale Kodları Doğru mu?

Locale kodları allowlist ve standart formatla karşılaştırılmalıdır. Hatalı dil veya region değeri açıkça raporlanmalıdır. CMS code ile SEO code farklıysa mapping kaynaklı hata aranmalıdır. Duplicate locale aynı cluster içinde ayrıca kontrol edilmelidir. Yeni locale lansmanlarında bu test zorunlu tutulabilir.

Self-Reference Var mı?

Her locale kendisini doğru hreflang koduyla göstermelidir. Canonical URL ile self target aynı olmalıdır. x-default bu koşulu karşılamaz. Eksik kayıtlar cluster ID ile raporlanabilir. Otomatik düzeltme yerine önce veri kaynağındaki hata giderilmelidir.

Reciprocal Mapping Var mı?

Her hreflang bağlantısının dönüş bağlantısı aranmalıdır. Graph analysis bunun için uygundur. Tek yönlü ilişkiler locale çiftleri halinde gösterilebilir. Çok sayıda hata tek bir stale locale deployment'ına işaret edebilir. Root cause bulunduktan sonra bütün cluster'lar yeniden üretilebilir.

x-default Mantıklı mı?

x-default URL gerçek fallback işlevi sunmalıdır. Belirli bir ülkeye zorlanan landing page rastgele fallback olarak kullanılmamalıdır. Dil seçim sayfası veya global homepage daha uygun olabilir. Her cluster'da kullanılması zorunlu değildir. Audit varlığından çok doğruluğunu değerlendirmelidir.

lastmod Doğru mu?

lastmod değerleri bütün sitemap'te aynı timestamp'e çekilmişse generation politikasına bakılmalıdır. Gerçek içerik revision verisi kullanılması tercih edilir. Locale bazındaki tarihler birbirinden farklı olabilir. Gelecek tarihleri veya anlamsız sabit değerleri validator yakalayabilir. Güncellik metadata'sı güvenilir tutulmalıdır.

Translation State ile Senkron mu?

QA_PENDING bir locale sitemap'te görünüyorsa publication gate düzgün çalışmıyor demektir. PUBLISHED locale'in sitemap'te eksik olması da farklı bir senkronizasyon problemidir. Registry ve XML karşılaştırması bu farkları doğrudan bulabilir. Her content ID için beklenen ve gerçek locale setleri çıkarılabilir. Bu test çok dilli platformlarda yüksek değer üretir.

Sık Sorulan Sorular

Çok dilli sitemap konusu yalnız XML sözdizimiyle sınırlı olmadığı için uygulama sırasında benzer sorular tekrar tekrar karşımıza çıkar. En önemli kararlar URL mimarisi, canonical davranışı, hreflang cluster'ları ve yayın süreçleri etrafında toplanır. Aşağıdaki yanıtlar özellikle çok dilli SEO ve sitemap danışmanlığı yakınımda şeklinde araştırma yapan veya kendi teknik ekibiyle sistemi kurmak isteyenler için temel bir karar çerçevesi sunar. Her sitenin ölçeği farklı olduğu için dosya bölme ve locale stratejisi bire bir kopyalanmamalıdır. Önce mevcut URL ve içerik envanteri incelenmeli, ardından ihtiyaca uygun mimari oluşturulmalıdır.

Çok dilli sitemap nedir?

Çok dilli sitemap farklı locale sürümlerindeki canonical ve indekslenebilir URL'lerin yapılandırılmış XML envanteridir. İstenirse hreflang alternatifleri de sitemap içinde tanımlanabilir. Asıl amaç yalnız URL listesi oluşturmak değildir. Locale ilişkilerinin gerçek yayın durumu ve content entity mapping ile tutarlı olması gerekir. Sağlıklı yapı otomatik generator ve validation süreçleriyle desteklenir.

Hreflang nedir?

Hreflang aynı veya eşdeğer içeriğin farklı dil ve bölge sürümlerini ilişkilendiren sinyaldir. Örneğin Türkçe ve İngilizce hizmet sayfaları birbirine bağlanabilir. İlişki karşılıklı olmalıdır. Her locale kendisini de göstermelidir. Hreflang canonical veya indexability problemlerini tek başına çözmez.

Sitemap içine hreflang nasıl eklenir?

XML root seviyesinde gerekli XHTML namespace tanımlanır. Her url kaydı içinde loc ve locale alternatiflerini gösteren xhtml:link öğeleri üretilir. Her link rel="alternate", hreflang ve tam href değerini taşır. Bütün cluster aynı alternatif setini göstermelidir. Manuel XML yerine registry tabanlı generator kullanmak ölçek büyüdükçe daha güvenlidir.

Her dil için ayrı sitemap gerekir mi?

Her dil için ayrı sitemap zorunlu değildir. Küçük sitelerde bir sitemap yeterli olabilir. Büyük yapılarda locale bazlı partition teşhis ve yönetim avantajı sağlar. URL sayısı, içerik tipi ve Search Console reporting ihtiyacı karar üzerinde etkili olur. Teknik kural yerine operasyonel ihtiyaç temel alınmalıdır.

Tek sitemap içinde birden fazla dil kullanılabilir mi?

Evet, bir sitemap içinde farklı locale URL'leri bulunabilir. Hreflang alternate ilişkileri de aynı XML içinde tanımlanabilir. Bununla birlikte dosya büyüklüğü ve URL sayısı izlenmelidir. Büyük envanterler anlamlı partition'lara ayrılabilir. Tek dosyada olmak veya ayrı dosyada olmak tek başına sıralama avantajı sağlamaz.

Sitemap index nedir?

Sitemap index birden fazla child sitemap dosyasını tek üst dosyada listeler. Büyük ve çok dilli sitelerde dosyaların yönetimini kolaylaştırır. Locale veya içerik tipi bazlı partition'lar aynı index altında tutulabilir. robots.txt ana index URL'sini gösterebilir. Search Console'a da index gönderilebilir.

x-default nedir?

x-default belirli bir locale'e ait olmayan fallback URL'yi göstermek için kullanılabilir. Global dil seçim sayfası buna iyi bir örnektir. Her sitede kullanılması zorunlu değildir. Generic dil sürümüyle aynı kavram değildir. Self-reference yerine de geçmez.

Self-referencing hreflang nedir?

Self-referencing hreflang bir locale URL'sinin alternatif listesinde kendi adresini kendi locale koduyla göstermesidir. Türkçe sayfa kendisini tr olarak gösterebilir. Bu kayıt diğer alternatiflerle birlikte cluster'ın parçasıdır. x-default bunun yerine kullanılamaz. Validator bunu otomatik kontrol edebilir.

Return link nedir?

Return link hreflang ilişkilerinin karşılıklı olmasını sağlayan dönüş bağlantısıdır. A URL'si B'yi gösteriyorsa B de A'yı göstermelidir. Eksik return link cluster bütünlüğünü bozar. Graph validation büyük sitelerde bu hatayı hızlı biçimde bulur. Merkezi generator bağlantıları otomatik üretmelidir.

Hreflang ile canonical arasındaki fark nedir?

Canonical tercih edilen URL konusunda sinyal verir. Hreflang ise locale alternatifleri arasındaki ilişkiyi tanımlar. İkisi aynı problem için kullanılmaz. Çok dilli gerçek locale sayfaları çoğunlukla kendi canonical adreslerini taşır. Hreflang bu bağımsız canonical URL'leri birbirine bağlar.

Her dil sayfası kendisini canonical göstermeli midir?

Gerçek, bağımsız ve indekslenmesini istediğiniz locale sürümlerinde self-canonical çoğu zaman doğru modeldir. Türkçe sürüm Türkçe URL'yi, İngilizce sürüm İngilizce URL'yi canonical gösterebilir. Böylece her dil ayrı indekslenebilir. Hreflang ilişkisi bu sayfalar arasında kurulur. Duplicate veya özel teknik senaryolar ayrıca değerlendirilmelidir.

Türkçe sayfa İngilizce sayfaya canonical verilebilir mi?

Standart çeviri mimarisinde bu genellikle doğru yaklaşım değildir. Türkçe URL'yi İngilizceye canonical etmek, Türkçe sürümün bağımsız temsilci olma sinyalini zayıflatır. Aynı anda hreflang="tr" kullanmak teknik olarak çelişkili yapı oluşturabilir. Her locale'in kendi canonical URL'si tercih edilmelidir. Dil alternatifi hreflang ile tanımlanmalıdır.

Dil karşılığı olmayan sayfa hreflang'a eklenmeli midir?

Hayır, var olmayan locale için sahte URL oluşturulmamalıdır. Partial translation normaldir. Cluster yalnız gerçekten yayınlanan alternatifleri içermelidir. Yeni çeviri daha sonra yayınlandığında bütün cluster güncellenebilir. Language switcher da yalnız gerçek kullanıcı erişimi bulunan sürümleri göstermelidir.

noindex URL sitemap'te olmalı mıdır?

Normal production sitemap'te noindex URL bulunmamalıdır. Sitemap inclusion indekslenmesini istediğiniz URL'lerin envanterini temsil eder. noindex ise bunun tersine sayfanın indekslenmesini istemediğinizi bildirir. Generator bu iki durumu birbiriyle uyumlu hale getirmelidir. noindex URL sitemap'ten filtrelenmelidir.

Redirect URL sitemap'te olabilir mi?

Aktif sitemap doğrudan yeni canonical URL'yi göstermelidir. Eski redirect URL'yi listede tutmak gerekli değildir. Migration sırasında eski sitemap geçici teşhis amacıyla ayrı tutulabilir. Ancak yeni sitemap, hreflang ve internal linkler yeni URL'lere güncellenmelidir. Redirect eski adreslerden geçiş görevini sürdürür.

URL slug'ları çevrilmeli midir?

Yerel kullanıcı için anlamlı slug'lar tercih edilebilir. /tr/hizmetler/ ve /en/services/ buna örnektir. Ancak bunun zorunlu tek model olduğu söylenemez. URL'ler stabil ve anlaşılır olmalıdır. Slug çevirisi kullanılıyorsa content ID mapping daha da önem kazanır.

Alt klasör mü subdomain mi daha iyidir?

Her proje için tek bir doğru seçenek yoktur. Alt klasör tek domain ve tek CMS kullanan projelerde operasyonu basitleştirebilir. Subdomain ayrı deployment veya ekip sınırları gerektiğinde tercih edilebilir. Teknik SEO kadar altyapı, organizasyon ve yayın süreçleri de değerlendirilmelidir. Bir model seçildikten sonra URL'lerin kalıcı ve tutarlı olması daha önemlidir.

IP bazlı dil yönlendirmesi doğru mudur?

Kullanıcı deneyimini kolaylaştırmak amacıyla öneri sunulabilir fakat kullanıcıyı zorunlu şekilde yanlış locale'e kilitlemek iyi değildir. IP konumu her zaman doğru olmayabilir. Kullanıcı dil ve bölge seçimini değiştirebilmelidir. Botların bütün locale URL'lerine erişebilmesi gerekir. Kalıcı ve ayrı locale URL'leri kullanmak daha açık bir mimari sağlar.

lastmod nasıl kullanılmalıdır?

lastmod gerçek son anlamlı içerik değişikliğini ifade etmelidir. Her generation sırasında otomatik olarak bugünün tarihine çekilmemelidir. Locale bazında ayrı tutulması gerekir. Kaynak içerik güncellenmiş fakat çeviri değişmemişse iki tarih farklı olabilir. Güvenilir CMS revision verisi iyi kaynaktır.

Next.js ile çok dilli sitemap nasıl oluşturulur?

Next.js projelerinde locale registry ile static ve dynamic route'lar birleştirilebilir. Server-side veya build-time generator kullanılabilir. Canonical URL builder ve hreflang generator aynı veriyi tüketmelidir. Büyük projelerde partition ve cache stratejisi eklenebilir. Production smoke test endpoint'in gerçek çıktısını doğrulamalıdır.

WordPress çok dilli sitemap nasıl oluşturulur?

WordPress'te kullanılan locale ve SEO katmanlarının ürettiği sitemap önce incelenmelidir. Birden fazla eklentinin aynı canonical veya hreflang çıktısını üretmediğinden emin olunmalıdır. Generated sitemap canonical, indexable ve HTTP 200 URL'ler açısından test edilmelidir. Locale mapping language switcher ile karşılaştırılmalıdır. Eklenti güncellemeleri sonrasında regression kontrolü yapılmalıdır.

Sitemap generator için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. Node.js, Python, PHP, Java veya .NET kullanılabilir. En önemli ölçüt mevcut backend ve veri kaynaklarıyla güvenli entegrasyondur. Generator'ın doğru canonical ve publication state verisini kullanması gerekir. Test ve monitoring programlama dilinden daha büyük önem taşır.

Açık kaynak araçlarla hreflang testi yapılabilir mi?

Evet, XML parser, HTTP istemcisi ve graph kütüphanesiyle güçlü validator geliştirilebilir. Self-reference, reciprocity ve canonical testleri otomatikleştirilebilir. Crawler çıktıları registry verisiyle karşılaştırılabilir. CI/CD integration sayesinde hatalar deployment öncesinde bulunabilir. Açık kural seti projenin topluluk katkısıyla gelişmesini sağlar.

Yazılımcı olmak için international SEO bilmek gerekir mi?

Her yazılımcının international SEO uzmanı olması gerekmez. Ancak URL, HTTP, canonical, hreflang ve indexability kavramlarını bilmek web geliştirme kalitesini artırır. Çok dilli projelerde bu bilgiler doğrudan mimari kararları etkiler. Frontend ve backend geliştiricileri SEO sinyallerinin nereden üretildiğini anlayabilir. Böylece sorunlar yalnız yayın sonrasında SEO ekibine bırakılmaz.

Diyarbakır Yazılım Topluluğunda hreflang validator geliştirilebilir mi?

Evet, bu konu açık kaynak topluluk projesi için oldukça uygundur. XML parsing, crawler, graph validation ve raporlama gibi farklı görevler yeni geliştiricilere bölünebilir. Proje gerçek teknik SEO problemini çözerken yazılım pratiği kazandırır. Mevcut topluluk projeleri https://www.diyarbakiryazilim.com.tr/projects üzerinden incelenebilir. Topluluk hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi ziyaret edilebilir.

Ek Sık Sorulan Sorular

Aşağıdaki sorular özellikle kapsamlı bir uluslararası SEO projesine başlamadan önce karar vermeyi kolaylaştırır. Çoklu dil destekli sitemap tasarımında XML dosyasından önce URL, locale ve publication state modelinin netleşmesi gerekir. Sitemap partition sayısı sitenin gerçek boyutuna göre seçilmelidir. Canonical ve hreflang aynı content mapping sisteminden beslenmelidir. Teknik danışmanlık alınacaksa yalnız XML çıktısına değil, sistemin bütün yaşam döngüsüne bakılması daha değerlidir.

Çoklu dil destekli web sitelerinde XML site haritası mimarisi nasıl oluşturulmalıdır?

Önce her içeriğin locale sürümlerini content ID altında eşleştiren merkezi bir registry oluşturulmalıdır. Sitemap yalnız PUBLISHED, canonical, indekslenebilir ve HTTP 200 URL'lerden üretilmelidir. Büyük sitelerde locale veya içerik tipi bazlı partition kullanılabilir. Hreflang XML üzerinden üretilecekse bütün cluster'lar aynı registry'den oluşturulmalıdır. Son adımda XML, canonical, hreflang ve URL health testleri otomatik çalıştırılmalıdır.

Çok dilli site haritalarında hreflang etiketleri nasıl doğru yapılandırılır?

Her URL kendisini ve diğer gerçek locale alternatiflerini göstermelidir. Alternatif ilişkiler karşılıklı olmalıdır. Hedef URL'ler tam, canonical ve erişilebilir adresler olmalıdır. Dil ve region kodları geçerli formatta kullanılmalıdır. x-default varsa gerçek fallback sayfasına işaret etmeli ve self-reference yerine kullanılmamalıdır.

Her dil için ayrı sitemap mı oluşturulmalı yoksa tüm dil sürümleri tek site haritasında mı gösterilmelidir?

İki yaklaşım da teknik olarak uygulanabilir ve karar sitenin ölçeğine göre verilmelidir. Küçük sitelerde tek sitemap basit ve yeterli olabilir. URL ve locale sayısı büyüdükçe dil bazlı partition teşhis avantajı sağlar. İçerik tipleri de çok farklı lifecycle'a sahipse dil ve içerik tipi birlikte kullanılabilir. Hangi dosya modelinin seçildiğinden çok içindeki URL ve hreflang verisinin tutarlı olması önemlidir.

Hreflang, canonical ve x-default etiketleri çoklu dil site haritasında nasıl birlikte kullanılmalıdır?

Her gerçek locale normalde kendi canonical adresini göstermeli ve hreflang alternatifleri bu canonical URL'lere bağlanmalıdır. Self-reference her locale için bulunmalıdır. x-default yalnız belirli bir locale'e ait olmayan gerçek fallback deneyimini tanımlar. x-default, Türkçe veya İngilizce self-reference kaydının yerine geçmez. Sitemap yalnız canonical ve indekslenebilir URL'leri içerdiğinde bu üç yapı birbirini destekleyen tutarlı sinyaller oluşturur.

Çoklu dil destekli site haritası ve uluslararası SEO optimizasyonu konusunda yakınımda teknik SEO danışmanlığı nerede bulabilirim?

Yerel bir teknik toplulukla birlikte çalışmak, yalnız hazır ayar uygulamak yerine mimariyi anlamak açısından faydalı olabilir. Diyarbakır ve çevresinde yazılım, web geliştirme ve teknik projelerle ilgileniyorsanız Diyarbakır Yazılım Topluluğu'nun çalışmalarını inceleyebilirsiniz. Topluluğun yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about adresinde bilgi bulunur. Proje örnekleri için https://www.diyarbakiryazilim.com.tr/projects sayfasına bakabilirsiniz. Böylece çok dilli site haritası ve uluslararası teknik SEO optimizasyon hizmeti ihtiyacınızı yalnız tek bir XML dosyasına değil, URL mimarisi, geliştirme ve test süreçlerine birlikte bakarak değerlendirebilirsiniz.

Sonuç — Çok Dilli Sitemap Bir XML Dosyası Değil, Locale Mimarinizin Arama Motorlarına Yansımasıdır

Yapısal Çoklu Dil Destekli (Multi-Language) Site Haritası Mimarisi yalnız sitemap.xml üretme işi değildir. Önce locale URL'leri doğru tasarlanmalı, ardından her içeriğin farklı dil ve pazar sürümleri kalıcı bir content entity üzerinden eşleştirilmelidir. Canonical, hreflang, language switcher ve sitemap aynı source of truth'tan üretildiğinde sistem hem kullanıcı hem arama motoru açısından daha tutarlı hale gelir. Büyük projelerde partitioning, CI/CD validation, graph testleri ve production monitoring manuel kontrol yükünü önemli ölçüde azaltır. En iyi mimari, localization sürecini teknik SEO'dan ayrı tutmak yerine aynı yayın yaşam döngüsü içinde yönetir.

Önce Yapısal Locale URL'leri Tasarlanmalıdır

International SEO projesi sitemap ile değil URL mimarisiyle başlamalıdır. Her indekslenebilir locale'in ayrı ve kalıcı URL'si bulunmalıdır. Alt klasör, subdomain veya ccTLD kararı operasyonel ihtiyaçlarla birlikte verilmelidir. URL üretimi deterministik olmalıdır. Böylece sonraki canonical ve hreflang katmanları sağlam temele oturur.

Her İçeriğin Locale Sürümleri Merkezi Olarak Eşleştirilmelidir

Content ID bütün locale varyantlarını aynı ailede tutmalıdır. URL metninden içerik eşleşmesi tahmin edilmemelidir. Registry hangi çevirinin gerçekten yayınlandığını bilmelidir. Partial translation doğal olarak desteklenmelidir. Bu yapı hreflang cluster generation'ın güvenilir temelidir.

Canonical ve Hreflang Aynı Source of Truth'tan Üretilmelidir

Canonical ve hreflang farklı sistemlerden üretilirse zamanla URL farkları oluşabilir. Registry canonical URL'yi tek değer halinde sağlamalıdır. Sitemap ve language switcher da aynı hedefi kullanmalıdır. Contract testleri production çıktısını bu veriyle karşılaştırabilir. Böylece teknik sinyaller birbirini destekler.

Sadece Yayındaki Canonical ve Indexable URL'ler Sitemap'e Girmelidir

Draft, preview, redirect ve noindex URL'leri production sitemap dışında kalmalıdır. Publication state ile indexability ayrı filtreler olarak değerlendirilmelidir. HTTP status son kontrolü tamamlayabilir. URL'nin yalnız CMS'de bulunması sitemap'e girmek için yeterli değildir. Arama sonucunda görmek istediğiniz gerçek production URL'leri seçilmelidir.

Büyük Sitelerde Sitemap'ler Anlamlı Partition'lara Ayrılmalıdır

Locale, market ve içerik tipi partition için kullanılabilir. Amaç dosya sayısını artırmak değil yönetilebilir envanter oluşturmaktır. Search Console reporting ihtiyacı karar üzerinde etkili olabilir. Çok büyük partition'lar otomatik olarak child dosyalara bölünebilir. Sitemap index bu dosyaları tek giriş noktasında toplar.

Hreflang Cluster'ları Otomatik Olarak Test Edilmelidir

Self-reference ve reciprocity manuel kontrol için uygun değildir. Locale sayısı büyüdükçe edge sayısı hızla artar. Graph validator eksik veya duplicate ilişkileri otomatik bulabilir. Canonical ve HTTP health testleri aynı rapora eklenebilir. CI ve production monitoring birlikte kullanıldığında regressions daha erken fark edilir.

Translation Lifecycle Sitemap Generation'a Bağlanmalıdır

Çeviri PUBLISHED durumuna geçmeden sitemap'e eklenmemelidir. Publish event ilgili cluster ve sitemap partition'ı güncelleyebilir. Retired locale aynı sistem üzerinden çıkarılabilir. Language switcher da bu lifecycle'ı takip etmelidir. Böylece içerik operasyonu ile SEO envanteri senkron kalır.

CI/CD ve Production Monitoring ile Drift Önlenmelidir

CI testleri hataların merge edilmesini azaltır fakat canlı sistem yine ayrıca izlenmelidir. Cache, deployment veya veri senkronizasyonu sorunları production'da farklı sonuçlar yaratabilir. Sitemap endpoint, URL count ve cluster health düzenli ölçülmelidir. Ani değişiklikler alert oluşturmalıdır. International SEO böylece sürekli doğrulanan platform davranışına dönüşür.

En Olgun Mimari Sitemap, Hreflang, Canonical, CMS ve Localization Süreçlerini Tek Locale Platformunda Birleştirir

Olgun sistemde sitemap ayrı bir SEO dosyası olarak yaşamaz. CMS içeriği, translation workflow, canonical URL, hreflang cluster ve language switcher aynı locale platformuna bağlanır. İçerik yayınlandığında bütün teknik çıktılar kontrollü olarak güncellenir. Validation ve monitoring sistemin sağlığını sürekli kontrol eder. Çok dilli bir proje planlıyor, açık kaynak çalışmalara katılmak veya bu mimariyi uygulamalı olarak öğrenmek istiyorsanız https://www.diyarbakiryazilim.com.tr üzerinden Diyarbakır Yazılım Topluluğu'na ulaşabilirsiniz.