Everything That's Wrong

Evidence: See report for details.

Recommendation: Address this issue to improve your site.

Evidence: See report for details.

Recommendation: Address this issue to improve your site.

Evidence: See report for details.

Recommendation: Address this issue to improve your site.

Evidence: See report for details.

Recommendation: Address this issue to improve your site.

Evidence: See report for details.

Recommendation: Address this issue to improve your site.

All 6 pages have mobile Largest Contentful Paint between 5.3s and 6.7s, well above the 2.5s 'good' threshold. The homepage is worst at 6.7s median across 3 runs.

Evidence: Homepage LCP: 6.7s, 6.8s, 6.7s (3 runs). Sign-up: 5.3s. Contact: 6.6s. Sign-in: 5.4s. Terms: 5.3s. Privacy: 5.3s.

Recommendation: Reduce JavaScript bundle size through code splitting, lazy load non-critical routes, and implement critical CSS inlining. Consider SSG/ISR for static pages.

Homepage ships ~415 KiB of unused JavaScript code. Other pages have ~207-208 KiB unused. This is the primary cause of slow mobile LCP.

Evidence: Lighthouse consistently reports 'Reduce unused JavaScript' with est. savings of 415 KiB on homepage, 207 KiB on lighter pages.

Recommendation: Audit bundle with webpack-bundle-analyzer or next/bundle-analyzer. Implement dynamic imports for below-fold components. Remove unused dependencies.

One of three Lighthouse runs flagged TTFB at 810ms. This is intermittent but worth monitoring.

Evidence: First run showed 'Root document took 810 ms' warning with est. savings of 710ms. Other runs did not flag this.

Recommendation: Enable edge caching/CDN if not already active. Monitor TTFB over time. Consider moving to edge deployment (Vercel Edge, Cloudflare Pages) for faster cold starts.

Build includes ~13 KiB of legacy JavaScript polyfills that modern browsers don't need.

Evidence: Lighthouse reports 'Legacy JavaScript' with est. savings of 13 KiB across all pages.

Recommendation: Update Next.js browserslist targets to drop IE11 support if not needed. Use modern JavaScript syntax without transpilation for baseline features.

Pages cannot use browser bfcache, slowing back button navigation. 6 failure reasons flagged.

Evidence: All pages report 'Page prevented back/forward cache restoration' with 4-6 failure reasons.

Recommendation: Review bfcache failure reasons in DevTools. Common fixes: remove 'no-cache' headers on HTML, avoid unload handlers, close WebSocket connections on pagehide.

Requests to www.formagents.com stay at www, while requests to formagents.com stay at non-www. This can cause duplicate content issues in search engines and split link equity between the two domains.

Evidence: Discovery data shows: httpWww -> https://www.formagents.com/, httpsNonWww -> https://formagents.com. No cross-redirect between variants.

Recommendation: Configure server to redirect all www requests to non-www (or vice versa) consistently. Add canonical URL tags on all pages pointing to the preferred domain.

Content Security Policy in report-only mode logs violations for JavaScript evaluation. This is informational only and does not block functionality, but indicates the build process uses eval-like patterns.

