Đã xong một nửa công việc - đã thêm các bản địa hóa và định tuyến

Trong trường hợp của tôi, việc triển khai không theo tiêu chuẩn, bởi vì tiếng Nga sẽ nằm trên tên miền hiện tại - https://vietnamguru.ru, còn các ngôn ngữ khác sẽ nằm trên tên miền quốc tế mới - https://vietnamguru.travel

Bây giờ tôi cần thêm tính năng lưu trữ bản dịch vào cơ sở dữ liệu, logic cuối cùng và dịch tất cả các tài liệu. May mắn là theo cấu trúc của tôi, hầu hết mọi thứ đều nằm ngay trong nội dung trang nên việc này sẽ tương đối dễ dàng thực hiện.

Đã thêm một resolver dịch thẻ sang đồng thời hai ngôn ngữ - en, vi (trong một yêu cầu).

Đã dịch xong. Chi phí khoảng 10 rúp cho một lần dịch.

Đầu vào nhận 4 trường: name, description, intro, content, trong đó intro và content chứa markdown trộn lẫn với HTML. Bản thân content là một trường khá phức tạp vì nó còn chứa cả các phần tử tạo khuôn mẫu (templating).

LLM trả về kết quả ở định dạng yaml, vì làm như vậy sẽ giảm nguy cơ gặp lỗi định dạng do dấu ngoặc kép chưa đóng nào đó. Kết quả thu được phản hồi xấp xỉ như sau:

responseContent en:
  name: |
    Dalat
  description: |
    A mountain city at an altitude of 1,500 m in Vietnam's Central Highlands, known for its French colonial architecture, cool climate, and natural attractions. A popular tourist destination for travelers seeking a break from the coastal heat.
  intro: |
    Dalat is a city on the Langbiang Plateau at an altitude of 1,500 m in Lâm Đồng Province. It is known for its unique "eternal spring" microclimate with temperatures of 18–21 °C, French colonial-era architecture, and surrounding nature with waterfalls, lakes, and pine forests. Until July 2025, it served as the capital of Lâm Đồng Province.
  content: |
    <page-hero data-from="#1e3a5f" data-to="#0f172a" data-accent="#3b82f6">
      <page-hero-crumbs>
        [Home](/) / [Locations](/city) / Dalat
      </page-hero-crumbs>
    
vi:
  name: |
    Đà Lạt
  description: |
    Thành phố miền núi ở độ cao 1.500 m tại cao nguyên trung bộ Việt Nam, nổi tiếng với kiến trúc thuộc địa Pháp, khí hậu mát mẻ và các danh thắng thiên nhiên. Điểm đến du lịch phổ biến cho những du khách tìm kiếm sự nghỉ ngơi khỏi cái nóng ven biển.
  intro: |
    Đà Lạt là thành phố trên cao nguyên Langbiang ở độ cao 1.500 m thuộc tỉnh Lâm Đồng. Nổi tiếng với vi khí hậu "mùa xuân vĩnh cửu" độc đáo với nhiệt độ 18–21 °C, kiến trúc thời kỳ thuộc địa Pháp và thiên nhiên xung quanh với các thác nước, hồ nước và rừng thông. Cho đến tháng 7 năm 2025, nơi đây là tỉnh lỵ của tỉnh Lâm Đồng.
  content: |
    <page-hero data-from="#1e3a5f" data-to="#0f172a" data-accent="#3b82f6">
      <page-hero-crumbs>
        [Trang chủ](/) / [Địa điểm](/city) / Đà Lạt
      </page-hero-crumbs>

Đã khởi chạy dịch tất cả các trang. Bản cập nhật lần này bổ sung một helper có chức năng dọn dẹp các liên kết không tồn tại (đôi khi AI tự bịa ra) và thực hiện việc này thông qua bộ phân tích cú pháp MDX. Cơ chế này đồng thời kiểm tra tính hợp lệ của các thẻ HTML trong mã. Lỗi phổ biến nhất là thẻ đóng không đúng (mở thẻ này nhưng lại đóng thẻ khác). Việc vi phạm định dạng sẽ dẫn đến lỗi và dữ liệu đó sẽ không được ghi lại. Tỷ lệ lỗi chiếm khoảng 4% số thẻ.

