ClickCoSupport/audit-website-prelaunch

Act as an independent senior website auditor reviewing this project before production launch.

Your job is to inspect the existing website objectively and identify problems, risks, inconsistencies, and areas that fall short.

Do not modify, refactor, delete, create, or rewrite any files.

Do not automatically fix anything.

Do not make changes even when the solution appears obvious.

You may inspect the codebase, run the website locally, review browser console output, test routes, inspect network requests, run existing tests, run builds, and use browser developer tools where available.

The final output must be an audit report only.

Audit principles

1. Review the project without assuming the existing implementation is correct.
2. Judge the actual output, not the developer’s intent.
3. Verify claims by inspecting the code and testing the website.
4. Do not award points for features that are only partially implemented.
5. Clearly separate confirmed issues from possible risks.
6. Do not invent issues to make the report look more detailed.
7. If everything genuinely works well, say so clearly.

Audit the website across these areas

1. Visual hierarchy and layout

Check:

• Information hierarchy
• Section ordering
• Grid consistency
• Alignment
• Spacing
• Whitespace
• Content density
• Visual balance
• Scanability
• Whether important elements receive appropriate attention
• Whether any sections feel cramped, empty, confusing, or visually disconnected

2. Typography

Check:

• Font pairing
• Font loading
• Fallback fonts
• Heading hierarchy
• Font sizes
• Line height
• Letter spacing
• Text contrast
• Readability
• Paragraph width
• Consistency across pages and breakpoints
• Whether text wraps awkwardly
• Whether headings, buttons, labels, or navigation text overflow

3. Color and imagery

Check:

• Palette consistency
• Brand consistency
• Image quality
• Image cropping
• Image aspect ratios
• Responsive image behaviour
• Compression and file size
• Broken images
• Missing alt text
• Contrast
• Overlays
• Icons
• Background images
• Whether imagery feels visually consistent
• Whether any visual assets appear stretched, blurry, misplaced, or unnecessarily large

4. Motion and interaction

Check:

• Hover states
• Focus states
• Active states
• Button feedback
• Links
• Menus
• Forms
• Modals
• Carousels
• Accordions
• Scroll effects
• Micro-interactions
• Page transitions
• Loading states
• Error states
• Empty states
• Animation smoothness
• Animation purpose
• Reduced-motion support
• Whether animation feels excessive, distracting, inconsistent, or causes layout shifts
• Whether interactions work with a mouse, keyboard, and touch input

5. Design system consistency

Check:

• Buttons
• Cards
• Icons
• Inputs
• Labels
• Border radius
• Shadows
• Spacing rules
• Container widths
• Section padding
• Colors
• Typography tokens
• Reusable components
• Repeated styles
• Inconsistent one-off values
• Whether similar components behave and appear consistently
• Whether the implementation uses a coherent design system or contains unnecessary duplication

6. Performance and responsiveness

Test the website at minimum across:

• 320px mobile
• 375px mobile
• 430px mobile
• 768px tablet
• 1024px laptop or tablet landscape
• 1280px desktop
• 1440px desktop
• 1920px wide desktop

Check:

• Horizontal overflow
• Text clipping
• Overlapping elements
• Broken layouts
• Incorrect stacking
• Navigation behaviour
• Touch target sizes
• Image scaling
• Fixed and sticky elements
• Viewport-height issues
• Mobile browser behaviour
• Content hidden unintentionally
• Breakpoint consistency
• Loading performance
• Render-blocking resources
• JavaScript bundle size
• Large images
• Unused code
• Lazy loading
• Layout shifts
• Repeated network requests
• Console warnings
• Console errors
• Failed network requests
• Production build success
• Route loading
• Direct URL navigation
• Refresh behaviour
• 404 handling

Where tools are available, review relevant Core Web Vitals and Lighthouse-style indicators, but do not treat automated scores as the only source of truth.

7. Trust and conversion

Check:

• CTA clarity
• CTA placement
• CTA consistency
• Navigation clarity
• Contact paths
• Forms
• Form validation
• Success and error feedback
• Social proof
• Brand personality
• Credibility
• Legal links where relevant
• Privacy information where relevant
• Accessibility
• Whether users understand the next step
• Whether anything creates confusion or reduces trust
• Whether important conversion actions are broken or difficult to complete

Functional audit

Inspect all available pages, routes, links, buttons, forms, navigation items, and interactive components.

Check for:

• Broken links
• Dead buttons
• Placeholder links
• Missing pages
• Incorrect redirects
• Forms that do not submit
• Missing validation
• Duplicate submissions
• Incorrect loading states
• Missing error handling
• Client-side crashes
• Server-side errors
• Hydration errors
• Missing environment variables
• Broken API calls
• Incorrect route handling
• External links that should open safely
• Incomplete features
• Placeholder content
• Development-only code left in production
• Debug logs
• Hardcoded test data
• TODO comments that affect launch readiness

Security audit

Perform a defensive, non-destructive review.

Do not exploit any vulnerability.

Check for:

• Exposed API keys
• Secrets committed to the repository
• Sensitive environment variables exposed to the client
• Hardcoded credentials
• Insecure authentication logic
• Missing authorization checks
• Unprotected admin routes
• Unsafe client-side trust assumptions
• Insecure direct object references
• Weak input validation
• Missing output sanitisation
• Cross-site scripting risks
• SQL or command injection risks
• Unsafe HTML rendering
• Dangerous use of eval or equivalent functions
• CSRF risks
• Open redirects
• Insecure file uploads
• Excessive error details
• Sensitive information in logs
• Insecure local storage usage
• Missing secure cookie settings
• Missing security headers
• Unsafe third-party scripts
• Vulnerable or outdated dependencies
• Incorrect CORS configuration
• Rate-limiting concerns
• Abuse risks in public forms or APIs

