Web Design ยุค AI ต่างจากสมัยก่อนยังไง เว็บที่ Google และ AI Search อ่านออกในปี 2569

Web design ยุค AI ต่างจากสมัยก่อนตรงที่หน้าเว็บหนึ่งหน้าไม่ได้ถูกอ่านโดยคนเพียงกลุ่มเดียวอีกแล้ว แต่ถูกอ่านโดยบอทของเสิร์ชเอนจินและโดยระบบ AI ที่ดึงข้อความบางก้อนออกไปตอบคำถามผู้ใช้แล้วอ้างอิงกลับมาที่เว็บ สมัยก่อนงานออกแบบถือว่าจบเมื่อภาพสวย แบรนด์ดูดี และหน้าโหลดไม่ช้าจนน่ารำคาญ แต่ในปี 2569 งานชิ้นเดียวกันต้องผ่านสามด่านพร้อมกัน คือคนที่เปิดเข้ามาแล้วต้องเข้าใจตั้งแต่หน้าจอแรกว่าเว็บนี้ทำอะไร เบราว์เซอร์ที่เก็บค่าประสบการณ์จากผู้ใช้จริงแล้วส่งกลับไปเป็นสัญญาณ และตัวแยกโครงสร้างที่อ่านโค้ด HTML ล้วนโดยไม่เห็นหน้าตาที่ CSS จัดไว้เลยแม้แต่นิดเดียว บทความนี้ไล่ทีละด่านว่ามีอะไรเปลี่ยนไปบ้าง และตอนจ้างทำเว็บใหม่ควรถามอะไรกับทีมที่รับงาน

เว็บสวยอย่างเดียวไม่พออีกต่อไป

ความสวยยังจำเป็นอยู่ เพราะเป็นสิ่งแรกที่คนตัดสินว่าแบรนด์นี้น่าเชื่อถือแค่ไหน แต่ความสวยเป็นค่าผ่านประตู ไม่ใช่เส้นชัย เว็บที่ออกแบบมาดีในเชิงภาพแล้วสร้างด้วยกล่อง div เปล่า ๆ ทั้งหน้า ใส่ข้อความสำคัญไว้ในไฟล์ภาพ และให้ทุกอย่างขึ้นจอหลังจาก JavaScript ทำงานเสร็จ จะเป็นเว็บที่คนอ่านออกแต่เครื่องอ่านไม่ออก ผลที่ตามมาไม่ได้เกิดทันทีในวันเปิดตัว แต่จะค่อย ๆ เห็นตอนที่หน้าเว็บไม่เคยขึ้นในผลการค้นหาที่ควรจะได้ ตอนที่คู่แข่งถูกยกไปเป็นคำตอบใน AI Search ส่วนแบรนด์เราไม่ถูกพูดถึงเลย และตอนที่ทีมการตลาดอยากแก้พาดหัวสักบรรทัดแล้วต้องรอคิวนักพัฒนาสามสัปดาห์

สิ่งที่เปลี่ยนไปจริง ๆ มีสองเรื่อง เรื่องแรกคือการวัดผล เมื่อก่อนเราเดาว่าเว็บเร็วหรือช้าจากเครื่องตัวเอง ตอนนี้เบราว์เซอร์เก็บค่าจากผู้ใช้จริงในสนามและรายงานออกมาเป็นตัวเลขที่ตรวจสอบได้ เรื่องที่สองคือผู้อ่านหน้าใหม่ ระบบ AI ไม่ได้เปิดเว็บแบบคนเปิด มันรับ HTML เข้าไปแล้วพยายามหาว่าอะไรคือหัวข้อ อะไรคือคำตอบ อะไรคือชื่อบริษัท ถ้าโครงสร้างบอกไม่ได้ มันก็เดา และเวลามันเดา มันมักเลือกเว็บอื่นที่บอกชัดกว่า

6 มิติของ web design ยุค AI

หกหัวข้อต่อไปนี้คือสิ่งที่ควรอยู่ในขอบเขตงานตั้งแต่วันเขียนใบเสนอราคา ไม่ใช่ของแถมที่ค่อยมาคุยกันตอนส่งมอบ

Core Web Vitals: LCP, INP, CLS และเกณฑ์ที่ใช้วัดจริง

Core Web Vitals คือชุดตัวชี้วัดประสบการณ์การใช้งานสามตัวที่วัดจากผู้ใช้จริง ไม่ใช่จากการจำลองในเครื่องทดสอบ

