Tối ưu website cho SEO và AI Search: khi ChatGPT, Claude và Perplexity cũng đọc trang của bạn

Trong nhiều năm, "tối ưu website" gần như đồng nghĩa với "tối ưu cho Google": sitemap, meta tag, backlink, Core Web Vitals — tất cả hướng đến một mục tiêu là vị trí trên trang kết quả tìm kiếm (SERP). Nhưng từ khi ChatGPT, Perplexity, Claude và Google AI Overview bắt đầu trả lời trực tiếp câu hỏi của người dùng — có trích dẫn nguồn hoặc không — một loại "người đọc" mới đã xuất hiện: AI crawler, thu thập nội dung không phải để xếp hạng trang, mà để tổng hợp thành một câu trả lời duy nhất. Bài viết này phân tích những thay đổi kỹ thuật cụ thể mà một website — đặc biệt là blog kỹ thuật, tài liệu sản phẩm, trang dịch vụ — cần cân nhắc trong giai đoạn mà search engine truyền thống và AI answer engine cùng tồn tại.

Hai loại "người đọc": search crawler và AI crawler

Googlebot và Bingbot từ lâu đã render JavaScript qua một headless Chromium trước khi index — một single-page app vẫn có thể được index đúng, dù chậm hơn HTML tĩnh. Nhóm crawler mới — GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Google-Extended, Applebot-Extended — hoạt động khác: phần lớn chỉ fetch HTML thô qua một HTTP request đơn giản, không thực thi JavaScript, và dùng nội dung cho hai mục đích: huấn luyện model, hoặc retrieval real-time để trả lời câu hỏi (kiểu RAG — model tìm vài trang liên quan rồi tổng hợp câu trả lời có trích dẫn).

Hệ quả trực tiếp: một trang chỉ render nội dung qua client-side JavaScript (ví dụ React SPA không server-side rendering) có thể được Googlebot index đúng sau một vài giây render, nhưng với nhiều AI crawler, request đó chỉ trả về một shell HTML gần như trống — không có gì để "đọc" hay trích dẫn. Đây là lý do server-side rendering hoặc static export, vốn đã quan trọng cho SEO truyền thống, càng trở nên thiết yếu hơn ở giai đoạn này — không phải là một tối ưu nâng cao, mà là điều kiện để nội dung tồn tại trong mắt AI crawler.

robots.txt: quyết định ai được đọc nội dung của bạn

robots.txt vẫn là điểm kiểm soát đầu tiên — chỉ khác là danh sách user-agent cần quản lý đã dài hơn nhiều. Bên cạnh Googlebot/Bingbot quen thuộc, một website hiện nay có thể cần khai báo rõ ràng cho:

GPTBot, ChatGPT-User — crawler của OpenAI, dùng cho training và cho ChatGPT truy cập trang khi trả lời
ClaudeBot, Claude-Web — crawler của Anthropic
PerplexityBot — crawler của Perplexity AI, retrieval cho câu trả lời real-time
Google-Extended — kiểm soát riêng việc Gemini/AI Overview dùng nội dung, tách biệt với Googlebot index thông thường
CCBot, Bytespider, Amazonbot — crawler thu thập dữ liệu training từ Common Crawl, ByteDance, Amazon

Allow hay Disallow từng bot không phải là quyết định kỹ thuật thuần túy — nó là quyết định kinh doanh. Cho phép đồng nghĩa nội dung có thể xuất hiện làm trích dẫn trong câu trả lời AI, tăng khả năng được biết đến qua một kênh discovery mới — nhưng cũng có thể bị dùng làm dữ liệu huấn luyện model miễn phí, và người dùng có thể không bao giờ click vào trang gốc (zero-click). Chặn bảo vệ nội dung nhưng đồng nghĩa trang biến mất khỏi kênh đó hoàn toàn.

Không có cấu hình "đúng" chung cho mọi website. Một trang blog kỹ thuật muốn được trích dẫn như một nguồn tham khảo thường nên mở cho các crawler retrieval (PerplexityBot, ChatGPT-User); một sản phẩm có nội dung độc quyền cần bảo vệ có thể chặn nhóm crawler dùng cho training (GPTBot, CCBot) nhưng vẫn mở cho nhóm retrieval. Quyết định này nên được ghi rõ trong robots.txt và review định kỳ — không phải để mặc định trống.

