การกำกับดูแลเว็บไซต์: ควบคุมเว็บไซต์ขนาดใหญ่ที่หลายทีมช่วยกันดูแล

เว็บไซต์ขนาดใหญ่ ไม่ค่อยพังเพราะการตัดสินใจผิดครั้งเดียว มันค่อย ๆ ไหลออกนอกทาง แผนกหนึ่งเผยแพร่หน้าแคมเปญ ที่ไม่มีใครรู้ ราคาเปลี่ยนในภาษาหนึ่ง แต่ไม่เปลี่ยนในภาษาอื่น การอัปเดตปลั๊กอินวันศุกร์ ทำให้แบบฟอร์มติดต่อสอบถามหยุดทำงาน และไม่มีใครรู้ว่าใครอนุมัติ ไม่นาน เว็บไซต์ก็มีหลายร้อยหน้า บัญชีผู้ใช้หลายสิบบัญชี และไม่มีคำตอบให้คำถามง่าย ๆ ว่า ใครเป็นคนตัดสิน? การกำกับดูแลเว็บไซต์ (website governance) ตอบคำถามนี้ครั้งเดียว ไม่ต้องตอบใหม่ในทุกการประชุม

คู่มือนี้สำหรับทีมภายในองค์กร ที่ดูแลเว็บไซต์ซึ่งมีหลายหน้า หลายคนแก้ไข หลายแผนก หรือหลายภาษา และสิ่งที่แนะนำส่วนใหญ่ ใช้แค่สเปรดชีตหนึ่งไฟล์ กับเอกสารสั้น ๆ ไม่กี่ฉบับ

การกำกับดูแลเว็บไซต์ครอบคลุมอะไร

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

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

สัญญาณว่าเว็บไซต์โตเกินกฎแบบไม่เป็นทางการ

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

ถ้าติ๊กสองข้อขึ้นไป มักแปลว่าถึงเวลาเขียนกฎไว้เป็นลายลักษณ์อักษรแล้ว

กำหนดว่าใครเป็นเจ้าของอะไร

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

ความเป็นเจ้าของ 3 ระดับ

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

ตัวอย่างที่นำไปปรับใช้ได้:

เปลี่ยนรายการคอนเทนต์ให้เป็นทะเบียนความเป็นเจ้าของ

ส่งออกทุก URL จาก XML sitemap หรือเครื่องมือ crawl ลงสเปรดชีต พร้อมคอลัมน์เจ้าของ วันที่ตรวจล่าสุด วันตรวจครั้งถัดไป และสถานะ (เก็บไว้ อัปเดต รวม หรือลบ) ทะเบียนนี้ คือแกนหลักของการบริหารเว็บไซต์ขนาดใหญ่ ทำให้เห็นในแวบเดียวว่า หน้าไหนไม่มีเจ้าของ การตรวจไหนเลยกำหนด และหน้าไหนซ้ำกัน

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

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

บทบาทและสิทธิ์ผู้ใช้ใน CMS

คู่มือ แนวปฏิบัติที่ดีของ WordPress ของเรา อธิบายบทบาทมาตรฐานไว้ บนเว็บไซต์ขนาดใหญ่ คำถามที่ยากกว่า คือการให้คนจำนวนมาก ได้สิทธิ์ตรงกับที่งานต้องใช้พอดี

จับคู่หน้าที่งานกับบทบาท ไม่ใช่กับตัวบุคคล

กำหนดบทบาทครั้งเดียวตามหน้าที่งาน แล้วกำหนดคนเข้าบทบาทนั้น ตัวอย่างการจับคู่ใน WordPress ทั่วไป:

เมื่อบทบาทมาตรฐานของ WordPress ไม่พอ

ใน WordPress แบบค่าเริ่มต้น บทบาท Author และ Contributor ทำงานกับโพสต์ได้ แต่ทำงานกับหน้า (page) ไม่ได้ การแก้ไขหน้า ต้องมีบทบาทอย่างน้อย Editor และ Editor แก้ได้ทุกหน้าบนเว็บไซต์ รวมถึงหน้าแรก และคอนเทนต์ของแผนกอื่น

สามวิธีที่ใช้กันบ่อย ในการปิดช่องว่างนี้:

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

เริ่มจากทางเลือกที่ง่ายที่สุด เพราะทุกบทบาทที่กำหนดเอง ต้องถูกดูแล ทดสอบหลังการอัปเดต และอธิบายให้พนักงานใหม่เข้าใจ

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

ขั้นตอนอนุมัติคอนเทนต์ที่คนยอมทำตาม

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

ให้การอนุมัติเหมาะกับระดับความเสี่ยง

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

