Bahasa

Hreflang

Apa itu hreflang, tiga cara menerapkannya, aturan timbal balik dan referensi diri, kode bahasa/wilayah yang valid, serta cara mengaudit cluster dalam skala besar.

Pertama kali diterbitkan: 25 Jun 2026 · Terakhir diperbarui: 21 Agu 2026 · Advanced
Bahasa
AIDitulis olehAI v2
1 sinyal bukti di halaman ini

Hreflang memberi tahu mesin pencari versi bahasa/wilayah mana dari suatu halaman yang harus ditampilkan kepada pengguna. Anda mendeklarasikannya melalui salah satu dari tiga cara—tag di head HTML, header HTTP, atau sitemap XML—dengan kode bahasa ISO 639-1 dan kode wilayah ISO 3166-1 alpha-2. Hreflang hanya bekerja sebagai cluster timbal balik: setiap halaman harus menaut ke dirinya sendiri dan semua alternatifnya; jika tautan balik hilang, Google mengabaikan pasangan tersebut. Ini adalah petunjuk, bukan direktif—hreflang yang salah diabaikan, bukan dihukum. Hreflang juga rapuh: dalam studi saya terhadap 374 756 domain yang menggunakan hreflang, lebih dari 67% memiliki setidaknya satu masalah. Bing hampir tidak menggunakannya (content-language menjadi sinyal yang lebih kuat di sana). Hub ini menjelaskan semuanya dan mengarahkan Anda ke pembahasan mendalam.

TL;DR — Hreflang adalah sinyal cluster timbal balik: setiap halaman mencantumkan dirinya sendiri dan semua alternatif, sedangkan tag balik yang hilang membatalkan pasangan tersebut. Nyatakan hanya melalui satu cara—head HTML, header Link HTTP (untuk PDF), atau sitemap XML (paling baik dalam skala besar). Kode terdiri dari bahasa ISO 639-1 + wilayah ISO 3166-1 alpha-2; en-UK salah, yang benar en-GB. Ini adalah petunjuk, bukan direktif (Mueller) —hreflang yang salah diabaikan, bukan dihukum, dan Google dapat mengesampingkannya demi konsolidasi bahasa yang sama atau alasan pengindeksan. Hreflang sering rusak: dalam studi Ahrefs saya terhadap 374 756 domain, lebih dari 67% memiliki setidaknya satu masalah. Bing menganggapnya jauh lebih lemah daripada content-language. Audit cluster secara visual, bukan melalui spreadsheet.

Hreflang adalah cluster, bukan tag

Hreflang sits between one piece of content and the right version showing up for each market's search. Sumber: /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

A hreflang cluster is a bidirectional graph — one missing return link breaks just that pair. Sumber: /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

Model mental yang mengatasi sebagian besar kebingungan tentang hreflang: hreflang bukan tag per halaman, melainkan graf dua arah. Persyaratan Google sendiri tegas—“Each language version must list itself as well as all other language versions,” (terjemahan) “Setiap versi bahasa harus mencantumkan dirinya sendiri serta semua versi bahasa lainnya,” dan “if two pages don’t both point to each other, the tags will be ignored.” (terjemahan) “jika dua halaman tidak sama-sama menunjuk satu sama lain, tag tersebut akan diabaikan.” Jadi, jika halaman X menunjuk ke Y tetapi Y tidak menunjuk balik ke X, hubungan itu diam-diam dibuang. Satu tag balik yang hilang dapat membuat anotasi yang terdampak diabaikan atau ditafsirkan keliru—namun Google mengatakan bahwa pasangan yang memang timbal balik dengan benar tetap dapat diproses, sehingga satu hubungan yang rusak tidak selalu menjatuhkan semua anotasi dalam cluster yang lebih besar.

Evidence for this claim Each hreflang set should include the page itself, use fully qualified URLs, and include return links; without reciprocity, the affected annotations may be ignored or misinterpreted. Scope: Google Search hreflang guidelines; the documentation does not say one missing return link invalidates every annotation in a cluster. Confidence: high · Verified: Google: Localized versions guidelines

Dua hal yang tak bisa ditawar:

  • Timbal balik. Setiap referensi harus mendapat referensi balik. Di sinilah penerapan sering rusak dalam skala besar—begitu satu template, satu kolom CMS, atau halaman dari satu wilayah tidak lagi sinkron, tautan balik menghilang.
  • Referensi diri. Setiap halaman mencantumkan dirinya sendiri. Mueller menyebutnya “opsional—tetapi merupakan praktik yang baik”; dalam praktiknya, kumpulan referensi diri adalah cara paling bersih untuk menjaga konsistensi cluster, dan ketidakhadirannya ditandai sebagai masalah.

