Cách sửa lỗi 404 trong Google Search Console (2026)

Sửa lỗi 'Không tìm thấy (404)' trong Search Console: khi nào nên bỏ qua, khi nào cần chuyển hướng 301, khi nào nên khôi phục trang, kèm bảng quyết định và các bước xác thực.

Câu hỏi thường gặp

Lỗi 404 có làm giảm thứ hạng của tôi trên Google không?

Bản thân lỗi 404 thì không. Tài liệu về báo cáo Lập chỉ mục trang (Page indexing) của Google cho biết phản hồi 404 không nhất thiết là vấn đề khi một trang đã bị gỡ mà không có trang thay thế, và liệt kê 404 của trang bạn đã xóa là một lý do bình thường khiến URL không được lập chỉ mục. Những lỗi 404 đáng sửa là các URL do chính bạn liên kết tới hoặc khai báo trong sitemap.

Nên dùng 404 hay 410 cho các trang đã xóa?

Với Google Search thì trên thực tế không có khác biệt. Tài liệu về mã trạng thái HTTP của Google xử lý mọi lỗi 4xx (trừ 429) như nhau: nội dung được coi là không tồn tại, URL đã được lập chỉ mục trước đó sẽ bị loại khỏi chỉ mục và tần suất thu thập dữ liệu URL đó giảm dần. Hãy dùng loại nào nền tảng của bạn hỗ trợ dễ nhất.

'Validate fix' (Xác thực bản sửa) cho lỗi 404 mất bao lâu?

Google cho biết quá trình xác thực thường mất tối đa khoảng hai tuần, nhưng có thể lâu hơn nhiều. Đừng nhấp Validate fix lần nữa cho đến khi lần xác thực hiện tại thành công hoặc thất bại. Nếu Google còn tìm thấy dù chỉ một trường hợp của lỗi, quá trình xác thực sẽ dừng lại.

Vì sao URL đã sửa vẫn xuất hiện trong báo cáo Not found (404)?

Google vẫn tiếp tục thử thu thập một URL không tồn tại trong một thời gian, nên URL có thể còn nằm trong danh sách sau khi bạn đã sửa. Ngoài ra, danh sách ví dụ trong báo cáo giới hạn 1.000 dòng và không đảm bảo hiển thị mọi URL. Hãy xử lý nguyên nhân (liên kết hỏng, mục trong sitemap), sau đó chạy xác thực và chờ kết quả.

Có nên chuyển hướng mọi trang 404 về trang chủ không?

Không. Hướng dẫn của Google là trả về chuyển hướng 3XX khi một trang đã được chuyển sang trang mới. Trang không có trang thay thế thực sự thì nên để là 404. Đẩy các URL không liên quan về trang chủ khiến khách truy cập nhận được thứ họ không hề tìm, đồng thời che giấu vấn đề thật với bạn.

Trả lời ngắn gọn: Trong Search Console, mở Indexing > Pages (Lập chỉ mục > Trang), nhấp Not found (404) rồi phân loại từng URL vào một trong ba nhóm. Nếu trang bị gỡ có chủ đích và không có liên kết nào trỏ tới, hãy bỏ qua. Nếu trang đã chuyển đi hoặc có trang thay thế tương đương, hãy thêm chuyển hướng 301 tới trang đó. Nếu trang lẽ ra phải tồn tại, hãy khôi phục nó. Sau đó sửa các liên kết nội bộ hoặc mục trong sitemap đang trỏ tới URL lỗi và nhấp Validate fix.

Phần lớn "lỗi 404" trong Search Console không cần sửa, nên kỹ năng quan trọng ở đây là phân loại chứ không phải sửa chữa.

"Not found (404)" thực sự có nghĩa là gì

Báo cáo Page indexing liệt kê các URL mà Google đã thử thu thập dữ liệu nhưng không thể lập chỉ mục. "Not found (404)" nghĩa là máy chủ đã trả lời yêu cầu đó bằng mã trạng thái 404. Chỉ có vậy thôi. Nó không cho biết URL đó có quan trọng hay không.

Lời khuyên xử lý sự cố của chính Google rất cụ thể: chỉ sửa những lỗi 404 mà bạn tự liên kết tới hoặc khai báo trong sitemap, và nếu một trang đã chuyển đi thì hãy trả về chuyển hướng 3XX tới trang mới. Google cũng liệt kê "404 cho trang bạn đã xóa và không có trang thay thế" là một trong những lý do hợp lệ khiến trang không được lập chỉ mục.

Nếu bạn chưa thiết lập công cụ này, hãy bắt đầu với hướng dẫn Search Console của chúng tôi hoặc bài hướng dẫn về xác minh website trong Google Search Console.

