Plenty of businesses run marketing in HubSpot while the website still lives on WordPress. That works — but only if the forms genuinely connect the two. Done badly, you get leads in your inbox that never appear in the CRM, contacts with no original source, and a sales team quietly rebuilding the pipeline in a spreadsheet.
There are three legitimate ways to do this, and the right one depends on whether you care more about design control or attribution accuracy. Below is what each method actually does, the trade-offs nobody mentions, and the specific failure points we find when someone calls us because submissions have stopped arriving.
If forms are already failing on the HubSpot side rather than the WordPress side, start with our troubleshooting guide on HubSpot forms not working — this article is about the connection between the two platforms.
The three ways to run HubSpot forms on WordPress
Method one is the native embed code: build the form in HubSpot, paste the JavaScript snippet into a WordPress page or a Custom HTML block. Submissions land directly in HubSpot, tracking is intact, and you never touch the CRM mapping again. The cost is styling — the form renders inside HubSpot's markup and needs CSS overrides to match your theme.
Method two is the official HubSpot plugin. It installs the tracking code, gives you a shortcode and block for embedding forms, and adds a lightweight CRM view inside WordPress. It is the easiest option for a marketing team without a developer, at the cost of another plugin to keep updated.
Method three is a native WordPress form — Gravity Forms, WPForms, Contact Form 7 — connected to HubSpot through an integration or the Forms API. You get complete design and conditional-logic control, but you are now responsible for making sure every submission actually reaches HubSpot with the right context.
| Method | Best for | Tracking quality | Main trade-off |
|---|---|---|---|
| HubSpot embed code | Attribution accuracy, campaign pages | Full — cookies, source, page context | Styling requires CSS overrides |
| HubSpot WordPress plugin | Teams without a developer | Full, if tracking code is enabled once | Extra plugin to maintain and update |
| Native form + API/integration | Complex logic, pixel-perfect design | Partial unless hutk is passed | You own the mapping and the failures |
The embed method, done properly
Create the form in HubSpot, open the embed code and paste it into a Custom HTML block on the WordPress page. Avoid pasting it into the visual editor — WordPress will sometimes strip or reformat the script tag, which is the single most common reason an embedded form renders as blank space.
Do not load the HubSpot forms script more than once per page. Multiple embeds should share one `forms/v2.js` include, with a separate `hbspt.forms.create` call per form. Duplicate script loads cause forms to render twice or not at all.
Style with CSS targeting HubSpot's own classes rather than rebuilding the markup, and set a min-height on the wrapper so the page does not shift while the form loads.
<script src="https://js.hsforms.net/forms/v2.js"></script>
<div id="form-demo"></div>
<div id="form-newsletter"></div>
<script>
hbspt.forms.create({ portalId: "XXXXXXX", formId: "aaaa-bbbb", target: "#form-demo" });
hbspt.forms.create({ portalId: "XXXXXXX", formId: "cccc-dddd", target: "#form-newsletter" });
</script>Install the HubSpot tracking code — this is the part people skip
The HubSpot tracking script sets a `hubspotutk` cookie in the visitor's browser. That cookie is what ties a submission to the visitor's full page history, original traffic source and previous sessions. Without it, contacts still get created, but with no source and no page views attached.
Add the tracking code sitewide — via the HubSpot plugin, your theme's header, or a tag manager — not just on pages with forms. Attribution needs the pages before the form, not only the form page.
This is also why HubSpot and Google Analytics disagree so often when tracking is partial. If your numbers already look wrong, why your HubSpot and GA4 numbers never match explains which one to trust in each situation.
Using Gravity Forms or WPForms without losing attribution
If you use a native WordPress form and push submissions through the HubSpot Forms API, you must pass the `hubspotutk` cookie value in the request context along with the page URI and page name. Skip it and every contact arrives as 'Offline Sources' or direct traffic, and your campaign reporting becomes fiction.
Map fields explicitly to internal HubSpot property names, not labels. Dropdown and checkbox values must match the internal values defined on the property, or the submission is rejected or silently blanks that field.
Log every API response. Silent failures — a 400 from a mismatched enumeration value — are the reason teams discover three weeks later that half their leads never arrived.
{
"fields": [
{ "name": "email", "value": "jane@example.com" },
{ "name": "firstname", "value": "Jane" }
],
"context": {
"hutk": "<value of the hubspotutk cookie>",
"pageUri": "https://example.com/contact",
"pageName": "Contact"
}
}Why submissions go missing between WordPress and HubSpot
In order of how often we see them: the tracking code was never installed sitewide; a caching or optimisation plugin defers the HubSpot script so `hbspt` is undefined when the page calls it; a consent banner blocks the script until acceptance and the form never renders for people who ignore the banner; the API key or private app token behind a custom integration expired; or a required HubSpot property is not being sent, so the submission is rejected.
Two more are specific to WordPress: aggressive page caching serving a stale form ID after you edited the form in HubSpot, and a security plugin blocking outbound requests to HubSpot's API endpoints.
Test with a real submission from an incognito window on the live domain — not the WordPress preview — and confirm the contact appears with a source, not just in your notification email.
When it is time to stop bridging and move the site
Running forms across two platforms is fine indefinitely if it is stable. It stops being fine when you are maintaining plugin updates, a separate hosting bill, duplicate tracking and a field mapping that only one person understands — and every new campaign page needs work in both systems.
At that point the maintenance cost usually exceeds the cost of moving the site, and a HubSpot website migration puts pages, forms, CRM and reporting in one place. If you are weighing the platforms themselves, HubSpot CMS vs WordPress for B2B websites and HubSpot vs WordPress for SEO cover the decision properly.