Table of Contents

Website Health Audit: Why a Single Readiness Score Beats a 200-Point Checklist

ChatGPT's crawler now issues roughly 3.6 times more requests to websites than Googlebot, according to Search Engine Journal data cited in Alef's analysis of AI crawler behavior. Machine readers, not only human searchers, now decide whether a page is discoverable.

A website health audit is a structured, repeatable evaluation of a site's crawlability, indexation, speed, mobile readiness, metadata, duplicate content, and structured data — scored so fixes can be ranked by impact rather than discovered at random. Teams that audit on a cadence catch indexation ceilings, speed regressions, and metadata decay before they compound into traffic loss, and they produce pages that AI answer engines can actually parse and cite.

Alef is an AI visibility engine whose Site Health module runs one audit across technical, SEO, and answer-readiness issues, ranks each finding by impact, and surfaces a single readiness score — the product demo shows 84.6 across 24 audited pages.

This guide assumes intermediate skill, 6–10 hours for a first full pass, and access to Google Search Console, a CMS supporting metadata and schema, and a crawl tool. It covers 12 sequential checks, the mistakes that waste the effort, a summary table mapping each check to its outcome, and a FAQ.

↑ Back to top

When You Need a Website Health Audit (and When You Do Not)

Four signals reliably justify a full 12-check pass.

  • Indexation is stalling. Search Console's Page indexing report shows a rising share of URLs stuck in "Discovered — currently not indexed" or "Crawled — currently not indexed." That pattern usually points to a crawl-budget, internal-linking, or render ceiling, not thin content.
  • Rankings exist but citations do not. A brand ranks in Google for a query yet never surfaces in ChatGPT, Perplexity, or AI Overviews for the same intent. A ranking-only dashboard misdiagnoses this gap; tracking AI search visibility alongside Google rankings exposes it.
  • A migration, redesign, or domain move has shipped. These events routinely invalidate the XML sitemap and internal link graph that both search engines and AI crawlers traverse.
  • Traffic declines without explanation. A Core Web Vitals regression flagged in Search Console or a competitor overtaking a long-held position qualifies.

When a Lighter Check Is Enough

A small, stable, fully indexed site with clean Core Web Vitals does not need the full sequence. A quarterly spot-check suffices.

Cadence matters more than depth: run the complete audit quarterly, re-check targeted checks after every deploy or content cluster launch, and monitor the readiness score continuously between passes. For teams aligning technical fixes with content work, this is where an AI SEO strategy spanning content and technical SEO pays off.

↑ Back to top

The 12-Step Website Health Audit Checklist

The audit sequence below moves from discovery to diagnosis to repair, in the order that prevents wasted effort. There is no value in optimizing title tags on pages that are blocked from crawling, or compressing images on URLs that return a 404. Each step produces an artifact — a URL inventory, a crawl directive report, an indexation map — that the next step depends on. Run in sequence, the twelve checks take a mid-sized site (roughly 500 to 5,000 URLs) between four and eight hours of analyst time on the first pass, and under two hours on each subsequent monthly cycle.

Before the Audit: Prerequisites and Baseline

Three inputs must be in place before Step 1 begins. Without them, the audit produces observations rather than a prioritized fix list.

  • Search Console verification with at least 90 days of historical data, so indexation and Core Web Vitals trends can be read against a baseline rather than a single snapshot.
  • A crawler configured with the production user-agent, not a browser-emulating default. Crawling as Googlebot surfaces directive conflicts that a generic crawl hides.
  • A staging or backup snapshot of the current sitemap and robots.txt, so any change can be diffed and reverted.

The expected outcome of the full sequence is a scored, ranked list of issues — each mapped to a URL set, a severity, and an owner. Verification comes at Step 12, when the readiness score is recalculated and compared against the baseline captured here.

Step 1 — Crawl the Site and Inventory Every URL

Action: Run a full crawl from the root domain and export the complete URL list.

