"Show IH:" I built an AI website health checker because every "free SEO audit" tool I found was actually a lead-gen trap
What I built: SiteSense AI — paste any URL, get back an AI-generated health score covering SEO, performance, accessibility, and a newer category I added called "AI Search Visibility" (basically: can ChatGPT/Perplexity/Gemini even crawl and cite your site — most people have never checked this).
Try it with zero signup: sitesense-ai-nine.vercel.app/demo
Why I built it: I went looking for a simple site audit tool and found two categories of thing — $140+/month agency platforms (Semrush) built for teams with budgets, or "free audit" tools that are actually lead-gen forms where submitting your URL just hands your email to an SEO agency's sales funnel. I wanted something that actually just tells you what's wrong with your site, for free, with no strings.
Tech stack: Next.js 15 + TypeScript frontend on Vercel, FastAPI backend on Render, Supabase for auth/data, Gemini for the actual analysis. Scoring runs on a fixed rubric (point deductions per issue found), not just free-form AI vibes, so the same site scores consistently instead of randomly.
Where it's at: live and working, free tier is 5 scans/month, no paid plan yet. Built this over the past couple weeks, including a genuinely painful stretch fighting Windows PowerShell execution policies and a silently-failing Vercel build — the usual indie dev stuff.
What I'd love feedback on:
Does the score feel accurate for your own site?
Anything confusing or missing in the report?
Would this be worth paying for, and what would make it worth it to you?
Happy to answer anything about the build.
Really like the framing — the "free audit = lead-gen form for your email" thing is exactly why this space feels so gross to wade into. Good on you for just showing the results.
One piece of honest feedback on the accessibility slice specifically (it's the corner I work in): I'd be careful using Gemini to score accessibility. Unlike SEO "best practices," a11y has deterministic, testable rules — WCAG success criteria that a rules engine like axe-core can check exactly (missing alt text, contrast ratios, ARIA misuse, etc.). An LLM tends to be inconsistent and can even hallucinate issues that aren't there — which quietly undercuts your great "fixed rubric = same score every time" pitch. For that one category, a deterministic engine under the hood would make the number defensible.
On "would I pay for it": your most interesting, least-crowded wedge is AI Search Visibility. SEO scores compete with a dozen free tools + Semrush, but "can ChatGPT/Perplexity actually crawl and cite my site" is a question almost nobody is answering yet. I'd consider leaning the whole product toward that.
Nice ship 👏
Really appreciate this feedback. You're absolutely right about accessibility being more deterministic than SEO or AI visibility. We're already evaluating adding axe-core-based checks so accessibility scores are consistent and defensible.
Also appreciate the point on AI Search Visibility. That's actually the direction we're leaning toward — treating SEO as supporting context while focusing on the question businesses increasingly care about: "Can AI systems discover, understand, and cite my content?"
Thanks for taking the time to dig into it.
Hey prasib — circling back on the axe-core point. Since you said you're evaluating axe-core for the accessibility slice, figured I'd just show you the thing instead of talking about it: I built a hosted scanner on axe-core (AbleScan) — paste a URL, get the WCAG/EAA violations in plain language plus the exact fix for the first one. Free, no signup.
Curious what it flags on SiteSense's own pages — run it on any URL you care about. And since it's framed around the EU Accessibility Act, if you've got EU users it doubles as a compliance check, not just a score.
ablescan.app — same honest, no-lead-gen spirit as what you built, so figured you'd actually appreciate the tool instead of a pitch.
This is really cool—thanks for sharing the link! Dropping a clean, hosted runner for axe-core with plain-language fixes and EAA context is a fantastic concept, especially given how messy legal compliance messaging usually gets. I ran the sitesense-ai-nine URL through it: The Clean Bill of Health: It scored a 100/100 with 0 issues found across 24 rules. Nice to know our base DOM markup, contrast, and basic ARIA setups are clean right out of the box. Plain-Language & Legal framing: Framing it directly around WCAG 2.1 A/AA and the EU Accessibility Act makes the output feel actionable for business owners rather than just dumping dev console logs. The main challenge we're weighing as we integrate axe-core into SiteSense is managing expectations around automated vs. manual coverage. While axe-core is great for catching deterministic structural bugs (like color contrast, missing labels, and structural HTML), static scanners generally miss dynamic states, complex keyboard focus traps, and screen-reader flow context. We're figuring out how to present an accessibility metric that feels reliable without giving users a false sense of absolute compliance. Appreciate you sharing AbleScan—it's a super slick implementation!
Ha — 100/100 is almost the awkward case for a scanner like mine: you got the clean bill, but not the "here's your problem + the fix" payoff that's the actual point. Glad the framing still landed.
On automated-vs-manual — that's the exact tension I live in, so a few honest notes:
The number has to describe what it measured, never what it didn't. Automated rules catch maybe a third of WCAG; the rest — focus order, keyboard traps, SR flow, dynamic states, exactly what you listed — just isn't machine-testable. So a "100" has to mean "passed every automatable check," not "accessible." The moment the UI lets someone read it as "compliant," you've rebuilt the same false-confidence trap you set out to kill.
It gets sharper with AI-scaffolded stacks like both of ours: modern component libs hand you the automatable third for free, so almost everything now scores high on the easy rules. That makes the manual two-thirds the only part that actually separates a real accessibility story from a green number.
What's worked for me: scope the score's label to the engine, and surface the non-automatable stuff as a separate "needs a human" checklist instead of folding it into the number — turns the limitation into the honest-differentiator you already lead with.
Happy to compare notes as you wire axe-core in — with a Next app the timing gotcha (scanning before the page finishes hydrating = phantom passes/fails) tends to bite first.