Technical SEO Audit: A Complete Step-by-Step Checklist

Technical SEO audits become useful when they produce a ranked worklist, not a long export of warnings. This checklist takes site owners and SEO teams from crawlability to indexing, rendering, canonicals, redirects, structured data and measurement. For every finding, record the affected URL or template, evidence, severity, recommended fix and owner.

What should a technical SEO audit produce?

A good audit produces decisions: what is broken, how you know, why it matters and what should happen next. Start with a representative URL sample and a short description of the site’s important page types, such as home, category, product, service, article and conversion pages.

Use one row per finding. A practical record contains:

• Issue: the specific technical condition.

• Evidence: the URL, report, response, screenshot or test result that proves it.

• Scope: one URL, a template, a directory or the whole site.

• Severity: critical, high, medium or low, based on the effect on discovery, indexation, access or measurement.

• Recommendation: the smallest clear change that resolves the condition.

• Owner and status: the person responsible, the planned release and the retest result.

Do not label every warning an error. A blocked parameter URL and a blocked revenue page do not deserve the same response. Severity should reflect the affected page’s business role and the strength of the evidence, not the colour used by an audit tool.

How do you check crawlability first?

Check whether search-engine crawlers can discover and request the pages that matter before investigating more subtle signals. Google describes crawling as the discovery and access stage; the owner’s technical framework groups crawlability with links, site structure, JavaScript, redirects and server errors (Technical SEO: Concepts and Audit Framework, version 3fcbe160c17e1af8).

Begin with the site’s robots.txt file. Record its URL, response status, directives, sitemap references and the paths they affect. Compare those rules with the pages the business wants discovered. A disallow rule can be intentional, but it deserves a high-severity finding when it covers an important page or a directory containing important pages.

Then inspect internal discovery:

• Crawl from the homepage and key navigation paths.

• List important pages with no internal links pointing to them.

• Check that links use real, crawlable destinations rather than click handlers alone.

• Look for redirect chains, loops and links to error pages.

• Compare the crawl’s discovered URLs with the site’s known templates and XML sitemap entries.

Review server logs when they are available. They can show which URLs crawlers request, how often errors occur and whether low-value URL patterns consume attention. Treat a crawl-tool warning as a lead until you reproduce it with the affected URL and a recorded response.

How do you verify indexing and sitemaps?

Verify that the pages you want indexed are eligible, discoverable and represented consistently across the site. Search Console helps owners understand how Google crawls, indexes and serves a site; its starting workflow includes checking whether Google can find and read pages and reviewing index reports (Google Search Console for SEO, version ff71bc15edcb03d5).

Build an indexation comparison rather than trusting one total. Compare:

• Important URLs in your inventory.

• URLs found by the crawler.

• Canonical URLs declared by pages.

• URLs included in the XML sitemap.

• URLs reported as indexed or excluded in Search Console.

For each mismatch, identify the intended state. An intentional noindex on a thin internal-search page may be correct. A valuable article excluded because of a mistaken noindex is a high-severity issue. A sitemap should contain the URLs you want considered, use the preferred URL format and avoid known error, redirect or duplicate variants.

Inspect representative URLs in Search Console and record the result, inspection date and tested URL. Separate “not in the index” from “not eligible for indexing”: the fix differs. Also check whether a page’s rendered HTML contains the main content and whether internal links point to the same preferred URL submitted in the sitemap.

How do you test rendering and mobile experience?

Test what a crawler can access after rendering, not only what appears in the initial HTML response. JavaScript-heavy templates can hide navigation, content, links or metadata from the first response, so compare source HTML with the rendered DOM for representative page types.

For each template, test a page with realistic content and record:

• Main copy, headings, links and images in the initial response.

• The same elements after JavaScript execution.

• Client-side errors, failed requests and blocked resources.

• Metadata, canonical tags and structured data after rendering.

• Layout and content availability at a narrow viewport.

A page can look complete in a browser and still fail a technical check if essential content depends on a request that fails for crawlers. Test logged-out and consent states when they change what a visitor or crawler receives. Check mobile navigation, tap targets, horizontal overflow, text visibility and image loading rather than treating “responsive” as a checkbox.

Use performance data as evidence, not as a vague speed score. Record the affected template, device context, test date, slow resource and user-facing consequence. Prioritize a blocking script or missing primary content above a cosmetic improvement. Retest after deployment with the same URL and conditions so the before-and-after comparison remains meaningful.

How do you audit canonicals and duplicate URLs?

Audit canonicals by deciding which URL should represent each content set, then testing whether every signal supports that choice. A canonical is a preferred-URL signal, not a substitute for removing accidental duplicates or fixing poor internal linking.

