Technical SEO · Accessibility · Performance · Security

SiteAudit AI

Automated website audits for technical SEO, accessibility and performance -- actionable, consistent reports for agencies and SMEs, in seconds instead of hours of manual review.

What the report separates

Latency, compression, caching and security headers are measured from the real HTTP response. Markup findings are inferred from the document. Every finding says which it is, so a client can tell a reading from a judgement.

A check that could not run is reported as not measured in its own right. It never becomes a fix, and it never moves the score in either direction — charging a client for a measurement nobody took is the one failure this report will not commit.

There is no headless browser here, so this does not report LCP, CLS or INP, and it does not see content rendered by JavaScript.

Four deliverables, one audit

An agency hands out four different things from the same reading: the full PDF for the client file, every finding on the record; the one-page summary for the meeting, scores and the top fixes on a single sheet; the spreadsheet for the backlog — one row per finding with its severity, its id and whether it was measured or inferred, so findings become tickets without anyone re-typing them out of a PDF; and the Markdown export for the issue tracker, the pull request or the internal wiki, where a PDF attachment is unreadable and a spreadsheet cell will not paste.

API

• POST /api/audit — body {"url":"https://example.com"}, returns the full JSON report.
• POST /api/audit/pdf — same body, returns the full report as a PDF deliverable.
• GET /api/audit/pdf?url=https://example.com — linkable full PDF report.
• GET /api/audit/summary.pdf?url=https://example.com — one-page executive summary, as a PDF.
• GET /api/audit/spreadsheet?url=https://example.com — every finding as a spreadsheet row.
• GET /api/audit/markdown?url=https://example.com — the same report as Markdown, for tickets and wikis.
• GET /health — service health check.

A request to one of these paths with the wrong method answers 405 with an Allow header listing the methods that path really accepts, rather than a 404 that would suggest the endpoint does not exist at all.

HEAD is answered wherever GET is, with the same status and the same headers and no body, so an uptime checker or a link verifier sees exactly what a browser would without downloading a report.

OPTIONS on any of these paths answers 204 with the same Allow header, so a client can discover what a path accepts without sending a request that would run an audit.