Diller

Hreflang Nasıl Uygulanır (Adım Adım)

Üç hreflang yönteminin tümü için çalışan kod — HTML head etiketleri, HTTP Link başlıkları ve XML site haritası ek açıklamaları — ayrıca sözdizimi kuralları, ölçekte CMS otomasyonu ve gerçekten doğru şekilde yayınlandığını doğrulamak için doğrulama iş akışı.

İlk yayın tarihi: 2 Tem 2026 · Son güncelleme: 8 Ağu 2026 · Advanced
Diller
AIYazanAI v2
Bu sayfada 1 kanıt sinyali

Hreflang eklemenin tam olarak üç yolu vardır — head içinde HTML link etiketleri, HTTP Link yanıt başlıkları (PDF gibi HTML olmayan dosyalar için) veya XML site haritasında xhtml:link girdileri (ölçekte en iyisi). Birini seçin; Google üçünü de eşdeğer kabul eder ve birleştirmenin bir faydası yoktur. Her yöntem aynı iki tartışılmaz kurala uyar: kendine referans (her sayfa kendini listeler) ve karşılıklılık (A, B'yi gösteriyorsa, B de A'yı göstermelidir, aksi takdirde Google çifti yok sayar). Kodlar ISO 639-1 dil kodu artı isteğe bağlı ISO 3166-1 alpha-2 bölge kodudur; x-default geri dönüş değeridir. Hepsini tek bir doğruluk kaynağından üretin, ardından yalnızca kaynağı görüntüleyerek değil, işlenmiş head'i doğrulayın — 374 756 alan adı üzerinde yaptığım çalışmada, hreflang kurulumlarının %67'sinden fazlasında en az bir sorun vardı.

TL;DR — Üç yöntem, birini seçin: <link> içinde HTML <head> etiketleri, HTTP Link: başlıkları (PDF gibi HTML olmayan dosyalar için tek seçenek) veya bir XML site haritasındaki <xhtml:link> girdileri (ölçekte en iyisi — makine tarafından oluşturulan tek bir dosya, QA’sı en kolay). Google üçünün eşdeğer olduğunu ve bunları birleştirmenin bir faydası olmadığını söylüyor. Her yöntem öz referans + karşılıklılık kuralına uyar, mutlak URL’ler kullanır ve ISO 639-1 dil + isteğe bağlı ISO 3166-1 alpha-2 bölge kodlarını kullanır. Her şeyi tek bir doğruluk kaynağından üretin — elle bakımı yapılan hreflang bozulur. Ardından oluşturulan head’i doğrulayın, karşılıklılık için tüm kümeyi tarayın ve her URL değişikliğinden sonra yeniden kontrol etmeye devam edin. Tarayıcıları coğrafyaya göre otomatik yönlendirmeyin.

Bir satır kod yazmadan önce: üç karar

1. Hangi yöntem. Google, seçimin performansla değil kolaylıkla ilgili olduğunu açıkça belirtiyor — “The three methods are equivalent from Google’s perspective and you can choose the method that’s the most convenient for your site.” (çeviri) «Üç yöntem Google’ın bakış açısından eşdeğerdir ve siteniz için en uygun olan yöntemi seçebilirsiniz.» Benim kaba kuralım:

Evidence for this claim Google supports equivalent HTML, HTTP-header, and sitemap methods for declaring localized versions; HTTP headers can be used for non-HTML files such as PDFs. Scope: Google Search hreflang implementation methods. Confidence: high · Verified: Google: Localized versions
  • Bir avuç URL, statik veya basit bir site, az sayıda yerel ayar → HTML <link> etiketleri.
  • HTML olmayan varlıklar (PDF’ler, belgeler) → HTTP Link: başlıkları (başka seçeneğiniz yok — bir PDF’de <head> yoktur).
  • Çok sayıda yerel ayar, mevcut bir site haritası hattı veya headless/JAMstack kurulumu → XML site haritası, programlı olarak oluşturulur.

Karar Ağaçları merceği bunu gerçek bir akış şeması olarak ele alır.

2. Tek doğruluk kaynağı. Hangi yöntemi seçerseniz seçin, ek açıklamalar tek bir yerden üretilmelidir — veritabanınızdaki bir yerel ayar/çeviri tablosu, bir CMS ilişki alanı veya (küçük siteler için) tek bir elektronik tablo. En kötü hreflang anti-deseni, sayfa başına etiketleri elle bakım yapmaktır. Bir yerel ayarın şablonu saptığı anda, geri dönüş bağlantıları kaybolur ve çiftler düşer.

