แก้ SEO หลังย้าย WordPress มา Astro: การเปลี่ยนเส้นทาง แผนผังเว็บไซต์ และ GSC

หลังย้ายเว็บจาก WordPress มา Astro คุณจะสร้างเว็บไซต์ได้เร็วขึ้น โหลดเร็วขึ้น และมีค่าโฮสต์ลดลง แต่หาก URL ของบล็อกเปลี่ยนระหว่างการย้าย เช่น จาก /post-slug/ เป็น /insights/post-slug คุณอาจมีปัญหา SEO ที่ปรากฏหลายสัปดาห์ต่อมา เมื่อ Google รวบรวมข้อมูลเว็บไซต์ซ้ำเสร็จ

Google Search Console จะเริ่มส่งอีเมลแจ้งเรื่อง "Duplicate, Google chose different canonical than user" และ "Not found (404) validation failed" หน้าที่เคยทำผลงานได้ดีอาจผ่านการเปลี่ยนเส้นทางหลายขั้นโดยไม่จำเป็น และคุณอาจกำลังดูแลแผนผังเว็บไซต์สองชุดที่มีเนื้อหาซ้อนทับกันอยู่โดยไม่รู้ตัว

คู่มือนี้ครอบคลุมวิธีค้นหาและแก้ไขปัญหาเหล่านี้ทั้งหมด เราเจอทุกปัญหาที่กล่าวถึงระหว่างการจัดการปัญหา SEO หลังย้ายเว็บ WordPress มา Astro และได้บันทึกวิธีแก้ไขไว้ที่นี่

สิ่งที่คุณต้องมี

สิทธิ์เข้าถึงเซิร์ฟเวอร์ผ่าน SSH (สำหรับตั้งค่า nginx)
สิทธิ์เข้าถึง Google Search Console สำหรับพร็อพเพอร์ตีของคุณ
curl ติดตั้งไว้ในเครื่อง
เครื่องมือวิเคราะห์ข้อมูลผู้เข้าชม (เราใช้ Plausible ที่ติดตั้งและดูแลเอง)

ปัญหาที่จะได้รับการแก้ไข

ลดการเปลี่ยนเส้นทางต่อกันหลายขั้น (2 ขั้นขึ้นไป) ให้เหลือ 301 ขั้นเดียว
รวมแผนผังเว็บไซต์ที่ซ้ำกันให้เหลือแหล่งเดียวที่สร้างอัตโนมัติ
นำหน้าที่ติด noindex ออกจากแผนผังเว็บไซต์
ล้างพร็อพเพอร์ตี GSC เก่าและแผนผังเว็บไซต์ WordPress ที่ค้างอยู่
แก้ความสับสน canonical ระหว่างโครงสร้าง URL เก่าและใหม่

ขั้นตอนที่ 1: วินิจฉัยการเปลี่ยนเส้นทางต่อกันหลายขั้น

ตรวจว่า URL ที่มีผู้เข้าชมมากต้องผ่านการเปลี่ยนเส้นทางกี่ครั้ง หาก URL ของ WordPress มีเครื่องหมาย / ท้าย URL แต่ของ Astro ไม่มี อาจเกิดสองขั้น: ขั้นแรกตัดเครื่องหมาย / และขั้นที่สองเพิ่มส่วนต้นของเส้นทางใหม่

curl -sL -w "Hops: %{num_redirects}, Final: %{http_code}, URL: %{url_effective}\n" \
  -o /dev/null "https://yourdomain.com/old-post-slug/"

ถ้าผลลัพธ์แสดง Hops: 2 แสดงว่าคุณมีการเปลี่ยนเส้นทางต่อกันหลายขั้นให้รันคำสั่งนี้กับ 5 หน้าที่มีผู้เข้าชมสูงสุด เพราะนั่นคือหน้าที่ขั้นตอนการเปลี่ยนเส้นทางส่วนเกินส่งผลกระทบมากที่สุด

ตรวจเทียบกับข้อมูลวิเคราะห์ผู้เข้าชมด้วย หากบทความเดียวกันปรากฏภายใต้ URL หลายรูปแบบ ทั้งมี / ไม่มี / และมีส่วนต้นใหม่ แสดงว่าการเปลี่ยนเส้นทางยังไม่ได้รวมผู้เข้าชมไว้ที่เดียว เราพบบทความยอดนิยมแยกเป็นสามรูปแบบ URL ใน Plausible ซึ่งทำให้เราเริ่มตรวจสอบการเปลี่ยนเส้นทางตามวิธีข้างต้น

