Orova OROVA.VN Marketing AI Agent
Góc nhìn

Những lỗi robots.txt âm thầm giết traffic

Orova 2 lượt xem
Những lỗi robots.txt âm thầm giết traffic

Có một loại sự cố SEO không bao giờ hiện lên dưới dạng cảnh báo đỏ, không làm website chậm đi, không phá vỡ giao diện, và thường chẳng ai trong đội phát hiện ra cho tới khi traffic đã rơi mất một mảng lớn. Nó nằm gọn trong một tệp văn bản vỏn vẹn vài dòng, đặt ở thư mục gốc của website, mang cái tên khô khan: robots.txt. Bạn có thể đã không mở nó ra xem suốt cả năm trời. Và chính vì không ai để ý, nó âm thầm chặn Google khỏi những trang quan trọng nhất của bạn — đôi khi chặn cả website.

Bài viết này không phải bài tâng bốc rằng robots.txt là "công cụ SEO mạnh mẽ". Ngược lại: tôi muốn phê bình thẳng những lỗi robots.txt phổ biến nhất mà tôi gặp đi gặp lại trên website của doanh nghiệp Việt — những lỗi tự tay bóp nghẹt traffic của chính mình. Một dòng đặt sai chỗ trong tệp này có sức phá hoại lớn hơn hàng tháng trời làm nội dung gộp lại. Và điều đáng nói là gần như mọi lỗi trong số đó đều bắt nguồn từ việc hiểu sai bản chất robots.txt làm gì.

Hãy đi qua từng lỗi, vì sao nó nguy hiểm, cách phát hiện, và cách sửa an toàn mà không tự tạo ra một lỗ hổng mới.

Lỗi robots.txt nguy hiểm nhất là chặn nhầm những thứ đáng lẽ phải được Google thu thập. robots.txt chỉ là chỉ dẫn cho bot biết được phép thu thập (crawl) thư mục nào, chứ nó không quyết định trang nào được index hay ẩn khỏi kết quả tìm kiếm. Hiểu lệch điều này dẫn tới bốn lỗi chí mạng: chặn cả site khi lên production, chặn thư mục chứa CSS/JS khiến Google không render được trang, nhầm lẫn giữa disallow và noindex, và chặn nhầm các trang đang ra tiền.

robots.txt thực ra làm gì — và không làm gì

Trước khi phê bình các lỗi, cần đặt lại nền móng, vì hầu hết tai nạn đều sinh ra từ một hiểu lầm duy nhất.

robots.txt là một tệp văn bản đặt tại địa chỉ gốc của tên miền, ví dụ ten-mien.com/robots.txt. Khi một con bot của công cụ tìm kiếm — Googlebot, Bingbot và nhiều bot khác — ghé thăm website, việc đầu tiên nó làm là đọc tệp này để biết bạn cho phép hay không cho phép nó thu thập những phần nào. Cú pháp rất gọn: User-agent chỉ định lệnh áp dụng cho bot nào, Disallow liệt kê đường dẫn không cho thu thập, Allow mở lại một ngoại lệ bên trong vùng đã chặn, và Sitemap trỏ tới sơ đồ trang.

Đây là điểm mấu chốt mà rất nhiều người làm marketing và cả lập trình viên hiểu sai: Disallow trong robots.txt chỉ ngăn bot THU THẬP nội dung trang, chứ không ngăn trang đó xuất hiện trong kết quả tìm kiếm. Nghe nghịch lý, nhưng đúng. Nếu một trang bị Disallow nhưng lại có nhiều website khác trỏ link tới, Google vẫn có thể index địa chỉ trang đó và hiển thị nó trong kết quả tìm kiếm — chỉ là với dòng mô tả trống rỗng kiểu "Không có thông tin nào cho trang này vì tệp robots.txt của website chặn", vì Google bị cấm vào đọc nội dung. Bạn vừa có điều tệ nhất của cả hai thế giới: trang vẫn lọt vào kết quả nhưng trông như một liên kết hỏng, đuổi người dùng đi.

