HubSpot website integration: a step-by-step setup guide
Install HubSpot's tracking code site-wide, connect your forms through your CMS's native method (or an embed or API when native won't stretch far enough), then verify contact capture inside HubSpot. That's the whole job in one sentence, and it holds true whether you're running WordPress, Webflow, or a hand-rolled React app. The honest time estimate: WordPress with the HubSpot plugin takes about 15 minutes. Webflow's native app is similarly quick. A custom stack or single-page application, where you're wiring the Tracking Code API by hand, usually takes an afternoon once you factor in testing. Copy the tracking snippet from Settings → Tracking & Analytics Paste it before </body> on every external page (or install via plugin/Tag Manager) Connect forms: native embed, third-party form plus webhook, or Forms API Add every domain and subdomain to Additional Site Domains Run HubSpot's validate tool and submit one test form Pro Tip: *Don't trust a green tick on the dashboard alone. Submit a real test form from an incognito window and watch it land as a contact record before you call the job done.*
Key Takeaways
A working HubSpot website integration depends on installing the tracking code site-wide, mapping forms accurately, registering every domain, and verifying capture before trusting the data.
Point Details Install code before </body> Paste HubSpot's tracking snippet site-wide, or use a plugin to avoid manual edits breaking on updates. Choose the right form method Use native embeds first; reserve the Forms API for genuinely bespoke validation or logic needs. Verify with real tools Check the Network tab for 200/304 responses and confirm a test submission creates a contact record. Register every domain Add all domains and subdomains to Tracking & Analytics to stop leads being flagged as spam. Handle SPAs explicitly Push setPath and trackPageView to _hsq on virtual navigation or page views go uncounted. Consider a managed build Project-pixel includes tracking, form mapping, and validation as standard in fixed-price website projects.
How do I set up HubSpot website integration step by step?
Start in HubSpot itself, not on your website. Go to Settings → Tracking & Analytics → Tracking Code, and you'll find an account-specific snippet. HubSpot's own guidance is clear that this code must be pasted before the closing </body> tag on every page not already hosted on HubSpot; the platform can't track traffic, load chat widgets, or render embedded forms without it, according to HubSpot's installation documentation. If your CMS has a global footer or header include, that's where it belongs. Failing that, a tag management tool like Google Tag Manager will fire it site-wide without touching template files directly.
Once the code is live, you need a way to get form submissions into HubSpot as contact records. There are three realistic routes:
Pick the plugin or embed unless you have a concrete reason not to. Custom API work adds ongoing maintenance that the other two methods don't.
Verification is where most DIY installs quietly fail. Open your browser's developer tools, go to the Network tab, and look for requests to js.hs-scripts.com and js.hs-analytics.net. You want to see HubSpot's own troubleshooting checklist confirm 200 or 304 responses, and the tracking pixel request (often shown as __ptq.gif) should also return 200 OK. Then submit a real test form and check that a contact record appears with the correct original source.
Last step: go to Tracking & Analytics → Domains and add every domain and subdomain the tracking code runs on, including staging or helper domains used by embedded iframes. Turn on automatic cross-domain linking so a visitor who moves between www.yoursite.com and a booking subdomain is tracked as one person, not two separate sessions, a setup HubSpot details in its site tracking documentation. Skip this and you'll see submissions flagged as coming from an unregistered domain, which HubSpot can treat as spam.
Before you call it finished, test forms on desktop and mobile, click through a single-page app's virtual routes if you have one, and preview any Tag Manager container before publishing it live.
- 01Native embed or plugin. HubSpot forms embedded directly on the page, or built through a CMS plugin. This is the lowest-maintenance option and the one HubSpot recommends first, because the mapping between form fields and contact properties happens automatically.
- 02Non-HubSpot form collection. You keep your existing form (Gravity Forms, Webflow native forms, a custom build) and pipe submissions to HubSpot via a webhook or Zapier-style connector. Useful when you need specific form styling or logic HubSpot's builder can't replicate.
- 03Forms API. Full custom control over submission handling, typically reserved for apps with bespoke validation, multi-step forms, or data that needs enriching before it reaches HubSpot.
WordPress, Webflow, or custom stack: which setup applies to you?
Your platform decides how much manual wiring you'll do. Here's the breakdown.
WordPress. Install the HubSpot WordPress plugin rather than pasting the snippet into functions.php or a theme footer file. Manual edits to theme files get wiped out the next time the theme updates, silently killing your tracking until someone notices contact volume has dropped. The plugin also handles form mapping and chat widget placement without touching code.
Webflow. Either install the HubSpot app from Webflow's integrations marketplace or paste the embed code into your site's custom code settings, in the head or before the body tag. One quirk worth knowing: embedded HubSpot forms inherit whatever CSS your Webflow site already applies, so styling can look unpredictable until you override it. The tracking code needs to sit on the actual host domain, not just a staging subdomain, or you'll validate the code correctly and still see no data once you go live.
Custom stacks and SPAs. Install the standard snippet once in your root HTML, then handle route changes manually. Because a single-page app doesn't reload the page on navigation, HubSpot won't automatically log new page views. Push ['setPath', '/your-route'] followed by ['trackPageView'] to the _hsq array on every virtual navigation, exactly as HubSpot's developer documentation specifies. If you already know a visitor's email (a logged-in user, for instance), pushing an identify call at that point links their session to the right contact record.
Pro Tip: *If you're using Google Tag Manager to fire the tracking code, always check it in Preview mode before publishing. GTM's async loading can occasionally beat HubSpot's own script to the page, causing missed early page views on fast-loading sites.*
Whatever the platform, run the same final check: developer tools open, Network tab filtered for HubSpot's domains, one test submission through a real form.
Why isn't my HubSpot tracking code working?
Nine times out of ten, a broken integration traces to one of five causes. Work through them in order rather than guessing.
- 01Check the network requests first. Search for a file matching your hub ID (something like 123456.js) loading from HubSpot's servers. A 200 or 304 status is healthy; anything else means the script isn't loading at all.
- 02Look for "Unregistered Site Domain" warnings. This means a domain or subdomain sending traffic or form submissions isn't listed in Tracking & Analytics → Domains. Add the exact domain, save, and release any submissions HubSpot quarantined as spam in the meantime.
- 03Rule out blockers. Ad blockers, strict Content Security Policy headers, and cookie consent banners that delay script loading are common culprits. Test in an incognito window with extensions disabled to isolate the problem.
- 04Hunt for duplicate snippets. A plugin and a manually pasted snippet both firing at once causes double-counted page views and occasionally breaks form tracking. Remove one.
- 05For SPAs, check virtual navigation. If page views only register on the first load and never again, you're missing the setPath and trackPageView push on route changes, as HubSpot's tracking API confirms is required for single-page apps.
What we've learned installing HubSpot on client sites
Project-pixel defaults to native integrations and plugins first, reserving custom API work for cases that genuinely need bespoke data mapping or app logic HubSpot's standard tools can't handle. This mirrors the wider industry view that vendor-maintained connectors survive site updates better than custom code does.
The two failures we see most on DIY builds: a tracking snippet pasted straight into theme files that vanishes on the next update, and domains left off the tracking settings so genuine leads get quarantined as spam.
A fixed-price build removes both risks by design: tracking installation, form field mapping, a validation checklist, and launch support are all scoped and delivered before the invoice is settled, not left as an afterthought once the site goes live.
Our own integration work covers tracking installation, form-to-property mapping, the full verification checklist above, and a period of launch support to catch anything that slips through.
Configuring HubSpot CRM to receive your website leads
Tracking code installed and forms connected only gets you halfway. HubSpot CRM needs configuring on its own side to actually do something useful with what arrives.
Start with Objects and Pipelines. New contacts from web forms land in your default contacts database, but you decide what happens next: which lifecycle stage they enter, whether a deal record gets created automatically, and which pipeline that deal sits in. Set this up in Settings → Objects → Contacts before your forms go live, not after.
Notifications and ownership matter more than most teams realise. Configure lead rotation or assignment rules so a new website enquiry reaches a specific salesperson within minutes, not whenever someone next checks the CRM. Settings → Automation → Workflows is where you'll build this, using a simple "form submitted" trigger.
List segmentation comes next. Build active lists that automatically group contacts by source, form type, or lifecycle stage. A contact from your "Request a Quote" form should never sit in the same nurture sequence as someone who downloaded a guide.
Finally, check your default contact properties against what your forms actually collect. If a form field has no matching property in HubSpot, the submission still arrives, but that data has nowhere to live, and you'll only discover the gap when someone asks for a report that can't be run.
Mapping form fields to HubSpot properties correctly
Data accuracy lives or dies on field mapping, and it's the step most guides skip past. Get it wrong and you'll spend months reconciling duplicate or malformed contact records instead of running campaigns.
Match every form field to an existing HubSpot contact property before the form goes live, rather than letting HubSpot create new properties automatically on first submission. Automatic property creation tends to produce inconsistent naming (Phone, phone_number, and Phone Number all existing as separate properties isn't unusual on integrations built in a hurry).
A few rules that hold up in practice:
Review your mapping every time you add a new form. A single unmapped field on a high-traffic page can quietly cost you weeks of usable data before anyone notices.
- 01Standardise on internal field names, not the label shown to visitors. "What's your budget?" and "Project Budget" should map to the same property, however the copy reads on the form itself.
- 02Use dropdowns or radio buttons over free text wherever the answer set is finite. Free-text industry or company-size fields generate reporting chaos within weeks.
- 03Set required fields deliberately. Email should always be required; phone number often shouldn't be, unless your sales process genuinely depends on it.
- 04Test with deliberately messy input. Submit a form with extra spaces, mixed case, and special characters, and check how the property stores it.
Connecting e-commerce and transactional data to HubSpot
If your site processes purchases, bookings, or quote requests, tracking code and lead forms only capture the top of the funnel. Revenue data needs a separate connection.
For established e-commerce platforms, native connectors typically sync order data, product catalogues, and abandoned cart activity directly into HubSpot, creating or updating contact and deal records automatically as purchases happen. This is the same principle as choosing a plugin over custom code for tracking: let the vendor-maintained connector do the heavy lifting rather than building a custom webhook pipeline from scratch.
Where no native connector exists, or your checkout is bespoke, you'll typically send order confirmation data to HubSpot via a webhook that fires on purchase completion, mapped to custom deal or line-item properties. This is genuinely one of the cases where custom API work earns its complexity, because transactional data has specific formatting and timing needs that a generic form submission doesn't.
Whichever route you take, decide upfront what counts as a "closed" deal versus an open enquiry, and make sure revenue figures sync as numbers, not text strings, or your reporting dashboards will silently misbehave. If you take bookings rather than direct payments, the same logic applies. A confirmed booking should trigger a deal stage change, not sit as an unremarkable contact property update buried in a timeline nobody checks.
Keeping your HubSpot integration running smoothly long-term
Most integration failures happen months after launch, not on day one. A theme update overwrites a manually placed snippet, a new landing page ships on a subdomain nobody added to tracking settings, or a marketing intern swaps out the contact form without checking the field mapping still holds.
Build a quarterly check into your calendar: rerun the validate tool, submit one test form, and confirm the contact record still populates correctly, following the same ongoing validation habit HubSpot recommends rather than treating verification as a one-off launch task.
The pitfalls worth watching for specifically:
Document your setup once, properly, and revisit it whenever the site itself changes.
- 01Plugin conflicts. Two form plugins or two tracking installs firing simultaneously cause duplicate contacts and inflated analytics.
- 02New subdomains left unregistered. Every staging environment, booking portal, or campaign microsite needs adding to Tracking & Analytics before it goes live, not after leads start bouncing.
- 03Silent property drift. A developer renames a form field on the front end without updating the HubSpot mapping, and submissions start landing with blank properties nobody notices for weeks.
- 04CSP and cookie consent changes. Updating your cookie banner or Content Security Policy headers can quietly block HubSpot's scripts from loading, even when nothing on the HubSpot side has changed.
Managed HubSpot integration without the agency overhead
Project-pixel builds the HubSpot integration into the website project itself, not as a bolt-on afterwards. A fixed-price build for a service business typically includes the tracking code installed correctly for your platform, whether that's Webflow or WordPress, form fields mapped to the right contact properties from day one, domain settings configured to avoid spam flags, and a launch checklist run before the site goes live rather than discovered broken three months in.
The advantage over piecing it together yourself isn't just saved time, it's avoiding the two failure points covered above: theme updates wiping manual code edits, and unregistered domains quietly binning genuine leads as spam. A fixed deadline and fixed price mean you know exactly what you're getting and when, without an open-ended hourly quote for "integration work" that scope-creeps into weeks. If your site runs on Webflow, our Webflow build and migration service covers this as standard. For a broader view of what's included across industry-specific web design packages, or to see current pricing and package details, that's the fastest way to see if a managed build fits what you need.
When to DIY and when to call in help
I'd default to the plugin or native embed every time over custom API work, simply because it survives longer without babysitting. Three signs you should hand this to an agency rather than doing it yourself: you're managing tracking across multiple domains, your site is a single-page app with complex routing, or your data mapping needs genuinely bespoke logic HubSpot's standard properties can't hold. Below that threshold, a careful afternoon gets you there.
Sources
FAQ
How do I integrate HubSpot with an existing website?
Install the tracking code before </body> on every page, connect your forms through a native plugin, embed, or the Forms API, then verify capture using HubSpot's validate tool and a real test submission.
Is Wix or HubSpot better for building a website?
They solve different problems: Wix is a website builder, while HubSpot is primarily a CRM and marketing platform that connects to whatever site you already have. For a service business wanting both a professional site and CRM data flowing correctly, a purpose-built site with HubSpot integrated, the approach Project-pixel takes, generally outperforms a generic builder with a bolted-on integration.
Can I link my existing website to HubSpot?
Yes. Any website on any platform can connect to HubSpot by installing the tracking code and connecting forms, whether that's WordPress, Webflow, or a custom-built site.
Can I build a website directly inside HubSpot?
Yes, HubSpot's CMS Hub lets you build and host a site natively, but most established businesses with an existing site simply integrate rather than migrate, keeping their current platform and connecting it to HubSpot's tracking and forms instead.
Why does HubSpot flag my form submissions as spam?
This almost always means the domain sending the submission isn't listed under Additional Site Domains in Tracking & Analytics. Add the exact domain or subdomain and release any wrongly flagged submissions.