Lượng truy cập từ công cụ tìm kiếm vào blog này đã đứng yên vài năm nay, và tôi cũng thôi mong nó nhúc nhích. Nên thay vào đó tôi đi xem khách đến từ đâu, và trong số đó có các trợ lý AI (AI assistant) hay không. Có, nhưng chỉ vừa đủ để gọi là có. Trong mười hai tháng tính đến ngày 16 tháng 9 năm 2026, công cụ phân tích truy cập của tôi đếm được 5,372 phiên truy cập (session) ở đây. Hai mươi bảy phiên trong số đó đến từ một trợ lý AI: mười hai từ chatgpt.com, chín từ gemini.google.com, sáu từ Perplexity, và không có phiên nào từ claude.ai. Nửa phần trăm. Nhưng khách đến từ ChatGPT lại là loại khách tốt. Họ ở lại trung bình năm phút, so với 27 giây của lượt truy cập trực tiếp và ba phút của khách từ Google, vì họ đã đọc xong câu trả lời rồi và muốn xem chi tiết.

Nên tôi đã dành thời gian tìm hiểu xem một blog nhỏ làm thế nào để được chọn làm nguồn cho những câu trả lời đó. Bài này là những gì tôi đã làm trên trang này, cùng với những gì log nói về chuyện đó. Chỗ nào có số thì tôi đưa số, chỗ nào đang đoán thì tôi nói rõ là đoán. Có ba câu trong bản nháp đầu hóa ra sai khi tôi thực sự nhìn vào số liệu, và tôi để nguyên các chỗ sửa trong bài.

Hai loại bot, và chỉ một loại trích dẫn bạn

#

Điều đầu tiên cần phân định rõ là “bot AI” thực ra là hai công việc khác nhau với hai bộ user agent khác nhau, và chặn loại này chẳng ảnh hưởng gì đến loại kia.

Trình thu thập dữ liệu (crawler) huấn luyện kéo trang về hàng loạt để xây mô hình tiếp theo. Của OpenAI là GPTBot, của Anthropic là ClaudeBot, của Google được điều khiển qua token Google-Extended, của Apple qua Applebot-Extended, còn CCBot của Common Crawl thì cấp dữ liệu cho phần lớn các bộ dữ liệu mở. Những gì chúng lấy đi cuối cùng trở thành trọng số (weights) của mô hình, không có đường dẫn nào trỏ ngược về bạn. Chặn những bot này là có lý, và tôi không cho đó là chuyện vớ vẩn.

Bot truy xuất (retrieval bot) là loại còn lại. Khi ai đó hỏi ChatGPT, Claude hay Perplexity một câu, trợ lý sẽ chạy một lượt tìm kiếm, tải về ngay lúc đó một nhúm trang, đọc chúng, rồi viết câu trả lời kèm trích dẫn (citation). Những lượt tải đó đến dưới tên OAI-SearchBot và ChatGPT-User, Claude-SearchBot và Claude-User, PerplexityBot và Perplexity-User. AI Overviews của Google thì dùng Googlebot thường, nên chẳng có công tắc riêng nào cho chúng cả. Đây mới là những bot đưa người đọc quay lại với bạn. Nếu mục tiêu là được trích dẫn thì đây là những bot bạn đang tối ưu cho, và cũng nên biết rằng chặn GPTBot không ảnh hưởng gì đến kết quả tìm kiếm của ChatGPT, theo cả hai chiều.

robots.txt của trang này là bản mặc định của Hugo, tức là cho phép tất cả:

User-agent: *
Allow: /
Sitemap: https://jared.lynskey.co.nz/sitemap.xml

Tôi đã cân nhắc tách nó ra, cho bot truy xuất vào và giữ bot huấn luyện ở ngoài, rồi quyết định là không đáng làm với một blog mà mục đích duy nhất là để được đọc. Nếu tôi muốn vậy thì nó sẽ trông như khối bên dưới. Lý do đưa nó ra đây cũng là bài học trong bài Cloudflare trả về cho Googlebot một trang trống: danh sách phải gọi tên bot, không phải tên hãng. Không có dòng nào bạn viết ra được để nói “OpenAI”.

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: Applebot-Extended
User-agent: CCBot
Disallow: /

User-agent: *
Allow: /

Một điều cần kiểm tra nếu trang nằm sau Cloudflare. Từ giữa năm 2025, các zone mới ở đó chặn trình thu thập dữ liệu AI theo mặc định, và có một nút bật một chạm trong phần cài đặt bot làm điều tương tự với các zone cũ. Nó chặn cả hai loại. Blog này vừa chuyển sang Cloudflare Pages tuần trước, nên việc đó có trong danh sách của tôi. Nếu bạn bật nó lên vì “bot AI” nghe như thứ nên chặn ở ngoài, thì bạn cũng vừa tắt luôn việc được trích dẫn. Cloudflare sau đó đã bắt đầu ghi một dòng Content-Signal vào các tệp robots.txt mà họ quản lý, với ba cờ riêng search, ai-input và ai-train. Không ai bị bắt buộc phải tuân theo, nhưng đó là đúng bộ từ vựng: cùng cách phân chia như trên, diễn đạt như một nguyện vọng thay vì một bức tường.

Thực sự thì ai đang gõ cửa

#

Việc chuyển sang Cloudflare có một tác dụng phụ: lần đầu tiên tôi nhìn thấy được từng request theo user agent. Dưới đây là những gì đã ghé vào trong bốn ngày từ ngày 13 đến ngày 16 tháng 9 năm 2026, sau khi đã loại bỏ các bot giả mạo (spoof), phần này tôi sẽ nói ngay sau đây.

Có hai điều nổi bật. Các bot huấn luyện (training crawler) đọc hết mọi thứ, tới hai lần, trong khoảng thời gian mà các bot truy xuất chỉ đọc vài chục trang. Và bot truy xuất không tải về một cách ngẫu nhiên: cả ChatGPT-User lẫn Claude-User đều nhắm vào bài về máy chủ cập nhật, là bài cụ thể nhất trên trang này, còn bài về khởi động nguội bản tiếng Nhật thì được tải về đúng bằng tiếng Nhật.

