completed

HTTP 200

0 redirects

37 checks

Website audit scorecard for freerealm.org

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

Submitted

freerealm.org

Final URL

https://freerealm.org

Created

Aug 5, 2026, 3:31 AM

Safe fetch

108 ms

Four-score result

Close to ready (Needs polish): 26 passed, 10 failed, and 1 unknown. Strongest area: SEO / AEO. Weakest area: Accessibility.

Overall

out of 100

SEO / AEO

out of 100

81/103 rule points

Security

out of 100

60/76 rule points

Accessibility

out of 100

54/94 rule points

Design

out of 100

86/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 / AEO81/103

Security60/76

Accessibility54/94

Design86/110

Biggest score-losing checks

high

Accessibility

Rendered axe accessibility violations

axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).

critical

Security

Sensitive file probes

A small allowlist probe returned a public success response.

high

Accessibility

Form labels

Detected labels or accessible names for 2 of 3 form control(s).

high

SEO / AEO

Canonical tag

No canonical link tag was detected.

Recommendations

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

5 fixes

7 opportunities

9 insights

fail

critical

Security

Priority 1

Remove exposed sensitive files

-16 rule pts

What failed

A small public allowlist probe found a sensitive-looking file path.

Evidence

A small allowlist probe returned a public success response.

Priority

Priority 1: fix before sharing the page publicly.

Why it matters

Publicly exposed config or backup files can leak implementation details or secrets.

How to fix it

Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.

Copyable agent prompt

## Role
Act as a focused public web security remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: security_sensitive_file_probes.
- Fix title: Remove exposed sensitive files.
- Scanner check: Sensitive file probes.
- Category: Security.
- Status: fail.
- Severity: critical.
- Priority: 1; lower numbers are more urgent.
- Score impact: 16 rule points lost.
- Evidence: A small allowlist probe returned a public success response.
- What needs attention: A small public allowlist probe found a sensitive-looking file path.
- Why it matters: Publicly exposed config or backup files can leak implementation details or secrets.
- 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.
- Likely places to inspect: public/static folders, storage buckets, web server rules, backup artifacts, config files, and deployment output; server, edge, CDN, hosting, proxy, form action, asset URL, cookie, and public file access configuration; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Remove exposed sensitive-looking files from public hosting or block public access to those paths.
- If secrets may have been exposed, recommend rotating them and checking access logs.
- Prefer narrow, production-safe security configuration changes over blanket disables or permissive rules.
- Preserve authentication, authorization, private paths, and sensitive file protections while fixing the public launch page.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The probed sensitive path no longer returns a public success response.
- No legitimate public asset or route is removed accidentally.
- The public URL keeps legitimate visitors and assets working while removing the reported browser-side or public exposure risk.
- The change does not weaken security headers, authentication, authorization, or private route protections.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

critical

SEO / AEO

Priority 2

Improve AI search and crawler readiness

-2 rule pts

What failed

One or more AI discovery, user-fetch, indexability, snippet, synthetic reachability, or sitemap signals need attention.

Evidence

FreeScan.app reached the public page with HTTP 200. robots.txt blocks Claude-SearchBot, PerplexityBot from AI search or discovery for this page path. Synthetic or robots checks block Claude-User, MistralAI-User from user-requested fetches. GPTBot, ClaudeBot, Google-Extended, and 4 more are explicit training or data-use opt-outs and do not reduce the AEO score. AEO crawler readiness is 88%: discovery 45/45, index and snippet eligibility 20/25, synthetic reachability 13/20, sitemap freshness 10/10.

Priority

Priority 2: fix before sharing the page publicly.

Why it matters

AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.

How to fix it

Use the component scores and exact matched robots rules in the crawler report. Fix blocked search agents, noindex or snippet restrictions, canonical or sitemap gaps, and synthetic WAF/challenge failures. Preserve intentional training opt-outs and keep private, admin, and authenticated paths protected before rescanning.

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_crawler_access.
- Fix title: Improve AI search and crawler readiness.
- Scanner check: Crawler access.
- Category: SEO / AEO.
- Status: fail.
- Severity: critical.
- Priority: 2; lower numbers are more urgent.
- Score impact: 2 rule points lost.
- Evidence: FreeScan.app reached the public page with HTTP 200. robots.txt blocks Claude-SearchBot, PerplexityBot from AI search or discovery for this page path. Synthetic or robots checks block Claude-User, MistralAI-User from user-requested fetches. GPTBot, ClaudeBot, Google-Extended, and 4 more are explicit training or data-use opt-outs and do not reduce the AEO score. AEO crawler readiness is 88%: discovery 45/45, index and snippet eligibility 20/25, synthetic reachability 13/20, sitemap freshness 10/10.
- What needs attention: One or more AI discovery, user-fetch, indexability, snippet, synthetic reachability, or sitemap signals need attention.
- Why it matters: AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.
- 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.
- Likely places to inspect: robots.txt rules for the scanned path and common search or AI crawler user agents; CDN, WAF, bot protection, rate-limit, firewall, and security challenge rules that apply to public pages; server responses for unauthenticated HEAD and GET requests to the scanned URL; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Use the component scores and exact matched robots rules in the crawler report. Fix blocked search agents, noindex or snippet restrictions, canonical or sitemap gaps, and synthetic WAF/challenge failures. Preserve intentional training opt-outs and keep private, admin, and authenticated paths protected before rescanning.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Identify exactly which crawler group or HTTP/security layer is blocking access before changing rules.
- Allow legitimate public-page crawling with narrow path, user-agent, or verified-bot rules instead of disabling bot protection globally.
- Keep admin, account, staging, preview, API, and private paths blocked or authenticated.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- A fresh unauthenticated request to the scanned public URL no longer returns crawler-blocking HTTP statuses such as 401, 403, 429, or 503.
- robots.txt does not disallow the scanned public path for the intended search and AI crawler user agents.
- Security controls still protect private and authenticated areas.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

Accessibility

Priority 5

Fix rendered axe accessibility violations

-18 rule pts

What failed

The rendered page has accessibility rule violations detected by axe-core.

Evidence

axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).

Priority

Priority 5: fix before sharing the page publicly.

Why it matters

axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.

How to fix it

Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_axe_violations.
- Fix title: Fix rendered axe accessibility violations.
- Scanner check: Rendered axe accessibility violations.
- Category: Accessibility.
- Status: fail.
- Severity: high.
- Priority: 5; lower numbers are more urgent.
- Score impact: 18 rule points lost.
- Evidence: axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).
- What needs attention: The rendered page has accessibility rule violations detected by axe-core.
- Why it matters: axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.
- 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.
- Likely places to inspect: axe violation details, affected selectors, rendered DOM, component source, and interaction state that triggered the issue; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Fix each reported accessibility violation at the semantic source.
- Avoid suppressing automated checks unless there is a documented false positive.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Critical and serious axe issues tied to this page are resolved or clearly documented as non-reproducible.
- Fixes do not introduce new keyboard, label, contrast, or landmark regressions.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

Accessibility

Priority 7

Label public form fields

-14 rule pts

What failed

Some form controls do not have a detectable label or accessible name.

Evidence

Detected labels or accessible names for 2 of 3 form control(s).

Priority

Priority 7: fix during launch polish.

Why it matters

Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.

How to fix it

Connect each input to a visible label or an accurate aria-label/aria-labelledby value.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_form_labels.
- Fix title: Label public form fields.
- Scanner check: Form labels.
- Category: Accessibility.
- Status: fail.
- Severity: high.
- Priority: 7; lower numbers are more urgent.
- Score impact: 14 rule points lost.
- Evidence: Detected labels or accessible names for 2 of 3 form control(s).
- What needs attention: Some form controls do not have a detectable label or accessible name.
- Why it matters: Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.
- 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.
- Likely places to inspect: inputs, selects, textareas, custom form controls, search fields, newsletter embeds, and generated form components; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Connect each input to a visible label or an accurate aria-label/aria-labelledby value.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Connect each control to a visible label, aria-label, or aria-labelledby that accurately describes the input.
- Keep labels available to assistive technology and preserve validation/error messaging.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Every public form control has a detectable accessible name.
- Keyboard and screen reader users can understand and complete the form.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

SEO / AEO

Priority 9

Add a canonical URL

-10 rule pts

What failed

The page does not declare which public URL is the preferred version.

Evidence

No canonical link tag was detected.

Priority

Priority 9: fix during launch polish.

Why it matters

A canonical tag reduces duplicate URL confusion before marketing links start spreading.

How to fix it

Add a canonical link tag that points to the final public landing page URL.

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_canonical.
- Fix title: Add a canonical URL.
- Scanner check: Canonical tag.
- Category: SEO / AEO.
- Status: fail.
- Severity: high.
- Priority: 9; lower numbers are more urgent.
- Score impact: 10 rule points lost.
- Evidence: No canonical link tag was detected.
- What needs attention: The page does not declare which public URL is the preferred version.
- Why it matters: A canonical tag reduces duplicate URL confusion before marketing links start spreading.
- 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.
- Likely places to inspect: canonical URL generation, site URL environment variables, routing aliases, trailing slash behavior, and deployment domains; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Add a canonical link tag that points to the final public landing page URL.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Set the canonical link to the preferred final public URL for this page.
- Keep canonical, og:url, sitemap URLs, and redirects aligned where possible.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The public HTML exposes one canonical URL for the scanned page.
- The canonical points to the intended public destination and avoids staging, localhost, tracking parameters, or duplicate variants.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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.

79/100

8 pass, 3 fail, 1 unknown

SEO / AEO

Severity mix: 1 critical, 6 high, 3 medium, 1 low.

critical

Crawler access

-2 rule pts

high

Canonical tag

-10 rule pts

No canonical link tag was detected.

high

Schema presence

-10 rule pts

Detected 0 JSON-LD schema block(s).

79/100

5 pass, 1 fail, 0 unknown

Security

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

critical

Sensitive file probes

-16 rule pts

A small allowlist probe returned a public success response.

57/100

5 pass, 3 fail, 0 unknown

Accessibility

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

high

Rendered axe accessibility violations

-18 rule pts

axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).

high

Form labels

