Run your own website audit with this checklist.

What should a website audit checklist cover?

Your checklist covers eight areas: architecture, performance, security, search, schema, AI readiness, editorial experience and operational health. List them down your sheet, then add a column for the evidence you find. A header value you copy, a URL you note, a screenshot you take. The assessment weights them at 15, 15, 12, 12, 10, 10, 10 and 16 percent in that order, so operational health counts most (the pillar people tend to leave for last).

You can test your audit order against one published checklist: crawl analysis, then indexation review, then structured data validation. Label each finding P0 to P3 by severity. That way your first afternoon goes to your worst problems, not the loudest ones. Repeat your full audit at least twice a year, and keep monitoring your site between rounds, because a clean audit only describes the day you ran it.

You get one score out of 100 for your site, built across the eight pillars from your homepage plus up to eight sampled pages. The assessment does not log in to your site, read your analytics, run field performance data or interview you or your team. That gap is yours to fill. So your hand audit covers what you can reach and a public read cannot.

How do you check architecture and rendering?

Check architecture by counting clicks from your homepage, and check rendering by comparing view-source with what your browser shows. Search view-source on your key page for your main heading and first paragraph. Missing? Then your content depends on JavaScript. One checklist says to confirm content is accessible in raw HTML before JavaScript runs. Test yours, because you can't trust a page you've only seen rendered.

Walk your menus and links. None of your important pages should sit more than 3 clicks from your homepage, and your breadcrumbs should exist and use structured data markup. Export your internal links with Screaming Frog or Ahrefs Site Audit, then list your pages with 0 inbound internal links: those are your orphans. Compare that crawl against your XML sitemap. Fix your 404s, 302s, redirect chains and broken internal links. The redirect chains are the ones you forget (they work fine, which is why they linger).

The assessment reads the markup, headings and canonical signals on your homepage and sampled pages. Architecture carries 15% of your score. But it does not crawl every URL. The orphan hunt stays with you.

How do you check performance from the outside?

Check performance from the outside by running your top pages through PageSpeed Insights and Lighthouse and reading what they flag: heavy scripts, unoptimized media, layout shifts. Start with your homepage, then move to your busiest template pages. Open your browser's Network tab, reload your page, sort by size and write down your largest files. And your biggest file is rarely the one you would have guessed.

Check mobile too. Load your site on your real phone and look for text too small to read, buttons too close together for your thumb and content that jumps while the page loads. Lab numbers give you a snapshot of one run. They do not tell you what your real visitors experienced, so don't treat them that way (a single run is a data point, not a verdict).

Expect the assessment to flag the same heavy files you found in your Network tab, since it reads script and image weight from your homepage and sampled pages. Performance carries 15% of your score. But field performance data is not part of its run. Treat your result as an outside read, not the whole picture.

How do you check security headers?

Check security headers by scanning your homepage with Mozilla Observatory or SmartScanner, or by reading the response headers in your browser's Network tab. Look for X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security, Content-Security-Policy, Permissions-Policy and the three Cross-Origin policies. Mark each one present, absent or misconfigured. Misconfigured catches people out, because a header that exists can still do nothing. Check your results.

Read what your site returns. You want nosniff in your X-Content-Type-Options. Your Strict-Transport-Security max-age needs 31536000, one year, the minimum for HSTS preloading. Your Content-Security-Policy belongs on every response you send, not only the main document. Generate a fresh nonce on each request, the recommended way to restrict your scripts. You can skip X-XSS-Protection. MDN recommends CSP instead and warns that the old header can create vulnerabilities, so if you still send it, drop it.

Finish with HTTPS. Fix any page you serve over HTTP, any mixed content warning and any link on your site that still points to an old HTTP URL. The assessment reads the response headers on your homepage and sampled pages, and security carries 12% of your score. Your server configuration, though, stays out of view beyond what those responses reveal (a header can only show you what the server chooses to say).

How do you check search signals and structured data?

Check your search signals by testing your canonical tags, your XML sitemap and your redirects, then run your structured data through Google's tools. Start in view-source. Confirm that the canonical tag on a few of your pages points to the version you want indexed (it's often not). Then work in this order: set your canonicals, remove duplicate parameters, merge similar content, audit your pagination. Each step makes the next easier to see. And if you skip ahead, you will usually redo the work.

Your sitemap should list only indexable pages. Update it after major site changes, and submit it through Search Console. Want Google rich results? Start with the Rich Results Test. For generic schema.org checks, run your markup through the Schema Markup Validator. Once you deploy, watch your Rich result status reports, because templating or serving errors can break your pages without anyone noticing. A few complete, accurate recommended properties beat many incomplete ones. So finish yours before you add more.

If you use carousels, your itemListElement needs two or more ListItem elements of the same type. The assessment reads the robots, canonical and structured data signals on your sampled pages, so you see the same signals you just checked by hand. Search carries 12% of your score. Schema carries 10% of your score. Together they weigh more than any single pillar except operational health, which makes them hard to wave off as housekeeping.

How do you check AI readiness, editorial and operational health?

Check these three by reading your robots.txt for AI crawler rules, reading your headings and titles as an editor would, and crawling your site for broken links and redirect chains. For AI, make your own deliberate robots.txt choice about each crawler. Then check your server logs for GPTBot, ClaudeBot and PerplexityBot each quarter, since robots.txt runs on good faith. Your rule is only a request. Your logs show who listened.

If you keep an llms.txt, treat it as a hint and hold your list to 10 to 50 URLs. For editorial experience, open a few of your pages and read the headings: you want one clear H1 and a logical order. And then sort your crawl for duplicate title tags and thin pages.

For operational health, rerun the broken link and redirect checks on a schedule, and keep your twice-a-year full audit. The assessment reads the robots, heading and markup signals on your sampled pages, the same ones you just checked by hand. Your AI readiness and editorial experience scores carry 10% each, and your operational health score carries 16%. Your server logs are beyond its reach. So the quarterly log check stays yours.

Questions, answered.

Your next read.

1. 01Website health checkThe general read, all eight pillars.
2. 02Enterprise SEO auditWhat a free scan can establish, and where it stops.
3. 03AI SEO auditCrawl access, extractable passages, schema, llms.txt.