For representative pages, record the canonical link element, the URL returned after redirects, the sitemap URL and the URLs used by internal links. Flag conflicts such as:

• A page canonicals to a different URL while the sitemap lists the page itself.

• HTTP, HTTPS, www and non-www versions mixing across templates.

• Trailing-slash, case, parameter or pagination variants creating duplicate paths.

• Similar pages using canonicals without a clear editorial reason.

• A canonical pointing to an error, redirect or inaccessible URL.

Group duplicate findings by template. Ten thousand parameter URLs generated by one filter system are one implementation problem, not ten thousand separate tickets. Preserve useful alternate pages when they serve a distinct need; consolidate only when the pages genuinely compete or repeat one another. Retest the full signal set after the fix, because changing canonicals without changing links or sitemaps leaves mixed instructions behind.

How do you find redirect and status-code problems?

Find redirect and status-code problems by testing important URLs from both the current site and historical URL lists. A correct destination is not enough: record the complete chain, each response code, the final URL and whether the destination satisfies the original intent.

Prioritize findings in this order:

• Important URLs returning server errors, unavailable responses or unexpected access blocks.

• Old valuable URLs with no relevant destination.

• Redirect chains and loops that can be replaced with one direct redirect.

• Internal links that point to redirected URLs.

• Soft error pages that return a successful response while showing missing content.

Check HTTP-to-HTTPS and hostname redirects, trailing-slash rules, uppercase paths and deleted content. A redirect spreadsheet should include the old URL, current response, target URL, target status, reason, owner and retest date. Do not redirect every removed URL to the homepage: use the closest useful replacement or return an appropriate not-found response when no equivalent exists.

How do you validate structured data?

Validate structured data by checking both syntax and whether the markup describes visible, relevant page content. A technically valid item can still be misleading if it claims information the page does not show, so the audit needs a page sample and a content comparison.

For each eligible template, record the schema types, required and recommended properties, validation result, source of each value and the page elements that support it. Check for:

• Invalid JSON-LD, malformed properties or unsupported values.

• Missing required fields for the intended enhancement.

• Conflicting entities across multiple scripts or templates.

• Markup copied onto pages that do not contain the described content.

• Stale prices, dates, ratings, authors or availability.

Separate “valid markup” from “eligible for a search feature”; never promise a rich result from validation alone. Fix template-level generation first, then retest several URLs with different content. Keep the validator result and tested URL in the evidence field so a developer can reproduce the finding.

How do you measure and prioritize findings?

Measure the audit against a baseline that combines technical state, search visibility and business importance. Search Console provides performance and indexing information; its reports can be compared over time and segmented by page, country, date and device, while the owner’s research notes caution against treating technical recommendations as ranking guarantees (Google Search Console for SEO, version ff71bc15edcb03d5; SEO for Google AI Overviews, version 7d969800065503c2).

Before changes, capture:

• Indexed and excluded URL groups.

• Organic clicks, impressions, click-through rate and average position for key page groups.

• Crawl errors, response-code counts and affected templates.

• Core user or performance measurements available to the team.

• Conversions or other business outcomes tied to organic landing pages.

Then score each issue using impact, reach, confidence and effort. A severe issue affecting one important template may outrank a low-impact issue affecting many low-value URLs. State the reason in plain language: “blocks discovery of the lead-generation template” is more useful than “high priority.” Assign a due date, release owner and retest condition. After release, compare the same baseline rather than claiming that any movement came from one fix without supporting evidence.

What should the final audit checklist contain?

The final checklist should let another person reproduce the audit, approve fixes and confirm that the site stayed healthy after release. Keep the evidence attached to each finding instead of placing conclusions in a separate summary that cannot be traced back to URLs and tests.

Use this final handoff list:

• Scope, crawl date, tools, access limits and sampled templates.

• Robots.txt, XML sitemap, internal links and crawl findings.

• Indexability, noindex, canonical and duplicate-URL findings.

• Rendering, mobile and performance observations.

• Status codes, redirect chains, loops and broken destinations.

• Structured-data types, validation results and content matches.

• Baseline measurements and the source of every number.

• Severity, impact, confidence, effort, owner and due date for each action.

• Retest evidence and the date the issue was closed.

End with the first three actions, not a hundred-item dump. The reader should know what to fix now, what to schedule next and what to monitor. That sequence turns an audit into an operating document rather than a one-time report. If the site has complex templates, hand this checklist to the person who can access logs, Search Console and deployment records, then review the evidence together before work begins.