Cách tạo danh mục dự án cho website bất động sản chuẩn UX và SEO

Khi website chỉ có 5–10 dự án, bạn có thể đưa tất cả vào một trang và người dùng vẫn tìm được thứ họ cần. Nhưng khi dữ liệu tăng lên 100, 500 hoặc hàng nghìn dự án, cách tổ chức danh mục bắt đầu quyết định trực tiếp tới khả năng tìm kiếm, SEO và quản trị website.

Một cấu trúc không tốt thường tạo ra hai vấn đề cùng lúc: khách không biết nên tìm dự án ở đâu, còn Google lại gặp quá nhiều URL danh sách và bộ lọc gần giống nhau.

Do đó, xây danh mục dự án không đơn giản là tạo các mục “Căn hộ”, “Đất nền”, “Hà Nội”, “TP.HCM”. Bạn cần xác định rõ đâu là taxonomy dùng để tổ chức dữ liệu, đâu là filter chỉ phục vụ thao tác, đâu là landing/category có giá trị SEO và đâu là URL không nên để Google crawl vô hạn.

Trong bài này, Bdsweb hướng dẫn cách xây hệ thống danh mục dự án theo hướng dễ tìm – dễ lọc – dễ mở rộng – dễ quản trị – kiểm soát SEO tốt. Nếu đang xây một website bất động sản có nhiều dự án và sản phẩm, đây là phần nên được thiết kế ngay từ kiến trúc dữ liệu thay vì xử lý sau khi website đã phát sinh hàng nghìn URL.

Danh mục dự án là gì?

Danh mục dự án là trang tập hợp nhiều dự án có chung một tiêu chí có ý nghĩa với người dùng, chẳng hạn:

• Dự án tại Hà Nội;
• Dự án căn hộ;
• Dự án đang mở bán;
• Dự án nghỉ dưỡng;
• Dự án tại Hà Đông.

Danh mục thường đóng vai trò hub điều hướng:

Trang chủ / menu → danh mục → dự án → CTA / sản phẩm.

Nó khác với:

• Trang dự án: mô tả một dự án cụ thể;
• Bộ lọc: công cụ thu hẹp kết quả theo điều kiện;
• Trang tìm kiếm: kết quả theo truy vấn người dùng;
• Landing page: trang có intent hoặc chiến dịch riêng.

1. Phân biệt Taxonomy, Attribute và Filter trước khi xây danh mục

Đây là bước quan trọng nhất vì rất nhiều website đang biến mọi thuộc tính thành một danh mục.

Taxonomy

Là cách phân nhóm tương đối ổn định và có ý nghĩa điều hướng.

Ví dụ:

• Khu vực;
• Loại hình dự án;
• Chủ đầu tư nếu website có nhu cầu rõ;
• Trạng thái dự án trong một số mô hình.

Attribute

Là thuộc tính của từng dự án:

• Khoảng giá;
• Diện tích;
• Số phòng ngủ;
• Pháp lý;
• Tiến độ;
• Mật độ;
• Năm bàn giao.

Filter

Là giao diện cho phép người dùng dùng taxonomy/attribute để thu hẹp dữ liệu.

Ví dụ:

Hà Nội + Căn hộ + 3–5 tỷ + Đang mở bán.

Không phải tổ hợp filter nào cũng cần trở thành một danh mục SEO.

Đây là nguyên tắc giúp website tránh tình trạng:

100 dự án → 20.000 URL lọc.

2. Danh mục nên phản ánh cách người mua tìm dự án

Không nên xây taxonomy theo cấu trúc phòng ban hoặc cách doanh nghiệp gọi dữ liệu nội bộ.

Hãy bắt đầu từ hành vi tìm kiếm.

Người mua BĐS thường thu hẹp lựa chọn theo các lớp:

Lớp	Ví dụ
Vị trí	Hà Nội → Hà Đông
Loại hình	Căn hộ → Nhà phố → Đất nền
Ngân sách	2–4 tỷ
Nhu cầu	Mua ở / đầu tư
Trạng thái	Đang mở bán / đã bàn giao
Thuộc tính sâu	2PN, diện tích, pháp lý...