The crawl establishes the ground truth: every URL the site exposes through internal links. Configure the crawler to follow internal links only, respect robots.txt as Googlebot, and capture status codes, indexability, canonical targets, word count, and depth from the homepage for each URL. A crawl that returns 4,200 URLs where the team believed the site had 3,000 is itself the finding — it usually means parameterized URLs, faceted navigation, or staging subdomains have leaked into the crawlable graph.

Once the crawl completes, reconcile three numbers:

Step 1 — Crawl the Site and Inventory Every URL
SourceWhat It RepresentsTypical Discrepancy
Crawl exportURLs reachable via internal linksBaseline
XML sitemapURLs the site declares as canonicalSitemap-only URLs (orphans from navigation, or stale entries)
Search Console indexed countURLs Google has actually indexedCrawl-only URLs (blocked, noindexed, or canonicalized away)

URLs in the sitemap but absent from the crawl are sitemap-only entries — either orphaned pages with no internal links or retired URLs the sitemap never dropped. URLs in the crawl but absent from the sitemap are undeclared pages that depend entirely on link discovery. Both categories need resolution before proceeding, because every later check operates on this URL set. The mechanics of keeping the sitemap aligned with the crawl are covered in this guide to sitemap optimization for search visibility.

Verification: The three counts should converge within 5 percent after reconciliation. A wider gap indicates a structural problem — not a reporting one.

Step 2 — Verify robots.txt and Crawl Directives

Action: Read robots.txt line by line and test every disallow rule against the URL inventory.

Most robots.txt problems are not malicious; they are leftovers. A staging block that shipped to production, a disallow rule added during a migration and never removed, a wildcard pattern that accidentally matches a product category. The check is mechanical: for each Disallow directive, confirm the matching URLs are genuinely meant to be excluded.

Four elements belong in every production robots.txt:

  1. A sitemap declaration — Sitemap: https://example.com/sitemap.xml — so crawlers find the canonical URL list without guessing.
  2. Explicit handling of AI crawler user-agents. GPTBot (OpenAI), PerplexityBot, ClaudeBot (Anthropic), and Google-Extended each control a distinct surface. Google-Extended governs whether content may be used for Gemini training and grounding, separate from Googlebot's indexing role. Blocking these agents by accident removes the site from AI answer surfaces entirely — a decision that should be made deliberately, documented, and revisited quarterly as the AI search landscape shifts.
  3. No disallow rules on CSS or JavaScript directories. Google renders pages to evaluate them; blocked resources break the render.
  4. A crawl-delay value that does not throttle legitimate crawling. Values above one second slow discovery on large sites without meaningfully reducing server load.

The distinction between blocking a training crawler and blocking a retrieval crawler matters. A site that wants citations in AI answers but not model training needs a granular configuration, not a blanket Disallow: /.

Verification: Run the robots.txt tester in Search Console against three representative URLs — a homepage, a key product page, and a blog post. All three should return "Allowed."

Step 3 — Audit Indexation Status and Canonical Tags

Action: Cross-reference the URL inventory against Search Console's Page indexing report and inspect canonical tags on every indexable URL.

The Page indexing report segments URLs into indexed, excluded, and errored states, each with a reason. The audit reads those reasons against intent: a page marked "Excluded by noindex tag" is correct if it is a thank-you page and a critical failure if it is a revenue page. Google's documentation on the Page indexing report lists the full set of status reasons and what each implies.

Three canonical failures account for most indexation problems:

  • Missing self-referencing canonicals. Every indexable page should declare itself canonical. Without the tag, Google infers the canonical from signals — and sometimes infers wrong, particularly on paginated or parameterized URLs.
  • Conflicting canonical signals. A page whose canonical tag points to URL A while its sitemap entry and internal links point to URL B sends contradictory instructions. Google resolves the conflict by ignoring both, which leaves the page in an ambiguous indexation state.
  • Canonicals on paginated series. Pages two through N of a paginated series should self-canonicalize, not point to page one. Consolidating a series into a single canonical removes the deeper pages from the index and, in ecommerce, from long-tail discovery.

Verification: Every URL in the inventory should carry exactly one canonical tag, and that tag should match the URL's own address unless a deliberate consolidation is documented.