สิ่งที่ WordPress มีให้ตั้งแต่ติดตั้ง

WordPress core มีขั้นตอนการทำงานแบบเบา ๆ ใครก็ตามที่แก้ไขคอนเทนต์ได้ แต่เผยแพร่ไม่ได้ ส่งคอนเทนต์นั้นให้ตรวจได้ โดยตั้งสถานะเป็น Pending Review ผู้ที่มีบทบาท Editor กรองตามสถานะนั้น แล้วเผยแพร่ หรือตั้งเวลาเผยแพร่ และยังเปรียบเทียบหรือกู้คืน revision ได้ core ไม่ส่งการแจ้งเตือน เมื่อมีอะไรรออยู่ จึงต้องตกลงกันว่า Editor จะเช็กรายการ Pending เมื่อไร สำหรับหลายองค์กร เท่านี้บวกกฎที่เขียนไว้ชัดเจน ก็เพียงพอแล้ว

ปลั๊กอินขั้นตอนการทำงานด้านบรรณาธิการ เพิ่มการอนุมัติหลายขั้น และการแจ้งเตือนผู้ตรวจ ตรวจให้แน่ใจว่าตัวที่เลือก ยังได้รับการดูแล และเข้ากันได้กับ page builder และระบบหลายภาษาของคุณ ไม่ว่าแบบไหน ให้การตรวจและอนุมัติ อยู่ใน CMS หรือบน staging ไม่ใช่ในอีเมล เพื่อให้คำถาม “ใครอนุมัติเรื่องนี้?” ยังมีคำตอบ ในอีกหลายเดือนต่อมา

เทมเพลตและคอมโพเนนต์: คุมโครงสร้าง ปล่อยคอนเทนต์ให้อิสระ

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

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

การบริหารเว็บไซต์หลายภาษา

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

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

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

การควบคุมการเปลี่ยนแปลง: staging การปล่อยงาน และบันทึกการปล่อยงาน

คอนเทนต์ไหลลง โค้ดไหลขึ้น

บน WordPress คอนเทนต์ การตั้งค่า และเทมเพลตของ page builder ใช้ฐานข้อมูลเดียวกัน การคัดลอกเว็บไซต์ staging ทับเว็บไซต์จริง จึงอาจลบทุกการแก้ไข ที่ทำไปตั้งแต่ตอนที่คัดลอกมา รูปแบบที่ปลอดภัยคือ:

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

โค้ดที่เขียนเอง ควรอยู่ใน version control เพื่อให้ทุกการเปลี่ยนแปลง ถูกบันทึกและย้อนกลับได้ คู่มือการพัฒนาเว็บไซต์ แสดงว่าเรื่องนี้ เข้ากับการพัฒนาที่ถูกต้องอย่างไร

ปล่อยงานเป็นรอบ พร้อมบันทึกทุกครั้ง

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

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

แชร์บันทึกนี้ให้เจ้าของส่วนต่าง ๆ ซึ่งมักเป็นคนแรกที่เห็นปัญหา

เว็บไซต์เดียว เครือข่าย multisite หรือแยกเว็บไซต์?

WordPress multisite รันเครือข่ายเว็บไซต์ จากการติดตั้งครั้งเดียว ใช้โค้ด ธีม และปลั๊กอินร่วมกัน แต่คอนเทนต์แยกกันในแต่ละเว็บไซต์ และมี Super Admin ที่ควบคุมทั้งเครือข่าย

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

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

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

เอกสารกำกับดูแลที่ควรเขียนไว้

เขียนแต่ละฉบับให้สั้น เก็บไว้ในที่ที่คนแก้ไขคอนเทนต์ทำงาน และให้แต่ละฉบับมีเจ้าของ:

1. ทะเบียนความเป็นเจ้าของ หน้า เจ้าของ และวันตรวจ
2. นโยบายบทบาทและสิทธิ์การเข้าถึง บทบาท ใครอนุมัติบัญชี และวิธีลบบัญชีของคนที่ลาออก
3. กฎการเผยแพร่ ระดับการอนุมัติ ผู้แทน และเส้นทางฉุกเฉิน
4. แคตตาล็อกเทมเพลต ประเภทหน้า และวิธีขอเทมเพลตใหม่
5. กฎการแปล ผู้ดูแลแต่ละภาษา และอะไรที่ต้องตรงกัน
6. กระบวนการปล่อยงาน รอบปล่อยงาน แบบฟอร์มบันทึก และการย้อนกลับ

ทบทวนทุกปี กฎที่ CMS ไม่ได้บังคับ และไม่มีใครตรวจ เป็นแค่ข้อเสนอแนะ

ขั้นต่อไป

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

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