Giờ đến phần giả mạo. Trong 20 request tự xưng là GPTBot, có 18 đến từ những địa chỉ nằm ngoài dải địa chỉ IP (IP range) mà OpenAI công bố, và chúng đòi /.env, /.git/HEAD và /firebase-adminsdk.json. Mười lăm trong 36 request “ChatGPT-User” cũng là kiểu đó. Phần lớn lưu lượng “PerplexityBot” thì muốn lấy /id_ed25519. User agent chỉ là một chuỗi ký tự mà ai cũng gửi được, và các công cụ quét lỗ hổng đã nhận ra rằng cứ mang tên bot AI là được cho qua. OpenAI, Anthropic và Perplexity đều công bố dải địa chỉ IP của mình. Nếu bạn định đối xử đặc biệt với một bot, dù là cho vào hay chặn lại, hãy kiểm tra địa chỉ chứ đừng tin cái tên. Các con số 20, 59 và 8 ở trên là những request đến từ đúng địa chỉ.

Trang phải đọc được mà không cần trình duyệt

#

Bot truy xuất tải trang ngay lúc trả lời, có giới hạn thời gian chờ (timeout), và phần lớn không chạy JavaScript. Một trang chỉ là cái div rỗng cho đến khi bundle tải xong là một trang chúng không đọc. Hugo xuất ra HTML hoàn chỉnh, nên blog này có sẵn điều đó mà không phải làm gì, và đó là lý do chính tôi chưa bao giờ bị cám dỗ chuyển nó sang thứ gì đó thông minh hơn. Sàn mua bán tôi đang vận hành là trường hợp ngược lại, một ứng dụng web React Native, và để trình thu thập dữ liệu nhận được một tài liệu thực sự ở đó, tôi đã phải làm một nhánh dựng trang động (dynamic rendering), rồi dính một lỗi bộ nhớ đệm (cache) lặng lẽ phá hỏng nó. Bài Cloudflare ở trên chính là câu chuyện đó.

Tốc độ cũng được tính theo cách tương tự, và ở chỗ này log đã sửa lưng tôi. Tôi vẫn đinh ninh một trang tĩnh nằm sau Cloudflare thì được phục vụ từ máy chủ biên (edge) gần nhất. Không phải vậy. Blog này chạy trên Cloudflare Pages, HTML được trả ra mà không qua bộ nhớ đệm, và từ Seoul thì phản hồi quay về từ Los Angeles mất khoảng nửa giây. Với một bot có thời gian chờ vài giây thì vẫn ổn, nhưng nó không phải vài chục mili giây như tôi suýt viết ra, và tôi biết được chỉ vì đã đo. Một trợ lý đang ghép câu trả lời từ sáu trang sẽ bỏ cái trang mất ba giây, và nó không nói cho bạn biết là nó đã bỏ.

Viết sao cho nhấc nguyên một đoạn ra được

#

Cách các hệ thống này dùng một trang không giống cách một người đọc dùng. Chúng cắt trang thành từng khúc (chunk), chấm điểm từng khúc so với câu hỏi, rồi trích những khúc điểm cao. Một bài dẫn dắt suốt tám trăm chữ mới đến ý chính thì khúc nào điểm cũng thấp. Một bài mà mỗi phần nêu luận điểm ngay câu đầu rồi mới chứng minh thì phần khớp với câu hỏi sẽ ghi điểm.

Điều đó thay đổi cách tôi viết ở đây nhiều hơn bất cứ thứ gì thuộc về kỹ thuật. Phần description trong front matter giờ là tóm tắt bài nói gì, không phải câu mồi để bạn bấm vào đọc, vì description thường là phần duy nhất trợ lý hiển thị. Tiêu đề mục nói thẳng mục đó kết luận gì. Con số đi kèm đơn vị ngay trong câu thay vì nằm trong biểu đồ. Ngày tháng được viết ra đầy đủ, vì “tuần trước” chẳng có nghĩa gì với một mô hình đọc trang này một năm sau. Và một bài chỉ nói về một chuyện.

Nửa còn lại là phải có thứ đáng để trích, và ở chỗ này số liệu lại không thuận một chiều. Trong log, những trang mà bot tải về lúc trả lời là những bài cụ thể: khởi động nguội, máy chủ cập nhật, gỡ lỗi iOS. Trình thu thập dữ liệu của Naver tên là Yeti và của Daum là Daumoa, một lần khởi động lại máy ở nhà cung cấp hosting của tôi là một khoảng ba mươi giây trả lỗi 504, Cloudflare nén Brotli tại chỗ đo trên bundle của tôi còn tệ hơn gzip. Những dữ kiện đó không được ghi lại ở nhiều nơi, nên câu hỏi nào cần đến một trong số chúng sẽ rơi vào đây. Nhưng những người bấm từ trợ lý sang thì phần lớn lại rơi vào các bài về quản lý từ năm 2023 và 2024, mỗi bài một hai phiên. Bài cụ thể thì máy đọc. Bài chung chung thì người bấm. Tôi không có lời giải thích gọn gàng nào cho chuyện đó, và tôi thà kể lại đúng như vậy còn hơn bịa ra một lý do. Đòn bẩy, nếu có, vẫn là viết ra cái điều cụ thể bạn vừa phát hiện tuần này mà lúc tìm kiếm bạn không thấy đâu, vì đó rõ ràng là thứ máy đang đọc.

Nói rõ ai viết, và lần nào cũng nói như nhau

#

Một trợ lý khi cân nhắc có trích dẫn một trang hay không đang làm gần giống một người đọc cẩn thận: ai viết cái này, viết khi nào, và nó có khớp với mọi thứ khác tôi đã tìm thấy không? Phần cơ chế của việc đó trên trang này chủ yếu là do theme làm. Mỗi bài đều mang dữ liệu có cấu trúc (structured data) kiểu Article với tác giả, ngày đăng và ngày sửa, và tác giả là một Person với liên kết đến cùng các hồ sơ công khai. Đó là vài dòng trong template, và là khác biệt giữa “một trang” với “một trang của một người có tên tuổi và có quá trình”.

