Redirect Map Generator: แปลงคู่ URL เก่า-ใหม่เป็นไฟล์ config redirect พร้อม deploy
วางคู่ URL เก่า-ใหม่ แล้วสร้างไฟล์ config redirect สำหรับ nginx, Apache, Netlify และ Vercel ได้ทันที พร้อม export เป็น JSON และ CSV — ทำงานในเบราว์เซอร์
Table of Contents
Redirect Map Generator: แปลงคู่ URL เก่า-ใหม่เป็นไฟล์ config redirect พร้อม deploy
การย้ายเว็บไซต์ (site migration) คือจุดที่ SEO พังบ่อยที่สุด คุณเปิดตัวเวอร์ชันใหม่ที่คอนเทนต์ดีกว่า ดีไซน์ประณีตกว่า แต่ภายในหนึ่งสัปดาห์ traffic จาก search ร่วงฮวบ สาเหตุนั้นง่ายและเจ็บปวด: หน้าที่เคยอยู่ใน URL เดิมตอนนี้กลับคืน 404 ทั้งหมด ทุก backlink ทุก bookmark และทุกหน้าที่ search engine เคย index จะเจอทางตัน แล้วความน่าเชื่อถือของโดเมนก็รั่วไหลไปกับมัน
ทางแก้คือ redirect map — รายการคู่ URL เก่า-ใหม่ที่บอกเซิร์ฟเวอร์หรือ platform ปลายทางว่าแต่ละ address เก่าควรถูกส่งไปที่ไหน มันคือกรมธรรม์ประกันของ migration เมื่อ deploy map ครบ ผู้ใช้ที่เข้ามาผ่านลิงก์เก่าจะถูกพาไปหน้าใหม่อย่างเงียบ ๆ และ search engine จะโอน ranking signal ไปยังหน้าใหม่แทนที่จะถอดหน้านั้นออกจาก index
นี่คือเหตุผลที่เราสร้าง Redirect Map Generator ขึ้นมา วางคู่ URL เก่า-ใหม่ลงไป แล้วเครื่องมือจะสร้างไฟล์ config redirect พร้อมใช้งานให้ 4 platform หลักได้แก่ nginx, Apache, Netlify และ Vercel พร้อม export เป็น JSON และ CSV ทุกอย่างทำงานในเบราว์เซอร์ 100 เปอร์เซ็นต์ — ไม่ต้องอัปโหลด ไม่ต้องสมัครบัญชี
ทำไมต้องใช้ Redirect Map Generator?
- ข้ามเรื่อง syntax ที่ปวดหัว — rewrite flag ของ nginx, directive ของ Apache, รูปแบบ _redirects ของ Netlify และ schema JSON ของ Vercel ต่างกันแบบละเอียดอ่อน ใส่รายการคู่ URL เดียวแล้วเครื่องมือเรนเดอร์ให้ถูกทุกแบบ
- รักษา ranking ที่สร้างมายากน — 301 บอก search engine ว่าการย้ายนี้ถาวร ranking signal ของหน้าเก่าจึงไหลไปหน้าใหม่แทนที่จะระเหยหายไป
- ลดข้อผิดพลาดจากการพิมพ์เอง — เขียน redirect หลายร้อยเส้นด้วยมือชวนเจอ typo และสลับ source-destination ผิด การใช้ input แบบมีโครงสร้างบวก output ที่ generate ให้ทำให้ทุก rule สม่ำเสมอ
- เปลี่ยน platform โดยไม่ต้องเริ่มใหม่ — ย้ายจาก Apache ไป nginx หรือจาก VPS ไป Netlify? map เดิมสร้าง config ใหม่ให้ platform ไหนก็ได้ที่จะ deploy ต่อไป
- เก็บ source of truth ที่พกพาได้ — ไฟล์ CSV export เป็น generic และอ่านง่าย commit ไว้ใน repository แล้วสร้าง config ใหม่ได้ในไม่กี่วินาที แม้ผ่านไปหลายปี
- ข้อมูลไม่ออกจากเครื่องคุณ — redirect map อาจมี URL ของสินค้าที่ยังไม่เปิดตัว เครื่องมือทำงานฝั่ง client ล้วน ๆ path ที่อ่อนไหวจึงไม่ผ่านเซิร์ฟเวอร์ใดเลย
ฟีเจอร์หลัก
| ฟีเจอร์ | สิ่งที่ได้ |
|---|---|
| ใส่คู่ URL แบบกลุ่ม | วางคู่ URL เก่า-ใหม่หลายแถวพร้อมกัน แต่ละแถวกลายเป็นหนึ่ง rule |
| ผลลัพธ์ nginx | ไฟล์ nginx-redirects.conf พร้อมแปะใช้ |
| ผลลัพธ์ Apache | ไฟล์ .htaccess ที่ใช้ permanent Redirect directive |
| ผลลัพธ์ Netlify | ไฟล์ _redirects เรียบง่าย เรียงตามหลัก first match wins |
| ผลลัพธ์ Vercel | vercel.json ที่มี redirects array ถูกต้อง |
| Export JSON และ CSV | ไฟล์ export ตามแบบพร้อมชื่อไฟล์ของแต่ละ format |
| ทำงานในเบราว์เซอร์ | parse และจัด format ทั้งหมดในเครื่อง ไม่มีข้อมูลออกจากหน้าเว็บ |
- ชื่อไฟล์ตรง convention — ทุก export ดาวน์โหลดมาเป็น nginx-redirects.conf, .htaccess, _redirects หรือ vercel.json นำไปวางได้เลย
- ทนต่อ paste แบบรก ๆ — แถวคั่นด้วย enter, คั่นด้วยเว้นวรรคหรือ comma และบรรทัดว่าง จัดการให้หมด
- JSON สำหรับปลายทางอื่น — จุดตั้งต้นที่ดีเมื่อ platform เป้าหมายไม่ใช่สี่ตัวข้างบน
วิธีใช้งาน
- วางคู่ URL ของคุณ เพิ่ม mapping เก่า-ใหม่ทีละแถว เช่น /old-pricing ชี้ไป /pricing วางจาก spreadsheet เป็นก้อนก็ได้
- เลือก platform ปลายทาง เลือก nginx, Apache, Netlify หรือ Vercel ผลลัพธ์อัปเดตทันทีด้วย syntax และ status code ที่ถูกต้อง
- ดาวน์โหลด config เอาไฟล์ที่ generate แล้ว — nginx-redirects.conf, .htaccess, _redirects หรือ vercel.json — หรือ copy เนื้อหาไป clipboard
- นำไป deploy วางไฟล์ตามที่ platform กำหนด: path include ของ nginx, web root สำหรับ .htaccess, publish directory สำหรับ _redirects หรือ repo root สำหรับ vercel.json
- ตรวจสอบด้วย curl เช็ค URL เก่าที่ traffic เยอะ: curl -I https://example.com/old-page ต้องได้ 301 Moved Permanently พร้อม header location ที่ถูกต้อง ลองกับ URL เก่า top ten ก่อนประกาศชัย
แผนที่เดียว สี่ platform
ของจริงที่มีค่าคือ map เอง — รายการคู่ URL ธรรมดา ๆ ส่วนที่เหลือเป็นแค่การแปลงรายการนั้นไปเป็น syntax ของแต่ละ platform ลองดูว่าคู่ตัวอย่าง (/old-pricing ไป /pricing, /blog-2023 ไป /insights) เขียนออกมาแต่ละที่หน้าตาไหน
nginx ใช้ rewrite directive กับ flag permanent ซึ่งให้ผลเป็น 301 ในไฟล์ nginx-redirects.conf ที่ generate ให้:
rewrite ^/old-pricing$ /pricing permanent; rewrite ^/blog-2023$ /insights permanent;
Apache อ่านจาก .htaccess โดยรูปแบบคลาสสิกคือ Redirect directive และคำว่า permanent แทน 301:
Redirect 301 /old-pricing /pricing Redirect 301 /blog-2023 /insights
Netlify ใช้ไฟล์ _redirects แบบ flat แต่ละบรรทัดคือ source, destination และ status code ลำดับสำคัญมาก เพราะ Netlify ประมวลผลจากบนลงล่างและใช้ match แรกที่เจอ เครื่องมือจึงคงลำดับ input ของคุณไว้ ส่วน Vercel ต้องการ redirects array ใน vercel.json ที่แต่ละ entry มี source, destination และ flag permanent: true สำหรับ 301
มีสองเรื่องที่ต้องระวังเป็นพิเศษ หนึ่งคือ 301 หรือ 302 — 301 บอกเบราว์เซอร์และ search engine ว่าการย้ายถาวร และเกือบทุกครั้งคือคำตอบที่ถูกสำหรับ migration ส่วน 302 หมายถึงการย้ายชั่วคราว แต่ถ้าใช้ 302 กับการย้ายถาวร search engine จะยังเก็บ URL เก่าไว้ใน index แล้ว ranking ก็ค่อย ๆ กินตัวหาย สองคือ ลำดับและพฤติกรรม first match wins — บน engine ที่ประมวลผลตามลำดับ rule เฉพาะเจาะจงที่วางไว้หลัง rule กว้างกว่าจะไม่มีวันทำงาน วาง path เฉพาะเจาะจงไว้บน และ pattern แบบ catch-all ไว้ล่างสุด
Wildcard คือจุดที่ map เขียนมือพังบ่อยที่สุด Netlify ใช้ /old/* กับ placeholder :splat ใน destination, Vercel รองรับ path segment ส่วน nginx ใช้ regular expression Splat เหมาะสุด ๆ เวลาทั้ง section ย้ายทั้งบล็อก — /blog-2023/* ไป /insights/:splat ทำให้ทุก deep link ยังใช้ได้โดยไม่ต้องไล่ใส่ทีละบทความ ให้ splat คุมส่วนที่เหลือ แต่อย่าวาง splat ไว้บน rule ที่มันจะกลืนกิน
สุดท้าย เก็บไฟล์ CSV export ไว้เป็น source of truth ไฟล์ config มักเลื้อยจากที่ตั้งใจไว้เมื่อทีมไปแก้เซิร์ฟเวอร์ตรง ๆ ส่วน CSV ที่ commit ไว้ใน repository คือที่เดียวที่บอกว่า mapping ที่ตั้งใจไว้คืออะไร
กรณีใช้งานจริง
ย้าย platform ทั้งเว็บ
ย้ายจาก Apache บน VPS ไป Netlify หรือจาก nginx ไป Vercel คือสถานการณ์ตำราเรียน export รายชื่อ URL จาก sitemap เดิม map แต่ละ URL ไปหน้าใหม่ แล้วสร้าง config ให้ platform ปลายทาง
จัดระเบียบ slug และโครงสร้าง URL
เว็บยังอยู่ที่เดิม แต่ /products/best-widget-2024-final ต้องกลายเป็น /products/best-widget ทุก URL ที่เปลี่ยนควรมี 301 — วางคู่ slug เก่า-ใหม่ สร้าง config แล้ว deploy
รวมสองเว็บเข้าด้วยกัน
เมื่อบริษัท B ถูกดูดเข้าโดเมนของบริษัท A ทุกหน้าของ B ต้องมีปลายทางในเว็บ A สร้าง pair list เดียว แล้วใช้ CSV เป็นสัญญาร่วมระหว่างสองทีม
เกษียณ URL แคมเปญ
Microsite ตามฤดูกาลสะสมเร็วมาก เมื่อ /summer-sale-2025 เลิกใช้ แค่ map เล็ก ๆ ที่ชี้ URL แคมเปญเก่าไปหน้า evergreen ก็ทำให้ QR code และอีเมลเก่ายังใช้งานได้ แทนที่ผู้ใช้จะเจอ 404
แนวปฏิบัติที่ดี
- ใช้ 301 สำหรับการย้ายถาวร สงวน 302 ไว้กับ redirect ที่ชั่วคราวจริง ๆ เพราะ status code คือการประกาศเจตนาต่อ search engine
- หลีกเลี่ยง redirect chain ที่ยาวเกินหนึ่ง hop ชี้ URL เก่าไปปลายทางสุดท้ายตรง ๆ ทุก hop พ่วง latency เพิ่มและทำ ranking signal จางลง
- ทดสอบหน้าหลักด้วย curl -I เช็ค status code และ header location ของ URL เก่าที่มีลิงก์มากที่สุดสิบอันดับแรกหลัง deploy ทันที
- เก็บ map ไว้ใน version control commit ไฟล์ CSV เพื่อให้ mapping ตรวจสอบ ย้อนกลับ และไล่รับผิดชอบได้
- วาง rule เฉพาะเจาะจงไว้ก่อน wildcard บน platform แบบ first match wins splat ที่อยู่บน rule เฉพาะจะกลืน rule นั้นทิ้งอย่างเงียบ ๆ
- Regenerate อย่าแก้มือ แก้ที่ map แล้วสร้าง output ใหม่ทุก format — source of truth เดียวดีกว่าไฟล์ config ที่แยกกันสี่ไฟล์
พร้อมปกป้อง ranking ก่อน migration ครั้งถัดไปหรือยัง? เปิด Redirect Map Generator วางคู่ URL ของคุณ แล้วดาวน์โหลด config พร้อม deploy ได้ในไม่ถึงนาที — ทำงานในเบราว์เซอร์ล้วน ๆ
เครื่องมืออื่นที่คุณอาจสนใจ:
- Apache to Nginx Converter — แปลง rewrite rule ของ Apache เป็น syntax ของ nginx
- .htaccess Generator — สร้าง snippet config ของ Apache โดยไม่ต้องจำ directive
- Caddyfile Generator — สร้าง config สำหรับเว็บเซิร์ฟเวอร์ Caddy
ขอให้ทุก URL เก่าได้พบบ้านใหม่ที่อบอุ่น — Online Tools Forge Team
คำถามที่พบบ่อย
ถ: ข้อมูล URL ของฉันถูกอัปโหลดไปที่ไหนหรือเปล่า?
ตอบ: เปล่าครับ การ parse, จัด format และสร้างไฟล์ทั้งหมดเกิดขึ้นฝั่ง client ในเบราว์เซอร์ คู่ URL ของคุณจึงไม่ออกจากเครื่อง
ถ: ควรใช้ status code แบบไหนสำหรับ migration?
ตอบ: ใช้ 301 สำหรับการย้ายถาวร และ 302 เฉพาะ redirect ที่ชั่วคราวจริง ๆ — search engine ใช้ status code ตัดสินใจว่าจะโอน ranking signal ไปหน้าใหม่หรือไม่
ถ: ต้องดาวน์โหลดไฟล์ config ทั้งสี่ไฟล์ไหม?
ตอบ: ไม่ต้อง ดาวน์โหลดเฉพาะ format ของ platform ที่ deploy จริง ที่ทำไว้ทั้งหมดเพื่อให้ map เดิมใช้ต่อได้เมื่อวันหนึ่งคุณเปลี่ยนที่ hosting
ถ: map รองรับ wildcard redirect สำหรับทั้ง section ที่ย้ายไหม?
ตอบ: ได้ — เพิ่ม rule แบบ splat หรือ path pattern สำหรับการย้ายทั้งโฟลเดอร์ โดยวาง rule เฉพาะเจาะจงไว้ข้างบน