Step 4 — Measure Core Web Vitals Against Google's Thresholds

Action: Pull field data from the Chrome User Experience Report and compare each metric to its threshold at the 75th percentile.

Core Web Vitals are evaluated on real-user data, not lab scores. The thresholds, as defined by web.dev's Core Web Vitals documentation, are:

Step 4 — Measure Core Web Vitals Against Google's Thresholds
MetricFull NameGood ThresholdWhat It Measures
LCPLargest Contentful PaintUnder 2.5 secondsLoading performance of the main content element
INPInteraction to Next PaintUnder 200 millisecondsResponsiveness across all interactions in a session
CLSCumulative Layout ShiftUnder 0.1Visual stability during load

The 75th percentile requirement is the detail most audits miss. A page passes only when 75 percent of real-user visits meet the threshold — meaning a site with a fast median and a slow tail still fails. Segment the data by device and by template. A homepage that passes on desktop while the product template fails on mobile is a template-level fix, not a page-level one.

INP replaced First Input Delay as a Core Web Vital in March 2024, and sites that optimized only for FID often discover their INP fails. INP measures every interaction in a session, not just the first, which exposes long tasks in third-party scripts that FID never caught. The common culprits: chat widgets, tag managers loading synchronously, and analytics scripts that block the main thread during interaction.

Verification: Each URL group should show "Good" status for all three metrics at the 75th percentile in the Search Console Core Web Vitals report. URLs with insufficient data need lab testing as a proxy.

Step 5 — Test Mobile Readiness and Indexing Parity

Action: Render every key template on a mobile user-agent and compare the output against the desktop render.

Google indexes the mobile version of a page — the mobile render is the canonical source for both mobile and desktop rankings. Google's mobile-first indexing guidance is explicit that the mobile and desktop versions must contain equivalent content, metadata, and structured data. When they diverge, the mobile version wins, and anything present only on desktop is effectively invisible.

The parity check compares four elements across renders:

  • Primary content. Text hidden behind mobile accordions or tabs still counts if it is in the DOM, but content loaded only on desktop viewports does not.
  • Metadata. Title tags, meta descriptions, and canonical tags must match. A mobile template that injects a shortened title changes what ranks.
  • Structured data. JSON-LD injected only in the desktop template is absent from the indexed version.
  • Internal links. Navigation collapsed into a hamburger menu is fine; links removed entirely from the mobile DOM are not.

Beyond parity, two mobile-specific checks: viewport configuration must include width=device-width, initial-scale=1, and tap targets must be at least 48 by 48 pixels with adequate spacing. Overlapping tap targets trigger a Lighthouse failure and degrade the interaction signals that feed INP.

Verification: The URL Inspection tool's "Test live URL" feature renders the page as Googlebot smartphone. The rendered HTML should contain every element present in the desktop source.

Step 6 — Audit Title Tags and Meta Descriptions

Action: Export every title tag and meta description from the crawl and audit for four failure modes.

Metadata is the highest-leverage, lowest-effort fix in the audit — and the most commonly neglected at scale. The crawl export gives every title and description in one table, which makes the failure patterns visible immediately:

  • Missing. Pages with no title tag or an empty one. Google generates a replacement from page content, which rarely matches search intent.
  • Duplicated. Identical titles across multiple URLs. This is the most damaging pattern, because it signals to search engines that the pages are interchangeable. A site with 400 product pages sharing the title "Products | Brand Name" has effectively told Google it has one page.
  • Truncated. Titles exceeding roughly 60 characters or 600 pixels are cut in the SERP, hiding the differentiating terms at the end. Descriptions beyond roughly 155 characters truncate similarly.
  • Templated. Titles that follow a rigid pattern — "Keyword | Category | Brand" — across every page, where the keyword slot is the only variable. Templated metadata reads as low-effort to both users and ranking systems.

The deeper check is intent differentiation. Two pages can have unique titles and still target the same query, which produces keyword cannibalization — the pages compete against each other and neither ranks. Group titles by their primary phrase and flag any group with more than one URL. Each distinct intent should map to exactly one page.

