301 redirect กับ 302 redirect ต่างกันยังไง ใช้ตอนไหนให้ถูก

301 redirect กับ 302 redirect ต่างกันยังไง

ต่างกันที่สัญญาณ "ถาวรหรือชั่วคราว" ที่ส่งให้เบราว์เซอร์และ crawler ซึ่งนำไปสู่ผลลัพธ์คนละแบบในดัชนีของ Google ตัว 301 (Moved Permanently) สั่งให้จำ URL ใหม่แล้วเลิกสนใจของเดิม ส่วน 302 (Found) บอกว่าให้ไปที่ปลายทางไปก่อนแต่ของจริงยังอยู่ที่ URL เดิม

ผลตามมาในทางปฏิบัติต่างกันชัดเจน เมื่อเจอ 301 เบราว์เซอร์จะแคชผลไว้นาน ครั้งต่อไปที่ผู้ใช้พิมพ์ URL เดิมมันอาจกระโดดไปปลายทางเลยโดยไม่ยิงถามเซิร์ฟเวอร์ซ้ำ ส่วนฝั่ง Google จะค่อยๆ ถอด URL เดิมออกจากดัชนีแล้วยก URL ปลายทางขึ้นมาเป็นตัวที่แสดงและจัดอันดับแทน

ในทางกลับกัน 302 เบราว์เซอร์จะไม่แคช ทุกครั้งที่เรียกยังต้องถามเซิร์ฟเวอร์ใหม่ และ Google จะยังเก็บ URL เดิมไว้เป็นตัวหลักในดัชนี ถือว่าปลายทางเป็นแค่ที่ยืนชั่วคราว ความต่างที่แท้จริงของ 301 กับ 302 จึงเป็นเรื่องว่า Google จะเก็บ URL ไหนไว้ในดัชนี ไม่ใช่เรื่องว่าส่งพลัง SEO ไปได้กี่เปอร์เซ็นต์

แล้วตกลงตัวไหนดีกว่ากัน

ไม่มีตัวไหนดีกว่ากันในตัวเอง มันคือคำสั่งคนละความหมายที่ตอบคนละคำถาม คำถามเดียวที่ต้องตอบก่อนเลือกคือ "URL เดิมจะกลับมาใช้อีกไหม" ถ้าคำตอบคือไม่กลับแล้วให้ใช้ 301 ถ้าคำตอบคือกลับแน่ๆ ในเวลาที่กำหนดได้ให้ใช้ 302

ที่คนมักตอบผิดคือกรณีคลุมเครือ เช่น เอาหน้าสินค้าที่ของหมดไปหน้าหมวดหมู่ ถ้าสินค้าตัวนั้นจะกลับมาขายในอีกไม่กี่สัปดาห์ 302 คือคำตอบที่ตรงความจริงกว่า แต่ถ้าเลิกขายถาวรแล้วต้องเป็น 301 การตอบตามความจริงของธุรกิจคือวิธีที่ปลอดภัยที่สุด ไม่ต้องเดาว่า Google ชอบอะไร

redirect ส่งต่อพลัง SEO ครบไหม หรือหายระหว่างทาง

ส่งครบทุกแบบ Google ยืนยันมาตั้งแต่ปี 2016 แล้วว่า 3xx redirect ทุกชนิดรวมทั้ง 301 และ 302 ส่งต่อ PageRank กับ link equity เต็มจำนวนเท่ากัน ความเชื่อเก่าที่ว่ามีแต่ 301 เท่านั้นที่รักษาพลังลิงก์ไว้ได้เป็นความเข้าใจที่ล้าสมัยไปแล้ว

จุดที่หลายคนพลาดคือเอาข้อเท็จจริงข้อนี้ไปสรุปต่อว่า "งั้นใช้อะไรก็ได้" ซึ่งไม่จริง เพราะพฤติกรรมของดัชนีต่างกันชัดเจน การส่งพลังลิงก์ครบไม่ได้ช่วยอะไรถ้า Google ยังเลือกโชว์ URL เก่าที่คุณตั้งใจจะเลิกใช้ ผลค้นหาที่ผู้ใช้เห็นก็ยังเป็นของเก่าอยู่ดี

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

