If you run a HubSpot site through a theme detector and get nothing back, the tool may not be broken. For a large share of HubSpot CMS sites, the theme name is genuinely not published anywhere a detector can read.
We tested this against real portals to find exactly where the line falls. The short version: marketplace themes name themselves, agency-built portals do not, and the difference is structural rather than a matter of detector quality.
Two ways a HubSpot site gets built
HubSpot CMS sites come from two very different routes, and they leave different fingerprints.
Marketplace themes. You buy a theme from HubSpot's marketplace and install it. HubSpot serves its assets from a predictable path:
/hubfs/raw_assets/public/<theme-name>/...The theme names itself in the URL, on every page that loads its CSS. This is directly analogous to WordPress's /wp-content/themes/<name>/, and it is just as readable.
Agency or in-house builds. A developer builds the site directly in HubSpot's Design Manager, writing modules and templates for that one client. There is no packaged "theme" — there is a collection of modules. HubSpot compiles each module separately, and the generated asset paths reference the module, not any parent theme.
There is no theme name in the output because, structurally, there is no theme.
What we tested
We checked three real HubSpot portals that we knew to be agency or in-house builds:
- hubspot.com — HubSpot's own site
- impulsecreative.com — a HubSpot partner agency
- bluleadz.com — another HubSpot partner agency
All three are unambiguously HubSpot CMS. All three expose the platform markers clearly:
hs_cos_wrapper
hubfs/raw_assets
hub_generatedNone of the three exposes a theme name. There is no raw_assets/public/<theme>/ path, because no marketplace theme is installed.
Here is the part that made us change our detector: the codebase we started from reported all three as an outright detection failure — and in doing so discarded nine or more modules it had already successfully identified on each site.
That is a bad trade. The scan had recovered real, useful information and threw it away because one field could not be filled.
What we report instead
Our HubSpot detector separates two questions that most tools merge:
- Is this HubSpot CMS? Usually answerable with confidence.
- Which theme? Answerable only for marketplace themes.
When the theme cannot be named, we set a themeUnavailable flag, say plainly that the portal appears to be an agency or in-house build, and still return the module list. For an agency build, the modules are the more interesting answer anyway — they tell you what the site is actually made of.
A result that says "HubSpot CMS, custom build, 12 modules detected" is more useful than an error, and considerably more useful than a fabricated theme name.
Reading a HubSpot site yourself
Open the page source and search for these.
Confirm HubSpot:
hs_cos_wrapper
hubfs/raw_assets
hub_generatedhs_cos_wrapper is a class HubSpot wraps around content areas rendered by its COS. It appears on essentially every HubSpot CMS page and is difficult to produce accidentally.
Look for a marketplace theme:
raw_assets/public/If you find something like /hubfs/raw_assets/public/growth_theme/css/main.css, the theme is Growth. If every raw_assets path points at individual module directories instead, it is a custom build and there is no theme name to find.
Read the modules. Module asset paths reveal the components in use — hero-banner, testimonial-slider, pricing-table. On an agency build this is the closest thing to a structural inventory of the site.
The markers to avoid
A note for anyone building their own detection, because this is a common false positive.
Do not treat these as HubSpot CMS markers:
js.hs-scripts.com
hs-sites.com (as a bare link)Both appear on any site with a single embedded HubSpot form or tracking script — including a great many WordPress sites. HubSpot's marketing tools are used far more widely than HubSpot CMS, so testing for the tracking script will report a large number of WordPress sites as HubSpot.
We restrict our test to markers that only appear when HubSpot is rendering the page itself. This is the same class of mistake we made with Shopify, where a bare .myshopify.com link caused a Ghost publication to be reported as a store — written up in full here.
Why this matters if you are evaluating HubSpot
People usually ask "what theme is this HubSpot site using?" because they want to build something similar and want to know what to buy.
If the answer comes back as a custom build, that is genuinely useful information rather than a dead end. It tells you:
- The look you admire is not purchasable. Someone was paid to build it. Budget accordingly.
- The agency is often identifiable. HubSpot partner agencies frequently credit themselves in the footer, and their own sites showcase their work.
- The modules are the reusable part. Individual module patterns can be rebuilt on a marketplace theme for far less than a full custom build.
If instead you get a marketplace theme name, you can go and buy that exact theme, which is a much shorter path.
The general principle
HubSpot sits in the middle of a spectrum. WordPress publishes the theme name in a URL path on every page. Ghost publishes almost nothing. HubSpot publishes it for one build route and not the other.
A detector's job is to report which situation you are in — not to return a name at all costs. "Custom build, no marketplace theme" is a complete and correct answer, and acting on a fabricated alternative would cost you real time.
Run a portal through our HubSpot detector and you will get the platform, the theme where one exists, and the module list either way.