• LCP (Largest Contentful Paint) วัดว่าองค์ประกอบเนื้อหาที่ใหญ่ที่สุดในกรอบหน้าจอแรก ซึ่งมักเป็นภาพแบนเนอร์หรือบล็อกข้อความพาดหัว ถูกวาดเสร็จเมื่อไรนับจากจังหวะที่เริ่มโหลดหน้า ตัวเลขนี้จึงสะท้อนว่า "เห็นของจริงเมื่อไร" ไม่ใช่แค่เซิร์ฟเวอร์ตอบกลับเร็วแค่ไหน ตัวการที่ทำให้ LCP แย่มักเป็นภาพฮีโร่ไฟล์ใหญ่ที่ไม่ได้บีบอัด ฟอนต์ที่บล็อกการแสดงผล และสคริปต์ของบุคคลที่สามที่แย่งแบนด์วิดท์ในช่วงวินาทีแรก
• INP (Interaction to Next Paint) เข้ามาแทน FID ในฐานะ Core Web Vitals ตั้งแต่เดือนมีนาคม ปี 2567 ต่างกันตรงที่ FID วัดแค่ความหน่วงของการโต้ตอบครั้งแรก ส่วน INP เฝ้าดูการคลิก การแตะ และการกดแป้นพิมพ์ตลอดทั้งการเข้าชม แล้วรายงานค่าที่ใกล้เคียงกับครั้งที่แย่ที่สุด โดยนับตั้งแต่ผู้ใช้กดจนถึงเฟรมถัดไปที่วาดเสร็จ ค่านี้จึงจับอาการ "กดแล้วค้าง" ที่คนบ่นกันจริง ๆ สาเหตุหลักคืองานยาว ๆ ในเธรดหลัก การผูก event handler ที่ทำงานหนักเกินจำเป็น และการ hydrate ทั้งหน้าในคราวเดียวทั้งที่มีแค่บางส่วนต้องโต้ตอบได้
• CLS (Cumulative Layout Shift) วัดการขยับของเลย์เอาต์ที่ผู้ใช้ไม่ได้สั่ง โดยคิดคะแนนจากช่วงที่ขยับต่อเนื่องรุนแรงที่สุด แต่ละครั้งคิดจากสัดส่วนพื้นที่จอที่ได้รับผลกระทบคูณกับระยะที่ของเลื่อนไป อาการคลาสสิกคือกำลังจะกดปุ่มแล้วแบนเนอร์คุกกี้โผล่มาดันทุกอย่างลง หรือภาพที่ไม่ได้กำหนดความกว้างความสูงไว้ล่วงหน้าโหลดเสร็จแล้วดันข้อความ

จุดที่คนเข้าใจผิดบ่อยคือวิธีตัดสิน Core Web Vitals ไม่ได้ตัดสินจากค่าเฉลี่ย แต่ประเมินที่เปอร์เซ็นไทล์ที่ 75 ของข้อมูลผู้ใช้จริง และแยกกันระหว่างมือถือกับเดสก์ท็อป แปลว่าถ้าผู้ใช้หนึ่งในสี่ที่แย่ที่สุดยังเจอประสบการณ์ห่วย หน้านั้นก็ยังไม่ผ่าน อีกจุดคือเครื่องมือทดสอบในห้องแล็บให้ค่า INP ไม่ได้ เพราะ INP ต้องมีคนกดจริง เครื่องมือแล็บทำได้แค่ประมาณการจากงานที่ค้างในเธรดหลัก ดังนั้นเวลาเปิดเว็บใหม่ ให้ดูรายงานจากข้อมูลภาคสนามควบคู่ไปด้วยเสมอ อย่าตัดสินจากคะแนนหน้าเดียวในเครื่องมือเดียว

semantic HTML: โครงร่างที่เครื่องอ่านออก

semantic HTML คือการเลือกแท็กตามความหมายของเนื้อหา ไม่ใช่ตามหน้าตาที่อยากได้ เมนูหลักใช้แท็ก nav เนื้อหาหลักของหน้าอยู่ในแท็ก main บทความหนึ่งชิ้นอยู่ในแท็ก article หัวข้อไล่ลำดับจาก h1 ที่มีตัวเดียวต่อหน้าลงมาเป็น h2 สำหรับหัวข้อใหญ่ และ h3 สำหรับหัวข้อย่อยหรือคำถามแต่ละข้อ ตารางใช้แท็ก table พร้อมหัวคอลัมน์จริง ปุ่มที่กดแล้วเกิดการกระทำใช้แท็ก button ไม่ใช่ div ที่ผูก onclick และช่องกรอกทุกช่องต้องมี label ผูกกับมันจริง ๆ

