Panduan SEO Langkah 10: SEO Multi-bahasa

Ini adalah Langkah 10 dari Panduan SEO 13-Langkah. SEO multi-bahasa memungkinkan Anda mengalikan traffic organik dengan melayani setiap pasar dalam bahasa mereka sendiri — jika dilakukan dengan salah, ini akan menciptakan kekacauan konten duplikat.

Setiap bahasa yang Anda tambahkan akan menjadi pengganda untuk konten yang sudah ada. Sebuah situs dengan 50 halaman dalam satu bahasa memiliki 50 URL yang dapat diindeks. Tambahkan 5 bahasa dan Anda memiliki 250. Tambahkan 20 bahasa dan Anda memiliki 1.000. Masing-masing URL tersebut dapat memiliki peringkat secara independen dalam hasil pencarian Google lokal mereka.

Namun, SEO multi-bahasa adalah salah satu bidang SEO yang paling kompleks secara teknis. Implementasi yang salah menciptakan konten duplikat, pengenceran peringkat, dan pemborosan anggaran crawl. Perbedaan antara situs yang diinternasionalisasi dengan benar dan yang tidak dapat mencapai perbedaan trafik hingga 10x.

LANGR sendiri beroperasi dalam 108 bahasa di 89 lokal aktif — kami telah menyelesaikan masalah ini dalam skala besar. Panduan ini membagikan semua yang telah kami pelajari.

Apa yang Dicakup oleh SEO Multi-bahasa

SEO multi-bahasa mencakup 8 area kritis:

Implementasi Hreflang — Memberitahu Google halaman mana yang melayani bahasa mana
Strategi Routing Lokal — Subdomain vs subfolder vs TLD
Kualitas Terjemahan — Terjemahan mesin vs manusia vs hibrida
Penargetan Internasional — Konfigurasi Search Console
Lokalisasi Konten — Di luar terjemahan: adaptasi budaya
Dukungan RTL — Bahasa dari kanan ke kiri (Arab, Ibrani, Farsi)
Deteksi Bahasa — Menyajikan versi yang tepat secara otomatis
Konten Duplikat — Mencegah kanibalisasi antar bahasa

1. Implementasi Hreflang

Tag hreflang memberi tahu mesin pencari URL mana yang melayani bahasa dan wilayah mana. Mereka adalah fondasi teknis dari SEO multi-bahasa — dan elemen yang paling sering salah dikonfigurasi.

Sintaks hreflang dasar:

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

Aturan kritis:

Setiap halaman harus mereferensikan SEMUA versi alternatif (termasuk dirinya sendiri)
x-default menentukan fallback (biasanya bahasa Inggris atau pemilih bahasa)
Tag hreflang harus saling mengacu (halaman A menghubungkan ke B, B harus kembali menghubungkan ke A)
Gunakan kode bahasa ISO 639-1 (en, da, de) bukan kode negara
Untuk konten spesifik wilayah: en-us, en-gb, pt-br (bahasa-wilayah)
Maksimal ~50 entri hreflang per halaman (batas kinerja)

Tiga opsi penempatan:

| Metode | Terbaik Untuk | Kekurangan | |--------|---------------|------------| | di | Situs kecil (< 10 bahasa) | Membebani HTML, parsing lebih lambat | | Header HTTP | File non-HTML (PDF, API) | Tidak banyak didukung | | Sitemap XML | Situs besar (10+ bahasa) | Penemuan lebih lambat oleh crawler |

Contoh sitemap hreflang:

<url>
  <loc>https://example.com/page</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/page" />
  <xhtml:link rel="alternate" hreflang="da" href="https://example.com/da/page" />
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/page" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>

Kesalahan hreflang umum:

Tag referensi diri yang hilang (halaman tidak menyertakan dirinya sendiri)
Tag tidak saling mengacu (A mereferensikan B, tetapi B tidak mereferensikan A)
Kode bahasa yang salah (dk bukan da untuk bahasa Denmark)
Mengarahkan ke URL non-200 (redirect, 404s)
Mencampur x-default dengan halaman spesifik bahasa

Quick win: Crawl situs Anda dan ekspor semua tag hreflang. Periksa untuk hubungan tidak saling mengacu — ini adalah kesalahan yang paling umum dan menyebabkan Google mengabaikan seluruh pengaturan hreflang Anda.

2. Strategi Routing Lokal

Cara Anda menyusun URL untuk berbagai bahasa memengaruhi SEO, pengalaman pengguna, dan kompleksitas teknis. Ada tiga pendekatan utama:

Subfolder (Direkomendasikan)

