Module lọc theo loại hình BĐS: Căn hộ, đất nền, nhà phố nên thiết kế thế nào?

Khi tìm bất động sản, người dùng thường đã có một khái niệm tương đối rõ về loại sản phẩm mình muốn xem: căn hộ, nhà phố, biệt thự, đất nền, shophouse hoặc mặt bằng cho thuê.

Nếu website đang có hàng nghìn sản phẩm nhưng không phân loại nhất quán, khách có thể phải duyệt qua rất nhiều tin không liên quan trước khi gặp đúng nhu cầu.

Đó là lý do bộ lọc theo loại hình BĐS thường nằm ở lớp đầu của hệ thống tìm kiếm.

Tuy nhiên, chức năng này không đơn giản là tạo một dropdown gồm:

Căn hộ · Nhà phố · Đất nền · Biệt thự.

Để filter hoạt động chính xác, website phải giải quyết đồng thời:

Taxonomy → Data → Selection Logic → UX → Query → URL → SEO → Tracking.

Bài viết này Bdsweb đi sâu riêng vào cách xây module loại hình cho một website bất động sản có nhiều dự án hoặc tin đăng.

1. Bộ lọc loại hình giải quyết bài toán gì?

Mục tiêu chính không phải làm thanh filter trông đầy đủ hơn mà là giảm nhanh tập sản phẩm không liên quan.

Ví dụ một website có 5.000 listing gồm căn hộ, đất, nhà phố và mặt bằng. Người đang tìm căn hộ không cần nhìn hàng nghìn tin đất nền trước khi tiếp tục lọc giá hoặc diện tích.

Loại hình vì vậy thường là một trong những thuộc tính có khả năng phân chia inventory mạnh.

Sau khi chọn loại hình, những tiêu chí tiếp theo cũng có thể thay đổi.

Khách chọn Căn hộ có thể cần số phòng ngủ.

Khách chọn Đất nền lại quan tâm loại đất, mặt tiền hoặc đường vào.

Như vậy loại hình không chỉ lọc dữ liệu; nó còn có thể quyết định cấu trúc của những filter phía sau.

2. Taxonomy là nền móng của toàn bộ module

Nếu dữ liệu được nhập lúc là “Căn hộ”, lúc “Chung cư”, lúc “Căn hộ chung cư” và lúc “Apartment”, frontend rất khó tạo một filter đáng tin cậy.

Do đó trước khi thiết kế UI cần chuẩn hóa taxonomy.

Một mô hình đơn giản có thể là:

property_type
├── apartment
├── house
├── villa
├── land
├── shophouse
├── office
└── industrial

Frontend có thể hiển thị tên tiếng Việt thân thiện, còn database sử dụng identifier ổn định.

Ví dụ:

apartment → Căn hộ
land      → Đất nền
villa     → Biệt thự

Cách này giúp đổi label giao diện mà không phải thay cấu trúc dữ liệu.

3. Type và Subtype không nên bị trộn thành một danh sách dài

Một lỗi phổ biến là đặt tất cả vào cùng một dropdown:

Căn hộ · Studio · 1PN · 2PN · Duplex · Nhà phố · Liền kề · Đất nền...

Danh sách này đang trộn nhiều cấp khái niệm.

Ví dụ “Căn hộ” là loại hình, trong khi “2PN” gần với công năng hơn là loại hình chính.

Mô hình rõ hơn có thể là:

Loại hình chính	Thuộc tính phụ có thể dùng
Căn hộ	Studio, 1PN, 2PN, 3PN, Duplex, Penthouse
Nhà phố	Liền kề, mặt phố, nhà trong ngõ
Đất	Đất ở, đất dự án, loại đất khác theo dữ liệu
Biệt thự	Đơn lập, song lập nếu inventory có nhu cầu

Nhưng ngay cả bảng này cũng không nên được copy máy móc. Taxonomy phải phản ánh chính inventory của website.