เหตุผลไม่ได้เป็นเรื่องความสวยงามของโค้ด แต่เป็นเรื่องว่าตัวแยกโครงสร้างมองไม่เห็นสิ่งที่ CSS จัดวาง มันเห็นแค่ต้นไม้ของเอกสาร ถ้าทุกอย่างเป็น div เหมือนกันหมด มันไม่มีทางรู้ว่าบล็อกไหนคือเนื้อหาหลัก บล็อกไหนคือเมนู และหัวข้อไหนครอบคลุมย่อหน้าไหน ลำดับหัวข้อที่ถูกต้องทำหน้าที่เหมือนสารบัญที่เครื่องอ่านได้ ทำให้ระบบดึงคำตอบรู้ว่าย่อหน้าใต้หัวข้อ "ราคาเท่าไร" คือคำตอบของคำถามนั้น ผลพลอยได้อีกทางคือโปรแกรมอ่านหน้าจอใช้โครงสร้างชุดเดียวกันในการพาผู้ใช้ข้ามไปยังส่วนที่ต้องการ งานเดียวจึงได้ผลสองด้าน และถ้าอยากให้หน้าบริการถูกจัดกลุ่มถูกหมวดในผลการค้นหา โครงสร้างนี้คือฐานที่งานรับทำ SEOทุกอย่างวางอยู่บน

mobile-first และตัวอักษรไทย

mobile-first ไม่ได้แปลว่าย่อเว็บเดสก์ท็อปให้เล็กลง แต่แปลว่าตัดสินใจเรื่องลำดับความสำคัญบนจอแคบก่อน แล้วค่อยเพิ่มพื้นที่เมื่อจอกว้างขึ้น เพราะบนจอแคบเราซ่อนอะไรไม่ได้เลย ทุกอย่างต้องเรียงต่อกันลงมาเป็นแถวเดียว ถ้าลำดับบนมือถืออ่านแล้วไม่รู้เรื่อง แปลว่าโครงสร้างเนื้อหายังไม่ชัด ไม่ใช่เพราะจอเล็ก

ส่วนที่คู่มือภาษาอังกฤษมักข้ามไปคือการจัดตัวอักษรไทย ซึ่งมีเงื่อนไขที่ภาษาละตินไม่มี

• การตัดบรรทัด ภาษาไทยเขียนติดกันโดยไม่มีเว้นวรรคระหว่างคำ เบราว์เซอร์จึงต้องใช้พจนานุกรมช่วยหาขอบเขตคำ ถ้าตั้งค่าตัดบรรทัดผิดหรือใช้ระบบที่ไม่รองรับ ข้อความจะขาดกลางคำ อ่านแล้วสะดุดทันที ปัญหานี้เห็นชัดที่สุดในกล่องแคบ ๆ อย่างการ์ดสินค้าและปุ่ม
• ความสูงบรรทัด ภาษาไทยมีสระบนสระล่างและวรรณยุกต์ที่ซ้อนขึ้นไปอีกชั้น ถ้าใช้ค่าความสูงบรรทัดที่ตั้งมาสำหรับภาษาละติน วรรณยุกต์จะถูกตัดหัวหรือชนกับสระของบรรทัดบน เนื้อหาภาษาไทยจึงต้องการความสูงบรรทัดที่มากกว่าเนื้อหาภาษาอังกฤษที่ขนาดตัวอักษรเท่ากัน และควรทดสอบด้วยคำที่ซ้อนกันหลายชั้นจริง ๆ เช่นคำที่มีทั้งสระอิและไม้เอก
• ฟอนต์ที่มีวรรณยุกต์ครบ ฟอนต์บางตัวมีอักษรไทยไม่ครบทุกสระและวรรณยุกต์ หรือวางตำแหน่งซ้อนไม่ถูก ผลคือเบราว์เซอร์สลับไปใช้ฟอนต์สำรองกลางประโยค ตัวอักษรจึงหน้าตาไม่เหมือนกันในบรรทัดเดียว อีกกับดักคือการใช้ตัวหนาปลอมที่เบราว์เซอร์สังเคราะห์ขึ้นเอง ซึ่งทำให้วรรณยุกต์เละ ควรใช้น้ำหนักฟอนต์ที่มีอยู่จริงในไฟล์
• ขนาดและความยาวบรรทัด เพราะมีชั้นสระซ้อนอยู่ ตัวอักษรไทยที่ขนาดพิกเซลเท่ากับภาษาอังกฤษจะดูแน่นกว่า การขยับขนาดขึ้นอีกขั้นและคุมความยาวบรรทัดไม่ให้ยาวเกินไปช่วยให้สายตากลับมาต้นบรรทัดถูก
• ขนาดพื้นที่กด ปุ่มและลิงก์บนมือถือต้องกดโดนด้วยนิ้วโป้ง ไม่ใช่ด้วยเมาส์ WCAG 2.2 มีเกณฑ์ Target Size (Minimum) ระดับ AA ที่กำหนดพื้นที่กดขั้นต่ำ 24 คูณ 24 พิกเซล CSS โดยมีข้อยกเว้นบางกรณี ส่วนระดับ AAA กำหนดไว้ที่ 44 คูณ 44 พิกเซล ลิงก์ในเนื้อหาไทยที่วางชิดกันหลายอันติดต่อกันมักหลุดเกณฑ์นี้