Bước 1: Xuất danh sách và tìm nguồn gốc của từng lỗi 404

  1. Mở Search Console và chọn thuộc tính (property) của bạn.
  2. Vào Indexing > Pages.
  3. Cuộn tới bảng "Why pages aren't indexed" (Lý do trang không được lập chỉ mục) và nhấp Not found (404).
  4. Xem các URL ví dụ. Bảng này giới hạn 1.000 dòng và không đảm bảo hiển thị mọi URL, vì vậy với website lớn hãy coi đó là một mẫu.
  5. Xuất dữ liệu nếu bạn muốn làm việc trong bảng tính.
  6. Nhấp vào một URL và dùng Inspect URL (Kiểm tra URL) để xem Google đã phát hiện URL đó bằng cách nào. Trang giới thiệu và thông tin sitemap cho bạn biết liên kết đó có phải của bạn hay không.

Nguồn phát hiện là thông tin then chốt. Lỗi 404 mà Google tìm thấy qua menu hoặc sitemap của chính bạn là lỗi thật. Lỗi 404 được tìm thấy qua một liên kết ngoài cũ hoặc lỗi gõ sai trên website của người khác thường chỉ là nhiễu, trừ khi liên kết đó đang dẫn khách truy cập thật.

Bước 2: Quyết định: bỏ qua, chuyển hướng hay khôi phục

Hãy dùng bảng này cho mọi nhóm URL trong báo cáo.

Tình huốngBiểu hiệnHành động
Trang bị xóa có chủ đích, không có trang thay thế, không có liên kết nội bộSản phẩm cũ, sự kiện đã hết hạn, trang thử nghiệmBỏ qua. Giữ nguyên 404 (hoặc 410).
Trang bị xóa nhưng có trang thay thế tương đươngSản phẩm ngừng bán, phiên bản mới hơn của bài hướng dẫnChuyển hướng 301 tới trang tương đương gần nhất.
URL thay đổi (đổi slug, chuyển thư mục, di chuyển tên miền hoặc sang HTTPS)Cùng nội dung ở địa chỉ mớiChuyển hướng 301 từ URL cũ sang URL mới, chỉ một bước.
Trang lẽ ra phải tồn tại nhưng bị xóa hoặc hủy xuất bản do nhầmTrang dịch vụ đang hoạt động, bài viết quan trọngKhôi phục trang, xác nhận trả về 200, rồi xác thực.
Liên kết trong menu, chân trang hoặc nội dung của bạn trỏ tới nóLiên kết nội bộ tới URL lỗiSửa liên kết (hoặc chuyển hướng nếu trang đã chuyển).
Có trong sitemap XML của bạnSitemap chứa các URL đã bị gỡXóa khỏi sitemap, rồi quyết định chuyển hướng hay bỏ qua.
URL rác từ spam hoặc tham số lạChuỗi ngẫu nhiên, mẫu của công cụ thu thập dữ liệuBỏ qua. Kiểm tra bảo mật nếu chúng trông như bị chèn vào (xem bên dưới).

Khi trang thay thế không thực sự tương đương, đừng ép tìm một trang. Tài liệu về chuyển hướng của Google mô tả chuyển hướng là cách đưa người dùng và Google tới vị trí mới của trang, còn một trang không có vị trí mới thì không có gì để trỏ tới.

Bước 3: Thêm chuyển hướng đúng cách

Với việc chuyển vĩnh viễn, Google khuyến nghị dùng chuyển hướng vĩnh viễn phía máy chủ bất cứ khi nào có thể. Cả hai mã trạng thái 301 và 308 đều có nghĩa là trang đã được chuyển vĩnh viễn. Google cho biết chỉ nên dùng chuyển hướng JavaScript khi bạn không thể dùng chuyển hướng phía máy chủ hoặc meta refresh.

Nguyên tắc thực hành:

  • Chuyển hướng tới một URL phù hợp nhất, không đi qua chuỗi nhiều bước.
  • Trỏ tới trang trả về phản hồi 200 bình thường, không phải một chuyển hướng hay trang lỗi khác.
  • Cập nhật cả liên kết nội bộ sang URL mới để bạn không phải phụ thuộc vào chuyển hướng mãi mãi.
  • Trên WordPress, plugin chuyển hướng hoặc quy tắc chuyển hướng của nhà cung cấp hosting sẽ làm việc này. Trên các nền tảng khác, hãy dùng cài đặt chuyển hướng hoặc rewrite của máy chủ hay CMS.

Ví dụ bảng ánh xạ chuyển hướng bạn có thể đưa cho lập trình viên hoặc dán vào công cụ chuyển hướng:

`` /old-pricing -> /pricing /blog/2022/seo-tips -> /blog/seo-tips /services/web-design -> /services/website-design ``

Bước 4: Kiểm tra bản sửa, rồi xác thực

Trước khi báo cho Google, hãy tự kiểm tra URL.

  1. Mở URL cũ trong trình duyệt, hoặc chạy công cụ kiểm tra header, và xác nhận nó trả về 301 rồi dẫn tới một trang 200.
  2. Trong Search Console, dán URL vào thanh trên cùng và chạy Inspect URL, sau đó dùng bài kiểm tra trực tiếp (live test) để xem Google nhận được gì.
  3. Xác nhận URL không còn trong sitemap và không có trang nội bộ nào liên kết tới nó.