4. Không phải thuộc tính nào cũng nên trở thành Subtype

Nếu website có “Căn hộ 2PN”, câu hỏi cần đặt là:

2PN có phải subtype hay nên là field bedrooms?

Thông thường nếu một thuộc tính có thể được dùng độc lập cho nhiều loại sản phẩm, lưu thành field riêng sẽ linh hoạt hơn.

Ví dụ:

property_type = apartment
bedrooms = 2

thường tốt hơn:

property_type = apartment_2_bedroom

Bởi sau này website có thể dễ dàng lọc:

Căn hộ + 2PN + 60–80 m² + 2–3 tỷ.

Taxonomy càng gắn quá nhiều thuộc tính vào tên loại hình, hệ thống càng khó mở rộng.

5. Loại hình nên được xây theo dữ liệu thực tế, không theo danh sách càng nhiều càng tốt

Một website chỉ có ba tin shophouse không nhất thiết cần đặt “Shophouse” ngang hàng nổi bật với “Căn hộ” đang có hàng nghìn listing.

Tương tự, tạo mười subtype nhưng mỗi subtype chỉ có một sản phẩm sẽ làm giao diện phức tạp mà không cải thiện việc tìm kiếm.

Trước khi đưa một type hoặc subtype vào bộ lọc, nên kiểm tra:

Có đủ dữ liệu không? Người dùng có thực sự tìm theo tiêu chí này không? Nó có giúp thu hẹp kết quả một cách có ý nghĩa không?

Nếu câu trả lời chưa rõ, có thể giữ thuộc tính trong dữ liệu nhưng chưa cần đưa lên UI chính.

6. Single-select hay Multi-select?

Đây là một quyết định UX quan trọng.

Single-select

Phù hợp khi mỗi phiên tìm kiếm thường tập trung vào một loại hình và việc chọn loại hình làm thay đổi mạnh các filter phía sau.

Ví dụ:

Căn hộ → hiện Bedrooms

Đất nền → ẩn Bedrooms, hiện loại đất.

Multi-select

Hữu ích khi người dùng có thể cân nhắc nhiều loại hình gần nhau, chẳng hạn:

Nhà phố + Biệt thự.

Nhưng multi-select làm logic filter phụ thuộc phức tạp hơn.

Nếu người dùng chọn đồng thời Căn hộ và Đất nền, website phải quyết định có nên hiển thị Bedrooms, loại đất hay cả hai.

Do đó không nên bật multi-select chỉ vì framework UI hỗ trợ checkbox.

7. Filter phụ thuộc phải thay đổi theo loại hình đã chọn

Đây là nơi module loại hình thực sự cải thiện UX.

Ví dụ khi chọn Căn hộ, bảng lọc nâng cao có thể ưu tiên:

Phòng ngủ · WC · tầng · nội thất.

Khi chọn Đất nền, giao diện có thể chuyển sang:

Diện tích · loại đất · mặt tiền · đường/lộ giới.

Không cần bắt người dùng đất nền nhìn thấy filter “3 phòng ngủ”.

Logic này cũng làm dữ liệu rõ ràng hơn vì mỗi thuộc tính chỉ xuất hiện khi nó có ý nghĩa.

Toàn bộ kiến trúc filter phụ thuộc được mở rộng thêm trong hướng dẫn thiết lập bộ lọc BĐS nâng cao.

8. Giao dịch mua – thuê nên tách khỏi loại hình

“Căn hộ cho thuê” không nhất thiết nên trở thành một property type riêng.

Data model thường rõ hơn nếu tách:

transaction_type = rent
property_type = apartment

hoặc:

transaction_type = sale
property_type = apartment

Nhờ vậy website có thể tái sử dụng cùng taxonomy loại hình cho cả mua và thuê.

Trên UI, có thể cho người dùng chọn:

Mua | Thuê

sau đó:

Căn hộ | Nhà phố | Đất | Biệt thự...