Nhưng không sao cả. 1.000 thẻ đã được xử lý trong 2 giờ và tổng chi phí chưa đến 9 đô la. Tính ra khoảng 1 rúp cho mỗi thẻ. Tôi sẽ chạy lại quy trình này một lần nữa. Các thẻ đã được điền sẽ được bỏ qua.

Next.js i18n Domain Routing trong môi trường phát triển nội bộ: Lý do tôi phải chạy dev-server ở cổng 80

Khi thiết lập môi trường cục bộ cho Next.js, tôi đã gặp phải một hạn chế khá khó chịu của tính năng domain-based i18n routing được tích hợp sẵn.

Thoạt nhìn, bài toán rất đơn giản: ứng dụng sử dụng các tên miền khác nhau cho các ngôn ngữ (locales) khác nhau và bạn muốn tái tạo lại sơ đồ đó trên máy cục bộ. Ví dụ:

const nextConfig: NextConfig = {
  i18n: {
    locales: LOCALE_CODES,
    defaultLocale: 'en',
    localeDetection: false,
    domains: [
      {
        domain: 'vietnamguru-v3.localhost',
        defaultLocale: 'ru',
        locales: ['ru'],
        http: true,
      },
    ],
  },
}

Next.js chính thức hỗ trợ cấu hình này. Trường http: true tồn tại phần lớn để kiểm thử cục bộ các locale domain qua HTTP thay vì HTTPS.

Vấn đề bắt đầu phát sinh từ số cổng (port).

Không thể chỉ định đúng cổng dev trong i18n.domains

Dev server thông thường của Next.js chạy trên cổng 3000:

http://vietnamguru-v3.localhost:3000

Sẽ rất hợp lý nếu viết thế này:

domains: [
  {
    domain: 'vietnamguru-v3.localhost:3000',
    defaultLocale: 'ru',
    locales: ['ru'],
    http: true,
  },
]

Nhưng i18n.domains trong Next.js được thiết kế dành riêng cho các tên miền (domain), chứ không phải cho các origin tùy ý.

Kiểu dữ liệu DomainLocale hiện tại trông như thế này:

export interface DomainLocale {
  defaultLocale: string
  domain: string
  http?: true
  locales?: readonly string[]
}

Nó không có port, origin, hay bất kỳ trường devPort nào cả.

Bản thân điều này sẽ không quá tệ nếu Next chỉ sử dụng tên miền để nhận diện locale. Tuy nhiên, domain routing còn ảnh hưởng đến cả việc tạo liên kết (link generation).

<Link href="/place"> bất ngờ trở thành liên kết tuyệt đối (absolute link)

Trong ứng dụng có một liên kết hoàn toàn bình thường:

<Link href="/place">
  Что посетить
</Link>

Nếu không có domain-based i18n, bạn sẽ mong đợi một đoạn HTML đại loại thế này:

<a href="/place">Что посетить</a>

Và trình duyệt sẽ tự nhiên mở ra:

http://vietnamguru-v3.localhost:3000/place

Nghĩa là origin hiện tại, bao gồm cả cổng, được giữ nguyên tự động.

Nhưng khi bật domain routing, Next.js biết rằng một locale cụ thể thuộc về một tên miền cụ thể. Do đó, nó có thể tạo ra một URL locale-domain tuyệt đối cho thẻ Link.

Kết quả là ta nhận được:

<a href="http://vietnamguru-v3.localhost/place">
  Что посетить
</a>

Và tại đây, :3000 đã bị mất.

Điều này đặc biệt khó chịu bởi vì trong mã nguồn JSX hoàn toàn không có URL tuyệt đối nào cả:

<Link href="/place">

Chính tầng routing của Next.js đã biến nó thành tuyệt đối.

Tình trạng nghịch lý xuất hiện:

Trang hiện tại:
http://vietnamguru-v3.localhost:3000/foo

JSX:
<Link href="/place">

Href được tạo ra:
http://vietnamguru-v3.localhost/place

Trình duyệt hoàn toàn có lý khi hiểu URL sau cùng là HTTP trên cổng chuẩn 80.

