HubSpot WordPress integration.
Keep the site. Own the data. Not every company should move its website onto HubSpot. Plenty should keep WordPress, Wix or Squarespace and simply make sure the CRM sees everything that happens on it.
The site and the CRM are strangers.
Forms post to the site database, the tracking code was installed once and never checked, and nobody can say which pages a given contact read before they converted. The site is generating signal and throwing almost all of it away.
The page view that never reached the record.
WordPress — the lost signalMaking the site report to the CRM.
Tracking that actually fires
The tracking code present on every template, firing after consent, not blocked by the caching plugin. We verify it rather than assume it, because it is wrong more often than not.
Forms that keep attribution
Embedded HubSpot forms, or native WordPress forms passing the tracking cookie and UTM parameters through. Otherwise every conversion is attributed to direct.
Gated content without a plugin stack
Content gating driven by HubSpot lists and forms rather than a membership plugin with its own user table nobody reconciles.
Chat and meetings embedded
Live chat and booking links on the WordPress site, landing on the same record as everything else.
Consent before tracking
The consent banner gating the tracking script rather than sitting decoratively beside it, which is the configuration a regulator would actually ask about.
Performance not sacrificed
Scripts loaded so they do not block rendering. A tracking implementation that costs a second of load time costs conversions, which defeats the purpose.
Built to a contract, not to a connector.
Draw the boundary
Which system owns which field, in writing, before a line of code. Most broken integrations are two systems both believing they are the source of truth.
Model the join
The key that matches a record on one side to a record on the other, and the rule for what happens when it does not match — because it will not match.
Build and instrument
Sync built with retries, idempotency and a dead letter path, plus logging you can read without opening a console.
Reconcile
Counts compared on both sides on a schedule, with a report that names the drift rather than a green tick that hides it.
Hand over
A runbook covering the three failures that actually happen, so the next person does not have to reverse-engineer the design from the logs.
The plugin was installed. Nobody checked.
The HubSpot WordPress plugin is installed on a Tuesday, a caching layer is added in March, and tracking has been silently broken ever since. We verify the whole chain end to end and re-check it after any infrastructure change, because this fails quietly and expensively.
What people ask before they commit.
Do we have to migrate to HubSpot CMS?
No, and often you should not. If WordPress is working and your team is happy with it, integrating gets you the CRM benefit without the cost and risk of a rebuild.
Is the official plugin enough?
For tracking, forms and chat it is a good start. It stops being enough when you need gated content, custom event tracking or attribution across a multi-site setup.
Does this work with Wix and Squarespace?
Yes. Both allow script injection and embedded forms. You have less control than with WordPress, so some patterns need adapting.
Will tracking survive our caching plugin?
Only if it is configured to. This is the single most common cause of broken HubSpot tracking on WordPress, and it is why we test rather than trust the install.
How long does it take?
One to three weeks for a standard site. Multi-site setups and heavy customisation take longer.
Where people go from here.
Keep WordPress. Keep the data too.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.