Verification: Zero missing titles, zero duplicate titles within an intent group, and every title under 60 characters with the primary phrase in the first 40.

Step 7 — Find and Resolve Duplicate Content

Action: Run a similarity analysis across the URL inventory and classify every near-duplicate cluster.

Duplicate content dilutes ranking signals across multiple URLs and forces search engines to choose a canonical for you. The audit identifies four recurring sources:

  1. Parameter and tracking variants. ?utm_source=, ?ref=, ?sort=, and ?filter= parameters generate unlimited URL permutations of identical content. These should be handled with canonical tags pointing to the clean URL, or blocked in robots.txt when they serve no indexation purpose.
  2. Print and AMP variants. /print/ and /amp/ versions of an article are duplicates unless canonicalized to the primary URL.
  3. Protocol and hostname duplicates. http:// versus https:// and www. versus non-www. are the most dangerous duplicates because they split authority across two hostnames. A single 301 redirect at the server level resolves this permanently.
  4. Genuine near-duplicates. Product variants with identical descriptions, location pages with swapped city names, and syndicated content republished without canonical attribution.

Resolution follows a decision tree. If two URLs serve the same intent, consolidate: 301 redirect the weaker URL to the stronger one. If they serve different intents but share content, differentiate the content or canonicalize the variant to the primary. If the duplicate exists only for tracking, canonicalize and move on. The rule is one intent, one URL.

Verification: The similarity report should show no cluster of indexable URLs above 90 percent content overlap without a documented canonical relationship.

Step 8 — Validate Internal Linking and Find Orphan Pages

Action: Map link depth from the homepage and identify URLs with zero or one internal inbound link.

Internal linking distributes authority and tells crawlers which pages matter. The audit measures two things: depth and density.

Depth is the number of clicks from the homepage. Every important URL should be reachable within three clicks. Pages at depth four or deeper are crawled less frequently and receive less authority. The crawl export includes a depth column, which makes the distribution visible in one view.

Density is the number of internal inbound links per URL. A page with zero internal links is an orphan — reachable only through the sitemap or an external link. Orphans are the most common cause of "why isn't this page indexed" questions, because nothing on the site points to it. A page with one internal link, typically from a sitemap-style index page, is functionally an orphan for authority purposes.

The structural check is cluster integrity. In a topic cluster model, every spoke article links up to its pillar page, and the pillar links down to each spoke. A spoke that links to the pillar but receives no link back is a dead end for both users and crawlers. Building that reciprocal structure deliberately — rather than leaving it to chance — is what turns a collection of pages into a ranking asset, and it is the core of a content growth system that compounds over time.

Verification: No indexable URL at depth greater than three, no orphans, and every spoke-to-pillar link matched by a pillar-to-spoke link.

Step 9 — Validate Structured Data and Rich Result Eligibility

Action: Extract every JSON-LD block from the crawl and validate each against its schema type.

Structured data determines eligibility for rich results — review stars, FAQ accordions, breadcrumb trails, product pricing — and it feeds the entity signals that AI answer engines use to attribute and cite content. Google's structured data guidelines define which types are supported and what each requires.

The audit checks three layers:

  • Presence. Which templates carry structured data and which do not. An article template with no Article schema, or a product template with no Product schema, is leaving rich result eligibility on the table.
  • Validity. Required properties present, values in the correct format, no deprecated types. A Product schema missing offers or price fails validation and earns nothing.
  • Accuracy. Marked-up values must match visible page content. Marking up a 4.8-star rating that does not appear on the page is a guidelines violation and risks a manual action.

The most common failure is partial implementation: schema present on the homepage and blog posts but absent from category, product, and location templates — the pages most likely to earn rich results.

Verification: Every template carries valid, accurate structured data for its content type, and the Rich Results Test returns zero errors on a representative URL from each template.

Action: Trace every redirect and log every 4xx and 5xx response in the crawl.

Redirects accumulate. A site that has migrated twice and restructured once can carry chains four and five hops deep, each hop adding latency and diluting the authority passed to the final destination. The audit flattens every chain to a single 301 pointing directly at the final URL.

