Cấu trúc website chuẩn SEO: Ba lớp kiến trúc quyết định sức mạnh bền vững

Bài viết dành cho chủ doanh nghiệp, quản trị viên web, người làm SEO và lập trình viên đang xây mới hoặc tái cấu trúc website. Bài đi qua ba lớp kiến trúc quyết định năng lực SEO của một website – lớp liên kết, lớp URL, lớp ngữ nghĩa – kèm bộ mẫu cấu trúc cho ba mô hình website phổ biến, cách xử lý bốn bài toán kỹ thuật khó nhất, và quy trình audit bảy bước có thể áp dụng ngay vào dự án.

1. Phá bỏ lầm tưởng

Cấu trúc website là phần bị hiểu sai nhiều nhất trong SEO, phần lớn vì các lời khuyên phổ biến trên thị trường đã lỗi thời từ 5 đến 10 năm nhưng vẫn được truyền tay nhau như chân lý.

1.1. Lầm tưởng 1: “Kiến trúc phẳng” nghĩa là dồn hết lên trang chủ

• Nhận thức sai: Cố gắng liên kết mọi trang con trực tiếp từ trang chủ, hoặc để toàn bộ nội dung ở cấp thư mục gốc.
• Thực tế: Kiến trúc phẳng là tối thiểu hóa số nhấp chuột từ trang chủ đến trang đích, không phải tối thiểu hóa số cấp thư mục. Nhồi hàng nghìn liên kết vào trang chủ triệt tiêu phân cấp ngữ nghĩa và làm loãng giá trị của mọi liên kết trên trang đó. Ngưỡng thực dụng: dưới 10.000 trang thì mọi trang quan trọng nên nằm trong 3 đến 4 click; site thương mại điện tử rất lớn có thể chấp nhận sâu hơn ở tầng sản phẩm, miễn là danh mục chính nằm ở tầng 1 đến 2.

1.2. Lầm tưởng 2: URL sâu đồng nghĩa với click sâu

Đây là nhầm lẫn khái niệm nghiêm trọng nhất và ít được nói đến nhất.

• Nhận thức sai: domain.com/a/b/c/d/ là trang ở độ sâu 4 click.
• Thực tế: Độ sâu click được quyết định bởi cấu trúc liên kết nội bộ, không phải bởi số dấu gạch chéo trong URL. Một trang có URL bốn tầng nhưng được liên kết trực tiếp từ trang chủ thì có độ sâu click bằng 1. Ngược lại, một trang URL phẳng domain.com/san-pham-x/ nhưng chỉ tiếp cận được qua trang phân trang thứ 12 thì thực chất nằm rất sâu.
• John Mueller của Google đã nói rõ nhiều lần rằng Google không quan tâm nhiều đến cấu trúc thư mục mà tập trung vào liên kết nội bộ – từ trang chủ đi tới trang đó nhanh đến mức nào. Hệ quả thực hành: đừng làm phẳng URL để “giảm độ sâu”. Hãy sửa menu, breadcrumb, hub page và liên kết ngữ cảnh.

1.3. Lầm tưởng 3: Subdomain và subfolder giống hệt nhau (hoặc khác nhau tuyệt đối)

Thị trường chia hai phe cực đoan, cả hai đều sai một nửa.

• Lập trường công khai của Google: cả subdomain lẫn subdirectory đều dùng được; hãy chọn theo cấu hình kỹ thuật và kế hoạch dài hạn của bạn.
• Thực tế vận hành: subdomain phải xác minh riêng trong Search Console, được xử lý như một tài sản tương đối độc lập, và trong nhiều trường hợp thực tế thì tín hiệu tích lũy không chảy qua lại thuận lợi như subfolder.

Vì vậy khuyến nghị của tôi là:

• Mặc định chọn subfolder cho mọi nội dung thuộc cùng một chủ đề kinh doanh với tên miền chính: blog, danh mục dịch vụ, tài liệu, case study.
• Chỉ chọn subdomain khi có lý do kỹ thuật hoặc tổ chức thật sự: nền tảng khác biệt hoàn toàn (app, help desk, LMS), đội ngũ vận hành riêng, hoặc phân vùng theo địa lý ở quy mô rất lớn.

Lưu ý về nguồn: con số “90% đến 99.9% trường hợp nên dùng subfolder” đang lưu hành trong cộng đồng SEO Việt Nam không phải là số liệu do Google công bố trong tài liệu chính thức. Hãy lập luận bằng cơ chế vận hành, đừng mượn uy tín bằng một con số không truy được nguồn.

1.4. Lầm tưởng 4: Canonical từ trang phân trang trỏ về trang “Xem tất cả”

• Nhận thức sai: Trang 2, 3, 4 đặt rel="canonical" trỏ về trang View-All để “hợp nhất sức mạnh”.
• Thực tế: Đây là lời khuyên từ một bài blog của Google năm 2011, thuộc thời kỳ rel="next"/"prev" còn hiệu lực – và Google đã ngừng hỗ trợ cặp thẻ này từ năm 2019. Tài liệu e-commerce hiện hành của Google nêu rõ: mỗi trang trong chuỗi phân trang cần URL riêng và canonical trỏ về chính nó, không lấy trang đầu tiên làm canonical cho cả chuỗi, và không dùng fragment # cho số trang vì Google bỏ qua toàn bộ phần sau dấu thăng.
• Hậu quả của cách làm cũ rất cụ thể: khi trang 2 trở đi bị canonical hóa đi nơi khác, Google giảm ưu tiên crawl các trang đó, và các liên kết sản phẩm nằm trên chúng mất đường tiếp cận. Với danh mục lớn, đây chính là nguyên nhân hàng nghìn sản phẩm không bao giờ được index.

1.5. Lầm tưởng 5: Chặn robots.txt rồi vẫn đặt canonical là “làm cả hai cho chắc”

• Hai lệnh này triệt tiêu nhau. Nếu URL bị chặn crawl, Google không đọc được nội dung trang, do đó không thấy thẻ canonical hay noindex bên trong. Tệ hơn, URL bị chặn vẫn có thể xuất hiện trong index dưới dạng rỗng nếu có liên kết trỏ tới.
• Tài liệu Google về điều hướng đa chiều phân tách rõ hai nhánh: nếu không cần các URL bộ lọc được index thì ngăn crawl; nếu cần chúng được index thì để chúng tuân theo best practices. Chọn một nhánh cho mỗi nhóm URL, không trộn lẫn. Mueller còn khuyến nghị mặc định không dùng robots.txt cho URL bộ lọc mà cho crawl rồi xử lý bằng canonical hoặc noindex, trừ khi máy chủ thật sự quá tải.

1.6. Lầm tưởng 6: Crawl budget là bài toán của mọi website

• Thực tế: Tài liệu quản lý crawl budget của Google tự giới hạn phạm vi cho ba nhóm – site trên 1 triệu URL thay đổi hàng tuần, site trên 10.000 URL thay đổi hàng ngày, và site có tỷ lệ lớn URL ở trạng thái “Discovered – currently not indexed”. Google đã tái xác nhận ngưỡng 1 triệu trang, đồng thời bổ sung một chi tiết ít người để ý: tốc độ phản hồi của database ảnh hưởng đến khả năng crawl nhiều hơn số lượng trang.
• Với phần lớn website doanh nghiệp Việt Nam dưới vài nghìn URL, nếu nội dung không được index thì nguyên nhân gần như luôn là chất lượng nội dung, trùng lặp, hoặc trang mồ côi không có liên kết nội bộ – không phải crawl budget. Chẩn đoán sai bệnh dẫn đến kê sai thuốc.

1.7. Lầm tưởng 7: URL là “yếu tố xếp hạng chính thức”

