A useful website audit checklist is fixed and inspectable: the same checks, the same thresholds, on every site. webvise published its own as a free tool. The WP Health Report runs 13 named performance checks, 5 Core Web Vitals, and 3 rule-based security flags against any public URL in about 60 seconds, with no access, plugin, or install required.
Every check in this article is copied from the tool's source code, down to the threshold that decides whether a finding makes the report. Most audit checklists end in judgment calls, like rating your own value proposition. A check you cannot score the same way twice is an opinion.
If you searched for a website audit checklist, you want something you can run today without hiring anyone. This article delivers the 60-second pipeline, the 13 checks with their 0.9 scoring rule, the 5 vitals with green thresholds, the WordPress fingerprinting logic, and a 30-minute manual runbook.
- The [WP Health Report](/wp-health-report) is the automated version of this checklist. It runs entirely on public data and takes about 60 seconds per site.
- Only Lighthouse audits scoring below 0.9 count as findings. The report sorts them worst first and shows the top 5 with estimated savings.
- 5 Core Web Vitals are read from the mobile run: FCP, LCP, TBT, CLS, and Speed Index.
- WordPress is detected through 5 markers, PHP through 3. One hit is enough to raise the matching security flag.
- Every step can be reproduced by hand in about 30 minutes. The runbook is in the second half of this article.
How the 60-second pipeline works
The tool validates the URL, then calls Google's PageSpeed Insights API v5 twice in parallel: one mobile run, one desktop run, performance category only, each with a 20-second timeout. Fingerprinting, issue extraction, vitals, and the security rules follow. The PageSpeed calls dominate the runtime, which is why the whole report lands in about 60 seconds.
Findings and vitals both come from the mobile run, and that is deliberate. Mobile Lighthouse throttles CPU and network, so it produces the stricter of the two scores, and mobile is the surface Google indexes first. The desktop score appears in the report for context.
The 13 performance checks and the 0.9 rule
The tool requests exactly 13 Lighthouse audits, listed in the table below. An audit becomes a finding only when its score drops below 0.9. Everything above that passes silently. Findings are sorted worst first, and the report shows the top 5 with estimated savings in milliseconds where Lighthouse provides them.
I capped the output at 5 findings on purpose. A 30-item issue dump reads like noise and gets ignored, while 5 findings with the worst on top work as a fix order a developer can start on today.
| Check (Lighthouse audit ID) | What it flags |
|---|---|
| render-blocking-resources | CSS and scripts that delay the first paint |
| unused-javascript | Shipped JavaScript the page never executes |
| unused-css-rules | Stylesheets loaded but never applied |
| unminified-javascript | Scripts served without minification |
| unminified-css | Stylesheets served without minification |
| total-byte-weight | Total page weight across all requests |
| server-response-time | Slow time to first byte from the host |
| dom-size | Oversized DOM trees, often from page builders |
| redirects | Redirect chains before the final URL |
| uses-text-compression | Missing gzip or Brotli compression |
| uses-optimized-images | Images served oversized or in legacy formats |
| offscreen-images | Below-the-fold images loaded eagerly |
| uses-responsive-images | One large image served to every viewport |
WordPress sites tend to fail the same three: render-blocking-resources from theme stylesheets, unused-javascript from page builders, and server-response-time from PHP hosting without caching. The mechanics behind that pattern are covered in why WordPress is slow on mobile.
The 5 Core Web Vitals in the report
The report reads 5 metrics from the mobile run: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, and Speed Index. Each arrives with its raw value and a score from 0 to 100.
| Metric | What it measures | Green threshold (mobile) |
|---|---|---|
| FCP | First content painted on screen | 1.8 s or under |
| LCP | Largest element painted | 2.5 s or under |
| TBT | Main thread blocked during load | 200 ms or under |
| CLS | Visual layout shifting | 0.1 or under |
| Speed Index | How fast content visibly fills the page | 3.4 s or under |
Google's ranking set is LCP, CLS, and INP. Lab runs cannot measure INP because it needs real user input, so TBT stands in for it. If mobile LCP is red, fix that first: it is a ranking factor and the delay visitors actually feel.
WordPress fingerprinting and the 3 security flags
To fingerprint the stack, the tool fetches the page once and checks 5 WordPress markers: wp-content paths, wp-includes paths, a generator meta tag naming WordPress, an x-powered-by header mentioning WordPress, and a wp-json reference in the Link header. One hit is enough.
PHP detection uses 3 markers: a WordPress hit, since WordPress runs on PHP, an x-powered-by header naming PHP, or .php file references in the markup. When the fingerprint request fails, the tool reports nothing instead of guessing.
The 3 security flags are rules with exact triggers. "No HTTPS encryption" fires when the URL does not start with https. "WordPress plugin ecosystem exposure" fires on any WordPress hit. "PHP server-side attack surface" fires on any PHP hit.
A flag is a reason to look closer, and the report says so instead of dressing rules up as a vulnerability scan. What plugin exposure costs in practice is covered in WordPress security risks.
The manual version: 30 minutes, 6 steps
You can reproduce the full audit with a browser and a terminal. Same checks, same thresholds, same order.
- Run PageSpeed twice. Open pagespeed.web.dev, test your most important page, and read the mobile tab first. Note the performance score and the 5 vitals.
- Apply the 0.9 rule. Go through the 13 checks in the table above and mark every one PageSpeed lists under Diagnostics as a finding.
- Sort worst first, keep 5. Order your findings by estimated savings and ignore everything past the fifth. That is your fix order.
- Fingerprint your own stack. View the page source and search for wp-content, wp-includes, and generator.
- Check the headers. Run `curl -sI https://yourdomain.com` and read the x-powered-by and link headers.
- Score the security flags. Missing https in the address bar, a WordPress hit, or a PHP hit each raise one flag.
That is the entire checklist. The WP Health Report automates all 6 steps in about 60 seconds and emails you the findings if you want them in writing.
Where the checklist ends
The audit scores what public data can score: performance, vitals, and stack exposure. Copy, conversion paths, and design quality need a human, and a checklist that pretends to score them turns into opinion with numbers attached.
A report showing WordPress markers next to a mobile score under 50 usually points at a structural ceiling. The hidden cost of WordPress itemizes what keeping that setup costs. When a rebuild is on the table, webvise's WordPress migration service covers it end to end, at a 3-week average to launch across webvise projects.
webvise built the WP Health Report as the intake step of its own audit work, and the tool ships inside webvise.io, a site that is 100% AI-coded via Claude Code. Run your site through it at wp-health-report, or get in touch and I will go through the findings with you.