ควรใช้ 301 redirect ตอนไหน

ใช้ 301 ทุกครั้งที่การย้ายนั้นถาวรและไม่มีแผนจะกลับไปใช้ URL เดิมอีก นี่คือกรณีส่วนใหญ่ของงาน SEO ในชีวิตจริง

สังเกตว่าทุกข้อในรายการข้างล่างมีจุดร่วมเดียวกันคือ URL เดิมจะไม่มีวันกลับมาเป็นหน้าจริงอีก ถ้าสถานการณ์ของคุณเข้าเงื่อนไขนี้ให้ใช้ 301 โดยไม่ต้องลังเล

• ย้ายโดเมนถาวร เช่น เปลี่ยนชื่อแบรนด์แล้วย้ายทั้งเว็บไปโดเมนใหม่
• รวมหลายโดเมนหรือหลายเว็บย่อยเข้าเป็นเว็บเดียว
• เปลี่ยนจาก HTTP เป็น HTTPS ทั้งเว็บ
• รวมเวอร์ชัน www กับ non-www ให้เหลือรูปแบบเดียว
• เปลี่ยนโครงสร้าง URL ถาวร เช่น เลิกใช้ /p=123 มาเป็น slug ที่อ่านออก
• ลบหน้าเก่าทิ้งแล้วมีหน้าใหม่ที่เนื้อหาใกล้เคียงมารับแทนอย่างถาวร

ควรใช้ 302 redirect ตอนไหน

ใช้ 302 เมื่อการย้ายมีวันหมดอายุที่ชัดเจนและ URL เดิมจะกลับมาเป็นหน้าจริงอีกครั้ง เป้าหมายคือบอก Google ว่าอย่าเพิ่งเปลี่ยนตัวหลักในดัชนี เพราะเดี๋ยวของเดิมกลับมา

กรณีใช้งานจริงของ 302 แคบกว่าที่หลายคนคิดมาก ถ้าไล่รายการข้างล่างแล้วไม่มีข้อไหนตรงกับงานของคุณเลย ส่วนใหญ่แปลว่าคุณควรใช้ 301

ข้อควรระวังคือ 302 ที่ปล่อยทิ้งไว้นานหลายเดือน Google มักจะเริ่มตีความเองว่าเป็นการย้ายถาวรแล้วอัปเดตดัชนีตาม แต่ไทม์ไลน์เรื่องนี้ไม่แน่นอนและ Google ไม่เคยประกาศเกณฑ์อย่างเป็นทางการ การพึ่งพฤติกรรมนี้จึงเท่ากับรอฟรีๆ โดยไม่รู้ว่าต้องรอกี่เดือน สู้ตั้งให้ถูกตั้งแต่แรกดีกว่า

• แคมเปญหรือโปรโมชันตามฤดูกาลที่มีกำหนดจบชัดเจน แล้วหน้าเดิมจะกลับมา
• ทำ A/B test ที่ต้องสลับผู้ใช้ไปดูอีกเวอร์ชันชั่วคราว
• หน้าปิดปรับปรุงหรือ maintenance ที่ตั้งใจเปิดกลับในไม่กี่วัน
• การรีดีไซน์แบบทยอยปล่อยทีละส่วนที่ยังไม่สรุปว่าจะใช้โครงใหม่แน่หรือไม่
• สินค้าหมดสต๊อกชั่วคราวที่จะกลับมาขายอีกในเวลาอันใกล้

307 กับ 308 คืออะไร ต้องเปลี่ยนไปใช้แทน 301 กับ 302 ไหม

