How We Built an AI Website Detector: Architecture and Design Decisions
Most of what's written about AI detection tools describes what they claim to do. This is about the actual engineering decisions behind ours, including the ones that trade away capability on purpose.
We never execute JavaScript, on purpose
When you submit a URL, our server fetches it the way a search engine crawler does — a single HTTP request, reading whatever HTML comes back, with no headless browser and no client-side script execution. That's a real trade-off: a page that builds its entire DOM client-side after the initial response can hide evidence we'd otherwise find. We made this choice anyway, for two reasons. First, running a full browser per request is an order of magnitude more expensive and slower, for a tool that's free and has no rate limit. Second, and more importantly, it keeps every result explainable: the evidence we show you is a literal substring of the response your own browser would also receive, not something conjured by executing arbitrary third-party code server-side.
A public URL-fetcher is a security liability if you're not careful
Any tool that fetches a URL a stranger gives it is a classic server-side request forgery vector — nothing stops someone from pointing it at an internal address instead of a real website. Before any fetch happens, we check the resolved hostname against a blocklist of loopback and private IP ranges and refuse the request outright. We also cap the response at a few megabytes and enforce a hard timeout, so a slow or enormous page can't tie up server resources indefinitely. None of this is exotic, but skipping it is exactly how these tools get abused.
Hand-weighted rules instead of a trained classifier
We could have trained a model on labeled examples of AI-built and hand-built pages and let it output a probability. We didn't, because that approach can't do the one thing we care about most: show you exactly why. Every signal in our six categories is a deterministic, auditable rule with a fixed weight we chose by hand — a builder's CDN domain is worth more than a weak hosting-header correlation, an actual attribution claim is worth more than a bare mention, a CMS marker actively subtracts confidence rather than just failing to add it. A black-box model might be marginally more accurate in aggregate, at the cost of never being able to tell you which specific piece of evidence drove a specific score.
Rules get it wrong, and we treat that as routine, not exceptional
A fixed rule matching a class name or a CDN domain will eventually collide with something unrelated — an open-source font that happens to share a builder's naming prefix, or a platform's own homepage referencing its own CDN in a way that looks identical to genuine attribution. We've hit both. Rather than treat that as an embarrassing edge case to quietly patch, we log every fix on the accuracy log — most recently after scanning 20 real sites turned up three of them in one afternoon. A rule-based system's biggest advantage over a trained model is that when it's wrong, you can point at the exact line responsible and fix that line — not retrain and hope.
What this buys you as a user
Every result page lists every signal that fired, with its exact matched evidence, and every category we checked but found nothing for. Nothing is summarized away. If you disagree with a score, you can see precisely which rule produced it and judge the evidence yourself — which is the entire point of building it this way instead of the simpler, more common alternative of returning a single confident-sounding number.
Read the full signal-by-signal breakdown on the methodology page, or try it on a site of your choosing.