• Tài liệu Google chỉ nói rằng các từ mang tính mô tả trong đường dẫn có thể giúp Google hiểu trang tốt hơn. URL là tín hiệu hỗ trợ và là yếu tố trải nghiệm (người dùng đọc URL trên SERP trước khi click), không phải một đòn bẩy xếp hạng độc lập.
• Đừng tái cấu trúc toàn bộ URL của một site đang chạy tốt chỉ để nhét thêm từ khóa – chi phí redirect và rủi ro mất tín hiệu thường lớn hơn lợi ích.

2. Hiểu bản chất: Ba lớp kiến trúc

Cấu trúc website không phải một sơ đồ, mà là ba lớp chồng lên nhau. Nhầm lẫn giữa các lớp là nguồn gốc của hầu hết sai lầm ở phần 1.

Lớp 1 – Kiến trúc liên kết (lớp quyết định)

Đây là lớp có tác động lớn nhất và cũng là lớp bị bỏ quên nhiều nhất. Googlebot phát hiện trang bằng cách đi theo liên kết, và phân bổ tầm quan trọng theo mật độ, vị trí, chất lượng liên kết trỏ tới.

• Liên kết phải là HTML thật. Thẻ <a> với thuộc tính href trỏ tới URL thật. Menu, phân trang, bộ lọc dựng bằng JavaScript không sinh ra href (router client-side, onclick, <div> giả nút) sẽ tạo ngõ cụt cho bot. Đây là phiên bản 2026 của vấn đề mà 10 năm trước người ta gọi là “menu Flash”.
• Không có trang mồ côi. Mọi URL có giá trị phải nhận ít nhất một liên kết nội bộ theo ngữ cảnh, không chỉ nằm trong sitemap.xml. Sitemap giúp phát hiện, liên kết nội bộ mới truyền tầm quan trọng.
• Dòng chảy PageRank có chủ đích. Trang chủ và các hub nhận nhiều liên kết ngoài nhất; nhiệm vụ của kiến trúc là dẫn dòng chảy đó xuống các trang tạo doanh thu, thay vì để nó tản mát vào trang chính sách, điều khoản, tag rác.

Lớp 2 – Kiến trúc URL (lớp phản ánh)

URL phản ánh cấu trúc, không tạo ra cấu trúc. Nguyên tắc theo tài liệu URL structure của Google:

• Dùng từ mô tả, ưu tiên ngôn ngữ của đối tượng độc giả, mã hóa UTF-8 cho ký tự ngoài ASCII.
• Dùng gạch nối - để phân tách từ; tránh gạch dưới _ và tránh viết liền.
• Tránh chuỗi ID dài vô nghĩa và fragment #.
• Với tham số, dùng dạng ?key=value, dùng & để nối, dấu phẩy cho nhiều giá trị.
• Giữ nhất quán chữ thường – URL phân biệt hoa thường trên phần lớn máy chủ.

Một điểm cần nói thẳng cho thị trường Việt Nam: Google không yêu cầu URL phải bỏ dấu. Tài liệu chính thức khuyến khích dùng ngôn ngữ bản địa và có ví dụ URL tiếng Nhật, tiếng Đức có ký tự đặc biệt. Lý do chúng ta vẫn nên dùng URL tiếng Việt không dấu là thực dụng, không phải kỹ thuật SEO: URL có dấu bị percent-encoding làm biến dạng khi copy-paste, gây khó khi chia sẻ trên tin nhắn, và làm rối log phân tích. Hãy dạy đúng lý do, học viên sẽ ra quyết định đúng trong các tình huống ngoại lệ.

Lớp 3 – Kiến trúc ngữ nghĩa và thực thể (lớp nâng cao)

Đây là lớp phân biệt một website được sắp xếp gọn gàng với một website được máy hiểu.

