ค้นหาภายในเว็บไซต์: ตั้งค่า SearchWP/Elasticsearch และเพิ่มอัตราการแปลง

เลือกเครื่องมือค้นหา 3 ระดับ: WP เริ่มต้น, SearchWP, Elasticsearch เทียบขนาดและต้นทุน

ค้นหาภายในเว็บไซต์: ตั้งค่า SearchWP/Elasticsearch และเพิ่มอัตราการแปลง

สรุปก่อน: การค้นหาภายในเว็บไซต์ไม่ใช่แค่ “ติดตั้งช่องค้นหาแล้วจบ” แต่เป็นช่องทางสร้างยอดขายที่ถูกมองข้ามอย่างมาก หลังติดตั้ง Google Analytics 4 วัดผลสองสัปดาห์ ถ้าอัตราการใช้ค้นหาต่ำกว่า 2% และอัตราผลลัพธ์ว่างสูงกว่า 20% ปัญหามักไม่ได้อยู่ที่เครื่องมือค้นหา แต่อยู่ที่โครงสร้างเนื้อหาและการจัดหมวดหมู่สินค้า จะอัปเกรดจาก WP เริ่มต้นเป็น SearchWP หรือ Elasticsearch ก็ต่อเมื่ออัตราการใช้ค้นหาเกิน 5% และอัตราผลลัพธ์ว่างยังสูงกว่า 15% แบ่งตามขนาดเป็น 3 ระดับ: ต่ำกว่า 200 หน้าใช้ WP เริ่มต้น, 200 ถึง 5000 หน้าใช้ SearchWP (ประมาณ 199 ดอลลาร์/ปี), เกิน 5000 หน้าหรือ SKU เกินพันจึงใช้ Elasticsearch

หนึ่ง ทำไมทีมเว็บไซต์ของแบรนด์จึงมองข้ามการค้นหาภายในเว็บไซต์อย่างเป็นระบบ

เว็บไซต์ B2B ส่วนใหญ่มองช่องค้นหาเป็นแค่องค์ประกอบตกแต่ง วางไว้มุมขวาบน ไม่มีใครตั้งค่า ไม่มีใครดูข้อมูล แต่เส้นทางพฤติกรรมของนักซื้อ B2B ต่างจาก B2C พวกเขาไม่ได้เดินดูเรื่อยเปื่อย แต่มาพร้อมสเปกที่เจาะจง เช่น “304 stainless flange”, “1000W inverter”, “IP65 enclosure 200×150” ความต้องการที่แม่นยำแบบนี้แทบหาผ่านเมนูหมวดหมู่ไม่ได้ ต้องพึ่งช่องค้นหาเท่านั้น

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

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

สอง การตัดสินใจเลือกเครื่องมือ: เลือกแผนค้นหา 3 ระดับอย่างไร

ข้อผิดพลาดที่ทีมเว็บไซต์ของแบรนด์ทำบ่อยที่สุดคือเริ่มถกกันตั้งแต่แรกว่า “ใช้ Elasticsearch หรือ Algolia” ซึ่งเป็นการเลือกเครื่องมือก่อนวินิจฉัยปัญหา ลำดับที่ถูกต้องคือ: ใช้การวัดผลสองสัปดาห์ทำให้ชัดเจนก่อนว่าอัตราการใช้ค้นหา อัตราผลลัพธ์ว่าง และอัตราคลิกครั้งแรกเป็นอย่างไร แล้วจึงตัดสินใจว่าจะใช้แผนระดับไหน

เกณฑ์ตัดสินตรงไปตรงมา: ถ้าอัตราการใช้งานค้นหาต่ำกว่า 2% ให้ไปปรับ navigation กับเนื้อหาก่อน อย่าเพิ่งอัปเกรด engine; ถ้าอยู่ระหว่าง 2% ถึง 5% ติดตั้ง SearchWP เพื่อทำ synonym และปรับ weight ก็เพียงพอ; ถ้าเกิน 5% และสินค้ามี SKU มากกว่า 500 ค่อยพิจารณา Elasticsearch หรือบริการ search แบบ SaaS การออกแบบระบบค้นหาภาพรวมของแคตตาล็อกสินค้าดูได้ที่ประสบการณ์การค้นหาหน้าสินค้า。

