completed

HTTP 200

0 redirects

38 checks

Website audit scorecard for readinghabit.site

The scanner fetched the public page, extracted deterministic facts, and stored scored results across SEO / AEO, security, accessibility, and design.

Submitted

https://readinghabit.site

Final URL

https://readinghabit.site

Created

Jul 13, 2026, 12:12 PM

Safe fetch

276 ms

Four-score result

Close to ready (Strong): 33 passed, 5 failed, and 0 unknown. Strongest area: Security. Weakest area: Design.

Overall

out of 100

SEO / AEO

out of 100

110/114 rule points

Security

100

out of 100

76/76 rule points

Accessibility

100

out of 100

94/94 rule points

Design

out of 100

74/110 rule points

Why this scored this way

Scores are deterministic: each category earns rule points for verified public signals and loses points for failed checks. Unknown checks are shown separately instead of guessed.

Category point breakdown

SEO / AEO110/114

Security76/76

Accessibility94/94

Design74/110

Biggest score-losing checks

medium

Design

Trust signals

Detected 0 trust-signal keyword occurrence(s).

medium

Design

Rendered speed signals

DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.

medium

Design

Rendered layout ergonomics

Horizontal overflow: 0px. Small tap targets: 39.

low

Design

Runtime console health

Detected 4 console error(s) and 0 uncaught page error(s) during render.

Recommendations

Score-losing issues ordered by remediation priority, severity, and score impact.

5 fixes

7 opportunities

9 insights

fail

medium

Design

Priority 13

Fix rendered layout ergonomics

-9 rule pts

What failed

The browser-rendered page has layout or tap-target issues.

Evidence

Horizontal overflow: 0px. Small tap targets: 39.

Priority

Priority 13: fix during launch polish.

Why it matters

Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.

How to fix it

Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Fix rendered layout ergonomics.
- Scanner check: Rendered layout ergonomics.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 13; lower numbers are more urgent.
- Score impact: 9 rule points lost.
- Evidence: Horizontal overflow: 0px. Small tap targets: 39.
- What needs attention: The browser-rendered page has layout or tap-target issues.
- Why it matters: Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Priority 14

Improve rendered speed signals

-10 rule pts

What failed

The browser-rendered page shows slow or heavy speed signals.

Evidence

DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.

Priority

Priority 14: fix during launch polish.

Why it matters

Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.

How to fix it

Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Improve rendered speed signals.
- Scanner check: Rendered speed signals.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 14; lower numbers are more urgent.
- Score impact: 10 rule points lost.
- Evidence: DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.
- What needs attention: The browser-rendered page shows slow or heavy speed signals.
- Why it matters: Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Priority 16

Add trust signals

-10 rule pts

What failed

The page does not expose detectable proof, customer, review, security, or credibility signals.

Evidence

Detected 0 trust-signal keyword occurrence(s).

Priority

Priority 16: lower-risk cleanup after urgent launch blockers.

Why it matters

Trust signals reduce hesitation when strangers see the product for the first time.

How to fix it

Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Add trust signals.
- Scanner check: Trust signals.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 16; lower numbers are more urgent.
- Score impact: 10 rule points lost.
- Evidence: Detected 0 trust-signal keyword occurrence(s).
- What needs attention: The page does not expose detectable proof, customer, review, security, or credibility signals.
- Why it matters: Trust signals reduce hesitation when strangers see the product for the first time.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

low

Design

Priority 15

Fix runtime browser errors

-7 rule pts

What failed

The rendered page produced console or uncaught JavaScript errors.

Evidence

Detected 4 console error(s) and 0 uncaught page error(s) during render.

Priority

Priority 15: fix during launch polish.

Why it matters

Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.

How to fix it

Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Fix runtime browser errors.
- Scanner check: Runtime console health.
- Category: Design.
- Status: fail.
- Severity: low.
- Priority: 15; lower numbers are more urgent.
- Score impact: 7 rule points lost.
- Evidence: Detected 4 console error(s) and 0 uncaught page error(s) during render.
- What needs attention: The rendered page produced console or uncaught JavaScript errors.
- Why it matters: Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

low

SEO / AEO

Priority 24

Add an LLM-readable product file

-4 rule pts

What failed

The scan did not find llms.txt or .well-known/llms.txt.

Evidence

HTTP 404 returned for llms_txt.

Priority

Priority 24: lower-risk cleanup after urgent launch blockers.

Why it matters

A short LLM-readable file can help answer engines and AI tools summarize your product accurately.

How to fix it

Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Add an LLM-readable product file.
- Scanner check: LLM-readable file.
- Category: SEO / AEO.
- Status: fail.
- Severity: low.
- Priority: 24; lower numbers are more urgent.
- Score impact: 4 rule points lost.
- Evidence: HTTP 404 returned for llms_txt.
- What needs attention: The scan did not find llms.txt or .well-known/llms.txt.
- Why it matters: A short LLM-readable file can help answer engines and AI tools summarize your product accurately.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

Score aggregation details

Category scores come from earned rule points divided by available rule points. Failed checks are ordered by severity and score lost.

96/100

12 pass, 1 fail, 0 unknown

SEO / AEO

Severity mix: 1 critical, 7 high, 3 medium, 2 low.

low

LLM-readable file

-4 rule pts