-14 rule pts

Detected labels or accessible names for 2 of 3 form control(s).

medium

Basic contrast

-8 rule pts

5 of 100 rendered text color sample(s) missed WCAG contrast targets. Worst rendered ratio: 2.03.

78/100

8 pass, 3 fail, 0 unknown

Design

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

medium

Text density

-10 rule pts

Detected about 2698 visible word(s). General page range: 80-1800 words.

low

Spacing consistency

-7 rule pts

Detected 2 spacing class/style signal(s).

low

Runtime console health

-7 rule pts

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

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

critical

SEO / AEO

Crawler access

12/14

Failed: earned 12 of 14 points from partial coverage.

Priority: Priority 2: fix before sharing the page publicly.

Why it matters: AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.

Fix: Use the component scores and exact matched robots rules in the crawler report. Fix blocked search agents, noindex or snippet restrictions, canonical or sitemap gaps, and synthetic WAF/challenge failures. Preserve intentional training opt-outs and keep private, admin, and authenticated paths protected before rescanning.

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_crawler_access.
- Fix title: Improve AI search and crawler readiness.
- Scanner check: Crawler access.
- Category: SEO / AEO.
- Status: fail.
- Severity: critical.
- Priority: 2; lower numbers are more urgent.
- Score impact: 2 of 14 rule points lost.
- Evidence: FreeScan.app reached the public page with HTTP 200. robots.txt blocks Claude-SearchBot, PerplexityBot from AI search or discovery for this page path. Synthetic or robots checks block Claude-User, MistralAI-User from user-requested fetches. GPTBot, ClaudeBot, Google-Extended, and 4 more are explicit training or data-use opt-outs and do not reduce the AEO score. AEO crawler readiness is 88%: discovery 45/45, index and snippet eligibility 20/25, synthetic reachability 13/20, sitemap freshness 10/10.
- What needs attention: One or more AI discovery, user-fetch, indexability, snippet, synthetic reachability, or sitemap signals need attention.
- Why it matters: AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.
- 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.
- Likely places to inspect: robots.txt rules for the scanned path and common search or AI crawler user agents; CDN, WAF, bot protection, rate-limit, firewall, and security challenge rules that apply to public pages; server responses for unauthenticated HEAD and GET requests to the scanned URL; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Use the component scores and exact matched robots rules in the crawler report. Fix blocked search agents, noindex or snippet restrictions, canonical or sitemap gaps, and synthetic WAF/challenge failures. Preserve intentional training opt-outs and keep private, admin, and authenticated paths protected before rescanning.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Identify exactly which crawler group or HTTP/security layer is blocking access before changing rules.
- Allow legitimate public-page crawling with narrow path, user-agent, or verified-bot rules instead of disabling bot protection globally.
- Keep admin, account, staging, preview, API, and private paths blocked or authenticated.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- A fresh unauthenticated request to the scanned public URL no longer returns crawler-blocking HTTP statuses such as 401, 403, 429, or 503.
- robots.txt does not disallow the scanned public path for the intended search and AI crawler user agents.
- Security controls still protect private and authenticated areas.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

SEO / AEO

Canonical tag

0/10

No canonical link tag was detected.

Failed: earned 0 of 10 points.

Priority: Priority 9: fix during launch polish.

Why it matters: A canonical tag reduces duplicate URL confusion before marketing links start spreading.

Fix: Add a canonical link tag that points to the final public landing page URL.

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_canonical.
- Fix title: Add a canonical URL.
- Scanner check: Canonical tag.
- Category: SEO / AEO.
- Status: fail.
- Severity: high.
- Priority: 9; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: No canonical link tag was detected.
- What needs attention: The page does not declare which public URL is the preferred version.
- Why it matters: A canonical tag reduces duplicate URL confusion before marketing links start spreading.
- 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.
- Likely places to inspect: canonical URL generation, site URL environment variables, routing aliases, trailing slash behavior, and deployment domains; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Add a canonical link tag that points to the final public landing page URL.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Set the canonical link to the preferred final public URL for this page.
- Keep canonical, og:url, sitemap URLs, and redirects aligned where possible.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The public HTML exposes one canonical URL for the scanned page.
- The canonical points to the intended public destination and avoids staging, localhost, tracking parameters, or duplicate variants.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

SEO / AEO

Schema presence

0/10

Detected 0 JSON-LD schema block(s).

Failed: earned 0 of 10 points.

Priority: Priority 12: fix during launch polish.

Why it matters: Structured data gives search and answer engines explicit facts about your product.

Fix: Add JSON-LD for SoftwareApplication, Product, Organization, or WebSite using only accurate public facts.

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_schema_presence.
- Fix title: Add basic structured data.
- Scanner check: Schema presence.
- Category: SEO / AEO.
- Status: fail.
- Severity: high.
- Priority: 12; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: Detected 0 JSON-LD schema block(s).
- What needs attention: No JSON-LD schema was detected on the page.
- Why it matters: Structured data gives search and answer engines explicit facts about your product.
- 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.
- Likely places to inspect: JSON-LD generation in document head, route metadata, CMS SEO/schema fields, or server-rendered templates; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Add JSON-LD for SoftwareApplication, Product, Organization, or WebSite using only accurate public facts.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Add JSON-LD types that fit the visible page, such as Organization, WebSite, SoftwareApplication/Product, FAQPage, or BreadcrumbList.
- Use only accurate public facts and avoid unsupported ratings, prices, reviews, authors, or claims.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The public HTML includes at least one application/ld+json block.
- The schema parses as valid JSON and matches facts visible or clearly supported on the public page.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

critical

Security

Sensitive file probes

0/16

A small allowlist probe returned a public success response.

Failed: earned 0 of 16 points.

Priority: Priority 1: fix before sharing the page publicly.

Why it matters: Publicly exposed config or backup files can leak implementation details or secrets.

Fix: Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.

Copyable agent prompt

## Role
Act as a focused public web security remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: security_sensitive_file_probes.
- Fix title: Remove exposed sensitive files.
- Scanner check: Sensitive file probes.
- Category: Security.
- Status: fail.
- Severity: critical.
- Priority: 1; lower numbers are more urgent.
- Score impact: 16 of 16 rule points lost.
- Evidence: A small allowlist probe returned a public success response.
- What needs attention: A small public allowlist probe found a sensitive-looking file path.
- Why it matters: Publicly exposed config or backup files can leak implementation details or secrets.
- 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.
- Likely places to inspect: public/static folders, storage buckets, web server rules, backup artifacts, config files, and deployment output; server, edge, CDN, hosting, proxy, form action, asset URL, cookie, and public file access configuration; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Remove exposed sensitive-looking files from public hosting or block public access to those paths.
- If secrets may have been exposed, recommend rotating them and checking access logs.
- Prefer narrow, production-safe security configuration changes over blanket disables or permissive rules.
- Preserve authentication, authorization, private paths, and sensitive file protections while fixing the public launch page.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The probed sensitive path no longer returns a public success response.
- No legitimate public asset or route is removed accidentally.
- The public URL keeps legitimate visitors and assets working while removing the reported browser-side or public exposure risk.
- The change does not weaken security headers, authentication, authorization, or private route protections.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

Accessibility

Form labels

0/14

Detected labels or accessible names for 2 of 3 form control(s).

Failed: earned 0 of 14 points.

Priority: Priority 7: fix during launch polish.

Why it matters: Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.

Fix: Connect each input to a visible label or an accurate aria-label/aria-labelledby value.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_form_labels.
- Fix title: Label public form fields.
- Scanner check: Form labels.
- Category: Accessibility.
- Status: fail.
- Severity: high.
- Priority: 7; lower numbers are more urgent.
- Score impact: 14 of 14 rule points lost.
- Evidence: Detected labels or accessible names for 2 of 3 form control(s).
- What needs attention: Some form controls do not have a detectable label or accessible name.
- Why it matters: Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.
- 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.
- Likely places to inspect: inputs, selects, textareas, custom form controls, search fields, newsletter embeds, and generated form components; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Connect each input to a visible label or an accurate aria-label/aria-labelledby value.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Connect each control to a visible label, aria-label, or aria-labelledby that accurately describes the input.
- Keep labels available to assistive technology and preserve validation/error messaging.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Every public form control has a detectable accessible name.
- Keyboard and screen reader users can understand and complete the form.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

Accessibility

Basic contrast

0/8

5 of 100 rendered text color sample(s) missed WCAG contrast targets. Worst rendered ratio: 2.03.

Failed: earned 0 of 8 points.

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

Why it matters: Low contrast makes a launch page feel less polished and can exclude users with low vision.

Fix: Review key text, buttons, and links against a 4.5:1 contrast target for normal text.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_contrast.
- Fix title: Improve detectable color contrast.
- Scanner check: Basic contrast.
- Category: Accessibility.
- Status: fail.
- Severity: medium.
- Priority: 20; lower numbers are more urgent.
- Score impact: 8 of 8 rule points lost.
- Evidence: 5 of 100 rendered text color sample(s) missed WCAG contrast targets. Worst rendered ratio: 2.03.
- What needs attention: The scanner found text/background color pairs that may be hard to read, or could not verify contrast.
- Why it matters: Low contrast makes a launch page feel less polished and can exclude users with low vision.
- 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.
- Likely places to inspect: CSS variables, design tokens, theme config, text/background combinations, buttons, links, badges, and disabled states; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Review key text, buttons, and links against a 4.5:1 contrast target for normal text.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Adjust foreground/background colors or font treatment where contrast is too low.
- Preserve brand feel while making text readable in real viewport states.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Important text and controls meet reasonable contrast targets in rendered states.
- No new low-contrast states are introduced.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

Accessibility

Rendered axe accessibility violations

0/18

axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).

Failed: earned 0 of 18 points.

Priority: Priority 5: fix before sharing the page publicly.

Why it matters: axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.

