Mục lục

Subdomain và thư mục con đều được sử dụng để tổ chức nội dung bên trong một tên miền.

Ví dụ website chính:

example.com

Có thể xây khu vực blog theo hai cách:

Subdomain:

blog.example.com

Hoặc:

Thư mục con:

example.com/blog/

Cả hai đều có thể được Google crawl và index.

Google hiện cho biết từ góc độ lập chỉ mục và xếp hạng, họ không ưu tiên subdomain hay subdirectory, vì vậy doanh nghiệp nên lựa chọn cấu trúc thuận tiện nhất cho việc tổ chức và quản lý website. (developers.google.com)

Subdomain là một phần đứng trước tên miền chính.

Ví dụ:

shop.example.com

Trong đó:

example.com là tên miền chính.

shop là subdomain.

Doanh nghiệp có thể tạo nhiều subdomain như:

blog.example.com

seller.example.com

support.example.com

app.example.com

api.example.com

Mỗi subdomain có thể phục vụ một hệ thống hoặc chức năng khác nhau.

Thư mục con, hay subdirectory, nằm phía sau tên miền.

Ví dụ:

example.com/blog/

example.com/shop/

example.com/tin-tuc/

example.com/san-pham/

Các nội dung này vẫn nằm trực tiếp dưới website chính:

example.com

Thư mục con thường được sử dụng để tổ chức:

  • Danh mục.
  • Sản phẩm.
  • Tin tức.
  • Blog.
  • Dịch vụ.
  • Khu vực nội dung.

Ví dụ cùng một khu vực nội dung “blog”.

Subdomain:

blog.example.com

Thư mục con:

example.com/blog/

Sự khác biệt nằm ở vị trí của phần “blog”.

Với subdomain, blog đứng trước domain.

Với thư mục con, blog nằm phía sau domain.

Không phải một tên miền được đăng ký riêng.

Nếu bạn sở hữu:

example.com

bạn có thể tạo:

blog.example.com

shop.example.com

mà không cần đăng ký từng tên miền riêng.

Tuy nhiên, về mặt kỹ thuật, mỗi subdomain có thể được cấu hình như một hostname riêng và thậm chí chạy trên một hệ thống máy chủ hoàn toàn khác.

Đây là một trong những lợi thế lớn của subdomain.

Ví dụ:

www.example.com

chạy trên hệ thống website chính.

Trong khi:

app.example.com

có thể chạy trên một cloud server khác.

seller.example.com

có thể sử dụng một nền tảng khác.

support.example.com

có thể chạy trên phần mềm helpdesk bên thứ ba.

Do đó, subdomain rất phù hợp khi doanh nghiệp có nhiều hệ thống công nghệ độc lập.

Ví dụ:

example.com/blog/

thường được quản lý chung với:

example.com/san-pham/

example.com/dich-vu/

Điều này giúp:

  • Dễ quản trị.
  • Dễ xây internal link.
  • Đồng nhất giao diện.
  • Đồng nhất analytics.
  • Dễ quản lý SEO.

Với website doanh nghiệp thông thường, đây thường là cấu trúc đơn giản hơn.

Không.

Google hiện trả lời trực tiếp rằng khi lựa chọn giữa:

subfolder/subdirectory

và:

subdomain

hãy sử dụng cấu trúc dễ tổ chức và quản lý nhất; về mặt indexing và ranking, Google không có sự ưu tiên. (developers.google.com)

Google SEO Starter Guide cũng đưa ra quan điểm tương tự: lựa chọn nên dựa trên nhu cầu kinh doanh và cách quản lý website. (developers.google.com)

Vì vậy, không nên quyết định chỉ dựa trên quan niệm:

“Subfolder luôn SEO mạnh hơn subdomain.”

Mặc dù Google không nói thư mục con được ưu tiên hơn, nhưng trong thực tế thư mục con thường dễ quản lý hơn với một website thống nhất.

Ví dụ:

example.com/blog/

có thể sử dụng chung:

  • Navigation.
  • Internal link.
  • Analytics.
  • CMS.
  • Template.
  • Sitemap.
  • Quy trình nội dung.