HTTP 404 returned for llms_txt.

100/100

6 pass, 0 fail, 0 unknown

Security

Severity mix: 2 critical, 3 high, 0 medium, 0 low.

No failed checks in this category.

100/100

8 pass, 0 fail, 0 unknown

Accessibility

Severity mix: 0 critical, 3 high, 5 medium, 0 low.

No failed checks in this category.

67/100

7 pass, 4 fail, 0 unknown

Design

Severity mix: 0 critical, 3 high, 6 medium, 2 low.

medium

Trust signals

-10 rule pts

Detected 0 trust-signal keyword occurrence(s).

medium

Rendered speed signals

-10 rule pts

DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.

medium

Rendered layout ergonomics

-9 rule pts

Horizontal overflow: 0px. Small tap targets: 39.

Full check list

Failed, unknown, and passed checks are all shown so the report is transparent even when public data is partial.

Showing failed checks.

Failed checks

These checks need attention.

fail

low

SEO / AEO

LLM-readable file

0/4

HTTP 404 returned for llms_txt.

Failed: earned 0 of 4 points.

Priority: Priority 24: lower-risk cleanup after urgent launch blockers.

Why it matters: A short LLM-readable file can help answer engines and AI tools summarize your product accurately.

Fix: Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Add an LLM-readable product file.
- Scanner check: LLM-readable file.
- Category: SEO / AEO.
- Status: fail.
- Severity: low.
- Priority: 24; lower numbers are more urgent.
- Score impact: 4 of 4 rule points lost.
- Evidence: HTTP 404 returned for llms_txt.
- What needs attention: The scan did not find llms.txt or .well-known/llms.txt.
- Why it matters: A short LLM-readable file can help answer engines and AI tools summarize your product accurately.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Trust signals

0/10

Detected 0 trust-signal keyword occurrence(s).

Failed: earned 0 of 10 points.

Priority: Priority 16: lower-risk cleanup after urgent launch blockers.

Why it matters: Trust signals reduce hesitation when strangers see the product for the first time.

Fix: Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Add trust signals.
- Scanner check: Trust signals.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 16; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: Detected 0 trust-signal keyword occurrence(s).
- What needs attention: The page does not expose detectable proof, customer, review, security, or credibility signals.
- Why it matters: Trust signals reduce hesitation when strangers see the product for the first time.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Rendered speed signals

0/10

DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.

Failed: earned 0 of 10 points.

Priority: Priority 14: fix during launch polish.

Why it matters: Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.

Fix: Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Improve rendered speed signals.
- Scanner check: Rendered speed signals.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 14; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.
- What needs attention: The browser-rendered page shows slow or heavy speed signals.
- Why it matters: Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

low

Design

Runtime console health

0/7

Detected 4 console error(s) and 0 uncaught page error(s) during render.

Failed: earned 0 of 7 points.

Priority: Priority 15: fix during launch polish.

Why it matters: Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.

Fix: Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Fix runtime browser errors.
- Scanner check: Runtime console health.
- Category: Design.
- Status: fail.
- Severity: low.
- Priority: 15; lower numbers are more urgent.
- Score impact: 7 of 7 rule points lost.
- Evidence: Detected 4 console error(s) and 0 uncaught page error(s) during render.
- What needs attention: The rendered page produced console or uncaught JavaScript errors.
- Why it matters: Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Rendered layout ergonomics

0/9

Horizontal overflow: 0px. Small tap targets: 39.

Failed: earned 0 of 9 points.

Priority: Priority 13: fix during launch polish.

Why it matters: Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.

Fix: Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Fix rendered layout ergonomics.
- Scanner check: Rendered layout ergonomics.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 13; lower numbers are more urgent.
- Score impact: 9 of 9 rule points lost.
- Evidence: Horizontal overflow: 0px. Small tap targets: 39.
- What needs attention: The browser-rendered page has layout or tap-target issues.
- Why it matters: Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

Public report link

Markdown export

Share the website audit report

Copy a public report link or a Markdown version with scores, fixes, opportunities, insights, and a normal link back to the scanned site.

Share preview

readinghabit.site website audit report

Close to ready: 91/100 overall, with prioritized fixes for SEO, security, accessibility, and design.

Public report link

Markdown report

# readinghabit.site Website Scan

