Yes, it can be, and it is easy to miss. Analytics tags usually send the page URL and title automatically, so an email address in a query string or a name in a title travels with every hit. Find these cases, remove them at the source, and treat tool side redaction as a backstop.
Why URLs leak data
Google's Analytics policy page says its terms require that data sent must not include information Google could use or recognize as personally identifiable information. It names email addresses, personal mobile numbers and social security numbers as examples. It also says that PII is often sent inadvertently in URLs and titles, and that both the path and the parameters must be free of it.
Typical culprits are password reset and confirmation links with an email parameter, search pages that echo what a visitor typed, account pages with a name in the title, and campaign links that were built with a customer identifier.
Find them: a four step audit
- Pull a list of the most visited URLs and page titles from your analytics tool.
- Search it for an at sign, long numeric strings, and parameter names like email, token, id, user and name.
- Walk key flows in a browser and watch the address bar and tab title.
- Check campaign tools, since links built for email campaigns often add identifiers.
Fix them at the source
| Where it leaks | Better approach |
|---|---|
| Email in a query string | Use an opaque, short lived token and look up the user server side |
| Name in the page title | Use a generic title for account pages |
| Search terms in the URL | Keep the visitor's input out of the data sent to analytics |
| Campaign identifiers | Use a campaign ID that does not map to a person outside your systems |
Also set a restrictive referrer policy so the full URL is not handed to other sites. See which Referrer-Policy value stops URL leaks.
Use redaction as a backstop
Google's help page describes data redaction for web data streams in the Admin settings. It can remove email addresses on a best effort basis and strip URL query parameters you specify, with no code. Notice the words best effort. Do not treat it as the only control. The page also says you can alter the location and title values in code before they are sent, and that you should remove PII from anything visitors type into search or forms.
Higher risk features named on the page include User ID override, custom dimensions, campaign parameters, site search and event dimensions. Review those first.
Consent does not fix it
Google's consent mode guide notes that data sent to Google still includes the full page URL. Consent settings do not remove an email address from a link. This is not legal advice, so ask counsel how local law treats identifiers in your context.
Quick check
Is a hashed email in a URL fine?
Not automatically. Google's page asks you to check whether data could be recognized as PII, and laws differ. Prefer an opaque token with no link to the person outside your systems.
Can redaction replace fixing the URL?
No. The documented email removal is best effort, so fix the source.
Where Safeguard fits
Safeguard's SBOM and dependency scanning cover the code you ship, and its policies can gate changes. URL design is a review item for your team. A free scan is available for your repositories.
Sources
Last reviewed: 19 October 2026.