example.com/en/page
example.com/da/page
example.com/de/page

Kelebihan: Otoritas domain tunggal, mudah dikelola, satu sertifikat SSL, satu properti analitik, satu properti Search Console, terbaik untuk sebagian besar situs.

Kekurangan: Sinyal penargetan geo lebih rendah dibandingkan ccTLD.

Subdomain

en.example.com/page
da.example.com/page
de.example.com/page

Kelebihan: Dapat dihosting di server/CDN yang berbeda per daerah, anggaran crawl terpisah.

Kekurangan: Setiap subdomain membangun otoritas secara terpisah (ekuitas tautan tidak mengalir secara otomatis), banyak properti Search Console, pengaturan lebih kompleks.

TLD kode negara (ccTLD)

example.com (Bahasa Inggris)
example.dk (Bahasa Denmark)
example.de (Bahasa Jerman)

Kelebihan: Sinyal penargetan geo terkuat, pengguna mempercayai TLD lokal, setiap domain independen.

Kekurangan: Mahal (pembelian 20+ domain), otoritas terpisah per domain, pengembangan tautan yang kompleks, analitik/konsol terpisah.

Rekomendasi kami: Routing Subfolder untuk 90% situs. Ini memusatkan semua otoritas tautan pada satu domain sambil memberikan sinyal lokal yang jelas. Gunakan format /{locale}/page.

https://langr.org/page        (Bahasa Inggris, default)
https://langr.org/da/page     (Bahasa Denmark)
https://langr.org/de/page     (Bahasa Jerman)
https://langr.org/ja/page     (Bahasa Jepang)

Quick win: Jika Anda menggunakan subdomain dan kesulitan dengan otoritas, pertimbangkan untuk bermigrasi ke subfolder. Situs yang bermigrasi dari subdomain ke subfolder biasanya melihat peningkatan trafik organik 20-50% dalam waktu 3-6 bulan saat ekuitas tautan bersatu.

3. Kualitas Terjemahan vs Terjemahan Mesin

Kualitas terjemahan secara langsung mempengaruhi peringkat. Google dapat mendeteksi terjemahan mesin dan mungkin menurunkan nilai halaman yang diterjemahkan dengan buruk. Namun, terjemahan AI tahun 2026 jauh lebih baik dibandingkan aturan praktis dari 2020.

Spektrum kualitas terjemahan:

| Tingkat | Metode | Kualitas | Biaya | Terbaik Untuk | |---------|--------|----------|-------|---------------| | 1 | Output GPT/DeepL mentah | 60-75% | ~$0 | Penggunaan internal, draf | | 2 | AI + pengeditan pasca-prompts | 75-90% | ~$0 | Konten blog, halaman non-kritis | | 3 | AI + tinjauan manusia | 90-97% | $0.03-0.08/kata | Halaman produk, halaman arahan kunci | | 4 | Penerjemah profesional asli | 97-100% | $0.10-0.25/kata | Hukum, medis, brand-kritis |

Wawasan kunci untuk 2026: Tingkat 2 (AI dengan prompts berkualitas) kini sudah cukup untuk sebagian besar konten web. Algoritma konten duplikat Google tidak lagi menghukum terjemahan mesin yang baik — mereka menghukum terjemahan buruk yang tidak memberikan nilai.

Tanda-tanda terjemahan yang merugikan SEO:

Segmen yang tidak diterjemahkan dicampurkan dengan konten yang diterjemahkan
Elemen UI (tombol, label) masih dalam bahasa sumber
Format spesifik lokal yang tidak disesuaikan (tanggal, mata uang, nomor telepon)
Referensi budaya yang tidak dapat diterjemahkan (idiom, lelucon, contoh)
Judul/meta deskripsi yang sama di semua bahasa

Bagaimana memvalidasi kualitas terjemahan:

Periksa bahwa SEMUA teks yang terlihat sudah diterjemahkan (termasuk navigasi, footer, formulir)
Verifikasi format spesifik lokal (DD/MM/YYYY vs MM/DD/YYYY)
Uji CTA — apakah terdengar alami dalam bahasa target?
Periksa meta tag — judul dan deskripsi harus ditulis secara mandiri per bahasa
Verifikasi tidak ada kunci i18n mentah yang terbuka (misalnya, nav.home sebagai "Home")

Quick win: Periksa halaman terjemahan Anda untuk konten campur bahasa. Jika ada tombol, label, atau elemen UI yang masih dalam bahasa sumber, perbaiki segera — halaman multibahasa yang campur memberi sinyal kualitas rendah bagi Google.

4. Penargetan Internasional di Search Console