Cách phân tách này cũng giúp bộ lọc giá chuyển đúng đơn vị và khoảng preset.

9. Chọn UI theo bối cảnh thay vì dùng một pattern cho mọi trang

Cùng một taxonomy nhưng cách hiển thị có thể khác theo vị trí.

Vị trí	UI phù hợp
Trang chủ	Chip/tab/card loại hình chính
Trang listing desktop	Checkbox, dropdown hoặc nhóm filter
Mobile	Chip + filter drawer/bottom sheet
Landing định hướng	Card trực quan
Bản đồ	Filter gọn, cập nhật pin trực tiếp

Ví dụ trang chủ chỉ nên hiển thị các nhóm chính để người dùng đi nhanh vào inventory.

Trang listing mới là nơi cần các lựa chọn chi tiết hơn.

10. Mobile cần hiển thị trạng thái filter thật rõ

Trên desktop, người dùng có thể nhìn toàn bộ sidebar và biết “Căn hộ” đang được chọn.

Trên mobile, filter thường nằm trong drawer nên sau khi đóng drawer, trạng thái rất dễ bị quên.

Website có thể hiển thị chip:

Căn hộ ×
2–3 tỷ ×
Hà Đông ×

Nhờ vậy người dùng biết danh sách hiện tại đang chịu ảnh hưởng bởi những điều kiện nào.

Nếu loại hình có subtype, label cũng cần dễ hiểu:

Căn hộ · 2PN

thay vì chỉ hiển thị một mã nội bộ.

Chi tiết UX màn hình nhỏ nên phối hợp với tối ưu website BĐS trên mobile.

11. Giữ trạng thái loại hình khi người dùng quay lại danh sách

Một flow thường gặp là:

Chọn Căn hộ → lọc giá → mở sản phẩm → Back.

Nếu website trả người dùng về danh sách mặc định gồm cả đất nền và nhà phố, toàn bộ ngữ cảnh tìm kiếm bị mất.

Filter state nên được giữ bằng URL, history state hoặc cơ chế phù hợp với frontend.

Ví dụ:

?type=apartment&price_min=2000000000

Điều này còn giúp người dùng chia sẻ chính tập kết quả đang xem.

12. Đồng bộ danh sách và bản đồ phải sử dụng cùng một nguồn filter state

Nếu website có bản đồ, việc chọn loại hình phải tác động đồng thời tới list và map.

Chọn:

Đất nền

thì danh sách chỉ còn đất nền và các pin trên bản đồ cũng phải phản ánh cùng tập dữ liệu.

Một lỗi dễ gặp là list đã lọc nhưng map vẫn giữ pin từ kết quả cũ do hai component quản lý state riêng.

Với kiến trúc frontend hiện đại, nên có một filter state chung làm nguồn dữ liệu cho cả:

List → Map → Result Count → URL.

Nhờ vậy các thành phần không bị lệch nhau.

13. “0 kết quả” phải xử lý theo loại hình vừa chọn

Giả sử người dùng chọn:

Biệt thự + dưới 3 tỷ + khu vực X.

Website trả về 0 kết quả.

Thay vì chỉ hiện:

“Không tìm thấy sản phẩm.”

có thể giúp người dùng điều chỉnh điều kiện:

Giữ Biệt thự nhưng mở rộng giá

hoặc:

Xem Nhà phố trong cùng khu vực và ngân sách.

Phương án thứ hai chỉ nên được trình bày như một gợi ý thay thế, không âm thầm thay filter của người dùng.

Nếu nguồn hàng thay đổi thường xuyên, có thể bổ sung thông báo khi xuất hiện sản phẩm mới đúng nhu cầu.

14. URL loại hình cần phân biệt giữa Filter State và Landing SEO

Đây là điểm module loại hình liên quan trực tiếp tới SEO.

Một trang:

Căn hộ tại Hà Nội

có thể là một landing có nhu cầu tìm kiếm thực và nội dung riêng.