Ngược lại, muốn một trang KHÔNG xuất hiện trong kết quả tìm kiếm thì công cụ đúng không phải Disallow, mà là thẻ meta noindex đặt trong phần đầu của trang đó, hoặc tiêu đề HTTP X-Robots-Tag. Và đây là cái bẫy lồng trong cái bẫy: muốn Google tuân theo lệnh noindex thì Google phải được phép VÀO trang để đọc thấy lệnh đó. Nếu bạn vừa Disallow trang trong robots.txt vừa đặt noindex bên trong, Google sẽ không bao giờ vào đọc được noindex, nên lệnh ẩn trang của bạn vô hiệu. Hai lệnh đánh nhau, và lệnh sai thắng. Phần lớn các sự cố tôi sắp mổ xẻ đều là biến thể của hiểu lầm này.

Lỗi số 1: chặn cả website khi đẩy lên production

Đây là lỗi kinh điển, gây thiệt hại nặng nhất, và tệ ở chỗ nó cực kỳ dễ xảy ra. Trong lúc dựng website, đội kỹ thuật thường chạy bản nháp trên một môi trường thử nghiệm (staging) và cố tình chặn toàn bộ để Google không index website chưa hoàn thiện. Dòng lệnh trông như thế này:

User-agent: *
Disallow: /

Dấu gạch chéo đơn độc sau Disallow nghĩa là "cấm thu thập mọi thứ từ thư mục gốc trở xuống" — tức toàn bộ website. Trên môi trường staging, điều đó hoàn toàn đúng. Vấn đề là khi website đi vào hoạt động thật, đội kỹ thuật quên gỡ dòng này, hoặc tệ hơn, sao chép nguyên cấu hình staging sang production. Thế là website chính thức của bạn ra mắt với một tấm biển khổng lồ treo trước cửa: "Google, đừng vào đây."

Hậu quả không diễn ra tức thì, và đó là lý do nó nguy hiểm. Những trang Google đã index trước đó còn nán lại vài ngày tới vài tuần. Rồi lần lượt rụng khỏi kết quả tìm kiếm khi Google ghé lại, đọc thấy lệnh cấm, và dần loại chúng ra. Traffic trượt dốc từ từ chứ không sụp một phát, nên đội ngũ dễ đổ cho "thuật toán Google thay đổi" hay "mùa thấp điểm" trong khi thủ phạm thật nằm gọn trong một dòng văn bản. Tôi đã thấy không ít website Việt mất hàng tháng trời băn khoăn vì sao thứ hạng tụt, để rồi phát hiện tệ nạn này. Đây cũng là một trong những nguyên nhân kỹ thuật hàng đầu khiến một trang biến mất khỏi Google, tôi đã phân tích sâu hơn trong bài vì sao Google không index trang của bạn.

Cách phòng tránh đơn giản đến mức đáng ngạc nhiên: ngay sau khi website lên production, việc đầu tiên — trước cả ăn mừng — là mở ten-mien.com/robots.txt trên trình duyệt và đọc bằng mắt. Nếu thấy Disallow: / đứng một mình dưới User-agent: *, bạn đang chặn cả website. Sửa ngay.

Sơ đồ so sánh hai tệp robots.txt: bên trái cấu hình staging với lệnh Disallow gạch chéo chặn toàn bộ website khiến Google bị từ chối, bên phải cấu hình production đúng cho phép Google thu thập và trỏ tới sitemap
Cùng một website, hai tệp robots.txt. Khác biệt nằm ở đúng một dấu gạch chéo — nhưng một bên giết sạch traffic, một bên mở cửa cho Google.

Lỗi số 2: chặn thư mục chứa CSS và JavaScript

Lỗi này tinh vi hơn, và chính vì tinh vi nên nó tồn tại dai dẳng trên rất nhiều website mà chủ nhân không hề hay biết. Trong nhiều năm, người ta tin rằng nên chặn các thư mục "kỹ thuật" như /wp-includes/, /assets/, /static/, /js/, /css/ để Google "tập trung vào nội dung chính" và "tiết kiệm tài nguyên thu thập". Lời khuyên đó từng phổ biến tới mức nó nằm sẵn trong vô số mẫu robots.txt sao chép qua lại.

