SEO
Complete Website Health Audit Checklist
A useful website audit is not a generic scorecard. It is a risk map that tells you what can break revenue, deliverability, crawlability, trust, and operations. This checklist follows the same order CheckFast uses for a full site audit: prove the domain resolves, prove browsers can connect safely, prove search and social crawlers can understand the page, prove users can load and use it, then prove the site can be monitored after the fix.
Try our Full Site AuditStart with the failure modes users actually feel
The first pass should answer five questions: can a visitor reach the site can their browser trust the connection can email from the domain be authenticated can search engines crawl the important pages and can the team detect the next regression before customers report it. That order prevents a common audit mistake: polishing metadata while the SSL chain is broken DNS records are stale or the homepage takes so long to render that users leave before the SEO improvements matter.
1. DNS and domain ownership
Check A AAAA CNAME NS MX TXT CAA and DNSSEC-relevant records before looking at page content. DNS mistakes create intermittent failures that look like application bugs: apex records pointing at an old host www and non-www resolving to different stacks MX records missing after a provider move or TXT records split incorrectly by the DNS UI. A healthy audit records the expected canonical hostname whether both apex and www are intentionally supported which nameservers are authoritative and whether CAA restricts certificate issuance to approved providers.
2. SSL, redirects, and browser trust
A green lock is not enough. Verify the certificate chain expiry window issuer SAN coverage supported TLS versions HSTS and the plain HTTP to HTTPS redirect. A site can pass casual browser checks while still serving an expired intermediate accepting obsolete TLS versions missing HSTS or redirecting through an insecure hop. For production treat certificate expiry under 14 days as an operational incident missing HTTP to HTTPS redirect as a trust defect and mixed-content resources as both a security and UX problem.
3. Email authentication and sender reputation
For most SaaS and commerce sites the domain is also an email identity. Audit SPF DKIM DMARC MX blacklist status and alignment. The minimum safe baseline is SPF present and not over the 10-DNS-lookup limit DKIM signing enabled for every real sender DMARC published with aggregate reports and a rollout path toward quarantine or reject. If the domain sends transactional mail marketing mail and support mail through different providers list each sender explicitly and test alignment instead of assuming the platform configured it correctly.
4. Crawlability, indexability, and structured data
The SEO pass starts with robots.txt sitemap.xml canonical tags status codes noindex rules title and description quality heading structure internal links Open Graph metadata and JSON-LD validity. The key is consistency: sitemap URLs should be indexable canonical URLs should return 200 internal links should not point at noindex report shells and JSON-LD should describe visible page content. Structured data is useful for machine understanding but it does not compensate for thin content hidden claims or unsupported rich-result promises.
5. Performance and Core Web Vitals
Run mobile and desktop separately. Mobile usually exposes the real bottleneck: oversized hero images render-blocking JavaScript delayed fonts slow TTFB layout shifts from unreserved media and client-only content that appears after the user has already waited. Record LCP INP CLS TTFB total page weight third-party script cost and whether the largest above-the-fold element has stable dimensions. Prioritize fixes that improve user-perceived load first: compression image sizing cache headers fewer blocking scripts and server response time.
6. Security headers, cookies, and browser boundaries
A production audit should include HSTS Content-Security-Policy X-Content-Type-Options Referrer-Policy frame protection Permissions-Policy CORS and cookie flags. Most sites do not need a perfect CSP on day one but they do need explicit defaults no wildcard credentialed CORS Secure and HttpOnly on session cookies SameSite chosen deliberately and no sensitive routes embedded in third-party frames. When a header is missing record the practical abuse case not just the header name.
7. Accessibility and UX correctness
Accessibility checks are product checks. Validate heading order link names form labels button accessible names keyboard navigation focus states color contrast error messaging and whether dynamic content can be understood without hover or mouse input. For audit tools specifically avoid inert buttons hidden full-report links ambiguous CTAs and tab traps in autocomplete. A site that scores well but cannot be operated by keyboard users is not production-ready.
8. Monitoring readiness after the audit
The audit is only useful if it becomes a control loop. Decide what should be monitored continuously: uptime SSL expiry DNS drift cron heartbeats broken critical links API health and key SEO surfaces such as robots.txt or sitemap.xml. One-off checks are enough for diagnosis; scheduled monitors are for regressions. Keep the alert policy honest: page humans only for failures that require action now send lower-priority drift to a ticket or weekly review.
How to turn findings into a release plan
Classify each finding by user impact and reversibility. P0 issues break access auth payments data integrity or public trust. P1 issues create likely regressions or business loss before the next release. P2 issues improve discoverability UX or maintainability but can ship behind a clear follow-up. For every fix write the verification before the implementation: the command page screenshot monitor or external validator that proves the defect is gone.
FAQ
Should every audit finding block a launch?+
No. Launch blockers are defects that break access trust security data integrity payments critical user journeys or indexability for pages that are supposed to rank. Lower-risk improvements should become tracked P2/P3 work.
How often should a production site be audited?+
Run a full manual audit before major releases and after infrastructure changes. Continuous monitors should cover uptime SSL expiry DNS drift and critical cron/API paths between releases.
Want to verify your setup?
Run the check now