# Fix missing traffic caused by caching and speed plugins

Speed plugins such as SiteGround Optimizer, WP Rocket, LiteSpeed Cache, and Autoptimize can bundle the SourceLoop script so visits never arrive. Here's how to spot it and the one-line fix.

Source: https://sourceloop.ai/help/tracking-with-caching-and-optimization-plugins/
Updated: 2026-10-29

---

Speed and caching plugins make pages faster by combining many JavaScript files into one, minifying them, or delaying them until the visitor interacts. Most scripts don't mind. The SourceLoop script does, because it sends each visit to the server it was loaded from. When a plugin copies it into a bundle on your own domain, visits go to your domain instead of SourceLoop and are lost.

The result looks confusing: the script is on the page, **Verify** may pass, but some or all of your pages send no visits.

## Signs you have this problem

- Data health shows visits from some pages (often ad landing pages) but none or very few from the rest of the site
- Traffic or leads dropped sharply on a date when someone changed site speed settings, switched hosts, or updated a plugin
- Leads in your inbox or CRM far outnumber the leads in SourceLoop

## Check in your browser

1. Open a page that isn't being tracked, in an incognito window.
2. Open the browser's developer tools (right-click, **Inspect**), then the **Network** tab, and reload the page.
3. Type `/e` in the network filter box.

If you see a request to `t.sourceloop.ai/e`, the script is sending correctly. If the request goes to **your own domain** (for example `yoursite.com/e`) and fails with a 404, a plugin has bundled the script. Use the fix below.

## The fix: tell the script where to send data

Add one line, `endpoint`, to the config part of your snippet:

```html
<script>
  window.SourceLoopConfig = {
    websiteId: "YOUR_WEBSITE_ID",
    endpoint: "https://t.sourceloop.ai/e"
  };
</script>
<script async src="https://t.sourceloop.ai/tracking-v3.js"></script>
```

Keep your own `websiteId`. With `endpoint` set, the script sends to SourceLoop no matter which file or domain it was loaded from, so it keeps working through any plugin, host, or future settings change. Then purge your site's cache (see the table below) and repeat the browser check.

> **Installed through Google Tag Manager?**
> Edit the SourceLoop Custom HTML tag, add the `endpoint` line, and publish the container. Tag Manager loads the script from `t.sourceloop.ai`, but a speed plugin can still bundle the config, so the line is worth adding either way.

## Or: exclude SourceLoop in your plugin

If you'd rather not edit the snippet, exclude the SourceLoop script from the plugin's JavaScript settings. Most plugins match by part of the file address, so add `tracking-v3.js` (or `t.sourceloop.ai`) to the exclusion list, and `SourceLoopConfig` where the plugin also handles inline scripts. Exclude it from **combining**, **minifying**, and **delaying**: a delayed script only runs after the visitor scrolls or clicks, so anyone who leaves first isn't counted.

Plugin menus change between versions, so look for these settings:

| Plugin or service | Where to look | Clear the cache |
|---|---|---|
| **SiteGround Speed Optimizer** | Speed Optimizer, **Frontend**, **JavaScript**: the exclude lists for Combine JavaScript Files, Minify JavaScript Files, and Defer Render-blocking JavaScript | **Purge SG Cache** in the WordPress admin bar |
| **WP Rocket** | WP Rocket settings, **File Optimization**: Excluded JavaScript Files, and the exclusions for Load JavaScript deferred and Delay JavaScript execution | **Clear and preload cache** on the WP Rocket dashboard |
| **LiteSpeed Cache** | LiteSpeed Cache, **Page Optimization**: the JS Excludes list (JS Settings), and the delayed or deferred JS excludes (Tuning) | **Purge All** in the LiteSpeed Cache toolbar |
| **Autoptimize** | Autoptimize settings, **JS, CSS & HTML**: Exclude scripts from Autoptimize | **Save Changes and Empty Cache** |
| **W3 Total Cache** | Performance, **Minify**: the list of JS files never to minify | **Empty all caches** in the Performance menu |
| **Hummingbird** | Hummingbird, **Asset Optimization**: find the SourceLoop file and turn off compress, combine, and move | **Clear cache** on the Hummingbird dashboard |
| **Perfmatters, Flying Scripts** | The **Delay JavaScript** settings: add SourceLoop to the excluded scripts | Purge your page cache |
| **Jetpack Boost** | **Concatenate JS**: add the SourceLoop script to the exclusions | Purge your page cache |
| **NitroPack** | **Excludes**: exclude the SourceLoop script from optimization | **Purge cache** in NitroPack |
| **Cloudflare Rocket Loader** | Add `data-cfasync="false"` to the SourceLoop `<script>` tag, or turn off Rocket Loader | Purge everything in Cloudflare |

If your host has its own optimization layer (for example a "speed" or "performance" toggle in the hosting dashboard), it can do the same thing. Add the `endpoint` line rather than hunting for its settings.

## Not using WordPress?

The same thing happens anywhere the SourceLoop script is served from another address:

- **Build tools** that download and bundle third-party scripts into your own JavaScript files
- **A copy of `tracking-v3.js` hosted on your own server or CDN**, sometimes done to dodge ad blockers
- **Proxies or edge optimizers** that rewrite script addresses to your domain

In each case, add the `endpoint` line from the fix above.

## After the fix

1. Purge every cache layer: the plugin, your host, and your CDN (Cloudflare or similar).
2. Open a few previously missing pages in an incognito window.
3. Open **Setup**, then **Data health**, then the **Live** tab. Your visits to those pages should appear within a few seconds. See [Verify tracking](/help/verify-tracking-is-working/) for the full check, including an end-to-end test lead.

Visits from before the fix were never sent to SourceLoop, so they can't be recovered. Everything from the moment the fix is live is tracked normally.

Still stuck? Email hello@sourceloop.ai with your domain and the name of your speed or caching plugin.

## Frequently Asked Questions

### The script is on my page. Why isn't SourceLoop getting the visits?

A speed plugin probably copied the script into its own bundled file on your domain. The script then sends visits to your own domain instead of to SourceLoop, and they are lost. Add the endpoint line to your snippet, or exclude the script from combining in the plugin.

### Is this only a WordPress problem?

No. It happens wherever something re-serves the SourceLoop script from another address, including WordPress speed plugins, some hosting optimizers, build tools that bundle third-party scripts, and a copy of tracking-v3.js you host yourself. The endpoint line fixes all of them.

### Can I get back the visits that were missed?

No. Visits that never reached SourceLoop were not recorded, so they can't be recovered. Tracking is complete again from the moment the fix is live.

### Will excluding the script make my site slower?

No. The script is small and loads async, so leaving it out of a bundle has no measurable effect on page speed.

### Some pages are tracked and some aren't. Is that the same problem?

Often, yes. Pages built with a different builder or template, such as ad landing pages, may load the script directly while the rest of the site loads it through the plugin's bundle. Data health showing visits only from some page paths is the typical sign.