คู่มือ SEO ขั้นตอนที่ 10: SEO หลายภาษา

นี่คือ ขั้นตอนที่ 10 จาก คู่มือ SEO 13 ขั้นตอน. SEO หลายภาษาช่วยให้คุณสามารถเพิ่มการเข้าถึงแบบออร์แกนิกได้โดยการให้บริการตลาดแต่ละแห่งในภาษาของตน — ถ้าทำแบบผิด ๆ จะเกิดความยุ่งเหยิงของเนื้อหาซ้ำกัน.

---

แต่ละภาษาที่คุณเพิ่มเข้าไปนั้นเป็นตัวคูณสำหรับเนื้อหาที่มีอยู่แล้ว เว็บไซต์ที่มีหน้า 50 หน้าภาษาเดียวจะมี URL ที่สามารถจัดอันดับได้ 50 รายการ หากเพิ่ม 5 ภาษา คุณจะมี 250 หากเพิ่ม 20 ภาษา คุณจะมี 1,000. แต่ละ URL เหล่านี้สามารถจัดอันดับได้อย่างอิสระในผลลัพธ์ของ Google ในท้องถิ่นของตน

แต่ SEO หลายภาษาเป็นหนึ่งในด้านที่ซับซ้อนทางเทคนิคที่สุดใน SEO การใช้งานที่ไม่ถูกต้องทำให้เกิดเนื้อหาซ้ำกัน การลดอันดับ และการสูญเสียงบประมาณการครอว์ล ความแตกต่างระหว่างเว็บไซต์ที่มีการทำให้เป็นนานาชาติได้อย่างถูกต้องกับที่ไม่ถูกต้องสามารถทำให้การเข้าถึงมีความแตกต่างถึง 10 เท่า

LANGR เองดำเนินการใน 108 ภาษาใน 89 ท้องถิ่นที่ใช้งานอยู่ — เราได้แก้ปัญหาเหล่านี้ในระดับใหญ่ คู่มือนี้จะแบ่งปันทุกสิ่งที่เราได้เรียนรู้

SEO หลายภาษาคืออะไร

SEO หลายภาษาครอบคลุม 8 ด้านที่สำคัญ:

1. การใช้ hreflang — บอก Google ว่าหน้าไหนให้บริการภาษาไหน
2. กลยุทธ์การจัดเส้นทางตามท้องถิ่น — ซับโดเมน vs โฟลเดอร์ย่อย vs TLD
3. คุณภาพการแปล — การแปลโดยเครื่อง vs มนุษย์ vs ไฮบริด
4. การกำหนดเป้าหมายระดับนานาชาติ — การกำหนดค่าคอนโซลค้นหา
5. การปรับเนื้อหาให้เหมาะสมกับท้องถิ่น — มากกว่าการแปล: การปรับตามวัฒนธรรม
6. การสนับสนุน RTL — ภาษาเขียนจากขวาไปซ้าย (อาหรับ, ฮิบรู, ฟาร์ซี)
7. การตรวจจับภาษา — ให้บริการเวอร์ชันที่ถูกต้องโดยอัตโนมัติ
8. เนื้อหาซ้ำกัน — ป้องกันการกินกันเองข้ามภาษา

1. การใช้ hreflang

แท็ก hreflang บอกเสิร์ชเอนจินว่าทาง URL ไหนให้บริการภาษาและภูมิภาคไหน มันเป็นพื้นฐานทางเทคนิคของ SEO หลายภาษา — และเป็นองค์ประกอบที่มักจะถูกตั้งค่าผิด

รูปแบบพื้นฐานของ hreflang:

<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" />

กฎสำคัญ:

• ทุกหน้า ต้องอ้างอิง URL ที่เป็นเวอร์ชันทางเลือกทั้งหมด (รวมถึงตัวเอง)
• x-default ใช้สำหรับการดึงกลับ (มักจะเป็นภาษาอังกฤษหรือเครื่องมือเลือกภาษา)
• แท็ก hreflang ต้องเป็นแบบคู่ (หน้า A ลิงก์ไปที่ B, B ต้องลิงก์กลับไปยัง A)
• ใช้รหัสภาษาตามมาตรฐาน ISO 639-1 (en, da, de) ไม่ใช่รหัสประเทศ
• สำหรับเนื้อหาเฉพาะภูมิภาค: en-us, en-gb, pt-br (ภาษา-ภูมิภาค)
• สูงสุด ~50 รายการ hreflang ต่อหน้า (ขีดจำกัดด้านประสิทธิภาพ)