Điều này giúp đội SEO dễ triển khai một hệ thống nội dung thống nhất.

Lợi thế chủ yếu đến từ quản trị và kiến trúc website, không phải vì Google mặc định ưu tiên subdirectory.

Thư mục con thường phù hợp khi nội dung là một phần trực tiếp của website chính.

Ví dụ:

example.com/blog/

example.com/tin-tuc/

example.com/san-pham/

example.com/dich-vu/

Nên ưu tiên thư mục con nếu:

  • Cùng thương hiệu.
  • Cùng đối tượng khách hàng.
  • Cùng CMS.
  • Cùng đội nội dung.
  • Cùng mục tiêu SEO.
  • Nội dung liên quan trực tiếp đến website chính.

Đây là trường hợp phổ biến nhất với website doanh nghiệp.

Trong phần lớn trường hợp, nếu blog là nội dung phục vụ website chính, có thể ưu tiên:

example.com/blog/

Ví dụ một website bán nội thất có blog:

example.com/blog/cach-chon-sofa/

Blog có thể trực tiếp hỗ trợ:

  • Danh mục.
  • Sản phẩm.
  • Internal link.
  • SEO chủ đề.

Không cần tách thành:

blog.example.com

trừ khi có lý do kỹ thuật hoặc tổ chức cụ thể.

Nếu tin tức là một phần của website chính:

example.com/tin-tuc/

thường đơn giản.

Nếu doanh nghiệp xây một hệ thống tin tức tương đối độc lập, có:

  • Đội nội dung riêng.
  • CMS riêng.
  • Nhận diện riêng.
  • Quy mô lớn.

thì:

news.example.com

cũng có thể hợp lý.

Không có quy tắc bắt buộc.

Subdomain phù hợp khi phần nội dung hoặc hệ thống có tính độc lập cao.

Ví dụ:

app.example.com

cho ứng dụng web.

seller.example.com

cho cổng người bán.

support.example.com

cho trung tâm hỗ trợ.

developers.example.com

cho tài liệu lập trình.

status.example.com

cho trạng thái hệ thống.

Trong các trường hợp này, việc tách subdomain giúp kiến trúc kỹ thuật rõ ràng hơn.

Ví dụ:

Website chính:

example.com

chạy WordPress.

Ứng dụng:

app.example.com

chạy React hoặc một framework khác.

Hỗ trợ khách hàng:

support.example.com

chạy trên nền tảng SaaS.

Việc đưa tất cả vào thư mục con đôi khi gây phức tạp về routing và hạ tầng.

Subdomain giúp mỗi hệ thống có thể vận hành độc lập.

Ví dụ một marketplace có:

example.com – website người mua.

seller.example.com – hệ thống người bán.

admin.example.com – quản trị.

api.example.com – API.

Đây là trường hợp subdomain rất tự nhiên.

Không nên ép toàn bộ thành:

example.com/seller/

example.com/admin/

nếu mỗi phần là một ứng dụng độc lập.

Đây là một điểm khác biệt đáng chú ý.

Google hiện hỗ trợ Site Name ở:

domain level

và:

subdomain level

nhưng không hỗ trợ Site Name riêng cho subdirectory. (developers.google.com)

Ví dụ:

news.example.com

có thể được Google xem như một site-level entity có Site Name riêng.

Trong khi:

example.com/news/

không thể thiết lập một Site Name độc lập ở cấp thư mục.

Điều này có thể hữu ích nếu subdomain thực sự là một sản phẩm hoặc khu vực thương hiệu riêng.

Google hiện xác định favicon ở cấp hostname.

Ví dụ:

example.com

và:

news.example.com

có thể có favicon khác nhau.

Trong khi:

example.com/news/

vẫn sử dụng favicon ở cấp website chính. (developers.google.com)

Đây là một điểm nên cân nhắc nếu muốn tạo nhận diện khá độc lập cho từng hệ thống.

Có thể tạo property riêng để theo dõi subdomain.

Ví dụ:

app.example.com

blog.example.com

Điều này thuận lợi nếu các hệ thống:

  • Có đội SEO riêng.
  • Có traffic riêng.
  • Có mục tiêu khác nhau.

