Mobile-first indexing: เนื้อหาบนมือถือ การตั้งค่า viewport และการแตะที่ใช้งานง่าย
1. mobile-first indexing เปลี่ยนอะไรไปบ้าง
Google เริ่มทดสอบ mobile-first indexing ในปี 2019 และบังคับใช้กับทุกเว็บไซต์ตั้งแต่เดือนกรกฎาคม 2024 สิ่งที่เปลี่ยนไปไม่ใช่อัลกอริทึมการจัดอันดับ แต่เป็นวิธีที่ Google มองเว็บไซต์ของคุณ
| แบบเดิม (desktop-first) | แบบใหม่ (mobile-first) | ผลกระทบต่อเว็บ B2B |
|---|---|---|
| ครอว์ลหน้าเวอร์ชันเดสก์ท็อปเพื่อจัดอินเด็กซ์ | ครอว์ลหน้าเวอร์ชันมือถือเพื่อจัดอินเด็กซ์ | ตารางบนเดสก์ท็อปที่ถูกมือถือซ่อนจะไม่ถูกจัดอินเด็กซ์ |
| เวอร์ชันมือถือเป็นแค่การปรับประสบการณ์ | เวอร์ชันมือถือเป็นแหล่งข้อมูลเดียวที่ใช้จัดอินเด็กซ์ | Schema ที่เรนเดอร์แค่บนเดสก์ท็อปเท่ากับไม่ได้เขียน |
| ยอมรับ subdomain แยกอย่าง m.example.com ได้ | subdomain มือถือแยกดูแลรักษาแพง | แนะนำให้ใช้ responsive แบบเดียวกัน และเลิกใช้ subdomain m. |
| ลิงก์ภายนอกส่งค่าคะแนนจากเดสก์ท็อป | ลิงก์ภายนอกก็ประเมินจากเวอร์ชันมือถือเช่นกัน | มือถือช้าจะกระทบอันดับด้วย |
เช็กว่าคุณถูกสลับไปแล้วหรือยัง: หน้าแรกของ Search Console จะแสดงข้อความ “ตรวจพบว่าอินเด็กซ์เว็บไซต์นี้แบบ mobile-first แล้ว” ถ้ายังไม่แสดง แปลว่า Google ยังใช้กฎเดิมครอว์ลคุณอยู่ แต่การสลับเป็นแค่เรื่องของเวลา อย่ารอ
2. สี่จุดตรวจตายตัว: viewport, เนื้อหา, การแตะ, Schema
การตรวจความสอดคล้องของ mobile-first indexing แบ่งได้เป็นสี่เรื่อง แต่ละเรื่องมีเกณฑ์ชัดเจน
| รายการตรวจสอบ | เกณฑ์ผ่าน | ข้อผิดพลาดที่พบบ่อย | เครื่องมือตรวจสอบ |
|---|---|---|---|
| viewport | <meta name=”viewport” content=”width=device-width, initial-scale=1″> | กำหนด width=1200 ตายตัว หรือไม่มี viewport | ทดสอบความเข้ากันได้กับมือถือ |
| เนื้อหาต้องสอดคล้องกัน | เนื้อหาที่มองเห็นบนเดสก์ท็อปและมือถือเหมือนกันทุกประการ | มือถือซ่อนตารางและสเปกด้วย display:none | ดูซอร์สโค้ดของ URL เวอร์ชันมือถือเพื่อเทียบ |
| แตะใช้งานง่าย | พื้นที่แตะ ≥ 48×48 CSS พิกเซล ระยะห่าง ≥ 8px | ปุ่มขนาด 24px ลิงก์ชิดกันเกินไป | จำลองมือถือใน Chrome DevTools |
| ข้อมูลแบบมีโครงสร้าง | ซอร์สโค้ดหน้าเวอร์ชันมือถือมี JSON-LD ครบถ้วน | Schema ถูกส่งออกแค่ในเทมเพลตเดสก์ท็อป | ทดสอบ URL เวอร์ชันมือถือด้วย Rich Results Test |
ตัวอย่างสถานการณ์: หน้าสินค้าของเว็บขายอะไหล่อุตสาหกรรม บนเดสก์ท็อปมีตารางสเปกครบ 30 แถว แต่บนมือถือถูกตั้ง display:none ทั้งตารางเพื่อ “ทำให้เรียบง่าย” หลังเปิดใช้ mobile-first index หน้าสินค้านี้มีคีย์เวิร์ดหางยาว 12 คำหลุดออกจาก 20 อันดับแรกทั้งหมด เพราะ Google เห็นแค่ข้อความแนะนำบนเวอร์ชันมือถือ ไม่รู้ว่าสินค้ามีสเปกอะไรบ้าง พอเปลี่ยนตารางเป็นเลื่อนแนวนอนบนมือถือ ภายในสองสัปดาห์มี 8 คำกลับมาอยู่ใน 10 อันดับแรก
ความสอดคล้องของเนื้อหาไม่ได้หมายความว่าจัดวางบนเดสก์ท็อปกับมือถือต้องเหมือนกันทุกจุด แต่ข้อความ ตาราง รูปภาพ และ Schema ต้องอยู่ครบ จัดวางแบบยุบรวมได้ แต่ห้ามลบ
สาม: Responsive vs dynamic serving vs m. subdomain
Google สนับสนุนสามแนวทางสำหรับเวอร์ชันมือถืออย่างเป็นทางการ แต่ระดับการแนะนำต่างกัน
| 方案 | การใช้งาน | ต้นทุนการดูแล | ระดับการแนะนำ |
|---|---|---|---|
| Responsive Web Design | HTML ชุดเดียวกัน ใช้ CSS media query ปรับ | ต่ำ | แนะนำเป็นอันดับแรก |
| Dynamic serving | URL เดียวกัน คืน HTML ต่างกันตาม UA | ปานกลาง | ใช้ได้ |
| m. subdomain แยก | m.example.com มีเทมเพลตแยกต่างหาก | สูง | ไม่แนะนำ เป็นภาระจากอดีต |
| ไม่มีเวอร์ชันมือถือ | ย่อเดสก์ท็อปให้แสดง | ไม่มี | ห้าม ไม่เป็นมิตรกับมือถือ |
จุดที่ขัดกับสัญชาตญาณ: m. subdomain แยกดูเหมือน “ควบคุมได้” แต่จริง ๆ ต้องดูแลเทมเพลตสองชุด Schema สองชุด hreflang สองชุด พอไม่ตรงกันก็เกิดเนื้อหาไม่สอดคล้อง กระบวนการย้ายไป responsive เองก็คือ การย้ายเว็บไซต์ ต้องทำ 301 mapping เว็บหลายภาษาต้องตรวจด้วยว่า Hreflang การรองรับหลายภาษา ถูกเทมเพลตมือถือทำพังหรือไม่
สี่: รูปภาพ ฟอนต์ และประสิทธิภาพเฉพาะมือถือ
Mobile-first index ไม่ได้แค่ “ดูได้” แต่ Google ยังใช้ข้อมูลเวอร์ชันมือถือประเมิน Core Web Vitals。
| รายการ | วิธีที่พบบ่อยบนเดสก์ท็อป | มือถือต้องแก้ |
|---|---|---|
| รูปภาพ | รูปใหญ่รูปเดียว | srcset + sizes ปรับตาม DPR และความกว้าง |
| ฟอนต์ | โหลดทั้ง 3 น้ำหนัก | โหลดแค่ 2 น้ำหนัก ใช้ font-display: swap |
| Navigational | เมนูแนวนอนด้านบน | เมนูแฮมเบอร์เกอร์ เลี่ยงการล้นบนมือถือ |
| ฟอร์ม | กางทุกฟิลด์ | type ปรับตามตัวเลข/อีเมล เลี่ยงคีย์บอร์ดเต็ม |
| โฆษณาและป๊อปอัป | แถบด้านข้าง | มือถือห้ามใช้ป๊อปอัปแบบคั่นหน้าบังเนื้อหา |
ตัวอย่างสถานการณ์ที่สอง: บล็อกของเว็บ B2B มี LCP บนมือถืออยู่ที่ 4.5 วินาทีมานาน เพราะรูป hero ใช้ต้นฉบับกว้าง 2400px ของเดสก์ท็อป หลังเพิ่ม srcset ให้มีขนาด 640px และ 1080px LCP บนมือถือลดลงเหลือ 2.1 วินาที โดยเดสก์ท็อปไม่ได้รับผลกระทบ การแก้นี้เพิ่มแค่สองแอตทริบิวต์ในแท็ก img ไม่ได้แก้ดีไซน์เลย
ป๊อปอัปบนมือถือเป็นเป้าที่ Google ตั้งใจจัดการเป็นพิเศษ: ถ้าหน้าบนมือถือใช้ป๊อปอัปแบบคั่นหน้าบังเนื้อหาหลัก จะถูกทำเครื่องหมายว่า “ไม่เป็นมิตรกับมือถือ” ป๊อปอัป Newsletter ที่พบบ่อยบนเว็บ B2B ต้องเปลี่ยนเป็นแถบล่างหรือไม่ต้องเด้งบนมือถือ
ห้า: เช็กลิสต์ตรวจสอบตัวเองและขั้นตอนยืนยัน
| รายการตรวจสอบ | เครื่องมือ | เกณฑ์ผ่าน | ความถี่ |
|---|---|---|---|
| ทดสอบความเป็นมิตรกับมือถือ | Google Mobile-Friendly Test | ผ่านทั้งหมด ไม่มีคำเตือนฟอนต์เล็กเกิน/พื้นที่แตะใกล้เกิน | รันหนึ่งครั้งหลังเปลี่ยนเวอร์ชัน |
| เนื้อหาต้องสอดคล้องกัน | จำลองมือถือใน Chrome + ดูซอร์สโค้ด | ข้อความที่มองเห็นบนเดสก์ท็อปกับมือถือตรงกันทั้งหมด | สุ่มตรวจ 10 หน้าทุกไตรมาส |
| การเรนเดอร์ Schema บนมือถือ | ทดสอบ URL เวอร์ชันมือถือด้วย Rich Results Test | ตรวจจับ Schema ได้ครบทุกประเภท | หลังเปลี่ยนเทมเพลต |
| ข้อมูล CrUX บนมือถือ | รายงานประสบการณ์ใน Search Console | ผ่านเกณฑ์ CWV บนมือถือครบทั้งสามตัว | ทุกเดือน |
| สถานะการจัดทำดัชนีบนมือถือ | หน้าแรกของ Search Console | แสดงว่า “จัดทำดัชนีแบบมือถือก่อนแล้ว” | ทุกเดือน |
การปรับประสบการณ์บนมือถือกับ การเข้าถึงเว็บไซต์ (WCAG) ทับซ้อนกันเยอะ ทั้งขนาดพื้นที่แตะ ความต่างสี และการนำทางด้วยคีย์บอร์ด แก้ครั้งเดียวได้ประโยชน์ทั้งสองฝั่ง
หก ปรับวิธีเขียนเนื้อหาหลังจากจัดทำดัชนีแบบมือถือก่อน
การจัดทำดัชนีแบบมือถือก่อนไม่ใช่แค่ปรับเทคนิค วิธีเขียนเนื้อหาก็ต้องเปลี่ยนตามด้วย บนเดสก์ท็อปใส่ตารางยาว ตารางพารามิเตอร์หลายคอลัมน์ หรือคำอธิบายยาว ๆ ได้ แต่คนที่เปิดบนมือถือถือมือเดียว จังหวะการอ่านต่างกันคนละเรื่อง โครงสร้างเนื้อหาจึงต้องจัดใหม่ให้เป็นคอลัมน์เดียวสำหรับจอแนวตั้ง
| องค์ประกอบเนื้อหา | วิธีเขียนที่พบบนเดสก์ท็อป | วิธีเขียนที่แนะนำบนมือถือ |
|---|---|---|
| ตารางยาว | ตารางกว้าง 8 คอลัมน์ขึ้นไป | แยกเป็นการ์ดหรือเลื่อนแนวนอน โดยวางคอลัมน์สำคัญไว้ต้น |
| ความยาวย่อหน้า | ย่อหน้าละ 200 ตัวอักษรขึ้นไป | ย่อหน้าละไม่เกิน 3 ถึง 4 บรรทัด ใช้ประโยคสั้นและขึ้นบรรทัดใหม่บ่อย ๆ |
| ข้อความ anchor ของลิงก์ภายใน | ลิงก์ทั้งประโยค | แยกข้อความลิงก์เป็นบรรทัดของตัวเอง แตะด้วยนิ้วได้ง่าย |
| กราฟและแผนภูมิ | กราฟข้อมูลแน่น ๆ | ทำกราฟแบบย่อแยกสำหรับมือถือ พร้อมข้อความสรุป |
| ปุ่ม CTA | ปุ่มเล็กบนแถบนำทางด้านบน | วางปุ่มใหญ่หนึ่งปุ่มกลางบทความและอีกหนึ่งปุ่มท้ายบทความ |
ตอนเขียนให้ร่างเป็นเลย์เอาต์คอลัมน์เดียวแบบมือถือก่อน แล้วค่อยปรับให้เข้ากับเดสก์ท็อป เนื้อหาที่ได้จะอ่านได้ทั้งสองฝั่ง ไม่ใช่เดสก์ท็อปสวยแต่บนมือถือเบียดกันแน่น ทุกไตรมาสให้สุ่มบทความที่เผยแพร่แล้วสิบชิ้น เปิดดูผ่านโหมดจำลองมือถือใน Chrome ถ้าเจอตารางล้น ปุ่มเล็กเกินไป หรือลิงก์ชิดขอบ ก็ใส่เข้าไปแก้ในรอบถัดไป
ฟอร์มคือจุดที่เสียConversion มากที่สุดบนมือถือ บนเดสก์ท็อปใส่สิบกว่าช่องในครั้งเดียวได้ แต่คนที่กรอกบนมือถือใช้มือเดียว กรอกเพิ่มช่องเดียวก็เสียคนไปอีกกลุ่ม ตัดฟอร์มสอบถามให้เหลือช่องบังคับแค่สามถึงสี่ช่อง คือชื่อบริษัท อีเมล และสรุปความต้องการ ที่เหลือค่อยเก็บเพิ่มหลังปิดการขาย เบอร์มือถือ เบอร์โทร และประเทศ ซึ่งอนุมานได้จากอีเมลและโดเมนบริษัท ไม่ควรให้ผู้ใช้พิมพ์เอง อัตราการConversion ของฟอร์มบนมือถือเพิ่มขึ้นทุกห้าเปอร์เซ็นต์ จำนวนผู้สอบถามก็จะขยับขึ้นตาม
FAQ คำถามที่พบบ่อย
Google เริ่มบังคับใช้การจัดทำดัชนีแบบมือถือก่อนเมื่อไหร่
ซ่อนเนื้อหาด้วย display:none บนมือถือมีผลกับ SEO ไหม
ยังต้องเก็บซับโดเมน m.example.com แยกไว้ไหม
พื้นที่กดขั้นต่ำควรใหญ่แค่ไหน
ให้ Schema แสดงเฉพาะเวอร์ชันเดสก์ท็อปได้ไหม
ทำไม pop-up แบบคั่นหน้าในมือถือถึงถูกลงโทษ
ทิ้งท้าย
mobile-first index ไม่ใช่แค่ทำเวอร์ชันมือถือแล้วจบ แต่เป็นวิธีเดียวที่ Google ใช้มองเว็บของคุณ เดสก์ท็อปจะครบแค่ไหน ถ้ามือถือมองไม่เห็นก็เท่ากับไม่มีอยู่
ลงมือสามขั้นตอน: สัปดาห์นี้ใช้ Chrome DevTools จำลองมือถือสุ่มตรวจ 10 หน้าหลัก ยืนยันว่าเนื้อหาเดสก์ท็อปกับมือถือตรงกัน; สัปดาห์หน้าแก้จุดบกพร่องหนักๆ สามข้อ คือ viewport, พื้นที่กด และการเรนเดอร์ Schema บนมือถือ; สัปดาห์ที่สามเช็กใน Search Console ว่า mobile-friendly test ผ่าน และข้อมูล CrUX บนมือถืออยู่ในเกณฑ์
ประโยคที่จำง่ายๆ: mobile-first index ไม่ได้ให้คุณทำเว็บเดสก์ท็อปแบบย่อส่วน แต่ให้คุณยอมรับว่า สิ่งที่ Google เห็นก็คือเวอร์ชันเดียวกับที่ผู้เข้าชมเห็นบนมือถือ