ชั้น	ขนาดที่เหมาะ	เวลาตอบสนอง	ต้นทุนต่อปี	ต้นทุนการดูแล
WP_Query เริ่มต้นของ WP	เว็บบทความล้วน <200 หน้า	1 ถึง 3 วินาที	0 ดอลลาร์	แทบไม่มีเลย
ปลั๊กอิน SearchWP	200 ถึง 5000 หน้ารวมสินค้า	200 ถึง 400 มิลลิวินาที	ประมาณ 199 ดอลลาร์	ต่ออายุรายปี + สร้าง index ใหม่
Elasticsearch ติดตั้งเอง	>5000 หน้า SKU>1000	80 ถึง 150 มิลลิวินาที	เซิร์ฟเวอร์ self-host 30 ถึง 80 ดอลลาร์/เดือน	ต้องมีความสามารถด้าน ops
Algolia/Meilisearch แบบ cloud	ทีมไม่มีทรัพยากรด้าน ops	50 ถึง 120 มิลลิวินาที	99 ถึง 399 ดอลลาร์ต่อเดือน	คิดตามจำนวน document
ค้นหาสินค้า WooCommerce	ร้านอีคอมเมิร์ซขนาดเล็ก	300 ถึง 600 มิลลิวินาที	ประมาณ 99 ดอลลาร์/ปี	ผสานรวมกับ Woo ได้ลึก

สาม、วิธีตั้งค่า SearchWP: weight, synonym และหน้าผลลัพธ์ว่าง

SearchWP คือทางเลือกอัปเกรดระบบค้นหาที่คุ้มค่าที่สุดในระบบนิเวศ WordPress คุณค่าหลักไม่ใช่ “เร็วขึ้น” แต่เป็น “ความเกี่ยวข้องที่ปรับแต่งได้” การค้นหา WP เริ่มต้นเรียงตาม post_date จากใหม่ไปเก่า ส่วน SearchWP ให้คุณตั้ง weight แยกให้ title, เนื้อหา, tag, custom field, หมวดหมู่ และคำอธิบายสั้น ซึ่งสำคัญมากสำหรับเว็บสินค้า เพราะผู้ซื้อค้นหารุ่นสินค้า ไม่ใช่หัวข้อบทความ

ตัวอย่างการตั้งค่าจริง: เว็บสินค้าตั้ง weight ฟิลด์ “รุ่นสินค้า” เป็น 10, “คำอธิบายสั้น” เป็น 5, “เนื้อหา” เป็น 2, “tag” เป็น 3 แบบนี้เมื่อผู้ซื้อพิมพ์ “WF-200” จะตรงกับฟิลด์รุ่นสินค้าทันที ไม่ต้องไปเจอย่อหน้าในบล็อกที่พูดถึง WF-200 ตาราง synonym ควรมีอย่างน้อย 50 กลุ่ม ครอบคลุมคำย่อในอุตสาหกรรม รูปแบบการสะกดที่ต่างกัน และความต่างระหว่างการสะกดแบบอเมริกันกับอังกฤษ (เช่น “aluminum” กับ “aluminium”) วิธีประกอบ tech stack ของ WP ดูได้ที่สแต็กเทคโนโลยี WordPress。

รายการตั้งค่า	ค่าที่แนะนำสำหรับเว็บสินค้า	ค่าที่แนะนำสำหรับเว็บเนื้อหา	สัญญาณที่ควรปรับ
weight ของ title	8	10	ปรับขึ้นเมื่อ CTR ของผลลัพธ์แรก <30%
weight ของเนื้อหา	2	5	ปรับลงเมื่ออัตราผลลัพธ์ว่างสูง
weight ของ custom field	10 (รุ่น/สเปก)	1 (แทบไม่ใช้)	ปรับขึ้นเมื่อค้นหารุ่นสินค้าได้ผลไม่ดี
weight ของ tag	3	4	เพิ่มเมื่อ synonym ครอบคลุมไม่ครบ
weight ของหมวดหมู่	5	2	ปรับลงเมื่อผลลัพธ์กว้างเกินไป
ความยาวคำขั้นต่ำ	2 ตัวอักษร	3 ตัวอักษร	ลดเหลือ 2 เมื่อค้นหารุ่นสั้นไม่เจอ
จับแบบคลุมเครือ	เปิด (edit distance 1)	ปิด	เปิดในตลาดที่พิมพ์ผิดบ่อย

สี่、เมื่อไหร่ที่ต้องใช้ Elasticsearch จริง ๆ และตั้งค่าอย่างไร

