We built TopSyde's website audit to turn the public signals on a homepage into a useful list of fixes. It checks performance, SEO, AEO/GEO, structure, UX, and security, then uses Claude to explain what needs attention and what to do first.
Run a free homepage audit with your website address and email. The report appears on screen, with a copy sent by email. No account, payment, or website login is required. Allow a few minutes for a fresh audit.
What AI Adds to a Website Audit
Some questions have a direct answer in the page source: is there a title, does the response include a security header, and how many script tags load without async or defer? We collect those facts in code before asking Claude to assess the page.
The model's job is to connect the findings. A large HTML response, many blocking scripts, and a recognizable page builder can point toward a useful performance investigation. A missing description and unclear headings can become an editing task that a site owner understands.
That interpretation still needs boundaries. A public homepage cannot reveal checkout abandonment, the contents of a private database, or how visitors behave after clicking a button. The report gives you findings to investigate, with estimated gains where relevant. Those estimates are not measured improvements or promises of more traffic.
Architecture: How We Fetch, Collect, and Analyze
The audit follows a short pipeline:
Public page fetch → Structured signals + HTML excerpt → Claude analysis → Validated report
Stage 1: Fetch the Public Page
The form is designed for a homepage check. We fetch the submitted URL, follow permitted redirects, and record the response status, headers, response timing, and HTML.
We also fetch robots.txt and llms.txt and resolve the site's sitemap, including sitemap indexes. Reading sitemap entries helps describe the site's public structure and check for suspicious URL patterns. It does not mean that every listed page has been crawled or audited.
The collector makes HTTP requests and reads the returned markup. It does not run a headless browser or execute the page's JavaScript. If a site builds its navigation or content entirely in the browser, the initial HTML may be incomplete. A rendered crawl or a manual browser check is needed to confirm findings about that content.
Stage 2: Extract Measurements Before Asking the Model
The collector turns the response into a structured signals object:
| Signal group | What the collector reads | What it helps evaluate |
|---|---|---|
| Response and page weight | Time to first byte, fetch duration, HTML size, headers | Server response and page-weight concerns |
| Metadata and headings | Title, description, canonical, robots meta, heading counts | Search presentation and document structure |
| Scripts, styles, and images | Resource tags, blocking attributes, image alt text and responsive-image markup | Potential loading and accessibility issues |
| Structured data | JSON-LD types and microdata markers | Machine-readable context for search and AI discovery |
| Security | HTTPS, security headers, public markup and sitemap signals | Visible configuration gaps and suspicious patterns |
| Platform hints | CMS, page-builder, and CDN fingerprints | Recommendations that fit the detected stack |
These are observations from the fetched response. Time to first byte is not a Core Web Vitals score, and counting scripts does not measure their execution cost. The public audit does not run Lighthouse or WebPageTest, collect real-user measurements, or connect to your analytics account.
We send Claude both the structured signals and a bounded HTML excerpt. Keeping the measured facts separate makes it easier to ask for an explanation without asking the model to invent the measurements.
Stage 3: Produce a Structured Report
A fresh audit sends those inputs to a configured Claude model through the Messages API. One analysis request covers the six categories.
The response is JSON with an overall score, category scores, individual checks, and recommendations ranked by impact, with effort estimates. The application validates that response with Zod before building the report. A malformed response produces an error instead of being presented as a completed audit.
The server fills the report's overview with collected facts such as the final URL, response timing, and resource counts. It also adds findings from the collector's integrity checks so a suspicious public-code pattern does not depend entirely on the model mentioning it.
Prompt Engineering: Keeping the Report Tied to the Page
A useful prompt defines what the model can assess, what evidence it has, and how the answer must be structured.
Our rubric covers:
- Performance: response timing, HTML weight, blocking resources, and image markup
- SEO: titles, descriptions, canonical tags, headings, and crawl directives
- AEO/GEO: structured data, content organization, and public crawler-discovery files
- Structure: page complexity and CMS or page-builder signals
- UX: visible content organization and basic form and accessibility signals
- Security: HTTPS, response headers, and public signs that need investigation
The prompt asks for short checks with an evidence field and a focused set of recommendations. The current target is 16-20 checks and 5-7 recommendations. Those are report-generation targets, not a fixed count of tests guaranteed on every site. Recommendations are sorted by impact, with a limit on the ordinary recommendation list; integrity findings can add a further item.
Keep Measurements and Inferences Separate
A missing header is a directly observed fact. The business effect of adding it depends on the site. A recommendation should make that distinction readable.
The prompt tells Claude to quote supplied numbers accurately and qualify findings drawn from initial HTML. For example, if no internal links appear in that response, the report should say what the collector saw and identify the need for a rendered check. It should not conclude that the live site has no navigation.
Schema validation helps keep the report usable, but it does not establish that every judgment is correct. Review a proposed change against the site before applying it, especially if it affects security headers, templates, or third-party integrations.
Fit the Advice to the Platform
A WordPress owner with server access can make changes that a merchant on a hosted platform cannot. We add platform-specific constraints when the collector recognizes the CMS.
Those instructions keep the recommendations within the platform's available controls and tell the model to avoid asserting unobserved defaults. A missing signal in one response should lead to a checkable next step, not a claim about every site on that platform.
Cost Optimization: Control the Work Each Audit Generates
The public audit has two substantial pieces of model input: structured signals and the HTML excerpt. The response also takes work to generate. A longer list of checks and recommendations increases both output size and the time someone waits to read it.
We limit the excerpt, ask for concise explanations, and keep the recommendations focused. We record input and output token usage alongside the duration of saved reports so changes can be evaluated against completed runs. That provides a basis for comparing model settings and prompt revisions without inventing a universal cost per site.
Reuse a Recent Result for the Same URL
The route uses Redis to cache an audit by normalized URL for 24 hours. A repeated request can display that stored result instead of fetching the site and generating a new analysis.
The interface shows when the cached report was generated and when a fresh audit becomes available. If the same email already has a recent report for that URL, the route avoids creating another lead row and sending another copy of the same report.
This is URL-based result reuse. It does not substitute another customer's audit because their theme, industry, or platform looks similar. If you change your site during the cache window, check the report timestamp before treating it as a fresh measurement.
Performance and Reliability
A fresh report can take a few minutes. Site response time, model availability, and the amount of output all affect the wait. The visitor-facing route can request faster model processing where the configured model supports it. If that mode is refused with a supported fallback status, the request retries at standard speed. Requesting the faster mode is not proof that a particular audit used it or finished sooner.
Show the Report Before Preparing the Email
The route streams server-sent events over the audit request. It sends the completed result to the browser before saving the lead, rendering the PDF, and sending emails. The browser can therefore show the report while those later steps finish.
The server keeps the response open while post-processing runs. Duplicate result events and errors arriving after a completed report should not replace that report with an error screen. This behavior is covered by the frontend's mocked stream checks.
The PDF and email are delivery steps, not prerequisites for reading the result on screen. The public flow runs over the streaming request without a separate background job queue or WebSocket connection.
Handle Refusals Without Inventing Findings
The API validates public URLs, screens submissions, and supports per-IP rate limits. Rate-limit responses include retry information. If a site's firewall refuses the fetch, the interface explains the block instead of generating an audit of an error page.
A failed model response also remains a failed attempt. Saved report rows contain completed outputs, so counting them alone cannot establish the tool's completion rate. Measuring attempts and failures separately matters when evaluating whether a change helped visitors get through the flow.
Lessons for Building AI Analysis Products
The useful engineering work is making the model's inputs and limits explicit, then keeping the report readable.
Collect facts in code when you can. Give the model a bounded task and a defined output format. Validate the structure, preserve the distinction between measurements and estimates, and test the browser behavior when a request fails or a stream ends unexpectedly.
Measure the whole wait that the visitor experiences. Cutting an unnecessary paragraph from every recommendation can matter as much as choosing a different model setting. Check actual completed runs before making a new speed claim.
The report is a starting point for work on the site. It does not apply fixes, schedule recurring audits, or grant access to your hosting account. You can take the findings to your own developer or use them to discuss the work with TopSyde.
Run the free homepage audit to see the report on your own site. If your immediate concern is a possible infection, the free malware scanner checks public signs of malware and suspicious redirects without requiring an email to show the result. Neither public tool can inspect private server files or certify that a site is malware-free.
Keep Reading on TopSyde
Topics
Founder & Lead Developer
20+ years full-stack development, WordPress, AI tools & agents
Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.