Trong đó, những lớp có nhu cầu ổn định và đủ dữ liệu mới nên được cân nhắc thành category/hub riêng.

3. Đừng tạo một danh mục chỉ vì CMS cho phép

Một lỗi phổ biến là:

• Thêm dự án nào cũng tạo category mới;
• Thêm quận mới cũng tạo category;
• Mỗi mức giá có một category;
• Mỗi trạng thái lại một URL;
• Mỗi tổ hợp lại sinh thêm landing page.

Kết quả là rất nhiều trang chỉ có 1–2 dự án hoặc gần như giống nhau.

Trước khi tạo một category, nên hỏi bốn câu:

1. Người dùng có nhu cầu duyệt nhóm này không?
2. Website có đủ dự án để duy trì nhóm này không?
3. Nhóm này có intent khác nhóm đang có không?
4. Trang này có thể cung cấp giá trị ngoài một danh sách card không?

Nếu cả bốn câu đều yếu, có thể chỉ cần filter thay vì category.

4. Không có số lượng dự án tối thiểu cố định cho một danh mục

Không nên đặt một quy tắc như:

“Phải có ít nhất 5 hoặc 10 dự án mới tạo category.”

Một category có 3 dự án nhưng đáp ứng một nhu cầu rất rõ vẫn có thể hữu ích. Ngược lại, category có 50 dự án nhưng chỉ khác danh mục khác ở một thuộc tính nhỏ chưa chắc cần thiết.

Nên đánh giá tổng thể:

• Search Intent;
• Inventory hiện tại;
• Khả năng bổ sung dữ liệu;
• Giá trị điều hướng;
• Mức độ khác biệt nội dung;
• Vai trò trong kiến trúc website.

5. Một dự án có thể thuộc nhiều taxonomy mà không cần nhiều URL chi tiết

Ví dụ dự án ABC có thể đồng thời là:

• Căn hộ;
• Hà Nội;
• Hà Đông;
• Đang mở bán.

Nó hoàn toàn có thể xuất hiện trong nhiều trang danh mục tương ứng.

Nhưng trang chi tiết vẫn nên có một URL chính:

/du-an/abc-residence/

thay vì tạo:

/can-ho/abc-residence/
/ha-noi/abc-residence/
/dang-mo-ban/abc-residence/

với cùng một nội dung.

Điểm quan trọng là phân loại dữ liệu nhiều chiều nhưng URL entity vẫn ổn định.

6. Mô hình 1: Danh mục theo khu vực

Đây thường là lớp taxonomy quan trọng vì vị trí có ảnh hưởng trực tiếp đến quyết định BĐS.

Ví dụ:

/du-an/ha-noi/
/du-an/ha-noi/ha-dong/
/du-an/ha-noi/nam-tu-liem/

Cấu trúc có thể đi theo:

Tỉnh/TP → Quận/Huyện → Phường/Xã

nhưng không nhất thiết website phải tạo trang cho mọi cấp địa giới.

Chỉ nên tạo URL khi trang đó thực sự có:

• Dự án;
• Nhu cầu điều hướng;
• Nội dung riêng;
• Internal link hợp lý.

7. Mô hình 2: Danh mục theo loại hình

Ví dụ:

/du-an/can-ho/
/du-an/nha-pho/
/du-an/biet-thu/
/du-an/dat-nen/

Mô hình này phù hợp với sàn hoặc portal có nhiều loại sản phẩm.

Taxonomy loại hình cần được chuẩn hóa ngay từ đầu.

Không nên có cùng lúc:

• Căn hộ;
• Chung cư;
• Căn hộ chung cư;
• Căn hộ cao cấp;

nếu các khái niệm đang được dùng lẫn lộn.

Hãy xác định:

• Đâu là loại hình chính;
• Đâu là phân khúc;
• Đâu chỉ là tag/attribute.

8. Mô hình 3: Kết hợp khu vực + loại hình

Ví dụ:

/du-an/ha-noi/can-ho/
/du-an/ha-noi/nha-pho/

Đây là cấu trúc có thể rất hữu ích khi website có inventory lớn và người dùng thực sự tìm theo hai chiều này.

