Technical SEO audit checklist for client websites

1. Agree what the audit covers

Before running a crawler, ask which pages matter to the business and which changes your team can actually make. Record the preferred domain, languages, site sections, recent releases and the client's conversion path. A brochure site and a large product catalog need different sampling plans.

• Confirm the canonical hostname and the site owner's permission to crawl.
• List priority page types, including service pages, articles and conversion pages.
• Agree crawl limits, an acceptable request rate and a time window.
• Request read-only Search Console access if available. If it is missing, label index status unknown.
• Record the audit date, tool settings and any excluded areas.

2. Build an evidence inventory

Compare URLs from navigation, internal links and the sitemap. Keep both the requested URL and final destination when following a redirect. Save representative response headers and rendered-page observations, so a developer can reproduce each finding without rerunning the whole audit.

• For each priority URL: status, redirect chain, canonical, robots directives, title and main heading.
• For each template: one normal page and one edge case, such as an empty category or discontinued service.
• For each finding: the exact URL, observation time, evidence and expected behavior.

3. Separate crawling from indexing

Google's robots.txt documentation describes crawl access. Its noindex documentation describes exclusion from search results. A crawler must be able to fetch a page to read its noindex rule. Check these controls separately instead of reporting one generic 'SEO blocked' issue.

For duplicates, compare redirects, declared canonicals, sitemap entries and internal links. Google treats redirects and canonical annotations as strong canonicalization signals, with sitemap inclusion a weaker signal. These signals indicate a preference, not a guarantee of Google's chosen URL.

• Can the intended crawler request the page?
• Does the response or rendered document contain an unintended noindex?
• Does the canonical point to the approved equivalent page?
• Do navigation and sitemap entries agree with that choice?
• Is the observation a live-page test or Google's stored indexing information? Label which.

4. Prioritize by impact and confidence

Our working order is to investigate access failures on important pages first, then conflicting indexing signals, then page-level improvements. This is a triage method, not a ranking formula. Include business importance, affected templates, confidence, implementation effort and rollback risk in each ticket.

5. Verify the repair, then monitor

Give each repair an owner, a small change, a verification step and a rollback. Retest the affected URLs after deployment and save the new response beside the original evidence. Keep 'fixed on the site' separate from 'observed in search': search systems may not have revisited the page yet.