Phần không phải theme làm là sự nhất quán. Trang giới thiệu, llms.txt, các hồ sơ công khai của tôi và dòng ở đầu mỗi bài đều mô tả cùng một người với cùng một quá trình làm việc. Khi có gì thay đổi thì tất cả cùng đổi, nếu không, cái tôi quên sẽ thành cái sai. Nghe có vẻ tỉ mẩn, nhưng một trang nói tôi là quản lý kỹ thuật (engineering manager) còn trang khác nói tôi làm tự do chính là kiểu mâu thuẫn khiến mô hình trả lời nước đôi, hoặc chọn người khác.

Ngày sửa cũng phải thành thật. Nó đổi khi nội dung đổi, ngoài ra tôi không đụng vào. Đẩy ngày lên cho trông có vẻ mới là kiểu chiêu dùng được một lần, rồi cả tên miền của bạn bị hạ tín nhiệm.

llms.txt là gì, và sự thật là chẳng ai đọc nó

#

llms.txt là một đề xuất từ tháng Chín năm 2024 về một tệp Markdown đặt ở gốc trang, cung cấp cho mô hình ngôn ngữ một bản tóm tắt về trang cùng một danh sách liên kết chọn lọc. Tôi thêm một tệp như vậy vào tháng Hai năm nay. Nó gồm một đoạn về tôi là ai, rồi các mục cho quản lý, hạ tầng, di động và cộng đồng, mỗi bài một dòng: tiêu đề, URL, và một câu nói bài đó kết luận gì. Đọc nó giống như một mục lục viết cho người đang vội.

Điều đáng nói là chẳng ai đọc nó. Trong bốn ngày log tôi có, những request duy nhất tới /llms.txt là của chính tôi. Common Crawl đã lấy 76 trang của site này trong đợt thu thập tháng 8 năm 2026 mà chưa lần nào đụng đến tệp đó. Chưa có trợ lý lớn nào nói rằng họ đọc nó. Nên nó không phải lý do bất cứ thứ gì ở đây được trích dẫn, và tôi sẽ không khuyên ai làm nó vì lý do đó. Tôi giữ nó vì hai lý do. Nó tốn một tiếng, và việc viết cho mỗi bài một câu nói bài đó thực sự kết luận gì còn đáng giá hơn bản thân cái tệp, vì nó cho tôi thấy bài nào chẳng kết luận được gì. Nó cũng là trang duy nhất trên site nói cho máy biết trang này để làm gì, và tôi thà có mà không cần đến. Từ đó nó đã lệch đi, vì tôi viết tay và hay quên, và đó là lý do nên sinh nó từ front matter như một định dạng đầu ra (output format) của Hugo thay vì viết tay. Việc đó đang nằm trong danh sách.

Feed, sitemap và năm ngôn ngữ

#

Phần đường ống nhàm chán vẫn có giá trị. Sitemap là cách trình thu thập dữ liệu tìm thấy bài mới ngay ngày nó lên. RSS là cách nó biết một bài đã thay đổi. Cả hai đều là mặc định của Hugo và tôi chưa bao giờ phải nghĩ đến. ClaudeBot đọc sitemap 36 lần trong hai ngày, và đó là cách nó tìm ra 1,380 trang nhanh đến vậy.

Ngôn ngữ là phần tôi không ngờ lại quan trọng. Mọi thứ ở đây có bản tiếng Anh, Nhật, Hàn, Trung giản thể và Việt, với các liên kết thay thế (alternate link) để trình thu thập dữ liệu biết chúng là cùng một bài. Các trình thu thập dữ liệu coi chúng như năm site riêng: lượt thu thập của ClaudeBot chia gần như đều cho cả năm, và trong 73 trang bài viết mà Common Crawl lấy hồi tháng 8, chỉ có bốn trang là bản tiếng Anh. Trợ lý trả lời bằng ngôn ngữ được hỏi và nghiêng về nguồn bằng chính ngôn ngữ đó, nên một câu hỏi tiếng Hàn về khởi động nguội có thể được trả lời từ trang tiếng Hàn thay vì từ một bản dịch tại chỗ của trang tiếng Anh, và trang tiếng Nhật chính là trang mà ChatGPT thực sự đã tải về. Điều kiện là bản dịch phải đọc như thể được viết bằng chính ngôn ngữ đó. Lượt rà soát tôi làm đầu năm nay, có người bản ngữ kiểm tra, là dành cho người đọc, nhưng nó cũng là thứ khiến trang tiếng Việt trở thành một nguồn thay vì một món lạ.

Những gì tôi đo được

#

Nhiều hơn tôi tưởng, một khi tôi thôi đoán mò. Gói miễn phí của Cloudflare cho xem log request theo user agent và đường dẫn, mỗi lần truy vấn được một ngày, và bảng bot ở trên là từ đó mà ra; còn muốn xem referrer thì phải lên gói trả phí. Công cụ phân tích truy cập thì có referrer, và kéo chúng ra qua API báo cáo của nó thay vì căng mắt nhìn dashboard chính là cách tôi có được các con số ở đầu bài. Ghép hai nguồn lại thì thấy được hình dạng của câu chuyện. Trong bốn ngày, các bot truy xuất tải về khoảng chín mươi trang từ các địa chỉ của OpenAI và Anthropic. Trong tháng vừa rồi, có hai người đến từ ChatGPT. Đọc nhiều, thỉnh thoảng trích dẫn, hiếm khi bấm vào. Vẫn chưa có cách nào tôi biết để xem những câu trả lời đã dùng một trang mà không được bấm vào. Cách kiểm tra hữu ích nhất vẫn là làm bằng tay: hỏi trợ lý đúng câu hỏi mà bài của bạn trả lời, rồi xem nó trích trang của ai.

