# URL Param Passthrough Disabling on page Anchor Links

**URL:** <https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063>\
**Category:** General\
**Created:** [January 6, 2025, 7:02pm UTC](https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063 "2025-01-06T19:02:34Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![mmdesign](https://avatars.discourse-cdn.com/v4/letter/m/a9a28c/32.png) [@mmdesign](https://sygnal-attr.discourse.group/u/mmdesign)\
**Post date:** [January 6, 2025, 7:02pm UTC](https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063/1 "2025-01-06T19:02:34Z")

</div>

Hey there! It looks like the URL Param Passthrough build has a bug where it does not recognize on page anchor links. When on page anchor links are clicked, the anchor link flashes for a second in the top URL bar but then the full page completely reloads before the browser can bring the user to that anchored section. This behavior effectively breaks any on page anchor link.

Is there a workaround for that behavior? Here is our implementation:

```auto
<!--- Sygnal Attributes 5 | Url UTM Tracking Parameter Code for specific pages only -->
<script defer src="https://cdn.jsdelivr.net/gh/sygnaltech/webflow-util@5.4.22/dist/nocode/webflow-url.js"></script>
<script>
window.sa5 = window.sa5 || [];
window.sa5.push(['urlConfig', 
  (config) => {
    config.passthrough = true;
    config.passthroughConfig = {
      ignorePatterns: ["ignore", /_page$/],
      overwriteExisting: true,
      internalOnly: false
    };
    return config;
  }]); 
</script>
<!-- End Sygnal Attributes 5 | Url | Config -->

```

I’ve tried disallowing hashtags in the ignore pattern line, but that didn’t help.

---

<div class="post-metadata">

**Author:** ![memetican](https://yyz2.discourse-cdn.com/free1/user_avatar/sygnal-attr.discourse.group/memetican/32/9_2.png) [@memetican](https://sygnal-attr.discourse.group/u/memetican)\
**Post date:** [January 7, 2025, 7:02am UTC](https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063/2 "2025-01-07T07:02:48Z")

</div>

I think I understand the scenario you’re describing, but can you share a published site link and let me know which link is affected?

---

<div class="post-metadata">

**Author:** ![mmdesign](https://avatars.discourse-cdn.com/v4/letter/m/a9a28c/32.png) [@mmdesign](https://sygnal-attr.discourse.group/u/mmdesign)\
**Post date:** [January 7, 2025, 6:56pm UTC](https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063/3 "2025-01-07T18:56:35Z")

</div>

Hey there, thanks for responding! Staged page with the UTM script for debugging can be found [here](https://freed-web.webflow.io/home---utm-debugging). Control page to confirm behavior without the script can be found [here](https://freed-web.webflow.io).

The top navigation links (Features, How it Works, Pricing, About) are all working on the Control page, but not working on the staged page. It looks like the anchor links are being completely ignored. Removing the UTM script solves the problem. Looking forward to your thoughts here! Appreciate the help 🙂

---

<div class="post-metadata">

**Author:** ![memetican](https://yyz2.discourse-cdn.com/free1/user_avatar/sygnal-attr.discourse.group/memetican/32/9_2.png) [@memetican](https://sygnal-attr.discourse.group/u/memetican)\
**Post date:** [January 8, 2025, 3:02am UTC](https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063/4 "2025-01-08T03:02:08Z")

</div>

Interesting- the passthrough feature was always a quick-hack solution to support simple referral tracking situation, but engineering-wise it’s a very difficult approach to support.

I’ve made some updates that will hopefully handle most common `#hash` scenarios in combination with most `?query` scenarios, but I don’t have the bandwidth to do wide-spectrum browser testing.

Try `5.4.25` and see if it works for you. If not, this is not now I approach referral tracking, because its tracking capabilities are too simplistic for real-world CRO setups.

> **[Quick Start | SA5 Url | SA5 | Sygnal Attributes | Designed for Webflow](https://attr.sygnal.com/sa5-url/quick-start)**
>
> How to Easily Add SA5's Url Enhancements to Your Webflow Site

I’ve updated the notes here as well;

> **[Query Param Passthrough | SA5 | Sygnal Attributes | Designed for Webflow](https://attr.sygnal.com/sa5-url/query-param-passthrough)**
>
> Automatically pass through querystring params from the current page, as users navigate through your site.

---

<div class="post-metadata">

**Author:** ![mmdesign](https://avatars.discourse-cdn.com/v4/letter/m/a9a28c/32.png) [@mmdesign](https://sygnal-attr.discourse.group/u/mmdesign)\
**Post date:** [January 8, 2025, 8:08pm UTC](https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063/5 "2025-01-08T20:08:59Z")

</div>

Amazing, that fix worked! Really appreciate the help here, and I also really appreciate the added warning note 🙂

Curious, what do you recommend for enterprise level URL parameter tracking on Webflow? I’m going to let my client know this was fixed, but that it may be best to do whatever the more stable enterprise solution you suggest is.

---

<div class="post-metadata">

**Author:** ![memetican](https://yyz2.discourse-cdn.com/free1/user_avatar/sygnal-attr.discourse.group/memetican/32/9_2.png) [@memetican](https://sygnal-attr.discourse.group/u/memetican)\
**Post date:** [January 9, 2025, 9:46pm UTC](https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063/6 "2025-01-09T21:46:13Z")

</div>

I should do a writeup on it, but the approach I build is a bit custom for each client, since it depends on their site structure, incoming traffic sources and what they need to track.

In general for referrer tracking the solution captures the referrer code from the URL as a querystring or path part and then creates a tracking cookie / localstorage token to remember that source.

Then I inject it into form submissions and other conversion actions so that the referrer ( within e.g. 30 days ) is known.

It’s often part of a larger solution that’s also tracking e.g. Google Ad conversions, e.g. when we want long-term visibility on the captured leads and which platform/ad/keyword/referrer they came from.

---

<div class="post-metadata">

**Author:** ![mmdesign](https://avatars.discourse-cdn.com/v4/letter/m/a9a28c/32.png) [@mmdesign](https://sygnal-attr.discourse.group/u/mmdesign)\
**Post date:** [January 10, 2025, 4:16pm UTC](https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063/7 "2025-01-10T16:16:03Z")

</div>

Got it, thanks for the response! Agreed about the cookie approach, however we are working with embedded Typeforms via iframes that can only pull UTMs when present in the URL (as far as we can tell). That’s why we were very excited about SA5!

We are looking further to see if Typeform can offer any solutions, or may decide to migrate off of Typeform entirely so we can do the traditional cookie approach. Appreciate all of your amazing support on this 🙂

---

<div class="post-metadata">

**Author:** ![memetican](https://yyz2.discourse-cdn.com/free1/user_avatar/sygnal-attr.discourse.group/memetican/32/9_2.png) [@memetican](https://sygnal-attr.discourse.group/u/memetican)\
**Post date:** [January 10, 2025, 9:01pm UTC](https://sygnal-attr.discourse.group/t/url-param-passthrough-disabling-on-page-anchor-links/1063/8 "2025-01-10T21:01:06Z")

</div>

That’s exactly why I prefer more explicit control over the referral tracking and data forwarding. Blind querystring passthrough misses cases like this where you want to use the data specially, like appending it to an IFRAME URL.

The cookie approach supports this scenario better, because the cookies is connected to the Webflow site, so e.g. 30 days after that referral link click, your IFRAME URLs still correctly represent the referral source.

Of course, even basic cookies and tracking are always subject to GDPR considerations, so make sure you know your market.

Let me know if you need anything custom built on the referral part.