Tuy nhiên, Domain Property trong Search Console cũng có thể giúp theo dõi toàn bộ domain và các subdomain nếu được cấu hình phù hợp.

Ví dụ:

example.com/blog/cach-chon-gach/

có thể dễ dàng link tới:

example.com/gach/

và ngược lại.

Toàn bộ website nằm trong cùng hệ thống navigation và cấu trúc.

Với subdomain, internal link vẫn hoàn toàn có thể thực hiện, nhưng nếu hai hệ thống được vận hành độc lập, việc quản lý liên kết đôi khi phức tạp hơn.

Ví dụ website có:

example.com/san-pham/

example.com/blog/

example.com/tin-tuc/

có thể sử dụng một sitemap index chung.

Nếu dùng nhiều subdomain, mỗi subdomain có thể cần cấu hình sitemap, robots và hệ thống quản trị riêng tùy kiến trúc.

Điều này không phải vấn đề với doanh nghiệp lớn nhưng có thể làm tăng công việc với website nhỏ.

Một website dạng:

example.com/blog/

example.com/shop/

thường dễ theo dõi chung.

Với:

blog.example.com

shop.example.com

có thể phải cấu hình thêm để đảm bảo:

  • Cross-subdomain tracking.
  • Session không bị tách.
  • Cookie đúng phạm vi.
  • Conversion được ghi nhận chính xác.

Hệ thống hiện đại hoàn toàn xử lý được, nhưng cần cấu hình kỹ hơn.

Ví dụ website về xây dựng có:

example.com/vat-lieu/

example.com/thiet-bi/

example.com/kien-thuc/

Cấu trúc này giúp thể hiện rõ các cụm chủ đề trong cùng một website.

Nội dung hỗ trợ và trang thương mại có thể liên kết qua lại tự nhiên.

Đây thường là hướng tốt cho các website muốn phát triển topical coverage rộng trên cùng một thương hiệu.

Không nên nếu không có lý do rõ ràng.

Ví dụ:

gach.example.com

son.example.com

ongnuoc.example.com

trong khi tất cả đều là danh mục sản phẩm của cùng một cửa hàng.

Cấu trúc:

example.com/gach/

example.com/son/

example.com/ong-nuoc/

thường đơn giản hơn.

Không cần biến từng danh mục thành một website kỹ thuật riêng.

Cả hai đều có thể sử dụng.

Ví dụ:

en.example.com

vi.example.com

hoặc:

example.com/en/

example.com/vi/

Google hiện khuyến nghị các URL riêng biệt cho từng phiên bản ngôn ngữ/khu vực và đưa cả subdomain lẫn subdirectory vào các cấu trúc có thể sử dụng. (developers.google.com)

Nếu hệ thống đơn giản, thư mục con thường dễ quản lý hơn.

Nếu từng thị trường có hệ thống độc lập, subdomain có thể phù hợp.

Ví dụ:

us.example.com

uk.example.com

hoặc:

example.com/us/

example.com/uk/

Việc lựa chọn nên dựa vào:

  • Hạ tầng.
  • Đội vận hành.
  • CMS.
  • Mức độ độc lập của từng thị trường.
  • Chiến lược thương hiệu.

Không nên chọn chỉ vì nghĩ một cấu trúc sẽ “SEO mạnh hơn” cấu trúc kia.

Câu trả lời là: tùy ngữ cảnh.

Google cho biết trong hệ thống site diversity, subdomain thường được xem là một phần của root domain, nhưng trong một số trường hợp có thể được xử lý như một site riêng nếu phù hợp. (developers.google.com)

Điều này cho thấy không nên suy nghĩ đơn giản:

“Subdomain luôn là website hoàn toàn độc lập.”

hoặc:

“Subdomain luôn được gộp hoàn toàn với domain chính.”

Cách Google xử lý còn phụ thuộc vào cấu trúc và nội dung thực tế.

Không nên mặc định như vậy.

Ví dụ:

brand.com

đã có rất nhiều backlink.

Sau đó tạo:

blog.brand.com