accessibility ตาม WCAG 2.2

WCAG 2.2 คือมาตรฐานการเข้าถึงเนื้อหาเว็บที่แบ่งเกณฑ์เป็นสามระดับ คือ A, AA และ AAA โดยระดับ AA เป็นระดับที่องค์กรและงานจัดซื้อส่วนใหญ่ใช้อ้างอิง เกณฑ์ที่กระทบงานออกแบบโดยตรงที่สุดคือความต่างของสี ข้อความขนาดปกติต้องมีอัตราส่วนความสว่างระหว่างตัวอักษรกับพื้นหลังอย่างน้อย 4.5 ต่อ 1 ข้อความขนาดใหญ่ลดลงมาที่ 3 ต่อ 1 และองค์ประกอบส่วนติดต่อผู้ใช้อย่างขอบช่องกรอกหรือไอคอนที่สื่อความหมายต้องได้อย่างน้อย 3 ต่อ 1 เช่นกัน ตัวอักษรสีเทาอ่อนบนพื้นขาวที่นักออกแบบชอบใช้เพราะดูสะอาด มักเป็นจุดแรกที่ตก

เกณฑ์ที่เพิ่มเข้ามาใน WCAG 2.2 มีหลายข้อที่เกี่ยวกับพฤติกรรมของหน้าเว็บโดยตรง เช่น Focus Not Obscured ที่ห้ามให้แถบลอยหรือแชตวิดเจ็ตบังองค์ประกอบที่กำลังโฟกัสอยู่ Dragging Movements ที่กำหนดว่าอะไรที่ทำได้ด้วยการลากต้องมีวิธีทำแบบไม่ต้องลากด้วย Consistent Help ที่ให้ช่องทางขอความช่วยเหลืออยู่ตำแหน่งเดิมทุกหน้า Redundant Entry ที่ห้ามบังคับให้กรอกข้อมูลเดิมซ้ำในขั้นตอนถัดไป และ Accessible Authentication ที่ห้ามให้การเข้าสู่ระบบขึ้นอยู่กับการจำหรือการแก้ปริศนาอย่างเดียว

งานพื้นฐานที่ควรทำทุกครั้งคือ กำหนดค่าภาษาของหน้าเป็นภาษาไทยที่ระดับเอกสาร เพื่อให้โปรแกรมอ่านหน้าจอเลือกเสียงอ่านถูกและเพื่อให้ระบบอื่นรู้ว่าหน้านี้เป็นภาษาอะไร ใส่คำอธิบายภาพให้ภาพที่สื่อความหมายและปล่อยว่างสำหรับภาพตกแต่ง ทำให้ทุกอย่างใช้งานได้ด้วยคีย์บอร์ดโดยมีกรอบโฟกัสที่มองเห็นชัด และผูก label กับช่องกรอกทุกช่องแทนการใช้ข้อความจาง ๆ ในช่องเป็นคำอธิบาย เพราะข้อความนั้นหายไปทันทีที่เริ่มพิมพ์

LINE และ PromptPay สำหรับเว็บไทย

พฤติกรรมคนไทยทำให้เว็บไทยมีสองชิ้นส่วนที่เว็บต่างประเทศไม่มี ชิ้นแรกคือ LINE คนจำนวนมากไม่กรอกฟอร์มแต่ทักแชท ปุ่มเพิ่มเพื่อนหรือปุ่มเปิดแชตจึงควรอยู่ในตำแหน่งที่มือถือกดถึงตลอดเวลา และควรส่งบริบทไปกับการกดด้วย เช่น รู้ว่าผู้ใช้มาจากหน้าบริการไหนหรือสินค้ารุ่นใด ไม่อย่างนั้นทีมขายต้องเริ่มถามใหม่ตั้งแต่ต้นทุกครั้ง ถ้าธุรกิจต้องการมากกว่าการแชต เช่น จองคิว สะสมแต้ม หรือดูสถานะคำสั่งซื้อภายในแอป การทำเป็นLINE Mini Appจะให้ประสบการณ์ที่ต่อเนื่องกว่าการเด้งออกไปเปิดเบราว์เซอร์ ข้อควรระวังด้านการวัดผลคือการกดออกไปที่ LINE เป็นแค่การออกจากเว็บ ไม่ใช่ยอดขาย ควรบันทึกเป็นเหตุการณ์แล้วไปกระทบยอดกับฝั่งแชตอีกที

