หลังออกแบบใหม่ URL เดิมไม่ควรหายไปเฉย ๆ ผู้เข้าชมอาจบันทึกสินค้าหรือเข้าบทความเก่าจากผลค้นหา หน้าที่หายไปอาจทำให้พวกเขาออกจากเว็บ เมื่อเปลี่ยน URL ให้จับคู่ที่อยู่เดิมแต่ละรายการกับเนื้อหาใหม่ที่สอดคล้องกัน เปลี่ยนเส้นทางอย่างถาวร แล้วเปิดตรวจสอบทุกเส้นทาง
301 คือการตอบกลับจากเซิร์ฟเวอร์ที่แจ้งเบราว์เซอร์และเครื่องมือค้นหาว่าหน้าย้ายถาวรแล้ว แต่ไม่ได้หาเป้าหมายที่ถูกต้องให้เอง ปลายทางผิด วนลูป หรือส่งหน้าเก่าทั้งหมดไปหน้าแรกยังทำให้ผู้เข้าชมหาข้อมูลที่ต้องการไม่พบ
ก่อนอื่น เข้าใจว่าเมื่อใดควรใช้ 301
หากย้ายเนื้อหาสินค้าจาก example.com/old-product/ ถึง example.com/new-product/ และเลิกใช้ที่อยู่เดิมเป็นหน้าแยก นี่คือการย้ายถาวรทั่วไป ทั้ง 301 และ 308 หมายถึงการเปลี่ยนเส้นทางถาวร ผู้เริ่มต้นใช้ตัวเลือก 301 ที่เว็บไซต์ WordPress เดิมรองรับได้ Google มอง 301 และ 308 ฝั่งเซิร์ฟเวอร์เป็นสัญญาณการย้ายถาวรที่ชัดเจน ตามที่อธิบายไว้ใน เอกสารการเปลี่ยนเส้นทาง .
หากเป็นการบำรุงรักษาชั่วคราวแล้วจะกลับมาใช้ URL เดิม อย่าประกาศว่าย้ายถาวร 302 และ 307 หมายถึงการเปลี่ยนเส้นทางชั่วคราว หากเปลี่ยนเพียงดีไซน์และเนื้อหาโดย URL เหมือนเดิม ก็ไม่ต้องเพิ่ม 301 ให้ URL นั้น
ตรวจสอบว่า URL ใหม่ทำงานก่อนตั้งค่า หากปลายทางตอบ 404 หรือยังไม่เผยแพร่ แม้ 301 ถูกต้องก็ส่งผู้ใช้ถึงเนื้อหาไม่ได้ เตรียมรายการทดสอบนำร่องและเปลี่ยนเมื่อหน้าใหม่พร้อม
หากหน้าเก่าไม่มีหน้าทดแทนควรทำอย่างไร
อย่าส่งทุกอย่างไปหน้าแรกเพียงเพื่อให้ URL เก่าทั้งหมดตอบ 301 สินค้าเลิกขายอาจส่งไปสินค้าทดแทนที่คล้ายกันจริงเมื่อเนื้อหาและความต้องการซื้อสอดคล้องกัน หากไม่มีปลายทางเหมาะสม ให้อธิบายว่าเลิกขายหรือส่งสถานะ 404/410 ที่เหมาะสม แทนการส่งไปหน้าแรกที่ไม่เกี่ยวข้อง ใน คู่มือการย้ายเว็บไซต์ของ Google ยังเตือนว่าการส่ง URL เก่าจำนวนมากไปหน้าแรกที่ไม่เกี่ยวข้องอาจถูกมองเป็น soft 404
ขั้นตอน 1: ทำตารางจับคู่ URL แบบหนึ่งต่อหนึ่ง
ส่งออก sitemap ปัจจุบัน หน้าเข้าชมสำคัญ และลิงก์ภายใน จากนั้นเพิ่ม URL เก่าที่ยังมีการเข้าชมหรือการแสดงผลใน Search Console บันทึกอย่างน้อย URL เดิม URL ใหม่ จุดประสงค์หน้า การดำเนินการ และผลตรวจสอบ อย่าเดาปลายทางจากชื่อหน้าอย่างเดียว เปิดเนื้อหาเก่าเพื่อเข้าใจงานของผู้อ่าน โดยเฉพาะเมื่อเปลี่ยนชื่อรุ่น รวมหมวดหมู่ หรือออกแบบเว็บหลายภาษาใหม่
| URL เดิม (ตัวอย่าง) | URL ใหม่ (ตัวอย่าง) | การดำเนินการและเหตุผล |
|---|---|---|
| example.com/old-lamp/ | example.com/desk-lamp/ | สินค้าเดิมเปลี่ยนชื่อ: ใช้ 301 ส่ง URL เดิมไปหน้าสินค้าใหม่ |
| example.com/size-help/ | example.com/size-guide/ | ข้อมูลขนาดย้ายไปหน้าช่วยเหลือใหม่: ใช้ 301 กับ URL เดิม |
| example.com/retired-item/ | ไม่มีหน้าใหม่ที่ตรงกัน | ตรวจหาสิ่งทดแทน หากไม่มีปลายทางเหมาะสมอย่าบังคับส่งไปหน้าแรก |
นี่คือตัวอย่างเพื่อการเรียนรู้ ไม่ใช่บันทึกการย้ายเว็บของลูกค้า AIRSANG จริง เมื่อเปิดใช้งานจริงให้ระบุโปรโตคอล โดเมน พาธ เครื่องหมายทับท้าย และตัวพิมพ์ใหญ่เล็กให้ครบ การย้ายจาก http ถึง https หรือเปลี่ยนว่าที่อยู่มี www หรือไม่ ก็อาจสร้างการเปลี่ยนเส้นทางหลายครั้ง ตรวจว่าปลายทางสุดท้ายเป็น URL canonical ที่ต้องการ
- เก็บ URL เดิม URL ปลายทาง และประเภทหน้าไว้ตรวจทีละรายการ
- ให้ความสำคัญกับหน้าที่มีการเข้าชมจากการค้นหาธรรมชาติ ลิงก์ภายนอก บุ๊กมาร์กที่ใช้บ่อย หรือโฆษณา
- บันทึกผู้ตั้งค่ากฎและเวลาที่เริ่มใช้ เพื่อหาต้นทางการตั้งค่าได้รวดเร็ว
ขั้นตอน 2: เลือกจุดตั้งค่าที่จัดการได้เพียงจุดเดียว
เว็บไซต์ WordPress มักใช้ฟังก์ชันจัดการการเปลี่ยนเส้นทางที่มีอยู่หรือกฎเซิร์ฟเวอร์/โฮสติ้ง ถามผู้ดูแลว่าใครควบคุมอยู่ เพื่อหลีกเลี่ยงปลั๊กอิน เซิร์ฟเวอร์ และ CDN กำหนดปลายทางขัดกันสำหรับ URL เดียว หากใช้เครื่องมืออย่าง Rank Math ให้ตรวจฟีเจอร์ที่ติดตั้งและการตั้งค่าจริง การกล่าวถึงปลั๊กอินในบทความไม่ได้แปลว่าเปิดใช้บนเว็บของคุณแล้ว
โดยทั่วไปให้กรอกพาธเดิมและ URL ปลายทางเต็ม แล้วเลือกการย้ายถาวร ก่อนบันทึก ตรวจว่าพาธเดิมตรงเฉพาะหน้าที่ต้องการ ปลายทางไม่พิมพ์ผิด และไม่กระทบหน้าจัดการ รูปภาพ หรือภาษาอื่น ทดลอง URL จริงที่เสี่ยงต่ำหนึ่งรายการก่อนนำเข้าจำนวนมาก
หากนักพัฒนาตั้งค่าเว็บเซิร์ฟเวอร์ ให้ส่งตารางจับคู่ครบและขอทดสอบในสภาพแวดล้อม staging ก่อน Nginx, Apache, CDN และ WordPress ใช้รูปแบบกฎต่างกัน บทความนี้ไม่มีการตั้งค่าที่อ้างว่าใช้ได้ทุกระบบให้วางในระบบจริง เขียนโค้ดตามเวอร์ชันเซิร์ฟเวอร์จริงและเอกสารทางการ พร้อมสำรองกฎเดิม
เลือกแบบถาวรและระบุจุดที่กฎมีผล
เปิดหน้าใหม่ในเบราว์เซอร์ได้ไม่ได้พิสูจน์ว่า URL เก่าตอบ 301 สคริปต์หน้าเว็บ meta refresh และลิงก์เชิญไปหน้าใหม่อาจพาไปได้โดยไม่มีการตอบกลับถาวรจากเซิร์ฟเวอร์ที่ต้องการ ตรวจสถานะเครือข่ายหลังตั้งค่า แทนการดูเพียงแถบที่อยู่เปลี่ยน
เมื่อกฎหนึ่งทำงานแล้ว ให้นำเข้ารายการเป็นชุด เก็บจำนวนกฎ ภาพหน้าจอหรือไฟล์ส่งออก ผลทดสอบ และผู้รับผิดชอบย้อนกลับของแต่ละชุด หากพาธหมวดหมู่ผิดจะย้อนกลับชุดนั้นได้โดยไม่ต้องเดาว่าเว็บเสียเมื่อใด
ขั้นตอน 3: ตรวจทุก URL เดิมว่าตอบ 301 และปลายทางตอบ 200
เปิด URL เดิมในหน้าต่างส่วนตัวและตรวจว่าไปถึงหน้าทดแทนที่ถูกต้อง ดูการตอบกลับในแผง Network ของเครื่องมือนักพัฒนาหรือเครื่องมือตรวจ HTTP ที่เชื่อถือได้ การย้ายถาวรทั่วไปจะตอบ 301 ที่ที่อยู่เดิม พร้อมส่วนหัว Location ชี้ไปที่อยู่ใหม่ซึ่งสุดท้ายตอบ 200 สถานะ 200 หมายถึงหน้าส่งเนื้อหากลับสำเร็จ ส่วน 404 หมายถึงไม่พบหน้า
ตรวจเพียงว่าสุดท้ายเปิดหน้าได้อาจพลาดห่วงโซ่การเปลี่ยนเส้นทาง: URL เก่าไปที่อยู่กลางแล้วส่งต่ออีกครั้งก่อนถึงหน้าใหม่ การส่งต่อที่จำเป็นไม่กี่ครั้งไม่ได้แปลว่าล้มเหลว แต่โซ่ยาวดูแลยากและมีโอกาสวนลูปเมื่อปรับเว็บครั้งต่อไป ควรชี้ตรงไปที่อยู่ canonical สุดท้ายหากทำได้
- เปิด URL เดิมแต่ละรายการ บันทึกรหัสสถานะแรกและส่วนหัว Location
- เปิด URL สุดท้าย ยืนยันว่าเนื้อหาเหมือนเดิมหรือสอดคล้องกันจริง และตรวจว่าตอบ 200 ในขั้นสุดท้าย
- ตรวจการส่งกลับ URL เดิม ส่งหาตัวเอง ไปภาษาผิด หรือทั้งชุดลงหน้าแรก
- สุ่มตรวจหน้าสำคัญบนมือถือและคอมพิวเตอร์ รวมรูปภาพ ปุ่ม และแบบฟอร์ม
หากไม่คุ้นเครื่องมือนักพัฒนา ให้ขอตารางราย URL ที่แสดงที่อยู่เดิม สถานะ ปลายทาง และสถานะปลายทาง แทนคำบอกว่าตั้งค่าเสร็จแล้ว สคริปต์ตรวจทุก URL ในการย้ายครั้งใหญ่ได้ แต่ควรเปิดตัวอย่างของทุกเทมเพลตด้วยตนเองเพื่อตรวจเนื้อหาที่จับคู่ผิด
ขั้นตอน 4: อัปเดตลิงก์ภายในเป็น URL ใหม่
301 ช่วยผู้ที่ยังใช้ที่อยู่เดิม ไม่ควรกลายเป็นเส้นทางปกติของการนำทางภายใน หลังตั้งค่า ให้อัปเดต URL เก่าในเมนู ท้ายเว็บ บทความ ปุ่ม สินค้าแนะนำ และเทมเพลตอีเมลเมื่อทำได้ บทความ แนวทางเก็บหรือลบส่วนเก่าของหน้าแรก ช่วยระบุจุดเข้าที่ควรเก็บก่อนอัปเดตลิงก์
ตรวจแท็ก canonical ของหน้าใหม่ด้วย Canonical บอกเครื่องมือค้นหาว่า URL ใดเป็นรุ่นหลัก หน้าสินค้าใหม่ที่ยังชี้ไป URL เก่าสร้างสัญญาณการย้ายขัดแย้งกัน ปกติหน้าใหม่ควรอ้าง URL canonical ของตัวเอง หรือรุ่นที่ถูกต้องตามกลยุทธ์เนื้อหาซ้ำจริง อย่าแก้ canonical ทั้งหมดโดยยังไม่ตรวจซอร์สและกฎแพลตฟอร์ม
อัปเดต sitemap XML ให้รายการหลักมี URL canonical ใหม่ที่ยังต้องการให้เครื่องมือค้นหาพบ แล้วส่งใหม่หรือรอการเก็บข้อมูล เก็บกฎของหน้าเก่าไว้ การลบ URL จาก sitemap ไม่ได้แปลว่าลบกฎได้ทันที เมื่อกำหนดขอบเขตออกแบบใหม่ให้ดู รายการหกขั้นตอนสำหรับโครงการเว็บไซต์องค์กร และรวมการย้าย URL กับการตรวจสอบในแผนส่งมอบ
คุณอาจควบคุมลิงก์เก่าในเว็บอื่นไม่ได้ จึงควรให้ 301 รองรับการเข้าชมเหล่านั้นต่อไป ขอให้คู่ค้าสำคัญที่ยินดีช่วยแก้ลิงก์ตรงไปที่อยู่ใหม่ วิธีนี้ลดการส่งต่อระหว่างทาง แต่ไม่แทนการเก็บกฎฝั่งเซิร์ฟเวอร์
ขั้นตอน 5: ติดตามหลังเปิดใช้และเก็บกฎเก่า
ช่วงวันแรกหลังย้าย ให้ติดตามบันทึกการเข้าถึง URL เก่า รายงาน 404 การประมวลผล sitemap และสถานะดัชนีใน Search Console รายงานหน้าเว็บของ Google Search Console ช่วยพบหน้าที่หาย หน้าเปลี่ยนเส้นทาง และการประมวลผลหน้าใหม่ รายงานมีความล่าช้า การไม่อัปเดตในวันเดียวกันไม่ได้พิสูจน์ว่าย้ายล้มเหลว
ทดสอบตัวอย่าง URL เก่าที่เพิ่งมีผู้เข้าชมอีกครั้ง โดยเฉพาะลิงก์ในโฆษณา โปรไฟล์สังคมออนไลน์ และอีเมลลูกค้า หาก URL เก่าตอบ 404 ให้ตรวจว่ามีเนื้อหาใหม่ตรงกันก่อนเพิ่มคู่ ห้ามส่งทุก 404 ไปหน้าแรกอัตโนมัติ หากลิงก์ภายในยังเก่าจำนวนมาก ให้แก้ต้นทางแล้วสุ่มตรวจใหม่
โดยทั่วไปคู่มือ Google แนะนำให้เก็บการเปลี่ยนเส้นทาง URL เก่าอย่างน้อยหนึ่งปี และนานกว่านั้นหากผู้ใช้หรือลิงก์ภายนอกยังใช้ที่อยู่เหล่านี้ หนึ่งปีคือแนวทางดูแล ไม่ใช่คำสัญญาว่าอันดับจะกลับมาหลังหนึ่งปี ก่อนออกแบบใหม่ให้ดู คู่มือขอบเขตราคาออกแบบเว็บไซต์ใหม่ เพื่อกำหนดผู้รับผิดชอบติดตามหลังเปิดใช้ ซ่อมลิงก์ และเก็บกฎ
แก้ปัญหาตามอาการ
หน้าเก่าไปหน้าแรกหรือภาษาผิด
ตรวจว่าตารางส่งพาธเก่าหลายรายการไปปลายทางรวมเดียวกันหรือไม่ แล้วหากฎซ้ำในเซิร์ฟเวอร์ WordPress หรือ CDN แก้ตามงานเดิมของผู้ใช้: คนหาขนาดควรได้ข้อมูลขนาด ไม่ใช่หน้าแรกแบรนด์ เว็บหลายภาษาต้องแน่ใจว่าหน้าจีนเก่าไม่พลาดไปหน้าแรกสินค้าอังกฤษ
เบราว์เซอร์แจ้งว่าเปลี่ยนเส้นทางมากเกินไป
มักหมายถึงสองกฎชี้กลับหากัน หรือกฎ HTTP/HTTPS และ www/ไม่มี www ขัดกัน ติดตาม Location ทุกขั้นในสายคำขอ แทนการล้างแคชซ้ำ ปิดหรือแก้กฎที่ขัดกันหนึ่งข้อ แล้วตรวจใหม่ในหน้าต่างส่วนตัวและผ่านบรรทัดคำสั่ง
หน้าใหม่ใช้ได้ แต่ผลค้นหายังแสดง URL เก่า
ทำให้ 301 ฝั่งเซิร์ฟเวอร์ สถานะ 200 ปลายทาง canonical ใหม่ ลิงก์ภายใน และ sitemap สอดคล้องกันก่อน แล้วให้เวลาเครื่องมือค้นหาประมวลผล การบันทึกกฎไม่ได้อัปเดตผลค้นหาทันที อย่าเปลี่ยน slug ซ้ำหรือส่ง sitemap ผิดอันเดิมเพื่อเร่งการแสดงผล ให้แก้สัญญาณทางเทคนิคก่อน
หากต้องย้อนการย้ายที่ผิด ให้คืนการตั้งค่าสำรองเดิมเพื่อให้ URL เก่าแสดงเนื้อหาถูกต้อง หรือแก้ปลายทางผิดเป็นคู่หนึ่งต่อหนึ่งที่เหมาะสม บันทึกเวลาย้อนกลับ URL ที่กระทบ และผลทดสอบใหม่ เพื่อป้องกันเพื่อนร่วมทีมนำเข้ากฎเก่าอีก เมื่อย้อนกลับอย่างเป็นทางการ ตรวจลิงก์ภายในและ canonical ให้ตรงกับ URL ที่คืนแล้วด้วย
สรุป: จับคู่ เปลี่ยนเส้นทาง และทดสอบซ้ำ
เมื่อออกแบบใหม่แล้ว URL เปลี่ยน ให้ส่งที่อยู่เดิมทุกแห่งที่ยังมีเนื้อหาตรงกันอย่างถาวรไปหน้าทดแทนที่เกี่ยวข้องที่สุด หลังหน้าใหม่เผยแพร่ ตรวจว่าทุกที่อยู่เดิมตอบ 301 และทุกปลายทางสุดท้ายตอบ 200 อัปเดตลิงก์ภายใน canonical และ sitemap พร้อมติดตามรายงาน 404 และ Search Console ต่อ
สำหรับครั้งแรก ทดลองสามถึงห้าหน้าที่สำคัญเพื่อหาคู่ผิดได้ง่ายกว่าการเปลี่ยนทั้งเว็บพร้อมกัน ยืนยันจุดที่กฎมีผล ทิศทางการจับคู่ และผู้รับผิดชอบย้อนกลับก่อนขยายเป็นชุด อย่าบังคับหน้าเก่าที่ไม่มีสิ่งทดแทนไปหน้าแรก เกณฑ์หลักของการเปลี่ยนเส้นทางที่ถูกต้องยังคงเป็นการที่ผู้เข้าชมหาข้อมูลที่ต้องการแต่แรกได้