• Pillar & Cluster: Trang trụ cột bao quát chủ đề lớn, nhắm từ khóa ngắn; các bài cluster giải quyết từng khía cạnh hẹp, nhắm từ khóa đuôi dài. Liên kết hai chiều giữa pillar và cluster tuyên bố với công cụ tìm kiếm rằng site sở hữu chủ đề đó.
• Schema như bản đồ thực thể: Organization với sameAs trỏ về các hồ sơ chính thức, Person cho tác giả và liên kết tới trang hồ sơ, BreadcrumbList cho phân cấp, Product, Service, Article theo loại trang. Schema không phải trang trí SERP – nó là cách khai báo cấu trúc bằng ngôn ngữ máy đọc.
• Anchor text nhất quán: Neo văn bản là nhãn ngữ nghĩa bạn tự gán cho trang đích. Ba mươi liên kết nội bộ trỏ về cùng một trang với ba mươi neo khác nhau là ba mươi tín hiệu mờ.

Mô hình Tủ hồ sơ (vẫn dùng được, sau khi hiệu chỉnh)

Mô hình này mô tả tốt lớp 2, nhưng có một giới hạn cần nói rõ khi giảng: tủ hồ sơ là phép ẩn dụ một chiều, trong khi website thật là mạng lưới nhiều chiều. Một sản phẩm có thể thuộc nhiều bộ sưu tập, một bài viết có thể phục vụ nhiều intent. Đó là lý do phần 4 nói về Ontology.

3. Ví dụ minh họa và trải nghiệm

3.1. Craigslist: sức mạnh của phân cấp – và một nghịch lý cần giải thích

• Craigslist là minh chứng rằng logic thông tin quan trọng hơn thẩm mỹ giao diện. Hành trình tìm căn hộ ở Seattle gọn trong bốn bước: vào khu vực, chọn Housing, chọn Apartments for Rent, lọc theo tiêu chí. Hàng triệu trang niêm yết vẫn được thu thập và xếp hạng tốt nhờ phân cấp nhất quán và điều hướng bằng HTML thuần.
• Nghịch lý cần chỉ ra thay vì né tránh: Craigslist dùng subdomain cho từng thành phố (seattle.craigslist.org), đi ngược khuyến nghị “ưu tiên subfolder” ở phần 1.3. Lý do hợp lý: mỗi thành phố là một thị trường gần như độc lập, với tập người dùng, tin đăng và ngôn ngữ tìm kiếm riêng – đúng vào nhóm ngoại lệ mà subdomain phục vụ tốt. Bài học không phải “subfolder luôn thắng”, mà là ranh giới cấu trúc nên trùng với ranh giới thị trường thật.

3.2. Amazon: liên kết ngang là hạ tầng, không phải tiện ích

• Amazon giỏi phân cấp dọc, nhưng thứ khiến hệ thống của họ không có ngõ cụt là các khối liên kết ngang tự sinh: sản phẩm thường mua cùng, khách mua món này cũng mua, sản phẩm tương tự. Máy ảnh nối sang thẻ nhớ, túi, chân máy. Mạng lưới này tạo đường dẫn ngữ nghĩa cho bot và tạo đường khám phá cho người dùng, đồng thời liên tục bơm liên kết mới cho các sản phẩm nằm sâu.
• Điều cần lưu ý khi áp dụng: khối liên kết ngang chỉ có giá trị khi được render trong HTML. Nếu widget “sản phẩm liên quan” tải bằng AJAX sau khi người dùng cuộn, bot có thể không bao giờ nhìn thấy nó – và bạn đang trả tiền cho một tính năng SEO không tồn tại.

3.3. Google tự tái cấu trúc tài liệu của chính mình