Không thể đơn giản bảo Next.js: "Hãy giữ các liên kết nội bộ ở dạng tương đối"

Đây có lẽ là hạn chế lớn nhất.

Trong cấu hình domain i18n, không có tùy chọn kiểu như:

relativeLinks: true

hay:

absoluteLocaleLinks: false

Không có cách nào để thiết lập:

port: 3000

và không có dev-origin riêng biệt:

origin: 'http://vietnamguru-v3.localhost:3000'

Nói cách khác, mô hình cấu hình thực chất giả định rằng locale domain khả dụng trên cổng chuẩn của giao thức tương ứng.

Đối với môi trường production, điều này hoàn toàn bình thường:

https://example.com
https://example.fr

Đối với môi trường phát triển cục bộ:

http://example.localhost:3000

— lại là một vấn đề.

Tại sao http: true không giải quyết được vấn đề

Thoạt đầu, tên trường mang lại hy vọng:

{
  domain: 'vietnamguru-v3.localhost',
  http: true,
}

Nhưng nó chỉ chịu trách nhiệm chọn giao thức:

https://

hoặc:

http://

Tức là Next nhận đủ thông tin để xây dựng:

http://vietnamguru-v3.localhost/place

Nhưng thông tin rằng máy chủ cục bộ đang chạy ở cổng 3000 đơn giản là không tồn tại trong mô hình này.

Phương án dùng reverse proxy

Về mặt kiến trúc, giải pháp sạch sẽ nhất là đặt một reverse proxy cục bộ trước Next:

http://vietnamguru-v3.localhost
              |
              v
        localhost:3000

Ví dụ, thông qua nginx, Caddy hoặc một proxy cục bộ khác.

Khi đó, Next vẫn tiếp tục tạo ra:

http://vietnamguru-v3.localhost/place

và URL này thực sự hoạt động.

Nhưng đối với môi trường dev hiện tại của tôi, đây là hạ tầng dư thừa chỉ để lách qua một hạn chế của framework.

Do đó, giải pháp tạm thời hóa ra lại đơn giản hơn: chạy trực tiếp Next.js trên cổng 80.

Chạy Next.js trên cổng 80

Việc chạy thì cực kỳ đơn giản:

PORT=80 npm run dev

Sau đó:

http://vietnamguru-v3.localhost

thực sự trở thành địa chỉ của dev server, và các liên kết tuyệt đối do Next.js tạo ra bắt đầu hoạt động chính xác.

Nhưng vấn đề tiếp theo lại xuất hiện.

Người dùng thông thường không thể lắng nghe cổng 80

Trên Linux, các cổng dưới 1024 theo truyền thống là các cổng đặc quyền (privileged ports).

Do đó, lệnh thông thường:

PORT=80 npm run dev

có thể kết thúc bằng lỗi quyền truy cập khi Node.js cố gắng bind vào cổng 80.

Ý nghĩ hiển nhiên đầu tiên:

sudo npm run dev

Nhưng đây vốn dĩ là một lựa chọn tồi, và trong trường hợp của tôi, nó gần như không khả thi: Node/npm không được cài đặt toàn cục trong môi trường hệ thống.

Ví dụ, nếu Node được quản lý bởi một trình quản lý phiên bản (version manager) của người dùng, lệnh npm hiển thị trên shell hiện tại không nhất thiết tồn tại trong môi trường của sudo.

Ta rơi vào tình huống kinh điển:

npm run dev

thì chạy được, còn:

sudo npm run dev

— thì không, hoặc nó khởi chạy một môi trường Node hoàn toàn khác.

Và việc chạy toàn bộ dev server dưới quyền root chỉ vì muốn mở một cổng duy nhất là điều không hề mong muốn.

Dùng CAP_NET_BIND_SERVICE thay vì chạy Node dưới quyền root

Trên Linux, có một capability tên là CAP_NET_BIND_SERVICE phục vụ mục đích này.

Nó cho phép một tệp thực thi (executable) cụ thể mở các cổng mạng đặc quyền mà không cần phải chạy toàn bộ tiến trình dưới quyền root.

