B+87%
Quality Score
6
Pages
92
Issues
7.9
Avg Confidence
7.7
Avg Priority
35 Critical37 High20 Medium
>_ Testers.AI
AI Analysis
Bolt was tested and 92 issues were detected across the site. The most critical finding was: Unconsented third-party tracking on enterprise page. Issues span Security, Performance, A11y, Other categories. Persona feedback rated Visual highest (9/10) and Accessibility lowest (6/10).
Qualitative Quality
Bolt
Category Avg
Best in Category
Pages Tested · 6 screenshots
Homepage
bolt.new
bolt.new
bolt.new
bolt.new
bolt.new
Detected Issues · 92 total
1
Unconsented third-party tracking on enterprise page
CRIT P9
Prompt to Fix
In the enterprise page, remove unnecessary third-party trackers or gate them behind a consent banner. Add a CMP and ensure tag loading respects user consent. For each tracker, configure it to operate in a privacy-friendly mode (e.g., anonymize IPs, disable cross-site collection where possible, set ad_storage=denied in GTM/GA4). Replace or supplement with a first-party analytics solution that complies with data minimization.
Why it's a bug
The enterprise page loads multiple third-party tracking scripts (Google Tag Manager, Facebook Pixel, LinkedIn Insight, Reddit, TikTok, etc.) without clear user consent, enabling cross-site user tracking and data sharing to advertising networks. This exposure risks privacy compliance (GDPR/CCPA) and erodes user trust.
Why it might not be a bug
If a robust Consent Management Platform (CMP) is already implemented and trackers only load after explicit consent, this would be expected behavior. The logs provided show trackers being loaded without evident consent gating, so treat as a bug unless consent is confirmed.
Suggested Fix
Implement or verify a Consent Management Platform to gate all third-party trackers behind explicit user consent. Prefer first-party analytics, or ensure third-party tags are loaded only after consent. Minimize data shared with third parties and consider anonymizing identifiers. Add clear privacy notices and a 'Do Not Track' option.
Why Fix
Protect user privacy, reduce regulatory risk, and restore user trust by ensuring trackers are loaded only with consent and data sharing is minimized.
Route To
Privacy Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
⚠️ POTENTIAL ISSUE: Tracking request detectedNetwork:
GET https://www.googletagmanager.com/gtm.js?id=GTM-58KJM59B; GET https://px.ads.linkedin.com/collect?v=2&fmt=js&pid=8244692&time=1774468627251&li_adsId=89283d7f-fdeb-4292-afa0-045a590e78d0&url=https%3A%2F%2Fbolt.new%2Fenterprise%2F2
PII-like identifiers transmitted to third-party trackers in URL query strings
CRIT P9
Prompt to Fix
In the example Reddit rp.gif request, remove all PII-like parameters from the query string (uuid, aaid, idfa, em, external_id, pn, etc.). Replace with non-identifying tokens or omit entirely. If identifiers are required for functionality, move them to a server-side, first-party flow and/or use hashed/opaque IDs. Implement a consent gate before loading third-party trackers and ensure privacy disclosures are visible.
Why it's a bug
URLs to third-party trackers include parameters such as uuid, aaid, idfa, em, external_id, pn in the query string. These keys map to unique device/user identifiers or potential personal data. Even if values are empty, the presence of PII-keyed parameters in client requests enables cross-site data collection and profiling by ad/analytics networks, which can violate data minimization principles and privacy regulations.
Why it might not be a bug
Some parameters may be placeholders and not carrying actual data in this instance; trackers often expect these keys. However, the very existence of PII-like keys in client-side requests to third parties creates a real risk of leakage and profiling, so this should still be treated as a high-priority concern.
Suggested Fix
Remove PII-like identifiers from client-side tracking requests. Replace with opaque, server-generated tokens or hashed identifiers. Gate all third-party trackers behind a user consent mechanism and/or move telemetry to first-party, server-side analytics. Do not pass uuid, aaid, idfa, em, external_id, pn in query strings to third parties.
Why Fix
Reduces risk of personal data leakage, improves regulatory compliance (e.g., GDPR/CCPA), and preserves user trust by limiting third-party data collection.
Route To
Privacy Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
⚠️ POTENTIAL ISSUE: Tracking request detectedNetwork:
GET https://alb.reddit.com/rp.gif?ts=1774468655471&id=a2_ghqj0ktog57o&event=PageVisit&m.value=&m.transactionId=&m.customEventName=&m.products=&m.conversionId=&uuid=7dcf330c-e5d8-4d15-b284-bd03ff26c525&aaid=&em=&pn=&external_id=&idfa=&integration=gtm&partner=&partner_version=&opt_out=0&sh=800&sw=600&v=rdt_79aa2193&dpm=&dpcc=&dprc=3
AI/LLM endpoint calls detected on page load
CRIT P9
Prompt to Fix
Audit the page for any on-load calls to AI/LLM endpoints. Remove or defer them behind a user action, ensure endpoints are server-side or behind consent, and remove the 'AI endpoint detected' diagnostic logs.
Why it's a bug
Console logs show multiple '⚠️ AI/LLM ENDPOINT DETECTED' messages, indicating the page is calling or exposing AI endpoints during initial paint. This can leak user data, increase attack surface, and degrade performance.
Why it might not be a bug
If these are intentional development flags or instrumentation disabled in production, they should be gated behind a feature flag; otherwise it's risky.
Suggested Fix
Remove on-load AI endpoint calls or ensure they're only triggered after explicit user action and with proper consent. Remove the diagnostic log and restrict AI calls to server-side processing where possible. Add privacy/compliance review.
Why Fix
Reduces data leakage risk, improves load performance, and aligns with privacy expectations.
Route To
Frontend/Platform & Security Engineer
Page
Tester
Jason · GenAI Code Analyzer
Technical Evidence
Console:
⚠️ AI/LLM ENDPOINT DETECTED appears in console during page load.Network:
AI endpoint calls detected on load (endpoint URL not visible in logs).