3. Yöntemleri birleştirmeyin. Üçünü de çalıştırabilirsiniz; Google’ın faydası olmadığını söylüyor ve her ek yöntem, üç kopyanın birbiriyle çelişmesi için başka bir yüzeydir.

Evidence for this claim Google requires fully qualified alternate URLs and reciprocal links, and recommends including each page itself in its alternate set. Scope: Google Search hreflang rules shared by all delivery methods. Confidence: high · Verified: Google: Hreflang guidelines

Yöntem 1 — <link> içinde HTML <head> etiketleri

Google’dan birebir alınan sözdizimi şöyledir:

<link rel="alternate" hreflang="lang_code" href="url_of_page" />

Geri dönüşlü, çok dilli, çok bölgeli bir küme için tam çalışan bir set:

<link rel="alternate" hreflang="en-us" href="https://example.com/us/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Bu tam blok, kümedeki her sayfaya gider (ABD sayfası, Birleşik Krallık sayfası, Almanya sayfası ve ana sayfa) — her biri kendi öz referans satırını içerir. Karşılıklılığı sağlayan şey budur.

Yerleşim katı bir kuraldır. Google: “The <link> tags must be inside a well-formed <head> section of the HTML.” (çeviri) «<link> etiketleri, HTML’nin iyi biçimlendirilmiş bir <head> bölümünün içinde olmalıdır.» Ve kendi sorun giderme tavsiyeleri: “If in doubt, paste code from your rendered page into an HTML validator to ensure that the links are inside the <head> element.” (çeviri) «Şüpheye düşerseniz, bağlantıların <head> öğesinin içinde olduğundan emin olmak için oluşturulmuş sayfanızdaki kodu bir HTML doğrulayıcıya yapıştırın.»

Bu, kulağa geldiğinden daha önemlidir, çünkü çoğu yazılı rehberin atladığı bir hata modu vardır: hreflang etiketleri <head> dışına ve geçersiz oldukları <body> içine zorlanabilir. Pubcon Vegas 2019 sunumumda bunu doğrudan işaretledim — etiketler meşru olarak gövdede bulunamaz (bu, bir sitenin başka bir sitenin alternatiflerini ele geçirmesine izin verir), ancak hatalı biçimlendirilmiş veya enjekte edilmiş bir <p> etiketi veya bir iframe, <head>’i erken kapatabilir, böylece ondan sonraki her şey — hreflang’ınız dahil — <body> içinde oluşturulur. Etiket teknik olarak kaynakta mevcuttur ancak sessizce geçersizdir. Hata ayıklamanın en hızlı yolu tarayıcı DOM kesme noktalarıdır: etiketlerin oluşturulan DOM’da gerçekte nereye düştüğünü izleyin, ardından <head>’i bozan işaretlemeye geri dönün.

HTML etiketleri ne zaman mantıklıdır: yönetilebilir sayıda yerel ayara sahip küçük ve orta ölçekli siteler, sayfa başına <link> bloğunun büyümediği yerler. Düzinelerce yerel ayarı olan bir sitede, her sayfa büyük bir işaretleme bloğu taşır — büyük sitelerin site haritası yöntemine yaslanmasının nedenlerinden biri de budur.

hreflang’i aynı alternate öğesi üzerindeki diğer <link> öznitelikleriyle karıştırmayın. Google’ın rehberliği, <link rel="alternate"> taşıyan bir hreflang öğesinin aynı etikette media gibi ilgisiz bir alternate özniteliği de taşımaması gerektiğini açıkça belirtir — aynı URL için hem bir dil/bölge alternatifi hem de bir medya sorgusu alternatifi gerekiyorsa, bunlar birleştirilmiş tek bir öğe değil, iki ayrı <link> öğesidir. Bunları karıştırmak, Google’ın ikisi olarak da ayrıştıramayacağı bir etiketle sonuçlanmanın kolay bir yoludur.

Yöntem 2 — HTTP Link: başlıkları

Aynı bilgi, HTML yerine HTTP yanıtında gönderilir. Sözdizimi:

Link: <https://example.com/file.pdf>; rel="alternate"; hreflang="en",
      <https://de-ch.example.com/file.pdf>; rel="alternate"; hreflang="de-ch"

Her URL’nin etrafındaki açılı parantezlere, noktalı virgülle ayrılmış özniteliklere ve her alternatifi ayıran virgüle dikkat edin. Başlıktaki her URL virgülle eklenir.

Buna ne zaman ihtiyacınız olur: HTML olmayan kaynaklar. Bir PDF, bir .doc, doğrudan sunulan bir görsel — hiçbirinin <head> etiketlerini tutacak bir <link> bölümü yoktur, bu nedenle başlık, hreflang’ı bunlara eklemenin tek yoludur.

Yapılandırma hususları: bu başlıkları sunucu veya CDN katmanında ayarlarsınız (bir Apache Header yönergesi, bir Nginx add_header, bir Cloudflare/Fastly/CloudFront yanıt başlığı kuralı veya uygulamanızın yanıtı). Başlık belge başına işaretleme yerine altyapı tarafından ayarlandığından, karşılıklılık kuralını burada bozmak kolaydır — İngilizce PDF’nin başlığı ve Almanca PDF’nin başlığı genellikle ayrı ayrı yapılandırılır, bu nedenle her birinin tüm seti (kendisi dahil) listelediğinden emin olmak size kalmıştır. Başlık oluşturmayı, HTML/sitemap yaklaşımınızla aynı yerel ayar tablosuyla yönlendirin.

Tutulması gereken değişmez: her alternatif yanıt, her seferinde aynı eksiksiz seti taşır. İngilizce PDF’nin başlığının Almanca alternatifi listelemesi yeterli değildir — Almanca PDF’nin yanıtı, her yanıtta (yalnızca bir tarayıcının denk geldiği ilkinde değil) aynı seti (kendisi artı diğer tüm alternatifler) geri taşımak zorundadır. Başlığı, ayarlayıp unuttuğunuz tek seferlik bir şey olarak değil, oluşturulmuş çıktı olarak ele alın.

Yöntem 3 — XML sitemap <xhtml:link> ek açıklamaları

Ölçekte, bu genellikle doğru tercihtir: tüm küme bir (veya birkaç) makine tarafından oluşturulan dosyada yaşar, hiçbir şey her sayfanın <head> bölümünü şişirmez ve — tüm ilişki grafiği tek bir yerde olduğu için — QA yapması açık ara en kolay yöntemdir. Sözdizimi:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.example.com/english/page.html</loc>
    <xhtml:link rel="alternate" hreflang="de"
                href="https://www.example.de/deutsch/page.html"/>
    <xhtml:link rel="alternate" hreflang="en"
                href="https://www.example.com/english/page.html"/>
  </url>
  <url>
    <loc>https://www.example.de/deutsch/page.html</loc>
    <xhtml:link rel="alternate" hreflang="de"
                href="https://www.example.de/deutsch/page.html"/>
    <xhtml:link rel="alternate" hreflang="en"
                href="https://www.example.com/english/page.html"/>
  </url>
</urlset>

Sitemap yönteminde insanların takıldığı iki şey:

  1. Ad alanı bildirimi zorunludur. xmlns:xhtml="http://www.w3.org/1999/xhtml" öğesindeki o <urlset> isteğe bağlı bir süsleme değildir — onu atlarsanız dosyadaki her <xhtml:link> geçersiz olur.
  2. Her <url> bloğu kendi kendine eksiksiz olmalıdır. Yukarıdaki her iki <url> bloğunun, kendi <loc> öğeleri dahil her iki alternatifi de listelediğine dikkat edin. Her <url> girişi tam seti taşır (kendine referans + tüm alternatifler). Bir sitemapta karşılıklılık yalnızca “her URL’nin bloğu, kümedeki her URL’yi (kendisi dahil) listeler” anlamına gelir.

Oluşturucuyu gereğinden fazla mühendislikle donatmamanız için bilmeye değer iki davranış: bir <xhtml:link> bloğu içindeki <url> alt öğelerinin sırası Google için önemli değildir — onları sıralamak için zaman harcamayın — ve bu <xhtml:link> ek açıklamaları, bir <url> girişinin alt öğeleri oldukları ve kendileri ayrı <url> girişleri olmadıkları için sitemap’inizin dosya başına 50 000 URL sınırına dahil edilmez.