Đối với tệp thực thi Node hiện tại:

which node

ta có thể cấp capability:

sudo setcap 'cap_net_bind_service=+ep' $(which node)

Sau đó, ta có thể tiếp tục chạy Node dưới quyền người dùng thông thường:

PORT=80 npm run dev

và tiến trình sẽ có thể lắng nghe trên cổng 80.

Kết quả là sơ đồ cục bộ trở thành như sau:

vietnamguru-v3.localhost
        |
        | :80
        v
   Next.js dev

trong khi Next.js domain routing tạo ra:

http://vietnamguru-v3.localhost/place

giữ cho URL khớp với địa chỉ thực tế của ứng dụng.

Tại sao đây vẫn chỉ là một giải pháp tạm thời (workaround)

Việc cấp CAP_NET_BIND_SERVICE trực tiếp cho node không phải là một giải pháp tổng quát hoàn hảo.

Capability này được gán cho tệp thực thi Node.js, chứ không phải cho một dự án Next.js cụ thể nào. Do đó, bất kỳ tiến trình nào chạy thông qua tệp nhị phân Node cụ thể đó từ môi trường này đều có khả năng bind vào các cổng đặc quyền.

Hơn nữa, nếu Node được cài đặt thông qua version manager và phiên bản Node bị chuyển đổi hoặc cài đặt lại, đường dẫn đến tệp thực thi có thể thay đổi. Khi đó, capability sẽ phải được gán lại cho tệp nhị phân mới.

Bạn có thể kiểm tra các capability hiện tại bằng lệnh, ví dụ:

getcap $(which node)

Kết quả mong đợi:

/path/to/node cap_net_bind_service=ep

Khi cần thiết, ta có thể gỡ bỏ capability:

sudo setcap -r $(which node)

Đó là lý do tại sao đây chỉ đơn thuần là một giải pháp tạm thời thuận tiện trên máy cục bộ, chứ không phải là cấu hình nên áp dụng một cách bừa bãi cho mọi môi trường phát triển.

Tổng kết

Vấn đề hóa ra không nằm ở DNS, /etc/hosts, React hay hành vi của trình duyệt.

Nó phát sinh từ sự kết hợp của một số đặc điểm trong domain-based i18n của Next.js:

1. i18n.domains mô tả hostname nhưng không cung cấp thiết lập cổng riêng.
2. http: true cho phép chọn HTTP thay vì HTTPS, nhưng không cấu hình cổng dev.
3. Khi sử dụng domain routing, Next.js có thể chuyển đổi thẻ <Link href="/..."> thông thường thành liên kết tuyệt đối trỏ tới locale domain.
4. Trong cấu hình không có nút chuyển đổi riêng để giữ các liên kết nội bộ đó ở dạng tương đối.
5. Do đó, cổng dev mặc định 3000 của Next không tương thích tốt với việc giả lập domain-based locale routing trên máy cục bộ.

Trong trường hợp của tôi, giải pháp tạm thời thu được là:

sudo setcap 'cap_net_bind_service=+ep' $(which node)
PORT=80 npm run dev

Sau đó, hostname cục bộ có thể được sử dụng mà không cần chỉ định cổng tường minh:

http://vietnamguru-v3.localhost

và các liên kết locale-domain tuyệt đối của Next.js trùng khớp với origin thực tế.

Nó hoạt động. Nhưng lại để lại khá nhiều hệ lụy về mặt hạ tầng cho một thứ mà ở cấp độ ứng dụng trông chỉ giống như thế này:

<Link href="/place">

Nguồn tham khảo

Tài liệu chính thức của Next.js về Pages Router xác nhận việc hỗ trợ sẵn domain routing, cấu trúc của domains và mục đích của http: true dành riêng cho việc kiểm thử HTTP cục bộ.

Kiểu dữ liệu DomainLocale hiện tại trong vercel/next.js chứa các trường domain, defaultLocale, locales và http, nhưng không có cài đặt cổng riêng biệt trong đó.

Trong tài liệu về thành phần Link, các chuyển hướng nội bộ thông thường vẫn được định nghĩa bằng đường dẫn tương đối (/, /about, /blog/...), tức là không cần phải viết URL locale-domain tuyệt đối vào mã JSX của ứng dụng.