Nhưng tổ hợp:

?type=apartment&bedroom=2&price=2-3&sort=new

có thể chỉ là trạng thái lọc phục vụ UX.

Không nên mặc định mọi URL filter đều được index.

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

Filter tạo trải nghiệm; Landing SEO được tạo có chủ đích.

Trang landing đáng index cần có inventory đủ ổn định, nhu cầu tìm kiếm và nội dung bổ sung phù hợp.

Việc kiểm soát crawl/index nên nằm trong chiến lược SEO website bất động sản.

15. Taxonomy sai có thể tạo cannibalization ngay trong cấu trúc website

Ví dụ website đồng thời có ba category:

Căn hộ

Chung cư

Căn hộ chung cư.

Nếu cả ba cùng chứa gần một inventory và nhắm tới cùng nhu cầu, website có thể tạo nhiều landing cạnh tranh nhau.

Đây không chỉ là vấn đề SEO; người quản trị cũng không biết nên đưa listing vào category nào.

Tốt hơn là có một taxonomy canonical ở tầng dữ liệu.

Các cách gọi khác có thể được xử lý bằng copy, synonym trong search hoặc nội dung, không nhất thiết phải biến thành ba category độc lập.

16. Tracking giúp biết taxonomy có phù hợp với hành vi người dùng hay không

Không nên đánh giá module chỉ bằng việc “lọc đã chạy đúng”.

Website có thể theo dõi:

KPI	Câu hỏi
Type Filter Usage	Bao nhiêu phiên sử dụng loại hình?
Top Selected Types	Loại nào được chọn nhiều nhất?
Zero-result Rate	Loại hình nào thường không có hàng?
Type → Detail CTR	Sau lọc khách có mở sản phẩm không?
Type → Lead Rate	Nhóm loại hình nào tạo conversion?

Nếu một subtype gần như không bao giờ được chọn, có thể nó không cần xuất hiện ở UI chính.

Nếu một type được chọn nhiều nhưng zero-result cao, doanh nghiệp có thể đang thiếu inventory ở chính phân khúc khách quan tâm.

Tracking vì vậy hỗ trợ cả UX lẫn quyết định kinh doanh.

Những lỗi phổ biến khi xây bộ lọc loại hình BĐS

Lỗi đầu tiên là dùng nhiều tên cho cùng một loại hình khiến dữ liệu phân mảnh.

Lỗi thứ hai là trộn loại hình, công năng và loại giao dịch vào cùng một taxonomy.

Lỗi thứ ba là tạo quá nhiều subtype dù inventory rất ít.

Lỗi thứ tư là cho phép multi-select nhưng không xử lý được các filter phụ thuộc.

Lỗi thứ năm là cùng một sản phẩm được gán nhiều loại chính chỉ để “xuất hiện nhiều nơi”, khiến kết quả lọc thiếu chính xác.

Lỗi thứ sáu là mobile đóng drawer xong không cho người dùng biết loại hình nào đang active.

Lỗi thứ bảy là list và map sử dụng hai trạng thái filter khác nhau.

Và lỗi cuối cùng là biến mọi tổ hợp type/subtype thành URL indexable, khiến website sinh nhiều landing mỏng.

Checklist nghiệm thu module lọc theo loại hình

• [ ] Có taxonomy loại hình chính thống nhất;
• [ ] Identifier dữ liệu tách khỏi label giao diện;
• [ ] Type và Subtype được phân biệt rõ;
• [ ] Bedrooms, diện tích và thuộc tính riêng không bị nhồi vào taxonomy khi không cần;
• [ ] Chỉ hiển thị subtype khi inventory đủ ý nghĩa;
• [ ] Single-select/Multi-select được chọn theo use case;
• [ ] Filter phụ thuộc thay đổi đúng theo loại hình;
• [ ] Mua/thuê được tách khỏi property type;
• [ ] Desktop và mobile dùng UI phù hợp;
• [ ] Filter active được hiển thị rõ sau khi đóng drawer;
• [ ] Trạng thái được giữ khi quay lại danh sách;
• [ ] List, map, count và URL dùng cùng filter state;
• [ ] Zero-result có hướng xử lý;
• [ ] Landing SEO được tách khỏi URL filter động;
• [ ] Tracking được Type Select → Result → Detail → Lead.

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