ชิ้นที่สองคือการชำระเงิน PromptPay ทำให้การโอนด้วยคิวอาร์เป็นเรื่องปกติจนคนคาดหวังว่าต้องมี เว็บขายของที่เปิดหน้าชำระเงินมาแล้วมีแต่บัตรเครดิตจะเสียคนที่ตั้งใจจะโอนไปเงียบ ๆ สิ่งที่ควรออกแบบให้ดีคือคิวอาร์ที่ระบุยอดมาให้แล้วเพื่อไม่ให้กรอกเลขผิด ขั้นตอนยืนยันที่บอกชัดว่าจ่ายสำเร็จหรือยัง และเส้นทางสำรองเมื่อสลิปยังไม่ถูกตรวจอัตโนมัติ ทั้งหมดนี้เป็นงานออกแบบขั้นตอน ไม่ใช่แค่งานติดตั้งปลั๊กอิน และเชื่อมโยงตรงกับงานการตลาดอีคอมเมิร์ซที่วัดผลตั้งแต่หน้าสินค้าจนถึงการจ่ายเงินจริง

headless CMS เมื่อเว็บต้องขยาย

headless CMS คือการแยกที่เก็บเนื้อหาออกจากส่วนแสดงผล เนื้อหาอยู่ในระบบหลังบ้านและถูกเรียกผ่าน API ส่วนหน้าเว็บเป็นแอปแยกที่ดึงข้อมูลไปวาด ข้อดีที่ชัดคือเนื้อหาชุดเดียวจ่ายออกไปได้หลายที่พร้อมกัน ทั้งเว็บหลัก แอป จอในสาขา LINE Mini App และปลายทางอื่นที่จะเกิดขึ้นทีหลัง แก้ราคาที่เดียวแล้วเปลี่ยนทุกที่ อีกข้อคือการทำสองภาษา ถ้าโครงสร้างข้อมูลมองภาษาเป็นฟิลด์หนึ่งของเนื้อหาตั้งแต่แรก การจับคู่หน้าไทยกับหน้าอังกฤษเพื่อประกาศความสัมพันธ์ระหว่างภาษาจะตรงกันเสมอ ต่างจากการก๊อบปี้ต้นไม้หน้าเว็บทั้งชุดมาแก้ ซึ่งพอแก้หน้าเดียวแล้วอีกภาษาลืมแก้ก็เพี้ยนทันที

ข้อแลกเปลี่ยนที่ต้องยอมรับคือมันต้องการสายการสร้างและปล่อยเว็บที่ทำงานได้จริง และการแก้เลย์เอาต์ต้องผ่านนักพัฒนา เว็บโบรชัวร์สิบกว่าหน้าที่แก้ปีละสองครั้งไม่จำเป็นต้องใช้ ถ้าเนื้อหามีจำนวนมาก มีหลายภาษา มีทีมหลายคนแก้พร้อมกัน หรือมีปลายทางมากกว่าหนึ่งช่องทาง ตอนนั้นค่อยคุยเรื่องนี้ถึงจะคุ้ม

ตารางด้านล่างสรุปว่าหกมิติข้างต้นเปลี่ยนอะไรให้ผู้ใช้ที่เป็นคน และเปลี่ยนอะไรให้ระบบที่อ่านหน้าเว็บแทนคน

8 องค์ประกอบของ landing page ที่แปลงได้

หน้าแลนดิงเพจที่ทำงานได้ไม่ได้ต่างกันที่ลูกเล่น แต่ต่างกันที่ครบหรือไม่ครบ แต่ละส่วนด้านล่างมีหน้าที่ของตัวเองและตอบคำถามคนละข้อในหัวของผู้อ่าน