Đã thêm 8 ngôn ngữ nữa. Việc cập nhật một thẻ (bao gồm 8 ngôn ngữ này) có giá 5 xu.

Sự thật thú vị: mặc dù tôi đã khởi chạy một tên miền hoàn toàn mới và chỉ xuất bản ngày hôm nay — https://vietnamguru.travel, các bot AI đã nuốt chửng nó gần như ngay lập tức và bắt đầu quét sạch trang web mới.

Đã khởi chạy bản dịch sang thêm 8 ngôn ngữ khác. Đã xử lý 742 trang trong 9,5 giờ.

Chi phí hết 32 đô la.

Giả thuyết: Web mở sẽ lại trở thành lợi thế cạnh tranh

Trong khoảng mười lăm năm qua, sự phát triển của cơ sở hạ tầng web đã dịch chuyển theo hướng ngày càng hạn chế quyền truy cập của máy tính.

Nguyên nhân hoàn toàn hợp lý. Bot tạo ra tải, quét nội dung, tìm kiếm lỗ hổng, spam, sao chép cơ sở dữ liệu, thu thập giá cả, tạo tài khoản giả. Để đáp ứng, các trang web dần được trang bị thêm CDN, WAF, giới hạn tốc độ (rate limits), thử thách JavaScript, nhận dạng dấu vân tay (fingerprinting), CAPTCHA, chống cào dữ liệu (anti-scraping) và phân tích hành vi.

Kết quả là một nghịch lý của internet hiện đại đã xuất hiện:

Chúng ta tạo ra Mạng lưới toàn cầu (World Wide Web) để liên kết và phổ biến thông tin tự do, rồi sau đó dành hai mươi năm để làm cho thông tin đó trở nên bất tiện nhất có thể đối với việc đọc tự động.

Đối với Web mà người tiêu dùng chính của trang là con người sử dụng trình duyệt, điều này có ý nghĩa.

Tôi cho rằng với sự xuất hiện của AI, sự cân bằng này bắt đầu thay đổi.

Bot không còn chỉ là kẻ ăn bám

Trong nền kinh tế cũ của một trang web công khai, có sự phân chia khá đơn giản:

Human (Con người) → khách truy cập tốtSearch crawler (Trình thu thập của công cụ tìm kiếm) → được dung thứ vì mang lại con ngườiOther bot (Bot khác) → khách truy cập xấu

Loại sau hầu như không có giá trị kinh tế.

Nó lấy trang, tiêu thụ CPU và băng thông mà không mua bất cứ thứ gì.

Do đó, chiến lược kỹ thuật tự nhiên là:

không cho phép vào.

Nhưng AI tạo ra một tầng lớp người tiêu dùng máy tính hoàn toàn mới.

AI crawler có thể đọc trang web không phải để cho chủ sở hữu xem một bản sao bị đánh cắp của trang, mà để sau đó trả lời con người:

Đi đâu chơi một ngày ở Đà Lạt?

Porter và stout khác nhau ở điểm nào?

Cách sử dụng phòng xông hơi Phần Lan đúng cách là gì?

Và nếu phần lớn hoạt động tìm kiếm của con người thực sự chuyển từ danh sách liên kết sang cuộc trò chuyện với AI, một điều cốt lõi sẽ xảy ra:

bot trở thành bên trung gian giữa nhà xuất bản và con người.

Kết quả là:

Web cũ:Publisher (Nhà xuất bản)   ↓Google   ↓SERP   ↓Human (Con người)   ↓Website (Trang web)Web AI:Publisher (Nhà xuất bản)   ↓Machine (Máy tính)   ↓understanding / synthesis (hiểu / tổng hợp)   ↓Human (Con người)

Và khi đó, yêu cầu từ một AI bot không còn có thể bị coi là lưu lượng truy cập vô ích một cách tự động nữa.

Có lẽ đây là phần trên của phễu thu hút người dùng mới.

Từ đó nảy sinh nghịch lý