Elasticsearch ไม่ใช่คำพ้องของ “การค้นหาขั้นสูง” แต่ถูกออกแบบมาสำหรับการค้นหา full-text ขนาดใหญ่และการ aggregate ที่ซับซ้อน ร้าน standalone ต้องเข้าเงื่อนไขใดเงื่อนไขหนึ่งในสองข้อนี้จึงคุ้มที่จะใช้: ข้อแรก สินค้ามี SKU เกิน 1000 และต้องกรองแบบ facet แบบเรียลไทม์ (กรองตามช่วงราคา ตามวัสดุ ตามการรับรองพร้อมกัน); ข้อสอง จำนวนหน้ารวมเกิน 5000 และเวลาตอบสนองการค้นหาเกิน 500 มิลลิวินาทีแล้ว ถ้าไม่เข้าเงื่อนไขสองข้อนี้ การใช้ Elasticsearch ก็เหมือนเอาปืนใหญ่ยิงยุง

จุดที่พลาดง่ายที่สุดในการตั้งค่าคือการตัดคำภาษาไทยและหลายภาษา ภาษาอังกฤษใช้ standard analyzer ก็เพียงพอ แต่ภาษาจีนต้องติดตั้ง IK tokenizer และตั้งค่าพจนานุกรมกำหนดเอง (ใส่รุ่นสินค้าและคำย่อในอุตสาหกรรมของคุณเข้าไป) ไม่เช่นนั้น “หน้าแปลนสแตนเลส 304” จะถูกตัดเป็นตัวอักษรเดี่ยวๆ ผลการค้นหาจะมั่วไปหมด เว็บหลายภาษาต้องสร้าง index แยกตามภาษาและจับคู่ด้วย hreflang ส่วนนี้ดูได้ที่การติดตั้ง hreflang สำหรับหลายภาษา ส่วน CDN และแคชตั้งค่าอย่างไร ดูที่CDN เร่งความเร็วทั่วโลก。

สถานการณ์	推荐方案	การตั้งค่าสำคัญ	ผลลัพธ์ที่คาดหวัง
บล็อก 500 หน้า	SearchWP เวอร์ชันฟรี	น้ำหนักหัวข้อ 10 เนื้อหา 5	อัตราผลลัพธ์ว่างลดจาก 25% เหลือ 8%
เว็บสินค้า 3000 หน้า	SearchWP Pro	ฟิลด์รุ่นน้ำหนัก 10 + ตารางคำพ้อง	อัตราการแปลงหลังค้นหา +15%
เว็บอีคอมเมิร์ซ 2000 SKU	Elasticsearch ภายในเครื่อง + ปลั๊กอิน WP	IK tokenizer + การรวมกลุ่มแบบ facet	ตอบสนอง <150ms
เว็บ B2B หลายภาษา	Elasticsearch หลาย index	แยก index ตามภาษา + คำพ้อง	อัตราผลลัพธ์ว่างแต่ละภาษา <10%
ทีมไม่มีฝ่ายดูแลระบบ	Algolia/Meilisearch แบบ cloud	ใช้ปลั๊กอิน WordPress อย่างเป็นทางการ	ไม่ต้องดูแลระบบ จ่ายตามจำนวนเอกสาร

ห้า อัตราผลลัพธ์ว่างเป็นตัวชี้วัดที่สำคัญกว่าอันดับ

หลายทีมจับจ้องที่ “ผลการค้นหาอยู่อันดับที่เท่าไร” แต่ตัวชี้วัดที่ฆ่าคนจริงๆ ของการค้นหา B2B คืออัตราผลลัพธ์ว่าง เมื่อผู้ใช้พิมพ์คำค้นแล้วไม่มีผลลัพธ์ใดๆ สิ่งที่ผู้เข้าชมทำต่อไปไม่ใช่การเลื่อนหน้า แต่คือการปิดเบราว์เซอร์ ประสบการณ์ในวงการบอกว่า อัตราผลลัพธ์ว่างสูงกว่า 20% แสดงว่าคำค้นกับโครงสร้างเนื้อหาไม่ตรงกัน สูงกว่า 35% แสดงว่าฟังก์ชันค้นหาแทบใช้ไม่ได้แล้ว

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

