Crafting Data-Driven Hubspot Sites That Convert

Sure, you can create static websites with Hubspot and the website addon, but what if you’d like to create a data driven website using Hubspot?

What if you’d like to create a:

  • Real estate website with dynamic property listings and search functionality.
  • Car sales website with dynamic car listings.
  • E-commerce.
  • Any other data driven website using Hubspot.

In this article, I’m going to share some of the technical challenges we came up against when implementing a data-driven Hubspot website for a large real-estate company.

This article is more technical than the other articles on this site, but may provide some insight on the journey!

The challenges

Dynamic URLs

Hubspot’s templating system initially sounded like it’d be able to handle dynamic data as we could simply integrate JavaScript calls for data based on the URL parameters, but we quickly ran into trouble.

Hubspot doesn’t natively support dynamic routing.

This meant that we’d have to use query parameters for any type of dynamic page that required data fetching.


And while this is technically possible, it’s a less than ideal outcome for a client who’s used to looking at tidy urls on their competitor’s websites and relies on SEO to drive website traffic.

The solution

The solution to creating SEO friendly dynamic URL’s with Hubspot is to leverage Hubspot’s HubDB.

HubDB can be used for “Dynamic pages” which then allows for the creation of a unique page path and page title for each piece of dynamic data, along with the ID of that piece of data to be fetched from an external API if HubDB isn’t appropriate.

The page’s data will be loaded on the clientside which would’ve impacted SEO once upon a time, but luckily Google is now more than happy to crawl and index JavaScript driven sites.

jQuery Spaghetti

The creation of dynamic pages with Hubspot creates another issue:

You’re doing A LOT of work on the client side.

Now, this isn’t an issue that is inherently bad, but it is an issue that can get out of hand quickly if you’re not using some sort of framework (mental or library-enforced) to manage your codebase.

You can expect your client-side code to be:

  • Loading initial data from an external API.
  • Rendering HTML based on that data.
  • Handling errors and redirects.
  • Integrating with HubDB for further data collection.
  • Integrating with Hubspot forms to capture leads.
  • Filtering / sorting data lists.

In my opinion, it would be incredibly challenging to create a robust and eloquent system for managing all of the above with jQuery and you’ll quickly get into spaghetti code territory, making future iterations and feature builds a nightmare.

The solution

Use a modern JavaScript framework such as Vue (tested) or React (untested).

Using a framework like Vue or React will allow you to structure your JavaScript for each page in coherent, consistent and understandable ways and allow you to share components and functionality across the project as a whole.

To use Vue or React you will need to develop your project locally using a build process with a tool like Gulp so that browsers can natively make sense of your front-end code and then copy the built code to your Hubspot site’s JS file.

I’d also recommend you use a tool like Gulp or Webpack to:

  • Rename local references to files to the production version.
  • Merge and minify your many JavaScript (and CSS / SCSS) files.
  • Convert modern JavaScript to something that can be run on IE11 and above.

Now, Hubspot includes jQuery by default in every project and will get upset if you try to remove it, so adding a new JavaScript library will add some size to your page. You could expect an addition of 59K for Vue and 98K for React, so it’s unlikely to be discounted for that reason alone.

Another larger compromise when using a front-end framework like React or Vue with your Hubspot site is that it could possibly impact your ability to use the preview function for your dynamic pages within the Hubspot dashboard and it may require that the Hubspot moduels within those pages will have to be edited directly using their template’s associated HTML.

This wasn’t an issue for our use case as the dynamic pages were not required to be edited by the client. We also found that previews started to work as they should later in the project. This could be because of an internal Hubspot update that occured during our project.

The final issue that I found when using a front-end framework (Vue in this case) was that it meant that Hubspot’s forms could not be embedded natively within a template as you’d expect and instead had to be dynamically called via the Hubspot Form API.

While not a huge issue, it does impact the ability to see your conversion rates for forms, as Hubspot will no longer automatically register views to a form and therefore calculate the opt-in conversion rate for you.

If you’re considering using Vue as a front-end library for your Hubspot project, it’s worthe mentioning that it uses a liquid-esque templating system similar in nature to Hubspot’s which uses double curly braces {{ variable }} to render dynamic content.

To get around this conflict you can conveniently use v-html or v-text within a dom element to dynamically render content and v-if, v-for and other directives to successfully create dynamic pages.

I also want to re-iterate that I have not tested this system with React and it could have it’s own quirks. It appears that Hubspot’s embedded forms use React to render and there could be conflicts as a result.

An External API

A project like this will have the overhead of requiring an external server with a semi-public API for handling the storage of your dynamic data and the sharing of that data with your Hubspot project.

This assumes that HubDB isn’t enough for your use case.

This will add some ongoing overhead to the project (and increase the initial cost) but can also add flexibility if a mobile app or other service requires access to this data in the future.

The Solution

Any server-side language / framework / database can be used to serve data to your Hubspot site, so I’d simply recommend whichever you’re most comfortable with.

In our case, we had to access a third party data source API, filter and store that data within our own database and then serve that data to the Hubspot website project via a REST API.

The fetching of that data from the Hubspot site was done using the fetch browser API (a polyfill is required for older browsers).

The Upside

Sales-driven businesses such as real estate, car sales and others can learn a lot about their potential clients by reviewing the data that Hubspot’s CRM provides and if your client is already embedded with Hubspot, I think that creating a dynamic website within their ecosystem can have a lot of upside.

The client will be able to use Hubspot’s inbound marketing tools such as blogging and the associated analytics as well as the ability to edit the non-dynamic sites as they’d expect.