ตัวเลือกการวางตำแหน่งสามแบบ:

| วิธีการ | เหมาะสำหรับ | จุดด้อย | |--------|----------|-----------| | ใน | เว็บไซต์ขนาดเล็ก (< 10 ภาษา) | ทำให้ HTML ใหญ่ขึ้น, การแปลงข้อมูลช้าลง | | HTTP headers | ไฟล์นอก HTML (PDFs, APIs) | ไม่ได้รับการสนับสนุนอย่างแพร่หลาย | | XML sitemap | เว็บไซต์ขนาดใหญ่ (10+ ภาษา) | ค้นพบช้ากว่าโดยโปรแกรมค้นหา |

ตัวอย่าง 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>

ข้อผิดพลาดทั่วไปของ hreflang:

• ขาดแท็กการอ้างอิงตัวเอง (หน้าไม่ได้รวมตัวเอง)
• แท็กที่ไม่เป็นคู่ (A อ้างอิง B แต่ B ไม่อ้างอิง A)
• รหัสภาษาไม่ถูกต้อง (dk แทนที่ da สำหรับเดนมาร์ก)
• ชี้ไปที่ URL ที่ไม่เป็น 200 (การเปลี่ยนทิศทาง, 404s)
• ผสม x-default กับหน้าที่เฉพาะทางภาษา

Quick win: ตรวจสอบเว็บไซต์ของคุณและส่งออกรหัส hreflang ทั้งหมด ตรวจสอบหาความสัมพันธ์ที่ไม่เป็นคู่ — นี่คือข้อผิดพลาดที่พบบ่อยที่สุดและทำให้ Google ไม่สนใจการตั้งค่า hreflang ทั้งหมดของคุณ

2. กลยุทธ์การจัดเส้นทางตามท้องถิ่น

โครงสร้าง URL สำหรับภาษาต่าง ๆ มีผลต่อ SEO, ประสบการณ์ผู้ใช้, และความซับซ้อนทางเทคนิค มีสามวิธีหลัก:

โฟลเดอร์ย่อย (แนะนำ)

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

ข้อดี: มีอำนาจเต็มโดเมนเดียว ง่ายต่อการจัดการ, ใบรับรอง SSL หนึ่งใบ, คุณสมบัติการวิเคราะห์หนึ่งรายการ, คุณสมบัติ Search Console หนึ่งรายการ, เหมาะสำหรับส่วนใหญ่ของเว็บไซต์

จุดด้อย: สัญญาณการกำหนดเป้าหมายทางภูมิศาสตร์น้อยกว่าซีซี TLD

ซับโดเมน

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

ข้อดี: สามารถโฮสต์บนเซิร์ฟเวอร์/CDN ที่แตกต่างกันตามภูมิภาค, งบประมาณการครอว์ลแยกต่างหาก

จุดด้อย: แต่ละซับโดเมนสร้างอำนาจแยกกัน (อำนาจลิงก์ไม่ไหลอัตโนมัติ) คุณสมบัติ Search Console หลายรายการ การตั้งค่าที่ยุ่งยากกว่า

TLD ที่ใช้รหัสประเทศ (ccTLD)

example.com (อังกฤษ)
example.dk (เดนมาร์ก)
example.de (เยอรมัน)

ข้อดี: สัญญาณการกำหนดเป้าหมายทางภูมิศาสตร์ที่แข็งแกร่งที่สุด ผู้ใช้เชื่อใจใน TLD ท้องถิ่น แต่ละโดเมนมีความเป็นอิสระ

จุดด้อย: แพง (ซื้อโดเมน 20+ รายการ) มีอำนาจแยกตามโดเมน การสร้างลิงค์ที่ซับซ้อน, การวิเคราะห์/คอนโซลแยก

ข้อเสนอแนะของเรา: การจัดเส้นทางโฟลเดอร์ย่อย สำหรับ 90% ของเว็บไซต์ จะทำให้อำนาจลิงค์ทั้งหมดรวมอยู่ในโดเมนเดียวในขณะเดียวกันก็มอบสัญญาณท้องถิ่นที่ชัดเจน ใช้รูปแบบ /{locale}/page