Vấn đề là Google ngày nay không đọc trang của bạn như một tài liệu văn bản thô. Nó render trang giống hệt cách một trình duyệt làm: tải HTML, rồi tải CSS để biết bố cục và giao diện, rồi chạy JavaScript để dựng những phần nội dung sinh ra động. Chỉ sau khi render xong, Google mới "nhìn thấy" trang của bạn thực sự trông và hoạt động ra sao. Nếu bạn chặn thư mục chứa CSS và JavaScript, bạn đang bịt mắt Google ngay tại bước render.

Kết quả là Google nhìn thấy một phiên bản méo mó của trang: chữ nghĩa lộn xộn không có bố cục, nội dung quan trọng do JavaScript dựng lên thì biến mất hoàn toàn, và — đây là đòn chí mạng trong thời đại ưu tiên di động — Google không thể xác nhận trang của bạn thân thiện với thiết bị di động vì nó không tải được tệp CSS quy định cách trang co giãn trên màn hình nhỏ. Một trang đáng lẽ được đánh giá tốt bỗng bị chấm điểm như một trang vỡ vạc, và thứ hạng tụt theo mà không một thông báo lỗi nào hiện ra.

Cách kiểm tra rất rõ ràng. Trong Google Search Console có công cụ Kiểm tra URL (URL Inspection): dán địa chỉ một trang vào, chọn xem trang đã render, và đối chiếu với những gì người dùng thật nhìn thấy. Nếu phiên bản Google render bị vỡ giao diện hoặc thiếu nội dung, gần như chắc chắn bạn đang chặn nhầm tài nguyên. Search Console cũng liệt kê các tài nguyên mà Google không tải được và lý do — nếu lý do là "bị robots.txt chặn", bạn đã tìm ra thủ phạm.

Nguyên tắc cho năm 2026 rất dứt khoát: đừng chặn CSS, JavaScript hay hình ảnh cần thiết để render trang. Lý do "tiết kiệm tài nguyên thu thập" đã lỗi thời và gây hại nhiều hơn lợi với đại đa số website. Hãy để Google nhìn thấy trang của bạn đúng như người dùng nhìn thấy.

Lỗi số 3: nhầm Disallow với noindex

Tôi đã nêu nguyên lý ở phần đầu, nhưng nó đáng có một mục riêng vì đây là lỗi gây bối rối nhiều nhất, và là gốc rễ của những quyết định sai lầm dây chuyền.

Tình huống điển hình: bạn có một loạt trang không muốn xuất hiện trong kết quả tìm kiếm — trang cảm ơn sau khi điền form, trang kết quả tìm kiếm nội bộ, trang giỏ hàng, các bản lọc sản phẩm trùng lặp. Theo phản xạ, nhiều người mở robots.txt và Disallow chúng. Nghe có vẻ hợp lý: "tôi không muốn Google thấy, vậy thì cấm Google vào." Nhưng như đã nói, Disallow không ẩn trang khỏi kết quả — nó chỉ cấm Google đọc nội dung. Trang vẫn có thể lọt vào kết quả tìm kiếm với mô tả trống, trông như một liên kết hỏng làm xấu hình ảnh thương hiệu.

Ngược lại, muốn một trang thực sự biến mất khỏi kết quả thì phải để Google VÀO đọc được lệnh noindex. Nghĩa là trang đó KHÔNG được Disallow trong robots.txt. Quy tắc gọn để nhớ:

  • Muốn ẩn trang khỏi kết quả tìm kiếm: dùng thẻ meta noindex bên trong trang, và để robots.txt cho phép Google vào trang đó.
  • Muốn chặn bot thu thập cả một vùng nặng kỹ thuật, không có nội dung cần index: dùng Disallow trong robots.txt.
  • Tuyệt đối không vừa Disallow vừa đặt noindex cho cùng một trang — hai lệnh triệt tiêu nhau, Google không vào được nên không bao giờ thấy noindex, và trang vẫn lảng vảng trong kết quả.