URL absolut yang sepenuhnya memenuhi syarat juga diperlukan—https://example.com/foo, bukan //example.com/foo atau /foo.

Tiga metode—dan komprominya

Google memperlakukan tag HTML, header HTTP, dan sitemap XML sebagai hal yang setara—tidak ada manfaat Penelusuran dengan menerapkan lebih dari satu. Pilih satu metode per situs berdasarkan kemampuan stack Anda untuk memeliharanya secara andal; mencampurnya mengundang konflik.

  • Tag HTML <head>. Paling sederhana dan paling mudah dilihat. Kekurangannya: pada situs dengan puluhan locale, setiap halaman membawa blok besar tag <link> yang menambah bobot markup. Selain itu, tag yang berada di <body> akibat HTML rusak atau injeksi JavaScript tidak valid—hreflang hanya dihitung di <head> halaman sebagaimana Google merender dan menguraikannya.
  • Header Link HTTP. Satu-satunya opsi untuk sumber daya non-HTML seperti PDF. Header dikirim dalam respons sehingga tidak memperbesar dokumen.
  • Sitemap XML. Pilihan tepat dalam skala besar. Anotasi berada secara terpusat (elemen anak xhtml:link di bawah setiap <url>, dengan namespace xmlns:xhtml="http://www.w3.org/1999/xhtml"), sehingga Anda dapat membuat ulang seluruh cluster dari basis data tanpa menerapkan ulang halaman. Tidak ada metode yang “lebih cepat”—HTML dan sitemap sama-sama diselesaikan saat crawling—tetapi sitemap jauh lebih mudah diperiksa karena seluruh graf dapat divalidasi dalam satu berkas, bukan dengan crawling setiap halaman.
Evidence for this claim Google accepts hreflang in HTML, HTTP headers, or XML sitemaps and says the methods are equivalent from its perspective. Scope: Google Search hreflang implementation methods. Confidence: high · Verified: Google: Localized versions

Tautan timbal balik dalam skala besar—di mana ia rusak

Pada situs dengan 5 locale, setiap kumpulan halaman membentuk matriks referensi 5×5, yang dibuat ulang setiap kali Anda menambah atau menghapus locale, memperbaiki slug, atau memigrasikan URL. Pola kegagalannya dapat diprediksi:

  • Format URL tidak konsisten. Garis miring penutup vs. tanpa garis miring, http vs. https, www vs. apex, atau jalur huruf besar vs. huruf kecil—ketidakcocokan apa pun antara URL dalam hreflang dan URL yang benar-benar diindeks Google memutus pencocokan tautan balik.
  • Menunjuk ke URL yang dialihkan atau rusak. URL locale berubah, pengalihan dipasang, tetapi hreflang masih menunjuk ke URL lama. Kini cluster merujuk ke URL 301 atau 404.
  • Drift kode. jp alih-alih ja untuk bahasa Jepang, kode tiga huruf ketika dua huruf diwajibkan, atau en-UK alih-alih en-GB. Kode tidak valid diabaikan.

Contoh penerapan: tag balik masih menunjuk ke URL kemarin

Misalkan halaman produk Britania Raya berpindah dari /gb/shoes/ ke /uk/shoes/. Halaman Amerika Serikat belum dibuat ulang, sehingga masih menerbitkan:

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/gb/shoes/" />

URL Britania Raya yang lama mengalihkan ke /uk/shoes/, sedangkan halaman Britania Raya yang baru menaut kembali ke halaman Amerika Serikat dari URL kanonik finalnya. Ini menimbulkan dua masalah berbeda: anotasi Amerika Serikat menargetkan pengalihan, dan URL final Britania Raya tidak sama dengan URL yang dideklarasikan halaman Amerika Serikat. Perbaiki generator agar kedua halaman menerbitkan kumpulan lengkap menggunakan URL final yang dapat diindeks:

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/uk/shoes/" />

Validasi kedua arah setelah penerapan; jika hanya memeriksa tag sumber Amerika Serikat, kegagalan tag balik akan terlewat. Ini adalah cluster ilustratif dengan domain .example.

Pelajaran dari presentasi konferensi saya tetap berlaku: otomatisasi pembuatan hreflang dari satu sumber kebenaran. Hreflang yang dipelihara secara manual dalam skala besar hampir pasti mengalami kerusakan tag balik.

Konflik kanonikalisasi

