เว็บไซต์ไม่ค่อยพังแบบโจ่งแจ้งในวันเปิดตัว แต่มักพังแบบเงียบ ๆ เช่น ฟอร์มติดต่อที่ยังส่งอีเมลไปกล่องทดสอบของนักพัฒนา ค่า “noindex” ที่ลืมปิดไว้จาก staging หรือแท็ก analytics ที่นับการเข้าชมทุกครั้งเป็นสองเท่า เว็บไซต์ดูเสร็จแล้ว จึงไม่มีใครสังเกตไปหลายสัปดาห์ เช็กลิสต์เปิดตัวเว็บไซต์ คือวิธีจับปัญหาเหล่านั้นให้ได้ก่อน
เช็กลิสต์นี้จัดกลุ่มการตรวจตามคนที่ควรเป็นผู้ตรวจ แล้ววางลำดับงานในวันเปิดตัว และสิ่งที่ต้องเฝ้าดูในสัปดาห์แรก โดยสมมติว่าเว็บไซต์ถูกสร้างบน staging ซึ่งเป็นสำเนาส่วนตัวที่ใช้ทดสอบ คู่มือกระบวนการพัฒนาเว็บไซต์ ของเราอธิบายว่าขั้นนี้อยู่ตรงไหน
วิธีใช้เช็กลิสต์เปิดตัวเว็บไซต์นี้
ปัญหาตอนเปิดตัวส่วนใหญ่ มาจากสิ่งที่เปลี่ยนในวันเปิดตัว ทั้งโดเมน เซิร์ฟเวอร์ที่มักเปลี่ยนไปด้วย ใบรับรอง วิธีส่งอีเมล และการแคช ฟอร์มที่ทำงานได้บน staging อาจใช้ไม่ได้บนโดเมนจริง ด้วยเหตุผลที่ไม่เกี่ยวกับตัวฟอร์มเลย
ดังนั้นใช้เช็กลิสต์นี้ทั้งก่อนเปิดตัว และตอนขึ้นระบบ รันการตรวจแต่ละข้อบน staging แก้สิ่งที่เจอ แล้วตรวจซ้ำบนเว็บไซต์จริง ภายในหนึ่งชั่วโมงหลังสลับระบบ
คนหนึ่งคนอาจรับหลายบทบาท แต่ทุกแถวต้องมีชื่อคนรับผิดชอบ
การตรวจของนักพัฒนา
การบล็อกเครื่องมือค้นหาและรหัสผ่าน staging
staging มักถูกซ่อนจาก Google ไว้หลายวิธี ทุกวิธีต้องถูกเอาออก
ถ้าชื่อโฮสต์ของ staging ยังโผล่อยู่ที่ไหนในซอร์สของหน้า ให้ค้นหาและแทนที่ในฐานข้อมูล ด้วยเครื่องมือที่รองรับวิธีที่ WordPress เก็บการตั้งค่า การบล็อกที่หลงเหลืออยู่ เป็นสาเหตุที่พบบ่อยที่ทำให้ เว็บไซต์ใหม่ไม่ขึ้นบน Google
HTTPS และ mixed content
ใบรับรองควรครอบคลุมโดเมนทุกเวอร์ชัน ทั้งแบบมีและไม่มี “www” และต่ออายุอัตโนมัติ ทุกเวอร์ชันควรไปถึงที่อยู่ HTTPS ที่เลือกไว้เพียงที่เดียว โดยดีที่สุดคือใน redirect ครั้งเดียว
จากนั้นมองหา mixed content คือหน้าที่ปลอดภัย แต่โหลดรูป สคริปต์ หรือฟอนต์ผ่าน HTTP ธรรมดา ซึ่งมักมาจากที่อยู่ที่เขียนตายตัวไว้ระหว่างสร้าง เบราว์เซอร์จะบล็อกสคริปต์และฟอนต์ที่ไม่ปลอดภัย และอัปเกรดหรือบล็อกรูปที่ไม่ปลอดภัย ผลที่เจอจึงมีตั้งแต่รูปหายไป จนถึงเมนูพัง console ของเบราว์เซอร์จะแจ้งทุกกรณี ให้ตรวจในทุกเทมเพลตของหน้า
redirect จาก URL เดิม
ในการรีดีไซน์ ทุกหน้าที่มีอยู่วันนี้ ต้องมีที่ไปในวันพรุ่งนี้ สร้างรายการจากการครอว์ลเว็บไซต์เดิมทั้งหมด รวมกับหน้าที่ Search Console แสดงว่าได้คลิก หรือได้ลิงก์จากเว็บไซต์อื่น ใช้ redirect แบบถาวร (301) แบบทอดเดียว ไปยังหน้าใหม่ที่ใกล้เคียงที่สุดของแต่ละหน้า แทนที่จะส่งไปหน้าแรก รวม PDF เก่าและทุกเวอร์ชันภาษาด้วย
หลังเปิดตัว ให้ทดสอบทั้งรายการบนเว็บไซต์จริง เช็กลิสต์ SEO สำหรับการย้ายเว็บไซต์ ครอบคลุมฝั่งอันดับ ถ้าคุณเปลี่ยนบริษัทโฮสติ้งด้วย บทความ ย้ายไปโฮสต์ใหม่ ของเราอธิบายเรื่อง DNS และอีเมล ซึ่งเป็นจุดที่การย้ายเซิร์ฟเวอร์มักผิดพลาด
หน้า 404
พิมพ์ที่อยู่มั่ว ๆ บนโดเมนของคุณ คุณควรเจอหน้าที่มีประโยชน์ ในภาษาที่ถูกต้อง พร้อมลิงก์ไปยังส่วนหลักและข้อมูลติดต่อ รหัสสถานะของหน้านั้น ซึ่งดูได้ในแท็บ Network ของเครื่องมือนักพัฒนา ต้องเป็น 404 หน้า “ไม่พบ” ที่ส่ง 200 จะบอกเครื่องมือค้นหาว่าหน้านั้นมีอยู่ และ Search Console จะรายงานหน้าแบบนั้นเป็นข้อผิดพลาด “soft 404”
ความเร็ว
รัน PageSpeed Insights กับหน้าแรก หน้าบริการสำคัญ และหน้าที่หนักที่สุด โดยดูผลบนมือถือก่อน ข้อมูลผู้เข้าชมจริง (จาก Chrome UX Report) ครอบคลุม 28 วันที่ผ่านมา เว็บไซต์ใหม่เอี่ยมจึงยังไม่มีข้อมูล และเว็บไซต์ที่รีดีไซน์ จะแสดงข้อมูลของเว็บไซต์เดิมเป็นส่วนใหญ่ ไปอีกหลายสัปดาห์ ระหว่างนั้นให้ถือผลจากแล็บเป็นสัญญาณเตือนล่วงหน้า ไม่ใช่คำตัดสิน
ยืนยันว่าเปิดการตั้งค่าสำหรับใช้งานจริงแล้ว (การแคชหน้า การบีบอัดรูป และ CDN ถ้ามี) และปิดเครื่องมือที่ใช้เฉพาะบน staging แล้ว เช่น ปลั๊กอินดีบัก บทความ วิธีอ่านรายงาน PageSpeed Insights อธิบายว่าตัวเลขไหนสำคัญ
การสำรองข้อมูล การเฝ้าระวัง และความปลอดภัย
เมื่อเว็บไซต์ใหม่ขึ้นระบบแล้ว ให้ยืนยันว่า
การตรวจเหล่านี้ยังเป็นจุดเริ่มต้นของ เช็กลิสต์การดูแลเว็บไซต์ ของคุณ เพราะวันเปิดตัวคือวันที่การดูแลเว็บไซต์เริ่มต้น
การเชื่อมต่อระบบ
CRM ปฏิทินการจอง เครื่องมืออีเมล และผู้ให้บริการชำระเงิน มักถูกเชื่อมต่อในโหมดทดสอบระหว่างสร้าง ตอนเปิดตัว ให้ยืนยันว่า API key ของระบบจริงมาแทน key ทดสอบแล้ว webhook ชี้ไปที่โดเมนจริง และบริการที่รับเฉพาะโดเมนที่อนุมัติ เช่น Google reCAPTCHA มีโดเมนนี้อยู่ในรายการ
ส่งข้อมูลทดสอบหนึ่งรายการตั้งแต่ต้นจนจบ แล้วขอให้คนที่ใช้ระบบนั้นทุกวันตรวจดู เขาจะเห็นช่องที่หายไป หรือลีดที่ถูกส่งผิดที่ ได้เร็วกว่านักพัฒนาคนไหน บทความ การเชื่อมต่อระบบกับเว็บไซต์ ของเราอธิบายว่า ทำไมการเชื่อมต่อเหล่านี้มักล้มเหลวแบบเงียบ ๆ
การตรวจของฝ่ายการตลาด
analytics และความยินยอม
เปิดรายงาน Realtime ใน Google Analytics 4 แล้วท่องเว็บไซต์จริง ตรวจว่า
ในที่ที่ต้องขอความยินยอม ให้กดปฏิเสธบนแบนเนอร์ แล้วดูในเครื่องมือนักพัฒนาของเบราว์เซอร์ (Application → Cookies ใน Chrome) ต้องไม่มีคุกกี้ analytics หรือโฆษณาปรากฏ จนกว่าคุณจะกดยอมรับ นโยบายความเป็นส่วนตัวควรระบุเครื่องมือ ที่เว็บไซต์ใหม่ใช้จริง บทความ การติดตามการติดต่อสอบถามใน GA4 อธิบายการตั้งค่าอีเวนต์ทีละขั้น
ภาพตัวอย่างบนโซเชียล
ภาพตัวอย่างลิงก์บน LinkedIn, Facebook และแอปแชท มาจากแท็ก Open Graph ได้แก่ og:title og:description และ og:image หน้าสำคัญทุกหน้าต้องมีของตัวเอง พร้อมภาพสำหรับแชร์ (ขนาด 1200 × 630 พิกเซลเป็นตัวเลือกที่ใช้กันทั่วไป) ที่วางข้อความสำคัญให้ห่างจากขอบ เพราะบางแพลตฟอร์มครอปภาพ วาง URL จริงลงใน Sharing Debugger ของ Meta และ Post Inspector ของ LinkedIn เพื่อดูภาพตัวอย่าง และรีเฟรชข้อมูลเก่าที่ค้างอยู่
ทดสอบหลายเบราว์เซอร์และหลายอุปกรณ์
analytics ของคุณแสดงว่า ผู้เข้าชมใช้เบราว์เซอร์และอุปกรณ์อะไร สำหรับเว็บไซต์ธุรกิจส่วนใหญ่ หมายถึง Chrome, Safari, Edge และ Firefox บนคอมพิวเตอร์ รวมถึง iPhone และมือถือ Android เครื่องจริง บนอินเทอร์เน็ตมือถือ ในแต่ละเครื่อง ตรวจว่า
- เมนูเปิด ปิด และเลื่อนได้
- ฟอร์มใช้งานได้ขณะแป้นพิมพ์บนจอเปิดอยู่ รวมถึงตัวเลือกวันที่และการอัปโหลดไฟล์
- ไม่มีอะไรเลื่อนออกด้านข้าง และ header ที่ติดขอบจอหรือปุ่มแชท ไม่บังเนื้อหา
- การสลับภาษาพาคุณไปยังหน้าที่เทียบเท่ากัน
จากนั้นขอให้เพื่อนร่วมงานสองคน ที่ยังไม่เคยเห็นเว็บไซต์ ลองหาบริการหนึ่งอย่างแล้วติดต่อเข้ามา และสังเกตว่าพวกเขาลังเลตรงไหน
พื้นฐานการเข้าถึง
การตรวจสั้น ๆ เหล่านี้จับอุปสรรคที่พบบ่อยได้หลายอย่าง
เครื่องมือตรวจอัตโนมัติอย่าง Lighthouse และ WAVE ช่วยได้ แต่จับได้แค่บางส่วน คู่มือ web accessibility ครอบคลุมส่วนที่เหลือ
การตรวจของเจ้าของและทีมขาย
ฟอร์มและการแจ้งเตือน
ฟอร์มคือจุดที่ปัญหาตอนเปิดตัว สร้างความเสียหายมากที่สุด เพราะฟอร์มที่พัง ดูเหมือนสัปดาห์ที่เงียบเหงาไม่มีผิด คนที่รับการติดต่อสอบถาม ควรส่งทุกฟอร์มในทุกภาษา ทั้งจากมือถือและแล็ปท็อป แล้วยืนยันว่า
ถ้าการแจ้งเตือนไปตกอยู่ในกล่องสแปมหรือไม่มาถึงเลย สาเหตุมักอยู่ที่วิธีที่เว็บไซต์ส่งอีเมล โดยค่าเริ่มต้น WordPress ส่งอีเมลจากเว็บเซิร์ฟเวอร์ผ่านฟังก์ชัน mail ของ PHP และผู้ให้บริการอีเมลหลายรายไม่ไว้ใจข้อความแบบนั้น การส่งผ่านบริการอีเมลที่ยืนยันตัวตนแล้ว พร้อมตั้งค่าเรคคอร์ด SPF, DKIM และ DMARC ให้โดเมนของคุณ แก้ปัญหาได้เกือบทุกกรณี ด้านการออกแบบ ดู การออกแบบฟอร์มบนเว็บไซต์
บัญชี จังหวะเวลา และทางถอยกลับ
ก่อนใครจะกดสวิตช์ เจ้าของธุรกิจควรยืนยันว่า
- บัญชีต่าง ๆ โดเมน DNS โฮสติ้ง analytics และ Search Console อยู่ในชื่อบริษัท และคุณมีบัญชีผู้ดูแลระบบของตัวเอง
- การอนุมัติเนื้อหา ราคา เบอร์โทรศัพท์ ที่อยู่ และหน้าข้อกฎหมาย ผ่านการอ่านโดยคนที่รู้ทันทีถ้าข้อมูลผิด
- จังหวะเวลา ทั้งคนสร้างเว็บไซต์และคนรับการติดต่อสอบถาม ว่างตลอดวันเปิดตัวที่เหลือ และไม่ใช่วันก่อนวันหยุดหรือก่อนเริ่มแคมเปญ
- ทางถอยกลับ เว็บไซต์เดิมและไฟล์สำรองของมันยังพร้อมใช้ เพื่อให้ชี้โดเมนกลับไปได้ ถ้ามีอะไรร้ายแรงพัง
วันเปิดตัว ตามลำดับ
เช็กลิสต์วันเปิดตัวส่วนใหญ่เป็นเรื่องของลำดับ ลำดับนี้ทำให้ช่วงเวลาที่เสี่ยงสั้นที่สุด
- หยุดแก้ไขเนื้อหาบนเว็บไซต์เดิม เพื่อไม่ให้สิ่งที่เพิ่มในวันนั้นหายไป
- สำรองข้อมูลเว็บไซต์เดิมทั้งหมด แล้วดาวน์โหลดเก็บไว้
- อัปเดตเรคคอร์ด DNS ให้ชี้โดเมนไปที่เซิร์ฟเวอร์ใหม่ ค่า TTL (ระยะเวลาที่เครือข่ายอื่นอาจใช้ที่อยู่เดิมต่อไป) ควรถูกลดลงไว้ล่วงหน้าหนึ่งหรือสองวัน เพื่อให้การเปลี่ยนแปลงกระจายได้เร็ว อย่าแตะเรคคอร์ดอีเมล (MX) ถ้าย้ายผู้ให้บริการ DNS ให้คัดลอกเรคคอร์ดเหล่านั้นไปก่อน
- เอาการป้องกันของ staging ออก และยืนยัน HTTPS ในโดเมนทุกเวอร์ชัน
- ส่งทุกฟอร์ม ทดสอบรายการ redirect และตรวจ GA4 Realtime
- ตรวจว่า Google Search Console ยังแสดงว่าเว็บไซต์ได้รับการยืนยันอยู่ (ไฟล์หรือแท็กยืนยันบนเว็บไซต์เดิม อาจไม่ได้ย้ายมาด้วย) แล้วส่ง XML sitemap
- บอกทีมของคุณว่าเว็บไซต์ขึ้นระบบแล้ว และให้มีที่เดียวสำหรับแจ้งปัญหา
สัปดาห์แรกหลังเปิดตัว
ปัญหาบางอย่างจะปรากฏ ก็ต่อเมื่อผู้เข้าชมจริงและเครื่องมือค้นหามาถึง ให้เฝ้าดูสี่เรื่อง
- การ index ในวันแรก ให้ใช้ URL Inspection ของ Search Console กับหน้าสำคัญ ปุ่ม “Test live URL” ควรยืนยันว่าแต่ละหน้า index ได้ ขอให้ index หน้าที่สำคัญที่สุด แล้วเฝ้าดูรายงาน Page indexing ซึ่งจะช้ากว่าความจริงไม่กี่วัน
- การติดต่อสอบถาม เทียบกับสัปดาห์ปกติ ถ้าลดลงเหลือศูนย์ ให้ทดสอบฟอร์มใหม่ ก่อนจะสรุปว่าตลาดเงียบ
- หน้าที่หายไป มองหา 404 ใน Search Console ใน analytics และในทุกอย่างที่ลูกค้าพูดถึง แต่ละอันคือ redirect ที่ขาดไป หรือลิงก์ที่เสีย
- การติดตามและการสำรองข้อมูล key event ใน GA4 ควรใกล้เคียงกับการติดต่อสอบถามที่ทีมของคุณได้รับ และการสำรองข้อมูลตามกำหนดครั้งแรก ควรทำงานไปแล้ว
หลังจากนั้น การเปิดตัวจะเปลี่ยนเป็นการปรับปรุง คือทบทวนให้ละเอียดขึ้นด้วย เช็กลิสต์ technical SEO เมื่อ Google ประมวลผลเว็บไซต์ใหม่แล้ว และมี แผนพัฒนาอย่างต่อเนื่อง สำหรับ 90 วันแรก
ก่อนกำหนดวันเปิดตัว
คัดลอกตารางข้างบนไปไว้ในแผนโปรเจกต์ ใส่ชื่อคนรับผิดชอบในทุกแถว และอย่ากำหนดวันเปิดตัว จนกว่าทุกการตรวจจะผ่านบน staging
เว็บไซต์ขึ้นระบบไปแล้ว และไม่แน่ใจว่าเคยตรวจสิ่งเหล่านี้หรือเปล่า? ตรวจสอบเว็บไซต์ฟรี จะดูหลายข้อในนี้จากภายนอก รวมถึงการ index ความเร็ว HTTPS และเส้นทางสู่การติดต่อสอบถาม และเราจะส่งผลการตรวจเป็นลายลักษณ์อักษร ภายในสองวันทำการ
กำลังวางแผนรีดีไซน์? โปรเจกต์ รีดีไซน์เว็บไซต์ ของเรา ทำ redirect ให้ทุก URL เดิม และเปิดตัวโดยไม่ต้องปิดเว็บไซต์ และ แผนดูแลเว็บไซต์ ของเรา ดูแลการสำรองข้อมูล การอัปเดต และการเฝ้าระวังต่อไปหลังจากนั้น