Căn hộ 2PN nên là loại hình hay thuộc tính phòng ngủ?

Trong phần lớn hệ thống, “Căn hộ” nên là loại hình còn “2PN” là thuộc tính số phòng ngủ. Cách này giúp kết hợp filter linh hoạt hơn.

Website có nên cho chọn nhiều loại hình cùng lúc?

Có thể nếu người dùng thường cân nhắc nhiều nhóm gần nhau và hệ thống xử lý tốt filter phụ thuộc. Nếu chọn nhiều loại khiến giao diện trở nên khó hiểu, single-select có thể phù hợp hơn.

Nhà phố và biệt thự nên tách hay gộp?

Phụ thuộc inventory và cách khách hàng của website tìm kiếm. Nếu hai nhóm có đủ sản phẩm và thuộc tính ra quyết định khác nhau thì nên tách. Nếu dữ liệu rất ít, gộp ở cấp cao rồi dùng subtype có thể đơn giản hơn.

Có nên tạo subtype Studio, 1PN, 2PN, 3PN?

Có thể hiển thị chúng như preset UX, nhưng ở data model thường nên lưu số phòng ngủ riêng thay vì tạo một property type mới cho từng số phòng.

Thứ tự lọc có bắt buộc phải là khu vực → loại hình → giá?

Không. Người dùng có thể bắt đầu bằng khu vực, loại hình hoặc ngân sách tùy nhu cầu. Website nên cho phép hành trình linh hoạt, chỉ áp quan hệ phụ thuộc khi dữ liệu thực sự yêu cầu.

Có nên tạo landing SEO cho từng loại hình?

Có thể với những loại hình có nhu cầu tìm kiếm và đủ inventory. Không nên tạo landing chỉ vì taxonomy có một giá trị mới.

Một listing có thể thuộc hai loại hình chính không?

Chỉ nên khi nghiệp vụ thực sự có ý nghĩa. Nếu gán nhiều loại chỉ để tăng khả năng xuất hiện, kết quả filter sẽ thiếu nhất quán. Trong nhiều trường hợp nên có một type chính và các thuộc tính/tag bổ sung.

Filter loại hình có nên tạo URL riêng?

Có thể tạo URL để lưu hoặc chia sẻ trạng thái. Nhưng việc URL có được index hay không là một quyết định SEO riêng; không phải mọi URL filter đều nên trở thành landing tìm kiếm.

Kết luận

Module lọc theo loại hình BĐS không bắt đầu từ việc chọn icon căn hộ, ngôi nhà hay lô đất.

Nó bắt đầu từ cách website định nghĩa dữ liệu.

Một hệ thống tốt cần đi theo chuỗi:

Taxonomy → Data → Selection → Dependency → State → Result → SEO → Measurement.

Taxonomy phải rõ. Data phải nhất quán. Selection phải phù hợp single hoặc multi. Dependency thay đổi các filter tiếp theo theo đúng loại hình. State phải được giữ khi người dùng duyệt sản phẩm. Result phải đồng bộ list và map. SEO phân biệt filter động với landing có chủ đích. Và Measurement giúp biết taxonomy nào thực sự có giá trị.

Khi cần mở rộng từ loại hình sang khu vực, giá, diện tích, pháp lý và tiến độ, có thể tiếp tục với hệ thống bộ lọc tìm kiếm BĐS nâng cao. Riêng phần numeric filter có thể kết hợp với lọc nhanh theo giá và diện tích để tạo một luồng tìm kiếm nhất quán từ loại sản phẩm tới ngân sách và quy mô.