Mục lục

URL là địa chỉ của từng trang trên website.

Ví dụ:

example.com/noi-that/sofa/

Một cấu trúc URL tốt cần giúp cả người dùng và công cụ tìm kiếm nhanh chóng hiểu:

  • Trang đang nói về nội dung gì.
  • Trang thuộc khu vực nào của website.
  • Mối quan hệ giữa danh mục và nội dung.
  • Đâu là URL chính cần được sử dụng.

Google hiện khuyến nghị sử dụng cấu trúc URL đơn giản, logic và dễ hiểu đối với con người, đồng thời ưu tiên các từ mô tả thay vì chuỗi ID dài và khó đọc.

Ví dụ:

example.com/noi-that/sofa/

thường hợp lý hơn:

example.com/noi-that-dep-gia-re/sofa-gia-re-noi-that-cao-cap/

URL cần mô tả nội dung, không cần biến thành nơi nhồi từ khóa.

Từ khóa có thể xuất hiện nếu tự nhiên và giúp người dùng hiểu trang.

Nguyên tắc nên là:

Ngắn + rõ nghĩa + đúng nội dung + nhất quán.

Hãy so sánh:

example.com/may-bom-cong-nghiep/

với:

example.com/index.php?id=8372&cat=41&ref=9827

URL đầu tiên giúp người dùng hiểu ngay nội dung.

Google cũng khuyến nghị sử dụng các từ mô tả dễ đọc thay cho những mã ID dài nếu có thể.

Với website doanh nghiệp, URL càng dễ đọc càng thuận lợi cho:

  • Chia sẻ.
  • Internal link.
  • Quản trị.
  • Theo dõi Analytics.
  • Nhận diện nội dung.

Nếu website phục vụ người Việt Nam, slug tiếng Việt không dấu thường là một lựa chọn thực tế.

Ví dụ:

example.com/vat-lieu-xay-dung/

thay vì:

example.com/building-materials/

nếu khách hàng và nội dung đều chủ yếu sử dụng tiếng Việt.

Google khuyến nghị sử dụng ngôn ngữ của chính đối tượng mục tiêu trong URL khi phù hợp.

Về kỹ thuật, URL có thể chứa ký tự ngoài ASCII và được mã hóa theo chuẩn.

Tuy nhiên, với website Việt Nam, sử dụng slug không dấu thường thuận tiện hơn cho:

  • Sao chép URL.
  • Nhập bằng tay.
  • Chia sẻ.
  • Quản trị.
  • Tránh chuỗi mã hóa dài khi URL được hiển thị ở một số hệ thống.

Ví dụ:

example.com/cach-chon-ten-mien/

thường dễ sử dụng hơn URL chứa nhiều ký tự được percent-encode.

Đây là lựa chọn về trải nghiệm và quản trị hơn là một “mẹo SEO”.

Google khuyến nghị sử dụng:

dấu gạch ngang -

để phân tách các từ trong URL.

Ví dụ tốt:

example.com/may-bom-cong-nghiep/

Nên hạn chế:

example.com/may_bom_cong_nghiep/

hoặc:

example.com/maybomcongnghiep/

Google cho biết dấu gạch ngang giúp người dùng và công cụ tìm kiếm nhận diện các khái niệm trong URL rõ hơn, đồng thời không khuyến nghị sử dụng dấu gạch dưới để tách từ.

URL có thể phân biệt chữ hoa và chữ thường tùy máy chủ.

Ví dụ Google có thể xem:

example.com/Sofa/

và:

example.com/sofa/

là hai URL khác nhau.

Google vì vậy khuyến nghị thống nhất cách viết hoa/thường nếu máy chủ cho phép.

Cách đơn giản nhất cho phần lớn website là:

sử dụng toàn bộ chữ thường.

Ví dụ:

example.com/noi-that/sofa/

thay vì:

example.com/Noi-That/Sofa/

Không có một số ký tự chuẩn bắt buộc.

URL nên ngắn đến mức vẫn mô tả được nội dung.

Ví dụ:

example.com/van-bi/

rất rõ ràng.

Không cần:

example.com/danh-muc-san-pham-van-bi-chat-luong-cao/

Ngược lại, cũng không nên rút quá mức thành:

example.com/vb/

nếu người dùng không thể hiểu “vb” là gì.

Mục tiêu là:

ngắn nhưng vẫn có nghĩa.

Ví dụ tiêu đề bài viết:

Cách chọn tên miền ngắn, dễ nhớ và dễ xây dựng thương hiệu

URL không cần phải là:

example.com/cach-chon-ten-mien-ngan-de-nho-va-de-xay-dung-thuong-hieu/

Có thể rút còn:

example.com/cach-chon-ten-mien/

hoặc:

example.com/chon-ten-mien-thuong-hieu/

URL nên đại diện cho chủ đề, không cần sao chép nguyên tiêu đề.

Ví dụ website thương mại điện tử có thể xây:

example.com/thiet-bi-dien/

example.com/thiet-bi-dien/aptomat/

example.com/thiet-bi-dien/aptomat-mpe-mp6-c220/

Nhìn vào URL, người dùng có thể hiểu:

Thiết bị điện → Aptomat → Sản phẩm

Đây là cấu trúc có logic.

Tuy nhiên, không nên tạo phân cấp quá sâu nếu không cần thiết.

Không bắt buộc.

Ví dụ:

example.com/thiet-bi-dien/aptomat/mcb/2p/mpe/mp6-c220/

có thể trở nên quá sâu.

Một cấu trúc gọn hơn:

example.com/aptomat/mp6-c220/

hoặc:

example.com/san-pham/mp6-c220/

có thể dễ quản lý hơn.

Điều quan trọng là URL phải ổn định và người dùng hiểu được nội dung.

Có thể tham khảo:

Danh mục cấp 1

example.com/vat-lieu-xay-dung/

Danh mục cấp 2

example.com/vat-lieu-xay-dung/chong-tham/

Sản phẩm

example.com/chong-tham-kova-ct11a-plus/

hoặc:

example.com/san-pham/chong-tham-kova-ct11a-plus/

Không có một cấu trúc duy nhất phù hợp với mọi website.

Điều quan trọng là thiết kế ngay từ đầu để tránh sau này phải đổi hàng nghìn URL.

Có thể nếu mã/model là một phần quan trọng để nhận diện sản phẩm.

Ví dụ:

example.com/rcbo-mpe-rcbo2-30-232/

hoặc đơn giản:

example.com/rcbo2-30-232/

Mã model giúp URL:

  • Phân biệt sản phẩm.
  • Hạn chế trùng slug.
  • Dễ quản lý catalog.

Nhưng không nên đưa hàng loạt mã nội bộ vô nghĩa mà khách hàng không bao giờ sử dụng.

Có thể sử dụng dạng:

example.com/tin-tuc/ten-mien-la-gi/

hoặc:

example.com/ten-mien-la-gi/

Cả hai đều có thể hoạt động tốt.

Nếu website có nhiều loại nội dung, thư mục giúp tổ chức rõ hơn:

example.com/tu-van/

example.com/tin-tuc/

example.com/thuong-hieu/

example.com/seo-website/

Nếu website nhỏ, cấu trúc phẳng hơn cũng có thể phù hợp.

Ví dụ:

example.com/2026/08/31/cach-chon-ten-mien/

Có thể sử dụng nếu website thực sự cần cấu trúc theo thời gian, chẳng hạn báo chí.

Nhưng với nội dung evergreen, việc đưa ngày vào URL có thể khiến URL:

  • Dài hơn.
  • Tạo cảm giác bài cũ.
  • Khó tái sử dụng lâu dài.

Ví dụ:

example.com/cach-chon-ten-mien/

thường linh hoạt hơn với một bài hướng dẫn lâu dài.

Có thể nếu danh mục ổn định.

Ví dụ:

example.com/seo-website/cau-truc-url-chuan-seo/

Tuy nhiên, hãy cân nhắc:

Nếu sau này đổi bài từ danh mục SEO Website sang Tư vấn Website, URL có phải đổi không?

Nếu cấu trúc URL phụ thuộc quá nhiều vào taxonomy có thể thay đổi, doanh nghiệp sẽ phải xử lý migration nhiều hơn.