• Đội tài liệu của Google từng tổ chức Search Central theo trình độ người đọc: cơ bản, trung cấp, nâng cao. Cách phân loại này chủ quan – một bài với người này là cơ bản, với người khác là nâng cao – dẫn đến nội dung chồng chéo, URL không ổn định và cản trở dịch thuật đa ngôn ngữ.
• Họ chuyển sang cấu trúc theo chủ đề, nhóm theo chức năng kỹ thuật: crawling, indexing, ranking. Trong nhật ký cập nhật tài liệu, Google ghi nhận việc tổ chức lại điều hướng theo chủ đề thay vì theo cấp độ, đồng thời gỡ bỏ các hướng dẫn cấp cơ bản bị trùng với SEO Starter Guide.
• Bài học chuyển giao được: phân loại theo thuộc tính chủ quan của người đọc (trình độ, nhu cầu giả định) tạo ra cấu trúc không ổn định. Phân loại theo thuộc tính khách quan của đối tượng (chức năng, loại sản phẩm, giai đoạn quy trình) tạo ra cấu trúc sống lâu. Đây là câu hỏi cần đặt ra trước mọi dự án: cái gì trong phân loại này sẽ vẫn đúng sau ba năm?

4. Triết lý

4.1. Taxonomy và Ontology

• Taxonomy là phân cấp cứng, một chiều, theo logic kỹ thuật: Thời trang Nam → Áo Nam → Áo sơ mi.
• Ontology là mạng lưới khái niệm mô phỏng cách con người liên tưởng trong đời thực.

Ví dụ kinh điển: với nhà thực vật học, cà chua là trái cây. Với người nội trợ, cà chua là rau, là nguyên liệu salad, là thứ nằm cạnh hành và dưa chuột.

Kiến trúc sư thông tin giỏi không chọn một trong hai. Anh ta dùng Taxonomy làm bộ xương (một trang, một vị trí chính tắc, một URL canonical) và dùng Ontology làm hệ tuần hoàn (bộ lọc, tag, liên kết ngang, khối gợi ý). Người dùng tư duy kiểu nào cũng tới được đích, nhưng hệ thống chỉ có một nguồn chân lý.

4.2. “Don’t Make Me Think”

• Triết lý tối cao của cấu trúc là sự vô hình. Nếu người dùng phải dừng lại một giây để tự hỏi “tôi đang ở đâu”, “quay lại danh mục kiểu gì”, “nút mua nằm chỗ nào” – cấu trúc đã thất bại, bất kể sơ đồ trên giấy đẹp đến đâu.

4.3. Cấu trúc là một quyết định quản trị, không phải một quyết định kỹ thuật

• Điểm này ít được nói nhưng quan trọng nhất với chủ doanh nghiệp: chi phí thay đổi cấu trúc tăng theo hàm mũ với tuổi đời website. Sửa cấu trúc ở tháng thứ hai tốn một buổi chiều. Sửa cấu trúc ở năm thứ năm tốn một bản đồ redirect vài nghìn dòng, ba tháng biến động thứ hạng, và rủi ro mất tín hiệu vĩnh viễn ở những URL có backlink tốt.
• Vì vậy, thời điểm đầu tư nghiêm túc nhất vào kiến trúc thông tin là trước khi xuất bản trang nội dung đầu tiên. Và nguyên tắc vận hành sau đó là: cấu trúc chỉ nên thay đổi khi mô hình kinh doanh thay đổi, không phải khi có xu hướng SEO mới.

5. Đào sâu mở rộng

5.1. Bộ mẫu cấu trúc cho ba mô hình website

A. Website dịch vụ

Quy mô nhỏ và vừa, mục tiêu là dồn sức mạnh xuống các trang dịch vụ chuyển đổi.

Phân cấp: Trang chủ → Danh mục dịch vụ (hub) → Dịch vụ chi tiết, cộng thêm trang giới thiệu, trang tác giả, trang liên hệ.

Mẫu URL:

https://domain.com/
https://domain.com/dich-vu-seo/
https://domain.com/dich-vu-seo/seo-tong-the/
https://domain.com/ve-chung-toi/
https://domain.com/author/ten-tac-gia/
https://domain.com/lien-he/

Schema khuyên dùng: Organization, Service, LocalBusiness (nếu có địa điểm vật lý), BreadcrumbList.

Chi tiết và cụ thể hơn thì Webiste dịch vụ chi tiết sẽ có các phân khu sau:

1. Phân khu trang chủ

• Đại diện cho Doanh nghiệp
• https://domain.com/

2. Phân khu các dịch vụ:

• Gồm danh sách các dịch vụ cha và các dịch vụ con. Tên các dịch vụ này sẽ kết hợp giữa bản chất của gói dịch vụ và từ khóa, cũng như volume search mà người dùng đang tìm kiếm trên Google search. Lúc này mới khởi tạo tên dịch vụ cha và con thỏa cả doanh nghiệp và người dùng.
• https://domain.com/dich-vu-cha/
• https://domain.com/dich-vu-cha/dich-vu-con

3. Phân khu các danh mục Blog 

• Thường sẽ đặt tên là: Cẩm nang | Hỏi đáp | 

Ghi chú E-E-A-T: trang tác giả và trang giới thiệu không phải thủ tục hình thức. Chúng là nơi bạn khai báo thực thể con người và tổ chức đứng sau nội dung – và là nơi sameAs trỏ ra các hồ sơ có thể xác minh độc lập.

B. Website sản phẩm / thương mại điện tử

Phân cấp: Trang chủ → Danh mục cha → Danh mục con → Sản phẩm → Biến thể.

Mẫu URL:

https://domain.com/thoi-trang-nam/
https://domain.com/thoi-trang-nam/giay-the-thao/
https://domain.com/thoi-trang-nam/giay-the-thao/giay-nike-air-max/
https://domain.com/thoi-trang-nam/giay-the-thao/giay-nike-air-max?color=red

Về biến thể sản phẩm, tài liệu e-commerce của Google chấp nhận cả hai cách: phân đoạn đường dẫn hoặc tham số truy vấn. Nguyên tắc chọn:

• Biến thể có nhu cầu tìm kiếm thật (ví dụ “giày Nike đỏ”) → URL riêng, cho index, có tiêu đề và mô tả riêng.
• Biến thể không có nhu cầu tìm kiếm (size 40.5, mã màu nội bộ) → canonical về sản phẩm gốc.

Schema: Product, Offer, AggregateRating, BreadcrumbList.

C. Website tin tức / blog

Phân cấp: Trang chủ → Chuyên mục → Bài viết, cộng trang hồ sơ tác giả.

Mẫu URL:

https://domain.com/marketing/
https://domain.com/marketing/chien-luoc-content-marketing/
https://domain.com/author/ten-tac-gia/

Schema: NewsArticle hoặc BlogPosting với headline, image, datePublished, dateModified, và author dạng Person liên kết tới trang hồ sơ.

Một quyết định cấu trúc dễ sai: không đưa ngày tháng vào URL với nội dung evergreen. /2023/07/bai-viet/ biến mọi lần cập nhật thành một cuộc thương lượng khó chịu giữa tính chính xác và tính ổn định của URL.

5.2. Phân trang: cách làm đã cập nhật

Cách làm hiện hành theo tài liệu Google:

1. Mỗi trang phân trang có URL riêng, dùng tham số truy vấn rõ ràng như ?page=2.
2. Mỗi trang có canonical trỏ về chính nó.
3. Liên kết tuần tự giữa các trang bằng thẻ <a href> thật, không phải nút JavaScript.
4. Không dùng fragment # cho số trang – Google bỏ qua phần sau dấu thăng.
5. Không noindex và không chặn robots.txt các trang phân trang, vì các liên kết sản phẩm nằm trên chúng.

Bổ sung thực chiến: thay vì chỉ có nút “Trước / Sau”, hãy hiển thị dãy số trang (1, 2, 3… 10). Việc này giảm độ sâu click cho các trang cuối chuỗi và cho các sản phẩm nằm trên đó.

Về trang “Xem tất cả”: nó vẫn hữu ích cho người dùng nếu tải nhanh, nhưng không còn là giải pháp canonical được khuyến nghị. Nếu bạn duy trì trang View-All, hãy để nó tồn tại song song với canonical tự tham chiếu, và cân nhắc tốc độ tải trước tiên.