Sau đó xác thực:

  1. Mở vấn đề Not found (404) trong báo cáo Page indexing.
  2. Nhấp Validate fix.
  3. Theo dõi trạng thái. Đừng nhấp Validate fix lần nữa cho đến khi quá trình xác thực thành công hoặc thất bại.
  4. Nếu thất bại, nhấp See details (Xem chi tiết), sửa các URL còn lại rồi bắt đầu lại.

Google cho biết quá trình xác thực thường mất tối đa khoảng hai tuần nhưng có thể lâu hơn nhiều. Nó cũng dừng lại nếu tìm thấy dù chỉ một trường hợp còn sót, vì vậy chỉ nên xác thực khi bạn đã sửa xong cả nhóm. Một mẹo từ tài liệu của Google: xác thực trên một tập con các URL bị ảnh hưởng có thể hoàn tất nhanh hơn, bạn có thể làm vậy bằng cách lọc báo cáo theo một sitemap chỉ chứa các trang quan trọng của mình.

Một lưu ý liên quan: Google xử lý các URL 404 dần dần. Với URL trả về 404, Google cho biết quy trình lập chỉ mục sẽ loại URL khỏi chỉ mục nếu trước đó nó đã được lập chỉ mục, các trang 404 mới phát hiện không được xử lý và tần suất thu thập dữ liệu giảm dần. Vì vậy URL bạn để là 404 sẽ tự mờ dần.

Bước 5: Kiểm tra các trường hợp "không thực sự là 404"

Có hai trường hợp trông giống 404 nhưng cần xử lý khác:

  • Soft 404. Trang trả về mã 200 nhưng hiển thị trang trống hoặc thông báo lỗi, và Search Console báo là soft 404. Hãy sửa bằng cách trả về mã 404 thật, hoặc đưa nội dung thực vào trang.
  • URL bị tấn công hoặc bị chèn mã độc. Một loạt lỗi 404 đột ngột trên các tên tệp lạ hoặc đường dẫn spam có thể cho thấy website đã bị xâm nhập. Nếu đúng với những gì bạn thấy trên một CMS, hãy đọc hướng dẫn khắc phục của chúng tôi cho WordPress, Joomla hoặc Drupal, rồi kiểm tra lại báo cáo.

Danh sách kiểm tra phân loại có thể sao chép

  • [ ] Đã xuất các URL Not found (404) từ Indexing > Pages
  • [ ] Đã đánh dấu từng URL: liên kết của bạn, sitemap của bạn, liên kết ngoài hoặc không rõ
  • [ ] Đã bỏ qua các trang bị xóa không có trang thay thế và không có liên kết nội bộ
  • [ ] Đã thêm chuyển hướng 301 cho các trang đã chuyển, một bước, tới trang 200
  • [ ] Đã khôi phục các trang bị gỡ nhầm
  • [ ] Đã sửa các liên kết nội bộ trỏ tới URL lỗi
  • [ ] Đã xóa các URL lỗi khỏi sitemap XML
  • [ ] Đã kiểm tra một mẫu bằng Inspect URL
  • [ ] Đã nhấp Validate fix một lần và chờ kết quả

Ngăn chặn đợt lỗi tiếp theo

Phần lớn lỗi 404 lặp lại xuất phát từ việc làm lại website, đổi slug và xóa bài viết mà không có kế hoạch chuyển hướng. Trước mỗi lần di chuyển, hãy liệt kê các URL cũ và ánh xạ từng URL tới vị trí mới. Nếu dù sao bạn cũng đang làm lại một website nhỏ, gói miễn phí của We.Inc cho phép bạn xuất bản tối đa ba website từ các mẫu có sẵn; trình xây dựng AI tạo website từ một câu lệnh bắt đầu ở gói Starter với giá $20 một tháng. Bạn có thể đăng ký tại đây. Dù chọn cách nào, hãy giữ lại bảng ánh xạ URL cũ sang mới, vì chính nó giúp báo cáo này luôn sạch.

Để có cái nhìn tổng quan hơn về công cụ này, hãy xem Google Search Console cho người mới bắt đầu.

Bắt đầu miễn phí · Không cần thẻ tín dụng

Umair Ali Sadaqat

Nhà sáng lập We.Inc

Umair là nhà sáng lập We.Inc. Anh viết về xây dựng website bằng AI, các agency và việc kinh doanh, vận hành một studio web.

Sẵn sàng tạo nên điều tuyệt vời?

Tham gia cùng 15,000+ doanh nghiệp đang dùng We.Inc để ra mắt, phát triển và tự động hóa, tất cả trên một nền tảng.

Bắt đầu miễn phí

Không cần thẻ tín dụng · Liên hệ bộ phận kinh doanh

Liên quan: Blog

Sản phẩm

Dành cho ai

Tính năng

Tài nguyên

Công ty

Sơ đồ trang