Hreflang bergantung pada apa yang diindeks, bukan pada apa yang dikanonikalkan—tetapi keduanya berinteraksi, dan kesalahan di sini merusak cluster:

  • Kanonik yang merujuk ke diri sendiri adalah default yang aman. Setiap versi bahasa sebaiknya dikanonikalkan ke dirinya sendiri. Jika halaman bahasa Spanyol Anda dikanonikalkan ke halaman bahasa Inggris, Anda memberi tahu Google bahwa URL bahasa Spanyol bukan URL yang harus diindeks—dan hreflang yang menunjuk ke URL non-kanonik adalah salah satu kesalahan yang paling umum.
  • Kasus tepi: satu bahasa, banyak negara. Jika, misalnya, Anda memiliki halaman en-us dan en-gb yang hampir identik, Google dapat mengonsolidasikannya dan mengindeks salah satunya—tetapi Google masih dapat menukar URL yang ditampilkan di SERP ke versi negara yang tepat melalui tautan hreflang. Jadi, URL yang “dikanonikalkan keluar” masih dapat muncul untuk pengguna yang tepat. Ini adalah fitur, bukan bug, tetapi sering mengejutkan orang yang mengaudit cakupan indeks.
  • noindex dan robots.txt. Halaman yang diblokir dari pengindeksan tidak dapat berpartisipasi dalam cluster—hreflang-nya tidak dapat diproses, dan menunjuk ke URL yang noindex/diblokir merusak tautan balik. Jangan memblokir atau memberi noindex pada varian bahasa yang ingin Anda tampilkan.

Ini petunjuk, bukan direktif

Inilah cara pandang yang perlu diingat. Pada Mei 2025 di Bluesky, John Mueller menanggapi kasus halaman fr-be yang muncul dalam hasil fr meskipun hreflang-nya benar: “hreflang doesn’t guarantee indexing, so it can also just be that not all variations are indexed,” (terjemahan) “hreflang tidak menjamin pengindeksan, jadi bisa saja tidak semua variasi diindeks,” dan “I suspect this is a ‘same language’ case where our systems just try to simplify things for sites.” (terjemahan) “Saya menduga ini adalah kasus ‘bahasa yang sama’ ketika sistem kami hanya mencoba menyederhanakan keadaan bagi situs.” Google berhak mengesampingkan hreflang untuk konsolidasi bahasa yang sama, celah pengindeksan, atau pilihan kanoniknya sendiri.

Panduan kanonikalisasi Google adalah sisi lain dari prinsip tersebut: Google menyarankan memilih kanonik dalam bahasa yang sama dengan halaman (atau pengganti terbaik yang tersedia), dan menyatakan lebih menyukai URL yang merupakan bagian dari cluster hreflang timbal balik yang lengkap dibanding URL serupa di luar cluster. Itu adalah preferensi, bukan janji—berada dalam cluster yang dibuat dengan benar meningkatkan peluang URL yang tepat dipilih, tetapi tidak menjamin pengindeksan atau URL mana yang ditampilkan.

Konsekuensi praktisnya: hreflang yang salah diabaikan, bukan dihukum. Jika cluster Anda rusak, Google kembali menggunakan deteksi bahasa/wilayahnya sendiri. Biayanya adalah peluang yang hilang (URL yang salah muncul untuk sebagian pengguna), bukan penurunan peringkat. Jadi, “hreflang saya salah” jarang merupakan keadaan darurat—tetapi juga jarang menghasilkan manfaat.

Bing dan mesin pencari lain menggunakan stack yang berbeda

Hreflang adalah sinyal untuk Google (dan Yandex). Susunan sinyal Bing sepenuhnya berbeda. Fabrice Canel, Principal Program Manager di Microsoft Bing, menyatakan dengan jelas: “hreflang is indeed a far weaker signal than content-language at Bing.” (terjemahan) “hreflang memang merupakan sinyal yang jauh lebih lemah daripada content-language di Bing.” Bing mengandalkan header HTTP atau tag meta content-language, atribut <html lang="">, tautan masuk, geografi pengunjung, serta lokasi server atau ccTLD; Canel juga menyarankan agar tidak “menduplikasi URL hanya untuk memberinya tag pasar bahasa” dalam kebanyakan kasus. Baidu sama sekali tidak mendukung hreflang (Baidu menggunakan lokasi hosting, pendaftaran domain Tiongkok, lisensi ICP, dan content-language). Jadi, penerapan internasional yang tangguh memasangkan hreflang untuk Google dengan content-language dan html lang yang benar untuk mesin lainnya.

Tingkat kesalahan menjelaskan semuanya

