I built an AI website audit tool in Make.com. Here's the whole thing.

I wanted a tool on my site that did something real rather than just claiming expertise. Most agency sites say they know SEO. Very few let you test it in thirty seconds.

So I built an audit tool. You submit your URL, and a few minutes later you get a report covering page performance, SEO structure, and something most audits ignore entirely — whether AI systems can actually read and cite your site.

Here's how it works, end to end.

The architecture

The whole thing runs on Make.com. Eight modules:

1. Webhook receives the form submission from my site
2. HTTP GET fetches the raw HTML of the submitted URL
3. PageSpeed Insights API returns Core Web Vitals and Lighthouse data
4. Set variable assembles both data sources into a single prompt
5. Claude API generates the report
6. Set variable wraps the output in a branded HTML email
7. Hostinger Mail API sends the report to whoever requested it
8. Hostinger Mail API sends me a notification

No database, no server, no backend code. The website itself is static HTML — the form just POSTs JSON to a Make webhook.

Why two data sources

PageSpeed alone tells you a site is slow. It doesn't tell you the H1 is missing, or that there's no structured data, or that nothing on the page states plainly what the business does.

So I fetch the raw HTML too. The model gets both: Lighthouse metrics for the performance section, and the actual markup for everything else. That's what makes the AI-readiness section possible — you can only assess whether an AI can understand a page by looking at what's actually in it.

Both inputs are truncated before they hit the API — 12,000 characters of PageSpeed data, 14,000 of HTML. That caps the cost per run regardless of how bloated the site is. A heavy e-commerce homepage costs the same as a lean landing page.

The prompt is mostly constraints

The interesting part of the prompt isn't the instructions about what to write. It's the rules about what not to do:

• Base every claim strictly on the data provided
• Never invent metrics, scores or findings
• If data for a section is missing or unreadable, say so plainly rather than guessing
• Do not promise rankings, traffic or revenue outcomes

That last one matters commercially. An automated tool that promises "you'll rank #1 if you fix these" is generating claims I'd have to stand behind. An automated tool that says "your H1 is missing and here's why that matters" is just true.

There's also an explicit instruction telling the model that either data block might contain an API error instead of real data, and to say so rather than fabricating numbers. That's not paranoia — it happened, repeatedly, while I was building it.

What it costs

About four US cents per audit. Roughly:

A hundred audits costs about four dollars. Plus eight Make operations per run, which on the free tier gives you around 125 audits a month.

The cost genuinely isn't the constraint. Whether the leads convert is the constraint.

What I'd do differently

Build the error handling first, not last. My original version treated every failure as fatal, which meant a temporary PageSpeed rate limit killed the entire audit. Now a PageSpeed failure degrades to a partial report — you still get SEO structure and AI-readiness, with a note that performance data couldn't be retrieved.

That's a better failure mode than nothing at all, and it took a live failure for me to build it.

I wrote separately about the four things that broke while building this. Some of them were genuinely stupid.