VisitorOpsB2B visitor identification and lead-magnet operations

Install Visitor ID on Webflow and HubSpot: QA Checklist

To install visitor identification on Webflow, paste the vendor script into Site Settings > Custom Code (Head Code), which applies site-wide once published; custom code needs an active Site plan or a Core, Growth, Agency or Freelancer Workspace, and the Head and Footer code fields hold up to 50,000 characters each. On HubSpot, paste the script before the closing body tag on every externally hosted page, or use a Custom HTML module or Google Tag Manager tag if the site is not HubSpot-hosted. Both paths need the same QA pass afterward: confirm the script fires once, does not duplicate the platform's own tracking, respects consent, and reaches the vendor dashboard before any signal reaches sales.

VisitorOpsReviewed September 16, 20269 min read

To install visitor identification on Webflow, open Site Settings > Custom Code and paste the vendor script into the Head Code field, which Webflow injects site-wide once you publish; custom code needs an active Site plan or a Core, Growth, Agency or Freelancer Workspace, and the Head and Footer code fields hold up to 50,000 characters each. To install on HubSpot, paste the script before the closing </body> tag on every externally hosted page (HubSpot-hosted pages get the HubSpot tracking code automatically), or route it through a Custom HTML module or Google Tag Manager container if you would rather manage it centrally. Neither install is finished when the script is pasted. Run the QA checklist below before any signal from either platform reaches sales.

This guide is vendor-neutral: it covers where the script goes on each platform and how to prove it fired correctly, not the setup screen of any one visitor-identification tool. If your team already deploys tags through Google Tag Manager, use the GTM install checklist instead; use this page when the script goes directly into the platform.

Why do Webflow and HubSpot need separate install steps?

Webflow and HubSpot both let you add a third-party script without a developer, but they inject code differently, and vendor blog posts describing "visitor identification for Webflow" or HubSpot's own Visitor Identification API cover different problems. Webflow's Custom Code feature is a site-settings field; HubSpot's own tracking code auto-installs on HubSpot-hosted pages but needs manual placement everywhere else. Treat them as two separate installs even if the same vendor script goes into both.

How do you install the script on Webflow?

  1. Open Site Settings > Custom Code. Webflow's documentation places header scripts in the Head Code field and footer scripts in the Footer Code field; footer code runs after page content starts loading, which is the usual home for a visitor-identification pixel that does not need to block render.
  2. Paste the vendor's full snippet, including its opening and closing <script> tags. Webflow's help page says to keep opening and closing tags, and warns that <html>, <body>, or <head> tags in custom code will break the layout.
  3. Confirm the character limit. Webflow's help page gives 50,000 characters each for the Site settings Head code and Footer code fields. If you register scripts through Webflow's Custom Code API instead, that API caps each inline script at 10,000 characters.
  4. Choose site-wide or page-specific scope. Webflow supports both; a company evaluating a new tool should scope the script to a small page set first (see the QA checklist), then widen it after a clean test.
  5. Publish. Webflow's documentation is explicit that "changes require a publish" — staged custom code does not go live until you publish the site, and all staged changes publish together.

How do you install the script on HubSpot?

  1. Check whether the page is HubSpot-hosted. HubSpot's tracking-code documentation says the HubSpot tracking code is automatically included on HubSpot-hosted pages. If your marketing site sits outside HubSpot's CMS, you install manually.
  2. Paste the script before the closing </body> tag on every externally hosted page, per HubSpot's own tracking-code instructions. Most CMS platforms let you deploy this once through a shared footer file instead of editing every page.
  3. Avoid duplicate tracking codes. HubSpot's documentation warns that if multiple HubSpot tracking codes land on one page, only the first will execute — a common failure mode when a theme footer and a page template both include the snippet.
  4. Decide whether to route through Google Tag Manager instead. HubSpot's own install documentation lists creating a custom HTML tag with an "All Pages" trigger as a supported path, which centralizes management if you already run other tags through GTM.
  5. Add external domains to HubSpot's reporting settings if the visitor-identification workflow depends on HubSpot seeing traffic from a non-HubSpot-hosted domain; HubSpot's documentation calls this out as a required step for cross-domain visibility.

