Most real estate websites running on HubSpot CMS handle listings one of five ways. The right one depends entirely on your tier, your listing count, and whether your data already lives somewhere structured.
This is a practical guide to the five paths we see most often, with the honest tradeoffs of each. No "best in class" rankings, just what fits which kind of agency.
The short version
If you have under 50 listings and you are on Content Starter, use a marketplace module with manual entry. It is the cheapest path and it works.
If you have more than 50 listings or your team will edit weekly, you probably need Content Hub Professional and a HubDB-backed page. Pro is the realistic floor for any kind of CRM-synced or database-driven setup.
If your listings are part of broader sales workflows (lead routing, agent assignment, deal stages), look at HubSpot Custom Objects on Pro or Enterprise.
If you have an MLS feed already syncing somewhere, write a serverless function on Pro or Enterprise to pull from it.
If none of the above fit, you fall back to a JavaScript-rendered page, which has real SEO downsides.
Below is the long version.
Option 1: Manual entry via a marketplace module (Content Starter friendly)
The simplest setup. Buy a marketplace module designed for real estate listings, install it on a page, enter listings directly through the page editor. Done.
This is what most small brokerages and solo agents start with. It works on every Content Hub tier including Starter, which is the only listing-page approach that does. The whole site can run on Starter, the listings live inside the module instance, and there is no database, no HubDB, no API setup, and no developer.
When this fits:
- Boutique agency with 10 to 50 active listings
- Solo agent or small team
- Listings change a few times a week, not hourly
- Data lives in the agent's head and a few spreadsheets, not in an MLS
When this breaks:
- More than 100 listings (the page editor gets clunky at that size)
- Multiple agents need to edit their own listings simultaneously
- Listings change daily and copy-paste is error-prone
- You need MLS-sourced data with field-level accuracy
We built Property Listing Pro for this exact case. It runs on Content Starter, ships with live search, three filter groups, drawer detail view with an embedded HubSpot inquiry form, and Schema.org RealEstateListing structured data so Google rich results and AI search can read every property. One-time module purchase, no subscription.
There are other marketplace modules with similar shapes. The thing to verify before buying any of them: does it actually run on Content Starter, or does it require HubDB underneath? A surprising number of "real estate" modules on the marketplace assume HubDB is available, which silently locks them to Pro+ portals.
Option 2: HubDB-backed listings page (Content Hub Professional and above)
The next step up. Build a HubDB table for your listings (one row per property), build a dynamic page template that pulls from the table, and optionally enable HubDB dynamic pages so each listing gets its own URL automatically.
HubDB requires Content Hub Professional or higher. That is the hard floor. You cannot do this on Starter no matter how creative the workaround is.
What you get:
- A real database with rows, columns, and types
- The HubDB UI for editors (similar to a spreadsheet inside HubSpot)
- Bulk import via CSV
- Per-listing URLs auto-generated from a slug column
- Up to 10,000 rows per table, more than enough for any single agency
When this fits:
- 50 to 500 listings
- Multiple editors with different responsibilities
- You want each listing to have a clean, indexable URL like /listings/123-main-st
- You are already on Content Pro for other reasons (smart content, A/B testing, custom CRM dashboards)
When this breaks:
- Listings need to sync from an external system (MLS, Salesforce, Airtable). HubDB is editable but it does not pull from anywhere on its own. You would need a separate sync job.
- You want listings tied into HubSpot CRM workflows ("contact viewed listing X, route to agent Y"). HubDB does not link cleanly to CRM objects.
Cost is the Content Hub Pro subscription (a few hundred dollars per month) plus custom development to build the page template and HubDB schema. Typical scope of work for a small build is a couple of weeks of dev time.
Option 3: HubSpot Custom Object integration (Content Pro or Enterprise)
For agencies that want listings to be a first-class CRM object, not just a website resource.
Custom Objects let you create a "Listing" type in the HubSpot CRM, with its own properties (price, beds, baths, MLS ID, agent owner, status). You can associate listings with contacts, with deals, with companies, run workflows on them, build reports off them, and query them from CMS pages with HubL crm_objects().
Read access from CMS pages is available on Content Hub Professional. Full custom object create and edit access requires Enterprise. Most real estate teams that go this route are already on Sales Hub Enterprise for the broader CRM features.
When this fits:
- Listings are part of your sales process, not just your marketing site
- Agents need to track which contacts viewed which properties
- Lead routing, follow-up automation, and reporting all need to know about listings
- You are already on Enterprise tiers
When this breaks:
- You only need a website listings page with no CRM logic. This is overkill.
- You are not already on Enterprise. The cost jump from Pro to Enterprise is significant and rarely justified by listings alone.
This is the most expensive option but it is also the only one where listings become a real CRM citizen. If your sales process revolves around tracking property interest, it is the right path.
Option 4: External MLS or CRM sync via serverless functions (Content Pro and above)
For brokerages with an MLS feed or an external system of record. Use HubSpot serverless functions to fetch listings from the MLS API on a schedule and write them into HubDB or a custom object, or to fetch on page render with caching.
Serverless functions require Content Hub Professional or higher.
When this fits:
- Franchised brokerage with MLS access (RETS, RESO Web API, Spark, Bridge)
- Listings update hourly or more often
- You need 500+ listings and editors will not maintain them by hand
- You have a developer or agency to build and maintain the integration
When this breaks:
- MLS access is gated by region and board. Each region has its own setup cost (typically a monthly fee plus board membership).
- Caching strategy matters. Hitting the MLS API on every page load is slow and gets you rate-limited.
- Schema mapping from MLS fields to your page is custom work for every MLS region. There is no universal MLS schema.
This is the most operationally complex option. It is also the only one that scales to thousands of always-fresh listings without manual data entry. Reserve it for brokerages that genuinely need MLS-sourced data.
Option 5: Client-side JavaScript fetch (any tier including Starter)
The escape hatch when you absolutely cannot afford a tier upgrade. Build an empty page on HubSpot, drop a JavaScript snippet that fetches listings from an external API at page load, and renders them client-side.
Works on every tier including Starter. No HubDB needed, no serverless needed.
When this fits:
- You are stuck on Content Starter for budget reasons
- Listings live in an external system that exposes a JSON API
- You do not care about SEO indexing of individual listings
- You do not need Schema.org structured data on the listings
When this breaks:
- Almost every other case. Search engines render JavaScript imperfectly. AI assistants do not see client-side content reliably. Schema.org structured data on the initial HTML is not there. The page loads slower because it has to fetch before rendering.
We do not recommend this approach for any agency that wants to be found in search. It is a stop-gap, nothing more.
Which one fits your agency
A simple decision tree:
- 5 to 50 listings, small team, Content Starter is your tier: Option 1, marketplace module with manual entry.
- 50 to 500 listings, ready to upgrade to Content Pro: Option 2, HubDB-backed page.
- Listings are central to your sales process and you are on Sales Enterprise: Option 3, Custom Object integration.
- You have MLS access and 500+ listings: Option 4, serverless and MLS sync.
- You are tier-locked on Starter and have an external API: Option 5, JavaScript fetch (with the SEO caveat).
The most common mistake we see is small agencies trying to build a Pro-tier solution because somebody told them "you need a real database." For 30 listings, a marketplace module on Starter is faster, cheaper, and produces a better-looking page than a half-finished HubDB build. Match the tool to the actual scale.
If you are scoping a real estate site on HubSpot and want help figuring out which path fits, get in touch. If you already know you want the marketplace-module path, the Property Listing Pro page has a live demo, full feature list, and the marketplace link.