ChatGPT prompt for website analysis

Act as a senior web engineer performing a focused technical analysis of [WEBSITE OR PAGE]. The analysis goal is [ANALYSIS GOAL], the site uses [TECH STACK OR KNOWN CONSTRAINTS], and the relevant evidence is [AVAILABLE EVIDENCE]. The priority audience or user journey is [PRIMARY USER JOURNEY].

First state what you can verify from the supplied material and what requires browser, repository, analytics, server-log, or production access. Do not imply you fetched, ran, or measured anything that I did not provide.

Then produce a report with these sections:
1. Scope and evidence: pages or components assessed, assumptions, and important unknowns.

2. Findings: separate UX/content, performance, accessibility, security/privacy, SEO/technical discovery, and maintainability. For each concrete finding, give severity (blocker, high, medium, low), evidence, likely user or business impact, and confidence.
3. Prioritized fix plan: order work by impact, effort, dependency, and risk. Distinguish quick fixes from changes needing design, product, or security review.
4. Implementation guidance: provide working, well-explained code only where the evidence supports a specific fix. Name the file or component context assumed. Include error states, loading behavior, mobile and keyboard use, missing data, slow connections, and no-JavaScript behavior when relevant.
5. Validation plan: give reproducible checks, including affected browsers/devices, performance metrics, accessibility checks, regression tests, and a rollback signal for risky changes.

Do not invent analytics results, vulnerabilities, rankings, or compliance status. Treat security and legal matters as items for qualified review, not certifications. Ask up to 3 clarifying questions only if a required input is missing.

Before answering, check that every recommendation maps to supplied evidence or a clearly labeled assumption, and that code changes do not introduce inaccessible controls, unescaped user content, or broken responsive behavior.

Audit [PAGE OR COMPONENT] for accessibility issues affecting [USER JOURNEY]. Review this evidence: [CODE, SCREENSHOTS, OR TEST RESULTS]. Assess keyboard order, focus visibility, semantic structure, labels and error messages, color contrast, headings, dialogs, dynamic updates, and screen-reader announcements. Return findings with severity, affected users, evidence, and a concrete remediation. For each code fix, preserve native HTML semantics where possible and explain how to test with keyboard and a screen reader. Do not claim WCAG conformance from partial evidence. Ask up to 3 questions only if required information is absent. Check that fixes work on mobile and do not depend on color alone.

Diagnose performance problems for [URL OR PAGE] using [PERFORMANCE EVIDENCE]. The important device and connection profile is [USER PROFILE], and the target interaction is [CRITICAL JOURNEY]. Explain what the evidence establishes versus what needs profiling. Identify likely LCP, INP, CLS, JavaScript, image, font, caching, third-party, and network contributors. Rank fixes by expected effect, implementation effort, and regression risk. Include framework-appropriate code only for supported changes, plus precise validation steps using lab and field measurements. Do not fabricate performance measurements. Ask up to 3 questions only if an input is missing. Check that improvements do not delay functionality or worsen accessibility.

Review the architecture of [CODE OR REPOSITORY AREA] for a feature that must support [REQUIREMENTS]. The stack is [TECH STACK], and the known failures or maintenance concerns are [CURRENT PROBLEMS]. Map data flow, state ownership, component boundaries, error handling, and test seams. Return a short diagnosis, a staged refactor plan, dependency risks, and before-and-after interface examples. Preserve behavior unless a change is explicitly proposed. Include edge cases such as absent data, retries, concurrent requests, stale state, and unmounting. Do not rewrite unrelated files or invent APIs. Ask up to 3 questions only if needed. Check that the proposed design is testable and avoids duplicated sources of truth.