How to Run a Technical SEO Audit: A Repeatable Checklist

A useful technical SEO audit produces a list of affected URLs, a reason each finding matters, and a way to check the fix. Start with representative pages to understand the site, then widen the crawl when the question is site-wide. Keep your own crawl results separate from what Google reports: they answer different questions.

1. Define the scope and page templates

List the URLs that matter to the audit: the homepage, important search-facing pages, and examples of each distinct template. On a site with product, category and blog pages, inspect at least one of each. Record which template generates each example so that a repeated defect can be fixed in one place rather than edited page by page. SEOmator recommends this template-based approach.

Decide whether you need a full-site crawl. A one-page audit can examine that page in depth, but it cannot establish whether the site has orphan pages or site-wide duplicate content; those questions require a full-site crawl. Treat the representative pages as a starting sample, not as proof that every URL using a template is healthy.

2. Crawl URLs and investigate failures

Crawl the site and group findings by response code, linked URL, redirect and page template. For a link returning a 4XX response, record both the destination and the pages linking to it. Check whether the destination moved, the link is wrong, or the URL is no longer meant to exist. Links to 4XX URLs can harm the visitor experience; the useful output is a specific link or destination to correct, not merely a count of errors (Ahrefs).

Investigate 5XX responses and redirects in the same URL-by-URL manner. Note whether an important page fails directly or whether an internal link sends visitors through an obsolete URL. After changing links or redirects, recrawl the affected area. A new crawl can show whether the reported response codes and links changed; it cannot establish a ranking effect.

3. Separate crawlability from indexability

Review robots.txt rules, sitemaps and page-level robots directives, then compare your findings with Google Search Console’s Indexing report. The report is useful for finding important pages Google reports trouble accessing or indexing; your own crawl shows a different view of the site (Backlinko).

Use URL Inspection on important URLs when access, an unintended noindex, or the selected canonical needs investigation. If Google reports that indexing is not allowed, inspect the page’s robots directive before calling it an error: the exclusion may be deliberate. If Google selects a different canonical, compare that choice with the version you intended. Those observations identify a discrepancy to investigate, not its cause by themselves.

A robots.txt crawl block is not a reliable substitute for an indexing decision. Google may index a URL it cannot crawl when other pages link to it (Ahrefs). For a page that is intentionally excluded, a robots meta directive in its HTML head can express that intent:

<head>
  <meta name="robots" content="noindex" />
</head>

Check the directive against the purpose of the specific page. Finding noindex on a page meant to appear in search is a problem; finding it on a deliberately excluded page is not.

4. Inspect the rendered state by template

For each representative template, compare the rendered page with the intended title, links and structured data. This matters when JavaScript supplies any of those elements: a rendered-page audit can see what was present in the state it analyzed (SEOmator). Record the URL and template alongside the result. A passing check for one product page does not establish that every product URL—or another template—renders the same way.

If a check fails across representative pages built from one template, investigate the shared template before patching individual pages. Then inspect another affected URL after the change. This distinguishes a template fix from a one-page exception.

5. Review duplicates, canonicals and changed URLs

Group URLs that appear to serve duplicate versions of a page and identify the version you intend search engines to use. Compare that decision with each page’s canonical link. For example, a duplicate page whose intended canonical is the main product URL might contain:

<head>
  <link rel="canonical" href="https://example.com/products/widget" />
</head>

The URL in that example is illustrative; the real value must match the page you intend as canonical. A canonical link is a signal about the preferred version, not proof that Google selected it. URL Inspection can reveal when Google’s selected canonical differs from your intention (Backlinko).

For an old URL that has a current location, map the old URL to that destination with a 301 redirect (Ahrefs). Recheck the old URL, its destination and internal links that still point to it. For duplicates, choose an approach that fits the pages: the AIOSEO duplicate-content guidance discusses redirects and canonical links as alternatives, rather than assuming every duplicate needs both.

6. Check search-facing content and performance evidence

Inspect titles and meta descriptions on representative pages, especially when a shared template generates them. Check whether expected structured data appears in the rendered state, not just in a source file you expect the site to use. These checks establish what the analyzed page contains; they do not establish how every URL appears in search.

Keep performance measurements in separate columns. Lighthouse results are lab data useful for diagnosis; field data comes from real Chrome users (SEOmator). Label each result accordingly instead of treating a lab score as a verdict on every visitor’s experience.

7. Prioritize, fix and rerun

Triage findings by whether they obstruct access or intended indexing, how many important URLs or templates they affect, and whether they are errors, warnings or smaller opportunities. Audit tools may supply severity labels, but inspect the affected URLs before accepting the label as your work order. The AgencyAnalytics audit workflow uses errors, warnings and notices to organize this review.

Fix shared template problems at the template level where appropriate. After each batch, rerun the relevant checks: recrawl links and response codes, inspect rendered examples, and revisit Search Console’s Indexing report and URL Inspection for the Google-reported issue. A successful deployment does not show that a failed check now passes. Nor does a passing technical check promise indexing or rankings.

For ongoing maintenance, combine crawl findings with Search Console and relevant performance diagnostics rather than relying on one report. Quarterly health checks plus automated weekly or monthly checks are one published audit cadence; choose a schedule that lets you notice changes and verify fixes on your site.