What can HubSpot's own tracking see before you QA?

Before you QA a new visitor-identification script, know what the platform underneath it can and cannot see. HubSpot's own visitor-tracking documentation is explicit: visitors are tracked anonymously through a cookie until they submit a form, click a tracked marketing email link, or are otherwise matched to a known contact; HubSpot "does not track unique visitors" in the traditional sense, so a visitor who clears cookies or switches browsers can appear twice; ad blockers and rejected cookie consent both suppress tracked activity; and manually imported contacts show no page views until they take a tracked action. None of that is specific to any visitor-identification vendor, but it explains why a QA test that "passes" on HubSpot's own dashboard still will not prove a named person browsed your site — the platform is telling you the same thing in its own documentation.

What should you test after either install?

Run this after either install, before the resulting signal reaches a CRM workflow or a Slack-style alert.

Step What to test Pass condition Stop or fix if
1. Script placement The script sits in the documented location (Webflow Head/Footer Code, or before </body> on HubSpot-hosted-externally pages). The script matches the vendor's snippet exactly, with no stray <script>, <head>, or <body> tags. The script is pasted into a page template instead of the site-wide field, or duplicated across a theme footer and a page.
2. Publish/deploy The change is live, not just staged. Webflow shows the change published; HubSpot shows the page rebuilt or redeployed. The tester is looking at a staged draft, not the live URL.
3. Single fire The script fires once per page load on a target page. Browser devtools or the vendor's own dashboard shows one event for one load. The script fires zero times, fires late, or fires more than once (often a duplicate install).
4. Consent behavior The script respects the site's configured consent state. The script does not fire before the documented consent decision is met. Nobody can describe the expected consent behavior, or the script ignores it.
5. Cross-domain / ad-blocker check The vendor dashboard shows the test visit. The session appears without a duplicate HubSpot or Webflow analytics event. The visit is missing; check ad blockers, consent state, or (on HubSpot) whether the external domain was added to reporting settings.
6. No duplicate tracking Only one instance of the platform's own tracking code runs. HubSpot's own tracking code (if present) fires once; Webflow analytics, if used, is unaffected. HubSpot's documented "only the first executes" behavior masks a second, broken install.
7. Rollback owner Someone can remove the script quickly if it misbehaves. An owner and the exact settings field or code change are recorded. Nobody can pause the script without a developer.

What does a Webflow install test look like? (hypothetical)

Hypothetical example — names, numbers and dates are illustrative. A ten-person B2B company runs its marketing site on Webflow's CMS plan and wants to test a visitor-identification vendor before rolling it out everywhere. The team pastes the vendor's script into Site Settings > Custom Code, in the Footer Code field, and scopes the first test to the pricing and comparison pages by temporarily removing the script from Head Code and placing a page-specific version instead. After publishing, the tester opens the pricing page in a clean browser profile, confirms the script fires once using browser devtools, and checks the vendor's dashboard ten minutes later for the test session. It appears once, with no duplicate Webflow analytics event. The team then widens the script to site-wide Footer Code and re-runs the same single-fire and consent checks before telling sales the signal is live.

What should you check after the install passes?

A passing install checklist proves the script is present, fires once, and reaches the vendor. It does not prove the vendor identified a real company, and it does not prove the resulting alert is safe to send to a rep. Use the post-launch QA test script to test the downstream CRM and alert handoff, and use the HubSpot workflow recipe if the next step is building a HubSpot workflow around the new signal. Once matches are flowing, run the match-rate calculator on a real week of data instead of trusting a vendor's stated percentage.

FAQ

Do I need Google Tag Manager to install visitor identification on Webflow or HubSpot?

No. Webflow's Custom Code fields and HubSpot's own tracking-code placement both work without GTM. GTM is a documented alternative on both platforms if you already manage other tags through a container and want one place to control firing rules.