Programatik olarak oluşturma. Sitemap yönteminin tüm amacı, CMS’nizin kendi çeviri verilerinin bir yan ürünü olmasıdır. CMS’niz /english/page.html ve /deutsch/page.html dosyalarının birbirinin çevirisi olduğunu zaten biliyorsa, sitemap oluşturucunuz bu ilişki tablosunu gezinmeli ve <xhtml:link> bloklarını derleme zamanında (veya sitemap isteği zamanında) yaymalıdır. Bunu yaparsanız, hreflang gerçeklikle senkronizasyonu kaybedemez — her seferinde gerçeğin kaynağından yeniden oluşturulur ve bir yerel ayar eklemek, yüzlerce sayfada elle düzenleme değil, bir veri değişikliğidir.

Ekipler için geliştirici kaynakları olmadan, Ahrefs hreflang rehberimde hafif bir Google Sheets şablonu oluşturdum: bir Kurulum sekmesi (varsayılan bir dil artı en fazla dört varyant seçin), bir URL’ler sekmesi (her dilin URL’lerini sütunlara yapıştırın) ve sizin için sitemap XML bloğunu otomatik olarak oluşturan bir Sonuçlar sekmesi. Bu, gerçek bir CMS entegrasyonunu haklı çıkaramayacak kadar küçük siteler için somut hale getirilmiş “tek doğruluk kaynağı” fikridir.

Hangi yöntemi seçerseniz seçin geçerli olan kurallar

Bunlar yöntemden bağımsızdır ve tartışılmaz.

  • Kendine referans. Her sayfa (veya her <url> bloğu veya her başlık) kendisini listeler. Mueller bunu isteğe bağlı-ancak-iyi-uygulama olarak çerçeveler, ancak bunu atlamak çalışmamdaki alan adlarının %18,0’ında mevcuttu — otomatikleştirin ve hiçbir maliyeti olmaz.
  • Karşılıklılık. “Each language version must list itself as well as all other language versions.” Ve uygulama: “If two pages don’t both point to each other, the tags will be ignored. This is so that someone on another site can’t arbitrarily create a tag naming itself as an alternative version of one of your pages.” Eksik bir geri dönüş bağlantısı çifti düşürür.
  • Mutlak, tam nitelikli URL’ler. “Alternate URLs must be fully-qualified, including the transport method (http/https)” — yani https://example.com/foo, asla //example.com/foo veya /foo değil. Ve URL, Google’ın dizine eklediği tam biçimle eşleşmelidir: protokol, www, sondaki eğik çizgi ve büyük/küçük harf hepsi uyumlu olmalıdır, aksi takdirde geri dönüş bağlantısı eşleşmesi başarısız olur.

Kodları doğru almak

“The first code of the hreflang attribute is the language code (in ISO 639-1 format) followed by an optional second code that represents the region code (in ISO 3166-1 Alpha 2 format).” Bunları bir tire ile birleştirin: en-US. Bir dili tek başına hedefleyebilirsiniz (es = İspanyolca her yerde), ancak bir bölgeyi tek başına hedefleyemezsiniz — her zaman önce bir dil vardır.

En sık gördüğüm hatalar (ve çalışma veri setinde gördüklerim):

  • en-UK yerine en-GB — uk Ukraynaca’dır, Birleşik Krallık’ın bölge kodu gb’dir.
  • Japonca için jp yerine ja, Çince için cn yerine zh.
  • İki harfli ISO 639-1 gerektiğinde üç harfli kodlar (ger, eng).
  • Bölge kodu olarak EU, UN veya UK kullanmak — hiçbiri geçerli ISO 3166-1 alpha-2 hedefleri değildir.

x-default, geri dönüş için ayrılmış değerdir — açık yerel ayarlarınızdan hiçbiriyle eşleşmeyen kullanıcılara hizmet veren bir dil seçici veya otomatik yönlendiren bir ana sayfa:

<link rel="alternate" href="https://example.com/" hreflang="x-default" />

Zorunlu değildir. Çalışmamda en çok eksik olan öğeydi (alan adlarının %56,3’ü bunu atladı), ancak eksik bir x-default, eksik bir karşılıklı etiket gibi kümeyi bozmaz — Google, eşleşmeyen kullanıcılar için kendi dil/bölge algılamasına geri döner. Yine de ekleyin; bu bir kontrol listesi öğesidir, küme kırıcı değil. (Bu kümede özel bir x-default alt konusu vardır.)