Nếu phải giữ lại một thứ từ tất cả những điều này thì đó là quy tắc viết. robots.txt, dữ liệu có cấu trúc và llms.txt là công việc của một buổi chiều, xong là xong. Viết sao cho mỗi phần nêu luận điểm trước, và viết về điều cụ thể thay vì điều chung chung, là một thói quen, và chính thói quen đó quyết định một trang có đáng trích dẫn hay không. Điều thứ hai là hãy đo trước rồi hãy khẳng định. Hóa ra được máy tin cậy trông rất giống được người tin cậy: nói bạn là ai, nói bạn biết gì, và lần nào cũng nói theo cùng một cách.

Ứng dụng chợ (marketplace) mà tôi đang làm là một ứng dụng trang đơn (single-page app) viết bằng React Native Web. Trước khi JavaScript chạy, trang tin đăng (listing) nào cũng chỉ có đúng một thẻ script và một thẻ div rỗng. Với người dùng thì chẳng sao, nhưng với công cụ tìm kiếm thì coi như xong: Google thỉnh thoảng chạy được JS, Bing thì không, còn trình thu thập dữ liệu (crawler) của Naver — thứ quan trọng nhất với một trang web mà gần như toàn bộ tin đăng đều bằng tiếng Hàn — thì chắc chắn là không.

Bài này kể lại quá trình tôi làm cho các trang đó hiện ra với công cụ tìm kiếm, rồi chuyện một quy tắc lưu đệm (cache rule) phá hỏng tất cả theo cách tôi không hề lường trước.

Kết xuất động, chứ không phải che giấu nội dung

#

Cách sửa thì chẳng có gì mới, và được chính Google chấp nhận dưới cái tên kết xuất động (dynamic rendering), khác hẳn với che giấu nội dung (cloaking): nhận diện trình thu thập dữ liệu, rồi trả cho nó HTML đã kết xuất (render) sẵn ở máy chủ, chứa đúng nội dung mà SPA lẽ ra sẽ vẽ lên màn hình. Không phải nội dung khác. Vẫn nội dung ấy, chỉ là có sớm hơn.

Vì vậy, một URL tin đăng như /listings/view?id=... được tách làm hai nhánh. Trình duyệt nhận phần khung (shell) của SPA. Trình thu thập dữ liệu nhận một tài liệu HTML thật sự: tiêu đề, các thông tin chính của tin đăng, mỗi ảnh một thẻ ảnh kèm văn bản thay thế (alt text), một đoạn trích nội dung, và liên kết sang vài tin đăng liên quan để trang không bị mồ côi.

Phần cuối này hoá ra quan trọng hơn tôi nghĩ. Trước khi có mấy liên kết nội bộ đó, khoảng một nghìn trang tin đăng nằm trơ trọi, không có liên kết nào trỏ tới, và Search Console cho thấy lượng thu thập chững lại ở mức bảy đến mười một yêu cầu mỗi ngày. Trình thu thập dữ liệu mà không tìm thấy trang của bạn thì trang có hay đến mấy cũng vô nghĩa.

Cái bẫy: tên công ty không phải là tên bot

#

Nhận diện trình thu thập dữ liệu thực chất là so khớp chuỗi user-agent, và tôi dính đòn đúng ở bước này.

Các nền tảng Hàn Quốc cho trình thu thập dữ liệu chạy dưới những cái tên chẳng liên quan gì tới tên công ty. Trình thu thập của Naver tên là Yeti. Của Daum là Daumoa. Còn công cụ cào dữ liệu (scraper) lấy bản xem trước liên kết của Kakao là kakaotalk-scrap. Không cái nào mang đúng tên công ty.

Trong khi đó, cũng chính mấy công ty này làm ứng dụng có trình duyệt nhúng bên trong, và trình duyệt đó gửi user-agent y như trình duyệt thật, chỉ gắn thêm tên ứng dụng ở cuối. Trình duyệt trong ứng dụng KakaoTalk ghi KAKAOTALK/10.5.1. Công cụ cào dữ liệu của Kakao thì ghi kakaotalk-scrap/1.0.

Cứ so khớp theo kakao là bạn tóm luôn cả hai. Tôi đã làm đúng như vậy, thế là người dùng KakaoTalk, ứng dụng Naver hay ứng dụng Daum nào mở liên kết cũng nhận về trang dành cho trình thu thập: không JavaScript, không điều hướng, không đăng nhập. Một tài liệu hoàn toàn chuẩn chỉnh, nhưng với con người thì vô dụng.

Cách sửa là một quy tắc về thứ tự kiểm tra, và đáng để viết hẳn ra thành quy tắc:

import re

# In-app browsers append the app's name to an ordinary browser UA.
INAPP_BROWSER_RE = re.compile(r"kakaotalk/|naver\(inapp|daumapps", re.I)

# Name the bot, never the vendor: Naver crawls as Yeti, Daum as Daumoa,
# Kakao's link-preview scraper as kakaotalk-scrap.
CRAWLER_RE = re.compile(r"googlebot|bingbot|yeti/|daumoa|kakaotalk-scrap", re.I)


def is_crawler(user_agent: str) -> bool:
    # An in-app browser is never a crawler, so that check comes first.
    if not user_agent or INAPP_BROWSER_RE.search(user_agent):
        return False
    return bool(CRAWLER_RE.search(user_agent))

Trình duyệt trong ứng dụng được kiểm tra trước, và luôn thắng. Còn token nhận diện trình thu thập nào cũng phải là tên của một bot, tuyệt đối không phải tên công ty.

Rồi tôi đặt Cloudflare đứng trước

#

Máy chủ gốc (origin) chỉ là một máy shared-cpu duy nhất đặt ở Sydney, chịu tải ổn định được khoảng hai mươi đến ba mươi yêu cầu mỗi giây. Googlebot có chừng 995 URL cần đi qua. URL nào cũng chạy thẳng về Sydney, vì cf-cache-status ở tất cả đều là DYNAMIC: Cloudflare không lưu đệm HTML trừ khi có quy tắc bảo nó làm vậy. Cả vùng (zone) chỉ khoảng 16% được lưu đệm, và phần quan trọng thì không nằm trong số đó.