https://langr.org/page        (ภาษาอังกฤษ, ค่าเริ่มต้น)
https://langr.org/da/page     (เดนมาร์ก)
https://langr.org/de/page     (เยอรมัน)
https://langr.org/ja/page     (ญี่ปุ่น)

Quick win: หากคุณใช้ซับโดเมนและมีปัญหาเรื่องอำนาจ ให้พิจารณาการย้ายไปยังโฟลเดอร์ย่อย เว็บไซต์ที่มีการย้ายจากซับโดเมนไปยังโฟลเดอร์ย่อยมักจะเห็นการเพิ่มการเข้าชมแบบออร์แกนิก 20-50% ภายใน 3-6 เดือนเมื่ออำนาจลิงค์รวมกัน

3. คุณภาพการแปล vs การแปลด้วยเครื่อง

คุณภาพการแปลส่งผลโดยตรงต่ออันดับ Google สามารถตรวจจับการแปลด้วยเครื่องและอาจลดค่าเนื้อหาที่แปลไม่ดี แต่การแปล AI ในปี 2026 ดีกว่ากฎเกณฑ์ที่ใช้ในปี 2020 อย่างมาก

ช่วงคุณภาพการแปล:

| ระดับ | วิธีการ | คุณภาพ | ค่าใช้จ่าย | เหมาะสำหรับ | |-------|--------|---------|------|----------| | 1 | ข้อมูลดิบ GPT/DeepL | 60-75% | ~$0 | การใช้งานภายใน, ร่าง | | 2 | AI + โปรมต์การแก้ไขหลัง | 75-90% | ~$0 | เนื้อหาบล็อก, หน้าไม่สำคัญ | | 3 | AI + การตรวจสอบจากมนุษย์ | 90-97% | $0.03-0.08/คำ | หน้าเกี่ยวกับผลิตภัณฑ์, หน้า Landing ที่สำคัญ | | 4 | นักแปลมืออาชีพที่เป็นเจ้าของภาษา | 97-100% | $0.10-0.25/คำ | เนื้อหาทางกฎหมาย, การแพทย์, เนื้อหาที่เกี่ยวข้องกับแบรนด์ |

ข้อมูลเชิงลึกสำหรับปี 2026: ระดับ 2 (AI พร้อมโปรมต์คุณภาพ) ตอนนี้เพียงพอสำหรับเนื้อหาบนเว็บส่วนใหญ่ อัลกอริธึมเนื้อหาซ้ำของ Google ไม่ได้ลงโทษการแปลด้วยเครื่องที่ทำได้ดี — แต่ลงโทษการแปลที่ไม่ดีซึ่งไม่ให้คุณค่า

สัญญาณของการแปลที่สร้างความเสียหายต่อ SEO:

• ส่วนที่ไม่ได้แปลปนกับเนื้อหาที่แปลแล้ว
• องค์ประกอบ UI (ปุ่ม, ป้ายชื่อ) ยังอยู่ในภาษาต้นฉบับ
• รูปแบบที่เฉพาะตามท้องถิ่นที่ไม่ได้ปรับ (วันที่, สกุลเงิน, หมายเลขโทรศัพท์)
• การอ้างอิงทางวัฒนธรรมที่ไม่ได้แปล (สำนวน, มุขตลก, ตัวอย่าง)
• ชื่อและคำอธิบายเมตาที่เหมือนกันทั่วทุกภาษา

วิธีการตรวจสอบคุณภาพการแปล:

1. ตรวจสอบว่าข้อความที่มองเห็นได้ทั้งหมดแปลแล้ว (รวมถึงการนำทาง, ฟุตเตอร์, ฟอร์ม)
2. ตรวจสอบรูปแบบเฉพาะภูมิภาค (DD/MM/YYYY vs MM/DD/YYYY)
3. ทดสอบ CTAs — ดูว่าฟังดูเป็นธรรมชาติในภาษาที่เลือกไหม?
4. ตรวจสอบแท็กเมตา — ชื่อและคำอธิบายต้องเขียนอย่างอิสระต่อภาษาทุกภาษา
5. ยืนยันว่าไม่มีคีย์ i18n ดิบที่เปิดเผย (เช่น, nav.home แทนที่ "Home")