307 (Temporary Redirect) และ 308 (Permanent Redirect) คือเวอร์ชันเข้มงวดของ 302 และ 301 ตามลำดับ ความต่างอยู่ที่มันห้ามเปลี่ยน HTTP method ระหว่างทาง เช่น ถ้าผู้ใช้ส่ง POST มาปลายทางต้องได้ POST ต่อ ไม่ถูกแปลงเป็น GET เหมือนที่ 301 กับ 302 บางระบบทำ

ในแง่ SEO ไม่ต้องกังวล เอกสารทางการ Redirects and Google Search ของ Google จัด 301 กับ 308 เป็น permanent redirect เหมือนกัน และจัด 302 กับ 307 เป็น temporary redirect เหมือนกัน ดังนั้นถ้าระบบของคุณส่ง 308 ออกมาแทน 301 อยู่แล้วก็ไม่ต้องไปดัดให้เป็น 301 เพื่อ SEO

เหตุผลเดียวที่ยังมีคนเลือก 301 แท้ๆ คือความเข้ากันได้กับ HTTP client รุ่นเก่าบางตัวที่ไม่รู้จัก 308 ซึ่งเป็นเรื่องของความเข้ากันได้ของระบบ ไม่ใช่เรื่องอันดับ

ทำไมเว็บ Next.js บน Vercel ถึงคืน 308 ไม่ใช่ 301

เพราะเป็นค่าเริ่มต้นของแพลตฟอร์ม เมื่อประกาศ redirect ในไฟล์ next.config.js ผ่านฟังก์ชัน redirects() แล้วตั้ง permanent เป็น true ระบบจะคืนสถานะ 308 ให้ ส่วนตั้ง permanent เป็น false จะได้ 307 ถ้าเห็นเครื่องมือ SEO รายงานว่าเว็บคืน 308 ไม่ใช่ 301 นั่นคือพฤติกรรมปกติ ไม่ใช่บั๊กและไม่ใช่ปัญหา SEO

ถ้าจำเป็นต้องได้ 301 แท้ๆ จริงๆ เช่น มีระบบภายนอกเก่าที่อ่าน 308 ไม่ออก ก็ระบุ statusCode เป็น 301 ในกฎของ redirects() แทนการใช้ permanent ได้เลย หรือจะประกาศใน vercel.json ก็ได้ แต่ควรทำเมื่อมีเหตุผลทางเทคนิคชัดเจนเท่านั้น

ใช้ 302 แทน 301 แล้วเสีย SEO ไหม

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

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

ทางแก้ตรงไปตรงมาคือเปลี่ยนเป็น 301 แล้วรอให้บอตกลับมาเก็บอีกรอบ โดยทั่วไปการย้ายดัชนีหลังตั้ง 301 ใช้เวลาไม่กี่วันถึงไม่กี่สัปดาห์ ขึ้นกับว่า Google มาเก็บหน้านั้นบ่อยแค่ไหน ถ้าเว็บใหญ่และอัปเดตบ่อยก็เร็ว ถ้าเป็นหน้าที่แทบไม่มีใครลิงก์หาเลยก็อาจนานกว่านั้น

ตั้ง redirect ยังไงในแต่ละแพลตฟอร์ม

หลักการเดียวที่ใช้ได้ทุกที่คือทำที่ระดับเซิร์ฟเวอร์หรือระดับ config ให้มากที่สุด เพราะเป็นวิธีที่เร็วที่สุดและส่งสัญญาณชัดที่สุดให้ทั้งผู้ใช้และบอต

รายละเอียดต่างกันตามแพลตฟอร์ม แต่สิ่งที่ต้องเช็คเหมือนกันหมดคือหลังตั้งเสร็จต้องยิงทดสอบดูสถานะจริงที่ได้กลับมา ไม่ใช่เชื่อหน้าจอตั้งค่า

Apache กับไฟล์ .htaccess

ใช้คำสั่ง Redirect 301 /old-page /new-page สำหรับ URL รายตัว หรือใช้ RewriteRule คู่กับแฟล็ก R=301,L เมื่อต้องจับรูปแบบเป็นกลุ่ม เช่น ย้ายทั้งโฟลเดอร์หรือบังคับ HTTPS ทั้งเว็บ ข้อควรระวังคือลำดับของกฎมีผล กฎที่อยู่บนกว่าจะทำงานก่อนเสมอ

