ฉันปล่อยอัปเดต sitemap ที่มีหน้าใหม่ประมาณ 3,000 หน้าใต้ /en/blog/... ไม่นานหลังจากนั้น Yandex Webmaster แสดงรูปแบบที่ฉันไม่คาดคิด: Yandex พยายามครอลพาธที่สอดคล้องกันใต้ /blog/... โดยไม่มี prefix /en
ถ้า URL เหล่านั้นตอบ 404 ตรง ๆ ฉันอาจได้การ crawl ที่ไม่มีประโยชน์เป็นหลักพันครั้งไปยังพาธที่ไม่มีอยู่จริง โชคดีที่ฉันตั้ง 308 Redirect แบบถาวร จาก route ที่ไม่มี language prefix ไปยัง URL ภาษาอังกฤษที่ถูกต้องไว้ก่อนแล้ว
routing layer เล็ก ๆ ที่ทำหน้าที่ป้องกันนี้มีค่ากว่าที่ฉันคิดไว้มาก
สิ่งที่ฉันสังเกตได้จริง
- ฉันเผยแพร่ sitemap ที่มีหน้าใหม่ประมาณ 3,000 หน้าในโครงสร้าง
/en/blog/... - หลังจากนั้น Yandex Webmaster แสดงว่า Yandex พยายามครอล URL ที่สอดคล้องกันใน
/blog/... - พาธทางเลือกเหล่านั้นมี 308 Redirect รองรับอยู่แล้ว
- request จึงไม่จบที่ 404 แต่ถูกส่งไปยัง
/en/blog/...ที่ตั้งใจไว้
มีจุดหนึ่งที่ฉันต้องแก้จากคำอธิบายเดิม: ฉันพิสูจน์ไม่ได้ว่า Yandex “parse sitemap ผิด” ฉันเห็นพาธที่ไม่คาดคิดหลังอัปเดต sitemap จริง แต่ลำดับเวลาเพียงอย่างเดียวไม่พิสูจน์สาเหตุภายใน Search engine สามารถค้นพบ URL ได้จากหลาย signal และแหล่งข้อมูลเก่า หากไม่มีหลักฐานที่แข็งแรงกว่า สิ่งที่พูดได้อย่างแม่นยำคือ Yandex ครอลพาธที่ฉันไม่ได้คาดไว้
ความแตกต่างนี้สำคัญ Crawler ขอ URL แปลก ๆ คือ observation แต่คำอธิบายว่าทำไมมันเลือก URL นั้นเป็นอีก claim หนึ่ง
ทำไม 308 Redirect ถึงช่วยได้
logic ของฉันถือว่าพาธสั้นเป็น alias แบบถาวรของ URL ที่ localize แล้ว:
/blog/example-post -> 308 -> /en/blog/example-postดังนั้นแม้ crawler จะเข้ามาจาก URL ที่ไม่คาดคิด มันก็ยังไปถึงหน้าที่ฉันต้องการให้บริการจริง
308 Permanent Redirect คือ HTTP redirect แบบถาวรที่คง request method และ body ไว้ สำหรับ GET request ปกติของ crawler การคง method ไม่ใช่ประเด็นหลัก ในกรณีของฉันสิ่งสำคัญคือ redirect ถูกระบุว่าเป็นแบบถาวรอย่างชัดเจน เอกสารปัจจุบันของ Yandex Webmaster จัดทั้ง 301 และ 308 เป็น permanent redirect
เอกสารทางการของ Yandex Webmaster เรื่อง Redirect.
นี่ ไม่ได้หมายความ ว่า 308 ดีกว่า 301 สำหรับ SEO เสมอไป ในกรณีของฉัน 308 มีอยู่แล้วและทำหน้าที่ที่ต้องการ: URL ที่ไม่คาดคิดไม่กลายเป็นทางตัน
Redirect คือ safety net ไม่ใช่การแก้ sitemap
Redirect ช่วยจำกัดผลกระทบ แต่ไม่ได้ทำให้ crawl ที่เกินมานั้นดีขึ้น ทุก redirect ที่ไม่จำเป็นเพิ่มอีกหนึ่ง request และ hop และ rule ที่กว้างเกินไปอาจซ่อน bug ในการสร้าง URL ถ้าเราเลิกตามหาต้นตอของ URL ผิด
ถ้า sitemap เองมี URL เก่าหรือ URL ที่ redirect อยู่ สิ่งที่ควรทำคือแก้ sitemap ให้ชี้ไป final URL โดยตรง Redirect ควรใช้รองรับพาธเก่า พาธทางเลือก หรือ URL ที่ crawler ค้นพบโดยบังเอิญ ไม่ใช่ใช้แทนความถูกต้องของข้อมูล URL
ในกรณีของฉัน sitemap ใช้ /en/blog/... อยู่แล้ว 308 เพียงทำให้เว็บไซต์ทนต่อกรณีที่ crawler เข้ามาทาง /blog/... มากขึ้น
ถ้าเกิดอีก วันนี้ฉันจะตรวจอะไร
- เปิด sitemap ที่ deploy จริง ไม่เชื่อแค่ generator แต่ตรวจไฟล์ final และสุ่มดู URL จริง
- ตรวจ response สุดท้าย URL ที่ต้องการ index ควรไปถึงหน้าที่ถูกต้องโดยตรงและหลีกเลี่ยง redirect chain ที่ไม่จำเป็น
- ทดสอบ alternate path ที่คาดเดาได้ ถ้า URL เก่าหรือไม่มี prefix มีปลายทางถาวร mapping ควรชัดเจนและ one-to-one
- หลีกเลี่ยง redirect chain
A -> B -> Cตรวจยากกว่าA -> C - เทียบ crawler report กับข้อมูล server เมื่อทำได้ Webmaster tools มีประโยชน์ แต่ไม่ได้บอกเสมอว่า URL ถูกค้นพบครั้งแรกจากไหน
- อย่าสรุป ranking จาก crawling crawling, indexing, ranking และ traffic เป็นคนละขั้นตอน
curl -I https://example.com/blog/example-post
HTTP/2 308
location: https://example.com/en/blog/example-postตัวอย่างนี้ใช้เพื่ออธิบายเท่านั้น ประเด็นคือควรตรวจ status และ destination จริง ไม่ใช่สมมติว่า routing rule ทำงาน
สิ่งที่สรุปได้และสิ่งที่สรุปไม่ได้
ฉันยืนยันได้ว่า 308 Redirect ที่มีอยู่แล้วทำให้ request ที่ไม่คาดคิดไปยัง /blog/... ไม่จบด้วย 404 และส่งต่อไปยัง URL ที่ต้องการ
ฉันยืนยันไม่ได้ว่า parser ของ sitemap ใน Yandex เป็นสาเหตุ และฉันไม่ได้วัด ranking gain, indexing improvement หรือจำนวน traffic ที่ “ช่วยไว้” อย่างเฉพาะเจาะจง การกล่าวเช่นนั้นจะเกินหลักฐานที่มี
บทเรียนที่ฉันเก็บไว้จึงแคบกว่าแต่มีประโยชน์กว่า: URL architecture ควรทนต่อความผิดพลาดที่คาดเดาได้บริเวณขอบของระบบ sitemap ที่สะอาดคือแนวป้องกันแรก และ permanent redirect layer ที่แม่นยำคือแนวที่สอง
เมื่อมีทั้งสองอย่าง พาธ crawler ที่ไม่คาดคิดก็มีโอกาสน้อยลงมากที่จะกลายเป็น URL ตายจำนวนมหาศาล