Quick win: ตรวจสอบหน้าที่แปลแล้วของคุณเพื่อหาคอนเทนต์ที่เป็นภาษาหลายภาษา หากปุ่ม ป้ายชื่อ หรือองค์ประกอบ UI ใดยังอยู่ในภาษาต้นฉบับของคุณ ให้แก้ไขทันที — หน้าภาษาหลายภาษาส่งสัญญาณคุณภาพต่ำต่อ Google

4. การกำหนดเป้าหมายระดับนานาชาติใน Search Console

การตั้งค่าการกำหนดเป้าหมายระดับนานาชาติใน Google Search Console ช่วยให้ Google เข้าใจว่าหน้าไหนควรจะจัดอันดับในประเทศไหน

สำหรับการตั้งค่าโฟลเดอร์ย่อย:

• คุณไม่สามารถตั้งค่าการกำหนดเป้าหมายประเทศตามโฟลเดอร์ย่อยได้ (มีให้ตั้งค่าตามโดเมน/ซับโดเมนเท่านั้น)
• แทนที่จะเป็นเช่นนั้น ให้พึ่งพา hreflang + ภาษาเนื้อหา + สัญญาณจากผู้ใช้
• เสนอแผนที่ไซต์ที่แยกตามภูมิภาค: sitemap-en.xml, sitemap-da.xml

สำหรับ ccTLD:

• .dk จะถูกกำหนดเป้าหมายโดยอัตโนมัติต่อเดนมาร์ก
• .de จะถูกกำหนดเป้าหมายโดยอัตโนมัติต่อเยอรมนี
• ไม่จำเป็นต้องตั้งค่าเอง

สำหรับ TLD ทั่วไป (.com, .org, .net):

• ตั้งค่าการกำหนดเป้าหมายระดับนานาชาติใน Search Console
• ใช้ hreflang เป็นสัญญาณหลัก

ขั้นตอนปฏิบัติ:

1. ตรวจสอบเว็บไซต์ของคุณใน Search Console (หนึ่งคุณสมบัติสำหรับการตั้งค่าโฟลเดอร์ย่อย)
2. ส่งแผนที่ไซต์ของคุณที่มีการบันทึก hreflang
3. ตรวจสอบรายงาน "การกำหนดเป้าหมายระดับนานาชาติ" สำหรับข้อผิดพลาด
4. ตรวจสอบรายงาน "การครอบคลุม" ตามภาษาต่าง ๆ (ใช้การกรองพารามิเตอร์ URL)
5. ตรวจสอบว่ามีการเตือน "ซ้ำกันโดยไม่มีแคนนอนิกที่ผู้ใช้เลือก" หรือไม่ — สิ่งเหล่านี้มักบ่งบอกถึงปัญหา hreflang

Quick win: ไปที่ Search Console > ประสิทธิภาพ > กรองตามประเทศ ตรวจสอบว่าผู้ใช้ในเยอรมนีกำลังเข้าถึงหน้าอังกฤษของคุณแทนที่จะเป็นภาษาเยอรมัน หากใช่ การตั้งค่า hreflang ของคุณมีข้อผิดพลาด

5. การปรับเนื้อหาให้เหมาะสมกับท้องถิ่น (ไม่ใช่แค่การแปล)

การปรับตามท้องถิ่นมากกว่าการแปลตามคำ การปรับเนื้อหาให้เข้ากับบริบททางวัฒนธรรม, พฤติกรรมการค้นหาในท้องถิ่น, และความต้องการตามตลาดที่เฉพาะเจาะจง

สิ่งที่ควรปรับให้เหมาะสม:

• สกุลเงินและราคา: แสดงสกุลเงินในท้องถิ่น (€ ในเยอรมนี, kr ในเดนมาร์ก, ¥ ในญี่ปุ่น)
• รูปแบบวันที่/เวลา: 25/06/2026 (สหภาพยุโรป) vs 06/25/2026 (สหรัฐฯ) vs 2026/06/25 (ISO/ญี่ปุ่น)
• หมายเลขโทรศัพท์: รูปแบบท้องถิ่นพร้อมรหัสประเทศสำหรับระดับนานาชาติ
• ที่อยู่: ตรงตามรูปแบบไปรษณีย์ในท้องถิ่น
• หลักฐานทางสังคม: ชื่อชาวบ้าน, บริษัทในท้องถิ่น, กรณีศึกษาที่เกี่ยวข้องในท้องถิ่น
• CTAs: ปรับโทนเสียง (เป็นทางการในภาษาเยอรมัน/ญี่ปุ่น, ไม่เป็นทางการในภาษาอังกฤษ/เดนมาร์ก)
• ภาพ: ปรับข้อความในภาพ, ใช้ภาพที่เหมาะสมทางวัฒนธรรม
• กฎหมาย: GDPR สำหรับสหภาพยุโรป, ความต้องการการตอบสนองเกี่ยวกับคุกกี้ที่แตกต่างกันตามประเทศ
• ตัวอย่าง: แบรนด์ในท้องถิ่น, เว็บไซต์ในท้องถิ่น, อ้างอิงในท้องถิ่น

เนื้อหาที่ไม่ควรแปลตรง:

• บล็อกโพสต์เกี่ยวกับหัวข้อในท้องถิ่น (เขียนเฉพาะสำหรับแต่ละตลาด)
• กรณีศึกษา (ใช้ธุรกิจในท้องถิ่น)
• หน้าเกี่ยวกับราคา (มีราคาต่างกันต่อแต่ละตลาดถือว่าถูกต้อง)
• เนื้อหาข่าว (ความเกี่ยวข้องตามภูมิภาคแตกต่างกัน)

การปรับคำหลัก: อย่าแปลคำหลัก — ศึกษาในรูปแบบท้องถิ่น "ประกันรถยนต์" ในภาษาอังกฤษอาจเป็น "bilforsikring" ในภาษาเดนมาร์ก แต่ผู้นำในปริมาณการค้นหาอาจเป็นจริงว่า "forsikring bil" (รูปแบบคำที่แตกต่างกัน) ใช้เครื่องมือวิจัยคำหลักในท้องถิ่น

Quick win: ตรวจสอบหน้าราคาของคุณให้เหมาะสมกับทุกภาษา แสดงสกุลเงินท้องถิ่นที่ถูกต้องหรือไม่? CTAs ของคุณเหมาะสมทางวัฒนธรรมหรือไม่? CTAs "เริ่มการทดลองใช้ฟรี" อาจจำเป็นต้องเป็น "Jetzt kostenlos testen" ในภาษาเยอรมัน — ไม่ใช่การแปลอย่างตรงตัว แต่เป็นสิ่งที่ผู้ใช้ชาวเยอรมันคาดหวัง

6. การสนับสนุน RTL

ภาษาที่เขียนจากขวาไปซ้าย (อาหรับ, ฮิบรู, ฟาร์ซี/เปอร์เซีย, อูร์ดู, ปาชโต) ต้องการการปรับโครงสร้างที่สำคัญ การให้บริการเนื้อหา RTL ด้วยเลย์เอาต์จากซ้ายไปขวาทำให้เว็บไซต์ของคุณไม่สามารถใช้งานได้สำหรับผู้พูดภาษาพื้นเมืองประมาณ 500 ล้านคน

การใช้งานทางเทคนิค:

<!-- ตรวจจับและใช้งานทิศทาง -->
<html lang="ar" dir="rtl">

สิ่งที่ต้องพลิกใน RTL:

• การจัดตำแหน่งข้อความ (จัดตำแหน่งข้อความในร่างกายทางขวา)
• ทิศทางเลย์เอาต์ (แถบด้านข้างย้ายจากซ้ายไปขวา)
• ลำดับการนำทาง (ย้อนกลับ)
• ไอคอนที่มีความหมายในการกำหนดทิศทาง (ลูกศร, แถบความก้าวหน้า)
• การเพิ่มขอบและมาร์จิ้น (สลับค่าซ้าย/ขวา)
• รัศมีของขอบ (สลับค่ามุม)
• ทิศทาง CSS flexbox/grid

สิ่งที่ไม่ควรพลิก:

• หมายเลขโทรศัพท์และสมการทางคณิตศาสตร์
• ชื่อแบรนด์และโลโก้ที่เขียนจากซ้ายไปขวา
• การควบคุมของผู้เล่นเสียง/วิดีโอ
• ตัวบ่งชี้การเลื่อนแนวนอน
• บล็อกโค้ดฝังอยู่

