Ngừng tối ưu hóa trang web của bạn cho con người (họ không còn đọc nó nữa)

Tôi là sinh viên ngành công nghệ thông tin. Thỉnh thoảng tôi thực hiện các dự án nhỏ và hiện tại đang xây dựng một nền tảng để hỗ trợ những người sáng tạo nội dung. Giống như nhiều người khác trước đây, tôi nhận thấy một điều: những gì chúng ta đăng tải trên Internet không còn thực sự được con người đọc nữa. Chúng được các AI đọc, xử lý, sau đó được trình bày lại cho con người dưới dạng tóm tắt. Kể từ đó, tôi đã tối ưu hóa mọi thứ mình đăng tải trực tuyến cho các AI. Dưới đây là lý do. Hãy nhìn vào Google: khi bạn đặt một câu hỏi, điều đầu tiên hiển thị không còn là danh sách các liên kết, mà là một "Tổng quan AI" trả lời trực tiếp cho bạn. Hầu hết thời gian, điều đó là đủ – bạn rời đi mà không cần truy cập bất kỳ trang web nào. Các số liệu cũng xác nhận điều này: khi một Tổng quan AI hiển thị, chỉ 8% người dùng vẫn nhấp vào một kết quả, so với 15% khi không có (Pew Research, 68.879 lượt tìm kiếm thực tế). Đôi khi, tôi thậm chí không còn gõ từ khóa nữa: tôi đặt cả câu hỏi, vì tôi biết rằng một LLM sẽ trả lời tôi. Người truy cập mới không nhấp chuột, họ đọc Thay vì con người, một loại khách truy cập mới xuất hiện: tác nhân AI. ChatGPT, Claude hoặc Perplexity truy cập trang thay cho người dùng, giữ lại những thông tin cốt lõi và tóm tắt chúng. Khối lượng này vẫn còn khiêm tốn – khoảng 1% lưu lượng truy cập web (Conductor) – nhưng đang tăng nhanh (+357% trong một năm, Similarweb) và có tỷ lệ chuyển đổi rất cao: 15,9% đối với lưu lượng truy cập từ ChatGPT, so với 1,76% đối với lưu lượng truy cập tự nhiên từ Google (Seer Interactive). Khối lượng nhỏ, nhưng ý định rất lớn: đây là thời điểm để tạo lợi thế. LLMO, những gì nó không phải Cộng đồng SEO có một tên gọi cho điều này: LLMO, Tối ưu hóa Mô hình Ngôn ngữ Lớn (Large Language Model Optimization). Nói một cách ngắn gọn: SEO tối ưu hóa cho thứ hạng; LLMO tối ưu hóa cho ý nghĩa, cấu trúc và khả năng trích xuất bởi các AI. Điểm mấu chốt đối với các nhà phát triển: một LLM không "điều hướng". Nó không nhìn thấy phần hero section, các hoạt ảnh hay chế độ tối của bạn. Nó nhận văn bản, chia thành các token, và mỗi token đều có chi phí. Giao diện tuyệt đẹp của bạn, theo quan điểm của nó, là: nhiễu không cần thiết, bị tính phí và làm tăng ngữ cảnh; không có lợi ích nào. Chi phí thực sự, các token Tôi đã thực hiện thử nghiệm trên một trang thực tế của nền tảng của mình: dunga.io/midwiq, với bộ tokenizer của OpenAI. Cùng một thông tin, ba cách thể hiện: Trang đầy đủ (HTML + UI/UX): 1.904 token – và gần 2.900 trên bộ tokenizer GPT-4 legacy HTML ngữ nghĩa tối thiểu: 521 token Markdown tinh gọn: 283 token Tức là giảm 85% số token – lên đến gấp 10 lần tùy thuộc vào bộ tokenizer. Điều này hợp lý: điều hướng, CSS, các thành phần JavaScript… tất cả những thứ đó không mang thông tin nào, nhưng tác nhân vẫn phải trả phí. Một Markdown sạch sẽ loại bỏ tất cả. llms.txt: giải pháp tưởng chừng tốt Giải pháp phổ biến hiện nay được gọi là llms.txt: một tệp Markdown ở thư mục gốc của trang web, được cho là để hướng dẫn các AI. Trên lý thuyết, điều này hấp dẫn. Nhưng trên thực tế, nó không hiệu quả. SE Ranking (phân tích 300.000 tên miền): không có hiệu ứng đo lường được đối với các trích dẫn – trong số 50 tên miền được AI trích dẫn nhiều nhất, chỉ có một tên miền có tệp này. Limy: trong 500 triệu lượt truy cập của bot AI trong 90 ngày, 408 lượt đã yêu cầu llms.txt; các bot thu thập dữ liệu HTML trực tiếp. Và Google đã đưa ra quyết định: không hỗ trợ, John Mueller thậm chí còn so sánh nó với thẻ meta keywords cũ. Vấn đề không phải là ý định, mà là kiến trúc: các tác nhân sẽ không tìm kiếm một tệp phụ trợ, họ đọc URL được cung cấp cho họ. Do đó, chính tại đó chúng ta cần cung cấp cách thể hiện phù hợp. Tuy nhiên, tôi vẫn có một cái trên trang web của mình — và tôi chấp nhận điều đó, vì hai lý do. Thứ nhất: khi một quy ước xuất hiện trên web, tôi thích tuân theo; đó là cách các tiêu chuẩn cuối cùng trở thành chuẩn mực. Thứ hai: cái của tôi không nhằm mục đích được trích dẫn, nó đóng vai trò như một README của giao diện máy — đó là nơi một tác nhân (agent) học được rằng mỗi trang tồn tại dưới dạng .md, và cách yêu cầu nó. Thành thật mà nói: theo số liệu, hiện tại, điều này không có tác dụng gì. Nhưng đó là một tệp tĩnh, không cần bảo trì — nếu tiêu chuẩn này phát triển, chúng ta hãy sẵn sàng; nếu nó biến mất, chúng ta không mất gì. Điều này được thực hiện trong thực tế (ví dụ: dunga.io) Đây là điều tôi đã làm trên dunga.io, nền tảng liên kết thông minh (fanlinks, link-in-bio, deeplinks) nhỏ mà tôi tạo cho các nhà sáng tạo và nghệ sĩ. Một trang liên kết là một trường hợp điển hình: một tên, các liên kết, một tiểu sử — ba thông tin hữu ích bị chìm trong thiết kế. Mỗi trang liên kết tồn tại ở phiên bản HTML ngữ nghĩa và phiên bản Markdown, được tạo ra ngay lập tức tại thời điểm yêu cầu — luôn cập nhật, không cần lưu trữ gì. Và thậm chí không phải máy chủ xử lý việc này: một middleware biên (edge middleware) (vài chục dòng mã được thực thi trên CDN, trước mọi thứ khác) sẽ kiểm tra User-Agent. Một người dùng nhận được thiết kế, một trình thu thập thông tin mạng xã hội nhận được thẻ Open Graph của nó, một tác nhân AI nhận được phiên bản tinh gọn. Cùng một URL, ba cách thể hiện — 100% thông tin, khoảng 15% token. Bạn có thể tự mình xem: thêm .md hoặc ?format=md vào bất kỳ trang công khai nào của dunga.io. Và nhà sáng tạo không phải làm gì cả. Đây là điểm tôi nhấn mạnh: LLMO không nên là một nhiệm vụ bổ sung cho các nhà sáng tạo, đó là trách nhiệm của nền tảng. Đến lượt bạn Tôi không biết liệu thuật ngữ "LLMO" có tồn tại sau năm 2027 hay không. Nhưng khoảng cách giữa một DOM 2.000 token và 300 token Markdown sẽ không thay đổi. Ba điều đơn giản để thử nghiệm trong tuần này: Kiểm tra nhật ký (logs) của bạn: lọc theo User-Agent AI (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot) và đo lường lưu lượng truy cập này. Token hóa một trong các trang của bạn: đưa HTML thô vào một bộ token hóa (tokenizer) và tính toán tỷ lệ token hữu ích / tổng số token. Cung cấp một cách thể hiện thay thế trên cùng một URL: việc đàm phán nội dung dựa trên User-Agent chỉ cần vài dòng middleware. Và cái bẫy mà tôi chỉ phát hiện ra khi thử nghiệm với các tác nhân thực tế: Content-Type. Cung cấp text/markdown nghe có vẻ hợp lý trên lý thuyết — ngoại trừ việc một số trình tìm nạp (fetcher) LLM từ chối mọi phản hồi không phải là HTML. Và điều ngược lại còn tệ hơn: Markdown thô.