วิธีย้ายโดเมนโดยไม่ทำให้อันดับการค้นหาร่วง

การเปลี่ยนโดเมนเป็นหนึ่งในไม่กี่งาน SEO ที่ความผิดพลาดทางเทคนิคเล็ก ๆ อาจปรากฏให้เห็นชัดเจนอย่างรวดเร็ว redirect ที่หายไป เส้นทาง crawl ที่ถูกบล็อก หรือ canonical ที่ถูกลืม อาจเปลี่ยนการรีแบรนด์ที่ควรตรงไปตรงมาให้กลายเป็นความผันผวนของอันดับนานหลายสัปดาห์

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

เริ่มจาก inventory ไม่ใช่กฎ redirect

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

ก่อนแตะ DNS ให้สร้างรายการ URL ที่สำคัญ:

• URL ที่มีทราฟฟิกจาก organic search
• URL ที่มี backlink ภายนอก
• URL ที่ทำให้เกิด conversion, lead หรือสนับสนุน campaign
• Canonical URL ที่อยู่ใน XML sitemap ปัจจุบัน
• PDF, รูปภาพ และไฟล์ดาวน์โหลดที่ถูกลิงก์จากภายนอก
• URL เก่ามูลค่าสูงที่อาจไม่ปรากฏใน navigation ปัจจุบัน

สำหรับ URL เก่าแต่ละรายการ ให้กำหนดปลายทางบนโดเมนใหม่ ในกรณีส่วนใหญ่ ปลายทางนั้นควรเป็นหน้าเดียวกันที่มีเจตนาเดียวกัน ถ้า /pricing กลายเป็น https://newdomain.com/pricing นั่นเป็นเรื่องง่าย หากหน้าผลิตภัณฑ์เก่าสามหน้าถูกรวมเป็นคู่มือใหม่หน้าเดียว ให้บันทึกการตัดสินใจนั้นอย่างตั้งใจ

หลีกเลี่ยงรูปแบบที่มักง่าย: redirect ทุกอย่างไปยัง homepage ใหม่ วิธีนี้สะดวก แต่ทำให้ความเกี่ยวข้องสูญหาย ทั้งเสิร์ชเอนจินและผู้ใช้ต่างคาดหวังว่าปลายทางจะตอบความต้องการเดียวกับ URL เดิม

รักษาโครงสร้าง URL ไว้เมื่อทำได้

การย้ายโดเมนจะง่ายขึ้นเมื่อ path ยังคงเสถียร การย้ายจาก oldsite.com/blog/example ไปยัง newsite.com/blog/example สะอาดกว่าการเปลี่ยนโดเมน, CMS, slug, โครงสร้างโฟลเดอร์ และเนื้อหาพร้อมกันมาก

บางครั้งการ redesign หรือการย้าย CMS ทำให้การเปลี่ยน URL หลีกเลี่ยงไม่ได้ หากเป็นเช่นนั้น ให้แยกการตัดสินใจออกจากกัน:

1. อะไรที่เปลี่ยนเพราะโดเมนเปลี่ยน?
2. อะไรที่เปลี่ยนเพราะโครงสร้างไซต์เปลี่ยน?
3. อะไรที่ถูกลบ รวม หรือเขียนใหม่?

ยิ่งเพิ่มตัวแปรมากเท่าไร การวินิจฉัยปัญหาภายหลังก็ยิ่งยากขึ้น หากการย้ายครั้งนี้สำคัญและไซต์ปัจจุบันทำผลงานได้ดี ให้พิจารณาย้ายโดเมนก่อน แล้วค่อย redesign ภายหลัง

ใช้ redirect แบบถาวรและจบในหนึ่ง hop

สำหรับการย้ายโดเมนจริง ให้ใช้ server-side 301 หรือ 308 redirect จาก URL เก่าไปยัง URL ใหม่ที่เทียบเท่ากัน redirect แบบชั่วคราวมีไว้สำหรับสถานการณ์ชั่วคราว JavaScript redirect, meta refresh และ soft redirect เป็นสัญญาณที่อ่อนกว่าและพังได้ง่ายกว่า