Nginx

ใช้คำสั่ง return 301 พร้อมระบุปลายทางแบบเต็มรูปแบบภายใน server block ที่รับ URL เดิม วิธีนี้เบากว่าการเขียน rewrite ซับซ้อนและอ่านง่ายกว่ามาก เหมาะกับงานบังคับ HTTPS และรวม www กับ non-www ให้เหลือรูปแบบเดียว

Next.js และ Vercel

ประกาศไว้ในฟังก์ชัน redirects() ในไฟล์ next.config.js ระบุ source, destination และ permanent ตามความหมายจริงของการย้าย ข้อดีคือกฎทั้งหมดอยู่ในโค้ดที่ผ่าน code review ได้ ไม่กระจัดกระจายอยู่ในหน้าแอดมิน และถ้าย้อนกลับก็แค่ revert commit

WordPress

ใช้ปลั๊กอินจัดการ redirect เช่น Redirection หรือฟีเจอร์ใน Yoast SEO รุ่นเสียเงิน แล้วเลือกชนิดให้ถูกระหว่าง 301 Moved Permanently กับ 302 Found ไม่ต้องไปแก้ไฟล์เซิร์ฟเวอร์เอง ข้อดีคือทีมคอนเทนต์จัดการเองได้ ข้อเสียคือกฎจำนวนมากถูกประมวลผลในชั้นแอป จึงช้ากว่าการทำที่ระดับเซิร์ฟเวอร์

ข้อผิดพลาดเรื่อง redirect ที่เจอบ่อยที่สุด

ปัญหาส่วนใหญ่ไม่ได้เกิดจากเลือกสถานะผิดอย่างเดียว แต่เกิดจากการต่อ redirect ซ้อนกันหลายชั้นและการเลือกใช้วิธีที่ไม่ใช่ระดับเซิร์ฟเวอร์

ที่ต้องระวังเป็นพิเศษคือ redirect chain ซึ่งเกิดง่ายมากเวลาเว็บผ่านการย้ายหลายรอบ ควรทำให้ทุก URL เก่าชี้ไปที่ปลายทางสุดท้ายในทีเดียว ไม่ใช่ต่อกันเป็นทอดๆ ทุก hop ที่เพิ่มขึ้นคือเวลาโหลดที่เพิ่มขึ้นและความเสี่ยงที่บอตจะเลิกตามกลางทาง

อีกกับดักที่เจอบ่อยคือการใช้ meta refresh หรือ JavaScript redirect แทนของจริง Google แนะนำให้ใช้ server-side redirect ก่อนเสมอ แล้วค่อยพึ่ง meta refresh เฉพาะเมื่อทำที่เซิร์ฟเวอร์ไม่ได้จริงๆ โดย meta refresh แบบ 0 วินาทีมักถูกตีความคล้าย 301 ส่วนแบบหน่วงเวลาถูกตีความคล้าย 302 แต่ทั้งสองแบบยังเป็นสัญญาณที่อ่อนกว่า HTTP redirect เพราะเกิดขึ้นหลังหน้าเริ่มโหลดไปแล้ว

• ใช้ 302 ทั้งที่ตั้งใจย้ายถาวร ทำให้ Google ยังยึด URL เก่าเป็นตัวหลักโดยไม่จำเป็น
• redirect chain แบบ A ไป B ไป C ไป D ควรตัดให้เหลือ A ไป D ตรงๆ
• redirect loop แบบ A ไป B แล้ว B ย้อนกลับมา A ทำให้เข้าหน้านั้นไม่ได้เลย
• แยก hop ระหว่าง http กับ https และ www กับ non-www เป็นหลายชั้น แทนที่จะรวมเป็น hop เดียว
• ปล่อยให้ทั้ง www และ non-www หรือทั้ง http และ https ใช้งานได้พร้อมกันโดยไม่ redirect เลย จนเกิดเนื้อหาซ้ำและสัญญาณกระจาย
• ตั้ง redirect ในชั้นแอปพลิเคชันทั้งที่ควรทำที่ระดับเซิร์ฟเวอร์ ทำให้ทุกคำขอต้องวิ่งผ่านโค้ดโดยไม่จำเป็น