Tuy nhiên, nếu bạn có:

• 30 tỉnh;
• 10 loại hình;

thì lý thuyết có thể phát sinh 300 tổ hợp.

Nếu chỉ 20 tổ hợp có dự án thực tế, đừng tự động xuất bản cả 300 URL.

Category nên được tạo từ dữ liệu và nhu cầu thực, không phải từ phép nhân taxonomy.

9. Trạng thái dự án: Category hay Filter?

Các trạng thái như:

• Sắp mở bán;
• Đang mở bán;
• Đang xây dựng;
• Đã bàn giao;

có thể được triển khai theo hai cách.

Làm filter

Phù hợp nếu mục đích chủ yếu là giúp khách lọc nhanh.

Làm category/landing

Phù hợp nếu:

• Có nhu cầu tìm kiếm rõ;
• Có đủ inventory;
• Có nội dung riêng;
• Trang đóng vai trò chiến dịch hoặc hub.

Không nên mặc định mọi giá trị taxonomy đều được index.

10. Có nên tạo danh mục theo mức giá?

Khoảng giá thường phù hợp với filter hơn taxonomy cố định vì giá thay đổi theo thời gian.

Ví dụ:

• Dưới 2 tỷ;
• 2–4 tỷ;
• 4–7 tỷ.

Nếu doanh nghiệp muốn SEO một intent thực sự như:

“Dự án căn hộ dưới 3 tỷ tại Hà Nội”

thì có thể xây landing page riêng có quản trị nội dung và query dữ liệu động.

Nhưng đừng để mọi khoảng giá được bộ lọc tạo thành URL indexable tự động.

11. Category SEO và Filter URL là hai lớp khác nhau

Đây là một trong những điểm cần xác định rõ nhất trong kiến trúc.

Category SEO	Filter URL
Được tạo có chủ đích	Phát sinh theo thao tác
Có Search Intent rõ	Chủ yếu phục vụ UX
Title/H1/nội dung riêng	Có thể không có nội dung riêng
Internal link có chủ đích	Có thể sinh hàng nghìn tổ hợp
Thường cân nhắc index	Phần lớn cần kiểm soát crawl/index

Google hiện cảnh báo faceted navigation dùng URL parameter có thể tạo ra gần như vô hạn URL, dẫn tới overcrawling và làm chậm quá trình phát hiện URL quan trọng.

Vì vậy website BĐS cần xác định trước:

Filter nào chỉ dùng cho UX và tổ hợp nào được nâng thành landing/category SEO.

12. Cấu trúc URL danh mục nên ổn định và có logic

Một cấu trúc dễ hiểu có thể là:

/du-an/
/du-an/ha-noi/
/du-an/ha-noi/ha-dong/

hoặc:

/du-an/
/du-an/can-ho/
/du-an/can-ho/ha-noi/

Không có một cấu trúc duy nhất bắt buộc.

Điều quan trọng là:

• Nhất quán;
• Không đổi thứ tự taxonomy tùy ý;
• Không tạo nhiều URL cho cùng một danh mục;
• Không nhồi keyword;
• Không để filter tạo đường dẫn vô hạn.

Nếu filter được mã hóa trực tiếp trong URL path, Google hiện khuyến nghị thứ tự filter phải nhất quán và không xuất hiện filter trùng lặp trong cùng URL.

13. Thiết kế trang danh mục theo nhiệm vụ người dùng

Khi vào danh mục, khách thường muốn trả lời ba câu hỏi:

1. Có bao nhiêu lựa chọn phù hợp?
2. Khác nhau ở đâu?
3. Làm thế nào thu hẹp nhanh hơn?

Do đó, một trang category tốt thường cần:

• H1;
• Giới thiệu ngắn;
• Số lượng kết quả;
• Filter;
• Sort;
• Danh sách/card dự án;
• Pagination hoặc cơ chế xem thêm;
• Nội dung hỗ trợ khi thực sự cần;
• Internal link.

Không cần chèn mọi module website vào trang danh mục.

14. Phần đầu trang danh mục nên hiển thị gì?