Over 67% of domains using hreflang have at least one issue — missing x-default is the top offender. Sumber: Data: Ahrefs

Saat saya menjalankan studi hreflang terbesar hingga saat ini di Ahrefs —374 756 domain, hampir 10× lebih besar daripada studi sebelumnya—lebih dari 67% domain yang menggunakan hreflang memiliki setidaknya satu masalah. Distribusinya:

Masalah% domain
x-default hilang56,3%
Tag referensi diri hilang18,0%
Merujuk ke halaman rusak/dialihkan16,9%
Tag timbal balik hilang15,3%
Menunjuk ke URL non-kanonik8,0%
Kode bahasa/negara keliru4,6%
Atribut bahasa tidak konsisten3,2%
Beberapa halaman untuk bahasa yang sama2,5%
Halaman yang sama untuk beberapa bahasa2,5%

Ringkasan studi saya masih berlaku: hreflang rumit dan sulit dibuat benar, serta dapat rusak dengan banyak cara.

Audit dalam skala besar—visualisasikan cluster, jangan membaca spreadsheet

Lihat cluster Anda sendiri dengan returntag:

  1. Tempelkan satu URL halaman, URL sitemap, atau daftar URL halaman ke dalam alat.
  2. Klik Validate cluster.
  3. Baca tampilan GRAPH—tautan balik yang rusak atau hilang akan terlihat melalui warna tingkat keparahan—atau beralih ke MATRIX untuk tampilan baris demi baris, lalu ekspor CSV daftar perbaikan jika perlu menyerahkannya kepada orang lain.

Alasan kesalahan hreflang tersembunyi adalah karena masalah tag balik merupakan hubungan antarhalaman, dan hubungan hampir mustahil dibaca dari baris-baris spreadsheet. Ahrefs Site Audit adalah alat pertama yang merender cluster hreflang sebagai graf—buka detail URL halaman mana pun dan tab Hreflangs akan menggambar seluruh cluster sebagai jaringan, dengan halaman rusak serta tautan yang hilang atau salah disorot warna merah. Sekilas Anda dapat melihat tag balik mana yang hilang atau tautan mana yang ditambahkan secara keliru—dan hasilnya jauh lebih mudah ditunjukkan kepada pemangku kepentingan daripada CSV. Site Audit juga menjalankan pemeriksaan dasar (anotasi tidak valid, referensi diri hilang, lebih dari satu halaman per bahasa, ketidakcocokan hreflang/html lang, tag timbal balik hilang, target nonkanonik, dan target rusak) yang secara langsung memetakan daftar kesalahan dalam studi tersebut.

Selain itu:

  • GSC URL Inspection mengonfirmasi cara satu URL dirayapi dan diindeks. Perhatikan bahwa laporan International Targeting lama dihentikan pada 22 September 2022—Google mengatakan laporan itu “had little value for the ecosystem.” (terjemahan) “bernilai kecil bagi ekosistem.” Tag hreflang sendiri masih berfungsi; hanya laporannya yang dihapus.
  • Pengujian SERP manual dengan parameter &hl= (bahasa host) dan &gl= (geolokasi) pada URL penelusuran Google memungkinkan Anda melihat pratinjau hasil untuk locale tertentu.

Hreflang juga menjadi perhatian dalam audit teknis SEO

Meskipun ranah utama hreflang adalah SEO internasional, hreflang muncul dalam hampir setiap audit teknis SEO untuk situs multibahasa atau multiwilayah—berdampingan dengan pemeriksaan kanonikalisasi, pengindeksan, dan aksesibilitas crawling, serta termasuk hal yang paling mungkin rusak tanpa terlihat. Jika Anda menjalankan audit teknis dan situs memiliki lebih dari satu locale, cluster hreflang harus masuk daftar periksa.

Ke mana selanjutnya

Hub ini adalah peta untuk subcluster hreflang. Pembahasan mendalam pertama:

  • x-default—nilai fallback untuk pengguna yang locale-nya tidak cocok dengan tag eksplisit mana pun (misalnya pemilih negara atau beranda global). Ini tidak wajib, tetapi merupakan kelalaian yang paling umum dalam studi saya (56,3% situs). Subtopik khusus membahas kapan menggunakannya, kapan melewatinya, dan bagaimana x-default berinteraksi dengan bagian cluster lainnya.

Untuk strategi yang lebih luas yang diterapkan di sini, lihat pilar International SEO —hreflang adalah lapisan teknis strategi internasional; hreflang tidak menggantikan lokalisasi yang nyata (niat lokal, konten lokal, dan otoritas lokal).

Add an expert note

Pin an expert quote

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