Redirect

Redirects do not break tracking — the snippet should live on the destination page, not the source of the redirect. Understanding which URL the visitor's browser actually loads tells you exactly where to paste.

The browser only loads the final destination

When a server sends a 301 or 302 redirect, the browser receives a Location header and immediately navigates to the new URL. It never renders the redirected page — it renders the destination. That is where the page load event fires. That is where the snippet needs to be.

If your snippet is only on the source URL, it never runs when visitors are redirected. Put the snippet in the template for the destination URL — the page visitors actually see — and your page views will be counted correctly.

This is the same principle whether the redirect is http → https, apex → www, www → apex, or an old slug → a new slug. Find the page that ends up in the browser's address bar. That is the page that needs the snippet.

HTTP to HTTPS redirects

Modern sites redirect all http:// traffic to https://. That redirect happens before the browser renders anything. Your snippet should be on the https:// template. If it is, you will never lose a page view to the redirect.

Make sure the site key you registered matches the https origin. If you registered http://example.com and your actual visitors always land on https://example.com, the origins do not match and the beacon will not count under the registered site. Update your site registration to use the https URL.

You can confirm this quickly: look at the site identifier in your dashboard and compare it to what appears in your browser's address bar after the redirect. They should be an exact match.

Trailing slash and canonical path redirects

Many web servers redirect /page to /page/ (adding a trailing slash) or vice versa. The snippet fires on whichever version the server actually serves HTML for. As long as the snippet is in the rendered template, it does not matter which direction the slash redirect goes.

Some servers redirect old URLs to new ones — for example /old-product to /new-product. If you have a redirect mapping in your nginx or Apache config, the snippet in your template covers both old and new paths automatically, because visitors always end up on the template page.

Where redirects cause confusion is with external analytics integrations that try to measure redirect sources. StatelessID measures what the visitor sees — the destination. It does not count the redirect hop as a separate event.

Chain redirects and CDN edge redirects

A chain redirect is one redirect that leads to another — http://example.com → https://example.com → https://www.example.com. The browser follows the whole chain and loads only the final destination. Your snippet needs to be on that final page.

CDN edge redirects (Cloudflare Page Rules, Vercel redirects, Netlify _redirects file) work the same way. If the CDN sends a 301 before the origin server ever sees the request, the origin server never runs the snippet. But the destination URL — wherever the CDN sends the visitor — will render the snippet if it is in that page's template.

To debug a redirect chain: open browser developer tools, go to the Network tab, turn on "Preserve log," then load the original URL. You will see every redirect hop as a separate row. The last row that returns an HTML document is the page that should contain the snippet.

Troubleshooting

I have the snippet in my template but redirects from old URLs are not being counted. Old URLs that redirect to the new URL count as page views on the new URL — which is correct. If the destination page has the snippet, those redirected visitors are counted when they land on the final page.

My dashboard shows the wrong domain in the site identifier after I added a redirect. Update the site registration to use the final destination domain. The beacon reports the origin that the browser sees in the address bar, and it must match the registered identifier.

Some page views appear under http:// and some under https:// in the referrer data. This usually means some inbound links use http:// URLs. The page view itself still fires on https://, but the referrer carries the http:// link the visitor clicked. This is a data quality issue in the referring site, not in your tracking.