Màn hình đầu nên giúp người dùng hiểu:

• Họ đang xem nhóm nào;
• Phạm vi khu vực/loại hình;
• Có bao nhiêu dự án;
• Cách thu hẹp kết quả.

Ví dụ:

H1: Dự án căn hộ tại Hà Nội

32 dự án đang được hiển thị

[Khu vực] [Khoảng giá] [Trạng thái] [Lọc thêm]

Không nên đặt một đoạn giới thiệu 800 từ trước danh sách khiến người dùng phải cuộn rất lâu mới thấy dự án.

15. Nội dung SEO trên category không cần đạt một số từ cố định

Không có quy tắc category phải có 200, 500 hay 1.000 từ mới SEO được.

Nội dung nên giải quyết phần mà danh sách card không thể tự trả lời:

• Nhóm dự án này có đặc điểm gì?
• Khu vực gồm những phân vùng nào?
• Nên chọn dự án theo tiêu chí gì?
• Những category con quan trọng nào?
• Dữ liệu được cập nhật ra sao?

Nếu 120 từ đã trả lời đủ thì không cần kéo thành 800 từ. Nếu category phức tạp, có thể cần nhiều hơn.

16. Card dự án nên giúp so sánh, không cố hiển thị toàn bộ dữ liệu

Card là công cụ quyết định nhanh.

Một card thường có thể gồm:

• Ảnh đại diện;
• Tên dự án;
• Khu vực;
• Loại hình;
• Khoảng giá nếu có dữ liệu đáng tin;
• Một hoặc hai thông tin quan trọng;
• Trạng thái;
• Link xem chi tiết.

Không nên đưa:

• Toàn bộ tiện ích;
• Đoạn mô tả dài;
• 10 thông số;
• Nhiều CTA cạnh tranh;

vào từng card.

Mục tiêu của card là giúp người dùng trả lời:

“Dự án này có đáng để tôi mở xem chi tiết không?”

17. Trạng thái trên card phải được chuẩn hóa

Không nên để editor tự nhập:

• Đang bán;
• Mở bán;
• Đang mở;
• Đang triển khai;
• Sale.

Hãy xây taxonomy/enum rõ:

• Sắp mở bán;
• Đang mở bán;
• Đang xây dựng;
• Đã bàn giao;
• Tạm ngừng nếu nghiệp vụ cần.

Việc chuẩn hóa này giúp:

• Lọc chính xác;
• Hiển thị nhất quán;
• Báo cáo;
• SEO landing;
• Automation sau này.

18. Sort khác Filter và thường không cần index

Sort chỉ thay đổi thứ tự cùng một tập kết quả.

Ví dụ:

• Mới cập nhật;
• Giá thấp → cao;
• Giá cao → thấp;
• Tên A–Z.

Nếu URL:

/du-an/ha-noi/?sort=price-asc

chỉ là cùng danh sách nhưng đổi thứ tự, thường không có lý do SEO mạnh để tạo một trang indexable riêng.

Google cũng khuyến nghị tránh index các URL chỉ thay đổi filter hoặc thứ tự sắp xếp của cùng danh sách.

19. Bộ lọc nên dựa trên dữ liệu sạch

Filter tốt không bắt đầu từ giao diện.

Nó bắt đầu từ CMS.

Ví dụ nếu diện tích được nhập:

• 70m²;
• 70 m2;
• Khoảng 70;
• 70;

thì hệ thống khó lọc số chính xác.

Các field dùng filter nên được lưu có cấu trúc:

area_min = 65
area_max = 72
price_min = ...
price_max = ...
property_type_id = ...
district_id = ...
status_id = ...

Không nên parse từ đoạn mô tả khi người dùng thực hiện lọc.

Cách thiết kế toàn bộ filter đã được tách riêng tại bài thiết lập bộ lọc tìm kiếm nâng cao cho dự án BĐS.

20. Zero-result: không để khách rơi vào ngõ cụt

Nếu người dùng chọn:

Hà Đông + Biệt thự + dưới 2 tỷ

và website không có kết quả, đừng chỉ hiển thị:

“Không tìm thấy dữ liệu.”