ขั้นตอนที่ 2: ตั้งค่า nginx ให้เปลี่ยนเส้นทางขั้นเดียว

กฎมาตรฐานของ nginx สำหรับตัดเครื่องหมาย / ท้าย URL มีดังนี้:

location ~ ^(.+)/$ { return 301 $1; }

กฎนี้ตัดเครื่องหมาย / แต่ไม่รู้ว่าเส้นทางบล็อกเปลี่ยน คำขอจึงไปถึงกฎที่สองซึ่งเปลี่ยนเส้นทาง /slug ไป /insights/slug รวมเป็นสองขั้น

แทนที่ด้วยกฎที่รองรับเส้นทางบล็อก โดยตรวจว่า slug ตรงกับบทความหรือไม่ แล้วเปลี่ยนเส้นทางไป URL ปลายทางโดยตรง:

# Blog slugs with trailing slash — single-hop to /insights/
location ~ ^/([^/]+)/$ {
    set $slug $1;
    if (-f /usr/share/nginx/html/insights/$slug/index.html) {
        return 301 https://www.yourdomain.com/insights/$slug;
    }
    return 301 https://www.yourdomain.com/$slug;
}
# Multi-segment paths — just strip the slash
location ~ ^(.+)/$ { return 301 https://www.yourdomain.com$1; }

กฎแรกจัดการ slug ระดับราก ซึ่งเป็น URL บล็อก WordPress เดิม ตรวจว่ามีหน้าตรงกันใต้ /insights/ หรือไม่ แล้วเปลี่ยนเส้นทางไปโดยตรง เส้นทางระดับรากอื่น ๆ จะได้รับการเปลี่ยนเส้นทางเพียงครั้งเดียวเพื่อตัดเครื่องหมาย / ท้ายเส้นทางด้วยกฎเดียวกัน ส่วนเส้นทางที่มีหลายส่วนจะตรงกับกฎทั่วไปข้อที่สอง หลังนำขึ้นใช้งานให้ตรวจดังนี้:

curl -sL -w "Hops: %{num_redirects}\n" -o /dev/null \
  "https://yourdomain.com/your-top-post-slug/"
# Expected: Hops: 1

ขั้นตอนที่ 3: รวมแผนผังเว็บไซต์ให้เป็นหนึ่งเดียว

ตรวจสอบว่าคุณมีแผนผังเว็บไซต์มากกว่าหนึ่งตัวหรือไม่ รูปแบบที่พบบ่อยหลังการย้าย: sitemap.xml แบบสแตติกที่สร้างเองระหว่างย้าย บวกกับ sitemap-index.xml ที่สร้างอัตโนมัติจากส่วนเชื่อมต่อ @astrojs/sitemap ของ Astro

# Check both
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1

ถ้าทั้งสองคืนค่า 200 แสดงว่าคุณกำลังดูแลแผนผังเว็บไซต์สองชุดที่อาจมีข้อมูลไม่ตรงกันในภายหลัง ตรวจสอบว่า robots.txt อ้างอิงอันไหน:

curl -s "https://yourdomain.com/robots.txt" | grep -i sitemap

วิธีแก้: ลบ sitemap.xml แบบสแตติกออกจากไดเรกทอรี public/ อัปเดต robots.txt ให้ชี้ไปที่ sitemap-index.xml และปล่อยให้ส่วนเชื่อมต่อของ Astro จัดการทุกอย่าง บทความใหม่จะปรากฏในแผนผังเว็บไซต์โดยอัตโนมัติทุกครั้งที่สร้างเว็บไซต์

ตรวจด้วยว่าแผนผังเว็บไซต์แบบสแตติกมีหน้าที่กำหนด noindex หรือไม่ หาก sitemap.xml ระบุหน้าอย่าง /legal หรือ /privacy-policy ที่มี <meta name="robots" content="noindex"> จะส่งสัญญาณขัดแย้งให้ Google แผนผังเว็บไซต์จาก @astrojs/sitemap สามารถตั้งกฎการกรองเพื่อไม่รวมหน้าเหล่านี้ได้อย่างถูกต้อง

ขั้นตอนที่ 4: จัดการ Google Search Console

เปิด GSC และตรวจสอบสองสิ่ง: พร็อพเพอร์ตีและแผนผังเว็บไซต์

พร็อพเพอร์ตี: หากมีทั้งแบบโดเมน (sc-domain:yourdomain.com) และแบบคำนำหน้า URL (https://www.yourdomain.com/) คุณจะได้รับแจ้งปัญหาเดิมซ้ำ คุณสามารถเก็บไว้ทั้งสองแบบได้ แต่หากอีเมลซ้ำรบกวนการทำงาน ให้เลือกแบบเดียว หากโดเมนย่อยเป็นโครงการแยก แบบคำนำหน้า URL จะตรงประเด็นกว่า เพราะรายงานเฉพาะ URL ภายใต้คำนำหน้าที่ตรงกันทุกตัวอักษร เช่น URL บนโฮสต์ www ของระบบใช้งานจริง

แผนผังเว็บไซต์: ไปที่ Indexing → Sitemaps ลบแผนผังเว็บไซต์ WordPress เดิมที่ยังลงทะเบียนไว้ เช่น post-sitemap.xml, page-sitemap.xml, sitemap-post-type-product.xml จากนั้นส่ง sitemap-index.xml ใหม่เป็นแผนผังเว็บไซต์เพียงชุดเดียว

การตรวจสอบการแก้ไข 404: ไปที่ Indexing → Pages → “Not found (404)” แล้วตรวจ URL ที่แสดง หากเป็นเส้นทาง WordPress เดิมที่ไม่มีและไม่ควรมีแล้ว เช่น หน้าสินค้า WooCommerce หน้าผู้เขียน หรือ URL ฟีด Google จะค่อย ๆ นำออกจากดัชนี หากเป็นบทความที่ควรเปลี่ยนเส้นทาง ต้องแก้กฎ nginx หลังแก้แล้วคลิก “Validate Fix” เพื่อให้รวบรวมข้อมูลอีกครั้ง

ขั้นตอนที่ 5: ตรวจสอบทุกอย่าง

ตรวจรายการต่อไปนี้หลังนำการแก้ไขขึ้นใช้งาน:

# 1. Redirect chains resolved
curl -sL -w "Hops: %{num_redirects}, URL: %{url_effective}\n" \
  -o /dev/null "https://yourdomain.com/your-top-post/"
# Expected: Hops: 1, URL ends in /insights/your-top-post

# 2. robots.txt points to generated sitemap
curl -s "https://yourdomain.com/robots.txt" | grep sitemap
# Expected: sitemap-index.xml

# 3. Old static sitemap returns 404
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
# Expected: 404

# 4. Generated sitemap returns 200
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
# Expected: 200

# 5. Non-www redirects to www
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" \
  "https://yourdomain.com/insights"
# Expected: 301 https://www.yourdomain.com/insights

Google ต้องใช้เวลานานแค่ไหนในการอัปเดต

การเปลี่ยนเส้นทางขั้นเดียวมีผลทันทีสำหรับการรวบรวมข้อมูลครั้งถัดไป การเปลี่ยนแผนผังเว็บไซต์ใช้เวลาไม่กี่วันกว่า Google จะรับรู้ ส่วนความสับสน canonical ที่ Google ยังเลือก URL เก่าแทน URL ใหม่นั้นต้องใช้เวลานานกว่า Google มองแท็ก <link rel="canonical"> เป็นเพียงคำแนะนำ ไม่ใช่คำสั่งที่บังคับ ถ้า URL เก่ามีลิงก์ย้อนกลับและข้อมูลคลิกสะสมมากกว่า Google อาจยังเลือกเป็น canonical ต่ออีกหลายสัปดาห์

การเปลี่ยนเส้นทางที่ชัดเจนและแผนผังเว็บไซต์หลักเพียงชุดเดียวช่วยส่งสัญญาณชัดที่สุดให้ Google ส่วนการรวมพร็อพเพอร์ตี GSC ช่วยให้ติดตามรายงานที่เหลือได้ง่ายขึ้น ในกรณีของเรา คำเตือน “Duplicate canonical” เริ่มลดลงภายในสองสัปดาห์หลังนำการแก้ไขเหล่านี้ขึ้นใช้งาน

เราดูแลการย้ายลักษณะนี้เป็นประจำในงานปรับประสิทธิภาพและย้ายระบบ WordPress หากคุณมีปัญหา SEO หลังย้ายเว็บ ติดต่อเรา