Website Health Check: A Practical Audit

A credible health check keeps indexing, performance, security, accessibility, and AI visibility as separate evidence layers. That makes the findings easier to verify and the fixes easier to prioritize.

A website can return a successful status code and still be unhealthy. Google may be unable to index an important page, mobile visitors may fail at checkout, a security policy may be missing, or an automated accessibility score may overlook a journey that a keyboard user cannot complete.

Audit rule

Keep the evidence attached to the layer that produced it. A Lighthouse lab result is not field performance. A live URL test is not an indexing guarantee. An automated accessibility scan is not a conformance decision. An AI Readiness score is not proof that an AI engine mentions the brand.

The five layers of website health

1. Availability and indexing

Google's minimum technical requirements are narrow and useful: Googlebot must not be blocked, the page must return HTTP 200, and the response must contain indexable content. Meeting those conditions makes a page eligible. It does not guarantee that Google will index or serve it.

Start with server monitoring and the Page Indexing report. Use Search Console's URL Inspection tool for a specific page. Compare the indexed version with a live test, inspect the fetched HTML and screenshot, and verify the declared canonical, robots directives, and structured data. Google cautions that the live test does not cover every indexing state, including some duplicate and canonical decisions.

Sources: Google Search technical requirements and URL Inspection documentation.

2. Real-user performance

Google's current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. The good thresholds are LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less. Evaluate all three at the 75th percentile of page loads, segmented by mobile and desktop.

Use field data for the outcome and lab traces for diagnosis. PageSpeed Insights can provide Chrome User Experience Report data when enough traffic exists, plus a Lighthouse lab run. A fast lab run on one device does not prove that most visitors receive the same experience.

Source: Google Search Central's Core Web Vitals guide.

3. Transport and browser security

Confirm valid HTTPS, certificate renewal, secure redirects, and the policies the application actually needs. HTTP Strict Transport Security can enforce HTTPS for returning browsers. Content Security Policy can reduce script-injection risk when it is designed and tested for the application. Other headers control MIME sniffing, referrer data, framing, and browser capabilities.

A header checklist reviews configuration. A penetration test evaluates a wider set of threats. Security work also needs dependency management, authentication and authorization review, secret handling, logging, incident response, and testing of the application's own threat model. Use the OWASP Secure Headers Project as a maintained reference, then validate policy changes in report-only or staged environments before enforcement.

4. Accessibility and task completion

Automated tools can quickly find machine-testable problems such as some missing labels, contrast failures, and invalid relationships. W3C is explicit that no tool alone can determine whether a site meets accessibility standards. Knowledgeable human evaluation is required.

Combine an automated scan with keyboard-only navigation, zoom and reflow checks, screen-reader testing for critical journeys, error-recovery review, and testing with people who use assistive technology when the product risk warrants it.

Source: W3C's accessibility evaluation overview.

5. AI readiness and measured AI visibility

Technical checks can verify crawler access, structured data, headings, FAQ structure, content depth, citation formatting, and entity signals. Those are readiness inputs. They do not show whether ChatGPT, Perplexity, Gemini, Claude, or Google AI Overview mentions or cites the brand for a buyer's prompt.

Google says AI Overviews and AI Mode use the same foundational Search requirements, with no additional technical requirements. Other AI engines have their own retrieval systems and crawler controls. Keep the Technical Audit and the AI Visibility Check as two measurements with different jobs.

Source: Google's AI features guidance.

Use a tool stack instead of one unexplained score

Evidence source	Best use	Important boundary
Uptime and synthetic monitoring	Availability, status codes, certificates, and critical-path smoke tests	Does not reproduce every user, browser, or application state
Search Console	Indexed state, crawl evidence, canonical selection, and live inspection	A successful live test does not guarantee indexing
Field performance data	Real-user LCP, INP, and CLS distributions	Needs enough traffic and careful device or page segmentation
Security testing	Headers, dependencies, application controls, and threat-specific tests	A header grade is not a complete security assessment
Accessibility evaluation	Automated findings plus manual task and assistive-technology testing	No automated tool alone determines conformance
Foglift Technical Audit	Fast page-level SEO, performance, security, accessibility, and AI Readiness checks	A technical snapshot does not measure prompt-level AI visibility

Prioritize findings by evidence and impact

Restore availability and critical journeys. Fix outages, broken authentication, checkout failures, inaccessible blocking controls, and accidental indexing blocks first.
Protect data and application boundaries. Escalate exploitable security findings based on likelihood, blast radius, and exposed data.
Repair systemic template defects. One broken canonical, heading, navigation component, or consent layer can affect thousands of URLs.
Use field evidence for performance work. Fix the metric and page group affecting real users before chasing a generic lab score.
Measure discovery outcomes separately. Search clicks, indexed pages, AI mentions, citations, and conversions need their own baselines.

A practical operating cadence

The right frequency depends on release volume and business risk. This cadence is an operating recommendation rather than a universal standard.

Every release: availability, core journeys, indexing directives, console errors, and fast automated checks
Weekly: uptime, certificate, Search Console, field performance, and security alert review for business-critical sites
Quarterly: deeper accessibility, security, template, content, and cross-device journey review
After infrastructure changes: rerun the affected layers after DNS, CDN, hosting, CMS, authentication, consent, or checkout changes

Website health check checklist

Verify uptime, HTTP status, HTTPS, and certificate renewal
Inspect priority URLs in Search Console
Confirm canonical, robots, sitemap, and structured-data intent
Review mobile and desktop field Core Web Vitals
Test critical journeys across devices and input methods
Review security headers in the application's threat context
Combine automated accessibility results with human evaluation
Run a Technical Audit for page-level readiness signals
Measure search and AI visibility outcomes against separate baselines
Record owners, evidence, deadlines, and verification for each fix

Frequently asked questions

What should a website health check include?

A useful health check covers availability and indexing, real-user performance, transport and browser security, accessibility, and content or AI readiness. It should preserve the evidence for each layer instead of collapsing unrelated results into one unexplained score.

Can one automated scan prove that a website is healthy?

No. Automated scans are strong at repeatable technical checks, but they cannot confirm every indexing state, real-user journey, security threat, or accessibility criterion. Google says its live URL test does not cover every indexing issue, and W3C says no tool alone can determine accessibility conformance.

How often should I run a website health check?

Run fast automated checks on every release and after changes to templates, hosting, DNS, consent, authentication, or checkout. Review field performance and Search Console trends on a regular operating cadence. Schedule a deeper manual audit for critical journeys at least quarterly. Treat this as an editorial operating cadence; release volume and business risk should set your schedule.

Does technical website health directly increase AI citations?

There is no evidence that one technical health score directly causes citations in ChatGPT, Claude, or Perplexity. Technical readiness can preserve crawl access and extractable content. Prompt-level AI Visibility monitoring is still required to measure mentions, citations, sentiment, and competitor presence.

What does Foglift's Technical Audit cover?

Foglift's free Technical Audit checks a page across SEO, performance, security, accessibility, and AI Readiness signals. It is a fast technical snapshot. Pair it with Search Console, field Core Web Vitals, security review, accessibility testing, and real-user journeys for a complete health program.

Start with the technical snapshot

Run Foglift's free Technical Audit for a page-level baseline. Use the audit's findings to choose the next evidence source, then verify the fix in the tool that owns the outcome.

Sources & Further Reading

Fundamentals: Learn about GEO (Generative Engine Optimization) and AEO (Answer Engine Optimization) (the two frameworks for optimizing your content for AI search engines).