Does Webflow's Custom Code feature require a paid plan?

Webflow's own documentation and vendor install guides describe Custom Code as a paid-site-plan feature; teams on a free Webflow plan typically install through Google Tag Manager instead, which does not require the paid custom-code field.

Why did my visitor-identification script stop working after a Webflow republish?

Webflow's documentation states that custom-code changes are staged and only go live on publish, and that all staged changes publish together. A script that "disappears" after a Webflow update is usually an unpublished change, a page template that overwrote the site-wide setting, or an edit that was reverted.

Can HubSpot's own tracking code replace a visitor-identification vendor?

No. HubSpot's own documentation describes cookie-based, mostly anonymous-until-known tracking with no unique-visitor deduplication; it is not the same product as a company-identification vendor, even though both can run on the same page.

What is the single biggest install mistake on either platform?

Duplicate installs: a script pasted into both a page template and a site-wide field, or a HubSpot tracking code pasted twice. HubSpot's documentation explicitly warns that only the first tracking code on a page executes, which can silently break the intended one.

Claim ledger

Claim Source-backed boundary Last checked
Webflow custom code is added through Site settings, split into Head and Footer code fields of up to 50,000 characters each; API-registered inline scripts are capped at 10,000 characters. Webflow Help Center and Webflow custom-code API documentation. 2026-09-16
Webflow custom-code changes are staged and only go live when the site is published. Official Webflow custom-code documentation. 2026-09-16
The HubSpot tracking code auto-installs on HubSpot-hosted pages and must be manually placed before </body> on externally hosted pages. Official HubSpot tracking-code documentation. 2026-09-16
Only the first HubSpot tracking code on a page executes if more than one is present. Official HubSpot tracking-code documentation. 2026-09-16
HubSpot tracks visitors anonymously via cookie until a known-contact action occurs, does not deduplicate unique visitors, and is limited by ad blockers and consent. Official HubSpot visitor-tracking documentation. 2026-09-16
RB2B ships an Installation Debugger that flags script and consent-tool conflicts, most recently refined in mid-to-late July 2026. Official RB2B changelog. 2026-09-16
GTM Preview and Tag Assistant support inspecting tag-firing behavior around release. Official GTM preview/debug documentation. 2026-09-16

Sources

  1. https://developers.webflow.com/data/docs/working-with-custom-code
  2. https://help.webflow.com/hc/en-us/articles/33961357265299-Custom-code-in-head-and-body-tags
  3. https://knowledge.hubspot.com/reports/install-the-hubspot-tracking-code
  4. https://knowledge.hubspot.com/account/how-does-hubspot-track-visitors
  5. https://support.rb2b.com/en/articles/10442291-changelog
  6. https://support.google.com/tagmanager/answer/6107056?hl=en
  7. https://support.google.com/analytics/answer/9212670?hl=en

Reviewed

Scope: B2B visitor identification and lead-magnet operations. We update this guide as the underlying search behaviour changes.

Implementation and QA

Install Visitor Identification With Google Tag Manager: The QA Checklist

To install visitor identification with Google Tag Manager, add the vendor tag as a controlled GTM tag, limit its trigger to the pages that should collect visitor signals, check consent settings with your privacy owner, use Preview/Tag Assistant before publishing, and confirm the tag fires once without duplicating existing analytics or CRM events. GTM deploys and manages tags; it does not identify companies or people by itself.

Reviewed September 2, 202612 min read
Implementation and QA

How To QA a Visitor Identification Tag After Launch

To QA a visitor-identification pixel after launch, run a production test session on scoped pages, confirm the tag fires once, verify trigger and consent behavior against the implementation plan, look for the visit in analytics or the vendor interface, confirm any CRM/workflow handoff is labeled as a reviewed account signal, and check that internal alerts state what is known, inferred, and not safe for outreach. A passing test proves the tag and downstream workflow are usable; it does not prove every anonymous visitor is a named buyer.

Reviewed September 2, 202614 min read