บทความ
เรื่องราว ความรู้ และประสบการณ์จากการสร้างเว็บไซต์และ Web Application
Blogทำเว็บไซต์ย้ายเว็บจาก WordPress ไป Next.js ไม่เสียอันดับ
ย้ายเว็บจาก WordPress ไป Next.js โดยไม่เสียอันดับ Google ต้องทำรายการ URL ตั้ง redirect ถาวร และทดสอบก่อนเปิดจริง บทความนี้สรุป 8 ขั้นตอนพร้อมโค้ดตัวอย่าง
Kittipong C.
ทีมงาน KittiStack
October 28, 2026·11 min read
ย้ายเว็บจาก WordPress ไป Next.js ทำยังไงไม่ให้เสียอันดับ Google: คู่มือ 8 ขั้นตอน
ย้ายเว็บจาก WordPress ไป Next.js ให้ปลอดภัย สิ่งที่ต้องทำก่อนเขียนโค้ดหน้าแรกคือ ทำรายการ URL เก่าทั้งหมด แล้วกำหนดว่าแต่ละ URL จะไปอยู่ที่ไหน จากนั้นตั้ง redirect แบบถาวรจาก URL เก่าไปใหม่ ทดสอบบน staging และติดตามผลใน Google Search Console หลังเปิดตัว ถ้า URL เดิมยังใช้ได้ทั้งหมด ความเสี่ยงจะน้อยลงมาก แต่ถ้าเปลี่ยน URL แล้วไม่ตั้ง redirect อันดับที่สะสมมาหลายปีอาจหายไปทันที
บทความนี้อธิบายทั้งขั้นตอนและโค้ดตัวอย่าง ตั้งแต่ดึงรายการบทความจาก WordPress ไปจนถึงตั้ง redirect ใน Next.js ผู้เขียนรับงานพัฒนาเว็บด้วย Next.js จึงระบุไว้ตรง ๆ ว่าบางกรณีการอยู่กับ WordPress ต่อคือทางเลือกที่ดีกว่า ดูรายละเอียดในหัวข้อ "ควรย้ายไหม"
แสดงรูปภาพ
ย้ายเว็บจาก WordPress ไป Next.js มี 3 แบบ
คำว่า "ย้ายไป Next.js" ไม่ได้แปลว่าทิ้ง WordPress เสมอไป ก่อนเริ่มต้องเลือกก่อนว่าจะย้ายแบบไหน เพราะงานและความเสี่ยงต่างกันมาก
#Next.js#WordPress#SEO#ย้ายเว็บ
1. Headless WordPress | ยังอยู่ใน WordPress | หลังบ้าน WordPress เดิม | เว็บที่มีบทความเยอะ ทีมคุ้นกับ WordPress แล้ว |
2. ย้ายเนื้อหาไป CMS ตัวใหม่ | Headless CMS หรือฐานข้อมูล เช่น Supabase | หน้าแอดมินของ CMS หรือที่สร้างเอง | เว็บที่อยากเลิกดูแล WordPress และปลั๊กอินทั้งหมด |
3. ย้ายเป็นไฟล์ในโค้ด | ไฟล์ Markdown หรือ MDX ในโปรเจกต์ | แก้ผ่านนักพัฒนา | เว็บบริษัทขนาดเล็กที่เนื้อหาเปลี่ยนไม่บ่อย |
แบบที่ 1 ยังต้องดูแลเซิร์ฟเวอร์ WordPress และปลั๊กอินอยู่ แต่ผู้อ่านจะไม่เห็นหน้า WordPress โดยตรง ส่วนแบบที่ 2 และ 3 ตัด WordPress ออกทั้งหมด งานย้ายเนื้อหาจึงมากกว่า
ควรย้ายไหม
การย้ายแพลตฟอร์มเป็นงานที่มีความเสี่ยงต่ออันดับ Google ในระดับสูง จึงควรย้ายเมื่อมีเหตุผลที่ชัดเจนเท่านั้น
- ✦เว็บช้าเรื้อรัง แม้ปรับธีม ปลั๊กอิน และแคชแล้ว
- ✦ต้องการฟีเจอร์ที่ปลั๊กอินทำไม่ได้ เช่น ระบบสมาชิก แดชบอร์ด หรือระบบจองเฉพาะธุรกิจ
- ✦เบื่อการอัปเดตปลั๊กอินและกังวลเรื่องความปลอดภัย
- ✦วางแผนต่อยอดเป็นเว็บแอปในอนาคต
- ✦เว็บทำรายได้จาก SEO อยู่ และยังไม่มีคนที่ดูแลการย้ายอย่างรอบคอบ
- ✦ทีมการตลาดลงบทความเองทุกสัปดาห์ และไม่มีงบทำหลังบ้านใหม่
- ✦ปัญหาจริงคือเนื้อหาหรือการออกแบบ ไม่ใช่เทคโนโลยี
ถ้าไม่แน่ใจ ลองแก้ปัญหาความเร็วใน WordPress ก่อน ถ้าทำแล้วยังไม่พอ ค่อยกลับมาอ่านขั้นตอนข้างล่าง
ขั้นตอนย้ายเว็บจาก WordPress ไป Next.js 8 ขั้นตอน
ขั้นที่ 1: ทำรายการ URL และเนื้อหาทั้งหมด
- ✦บทความ หน้า และ custom post type
- ✦หมวดหมู่ แท็ก ผู้เขียน และหน้า archive
- ✦ไฟล์สื่อและเมนู
- ✦ช่อง custom field และช่อง SEO จากปลั๊กอิน
- ✦กฎ redirect ที่ตั้งไว้ในปลั๊กอิน
- ✦shortcode ฟอร์มที่ฝังไว้ และสคริปต์ที่ฝังไว้
- ✦URL ของ feed และหน้าค้นหา
ถ้าจะดึงรายการบทความและหน้าผ่าน WordPress REST API ใช้สคริปต์ Node.js (เวอร์ชัน 20 ขึ้นไป) แบบนี้ได้
// inventory.mjs (รัน: node inventory.mjs)
import { writeFileSync } from 'node:fs'
const base = 'https://example.com/wp-json/wp/v2'
async function fetchAll(type) {
const items = []
let page = 1
let totalPages = 1
do {
const res = await fetch(
`${base}/${type}?per_page=100&page=${page}&_fields=id,link,slug,date,modified`
)
if (!res.ok) throw new Error(`${type} หน้า ${page}: ${res.status}`)
totalPages = Number(res.headers.get('X-WP-TotalPages') || 1)
items.push(...(await res.json()))
page += 1
} while (page <= totalPages)
return items
}
const rows = ['type,id,old_url,slug,modified']
for (const type of ['posts', 'pages']) {
for (const item of await fetchAll(type)) {
rows.push([type, item.id, item.link, item.slug, item.modified].join(','))
}
}
writeFileSync('inventory.csv', rows.join('\n'))
console.log(`บันทึก ${rows.length - 1} รายการ`)
ตามเอกสาร REST API ของ WordPress ค่า per_page สูงสุดคือ 100 และทุกการตอบกลับมี header X-WP-TotalPages บอกจำนวนหน้าทั้งหมด สคริปต์นี้จึงวนดึงจนครบ ข้อควรระวังคือถ้าใช้ custom post type ต้องเปิดให้ REST API มองเห็นก่อน และถ้าปิด REST API ไว้ ให้ใช้เมนู Tools > Export ของ WordPress แทน
ไฟล์ CSV ที่ได้เป็นแค่จุดเริ่มต้น ให้เพิ่ม URL จาก 3 แหล่งนี้ด้วย
- ✦Google Search Console: หน้าที่มีผู้เข้าจาก Google จริง
- ✦Google Analytics: หน้าที่มีทราฟฟิกจากช่องทางอื่น
- ✦รายงาน backlink: URL ที่เว็บอื่นลิงก์มา แม้ตัวหน้าจะไม่มีทราฟฟิกแล้ว
ขั้นที่ 2: บันทึกตัวเลขก่อนย้าย
เก็บสถิติปัจจุบันไว้เปรียบเทียบหลังย้าย ได้แก่
- ✦จำนวนคลิกและการแสดงผลรวมจาก Search Console ย้อนหลังอย่างน้อย 3 เดือน
- ✦20 หน้าที่ได้ทราฟฟิกสูงสุด และคีย์เวิร์ดที่แต่ละหน้าติดอันดับ
- ✦คะแนน PageSpeed และ Core Web Vitals ของหน้าสำคัญ
- ✦รายการ backlink ที่สำคัญ
ถ้าไม่เก็บตัวเลขก่อน หลังย้ายจะบอกไม่ได้ว่าอันดับตกจริงหรือแค่ผันผวนตามปกติ
ขั้นที่ 3: เลือกว่าเนื้อหาจะอยู่ที่ไหน
กลับไปดูตาราง 3 แบบด้านบน แล้วตอบ 2 คำถาม
- 1.ใครจะแก้เนื้อหาหลังเปิดเว็บ และบ่อยแค่ไหน
- 2.ถ้าติดต่อนักพัฒนาไม่ได้ ใครดูแลต่อ
ถ้าทีมต้องแก้เองและไม่มีนักพัฒนา การมีหลังบ้านคือเงื่อนไขที่ต้องมี ถ้าไม่มี Next.js จะกลายเป็นภาระ เพราะทุกการแก้ไขต้องเรียกนักพัฒนา
ขั้นที่ 4: ย้ายเนื้อหาและไฟล์สื่อ
สิ่งที่มักเป็นงานหนักกว่าที่คิดคือ
- ✦เนื้อหาจาก page builder: บทความที่สร้างด้วย Elementor หรือ Divi จะมี shortcode และโครงสร้าง HTML เฉพาะของธีม ต้องล้างหรือแปลงก่อนนำไปแสดงใน Next.js
- ✦รูปภาพ: ย้ายไฟล์ไปที่เก็บใหม่ และแก้ลิงก์รูปในเนื้อหาทุกบทความ พร้อมเก็บ alt text ไว้ตามเดิม
- ✦ฟอร์มและสคริปต์ฝังในหน้า: ฟอร์มติดต่อ สคริปต์ติดตามโฆษณา และปลั๊กอินที่ทำงานฝั่งหน้าเว็บ ต้องสร้างใหม่หรือหาตัวแทน
- ✦ช่อง SEO ของปลั๊กอิน: SEO Title และ Meta Description ที่เคยตั้งใน Yoast หรือ Rank Math ต้องดึงมาเก็บไว้ ไม่ใช่ปล่อยให้ Next.js สร้างค่าเริ่มต้นใหม่
ขั้นที่ 5: จับคู่ URL เก่ากับ URL ใหม่
ขั้นนี้สำคัญที่สุดของทั้งกระบวนการ คู่มือการย้ายเว็บของ Google ครอบคลุมการเปลี่ยนโครงสร้าง URL และระบุว่า redirect แบบถาวรอย่าง 301 ไม่ทำให้สูญเสีย PageRank ดังนั้นการตั้ง redirect ให้ครบจึงรักษาคะแนนที่สะสมไว้ได้
สำหรับ URL แต่ละรายการในรายการ ให้ตัดสินใจเพียงข้อเดียวจาก 3 ข้อนี้
ถ้าเป็นไปได้ ควรพยายามคง URL เดิมไว้ให้มากที่สุด เพราะลดจำนวน redirect และลดความเสี่ยง WordPress มักใช้รูปแบบ /ชื่อบทความ/ หรือ /ปี/เดือน/ชื่อบทความ/ ซึ่งทำให้ route ใน Next.js ได้เหมือนเดิม เช่น ใช้ app/[slug]/page.tsx
อย่าส่ง URL เก่าทั้งหมดไปที่หน้าแรกรวมกัน ให้ส่งไปหน้าที่เนื้อหาตรงกันมากที่สุด เพื่อให้ผู้เข้าชมที่กดลิงก์เก่าได้เจอสิ่งที่ตามหา
ตั้ง redirect ใน Next.js ผ่านไฟล์ next.config.js
// next.config.js
const urlMap = require('./redirect-map.json')
// ตัวอย่างไฟล์: { "/2024/05/hello-world": "/blog/hello-world" }
module.exports = {
async redirects() {
const exact = Object.entries(urlMap).map(([source, destination]) => ({
source,
destination,
permanent: true,
}))
return [
...exact,
// รูปแบบเป็นกลุ่ม เช่น หมวดหมู่เดิม /category/xxx
{ source: '/category/:slug*', destination: '/blog/category/:slug*', permanent: true },
]
},
}
เอกสาร Next.js อธิบายว่า permanent: true ใช้รหัส 308 ซึ่งบอก client และเสิร์ชเอนจินว่าย้ายถาวร ส่วน permanent: false ใช้ 307 ที่เป็นการย้ายชั่วคราว รหัส 308 ทำงานเหมือน 301 ในแง่ที่เป็นสัญญาณถาวร แต่ต่างตรงที่คงวิธีเรียก (method) เดิมไว้ ใช้ /blog/:slug* จับหลายระดับของ path ได้ และ query string จะถูกส่งต่อไป URL ปลายทางให้ด้วย
ถ้ามี redirect หลายร้อยรายการ ให้เก็บแผนที่เป็นไฟล์แยกอย่างในตัวอย่าง แทนการเขียนในโค้ดตรง ๆ จะดูแลและตรวจสอบง่ายกว่า
เรื่อง trailing slash ที่คนมักลืม: WordPress ส่วนใหญ่ใช้ URL ที่ลงท้ายด้วย / แต่ Next.js ตั้งค่าเริ่มต้นให้ตัด / ท้ายออกแล้ว redirect ให้ ถ้าต้องการคง URL แบบเดิมไว้ ให้ตั้ง trailingSlash: true ใน next.config.js ไม่เช่นนั้นทุกหน้าจะมี redirect เพิ่มอีกหนึ่งชั้น และอาจกลายเป็นลูกโซ่เมื่อรวมกับ redirect อื่น ควรทดสอบให้แน่ใจว่าแต่ละ URL เก่าถึงปลายทางใน redirect ครั้งเดียว
ขั้นที่ 6: ทำให้หน้าใหม่ได้ SEO เท่าเดิมหรือดีกว่า
หน้าที่ URL ตรงกันแต่เนื้อหาหรือโครงสร้างเปลี่ยน ก็ทำให้อันดับขยับได้ ตรวจรายการนี้ทุกหน้าสำคัญ
- ✦Title และ Meta Description: ใช้ค่าเดิมจาก WordPress ไม่ใช่ค่าเริ่มต้น
- ✦Canonical: ชี้ไปที่ URL ใหม่ของตัวเอง
- ✦หัวข้อ (H1, H2) และเนื้อหา: คงโครงสร้างและข้อความหลักไว้
- ✦Structured data: ถ้าเว็บเดิมมี schema (บทความ องค์กร FAQ) ต้องสร้างใหม่ให้ครบ เพราะ schema ที่หายไปตอนย้ายเป็นสาเหตุที่พบบ่อยของการเสีย rich result
- ✦ลิงก์ภายใน: แก้ให้ชี้ URL ใหม่ตรง ๆ ไม่ปล่อยให้พึ่ง redirect
- ✦Sitemap และ robots.txt: สร้างไฟล์ใหม่ และเช็กว่า robots.txt ไม่ได้บล็อกหน้าสำคัญ
- ✦HTML ที่ render จริง: เนื้อหาต้องอยู่ใน HTML ที่เซิร์ฟเวอร์ส่งมา ไม่ใช่โหลดฝั่งเบราว์เซอร์อย่างเดียว
ตัวอย่างการตั้ง metadata ให้หน้าบทความใน App Router
// app/blog/[slug]/page.tsx
import type { Metadata } from 'next'
type Props = { params: Promise<{ slug: string }> }
export async function generateMetadata({ params }: Props): Promise<Metadata> {
const { slug } = await params
const post = await getPost(slug) // ดึงจาก CMS, ฐานข้อมูล หรือไฟล์ที่ย้ายมา
return {
title: post.seoTitle ?? post.title, // ใช้ SEO Title เดิมจาก WordPress ก่อน
description: post.seoDescription,
alternates: { canonical: `https://www.example.com/blog/${slug}` },
}
}
ขั้นที่ 7: ทดสอบบน staging
ก่อนเปิดจริง ให้ทดสอบบนเว็บทดลองที่มี redirect ชุดเดียวกัน
- 1.ทดสอบ redirect ทั้งรายการ ตรวจว่าแต่ละ URL เก่าตอบรหัสถาวรและไปถึงปลายทางที่ถูกต้อง ไม่เป็นลูกโซ่หลายชั้นและไม่วนลูป
- 2.เปรียบเทียบ HTML ของหน้าสำคัญระหว่างเว็บเก่าและเว็บใหม่ ดู title, canonical, หัวข้อ และ schema
- 3.เช็กว่าลบ
noindex ของ staging ออกแล้ว และ robots.txt ของเว็บจริงไม่บล็อกเว็บทั้งหมด ข้อนี้พลาดบ่อยมากเพราะ staging มักตั้งไม่ให้ Google เก็บ - 4.ทดสอบบนมือถือ และวัดความเร็วซ้ำ
สคริปต์ตรวจ redirect จากไฟล์ CSV (คอลัมน์ URL เก่า,URL ปลายทางที่คาดหวัง)
while IFS=, read -r old expected; do
result=$(curl -s -o /dev/null -w "%{http_code} %{redirect_url}" "https://www.example.com$old")
echo "$old => $result (คาดหวัง $expected)"
done < redirect-map.csv
ผลที่ต้องการคือรหัส 301 หรือ 308 พร้อม URL ปลายทางที่ตรงกับคอลัมน์ที่สอง ถ้าเจอ 200 ตรง ๆ แปลว่าหน้าเก่ายังอยู่ ถ้าเจอ 404 แปลว่าลืมจับคู่ และถ้าเจอ 307 แปลว่าตั้ง permanent: false ไว้
ขั้นที่ 8: เปิดตัวและติดตามผล
วันเปิดตัวให้ทำตามลำดับนี้
- 1.เปิดใช้ redirect และสลับ DNS ไปที่เว็บใหม่
- 2.ส่ง sitemap ใหม่ใน Search Console
- 3.ใช้ URL Inspection ตรวจหน้าสำคัญไม่กี่หน้า ดูว่า Google เห็น canonical ที่ถูกต้อง
- 4.คลิกดูเว็บจริงบนมือถือและเดสก์ท็อป
หลังเปิดตัว Google แนะนำให้เก็บ redirect ไว้อย่างน้อย 180 วัน และนานกว่านั้นถ้ายังเห็นทราฟฟิกจาก Google เข้ามาที่ URL เก่า และบอกว่าการเปลี่ยน URL ใช้เวลาหลายเดือนกว่า Google จะประมวลผลครบ ตามที่ John Mueller เคยอธิบายไว้ ดังนั้นการที่ตัวเลขผันผวนในช่วงแรกไม่ได้แปลว่าล้มเหลว สิ่งที่ควรดูทุกสัปดาห์ในช่วง 1–2 เดือนแรกคือ
- ✦รายงานการจัดทำดัชนี (Indexing) ใน Search Console ว่ามีหน้าที่ขึ้น "Not found (404)" หรือ "Page with redirect" เกินคาดไหม
- ✦จำนวนคลิกและการแสดงผลเทียบกับตัวเลขที่บันทึกไว้ในขั้นที่ 2
- ✦หน้า 404 ในเว็บเอง และข้อผิดพลาดของ redirect
ถ้าย้ายโดเมนด้วย ให้ใช้เครื่องมือ Change of Address ใน Search Console เพิ่มเติม แต่ถ้า URL หลักไม่เปลี่ยนโดเมน และแค่ย้ายแพลตฟอร์ม ไม่จำเป็นต้องใช้
สิ่งที่มักพลาดตอนย้ายเว็บ
- ✦ส่ง URL เก่าทั้งหมดไปหน้าแรก แทนที่จะจับคู่ทีละหน้า
- ✦ใช้ redirect ชั่วคราว (302 หรือ 307) กับการย้ายถาวร ทำให้สัญญาณขัดแย้งกัน
- ✦ลืมไฟล์สื่อ รูปและ PDF ที่มี backlink จากเว็บอื่นยังต้องเปิดได้
- ✦ลืม schema และ canonical ทำให้หน้าใหม่ดูต่างจากหน้าเก่าในสายตาของ Google
- ✦เปิดเว็บใหม่ทั้งที่ staging ยังมี noindex ทำให้ Google ไม่เก็บหน้าใหม่เลย
- ✦เปลี่ยนเนื้อหาและ URL พร้อมกัน ถ้าเปลี่ยนสองอย่างพร้อมกัน จะหาสาเหตุไม่ได้เมื่ออันดับตก ควรย้ายก่อน ปรับเนื้อหาทีหลัง
- ✦ไม่ได้บันทึกตัวเลขก่อนย้าย ทำให้เทียบผลไม่ได้
ค่าใช้จ่ายและเวลา
ราคาย้ายเว็บขึ้นกับจำนวนหน้า ความซับซ้อนของเนื้อหา และแบบที่เลือกจาก 3 แบบ ตัวเลขที่ตายตัวจึงไม่เหมาะกับทุกเว็บ ควรขอใบเสนอราคาหลังให้ผู้รับจ้างดูรายการ URL จริง ข้อมูลช่วงราคาเว็บไซต์ทั่วไปอยู่ในทำเว็บไซต์ราคาเท่าไหร่ 2026
ค่าใช้จ่ายรายปีที่ต้องรวมไว้ในงบ ถ้าวางเว็บเชิงพาณิชย์บน Vercel ต้องใช้แพ็กเกจ Pro ที่เริ่ม 20 ดอลลาร์ต่อผู้ใช้ต่อเดือน เพราะแพ็กเกจ Hobby ใช้ได้เฉพาะงานส่วนตัว และถ้าย้ายเนื้อหาไปฐานข้อมูล เช่น Supabase ก็มีค่า Pro เริ่ม 25 ดอลลาร์ต่อเดือน ดูรายละเอียดในSupabase คืออะไร
ก่อนจ้าง ให้ตกลงเรื่องเหล่านี้ให้ชัด
- 1.ราคารวมการตั้ง redirect ครบทุก URL และการทดสอบหรือไม่
- 2.รวมการย้าย SEO Title และ Meta Description เดิมหรือไม่
- 3.มีเวลาติดตามผลหลังเปิดตัวกี่เดือน และมีเงื่อนไขแก้ไขอะไรบ้าง
- 4.โดเมน บัญชีโฮสติ้ง และซอร์สโค้ดอยู่ในชื่อใคร
คำถามที่พบบ่อย
อาจตกชั่วคราวได้ แม้ทำถูกวิธี เพราะ Google ต้องประมวลผล URL ใหม่ แต่ถ้า redirect ครบ เนื้อหาและ metadata คงเดิม อันดับมักกลับมาใกล้เคียงเดิมภายในไม่กี่เดือน ตามที่ Google ระบุ redirect ถาวรไม่ทำให้สูญเสีย PageRank ส่วนความเสี่ยงสูงสุดคือเปลี่ยน URL แล้วไม่ตั้ง redirect
ทั้งคู่เป็นสัญญาณถาวรสำหรับ Google ใน Next.js ตั้ง permanent: true จะได้ 308 ซึ่งใช้ได้เหมือน 301 ในทางปฏิบัติ
ได้ ถ้าเลือกแบบ headless WordPress ที่ใช้ WordPress เป็นที่เก็บเนื้อหา และให้ Next.js ดึงมาแสดงผลผ่าน REST API ข้อแลกคือต้องดูแลสองระบบ และปลั๊กอินที่ทำงานฝั่งหน้าเว็บส่วนใหญ่จะใช้ไม่ได้
ขึ้นกับจำนวนหน้าและความซับซ้อน เว็บเล็กที่ไม่มีฟีเจอร์เฉพาะใช้เวลาน้อย ส่วนเว็บที่มีบทความหลายร้อยชิ้น ร้านค้า หรือระบบสมาชิก ใช้เวลานานกว่ามาก ควรให้ผู้รับจ้างประเมินจากรายการ URL และฟีเจอร์ที่ใช้อยู่จริง
ได้ แต่เป็นงานใหญ่กว่าเว็บบทความมาก เพราะต้องสร้างตะกร้า การชำระเงิน การจัดการออเดอร์ และสต็อกใหม่ หรือเชื่อมกับบริการอื่น ควรประเมินแยกต่างหากว่าคุ้มกว่าการอยู่กับ WooCommerce หรือไม่
ไม่ต้องแจ้งโดยตรงถ้าแค่ย้ายแพลตฟอร์มในโดเมนเดิม สิ่งที่ควรทำคือส่ง sitemap ใหม่ ตรวจหน้าสำคัญด้วย URL Inspection และตั้ง redirect ให้ครบ ถ้าเปลี่ยนโดเมนด้วย ให้ใช้เครื่องมือ Change of Address ใน Search Console
สรุป
การย้ายเว็บจาก WordPress ไป Next.js ที่ปลอดภัยต่ออันดับเริ่มจาก 3 อย่าง คือ ทำรายการ URL ให้ครบ จับคู่ URL เก่ากับใหม่ทีละหน้า และตั้ง redirect ถาวรพร้อมทดสอบก่อนเปิดจริง หลังเปิดตัวให้ติดตามใน Search Console อย่างน้อย 2–3 เดือน และเก็บ redirect ไว้ไม่ต่ำกว่า 180 วัน
ถ้าอยากให้ช่วยประเมินว่าเว็บของคุณควรย้ายหรือไม่ และแบบไหนเหมาะ ดูรายละเอียดและขอใบเสนอราคาได้ที่หน้ารับทำเว็บไซต์และเว็บแอปด้วย Next.js โดยเตรียมลิงก์เว็บปัจจุบันและข้อมูลจาก Search Console ไว้จะช่วยให้ประเมินได้แม่นขึ้น