Pengaturan penargetan internasional Google Search Console membantu Google memahami halaman mana yang harus peringkat di negara mana.

Untuk pengaturan subfolder:

Anda tidak dapat menetapkan penargetan negara per subfolder (hanya per domain/subdomain)
Sebagai gantinya, andalkan hreflang + bahasa konten + sinyal pengguna
Kirim sitemap per-lokal: sitemap-en.xml, sitemap-da.xml

Untuk ccTLD:

.dk secara otomatis ditargetkan untuk Denmark
.de secara otomatis ditargetkan untuk Jerman
Tidak ada konfigurasi manual yang diperlukan

Untuk TLD generik (.com, .org, .net):

Atur "Penargetan Internasional" per properti di Search Console
Gunakan hreflang sebagai sinyal utama

Langkah praktis:

Verifikasi situs Anda di Search Console (satu properti untuk pengaturan subfolder)
Kirim sitemap Anda dengan anotasi hreflang
Periksa laporan "Penargetan Internasional" untuk kesalahan
Pantau laporan "Cakupan" per bahasa (gunakan pemfilteran parameter URL)
Periksa peringatan "Duplikat tanpa kanonik yang dipilih pengguna" — ini sering menunjukkan masalah hreflang

Quick win: Masuk ke Search Console > Kinerja > Filter berdasarkan negara. Periksa apakah pengguna di Jerman mendarat di halaman bahasa Inggris Anda daripada halaman bahasa Jerman. Jika iya, konfigurasi hreflang Anda memiliki kesalahan.

5. Lokalisasi Konten (Bukan Hanya Terjemahan)

Lokalisasi melampaui terjemahan kata demi kata. Ini menyesuaikan konten untuk konteks budaya, perilaku pencarian lokal, dan kebutuhan spesifik pasar.

Apa yang perlu dilokalisasi:

Mata uang dan harga: Tampilkan mata uang lokal (€ di Jerman, kr di Denmark, ¥ di Jepang)
Format tanggal/waktu: 25/06/2026 (EU) vs 06/25/2026 (AS) vs 2026/06/25 (ISO/Jepang)
Nomor telepon: Format lokal dengan kode negara untuk internasional
Alamat: Sesuaikan dengan format pos lokal
Bukti sosial: Nama pelanggan lokal, perusahaan lokal, studi kasus lokal
CTA: Sesuaikan nada (formal dalam Jerman/Jepang, santai dalam Inggris/Danish)
Gambar: Lokalisasi teks dalam gambar, gunakan visual yang sesuai dengan budaya
Hukum: GDPR untuk UE, persyaratan persetujuan cookie yang berbeda per negara
Contoh: Merek lokal, situs web lokal, referensi lokal

Konten yang seharusnya tidak diterjemahkan secara langsung:

Postingan blog tentang topik lokal (tulis unik per pasar)
Studi kasus (gunakan bisnis lokal)
Halaman harga (harga yang berbeda per pasar adalah sah)
Konten berita (relevansi regional bervariasi)

Lokalisasi kata kunci: Jangan menerjemahkan kata kunci — teliti mereka secara asli. "Asuransi mobil" dalam bahasa Inggris mungkin "bilforsikring" dalam bahasa Denmark, tetapi pemimpin volume pencarian mungkin sebenarnya "forsikring bil" (urutan kata yang berbeda). Gunakan alat penelitian kata kunci lokal.

Quick win: Periksa halaman harga Anda di semua bahasa. Apakah menampilkan mata uang lokal yang benar? Apakah CTA Anda sesuai dengan budaya? CTA "Mulai Gratis" mungkin perlu menjadi "Jetzt kostenlos testen" dalam bahasa Jerman — bukan terjemahan literal, tetapi apa yang diharapkan pengguna Jerman.

6. Dukungan RTL

Bahasa dari kanan ke kiri (Arab, Ibrani, Farsi/Persia, Urdu, Pashto) memerlukan penyesuaian tata letak yang signifikan. Menyajikan konten RTL dengan tata letak dari kiri ke kanan membuat situs Anda tidak dapat digunakan untuk ~500 juta penutur asli.

Implementasi teknis:

<!-- Deteksi dan terapkan arah -->
<html lang="ar" dir="rtl">

Apa yang harus dibalik dalam RTL:

Perataan teks (teks tubuh rata kanan)
Arah tata letak (sidebar berpindah dari kiri ke kanan)
Urutan navigasi (dibalik)
Ikon dengan makna arah (panah, bilah kemajuan)
Padding dan margin (tukar nilai kiri/kanan)
Jangkauan border (tukar nilai sudut)
Arah CSS flexbox/grid