เป้าหมายของ redirect นั้นเรียบง่าย:

• URL เก่าที่สำคัญทุกหน้าส่งกลับ permanent redirect
• redirect แต่ละรายการไปยังปลายทางสุดท้ายโดยตรง
• HTTP redirect ไป HTTPS อย่างสะอาด
• ตัวแปร www และ non-www ถูกจัดการอย่างสม่ำเสมอ
• redirect ไม่พึ่งพาพฤติกรรม query-string ที่เปราะบาง เว้นแต่จำเป็น

chain ที่ไม่ดีมีลักษณะเช่นนี้:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

สุดท้ายอาจไปถึงหน้าที่ถูกต้อง แต่ช้า crawl ได้ยากกว่า และมีโอกาสซ่อนข้อผิดพลาดมากกว่า ตั้งเป้าให้ทุก variant เก่ามีเพียงหนึ่ง hop ไปยัง URL ใหม่สุดท้าย

เมื่อตรวจสอบพฤติกรรม ให้ดู HTTP response จริงแทนที่จะเชื่อสิ่งที่ browser แสดง คู่มือของเราเรื่อง การ debug redirect และ HTTP header ใน production มีประโยชน์ในจุดนี้ เพราะ browser สุภาพเกินไป: มันตาม chain ให้เองและซ่อนส่วนที่ยุ่งเหยิงไว้

เตรียม DNS และ certificate ก่อนเปิดใช้งาน

DNS ไม่ได้ถ่ายโอนอันดับโดยตรง แต่ DNS ที่ผิดพลาดอาจทำให้การย้ายดูเหมือนพัง ลดค่า TTL ก่อนช่วงเปิดใช้งาน เพื่อให้การเปลี่ยนแปลง propagate ได้คาดการณ์ง่ายขึ้น ตรวจสอบว่าโดเมนใหม่มี record ที่ถูกต้องสำหรับ web traffic, email และ subdomain ที่จำเป็น

คุณยังต้องมี TLS certificate ที่ถูกต้องสำหรับทั้งสองโดเมน เรื่องนี้มักถูกมองข้ามได้ง่าย โดเมนเก่ายังคงต้องให้บริการ HTTPS redirect หลังการย้าย หาก certificate หมดอายุ ผู้ใช้และ crawler อาจเจอคำเตือนจาก browser ก่อนจะไปถึงไซต์ใหม่เสียอีก

หากการย้ายมีผลกับ email อย่ามองเป็นเรื่องภายหลัง การเปลี่ยนโดเมนมักทำให้ SPF, DKIM, DMARC, MX record, tracking link และ transactional mail มีปัญหา หากต้องการทบทวน record ที่สำคัญ ดูคู่มือที่เป็นมิตรกับนักพัฒนาของเราเรื่อง MX, SPF, DKIM และ DMARC

ตรวจสอบ canonical, internal link และ sitemap

หลังเปิดใช้งาน โดเมนใหม่ควรทำงานราวกับว่าเป็นบ้าน canonical ของเนื้อหามาตลอด

นั่นหมายความว่า:

• canonical tag ชี้ไปยัง URL ใหม่ ไม่ใช่โดเมนเก่า
• internal link ใช้โดเมนใหม่หรือ root-relative path
• XML sitemap มีเฉพาะ URL ใหม่สุดท้ายที่ index ได้
• hreflang annotation หากใช้งาน ต้องอ้างอิง URL ใหม่
• Open Graph, structured data และ alternate link ได้รับการอัปเดต
• Robots.txt ไม่บล็อกส่วนสำคัญ