1. ฮีโร่ พื้นที่บนสุดที่เห็นก่อนเลื่อน หน้าที่คือตอบให้ได้ในหนึ่งบรรทัดว่านี่คืออะไร สำหรับใคร และให้กดอะไรต่อ ถ้าพาดหัวเป็นคำโฆษณาลอย ๆ อย่าง "ก้าวไปอีกขั้น" ผู้อ่านจะยังไม่รู้ว่าเว็บนี้ขายอะไร ควรเขียนพาดหัวเป็นข้อความจริงในโค้ด ไม่ใช่ตัวหนังสือที่ฝังอยู่ในภาพ
2. หลักฐานจากภายนอก โลโก้ลูกค้า จำนวนปีที่ทำ ใบรับรอง หรือรางวัลที่ได้มาจริง วางไว้ใกล้ฮีโร่เพื่อลดความลังเลตั้งแต่ต้น ข้อสำคัญคือต้องเป็นของจริงที่ตรวจสอบได้ ไม่ใช่ตัวเลขที่คิดขึ้นเอง
3. จุดขายที่ต่างจากคนอื่น อธิบายว่าทำไมต้องเป็นเจ้านี้ โดยเทียบกับทางเลือกที่ผู้อ่านกำลังคิดอยู่จริง ๆ รวมถึงทางเลือกที่ว่าไม่ทำอะไรเลย ส่วนนี้เขียนสั้นได้แต่ต้องเฉพาะเจาะจง
4. ส่วนอธิบายความสามารถ ไล่ว่าบริการหรือสินค้าทำอะไรได้บ้าง โดยผูกความสามารถแต่ละข้อกับผลลัพธ์ที่ผู้อ่านได้ ส่วนนี้เหมาะกับการใช้หัวข้อย่อยและรายการ เพราะเป็นจุดที่คนกวาดสายตามากกว่าอ่านทุกคำ
5. เสียงจากผู้ใช้จริง คำพูดของลูกค้าที่ระบุชื่อและบริบทได้ มีน้ำหนักกว่าคำชมลอย ๆ ที่ไม่รู้ว่าใครพูด ถ้ามีรูปหรือชื่อองค์กรประกอบด้วยจะยิ่งตรวจสอบได้
6. คำถามที่พบบ่อย รวบคำถามที่ทำให้คนไม่กล้าตัดสินใจ เช่น ราคา ระยะเวลา และเงื่อนไขการยกเลิก การเขียนแต่ละคำถามเป็นหัวข้อย่อยแล้วตอบให้จบในประโยคแรกช่วยทั้งผู้อ่านและระบบที่ดึงคำตอบไปแสดง
7. ปุ่มที่ติดอยู่กับหน้าจอ บนมือถือ ปุ่มติดต่อที่ลอยอยู่ด้านล่างทำให้คนไม่ต้องเลื่อนกลับขึ้นไปหา ข้อควรระวังคืออย่าให้มันบังเนื้อหาหรือบังองค์ประกอบที่กำลังโฟกัสอยู่ เพราะขัดกับเกณฑ์การเข้าถึงโดยตรง
8. การจับจังหวะก่อนออก ข้อเสนอที่แสดงเมื่อผู้ใช้กำลังจะปิดหน้าหรือหยุดนิ่งนาน ใช้ได้ผลก็ต่อเมื่อสิ่งที่เสนอมีค่าจริง เช่น ใบเสนอราคาหรือคู่มือเปรียบเทียบ ถ้าเป็นป๊อปอัปขอให้กรอกอีเมลเปล่า ๆ มันจะกลายเป็นสิ่งกวนใจที่ทำให้คนออกเร็วขึ้น

เว็บที่ AI Search อ่านง่ายต่างจากเว็บทั่วไปยังไง

ระบบ AI ที่ไปดึงเนื้อหาจากเว็บมาตอบคำถามทำงานเป็นขั้น คือเข้าถึงหน้าให้ได้ อ่านโครงสร้างให้ออก แยกก้อนเนื้อหาที่ตอบคำถามได้ แล้วตัดสินใจว่าจะยกก้อนไหนไปพร้อมกับเครดิตแหล่งที่มา เว็บที่ถูกยกไปใช้บ่อยจึงมักมีลักษณะร่วมกันไม่กี่อย่าง

อย่างแรกคือมี structured data สำหรับ AI Search ที่เขียนด้วยรูปแบบ JSON-LD ซึ่งเป็นการอธิบายหน้าเว็บด้วยข้อมูลที่เครื่องอ่านโดยตรง แยกจากข้อความที่คนอ่าน ประเภทที่ใช้ได้จริงกับเว็บธุรกิจคือ Organization สำหรับตัวองค์กร WebSite สำหรับตัวเว็บ BreadcrumbList สำหรับเส้นทางนำทาง Service สำหรับหน้าบริการแต่ละหน้า FAQPage สำหรับชุดคำถามคำตอบ และ Article สำหรับบทความ ข้อมูลพวกนี้ไม่ได้ทำให้เนื้อหาดีขึ้นเอง แต่ทำให้สิ่งที่เขียนไว้อยู่แล้วถูกอ่านโดยไม่ต้องตีความ

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

อย่างที่สามคือรูปร่างของเนื้อหา ก้อนที่ถูกยกไปตอบได้ดีคือย่อหน้าที่อ่านจบแล้วเข้าใจโดยไม่ต้องย้อนไปอ่านย่อหน้าก่อนหน้า วิธีเขียนที่ได้ผลคือใช้หัวข้อย่อยเป็นคำถามที่คนถามจริง แล้วตอบให้จบตั้งแต่ประโยคแรกใต้หัวข้อนั้น ค่อยขยายรายละเอียดต่อ หลีกเลี่ยงการอ้างว่า "ตามที่กล่าวไปข้างต้น" เพราะเวลาก้อนนั้นถูกยกออกไปเดี่ยว ๆ มันจะอ้างถึงสิ่งที่ไม่มีอยู่ ตารางที่มีหัวคอลัมน์จริงและรายการที่ใช้แท็กรายการก็ถูกอ่านง่ายกว่าข้อความที่จัดคอลัมน์ด้วย CSS เฉย ๆ