Giao diện có thể gợi ý:

• Xóa mức giá;
• Mở rộng sang khu vực lân cận;
• Xem loại hình tương tự;
• Xóa toàn bộ bộ lọc;
• Nhận tư vấn tìm dự án phù hợp.

Zero-result UX và HTTP/SEO của URL filter là hai vấn đề khác nhau. Với những facet URL được cho phép crawl, Google hiện khuyến nghị URL có tổ hợp vô nghĩa hoặc không có kết quả nên phản hồi HTTP 404 thay vì tạo vô số trang rỗng.

21. Pagination, Load More hay Infinite Scroll?

Trang category có nhiều dự án không nên tải toàn bộ một lần.

Phương án	Ưu điểm	Điểm cần lưu ý
Pagination	Rõ vị trí, dễ quay lại	Cần URL từng trang
Load More	Thân thiện mobile	Cần cơ chế crawl phía sau
Infinite Scroll	Duyệt liên tục	Dễ mất vị trí, SEO phức tạp hơn

Google cho biết crawler thường khám phá URL từ thuộc tính href của thẻ và không “click” nút như người dùng. Vì vậy Load More/Infinite Scroll muốn đảm bảo khả năng discovery cần có URL phân trang có thể crawl phía sau.

Phần này đã có bài chuyên sâu tại hướng dẫn phân trang danh sách dự án BĐS.

22. Mỗi trang pagination nên có URL riêng

Ví dụ:

/du-an/ha-noi/
/du-an/ha-noi/?page=2
/du-an/ha-noi/?page=3

hoặc:

/du-an/ha-noi/page/2/

Google hiện khuyến nghị mỗi page trong sequence có URL riêng và không canonical tất cả trang 2, 3, 4 về trang đầu; mỗi page nên có canonical phù hợp với chính nó.

Đây là điểm rất dễ làm sai ở category BĐS lớn.

23. Không cần dùng rel="next" và rel="prev" cho Google

Nhiều tài liệu pagination cũ vẫn hướng dẫn:

Google hiện cho biết họ không còn sử dụng hai tín hiệu này để nhận diện chuỗi phân trang, dù các công cụ tìm kiếm khác vẫn có thể sử dụng chúng.

Điều quan trọng hơn là:

• URL riêng;
• Link HTML crawlable;
• Canonical đúng;
• Không tạo biến thể filter/sort vô hạn.

24. Breadcrumb giúp người dùng hiểu đang ở lớp nào

Ví dụ:

Trang chủ
→ Dự án
→ Hà Nội
→ Hà Đông

Breadcrumb vừa giúp điều hướng vừa thể hiện vị trí của page trong hierarchy.

Google hiện hỗ trợ BreadcrumbList structured data và mô tả breadcrumb như một cách thể hiện vị trí của trang trong hệ thống phân cấp website.

Với website BĐS nhiều chiều taxonomy, breadcrumb nên đại diện một đường hierarchy rõ ràng thay vì cố liệt kê mọi tag của dự án.

25. Internal link của category nên đi hai chiều

Category → trang con

Link tới:

• Dự án;
• Category con;
• Khu vực quan trọng;
• Bài hướng dẫn liên quan.

Trang khác → category

Có thể nhận link từ:

• Trang chủ;
• Menu;
• Blog;
• Trang dự án;
• Category cha;
• Footer có chọn lọc.

Ví dụ một bài “Kinh nghiệm mua căn hộ Hà Đông” có thể dẫn người đọc tới danh mục “Dự án căn hộ Hà Đông” nếu đó là bước tiếp theo tự nhiên.

Nhờ vậy category không trở thành một URL tồn tại chỉ trong sitemap.

26. Category có thể đóng vai trò hub SEO như thế nào?

Một category tốt không chỉ liệt kê project.

Nó có thể giúp người dùng khám phá:

• Phân khu;
• Loại hình con;
• Phân khúc;
• Dự án nổi bật;
• Bài tư vấn;
• Category liên quan.

Ví dụ:

Dự án Hà Nội

có thể dẫn tới:

• Dự án Hà Đông;
• Dự án Nam Từ Liêm;
• Căn hộ Hà Nội;
• Nhà phố Hà Nội;
• Các dự án cụ thể.

Đây là cách category góp phần vào cấu trúc website bất động sản thay vì chỉ là trang kết quả.

27. Không phải mọi category đều cần FAQ

Bài cũ thường đưa FAQ thành một thành phần mặc định.

Thực tế, FAQ chỉ nên dùng khi người dùng có những câu hỏi lặp lại mà phần danh sách chưa giải quyết.

Ví dụ:

• Dự án nào đang mở bán tại Hà Đông?
• Có dự án nào đã bàn giao không?
• Dữ liệu giá được cập nhật thế nào?

Nếu không có câu hỏi thực sự hữu ích, không cần thêm FAQ chỉ để kéo dài page.

28. Mobile: ưu tiên duyệt danh sách trước, filter sau

Trên mobile, sidebar filter desktop thường không còn phù hợp.

Một layout thực dụng có thể là:

[32 dự án]      [Lọc] [Sắp xếp]

[Card dự án]
[Card dự án]
[Card dự án]
...

Khi nhấn “Lọc”, mở drawer/bottom sheet.

Drawer nên:

• Hiển thị tiêu chí quan trọng trước;
• Có “Xóa lọc”;
• Có nút “Xem X dự án”;
• Không áp dụng từng lựa chọn làm reload liên tục nếu không cần;
• Giữ trạng thái khi khách quay lại.

Nếu muốn rà toàn bộ trải nghiệm màn hình nhỏ, xem tối ưu website bất động sản trên mobile.

29. Giữ trạng thái khi người dùng mở dự án rồi quay lại

Đây là một chi tiết UX rất có giá trị.

Khách:

1. Lọc Hà Đông + 3–5 tỷ;
2. Cuộn đến dự án thứ 15;
3. Mở dự án;
4. Nhấn Back.

Nếu website đưa họ về đầu category, xóa filter và mất vị trí scroll, trải nghiệm sẽ rất khó chịu.

Nên cố gắng giữ:

• Filter;
• Sort;
• Trang hiện tại;
• Scroll position khi phù hợp.

30. Category không nên phụ thuộc hoàn toàn vào JavaScript

Nếu website render danh sách dự án sau một thao tác JavaScript mà HTML ban đầu gần như rỗng, cần kiểm tra kỹ crawl/index.

Google cho biết các crawler thường khám phá URL qua link HTML và không kích hoạt các nút yêu cầu user action.

Với category quan trọng, nên đảm bảo:

• Dự án/link có thể được Google phát hiện;
• Pagination có URL thực;
• Không yêu cầu click để crawler mới nhận thấy toàn bộ cấu trúc;
• Rendered HTML được kiểm tra trong Search Console.

31. Sitemap không thay thế internal link

Sitemap giúp Google biết URL tồn tại nhưng không nên dùng như cách duy nhất để Google phát hiện category.

Category quan trọng nên có internal link trực tiếp từ hierarchy hợp lý:

Trang chủ → Dự án → Hà Nội → Hà Đông.

Hoặc:

Trang chủ → Căn hộ → Hà Nội.

Tùy kiến trúc bạn đã chọn.

32. Danh mục hết dự án nên xử lý thế nào?

Không nên có một rule chung cho mọi tình huống.

Tạm thời hết inventory

Nếu category có nhu cầu dài hạn và dự án có thể quay lại:

• Giữ URL;
• Thông báo hiện chưa có dự án;
• Đề xuất category lân cận;
• Cho phép nhận thông báo nếu hệ thống hỗ trợ.

Category không còn giá trị vĩnh viễn

Cân nhắc:

• Gộp vào category phù hợp hơn;
• 301 khi có trang thay thế tương đương;
• 404/410 nếu thực sự không còn nội dung và không có trang thay thế.

Không nên redirect mọi category hết dữ liệu về homepage.

33. Quy trình tạo danh mục dự án Bdsweb đề xuất