Ölçekte uygulama — CMS ve platform yaklaşımları

WordPress. Yoast SEO does not generate hreflang on its own. To actually output tags you need a multilingual plugin — WPML or Polylang. WPML auto-generates hreflang for every page that has translations, adds an x-default pointing at your default-language version, and by default injects the annotations into the XML sitemap; there’s a setting under WPML → Languages → SEO Options (“Display alternative languages in the HEAD section”) if you want head-tag output instead of, or in addition to, the sitemap. (See WPML’s docs on using it with Yoast.)

Shopify. Shopify Markets, pazarlar/dilleri yapılandırdıktan ve içerik yayınlanıp gezinmeye eklendikten sonra otomatik olarak karşılıklı bağlantılı hreflang etiketleri oluşturur — bu da en yaygın hata modunu (eksik karşılıklı bağlantılar) tasarım gereği ortadan kaldırır. Sorun şu: Markets’in otomatik etiketleri genellikle yalnızca dil (fr, de) biçimindedir, dil-bölge (fr-FR, fr-CA) biçiminde değildir; bu da bölgesel özgüllüğe ihtiyaç duyan markaları yetersiz bırakır — Fransa için Fransızca vs. Kanada vs. Belçika. Bunun için <link> içinde manuel theme.liquid etiketlerine (Shopify’ın kendi tema hreflang belgeleri bu kalıbı gösterir) veya bir uygulamaya geçmeniz gerekir — ve dikkatli olun, çünkü otomatik Markets etiketlerini manuel/uygulama etiketleriyle karıştırmak belgelenmiş bir çakışma kaynağıdır. Birini seçin.

Özel / headless / kurumsal. Çeviri-ilişki tablonuzdan derleme veya sunum zamanında açıklamaları oluşturun, yukarıdaki site haritası bölümünde açıklandığı gibi. Bu, aynı “tek doğruluk kaynağı” ilkesidir — hreflang, CMS’nizin zaten sahip olduğu verilerin hesaplanmış bir çıktısı haline gelir, elle bakımı yapılan ve bozulabilecek bir yapı değil.

Kümeyi bozan uygulama hataları

Coğrafi/IP’ye göre otomatik yönlendirme. Bu, sözdizimi hatalarından ayrı bir hatadır ve daha kötüdür. Ziyaretçileri — ve özellikle tarayıcıları — algılanan konuma göre bir sürüme yönlendirirseniz, tüm bölgesel kümelerin dizinden çıkarılmasına neden olabilirsiniz, çünkü Googlebot çoğunlukla ABD’den tarar. O Pubcon sunumunda söylediğim gibi: bir coğrafi yönlendirme “arama motorlarını taradıkları yere yönlendirir. Örneğin Google çoğunlukla ABD’den tarar, bu yüzden tüm coğrafi sayfaları fiilen dizinden çıkarırdık.” Burada bir düzenleyici boyut da var — AB’nin coğrafi engelleme karşıtı kuralları kapsamında potansiyel risk. Doğru model kullanıcıları yönlendirmek, tarayıcıları asla: insan ziyaretçileri tespit edin ve (isteğe bağlı olarak) yönlendirin, ancak botların her URL varyantına doğrudan erişmesine her zaman izin verin; asıl yönlendirme sinyalini hreflang versin. Google’ın kendi çok bölgeli rehberliği tam da bu nedenle otomatik yönlendirme yerine müdahaleci olmayan bir öneri bandı önerir.

Hreflang’i canonical olmayan, yönlendirilmiş veya noindex URL’lere yönlendirmek. Bir yerel ayarın URL’si değişirse ve yönlendirme eklenirse ancak hreflang hâlâ eski URL’yi gösteriyorsa, kümeniz artık bir 301 veya 404’e referans veriyor demektir (çalışmamda alan adlarının %16,9’u bozuk/yönlendirilmiş sayfalara referans veriyordu). Benzer şekilde, her varyant kendisine canonicalize edilmelidir; canonicalize edilmiş bir URL’ye veya noindex’li bir sayfaya hreflang işaret etmek, geri dönüş bağlantısını bozar (%8,0’ı canonical olmayan URL’lere işaret ediyordu).

