This check detects a geolocation request during initial page load or before the user has chosen a feature that needs their location.
Why this matters
Location is sensitive data. An unexplained prompt creates distrust, interrupts the page, and can lead users to deny access permanently even when a later feature would have a valid need.
How to fix it
- Ask only after an explicit action such as “Use my location.”
- Explain the benefit and whether precise or approximate location is needed.
- Provide a manual city, postcode, or address option when the task can support it.
- Handle denial and errors with a safe unavailable state rather than repeatedly prompting or silently substituting data.
When the finding appears across many URLs, fix the shared component or layout that produces it instead of patching generated HTML page by page. Recheck representative templates and responsive states after deployment so the correction does not create a regression elsewhere.
How to verify the fix
Use a fresh permission state and confirm the page makes no geolocation request on load. Start the relevant feature, review the explanation, and test granted, denied, and unavailable outcomes.
Keep before-and-after evidence for the affected URL, original output, correction, and verification method. If markup changes after load, test consent states, localization, responsive variants, and client-side navigation because the initial HTML and rendered DOM can differ.