ตัวชี้วัด	ช่วงสุขภาพดี	เกณฑ์แจ้งเตือน	การดำเนินการ
อัตราการใช้การค้นหา (สัดส่วนเซสชันที่ค้นหา)	5% ถึง 15%	ต่ำกว่า 2% ติดต่อกัน 4 สัปดาห์	ปรับปรุงการนำทางและความเด่นชัดของทางเข้าค้นหา
อัตราผลลัพธ์เป็นศูนย์	ต่ำกว่า 10%	สูงกว่า 20%	ส่งออกคำที่ให้ผลลัพธ์ว่างบ่อย เพิ่มเนื้อหาหรือปรับน้ำหนัก
อัตราคลิกแรก	สูงกว่า 40%	ต่ำกว่า 25%	ความเกี่ยวข้องของการจัดอันดับมีปัญหา ปรับน้ำหนัก
อัตราการแปลงหลังการค้นหา	สูงกว่าการเรียกดูปกติ 2 ถึง 3 เท่า	เท่ากับการเรียกดู	หน้าผลลัพธ์ขาดตัวกรองและ CTA
เวลาตอบสนองการค้นหา	ต่ำกว่า 300 มิลลิวินาที	สูงกว่า 800 มิลลิวินาที	เพิ่มแคชหรืออัปเกรดเอนจิน

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

เว็บไซต์อิสระจำเป็นต้องใช้ Elasticsearch หรือไม่

ไม่จำเป็น ต้องเข้าเงื่อนไขข้อใดข้อหนึ่งจึงคุ้มค่า คือ SKU เกิน 1000 และต้องการกรองแบบ facet แบบเรียลไทม์ หรือหน้าเว็บเกิน 5000 และเวลาตอบสนองการค้นหาเกิน 500 มิลลิวินาทีแล้ว นอกนั้น SearchWP (ประมาณ 199 ดอลลาร์/ปี) เพียงพอ เว็บ B2B อิสระส่วนใหญ่มี SKU ไม่เกิน 500 การใช้ Elasticsearch ถือเป็น overengineering ต้องจ่ายค่าเซิร์ฟเวอร์และดูแลระบบปีละ 300 ถึง 1000 ดอลลาร์ แต่ประสบการณ์ที่ได้กลับมาแทบไม่รู้สึก

จะตัดสินได้อย่างไรว่าการค้นหาในเว็บควรปรับปรุงหรือไม่

เริ่มจากติดตั้ง GA4 หรือ SearchWP แล้วเก็บข้อมูลหลังบ้านสองสัปดาห์ ดูตัวเลขสามตัว: อัตราการใช้ค้นหา, อัตราผลลัพธ์เป็นศูนย์ และอัตราคลิกครั้งแรก ถ้าอัตราการใช้ค้นหาต่ำกว่า 2% แปลว่าเมนูนำทางสำคัญกว่าการค้นหา อย่าเพิ่งไปยุ่งกับการค้นหา ถ้าอัตราการใช้อยู่ที่ 2% ถึง 5% และอัตราผลลัพธ์เป็นศูนย์สูงกว่า 15% ให้ติดตั้ง SearchWP แล้วปรับน้ำหนัก ถ้าอัตราการใช้สูงกว่า 5% และอัตราผลลัพธ์เป็นศูนย์ยังสูงกว่า 20% ค่อยพิจารณาอัปเกรดเอนจิน

SearchWP ต่างจากค้นหาเริ่มต้นของ WP ตรงไหน?

ค่าเริ่มต้นของ WP ใช้แค่ WP_Query เรียงตาม post_date จากใหม่ไปเก่า ค้นหาแค่หัวข้อกับเนื้อหา ไม่รองรับ custom field คำพ้อง หรือการจับคู่แบบคลุมเครือ ส่วน SearchWP กำหนดน้ำหนักให้หัวข้อ เนื้อหา custom field และแท็กแยกกันได้ รองรับตารางคำพ้องและการจับคู่แบบคลุมเครือ ดัชนีเก็บในตารางของตัวเองจึงค้นหาได้เร็วกว่า สิ่งที่มีค่าที่สุดสำหรับเว็บสินค้าคือปรับน้ำหนักฟิลด์รุ่นสินค้าเป็น 10 ให้ผู้ซื้อค้นหารุ่นแล้วเจอทันที

ทำไมการค้นหาภาษาจีนใน Elasticsearch ได้ผลลัพธ์แย่มาก?