Hiểu đúng sự phân vai này còn giúp bạn tránh một lỗi liên đới: chặn lung tung bằng robots.txt với hy vọng "dọn dẹp" những trang không mong muốn, trong khi công cụ phù hợp lẽ ra là noindex hoặc thẻ canonical. Khi nào nên dùng cái nào là một phần quan trọng của việc giữ website khoẻ mạnh về mặt kỹ thuật, tôi gom đầy đủ trong bài về cách kiểm tra sức khoẻ kỹ thuật website.

Lỗi số 4: chặn nhầm chính những trang đang ra tiền

Đây là lỗi đau nhất, vì nó tấn công thẳng vào doanh thu. Nó thường xảy ra qua một quy tắc Disallow viết quá rộng, vô tình quét trúng những trang quan trọng.

Ví dụ kinh điển: một website thương mại điện tử muốn chặn các trang lọc sản phẩm có tham số dài dòng trong địa chỉ, nên viết một dòng Disallow để chặn mọi địa chỉ chứa dấu chấm hỏi. Nghe hợp lý, nhưng nếu các trang danh mục sinh ra tiền của họ cũng dùng tham số trong địa chỉ, dòng lệnh ấy vừa quét sạch luôn cả danh mục bán hàng. Hoặc một website Disallow toàn bộ thư mục /san-pham/ vì nhầm tưởng đó là khu kỹ thuật, trong khi đó chính là nơi đặt mọi trang sản phẩm. Hoặc một blog Disallow /blog/ trong lúc thử nghiệm rồi quên gỡ, làm bay sạch nội dung kéo traffic tự nhiên về.

Điểm chung của những lỗi này: chúng không gây ra thông báo lỗi nào, không làm hỏng website về mặt kỹ thuật, không khiến trang chậm đi. Trang vẫn mở bình thường khi người dùng truy cập trực tiếp. Chỉ có Google bị chặn cửa, nên dần dần các trang đó rụng khỏi kết quả tìm kiếm và traffic tự nhiên cạn dần — một cái chết chậm rãi mà không có giấy báo tử.

Một biến thể đặc biệt tinh quái là quy tắc Disallow dùng ký tự đại diện quá rộng. Dấu sao trong robots.txt khớp với "bất kỳ chuỗi ký tự nào", nên một dòng tưởng vô hại có thể quét trúng nhiều thứ ngoài dự kiến. Mỗi khi viết một quy tắc có ký tự đại diện, bạn phải tự hỏi: dòng này còn vô tình khớp với trang quan trọng nào nữa không? Câu hỏi đó tiết kiệm cho bạn rất nhiều đau đớn về sau.

Cách kiểm tra robots.txt một cách có hệ thống

Phê bình thì dễ, nhưng giá trị nằm ở quy trình kiểm tra để bạn không bao giờ trở thành nạn nhân của chính tệp này. Đây là trình tự tôi khuyên áp dụng định kỳ.

Đọc tệp bằng mắt thường

Bước rẻ nhất và hiệu quả nhất. Mở ten-mien.com/robots.txt trên trình duyệt và đọc từng dòng. Bạn không cần là dân kỹ thuật để nhận ra Disallow: / đứng một mình là dấu hiệu chặn cả website. Đọc kỹ mọi dòng Disallow và tự hỏi từng dòng đang chặn cái gì, có vô tình quét trúng trang quan trọng không. Riêng việc này đã bắt được phần lớn tai nạn nghiêm trọng.

Dùng công cụ Kiểm tra URL trong Search Console

Google Search Console là nguồn sự thật chính thức, vì nó cho bạn thấy đúng những gì Googlebot nhìn thấy chứ không phải phỏng đoán. Dán địa chỉ một trang vào ô Kiểm tra URL, Search Console sẽ cho biết trang có được phép thu thập không, có được index không, và nếu bị chặn thì chặn bởi quy tắc nào. Hãy kiểm tra ít nhất: trang chủ, một trang sản phẩm hoặc dịch vụ quan trọng, và một bài blog kéo traffic. Nếu bất kỳ trang nào báo "Bị robots.txt chặn" mà đáng lẽ phải được index, bạn vừa bắt được một lỗ rò traffic.