1. Audit dữ liệu: xem hiện có khu vực, loại hình, giá, trạng thái nào;
2. Xác định taxonomy ổn định;
3. Tách taxonomy và attribute;
4. Map nhu cầu người dùng vào category;
5. Chọn category được SEO;
6. Xác định filter chỉ phục vụ UX;
7. Thiết kế URL;
8. Thiết kế card và sort;
9. Thiết kế filter desktop/mobile;
10. Thiết lập pagination;
11. Viết nội dung hub khi cần;
12. Xây internal link;
13. Kiểm soát crawl/index filter;
14. Test với dữ liệu thực tế trước khi launch.

34. Ví dụ kiến trúc cho sàn có nhiều dự án

Dự án
│
├── Theo khu vực
│   ├── Hà Nội
│   │   ├── Hà Đông
│   │   ├── Nam Từ Liêm
│   │   └── Long Biên
│   └── TP.HCM
│
├── Theo loại hình
│   ├── Căn hộ
│   ├── Nhà phố
│   ├── Biệt thự
│   └── Đất nền
│
└── Filter
    ├── Giá
    ├── Diện tích
    ├── Trạng thái
    ├── Pháp lý
    └── Chủ đầu tư

Trong mô hình này:

• Khu vực và loại hình có thể là taxonomy;
• Giá/diện tích là attribute/filter;
• Một số trạng thái có thể được nâng thành landing nếu có nhu cầu;
• Không phải mọi combination đều tạo URL indexable.

35. Ví dụ kiến trúc cho chủ đầu tư chỉ có một cụm dự án

Doanh nghiệp chỉ có 3–5 dự án không nhất thiết cần taxonomy phức tạp.

Có thể dùng:

/du-an/
    ├── du-an-a/
    ├── du-an-b/
    └── du-an-c/

Trang `/du-an/` đóng vai trò hub.

Các filter sâu có thể hoàn toàn không cần.

Đây là một ví dụ cho nguyên tắc:

Kiến trúc phải tương xứng với dữ liệu thực tế.

36. Ví dụ kiến trúc cho môi giới chuyên một khu vực

Nếu doanh nghiệp chỉ tập trung một thành phố, hierarchy địa lý có thể đi sâu hơn:

/du-an/ha-noi/
/du-an/ha-noi/ha-dong/
/du-an/ha-noi/nam-tu-liem/

Loại hình có thể trở thành filter hoặc category con tùy inventory:

/du-an/ha-noi/ha-dong/can-ho/

Nhưng chỉ tạo khi trang đó có giá trị thực, không tự động sinh cho mọi quận × loại hình.

37. Những lỗi phổ biến khi tạo danh mục dự án

• Biến mọi attribute thành category;
• Tạo category không có inventory;
• Tạo mọi tổ hợp khu vực × loại hình;
• Một dự án có nhiều URL detail theo category;
• Taxonomy loại hình không chuẩn hóa;
• Giá được lưu dưới dạng text nên lọc sai;
• Sort URL bị index hàng loạt;
• Filter sinh không giới hạn URL;
• Canonical mọi trang pagination về trang 1;
• Load More nhưng không có URL crawlable;
• Category chỉ có card, không có điều hướng/hub;
• Nhồi đoạn SEO dài trước danh sách;
• Card chứa quá nhiều thông tin;
• Mobile filter chiếm cả màn hình;
• Không giữ trạng thái khi quay lại;
• Danh mục quan trọng không có internal link.

38. Checklist nghiệm thu danh mục dự án BĐS

Kiến trúc

• [ ] Taxonomy phản ánh hành vi người dùng;
• [ ] Phân biệt taxonomy và attribute;
• [ ] Không tạo category chỉ vì có một giá trị dữ liệu;
• [ ] Một dự án có một URL detail chính;
• [ ] Category có thể mở rộng khi inventory tăng.

UX

• [ ] H1 rõ;
• [ ] Số lượng kết quả rõ;
• [ ] Card dễ so sánh;
• [ ] Filter dễ dùng;
• [ ] Sort không gây nhầm;
• [ ] Zero-result có gợi ý;
• [ ] Giữ trạng thái khi quay lại.

Mobile

