SEO Audit Checklist

A full SEO audit checklist covering technical, on-page, content, and off-page factors — what to check, what tools to use, and how to prioritize findings into an action plan.

First published: Jun 27, 2026 · Last updated: Jul 29, 2026 · Advanced
demand #5 in Tools#121 in Technical SEO#158 on the site

A full SEO audit reviews four things — technical health, on-page elements, content quality, and off-page authority — and turns them into a short, prioritized action plan, not a 100–200 item report. The core skill isn't checking more; it's checking what matters and ordering it by impact vs. effort. Start from the pain point, fix crawling/indexing gatekeepers first, then spend most of your time on content unless something technical is genuinely broken. Ship 5–10 findings people will actually implement. This is the broad, full-site version; for the technical-only deep dive, use the Technical SEO Checklist.

TL;DR — A full SEO audit spans technical, on-page, content, and off-page — plus an emerging AI-visibility layer — but its output is a prioritized plan, not an inventory. Start from the pain point, scope so it’s manageable, gather data with a crawler + Search Console + analytics, then triage by impact vs. effort. Fix crawling/indexing gatekeepers first, but spend most of your time on content unless something technical is genuinely broken. Ship 5–10 findings in a format people will actually implement. For the technical-only deep dive, use the sibling Technical SEO Checklist; for very large sites, the Enterprise SEO Audit.

Evidence for this claim Google Search Console provides performance and indexing reports that can inform an SEO audit. Scope: Google-owned search data; supplement with crawl and business data. Confidence: high · Verified: Google Search Console: Get started Evidence for this claim Google's SEO Starter Guide organizes the core work around crawlability, useful content, links, and search appearance. Scope: Baseline Google guidance, not a complete audit methodology. Confidence: high · Verified: Google Search Central: SEO Starter Guide

What this audit is — and what it isn’t

This is the broad, full-site audit. It’s deliberately wider than the Technical SEO Checklist, which is the technical-only floor — crawlability, indexing, HTTPS, Core Web Vitals, structured data, sitemaps, robots.txt, canonicalization, mobile. When you need the deep technical diagnosis, go there. This article covers all of that plus on-page, content, and authority, and — more than anything — how to prioritize across all of it.

It’s also distinct from the size- and vertical-specific audits. Auditing a huge multi-team, multi-CMS site is a genuinely different job (you scope by template, not by page) — that’s the Enterprise SEO Audit. Storefronts have their own faceted-nav and variant problems (the Ecommerce SEO Audit), and multi-region sites add hreflang and geotargeting (the International SEO Audit). This general audit is the baseline the enterprise version explicitly departs from.

The philosophy: prioritize, don’t enumerate

The differentiating thesis of a good audit is that exhaustiveness is not rigor. The 1-million-domain site audit study I ran at Ahrefs makes the point in the “What should you fix?” section: “Sometimes, the best course of action is to do nothing because the costs outweigh the benefits.” Not every flag is a problem worth your time.

On the Voices of Search podcast I put the ordering heuristic plainly: “Most of your time is better spent fixing your content unless you have some huge issues with crawling or indexing or something.” That’s the whole prioritization logic in one sentence — technical gatekeepers first if they’re broken, otherwise content is usually where the return is.

And when you deliver, keep it short. In the enterprise-audit context I’ve written that “SEO checklists are impractical at scale” and — the line that generalizes to any site — “I’ve seen several hundred-page documents detailing everything you checked, but no one is going to read those.” The output that gets implemented is “reporting on 5-10 main issues or opportunities.”

The audit process (not just the checklist)

A checklist is what you look at. A process is how you turn it into results. Scaled down from the enterprise version, the shape is:

  1. Start from the pain point. Even for a solo site owner, ask “what’s actually wrong?” before you crawl anything. As I’ve said about client work: “If clients are coming to you asking for an audit, they already have a pain point. Talk to them. Solve that one thing and they’ll be happy with the audit.”
  2. Set scope, in writing. Decide what you’re auditing (whole site? one section? which templates, markets, or subdomains?) and write it down in a line or two — the properties/sections in scope and who owns each one. That short scope note is what keeps a large or multi-template site from turning into an unscoped crawl of everything.
  3. Gather data — and label it. Crawl the site, and pull Search Console + analytics. Keep straight what kind of data each source gives you: Search Console’s Performance and Page Indexing report totals are observed, first-party numbers, but the example URLs GSC lists under an indexing reason are a sample, not a complete inventory of every affected page — don’t treat a handful of examples as the whole picture. On a large or template-driven site, don’t crawl a few convenient URLs and call the result representative; group findings by template, section, or market and sample enough pages from each cohort to say whether an issue is isolated or sitewide.
  4. Prioritize. Score findings by impact vs. effort (below). Discard the low-impact noise.
  5. Deliver a short report. 5–10 findings, in whatever format your implementers actually use — ideally developer-ticket style, tied to business outcomes.
  6. Track implementation, then verify it — don’t assume it. Once something ships, log the release date. A ranking or traffic change after that date isn’t proof the fix worked: Google’s own traffic-drop framework lists concurrent causes — algorithm updates, demand/seasonality shifts, other site changes — that move the same numbers. Watch the specific cohort the fix targeted against a dated baseline for a few weeks before crediting (or blaming) it.