Fix: Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_axe_violations.
- Fix title: Fix rendered axe accessibility violations.
- Scanner check: Rendered axe accessibility violations.
- Category: Accessibility.
- Status: fail.
- Severity: high.
- Priority: 5; lower numbers are more urgent.
- Score impact: 18 of 18 rule points lost.
- Evidence: axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).
- What needs attention: The rendered page has accessibility rule violations detected by axe-core.
- Why it matters: axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.
- 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.
- Likely places to inspect: axe violation details, affected selectors, rendered DOM, component source, and interaction state that triggered the issue; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Fix each reported accessibility violation at the semantic source.
- Avoid suppressing automated checks unless there is a documented false positive.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Critical and serious axe issues tied to this page are resolved or clearly documented as non-reproducible.
- Fixes do not introduce new keyboard, label, contrast, or landmark regressions.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

Text density

0/10

Detected about 2698 visible word(s). General page range: 80-1800 words.

Failed: earned 0 of 10 points.

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

Why it matters: Too little copy can leave visitors confused; too much copy can bury the value proposition.

Fix: Add concise sections for value, proof, how it works, and next steps, then remove repetitive copy.

Copyable agent prompt

## Role
Act as a focused conversion-focused frontend quality remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: design_text_density.
- Fix title: Balance landing page copy.
- Scanner check: Text density.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 21; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: Detected about 2698 visible word(s). General page range: 80-1800 words.
- What needs attention: The page has too little or too much detectable text for a useful launch page.
- Why it matters: Too little copy can leave visitors confused; too much copy can bury the value proposition.
- 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.
- Likely places to inspect: long sections, paragraphs, feature lists, cards, FAQ blocks, and mobile line lengths; page layout, responsive CSS, component states, copy hierarchy, CTA placement, spacing tokens, rendered console output, and performance-sensitive assets; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Add concise sections for value, proof, how it works, and next steps, then remove repetitive copy.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Break dense copy into scannable headings, shorter paragraphs, lists, or progressive disclosure.
- Keep important details while reducing cognitive load.
- Improve the actual rendered page at mobile and desktop sizes, not only the source code shape.
- Preserve core conversion flows while making layout, hierarchy, readability, or runtime health better.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The page is easier to scan without hiding essential offer, pricing, trust, or support information.
- Text remains readable on mobile and desktop.
- The rendered page is visually stable and usable on mobile and desktop viewports.
- The fix does not hide content, break CTAs, introduce console errors, or reduce clarity for visitors.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

Spacing consistency

0/7

Detected 2 spacing class/style signal(s).

Failed: earned 0 of 7 points.

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

Why it matters: Consistent spacing helps the page feel deliberate and easier to scan.

Fix: Use consistent section padding, gaps, and margins across repeated content blocks.

Copyable agent prompt

## Role
Act as a focused conversion-focused frontend quality remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: design_spacing_consistency.
- Fix title: Make spacing more consistent.
- Scanner check: Spacing consistency.
- Category: Design.
- Status: fail.
- Severity: low.
- Priority: 25; lower numbers are more urgent.
- Score impact: 7 of 7 rule points lost.
- Evidence: Detected 2 spacing class/style signal(s).
- What needs attention: The page exposes few consistent spacing signals in class or inline styles.
- Why it matters: Consistent spacing helps the page feel deliberate and easier to scan.
- 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.
- Likely places to inspect: layout spacing tokens, component padding, section gaps, card grids, mobile breakpoints, and repeated patterns; page layout, responsive CSS, component states, copy hierarchy, CTA placement, spacing tokens, rendered console output, and performance-sensitive assets; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Use consistent section padding, gaps, and margins across repeated content blocks.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Normalize spacing using existing tokens or local conventions.
- Avoid one-off spacing hacks that create new breakpoints or layout shifts.
- Improve the actual rendered page at mobile and desktop sizes, not only the source code shape.
- Preserve core conversion flows while making layout, hierarchy, readability, or runtime health better.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Spacing feels consistent across related sections and viewport sizes.
- No important UI shifts or overlaps after the change.
- The rendered page is visually stable and usable on mobile and desktop viewports.
- The fix does not hide content, break CTAs, introduce console errors, or reduce clarity for visitors.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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 2 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 conversion-focused frontend quality remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: design_runtime_health.
- 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 2 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.
- Likely places to inspect: browser console errors, uncaught page errors, missing assets, hydration issues, and third-party script failures; page layout, responsive CSS, component states, copy hierarchy, CTA placement, spacing tokens, rendered console output, and performance-sensitive assets; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## 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.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Reproduce the runtime error and fix the source rather than hiding console output.
- Handle missing data, failed requests, and client-only APIs safely.
- Improve the actual rendered page at mobile and desktop sizes, not only the source code shape.
- Preserve core conversion flows while making layout, hierarchy, readability, or runtime health better.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The page renders without the reported console or uncaught page errors.
- No key interaction, analytics, or rendering flow breaks after the fix.
- The rendered page is visually stable and usable on mobile and desktop viewports.
- The fix does not hide content, break CTAs, introduce console errors, or reduce clarity for visitors.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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.

Page-level AEO readiness

Shared eligibility and content signals that affect every search and answer agent.

80/100 ready

Index and citation eligibility

No general noindex directive was detected.

Snippet and answer controls

No general nosnippet or max-snippet:0 control was detected.

Canonical alignment

No canonical URL was detected.

Sitemap coverage and freshness

The exact URL appears in sitemap.xml with lastmod 2026-05-27.

Structured data

Detected 0 JSON-LD block(s), 0 parse error(s), and types none.

Public or paywalled content

No isAccessibleForFree structured-data value was detected.

Entity clarity

Detected 3 of 3 core identity signals across the title, description, and H1.

Answer-ready visible text

Detected 2698 visible words and 27 audience, use-case, pricing, or integration signals.

Authorship and accountability

No author meta value or structured-data author was detected.

Published or updated date

No datePublished or dateModified value was detected in structured data.

Supporting-source links

No external supporting links were detected; this is contextual rather than a universal requirement.

Rendered content availability

Rendered audit completed with 128 visible text element(s).

Synthetic search-agent reachability

6 of 8 search/discovery User-Agent probes returned reachable content.

Optional LLM-readable summary

No llms.txt file was found; this is optional and does not reduce core AEO readiness.

OpenAIChatGPT search

OAI-SearchBot

PASS · ALLOWED

AI search

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

OpenAIOpenAI model training

GPTBot

OPTED OUT

Model training

Robots: blocked by gptbot disallow: / · line 55

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

OpenAIChatGPT user fetches

ChatGPT-User

UNKNOWN

User-requested fetch

Robots: not applicable to user-requested fetches

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AnthropicClaude model training

ClaudeBot

OPTED OUT

Model training

Robots: blocked by claudebot disallow: / · line 46

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AnthropicClaude search

Claude-SearchBot

FAIL · BLOCKED

AI search

Robots: allowed by * allow: / · line 31

Probe: blocked · HTTP 403

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AnthropicClaude user fetches

Claude-User

FAIL · BLOCKED

User-requested fetch

Robots: allowed by * allow: / · line 31

Probe: blocked · HTTP 403

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

GoogleGoogle Search and AI features

Googlebot

PASS · ALLOWED

Search and discovery

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

GoogleGemini data use and grounding

Google-Extended

OPTED OUT

Data-use policy control

Robots: blocked by google-extended disallow: / · line 52

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

MicrosoftBing and Copilot

Bingbot

PASS · ALLOWED

Search and discovery

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

PerplexityPerplexity search

PerplexityBot

FAIL · BLOCKED

AI search

Robots: allowed by * allow: / · line 31

Probe: blocked · HTTP 403

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

PerplexityPerplexity user fetches

Perplexity-User

UNKNOWN

User-requested fetch

Robots: not applicable to user-requested fetches

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AppleSiri, Spotlight, and Safari search

Applebot

PASS · ALLOWED

Search and discovery

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AppleApple foundation-model training

Applebot-Extended

OPTED OUT

Data-use policy control

Robots: blocked by applebot-extended disallow: / · line 37

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

Mistral AIMistral search

MistralAI-Index

PASS · ALLOWED

AI search

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

Mistral AIMistral user fetches

MistralAI-User

FAIL · BLOCKED

User-requested fetch

Robots: allowed by * allow: / · line 31

Probe: blocked · HTTP 403

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

MetaMeta AI model and product data

meta-externalagent

OPTED OUT

Model training

Robots: blocked by meta-externalagent disallow: / · line 58

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

MetaMeta AI user fetches

meta-externalfetcher

PASS · ALLOWED

User-requested fetch

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AmazonAmazon model training

Amazonbot

OPTED OUT

Model training

Robots: blocked by amazonbot disallow: / · line 34

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AmazonAlexa and Rufus search

Amzn-SearchBot

PASS · ALLOWED

AI search

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AmazonAlexa user fetches

Amzn-User

PASS · ALLOWED

User-requested fetch

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

Common CrawlOpen web datasets

CCBot

OPTED OUT

Model training

Robots: blocked by ccbot disallow: / · line 43

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

Ready combines robots policy, a bounded synthetic User-Agent fetch, indexability, and snippet eligibility. Synthetic probes do not prove vendor-origin traffic. Purple preference states are training or data-use choices and do not lower the AEO score.

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

freerealm.org website audit report

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

Public report link

Markdown report

# freerealm.org Website Scan