Evidence: CSP report-only violations in _next/static/chunks/*.js files across all pages

Recommendation: Consider updating Next.js build configuration to avoid eval patterns, or update CSP to allow unsafe-eval if intentional. Low priority as these are report-only.

CSP is in report-only mode, not actively blocking malicious content. While a well-defined policy exists, it does not protect users until enforced.

Evidence: Header 'Content-Security-Policy-Report-Only' present but 'Content-Security-Policy' absent

Recommendation: After monitoring report-only CSP for violations, promote it to enforced mode by renaming the header to Content-Security-Policy

Without this header, browsers may MIME-sniff responses, potentially executing malicious content.

Evidence: X-Content-Type-Options header not present in responses

Recommendation: Add header: X-Content-Type-Options: nosniff

Without explicit control, full referrer URLs may be sent to third parties, potentially leaking sensitive URL parameters.

Evidence: Referrer-Policy header not present in responses

Recommendation: Add header: Referrer-Policy: strict-origin-when-cross-origin

Browser features like camera, microphone, and geolocation are not explicitly restricted.

Evidence: Permissions-Policy header not present in responses

Recommendation: Add Permissions-Policy header to restrict unnecessary browser features

Server and X-Powered-By headers reveal technology choices, aiding reconnaissance by attackers.

Evidence: Server: Google Frontend, X-Powered-By: Next.js

Recommendation: Remove or genericize Server and X-Powered-By headers. Note: Google Frontend header may not be configurable on Google Cloud hosting.

The report-only CSP policy allows 'unsafe-inline' for scripts and styles, which weakens XSS protection when enforced.

Evidence: CSP contains: script-src 'self' 'unsafe-inline' ...; style-src 'self' 'unsafe-inline'

Recommendation: Refactor code to use nonces or hashes instead of unsafe-inline, then update CSP accordingly

DMARC policy is p=reject (excellent), but no reporting addresses are configured. This means the domain owner has no visibility into delivery failures, authentication issues, or attempted spoofing.

Evidence: DMARC record: v=DMARC1; p=reject; adkim=r; aspf=r; — no rua or ruf tags present

Recommendation: Add aggregate reporting: v=DMARC1; p=reject; adkim=r; aspf=r; rua=mailto:dmarc@formagents.com; — Consider a service like dmarcian or Valimail for report analysis

MTA-STS (Mail Transfer Agent Strict Transport Security) is not configured. Without MTA-STS, email transport is vulnerable to downgrade attacks where an attacker could intercept or redirect mail by spoofing DNS.

Evidence: No TXT record found at _mta-sts.formagents.com

Recommendation: Configure MTA-STS by: 1) Publishing a policy file at https://mta-sts.formagents.com/.well-known/mta-sts.txt, 2) Adding a _mta-sts TXT record with policy ID

No DKIM selectors could be found using common selector names. This doesn't necessarily mean DKIM isn't configured, but it couldn't be verified. If DKIM is not configured for Google Workspace, emails may have reduced deliverability.

Evidence: Checked selectors: google, selector1, selector2, k1, default, dkim, mail — none returned DKIM records

Recommendation: Verify DKIM is configured in Google Workspace Admin Console under Apps > Google Workspace > Gmail > Authenticate email. Generate and publish DKIM keys if not already done.

SPF record ends with ~all (soft fail) instead of -all (hard fail). Soft fail marks failing emails as suspicious but doesn't reject them, reducing the effectiveness of SPF protection.

Evidence: SPF record: v=spf1 include:dc-aa8e722993._spfm.formagents.com ~all

Recommendation: After confirming all legitimate sending sources are included in SPF, change ~all to -all for strict enforcement

Domain has good nameserver redundancy (2 servers on different subnets), multiple A records for resilience, and properly configured MX records for email.

Evidence: NS: ns65.domaincontrol.com (97.74.102.43), ns66.domaincontrol.com (173.201.70.43). A: 4 Google IPs (216.239.32.21, 216.239.34.21, 216.239.36.21, 216.239.38.21). MX: 5 Google Workspace servers with proper priority ordering.

Recommendation: Continue current configuration. DNS foundation is stable.

Without CAA records, any Certificate Authority can issue SSL/TLS certificates for formagents.com. This is a minor security consideration.

Evidence: dig CAA formagents.com returned no records.

Recommendation: Consider adding CAA records to restrict certificate issuance to your preferred CA (e.g., Let's Encrypt, Google Trust Services, or whoever issues your certificates).

DNSSEC is not enabled for this domain. While common, this means DNS responses cannot be cryptographically verified, leaving potential for DNS spoofing attacks.

Evidence: WHOIS shows 'DNSSEC: unsigned'. No DS records found at parent.

Recommendation: Consider enabling DNSSEC through GoDaddy for enhanced security. Low priority unless handling highly sensitive data.

Domain does not have AAAA (IPv6) records. IPv6-only clients may have difficulty reaching the site.

Evidence: dig AAAA formagents.com returned no records.

Recommendation: If your hosting supports IPv6, add AAAA records for future-proofing. Low priority as most networks still support IPv4.

The primary teal color (#17ba99) used throughout the site has a contrast ratio of only 2.46:1 against white backgrounds. WCAG AA requires 4.5:1 for normal text and 3:1 for large text. This affects all CTA buttons, links, and brand elements site-wide.

Evidence: axe-core detected 29+ color contrast violations on homepage alone. Elements include: sign-up button (2.46:1), 'Talk To' text in H1 (2.46:1), 'With FormAgents' heading (2.46:1), all teal links and badges.

Recommendation: Darken the primary color to at least #0d8a70 for 4.5:1 contrast, or use a darker shade like #096b57 for better readability. Apply consistently via CSS custom property --primary.

The submit button in the FormAgents chat widget (used on homepage and contact page) contains only an icon with no text, aria-label, or title attribute. Screen reader users cannot identify what the button does.

Evidence: axe-core critical violation on / and /contact pages. Button HTML: <button type='submit' disabled=''> with no inner text or aria attributes.

Recommendation: Add aria-label='Send message' or include visually hidden text: <span class='sr-only'>Send message</span> inside the button.

The chat message area uses a Radix ScrollArea component that cannot be scrolled by keyboard users. Users who cannot use a mouse have no way to scroll through conversation history.

Evidence: Element [data-radix-scroll-area-viewport] has no tabindex attribute and overflow: hidden scroll. axe-core serious violation: 'scrollable-region-focusable'.

Recommendation: Add tabindex='0' to the scroll container and ensure it can receive focus. Add role='region' and aria-label='Chat messages' for screen reader context.

The homepage has heading structure problems: an H2 ('Try FormAgents') appears before the H1, and there's a skip from H3 to H4 ('Event Registration'). This confuses screen reader users navigating by headings.

Evidence: Heading sequence: H2 'Try FormAgents' -> H1 'Build Forms...' -> H2 -> H3 -> H3 -> H2 -> H3 -> H3 -> H3 -> H3 -> H3 -> H2 -> H4 'Event Registration' -> H2. Lighthouse flagged heading-order violation.

Recommendation: Restructure headings so H1 comes first. Change 'Try FormAgents' in chat widget to a visually styled div or use aria-hidden if it's not part of document outline. Change H4 to H3 for 'Event Registration'.

The 'Most Popular' badge on pricing uses orange (#f97316) with white text at 2.8:1 contrast. The indigo 'Enterprise' badge (#6366f1) with white text has 4.46:1 - just below the 4.5:1 threshold.

Evidence: axe-core violations on homepage pricing section. Orange badge: foreground #ffffff, background #f97316, 2.8:1 ratio. Indigo badge: foreground #ffffff, background #6366f1, 4.46:1 ratio.

Recommendation: For orange: darken to #c25c04 or use dark text on light orange background. For indigo: darken slightly to #4f46e5 to achieve 4.5:1 minimum.

Search engines cannot understand your business type, services, or organization details. No Organization, WebSite, or Product schema found. This limits rich result eligibility and reduces context for search engines.

Evidence: Checked all 6 pages for script[type='application/ld+json'] - none found

Recommendation: Add Organization schema to homepage with name, logo, URL, and contact info. Consider adding WebSite schema with SearchAction for site search. Add FAQ schema if FAQ content is added.

The homepage, sign-up, and sign-in pages all have identical titles. This confuses search engines about page differentiation and dilutes ranking signals. Users in search results cannot distinguish between these pages.

Evidence: Title tag on /, /sign-up, and /sign-in all return 'FormAgents - Build Forms People Can Call'

Recommendation: Create unique, descriptive titles: 'Sign Up - Create Your Free FormAgents Account' for sign-up, 'Sign In - FormAgents Dashboard' for sign-in. Keep homepage title as is.

The /sign-up and /sign-in pages lack canonical URL tags. Without explicit canonicals, search engines must guess the preferred version, potentially causing duplicate content issues if pages are accessible via multiple URL variations.

Evidence: link[rel='canonical'] element absent on /sign-up and /sign-in pages

Recommendation: Add self-referencing canonical tags: <link rel='canonical' href='https://formagents.com/sign-up'> and <link rel='canonical' href='https://formagents.com/sign-in'>

The robots.txt file returns 404. While crawlers will assume full access, having a robots.txt is best practice for controlling crawl behavior and pointing to sitemaps.

Evidence: HTTP 404 response from https://formagents.com/robots.txt

Recommendation: Create a robots.txt file with User-agent: * and Allow: /. Include Sitemap directive pointing to sitemap.xml.

No sitemap.xml found. Search engines must discover pages through crawling alone, which may result in slower or incomplete indexing, especially as the site grows.

Evidence: HTTP 404 response from https://formagents.com/sitemap.xml; Discovery phase found no accessible sitemaps

Recommendation: Generate an XML sitemap listing all public pages (/, /contact, /terms, /privacy). Exclude auth pages (sign-up, sign-in) if not intended for organic search. Submit to Google Search Console.

Requests to www.formagents.com stay on www, while non-www requests stay on non-www. This could cause search engines to see two versions of the site, diluting link equity.

Evidence: Discovery data shows: httpsWww stays at www.formagents.com, httpsNonWww stays at formagents.com

Recommendation: Configure server to redirect all www requests to non-www (or vice versa). The canonical on homepage points to non-www, so redirect www to non-www for consistency.

AI search engines rely heavily on structured data to understand entities, products, and organizations. Without JSON-LD markup, AI systems must infer meaning from unstructured text, reducing the chance of being cited accurately.

Evidence: All 6 pages return hasJsonLd: false with empty jsonLdTypes arrays. No Organization, Product, SoftwareApplication, or FAQPage schemas present.

Recommendation: Add Organization schema to homepage, SoftwareApplication schema for product description, and FAQPage schema for the use cases section which functions as an FAQ.

AI systems prefer content with clear attribution. Anonymous content is less likely to be cited as authoritative in AI-generated answers.

Evidence: author: null on all pages. No bylines, no 'About Us' page linked in navigation, no team information, no publication or last-updated dates visible.

Recommendation: Add an About page with team/company information. Consider adding author bylines for any blog or documentation content. Add lastModified dates to legal pages.

While the homepage communicates the product well, the core value proposition uses metaphorical language that's harder for AI to extract as a direct answer.

Evidence: H1 is 'Build Forms People Can Talk To' - creative but not a direct definition. The meta description is better: 'Design a form with AI, assign it a phone number, and let anyone call to submit information 24/7.'

Recommendation: Add a clear definition-style statement early on the homepage: 'FormAgents is an AI-powered form builder that lets you create conversational forms people can fill out by calling a phone number or chatting on your website.'

The 'When Phone Access Matters Most' section contains question-and-answer style content but lacks FAQPage schema, missing an opportunity for rich results and AI citation.

Evidence: 6 use cases on homepage (After-Hours Support, Senior-Friendly Service, etc.) each answer implicit questions like 'When should I use phone forms?' but have no schema markup.

Recommendation: Either convert this section to explicit FAQ format with FAQPage schema, or create a dedicated FAQ page addressing common questions about the product.

Clear pricing ($0, $29, $99, Enterprise) is present but not structured in a way AI can easily extract and cite.

Evidence: Pricing section uses plain text for 'Free', '$29/month', '$99/month', 'Custom' without Product or Offer schema.

Recommendation: Add Product schema with Offer pricing for each plan tier. This enables AI to accurately answer 'How much does FormAgents cost?'

Homepage lacks customer testimonials, logos, or reviews in the hero section. Users must scroll significantly to find any trust indicators. For a SaaS product handling business communications, trust signals are critical for conversion.

Evidence: Reviewed homepage screenshots across desktop (1440px) and mobile (390px) viewports - no customer logos, testimonial quotes, or 'trusted by' sections visible without scrolling

Recommendation: Add 3-5 customer logos or a brief testimonial quote in the hero section, positioned near the primary CTA

The primary brand color (#17ba99 teal) used for CTAs has a contrast ratio of only 2.46:1 against white text, well below WCAG AA requirements. This affects all conversion buttons site-wide and reduces their visual impact.

Evidence: Lighthouse accessibility audit flagged 29 color contrast failures on homepage alone. All 'Sign up', 'Get Started Free', and 'Contact Sales' buttons affected.

Recommendation: Darken the teal to at least #0f9076 to achieve 4.5:1 contrast ratio while maintaining brand identity

Signup page doesn't indicate what happens after signup - no preview of onboarding, no mention of what users will do first, no time expectation set.

Evidence: Reviewed signup page on both viewports - form includes only email/password fields with terms agreement. No 'What's next?' messaging or onboarding preview.

Recommendation: Add brief copy below signup button: 'Create your first form in under 2 minutes' or similar expectation-setting message

The contact/sales page uses FormAgents' own conversational form product as the contact method. This is clever product demonstration that builds confidence while capturing leads.

Evidence: Contact page at /contact shows the FormAgents chat widget with clear '~2 minutes' time estimate and email fallback option

Recommendation: This is working well - consider adding similar conversational elements to other high-intent pages

Four-tier pricing (Free, Basic $29, Pro $99, Enterprise) is clearly laid out with feature comparison. 'Most Popular' badge on Pro tier guides decision-making. Free tier lowers initial commitment barrier.

Evidence: Pricing section visible on homepage with clear tier comparison, feature lists, and CTAs for each plan

Recommendation: Consider adding annual pricing toggle or money-back guarantee messaging to further reduce purchase anxiety

The primary teal color (#17BA99) used for buttons, links, and accents fails WCAG 2.1 AA contrast requirements against white backgrounds

Evidence: Contrast ratio of 2.46:1 for white text on teal buttons (requires 4.5:1); 2.46:1 for teal text on white (requires 3:1 for large text)

Recommendation: Darken the primary brand color to at least #0D8A71 to meet WCAG AA standards while maintaining brand identity

Pricing section uses three different button colors: teal (Free/Basic), orange (Pro), and indigo (Enterprise)

Evidence: Homepage uses consistent teal CTAs; pricing page introduces orange (#F97316) and indigo (#6366F1) variants

Recommendation: Acceptable for visual hierarchy if intentional; document in brand guidelines to ensure consistent future usage

Contact page uses more casual, conversational tone compared to rest of site

Evidence: Contact chatbot opens with 'Hey! Thanks for reaching out...' while rest of site maintains professional tone

Recommendation: Minor observation; the casual tone may be intentional for the conversational interface context

Total JavaScript is ~2.4 MB uncompressed (600 KB gzip). Lighthouse identifies 415-417 KiB of unused JavaScript on the homepage. Two bundles dominate: 949052e81f06e226.js (792 KB) and fb75085a31ae1382.js (414 KB).

Evidence: Lighthouse unused-javascript audit shows potential savings of 415 KiB on mobile, 417 KiB on desktop. Network analysis shows 23 JavaScript chunks totaling 2,475,166 bytes uncompressed.

Recommendation: Audit dependencies with bundle analyzer. Large chunks likely contain libraries loaded but not fully used on all pages. Consider dynamic imports for route-specific code.

Content Security Policy is configured but uses eval() in JavaScript chunks, triggering CSP violations. Currently in report-only mode so execution continues, but this blocks enforcing CSP.

Evidence: Console shows: 'Evaluating a string as JavaScript violates CSP directive' for chunks fb75085a31ae1382.js and 949052e81f06e226.js

Recommendation: Identify which dependency uses eval() (likely a form validation library or animation) and replace with CSP-compatible alternative, or configure webpack/turbopack to avoid eval in production.

8 of 10 recommended security headers are missing. While HSTS and X-Frame-Options are present, the site lacks X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and cross-origin isolation headers.

Evidence: Headers check shows missing: Content-Security-Policy (only report-only), X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy

Recommendation: Add X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and consider enforcing CSP once eval issue is resolved.

Next.js static chunks have excellent caching (immutable, 1 year), but logo.svg and other public assets have max-age=0, causing unnecessary re-downloads.

Evidence: curl -I shows _next/static/* has 'cache-control: public, max-age=31536000, immutable' but logo.svg has 'cache-control: public, max-age=0'

Recommendation: Configure Cloud Run or CDN to serve public assets (logo.svg, images) with long cache times. Consider using Next.js Image component for automatic optimization.

Build includes legacy JavaScript polyfills for older browser support, adding ~13 KiB of unnecessary code for modern browsers.

Evidence: Lighthouse legacy-javascript-insight audit shows 'Est savings of 13 KiB'

Recommendation: Configure browserslist target to modern browsers only if legacy support isn't needed, or use module/nomodule pattern to serve modern JS to capable browsers.