5.3. Điều hướng đa chiều: quyết định theo nhóm URL

Bộ lọc màu sắc, kích thước, khoảng giá sinh ra tổ hợp URL gần như vô hạn. Cách xử lý đúng là phân nhóm trước, ra quyết định sau – không áp một chiến thuật cho tất cả:

Quy tắc bất di bất dịch: đã chặn crawl thì đừng trông chờ vào canonical hay noindex trong trang đó. Một URL, một cơ chế.

5.4. Đa ngôn ngữ và Hreflang

• Ưu tiên thư mục con (example.com/en/) hoặc ccTLD (example.de). Tránh tham số ngôn ngữ dạng ?lang=fr.
• Ba quy tắc hreflang: mã ngôn ngữ và quốc gia hợp lệ, liên kết đối ứng hai chiều giữa mọi phiên bản, và bắt buộc có self-reference trỏ về chính nó.
• x-default cho trang chọn ngôn ngữ hoặc phiên bản mặc định.

Đính chính một hiểu nhầm phổ biến: Google không phạt nội dung dịch thuật vì trùng lặp. Hreflang là tín hiệu giúp Google chọn đúng phiên bản cho đúng người dùng, không phải lá chắn tránh án phạt. Cách nói “để Google không phạt bạn” tạo ra nỗi sợ sai chỗ.

5.5. Breadcrumbs

Lợi ích kép: giúp người dùng định vị và quay lên cấp cha bằng một click; đồng thời tạo mạng liên kết nội bộ tự nhiên từ dưới lên. Khi triển khai BreadcrumbList schema, Google có thể hiển thị đường dẫn phân cấp trên SERP.

Yêu cầu kỹ thuật thường bị bỏ sót: breadcrumb hiển thị trên giao diện và breadcrumb trong schema phải khớp nhau. Breadcrumb dựng bằng JavaScript sau khi tải trang thường không đóng góp gì vào lớp liên kết.

6. Cấu trúc trong kỷ nguyên AI Search

Đây là lớp mà hầu hết tài liệu về cấu trúc website chưa cập nhật.

Các hệ thống tìm kiếm sinh nội dung không đọc website theo cấp trang mà theo cấp đoạn. Google xác nhận hệ thống passage ranking có thể nhận diện từng đoạn riêng lẻ trong một trang để đánh giá mức độ liên quan, và tài liệu hướng dẫn về generative AI mô tả quá trình truy xuất là: lấy về các trang liên quan, sau đó xem xét thông tin cụ thể bên trong những trang đó.

Hệ quả với kiến trúc thông tin:

1. Mỗi mục H2 nên tự đứng được. Một đoạn bị trích ra khỏi ngữ cảnh trang vẫn phải nêu rõ nó nói về thực thể nào. Đại từ và tham chiếu ngược (“như đã nói ở trên”, “công cụ này”) làm hỏng khả năng trích xuất.
2. Liên kết phải nằm cùng đoạn với luận điểm nó chứng minh. Nếu bằng chứng nằm cách luận điểm ba đoạn, hệ thống truy xuất có thể lấy luận điểm mà bỏ lại bằng chứng.
3. Tín hiệu thực thể quan trọng hơn trước. Schema Organization với sameAs, hồ sơ tác giả có thể xác minh, và cụm liên kết nội bộ quanh một chủ đề – tất cả cùng làm rõ site này đại diện cho thực thể nào và sở hữu chủ đề nào.

Cần nói rõ mức độ chắc chắn: Google đã công bố hướng dẫn tối ưu cho các tính năng AI với thông điệp rằng nền tảng SEO vẫn áp dụng và không cần chia nhỏ nội dung theo cách đặc biệt hay dùng định dạng riêng cho AI. Một bộ phận trong ngành phản biện quan điểm này, dựa trên dữ liệu quan sát về cách các câu trả lời AI trích dẫn ở cấp đoạn. Đây là vấn đề đang tranh luận, không phải chân lý đã chốt. Lập trường an toàn và đúng đắn về mặt nghề nghiệp: viết rõ ràng, đoạn tự chứa, cấu trúc phân cấp minh bạch – những việc này tốt cho người đọc trước, và tình cờ cũng tốt cho mọi hệ thống truy xuất.