แนวทาง CSS (ทันสมัย):

/* ใช้คุณสมบัติเชิงตรรกะ */
.card {
  margin-inline-start: 1rem; /* แทนที่ margin-left */
  padding-inline-end: 0.5rem; /* แทนที่ padding-right */
  border-start-start-radius: 8px; /* มุมบนซ้ายใน LTR, มุมบนขวาใน RTL */
}

การทดสอบ RTL:

• เพิ่ม dir="rtl" ไปยัง และตรวจสอบหน้าทุกหน้า
• ตรวจสอบว่าข้อความอาหรับ/ฮิบรูอ่านได้ (ไม่เป็น Unicode ที่คลุมเครือ)
• ทดสอบแบบฟอร์ม (ทิศทางการป้อนข้อความ)
• ตรวจสอบว่าหมายเลขแสดงอย่างถูกต้องภายในข้อความ RTL

Quick win: หากคุณสนับสนุนภาษาอาหรับหรือฮิบรู เพิ่ม dir="rtl" ไปยัง HTML ของคุณสำหรับท้องถิ่นเหล่านั้นและใช้คุณสมบัติเชิงตรรกะ CSS (margin-inline-start แทนที่ margin-left) การเปลี่ยนแปลงเพียงครั้งเดียวนี้จะแก้ไขปัญหาเลย์เอาต์ RTL ได้ถึง 80%

7. การตรวจจับและการจัดเส้นทางภาษา

วิธีการที่คุณตัดสินใจว่าควรแสดงเวอร์ชันภาษาไหนต่อผู้ใช้มีผลต่อ UX และ SEO

แนวทางปฏิบัติที่ดีที่สุด: ใช้ URL พร้อมคุกกี้ความชอบ

1. การเยี่ยมชมครั้งแรก: แสดงเนื้อหาตาม URL (เช่น /da/page = เดนมาร์ก)
2. URL ราก (/): เปลี่ยนเส้นทางตาม Accept-Language header หรือแสดงค่าเริ่มต้น (ภาษาอังกฤษ)
3. สลับด้วยตนเอง: เมื่อผู้ใช้เลือกภาษา ให้ตั้งค่าคุกกี้และเคารพมันในการเยี่ยมชมครั้งถัดไป
4. อย่า: เปลี่ยนเส้นทางออกจาก URL ที่กำหนดภาษาไปโดยอัตโนมัติ

สิ่งที่ควรหลีกเลี่ยง:

• การเปลี่ยนเส้นทางตาม IP (Google ค้นหาจาก IP ของสหรัฐฯ → ทำให้สามารถจัดอันดับภาษาอังกฤษได้เท่านั้น)
• การตรวจจับภาษาผ่าน JavaScript เท่านั้น (เสิร์ชเอนจินไม่สามารถดำเนินการ JS ได้อย่างเชื่อถือได้)
• การเปลี่ยนเส้นทาง /de/page ไปยัง /en/page สำหรับผู้ใช้ภาษาอังกฤษ (ทำให้ hreflang ขัดข้อง)
• การสร้างภาพหลอก (แสดงเนื้อหาที่แตกต่างกันตาม user-agent)

พฤติกรรมการเปลี่ยนเส้นทางที่ถูกต้อง:

ผู้ใช้เข้าเยี่ยมชม: /                  → 302 เปลี่ยนเส้นทางไปที่ /{detected-locale}/
ผู้ใช้เข้าเยี่ยมชม: /da/page            → ให้บริการเนื้อหาเดนมาร์ก (อย่าเปลี่ยนเส้นทางออก)
ผู้ใช้เข้าเยี่ยมชม: /nonexistent        → 404 (อย่าเปลี่ยนเส้นทางไปยังภาษาที่เริ่มต้น)

กฎที่มีผลต่อ SEO: ทุก URL ภาษา ต้องสามารถเข้าถึงโดย Googlebot โดยตรงโดยไม่ต้องเปลี่ยนเส้นทาง หาก Google สำรวจ /da/page และถูกเปลี่ยนเส้นทางไปยัง /en/page มันจะไม่จัดอันดับเนื้อหาเดนมาร์กของคุณ