analyzer มาตรฐานค่าเริ่มต้นจะตัดคำภาษาจีนทีละตัวอักษร คำว่า “หน้าแปลนสแตนเลส 304” จะถูกตัดแยกเป็นตัวอักษรเดี่ยว ๆ ทำให้การค้นคืนผิดเพี้ยนไปหมด ต้องติดตั้ง IK tokenizer และเพิ่มรุ่นสินค้า คำย่อเฉพาะอุตสาหกรรม และคำแบรนด์ของคุณเข้าไปในพจนานุกรมกำหนดเอง เลือก tokenizer ผิดอันตรายกว่าเลือก search engine ผิด เพราะผลลัพธ์ดูเหมือน “มีเนื้อหา” แต่ความเกี่ยวข้องผิดทั้งหมด

อัตราผลลัพธ์เป็นศูนย์สูงทำอย่างไร จัดการเป็นชุดได้ไหม?

ส่งออก query ที่ให้ผลลัพธ์เป็นศูนย์ทั้งหมดในสองสัปดาห์ เรียงตามความถี่ เอาคำที่พบบ่อย 20 อันดับแรกมาพิจารณาทีละคำ: ถ้าไม่มีเนื้อหาให้เพิ่ม landing page หรือหน้าสินค้าหนึ่งหน้า ถ้ามีเนื้อหาแต่ค้นไม่เจอให้ปรับน้ำหนักดัชนีหรือเพิ่มคำพ้อง โดยทั่วไปจัดการได้ 70% ของผลลัพธ์เป็นศูนย์ ที่เหลือเป็นคำหางยาวไม่ต้องจัดการทีละคำ ใช้หน้าผลลัพธ์เป็นศูนย์วางฟอร์ม “ไม่พบสิ่งที่ค้นหา ส่งคำถาม” เป็นตัวสำรอง

Algolia กับสร้าง Elasticsearch เอง เลือกอันไหน?

ถ้าทีมไม่มีคนดูแลระบบโดยเฉพาะให้เลือก Algolia ค่าบริการรายเดือน 99 ถึง 399 ดอลลาร์ คิดตามจำนวนเอกสาร เชื่อมต่อปลั๊กอิน WordPress ได้ใน 5 นาที เว็บที่มี UV ต่อวันต่ำกว่า 10000 ค่า Algolia โดยทั่วไปอยู่ที่ 100 ถึง 200 ดอลลาร์ต่อเดือน ถูกกว่าสร้างเองแล้วเพิ่มคนดูแลระบบอีกหนึ่งคนมาก ถ้า UV ต่อวันเกิน 5 หมื่น หรือต้องปรับแต่งตรรกะการค้นหาเชิงลึก ค่อยพิจารณาสร้าง Elasticsearch เอง ค่าเซิร์ฟเวอร์ 30 ถึง 80 ดอลลาร์ต่อเดือน แต่ต้องมีคนดูแลระยะยาว

ทิ้งท้าย

站内搜索是独立站里投入产出比最被低估的模块。它不需要大动干戈，先做两周埋点，再用零结果率和搜索使用率两个数字决定升级层级，大多数站停在SearchWP这一层就够了。Elasticsearch不是必选项，是规模到了之后的自然选择，不是搜索体验的起点。

เริ่มใช้ 3 ขั้นตอน: หนึ่ง ภายในสัปดาห์นี้ติดตั้ง GA4 event tracking ที่ช่องค้นหา เพื่อบันทึก query, การคลิก และจำนวนผลลัพธ์ สอง หลังจากสองสัปดาห์ส่งออกตารางคำที่ค้นแล้วไม่เจอผลลัพธ์ แล้วจัดการ 20 คำที่ค้นบ่อยที่สุด สาม ดูอัตราการใช้งานค้นหาแล้วตัดสินใจว่าจะติด SearchWP หรือไม่ ถ้าติดก็ปรับ weight หนึ่งครั้ง แล้วรันหนึ่งเดือนดูว่าอัตราคลิกผลลัพธ์แรกเพิ่มจาก 25% เป็น 40% ขึ้นไปหรือไม่

ประโยคเดียวที่จำได้: อัตราการใช้งานค้นหาต่ำไม่ได้แปลว่าไม่ต้องมีระบบค้นหา แต่แปลว่าระบบค้นหาแย่จนไม่มีใครกล้าใช้ เริ่มจากติด tracking เพื่อวินิจฉัยก่อน แล้วค่อยเลือก engine