Scanned URL: [https://readinghabit.site](https://readinghabit.site)
Report URL: /scan/readinghabit-site-91-launch-readiness-report-dfa80783
Created: 2026-07-13T12:12:34.874Z

## Score Summary

- Overall: 91/100
- SEO / AEO: 96/100
- Security: 100/100
- Accessibility: 100/100
- Design: 67/100

## Launch Readiness

Close to ready (Strong).

Passed: 33. Failed: 5. Unknown: 0.
Strongest area: Security. Weakest area: Design.

## Prioritized Fixes

### 1. Fix rendered layout ergonomics

- Category: Design
- Status: fail
- Severity: medium
- Rule points lost: 9
- Evidence: Horizontal overflow: 0px. Small tap targets: 39.
- Why it matters: Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.
- Fix: Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.

### 2. Improve rendered speed signals

- Category: Design
- Status: fail
- Severity: medium
- Rule points lost: 10
- Evidence: DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.
- Why it matters: Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.
- Fix: Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.

### 3. Add trust signals

- Category: Design
- Status: fail
- Severity: medium
- Rule points lost: 10
- Evidence: Detected 0 trust-signal keyword occurrence(s).
- Why it matters: Trust signals reduce hesitation when strangers see the product for the first time.
- Fix: Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.

### 4. Fix runtime browser errors

- Category: Design
- Status: fail
- Severity: low
- Rule points lost: 7
- Evidence: Detected 4 console error(s) and 0 uncaught page error(s) during render.
- Why it matters: Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.
- Fix: Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.

### 5. Add an LLM-readable product file

- Category: SEO / AEO
- Status: fail
- Severity: low
- Rule points lost: 4
- Evidence: HTTP 404 returned for llms_txt.
- Why it matters: A short LLM-readable file can help answer engines and AI tools summarize your product accurately.
- Fix: Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.

## Opportunities

### Add answer-ready sections for common buyer questions

- Impact: high
- Category: SEO / AEO
- Evidence: Pricing signals: 3. Use-case signals: 0. Integration/API signals: 0.
- Why it matters: Answer engines and search visitors need concise textual answers to summarize who the product is for, how it works, what it costs, and what it connects with.
- Next step: Add short, crawlable sections for pricing or plans, ideal users, use cases, integrations, security, and how the product differs from alternatives.

### Make trust and proof easier to detect

- Impact: medium
- Category: Design
- Evidence: Detected 0 trust-signal keyword occurrence(s).
- Why it matters: Visitors who arrive cold from search, social, or AI citations need proof before they submit a form, start a trial, or buy.
- Next step: Add honest proof such as customer quotes, recognizable logos, security notes, usage stats, reviews, case studies, or founder credibility.

### Add an optional LLM-readable site summary

- Impact: low
- Category: SEO / AEO
- Evidence: HTTP 404 returned for llms_txt.
- Why it matters: This is not required for Google AI features, but a concise public markdown summary can help AI agents and internal tools understand key pages.
- Next step: Publish a short llms.txt with product facts, audience, key public links, docs, pricing, support, and usage boundaries.

### Review snippet and preview controls

- Impact: low
- Category: SEO / AEO
- Evidence: Open Graph image was detected. Preview controls detected: 0.
- Why it matters: Preview controls can clarify how much text, image, and video content search systems may show from the page.
- Next step: Only add robots preview controls when you intentionally want to limit snippets or image/video previews; otherwise leave previews open.

### Speed up the rendered first impression

- Impact: medium
- Category: Design
- Evidence: DOMContentLoaded: 475ms. First contentful paint: 672ms. Scripts: 35. Third-party origins: 6. Transfer: not available.
- Why it matters: Visitors judge quality before reading much copy; a slow first render makes the product feel heavier and less trustworthy.
- Next step: Compress hero media, defer non-critical JavaScript, reduce third-party scripts, and keep the first viewport visually complete without waiting on heavy client work.

### Polish rendered responsive ergonomics

- Impact: medium
- Category: Design
- Evidence: Horizontal overflow: 0px. Small tap targets: 39.
- Why it matters: Overflow and tiny controls are easy for static scans to miss but obvious to real users, especially on mobile and tablet layouts.
- Next step: Constrain wide elements, avoid fixed-width content that exceeds the viewport, and increase touch target sizes for interactive controls.

### Measure search performance with first-party data

- Impact: medium
- Category: SEO / AEO
- Evidence: robots.txt and sitemap.xml were reachable, so the site has the basics needed for Search Console verification and monitoring.
- Why it matters: A scan can identify technical readiness, but Search Console and analytics reveal impressions, queries, clicks, pages, and conversions over time.
- Next step: Verify the domain in Search Console, submit the sitemap, and pair query/page data with analytics events for signups, demo requests, and purchases.

## Insights

### The page appears basically crawlable

- Category: SEO / AEO
- Evidence: HTTP 200. robots.txt: HTTP 200. sitemap.xml: HTTP 200. noindex check: clear.
- Interpretation: The public page satisfies the basic crawl/index path the scan can verify.
- Recommended use: Use this as the first launch gate before deeper content, ranking, or AI visibility work.

### AEO depends on normal SEO plus answerable text

- Category: SEO / AEO
- Evidence: Visible words: 1606. H1 count: 1. Audience signals: 10. CTA labels: Start my reading streak, Start Building Your Library, Start Building Your Library, Start Reading, How long will it take me to finish my book?.
- Interpretation: Google AI features currently rely on standard Search eligibility; the extra advantage comes from content that is easy to quote, summarize, and verify.
- Recommended use: Prioritize clear text answers, crawlable support pages, accurate schema, and visible proof over speculative AI-only markup.

### Detected entity signals

- Category: SEO / AEO
- Evidence: Title: The Complete Reading Tracker | ReadingHabit. H1: Become the person who actually finishes books.. Schema types: FAQPage, Organization, SoftwareApplication.
- Interpretation: The stronger and more consistent these entity signals are, the easier it is for search and answer systems to identify the brand, product category, and page purpose.
- Recommended use: Keep the title, H1, meta description, Open Graph, schema, footer, and about/pricing/docs pages aligned around the same product facts.

### Structured data is present

- Category: SEO / AEO
- Evidence: JSON-LD blocks: 3. Types: FAQPage, Organization, SoftwareApplication. Parse errors: 0.
- Interpretation: The page exposes machine-readable facts, but quality still depends on whether those facts match visible content.
- Recommended use: Validate JSON-LD and use only accurate facts that are visible or clearly supported on the public page.

### Weakest score area

- Category: Design
- Evidence: SEO / AEO: 96/100. Security: 100/100. Accessibility: 100/100. Design: 67/100
- Interpretation: The weakest area is Design, so improvements there should have the most visible effect on readiness.
- Recommended use: Use the score mix to choose the next workstream instead of treating every issue as equally urgent.

### LLM-readable file not found

- Category: SEO / AEO
- Evidence: HTTP 404 returned for llms_txt.
- Interpretation: llms.txt can be a useful optional summary for agents, but it should not be treated as a guaranteed AI search ranking factor.
- Recommended use: Invest first in crawlability, helpful visible content, internal links, and accurate schema; add llms.txt as a tidy supplement.

### Rendered page experience snapshot

- Category: Design
- Evidence: Rendered text samples: 100. Contrast failures: 0. Console errors: 4. Horizontal overflow: 0px.
- Interpretation: The scan inspected the browser-rendered page, so contrast, runtime, layout, and timing signals are more representative than static markup alone.
- Recommended use: Use rendered checks to prioritize issues that visitors actually experience after JavaScript and CSS load.

### Rendered speed snapshot

- Category: Design
- Evidence: DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.
- Interpretation: These are lightweight browser timings from one rendered scan, so they are useful directional signals rather than real-user performance proof.
- Recommended use: Use slow timings, high script counts, heavy transfer size, and many third-party origins to choose focused speed work, then verify important changes with analytics or field data when available.

### Rendered axe accessibility snapshot

- Category: Accessibility
- Evidence: axe violations: 0. Critical: 0. Serious: 0. Top rules: none.
- Interpretation: axe-core catches common accessibility failures in the actual rendered DOM, but it is still automated coverage and not a full manual accessibility audit.
- Recommended use: Treat critical and serious axe failures as high-priority fixes, then manually review keyboard flow, focus states, screen reader meaning, and interaction states.

## Scope

FreeScan.app performs safe public checks only. It is not a penetration test, full SEO engagement, full accessibility audit, WCAG certification, backlink audit, rank tracker, or analytics platform.

Public reports expose the scanned public URL, safe scores, sanitized public evidence, and fix guidance. They do not include credentials, cookies, hidden form values, or sensitive response bodies.

Rescan same URL

Rerun the full deterministic scanner for readinghabit.site without re-entering the URL. The previous report stays saved so the next result can be compared against it.

Start free audit

New scan Visit scanned site

completed

HTTP 200

0 redirects

38 checks

Website audit scorecard for readinghabit.site

The scanner fetched the public page, extracted deterministic facts, and stored scored results across SEO / AEO, security, accessibility, and design.

Submitted

https://readinghabit.site

Final URL

https://readinghabit.site

Created

Jul 13, 2026, 12:12 PM

Safe fetch

276 ms

Four-score result

Close to ready (Strong): 33 passed, 5 failed, and 0 unknown. Strongest area: Security. Weakest area: Design.

Overall

out of 100

SEO / AEO

out of 100

110/114 rule points

Security

100

out of 100

76/76 rule points

Accessibility

100

out of 100

94/94 rule points

Design

out of 100

74/110 rule points

Why this scored this way

Scores are deterministic: each category earns rule points for verified public signals and loses points for failed checks. Unknown checks are shown separately instead of guessed.

Category point breakdown

SEO / AEO110/114

Security76/76

Accessibility94/94

Design74/110

Biggest score-losing checks

medium

Design

Trust signals

Detected 0 trust-signal keyword occurrence(s).

medium

Design

Rendered speed signals

DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.

medium

Design

Rendered layout ergonomics

Horizontal overflow: 0px. Small tap targets: 39.

low

Design

Runtime console health

Detected 4 console error(s) and 0 uncaught page error(s) during render.

Recommendations

Score-losing issues ordered by remediation priority, severity, and score impact.

5 fixes

7 opportunities

9 insights

fail

medium

Design

Priority 13

Fix rendered layout ergonomics

-9 rule pts

What failed

The browser-rendered page has layout or tap-target issues.

Evidence

Horizontal overflow: 0px. Small tap targets: 39.

Priority

Priority 13: fix during launch polish.

Why it matters

Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.

How to fix it

Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Fix rendered layout ergonomics.
- Scanner check: Rendered layout ergonomics.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 13; lower numbers are more urgent.
- Score impact: 9 rule points lost.
- Evidence: Horizontal overflow: 0px. Small tap targets: 39.
- What needs attention: The browser-rendered page has layout or tap-target issues.
- Why it matters: Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Priority 14

Improve rendered speed signals

-10 rule pts

What failed

The browser-rendered page shows slow or heavy speed signals.

Evidence

DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.

Priority

Priority 14: fix during launch polish.

Why it matters

Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.

How to fix it

Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Improve rendered speed signals.
- Scanner check: Rendered speed signals.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 14; lower numbers are more urgent.
- Score impact: 10 rule points lost.
- Evidence: DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.
- What needs attention: The browser-rendered page shows slow or heavy speed signals.
- Why it matters: Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Priority 16

Add trust signals

-10 rule pts

What failed

The page does not expose detectable proof, customer, review, security, or credibility signals.

Evidence

Detected 0 trust-signal keyword occurrence(s).

Priority

Priority 16: lower-risk cleanup after urgent launch blockers.

Why it matters

Trust signals reduce hesitation when strangers see the product for the first time.

How to fix it

Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Add trust signals.
- Scanner check: Trust signals.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 16; lower numbers are more urgent.
- Score impact: 10 rule points lost.
- Evidence: Detected 0 trust-signal keyword occurrence(s).
- What needs attention: The page does not expose detectable proof, customer, review, security, or credibility signals.
- Why it matters: Trust signals reduce hesitation when strangers see the product for the first time.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

low

Design

Priority 15

Fix runtime browser errors

-7 rule pts

What failed

The rendered page produced console or uncaught JavaScript errors.

Evidence

Detected 4 console error(s) and 0 uncaught page error(s) during render.

Priority

Priority 15: fix during launch polish.

Why it matters

Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.

How to fix it

Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Fix runtime browser errors.
- Scanner check: Runtime console health.
- Category: Design.
- Status: fail.
- Severity: low.
- Priority: 15; lower numbers are more urgent.
- Score impact: 7 rule points lost.
- Evidence: Detected 4 console error(s) and 0 uncaught page error(s) during render.
- What needs attention: The rendered page produced console or uncaught JavaScript errors.
- Why it matters: Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

low

SEO / AEO

Priority 24

Add an LLM-readable product file

-4 rule pts

What failed

The scan did not find llms.txt or .well-known/llms.txt.

Evidence

HTTP 404 returned for llms_txt.

Priority

Priority 24: lower-risk cleanup after urgent launch blockers.

Why it matters

A short LLM-readable file can help answer engines and AI tools summarize your product accurately.

How to fix it

Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Add an LLM-readable product file.
- Scanner check: LLM-readable file.
- Category: SEO / AEO.
- Status: fail.
- Severity: low.
- Priority: 24; lower numbers are more urgent.
- Score impact: 4 rule points lost.
- Evidence: HTTP 404 returned for llms_txt.
- What needs attention: The scan did not find llms.txt or .well-known/llms.txt.
- Why it matters: A short LLM-readable file can help answer engines and AI tools summarize your product accurately.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

Score aggregation details

Category scores come from earned rule points divided by available rule points. Failed checks are ordered by severity and score lost.

96/100

12 pass, 1 fail, 0 unknown

SEO / AEO

Severity mix: 1 critical, 7 high, 3 medium, 2 low.

low

LLM-readable file

-4 rule pts

HTTP 404 returned for llms_txt.

100/100

6 pass, 0 fail, 0 unknown

Security

Severity mix: 2 critical, 3 high, 0 medium, 0 low.

No failed checks in this category.

100/100

8 pass, 0 fail, 0 unknown

Accessibility

Severity mix: 0 critical, 3 high, 5 medium, 0 low.

No failed checks in this category.

67/100

7 pass, 4 fail, 0 unknown

Design

Severity mix: 0 critical, 3 high, 6 medium, 2 low.

medium

Trust signals

-10 rule pts

Detected 0 trust-signal keyword occurrence(s).

medium

Rendered speed signals

-10 rule pts

DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.

medium

Rendered layout ergonomics

-9 rule pts

Horizontal overflow: 0px. Small tap targets: 39.

Full check list

Failed, unknown, and passed checks are all shown so the report is transparent even when public data is partial.

Showing failed checks.

Failed checks

These checks need attention.

fail

low

SEO / AEO

LLM-readable file

0/4

HTTP 404 returned for llms_txt.

Failed: earned 0 of 4 points.

Priority: Priority 24: lower-risk cleanup after urgent launch blockers.

Why it matters: A short LLM-readable file can help answer engines and AI tools summarize your product accurately.

Fix: Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Add an LLM-readable product file.
- Scanner check: LLM-readable file.
- Category: SEO / AEO.
- Status: fail.
- Severity: low.
- Priority: 24; lower numbers are more urgent.
- Score impact: 4 of 4 rule points lost.
- Evidence: HTTP 404 returned for llms_txt.
- What needs attention: The scan did not find llms.txt or .well-known/llms.txt.
- Why it matters: A short LLM-readable file can help answer engines and AI tools summarize your product accurately.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Trust signals

0/10

Detected 0 trust-signal keyword occurrence(s).

Failed: earned 0 of 10 points.

Priority: Priority 16: lower-risk cleanup after urgent launch blockers.

Why it matters: Trust signals reduce hesitation when strangers see the product for the first time.

Fix: Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Add trust signals.
- Scanner check: Trust signals.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 16; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: Detected 0 trust-signal keyword occurrence(s).
- What needs attention: The page does not expose detectable proof, customer, review, security, or credibility signals.
- Why it matters: Trust signals reduce hesitation when strangers see the product for the first time.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Rendered speed signals

0/10

DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.

Failed: earned 0 of 10 points.

Priority: Priority 14: fix during launch polish.

Why it matters: Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.

Fix: Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Improve rendered speed signals.
- Scanner check: Rendered speed signals.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 14; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.
- What needs attention: The browser-rendered page shows slow or heavy speed signals.
- Why it matters: Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

low

Design

Runtime console health

0/7

Detected 4 console error(s) and 0 uncaught page error(s) during render.

Failed: earned 0 of 7 points.

Priority: Priority 15: fix during launch polish.

Why it matters: Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.

Fix: Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Fix runtime browser errors.
- Scanner check: Runtime console health.
- Category: Design.
- Status: fail.
- Severity: low.
- Priority: 15; lower numbers are more urgent.
- Score impact: 7 of 7 rule points lost.
- Evidence: Detected 4 console error(s) and 0 uncaught page error(s) during render.
- What needs attention: The rendered page produced console or uncaught JavaScript errors.
- Why it matters: Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

fail

medium

Design

Rendered layout ergonomics

0/9

Horizontal overflow: 0px. Small tap targets: 39.

Failed: earned 0 of 9 points.

Priority: Priority 13: fix during launch polish.

Why it matters: Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.

Fix: Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.

Copyable agent prompt

## Role
Act as a focused expert website launch remediation agent for this workflow.
## Inputs
- Primary context: Improve readinghabit.site at https://readinghabit.site.
- Fix title: Fix rendered layout ergonomics.
- Scanner check: Rendered layout ergonomics.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 13; lower numbers are more urgent.
- Score impact: 9 of 9 rule points lost.
- Evidence: Horizontal overflow: 0px. Small tap targets: 39.
- What needs attention: The browser-rendered page has layout or tap-target issues.
- Why it matters: Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.
- Status-specific guidance: A public check reported a failure. Reproduce or inspect the issue first, then make the smallest safe fix.
- Audience or recipient: The site owner, builder, or marketing team responsible for improving this public page.
- Constraints, examples, or source material: Treat the live URL as the public target to inspect, not as the only source of truth. When repository, CMS, or hosting access is available, use that implementation context before changing anything.
- Target outcome: After the fix is deployed and the public page is rescanned, this specific check should improve or pass without lowering other SEO / AEO, security, accessibility, or design signals.
## Task
Use the provided context to safely complete this workflow: Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.
Before editing, identify the likely source of the issue, the smallest change that can fix it, and any user-visible behavior that must be preserved.
## Output
Return a structured response with headings, prioritized recommendations, changed files or page areas, verification results, rollback notes, and stated assumptions.
## Rules
- Ask a clarifying question when required context is missing.
- Preserve the user's intent and avoid inventing facts.
- Verify the issue exists before changing code or content. If the issue is not reproducible, explain what you checked and recommend no code change.
- If the live URL and implementation source disagree, trust the implementation source for edits and use the live URL only to understand current public behavior.
- Keep the change narrowly scoped to this fix unless another change is required to avoid a regression.
- Match the existing framework, style, design system, routing patterns, and content conventions.
- Preserve existing URLs, forms, analytics, SEO metadata, accessibility semantics, and conversion flows unless the fix explicitly requires changing them.
- Do not perform broad refactors, dependency upgrades, redesigns, rewrites, migrations, file deletions, route changes, or destructive commands unless they are explicitly required and approved.
- Make changes that are easy to review and roll back.
- Verify the result with the smallest reliable test, build, browser check, or manual inspection available.
## Safety
- Do not request, expose, or reproduce sensitive data.
- Redact private details from examples unless the user explicitly says they are safe to include.
- Do not use credentials, cookies, authenticated data, hidden form values, or private response bodies.
- Do not weaken security headers, authentication, authorization, privacy controls, accessibility, or error handling to make the scan pass.

Public report link

Markdown export

Share the website audit report

Copy a public report link or a Markdown version with scores, fixes, opportunities, insights, and a normal link back to the scanned site.

Share preview

readinghabit.site website audit report

Close to ready: 91/100 overall, with prioritized fixes for SEO, security, accessibility, and design.

Public report link

Markdown report

# readinghabit.site Website Scan

Scanned URL: [https://readinghabit.site](https://readinghabit.site)
Report URL: /scan/readinghabit-site-91-launch-readiness-report-dfa80783
Created: 2026-07-13T12:12:34.874Z

## Score Summary

- Overall: 91/100
- SEO / AEO: 96/100
- Security: 100/100
- Accessibility: 100/100
- Design: 67/100

## Launch Readiness

Close to ready (Strong).

Passed: 33. Failed: 5. Unknown: 0.
Strongest area: Security. Weakest area: Design.

## Prioritized Fixes

### 1. Fix rendered layout ergonomics

- Category: Design
- Status: fail
- Severity: medium
- Rule points lost: 9
- Evidence: Horizontal overflow: 0px. Small tap targets: 39.
- Why it matters: Horizontal overflow and tiny tap targets make the page feel broken on real devices, especially for mobile visitors.
- Fix: Remove elements wider than the viewport, add responsive constraints, and make important links, buttons, inputs, and controls at least 40px tall and wide where possible.

### 2. Improve rendered speed signals

- Category: Design
- Status: fail
- Severity: medium
- Rule points lost: 10
- Evidence: DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.
- Why it matters: Slow pages lose impatient visitors and make every SEO, social, and paid-traffic visit work harder.
- Fix: Reduce render-blocking scripts/styles, compress and size images, defer non-critical JavaScript, reduce third-party tags, and keep above-the-fold content quick to paint.

### 3. Add trust signals

- Category: Design
- Status: fail
- Severity: medium
- Rule points lost: 10
- Evidence: Detected 0 trust-signal keyword occurrence(s).
- Why it matters: Trust signals reduce hesitation when strangers see the product for the first time.
- Fix: Add honest proof such as customer quotes, usage stats, founder credibility, security notes, or relevant logos.

### 4. Fix runtime browser errors

- Category: Design
- Status: fail
- Severity: low
- Rule points lost: 7
- Evidence: Detected 4 console error(s) and 0 uncaught page error(s) during render.
- Why it matters: Runtime errors can break forms, CTAs, animations, tracking, or responsive behavior even when the static HTML looks fine.
- Fix: Open the page in a browser, reproduce the console errors, and fix missing assets, hydration problems, client-side exceptions, or failing third-party scripts.

### 5. Add an LLM-readable product file

- Category: SEO / AEO
- Status: fail
- Severity: low
- Rule points lost: 4
- Evidence: HTTP 404 returned for llms_txt.
- Why it matters: A short LLM-readable file can help answer engines and AI tools summarize your product accurately.
- Fix: Add /llms.txt or /.well-known/llms.txt with the product name, audience, value proposition, and key public links.

## Opportunities

### Add answer-ready sections for common buyer questions

- Impact: high
- Category: SEO / AEO
- Evidence: Pricing signals: 3. Use-case signals: 0. Integration/API signals: 0.
- Why it matters: Answer engines and search visitors need concise textual answers to summarize who the product is for, how it works, what it costs, and what it connects with.
- Next step: Add short, crawlable sections for pricing or plans, ideal users, use cases, integrations, security, and how the product differs from alternatives.

### Make trust and proof easier to detect

- Impact: medium
- Category: Design
- Evidence: Detected 0 trust-signal keyword occurrence(s).
- Why it matters: Visitors who arrive cold from search, social, or AI citations need proof before they submit a form, start a trial, or buy.
- Next step: Add honest proof such as customer quotes, recognizable logos, security notes, usage stats, reviews, case studies, or founder credibility.

### Add an optional LLM-readable site summary

- Impact: low
- Category: SEO / AEO
- Evidence: HTTP 404 returned for llms_txt.
- Why it matters: This is not required for Google AI features, but a concise public markdown summary can help AI agents and internal tools understand key pages.
- Next step: Publish a short llms.txt with product facts, audience, key public links, docs, pricing, support, and usage boundaries.

### Review snippet and preview controls

- Impact: low
- Category: SEO / AEO
- Evidence: Open Graph image was detected. Preview controls detected: 0.
- Why it matters: Preview controls can clarify how much text, image, and video content search systems may show from the page.
- Next step: Only add robots preview controls when you intentionally want to limit snippets or image/video previews; otherwise leave previews open.

### Speed up the rendered first impression

- Impact: medium
- Category: Design
- Evidence: DOMContentLoaded: 475ms. First contentful paint: 672ms. Scripts: 35. Third-party origins: 6. Transfer: not available.
- Why it matters: Visitors judge quality before reading much copy; a slow first render makes the product feel heavier and less trustworthy.
- Next step: Compress hero media, defer non-critical JavaScript, reduce third-party scripts, and keep the first viewport visually complete without waiting on heavy client work.

### Polish rendered responsive ergonomics

- Impact: medium
- Category: Design
- Evidence: Horizontal overflow: 0px. Small tap targets: 39.
- Why it matters: Overflow and tiny controls are easy for static scans to miss but obvious to real users, especially on mobile and tablet layouts.
- Next step: Constrain wide elements, avoid fixed-width content that exceeds the viewport, and increase touch target sizes for interactive controls.

### Measure search performance with first-party data

- Impact: medium
- Category: SEO / AEO
- Evidence: robots.txt and sitemap.xml were reachable, so the site has the basics needed for Search Console verification and monitoring.
- Why it matters: A scan can identify technical readiness, but Search Console and analytics reveal impressions, queries, clicks, pages, and conversions over time.
- Next step: Verify the domain in Search Console, submit the sitemap, and pair query/page data with analytics events for signups, demo requests, and purchases.

## Insights

### The page appears basically crawlable

- Category: SEO / AEO
- Evidence: HTTP 200. robots.txt: HTTP 200. sitemap.xml: HTTP 200. noindex check: clear.
- Interpretation: The public page satisfies the basic crawl/index path the scan can verify.
- Recommended use: Use this as the first launch gate before deeper content, ranking, or AI visibility work.

### AEO depends on normal SEO plus answerable text

- Category: SEO / AEO
- Evidence: Visible words: 1606. H1 count: 1. Audience signals: 10. CTA labels: Start my reading streak, Start Building Your Library, Start Building Your Library, Start Reading, How long will it take me to finish my book?.
- Interpretation: Google AI features currently rely on standard Search eligibility; the extra advantage comes from content that is easy to quote, summarize, and verify.
- Recommended use: Prioritize clear text answers, crawlable support pages, accurate schema, and visible proof over speculative AI-only markup.

### Detected entity signals

- Category: SEO / AEO
- Evidence: Title: The Complete Reading Tracker | ReadingHabit. H1: Become the person who actually finishes books.. Schema types: FAQPage, Organization, SoftwareApplication.
- Interpretation: The stronger and more consistent these entity signals are, the easier it is for search and answer systems to identify the brand, product category, and page purpose.
- Recommended use: Keep the title, H1, meta description, Open Graph, schema, footer, and about/pricing/docs pages aligned around the same product facts.

### Structured data is present

- Category: SEO / AEO
- Evidence: JSON-LD blocks: 3. Types: FAQPage, Organization, SoftwareApplication. Parse errors: 0.
- Interpretation: The page exposes machine-readable facts, but quality still depends on whether those facts match visible content.
- Recommended use: Validate JSON-LD and use only accurate facts that are visible or clearly supported on the public page.

### Weakest score area

- Category: Design
- Evidence: SEO / AEO: 96/100. Security: 100/100. Accessibility: 100/100. Design: 67/100
- Interpretation: The weakest area is Design, so improvements there should have the most visible effect on readiness.
- Recommended use: Use the score mix to choose the next workstream instead of treating every issue as equally urgent.

### LLM-readable file not found

- Category: SEO / AEO
- Evidence: HTTP 404 returned for llms_txt.
- Interpretation: llms.txt can be a useful optional summary for agents, but it should not be treated as a guaranteed AI search ranking factor.
- Recommended use: Invest first in crawlability, helpful visible content, internal links, and accurate schema; add llms.txt as a tidy supplement.

### Rendered page experience snapshot

- Category: Design
- Evidence: Rendered text samples: 100. Contrast failures: 0. Console errors: 4. Horizontal overflow: 0px.
- Interpretation: The scan inspected the browser-rendered page, so contrast, runtime, layout, and timing signals are more representative than static markup alone.
- Recommended use: Use rendered checks to prioritize issues that visitors actually experience after JavaScript and CSS load.

### Rendered speed snapshot

- Category: Design
- Evidence: DOMContentLoaded: 475ms. Load complete: 779ms. First contentful paint: 672ms. Resources: 59. Scripts: 35. Images: 4. Third-party origins: 6. Transfer: not available.
- Interpretation: These are lightweight browser timings from one rendered scan, so they are useful directional signals rather than real-user performance proof.
- Recommended use: Use slow timings, high script counts, heavy transfer size, and many third-party origins to choose focused speed work, then verify important changes with analytics or field data when available.

### Rendered axe accessibility snapshot

- Category: Accessibility
- Evidence: axe violations: 0. Critical: 0. Serious: 0. Top rules: none.
- Interpretation: axe-core catches common accessibility failures in the actual rendered DOM, but it is still automated coverage and not a full manual accessibility audit.
- Recommended use: Treat critical and serious axe failures as high-priority fixes, then manually review keyboard flow, focus states, screen reader meaning, and interaction states.

## Scope

FreeScan.app performs safe public checks only. It is not a penetration test, full SEO engagement, full accessibility audit, WCAG certification, backlink audit, rank tracker, or analytics platform.

Public reports expose the scanned public URL, safe scores, sanitized public evidence, and fix guidance. They do not include credentials, cookies, hidden form values, or sensitive response bodies.

Rescan same URL

Rerun the full deterministic scanner for readinghabit.site without re-entering the URL. The previous report stays saved so the next result can be compared against it.

Website audit scorecard for readinghabit.site

Fix rendered layout ergonomics

Copyable agent prompt

Improve rendered speed signals

Copyable agent prompt

Add trust signals

Copyable agent prompt

Fix runtime browser errors

Copyable agent prompt

Add an LLM-readable product file

Copyable agent prompt

SEO / AEO

LLM-readable file

Security

Accessibility

Design

Trust signals

Rendered speed signals

Rendered layout ergonomics

Failed checks

LLM-readable file

Copyable agent prompt

Trust signals

Copyable agent prompt

Rendered speed signals

Copyable agent prompt

Runtime console health

Copyable agent prompt

Rendered layout ergonomics

Copyable agent prompt

Unknown and not detected statesFreeScan.app keeps partial public data explicit. It marks unverifiable signals as unknown or not detected instead of inventing evidence.

Safe fetch metadataPublic headers and redirects captured during intake. Response bodies, cookies, and credentials are not stored.

Website audit scorecard for readinghabit.site

Fix rendered layout ergonomics

Copyable agent prompt

Improve rendered speed signals

Copyable agent prompt

Add trust signals

Copyable agent prompt

Fix runtime browser errors

Copyable agent prompt

Add an LLM-readable product file

Copyable agent prompt

SEO / AEO

LLM-readable file

Security

Accessibility

Design

Trust signals

Rendered speed signals

Rendered layout ergonomics

Failed checks

LLM-readable file

Copyable agent prompt

Trust signals

Copyable agent prompt

Rendered speed signals

Copyable agent prompt

Runtime console health

Copyable agent prompt

Rendered layout ergonomics

Copyable agent prompt

Unknown and not detected statesFreeScan.app keeps partial public data explicit. It marks unverifiable signals as unknown or not detected instead of inventing evidence.

Safe fetch metadataPublic headers and redirects captured during intake. Response bodies, cookies, and credentials are not stored.