The status code audit sorts into three buckets:

  • 404 Not Found. Internal links pointing to dead pages. Each one wastes crawl budget and delivers a broken experience. Either restore the page, redirect it to the closest equivalent, or remove the link.
  • 5xx Server Errors. These are availability failures, not SEO issues, and they take priority over everything else in the audit. A page that intermittently returns 503 is invisible to crawlers during those windows.
  • Soft 404s. Pages that return 200 but display "no results" or empty content. Google treats these as 404s, but they consume crawl budget as if they were live pages.

Redirect chains longer than two hops, any internal link returning 4xx, and any 5xx response are all fix-now items.

Verification: Zero internal links to 4xx URLs, zero redirect chains longer than one hop, and zero 5xx responses across a 24-hour monitoring window.

Step 11 — Assess HTTPS, Security Headers, and Mixed Content

Action: Confirm full HTTPS coverage and scan for mixed-content warnings.

HTTPS is a baseline requirement, not a differentiator. The audit confirms three things: every URL in the inventory resolves over HTTPS, the HTTP-to-HTTPS redirect is server-level and applies sitewide, and no page loads insecure resources over HTTP.

Mixed content — an image, script, or stylesheet loaded over http:// on an https:// page — triggers browser warnings that suppress trust signals and, in some browsers, block the resource entirely. The crawl flags every insecure resource reference. Common sources are legacy CDN URLs, hardcoded image paths in CMS templates, and third-party widgets that have not updated their endpoints.

Beyond HTTPS, check that HSTS is enabled with a reasonable max-age and that the certificate chain is complete. An incomplete chain causes failures on some devices even when the certificate itself is valid.

Verification: Every URL loads with zero mixed-content warnings, and the SSL certificate has at least 30 days before expiration.

Step 12 — Score the Findings and Rank Fixes by Impact

Action: Consolidate every finding into a single scored list, weighted by severity and effort.

The audit produces findings; the score produces a plan. Each issue is scored on two axes: impact on crawlability, indexation, or answer readiness, and effort to resolve. The resulting matrix sorts into four tiers:

Step 12 — Score the Findings and Rank Fixes by Impact
TierImpactEffortAction
1HighLowFix this week — metadata, canonicals, robots.txt
2HighHighSchedule this sprint — template fixes, Core Web Vitals, structured data
3LowLowBatch and clear — redirect cleanup, minor link fixes
4LowHighDocument and defer — full-site redesigns, platform migrations

This is where a manual audit diverges from a scored one. A spreadsheet of 340 findings does not tell a marketing lead what to do on Monday. A readiness score that weights technical health, SEO signals, and answer-engine readiness into a single number — and ranks the underlying fixes by their contribution to that number — does. Alef's Site Health module is built to run exactly this loop: it crawls, scores, and ranks fixes by impact, so the audit becomes a repeatable cycle rather than a quarterly project.

Verification: Every finding has a tier assignment, an owner, and a target date. The readiness score is recorded as the baseline for the next cycle.

What the Twelve Checks Produce

Run in sequence, these steps convert an unknown site into a scored, prioritized worklist. The first pass is the slowest; each subsequent cycle is faster because the URL inventory, directive report, and template map are already built. The next section covers the mistakes that most often derail an audit mid-sequence — and how to avoid them.

↑ Back to top

Common Website Health Audit Mistakes and How to Avoid Them

Most audits fail on execution, not detection. The findings are accurate; the follow-through is not. These are the recurring errors that keep a readiness score flat.

Seven Mistakes That Stall a Readiness Score

  • Fixing everything at once. A 200-item list with no order stalls execution, so rank findings by impact and traffic exposure, then clear the top issues first.
  • Auditing once and never again. Content velocity and routine deploys reintroduce issues within weeks, so schedule a recurring cadence rather than a one-time project.
  • Chasing a perfect score. A 100 readiness score on a site with no traffic is not the goal; removing the blockers that suppress indexation and citation is.
  • Ignoring AI crawler access. Blocking GPTBot, PerplexityBot, or ClaudeBot by default in robots.txt silently removes the site from AI answer surfaces — a costly default as AEO diverges from classic SEO.
  • Adding structured data without validating it. Schema that fails Google's rich-results tests or contradicts visible page content earns nothing.
  • Optimizing desktop only. Google indexes the mobile render first, so mobile-only gaps hide real problems.
  • Skipping the re-check. Closing an audit without re-running it leaves the readiness score unproven and the fixes unverified.

