Website Audit Checklist: I Audited My Own Site With a Claude Code Skill (Mobile Accessibility 94 to 100)

A website audit checklist should cover six areas: technical SEO, performance, accessibility, content and metadata, security and tracking. On my own business website, a Claude Code skill found 23 issues across six page types and helped me identify what to fix first. The worst were low text contrast, a missing <main> landmark and a missing <h1> on the homepage. Fixing them took one afternoon and moved mobile Lighthouse accessibility from 94 to 100 on the live site. Below is the checklist I use, how the audit ran, and where it was wrong.

What a website audit should check

This is the checklist I work from, grouped by area. It is a technical audit of the site itself: I skip backlink profiles, local SEO and competitor analysis on purpose, because they need other tools and a different kind of work.

Technical SEO

Every public page has a unique title and meta description (the skill flags titles over 60 characters and descriptions outside 70 to 160).
Exactly one <h1> per page, and no skipped heading levels (h2 straight to h4).
Canonical URL on every page, and metadataBase set.
No broken links or redirect chains, and Google Search Console is connected so you can monitor indexing and search traffic.
sitemap.xml lists every public route, on the host the site is actually served from.
robots.txt exists, points to the sitemap and does not block production.
Unknown URLs return a real 404, not a 200 page.
Preview and staging domains are not indexed.
Social preview image (og:image) and a favicon exist.

Performance and Core Web Vitals

Audit a production build, never next dev. Dev numbers are meaningless.
Core Web Vitals in range: LCP under 2.5 s, CLS under 0.1.
The LCP image is not lazy-loaded; everything below the fold is.
Images go through next/image, have width and height, and a sensible sizes.
Page speed is measured on mobile first, because that is where most visitors and most problems are.
Fonts are self-hosted and limited to what is used.
HTML and JS are compressed, static assets are cached long-term, and the HTML payload is lean.
Third-party scripts are loaded once, scoped, and deferred where possible.
Mobile gets attention first: no heavy animation or desktop-only assets.

Accessibility and user experience

Text contrast is at least 4.5:1 for normal text and 3:1 for large text.
Landmarks exist: one <main>, plus <header>, <nav> and <footer>.
A skip link is the first thing keyboard focus reaches.
Every link, button and form control has an accessible name or label.
Nothing focusable sits inside an aria-hidden element.
Tap targets are big enough on a phone (the skill measures 24 px), so the user experience holds up on small screens.
There is no horizontal scroll at 375 px, and text still works at 200 % zoom.
Focus is visible, and the keyboard order makes sense.

Content and metadata

Descriptions and titles are within range and say something specific.
Content quality: each page answers one question for one reader, and there is no duplicate content across routes.
Every page leads to one clear next step, because a business website exists to turn visitors into enquiries, and a good conversion path starts there.
Every image has alt text, or an empty alt if it is decorative.
Internal links work; external links that open in a new tab use rel="noopener noreferrer".
No console errors on any page type.
The <html lang> attribute is set.

Security

Basic response headers (this matters for user trust too): X-Content-Type-Options: nosniff, a Referrer-Policy, frame protection and a Permissions-Policy.
A Content-Security-Policy, if you can afford to maintain one.
X-Powered-By turned off, so the stack is not advertised.

Tracking and privacy

No analytics or marketing cookies before consent.
A consent banner with a real reject option, if you use tracking at all.
A privacy page that says what you collect, linked from the footer (mine is at /privacy).
Analytics fire once, from one place, not per page.

How the audit ran

I used the /site-audit skill from my Claude Code plugin marketplace. It samples one URL per page type instead of only the homepage, so a problem in a template shows up once with the pages it affects. For kuklewski.com that meant six page types at two viewports each (375 px and 1440 px): /, /blog, a blog post, a project page, /contact and /privacy.

Per page it runs a headless-Chrome DOM check (headings, landmarks, alt text, contrast, tap targets, overflow), HTTP checks (robots, sitemap, compression, caching, security headers) and a scan of the source code. Lighthouse runs separately for mobile and desktop, three runs each, and the skill reports the median. The result is a chat report plus a tracked document in the repo with a "was" and a "now" column. Re-running the audit later fills the "now" column.

Each finding has an ID and a severity: critical, important or minor. Fixes are ordered by impact and effort and done one commit per step. I did eight steps, plus a final recheck commit.

What it found

The baseline run on the live Vercel site found 11 critical, 7 important and 5 minor issues. Lighthouse scored mobile 97 / 94 / 96 / 100 (performance, accessibility, best practices, SEO) and desktop 100 / 94 / 96 / 100, with a mobile LCP of 2.5 s.

The main findings:

Severity	Finding	Where
Critical	Header links at 4.44:1 contrast	every page
Critical	No `<main>` landmark	`/`
Critical	No `<h1>` (hero text split into animated spans)	`/`
Critical	Hero characters at 2.34:1 contrast	`/`
Critical	Focusable input inside `aria-hidden` (honeypot field)	`/contact`
Critical	Skipped heading levels (footer h4 after h2)	blog, posts, projects
Critical	Footer text 3.66:1, blog date 2.45:1, code token 3.49:1	blog, posts
Important	No canonical link, no skip link, tap targets under 24 px	all
Important	Sitemap uses the non-www host and omits `/contact` and `/privacy`	sitemap
Important	Missing security headers, `x-powered-by` on	all
Minor	No `og:image`, no favicon, descriptions and titles out of range	various