7. Quy trình audit cấu trúc trong bảy bước

Thứ tự này quan trọng: mỗi bước cung cấp dữ liệu cho bước sau.

1. Crawl toàn site (Screaming Frog, Sitebulb hoặc tương đương). Xuất báo cáo độ sâu click, trạng thái index, canonical, số liên kết nội bộ tới từng URL.
2. Tìm trang mồ côi. Đối chiếu URL trong sitemap.xml với URL crawler tìm được qua liên kết. Chênh lệch chính là danh sách việc cần làm.
3. Lập biểu đồ độ sâu click. Bao nhiêu phần trăm URL doanh thu nằm trong 3 click? Đây là chỉ số kiến trúc quan trọng nhất.
4. Kiểm tra Search Console. Báo cáo Trang, đặc biệt các trạng thái “Discovered – currently not indexed” và “Crawled – currently not indexed”. Đây là nơi vấn đề cấu trúc lộ diện dưới dạng số liệu thật.
5. Kiểm kê URL tham số. Liệt kê mọi mẫu tham số đang tồn tại, phân nhóm theo bảng ở mục 5.3, gán một cơ chế xử lý cho mỗi nhóm.
6. Rà soát canonical và phân trang. Tìm mọi canonical trỏ ngược về trang 1 hoặc View-All – đây thường là mỏ vàng sửa lỗi.
7. Phân tích log máy chủ (chỉ với site lớn). So sánh tần suất crawl thực tế với danh sách URL ưu tiên kinh doanh.

Chỉ số theo dõi

Bảng tổng hợp

Kết luận

Cấu trúc website là bộ khung xương, và như mọi bộ khung, giá trị của nó nằm ở chỗ không ai nhìn thấy nó khi mọi thứ vận hành đúng.

Ba điều đáng mang theo từ bài này:

Thứ nhất, liên kết quyết định, URL chỉ phản ánh. Nếu chỉ có thời gian làm một việc, hãy sửa cấu trúc liên kết nội bộ trước khi động vào một ký tự nào của URL.

Thứ hai, mỗi URL một cơ chế. Phần lớn thảm họa kỹ thuật SEO đến từ việc chồng nhiều lệnh mâu thuẫn lên cùng một nhóm URL vì tâm lý “làm cả hai cho chắc”.

Thứ ba, hãy kiểm chứng nguồn trước khi truyền đạt. Nhiều lời khuyên về cấu trúc đang lưu hành trong cộng đồng là tàn dư của tài liệu Google từ 2011 đến 2014, đã bị chính Google thay thế. Thói quen mở tài liệu gốc trước khi dạy lại là ranh giới giữa người làm nghề và người lặp lại.

Đầu tư vào kiến trúc thông tin không tạo ra kết quả trong tuần này. Nó tạo ra điều kiện để mọi nỗ lực nội dung và liên kết trong ba năm tới không bị lãng phí. Đó chính là định nghĩa của bền vững.

Nguồn tham khảo chính

• Google Search Central – URL Structure Best Practices
• Google Search Central – Pagination and Incremental Page Loading (E-commerce)
• Google Search Central – Ecommerce URL Structure Best Practices
• Google Search Central – Managing Crawling of Faceted Navigation URLs
• Google Search Central – Large Site Owner’s Guide to Managing Crawl Budget
• Google Search Central – SEO Starter Guide
• Google Search Central – How Search Works
• Google Search Central Blog – One Year of Google Search Central (tái cấu trúc tài liệu theo chủ đề)
• Google Search Central – Documentation Updates Log
• Google Search Central – Passage Ranking và hướng dẫn về tính năng AI