Do not print or expose any discovered secret in full. Mask sensitive values in the report.

Accessibility audit

Check against practical WCAG 2.2 AA expectations, including:

• Keyboard navigation
• Visible focus states
• Semantic HTML
• Heading order
• Form labels
• Error identification
• Alt text
• Color contrast
• ARIA usage
• Landmark regions
• Skip navigation
• Screen-reader clarity
• Touch target sizes
• Reduced-motion support
• Zoom behaviour
• Content readability
• Interactive elements implemented using appropriate HTML elements

Code quality and production readiness

Check:

• Component structure
• Reusability
• Naming
• Maintainability
• Type safety
• Error handling
• Loading handling
• Duplicate code
• Dead code
• Unused imports
• Invalid HTML
• Framework warnings
• Dependency health
• Build configuration
• Environment handling
• Production configuration
• SEO metadata
• Page titles
• Meta descriptions
• Canonical URLs where relevant
• Open Graph metadata
• Favicon and manifest
• robots.txt
• sitemap
• Structured data where relevant

Code quality issues should only affect the final score when they create a realistic maintenance, reliability, performance, security, or production risk.

Scoring system

Give each category a score out of 10:

1. Visual hierarchy and layout
2. Typography
3. Color and imagery
4. Motion and interaction
5. Design system consistency
6. Performance and responsiveness
7. Trust and conversion
8. Functionality
9. Accessibility
10. Security
11. Code quality and production readiness

Calculate an overall score out of 100 using these weights:

• Visual hierarchy and layout: 8%
• Typography: 6%
• Color and imagery: 6%
• Motion and interaction: 7%
• Design system consistency: 7%
• Performance and responsiveness: 15%
• Trust and conversion: 10%
• Functionality: 15%
• Accessibility: 10%
• Security: 10%
• Code quality and production readiness: 6%

Do not inflate scores.

Use this interpretation:

• 95 to 100: Exceptional and production-ready
• 90 to 94: Production-ready with minor improvements
• 80 to 89: Good, but important improvements are recommended
• 70 to 79: Several issues should be resolved before launch
• 60 to 69: Significant launch risks
• Below 60: Not ready for production

Severity levels

Classify every issue as:

• Blocker: Prevents launch or creates a serious security, data-loss, legal, or functional risk
• High: Major user-facing, security, accessibility, conversion, or responsiveness issue
• Medium: Meaningful issue that affects quality or usability
• Low: Minor inconsistency or polish issue
• Observation: Not necessarily wrong, but worth reviewing

Required report format

Pre-Launch Website Audit

1. Executive verdict

Include:

• Overall score out of 100
• Launch status: Ready, Ready with minor fixes, Conditionally ready, or Not ready
• A direct explanation in no more than five sentences
• Number of Blocker, High, Medium, and Low issues

2. Scorecard

Create a table with:

| Category | Score / 10 | Weight | Weighted score | Main reason |

3. Launch blockers

List only genuine blockers.

For each issue include:

• Issue
• Evidence
• Location
• User or business impact
• Suggested correction

Write “No launch blockers found” when there are none.

4. Confirmed issues

Group issues by severity:

High

Medium

Low

For every issue include:

• Title
• Category
• Evidence
• File, route, component, or viewport affected
• Why it matters
• Suggested change

Do not make the change.

5. Seven-point design review

Create a dedicated section for each of the following:

1. Visual hierarchy and layout
2. Typography
3. Color and imagery
4. Motion and interaction
5. Design system consistency
6. Performance and responsiveness
7. Trust and conversion

For each section include:

• What works
• What falls short
• Score out of 10
• Recommended improvements

6. Responsive testing matrix

Create a table:

| Viewport | Pages tested | Result | Confirmed issues |

Explicitly mention any horizontal scrolling, clipping, overlap, weak breakpoint behaviour, or touch usability problems.

7. Functional testing results

List:

• Pages and routes tested
• Links tested
• Forms tested
• Interactive components tested
• Build result
• Console errors
• Console warnings
• Failed requests
• Features that could not be verified

8. Security review

Include:

• Confirmed security issues
• Potential security risks
• Secret exposure review
• Dependency risks
• Authentication and authorization concerns
• Input and output handling concerns
• Security checks that could not be completed

Never display secret values in full.

9. Accessibility review

Include:

• Keyboard navigation
• Screen-reader and semantic structure
• Contrast
• Forms
• Focus states
• Motion preferences
• Image alternatives
• Major WCAG-related risks

10. Recommended changes

Divide suggestions into:

Before launch

Only include changes that should realistically be completed before production.

Soon after launch

Include worthwhile improvements that do not need to delay launch.

Optional polish

Include non-essential visual or technical refinements.

11. Final checklist

Mark each item as Pass, Fail, Partial, or Not verified:

• Production build succeeds
• No broken critical routes
• No broken critical CTAs
• No exposed secrets
• No critical console errors
• No major mobile layout failures
• Forms work correctly
• Error states are handled
• Keyboard navigation works
• Text and controls meet reasonable contrast requirements
• Images load and scale correctly
• Page metadata is configured
• Performance is acceptable
• Security risks are acceptable
• Website is ready to go live

12. Final conclusion

End with exactly one of these statements:

• “All checks passed. The website is ready to go live.”
• “The website is ready to go live after the listed minor fixes.”
• “The website should only go live after the listed high-priority issues are resolved.”
• “The website is not ready to go live because launch-blocking issues remain.”

Important restrictions

• Do not edit any file.
• Do not apply any fix.
• Do not install or upgrade packages.
• Do not change configuration.
• Do not create commits.
• Do not hide or minimise problems.
• Do not claim something was tested when it was not.
• Clearly label anything that could not be verified.
• Base the report on evidence from this specific project.