อย่างสุดท้ายคือการเข้าถึงตัวเนื้อหา ถ้าข้อความปรากฏก็ต่อเมื่อ JavaScript ทำงานเสร็จในฝั่งผู้ใช้ นั่นคือขั้นตอนเพิ่มที่ตัวดึงข้อมูลบางตัวไม่ได้ทำ การส่ง HTML ที่มีเนื้อหาครบมาตั้งแต่เซิร์ฟเวอร์จึงปลอดภัยกว่า และเป็นหัวใจของงานGEO สำหรับ AI Searchที่มุ่งให้แบรนด์ถูกอ้างอิงในคำตอบ ไม่ใช่แค่มีอันดับในหน้าผลการค้นหา

5 ข้อผิดพลาดที่เจอบ่อยในเว็บแบรนด์ไทย

1. ใส่ข้อความไทยไว้ในไฟล์ภาพฮีโร่ เพราะอยากได้ฟอนต์สวยและจัดวางอิสระ ผลคือข้อความนั้นไม่ถูกค้นหา ไม่ถูกคัดลอก ไม่ถูกแปล และภาพขนาดใหญ่กลายเป็นองค์ประกอบที่กำหนดค่า LCP ของทั้งหน้า แก้ด้วยการวางข้อความเป็นข้อความจริงทับบนภาพพื้นหลัง
2. ทำหัวข้อด้วย div ที่จัดสไตล์ให้ตัวใหญ่ แทนการใช้ h2 และ h3 หน้าเว็บจึงไม่มีลำดับหัวข้อเลยในสายตาเครื่อง ชุดคำถามคำตอบที่อุตส่าห์เขียนไว้ก็ไม่มีขอบเขตให้ระบบจับว่าคำถามเริ่มตรงไหนจบตรงไหน โอกาสถูกยกไปแสดงเป็นคำตอบจึงหายไปทั้งชุด
3. ให้ข้อมูลติดต่ออยู่ในภาพหรืออยู่ในแชตอย่างเดียว เบอร์โทรและที่อยู่ที่เป็นภาพ อ่านไม่ได้ กดโทรไม่ได้ และไม่ถูกนำไปประกอบเป็นข้อมูลองค์กร พอข้อมูลชุดนี้ไม่ตรงกับที่ประกาศไว้ในโปรไฟล์อื่น ระบบก็จับคู่ไม่ได้ว่าเป็นแบรนด์เดียวกัน
4. ใช้ค่าความสูงบรรทัดและฟอนต์ที่มากับเทมเพลตภาษาอังกฤษ โดยไม่ปรับให้รองรับไทย วรรณยุกต์จึงถูกตัดหรือชนกัน และเมื่อฟอนต์หลักไม่มีอักษรไทยครบ เบราว์เซอร์จะสลับไปฟอนต์สำรองหลังโหลดเสร็จ ทำให้ข้อความขยับและคะแนน CLS แย่ลงพร้อมกัน
5. ย้ายเว็บใหม่แล้วเปลี่ยนที่อยู่หน้าเดิมโดยไม่ทำการเปลี่ยนเส้นทาง ทุกลิงก์ที่เคยชี้มาจากภายนอกและทุกหน้าที่เคยมีอันดับจะกลายเป็นหน้าไม่พบ ค่าที่สะสมมาหลายปีหายในวันเดียว ก่อนเปิดเว็บใหม่ควรมีตารางจับคู่ที่อยู่เดิมกับที่อยู่ใหม่ให้ครบทุกหน้าที่มีคนเข้าจริง

เว็บแบรนด์ไทยต้องเตรียมอะไรเป็นพิเศษ

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

เรื่องต่อมาคือช่องทางติดต่อ เว็บไทยที่มีแต่ฟอร์มยาว ๆ จะได้ลีดน้อยกว่าเว็บที่เปิดทางให้ทักแชทได้ทันที แต่การมีแค่ปุ่มแชตก็ไม่พอเช่นกัน เพราะข้อมูลจะไปกองอยู่ในแชตโดยไม่มีใครสรุปกลับมาเป็นตัวเลข ทางที่ใช้ได้จริงคือมีทั้งสองอย่างและวัดทั้งสองอย่าง สุดท้ายคือเนื้อหาราคาและเงื่อนไข คนไทยจำนวนมากตัดสินใจจากความชัดเจนเรื่องราคาและระยะเวลามากกว่าจากความสวยของหน้าเว็บ การเขียนช่วงราคาและขั้นตอนทำงานให้ชัดตั้งแต่หน้าบริการช่วยกรองคนที่ยังไม่พร้อมออกไปเอง และช่วยให้คนที่พร้อมทักมาพร้อมคำถามที่ตรงจุดกว่าเดิม

