# Consent on the Login Page: The Tracking That Starts Before the Visitor Is a Customer Source: https://consentvigil.com/blog/2026-11-10-consent-login-page-tracking-before-account.html [Home](../index.md) / [Blog](index.md) / Consent on the Login Page: The Tracking That Starts Before the Visitor Is a Customer Published 2026-11-10 A visitor lands on your homepage, rejects all cookies, and browses as a guest. The banner records the rejection. Then the visitor clicks log in. The login page loads analytics, a chat widget, and a session recording script, and none of them check the consent state first. The visitor has not become a customer yet. They have become a data subject with no consent record, tracked on a page the banner never saw. Login pages are the blind spot in most consent setups. They sit outside the marketing site, often on a subdomain or a separate application, and they are built by a different team with a different stack. The banner lives on the main site. The login page loads its own tags, its own way, and the consent state from the homepage does not follow. A visitor who rejected tracking on the homepage gets tracked on the login page, and the record says nothing about it. ## Why the login page escapes the banner Three things usually go wrong. First, the login page is a separate application, so the consent platform script is not installed there at all. The banner never renders, and no choice is ever asked. Second, the page is on a subdomain, and the consent cookie is scoped to the main domain, so even a working banner on the homepage cannot read the choice. Third, the login page loads security tools that the team treats as essential, a bot check, a fraud score, a session recording, and nobody asks whether those tools need consent, because they are framed as security rather than tracking. The security framing is where the argument gets sloppy. A bot check that sets a cookie and sends a fingerprint to a third party is processing personal data, whatever the team calls it. A fraud score that builds a profile across sessions is profiling, and it needs a legal basis. The question is not whether the tool is useful. The question is whether the visitor was told and whether they had a choice. On most login pages, the answer to both is no. ## What the tag order actually looks like Open the login page in a fresh browser with the network tab open and reject everything on the homepage first. Then click through to login and watch what fires. The usual picture is an analytics request in the first second, a chat widget loading its own cookies, and a session recording script starting before any field is filled in. The consent management platform, if it loads at all, arrives after those requests have already gone out. The order matters because consent mode works on defaults. Google consent mode expects a default state to be set before any tag fires, and the consent platform is supposed to set that default. When the platform loads late, or not at all, the tags run on their own defaults, which is to say they run. The CookieYes troubleshooting guide puts it plainly: the consent platform tag has to fire first, through the consent initialization trigger, and any tag that fires before the default state is set is a defect, not a timing quirk. ## What to check this week Start with the subdomain question. Check whether the consent cookie is set on the parent domain so subdomains can read it, and whether the login page actually loads the consent platform script. If either answer is no, the login page is running without a consent record, and every choice a visitor made on the homepage is being ignored the moment they click log in. Then list what the login page loads and classify each item honestly. Analytics, chat, session recording, and fraud scoring each need a stated basis, and the ones that rely on consent need to wait for it. A fraud tool that is genuinely necessary for security can rely on legitimate interest, but that interest has to be documented, limited, and balanced against the visitor, not assumed. The record should show the reasoning, not just the decision. Finally, test the withdrawal path from the login page. A visitor who withdraws consent on the homepage and then logs in should stay withdrawn. If the login page resets the state, or loads a fresh banner that defaults to accept, the withdrawal never happened in practice. The record will say the visitor withdrew at 2:14 pm. The network log will say the tracking continued at 2:15. The network log is the one a regulator reads. Keep reading: [what post-purchase pages track](https://consentvigil.com/blog/2026-10-17-consent-post-purchase-account-pages-tracking.md), [where server-side tracking slips past consent](https://consentvigil.com/blog/2026-09-25-server-side-tracking-consent-gap.md), and [how consent travels across devices](https://consentvigil.com/blog/2026-10-15-consent-multiple-devices-cross-device.md) cover the nearby cases in this series. ## Frequently asked questions ### Does consent from the homepage carry over to the login page? Only if the consent cookie is scoped to the parent domain and the login page loads the same consent platform. Most login pages sit on a subdomain or a separate application, and in that setup the choice made on the homepage is invisible. Check the cookie scope and the script, and test it by rejecting on the homepage and watching the network on the login page. ### Do security tools on a login page need consent? It depends on what they do. A bot check that sets a cookie and sends a fingerprint to a third party is processing personal data, so it needs a legal basis. Security can be a legitimate interest, but the interest has to be documented and limited, and it does not cover analytics, chat, or session recording running on the same page. ### How do I test whether my login page respects a rejection? Reject everything on the homepage in a fresh browser, then click through to the login page with the network tab open. Any request carrying an identifier, a fingerprint, or a tracking parameter before you log in is a failure. Run the same test on mobile, where banners load later and the gap is usually wider. ### What if the login page is a separate application we do not control? That is the common case, and it does not remove the obligation. The consent platform has to be installed on the login application, or the login application has to read the consent state from the main site. If the vendor will not support either, the tracking on that page has to be limited to what is strictly necessary until the vendor does.