Scanned URL: [https://freerealm.org](https://freerealm.org)
Report URL: /scan/freerealm-org-73-launch-readiness-report-4132d6a0
Created: 2026-08-05T03:31:17.662Z

## Score Summary

- Overall: 73/100
- SEO / AEO: 79/100
- Security: 79/100
- Accessibility: 57/100
- Design: 78/100

## Launch Readiness

Close to ready (Needs polish).

Passed: 26. Failed: 10. Unknown: 1.
Strongest area: SEO / AEO. Weakest area: Accessibility.

## AI Crawler Access

These results combine robots.txt policy, page controls, and bounded synthetic User-Agent probes. Synthetic probes do not prove that traffic came from the vendor; training and data-use choices are neutral publisher preferences.

- **OpenAI — ChatGPT search** (OAI-SearchBot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **OpenAI — OpenAI model training** (GPTBot): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by gptbot disallow: / on line 55. No synthetic fetch is appropriate for this policy or training control.
- **OpenAI — ChatGPT user fetches** (ChatGPT-User): UNKNOWN — robots not_applicable; synthetic probe not_tested. ChatGPT-User is used for user-requested retrieval, so robots.txt is not treated as a reliable access control for this row. No synthetic fetch is appropriate for this policy or training control.
- **Anthropic — Claude model training** (ClaudeBot): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by claudebot disallow: / on line 46. No synthetic fetch is appropriate for this policy or training control.
- **Anthropic — Claude search** (Claude-SearchBot): FAIL — robots allowed; synthetic probe blocked (HTTP 403). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 403.
- **Anthropic — Claude user fetches** (Claude-User): FAIL — robots allowed; synthetic probe blocked (HTTP 403). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 403.
- **Google — Google Search and AI features** (Googlebot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Google — Gemini data use and grounding** (Google-Extended): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by google-extended disallow: / on line 52. No synthetic fetch is appropriate for this policy or training control.
- **Microsoft — Bing and Copilot** (Bingbot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Perplexity — Perplexity search** (PerplexityBot): FAIL — robots allowed; synthetic probe blocked (HTTP 403). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 403.
- **Perplexity — Perplexity user fetches** (Perplexity-User): UNKNOWN — robots not_applicable; synthetic probe not_tested. Perplexity-User is used for user-requested retrieval, so robots.txt is not treated as a reliable access control for this row. No synthetic fetch is appropriate for this policy or training control.
- **Apple — Siri, Spotlight, and Safari search** (Applebot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Apple — Apple foundation-model training** (Applebot-Extended): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by applebot-extended disallow: / on line 37. No synthetic fetch is appropriate for this policy or training control.
- **Mistral AI — Mistral search** (MistralAI-Index): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Mistral AI — Mistral user fetches** (MistralAI-User): FAIL — robots allowed; synthetic probe blocked (HTTP 403). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 403.
- **Meta — Meta AI model and product data** (meta-externalagent): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by meta-externalagent disallow: / on line 58. No synthetic fetch is appropriate for this policy or training control.
- **Meta — Meta AI user fetches** (meta-externalfetcher): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Amazon — Amazon model training** (Amazonbot): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by amazonbot disallow: / on line 34. No synthetic fetch is appropriate for this policy or training control.
- **Amazon — Alexa and Rufus search** (Amzn-SearchBot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Amazon — Alexa user fetches** (Amzn-User): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Common Crawl — Open web datasets** (CCBot): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by ccbot disallow: / on line 43. No synthetic fetch is appropriate for this policy or training control.

## Page-level AEO Readiness

Readiness: 80/100

- **Index and citation eligibility**: PASS — No general noindex directive was detected.
- **Snippet and answer controls**: PASS — No general nosnippet or max-snippet:0 control was detected.
- **Canonical alignment**: FAIL — No canonical URL was detected.
- **Sitemap coverage and freshness**: PASS — The exact URL appears in sitemap.xml with lastmod 2026-05-27.
- **Structured data**: UNKNOWN — Detected 0 JSON-LD block(s), 0 parse error(s), and types none.
- **Public or paywalled content**: UNKNOWN — No isAccessibleForFree structured-data value was detected.
- **Entity clarity**: PASS — Detected 3 of 3 core identity signals across the title, description, and H1.
- **Answer-ready visible text**: PASS — Detected 2698 visible words and 27 audience, use-case, pricing, or integration signals.
- **Authorship and accountability**: UNKNOWN — No author meta value or structured-data author was detected.
- **Published or updated date**: UNKNOWN — No datePublished or dateModified value was detected in structured data.
- **Supporting-source links**: UNKNOWN — No external supporting links were detected; this is contextual rather than a universal requirement.
- **Rendered content availability**: PASS — Rendered audit completed with 128 visible text element(s).
- **Synthetic search-agent reachability**: UNKNOWN — 6 of 8 search/discovery User-Agent probes returned reachable content.
- **Optional LLM-readable summary**: INFO — No llms.txt file was found; this is optional and does not reduce core AEO readiness.

## Prioritized Fixes

### 1. Remove exposed sensitive files

- Category: Security
- Status: fail
- Severity: critical
- Rule points lost: 16
- Evidence: A small allowlist probe returned a public success response.
- Why it matters: Publicly exposed config or backup files can leak implementation details or secrets.
- Fix: Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.

### 2. Improve AI search and crawler readiness

- Category: SEO / AEO
- Status: fail
- Severity: critical
- Rule points lost: 2
- Evidence: FreeScan.app reached the public page with HTTP 200. robots.txt blocks Claude-SearchBot, PerplexityBot from AI search or discovery for this page path. Synthetic or robots checks block Claude-User, MistralAI-User from user-requested fetches. GPTBot, ClaudeBot, Google-Extended, and 4 more are explicit training or data-use opt-outs and do not reduce the AEO score. AEO crawler readiness is 88%: discovery 45/45, index and snippet eligibility 20/25, synthetic reachability 13/20, sitemap freshness 10/10.
- Why it matters: AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.
- Fix: Use the component scores and exact matched robots rules in the crawler report. Fix blocked search agents, noindex or snippet restrictions, canonical or sitemap gaps, and synthetic WAF/challenge failures. Preserve intentional training opt-outs and keep private, admin, and authenticated paths protected before rescanning.

### 3. Fix rendered axe accessibility violations

- Category: Accessibility
- Status: fail
- Severity: high
- Rule points lost: 18
- Evidence: axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).
- Why it matters: axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.
- Fix: Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.

### 4. Label public form fields

- Category: Accessibility
- Status: fail
- Severity: high
- Rule points lost: 14
- Evidence: Detected labels or accessible names for 2 of 3 form control(s).
- Why it matters: Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.
- Fix: Connect each input to a visible label or an accurate aria-label/aria-labelledby value.

### 5. Add a canonical URL

- Category: SEO / AEO
- Status: fail
- Severity: high
- Rule points lost: 10
- Evidence: No canonical link tag was detected.
- Why it matters: A canonical tag reduces duplicate URL confusion before marketing links start spreading.
- Fix: Add a canonical link tag that points to the final public landing page URL.

## Opportunities

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

- Impact: high
- Category: SEO / AEO
- Evidence: Pricing signals: 0. 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.

### Expose important supporting pages in navigation or footer

- Impact: medium
- Category: SEO / AEO
- Evidence: No pricing, docs, contact, security, privacy, terms, or about links were detected in public internal links.
- Why it matters: Internal links help visitors, crawlers, and AI answer systems discover supporting facts instead of relying on one landing page.
- Next step: Link to the most useful public pages, especially pricing, docs, contact, security, privacy, terms, and about pages where applicable.

### Make trust and proof easier to detect

- Impact: medium
- Category: Design
- Evidence: Detected 1 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.

### Tighten the live color system

- Impact: high
- Category: Accessibility
- Evidence: 5 of 100 rendered contrast sample(s) missed target. Worst ratio: 2.03.
- Why it matters: Computed contrast catches the actual colors visitors see after CSS, themes, and overlays are applied.
- Next step: Audit foreground/background token pairs for body text, muted text, links, buttons, inputs, and badges, then raise weak pairs to WCAG AA contrast targets.

### 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: 2698. H1 count: 1. Audience signals: 27. CTA labels: none detected.
- 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: Free Realm. H1: Beyond the reach 
        of any government. 
         Any corporation. Anyone.. Schema types: none.
- 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.

### No structured data detected

- Category: SEO / AEO
- Evidence: JSON-LD blocks: 0. Types: none. Parse errors: 0.
- Interpretation: Missing or invalid structured data makes the page rely more heavily on inferred meaning from text and layout.
- Recommended use: Validate JSON-LD and use only accurate facts that are visible or clearly supported on the public page.

### Weakest score area

- Category: Accessibility
- Evidence: SEO / AEO: 79/100. Security: 79/100. Accessibility: 57/100. Design: 78/100
- Interpretation: The weakest area is Accessibility, 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: 5. Console errors: 2. 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: 360ms. Load complete: 590ms. First contentful paint: 576ms. Resources: 17. Scripts: 4. Images: 4. Third-party origins: 5. 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: 1. Critical: 0. Serious: 0. Top rules: region.
- 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 freerealm.org 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

37 checks

Website audit scorecard for freerealm.org

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

Submitted

freerealm.org

Final URL

https://freerealm.org

Created

Aug 5, 2026, 3:31 AM

Safe fetch

108 ms

Four-score result

Close to ready (Needs polish): 26 passed, 10 failed, and 1 unknown. Strongest area: SEO / AEO. Weakest area: Accessibility.

Overall

out of 100

SEO / AEO

out of 100

81/103 rule points

Security

out of 100

60/76 rule points

Accessibility

out of 100

54/94 rule points

Design

out of 100

86/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 / AEO81/103

Security60/76

Accessibility54/94

Design86/110

Biggest score-losing checks

high

Accessibility

Rendered axe accessibility violations

axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).

critical

Security

Sensitive file probes

A small allowlist probe returned a public success response.

high

Accessibility

Form labels

Detected labels or accessible names for 2 of 3 form control(s).

high

SEO / AEO

Canonical tag

No canonical link tag was detected.

Recommendations

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

5 fixes

7 opportunities

9 insights

fail

critical

Security

Priority 1

Remove exposed sensitive files

-16 rule pts

What failed

A small public allowlist probe found a sensitive-looking file path.

Evidence

A small allowlist probe returned a public success response.

Priority

Priority 1: fix before sharing the page publicly.

Why it matters

Publicly exposed config or backup files can leak implementation details or secrets.

How to fix it

Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.

Copyable agent prompt

## Role
Act as a focused public web security remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: security_sensitive_file_probes.
- Fix title: Remove exposed sensitive files.
- Scanner check: Sensitive file probes.
- Category: Security.
- Status: fail.
- Severity: critical.
- Priority: 1; lower numbers are more urgent.
- Score impact: 16 rule points lost.
- Evidence: A small allowlist probe returned a public success response.
- What needs attention: A small public allowlist probe found a sensitive-looking file path.
- Why it matters: Publicly exposed config or backup files can leak implementation details or secrets.
- 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.
- Likely places to inspect: public/static folders, storage buckets, web server rules, backup artifacts, config files, and deployment output; server, edge, CDN, hosting, proxy, form action, asset URL, cookie, and public file access configuration; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Remove exposed sensitive-looking files from public hosting or block public access to those paths.
- If secrets may have been exposed, recommend rotating them and checking access logs.
- Prefer narrow, production-safe security configuration changes over blanket disables or permissive rules.
- Preserve authentication, authorization, private paths, and sensitive file protections while fixing the public launch page.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The probed sensitive path no longer returns a public success response.
- No legitimate public asset or route is removed accidentally.
- The public URL keeps legitimate visitors and assets working while removing the reported browser-side or public exposure risk.
- The change does not weaken security headers, authentication, authorization, or private route protections.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

critical

SEO / AEO

Priority 2

Improve AI search and crawler readiness

-2 rule pts

What failed

One or more AI discovery, user-fetch, indexability, snippet, synthetic reachability, or sitemap signals need attention.

Evidence

Priority

Priority 2: fix before sharing the page publicly.

Why it matters

AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.

How to fix it

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_crawler_access.
- Fix title: Improve AI search and crawler readiness.
- Scanner check: Crawler access.
- Category: SEO / AEO.
- Status: fail.
- Severity: critical.
- Priority: 2; lower numbers are more urgent.
- Score impact: 2 rule points lost.
- Evidence: FreeScan.app reached the public page with HTTP 200. robots.txt blocks Claude-SearchBot, PerplexityBot from AI search or discovery for this page path. Synthetic or robots checks block Claude-User, MistralAI-User from user-requested fetches. GPTBot, ClaudeBot, Google-Extended, and 4 more are explicit training or data-use opt-outs and do not reduce the AEO score. AEO crawler readiness is 88%: discovery 45/45, index and snippet eligibility 20/25, synthetic reachability 13/20, sitemap freshness 10/10.
- What needs attention: One or more AI discovery, user-fetch, indexability, snippet, synthetic reachability, or sitemap signals need attention.
- Why it matters: AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.
- 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.
- Likely places to inspect: robots.txt rules for the scanned path and common search or AI crawler user agents; CDN, WAF, bot protection, rate-limit, firewall, and security challenge rules that apply to public pages; server responses for unauthenticated HEAD and GET requests to the scanned URL; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Use the component scores and exact matched robots rules in the crawler report. Fix blocked search agents, noindex or snippet restrictions, canonical or sitemap gaps, and synthetic WAF/challenge failures. Preserve intentional training opt-outs and keep private, admin, and authenticated paths protected before rescanning.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Identify exactly which crawler group or HTTP/security layer is blocking access before changing rules.
- Allow legitimate public-page crawling with narrow path, user-agent, or verified-bot rules instead of disabling bot protection globally.
- Keep admin, account, staging, preview, API, and private paths blocked or authenticated.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- A fresh unauthenticated request to the scanned public URL no longer returns crawler-blocking HTTP statuses such as 401, 403, 429, or 503.
- robots.txt does not disallow the scanned public path for the intended search and AI crawler user agents.
- Security controls still protect private and authenticated areas.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

Accessibility

Priority 5

Fix rendered axe accessibility violations

-18 rule pts

What failed

The rendered page has accessibility rule violations detected by axe-core.

Evidence

axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).

Priority

Priority 5: fix before sharing the page publicly.

Why it matters

axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.

How to fix it

Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_axe_violations.
- Fix title: Fix rendered axe accessibility violations.
- Scanner check: Rendered axe accessibility violations.
- Category: Accessibility.
- Status: fail.
- Severity: high.
- Priority: 5; lower numbers are more urgent.
- Score impact: 18 rule points lost.
- Evidence: axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).
- What needs attention: The rendered page has accessibility rule violations detected by axe-core.
- Why it matters: axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.
- 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.
- Likely places to inspect: axe violation details, affected selectors, rendered DOM, component source, and interaction state that triggered the issue; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Fix each reported accessibility violation at the semantic source.
- Avoid suppressing automated checks unless there is a documented false positive.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Critical and serious axe issues tied to this page are resolved or clearly documented as non-reproducible.
- Fixes do not introduce new keyboard, label, contrast, or landmark regressions.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

Accessibility

Priority 7

Label public form fields

-14 rule pts

What failed

Some form controls do not have a detectable label or accessible name.

Evidence

Detected labels or accessible names for 2 of 3 form control(s).

Priority

Priority 7: fix during launch polish.

Why it matters

Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.

How to fix it

Connect each input to a visible label or an accurate aria-label/aria-labelledby value.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_form_labels.
- Fix title: Label public form fields.
- Scanner check: Form labels.
- Category: Accessibility.
- Status: fail.
- Severity: high.
- Priority: 7; lower numbers are more urgent.
- Score impact: 14 rule points lost.
- Evidence: Detected labels or accessible names for 2 of 3 form control(s).
- What needs attention: Some form controls do not have a detectable label or accessible name.
- Why it matters: Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.
- 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.
- Likely places to inspect: inputs, selects, textareas, custom form controls, search fields, newsletter embeds, and generated form components; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Connect each input to a visible label or an accurate aria-label/aria-labelledby value.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Connect each control to a visible label, aria-label, or aria-labelledby that accurately describes the input.
- Keep labels available to assistive technology and preserve validation/error messaging.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Every public form control has a detectable accessible name.
- Keyboard and screen reader users can understand and complete the form.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

SEO / AEO

Priority 9

Add a canonical URL

-10 rule pts

What failed

The page does not declare which public URL is the preferred version.

Evidence

No canonical link tag was detected.

Priority

Priority 9: fix during launch polish.

Why it matters

A canonical tag reduces duplicate URL confusion before marketing links start spreading.

How to fix it

Add a canonical link tag that points to the final public landing page URL.

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_canonical.
- Fix title: Add a canonical URL.
- Scanner check: Canonical tag.
- Category: SEO / AEO.
- Status: fail.
- Severity: high.
- Priority: 9; lower numbers are more urgent.
- Score impact: 10 rule points lost.
- Evidence: No canonical link tag was detected.
- What needs attention: The page does not declare which public URL is the preferred version.
- Why it matters: A canonical tag reduces duplicate URL confusion before marketing links start spreading.
- 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.
- Likely places to inspect: canonical URL generation, site URL environment variables, routing aliases, trailing slash behavior, and deployment domains; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Add a canonical link tag that points to the final public landing page URL.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Set the canonical link to the preferred final public URL for this page.
- Keep canonical, og:url, sitemap URLs, and redirects aligned where possible.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The public HTML exposes one canonical URL for the scanned page.
- The canonical points to the intended public destination and avoids staging, localhost, tracking parameters, or duplicate variants.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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.

79/100

8 pass, 3 fail, 1 unknown

SEO / AEO

Severity mix: 1 critical, 6 high, 3 medium, 1 low.

critical

Crawler access

-2 rule pts

high

Canonical tag

-10 rule pts

No canonical link tag was detected.

high

Schema presence

-10 rule pts

Detected 0 JSON-LD schema block(s).

79/100

5 pass, 1 fail, 0 unknown

Security

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

critical

Sensitive file probes

-16 rule pts

A small allowlist probe returned a public success response.

57/100

5 pass, 3 fail, 0 unknown

Accessibility

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

high

Rendered axe accessibility violations

-18 rule pts

axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).

high

Form labels

-14 rule pts

Detected labels or accessible names for 2 of 3 form control(s).

medium

Basic contrast

-8 rule pts

5 of 100 rendered text color sample(s) missed WCAG contrast targets. Worst rendered ratio: 2.03.

78/100

8 pass, 3 fail, 0 unknown

Design

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

medium

Text density

-10 rule pts

Detected about 2698 visible word(s). General page range: 80-1800 words.

low

Spacing consistency

-7 rule pts

Detected 2 spacing class/style signal(s).

low

Runtime console health

-7 rule pts

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

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

critical

SEO / AEO

Crawler access

12/14

Failed: earned 12 of 14 points from partial coverage.

Priority: Priority 2: fix before sharing the page publicly.

Why it matters: AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_crawler_access.
- Fix title: Improve AI search and crawler readiness.
- Scanner check: Crawler access.
- Category: SEO / AEO.
- Status: fail.
- Severity: critical.
- Priority: 2; lower numbers are more urgent.
- Score impact: 2 of 14 rule points lost.
- Evidence: FreeScan.app reached the public page with HTTP 200. robots.txt blocks Claude-SearchBot, PerplexityBot from AI search or discovery for this page path. Synthetic or robots checks block Claude-User, MistralAI-User from user-requested fetches. GPTBot, ClaudeBot, Google-Extended, and 4 more are explicit training or data-use opt-outs and do not reduce the AEO score. AEO crawler readiness is 88%: discovery 45/45, index and snippet eligibility 20/25, synthetic reachability 13/20, sitemap freshness 10/10.
- What needs attention: One or more AI discovery, user-fetch, indexability, snippet, synthetic reachability, or sitemap signals need attention.
- Why it matters: AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.
- 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.
- Likely places to inspect: robots.txt rules for the scanned path and common search or AI crawler user agents; CDN, WAF, bot protection, rate-limit, firewall, and security challenge rules that apply to public pages; server responses for unauthenticated HEAD and GET requests to the scanned URL; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Use the component scores and exact matched robots rules in the crawler report. Fix blocked search agents, noindex or snippet restrictions, canonical or sitemap gaps, and synthetic WAF/challenge failures. Preserve intentional training opt-outs and keep private, admin, and authenticated paths protected before rescanning.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Identify exactly which crawler group or HTTP/security layer is blocking access before changing rules.
- Allow legitimate public-page crawling with narrow path, user-agent, or verified-bot rules instead of disabling bot protection globally.
- Keep admin, account, staging, preview, API, and private paths blocked or authenticated.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- A fresh unauthenticated request to the scanned public URL no longer returns crawler-blocking HTTP statuses such as 401, 403, 429, or 503.
- robots.txt does not disallow the scanned public path for the intended search and AI crawler user agents.
- Security controls still protect private and authenticated areas.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

SEO / AEO

Canonical tag

0/10

No canonical link tag was detected.

Failed: earned 0 of 10 points.

Priority: Priority 9: fix during launch polish.

Why it matters: A canonical tag reduces duplicate URL confusion before marketing links start spreading.

Fix: Add a canonical link tag that points to the final public landing page URL.

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_canonical.
- Fix title: Add a canonical URL.
- Scanner check: Canonical tag.
- Category: SEO / AEO.
- Status: fail.
- Severity: high.
- Priority: 9; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: No canonical link tag was detected.
- What needs attention: The page does not declare which public URL is the preferred version.
- Why it matters: A canonical tag reduces duplicate URL confusion before marketing links start spreading.
- 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.
- Likely places to inspect: canonical URL generation, site URL environment variables, routing aliases, trailing slash behavior, and deployment domains; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Add a canonical link tag that points to the final public landing page URL.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Set the canonical link to the preferred final public URL for this page.
- Keep canonical, og:url, sitemap URLs, and redirects aligned where possible.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The public HTML exposes one canonical URL for the scanned page.
- The canonical points to the intended public destination and avoids staging, localhost, tracking parameters, or duplicate variants.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

SEO / AEO

Schema presence

0/10

Detected 0 JSON-LD schema block(s).

Failed: earned 0 of 10 points.

Priority: Priority 12: fix during launch polish.

Why it matters: Structured data gives search and answer engines explicit facts about your product.

Fix: Add JSON-LD for SoftwareApplication, Product, Organization, or WebSite using only accurate public facts.

Copyable agent prompt

## Role
Act as a focused technical SEO, AEO, and crawlability remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: seo_schema_presence.
- Fix title: Add basic structured data.
- Scanner check: Schema presence.
- Category: SEO / AEO.
- Status: fail.
- Severity: high.
- Priority: 12; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: Detected 0 JSON-LD schema block(s).
- What needs attention: No JSON-LD schema was detected on the page.
- Why it matters: Structured data gives search and answer engines explicit facts about your product.
- 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.
- Likely places to inspect: JSON-LD generation in document head, route metadata, CMS SEO/schema fields, or server-rendered templates; metadata/head configuration, canonical URL logic, robots and sitemap routes, structured data blocks, page copy, headings, and internal navigation; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Add JSON-LD for SoftwareApplication, Product, Organization, or WebSite using only accurate public facts.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Add JSON-LD types that fit the visible page, such as Organization, WebSite, SoftwareApplication/Product, FAQPage, or BreadcrumbList.
- Use only accurate public facts and avoid unsupported ratings, prices, reviews, authors, or claims.
- Keep all metadata, headings, schema, canonical URLs, and visible copy consistent with the same public facts.
- Use accurate, crawlable, human-visible content as the source for search and answer-engine improvements.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The public HTML includes at least one application/ld+json block.
- The schema parses as valid JSON and matches facts visible or clearly supported on the public page.
- The public URL exposes the corrected crawl/search/answer signal in rendered HTML or reachable public files.
- The change should be visible to a fresh unauthenticated request and likely improve the related FreeScan SEO / AEO check on rescan.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

critical

Security

Sensitive file probes

0/16

A small allowlist probe returned a public success response.

Failed: earned 0 of 16 points.

Priority: Priority 1: fix before sharing the page publicly.

Why it matters: Publicly exposed config or backup files can leak implementation details or secrets.

Fix: Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.

Copyable agent prompt

## Role
Act as a focused public web security remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: security_sensitive_file_probes.
- Fix title: Remove exposed sensitive files.
- Scanner check: Sensitive file probes.
- Category: Security.
- Status: fail.
- Severity: critical.
- Priority: 1; lower numbers are more urgent.
- Score impact: 16 of 16 rule points lost.
- Evidence: A small allowlist probe returned a public success response.
- What needs attention: A small public allowlist probe found a sensitive-looking file path.
- Why it matters: Publicly exposed config or backup files can leak implementation details or secrets.
- 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.
- Likely places to inspect: public/static folders, storage buckets, web server rules, backup artifacts, config files, and deployment output; server, edge, CDN, hosting, proxy, form action, asset URL, cookie, and public file access configuration; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Remove exposed sensitive-looking files from public hosting or block public access to those paths.
- If secrets may have been exposed, recommend rotating them and checking access logs.
- Prefer narrow, production-safe security configuration changes over blanket disables or permissive rules.
- Preserve authentication, authorization, private paths, and sensitive file protections while fixing the public launch page.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The probed sensitive path no longer returns a public success response.
- No legitimate public asset or route is removed accidentally.
- The public URL keeps legitimate visitors and assets working while removing the reported browser-side or public exposure risk.
- The change does not weaken security headers, authentication, authorization, or private route protections.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

Accessibility

Form labels

0/14

Detected labels or accessible names for 2 of 3 form control(s).

Failed: earned 0 of 14 points.

Priority: Priority 7: fix during launch polish.

Why it matters: Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.

Fix: Connect each input to a visible label or an accurate aria-label/aria-labelledby value.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_form_labels.
- Fix title: Label public form fields.
- Scanner check: Form labels.
- Category: Accessibility.
- Status: fail.
- Severity: high.
- Priority: 7; lower numbers are more urgent.
- Score impact: 14 of 14 rule points lost.
- Evidence: Detected labels or accessible names for 2 of 3 form control(s).
- What needs attention: Some form controls do not have a detectable label or accessible name.
- Why it matters: Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.
- 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.
- Likely places to inspect: inputs, selects, textareas, custom form controls, search fields, newsletter embeds, and generated form components; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Connect each input to a visible label or an accurate aria-label/aria-labelledby value.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Connect each control to a visible label, aria-label, or aria-labelledby that accurately describes the input.
- Keep labels available to assistive technology and preserve validation/error messaging.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Every public form control has a detectable accessible name.
- Keyboard and screen reader users can understand and complete the form.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

Accessibility

Basic contrast

0/8

5 of 100 rendered text color sample(s) missed WCAG contrast targets. Worst rendered ratio: 2.03.

Failed: earned 0 of 8 points.

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

Why it matters: Low contrast makes a launch page feel less polished and can exclude users with low vision.

Fix: Review key text, buttons, and links against a 4.5:1 contrast target for normal text.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_contrast.
- Fix title: Improve detectable color contrast.
- Scanner check: Basic contrast.
- Category: Accessibility.
- Status: fail.
- Severity: medium.
- Priority: 20; lower numbers are more urgent.
- Score impact: 8 of 8 rule points lost.
- Evidence: 5 of 100 rendered text color sample(s) missed WCAG contrast targets. Worst rendered ratio: 2.03.
- What needs attention: The scanner found text/background color pairs that may be hard to read, or could not verify contrast.
- Why it matters: Low contrast makes a launch page feel less polished and can exclude users with low vision.
- 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.
- Likely places to inspect: CSS variables, design tokens, theme config, text/background combinations, buttons, links, badges, and disabled states; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Review key text, buttons, and links against a 4.5:1 contrast target for normal text.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Adjust foreground/background colors or font treatment where contrast is too low.
- Preserve brand feel while making text readable in real viewport states.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Important text and controls meet reasonable contrast targets in rendered states.
- No new low-contrast states are introduced.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

high

Accessibility

Rendered axe accessibility violations

0/18

axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).