Một URL đã được:

  • Google index.
  • Chia sẻ.
  • Có backlink.
  • Được khách hàng bookmark.

thì không nên thay đổi chỉ vì muốn chỉnh một vài từ.

Ví dụ:

example.com/cach-chon-domain/

đã hoạt động tốt.

Không cần đổi thành:

example.com/cach-chon-ten-mien-chuan-seo/

chỉ để bổ sung từ khóa.

Nếu bắt buộc đổi URL, cần redirect URL cũ tới URL mới tương ứng.

Ví dụ đổi:

example.com/domain-la-gi/

sang:

example.com/ten-mien-la-gi/

cần redirect URL cũ tới URL mới.

Google khuyến nghị lập ánh xạ URL cũ–mới và dùng redirect khi thực hiện thay đổi URL; đồng thời tránh redirect nhiều URL không liên quan về một trang duy nhất như homepage.

Đừng:

xóa URL cũ → để 404 → tạo URL mới

nếu nội dung chỉ đơn giản được chuyển sang địa chỉ khác.

Ví dụ:

/bai-viet-a/
/bai-viet-b/
/bai-viet-c/

đều redirect về:

/

chỉ vì bạn đã thay cấu trúc website.

Google cảnh báo việc redirect nhiều URL cũ không liên quan tới một trang đích không phù hợp có thể gây nhầm lẫn cho người dùng và có thể bị xử lý như soft 404.

Mỗi URL cũ nên chuyển tới nội dung mới tương ứng nhất.

Ví dụ:

example.com/sofa?session=8372&utm_internal=abc&sort=default&id=72

nếu nhiều tham số không thay đổi nội dung thật sự thì có thể làm hệ thống URL phức tạp hơn.

Google khuyến nghị dùng ít tham số nhất có thể và loại bỏ các tham số không cần thiết.

Điều này đặc biệt quan trọng với:

  • Ecommerce.
  • Filter.
  • Sort.
  • Tracking.
  • Faceted navigation.

Không.

Ví dụ:

example.com/danh-muc?color=red&size=xl

hoàn toàn có thể là một URL hợp lệ.

Vấn đề xuất hiện khi website tạo ra hàng triệu tổ hợp tham số gần giống nhau.

Google cảnh báo các URL quá phức tạp và nhiều tổ hợp filter có thể khiến crawler phải xử lý rất nhiều URL giống hoặc gần giống nhau.

Vì vậy cần quản trị tốt:

  • Filter.
  • Sort.
  • Session ID.
  • Tracking parameter.

Ví dụ:

example.com/product?sessionid=928374928374

có thể tạo rất nhiều URL cho cùng một nội dung.

Điều này khiến:

  • Dữ liệu phân tán.
  • Crawl phức tạp.
  • Canonical khó quản lý.
  • Backlink có thể trỏ về nhiều phiên bản.

Nếu có thể, session nên được quản lý bằng phương pháp khác thay vì trở thành một phần cố định của URL.

Website thương mại điện tử thường có filter:

  • Thương hiệu.
  • Giá.
  • Màu.
  • Kích thước.
  • Công suất.
  • Chất liệu.

Ví dụ người dùng có thể tạo:

/den-led?brand=mpe&power=9w&color=warm&sort=price

Nếu mọi tổ hợp đều tạo URL indexable, website có thể sinh ra số lượng trang rất lớn.

Không nhất thiết mọi filter đều cần SEO.

Nên xác định:

Filter nào có nhu cầu tìm kiếm thực sự → có thể xây landing page riêng.

Filter chỉ phục vụ trải nghiệm → không cần trở thành một trang SEO độc lập.

Có thể.

Dấu ? dùng để bắt đầu query parameters và hoàn toàn hợp lệ.

Không cần ép tất cả URL động thành URL tĩnh chỉ vì lo SEO.

Quan trọng là:

  • URL crawl được.
  • Không tạo vô hạn biến thể.
  • Canonical rõ.
  • Nội dung khác nhau thực sự khi cần.