Ngành công nghiệp đã chi rất nhiều tiền để xây dựng cơ sở hạ tầng được tối ưu hóa hoàn hảo để bảo vệ thông tin khỏi máy tính, chính xác vào thời điểm mà máy tính đang bắt đầu trở thành một trong những phương thức tiêu thụ thông tin chính.

Hơn nữa, các trang web tốt nhất và thành công thương mại nhất thường là những trang được bảo vệ mạnh mẽ nhất.

Cloudflare, WAF, bot protection, kết xuất động (dynamic rendering), tường xác thực (authorization walls), giới hạn tốc độ, thử thách JavaScript.

Trong mô hình cũ, đây là lợi thế.

Trong mô hình mới đối với một nguồn thông tin công cộng, một phần cơ sở hạ tầng này có khả năng biến thành rào cản phân phối (distribution handicap).

Tình huống phi lý nhất có thể trông như thế này:

Công ty có nội dung tốt nhất trong ngành, nhưng AI lại biết đối thủ cạnh tranh rõ hơn vì trang web của đối thủ dễ đọc hơn.

Không phải vì đối thủ tối ưu hóa từ khóa tốt hơn.

Không phải vì họ có nhiều backlink hơn.

Mà vì kiến thức của họ có thể truy cập được về mặt vật lý đối với máy móc.

Nghịch lý thứ hai: Các trang web đã học cách cung cấp thông tin rẻ tiền với cái giá đắt đỏ

Vẫn còn một vấn đề nữa mà tôi cho là quan trọng.

Phát triển web hiện đại đã được tối ưu hóa cho phiên làm việc của con người trong nhiều năm.

Một người mở trang, đọc nó trong mười giây, nhấp vào trang tiếp theo.

Do đó, không ai bận tâm lắm việc việc lấy một trang web kích hoạt:

SSR↓máy chủ ứng dụng (application server)↓5 lệnh gọi API (5 API calls)↓15 truy vấn cơ sở dữ liệu (15 database queries)↓cá nhân hóa (personalization)↓phân tích (analytics)↓dịch vụ bên thứ ba (third-party services)↓kết xuất (render)

Con người chậm chạp về mặt vật lý.

AI crawler thì không.

Nó có thể nói với máy chủ:

GET page 1GET page 2GET page 3GET page 4GET page 5...

vài lần một giây và tiếp tục điều đó trong hàng giờ liền.

Và bất ngờ thay, kiến trúc phục vụ xuất sắc 1.000 người lại phục vụ kém một robot rất tò mò.

Do đó, việc chỉ đơn giản nói:

«Thôi được, ngày mai chúng ta tắt bảo vệ Cloudflare và cho phép AI crawlers»

có thể là điều bất khả thi.

Qua nhiều năm tồn tại của Web đóng, nhiều hệ thống đã mất đi khả năng kinh tế để được mở.

Lựa chọn của tôi thì ngược lại

Đối với các dự án kiến thức/nội dung công cộng, tôi có ý thức coi việc máy đọc hàng loạt là hành vi mong muốn.

Do đó, kiến trúc phải xuất phát từ giả định:

Trang web của tôi có thể không được đọc bởi hàng nghìn người, mà bởi hàng triệu yêu cầu từ máy tính. Và điều đó thật tuyệt.

Hậu quả là, chi phí biên của việc cung cấp kiến thức công cộng phải có xu hướng bằng không.

Nếu crawler muốn đọc một nghìn trang — cứ để nó đọc.

Nếu một vài hệ thống AI độc lập muốn cùng lúc tải xuống mười phiên bản ngôn ngữ của một bách khoa toàn thư — tuyệt vời.

Đây không phải là DDoS, miễn là hành vi vẫn hợp lý và cơ sở hạ tầng có thể chịu được.

Đây là sự phân phối (distribution).

VietnamGuru — Thử nghiệm đầu tiên

Vào ngày 14 tháng 8 năm 2026, tôi đã xuất bản tên miền quốc tế mới vietnamguru.travel.

Tên miền này hoàn toàn mới.

Đồng thời, tôi có ý thức làm cho nó đơn giản nhất có thể để máy móc khám phá:

• các URL thông thường có thể lập chỉ mục;
• HTML được kết xuất từ máy chủ (server-rendered HTML);
• các thẻ <a href> bình thường;
• sitemap;
• canonical;
• hreflang;
• các phiên bản ngôn ngữ mở;
• liên kết với trang vietnamguru.ru cũ;
• không có rào cản nhân tạo đối với các crawler bình thường.

Và gần như ngay sau khi xuất bản, các AI crawler khác nhau đã bắt đầu khám phá tên miền mới.

Một số thực hiện vài yêu cầu mỗi giây và duyệt qua các trang liên quan cũng như các phiên bản ngôn ngữ một cách có hệ thống.

Tôi không cố gắng ngăn chặn hành vi này.

Ngược lại, tôi coi đó là bằng chứng quan sát được đầu tiên cho thấy kênh phân phối mới thực sự tồn tại.

Đồng thời, toàn bộ dự án chạy trên cơ sở hạ tầng hoàn toàn bình thường: một máy chủ DigitalOcean nhỏ với 4 CPU và 8 GB RAM vẫn còn cách xa giới hạn hiệu suất khi chịu mức crawling như vậy.

Đây cũng là một phần của thử nghiệm.

Lựa chọn của tôi không chỉ nằm ở việc cần phải cho phép máy móc đọc.

Nó còn nằm ở chỗ:

một tài nguyên kiến thức công cộng phải có chi phí bảo trì rẻ đến mức có lợi về mặt kinh tế khi cho phép máy móc đọc nó một cách tích cực.

Nhưng việc crawling tự nó không chứng minh được điều gì

Đây là một lưu ý mang tính nguyên tắc.

Hôm nay tôi chỉ quan sát thấy:

Discovery (Khám phá).

Tôi vẫn phải kiểm tra các giai đoạn tiếp theo:

Discovery (Khám phá)    ↓Crawling (Thu thập dữ liệu)    ↓Understanding (Hiểu)    ↓Retrieval (Truy xuất)    ↓Citation (Trích dẫn)    ↓Recommendation (Gợi ý)

Bản thân việc GPTBot, PerplexityBot hoặc bất kỳ crawler nào khác xuất hiện không có nghĩa là trang web sẽ có được lượng khán giả.

Do đó, thử nghiệm phải được tiếp tục.

Câu hỏi thú vị tiếp theo:

Sau bao lâu kể từ khi ra mắt một tên miền hoàn toàn mới, các hệ thống AI độc lập mới có thể trả lời chính xác các câu hỏi bằng cách sử dụng thông tin từ đó?

Một bài kiểm tra mạnh mẽ hơn nữa:

Khi nào chúng sẽ bắt đầu sử dụng nó cho các truy vấn phi thương hiệu (non-branded queries)?

Không phải:

What is VietnamGuru?

mà là:

What waterfalls near Da Lat are worth visiting?

Và cuối cùng là cấp độ thú vị nhất:

Khi nào AI sẽ tự coi tài nguyên đó đủ hữu ích để giới thiệu nó hoặc sử dụng nó làm bằng chứng giữa các nguồn khác?

Nếu giả thuyết được xác nhận

Khi đó, chính khái niệm tối ưu hóa trang web công cộng sẽ thay đổi.

Trong thế hệ trước, SEO từng tồn tại với ý nghĩa:

giúp công cụ tìm kiếm tìm thấy trang để nó dẫn con người đến đó.

Trong thế hệ tiếp theo, một nhiệm vụ cơ bản hơn có thể xuất hiện:

giúp máy móc lấy, hiểu, xác minh và liên kết kiến thức của bạn để nó có thể sử dụng khi giải quyết vấn đề của con người.

Đây không hoàn toàn là SEO nữa.

Và thậm chí không nhất thiết là GEO/AEO theo nghĩa marketing hiện nay.

Đây chính là machine accessibility (khả năng tiếp cận của máy móc) như một thuộc tính của hệ thống thông tin.

Khi đó, các đặc tính cạnh tranh sẽ trở thành:

độ tiếp cận (accessibility)tính cấu trúc (structurability)tính liên kết (connectedness)sự rõ ràng về ngữ nghĩa (semantic clarity)tốc độ (speed)các URL ổn định (stable URLs)việc đọc hàng loạt giá rẻ (cheap mass reading)nguồn gốc xuất xứ (provenance)tính cập nhật (freshness)

Tức là nhiều thuộc tính kỹ thuật cực kỳ nhàm chán bỗng trở thành các thuộc tính của phân phối (distribution).

Và ở đây xuất hiện thêm một nghịch lý nữa

Trong Web cũ, giá trị của một trang web được đo lường một phần bằng số lượng người mà người ta có thể ép buộc đến trang web.

AI có thể phá hủy số đo này.

Con người có thể không bao giờ mở vietnamguru.travel.

Họ sẽ hỏi trợ lý của mình:

Có nên đi Đà Lạt vào tháng 8 không?

Và trợ lý sẽ đọc VietnamGuru, đối chiếu nó với thời tiết, đánh giá, lịch trình giao thông và năm nguồn khác để đưa ra câu trả lời cho con người.

Từ góc độ Google Analytics:

0 khách truy cập (visitors).

Từ góc độ ảnh hưởng thực tế:

VietnamGuru đã tham gia vào quá trình ra quyết định.

Kết quả là một tình huống khá thú vị:

trang web thông tin thành công của tương lai có tiềm năng trở nên có ảnh hưởng hơn đồng thời với việc tỷ lệ người trực tiếp truy cập các trang của nó giảm xuống.

Và khi đó, nhiều chỉ số Web của ngày hôm nay bắt đầu đo lường nhầm chỗ.

Một phỏng đoán tổng quát hơn

Do đó, giả thuyết của tôi không nói về VietnamGuru cũng như không nói về các AI crawler cụ thể.

Nó là thế này:

Khi chuyển từ Web con người duyệt sang Web AI làm trung gian, khả năng của một hệ thống thông tin công cộng được máy móc đọc một cách tự do, hàng loạt và giá rẻ sẽ trở thành lợi thế cạnh tranh.

Ngày nay, một phần đáng kể của ngành công nghiệp theo quán tính coi lưu lượng truy cập bot là chi phí hoặc mối đe dọa.

Tôi cho rằng đối với các nguồn kiến thức công cộng, một phần lưu lượng truy cập này sẽ trở thành kênh phân phối.

Do đó, một cửa sổ cơ hội xuất hiện.

Trong khi các chủ sở hữu nội dung khác đang đặt câu hỏi:

Làm cách nào để cấm AI lấy nội dung của tôi?

Tôi muốn kiểm tra câu hỏi ngược lại:

Điều gì xảy ra nếu bạn biến kho tri thức của mình thành một trong những nơi thuận tiện nhất cho một AI muốn tìm hiểu về lĩnh vực của bạn?

Có thể không có chuyện gì xảy ra.

Có thể các nền tảng AI sẽ xây dựng các cơ chế thu nhận kiến thức hoàn toàn khác.

Có thể các nhà xuất bản thực sự sẽ đóng cửa và một nền kinh tế cấp phép sẽ xuất hiện.

Có thể các crawler của ngày hôm nay sẽ biến mất hoàn toàn sau một năm nữa.

Đây là một thử nghiệm, không phải là một sự thật đã được thiết lập.

Nhưng lựa chọn của tôi cho tháng 8 năm 2026 rất đơn giản:

Nếu máy móc đang trở thành giao diện mới của con người với internet, việc chiến đấu với mọi cỗ máy chỉ vì nó là máy móc có lẽ là một trong những thói quen cuối cùng của Web đang lụi tàn.

Và tôi có ý thức đặt cược vào chiều ngược lại:

Đối với kiến thức công cộng, tính cởi mở sẽ lại trở thành lợi thế.

Cuối cùng tôi đã ra mắt trang web đa ngôn ngữ trên tên miền mới https://vietnamguru.travel/

Phiên bản tiếng Nga vẫn ở https://vietnamguru.ru

Thật đáng ngạc nhiên, Google đã lập chỉ mục một vài trang chưa đầy một ngày.

Chưa đầy một ngày, thống kê sau đã được thu thập (được nhóm theo tác nhân người dùng):