Vậy thì thêm một quy tắc lưu đệm cho các trang dành cho trình thu thập. Đơn giản. Có điều, một URL tin đăng không chỉ có một phần thân (body). Nó có tới ba.

• Trình thu thập dữ liệu xin HTML thì nhận trang kết xuất ở máy chủ.
• Người dùng thật thì nhận phần khung của SPA.
• Tác tử AI (AI agent) gửi Accept: text/markdown thì nhận markdown dựng từ cơ sở dữ liệu, vì đem một khung HTML rỗng đi chuyển đổi thì cũng chỉ ra một tài liệu rỗng.

Máy chủ gốc có trả Vary: Accept, còn Vary theo user-agent thì đằng nào cũng vô vọng. Và đây là điều tôi không hề biết:

Cloudflare bỏ qua Vary với HTML. Cả ba phần thân dùng chung một khoá lưu đệm (cache key).

Phần thân nào tới trước sẽ chiếm luôn URL đó cho mọi lượt truy cập sau ở điểm biên (edge location) ấy, trong suốt một tiếng mà s-maxage của máy chủ gốc cho phép, cộng thêm một ngày stale-while-revalidate.

Tôi được tận mắt thấy chuyện này trên môi trường production, theo cả hai chiều:

• Một người dùng ứng dụng Naver mở một URL tin đăng trước, bộ nhớ đệm giữ lại trang dành cho trình thu thập, rồi sau đó Safari bình thường trên iPhone nhận đúng trang ấy dưới dạng HIT. Một con người ngồi nhìn một tài liệu không có tí JavaScript nào.
• Một người dùng thật mở một URL trước, bộ nhớ đệm giữ lại phần khung của SPA, và Googlebot nhận về cái khung rỗng. Đúng cái lỗi mà cả nỗ lực SEO sinh ra để ngăn chặn, giờ lại còn được phục vụ nhanh hơn, ngay từ máy chủ biên.

Cái quy tắc sửa lỗi bằng cách thu hẹp phạm vi

#

Bạn không thể bắt Cloudflare tôn trọng Vary với HTML. Cái bạn làm được là đảm bảo trong ba phần thân đó, chỉ đúng một cái có cửa vào bộ nhớ đệm:

(starts_with(http.request.uri.path, "/listings/")
 and not any(http.request.headers["accept"][*] contains "text/markdown")
 and (lower(http.user_agent) contains "googlebot" or ...)
 and not (lower(http.user_agent) contains "kakaotalk/" or ...))

Chỉ khớp user-agent của trình thu thập, và loại trừ yêu cầu xin markdown. Giờ yêu cầu của người dùng thật không khớp quy tắc nào cả, nên nó là DYNAMIC và đi về máy chủ gốc như trước. Chỉ yêu cầu của trình thu thập mới được đọc hoặc ghi bộ nhớ đệm, nên phần thân duy nhất có thể nằm trong đó là phần thân dành cho trình thu thập.

Edge TTL để là respect_origin, nên thời gian sống của dữ liệu đệm vẫn do chính phần mã kết xuất trang quyết định, chứ không bị đóng cứng trong một bảng điều khiển nào đó.

Có một chi tiết vận hành rất dễ bỏ sót: thu hẹp quy tắc không xoá những gì đã nằm sẵn trong bộ nhớ đệm. Bạn phải xoá bộ nhớ đệm (purge), không thì vẫn tiếp tục trả ra những mục nhiễm độc mà mình vừa ngừng tạo ra.

Hai danh sách, và vì sao sai lệch giữa chúng không đối xứng

#

Quy tắc này cần một danh sách user-agent của trình thu thập, mà Django thì đã có sẵn một danh sách như vậy. Cùng một kiến thức mà nằm hai bản ở hai hệ thống thường là dấu hiệu có vấn đề. Nhưng ở đây, điều thú vị là chuyện gì xảy ra khi hai bản lệch nhau, vì hậu quả không đối xứng:

• Danh sách bot trong Cloudflare phải luôn là tập con của danh sách trong Django. Nếu có token mà Cloudflare coi là bot còn Django thì không, phần khung SPA sẽ bị lưu đệm dưới khoá chỉ dành cho trình thu thập, rồi bị trả cho một trình thu thập thật.
• Danh sách loại trừ trình duyệt trong ứng dụng phải luôn là tập cha của danh sách trong Django. Loại trừ thừa thì cùng lắm bạn mất một lần trúng bộ nhớ đệm (cache hit).

Sai theo chiều an toàn, dù ở danh sách nào, thì bạn chỉ mất một ít dữ liệu đệm. Nhưng sai danh sách đầu theo chiều ngược lại là bạn quay về cảnh trả cho Googlebot một trang trống. Nhân tiện, cũng vì sự bất đối xứng đó mà hai danh sách dùng contains chứ không dùng biểu thức chính quy (regex): matches đòi gói Business, còn contains là đủ cho một danh sách được phép xấp xỉ, miễn là lệch về phía đã biết là an toàn.

Một bất biến làm hỏng bản dựng thay vì làm hỏng trang

#

Các trang dành cho trình thu thập nhúng URL ảnh dạng ký sẵn (presigned), có hiệu lực bảy ngày. Còn bản thân các trang thì được lưu đệm ở máy chủ biên một tiếng, cộng thêm một ngày stale-while-revalidate.

Hai con số này dính dáng tới nhau. Nếu có ngày thời gian lưu đệm vượt quá thời hạn của ảnh, máy chủ biên sẽ bắt đầu trả ra những trang mà ảnh nào cũng dính lỗi 403. Sẽ chẳng có cảnh báo nào kêu cả, vì HTML vẫn hoàn toàn bình thường.

Nên đoạn mã định nghĩa mấy con số đó sẽ từ chối nạp (import) nếu quan hệ này bị phá vỡ:

CRAWLER_IMAGE_TTL = 7 * 24 * 3600  # presigned image URLs
EDGE_S_MAXAGE = 3600
EDGE_STALE_WHILE_REVALIDATE = 24 * 3600