Quick win: ตรวจสอบว่า Googlebot สามารถเข้าถึง URL ภาษาได้ทั้งหมดโดยตรง ใน Search Console ใช้เครื่องมือการตรวจสอบ URL บน URL ที่ไม่ใช่ภาษาอังกฤษ หากมันแสดงการเปลี่ยนเส้นทาง ให้แก้ไขตรรกะการจัดเส้นทางของคุณ

8. เนื้อหาซ้ำกันในหลายภาษา

เว็บไซต์หลายภาษาต้องเผชิญกับความท้าทายที่เป็นเอกลักษณ์ของเนื้อหาซ้ำกัน: หน้าเดียวกันในภาษาต่าง ๆ ที่สามารถแข่งขันกันในผลการค้นหา

เมื่อเนื้อหาซ้ำกันกลายเป็นปัญหา:

• หน้า 90%+ เหมือนกันในหลายภาษา (เนื้อหาที่ไม่ได้แปล)
• URL เดียวกันที่เข้าถึงได้ด้วยและไม่มีเค้าโครงเฉพาะ (/page และ /en/page)
• ขาดแท็ก canonical ที่อนุญาตให้ทั้งสองเวอร์ชันถูกจัดอันดับ
• ข้อผิดพลาด hreflang ที่ทำให้ Google เลือกเวอร์ชัน "ผิด"

คำตอบ:

| ปัญหา | คำตอบ | |---------|----------| | หน้าที่ไม่ได้แปล | ใช้ noindex จนกว่าจะได้รับการแปล หรือแสดงภาษาอังกฤษที่มีเครื่องหมายภาษาที่ชัดเจน | | URL ซ้ำกัน (/page + /en/page) | 301 เปลี่ยนเส้นทางหนึ่งไปอีกหนึ่ง | | Google จัดอันดับภาษาผิด | แก้ไขความสัมพันธ์ hreflang, ตรวจสอบใน Search Console | | การแปลที่มีคุณภาพต่ำถูกจัดอันดับ | ปรับปรุงคุณภาพการแปลหรือรวมไปยังภาษาน้อยกว่า |

กลยุทธ์แท็ก canonical:

<!-- หน้าแต่ละภาษาเป็น canonical ของตัวเอง -->
<!-- /en/page -->
<link rel="canonical" href="https://example.com/en/page" />

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

อย่าให้แท็ก canonical ชี้ไปจากภาษาหนึ่งไปยังอีกภาษาหนึ่ง (เช่น แคนนอนิกของเดนมาร์กชี้ไปยังภาษาอังกฤษ) — นั่นบอก Google ให้ไม่สนใจเวอร์ชันเดนมาร์กโดยสิ้นเชิง

Quick win: ค้นหา site:yourdomain.com "ชื่อหน้าของคุณ" ใน Google หากคุณเห็นทั้งเวอร์ชันภาษาอังกฤษและแปลปรากฏสำหรับคำค้นเดียวกัน หมายความว่าคุณมีปัญหาเนื้อหาซ้ำกันหรือ hreflang

เช็คลิสต์ SEO หลายภาษา

ตรวจสอบนี้สำหรับทุกเว็บไซต์ที่มีการทำให้เป็นนานาชาติ:

• [ ] แท็ก hreflang บนทุกหน้า รวมถึงการอ้างอิงตัวเองและ x-default
• [ ] ความสัมพันธ์ของ hreflang ทั้งหมดเป็นแบบคู่ (ตรวจสอบด้วยโปรแกรมค้นหา)
• [ ] การจัดเส้นทางท้องถิ่นที่ถูกต้อง (แนะนำโฟลเดอร์ย่อย): /{locale}/page
• [ ] ไม่มีการเปลี่ยนเส้นทางอัตโนมัติจาก URL ที่กำหนดภาษาเฉพาะ
• [ ] คุณภาพการแปลได้รับการตรวจสอบ (ไม่มีหน้าภาษาหลายภาษา)
• [ ] เมตาชื่อและคำอธิบายที่เป็นเอกลักษณ์ต่อภาษา (ไม่ซ้ำกัน)
• [ ] สกุลเงิน, วันที่ และรูปแบบที่ปรับตามตลาด
• [ ] การสนับสนุน RTL ถูกใช้งานสำหรับภาษาอาหรับ/ฮิบรู/ฟาร์ซี (ถ้าใช้)
• [ ] แผนที่ไซต์ต่อภูมิภาคส่งไปยัง Search Console
• [ ] หน้าแต่ละภาษามี URL canonical ของตัวเอง (ไม่ชี้ไปยังภาษาอื่น)
• [ ] ไม่มีคีย์ i18n ดิบที่มองเห็นได้บนหน้าใด ๆ
• [ ] ตัวเลือกการเปลี่ยนภาษาสามารถเข้าถึงได้จากทุกหน้า (เชื่อมโยงไปยังหน้าที่เทียบเท่าที่ไม่ใช่หน้าแรก)

