Trang chủ vẫn mở, bài còn trong quản trị nhưng đường dẫn bài viết lại trả 404. Nếu xử lý bằng cách tạo lại bài hoặc đổi slug, website có thể có thêm URL mà chưa sửa được đường đi đang hỏng. Khi bài viết WordPress bị 404, hãy giữ post ID làm mốc và tách việc tìm bản ghi khỏi việc đưa một URL đến đúng bản ghi đó.
Ta xét một tình huống giả định: sau khi chuyển môi trường, một website giới thiệu dịch vụ mở được trang chủ; người biên tập vẫn đọc được bài trong CMS; link bài đã gửi cho khách lại báo không tìm thấy. Đây là ví dụ phân tích, không phải mô tả một dự án hoặc cam kết xử lý của Onter.
Lập bảng nhỏ trước khi sửa đường dẫn
Người phụ trách chọn một bài chắc chắn đã xuất bản, ghi ID, slug hiện tại và permalink WordPress cung cấp. Lưu thêm URL mà khách thực sự bấm. Hai địa chỉ có thể khác nhau vì menu cũ, đường dẫn ngôn ngữ hoặc một lần đổi cấu trúc trước đó.
Không mở hàng trăm URL ngay khi website đang có sự cố. Một nhóm mẫu có chủ đích giúp trả lời câu hỏi đầu tiên: chỉ một đường dẫn lỗi hay một loại đường dẫn cùng lỗi? Với mỗi mẫu, ghi HTTP status thay vì chỉ ghi giao diện trông giống trang lỗi.
| Mẫu cần đối chiếu | Điều có thể biết thêm |
|---|---|
| Trang chủ | Đường vào cơ bản có phục vụ được nội dung? |
| Permalink của bài đã publish | URL bài cụ thể có được giải quyết đúng? |
| Một bài publish khác | Lỗi riêng bản ghi hay có dấu hiệu chung? |
| URL thực sự không tồn tại | Website có còn trả 404 đúng cho đường dẫn sai? |
Trong ví dụ này, bảng chưa khẳng định nguyên nhân. Trang chủ mở được không chứng minh rewrite của mọi bài hoạt động. Một bài khác mở được cũng không loại trừ collision ở đường dẫn đang lỗi. Kết quả chỉ giúp chọn phạm vi điều tra tiếp theo.
Bài viết WordPress bị 404: tìm đúng bản ghi trước
Trạng thái và đường dẫn hiện tại
Đọc lại trạng thái bản ghi bằng CMS hoặc công cụ native được phép. Bản nháp, bài riêng tư và bài đã xuất bản có điều kiện truy cập khác nhau. Không đổi visibility để làm một phép thử trên nội dung chưa được phép công khai.
Nếu URL khách dùng là địa chỉ cũ còn permalink hiện tại mở được, đây là câu hỏi về thay đổi URL và liên kết cũ. Cần xác định URL owner trước khi lên kế hoạch chuyển hướng. Đừng coi đổi slug lần nữa là cách tự động sửa mọi backlink đã tồn tại.
Với URL hiện tại vẫn lỗi, nhờ kỹ thuật đối chiếu post ID và đường xử lý request. Tài liệu Customize permalinks phân biệt permalink dạng query theo ID và dạng đường dẫn dễ đọc. Việc bản ghi tồn tại và việc URL đẹp được định tuyến tới nó là hai phần cần kiểm tra riêng.
Phép thử theo ID có giới hạn
Người kỹ thuật có thể dùng một đường đọc theo ID được hệ thống hỗ trợ để đối chiếu, nhưng cần hiểu hành vi chuyển hướng của WordPress. Nếu URL theo ID tự chuyển sang permalink rồi mới 404, kết quả không tương đương việc trực tiếp đọc bản ghi thành công ở tầng ứng dụng.
Không chuyển toàn bộ website sang cấu trúc Plain chỉ để thử một bài. Một thay đổi cấu trúc rộng có thể tác động nhiều liên kết đang đúng và làm khó việc so sánh trước sau. Hãy giữ nguyên cấu hình trong lúc thu thập bằng chứng chỉ đọc.
Đọc rule hiện tại thay vì tạo lại ngay
Ở nhánh đã xác nhận bài public tồn tại nhưng permalink không đến đúng nơi, đội kỹ thuật xem rewrite hiện tại và lớp web server phía trước. WP-CLI có lệnh wp rewrite list, với khả năng lọc rule khớp một URL. Đây là đường đọc phục vụ đối chiếu, không phải lệnh sửa lỗi tự động.
Cần chạy đúng site, đường cài đặt và ngữ cảnh multisite nếu có. Một danh sách rule lấy từ website khác trên cùng máy chủ không giải thích được request của website đang kiểm tra. Chỉ chia sẻ những dòng liên quan; không công khai namespace hoặc đường dẫn nội bộ không cần thiết.
Nếu có rule khớp, xem query mà nó tạo ra có trỏ tới đúng loại nội dung không. Nếu một plugin hoặc route riêng chiếm cùng đường dẫn, đổi slug để né có thể che collision mà không giải quyết quyền sở hữu URL. Ghi rõ producer nào chịu trách nhiệm trước khi chọn thay đổi.
Nếu chưa có dấu hiệu request tới được WordPress, lớp phục vụ phía trước cần được người quản trị phù hợp kiểm tra. Cấu hình Apache, Nginx và IIS khác nhau; một đoạn hướng dẫn chỉnh .htaccess không tự áp dụng cho mọi môi trường.
Hình thức trang lỗi chỉ là gợi ý, không phải bằng chứng chắc chắn lớp nào trả 404. Một template có thể giống giao diện WordPress nhưng phản hồi đã được cache; một proxy cũng có thể trình bày trang lỗi riêng. Đội kỹ thuật cần đối chiếu status và đường xử lý cụ thể.
Khi nào mới cân nhắc làm mới rewrite?
Tài liệu WP_Rewrite::flush_rules() mô tả việc tạo lại các rule và phân biệt soft với hard flush. Hard flush còn có thể cập nhật file cấu hình theo môi trường được hỗ trợ. Đây là một thao tác ghi có phạm vi ảnh hưởng rộng hơn một bài.
Vì vậy, chỉ cân nhắc khi bằng chứng cho thấy rule hiện tại chưa phản ánh cấu hình hoặc thành phần đang áp dụng. Trước thao tác, giữ cấu trúc permalink hiện tại, snapshot nhỏ của phần có thể bị thay đổi và một nhóm URL canary cần bảo toàn. Không cần sao chép cả VPS chỉ để ghi lại một thay đổi rewrite có phạm vi.
Trong ví dụ giả định, người vận hành xác định rõ thay đổi nào đã làm thiếu rule và chọn một lần làm mới được kiểm soát. Họ không lặp thao tác sau mỗi request, không thêm flush vào luồng tải trang và không đổi nhiều cấu hình cùng lúc. Tài liệu WordPress cũng lưu ý đây là thao tác có chi phí, cần dùng tiết chế.
Nếu sau một lần thay đổi được duyệt mà canary phát sinh lỗi, dừng đúng thao tác và khôi phục phần vừa thay khi điều kiện rollback còn khớp. Không tiếp tục sửa slug hay xóa bản ghi để làm sạch triệu chứng. Nếu có người khác thay cấu hình cùng lúc, cần đối chiếu lại thay vì ghi đè bằng snapshot cũ.
Nghiệm thu đúng URL và giữ lỗi 404 có ý nghĩa
Quay lại bảng mẫu ban đầu: URL bài cần trả nội dung đúng, các bài vốn hoạt động vẫn mở và đường dẫn không tồn tại vẫn trả 404. Không chuyển mọi URL sai về trang chủ hoặc trả 200 chỉ để báo rằng lỗi đã hết. Cách đó làm kết quả kiểm tra thiếu chính xác và khiến người đọc không biết nội dung mình tìm ở đâu.
Đọc canonical, tiêu đề và nội dung để bảo đảm URL mở đúng bài, không chỉ bất kỳ trang nào trả 200. Kiểm tra liên kết ở menu hoặc danh mục đã dẫn đến URL cần dùng chưa. Với bài có nhiều biến thể ngôn ngữ, nghiệm thu từng biến thể thực sự liên quan tới thay đổi.
Nếu một trang sản phẩm đã chủ động ngừng kinh doanh, quyết định giữ hay chuyển hướng thuộc bài toán vòng đời nội dung, khác với lỗi định tuyến bài public đang tồn tại. Có thể xem phân tích trang sản phẩm ngừng kinh doanh để tránh dùng cùng một cách xử lý cho hai tình huống.
Bản bàn giao cuối nên ghi post ID, URL chuẩn, nguyên nhân đã chứng minh, rule hoặc cấu hình đã thay và canary đã kiểm. Nếu nguyên nhân chưa rõ, giữ nguyên nhận định chưa rõ. Không quy một lỗi 404 cho mất database, bị hack hay lỗi hosting chỉ từ một lần mở trang.
Khi cần Onter rà soát tích hợp CMS hoặc quyền sở hữu đường dẫn, hãy gửi danh sách URL đại diện cùng mô tả đã loại dữ liệu riêng tư qua trang liên hệ. Giữ một bài có một owner rõ ràng sẽ hữu ích hơn việc tạo thêm một bản sao để thay cho URL đang lỗi.