Apa yang TIDAK boleh dibalik:

Nomor telepon dan ekspresi matematis
Nama dan logo merek dari kiri ke kanan
Kontrol pemutar audio/video
Indikator gulir horizontal
Blok kode tertanam

Pendekatan CSS (modern):

/* Gunakan properti logis */
.card {
  margin-inline-start: 1rem;  /* menggantikan margin-left */
  padding-inline-end: 0.5rem; /* menggantikan padding-right */
  border-start-start-radius: 8px; /* atas-kiri dalam LTR, atas-kanan dalam RTL */
}

Pengujian RTL:

Tambahkan dir="rtl" ke dan periksa setiap halaman
Verifikasi teks Arab/Ibrani dapat dibaca (tidak rusak Unicode)
Uji input formulir (arah entri teks)
Periksa bahwa angka ditampilkan dengan benar dalam teks RTL

Quick win: Jika Anda mendukung bahasa Arab atau Ibrani, tambahkan dir="rtl" ke elemen HTML Anda untuk lokal tersebut dan gunakan properti logis CSS (margin-inline-start daripada margin-left). Perubahan tunggal ini memperbaiki 80% masalah tata letak RTL.

7. Deteksi dan Routing Bahasa

Cara Anda memutuskan versi bahasa mana yang akan ditampilkan kepada pengguna memengaruhi UX dan SEO.

Praktik terbaik: berbasis URL dengan cookie preferensi

Kunjungan pertama: Tampilkan konten berdasarkan URL (misalnya, /da/page = Bahasa Denmark)
URL root (/): Redirect berdasarkan header Accept-Language ATAU tampilkan default (Bahasa Inggris)
Ganti manual: Ketika pengguna memilih bahasa, atur cookie dan hormati di kunjungan mendatang
Jangan pernah: Auto-redirect dari URL spesifik bahasa

Apa yang harus dihindari:

Redirect berbasis IP (Google merayapi dari IP AS → hanya mengindeks Bahasa Inggris)
Deteksi bahasa hanya dengan JavaScript (mesin pencari tidak dapat mengeksekusi JS dengan andal)
Mengarahkan /de/page ke /en/page untuk pengguna Bahasa Inggris (merusak hreflang)
Cloaking (menampilkan konten yang berbeda berdasarkan agen pengguna)

Perilaku redirect yang benar:

Pengguna mengunjungi: /             → 302 redirect ke /{detected-locale}/
Pengguna mengunjungi: /da/page      → Sajikan konten Bahasa Denmark (jangan redirect away)
Pengguna mengunjungi: /nonexistent  → 404 (jangan redirect ke bahasa default)

Aturan penting SEO: Setiap URL bahasa harus dapat diakses langsung oleh Googlebot tanpa redirect. Jika Google merayapi /da/page dan diarahkan ke /en/page, itu tidak akan pernah mengindeks konten Bahasa Denmark Anda.

Quick win: Verifikasi bahwa Googlebot dapat mengakses semua URL bahasa Anda secara langsung. Di Search Console, gunakan alat Inspeksi URL pada URL non-Inggris. Jika menunjukkan redirect, perbaiki logika routing Anda.

8. Konten Duplikat di Antara Bahasa

Situs multi-bahasa menghadapi tantangan unik terkait konten duplikat: halaman serupa dalam berbagai bahasa dapat bersaing satu sama lain dalam hasil pencarian.

Kapan konten duplikat menjadi masalah:

Halaman yang 90%+ identik di berbagai bahasa (konten yang tidak diterjemahkan)
URL yang sama dapat diakses dengan dan tanpa awalan lokal (/page dan /en/page)
Tag kanonik yang hilang memungkinkan kedua versi untuk diindeks
Kesalahan hreflang menyebabkan Google memilih versi "salah"

Solusi:

| Masalah | Solusi | |---------|--------| | Halaman yang tidak diterjemahkan | Gunakan noindex sampai diterjemahkan, atau tampilkan Bahasa Inggris dengan indikator bahasa yang jelas | | URL ganda (/page + /en/page) | 301 redirect salah satu ke yang lain | | Google mengindeks bahasa yang salah | Perbaiki saling menghormati hreflang, verifikasi di Search Console | | Terjemahan berkualitas rendah yang diindeks | Tingkatkan kualitas terjemahan atau gabungkan ke dalam lebih sedikit bahasa |

Strategi tag kanonik:

<!-- Setiap halaman bahasa adalah kanoniknya sendiri -->
<!-- /en/page -->
<link rel="canonical" href="https://example.com/en/page" />