เช็คลิสต์ก่อนและหลังตั้ง redirect

ก่อนกดใช้จริงให้ไล่รายการสั้นๆ นี้ทุกครั้ง ใช้เวลาไม่กี่นาทีแต่กันปัญหาที่ตามแก้ยากได้เกือบทั้งหมด

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

ถ้าหลังย้ายแล้วอันดับหรือทราฟฟิกร่วงผิดปกติ ให้ไล่หาสาเหตุอย่างเป็นระบบแทนการเดา โดยเริ่มจากตรวจสถานะ redirect ทุกเส้นก่อนไปโทษเรื่องอื่น

• ตอบให้ได้ก่อนว่า URL เดิมจะกลับมาใช้อีกไหม แล้วค่อยเลือกระหว่าง 301 กับ 302
• ทำแผนที่ URL เก่ากับใหม่แบบหนึ่งต่อหนึ่ง อย่าโยนทุกอย่างไปหน้าแรกเพราะขี้เกียจจับคู่
• ยิงทดสอบสถานะจริงด้วย curl หรือเครื่องมือเช็ค header แล้วดูว่าได้ 301, 302, 307 หรือ 308 ตรงตามที่ตั้งใจ
• เช็คว่าไม่มี chain เหลืออยู่ ทุก URL เก่าต้องถึงปลายทางภายใน hop เดียว
• อัปเดตลิงก์ภายในเว็บให้ชี้ URL ใหม่โดยตรง อย่าให้ลิงก์ในเมนูวิ่งผ่าน redirect
• อัปเดต sitemap ให้เหลือเฉพาะ URL ปลายทาง แล้วส่งใหม่ใน Search Console
• ตามดูรายงานการทำดัชนีต่ออีก 2 ถึง 4 สัปดาห์ เพื่อยืนยันว่า URL ใหม่ถูกเก็บและ URL เก่าค่อยๆ หายไป

สรุปและก้าวต่อไป

จำสั้นๆ แค่นี้พอ ถ้าไม่กลับมาใช้ URL เดิมอีกให้ใช้ 301 ถ้ากลับมาแน่ในเวลาที่กำหนดได้ให้ใช้ 302 ส่วน 307 กับ 308 คือเวอร์ชันเข้มงวดที่รักษา method ไว้ ซึ่ง Google มองเหมือน 302 และ 301 ตามลำดับ ไม่ต้องดัดให้เป็นเลขเดิมเพื่อ SEO

เรื่องพลังลิงก์ไม่ต้องกังวลอีกต่อไปเพราะ 3xx ส่งต่อเต็มจำนวนทุกแบบ สิ่งที่ต้องกังวลคือความสะอาดของเส้นทาง อย่าให้เกิด chain อย่าให้เกิด loop และอย่าปล่อยให้มีหลายเวอร์ชันของ URL เดียวกันเปิดใช้งานพร้อมกัน ถ้าหน้าใหม่ยังไม่ถูกเก็บเข้าดัชนีสักที ลองไล่สาเหตุตาม เช็กลิสต์เว็บไม่ติด index ดูก่อน

ถ้าเว็บของคุณมี URL เก่าค้างอยู่หลายร้อยหลายพันเส้นจนไล่เองไม่ไหว ทีม SEONo1 รับ ตรวจสุขภาพเว็บเชิงเทคนิค เพื่อหา chain, loop และ redirect ที่ตั้งผิดชนิดพร้อมแผนแก้เป็นข้อๆ ให้ทีมพัฒนาเอาไปทำต่อได้ทันที