Xem phiên bản trang đã render

Vẫn trong công cụ Kiểm tra URL, dùng tính năng xem trang đã render để đối chiếu phiên bản Google dựng được với phiên bản người dùng thật nhìn thấy. Nếu trang render bị vỡ bố cục hoặc mất nội dung, kiểm tra danh sách tài nguyên Google không tải được. Tài nguyên nào báo bị robots.txt chặn chính là CSS hay JavaScript bạn đang chặn nhầm — đây là cách phát hiện trực tiếp lỗi số 2.

Theo dõi báo cáo lập chỉ mục

Báo cáo Lập chỉ mục (Indexing) trong Search Console có mục liệt kê các trang bị loại trừ và lý do. Nếu thấy số lượng lớn trang gắn nhãn "Đã chặn do robots.txt" mà bạn không cố ý chặn, đó là tín hiệu đỏ. Theo dõi báo cáo này theo thời gian giúp bạn bắt sự cố sớm, ngay khi nó vừa bắt đầu rút trang ra khỏi index, thay vì sau khi traffic đã rơi.

Quy trình bốn bước kiểm tra robots.txt an toàn: đọc tệp bằng mắt thường, kiểm tra URL trong Search Console, xem phiên bản trang đã render, theo dõi báo cáo lập chỉ mục để phát hiện lỗi chặn nhầm
Bốn bước kiểm tra nên chạy định kỳ. Không bước nào cần kỹ năng lập trình — chúng cần kỷ luật đọc và đối chiếu trước khi traffic rơi.

Cách sửa robots.txt an toàn mà không tạo lỗ hổng mới

Khi đã phát hiện lỗi, đừng vội sửa ẩu, vì một lần sửa cẩu thả có thể thay lỗi cũ bằng lỗi mới còn tệ hơn. Đây là cách sửa an toàn.

Thứ nhất, sao lưu tệp robots.txt hiện tại trước khi đụng vào. Bạn cần một bản gốc để quay về nếu thay đổi gây hậu quả bất ngờ. Chỉ cần lưu lại nội dung tệp vào một nơi an toàn là đủ.

Thứ hai, sửa từng dòng có chủ đích, không sao chép nguyên một mẫu robots.txt từ trên mạng về dán đè. Phần lớn các mẫu trôi nổi đều chứa những dòng Disallow lỗi thời — chính là nguồn gốc của lỗi chặn CSS/JS mà tôi đã mổ xẻ. Mỗi dòng trong tệp của bạn phải có lý do tồn tại rõ ràng mà bạn giải thích được. Nếu không giải thích được vì sao một dòng Disallow nằm đó, khả năng cao nó nên bị xoá.

Thứ ba, sau khi sửa, dùng lại công cụ Kiểm tra URL trong Search Console để xác nhận những trang quan trọng giờ đã được phép thu thập, và những trang bạn cố ý chặn vẫn đang bị chặn đúng ý. Đừng tin rằng "sửa xong là xong" — hãy kiểm chứng bằng công cụ chính thức.

Thứ tư, một mẹo an toàn quan trọng: nếu bạn vừa gỡ một lệnh Disallow vốn đang chặn nhầm trang quan trọng, hãy chủ động yêu cầu Google index lại các trang đó qua nút trong công cụ Kiểm tra URL, thay vì ngồi chờ Google tự ghé lại. Việc này tăng tốc quá trình phục hồi đáng kể, nhất là khi traffic đã rơi và bạn cần lấy lại nhanh.

Cuối cùng, một lưu ý dễ bị quên: tệp robots.txt nên trỏ tới sitemap của bạn bằng dòng Sitemap. Đây là một trong số ít việc robots.txt làm để GIÚP SEO thay vì chỉ ngăn cản, vì nó dẫn Google tới danh sách đầy đủ các trang bạn muốn được thu thập. Một tệp robots.txt tốt không chỉ tránh chặn nhầm, nó còn chủ động chỉ đường.

Khi nào robots.txt thực sự cần thiết — và khi nào nên để yên

