A-91%
Quality Score
2
Pages
17
Issues
8.2
Avg Confidence
8.1
Avg Priority
8 Critical8 High1 Medium
>_ Testers.AI
AI Analysis
Big W scored A- (91%) with 17 issues across 6 tested pages, ranking #2 of 7 Australian retail sites. That's 104 fewer than the 120.6 category average (71st percentile).
Top issues to fix immediately: "Excessive white space between content sections causing long, tedious s" — Audit vertical rhythm across sections; "DNS resolution failures causing resource load errors (ERR_NAME_NOT_RES" — Identify failing hostnames from the network requests, verify DNS records and domain resolutions in the deployment env...; "HTTP/2 protocol errors causing widespread resource load failures (ERR_" — Investigate server-side HTTP/2 configuration, TLS settings, and any proxies/load balancers (e.
Weakest area — usability (5/10): Finding categories and specific products may require multiple clicks; header/search aren't immediately obvious.
Quick wins: Improve top navigation clarity with clearer categories and a persistent, prominent search bar. Prioritize key promotions with a clean, scannable layout and provide a skip-to-content option.
Qualitative Quality
Big W
Category Avg
Best in Category
Pages Tested · 2 screenshots
Homepage
www.bigw.com.au
Detected Issues · 17 total
1
Third-party tracking scripts loaded without explicit user consent
CRIT P9
Prompt to Fix
Paste the following prompt into an AI coding assistant: 1) Audit all third-party trackers loaded on the page (GTM, Insider, MPulse, AppDynamics) and confirm whether user consent is required for each. 2) Implement a consent management flow that defers loading of these scripts until consent is given. 3) Replace or minimize third-party data sharing by using first-party analytics where feasible. 4) Ensure trackers do not collect or transmit any PII and that data is minimized and anonymized where possible. 5) Add guardrails to prevent automatic re-enablement after consent changes without user interaction.
Why it's a bug
Multiple third-party tracking scripts are loaded from external domains (Google Tag Manager, Insider, MPulse, AppDynamics). These scripts can collect user behavior and cross-site data and may operate without an explicit consent gate visible in the provided activity, increasing risk of profiling and data sharing with third parties.
Why it might not be a bug
Consent mechanisms may be implemented outside of the captured logs (e.g., in a cookie banner or CMP). If consent gating exists, third-party data collection should be restricted until consent is given; otherwise, this remains a privacy risk.
Suggested Fix
Implement explicit, user-visible consent gating before loading any third-party analytics or tracking scripts. Consider migrating to a first-party analytics solution or loading trackers only after consent. Ensure data minimization (no personal data sent to third parties), and apply strict data sharing controls and regional restrictions where possible.
Why Fix
Reduces risk of user profiling without consent, aligns with privacy regulations, and preserves user trust.
Route To
Frontend Privacy Engineer
Page
Tester
Pete · Privacy Networking AnalyzerTechnical Evidence
Console:
Consent gating not observed in the captured logs; third-party trackers loadedNetwork:
GET https://www.googletagmanager.com/gtm.js?id=GTM-MWKMRZ8; GET https://bigwprod.api.useinsider.com/ins.js?id=10010250; GET https://s.go-mpulse.net/boomerang/62JC6-9JELE-Q7END-4LG2X-ZBARN; GET https://cdn.appdynamics.com/adrum/adrum-20.8.0.3230.js2
Exposed Google Maps API key in client-side request
CRIT P9
Prompt to Fix
Paste the following into a development AI: 1) Remove client-side exposure of Google Maps API keys. 2) Implement restricted API keys with HTTP referrer restrictions and rotate keys. 3) If possible, route map API usage through a server-side proxy or use a Maps embed that does not expose credentials. 4) Search the codebase for any other instances of exposed credentials and remediate. 5) Add security checks to CI to detect API keys in client bundles or logs.
Why it's a bug
The Maps JavaScript API request contains a public API key visible in the URL. Exposing API keys in client-side code enables potential misuse, quota abuse, and possible indirect privacy risks through downstream services.
Why it might not be a bug
If the API key is strictly restricted (referrers, IPs, domains) and usage is monitored, the risk is reduced but not eliminated; client-side exposure still presents a security/privacy concern.
Suggested Fix
Do not embed API keys in client-side requests. Use restricted API keys with HTTP referrer restrictions, rotate keys, and/or proxy map requests through a secure server-side component. Move to a server-side retrieval flow or use a Maps embed that does not expose credentials. Audit all client-side API usages to ensure keys are not exposed in source maps or logs.
Why Fix
Prevents credential leakage and potential abuse of API quotas, reducing downstream privacy/security risks and preserving user trust.
Route To
Security / Frontend Engineer
Page
Tester
Pete · Privacy Networking AnalyzerTechnical Evidence
Console:
Maps API key visible in URL in network callNetwork:
GET https://maps.googleapis.com/maps/api/js?callback=initMap&loading=async&key=[REDACTED]3
Hardcoded Google Maps API key exposed in client-side URL
CRIT P9
Prompt to Fix
Actionable fix: Remove hardcoded API keys from frontend code. Implement server-side retrieval or a secure proxy for Google Maps JavaScript API. Apply domain/IP restrictions on the key, disable logging of keys, and ensure no API keys appear in any console or network request URL during page load.
Why it's a bug
The console/network logs reveal the Google Maps API key embedded in the client-side request URL. Exposing API keys in frontend code/logs enables misuse, quota drains, and potential unauthorized access. This is a high-severity security risk.
Why it might not be a bug
If the key is a dummy or restricted by domain and only used in a non-production environment, it could reduce risk, but exposure in logs still constitutes a critical vulnerability and should not rely on restrictions alone.
Suggested Fix
Move API keys to secure server-side environment configurations, implement a proxy to call Google Maps APIs, apply strict HTTP referrer/domain restrictions, enable API key restrictions, and ensure keys are not logged or exposed in any client-side code or network traces.
Why Fix
Protects credentials, prevents abuse/costs, and brings the app into acceptable security hygiene for production deployments.
Route To
Security Engineer / Frontend Engineer
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
GET https://maps.googleapis.com/maps/api/js?callback=initMap&loading=async&key=AIzaSyBf4xPm5zBcehMMEqR5e802fpJnsqT3k2U - Status: N/ANetwork:
https://maps.googleapis.com/maps/api/js?callback=initMap&loading=async&key=AIzaSyBf4xPm5zBcehMMEqR5e802fpJnsqT3k2U