Khi cùng một nội dung có thể truy cập qua nhiều URL, doanh nghiệp cần xác định đâu là phiên bản đại diện.

Ví dụ:

example.com/sofa/

example.com/sofa/?sort=price

example.com/sofa/?utm_source=facebook

Nội dung cốt lõi có thể giống nhau.

Google gọi quá trình chọn URL đại diện là canonicalization. Google sử dụng nhiều tín hiệu như redirect, URL trong sitemap và rel="canonical" để xác định URL đại diện.

Canonical là một tín hiệu, không phải mệnh lệnh tuyệt đối.

Google có thể lựa chọn canonical khác nếu hệ thống nhận thấy URL khác phù hợp hơn.

Do đó, website nên đồng bộ:

  • Canonical.
  • Internal link.
  • Sitemap.
  • Redirect.
  • HTTPS.
  • www hoặc không www.

Không nên canonical một URL nhưng mọi internal link lại trỏ sang URL khác.

Ví dụ website chính là:

https://example.com/

thì:

http://example.com/

nên redirect sang HTTPS.

Tương tự, nếu chọn không www:

https://www.example.com/

nên redirect về:

https://example.com/

Việc tồn tại nhiều phiên bản cùng nội dung có thể khiến canonicalization phức tạp hơn. Google xem HTTP/HTTPS là một trong những nguyên nhân phổ biến tạo URL trùng lặp.

Nếu URL chuẩn là:

https://example.com/noi-that/

internal link nên trỏ trực tiếp tới URL đó.

Không nên liên kết qua:

http://example.com/noi-that

rồi redirect sang HTTPS.

Hoặc:

www.example.com/noi-that

rồi redirect sang không www.

Link nội bộ càng sạch, website càng dễ quản trị.

Sitemap nên chứa những URL bạn muốn Google index.

Ví dụ nếu canonical là:

https://example.com/sofa/

thì sitemap không nên đồng thời chứa:

https://example.com/sofa/?sort=price

Google xem việc URL xuất hiện trong sitemap là một trong những tín hiệu để lựa chọn canonical.

Ví dụ:

example.com/ten-mien-la-gi.html

vẫn hoàn toàn có thể hoạt động.

Không có lý do bắt buộc phải đổi sang:

example.com/ten-mien-la-gi/

chỉ vì SEO.

Với website mới, dạng không có .html thường:

  • Gọn hơn.
  • Linh hoạt hơn về công nghệ.
  • Dễ thay CMS sau này.

Nhưng với website cũ đã có hàng nghìn URL .html, không nên migration chỉ vì muốn URL nhìn đẹp hơn.

Ví dụ:

example.com/12345/van-bi-dn20/

không nhất thiết xấu.

ID có thể giúp hệ thống:

  • Đảm bảo URL duy nhất.
  • Quản trị database.
  • Tránh trùng slug.

Nhưng nếu ID không cần thiết, URL:

example.com/van-bi-dn20/

thường dễ đọc hơn.

Google khuyến nghị sử dụng các từ mô tả thay cho ID dài khi có thể.

Ví dụ bài viết có URL:

example.com/cach-chon-ten-mien/

Sau đó đổi title từ:

Cách chọn tên miền

thành:

10 cách chọn tên miền đẹp cho doanh nghiệp

Không cần đổi URL thành:

example.com/10-cach-chon-ten-mien-dep-cho-doanh-nghiep/

URL nên ổn định lâu dài.

Title có thể thay đổi theo nội dung, URL không nhất thiết phải chạy theo từng lần chỉnh tiêu đề.

Không cần áp dụng máy móc.

Ví dụ:

example.com/cach-chon-ten-mien/

rất tự nhiên.

Không nhất thiết phải rút thành:

example.com/chon-ten-mien/

chỉ vì muốn bỏ chữ “cách”.

Mục tiêu là URL:

ngắn nhưng dễ hiểu.

Không cần ám ảnh việc loại mọi từ được cho là “stop word”.

Có thể nếu hệ thống taxonomy ổn định.

Ví dụ:

Trang chủ → Vật liệu → Chống thấm → KOVA CT-11A

URL có thể:

example.com/vat-lieu/chong-tham/kova-ct11a/

Nhưng nếu danh mục sản phẩm có thể thay đổi thường xuyên, việc đưa toàn bộ breadcrumb vào URL có thể làm migration sau này phức tạp.

Breadcrumb và URL không bắt buộc phải giống tuyệt đối.

Không nên đánh giá chỉ theo số dấu /.

Một website có URL:

example.com/a/b/c/

không tự động SEO kém hơn:

example.com/c/

Quan trọng hơn là:

  • Trang có dễ tìm qua navigation không.
  • Internal link có tốt không.
  • Cấu trúc website có logic không.

Không cần cố làm URL thật phẳng nếu việc phân cấp giúp website dễ quản lý hơn.

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

Có danh mục:

example.com/den-led/rpl-9w/

Không có danh mục:

example.com/rpl-9w/

Nếu sản phẩm thường xuyên đổi danh mục, URL không chứa danh mục có thể ổn định hơn.

Nếu taxonomy rất ổn định, đưa danh mục vào có thể giúp người dùng hiểu cấu trúc.

Hãy ưu tiên sự ổn định dài hạn.

Ví dụ một sản phẩm vừa thuộc:

Đèn LED

vừa thuộc:

Đèn âm trần

Không nên tạo:

example.com/den-led/san-pham-a/

và:

example.com/den-am-tran/san-pham-a/

với nội dung giống hệt nhau nếu không cần thiết.

Nên có một URL sản phẩm chính và dùng internal link từ nhiều danh mục tới URL đó.

Điều này giúp tránh tạo nhiều URL cho cùng một sản phẩm.

Nếu sản phẩm tạm hết hàng nhưng có khả năng bán lại:

  • Giữ URL.
  • Thông báo hết hàng.
  • Hiển thị sản phẩm thay thế.

Nếu sản phẩm ngừng vĩnh viễn nhưng có sản phẩm thay thế rất tương đồng, có thể cân nhắc redirect tới trang phù hợp.

Nếu không có nội dung thay thế hợp lý, trả 404 hoặc 410 có thể phù hợp hơn việc redirect vô lý về trang chủ.

Không nên giữ hàng nghìn URL rác chỉ để “giữ SEO”.

Tên danh mục có thể được chỉnh trong giao diện nhưng URL không nhất thiết phải thay đổi theo.

Ví dụ:

URL:

example.com/thiet-bi-dien/

Tên hiển thị sau này đổi thành:

Thiết bị điện & chiếu sáng

không nhất thiết phải đổi URL.

Càng ít migration không cần thiết càng tốt.

Ví dụ:

example.com/vi/

example.com/en/

hoặc sử dụng subdomain phù hợp.

Google khuyến nghị sử dụng cấu trúc URL riêng biệt cho các phiên bản khu vực/ngôn ngữ để giúp hệ thống hiểu đối tượng mục tiêu.

Nếu dùng thư mục:

example.com/vi/san-pham/

example.com/en/products/

cần kết hợp với hreflang khi phù hợp.

Ví dụ:

example.com/#/san-pham

Google hiện khuyến nghị không sử dụng URL fragment để thay đổi nội dung trang mà bạn muốn Search hiểu và crawl; với website JavaScript, nên sử dụng History API phù hợp.

Điều này đặc biệt đáng chú ý khi xây:

  • SPA.
  • Web app.
  • Filter.
  • Navigation bằng JavaScript.

Ví dụ:

Trang chủ

example.com/

Dịch vụ

example.com/dich-vu/

Dịch vụ cụ thể

example.com/dich-vu/thiet-ke-noi-that/

Tin tức

example.com/tin-tuc/

Bài viết

example.com/tin-tuc/cach-chon-noi-that/

Cấu trúc đơn giản, dễ mở rộng và dễ hiểu.

Ví dụ:

Danh mục

example.com/den-led/

Danh mục con

example.com/den-led/den-panel/

Sản phẩm

example.com/den-panel-rpl-9w/

Thương hiệu

example.com/thuong-hieu/mpe/

Bài tư vấn

example.com/tu-van/cach-chon-den-led/

