The worst time to audit a website is six months after launch, when the traffic never arrived and nobody can tell you why. By then you are debugging a mystery. Before launch you are just running a checklist, and the checklist takes an afternoon.
This is the eight-dimension pass I run on every site I build or inherit. It started as a client deliverable and turned into the thing I do reflexively before I let anything go live. Every check below has a free browser tool on this site that runs it, and every check has one specific trap that makes people think they passed when they did not.
Run it before launch. Then run it again after every deploy that touches more than copy. That second habit is the part most people skip, and it is the part that actually keeps the site healthy.
Why eight dimensions and not one score
A single overall grade is comforting and useless. The problems that kill a new site are not evenly distributed: they cluster in two or three dimensions that nobody thought to look at, while the dimensions everyone obsesses over are usually fine.
I have never once opened a new small-business site and found the page titles broken. I open plenty where the email domain has no DMARC record, the contact form posts to a third party with no privacy notice, and the only structured data is whatever the theme shipped in 2019.
So the pass is deliberately eight separate reads, each with its own pass or fail, and no averaging. If seven dimensions are clean and email authentication is a zero, you do not have an 87 percent site. You have a site whose email is going to spam.
1. Crawl and indexability
What you are checking. Can a crawler reach every page you care about, and are you accidentally telling it not to?
The failure mode is almost never "Google cannot find the site." It is that the site tells Google something contradictory. A noindex left over from staging. A robots.txt that blocks a directory the sitemap advertises. Canonical tags pointing at a domain you no longer own. Pages in the sitemap that return 404. Pages on the site that appear in no sitemap and have no internal link pointing at them, which means a crawler has no path to them at all.
Run it. Sitemap Audit validates the sitemap and probes every URL in it for a real status code. Index Coverage Delta crawls the live site, diffs what it finds against the sitemap, and hands you the exact list of orphans, ghosts, and canonical conflicts. Orphan Page Detector walks internal links from the homepage and reports click depth, which tells you which pages are technically present and practically invisible.
The trap. A sitemap.xml that returns HTTP 200 is not a working sitemap. Plenty of single-page app hosts return the app shell with a 200 status for every path, including paths that do not exist. The XML parser then fails silently and you conclude the sitemap is fine. Check that the response is actually XML, not an HTML shell wearing a 200. This same failure hides /llms.txt and /.well-known/ files, which is why it is worth understanding the SPA shell trap before you trust any aux-file check.
2. Structured data
What you are checking. Does the page tell a machine what it is, and does that description survive a parser?
Structured data is how you stop being a blob of text. Organization says who you are. LocalBusiness says where. Product, Service, FAQPage, Article, Person each say something specific. Answer engines and search engines read this, and increasingly it is the difference between being summarized accurately and being summarized by inference.
Run it. Schema Validator parses every JSON-LD block on the page and reports what it found. Schema Completeness checks whether the types you shipped carry the properties that actually matter. JSON-LD Graph Linter and Schema Graph Visualizer show you how your nodes connect, which is where most real problems live.
The trap. Validators fail open. If a JSON-LD block has a trailing comma or an unescaped ampersand, a validator will often skip the broken block and cheerfully report on the ones that parsed. You see green and assume you have five schema types when you have three. Parse every rendered block yourself after deploy, not just before. The other common failure is dilution: two page-type nodes on one page, or an Article sitting next to a redundant WebPage, splits the signal instead of strengthening it. One canonical node per page, with an explicit @id, and every cross-reference to it carrying both a @type and a name so a consumer that does not follow references still knows what it is pointing at.
3. Answer-engine and generative readiness
What you are checking. If someone asks an assistant a question your site answers, can the assistant find, extract, and attribute your answer?
This dimension did not exist five years ago and now it decides a meaningful share of discovery. It is mostly about retrievability at the passage level rather than the page level. Can a model lift one self-contained paragraph out of your page and have it still make sense? Do you have an llms.txt? Do your crawler directives actually agree with each other?
Run it. Passage Retrievability splits a page into passages and scores each one on self-containment, fact density, and how directly it opens. LLMs.txt Validator checks a file against the spec rather than just checking it exists. AI Crawler Access Auditor reads robots.txt, ai.txt, llms.txt, meta robots, and X-Robots-Tag together and gives a per-bot verdict for the major AI crawlers, which is the only way to catch a robots.txt that allows a bot your meta tag blocks.
The trap. People ship llms.txt and stop. The file is a table of contents, not a magic word. If the pages it points at open with three sentences of throat-clearing before the answer, the file has pointed a model at content it cannot use. Write the answer in the first sentence of the section, then support it. That is the whole technique, and it is covered properly in the passage-retrieval piece.
4. Technical SEO fundamentals
What you are checking. Titles, descriptions, canonicals, heading structure, Open Graph, image dimensions, internal link distribution.
This is the boring dimension and it is usually the one in best shape, because it is the only one most website builders automate. Check it anyway, because the specific failures are cheap to fix and expensive to leave.
Run it. Meta + OG Inspector shows title, description, canonical, robots directives, Open Graph, and Twitter Card with a preview. SERP Snippet Preview shows you whether your description survives truncation. Image Alt Audit covers alt text and missing width and height attributes in one pass, which folds an accessibility check and a layout-shift check together. Anchor Text Entropy flags both over-optimized exact-match internal anchors and the opposite problem, a site where every internal link says "click here."
The trap. Meta descriptions written to a character count rather than to a click. A description that fits perfectly and says nothing loses to one that gets truncated but leads with the specific number or claim that makes someone tap. Write the hook first and let the tail get cut.
5. Security headers and transport
What you are checking. What your server says about itself on every single response.
Security headers are a trust signal and a real defence at the same time. Strict-Transport-Security stops protocol downgrade. Content-Security-Policy limits what can execute. X-Content-Type-Options: nosniff stops MIME confusion. Referrer-Policy controls what you leak to third parties. None of these require a developer. They are lines in a config file.
Run it. Security Headers scores the set and emits a paste-ready block for your host. Mega Security Analyzer goes further: TLS configuration, post-quantum key exchange posture, CSP strictness, and DNS email authentication in one scan.
The trap. Two of them. First, a CSP that is technically present and functionally unsafe-inline everywhere is a header, not a policy. Second, and more common on a new site: adding nosniff globally while serving downloadable files whose content type your host guesses wrong. The guess becomes final and the file downloads as the wrong thing. If you ship raw scripts, markdown, or text files for readers to view, pin the content type per extension explicitly. I have written more about why these six headers matter and which three actually do.
6. Accessibility
What you are checking. Whether a person using a screen reader, a keyboard, or a low-contrast display can use the site at all.
This is the dimension with legal teeth and the dimension most often skipped, which is a bad combination. It is also, unlike most of this list, a dimension where the fixes are visible to sighted users too: better contrast, real form labels, tables with headers, focus states you can see.
Run it. WCAG Accessibility Audit runs a WAVE-style pass against WCAG 2.1 and 2.2 AA, separating critical AA failures from warnings and manual-review items, and exports an AI remediation prompt. Image Alt Audit covers the single most common failure. Form Conversion Audit flags unlabeled inputs, which is an accessibility failure and a conversion failure at the same time. User Preference Media Queries Audit checks prefers-reduced-motion, prefers-contrast, and forced-colors support, which almost nobody implements. If you want the risk framing rather than the technical one, ADA Litigation Risk Score scores the twelve signals plaintiff firms target first.
The trap. Measuring contrast against the colour you meant rather than the colour that renders. If a text token sits on three different card backgrounds across the site, the ratio that matters is the one against the worst of the three. I have shipped that mistake myself and it hid eight separate AA failures behind a passing average. Test against the worst-case surface, every time.
7. Email and DNS authentication
What you are checking. SPF, DKIM, DMARC, MX, and whether your domain can be spoofed.
Here is the thing nobody tells a new business owner: your domain is a sending identity whether or not you send from it. A domain with no SPF and no DMARC can be spoofed by anyone, and the recipients getting the spoofed mail are your customers. And if you do send, from a contact form, an invoice tool, or a newsletter, missing authentication is the single most common reason legitimate mail lands in spam.
Run it. DNS / Email Auth Audit reads SPF, DKIM, DMARC, CAA, MX, and TXT over DNS-over-HTTPS. DNS Records Generator emits the records you are missing in five provider syntaxes so you can paste rather than type.
The trap. A DMARC record set to p=none and left there. p=none is monitoring mode. It is the correct first step and the wrong permanent state, and an enormous number of domains have been sitting in it for years. Publish p=none, read the reports for a few weeks, fix what is failing, then move to quarantine and then reject. The full sequence is in the small-business email infrastructure playbook, and if you own a domain you do not send from at all, lock it down rather than leaving it open.
8. Reputation and conversion surface
What you are checking. Whether a stranger who lands on the site can tell you are real, and whether they can act.
This is the least technical dimension and the one that most directly moves revenue. Is there a physical address or service area? A phone number that is text, not an image? Named humans with real bios? Legal pages that exist and are linked from the footer? Reviews or references that are not just a rotating carousel of first names?
Run it. Legal Pages Audit probes for privacy policy, terms, accessibility statement, cookie policy, disclaimer, refund policy, and DPA, and checks whether each one is footer-discoverable and carries a last-updated stamp. Legal Pages Generator writes the missing ones tailored to your business type and jurisdictions. Trust Signal Surface Audit and the E-E-A-T analyzer look at whether the authority signals you have are actually machine-readable.
The trap. Legal pages that exist but are not linked from the footer. A privacy policy at a URL nobody can navigate to satisfies nothing and nobody. Link it, date it, and make the date true.
Running all eight at once
Eight tools is eight tabs, which is why the Mega Analyzer exists: one URL, ten audit panels, one pass. Use it for the sweep, then drop into the individual tools for the dimensions that came back red, because the specialised tools give you the fix and the mega pass gives you the map. The scoring rubric behind it is published at /methodology/ if you want to know exactly what each bucket is measuring rather than trusting a number.
For a whole site rather than a page, Mega Batch runs the same pass across a URL list.
The loop part
Running this once before launch catches the state of the site on one afternoon. What actually keeps a site healthy is the second habit: re-run the pass after any deploy that changes more than words, and diff it against last time.
Deploys break things quietly. A build tool updates and starts emitting noindex on paginated routes. A plugin update rewrites robots.txt. A theme change drops the JSON-LD block from a template. A CDN gets added and starts challenging crawlers. None of these produce an error. All of them produce silence, and silence looks exactly like "we just have not ranked yet."
Three habits close that gap:
- Export every audit. Every tool on this site exports HTML, CSV, or PDF. Save the pre-launch run. It is your baseline, and a baseline turns "is this bad?" into "is this different?"
- Diff the crawler directives specifically. Robots/LLM Drift Diff takes a before and after of
robots.txt,ai.txt, andllms.txtand classifies what changed. This is the single highest-yield diff, because those three files are edited by tooling more often than by people. - Gate the deploy. Pre-Deploy Check runs fifteen regression checks before a build ships. A check that runs automatically is worth five checks you intend to run manually.
What this costs
Nothing. Every tool linked above runs in your browser, takes no signup, stores no data, and is free. That is the entire point of the catalogue: small businesses are routinely quoted several thousand dollars for a "technical SEO and accessibility audit" that is largely this checklist run by someone else.
If you want the whole thirty-day path from nothing to a live, accessible, properly configured site rather than just the audit half, that is what my book The $97 Launch covers end to end.
Fact-check notes and sources
- WCAG 2.2 is a W3C Recommendation and is the version the AA checks above target: W3C WCAG 2.2
- Structured data vocabulary and the
sameAs/@idmechanics referenced in dimension 2: schema.org - DMARC, including the
p=nonemonitoring-mode semantics described in dimension 7: RFC 7489 - SPF: RFC 7208. DKIM: RFC 6376
- HTTP Strict Transport Security: RFC 6797. Content Security Policy Level 3: W3C CSP3
- Sitemap protocol, including the requirement that listed URLs be valid: sitemaps.org protocol
- The scoring rubric and per-bucket definitions used by the Mega Analyzer: jwatte.com/methodology/
Related reading
- Why a new website does not show up in search, and the free stack that fixes it
- How to send email that actually gets delivered
- The six security headers every site should ship, and the three that actually matter
- When 200 OK lies: the SPA shell trap
- Passage retrieval is the new SEO
This post is informational, not legal or accessibility-compliance advice. Any site referenced was either my own, a site I was given permission to use, or anonymized as "a client site I was asked to audit." Mentions of third-party standards bodies and specifications are nominative fair use. No affiliation is implied.