อย่าเผยแพร่ sitemap ที่เต็มไปด้วย URL เก่าแล้วคาดหวังให้ redirect จัดการให้เรียบร้อย sitemap ควรเป็นรายการ URL ที่คุณต้องการให้ index หลังการย้าย นั่นหมายถึง URL สุดท้ายบนโดเมนใหม่

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

อย่าเปลี่ยนทุกอย่างในวันเปิดใช้งาน

การย้ายโดเมนเป็นเหตุการณ์ใหญ่พออยู่แล้ว หากเป็นไปได้ ให้หลีกเลี่ยงการรวมเข้ากับการตัดเนื้อหาครั้งใหญ่ การเขียน template ใหม่ การเปลี่ยน navigation การเปลี่ยนวิธี render JavaScript หรือ performance profile ใหม่

นี่ไม่ใช่ความเชื่อโชคลาง แต่เป็นวินัยในการ debugging หากอันดับตกหลังเปิดใช้งาน คุณต้องรู้ว่าสาเหตุมาจากการแมป redirect, การเข้าถึงของ crawl, เนื้อหาที่เปลี่ยน, การ render ที่ช้าลง, structured data ที่หายไป หรืออย่างอื่น

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

บอกเสิร์ชเอนจินว่าอะไรเปลี่ยนไป

ใน Google Search Console ให้ verify ทั้งโดเมนเก่าและโดเมนใหม่ จากนั้นใช้เครื่องมือ Change of Address เมื่อการย้ายเป็นการเปลี่ยนระดับโดเมนและเนื้อหาย้ายไปยังโดเมนใหม่ ส่ง sitemap ใหม่หลังเปิดใช้งาน

สิ่งนี้ไม่ได้แทนที่ redirect แต่ช่วยสนับสนุน redirect เสิร์ชเอนจินยังคงต้องการ redirect ที่ crawl ได้และคงอยู่ต่อเนื่อง เพื่อเข้าใจการแมปในระดับ URL

สำหรับ Bing และเสิร์ชเอนจินอื่น ๆ ให้ใช้ webmaster tools ของพวกเขาเมื่อมีให้ใช้งาน นอกจากนี้ให้อัปเดตจุดที่คุณควบคุมได้: social profile, business listing, ad destination, email footer, documentation, partner link และ canonical reference ใน syndicated content

ลิงก์ภายนอกทั้งหมดจะไม่ได้รับการอัปเดต และนั่นไม่เป็นไร แต่ลิงก์ที่สำคัญที่สุดควรได้รับการอัปเดต หาก partner รายใหญ่, app marketplace, documentation portal หรือ press page ลิงก์ไปยังโดเมนเก่า ให้ขอให้อัปเดต

มอนิเตอร์สิ่งที่ถูกต้องหลังเปิดใช้งาน

สองสามวันแรกหลังการย้ายควรเป็นการมอนิเตอร์อย่างจริงจัง ไม่ใช่การฉลอง

ตรวจสอบ:

• server log สำหรับกิจกรรม crawl บนโดเมนเก่าและใหม่
• 404 และข้อผิดพลาด 5xx ที่ไม่คาดคิด
• redirect chain และ loop
• สถานะ indexing ใน Search Console
• การค้นพบและประมวลผล sitemap
• organic landing page และรูปแบบ query
• conversion path ที่พึ่งพา URL เก่า
• analytics filter และ referral exclusion

คาดว่าจะมีสัญญาณรบกวนในการรายงาน เครื่องมือ analytics บางตัวมองโดเมนใหม่เป็น property ใหม่หากไม่ได้ตั้งค่าอย่างถูกต้อง dashboard บางตัวเปรียบเทียบทราฟฟิกโดเมนเก่ากับทราฟฟิกโดเมนใหม่ และทำให้การย้ายดูแย่กว่าความเป็นจริง

