HubSpot tracking code: how do you know it works?

The material available about HubSpot's tracking code almost always ends on the same sentence: paste it before the closing body tag. And that is where it stops.

But pasting is not the hard part — the hard part comes the following week, when the traffic report is empty and the conversation between marketing and technology turns into "it is installed, yes" against "then why does nothing show up".

That is a verification problem, not an installation problem.

And it has a documented solution. HubSpot publishes five validation methods, and one of them gives a definitive answer in under a minute, right in the browser, with no server access. That is the method that turns the marketing manager into the auditor of their own project.

What does the HubSpot tracking code do on your site?

The tracking code is a script, unique per account, that does three things: it monitors site traffic, recognizes when a form is submitted and enables conversation tools such as live chat. Manual installation is only necessary on external sites, and the feature is available across all products and plans.

Caption: the snippet on the page is only half the job; the other half is proving that it fired.

It is worth looking at each function from the other side, at what stops existing without the code.

Without tracking, there is no traffic source report. Contacts keep arriving, but with no way to know whether they came from organic search, paid media or email, and reading content marketing performance becomes unfeasible.

With no tracking, the form still creates the contact, but the submission loses its context. The history of pages visited before conversion does not exist, and that is the data separating a generic information request from someone who spent twenty minutes on a course page.

Anyone working on capturing leads in a student recruitment campaign knows the difference that browsing history makes in the sales approach.

And without tracking, chat does not appear. Conversation tools, including chatbots configured on the platform, depend on the same script to load on external sites.

One detail that confuses many people: the code is unique per account, not per site. The same snippet goes on every domain and subdomain you want to track, and what identifies the origin of the data is the account number embedded in it.

Where do you find the HubSpot tracking code and the Hub ID?

The path is the settings icon in the top right corner, then Tracking & Analytics > Tracking code in the sidebar. The snippet appears in the Embed code section, with a copy button. In Marketing Starter and free tools accounts, the item appears directly as Tracking Code in the sidebar.

Copy it with the button, never by selecting the text with the mouse. Manual selection is a banal source of broken code: one character out of place, a line break the site editor read as the end of a tag.

As for the Hub ID, it lives inside the snippet itself: the script points to a file whose name is your account number followed by .js, in the format [Hub ID].js. The same number appears in the browser's address bar while you are logged into the portal.

Keep that number, because it is the key to every test that follows. It is what distinguishes "there is a HubSpot code installed" from "my account's code is installed", a frequent distinction on sites that have passed through another portal or another agency.

How do you install the HubSpot tracking code on an external site?

The rule is to paste the snippet immediately before the closing body tag, on every page of the site.

On sites with a template structure, that means editing a single shared footer file, so the code loads on any URL of the domain.

In WordPress, there are three routes with different risks.

The first is editing the theme's footer file. It works, with one caveat: if the edit is made in the main theme instead of a child theme, the next update wipes the code. It is the most common reason for tracking that worked and stopped months later, with nobody having touched anything.

The second is using a script injection plugin, or the equivalent feature many themes offer for inserting code in the footer. It is the safest route for anyone who does not want to touch a theme file, and it survives updates.

HubSpot also maintains an official WordPress plugin, which installs tracking without manual code editing.

The third is distributing the snippet through a tag manager. That creates one more dependency: if the tag is paused, tracking goes down with it. And the most common mistake here is nobody documenting that decision, with the team spending an afternoon looking for the code in the theme.

Once the route is chosen, three precautions prevent rework:

• Cover every template. Home, inner pages, blog, course pages, search. An educational institution's site has more templates than the informal inventory suggests.
• Install it only once. Duplicate code on the same page produces inconsistent behavior and gets in the way of diagnosis.
• Clear the cache afterward. Cache plugins and CDNs keep serving the previous version of the page, and you will be testing the old HTML thinking the installation failed.

Do I need to install the tracking code on HubSpot pages?

No. On website pages, landing pages and blog posts hosted on HubSpot itself, the code is included automatically. Manual installation exists exclusively for content that lives outside the platform, such as a site on WordPress or on another third-party system.

That matters in the hybrid scenario, which is the most common one: institutional site on one platform, campaign landing pages on HubSpot. The snippet goes only on the institutional site, and trying to add it to the landing pages only creates duplication.

The point to watch is journey continuity. When a visitor navigates from the external site to a HubSpot landing page, tracking recognizes the same person because the cookie was placed at first contact.

Without the code on the external site, that part of the journey stays invisible and the landing page shows up in the report as if it were the beginning of everything.

What are the 5 ways to validate the HubSpot tracking code?

HubSpot documents five verification methods: the automatic tool inside settings, inspecting the page source, two different checks in the browser's network tab and confirming new page views in the traffic reports. They are not equivalent, because they prove different things.

That is the distinction most tutorials miss: seeing the script in the page source proves it is on the page, not that it loaded or that it sent data to HubSpot.