Sau tất cả những lời phê bình, công bằng mà nói robots.txt vẫn có chỗ đứng chính đáng. Nó hữu ích để chặn bot thu thập những vùng thực sự không có giá trị tìm kiếm và có thể ngốn tài nguyên thu thập: các trang quản trị nội bộ, kết quả tìm kiếm trên chính website, những vùng sinh ra vô số biến thể địa chỉ vô nghĩa. Với website rất lớn — hàng trăm nghìn trang trở lên — việc điều hướng bot khỏi những vùng vô ích để nó tập trung vào nội dung quan trọng là một mối quan tâm có thật, và tôi đã bàn riêng về chuyện này trong bài crawl budget khi nào cần quan tâm.

Nhưng với phần lớn website doanh nghiệp Việt Nam — vài chục đến vài nghìn trang — sự thật ít người nói ra là: tệp robots.txt đơn giản nhất thường là tệp tốt nhất. Một tệp chỉ cho phép thu thập mọi thứ, chặn vài vùng quản trị thật sự cần chặn, và trỏ tới sitemap, là quá đủ. Mọi dòng Disallow thêm vào đều là một cơ hội để tự bắn vào chân mình. Đừng phức tạp hoá một tệp mà sự phức tạp chỉ làm tăng rủi ro chứ không tăng lợi ích.

Cái bẫy lớn nhất với robots.txt không phải là thiếu tính năng, mà là ảo tưởng kiểm soát. Người ta thêm dòng Disallow vì cảm thấy như vậy là đang "tối ưu", trong khi thực ra mỗi dòng là một rủi ro chặn nhầm. Thái độ đúng với robots.txt là thái độ tối giản và thận trọng: chạm vào càng ít càng tốt, và mỗi lần chạm đều kiểm chứng lại bằng Search Console.

Tổng kết: một tệp nhỏ, hậu quả lớn

robots.txt là minh chứng rõ nhất cho một sự thật khó chịu của SEO kỹ thuật: thiệt hại lớn nhất thường không đến từ những thứ phức tạp, mà từ những thứ nhỏ bé bị bỏ quên. Một dòng Disallow đặt sai chỗ có thể xoá sổ nhiều traffic hơn cả một chiến dịch nội dung dài hơi mang về. Và vì nó không kêu la, không báo lỗi, không làm website chậm đi, nó là loại sự cố dễ sống sót qua hết đợt rà soát này tới đợt rà soát khác mà không ai phát hiện.

Cách phòng vệ không phải là một công cụ đắt tiền hay một kỹ thuật cao siêu, mà là kỷ luật: đọc tệp robots.txt của bạn ngay hôm nay, kiểm tra những trang quan trọng nhất bằng Search Console, và thiết lập thói quen rà soát định kỳ. Hiểu cho rõ rằng Disallow chặn thu thập chứ không ẩn trang, rằng noindex mới là công cụ ẩn trang, và rằng hai thứ đó không bao giờ nên đặt chung một chỗ. Riêng việc nắm chắc những nguyên tắc này đã đưa bạn vượt qua phần lớn website đang âm thầm tự bóp nghẹt traffic của họ mà không biết.

Việc rà soát robots.txt, đối chiếu phiên bản render, theo dõi báo cáo lập chỉ mục để bắt trang bị chặn nhầm — đó chính xác là loại công việc kỹ thuật lặp đi lặp lại, dễ bị bỏ quên giữa trăm thứ khác, mà một AI agent làm SEO như Orova được sinh ra để gánh: chạy nền liên tục, soi tệp robots.txt cùng các tín hiệu kỹ thuật khác, và báo động ngay khi một dòng Disallow bắt đầu rút trang quan trọng ra khỏi Google — trước khi traffic kịp rơi. Một tệp nhỏ như vậy không đáng để bạn mất ngủ, nhưng cũng tuyệt đối không đáng để bị bỏ quên.

Để AI Agent lo SEO cho bạn

Orova tự lên kế hoạch, viết bài, tối ưu và theo dõi thứ hạng — bạn chỉ việc đọc kết quả.

Dùng thử miễn phí