วิธี LANGR ตรวจสอบ SEO หลายภาษา

LANGR มีสองโมดูลเฉพาะสำหรับ SEO หลายภาษา:

i18n-checker: ตรวจสอบคู่ของขึ้นอยู่กับ 5 เวอร์ชันที่แตกต่างกันของคุณหน้าและตรวจสอบ:

• ความครบถ้วนและความสัมพันธ์ของแท็ก hreflang
• URL ท้องถิ่นที่ไม่สามารถเข้าถึงได้ (คืนค่า 404 หรือเปลี่ยนเส้นทาง)
• สตริงที่ถูกฮาร์ดโค้ด/ไม่ได้แปลในแต่ละท้องถิ่น (การตรวจจับการดึงกลับ)
• คีย์ i18n ดิบที่เปิดเผยในฐานะข้อความที่มองเห็น
• เปอร์เซ็นต์การครอบคลุมการแปล

Translation scanner: การประเมินคุณภาพที่ขับเคลื่อนด้วย AI:

• ประเมินความเป็นธรรมชาติของการแปลในระดับ 0-100
• ตรวจจับภาพลักษณ์จากการแปลด้วยเครื่อง
• ระบุส่วนที่ไม่ได้แปลภายในหน้าอื่นที่แปลแล้ว
• ตรวจสอบองค์ประกอบ UI (ปุ่ม, ป้ายชื่อ, การนำทาง) แยกจากเนื้อหาหลัก

รวมกันแล้ว โมดูลเหล่านี้ตรวจสอบการใช้งานหลายภาษาของคุณจากทั้งมุมมองทางเทคนิค (hreflang, การจัดเส้นทาง, แคนนอนิคัล) และคุณภาพ (การแปล, การปรับตามท้องถิ่น) — สองด้านของ 13 สาขา SEO ของ LANGR

ข้อผิดพลาดทั่วไปใน SEO หลายภาษา (เรียงตามผลกระทบ)

1. hreflang ไม่เป็นคู่ — Google จะไม่สนใจการตั้งค่าทั้งหมด
2. การเปลี่ยนเส้นทางอัตโนมัติแบบ IP — ป้องกัน Googlebot จากการจัดเก็บรุ่นที่ไม่ใช่ภาษาอังกฤษ
3. แท็กเมตาเดียวกันในหลายภาษา — เปลืองศักยภาพในการจัดอันดับของหน้าแปล
4. หน้ารวมภาษา — ปุ่มภาษาอังกฤษ, เนื้อหาเยอรมัน = สัญญาณคุณภาพต่ำ
5. ไม่มี x-default — Google ไม่สามารถระบุเวอร์ชันการดึงกลับของคุณ
6. การแปล URL ตามตัวอักษร — /about-us → /uber-uns อาจจะโอเค แต่อย่าลืมทำให้มันสอดคล้องกัน
7. ละเลย RTL — เลย์เอาต์เสียหายสำหรับผู้พูดถึง 500 ล้านคน
8. Canonical ชี้ไปยังอีกภาษา — ทำลายเวอร์ชันแปลในดัชนีของ Google

สิ่งต่อไป

ขั้นตอนที่ 11: การค้นหาลูกค้า B2B — เปลี่ยนข้อมูล SEO ให้เป็นลูกค้าที่มีคุณสมบัติโดยการหาลูกค้าอัตโนมัติ, การให้คะแนนเฉพาะตามโดเมน, และการเข้าถึงที่มีพลังจากการค้นพบ SEO

---

คู่มือเล่มนี้เป็นส่วนหนึ่งของซีรีส์ SEO 13 ขั้นตอนของ LANGR. ทำการตรวจสอบฟรี เพื่อดูว่าเว็บไซต์ของคุณอยู่ในระดับใดตาม 13 สาขาทั้งหมด.