คำถามที่พบบ่อย

ทำเว็บใหม่หรือปรับของเดิมดีกว่า

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

WordPress ยังใช้ได้ไหมในปี 2569

ยังใช้ได้ และยังเป็นตัวเลือกที่สมเหตุสมผลสำหรับเว็บบริษัทและเว็บเนื้อหาส่วนใหญ่ ปัญหาความเร็วที่คนโทษ WordPress มักไม่ได้มาจากตัวมันเอง แต่มาจากธีมสำเร็จรูปที่โหลดทุกอย่างเผื่อไว้ ตัวสร้างหน้าเว็บที่ผลิตกล่องซ้อนกันหลายชั้น และปลั๊กอินที่ทำงานทับซ้อนกัน ถ้าใช้ธีมที่คุมได้ ตัดสิ่งที่ไม่ใช้ออก และแคชหน้าไว้ ผลลัพธ์ด้านความเร็วก็อยู่ในเกณฑ์ได้ จุดที่ WordPress เริ่มไม่คุ้มคือเมื่อต้องจ่ายเนื้อหาชุดเดียวกันออกไปหลายช่องทางหรือมีทีมแก้ไขพร้อมกันจำนวนมาก ตอนนั้นค่อยพิจารณา headless CMS

ทำเว็บใหม่แล้วกี่เดือนถึงเห็นผลในการค้นหา

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

ถ้าเนื้อหาดีอยู่แล้ว ยังต้องใส่ structured data อีกไหม

ต้องใส่ เพราะ structured data ไม่ได้ทำหน้าที่แทนเนื้อหา แต่ทำหน้าที่บอกเครื่องว่าข้อความที่เขียนไว้คืออะไร ชื่อไหนคือชื่อองค์กร ตัวเลขไหนคือราคา และย่อหน้าไหนคือคำตอบของคำถามข้อไหน เมื่อไม่ต้องตีความ โอกาสที่เนื้อหาจะถูกหยิบไปใช้อย่างถูกต้องก็สูงขึ้น ข้อควรระวังคือข้อมูลที่ประกาศต้องตรงกับสิ่งที่แสดงบนหน้าจริง ถ้าประกาศคำถามคำตอบที่ไม่มีอยู่บนหน้า นั่นคือการประกาศข้อมูลเท็จ

ต้องตรวจอะไรบ้างหลังเว็บขึ้นจริง

ตรวจสี่อย่างในสัปดาห์แรก หนึ่งคือหน้าเว็บสำคัญทุกหน้าถูกเก็บเข้าดัชนีแล้วจริงหรือยัง สองคือค่าประสบการณ์จากผู้ใช้จริงทั้ง LCP, INP และ CLS แยกตามมือถือกับเดสก์ท็อป สามคือที่อยู่เดิมทุกอันเปลี่ยนเส้นทางมาที่หน้าใหม่ถูกต้อง ไม่มีหน้าไม่พบและไม่มีการเปลี่ยนเส้นทางต่อกันหลายทอด สี่คือปุ่มติดต่อและขั้นตอนชำระเงินทำงานได้บนมือถือจริงหลายรุ่น ไม่ใช่แค่ในเครื่องที่ทีมใช้ทดสอบ

เริ่มจากตรงไหนดี

ถ้าตอนนี้กำลังจะจ้างทำเว็บใหม่ ให้เอาหกมิติข้างต้นไปเป็นหัวข้อในขอบเขตงาน แล้วถามทีมที่รับงานว่าจะวัดผลแต่ละข้ออย่างไรหลังเปิดเว็บ คำตอบที่ดีจะพูดถึงข้อมูลผู้ใช้จริง โครงสร้างหัวข้อ และการทดสอบด้วยคีย์บอร์ด ไม่ใช่แค่จำนวนหน้าและจำนวนรอบแก้ไข ส่วนใครที่มีเว็บอยู่แล้วและอยากรู้ว่าห่างจากมาตรฐานปัจจุบันแค่ไหน เริ่มจากตรวจสามอย่างคือค่าจากผู้ใช้จริง ลำดับหัวข้อในหน้าสำคัญ และการจัดตัวอักษรไทยบนมือถือ ทีมของ Relevant Audience ทำงานด้าน web design bangkok ควบคู่กับงานค้นหาและงานเนื้อหา ถ้าอยากให้ช่วยดูว่าเว็บปัจจุบันติดตรงไหนก่อนตัดสินใจรื้อทั้งหมด ทักมาคุยได้