Một quy ước mới đang hình thành là llms.txt — một file Markdown ở root domain, tương tự sitemap.xml nhưng viết cho LLM: tóm tắt cấu trúc site, liệt kê các trang quan trọng kèm mô tả ngắn, giúp model hiểu nhanh "trang này nói về gì" mà không cần crawl toàn bộ site. Đây vẫn là một đề xuất chưa được các AI provider lớn cam kết hỗ trợ chính thức, nhưng chi phí triển khai gần như bằng không — và nếu nó trở thành chuẩn phổ biến, các site đã có sẵn sẽ có lợi thế đi trước.

Structured data — ngôn ngữ chung giữa SEO truyền thống và AI

JSON-LD theo schema.org từ lâu đã giúp Google hiển thị rich results — sao đánh giá, giá, breadcrumb ngay trên SERP. Với AI answer engine, vai trò của nó còn quan trọng hơn: structured data là dữ liệu có cấu trúc, máy đọc trực tiếp được, không cần suy luận từ văn xuôi — model có thể lấy chính xác tên tác giả, ngày đăng, breadcrumb, hay danh sách câu hỏi/trả lời từ một block JSON-LD, thay vì phải "hiểu" một đoạn HTML phức tạp.

Bốn loại schema có giá trị nhất cho một website nội dung/dịch vụ:

Organization — tên, logo, URL chính thức của doanh nghiệp, giúp cả search engine và AI xác định đúng "thực thể" đứng sau nội dung
BreadcrumbList — cấu trúc điều hướng, giúp model hiểu một trang nằm ở đâu trong site và liên quan đến chủ đề gì
Article/BlogPosting — headline, tác giả, ngày đăng, ngày sửa đổi — các trường này thường được AI answer engine ưu tiên khi cần trích dẫn nguồn và thời điểm
FAQPage — với nội dung dạng hỏi-đáp, đây gần như là định dạng lý tưởng để được trích dẫn trực tiếp trong AI Overview hoặc câu trả lời chatbot

Một điểm thường bị bỏ qua: structured data phải khớp với nội dung hiển thị trên trang. Một JSON-LD khai báo thông tin không xuất hiện trên trang (hoặc ngược lại) không chỉ vi phạm hướng dẫn của Google, mà còn tạo ra dữ liệu sai lệch cho AI — rủi ro bị trích dẫn sai thông tin về chính mình.

Viết nội dung "trích dẫn được" — cho cả người và máy

AI answer engine có xu hướng trích các câu hoặc đoạn độc lập, đủ nghĩa khi đứng riêng — không phải nguyên một bài dài. Một vài nguyên tắc viết giúp tăng khả năng được trích dẫn đúng:

Trả lời câu hỏi ngay trong 1-2 câu đầu của mỗi phần, rồi mới giải thích chi tiết — đừng để câu trả lời chính nằm ở đoạn cuối sau một phần dẫn dắt dài
Đặt heading theo dạng câu hỏi hoặc cụm từ mà người dùng có thể hỏi AI (ví dụ "khi nào nên dùng X", "X khác Y ở điểm nào") — heading trùng với cách model phân đoạn câu trả lời
Mỗi đoạn văn nên mang đúng một ý hoặc một khẳng định — đoạn chứa nhiều ý trộn lẫn khó được trích nguyên vẹn mà không mất ngữ cảnh
Bullet list và bảng so sánh dễ được model parse thành các tiêu chí rời rạc hơn văn xuôi liên tục — đặc biệt hữu ích cho nội dung dạng tiêu chí lựa chọn

Đây không phải là viết cho máy thay vì cho người — một bài viết có cấu trúc rõ ràng, trả lời thẳng vào câu hỏi, luôn dễ đọc hơn cho người thật. AI answer engine chỉ đơn giản thưởng cho nội dung đã được viết tốt theo đúng nghĩa đó.

Hiệu năng và Core Web Vitals vẫn là nền tảng

AI crawler ít nhạy với thời gian render hơn search crawler truyền thống, nhưng điều đó không có nghĩa hiệu năng không còn quan trọng. Ba lý do nó vẫn là nền tảng:

Core Web Vitals (LCP, INP, CLS) vẫn là tín hiệu xếp hạng trực tiếp cho SERP truyền thống — kênh traffic vẫn chiếm phần lớn trong ngắn và trung hạn
Khi người dùng click vào một trích dẫn từ AI answer để xem chi tiết, một trang tải chậm hoặc layout nhảy (CLS cao) tạo ấn tượng đầu tiên xấu ngay tại thời điểm có khả năng chuyển đổi cao nhất
Crawl budget — site phản hồi chậm hoặc lỗi thường xuyên bị mọi loại crawler giảm tần suất và độ sâu thu thập, kể cả AI crawler

Static export kết hợp hosting tại edge (Cloudflare Pages, Vercel Edge, Netlify Edge) cho time-to-first-byte gần như tức thì vì không có cold start hay truy vấn database ở request time — lợi ích này áp dụng đều cho người dùng thật, Googlebot, và AI crawler. Trong Internal dev portal cho team kỹ thuật mà chúng tôi xây dựng, mỗi pull request có deploy preview riêng và Lighthouse CI chạy tự động trên preview đó — performance regression bị chặn ngay tại bước review, không phải phát hiện sau khi đã lên production.

Tín hiệu đáng tin trong mắt AI — không khác E-E-A-T là bao

Google dùng khung E-E-A-T (Experience, Expertise, Authoritativeness, Trust) để đánh giá độ tin cậy của nội dung. AI answer engine, khi quyết định trích dẫn nguồn nào cho một câu trả lời, dựa trên những tín hiệu rất tương tự — vì phần lớn các model này cũng được đánh giá dựa trên việc câu trả lời có đúng và có nguồn đáng tin hay không:

Thông tin tác giả và tổ chức rõ ràng, nhất quán giữa các trang — Organization schema, trang About, thông tin liên hệ thật
Nội dung có ngày đăng và ngày sửa đổi rõ ràng — đặc biệt quan trọng với chủ đề kỹ thuật, nơi thông tin cũ có thể đã sai
Được trích dẫn hoặc liên kết từ các nguồn khác — một dạng đồng thuận mà cả search ranking và AI retrieval đều coi là tín hiệu chất lượng

Không có cách rút gọn nhanh cho mục này — nó là kết quả tích lũy của việc xuất bản nội dung chính xác, có cấu trúc, và nhất quán theo thời gian.

Checklist kỹ thuật tối thiểu

Server-side rendering hoặc static export — nội dung phải có sẵn trong HTML response đầu tiên, không phụ thuộc JavaScript chạy sau
sitemap.xml và robots.txt được cập nhật, khai báo rõ chính sách cho từng nhóm AI crawler
JSON-LD cho Organization, BreadcrumbList, và loại nội dung tương ứng (Article, FAQPage, Product...) trên mọi trang liên quan
Heading hierarchy (h1 → h2 → h3) phản ánh đúng cấu trúc logic, không bị bỏ cấp hoặc dùng heading chỉ để định dạng
Core Web Vitals trong ngưỡng tốt — đo bằng dữ liệu thực (CrUX, Search Console), không chỉ Lighthouse chạy local
Canonical URL rõ ràng cho mọi trang, tránh nội dung trùng lặp gây nhiễu cho cả index truyền thống và retrieval
(Tùy chọn, chi phí thấp) llms.txt — tóm tắt cấu trúc site cho LLM, theo dõi khi quy ước này được các provider lớn áp dụng rộng hơn

Kết luận

Tối ưu cho AI answer engine không phải là một hạng mục SEO tách biệt cần một bộ công cụ mới — phần lớn nền tảng (SSR/static export, structured data, hiệu năng, nội dung có cấu trúc) chính là những gì SEO kỹ thuật tốt đã yêu cầu từ trước. Điểm khác biệt là robots.txt giờ cần một quyết định rõ ràng hơn về nhóm crawler mới, và nội dung cần được viết để mỗi đoạn có thể đứng độc lập mà vẫn đúng. Đây là phần kỹ thuật chúng tôi tích hợp ngay từ đầu cho mọi website thuộc lớp Development tại KonexForge — không phải một đợt audit riêng làm sau khi site đã lên production.