B84%
Quality Score
7
Pages
83
Issues
7.8
Avg Confidence
7.5
Avg Priority
31 Critical30 High22 Medium
>_ Testers.AI
AI Analysis
Textra.Me was tested and 83 issues were detected across the site. The most critical finding was: Tracking pixel detected on textra.me image resource. Issues span Performance, A11y, Other, UX categories. Persona feedback rated Visual highest (7/10) and Content lowest (4/10).
Qualitative Quality
Textra.Me
Category Avg
Best in Category
Pages Tested · 7 screenshots
Homepage
textra.me
textra.me
textra.me
textra.me
textra.me
textra.me
Detected Issues · 83 total
1
Tracking pixel detected on textra.me image resource
CRIT P9
Prompt to Fix
In the page that loads textra.me/images/pixel6_pro_surround-no-cutout.jpg, remove or gate the image to prevent potential tracking unless the user has consented. Implement a consent-check before loading any tracking pixels. If tracking is required, replace with a privacy-preserving equivalent: use a first-party analytics endpoint with anonymized data and avoid setting unique identifiers in query strings. Remove any query parameters that could be used to identify the user (e.g., session or device IDs). Ensure your privacy policy communicates tracking practices and provide opt-out.
Why it's a bug
A tracking beacon (pixel image) appears to load from textra.me, potentially enabling user activity tracking without explicit consent or disclosure. This can lead to cross-site profiling and violates user privacy expectations.
Why it might not be a bug
If the image load is strictly for a visual asset and not used to collect identifiers or behavior, it could be benign. However, the presence of a tracking detection flag indicates risk; without consent and without disclosure, it should still be considered a potential privacy issue.
Suggested Fix
Audit and remove or guard tracking pixel loads. Ensure tracking pixels only load after explicit user consent and privacy notice. Prefer first-party analytics with anonymized data or privacy-preserving measurement. Remove any unique identifiers in image URLs, and avoid sending device identifiers via query params. If tracking is necessary, implement a consent banner and a clear privacy policy entry describing data collection.
Why Fix
Fixing tracking pixel exposure reduces risk of non-consensual user profiling, improves trust, and helps with regulatory compliance (e.g., GDPR/CCPA).
Route To
Web Analytics Privacy/Frontend Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
POTENTIAL ISSUE: Tracking request detectedNetwork:
GET https://textra.me/images/pixel6_pro_surround-no-cutout.jpg - Status: N/A2
Third-party font scripts and resources enable cross-site tracking
CRIT P9
Prompt to Fix
Actionable prompt: 'Replace all third-party font loading with self-hosted font files and inline CSS or local font-face rules. Remove fonts.googleapis.com/fonts.gstatic.com URL references. If retention of third-party fonts is required, implement a user consent prompt before loading and enforce CSP to only load fonts after consent. Provide a fallback to system fonts if consent is declined, and ensure fonts are served from the same origin.'
Why it's a bug
The page loads font assets and a webfont loader from third-party domains (fonts.googleapis.com, fonts.gstatic.com, ajax.googleapis.com). These requests can facilitate cross-site tracking and IP address exposure to Google/third parties without explicit user consent or clear privacy disclosures. Even though fonts may be essential for UI, the data sharing risk is non-trivial and should be addressed.
Why it might not be a bug
If a strict consent mechanism and privacy disclosures are in place for any third-party resource usage, this could mitigate risk. However, no consent indicators or disclosures are visible in the provided network activity, making the risk valid.
Suggested Fix
Self-host fonts and any font-loading logic to avoid third-party font services. Alternatively, implement a user consent prompt before loading fonts from Google and enforce a Content-Security-Policy that blocks third-party font loading until consent is given. Consider lazy-loading fonts after consent and migrating assets to the same-origin domain.
Why Fix
Eliminating or gating third-party font loading reduces exposure of IP addresses and potential user profiling by third parties, aligning with data minimization and user privacy expectations.
Route To
Frontend Engineer / Privacy Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Network:
https://fonts.googleapis.com/css?family=Outfit:100,200,300,regular,500,600,700,800,900%7CRoboto:300,regular; https://fonts.gstatic.com/s/outfit/v15/QGYvz_MVcBeNP4NJtEtq.woff2; https://fonts.gstatic.com/s/roboto/v51/KFO7CnqEu92Fr1ME7kSn66aGLdTylUAMa3yUBA.woff2; https://ajax.googleapis.com/ajax/libs/webfont/1.6.26/webfont.js3
AI endpoint detection log exposed in client-side code
CRIT P9
Prompt to Fix
In the client-side code, remove or guard the 'AI/LLM ENDPOINT DETECTED' debug logs. Do not reveal internal AI endpoint usage in production. Implement a development-only flag to emit such diagnostics and ensure no sensitive endpoint data is exposed.
Why it's a bug
The page logs '⚠️ AI/LLM ENDPOINT DETECTED' in the console during page load, which leaks internal AI/LLM usage to end users and could reveal endpoints or internal wiring. This is a clear GenAI artifact that compromises security/privacy and confuses users.
Why it might not be a bug
If this log is intended for developers only, it should be gated behind a development flag. Without such gating, users may see internal diagnostics.
Suggested Fix
Remove the console log or guard it behind an environment flag (e.g., if (process.env.NODE_ENV === 'development') { console.log(...) }), and avoid any mentions of LLM endpoints in production.
Why Fix
Prevent potential data leakage and maintain professional UX; reduce attack surface by not advertising internal AI endpoints.
Route To
Frontend Engineer / Security Engineer
Page
Tester
Jason · GenAI Code Analyzer
Technical Evidence
Console:
⚠️ AI/LLM ENDPOINT DETECTED