# Fail at import time if the edge cache could outlive the image URLs.
if EDGE_S_MAXAGE + EDGE_STALE_WHILE_REVALIDATE >= CRAWLER_IMAGE_TTL:
    raise RuntimeError("edge cache lifetime must stay below the image URL lifetime")

Một ràng buộc giữa hai hằng số nằm ở hai tệp khác nhau thì gần như vô hình khi rà soát mã, nhưng lộ ra ngay khi tiến trình khởi động. Vậy thì cứ đặt phép kiểm tra ở chỗ tiến trình khởi động.

Hai thứ Cloudflare làm mà tôi phải gỡ lại

#

Vary: Origin khiến gói JavaScript không vào được bộ nhớ đệm. django-cors-headers đóng dấu Vary: Origin lên mọi phản hồi mà nó đi qua, còn Cloudflare thì không lưu đệm bất cứ thứ gì vary theo nhiều hơn Accept-Encoding. Thế là gói JavaScript (bundle) 1.6 MB — thứ nặng nhất trên đường tải quan trọng (critical path) — lặng lẽ bị loại hẳn khỏi máy chủ biên. Cách sửa là một middleware đặt đầu tiên trong danh sách, để nó chạy sau cùng lúc phản hồi đi ra, và viết lại Vary cho các đường dẫn tài nguyên tĩnh.

Nén ở máy chủ biên còn tệ hơn nén ở máy chủ gốc. Để Cloudflare tự nén Brotli tức thời thì ra 2,041,742 byte, trong khi gzip của chính máy chủ gốc chỉ ra 1,658,115. To hơn hai mươi ba phần trăm, chỉ để đổi lấy cái sướng là không phải nghĩ ngợi gì. Nén tức thời tối ưu cho CPU chứ không tối ưu cho tỉ lệ nén; tài nguyên nén sẵn từ máy chủ gốc vẫn thắng.

Báo cho công cụ tìm kiếm mà không cần chờ được thu thập

#

Có hai giao thức, nhưng gộp cả hai lại thì phạm vi phủ vẫn ít đến đáng thất vọng.

IndexNow chỉ cần một cú ping là phủ được Bing, Yandex và Seznam. Google và Naver thì không tham gia. Mỗi khi một tin đăng được lưu, tôi gửi ping ở chế độ nền với thời gian chờ ngắn, và bỏ qua tin đăng đã bán hoặc đã đóng. Gặp lỗi mạng thì nó ghi một dòng cảnh báo vào nhật ký và không bao giờ làm hỏng lần lưu đã kích hoạt nó. Với một kênh phụ kiểu làm được đến đâu hay đến đó (best-effort), đó là cách hành xử duy nhất chấp nhận được.

Indexing API của Google chỉ nhận đúng hai loại schema, và một trong hai là JobPosting, thứ mà tôi lại có. Tin tuyển dụng còn mở thì gửi URL_UPDATED, tin đã đóng thì gửi URL_DELETED. Lệnh xoá đó chỉ trung thực vì tin đăng đã đóng cũng trả noindex, và mã nguồn có ghi chú rõ chuyện này, để lỡ ai gỡ noindex đi thì cũng biết mình còn làm hỏng thêm thứ gì.

Có hai chỗ làm tôi mất thời gian. Thứ nhất, hạn mức (quota) là 200 URL mỗi ngày, mà một lần nhập hàng loạt tin đăng sẽ gọi nó hàng trăm lần — nên tin đăng nhập vào phải được bỏ qua, không thì một lần nhập đốt sạch hạn mức của cả ngày. Thứ hai, endpoint là urlNotifications:publish, dùng dấu hai chấm. Dùng dấu gạch chéo là Google trả về một trang HTML 404 trơn, trông y hệt như API đang bị tắt.

Dữ liệu có cấu trúc dạy tôi những gì

#

Ba quy tắc về dữ liệu có cấu trúc (structured data), cái nào cũng học được sau khi bị Search Console phàn nàn:

1. Không phân tích được thì bỏ ra. Mức lương gửi đến dưới dạng văn bản tự do. Trước đây tôi nhét nguyên chuỗi đó vào baseSalary.value, vốn không hợp lệ, thế là tin tuyển dụng nào cũng bị gắn cờ thiếu đơn vị. Giờ lương nào không phân tích (parse) được thì đơn giản là không có.
2. Đừng bao giờ bịa ra một trường chỉ để chiều schema. Tin tuyển dụng hiếm khi ghi địa chỉ cụ thể đến tên đường. Rất dễ bị cám dỗ bịa ra một địa chỉ nghe hợp lý cho PostalAddress. Nhưng một địa chỉ bịa trên tin tuyển dụng còn tệ hơn một địa chỉ thiếu, nên tôi chỉ đưa vào khu vực (locality) và quốc gia.
3. Ngày hết hạn không phải là tuỳ chọn. Google bỏ qua JobPosting nào không có validThrough, nên tôi tự suy ra một giá trị, kèm mức sàn để một tin đăng cũ không tự nhận là đã hết hạn từ hôm qua.

Còn quy tắc thứ tư, về sơ đồ trang web (sitemap): đừng khai changefreq: daily cho mọi thứ. Bảo Googlebot thu thập lại một nghìn tin đăng mỗi ngày thì trong mắt nó, máy chủ của bạn đang quá tải, và nó sẽ đáp lại bằng cách giảm tốc độ thu thập cho cả trang web. Hãy suy ra giá trị này từ lần gần nhất nội dung thực sự thay đổi.