Không nên cho rằng blog.brand.com sẽ tự động có toàn bộ uy tín SEO của brand.com.

Subdomain mới vẫn cần:

  • Nội dung.
  • Internal link.
  • Backlink.
  • Crawl.
  • Index.

Ngược lại, cũng không nên cho rằng subdomain bị “tách hoàn toàn” và không liên quan gì tới thương hiệu chính.

Cũng không.

Ví dụ:

example.com/blog/

nằm dưới domain chính nhưng nếu:

  • Nội dung kém.
  • Không internal link.
  • Không được crawl.
  • Không có giá trị.

thì không có lý do gì nó tự động xếp hạng tốt.

Cấu trúc URL chỉ là một phần của chiến lược.

Chất lượng nội dung vẫn rất quan trọng.

Không nên thực hiện chỉ vì quan niệm:

“Subdirectory luôn SEO tốt hơn.”

Nếu subdomain hiện tại:

  • Hoạt động tốt.
  • Có traffic.
  • Có backlink.
  • Được index.
  • Kiến trúc hợp lý.

thì migration có thể tạo thêm rủi ro và công việc mà không có lợi ích chắc chắn.

Google nói rõ họ không có ưu tiên xếp hạng giữa hai cấu trúc. (developers.google.com)

Có thể cân nhắc nếu mục tiêu chính là:

  • Đơn giản hóa quản trị.
  • Gộp hai CMS.
  • Xây hệ thống nội dung thống nhất.
  • Giảm chi phí kỹ thuật.
  • Hợp nhất thương hiệu.

Đây là quyết định về kiến trúc và vận hành nhiều hơn là một “thủ thuật SEO”.

Có thể hợp lý khi:

  • Phần đó trở thành một ứng dụng riêng.
  • Cần server khác.
  • Có đội vận hành riêng.
  • Có hệ thống bảo mật riêng.
  • Muốn xây Site Name riêng.
  • Có sản phẩm tương đối độc lập.

Ví dụ:

example.com/app/

phát triển thành một SaaS hoàn chỉnh.

Khi đó:

app.example.com

có thể hợp lý hơn về kiến trúc.

Ví dụ chuyển:

blog.example.com/bai-viet-a

sang:

example.com/blog/bai-viet-a

cần permanent redirect từ URL cũ sang URL mới tương ứng.

Không nên chỉ chuyển homepage:

blog.example.com → example.com/blog/

rồi để toàn bộ bài cũ thành 404.

Mỗi URL quan trọng nên có ánh xạ chính xác.

Nếu chuyển từ subdomain sang subdirectory, canonical trên các trang mới cần trỏ về URL mới.

Ví dụ:

example.com/blog/bai-a

không nên còn canonical về:

blog.example.com/bai-a

Các hệ thống:

  • Sitemap.
  • Internal link.
  • Canonical.
  • Structured data.

đều cần được cập nhật đồng bộ.

Tiêu chí Subdomain Thư mục con
Ví dụ blog.example.com example.com/blog/
Hệ thống độc lập Rất phù hợp Ít phù hợp hơn
Dùng server riêng Dễ Có thể phức tạp hơn
CMS riêng Rất phù hợp Phù hợp nếu tích hợp được
Quản trị SEO chung Cần quản lý thêm Đơn giản hơn
Internal link Có thể dùng tốt Thường dễ hơn
Analytics Có thể cần cấu hình thêm Thường đơn giản
Site Name riêng trên Google Có thể Không
Favicon riêng trên Google Có thể Không
Blog cùng website Có thể Thường phù hợp hơn
App/hệ thống độc lập Rất phù hợp Tùy kiến trúc
Lợi thế ranking mặc định Không Không

Có thể áp dụng quy tắc đơn giản:

Nội dung cùng thương hiệu, cùng website

→ ưu tiên thư mục con.

Ví dụ:

brand.com/blog/

brand.com/tin-tuc/

brand.com/dich-vu/

Hệ thống hoặc sản phẩm độc lập

→ cân nhắc subdomain.

Ví dụ:

app.brand.com

seller.brand.com

support.brand.com

Một cấu trúc hợp lý có thể là:

brand.com/san-pham/