Tutarsız URL biçimleri. Hreflang URL’si ve dizine eklenen URL, biçim olarak bayt düzeyinde aynı olmalıdır — sondaki eğik çizgi, www, protokol ve büyük/küçük harf dahil. Buradaki bir uyumsuzluk sessiz bir karşılıklılık hatasıdır.

Yayın sonrası uygulamanızı doğrulama

Yalnızca ham kaynağı değil, oluşturulmuş kaynağı görüntüleyin. Hreflang’iniz istemci tarafı JavaScript ile ekleniyorsa, curl veya Ctrl+U (“Sayfa Kaynağını Görüntüle”) hiçbir şey göstermez — ancak etiketler oluşturulmuş DOM’da mevcuttur. GSC URL İnceleme → “Canlı URL’yi Test Et” → “Test Edilen Sayfayı Görüntüle” veya oluşturma yeteneğine sahip bir tarayıcı ile doğrulayın. Birinin “etiketlerim eksik” demesinin en yaygın nedeni budur; oysa aslında her şey yolundadır (veya tam tersi — kaynakta mevcut ancak <body> içinde oluşturuldukları için bozuk).

Tüm kümeyi tarayın, tek bir URL’yi rastgele kontrol etmeyin. Karşılıklılık, sayfalar arasındaki bir ilişkidir, bu nedenle tek bir sayfayı kontrol etmek size neredeyse hiçbir şey söylemez. Tüm küme genelinde bir tarayıcı çalıştırın — Screaming Frog’un hreflang denetimi veya Ahrefs Site Audit — eksik geri dönüş etiketlerini, canonical olmayan hedefleri ve bozuk referansları ölçekte yakalamak için. Ahrefs Site Audit’in Hreflangs sekmesi, kümeyi bozuk bağlantılar kırmızı olacak şekilde bir grafik olarak çizer; bu, bir CSV’den çok daha kolay anlaşılır.

Gerçek SERP’leri &hl= ve &gl= ile doğrulayın. Bir Google arama URL’sine ana dil (&hl=) ve coğrafi konum (&gl=) parametrelerini ekleyerek, belirli bir yerel ayarın sonuçlarının gerçekte nasıl göründüğünü önizleyin; kendi konumunuzdan tahmin yürütmek yerine.

Doğrulama tek seferlik bir adım değildir. Yeni yerel ayarlar, URL/yönlendirme değişiklikleri ve geliştirme/hazırlık yapılandırmasının üretime sızması, lansman sonrası bozulmaların yinelenen nedenleridir. hreflang kontrollerini yalnızca lansman günü QA geçişine değil, regresyon testlerine ve yinelenen taramalara dahil edin. Konuşmalarımdan benim çerçevem: “maskelemeden geliştirme/test/hazırlık ortamlarından taşınan şeylere kadar herhangi bir sayıda şey bozulabilir.”

Emekliye ayrılmaya değer mitler

  • “Site haritaları HTML etiketlerinden daha hızlı işlenir.” Yanlış. Her ikisi de tarama sırasında çözülür — bunu doğrudan çürüttüm. Site haritasının avantajı hız değil, bakım kolaylığı ve QA’dır.
  • “Yandex, site haritalarında hreflang’i desteklemez.” Yanlış — Yandex’in kendi belgeleri site haritası hreflang desteğini doğrulamaktadır.
  • “Ekstra sinyal için üç yöntemi de kullanın.” Google’a göre bir faydası yok ve bu yalnızca tutarsızlık riskini artırır.
  • “Eksik bir x-default kümeyi bozar.” Yanlış — isteğe bağlıdır; Google kendi algılamasına geri döner.
  • “Yanlış hreflang ceza getirir.” Yanlış — bu bir yönerge değil, bir ipucudur. Bozuk hreflang yok sayılır, cezalandırılmaz.

Sırada ne var

Bu makale, hreflang merkezinin altındaki nasıl yapılır derinliğidir — merkez, hreflang’in ne olduğunu, karşılıklılığın neden önemli olduğunu ve Bing’in bunun yerine ne yaptığını kapsar. x-default alt konusu, geri dönüş değeri hakkında derinlemesine bilgi verir. Bu stratejinin uyguladığı strateji için Uluslararası SEO temel direğine bakın — hreflang teknik katmandır, gerçek yerelleştirmenin yerine geçmez.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.