การมองเห็นใน search อาจผันผวนได้หลายสัปดาห์ สิ่งที่คุณไม่ต้องการคือรูปแบบที่ URL เก่ามูลค่าสูงถูก crawl ซ้ำ ๆ แต่ไม่ได้ redirect อย่างถูกต้อง หรือหน้าใหม่ถูกค้นพบแต่ถูกระบุว่าเป็น duplicate ของโดเมนเก่า

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

เก็บโดเมนเก่าไว้นาน ๆ

อย่าปล่อยให้โดเมนเก่าหมดอายุหลังจากการย้าย “ใช้งานได้แล้ว” ให้จดทะเบียนต่อ รักษา certificate ให้ใช้งานได้ และให้ redirect ทำงานต่อไปให้นานที่สุด ในทางปฏิบัติ มักหมายถึงหลายปี

ลิงก์เก่ายังคงอยู่ใน blog post, bookmark, documentation, PDF, email และ social post redirect คือสะพานระหว่างร่องรอยทางประวัติศาสตร์นั้นกับโดเมนใหม่ การปิดเร็วเกินไปทำให้เส้นทางของผู้ใช้พังและสิ้นเปลืองสัญญาณที่สะสมมา

เก็บสำเนา redirect map และ launch note ไว้ด้วย หกเดือนต่อมา เมื่อมีคนถามว่าเหตุใด legacy URL จึงทำงานแบบหนึ่ง คุณจะดีใจที่ได้บันทึกไว้

<!-- tool-cta:start -->

💡 ลองทำสิ่งนี้: หลังการสลับระบบ ให้ติดตาม URL เดิมของคุณผ่าน Redirect Checker เพื่อยืนยันว่าแต่ละรายการไปถึงหน้าใหม่ที่ถูกต้องด้วย 301 hop เพียงครั้งเดียว

<!-- tool-cta:end -->

เช็กลิสต์การย้ายโดเมนที่สมเหตุสมผล

ก่อนเปิดใช้งาน:

• Verify ทั้งสองโดเมนใน Search Console
• Crawl ไซต์ปัจจุบันและ export URL สำคัญ
• สร้าง redirect map แบบหนึ่งต่อหนึ่ง
• ลดค่า DNS TTL
• เตรียม TLS certificate สำหรับโดเมนเก่าและใหม่
• อัปเดต canonical, internal link, hreflang, structured data และ sitemap
• ทดสอบ redirect ใน staging หรือสภาพแวดล้อมที่ควบคุมได้

ในวันเปิดใช้งาน:

• Deploy redirect
• ยืนยันพฤติกรรม HTTP ไป HTTPS
• ทดสอบตัวอย่าง URL สำคัญจาก template ทุกประเภท
• ส่ง sitemap ใหม่
• ใช้เครื่องมือ Change of Address เมื่อเหมาะสม
• เฝ้าดู server error, redirect loop และ resource ที่ถูกบล็อก

หลังเปิดใช้งาน:

• มอนิเตอร์ crawl error และ indexing report
• อัปเดตลิงก์ภายนอกที่สำคัญเมื่อทำได้
• เปรียบเทียบทราฟฟิกตามเจตนาของ landing page ไม่ใช่แค่ยอดรวมตามโดเมน
• เปิด redirect ไว้ต่อไปโดยไม่มีกำหนด
• เลื่อน redesign หรือการทดลองเนื้อหาที่ไม่เกี่ยวข้องออกไปจนกว่าการย้ายจะเสถียร

การย้ายโดเมนไม่ได้ปราศจากความเสี่ยง แต่จัดการได้ อันดับมักเสียหายเมื่อการย้ายส่งสัญญาณไม่ชัดเจน: redirect ที่หายไป เนื้อหาที่เปลี่ยน canonical ที่ขัดแย้งกัน crawler ที่ถูกบล็อก หรือโดเมนเก่าที่ถูกลืม ให้แผนที่ที่สะอาดแก่เสิร์ชเอนจินและผู้ใช้ แล้วการย้ายจะดราม่าน้อยลงมาก