The pattern is consistent: each mistake substitutes activity for prioritization. A ranked queue, a recurring schedule, and a verification pass convert findings into measurable gains.

↑ Back to top

Website Health Audit Summary: 12 Checks and Their Outcomes

The table below condenses the 12-step process into a working checklist: each row pairs a check with the tool or signal that verifies it, the threshold that defines a pass, and the outcome once that threshold is met. It is designed to stand alone, so it can be lifted into a project tracker or shared with stakeholders who need the audit's scope without the full walkthrough.

Website Health Audit Summary: 12 Checks and Their Outcomes
#CheckTool or signalTarget or thresholdOutcome when the check passes
1Crawlabilityrobots.txt and log-file reviewZero unintended Disallow rules on indexable pathsGooglebot and AI crawlers reach every priority URL
2IndexationSearch Console Page indexing reportZero unintended noindex pages; one canonical per URLOnly canonical URLs appear in the index
3XML sitemapsitemap.xml validationEvery sitemap URL returns HTTP 200 and is indexableCrawlers discover new pages within days
4Core Web Vitalsweb.dev vitals thresholdsLCP under 2.5s, INP under 200ms, CLS under 0.1 at the 75th percentilePages qualify for the "good" CWV bucket
5Mobile readinessMobile-first indexing guidanceIdentical content and metadata on mobile and desktopMobile rendering matches the indexed version
6MetadataTitle and meta-description auditUnique title (50–60 characters) and description (120–155 characters) per URLSearch snippets render fully without truncation
7Heading structureH1–H6 outline reviewExactly one H1 per page; logical nesting below itAssistive tech and parsers map the page correctly
8Duplicate contentCanonical and parameter analysisOne canonical tag per URL; no near-duplicate clustersRanking signals consolidate on the canonical
9Structured dataRich results guidelinesValid JSON-LD on all eligible templates; zero errorsPages become eligible for rich results
10Internal linkingOrphan-page and depth analysisZero orphan pages; every priority URL within three clicks of the homepageLink equity flows to pages that need it
11HTTPS and securityCertificate and mixed-content scanValid TLS certificate; zero mixed-content warningsBrowsers show no "not secure" warning
12Readiness scoreAlef Site Health rollupAll 12 checks weighted into one scoreA single 0–100 figure tracks progress over time

The rollup matters more than any individual row. In Alef's demo environment, the 12 checks aggregate across 24 audited pages into a readiness score of 84.6 — a figure that moves as fixes ship, which is what makes the audit repeatable rather than a one-off cleanup. Teams that want the scoring, prioritization, and fix tracking handled in one place can review Alef's visibility solutions for how the module connects audit findings to content and ranking work.

↑ Back to top

Conclusion: Turn the Audit Into a Repeatable Readiness Loop

A website health audit is a scoring loop, not a one-time cleanup. The 12 checks map directly to the blockers that suppress both Google indexation and AI citation, which is why Alef's Site Health module scores technical, SEO, and answer-readiness signals together and ranks fixes by impact rather than volume.

The highest-leverage checks remain crawl and indexation, Core Web Vitals, mobile parity, metadata, duplicate content, and structured data. With AI crawlers issuing far more requests than Googlebot, answer-readiness is now part of site health, not a separate discipline — a principle explored further in this guide to mastering AI-driven SEO.

Key takeaways - Re-run the 12 checks monthly; re-audit immediately after migrations, redesigns, or CMS changes. - Fix in priority order: crawl and indexation first, then Core Web Vitals, mobile parity, metadata, duplicate content, and structured data. - Track one readiness score over time; a rising score signals improving crawlability, indexation, and AI citation eligibility.

↑ Back to top

Frequently Asked Questions About Website Health Audits