Sản phẩm không nhất thiết phải nằm sâu trong toàn bộ cây danh mục nếu muốn giữ URL ổn định.

Ví dụ:

Chuyên mục

example.com/seo-website/

Bài viết

example.com/seo-website/cau-truc-url-chuan-seo/

Hoặc cấu trúc phẳng:

example.com/cau-truc-url-chuan-seo/

Nếu website có nhiều chuyên mục và hàng nghìn bài, cách đầu tiên có thể giúp quản lý rõ hơn.

Tiêu chí Nên làm
URL dễ đọc Có
Dùng từ mô tả Có
Dùng chữ thường Có
Dùng dấu - giữa các từ Có
Hạn chế tham số Có
Không nhồi từ khóa Có
Không quá dài Có
Cấu trúc danh mục logic Có
Một nội dung có một URL chính Có
Canonical thống nhất Có
Internal link dùng URL chuẩn Có
Sitemap dùng URL canonical Có
HTTPS thống nhất Có
URL cũ redirect khi thay đổi Có

Nên tránh:

  • URL chứa ID dài không cần thiết.
  • Dùng dấu gạch dưới.
  • Chữ hoa và chữ thường lẫn lộn.
  • Nhồi nhiều từ khóa.
  • Thay URL liên tục.
  • Đưa ngày tháng vào mọi bài.
  • Tạo một sản phẩm ở nhiều URL.
  • Cho mọi bộ lọc được index.
  • Tạo hàng triệu URL tham số.
  • Canonical không thống nhất.
  • Redirect tất cả trang cũ về homepage.
  • Sitemap chứa URL không canonical.

Có thể ghi nhớ:

Tên miền

  •  

Danh mục hợp lý

  •  

Slug ngắn, mô tả

=

URL dễ hiểu

Ví dụ:

brand.com/noi-that/sofa-go/

thay vì:

brand.com/index.php?id=3927&cat=94&keyword=sofa_go_noi_that

Google cũng khuyến nghị cấu trúc URL đơn giản và dễ hiểu với con người.

Không nên thực hiện chỉ vì muốn URL đẹp hơn.

Nếu website hiện đã:

  • Có traffic.
  • Có backlink.
  • Có index.
  • URL vẫn hoạt động bình thường.

thì việc đổi hàng nghìn URL có thể tạo ra một migration lớn.

Chỉ nên thay khi có lợi ích rõ ràng như:

  • URL hiện tại quá lỗi.
  • Hệ thống tạo vô hạn URL.
  • Thay đổi kiến trúc website.
  • Chuyển CMS.
  • Rebrand.

Nếu thay, cần lập URL mapping và redirect đầy đủ.

URL chuẩn SEO không phải URL được tối ưu để chứa thật nhiều từ khóa.

Một URL tốt cần trả lời được:

Người dùng nhìn vào có hiểu trang này nói về gì không?

URL này có thể giữ ổn định trong nhiều năm không?

Có chỉ một phiên bản chính của nội dung không?

Nếu cả ba câu trả lời đều là có, cấu trúc URL thường đã đi đúng hướng.

Cấu trúc URL chuẩn SEO nên được xây dựng theo các nguyên tắc:

đơn giản – dễ đọc – mô tả đúng nội dung – sử dụng dấu gạch ngang – hạn chế tham số – nhất quán – ổn định lâu dài.

Google hiện khuyến nghị URL có cấu trúc logic, dễ hiểu với con người, sử dụng từ mô tả và hạn chế các tham số không cần thiết.

Với website doanh nghiệp hoặc thương mại điện tử, điều quan trọng nhất là thiết kế cấu trúc URL ngay từ đầu để hạn chế việc phải thay đổi hàng nghìn đường dẫn sau này.

Một URL tốt không chỉ hỗ trợ SEO mà còn giúp:

người dùng dễ hiểu – đội nội dung dễ quản lý – hệ thống dễ mở rộng – backlink và dữ liệu được duy trì ổn định trong nhiều năm.

Tags: cấu trúc URL chuẩn SEO URL SEO slug chuẩn SEO cấu trúc website tối ưu URL SEO website URL sản phẩm URL danh mục