Sơ đồ trang web cũng có một mức sàn về chất lượng: tiêu đề và nội dung cộng lại phải đủ bốn mươi ký tự. Search Console từng báo khoảng một nghìn tin đăng ở trạng thái “Crawled – currently not indexed”, và có một trang đồ cũ mà toàn bộ nội dung riêng của nó chỉ gồm một tiêu đề đúng một chữ và một số điện thoại. Bốn mươi ký tự là tôi cố tình đặt thấp, vì 471 trên 484 tin đăng viết bằng tiếng Hàn, mà tiếng Hàn chứa được nhiều ý hơn trên mỗi ký tự; một ngưỡng canh theo tiếng Anh sẽ loại mất một nửa sàn mua bán. Tin đăng nào nội dung mỏng thì vẫn được thu thập qua các trang danh mục, và sẽ tự động quay lại sơ đồ trang web khi có người sửa chúng.

Tôi rút ra được gì

#

• Trả nhiều phần thân khác nhau ở cùng một URL trước hết là bài toán khoá lưu đệm, rồi mới đến chuyện khác. Hãy tìm hiểu xem CDN của bạn lấy khoá theo những gì, và cứ giả định nó bỏ qua Vary cho đến khi bạn chứng minh được điều ngược lại với đúng kiểu nội dung (content type) đó.
• Khi hai hệ thống phải thống nhất về một danh sách, hãy xác định chiều sai nào là an toàn, rồi ghi điều đó ngay cạnh cả hai bản. Nói thẳng “hai bản này có thể lệch nhau, và đây là cách duy nhất chúng được phép lệch” vẫn hơn là giả vờ chúng không bao giờ lệch.
• So khớp bot theo tên bot, đừng bao giờ theo tên công ty. Nhất là ở ngoài thế giới nói tiếng Anh, nơi chính công ty làm bot cũng làm luôn cái trình duyệt mà người dùng của bạn đang cầm trên tay.
• Bất biến giữa những hằng số nằm xa nhau thì hãy đặt ở chỗ nào hỏng thật to. Kiểm tra lúc nạp mô-đun chẳng tốn gì, và không ai lách qua được.

Đó chính là khuyết điểm dễ thấy của lượt xem và lượt bình chọn (upvote): chúng chỉ thưởng cho những gì vốn đã nổi. Nội dung mới thì chết đói dưới đáy bảng tin, và dần dần nền tảng biến thành một kênh chiếu lại. Ở chỗ tôi làm, xếp hạng bảng tin cho tốt là một trong những bài toán khó mà ít ai để ý, nên tôi đã dành khá nhiều thời gian nghĩ xem còn những tín hiệu nào khác đáng tin.

Nhìn vào việc người ta làm, đừng chỉ nhìn chỗ họ bấm

#

Người dùng hiếm khi chủ động góp ý, mà có góp ý thì cũng thiên lệch; ngược lại, dữ liệu hành vi thì có rất nhiều. Thời gian ở lại trang và độ sâu cuộn cho biết người ta có đọc thật hay bỏ đi ngay sau đoạn đầu. Lượt quay lại còn tốt hơn nữa — quay lại đọc một bài là lời khen mạnh hơn bất kỳ lượt bình chọn nào. Còn thoát ra nhanh là một tín hiệu tiêu cực đáng giá: nội dung đã hứa hẹn một điều mà người đọc không nhận được.

Tín hiệu nằm sẵn trong chính nội dung

#

Nội dung tốt không phải lúc nào cũng gom được lượt thích ngay từ đầu, nhưng thường nó thể hiện chất lượng theo những cách khác. Tính mới là một — bài này có nói về điều gì mà nền tảng chưa từng có không? Cấu trúc là một yếu tố nữa; trình bày gọn gàng, ngữ pháp ổn và diễn đạt rõ ràng đi đôi với chất lượng nhiều hơn ta muốn thừa nhận. Lịch sử của tác giả cũng là một điểm xuất phát hợp lý, miễn là xét theo khả năng giữ chân người đọc của các bài cũ chứ không phải số lượt thích thô. Bình luận sớm cũng có ích: ba bình luận tích cực thật lòng đáng giá hơn ba mươi lượt bình chọn bấm theo phản xạ, và chỉ cần phân tích ngữ nghĩa một chút là đã có thể đánh dấu những nội dung lấp được khoảng trống mà nền tảng đang thiếu.

Mượn tín hiệu từ bên ngoài

#

Internet rộng lớn ngoài kia cho bạn biết cái gì đang được quan tâm ngay lúc này. Nội dung khớp với những từ khoá tìm kiếm đang lên thì đã có sẵn độ liên quan, và bài nào đăng nhanh về một chủ đề đang nóng thì xứng đáng được đẩy lên. Những gì đang rôm rả trên Twitter hay Reddit thường là bản xem trước cho những gì người dùng của bạn sẽ muốn tiếp theo — chỉ cần dự đoán một chút, bạn có thể đẩy nội dung mới phù hợp lên trước khi con sóng tới, thay vì chạy theo sau. Ô tìm kiếm ngay trên nền tảng của bạn cũng hay bị đánh giá thấp: nếu người dùng cứ tìm mãi một chủ đề, hay một bài đều đặn kéo lưu lượng truy cập (traffic) từ công cụ tìm kiếm về, thì đó là độ liên quan mà bạn chẳng cần phải đoán.

Gộp các tín hiệu thành một điểm số

#

Dưới đây là ý tưởng đó viết thành vài dòng Python. Đây chỉ là ví dụ minh họa, không phải một hệ thống chạy thật trên môi trường production. Mỗi tín hiệu được chuẩn hóa (normalise) về khoảng 0 đến 1 để tín hiệu nào có con số thô lớn cũng không lấn át phần còn lại, tổng có trọng số gộp chúng thành một điểm duy nhất, và hệ số suy giảm theo thời gian (time decay) cho bài mới một cơ hội sòng phẳng để cạnh tranh với bài “hot” của tháng trước.

WEIGHTS = {"read_depth": 0.3, "revisits": 0.25, "quality": 0.25, "early_comments": 0.2}
HALF_LIFE_HOURS = 48  # a post loses half its score every two days

def normalise(values):
    lo, hi = min(values), max(values)
    return [(v - lo) / (hi - lo) if hi > lo else 0.0 for v in values]