Almost all of the critical issues were contrast and structure (headings and landmarks).

The fixes that moved the score

I went through the steps in order of impact. The ones that mattered:

Header and text contrast. The header links used text-slate-500; one step darker to text-slate-600 cleared 4.5:1. The same change fixed the "prefer email" line, and the footer, blog date and hero text got darker shades too. Each is a one-line class change.
Landmarks and headings. I wrapped the homepage content in <main>, gave the hero a real <h1> that looks identical, and changed the footer h4 to an h3 so heading levels stop skipping.
Contact page. The honeypot field was hidden with aria-hidden but was still focusable. I dropped aria-hidden, made the wrapper inert and added a label.
Metadata. Canonical URLs on every page, an og:image route, a favicon, shorter descriptions, and a sitemap that uses the served host and includes the two missing pages.
Security headers. A headers() block in next.config.mjs and poweredByHeader: false. About ten lines.

The recheck, on the deployed site after the fixes:

Run	Mobile P / A / BP / SEO	Desktop P / A / BP / SEO	Mobile LCP	Open (C / I / M)
Before fixes	97 / 94 / 96 / 100	100 / 94 / 96 / 100	2.5 s	11 / 7 / 5
After fixes	98 / 100 / 100 / 100	100 / 96 / 100 / 100	2.4 s	0 / 3 / 2

Both rows come from the live site, measured the same way (three Lighthouse runs, median). The one number that did not reach 100 is desktop accessibility at 96: Lighthouse caught the hero's "Send Message" button in the middle of its entrance animation and flagged its contrast. I have since moved the hero buttons into the contact section and replaced them with a scroll cue, but I have not re-measured since that change. The three open important items are render-blocking scripts, one tap target under 24 px on post pages, and the lazy-image flag described below.

What the audit got wrong

A tool that flags everything is noisy, and mine was not perfect. Treat any audit tool as a helper that still needs a human to review its output.

The /landing page. It is unreleased work in progress and returns 404 on the live site, but the route scan found it and produced findings for it. I dropped them and added /landing and /welcome to the private routes in .site-audit.json, so later runs skip them.
Lazy image above the fold. The audit flagged a lazy-loaded image on /blog. It is the footer avatar, on a short page. On normal screens it is not above the fold, so I accepted it as a false positive.
Horizontal scroll at 375 px. The recheck flagged horizontal scroll on the homepage at phone width, marked critical. It did not reproduce once the hero animation had finished, so I treated it as transient. I would still open the page on a real phone before calling it fully closed.

What I did not fix or check

The keyboard and focus pass was not run. That is the interactive part: tab order, visible focus rings, focus after each step of the contact wizard, 200 % text. It is still open in the tracked document.
Render-blocking scripts remain. Lighthouse estimates around 110 ms. I found no safe configuration switch in Next.js for it, so the item is blocked, not fixed.
Oversized Unsplash images on posts and project pages are still open. The fix is a tighter sizes.
No Content-Security-Policy. I added the simpler security headers but not a CSP, which takes more care to maintain.
Post titles are still longer than the recommended range. A post title is the article headline, so I left it.

How often should you audit your website?

Before every launch, after any big change to layout or templates, and on a schedule in between. I have no data for an ideal interval; a reasonable default for a small site is quarterly, plus after any major release. The tracked was-to-now document makes re-checking cheap: a recheck only has to confirm the open items and catch new ones.

Run it on your own site

Install the plugin marketplace, then the skill:

/plugin marketplace add kkuklewski/claude-plugins
/plugin install site-audit@kkuklewski

Then run it. Skills from an installed plugin are namespaced as /<plugin>:<skill>, so the audit may be /site-audit:site-audit; I use the short name here:

/site-audit https://example.com     full audit of every page type
/site-audit --quick                 one page, no Lighthouse
/site-audit --recheck               re-audit and fill the "now" column
/site-audit --fix                   work through the findings, one commit per step

It needs Node 22 or newer, Chrome or Chromium and ripgrep. Lighthouse runs through npx, so there is nothing else to install. An optional .site-audit.json in the project root holds private routes and accepted exceptions. More about how I publish these skills in the plugin marketplace post . If you would rather have someone look at your site, tell me about your project.

FAQ

What should be included in a website audit?

Technical SEO, performance, accessibility, content and metadata, security and tracking. The grouped checklist above is the full list I use.

Can ChatGPT or Claude do an SEO audit?

An AI model can reason about findings, but it cannot measure anything by itself. What worked for me is a tool that runs real checks (headless browser, HTTP requests, Lighthouse) with Claude Code orchestrating and explaining the results. Even then the tool raised false alarms that I had to judge.

What does a website audit check?

The technical health of the site: how it is built, how fast it loads, whether everyone can use it, whether search engines can read it, and whether the headers and tracking behave. It is not a review of your marketing strategy.

What are the best free tools for a technical audit?

Lighthouse, built into Chrome DevTools, covers performance, accessibility, best practices and SEO; PageSpeed Insights and Search Console are the other free ones I rely on. For a site that has to be checked repeatedly across page types, I use the /site-audit skill above, which is free and open source under the MIT licence.

How often should you audit your website?

See the section above. Before launch, after large changes, and periodically.

For the hosting side of this site, see self-hosting Payload CMS with Coolify.