B-82%
Quality Score
11
Pages
142
Issues
8.0
Avg Confidence
7.8
Avg Priority
44 Critical64 High17 Medium
>_ Testers.AI
AI Analysis
Kmart scored B- (82%) with 142 issues across 8 tested pages, ranking #5 of 7 Australian retail sites. That's 21 more than the 120.6 category average (57th percentile).
Top issues to fix immediately: "Critical: External resources failing to load due to DNS resolution err" — Audit all external resource URLs failing to load, verify DNS resolution for those hostnames, and consider hosting cri...; "Informative images use non-descriptive or truncated alt text" — Provide meaningful, concise alt text for each informative image that describes the product and its variant, e; "Failed to load external resources due to DNS resolution errors" — Audit and validate all external asset URLs.
Weakest area — accessibility (5/10): Likely issues with contrast, font sizing, and keyboard navigation; needs more accessible patterns and ARIA labeling.
Quick wins: Simplify the hero area and reduce the number of carousels to improve focus, load speed, and quick access to popular.... Improve accessibility and readability: increase contrast, use scalable typography, ensure keyboard focus indicators,....
Qualitative Quality
Kmart
Category Avg
Best in Category
Pages Tested · 11 screenshots
Homepage
www.kmart.com.au
www.kmart.com.au
www.kmart.com.au
www.kmart.com.au
www.kmart.com.au
www.kmart.com.au
www.kmart.com.au
www.kmart.com.au
www.kmart.com.au
www.kmart.com.au
Detected Issues · 125 total
1
Hardcoded insecure HTTP endpoint detected in AI/test harness
CRIT P9
Prompt to Fix
In the AI-generated code, remove the hardcoded HTTP URL. Use https://www.kmart.com.au/search as the default endpoint and make it configurable via environment variables or a config file. Validate TLS, implement endpoint normalization, and add retry with backoff if the endpoint is unreachable.
Why it's a bug
The UI/test harness references an HTTP URL (http://www.kmart.com.au/search/) which is insecure and should be HTTPS. Hardcoded endpoints reduce configurability and risk data exposure via man-in-the-middle attacks.
Why it might not be a bug
If the environment purposely uses a mocked/test HTTP endpoint, this could be intentional; however, for production or regression testing, HTTPS and configurable endpoints are essential.
Suggested Fix
Replace hardcoded HTTP URL with a configurable HTTPS endpoint (e.g., https://www.kmart.com.au/search). Centralize endpoints in a config file or environment variable and validate TLS. Add retry/backoff as appropriate.
Why Fix
Using HTTPS and configurable endpoints improves security, reliability, and maintainability of the AI-generated codebase.
Route To
Security Engineer / Backend Engineer
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
[ERROR] Failed to load resource: the server responded with a status of 403 ()Network:
GET http://www.kmart.com.au/search/ - Status: 4032
AI/LLM endpoints triggered on page load causing performance/privacy risk
CRIT P9
Prompt to Fix
Audit all AI/LLM related script loads on the homepage. Remove or lazy-load any calls to AI endpoints (e.g., clrt.ai) until user consent is obtained. Implement a consent banner, defer the script injection until consent, and consider a server-side or proxy-based approach to minimize data exposure. Provide a follow-up PR with updated code paths and a smoke test plan.
Why it's a bug
The console shows repeated AI/LLM endpoint detections (⚠️ AI/LLM ENDPOINT DETECTED) and network requests to AI-related domains (e.g., clrt.ai) occurring on initial page load, which can leak context, add latency, and violate user consent expectations for AI integration.
Why it might not be a bug
If these AI endpoints are strictly for analytics or features behind explicit user consent, the issue may be mitigated by consent controls; however, the screenshot provides no evidence of a consent flow for such calls.
Suggested Fix
Defer or lazy-load AI/LLM related scripts until user action or explicit consent is given. Move AI calls behind a clearly labeled opt-in, and ensure privacy/compliance checks are in place. Consider server-side processing or a proxy to minimize data exposure.
Why Fix
Reduces unnecessary data exposure, improves initial page load performance, and aligns with privacy best practices for GenAI integrations.
Route To
Frontend Engineer (Performance & Privacy) / Privacy Engineer
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
⚠️ AI/LLM ENDPOINT DETECTEDNetwork:
GET https://js.clrt.ai/13262.js - Status: N/A3
Extensive third-party tracking on wishlist page enabling cross-site data sharing
CRIT P9
Prompt to Fix
Paste this prompt into a coding assistant: 'On the wishlist page, gate all third-party tags (Google GTM/Analytics, Google Ads/DoubleClick, Optimizely, cnstrc, Tealium, Yottaa, etc.) behind a consent decision. Remove or obfuscate identifiers sent to third parties (avoid including auid, cid, match_id in query strings or payloads). Enable IP anonymization in Analytics and ensure no PII is transmitted to external services. Implement a CMP (Consent Management Platform) with a visible banner and store user consent preferences. Switch to server-side tagging or first-party analytics where possible. Update privacy policy to reflect data sharing with these partners and provide a clear opt-out path. Ensure Do Not Track is respected where applicable.'
Why it's a bug
The wishlist page loads and executes a large number of third-party analytics/tracking scripts (Google GTM/Analytics, Google Ads, DoubleClick, Optimizely, cnstrc CNSTRCT/Tealium-like networks, Yottaa). These calls transmit user behavior data, navigation data, device information, and potentially identifiers to external domains without a visible consent gating mechanism. Several requests include identifiers (e.g., auid, cid) and page context (dt, u23, match_id) that could be correlated across sites, creating cross-site profiling risk and potential regulatory concerns.
Why it might not be a bug
Some teams rely on standard analytics and marketing tags to optimize the user experience; if consent is handled elsewhere or data is sufficiently anonymized, this could be acceptable. However, the logs show no clear, explicit consent gating in the captured activity and many third-party transmissions occur unblocked, indicating potential surprise data sharing for users who have not consented.
Suggested Fix
Implement a robust consent management workflow that gates all third-party tags (GTM/Analytics, Google Ads/DoubleClick, Optimizely, cnstrc, Tealium, Yottaa, etc.) behind user consent. Remove or minimize sending potentially sensitive identifiers (auid, cid, match_id) to third parties, and enable IP anonymization where available. Prefer first-party analytics or server-side tagging to reduce client-side data exposure. Ensure the privacy policy and consent UI clearly explain data sharing with these partners and provide an easy opt-out.
Why Fix
Mitigates cross-site tracking and data sharing risk, improves user trust, and supports regulatory compliance (e.g., consent requirements, data minimization).
Route To
Privacy Engineer / Frontend Engineer (Tag Management & Analytics Integrations)
Page
Tester
Pete · Privacy Networking AnalyzerTechnical Evidence
Console:
⚠️ POTENTIAL ISSUE: Tracking request detected on wishlist page; multiple third-party scripts loading (gtm.js, utag.js, etc).Network:
GET https://www.googletagmanager.com/gtm.js?id=GTM-WLL6; GET https://tags.kmart.com.au/main/prod/utag.js; POST https://ad.doubleclick.net/activity; POST https://analytics.google.com/g/collect?v=2&tid=G-CXF7KQVQ46&...; POST https://www.kmart.com.au/TL2AdQ/F/S/8GVMHxEkRNLW/at3YQJ7c7htuLb/JnAvJhNA/eQ92dF0f/MUgB; GET https://cnstrc.com/js/cust/kmart-aus_5l1eM1.js; GET https://ac.cnstrc.com/recommendations/v1/pods/bestsellers_products?c=...; GET https://cdn.optimizely.com/js/2758580386.js; GET https://www.googleadservices.com/pagead/conversion/1042281642/?random=...&label=FuhMCNuu4tYDEKrp__AD&...; GET https://www.google.com/gmp/conversion;dc_pre=...; etc.