def rank(items):
    """items: dicts holding raw signal values plus "age_hours"."""
    norm = {name: normalise([item[name] for item in items]) for name in WEIGHTS}
    scores = []
    for i, item in enumerate(items):
        base = sum(weight * norm[name][i] for name, weight in WEIGHTS.items())
        scores.append(base * 0.5 ** (item["age_hours"] / HALF_LIFE_HOURS))
    order = sorted(range(len(items)), key=lambda i: scores[i], reverse=True)
    return [items[i] for i in order]

Các trọng số chỉ là phỏng đoán cho tới khi những thử nghiệm ở phần dưới chứng minh điều ngược lại. Lượt xem và lượt thích vẫn có thể đưa vào; chỉ là chúng trở thành một đầu vào trong số nhiều đầu vào, chứ không còn là toàn bộ điểm số. Chu kỳ bán rã (half-life) quyết định bài cũ chìm xuống nhanh đến đâu, và đó là cả một chủ đề riêng: tôi đã viết kỹ về nó trong bài thuật toán xếp hạng bảng tin quyết định khi nào bài cũ bị dìm xuống. Các hệ thống thật thường để mô hình tự học trọng số thay vì chọn bằng tay, nhưng hình dạng thì vẫn vậy: nhiều tín hiệu đi vào, một con số đi ra, rồi sắp xếp.

Rồi kiểm thử cho sòng phẳng

#

Tín hiệu có khéo đến đâu cũng phải đem đi thử nghiệm A/B (A/B test) — cho một nhóm nhỏ người dùng xem nội dung mới rồi so mức tương tác với những bài đang giữ vị trí. Và để ý xem nội dung lan ra thế nào: lượt chia sẻ, lượt nhắc đến và lượt nhúng, cả trong lẫn ngoài nền tảng, nói lên giá trị nhiều hơn hẳn cái bộ đếm lượt xem.

Không chỉ số đơn lẻ nào trụ nổi khi va chạm với thực tế. Những cách xếp hạng thật sự hiệu quả đều pha trộn hành vi người dùng, chất lượng nội tại, tính thời sự và những thử nghiệm sòng phẳng, và không tín hiệu nào được quyền quyết định sau cùng.

Cập nhật tháng 10/2026: từ khi tôi viết bài này, rất nhiều lượt tìm kiếm hiện ra một câu trả lời do AI viết trước cả danh sách liên kết, chẳng hạn AI Overviews (phần tổng quan do AI tạo) của Google, ChatGPT search và những công cụ tương tự. Các câu trả lời đó có ghi nguồn và gắn liên kết tới những trang mà chúng dựa vào, và trang dễ được trích dẫn nhất là trang thật sự hữu ích, nói thẳng ra câu trả lời. Vì vậy, quy tắc nhàm chán ở cuối bài này không hề bớt quan trọng, mà còn quan trọng hơn. Những gì tôi đã thay đổi trên blog này vì chuyện đó, tôi viết lại trong bài Tối ưu blog để trở thành nguồn mà các trợ lý AI trích dẫn.

Vì sao đi theo số đông phần lớn là ổn

#

Các phương pháp tốt nhất (best practice) được gọi như vậy là có lý do cả. Chúng được đúc kết từ dữ liệu của hàng nghìn trang web, và nếu bạn mới làm SEO thì chỉ cần theo chúng là đã đi được gần hết quãng đường mà chẳng gặp trắc trở gì. Đi theo lối mòn cũng có nghĩa là ít gặp bất ngờ khó chịu hơn — làm đúng y những gì chính tài liệu của Google khuyến nghị thì khó mà bị một bản cập nhật thuật toán phạt. Mà thuật toán thì thay đổi liên tục, nên riêng chuyện theo kịp hướng dẫn hiện hành thôi cũng đã là cả một khối việc.

Vấn đề là ai cũng đang đọc cùng những hướng dẫn đó. Khi mọi trang trong một ngách đều có cùng một cấu trúc, cùng những tiêu đề nhồi từ khoá và cùng một khối câu hỏi thường gặp (FAQ) gắn vội ở cuối trang, thì chẳng trang nào nổi bật cả. Bạn cũng sẽ mãi ở thế bị động: ngồi chờ bản cập nhật tiếp theo, rồi cuống cuồng sửa theo cho kịp.

Lý do nên thử cách của riêng mình

#

Thử nghiệm là cách để bạn tìm ra những chiến thuật hợp riêng với trang của mình. Cái hiệu quả với một cộng đồng mỹ phẩm chưa chắc đã hiệu quả với một blog nấu ăn, và không danh sách kiểm tra chung chung nào chỉ ra được sự khác biệt đó. Nếu một thử nghiệm thành công, bạn sẽ có một khoảng thời gian là người duy nhất làm như vậy. Còn nếu thành công ấy được nhiều người biết đến, người ta sẽ bắt đầu coi bạn là hình mẫu để học theo, và điều đó cũng mang lại giá trị cộng dồn của riêng nó.

Nói thật thì mặt trái là phần lớn thử nghiệm đều thất bại trong im lặng. Bạn có thể đổ vài tuần vào một thử nghiệm mà cuối cùng chẳng có gì để khoe. Nếu lưu lượng từ tìm kiếm là thứ nuôi sống cả công ty, thì thật khó thuyết phục người đang duyệt quỹ thời gian của bạn.

Tôi chốt lại thế nào

#

Làm những việc nhàm chán trước, và làm cho đến nơi đến chốn. Sau đó dành ra một phần công sức nhỏ, có giới hạn rõ ràng cho thử nghiệm, và đo lường kết quả hẳn hoi thay vì đánh giá theo cảm giác. Trang nhỏ thì nên dựa chủ yếu vào những cách đã được kiểm chứng, chỉ thử nghiệm ở phần rìa; còn tổ chức lớn, nguồn lực dư dả thì đủ sức đặt những ván cược thật.

Quy tắc duy nhất trụ vững qua mọi bản cập nhật thuật toán cũng là quy tắc kém hấp dẫn nhất: làm ra thứ thật sự hữu ích cho người đang tìm kiếm. Mọi thứ khác chỉ là mốt nhất thời.