brand.com/danh-muc/

brand.com/tin-tuc/

Trong khi:

seller.brand.com

có thể dành cho người bán.

api.brand.com

dành cho API.

Điều này giúp phần nội dung và thương mại nằm chung một website, còn hệ thống chuyên biệt được tách riêng.

Nếu blog phục vụ SEO và hỗ trợ bán hàng, thường có thể chọn:

brand.com/blog/

hoặc:

brand.com/kien-thuc/

Lợi ích:

  • Dễ xây internal link.
  • Dễ quản lý.
  • Nội dung gắn trực tiếp với thương hiệu.
  • Không phải vận hành thêm một site kỹ thuật.

Chỉ nên dùng blog.brand.com khi có lý do cụ thể về hệ thống hoặc tổ chức.

Trong cách gọi phổ biến, subdomain thường được gọi là:

tên miền phụ.

Ví dụ:

shop.brand.com

Trong khi:

brand.com/shop/

là thư mục con.

Hai cấu trúc không nên nhầm lẫn.

Về mặt DNS, doanh nghiệp có thể tạo rất nhiều subdomain.

Nhưng không nên tạo quá nhiều nếu không cần thiết.

Mỗi subdomain thêm vào có thể kéo theo:

  • DNS.
  • SSL.
  • Tracking.
  • Search Console.
  • Monitoring.
  • Bảo mật.
  • Quản trị.

Kiến trúc càng đơn giản càng dễ duy trì.

Ví dụ:

noithat.brand.com

gach.brand.com

son.brand.com

chỉ để hy vọng SEO từ khóa tốt hơn.

Không cần thiết.

Nếu đây chỉ là các danh mục của cùng website, cấu trúc:

brand.com/noi-that/

brand.com/gach/

brand.com/son/

thường đơn giản và tự nhiên hơn.

Không nên tạo subdomain chỉ như một thủ thuật SEO.

Trước khi quyết định, hãy hỏi:

  • ☐ Nội dung có cùng thương hiệu không?
  • ☐ Có cùng khách hàng không?
  • ☐ Có cùng CMS không?
  • ☐ Có cần server riêng không?
  • ☐ Có cần đăng nhập riêng không?
  • ☐ Có đội vận hành riêng không?
  • ☐ Có cần Site Name riêng không?
  • ☐ Có cần favicon riêng không?
  • ☐ Có cần tách bảo mật không?
  • ☐ Việc tách có làm quản trị phức tạp hơn không?

Nếu phần lớn đều dùng chung, thư mục con thường hợp lý.

Nếu phần lớn cần tách biệt, subdomain đáng cân nhắc.

Có thể ghi nhớ:

Cùng website + cùng nội dung + cùng thương hiệu

→ Thư mục con

Ứng dụng riêng + hệ thống riêng + chức năng độc lập

→ Subdomain

Không nên lựa chọn dựa trên suy nghĩ:

“Cái nào SEO mạnh hơn?”

Google hiện nói rõ họ không có ưu tiên về indexing và ranking giữa subdomain với subdirectory. (developers.google.com)

Subdomain và thư mục con đều là cách tổ chức website hợp lệ.

Subdomain

như:

app.brand.com

phù hợp với những hệ thống có tính độc lập cao, cần server, CMS hoặc cách quản trị riêng.

Thư mục con

như:

brand.com/blog/

phù hợp với nội dung trực tiếp thuộc website chính và thường đơn giản hơn trong việc quản lý nội dung, internal link và SEO.

Google không mặc định ưu tiên subdomain hay thư mục con về xếp hạng.

Vì vậy, nguyên tắc tốt nhất là:

cùng một website thì giữ cấu trúc đơn giản bằng thư mục con; hệ thống thực sự độc lập thì dùng subdomain.

Một kiến trúc website rõ ràng, dễ quản lý và có nội dung chất lượng quan trọng hơn nhiều so với việc cố chọn subdomain hoặc subdirectory chỉ vì một lợi thế SEO được cho là tồn tại.

Tags: subdomain thư mục con subdirectory SEO website cấu trúc URL tên miền SEO subdomain cấu trúc website