Failed: earned 0 of 18 points.

Priority: Priority 5: fix before sharing the page publicly.

Why it matters: axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.

Fix: Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.

Copyable agent prompt

## Role
Act as a focused web accessibility remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: accessibility_axe_violations.
- Fix title: Fix rendered axe accessibility violations.
- Scanner check: Rendered axe accessibility violations.
- Category: Accessibility.
- Status: fail.
- Severity: high.
- Priority: 5; lower numbers are more urgent.
- Score impact: 18 of 18 rule points lost.
- Evidence: axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).
- What needs attention: The rendered page has accessibility rule violations detected by axe-core.
- Why it matters: axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.
- 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.
- Likely places to inspect: axe violation details, affected selectors, rendered DOM, component source, and interaction state that triggered the issue; semantic markup, labels, landmarks, headings, focus states, image rendering, form controls, and browser-rendered accessibility output; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Fix each reported accessibility violation at the semantic source.
- Avoid suppressing automated checks unless there is a documented false positive.
- Fix the semantic or interaction source of the issue rather than hiding warnings with ARIA or visual-only workarounds.
- Keep keyboard, screen reader, and touch users in the verification path.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Critical and serious axe issues tied to this page are resolved or clearly documented as non-reproducible.
- Fixes do not introduce new keyboard, label, contrast, or landmark regressions.
- The affected UI remains usable by keyboard and assistive technology and does not introduce heading, label, focus, or contrast regressions.
- The change can be checked in the browser or with an accessibility audit tool when available.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