<!-- /da/page -->
<link rel="canonical" href="https://example.com/da/page" />

Jangan pernah mengarahkannya kanonik dari satu bahasa ke bahasa lain (misalnya, kanonik bahasa Denmark mengarah ke bahasa Inggris) — itu memberitahu Google untuk mengabaikan versi Bahasa Denmark sepenuhnya.

Quick win: Cari site:yourdomain.com "judul halaman Anda" di Google. Jika Anda melihat versi Bahasa Inggris dan terjemahan muncul untuk permintaan yang sama, Anda memiliki masalah konten duplikat atau hreflang.

Daftar Periksa SEO Multi-bahasa

Jalankan ini untuk setiap situs yang diinternasionalisasi:

[ ] Tag hreflang di semua halaman, termasuk referensi diri dan x-default
[ ] Semua hubungan hreflang saling mengacu (diperiksa dengan crawler)
[ ] Routing lokal yang benar (subfolder direkomendasikan): /{locale}/page
[ ] Tidak ada redirect otomatis dari URL spesifik bahasa
[ ] Kualitas terjemahan terverifikasi (tidak ada halaman campur bahasa)
[ ] Judul dan deskripsi meta unik per bahasa (tidak diduplikasi)
[ ] Mata uang, tanggal, dan format dilokalisasi per pasar
[ ] Dukungan RTL diterapkan untuk Arab/Ibrani/Farsi (jika berlaku)
[ ] Sitemap per-lokal dikirim ke Search Console
[ ] Setiap halaman bahasa memiliki URL kanoniknya sendiri (tidak mengarah ke bahasa lain)
[ ] Tidak ada kunci i18n mentah yang terlihat di halaman mana pun
[ ] Pengalih bahasa dapat diakses di semua halaman (terhubung ke halaman yang setara, bukan halaman utama)

Bagaimana LANGR Memeriksa SEO Multi-bahasa

LANGR memiliki dua modul khusus untuk SEO multi-bahasa:

i18n-checker: Merayapi hingga 5 varian lokal dari halaman Anda dan memeriksa:

Kelayakan dan saling menghormati tag hreflang
URL lokal yang tidak dapat diakses (mengembalikan 404 atau mengarahkan)
String yang ditulis keras/tidak diterjemahkan di seluruh lokal (deteksi fallback)
Kunci i18n mentah yang terbuka sebagai teks yang terlihat
Persentase cakupan terjemahan

Translation scanner: Penilaian kualitas berbasis AI:

Mengevaluasi kealamian terjemahan pada skala 0-100
Mendeteksi artefak terjemahan mesin
Mengidentifikasi segmen yang tidak diterjemahkan dalam halaman yang diterjemahkan lainnya
Memeriksa elemen UI (tombol, label, navigasi) terpisah dari konten tubuh

Gabungan, modul-modul ini memeriksa implementasi multi-bahasa Anda dari kedua perspektif teknis (hreflang, routing, kanonik) dan kualitas (terjemahan, lokalisasi) — dua dari 13 disiplin SEO LANGR.

Kesalahan Multi-bahasa Umum (Diklasifikasikan berdasarkan Dampak)

Hreflang tidak saling mengacu — Google mengabaikan seluruh pengaturan
Arah otomatis berdasarkan IP — Menghalangi Googlebot dari mengindeks versi non-Inggris
Tag meta yang sama di seluruh bahasa — Memboroskan potensi peringkat halaman yang diterjemahkan
Halaman campur bahasa — Tombol dalam Bahasa Inggris, konten dalam Bahasa Jerman = sinyal kualitas rendah
Tidak ada x-default — Google tidak dapat menentukan versi fallback Anda
Menerjemahkan URL secara harfiah — /about-us → /uber-uns baik-baik saja, tetapi tetap konsisten
Mengabaikan RTL — Tata letak rusak untuk 500M+ penutur asli
Kanonik mengarah ke bahasa lain — Menghancurkan versi terjemahan dalam indeks Google

Apa Selanjutnya?

Langkah 11: Penemuan Lead B2B — Mengubah data SEO menjadi prospek yang memenuhi syarat dengan prospeksi otomatis, penilaian lead berbasis domain, dan outreach yang didorong oleh temuan SEO.

Panduan ini adalah bagian dari seri SEO 13-langkah LANGR. Jalankan audit gratis untuk melihat di mana posisi situs Anda di seluruh 13 disiplin.

Panduan SEO Langkah 10: SEO Multi-bahasa — Menjangkau Audiens Global Tanpa Mengurangi Peringkat Anda