วิธีใช้ hreflang Tags สำหรับ WordPress หลายภาษา
คุณแปลเว็บไซต์ WordPress ทั้งหมดของคุณเป็นหกภาษา ไฟล์ .po สะอาด ไฟล์ .mo คอมไพล์เรียบร้อย ทุกข้อความแสดงผลได้อย่างสมบูรณ์แบบในภาษาฝรั่งเศส เยอรมัน และญี่ปุ่น แต่หลายสัปดาห์หลังจากการเปิดตัว คุณตรวจสอบ Google Search Console และพบสิ่งที่น่าประหลาดใจ: หน้าภาษาฝรั่งเศสของคุณติดอันดับสำหรับการค้นหาในภาษาเยอรมัน หน้าภาษาสเปน-เม็กซิโกของคุณถูกแสดงให้ผู้ค้นหาในสเปน และเว็บไซต์ของคุณสองเวอร์ชันกำลังแย่งตำแหน่งกันในการจัดอันดับ เนื้อหาดีไม่มีปัญหา ปัญหาคือ Google ไม่รู้ว่าเวอร์ชันไหนเหมาะกับกลุ่มเป้าหมายใด
นี่คือสิ่งที่ hreflang WordPress tags ถูกออกแบบมาเพื่อแก้ไข Hreflang คือสัญญาณที่บอกเครื่องมือค้นหาว่าควรแสดงหน้าเว็บเวอร์ชันภาษาและภูมิภาคใดให้ผู้ใช้คนไหน หากทำผิด คุณจะเจอปัญหาการเจือจางเนื้อหาซ้ำซ้อน ผลลัพธ์ผิดภาษา และงบประมาณการรวบรวมข้อมูลที่สูญเปล่า หากทำถูก แต่ละหน้าที่แปลแล้วจะเข้าถึงกลุ่มเป้าหมายที่เขียนไว้ คู่มือนี้ครอบคลุมไวยากรณ์ ความแตกต่างระหว่างรหัสภาษาและรหัสภาษา-ภูมิภาค x-default ที่จำเป็น การแลกเปลี่ยน return-tag และสามวิธีปฏิบัติเพื่อนำไปใช้ใน WordPress
hreflang ทำอะไรจริงๆ
Hreflang ไม่ได้แปลอะไร เป็นแผนที่ความสัมพันธ์ เมื่อคุณมีหน้าเดียวกันในหลายภาษา hreflang annotations จะบอก Google ว่า "URL นี้เป็นเวอร์ชันภาษาอังกฤษ อันนี้เป็นเวอร์ชันภาษาเยอรมัน อันนี้สำหรับผู้พูดภาษาสเปนในเม็กซิโก" Google ใช้แผนที่นั้นเพื่อแสดงเวอร์ชันที่ถูกต้องในผลการค้นหาตามการตั้งค่าภาษาและตำแหน่งของผู้ใช้
คำอธิบายประกอบจะอยู่ใน <head> ของ HTML ของคุณในรูปแบบขององค์ประกอบ <link> แต่ละองค์ประกอบจะระบุหน้าเป้าหมายและภาษา (และภูมิภาคที่เป็นทางเลือก) ที่ให้บริการ นี่คือชุดของ hreflang tags ที่ถูกต้องสำหรับหน้าที่มีให้บริการในภาษาอังกฤษแบบ US ภาษาอังกฤษแบบ UK และภาษาสเปนแบบเม็กซิโก พร้อมการสำรองเริ่มต้น:
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />
ทุกหน้าในชุดควรแสดงบล็อกเดียวกันนี้ โดยระบุทุกทางเลือก รวมถึงตัวมันเอง จุดสุดท้ายนี้ทำให้คนส่วนใหญ่สับสน และเราจะกลับมาพูดถึงมันอีกครั้ง
เหตุใดสิ่งนี้จึงสำคัญต่อ SEO
หากไม่มี hreflang, Google จะถือว่าหน้าเว็บที่แปลแล้วของคุณเป็นเนื้อหาซ้ำซ้อนที่แข่งขันกันเพื่อใช้คีย์เวิร์ดเดียวกัน ผลลัพธ์ที่ได้คือการเจือจาง: สัญญาณการจัดอันดับจะถูกแบ่งแยกระหว่างเวอร์ชันต่างๆ แทนที่จะรวมกัน ด้วย hreflang ที่ถูกต้อง แต่ละเวอร์ชันจะได้รับอำนาจจากชุดทั้งหมด และปรากฏต่อผู้ค้นหาที่เหมาะสม นี่เป็นหนึ่งในกลยุทธ์ SEO ที่มีประสิทธิภาพสูงสุดที่เว็บไซต์หลายภาษาจะทำได้ และมันเสริมการแปลเนื้อหาจริงในไฟล์ .po ของคุณ ไม่ใช่การแทนที่ เราครอบคลุมด้านเนื้อหาอย่างละเอียดในคู่มือของเราที่ การแปลไฟล์ PO ส่งผลต่ออันดับ Google อย่างไร
รหัสภาษา vs รหัสภาษา-ภูมิภาค
คุณควรใช้ en หรือ en-GB? ใช้รหัสที่เรียบง่ายที่สุดที่เป็นความจริง หากเนื้อหาภาษาอังกฤษของคุณเป็นแบบทั่วไปและคุณไม่ได้ดูแลเวอร์ชันภาษาอังกฤษแบบอังกฤษและแบบอเมริกันแยกกัน ให้ใช้ en เพียงอย่างเดียว เพิ่ม subtag ภูมิภาคเฉพาะเมื่อคุณให้บริการเนื้อหาที่แตกต่างกันสำหรับประเทศที่แตกต่างกันจริงๆ
ค่า hreflang เป็นไปตามรูปแบบ language หรือ language-region ส่วนภาษาคือรหัส ISO 639-1 (en, es, de, pt) ส่วนภูมิภาคที่เป็นทางเลือกคือรหัสประเทศ ISO 3166-1 Alpha 2 (US, GB, MX, BR) ดังนั้น:
enกำหนดเป้าหมายผู้พูดภาษาอังกฤษทุกคนไม่ว่าจะอยู่ในประเทศใดen-GBกำหนดเป้าหมายผู้พูดภาษาอังกฤษในสหราชอาณาจักรesกำหนดเป้าหมายผู้พูดภาษาสเปนทุกคนes-MXกำหนดเป้าหมายผู้พูดภาษาสเปนในเม็กซิโกโดยเฉพาะ
รายละเอียดสำคัญ: subtag ภูมิภาคคือ ประเทศ ไม่ใช่วิธีการใช้ภาษาที่แตกต่างกัน es-MX ไม่ได้หมายถึง "ภาษาถิ่นสเปนแบบเม็กซิกัน" แต่หมายถึง "ภาษาสเปนที่แสดงให้ผู้ใช้ในเม็กซิโก" Google ยังคงแสดงผลตามตำแหน่งของผู้ใช้ หากคุณดูแลภาษาถิ่นในภูมิภาคในการแปลของคุณ รหัสภูมิภาคคือวิธีที่คุณจะจัดการสิ่งเหล่านี้ เราเจาะลึกด้านภาษาศาสตร์ในคู่มือของเราที่ ภาษาถิ่นสเปนและโปรตุเกสในภูมิภาค
ตัวอย่างที่ผิดพลาดที่พบบ่อย
นี่คือบล็อก hreflang ที่ผิดพลาดที่เราเห็นอยู่ตลอดเวลา:
<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />
มีข้อผิดพลาดสามประการ en-uk ไม่ถูกต้องเพราะรหัสประเทศสำหรับสหราชอาณาจักรคือ GB ไม่ใช่ UK sp ไม่ใช่รหัสภาษาเลย ภาษาสเปนคือ es และ pt-PT_BR ผสมสองภูมิภาคด้วยเครื่องหมายขีดล่างที่ไม่มีความหมายใน hreflang เครื่องมือค้นหาจะละเว้นค่าที่ไม่ถูกต้องโดยเงียบๆ ดังนั้นคุณจะไม่ได้รับข้อผิดพลาดและไม่มีประโยชน์ เพียงแค่เสียเวลาแก้ไขข้อบกพร่องหลายชั่วโมงสงสัยว่าทำไมไม่มีอะไรเปลี่ยนแปลง
โปรดทราบว่า hreflang ใช้เครื่องหมายขีดกลาง (en-GB) ในขณะที่ไฟล์โลเคชั่นของ WordPress ใช้เครื่องหมายขีดล่าง (en_GB) อย่าคัดลอกรหัสชื่อไฟล์ .po ของคุณโดยตรงลงใน hreflang tags
x-default และการแลกเปลี่ยน Return-Tag
กฎสองข้อที่ทำให้ hreflang ล้มเหลวแบบเงียบๆ มากกว่าสิ่งอื่นใดคือ x-default ที่หายไปและการแลกเปลี่ยนที่ไม่สมบูรณ์
ค่า x-default จะบอก Google ว่าควรแสดงหน้าใดเมื่อไม่มีภาษาอื่นตรงกับผู้ใช้ เป็นตัวสำรองของคุณ ซึ่งโดยทั่วไปแล้วคือตัวเลือกภาษาหรือหน้าแรกของตลาดหลักของคุณ แม้ว่าจะไม่จำเป็นตามข้อกำหนด แต่ในทางปฏิบัติคุณควรรวมไว้เสมอ หากไม่มีสิ่งนี้ ผู้เข้าชมที่พูดภาษาโปรตุเกสซึ่งคุณไม่มีเวอร์ชันภาษาโปรตุเกสจะได้รับผลลัพธ์แบบสุ่มแทนที่จะเป็นค่าเริ่มต้นที่ตั้งใจไว้
การแลกเปลี่ยน return-tag เป็นสิ่งที่ไม่สามารถต่อรองได้ ทุกหน้าในชุด hreflang จะต้องชี้กลับไปที่หน้าอื่นๆ ทั้งหมด รวมถึงตัวมันเองด้วย หากหน้าภาษาอังกฤษของคุณระบุภาษาเยอรมันเป็นตัวเลือกอื่น หน้าภาษาเยอรมันของคุณจะต้องระบุภาษาอังกฤษเป็นตัวเลือกอื่น หากหน้าภาษาเยอรมันละเว้นการอ้างอิงกลับ Google จะไม่เชื่อถือความสัมพันธ์ทั้งหมดและละเว้นคำอธิบายประกอบ
<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
การอ้างอิงตัวเอง (de ที่ชี้ไปยังหน้าภาษาเยอรมันในขณะที่ดูหน้าภาษาเยอรมัน) เป็นสิ่งจำเป็น ไม่ใช่ทางเลือก ชุดของเวอร์ชันภาษาห้าเวอร์ชันหมายความว่าแต่ละหน้าจากห้าหน้าจะแสดงแท็ก <link> ทั้งห้าแท็กพร้อมกับ x-default
สามวิธีในการนำ hreflang ไปใช้ใน WordPress
คุณมีสามทางเลือกที่ใช้งานได้จริง ตั้งแต่การควบคุมด้วยตนเองอย่างเต็มที่ไปจนถึงระบบอัตโนมัติอย่างเต็มที่
วิธีที่ 1: ด้วยตนเองผ่าน wp_head
สำหรับชุดหน้าคงที่ขนาดเล็ก คุณสามารถแทรก hreflang tags โดยตรงผ่าน wp_head action ใน functions.php ของธีมของคุณ:
add_action( 'wp_head', function () {
if ( ! is_page( 'pricing' ) ) {
return;
}
$alternates = array(
'en-US' => 'https://example.com/en-us/pricing/',
'es-MX' => 'https://example.com/es-mx/pricing/',
'x-default' => 'https://example.com/pricing/',
);
foreach ( $alternates as $lang => $url ) {
printf(
'<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
esc_attr( $lang ),
esc_url( $url )
);
}
} );
วิธีนี้ช่วยให้คุณควบคุมได้อย่างแม่นยำ แต่ไม่สามารถปรับขนาดได้ การรักษาการแลกเปลี่ยนด้วยตนเองในหลายร้อยโพสต์เป็นกับดักของการบำรุงรักษา
วิธีที่ 2: ปลั๊กอินหลายภาษา
หากคุณใช้ Polylang, WPML หรือ TranslatePress, hreflang จะถูกสร้างขึ้นโดยอัตโนมัติตามความสัมพันธ์ของการแปลของคุณ นี่คือคำตอบที่ถูกต้องสำหรับเว็บไซต์ส่วนใหญ่ เนื่องจากปลั๊กอินรู้แล้วว่าโพสต์ใดคือการแปลของโพสต์ใด ดังนั้นการแลกเปลี่ยนและ x-default จึงได้รับการจัดการให้คุณ ค่าใช้จ่ายคือโอเวอร์เฮดรันไทม์ที่ปลั๊กอินเหล่านี้เพิ่มเข้ามา ซึ่งเป็นการแลกเปลี่ยนที่เราจะพิจารณาในการเปรียบเทียบ วิธีการแปลด้วยตนเองเทียบกับ AI
วิธีที่ 3: XML Sitemap พร้อม xhtml:link
แทนที่จะใส่ hreflang ใน <head> ของทุกหน้า คุณสามารถประกาศความสัมพันธ์ใน XML sitemap ของคุณโดยใช้เนมสเปซ xhtml:link แต่ละรายการ <url> จะแสดงรายการภาษาทางเลือกทั้งหมด:
<url>
<loc>https://example.com/en/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>
วิธีนี้ช่วยให้ HTML ของหน้าเว็บของคุณกระชับ และรวมศูนย์แผนที่ภาษาไว้ในไฟล์ที่ Google สามารถรวบรวมข้อมูลได้ ซึ่ง Google ก็อ่านได้อย่างมีความสุข ปลั๊กอิน SEO ส่วนใหญ่สามารถสร้างสิ่งนี้ได้โดยอัตโนมัติ
hreflang เสริมการแปล ไม่ใช่ทดแทนการแปล
นี่คือจุดที่ทุกคนพลาดไป: hreflang จะไม่มีค่าอะไรเลยหากหน้าเว็บที่อยู่เบื้องหลังไม่ได้ถูกแปลจริงๆ แท็กนี้บอก Google ว่า "นี่คือเวอร์ชันภาษาเยอรมัน" แต่ถ้า URL ภาษาเยอรมันยังคงแสดงสตริงปลั๊กอินภาษาอังกฤษ ป้ายกำกับการชำระเงินที่ไม่ได้แปล หรือไฟล์ .po ที่ยังแปลไม่เสร็จ คุณก็แค่บอก Google ให้แสดงเนื้อหาที่เสียให้ผู้ใช้ชาวเยอรมันด้วยความมั่นใจอย่างเต็มที่
SEO หลายภาษาที่แท้จริงมีสองชั้น ชั้นเนื้อหาคือไฟล์ .po, .pot, .json และ .xliff ที่แปลแล้วของคุณ ซึ่งขับเคลื่อนทุกสตริงของธีมและปลั๊กอินไปยังภาษาเป้าหมาย ชั้นสัญญาณคือ hreflang ที่นำทางแต่ละเวอร์ชันที่แปลเสร็จแล้วไปยังกลุ่มเป้าหมาย ทั้งสองต้องแข็งแกร่ง ชุด hreflang ที่สมบูรณ์แบบบนเว็บไซต์ที่แปลได้เพียง 40 เปอร์เซ็นต์เพียงแค่รับประกันประสบการณ์ที่แย่ลงเร็วขึ้น
นี่คือจุดที่การรักษาชั้นการแปลให้สะอาดมีความสำคัญมากที่สุด เมื่อคุณแปลไฟล์อินเทอร์เฟซของคุณ ตัวยึดตำแหน่งเช่น %s, %1$s และ {name} ต้องคงอยู่เหมือนเดิม มิฉะนั้นหน้าภาษาเยอรมันที่ "แปลแล้ว" ของคุณจะแสดงโทเค็น %s ตามตัวอักษรที่ดูเสียหายทั้งสำหรับผู้ใช้และเครื่องมือค้นหา ไปป์ไลน์การแปลที่เข้าใจ gettext พร้อม Syntax Locking จะป้องกันโทเค็นเหล่านั้นโดยอัตโนมัติ เพื่อให้ทุกหน้าทางเลือกที่คุณชี้ hreflang ไปนั้นพร้อมใช้งานจริง เนื่องจากทำงานบนคลาวด์ด้วย Smart Batching คุณสามารถผลักดันเว็บไซต์หลายโลคัลทั้งหมดผ่านไปได้โดยไม่ต้องติดตั้งปลั๊กอินแปลภาษาที่ทำให้รันไทม์ที่ให้บริการหน้าเหล่านั้นบวมขึ้น
จัดเตรียมเนื้อหาให้ถูกต้องก่อน จากนั้นให้ hreflang ทำงานของมัน สองสิ่งนี้เมื่อรวมกันคือสิ่งที่รวบรวมสัญญาณการจัดอันดับ ขจัดผลลัพธ์ที่ผิดภาษา และนำแต่ละหน้าที่แปลแล้วไปแสดงต่อผู้ที่สามารถอ่านได้
พร้อมที่จะแก้ไขผลการค้นหาภาษาที่ไม่ถูกต้องจากแหล่งที่มาแล้วหรือยัง? ลองใช้ SimplePoTranslate ฟรี – ไม่ต้องใช้บัตรเครดิต แปลไฟล์
.po,.potและ.jsonของคุณในระดับฟรี แล้วชี้ hreflang tags ของคุณไปยังหน้าที่พร้อมสำหรับทุกตลาดจริงๆ