Here is what each method confirms:

Table: All five methods come from the official documentation; the order above runs from the most indirect to the most conclusive.

If you can only run one test, run the fourth.

The __ptq.gif request with status 200 OK is what confirms the firing. It is the call that carries the page view record to HubSpot, so its presence in the network tab means the whole cycle completed: script loaded, cookie allowed, event sent, server answered.

The route requires no coding knowledge. Open the page and the developer tools with F12, go to the Network tab, reload the page and type __ptq in the filter field. If the line appears with 200, it is working. If nothing appears, it is not.

In the same tab, it is worth checking two domains the documentation distinguishes: js.hs-scripts.com is the script loader and js.hs-analytics.net is the tracking part. Seeing the first without the second indicates that loading started but tracking did not come up, which points to a browser block or pending consent.

A complete audit is necessary, and it involves: the automatic tool so you have a record by email, the Hub ID confirmed in the page source, __ptq.gif with 200 in the network tab and, hours later, the page view in the report. None of that depends on server access or developer permission, and all of it produces evidence you can attach to a ticket.

Why is HubSpot not recording visits on the site?

When HubSpot records no visits, the cause is almost always in one of six areas: a Hub ID from another account, code missing from part of the templates, cache delivering the old page, pending consent in the cookie banner, a block in the tester's browser or a wrong expectation about how long the report takes to update.

Start with the network test, because it splits the problem into two contexts.

If __ptq.gif does not appear, tracking is not firing on that page. Check in this order: the snippet exists in the source of that specific URL and not just on the home page, the number in the .js file name is your account's Hub ID, and the file loads with 200 or 304 instead of an error. A missing script points to installation or cache; a script with a loading error points to the Hub ID or a network restriction.

If __ptq.gif appears with 200 and the report is empty, the data is being sent and the problem is one of reading. Check the date range, whether internal traffic is excluded from analytics and whether the tested URL belongs to the domain filtered in the report.

Some scenarios fool experienced teams:

• Code on only one template. The home page has the snippet, the course pages do not. The test on the home page passes, the report stays nearly empty, and the wrong conclusion is that the code does not work.
• An old portal still live. Sites that changed agencies or accounts keep the previous Hub ID. The code works, it just sends the data somewhere else.
• A blocker in the tester's browser. Privacy extensions block the call. Testing in an incognito window eliminates that variable in ten seconds.
• Pending consent. With an opt-in banner, tracking only fires after acceptance. Reloading, accepting and checking again is part of the test.
• CDN cache. The change was published, but the cached version keeps serving HTML without the snippet to a good share of visitors.

Once the data starts arriving, the next step is interpreting it. It is worth knowing the data analysis features in HubSpot before concluding anything from a report with a few days of history, because low volume in a short window misleads easily.

What does the consent banner change in tracking and cookies?

HubSpot's consent banner works both on pages hosted on the platform and on external pages that load the tracking code. Cookies classified as necessary are always placed. The rest depend on the banner type chosen, and that choice directly changes what shows up in the traffic reports.

There are three banner types: notify, which only informs; opt-in, which requires acceptance before tracking; and opt-out, which tracks automatically with an option to decline. For unambiguous consent under Brazil's LGPD, the relevant type is opt-in.

And there is the connection to this article's subject: in opt-in mode, a visitor who does not click accept generates no tracked page view.

That is not an installation failure, it is privacy working as it should, and it explains why HubSpot's number can sit below what other analytics tools show. The report starts measuring consented visits, not total visits.

HubSpot keeps in its documentation the list of cookies it places in the visitor's browser, with the function of each one. It is the input the legal team asks for when building the site's cookie policy.

The topic connects to the broader discussion of data privacy inside the CRM, which goes beyond the banner.

A note of precision: the banner and the consent record are means of evidencing free, informed and unambiguous consent for a determined purpose. Choosing the banner type is a compliance decision, not a performance one.

Frequently asked questions about the HubSpot tracking code

So, when can you consider the HubSpot tracking code validated?

When you have evidence from both sides: __ptq.gif with status 200 on at least one page of each site template and the corresponding page view showing up in the traffic report. One without the other does not close the diagnosis. The first proves sending, the second indicates receipt and attribution.

Before closing the task, settle four points: the Hub ID checks out, the snippet covers every template and not just the home page, the cache was cleared after publishing and the consent banner type is clear to whoever will read the reports.

It is worth seeing this step in the place it occupies: tracking is the first configuration that generates data in a project to HubSpot Implementation, and it is the one every later analysis inherits. A poor installation here does not show up as an error, but as a low number, far harder to detect.

With the code validated, the next step is immediate: watching the data arrive and learning to read what it shows. That is exactly what setting up HubSpot Analytics organizes, from traffic source reports to per-page metrics, so the installation effort turns into a marketing decision.