SEO audit checklist with evidence and priorities

An SEO audit should produce a ranked repair plan with evidence, not a spreadsheet full of red cells. The useful output is a list of findings that states what was observed, which URLs are affected, why the condition matters, what should change, who owns the change and how the fix will be verified.

This SEO audit checklist covers crawling, indexing, canonicals, redirects, sitemaps, on-page content, performance and measurement. It also adds a reproducible priority score so a small team can distinguish a site-wide indexing block from an unsupported suggestion to rewrite a handful of titles.

What should an SEO audit deliver?

Start with an evidence log. One row should represent one finding, even when that finding affects many URLs. Store the affected pattern and a small sample separately from the recommendation. This prevents the common mistake of treating a crawler label as a diagnosis.

An audit report is not complete when an issue is assigned. It is complete when the evidence, decision and verification result can be followed by another person. For an initial machine-readable inventory, the site audit tool can collect common page-level signals; the interpretation still belongs in the evidence log.

How should you set the audit scope before crawling?

Define the property, hostnames, protocols, environments and URL groups before running a crawler. Decide whether subdomains, parameters, faceted navigation, translated paths, PDFs and staging hosts belong in scope. Record the crawl time, user agent, starting URLs, authentication state and limits. Two crawls with different settings should not be compared as if they measured the same population.

Build the initial inventory from more than one source: internal links found by the crawler, XML sitemaps, important landing pages from Search Console, organic landing pages from analytics and business-maintained URL lists. Each source has a blind spot. A crawler misses orphan URLs; a sitemap can contain stale entries; Search Console shows URLs known to Google rather than a complete CMS inventory.

Google's Page indexing report documentation explicitly warns that non-indexed URLs are not automatically errors. Duplicates, removed pages and deliberately excluded parameter URLs may be correct. Write the intended index state for each template before judging the report.

Which crawling and indexing checks come first?

Test whether important URLs are reachable without a login, return the intended HTTP status, allow crawling and do not carry an accidental noindex. Then check whether Google discovered and indexed representative URLs. A crawler proves what your test client received; it does not prove that Google selected the same canonical or placed the page in the index.

1. Confirm that important HTML pages return a direct successful response.
2. Review robots.txt rules by user agent and path. Google's robots.txt guide explains that the file controls crawling, not reliable removal from search.
3. Check page-level robots directives in raw and rendered HTML.
4. Compare the declared canonical with the final URL, internal links and sitemap entry.
5. Inspect samples in Search Console instead of inferring index state from a crawler label.

The URL Inspection documentation separates indexed data from the live test. Indexed data describes the version in Google's systems; the live test evaluates the currently accessible page and does not itself change the index. Save which view supplied each observation.

How do canonicals, redirects and sitemaps fit together?

Audit these signals as a system. An indexable URL should normally link internally to its preferred version, declare a consistent canonical and appear in the sitemap when it belongs there. Redirected, duplicate, blocked or intentionally non-indexable URLs should not remain in an indexable sitemap set.

Google treats canonical declarations as signals and can select a different canonical when signals disagree. Its canonicalization guide recommends consistent internal linking and sitemap references. The sitemap guide says to include the canonical URLs that you want shown in search.

For moved content, map each old URL to the most relevant replacement. Google's redirect guidance recommends permanent server-side redirects for permanent moves. Avoid redirecting unrelated removals to the homepage merely to eliminate a crawler error.

How should titles, snippets and page content be audited?

Use page purpose and search evidence before applying length rules. A title is weak when it is missing, duplicated across pages with different purposes, misleading or too vague to identify the page. Google can construct title links from the title element, main heading, prominent page text and link text, as described in its title link documentation.

A meta description is a candidate source for the result snippet, not a guaranteed message. Google's snippet documentation says that snippets primarily come from page content and may vary by query. Flag missing descriptions for important pages when a written summary would help; do not label every rewritten snippet as a ranking fix.

Review whether the page answers its stated purpose, contains original evidence, identifies who created it and avoids unsupported claims. Google's people-first content questions are useful review prompts, but they are not a numeric scoring algorithm. Record a concrete gap such as “comparison omits total cost and test method,” rather than “content quality: 62.”

How do you audit performance, mobile rendering and structured data?

Separate field data from laboratory diagnostics. Field Core Web Vitals describe real-user experience over an aggregation window; a single lab run helps debug a page under one test configuration. Google's Core Web Vitals documentation recommends achieving good metrics while noting that page experience includes more than those metrics.

Test representative templates at narrow and wide viewports. Look for missing primary content, horizontal document overflow, inaccessible navigation, late layout shifts and interactions that require unsupported input. Save the device, network and test URL with the result.

Validate structured data against visible page content and the feature's documentation. Valid syntax does not guarantee a rich result. Google's structured data introduction explains that markup makes content eligible for supported features but display is not guaranteed.

How do Search Console and analytics change the diagnosis?

Join technical findings to outcomes only after aligning URL and date definitions. Search Console can show whether Google discovered, indexed and displayed pages. Analytics can show sessions and conversions after a visit. Neither replaces the other, and a crawl cannot establish either outcome.

For each high-impact template, store a baseline: indexed samples, impressions, clicks, organic landing-page activity and relevant conversions. Compare equivalent periods and annotate releases. If an important URL has no impressions, first verify index eligibility and query relevance. If it receives impressions but few clicks, inspect query-page fit and result presentation. The Search Console report guide explains which interface answers each question.

When exports exceed the interface limit, use the Search Console API export workflow and retain its request settings. An audit conclusion should be reproducible from the same source, filters and period.

How do you rank audit findings without pretending the score is Google’s?

Use an internal decision formula and label it as such:

Priority = (impact + coverage + confidence) / effort

Score impact from 0–3, coverage from 0–3, evidence confidence from 0–2 and effort from 1–3. The scale ranks work inside this audit; it does not estimate a ranking increase.

Our calculation. A template that adds noindex to 120 intended landing pages can score (3 + 3 + 2) / 1 = 8.0 when the template cause is proven and the repair is small. Rewriting 12 weak titles without query or CTR evidence can score (2 + 1 + 1) / 2 = 2.0. The first finding deserves earlier investigation under this model. The URL counts are hypothetical and do not describe a private project.

Keep regulatory, security and destructive-change risk outside the score. A high number is a queueing aid, not automatic permission to deploy. Record the owner and dependency beside the score so an unassigned critical issue does not disappear behind easy tasks.

How is an audit finding verified and closed?

Define the closure test before implementation. After a fix, rerun the smallest test that proves the intended state, then sample adjacent templates for regressions. For an indexing change, this may require a recrawl, a live inspection and later confirmation from indexed data. For a redirect map, test old URLs, final destinations, chains and internal links.

Do not close a finding because a ticket moved to “done.” Close it when the original condition no longer occurs and the intended outcome can be observed. Keep before-and-after evidence together.

What can an SEO audit checklist not prove?

A checklist cannot guarantee rankings, traffic or indexing. It cannot convert a third-party tool score into a Google diagnosis, and it cannot decide business intent for duplicate, archived or filtered pages. A crawler sees the response it received at a particular time; it does not see every Google system or every user session.

The checklist also cannot replace release controls. Recommendations involving templates, redirects, robots directives or canonicals need testing and rollback planning. Finish by moving accepted tasks into the team's delivery system and keep the audit log as the evidence layer.