Website cho Người và Website cho Agent: Hai Thiết Kế Song Song Mà Engineering Team Phải Master
Thực hiện
nguyen hoang khai
Website của bạn đang phục vụ ai — người dùng hay AI agent?
Năm 2025, một nghiên cứu trên 3.000 website phát hiện ra điều đáng suy nghĩ: 63% trong số đó đã nhận lượt truy cập từ AI agent — không phải từ người dùng ngồi trước màn hình. Nhưng cũng trong cùng thời điểm đó, chỉ 24% developer thiết kế API có tính đến AI agent như một loại “người dùng” hợp lệ. (Nguồn: Postman State of the API Report 2025)
Khoảng cách 39 điểm phần trăm đó là vấn đề thực sự. Và nó đang tăng dần.
Nếu bạn là CTO hoặc Engineering Lead đang lên kế hoạch cho sản phẩm trong 12-18 tháng tới, câu hỏi “website của mình cần serve ai?” không còn có một câu trả lời duy nhất. Người dùng và AI agent đọc, diễn giải, và tương tác với website theo hai cách hoàn toàn khác nhau — và engineering team của bạn phải đáp ứng cả hai.
Người dùng và AI agent “đọc” website theo hai ngôn ngữ khác nhau
Đây là điểm xuất phát quan trọng nhất: con người và AI agent xử lý thông tin trên web theo hai cách không tương thích với nhau.
Khi một người dùng truy cập trang pricing của bạn, họ nhìn vào layout tổng thể, so sánh bảng giá bằng mắt, click vào tooltip để hiểu thêm, rồi đọc testimonial ở cuối trang để củng cố quyết định. Trải nghiệm này được dẫn dắt bởi visual hierarchy, UX copy, và cảm giác tổng thể của trang.
Khi một AI agent như OpenAI Operator hoặc Perplexity truy cập cùng trang đó, nó không “nhìn” gì cả. Nó query structured data, parse HTML để tìm semantic tags, gọi API nếu có, và đưa ra quyết định dựa trên dữ liệu có thể đọc được theo máy — không phải dựa trên thiết kế bắt mắt của bạn.
AI agent không duyệt web. Chúng query dữ liệu có cấu trúc, semantic layer, và API để tìm câu trả lời nhanh nhất và đáng tin cậy nhất.
Jakob Nielsen — người đặt nền móng cho ngành UX hiện đại — đã gọi sự dịch chuyển này là thời điểm “Goodbye UI Design”. Luận điểm của ông: khi người dùng không còn trực tiếp tương tác với giao diện mà thay vào đó ủy quyền cho AI agent làm thay, design target phải thay đổi — từ page flows và pixel decisions sang outcomes, policies, và intent orchestration.
Đây không phải tín hiệu để bỏ qua UX. Đây là tín hiệu để thiết kế hai lớp song song.
Ba sự khác biệt kỹ thuật mà engineering team cần nắm rõ
1. Nội dung vs. Dữ liệu có cấu trúc
Website cho người dùng tập trung vào nội dung — copywriting, visual, narrative flow. Website cho agent tập trung vào structured data: Schema.org markup, JSON-LD, OpenGraph tags, và ngày càng quan trọng hơn là llms.txt — file hướng dẫn cho AI crawler về cách truy cập và ưu tiên nội dung trên site của bạn.
Sự khác biệt thực tế: một trang sản phẩm được viết tốt cho người dùng có thể hoàn toàn “vô hình” với AI agent nếu không có structured data đúng format. Agent sẽ không infer ý định từ copywriting — nó cần dữ liệu rõ ràng, có thể đọc được theo máy.
2. Navigation vs. API endpoint
Người dùng điều hướng qua menu, breadcrumb, internal link. AI agent bỏ qua toàn bộ lớp navigation đó và tìm cách ngắn nhất để lấy dữ liệu — thường là thông qua REST API, GraphQL, hoặc sitemap.
Postman 2025 ghi nhận: AI agent đang trở thành nhóm tiêu thụ API tăng trưởng nhanh nhất. Nhưng agent cần API được thiết kế theo chuẩn khác — cụ thể hơn, ít ambiguity hơn, error handling rõ ràng hơn so với API cho developer truyền thống. Không giống human developer có thể đọc docs không đầy đủ và tự suy luận, agent cần machine-readable schema (OpenAPI 3.0+) và predictable response structure.
3. Trust signal cho người vs. Trust signal cho máy
Người dùng đánh giá trust qua testimonial, badge, hình ảnh đội ngũ, tốc độ load, và thiết kế tổng thể. AI agent đánh giá trust qua completeness của structured data, consistency của thông tin qua các endpoint, freshness của content, và whether domain có authority signal theo cách máy có thể verify.
Gartner dự báo đến năm 2026, 20% customer interaction sẽ được xử lý bởi AI agent thay vì con người. Với tỷ lệ này, trust signal cho máy sẽ quan trọng không kém — và trong một số case còn quan trọng hơn — trust signal cho người dùng.
Tại sao việc tối ưu chỉ cho một phía là rủi ro chiến lược
Có một nhóm engineering team đang tối ưu website rất tốt cho người dùng nhưng hoàn toàn bỏ qua agent-readiness. Nhóm này sẽ gặp vấn đề khi AI-powered buyer journey trở thành chuẩn mực — người dùng hỏi ChatGPT hoặc Perplexity về vendor phù hợp, và sản phẩm của họ không xuất hiện trong kết quả vì không có structured data để AI parse.
Nhóm ngược lại — tập trung vào API và machine-readability nhưng bỏ qua human UX — cũng không ổn. Hiện tại, lượng traffic từ AI agent chỉ chiếm 0.2% trung bình trên mỗi website (dữ liệu tháng 2/2025). Phần lớn buyer journey B2B vẫn có điểm tiếp xúc trực tiếp với người dùng thật. Bỏ qua UX là sai lầm về thứ tự ưu tiên.
Vấn đề thực sự là hai loại website này đòi hỏi mindset thiết kế và kiểm thử khác nhau, và hầu hết engineering team chưa build process để đảm bảo chất lượng cho cả hai.
Framework quyết định: Bạn nên đầu tư vào đâu và theo thứ tự nào?
Không có câu trả lời “tùy” ở đây. Dưới đây là decision framework dựa trên giai đoạn phát triển của sản phẩm:
- Pre-PMF (dưới 1,000 user): 90% effort vào human UX. Agent-readiness không phải ưu tiên khi bạn chưa validate product-market fit với người dùng thật. Rủi ro: viết code quá sớm cho một audience chưa có.
- Post-PMF, đang scale (1,000 – 50,000 user): Bắt đầu invest vào structured data (Schema.org, JSON-LD), public API documentation chuẩn OpenAPI 3.0+, và
llms.txt. Budget gợi ý: 70% human UX, 30% machine-readability. - Scale-up với enterprise buyer: Agent-readiness trở thành competitive moat. Enterprise buyer ngày càng dùng AI tool để evaluate vendor — nếu sản phẩm của bạn không xuất hiện trong AI-generated shortlist, bạn không tồn tại trong deal. Ở giai đoạn này: 50/50.
- API-first product hoặc B2D (developer tool): Đầu tư 60-70% vào machine-readability ngay từ đầu. Đây là audience mà agent sẽ thay thế workflow nhanh nhất.
Phản biện phổ biến — và tại sao cần nhìn lại
“AI agent traffic hiện tại quá nhỏ để đáng đầu tư.”
Đúng về con số hiện tại (0.2%). Nhưng đây là bẫy của lagging indicator. Web traffic từ mobile cũng rất nhỏ năm 2008 — và team nào không chuẩn bị trước đều phải làm lại toàn bộ trong tình trạng gấp. Agent adoption đang đi theo trajectory tương tự, với vận tốc nhanh hơn.
“Structured data và API đã có rồi, cần gì làm thêm?”
Có API không có nghĩa là API đó agent-ready. Agent cần predictable error handling, schema đầy đủ, và không có ambiguity trong response. Hầu hết API hiện tại được thiết kế cho developer đọc docs và adapt — không phải cho agent hoạt động fully autonomous. Đây là gap cần đánh giá riêng.
Giới hạn của framework trên: Nó không áp dụng cho safety-critical system (fintech infrastructure, healthcare platform) nơi AI agent không được phép ra quyết định tự động. Trong các context đó, human UX và human oversight vẫn là ưu tiên tuyệt đối.
Hàm ý thực tế cho engineering team
Nếu bạn đang ở giai đoạn post-PMF và chưa làm gì với agent-readiness, đây là 3 việc có thể bắt đầu trong sprint tiếp theo:
- Audit structured data hiện tại: Dùng Google Rich Results Test và Schema Validator để xem sản phẩm của bạn đang expose gì cho AI crawler. Phần lớn team sẽ ngạc nhiên vì khoảng cách giữa những gì họ tưởng và thực tế.
- Tạo llms.txt cơ bản: File này hướng dẫn AI crawler về cấu trúc site và nội dung ưu tiên. Hiện tại chưa phải tất cả LLM crawler đọc file này, nhưng adoption đang tăng và chi phí setup thấp.
- Review API documentation theo chuẩn OpenAPI 3.0+: Đặt câu hỏi: nếu một AI agent cần thực hiện một task thông qua API của bạn mà không có human intervention, nó có thể không? Tìm chỗ nào trong docs cần “common sense” để hiểu — đó là những chỗ agent sẽ fail.
Quan trọng hơn: những thay đổi này cần được kiểm thử. Structured data sai còn tệ hơn không có — nó có thể khiến AI trích dẫn thông tin sai về sản phẩm của bạn. Schema markup cần validation, API contract cần contract testing, và behavior khi agent truy cập cần được test với agent simulator hoặc headless browser trước khi release.
Chúng tôi nghĩ gì về hướng đi của ngành
Ranh giới giữa “website cho người” và “website cho agent” sẽ không biến mất — nó sẽ trở nên rõ hơn, không mờ hơn. Trong 2-3 năm tới, sản phẩm tốt nhất không phải sản phẩm chọn một trong hai, mà là sản phẩm xây hai lớp trải nghiệm song song: human layer tập trung vào narrative và trust, machine layer tập trung vào accuracy và queryability.
Engineering team nào nhận ra điều này sớm — và build testing pipeline để đảm bảo chất lượng cho cả hai lớp — sẽ có lợi thế thực sự khi AI-driven buyer journey trở thành chuẩn mới. Không phải vì họ biết AI đang thay đổi mọi thứ, mà vì họ đã chuẩn bị trước khi số liệu yêu cầu họ làm vậy.