How often should a website health audit be run?

A full website health audit should run quarterly, with a targeted re-check after every deploy, template change, or content launch, and continuous readiness-score monitoring in between. Quarterly passes catch slow-moving decay such as broken internal links, expired redirects, and schema drift that accumulates without a triggering event. Deploy-triggered re-checks matter because a single CMS update or plugin release can alter canonical tags, robots directives, or render behavior across thousands of URLs at once. Between scheduled passes, a readiness score that updates continuously surfaces regressions the moment they appear rather than at the next audit cycle.

What is the difference between a website health audit and a technical SEO audit?

A technical SEO audit covers crawlability and indexation; a website health audit is broader, adding speed, mobile readiness, metadata, duplicate content, structured data, and AI answer-readiness into one score. The narrower audit answers whether search engines can discover and index a site correctly, drawing on the Page indexing report in Google Search Console to confirm which URLs are indexed, excluded, or erroring. The broader audit asks a second question: once a page is indexed, is it fast enough, structured clearly enough, and trustworthy enough to be cited by both Google and AI answer engines? That distinction is why a site can pass a technical SEO audit cleanly and still score poorly on answer-readiness.

How long does a website health audit take?

A first full pass on a mid-sized site takes roughly 6–10 hours at intermediate skill level; subsequent passes are faster because the crawl and baseline are already configured. The initial run absorbs setup time: connecting Search Console, configuring crawl scope, defining URL segments, and establishing the baseline score against which future passes are compared. Subsequent quarterly passes typically compress to 2–3 hours because the crawl configuration, segment definitions, and known-issue list already exist — the work shifts from discovery to verification. Sites above roughly 10,000 URLs scale crawl time linearly, though sampling by template rather than auditing every URL individually keeps the analysis window stable.

What is a good site health score?

There is no universal number, but a healthy site trends above roughly 80 on a 100-point readiness scale with no unresolved critical crawl or indexation issues. The threshold matters less than the trend: a score climbing from 71 to 84 over two quarters indicates the fix loop is working, while a flat 88 with three unresolved canonical conflicts indicates the score is masking real risk. Alef's demo workspace shows 84.6 across 24 audited pages, which illustrates the shape of a passing baseline rather than a target to copy. Any score should be read alongside the severity distribution of open issues, not in isolation.

Can a website health audit improve AI visibility?

Yes, because AI answer engines must crawl, parse, and trust a page before citing it, so fixing crawl access, structure, and structured data directly improves citation eligibility. An AI crawler blocked by a robots directive, a JavaScript-rendered page with no server-side HTML, or an ambiguous entity definition cannot be quoted regardless of content quality. The same technical signals that satisfy Google's structured data guidelines — clean schema, unambiguous entities, stable canonical URLs — also give answer engines the machine-readable confidence they need to attribute a claim. For teams tracking how much traffic arrives from AI surfaces, the AI search statistics for 2026 show why citation eligibility is now a measurable growth lever rather than a technical footnote.

What tools are needed to run a website health audit?

Google Search Console, PageSpeed Insights or a Core Web Vitals field-data source, a crawl tool, and a schema validator form the minimum viable stack. Search Console provides indexation and query data; Core Web Vitals thresholds require field data, not just lab scores, to reflect real user experience; a crawler maps internal links, status codes, and duplicate content; and a validator confirms structured data parses correctly. Alef consolidates the crawl, SEO, and answer-readiness checks into one workspace through its AI visibility platform, which scores technical, SEO, and answer-readiness signals together and ranks fixes by impact rather than by category.

↑ Back to top

Run a Free Website Health Check With Alef

The audit loop closes the moment the first fix ships, and Alef's Site Health module is built to make that first fix obvious. Running a free site health check at alef.ink takes three steps: add a domain, run the audit, then work the fix queue by impact. The readiness score spans technical, SEO, and answer-readiness signals together, so crawlability, metadata, and structured data are ranked in one prioritized list rather than three disconnected reports. Start with the highest-impact blocker, then re-run to confirm the score moved.

↑ Back to top

Sources

↑ Back to top