คำตอบสั้น ๆ
เว็บไซต์จะรักษาอันดับไว้ได้ตลอดการย้าย เมื่อทุก URL ที่สร้างทราฟฟิกหรือมีลิงก์ชี้เข้ามายังตอบสนองได้หลังเปิดตัว คือมีเนื้อหาเดิมอยู่ที่ที่อยู่เดิม หรือมีการรีไดเรกต์ถาวรฝั่งเซิร์ฟเวอร์ไปยังหน้าที่ใกล้เคียงที่สุด ปัญหาการย้ายเว็บส่วนใหญ่มาจาก URL ที่ไม่มีใครใส่ไว้ในรายการ
คู่มือการย้ายไซต์ที่มีการเปลี่ยน URL ของ Google วางแนวทางพื้นฐานไว้ว่า ให้แมป URL เก่าทุกตัวไปยัง URL ใหม่ ใช้การรีไดเรกต์ถาวรฝั่งเซิร์ฟเวอร์ เช่น 301 หรือ 308 คงไว้ "โดยทั่วไปอย่างน้อย 1 ปี" และ "คาดว่าอันดับของไซต์จะผันผวนชั่วคราวระหว่างการย้าย"
คู่มือเดียวกันแนะนำให้เปลี่ยนทีละอย่าง คือย้ายโดเมนใหม่ก่อน แล้วค่อยเปลี่ยนเลย์เอาต์ ส่วนเอกสารการเปลี่ยนที่อยู่ (Change of Address) ของ Google พูดตรงกว่านั้น หากรวมการย้ายเข้ากับการออกแบบเนื้อหาและโครงสร้าง URL ใหม่ "คุณอาจเห็นทราฟฟิกลดลงบ้าง" ระหว่างที่ Google ประเมินแต่ละหน้าใหม่ หากต้องทำทั้งสองอย่าง ให้วางแผนการออกแบบใหม่เป็นอีกเฟสหนึ่งต่างหาก
การย้ายสามแบบ
| รูปแบบการย้าย | สิ่งที่เปลี่ยน | รีไดเรกต์ | Search Console |
|---|---|---|---|
| ย้ายโฮสติ้งอย่างเดียว | เซิร์ฟเวอร์หรือ CDN โดยทุก URL ยังเหมือนเดิม | ไม่ต้อง | ติดตามการcrawl และการจัดทำดัชนี |
| แพลตฟอร์ม (Wix เป็น WordPress, WordPress เป็น Astro) | CMS เทมเพลต และมักมีรูปแบบ URL บางส่วน | ทุก URL ที่พาธเปลี่ยนไป | ส่ง sitemap ใหม่ แล้วติดตามผล |
| โดเมนหรือซับโดเมน | ทุก URL | ทั้งหมด | ใช้ Change of Address กับทุกเวอร์ชันที่ยืนยันความเป็นเจ้าของแล้ว |
สำหรับการย้ายโฮสติ้งอย่างเดียว คู่มือโฮสติ้งของ Google แนะนำให้ลด TTL ของ DNS "อย่างน้อยหนึ่งสัปดาห์ก่อนการย้าย" และเปิดเซิร์ฟเวอร์เก่าไว้จนทราฟฟิกลดเหลือศูนย์ อัตราการ crawl ที่ลดลงชั่วครู่หลังเปิดตัวเป็นเรื่องปกติ
ก่อนย้าย: ทำรายการทุกอย่างที่มี URL
แผนที่รีไดเรกต์จะดีได้เท่ากับรายการ URL เก่าที่อยู่เบื้องหลังเท่านั้น และแหล่งข้อมูลทุกแหล่งล้วนมีอะไรตกหล่น
crawl เว็บไซต์ที่ใช้งานอยู่
crawl เว็บไซต์ปัจจุบัน แล้วส่งออกทุก URL พร้อมรหัสสถานะ title meta description แท็ก canonical และ hreflang จากนั้นเพิ่ม URL ทั้งหมดใน XML sitemap Google ยังแนะนำให้ตรวจ log ของเซิร์ฟเวอร์เพื่อดู URL ที่มีผู้เข้าชมอย่างน้อยหนึ่งครั้งในช่วงที่ผ่านมา
ดึงหน้า Landing Page จาก Search Console และเครื่องมือวิเคราะห์
ในรายงานประสิทธิภาพของ Search Console ให้ส่งออกแท็บหน้า (Pages) โดยเลือกช่วงเวลายาวที่สุด และทำเช่นเดียวกันกับ Landing Page จากออร์แกนิกในเครื่องมือวิเคราะห์ หน้าเหล่านี้นำทราฟฟิกและลีดเข้ามา จึงต้องตรวจด้วยมือทีละหน้าตอนเปิดตัว
หาว่าใครลิงก์มาหาคุณ
รายงานลิงก์แสดงหน้าที่มีลิงก์ชี้เข้ามามากที่สุด แต่ตาราง "จำกัดไว้ที่ 1,000 แถว" และ Google ระบุว่าไม่ใช่รายการที่ครบถ้วน ควรใช้ร่วมกับเครื่องมือตรวจแบ็กลิงก์ที่คุณใช้อยู่
ทำรายการฟอร์ม ระบบเชื่อมต่อ และมีเดีย
จดให้ครบว่ามีฟอร์มอะไรบ้างและข้อมูลที่ส่งเข้ามาไปที่ไหน มีเครื่องมือฝังอะไรบ้าง (จองคิว แชต แผนที่ ชำระเงิน) และมีไฟล์ใดที่คนลิงก์ตรงมา คู่มือของ Google ระบุให้รวม "วิดีโอ รูปภาพ ไฟล์ JavaScript และ CSS" ไว้ในแผนด้วย เพราะ URL เหล่านี้ย้ายเหมือนเนื้อหาอื่น ๆ
สร้างแผนที่รีไดเรกต์
หนึ่งแถวต่อหนึ่ง URL เก่า: URL เก่า, URL ใหม่, รหัสสถานะ, หมายเหตุ, ทดสอบแล้ว มีสี่ข้อ:
- แมปแต่ละ URL เก่าไปยังหน้าที่ใกล้เคียงที่สุด การรีไดเรกต์ URL เก่าจำนวนมากไปยังปลายทางเดียวที่ไม่เกี่ยวข้อง เช่น หน้าแรก "อาจถูกมองว่าเป็น soft 404"
- หากรวมหลายหน้าเก่าเป็นหน้าเดียว ให้รีไดเรกต์ทุกหน้าไปยังหน้านั้น
- หากหน้าใดไม่มีหน้าที่เทียบเท่า ให้ตอบ 404 หรือ 410 ไม่ใช่รีไดเรกต์
- คงพาธเดิมไว้ทุกที่ที่แพลตฟอร์มใหม่รองรับ
ระหว่างการสร้าง: รีไดเรกต์และสิ่งที่ต้องไปด้วยกัน
ใช้รีไดเรกต์ 301 หรือ 308 ฝั่งเซิร์ฟเวอร์แบบ 1:1
เอกสารเรื่องรีไดเรกต์ของ Google ระบุว่า 301 และ 308 บ่งบอกว่า "ปลายทางของรีไดเรกต์ควรเป็น canonical" และแนะนำ "การรีไดเรกต์ถาวรฝั่งเซิร์ฟเวอร์เมื่อทำได้" ส่วนรหัสชั่วคราว (302, 303, 307) ไม่ได้บ่งบอกเช่นนั้น และรีไดเรกต์ด้วย JavaScript ควรเป็นทางเลือกสุดท้าย
รีไดเรกต์ตรงไปยัง URL ปลายทางสุดท้าย ตัว crawl ของ Google ตามรีไดเรกต์ได้สูงสุด 10 ทอด แต่คู่มือการย้ายไซต์แนะนำให้ "รีไดเรกต์ไปยังปลายทางสุดท้ายโดยตรง" หากการย้ายครั้งก่อนทิ้งรีไดเรกต์ไว้ ให้ชี้ไปยัง URL สุดท้ายใหม่เช่นกัน
ตรวจรหัสสถานะเริ่มต้นของสิ่งที่ให้บริการรีไดเรกต์ บน Cloudflare Workers ซึ่ง Dardo ใช้โฮสต์เว็บไซต์ที่สร้างไฟล์ _redirectsจะใช้ 302 เว้นแต่คุณเขียน 301 ไว้ในทุกบรรทัด รองรับรีไดเรกต์แบบคงที่ได้สูงสุด 2,000 รายการและแบบไดนามิก 100 รายการ และจับคู่พารามิเตอร์ query ไม่ได้ ดังนั้น permalink แบบ plain ของ WordPress (/?p=123) จึงต้องมีตรรกะรีไดเรกต์ในโค้ดของ Worker
เมื่อใดควรตอบ 404 หรือ 410 แทน
หน้าเนื้อหาบางเบา ข้อเสนอที่หมดอายุ และหน้าซ้ำ ไม่จำเป็นต้องคงไว้ คู่มือของ Google ระบุว่าเนื้อหาที่ไม่ย้ายควร "ตอบ HTTP 404 หรือ 410 อย่างถูกต้อง" และตัว crawl ของ Google จัดการรหัส 4xx ทุกตัวยกเว้น 429 แบบเดียวกัน คือ URL จะหลุดจากดัชนี
ย้ายเมทาดาตา canonical และ hreflang ไปด้วย
- Title และ meta description ย้ายทีละฟิลด์ แทนที่จะปล่อยให้เทมเพลตใหม่สร้างขึ้นเอง
- Canonical ทุกหน้าใหม่ควรมี canonical ชี้กลับมาที่ URL ใหม่ของตัวเอง คู่มือเรื่อง canonicalization ของ Google เรียก canonical ว่า "คำแนะนำ ไม่ใช่กฎ" ดังนั้น canonical รีไดเรกต์ และ sitemap ต้องสอดคล้องกัน
- Hreflang ตามคู่มือเวอร์ชันภาษาท้องถิ่นของ Google แต่ละเวอร์ชันภาษา "ต้องระบุทั้งตัวเองและเวอร์ชันภาษาอื่นทั้งหมด" และ "หากสองหน้าไม่ได้ชี้หากัน แท็กจะถูกเพิกเฉย" ให้อัปเดตทุกแอนโนเทชันเป็น URL ใหม่
ข้อมูลเชิงโครงสร้าง ลิงก์ภายใน และ URL ของรูปภาพ
- ข้อมูลเชิงโครงสร้าง สร้างมาร์กอัป Organization, Breadcrumb, Article หรือ Product ขึ้นใหม่ในเทมเพลตใหม่ แล้วทดสอบด้วย Rich Results Test คู่มือการย้ายของ Google ไม่ได้กล่าวถึงเรื่องนี้ จึงตกหล่นได้ง่าย
- ลิงก์ภายใน ชี้ไปที่ URL ใหม่โดยตรง ไม่ใช่ชี้ผ่านรีไดเรกต์
- รูปภาพและไฟล์ ตั้งชื่อไฟล์และข้อความ alt ให้สื่อความหมายต่อไป และรีไดเรกต์ URL เก่าของรูปภาพและ PDF ที่มีลิงก์หรือทราฟฟิกจากการค้นหารูปภาพ
การวิเคราะห์ข้อมูลและความยินยอม
ติดตั้งเครื่องมือวิเคราะห์ข้อมูล คอนเวอร์ชันอีเวนต์ และพิกเซลโฆษณาใหม่ แล้วทดสอบบน staging หากเว็บไซต์เดิมขอความยินยอมในการใช้คุกกี้ เว็บไซต์ใหม่ก็ต้องขอด้วยวิธีเดียวกันก่อนที่แท็กเหล่านั้นจะทำงาน
สิ่งที่มักเสียหาย แยกตามแพลตฟอร์ม
บันทึกเหล่านี้มาจากเอกสารทางการของแต่ละแพลตฟอร์ม ณ เดือนตุลาคม 2026 เป็นการอธิบายวิธีการทำงานของแพลตฟอร์ม ไม่ใช่ข้อบกพร่อง
| แพลตฟอร์ม | รูปแบบ URL ที่ต้องแมป | ข้อจำกัดของการส่งออกและรีไดเรกต์ |
|---|---|---|
| WordPress | Permalinks อาจเป็นแบบธรรมดา (/?p=N) แบบตามวันที่ หรือแบบตามชื่อโพสต์ ส่วนหน้าเก็บถาวรของหมวดหมู่และแท็กจะมีส่วนนำหน้าเสมอ เช่น /category/ | ตั้งแต่ WordPress 6.4 หน้าไฟล์แนบจะปิดอยู่ในการติดตั้งใหม่ แต่ยังเปิดอยู่ในเว็บไซต์ที่อัปเกรดมา ดังนั้นเว็บไซต์รุ่นเก่าอาจมีหนึ่ง URL ต่อหนึ่งไฟล์ที่อัปโหลด |
| Webflow | รายการ CMS อยู่ในหน้า Collection | การส่งออกโค้ดไม่รวมเนื้อหา CMS, Ecommerce, User Accounts, การประมวลผลฟอร์ม, การค้นหาในเว็บไซต์ และหน้าที่แปลภาษา และต้องใช้แผน Workspace ส่วน Collections ส่งออกแยกเป็น CSV |
| Wix | โพสต์บล็อกจะอยู่ภายใต้คำนำหน้า /post/ ซึ่งเปลี่ยนชื่อได้แต่ลบออกไม่ได้ ใน WordPress การตั้งโครงสร้างลิงก์ถาวรแบบกำหนดเองเป็น /post/%postname%/ จะคงคำนำหน้านี้ไว้ | เว็บไซต์ Wix "ต้องทำงานบนเซิร์ฟเวอร์ของ Wix" ดังนั้นการย้ายออกหมายถึงการสร้างหน้าใหม่ทั้งหมด |
| Framer | การเปลี่ยน sub-path จะไม่อัปเดตกฎรีไดเรกต์ที่มีอยู่ กฎเก่าจึงอาจชี้ไปยังเส้นทางที่ไม่มีอยู่แล้ว | เว็บไซต์เผยแพร่เป็น HTML, CSS และ JavaScript มาตรฐาน ส่วนเนื้อหา CMS ส่งออกผ่านปลั๊กอินเป็น CSV หรือ JSON |
| Squarespace | URL mappings รองรับตัวแปร [name] สำหรับทั้งคอลเลกชัน เช่น /blog/[name] -> /posts/[name] 301 | ไฟล์ส่งออกเป็น WordPress XML ที่มีหน้าบล็อกหนึ่งหน้า หน้าเลย์เอาต์ และแกลเลอรี แต่ไม่มีหน้าร้านค้า บล็อกสินค้า วิดีโอ หรือเสียง และไม่มี CSS แบบกำหนดเอง URL mappings รีไดเรกต์ URL ของรูปภาพหรือไฟล์ไม่ได้ และรองรับประมาณ 2,500 บรรทัด |
| Shopify | URL ของหน้าร้านอยู่ภายใต้เส้นทาง เช่น /products/, /collections/, /pages/ และ /blogs/<blog>/ โดย Shopify ระบุว่า /products และ /collections เป็นเส้นทางคงที่ | รีไดเรกต์ใช้ได้เฉพาะจาก URL ที่ไม่โหลดหน้าใดแล้ว และร้านค้าตั้งได้สูงสุด 100,000 รายการ (20,000,000 รายการบน Plus) |
การย้ายออกจาก Wix หมายถึงต้องสร้างทุกหน้าใหม่ การย้ายออกจาก Squarespace หมายถึงนำเข้าสิ่งที่ไฟล์ส่งออกครอบคลุมแล้วสร้างส่วนที่เหลือใหม่ การย้ายไป Shopify มักทำให้ URL สินค้าเปลี่ยน แผนที่รีไดเรกต์จึงต้องครอบคลุมทุกสินค้า
วันเปิดตัว
- DNS หากมีการเปลี่ยนโฮสติ้งหรือ DNS ให้ลดค่า TTL ล่วงหน้าอย่างน้อยหนึ่งสัปดาห์
- การบล็อกการครอว์ล ลบแท็ก
noindexของ staging และการบล็อกใน robots.txt ออก Google แนะนำให้จดรายการทุก URL ที่ใช้noindexระหว่างการพัฒนา - รีไดเรกต์ ปล่อยพร้อมกับเว็บไซต์ใหม่ในรีลีสเดียวกัน
- ทดสอบรีไดเรกต์ รันทั้งแผนที่ผ่านสคริปต์ ทุก URL เก่าต้องตอบกลับ 301 หรือ 308 ไปยัง URL ปลายทางที่ถูกต้องในครั้งเดียว และ URL นั้นต้องตอบกลับ 200
- Search Console ยืนยันความเป็นเจ้าของเว็บไซต์ใหม่ และส่งไซต์แมปใหม่ พร้อมไซต์แมปของ URL เก่าเพื่อให้ถูกครอว์ลอีกครั้ง คำเตือนว่า URL เหล่านั้นถูกรีไดเรกต์เป็นเรื่องที่คาดไว้ได้
- Change of Address หากเปลี่ยนโดเมน ให้ส่งคำขอจากพร็อพเพอร์ตีที่คุณเป็นเจ้าของทั้งสองฝั่งด้วยบัญชี Google เดียวกัน สำหรับโดเมนเก่าทุกรูปแบบ รวมถึงแบบมี www และไม่มี www
- เส้นทางที่สร้างรายได้ ลองส่งฟอร์มจริง ทดสอบชำระเงิน และยืนยันว่าอีเวนต์วิเคราะห์ข้อมูลถูกส่งเข้ามา
- ลิงก์ของคุณเอง อัปเดตโปรไฟล์โซเชียล โฆษณา และรายชื่อในไดเรกทอรี
30, 60 และ 90 วันหลังเปิดตัว
วันที่ 1 ถึง 30: คาดว่าจะมีการเปลี่ยนแปลง
อันดับอาจผันผวน "ระหว่างที่ Google ครอว์ลและจัดทำดัชนีเว็บไซต์ของคุณใหม่" และ "เว็บไซต์ขนาดเล็กถึงกลางอาจใช้เวลาไม่กี่สัปดาห์กว่าที่ส่วนใหญ่ของหน้าจะเปลี่ยนแปลง ส่วนเว็บไซต์ขนาดใหญ่ใช้เวลานานกว่า" ให้ติดตาม:
- รายงานการจัดทำดัชนีและไซต์แมป URL ที่ถูกจัดทำดัชนีบนเว็บไซต์เก่าจะลดลง และบนเว็บไซต์ใหม่จะเพิ่มขึ้น
- ประสิทธิภาพรายหน้า URL ใหม่เริ่มได้การแสดงผลและคลิก
- ล็อกเซิร์ฟเวอร์และ 404 ทุก 404 ที่ไม่คาดคิดคือแถวที่ขาดไปในแผนที่ ตรวจทุกวันเป็นเวลาสองสัปดาห์
วันที่ 31 ถึง 60: เปรียบเทียบกับค่าอ้างอิง
เปรียบเทียบแลนดิงเพจยอดนิยมกับ URL ใหม่ของแต่ละหน้า หากหน้าใดสูญเสียคลิก ให้ตรวจตามลำดับ: รีไดเรกต์ไปถึงหน้าที่ถูกต้องในครั้งเดียวหรือไม่ เนื้อหาหรือชื่อหน้าเปลี่ยนไปหรือไม่ ลิงก์ภายในยังชี้มาที่หน้านั้นอยู่หรือไม่ และอยู่ในไซต์แมปหรือไม่ จากนั้นให้ติดต่อเว็บไซต์ที่ลิงก์กลับมาซึ่งมีมูลค่าสูงสุดของคุณเพื่อขอให้อัปเดตลิงก์
วันที่ 90 เป็นต้นไป: คงรีไดเรกต์ไว้
คู่มือของ Google ระบุให้คงรีไดเรกต์ไว้ "โดยทั่วไปอย่างน้อย 1 ปี" และในมุมมองของผู้ใช้ ให้ "พิจารณาคงรีไดเรกต์ไว้ตลอดไป" สำหรับการย้ายโดเมน หน้า Change of Address กำหนดขั้นต่ำไว้ที่ 180 วัน หลังจากนั้น Google จะถือว่าเว็บไซต์เก่าไม่เกี่ยวข้องกันหากยังครอว์ลได้อยู่ นอกจากนี้ยังแนะนำให้จ่ายค่าโดเมนเก่าต่อ "อย่างน้อยหนึ่งปี" เพื่อไม่ให้คนอื่นซื้อไปได้
เช็กลิสต์
| ระยะ | งาน | ถือว่าเสร็จเมื่อ |
|---|---|---|
| ก่อน | ครอว์ลเว็บไซต์ ไซต์แมป และล็อกเซิร์ฟเวอร์ | มีรายการเดียวที่รวมทุก URL เก่าพร้อมรหัสสถานะ |
| ก่อน | ส่งออกแลนดิงเพจและหน้าที่มีลิงก์ชี้มามากที่สุด | หน้ายอดนิยมและเป้าหมายของแบ็คลิงก์ถูกทำเครื่องหมายไว้ในแผนที่ |
| ก่อน | ทำรายการฟอร์ม การเชื่อมต่อ สคริปต์ และไฟล์ | ทุกรายการมีผู้รับผิดชอบและแผนสำหรับเว็บไซต์ใหม่ |
| ก่อน | สร้างแผนที่รีไดเรกต์ | ทุก URL เก่ามีปลายทาง หรือมีการตัดสินใจเป็น 404/410 |
| สร้าง | รีไดเรกต์ 301 หรือ 308 ฝั่งเซิร์ฟเวอร์ | ครั้งเดียวถึงปลายทาง ไม่มีรีไดเรกต์ต่อเนื่อง ไม่รีไดเรกต์จำนวนมากไปหน้าแรก |
| สร้าง | ชื่อหน้า คำอธิบาย canonical และ hreflang | ตรงกับหน้าเก่า โดย canonical และ hreflang ใช้ URL ใหม่ |
| สร้าง | ข้อมูลเชิงโครงสร้าง ลิงก์ภายใน และ URL ของรูปภาพ | ผ่าน Rich Results Test และไม่มีลิงก์ภายในที่ชี้ไปยังรีไดเรกต์ |
| สร้าง | การวิเคราะห์ข้อมูล คอนเวอร์ชัน และความยินยอม | อีเวนต์ทำงานบน staging และทำงานหลังได้รับความยินยอมเท่านั้นในกรณีที่จำเป็น |
| เปิดตัว | ลบ noindex และการบล็อกใน robots.txt | URL ใหม่ครอว์ลได้ |
| เปิดตัว | ทดสอบแผนที่รีไดเรกต์ | ทุกแถวตอบกลับรหัสและปลายทางตามที่คาดไว้ |
| เปิดตัว | Search Console: ยืนยัน ไซต์แมป Change of Address | ส่งเรียบร้อยโดยไม่มีข้อผิดพลาดร้ายแรง |
| หลัง | ติดตามการจัดทำดัชนี 404 และประสิทธิภาพ | URL เก่าลดลง URL ใหม่ได้การแสดงผลเพิ่มขึ้น |
| หลังย้าย | คงรีไดเรกต์และโดเมนเก่าไว้ | อย่างน้อยหนึ่งปี |
ขอความช่วยเหลือในการย้ายเว็บไซต์
Dardo ย้ายเว็บไซต์ไปยังเว็บที่สร้างด้วย Astro แบบกำหนดเองบน Cloudflare Workers โดยแผนผังรีไดเรกต์เป็นงานส่งมอบที่เราทดสอบก่อนเปิดตัวและส่งมอบพร้อมกับเว็บไซต์ ดูการย้ายเว็บไซต์ หรือการรีดีไซน์เว็บไซต์หากการย้ายครั้งนี้ต้องการดีไซน์ใหม่ด้วย หรือบอกเราว่าคุณจะย้ายอะไร