Text density

0/10

Detected about 2698 visible word(s). General page range: 80-1800 words.

Failed: earned 0 of 10 points.

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

Why it matters: Too little copy can leave visitors confused; too much copy can bury the value proposition.

Fix: Add concise sections for value, proof, how it works, and next steps, then remove repetitive copy.

Copyable agent prompt

## Role
Act as a focused conversion-focused frontend quality remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: design_text_density.
- Fix title: Balance landing page copy.
- Scanner check: Text density.
- Category: Design.
- Status: fail.
- Severity: medium.
- Priority: 21; lower numbers are more urgent.
- Score impact: 10 of 10 rule points lost.
- Evidence: Detected about 2698 visible word(s). General page range: 80-1800 words.
- What needs attention: The page has too little or too much detectable text for a useful launch page.
- Why it matters: Too little copy can leave visitors confused; too much copy can bury the value proposition.
- 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.
- Likely places to inspect: long sections, paragraphs, feature lists, cards, FAQ blocks, and mobile line lengths; page layout, responsive CSS, component states, copy hierarchy, CTA placement, spacing tokens, rendered console output, and performance-sensitive assets; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Add concise sections for value, proof, how it works, and next steps, then remove repetitive copy.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Break dense copy into scannable headings, shorter paragraphs, lists, or progressive disclosure.
- Keep important details while reducing cognitive load.
- Improve the actual rendered page at mobile and desktop sizes, not only the source code shape.
- Preserve core conversion flows while making layout, hierarchy, readability, or runtime health better.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The page is easier to scan without hiding essential offer, pricing, trust, or support information.
- Text remains readable on mobile and desktop.
- The rendered page is visually stable and usable on mobile and desktop viewports.
- The fix does not hide content, break CTAs, introduce console errors, or reduce clarity for visitors.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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