• [ ] Filter dạng drawer/bottom sheet khi phù hợp;
• [ ] CTA filter đủ lớn;
• [ ] Card không quá cao;
• [ ] Ảnh tối ưu;
• [ ] Không reload nặng sau từng thao tác nhỏ.

SEO

• [ ] Category SEO có intent riêng;
• [ ] Title/H1 phù hợp;
• [ ] Nội dung không nhồi keyword;
• [ ] Internal link rõ;
• [ ] Breadcrumb đúng;
• [ ] Filter/sort URL được kiểm soát;
• [ ] Pagination có URL riêng;
• [ ] Canonical pagination đúng;
• [ ] Sitemap chỉ chứa URL cần thiết.

Dữ liệu

• [ ] Khu vực dùng ID/taxonomy chuẩn;
• [ ] Loại hình chuẩn hóa;
• [ ] Giá lưu dạng số;
• [ ] Diện tích lưu dạng số;
• [ ] Status dùng enum/taxonomy;
• [ ] Dữ liệu đủ sạch để filter chính xác.

39. Câu hỏi thường gặp

Nên tạo danh mục theo khu vực hay loại hình trước?

Phụ thuộc inventory và hành vi khách hàng. Nếu doanh nghiệp tập trung địa phương, khu vực thường là hierarchy tự nhiên. Nếu là sàn đa tỉnh với nhiều loại hình, có thể cần cả hai. Không nên chọn chỉ vì một cấu trúc được coi là “chuẩn SEO”.

Một dự án có được xuất hiện ở nhiều danh mục không?

Có. Một dự án có thể thuộc nhiều taxonomy như khu vực, loại hình và trạng thái. Điều quan trọng là trang chi tiết dự án vẫn có URL canonical chính, không tạo nhiều bản sao nội dung.

Mọi trang lọc có nên noindex không?

Không có rule chung. Một số tổ hợp có thể có Search Intent đủ mạnh để trở thành landing SEO; phần còn lại chủ yếu phục vụ UX. Cần quy hoạch trước URL nào được crawl/index và URL nào không.

Dùng robots.txt hay noindex cho URL lọc?

Hai công cụ giải quyết hai vấn đề khác nhau. Nếu không muốn crawler truy cập một nhóm facet URL, robots.txt có thể được dùng để hạn chế crawl. Nếu cần Google nhìn thấy chỉ thị noindex, URL phải được crawl để Google đọc chỉ thị đó. Vì vậy không nên máy móc đặt cả hai cùng lúc mà chưa hiểu mục tiêu.

Pagination trang 2 có canonical về trang 1 không?

Không nên mặc định như vậy. Google hiện khuyến nghị mỗi trang trong chuỗi pagination có URL và canonical riêng.

Có cần rel="next"/"prev" không?

Google hiện không còn dùng các thẻ này để hiểu pagination, dù một số hệ thống khác vẫn có thể sử dụng.

Category cần bao nhiêu chữ?

Không có số từ bắt buộc. Nội dung cần đủ để giải thích category và hỗ trợ quyết định; danh sách dự án, filter và điều hướng bản thân cũng là main content quan trọng của loại trang này.

Kết luận

Tạo danh mục dự án cho website BĐS không phải công việc “chia dự án vào vài thư mục”. Đây là bài toán kiến trúc dữ liệu và điều hướng:

Nhu cầu người dùng → taxonomy → dữ liệu chuẩn → category → filter → pagination → internal link → crawl/index.

Một hệ thống tốt cho phép một dự án xuất hiện ở nhiều ngữ cảnh nhưng vẫn chỉ có một URL chi tiết chuẩn; người dùng có thể lọc tự do nhưng Google không phải crawl hàng nghìn tổ hợp vô giá trị; category có thể mở rộng khi inventory tăng mà không phải thay toàn bộ cấu trúc website.

Ở cấp tổng thể, danh mục dự án nên được thiết kế như một phần của cấu trúc website bất động sản chuyên nghiệp. Khi taxonomy, URL, filter và nội dung hub được quy hoạch đồng bộ từ đầu, website vừa dễ sử dụng hơn vừa giảm đáng kể rủi ro duplicate, index rác và cannibalization khi dữ liệu tăng lên.