Tôi triển khai một bản cập nhật sitemap với khoảng 3.000 trang mới dưới /en/blog/.... Không lâu sau, Yandex Webmaster cho thấy một pattern bất ngờ: Yandex cố crawl các đường dẫn tương ứng dưới /blog/..., không có prefix /en.
Nếu các URL đó chỉ trả 404, tôi có thể đã nhận hàng nghìn lượt crawl vô ích vào những path không tồn tại. May mắn là tôi đã cấu hình sẵn redirect 308 vĩnh viễn từ các route không có language prefix sang URL tiếng Anh thật.
Lớp routing phòng thủ nhỏ này hóa ra có giá trị hơn nhiều so với tôi nghĩ.
Điều tôi thực sự quan sát được
- Tôi publish sitemap có khoảng 3.000 trang mới theo cấu trúc
/en/blog/.... - Sau đó Yandex Webmaster cho thấy Yandex thử crawl các URL tương ứng ở
/blog/.... - Các path thay thế này đã được bao phủ bởi redirect 308.
- Thay vì kết thúc ở 404, request được gửi tới URL
/en/blog/...dự kiến.
Có một điểm quan trọng tôi cần sửa so với cách diễn đạt ban đầu: tôi không thể chứng minh Yandex đã “parse sitemap sai”. Tôi thấy các path bất ngờ sau khi cập nhật sitemap, nhưng thứ tự thời gian tự nó không chứng minh nguyên nhân nội bộ. Search engine có thể discover URL từ nhiều signal và nguồn lịch sử. Nếu không có bằng chứng mạnh hơn, phát biểu chính xác chỉ là Yandex đã crawl những path mà tôi không mong đợi.
Phân biệt này quan trọng. Crawler request một URL lạ là observation; giải thích chính xác vì sao nó chọn URL đó là một claim khác.
Vì sao redirect 308 hữu ích
Logic của tôi coi path ngắn là alias vĩnh viễn của URL đã localized:
/blog/example-post -> 308 -> /en/blog/example-postVì vậy dù crawler vào bằng URL bất ngờ, nó vẫn tới trang mà tôi thực sự muốn serve.
308 Permanent Redirect là redirect HTTP vĩnh viễn giữ nguyên request method và body. Với GET request thông thường của crawler, việc giữ method thường không phải lợi ích chính; trong trường hợp này, điều hữu ích là redirect được xác định rõ là vĩnh viễn. Tài liệu hiện tại của Yandex Webmaster phân loại cả 301 và 308 là permanent redirect.
Tài liệu chính thức của Yandex Webmaster về redirect.
Điều đó không có nghĩa 308 tự động tốt hơn 301 cho SEO. Trong trường hợp của tôi, 308 đã có sẵn và làm đúng nhiệm vụ: URL bất ngờ không trở thành ngõ cụt.
Redirect là safety net, không phải cách sửa sitemap
Redirect giúp giới hạn hậu quả nhưng không làm việc crawl dư thừa trở nên tốt. Mỗi redirect không cần thiết là thêm một request và một hop. Rule quá rộng cũng có thể che lỗi sinh URL nếu bạn ngừng tìm nguồn gốc của các URL sai.
Nếu chính sitemap chứa URL cũ hoặc URL redirect, cách đúng là sửa sitemap để trỏ tới final URL. Redirect nên bảo vệ path cũ, path thay thế hoặc URL vô tình được discover; không nên trở thành lý do để chấp nhận dữ liệu URL thiếu chính xác.
Trong trường hợp của tôi, sitemap đã dùng /en/blog/.... Redirect chỉ làm site tolerant hơn khi crawler đi vào qua /blog/....
Hôm nay tôi sẽ kiểm tra gì
- Mở sitemap đã deploy thật. Không chỉ tin code generator; kiểm tra file cuối và một số URL mẫu.
- Kiểm tra response cuối. URL cần index nên lý tưởng là đi thẳng tới trang đích, không qua redirect chain có thể tránh.
- Test các alternate path có thể dự đoán. Nếu URL cũ hoặc không prefix có đích vĩnh viễn, mapping nên rõ ràng và một-một.
- Tránh redirect chain.
A -> B -> Ckhó kiểm soát hơnA -> C. - Khi có thể, so crawler report với dữ liệu server. Webmaster tools hữu ích nhưng không phải lúc nào cũng cho biết URL được discover từ đâu.
- Không suy ranking chỉ từ crawling. Crawling, indexing, ranking và traffic là các giai đoạn khác nhau.
curl -I https://example.com/blog/example-post
HTTP/2 308
location: https://example.com/en/blog/example-postVí dụ này chỉ để minh họa. Mục tiêu là verify status và destination chính xác thay vì giả định routing rule hoạt động.
Tôi có thể kết luận gì, và không thể kết luận gì
Tôi có thể xác nhận các 308 đã có sẵn khiến request bất ngờ tới /blog/... không kết thúc ở 404 và chuyển chúng sang URL dự kiến.
Tôi không thể xác nhận parser sitemap của Yandex là nguyên nhân. Tôi cũng không đo được ranking gain, cải thiện indexing hay một lượng traffic cụ thể được “cứu”. Nói như vậy sẽ vượt quá bằng chứng tôi có.
Bài học tôi giữ lại hẹp hơn nhưng hữu ích hơn: URL architecture nên chịu được những lỗi có thể dự đoán ở ranh giới hệ thống. Sitemap sạch là tuyến phòng thủ đầu tiên. Lớp permanent redirect chính xác là tuyến thứ hai.
Khi có cả hai, một crawler path bất ngờ ít có khả năng biến thành hàng nghìn URL chết.