Spacing consistency

0/7

Detected 2 spacing class/style signal(s).

Failed: earned 0 of 7 points.

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

Why it matters: Consistent spacing helps the page feel deliberate and easier to scan.

Fix: Use consistent section padding, gaps, and margins across repeated content blocks.

Copyable agent prompt

## Role
Act as a focused conversion-focused frontend quality remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: design_spacing_consistency.
- Fix title: Make spacing more consistent.
- Scanner check: Spacing consistency.
- Category: Design.
- Status: fail.
- Severity: low.
- Priority: 25; lower numbers are more urgent.
- Score impact: 7 of 7 rule points lost.
- Evidence: Detected 2 spacing class/style signal(s).
- What needs attention: The page exposes few consistent spacing signals in class or inline styles.
- Why it matters: Consistent spacing helps the page feel deliberate and easier to scan.
- 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.
- Likely places to inspect: layout spacing tokens, component padding, section gaps, card grids, mobile breakpoints, and repeated patterns; page layout, responsive CSS, component states, copy hierarchy, CTA placement, spacing tokens, rendered console output, and performance-sensitive assets; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## Task
Use the provided context to safely complete this workflow: Use consistent section padding, gaps, and margins across repeated content blocks.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Normalize spacing using existing tokens or local conventions.
- Avoid one-off spacing hacks that create new breakpoints or layout shifts.
- Improve the actual rendered page at mobile and desktop sizes, not only the source code shape.
- Preserve core conversion flows while making layout, hierarchy, readability, or runtime health better.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- Spacing feels consistent across related sections and viewport sizes.
- No important UI shifts or overlaps after the change.
- The rendered page is visually stable and usable on mobile and desktop viewports.
- The fix does not hide content, break CTAs, introduce console errors, or reduce clarity for visitors.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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 2 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 conversion-focused frontend quality remediation expert who can inspect the public page and safely improve the underlying implementation.
## Inputs
- Primary context: Improve freerealm.org at https://freerealm.org.
- Scanner check ID: design_runtime_health.
- 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 2 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.
- Likely places to inspect: browser console errors, uncaught page errors, missing assets, hydration issues, and third-party script failures; page layout, responsive CSS, component states, copy hierarchy, CTA placement, spacing tokens, rendered console output, and performance-sensitive assets; the route, template, component, CMS entry, theme file, or static page that renders the scanned URL; shared layout, metadata, routing, middleware, server, CDN, or hosting configuration if the issue is not in page content; existing tests, build scripts, preview commands, and deployment notes before choosing verification steps.
## 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.
First reproduce or verify the issue from the public page and available implementation source. Then make the smallest stack-appropriate change that fixes the scanner signal and improves the real user experience.
Use this check-specific implementation guide:
- Reproduce the runtime error and fix the source rather than hiding console output.
- Handle missing data, failed requests, and client-only APIs safely.
- Improve the actual rendered page at mobile and desktop sizes, not only the source code shape.
- Preserve core conversion flows while making layout, hierarchy, readability, or runtime health better.
- Keep the implementation stack-appropriate: use the existing framework, CMS, hosting provider, design system, and deployment workflow already in the project.
Acceptance criteria for this fix:
- The page renders without the reported console or uncaught page errors.
- No key interaction, analytics, or rendering flow breaks after the fix.
- The rendered page is visually stable and usable on mobile and desktop viewports.
- The fix does not hide content, break CTAs, introduce console errors, or reduce clarity for visitors.
- A fresh FreeScan rescan should show this check improved or passing after deployment.
## Output
Return a structured response with these headings: Findings, Changes Made, Verification Results, Rescan Expectation, Rollback Notes, 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.
- Prefer editing the canonical source of the page over patching built output, generated files, CDN-cached HTML, or minified assets.
- Do not make a cosmetic or placeholder change just to satisfy the scanner; the public page should be materially better for visitors, crawlers, or assistive technology.
- 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.

Page-level AEO readiness

Shared eligibility and content signals that affect every search and answer agent.

80/100 ready

Index and citation eligibility

No general noindex directive was detected.

Snippet and answer controls

No general nosnippet or max-snippet:0 control was detected.

Canonical alignment

No canonical URL was detected.

Sitemap coverage and freshness

The exact URL appears in sitemap.xml with lastmod 2026-05-27.

Structured data

Detected 0 JSON-LD block(s), 0 parse error(s), and types none.

Public or paywalled content

No isAccessibleForFree structured-data value was detected.

Entity clarity

Detected 3 of 3 core identity signals across the title, description, and H1.

Answer-ready visible text

Detected 2698 visible words and 27 audience, use-case, pricing, or integration signals.

Authorship and accountability

No author meta value or structured-data author was detected.

Published or updated date

No datePublished or dateModified value was detected in structured data.

Supporting-source links

No external supporting links were detected; this is contextual rather than a universal requirement.

Rendered content availability

Rendered audit completed with 128 visible text element(s).

Synthetic search-agent reachability

6 of 8 search/discovery User-Agent probes returned reachable content.

Optional LLM-readable summary

No llms.txt file was found; this is optional and does not reduce core AEO readiness.

OpenAIChatGPT search

OAI-SearchBot

PASS · ALLOWED

AI search

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

OpenAIOpenAI model training

GPTBot

OPTED OUT

Model training

Robots: blocked by gptbot disallow: / · line 55

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

OpenAIChatGPT user fetches

ChatGPT-User

UNKNOWN

User-requested fetch

Robots: not applicable to user-requested fetches

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AnthropicClaude model training

ClaudeBot

OPTED OUT

Model training

Robots: blocked by claudebot disallow: / · line 46

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AnthropicClaude search

Claude-SearchBot

FAIL · BLOCKED

AI search

Robots: allowed by * allow: / · line 31

Probe: blocked · HTTP 403

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AnthropicClaude user fetches

Claude-User

FAIL · BLOCKED

User-requested fetch

Robots: allowed by * allow: / · line 31

Probe: blocked · HTTP 403

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

GoogleGoogle Search and AI features

Googlebot

PASS · ALLOWED

Search and discovery

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

GoogleGemini data use and grounding

Google-Extended

OPTED OUT

Data-use policy control

Robots: blocked by google-extended disallow: / · line 52

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

MicrosoftBing and Copilot

Bingbot

PASS · ALLOWED

Search and discovery

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

PerplexityPerplexity search

PerplexityBot

FAIL · BLOCKED

AI search

Robots: allowed by * allow: / · line 31

Probe: blocked · HTTP 403

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

PerplexityPerplexity user fetches

Perplexity-User

UNKNOWN

User-requested fetch

Robots: not applicable to user-requested fetches

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AppleSiri, Spotlight, and Safari search

Applebot

PASS · ALLOWED

Search and discovery

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AppleApple foundation-model training

Applebot-Extended

OPTED OUT

Data-use policy control

Robots: blocked by applebot-extended disallow: / · line 37

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

Mistral AIMistral search

MistralAI-Index

PASS · ALLOWED

AI search

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

Mistral AIMistral user fetches

MistralAI-User

FAIL · BLOCKED

User-requested fetch

Robots: allowed by * allow: / · line 31

Probe: blocked · HTTP 403

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

MetaMeta AI model and product data

meta-externalagent

OPTED OUT

Model training

Robots: blocked by meta-externalagent disallow: / · line 58

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

MetaMeta AI user fetches

meta-externalfetcher

PASS · ALLOWED

User-requested fetch

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AmazonAmazon model training

Amazonbot

OPTED OUT

Model training

Robots: blocked by amazonbot disallow: / · line 34

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AmazonAlexa and Rufus search

Amzn-SearchBot

PASS · ALLOWED

AI search

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

AmazonAlexa user fetches

Amzn-User

PASS · ALLOWED

User-requested fetch

Robots: allowed by * allow: / · line 31

Probe: reachable · HTTP 200 · 100% parity

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

Common CrawlOpen web datasets

CCBot

OPTED OUT

Model training

Robots: blocked by ccbot disallow: / · line 43

Probe: not tested for this control

IndexSnippetsSitemapPublic content

Vendor documentationDefinition checked 2026-07-30

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

freerealm.org website audit report

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

Public report link

Markdown report

# freerealm.org Website Scan