The evidence package every audit finding needs

A finding should be reproducible by someone who did not run the audit. A screenshot without a URL, a crawl warning without settings, or a Search Console count without a collection date is context—not a complete finding.

Store these fields with every material recommendation:

FieldWhat to record
IdentityStable finding ID, title, author/reviewer, and collection timestamp with time zone
ScopeExact URL, request, template, cohort, property, market, and known population
EnvironmentUser agent, device/viewport, locale, authentication state, cache state, and relevant tool settings
Expected stateThe documented or approved behavior against which the observation is being compared
Observed stateStatus, headers, redirect chain, raw HTML, rendered output, extracted fields, logs, or product data actually captured
Evidence filesOriginal exports or captures, descriptive screenshots, and a hash when later alteration or drift matters
CoverageSample size, selection method, discovered-versus-tested counts, and whether results can be generalized
LimitationsBlind spots and explicit fields or systems that were not evaluated
ReproductionOrdered steps and inputs another person can use to see the same result
DeliveryLikely owner, affected value, dependencies, proposed change, and confidence
VerificationAcceptance test, monitoring window, rollback condition, and post-release evidence

Use evidence hashes to identify the exact saved response, export, configuration, or rendered capture that supported a finding; a hash does not make the source accurate or prove that a dynamic page stayed unchanged. Screenshots are useful for visible state, but pair them with the URL, timestamp, machine-readable capture, and test conditions. Preserve the original capture separately from later annotations.

Label the conclusion honestly:

  • Observed: the supplied evidence directly demonstrates the stated behavior.
  • Inferred: observations support a likely cause, but do not directly prove it. Evidence for this claim Google's SEO Starter Guide organizes the core work around crawlability, useful content, links, and search appearance. Scope: Baseline Google guidance, not a complete audit methodology. Confidence: high · Verified: Google Search Central: SEO Starter Guide
  • Not reproduced: the reported behavior was tested under stated conditions and did not occur; this is not proof that it never occurs. Evidence for this claim Google Search Console provides performance and indexing reports that can inform an SEO audit. Scope: Google-owned search data; supplement with crawl and business data. Confidence: high · Verified: Google Search Console: Get started
  • Not evaluated: the method, access, or scope did not test this claim. Do not turn it into zero, false, healthy, or passed.

Specialized audits should extend this record rather than replace it. Ecommerce adds SKU, variant, market, feed, and fulfillment state; international work adds requested locale, response location, canonical, and hreflang cluster; JavaScript audits add raw versus rendered output and navigation state; migrations add before/after captures, mapping version, and release cohort. AI-search observations have their own measurement methodology for prompts, models, answers, citations, and eligible-run denominators.

When to run an audit (the triggers)

An audit isn’t a one-time project. Run one when:

  • Traffic or rankings drop. Google’s official guide to debugging search traffic drops is your checklist here. Its first move: “Check the Crawl stats report and Page indexing report to find if there’s a corresponding spike in issues detected.” Then “Check the Manual Actions report on Search Console to see if any have been issued to your website”, “Check the Security Issues report to find if Google detected a security threat on your website”, and remember that “core updates and other smaller updates may change how some pages perform in Google Search results.” Crucially, Google also flags demand: “Sometimes changes in user behavior will change the demand for certain queries, either due to a new trend, or seasonality throughout the year.” Check Search Console Performance and Google Trends before assuming something broke.
  • Before/after a migration or redesign — the highest-risk moments for SEO.
  • After an algorithm update — to see what moved and why.
  • Before a big content push — to fix the foundation first.
  • On a recurring cadence — quarterly for most sites, monthly for large or fast-changing ones. (That’s common practice, not an official Google/Bing cadence — no such official guidance exists.)

The checklist, by category

Technical & crawlability/indexing

Keep this section short here and go deep in the Technical SEO Checklist. The gatekeeping questions: Is the site crawlable (robots.txt not blocking anything important)? Are your important pages actually indexed (Page Indexing report)? Are sitemaps submitted and clean? Is canonicalization consolidating duplicates correctly? Is HTTPS in place and is the site mobile-friendly? If any of these are broken, they jump to the top of the priority list — nothing downstream matters if pages can’t be crawled or indexed.

One official nuance worth checking during the technical pass: rendering. Google warns that “if your site is hiding important components that make up your website (like CSS and JavaScript), Google might not be able to understand your pages.”

On-page

This is where audits find the most, and where the volume can trick you into over-reporting. My 1-million-domain study quantified exactly how common these are — the top of the list:

Issue% of sites
3XX redirects95.2%
HTTP→HTTPS redirects88%
Missing alt attributes80.4%
Missing/empty meta descriptions72.9%
Slow pages72.3%
Page and SERP title mismatch68.5%
Only a single dofollow internal link66.2%
Title too long63.2%
Links to redirects62.7%
Missing/empty H1 tags59.5%

The catch: common is not the same as important. On meta descriptions specifically, my take from that study is candid: “I don’t focus much on meta descriptions. If it’s a page that’s important to you and you can write a better meta description that fits, go for it.” Fix the on-page issues on pages that matter; don’t burn a week normalizing alt text sitewide because a tool turned 80% of your pages red.

Content

For most sites this is where the real return lives. Audit for:

  • Quality. Google’s guidance is that good content is “easy-to-read and well organized,” “unique,” kept up to date, and “helpful, reliable, and people-first.” Assess depth relative to search intent — not word count. (Word count isn’t a ranking factor; don’t flag “thin” pages by a number alone.)
  • Gaps. What topics should you cover for your audience that you don’t yet?
  • Outdated pages. Updating strong old content usually beats publishing new content. I keep pushing this in talks and podcasts because it’s underrated.
  • Pruning candidates. Pages that get no traffic, no links, and serve no purpose.

One myth to kill here: E-E-A-T is not a ranking factor you should score. Google’s own SEO starter guide has a section literally titled “Thinking E-E-A-T is a ranking factor” and answers it “No, it’s not.” It’s content-creation guidance, not an audit metric.

Off-page / authority

  • Backlink profile — do you have links from relevant, credible sites, and how do you compare to competitors?
  • Dead pages with backlinks — one of the highest-ROI checks. If a page that other sites link to now 404s, you’re leaking authority; redirect it to a relevant live page.
  • Brand mentions — unlinked mentions and general brand presence.

A caution on the flip side: don’t over-disavow. Aggressively disavowing “toxic” links is a known industry over-correction. Most sites should not disavow without clear evidence of a manual action or genuine spam impact.

AI / answer-engine visibility (forward-looking)

Newer, and honestly not fully proven yet — keep it principle-level. Can AI crawlers access your content? Is your structured data in place so engines can parse entities? Is your brand showing up (and cited correctly) in AI answers? Worth a look on modern audits; not worth fabricating a scoring rubric around.

Prioritization: the impact/effort framework

This is the section most competitor checklists skip, and it’s the one that makes an audit useful. Score every finding on two axes — impact (how much will fixing it help) and effort (how hard/expensive is the fix) — and plot a 2×2:

Low effortHigh effort
High impactDo first — quick winsPlan it — big projects worth scheduling
Low impactBatch it — fill-in workSkip it — often the right call

Two framings I lean on hard:

  • “Sometimes, the best course of action is to do nothing because the costs outweigh the benefits.” The bottom-right quadrant is real. Not fixing something is a valid, often correct, audit recommendation.
  • Equate fixes to money. “You should try to equate fixes to cash. This is what businesses care about.” Reframing a fix from “301 these old URLs” to “recover the link equity on pages worth six figures in traffic value” is what gets it prioritized and shipped.

The 2×2 is the mental model, but a finding needs more than an impact/effort guess to survive scrutiny. For each one, record: what you observed, the affected cohort (a template, section, or market — not just “the site”), the evidence behind it, your confidence in it, the effort to fix, the risk of the fix (or of leaving it), any dependencies (a dev sprint, a CMS change, another team), and who owns it. That’s what turns “raise the priority” from a gut call into something a stakeholder can act on — and it’s worth saying plainly: a finding earning a spot on this list is an observation and a recommendation, not implementation approval. That’s a separate call for whoever owns the page or the budget.

Add a denominator before debating impact: a low-effort issue spanning 68% of a cohort deserves different treatment from one found on 0.4%.

In a frozen 10,000-URL crawl, internal links to redirects affect 6,800 URLs at low effort, missing titles affect 1,900 URLs at low effort, render-only content affects 720 URLs at high effort, and broken canonicals affect 40 URLs at low effort. The values are illustrative and are not a site audit.

Common myths this audit debunks

  • More items = more thorough. No — 13 focused items beat 200 unread ones.
  • E-E-A-T is a ranking factor to score. Google says it isn’t.
  • Bounce rate / word count are ranking factors to flag. Neither is a direct ranking factor; assess content against intent, not metrics.
  • An audit is a one-time project. It’s triggered and recurring.
  • SEO studies tell you what to fix. They tell you what’s common — including my own 1M-domain study. Common isn’t causal, and it isn’t always worth fixing on your site.

Where to go next

For the technical-only depth this article intentionally skips, use the Technical SEO Checklist. For scaling the process to massive sites, the Enterprise SEO Audit; for stores and international sites, the Ecommerce and International audit guides.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin an expert quote first.