Scanned URL: [https://freerealm.org](https://freerealm.org)
Report URL: /scan/freerealm-org-73-launch-readiness-report-4132d6a0
Created: 2026-08-05T03:31:17.662Z

## Score Summary

- Overall: 73/100
- SEO / AEO: 79/100
- Security: 79/100
- Accessibility: 57/100
- Design: 78/100

## Launch Readiness

Close to ready (Needs polish).

Passed: 26. Failed: 10. Unknown: 1.
Strongest area: SEO / AEO. Weakest area: Accessibility.

## AI Crawler Access

These results combine robots.txt policy, page controls, and bounded synthetic User-Agent probes. Synthetic probes do not prove that traffic came from the vendor; training and data-use choices are neutral publisher preferences.

- **OpenAI — ChatGPT search** (OAI-SearchBot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **OpenAI — OpenAI model training** (GPTBot): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by gptbot disallow: / on line 55. No synthetic fetch is appropriate for this policy or training control.
- **OpenAI — ChatGPT user fetches** (ChatGPT-User): UNKNOWN — robots not_applicable; synthetic probe not_tested. ChatGPT-User is used for user-requested retrieval, so robots.txt is not treated as a reliable access control for this row. No synthetic fetch is appropriate for this policy or training control.
- **Anthropic — Claude model training** (ClaudeBot): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by claudebot disallow: / on line 46. No synthetic fetch is appropriate for this policy or training control.
- **Anthropic — Claude search** (Claude-SearchBot): FAIL — robots allowed; synthetic probe blocked (HTTP 403). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 403.
- **Anthropic — Claude user fetches** (Claude-User): FAIL — robots allowed; synthetic probe blocked (HTTP 403). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 403.
- **Google — Google Search and AI features** (Googlebot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Google — Gemini data use and grounding** (Google-Extended): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by google-extended disallow: / on line 52. No synthetic fetch is appropriate for this policy or training control.
- **Microsoft — Bing and Copilot** (Bingbot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Perplexity — Perplexity search** (PerplexityBot): FAIL — robots allowed; synthetic probe blocked (HTTP 403). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 403.
- **Perplexity — Perplexity user fetches** (Perplexity-User): UNKNOWN — robots not_applicable; synthetic probe not_tested. Perplexity-User is used for user-requested retrieval, so robots.txt is not treated as a reliable access control for this row. No synthetic fetch is appropriate for this policy or training control.
- **Apple — Siri, Spotlight, and Safari search** (Applebot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Apple — Apple foundation-model training** (Applebot-Extended): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by applebot-extended disallow: / on line 37. No synthetic fetch is appropriate for this policy or training control.
- **Mistral AI — Mistral search** (MistralAI-Index): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Mistral AI — Mistral user fetches** (MistralAI-User): FAIL — robots allowed; synthetic probe blocked (HTTP 403). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 403.
- **Meta — Meta AI model and product data** (meta-externalagent): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by meta-externalagent disallow: / on line 58. No synthetic fetch is appropriate for this policy or training control.
- **Meta — Meta AI user fetches** (meta-externalfetcher): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Amazon — Amazon model training** (Amazonbot): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by amazonbot disallow: / on line 34. No synthetic fetch is appropriate for this policy or training control.
- **Amazon — Alexa and Rufus search** (Amzn-SearchBot): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Amazon — Alexa user fetches** (Amzn-User): PASS — robots allowed; synthetic probe reachable (HTTP 200). Allowed by * allow: / on line 31. Synthetic User-Agent probe returned HTTP 200 with 100% sampled-content parity.
- **Common Crawl — Open web datasets** (CCBot): PREFERENCE — robots blocked; synthetic probe not_tested. Blocked by ccbot disallow: / on line 43. No synthetic fetch is appropriate for this policy or training control.

## Page-level AEO Readiness

Readiness: 80/100

- **Index and citation eligibility**: PASS — No general noindex directive was detected.
- **Snippet and answer controls**: PASS — No general nosnippet or max-snippet:0 control was detected.
- **Canonical alignment**: FAIL — No canonical URL was detected.
- **Sitemap coverage and freshness**: PASS — The exact URL appears in sitemap.xml with lastmod 2026-05-27.
- **Structured data**: UNKNOWN — Detected 0 JSON-LD block(s), 0 parse error(s), and types none.
- **Public or paywalled content**: UNKNOWN — No isAccessibleForFree structured-data value was detected.
- **Entity clarity**: PASS — Detected 3 of 3 core identity signals across the title, description, and H1.
- **Answer-ready visible text**: PASS — Detected 2698 visible words and 27 audience, use-case, pricing, or integration signals.
- **Authorship and accountability**: UNKNOWN — No author meta value or structured-data author was detected.
- **Published or updated date**: UNKNOWN — No datePublished or dateModified value was detected in structured data.
- **Supporting-source links**: UNKNOWN — No external supporting links were detected; this is contextual rather than a universal requirement.
- **Rendered content availability**: PASS — Rendered audit completed with 128 visible text element(s).
- **Synthetic search-agent reachability**: UNKNOWN — 6 of 8 search/discovery User-Agent probes returned reachable content.
- **Optional LLM-readable summary**: INFO — No llms.txt file was found; this is optional and does not reduce core AEO readiness.

## Prioritized Fixes

### 1. Remove exposed sensitive files

- Category: Security
- Status: fail
- Severity: critical
- Rule points lost: 16
- Evidence: A small allowlist probe returned a public success response.
- Why it matters: Publicly exposed config or backup files can leak implementation details or secrets.
- Fix: Remove the exposed file, block public access to that path, and rotate any secrets that may have been exposed.

### 2. Improve AI search and crawler readiness

- Category: SEO / AEO
- Status: fail
- Severity: critical
- Rule points lost: 2
- Evidence: FreeScan.app reached the public page with HTTP 200. robots.txt blocks Claude-SearchBot, PerplexityBot from AI search or discovery for this page path. Synthetic or robots checks block Claude-User, MistralAI-User from user-requested fetches. GPTBot, ClaudeBot, Google-Extended, and 4 more are explicit training or data-use opt-outs and do not reduce the AEO score. AEO crawler readiness is 88%: discovery 45/45, index and snippet eligibility 20/25, synthetic reachability 13/20, sitemap freshness 10/10.
- Why it matters: AI search systems need crawlable, reachable, indexable, and quotable public content. Training and data-use choices remain neutral publisher preferences.
- Fix: Use the component scores and exact matched robots rules in the crawler report. Fix blocked search agents, noindex or snippet restrictions, canonical or sitemap gaps, and synthetic WAF/challenge failures. Preserve intentional training opt-outs and keep private, admin, and authenticated paths protected before rescanning.

### 3. Fix rendered axe accessibility violations

- Category: Accessibility
- Status: fail
- Severity: high
- Rule points lost: 18
- Evidence: axe found 1 violation rule(s), including 0 serious or critical rule(s). Top rules: region (13).
- Why it matters: axe checks the actual browser-rendered page, so these issues can affect people using keyboards, screen readers, or other assistive technology.
- Fix: Fix the top axe rule IDs first, especially critical and serious violations around names, roles, labels, headings, contrast, landmarks, and keyboard-accessible controls.

### 4. Label public form fields

- Category: Accessibility
- Status: fail
- Severity: high
- Rule points lost: 14
- Evidence: Detected labels or accessible names for 2 of 3 form control(s).
- Why it matters: Unlabeled inputs make email capture, demo requests, and signups harder for assistive technology users.
- Fix: Connect each input to a visible label or an accurate aria-label/aria-labelledby value.

### 5. Add a canonical URL

- Category: SEO / AEO
- Status: fail
- Severity: high
- Rule points lost: 10
- Evidence: No canonical link tag was detected.
- Why it matters: A canonical tag reduces duplicate URL confusion before marketing links start spreading.
- Fix: Add a canonical link tag that points to the final public landing page URL.

## Opportunities

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

- Impact: high
- Category: SEO / AEO
- Evidence: Pricing signals: 0. 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.

### Expose important supporting pages in navigation or footer

- Impact: medium
- Category: SEO / AEO
- Evidence: No pricing, docs, contact, security, privacy, terms, or about links were detected in public internal links.
- Why it matters: Internal links help visitors, crawlers, and AI answer systems discover supporting facts instead of relying on one landing page.
- Next step: Link to the most useful public pages, especially pricing, docs, contact, security, privacy, terms, and about pages where applicable.

### Make trust and proof easier to detect

- Impact: medium
- Category: Design
- Evidence: Detected 1 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.

### Tighten the live color system

- Impact: high
- Category: Accessibility
- Evidence: 5 of 100 rendered contrast sample(s) missed target. Worst ratio: 2.03.
- Why it matters: Computed contrast catches the actual colors visitors see after CSS, themes, and overlays are applied.
- Next step: Audit foreground/background token pairs for body text, muted text, links, buttons, inputs, and badges, then raise weak pairs to WCAG AA contrast targets.

### 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: 2698. H1 count: 1. Audience signals: 27. CTA labels: none detected.
- 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: Free Realm. H1: Beyond the reach 
        of any government. 
         Any corporation. Anyone.. Schema types: none.
- 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.

### No structured data detected

- Category: SEO / AEO
- Evidence: JSON-LD blocks: 0. Types: none. Parse errors: 0.
- Interpretation: Missing or invalid structured data makes the page rely more heavily on inferred meaning from text and layout.
- Recommended use: Validate JSON-LD and use only accurate facts that are visible or clearly supported on the public page.

### Weakest score area

- Category: Accessibility
- Evidence: SEO / AEO: 79/100. Security: 79/100. Accessibility: 57/100. Design: 78/100
- Interpretation: The weakest area is Accessibility, 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: 5. Console errors: 2. 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: 360ms. Load complete: 590ms. First contentful paint: 576ms. Resources: 17. Scripts: 4. Images: 4. Third-party origins: 5. 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: 1. Critical: 0. Serious: 0. Top rules: region.
- 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 freerealm.org without re-entering the URL. The previous report stays saved so the next result can be compared against it.

Website audit scorecard for freerealm.org

Remove exposed sensitive files

Copyable agent prompt

Improve AI search and crawler readiness

Copyable agent prompt

Fix rendered axe accessibility violations

Copyable agent prompt

Label public form fields

Copyable agent prompt

Add a canonical URL

Copyable agent prompt

SEO / AEO

Crawler access

Canonical tag

Schema presence

Security

Sensitive file probes

Accessibility

Rendered axe accessibility violations

Form labels

Basic contrast

Design

Text density

Spacing consistency

Runtime console health

Failed checks

Crawler access

Copyable agent prompt

Canonical tag

Copyable agent prompt

Schema presence

Copyable agent prompt

Sensitive file probes

Copyable agent prompt

Form labels

Copyable agent prompt

Basic contrast

Copyable agent prompt

Rendered axe accessibility violations

Copyable agent prompt

Text density

Copyable agent prompt

Spacing consistency

Copyable agent prompt

Runtime console health

Copyable agent prompt

AI crawler accessMajor AI search, user-fetch, and data-use agents checked for /, with robots evidence, synthetic reachability, and page-level AEO controls.8 pass4 fail2 unknown7 preferences

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 freerealm.org

Remove exposed sensitive files

Copyable agent prompt

Improve AI search and crawler readiness

Copyable agent prompt

Fix rendered axe accessibility violations

Copyable agent prompt

Label public form fields

Copyable agent prompt

Add a canonical URL

Copyable agent prompt

SEO / AEO

Crawler access

Canonical tag

Schema presence

Security

Sensitive file probes

Accessibility

Rendered axe accessibility violations

Form labels

Basic contrast

Design

Text density

Spacing consistency

Runtime console health

Failed checks

Crawler access

Copyable agent prompt

Canonical tag

Copyable agent prompt

Schema presence