A Technical SEO Audit Checklist Built Around Evidence and Release Decisions

This checklist is designed for practitioners who need a repeatable technical review rather than a tool-generated issue dump. It fits in-house SEO owners, agency teams onboarding or re-auditing a site, developers preparing a release, and operators who need to verify whether the technical foundation supports crawling, indexing, rendering, and machine-readable page data.

Use the checklist as a control document. For every item, attach the evidence that was inspected, record a pass or fail, assign severity, name the owner, describe the corrective action, and state how the fix will be validated. A completed audit should make it possible for another reviewer to reproduce the finding without relying on the original auditor's memory.

The scope is deliberately technical. Content quality, keyword targeting, editorial optimization, and link acquisition are separate workstreams. The technical audit answers a narrower set of questions: can search crawlers access the intended pages, are the right URLs indexable and canonical, does the rendered page perform acceptably, and does any structured data accurately describe what the page contains?

Crawlability comes first because every later check depends on search crawlers being able to request the intended URL and reach important templates through the site.

Robots.txt

• Confirm robots access rules. Evidence required: the live robots.txt file, a list of priority templates, and representative crawl tests. Pass condition: intended public pages and required render resources are not accidentally blocked. Fail condition: a rule prevents access to a priority URL or a resource needed to render it. Severity: Critical for sitewide or high-value template blocks, High for narrower accidental blocks. Owner: technical SEO owner with the developer or platform owner. Corrective action: narrow or remove the unintended rule and document the intended exclusion. Validation step: fetch the affected URLs again with the relevant crawler and confirm access after deployment.
• Verify robots directives are intentional. Evidence required: the live directives and the release or environment policy that explains them. Pass condition: production directives reflect the intended crawl policy and temporary environment rules are not leaking into the public site. Fail condition: legacy, staging, or copied directives remain active without a current purpose. Severity: High when important URLs are affected, Medium for unused or confusing rules. Owner: developer or infrastructure owner. Corrective action: reconcile the file with the documented production policy. Validation step: compare the live file with the approved version after release.
• Confirm sitemap discovery is configured as intended. Evidence required: the live robots file and the actual sitemap location used by the site. Pass condition: any sitemap reference points to the correct live resource and does not conflict with the site's sitemap configuration. Fail condition: the declaration is stale, missing where the team relies on it, or points to an obsolete environment. Severity: Medium. Owner: technical SEO owner. Corrective action: update the declaration or document why it is intentionally omitted. Validation step: fetch the declared sitemap and confirm it resolves successfully.

XML Sitemap

• Validate sitemap inclusion rules. Evidence required: the submitted sitemap files, a crawl export, and representative indexability checks. Pass condition: listed URLs are intended for indexing, resolve successfully, and use the preferred canonical form. Fail condition: the sitemap contains redirects, non-indexable URLs, duplicates, or obsolete locations. Severity: High when the problem affects large template groups, Medium for isolated entries. Owner: technical SEO owner with the CMS owner. Corrective action: change sitemap generation logic and remove non-preferred URLs. Validation step: regenerate the sitemap and compare a fresh export with crawl and indexability data.
• Check sitemap size and segmentation. Evidence required: sitemap file counts and file sizes from the live site. Pass condition: sitemap generation respects the source limits of 50,000 URLs or 50MB per file and uses a sitemap index where appropriate. Fail condition: files exceed the intended limits, truncate unexpectedly, or mix unrelated template groups in a way that makes diagnosis difficult. Severity: High if discovery is impaired, otherwise Medium. Owner: developer or CMS owner. Corrective action: split files by stable template or content grouping and regenerate the index. Validation step: fetch every sitemap file and confirm all intended entries are present.
• Verify change metadata is trustworthy. Evidence required: sample sitemap entries and the corresponding CMS publish or modification records. Pass condition: modification values are populated only when the underlying page meaningfully changed. Fail condition: timestamps are rewritten mechanically without a content change or remain stale after meaningful updates. Severity: Low to Medium because the primary issue is diagnostic reliability. Owner: CMS owner. Corrective action: bind sitemap change metadata to a reliable source. Validation step: update a test page through the normal workflow and confirm the generated sitemap changes as intended.

Internal Linking and Crawl Paths

• Confirm priority pages are reachable through normal navigation. Evidence required: a site crawl, internal link graph, and representative user paths. Pass condition: important pages are discoverable through stable HTML links without depending on search, scripts, or hidden navigation states. Fail condition: an important page is orphaned or discoverable only through an unstable path. Severity: High for important orphan pages, Medium for excessive depth. Owner: SEO owner with information architecture or product owner. Corrective action: add relevant contextual or navigational links. Validation step: recrawl and confirm the page receives intended internal links.
• Audit parameter and faceted crawl paths. Evidence required: crawl samples of parameterized URLs, canonical directives, robots rules, and server logs when available. Pass condition: crawlable variants have a deliberate purpose and low-value combinations do not create uncontrolled duplicate crawl paths. Fail condition: filters, session IDs, tracking parameters, or sort combinations generate large ungoverned URL sets. Severity: High when crawl resources or indexation signals are materially fragmented. Owner: technical SEO owner with engineering. Corrective action: simplify URL generation, canonicalization, linking, or crawl controls based on the intended user and search behavior. Validation step: rerun a focused crawl and confirm the unwanted URL set no longer expands.

Crawl Errors

• Resolve server and not-found failures on important URLs. Evidence required: crawl results, Search Console evidence, server logs where available, and a mapped list of affected internal links. Pass condition: important URLs return the intended response and broken internal destinations are removed or corrected. Fail condition: priority pages return 5xx or 4xx responses, or internal links repeatedly send crawlers to broken locations. Severity: Critical for widespread server failures, High for broken important pages. Owner: engineering or infrastructure for server faults, content or SEO owner for link corrections. Corrective action: restore the intended resource, repair links, or return the correct terminal status. Validation step: recrawl affected paths and confirm the response and internal linking are correct.
• Detect soft 404 states. Evidence required: crawler classification, rendered page review, and server response codes. Pass condition: an unavailable resource returns an appropriate terminal status rather than a thin error state with 200. Fail condition: an error-like page returns a successful response while offering no substantive replacement content. Severity: High at scale, Medium when isolated. Owner: developer. Corrective action: return an appropriate status or provide a genuine replacement page. Validation step: fetch the corrected URL and confirm the response and rendered state agree.
• Collapse unnecessary redirect chains. Evidence required: a redirect map from the crawl and representative browser or server traces. Pass condition: internal links point directly to the preferred destination and redirect paths are as short as practical. Fail condition: legacy chains add avoidable hops or create loops. Severity: High for loops, Medium for recurring chains. Owner: developer with SEO review. Corrective action: update redirect rules and source links to point to the final destination. Validation step: recrawl and confirm the chain has been removed without changing the intended destination.

Indexation checks verify whether crawlable pages send a consistent message about which URLs should be stored and surfaced. The audit should compare directives, canonicals, redirects, duplicate variants, internal links, and sitemap inclusion rather than reviewing any one signal in isolation.

Meta Robots and X-Robots-Tag

• Audit page-level indexation directives. Evidence required: rendered HTML, HTTP headers, and a crawl export for priority templates. Pass condition: pages intended for search have no unintended exclusion directive and pages intentionally excluded have a documented reason. Fail condition: a production template inherits an exclusion accidentally or conflicting directives appear in HTML and headers. Severity: Critical for large important sections, High for isolated high-value pages. Owner: developer or CMS owner with technical SEO review. Corrective action: correct the directive at its source template or header rule. Validation step: refetch representative URLs and confirm the effective directive.
• Review non-HTML asset directives where they matter. Evidence required: headers for relevant documents or media and the business requirement for their search visibility. Pass condition: asset directives match the intended indexation policy. Fail condition: important assets are excluded accidentally or unwanted assets are intentionally indexable without a clear reason. Severity: Medium. Owner: technical SEO owner with platform owner. Corrective action: revise header rules. Validation step: refetch the asset and confirm the returned directive.

Canonical Tags

• Verify preferred URL declarations. Evidence required: rendered canonical tags, redirects, sitemap entries, and internal links for representative templates. Pass condition: each indexable page points to the intended preferred URL and the surrounding signals agree. Fail condition: canonicals point to redirects, errors, unrelated pages, or inconsistent host and protocol variants. Severity: Critical for widespread canonical mistakes, High for important isolated conflicts. Owner: developer with technical SEO owner. Corrective action: repair canonical generation and align linking or redirect rules. Validation step: recrawl the affected template and confirm consistent canonical signals.
• Review pagination and cross-domain use deliberately. Evidence required: sample paginated sequences or cross-domain canonical relationships and the documented content ownership decision. Pass condition: canonicals preserve distinct useful pages where appropriate and cross-domain declarations are intentional. Fail condition: useful paginated content is collapsed indiscriminately or a cross-domain canonical appears without an approved reason. Severity: High when important pages are suppressed, otherwise Medium. Owner: SEO owner with content or platform owner. Corrective action: revise canonical logic to match the actual duplication relationship. Validation step: inspect the rendered tags and indexing signals after deployment.

Duplicate URL Variants

• Consolidate protocol and hostname variants. Evidence required: redirect tests and crawl data for all public host variants. Pass condition: each variant resolves consistently to the preferred host and protocol. Fail condition: multiple variants return indexable content or create divergent canonical signals. Severity: High. Owner: infrastructure or developer. Corrective action: standardize redirects and configuration. Validation step: retest all variants and confirm a single preferred destination.
• Control duplicate parameters and near-duplicate templates. Evidence required: crawl samples, canonical rules, internal links, and content comparison. Pass condition: parameterized or duplicate pages have a clear search purpose or are consolidated appropriately. Fail condition: sorting, tracking, filtering, or template duplication creates competing indexable URLs without distinct value. Severity: High at scale, Medium for limited sets. Owner: technical SEO owner with engineering or content owner. Corrective action: change linking, parameter handling, canonicalization, or content differentiation. Validation step: recrawl and inspect the preferred URL set.

Index Coverage Review

• Compare discovered, crawled, and indexed populations. Evidence required: site crawl totals, sitemap totals, Search Console indexing reports, and representative URL inspections. Pass condition: gaps between intended and observed indexation can be explained by documented exclusions, duplication, or crawl state. Fail condition: important missing pages have no known cause or excluded pages contradict the indexation policy. Severity: High for unexplained loss of important pages. Owner: technical SEO owner. Corrective action: investigate the specific signal conflict rather than forcing indexation blindly. Validation step: inspect corrected URLs after recrawl and confirm the intended state.
• Review reported exclusion reasons by template. Evidence required: exported Search Console categories mapped to site templates. Pass condition: expected exclusions are understood and unexpected categories have owners. Fail condition: large groups remain unexplained or are dismissed without sampling URLs. Severity: High when the group contains priority pages, otherwise Medium. Owner: technical SEO owner. Corrective action: sample, diagnose, and assign the root cause by template. Validation step: verify the corrected template and monitor whether the affected population moves toward the intended state.

Performance auditing should connect measured symptoms to the rendering or delivery cause. Use field data where available to understand real-user experience and lab tools to reproduce bottlenecks. Do not treat a single performance score as a guaranteed ranking outcome.

Largest Contentful Paint

• Identify the actual LCP element and its critical path. Evidence required: browser performance traces, PageSpeed evidence, network timing, and the rendered page. Pass condition: the main content element can be discovered and delivered without avoidable blocking work. Fail condition: delayed server response, oversized media, render-blocking resources, or late discovery materially delays the element. Severity: High on high-traffic templates, Medium elsewhere. Owner: front-end or platform engineering. Corrective action: optimize the specific request chain, resource priority, server path, or media delivery. Validation step: rerun the same test profile after deployment and compare the trace.
• Review server response against the source threshold. Evidence required: repeatable server timing from representative locations and request types. Pass condition: the measured response is below 600ms in the defined test context or any slower result has a documented infrastructure explanation and remediation plan. Fail condition: server delay is a recurring contributor to slow rendering. Severity: High when it affects core templates broadly. Owner: infrastructure or back-end engineering. Corrective action: profile application, cache, database, network, or hosting bottlenecks. Validation step: repeat the same measurement after the change.
• Check the LCP target in context. Evidence required: current field and lab measurements for the page template. Pass condition: the relevant mobile experience is under 2.5 seconds for the stated Good target in the source checklist. Fail condition: the page repeatedly exceeds the target in representative data. Severity: High where field data confirms a broad issue. Owner: performance owner. Corrective action: fix the dominant LCP causes rather than optimizing unrelated assets. Validation step: confirm improvement in lab traces and then monitor field data as it refreshes.

Cumulative Layout Shift

• Trace unexpected movement to the responsible element. Evidence required: layout-shift debugging data and a rendered replay. Pass condition: images, embeds, ads, fonts, and injected content reserve predictable space. Fail condition: late content changes move visible elements without user intent. Severity: High when the issue affects common interaction paths. Owner: front-end engineering. Corrective action: reserve dimensions, stabilize font delivery, or redesign the injection behavior. Validation step: rerun shift diagnostics on the same page states.
• Check the CLS target. Evidence required: representative field or lab measurements. Pass condition: the page is under 0.1 for the stated Good target in the source checklist. Fail condition: recurring layout movement exceeds the target. Severity: High on heavily used templates. Owner: front-end engineering. Corrective action: resolve the specific moving elements identified in the trace. Validation step: retest the same page and viewport states.

Interaction to Next Paint

• Profile long tasks and interaction handlers. Evidence required: performance traces from representative interactions and a list of third-party scripts active on the page. Pass condition: user interactions are not blocked by avoidable main-thread work. Fail condition: long JavaScript tasks, expensive handlers, or third-party scripts repeatedly delay response. Severity: High on key interactive templates. Owner: front-end engineering with product owner for third-party tradeoffs. Corrective action: split work, defer noncritical scripts, reduce handler cost, or remove low-value integrations. Validation step: repeat the same interaction trace after deployment.
• Check the INP target. Evidence required: field data when available and repeatable lab interaction tests. Pass condition: the experience is under 200ms for the stated Good target in the source checklist. Fail condition: representative interactions exceed the target. Severity: High where the issue is confirmed in field data. Owner: front-end engineering. Corrective action: address the dominant interaction bottleneck. Validation step: compare post-fix traces and monitor field data.

General Speed Checks

• Audit media delivery. Evidence required: image inventory, transfer sizes, formats, dimensions, and request priority. Pass condition: media is appropriately compressed, sized, and served in formats supported by the audience and platform. Fail condition: oversized or unnecessarily expensive assets dominate transfer or rendering cost. Severity: Medium to High depending on template impact. Owner: front-end or media pipeline owner. Corrective action: resize, compress, convert, or prioritize assets based on page need. Validation step: compare transfer size and rendering traces after release.
• Review render-blocking resources and cache policy. Evidence required: critical request chains, response headers, and dependency analysis. Pass condition: critical CSS or script work is deliberate and static assets use an appropriate cache policy. Fail condition: avoidable blocking resources or missing cache controls repeatedly increase load cost. Severity: Medium to High. Owner: front-end or platform engineering. Corrective action: defer, split, inline, preload, or cache resources based on measured need. Validation step: rerun network and rendering traces.
• Evaluate delivery architecture by audience. Evidence required: user geography, origin timing, cache behavior, and traffic profile. Pass condition: the delivery setup matches the site's real audience and performance bottlenecks. Fail condition: infrastructure choices add measurable latency without a business or technical reason. Severity: Medium. Owner: infrastructure owner. Corrective action: change caching or delivery architecture only where measurements justify it. Validation step: repeat geographically relevant timing tests.

Structured data should be audited as machine-readable page description, not as a guaranteed ranking or rich-result mechanism. The key questions are whether the markup matches visible content, uses appropriate types and properties, remains internally consistent, and satisfies current Google requirements when a supported feature is part of the objective.

Markup Presence and Fit

• Map schema types to real page entities. Evidence required: representative rendered pages and every JSON-LD block or other structured data format present. Pass condition: each type accurately describes content or an entity relationship on the page. Fail condition: a type is present only because a plugin emits it or because the team expects a search feature the page does not support. Severity: High for misleading markup, Medium for unnecessary markup. Owner: technical SEO owner with content or product owner. Corrective action: remove unsupported types or align the implementation with real page content. Validation step: review the corrected rendered page and markup together.
• Check Organization, LocalBusiness, Article, Product, Offer, BreadcrumbList, and other relevant types only where appropriate. Evidence required: template inventory and page-content mapping. Pass condition: the selected type is the best fit for the actual page and data source. Fail condition: broad or conflicting types are used without a defensible entity model. Severity: Medium to High. Owner: technical SEO owner. Corrective action: revise the type map and generator rules. Validation step: retest representative template instances.

Markup Validation

• Validate Google-supported features separately from Schema.org conformance. Evidence required: live Rich Results Test output where relevant and Schema.org validator results for vocabulary structure. Pass condition: supported feature requirements are met where intended and the markup is structurally valid. Fail condition: required fields are missing, the block does not parse, or the type-property relationship is invalid. Severity: High for blocking or misleading defects. Owner: implementer with technical SEO review. Corrective action: repair the generator or source data. Validation step: rerun both relevant validators on the live page.
• Review deprecated or obsolete assumptions. Evidence required: current Google documentation and the implementation inventory. Pass condition: no schema type or property is retained solely for a search feature that is no longer available. Fail condition: the implementation is justified by outdated documentation. Severity: Medium. Owner: technical SEO owner. Corrective action: update the objective or remove unnecessary markup. Validation step: document the current supported use case for each retained block.

Content Match and Conflict Checks

• Compare material structured data values with the rendered page. Evidence required: visible page content, source data, and the final markup. Pass condition: names, prices, ratings, dates, availability, authorship, and other important values agree with the page. Fail condition: markup contains hidden, stale, exaggerated, or contradictory information. Severity: Critical for deceptive material values, High for other significant mismatches. Owner: content or commerce data owner with technical SEO review. Corrective action: repair the source data or remove the unsupported property. Validation step: re-render and compare the page and markup again.
• Detect duplicate or competing generators. Evidence required: all structured data blocks and their generating components. Pass condition: multiple blocks are compatible and each entity has a known source of truth. Fail condition: a theme, plugin, tag manager, or custom template publishes conflicting versions of the same entity. Severity: High. Owner: developer or platform owner. Corrective action: consolidate generators or reconcile their data model. Validation step: recrawl affected templates and confirm the conflict is gone.

FAQ content may still be useful to readers, but do not treat FAQPage markup as a route to a current Google FAQ rich result. Prioritize structured data where the page has a genuine entity or supported use case and where the team can keep the values accurate over time.

Prioritization should follow dependency, severity, affected scope, and confidence in the diagnosis. A technical issue deserves immediate engineering attention when it prevents intended crawling or indexation, creates a server failure, or sends search systems to the wrong canonical destination.

Fix Immediately: Blocking Issues

• Robots or directive blocks on priority pages. Evidence required: live crawl tests and indexation directives. Pass condition: intended pages are accessible and indexable. Fail condition: a rule blocks them. Severity: Critical. Owner: platform or developer. Corrective action: remove the accidental block. Validation step: retest the live URL.
• Canonical or redirect failures. Evidence required: rendered canonicals and redirect traces. Pass condition: signals resolve to the intended preferred URL. Fail condition: loops, wrong targets, or conflicting host variants remain. Severity: Critical. Owner: developer. Corrective action: repair the rule or template. Validation step: recrawl and confirm a single preferred destination.
• Server failures on important pages. Evidence required: crawl, monitoring, and server evidence for 5xx responses. Pass condition: important requests return the intended successful or terminal response. Fail condition: repeated server failure prevents access. Severity: Critical. Owner: infrastructure or back-end engineering. Corrective action: resolve the underlying application, origin, dependency, or capacity fault. Validation step: repeat the same requests after remediation.

Fix in the Current Sprint: High Impact and Contained Scope

• Broken discovery paths. Evidence required: sitemap and internal link audits. Pass condition: priority pages are discoverable through stable links and correctly listed where intended. Fail condition: orphaning or broken sitemap generation hides important URLs. Severity: High. Owner: SEO with CMS or engineering. Corrective action: repair links or generation logic. Validation step: recrawl the affected template.
• Confirmed performance bottlenecks. Evidence required: field or lab traces tied to a specific cause. Pass condition: the dominant bottleneck has an assigned fix and measurable post-release validation. Fail condition: the team optimizes low-impact assets while the primary rendering issue remains. Severity: High where important templates are affected. Owner: performance engineering. Corrective action: address the measured cause. Validation step: compare like-for-like traces.
• Invalid structured data on priority templates. Evidence required: live validator output and page-content comparison. Pass condition: markup is valid, accurate, and appropriate for its current use case. Fail condition: errors, conflicts, or content mismatches remain. Severity: High for misleading or blocking defects. Owner: implementer with technical SEO review. Corrective action: repair the generator or remove unsupported output. Validation step: retest the live template.

Schedule in Backlog: Important but Non-Blocking

• Short redirect chains, secondary script work, and lower-priority duplicate cleanup. Evidence required: quantified affected URLs and measured impact. Pass condition: the issue is documented, bounded, and does not block core crawling or indexation. Fail condition: a supposedly low-priority item is actually propagating across important templates. Severity: Medium. Owner: relevant engineering or content owner. Corrective action: schedule the change with a defined validation plan. Validation step: verify the targeted URL set after release.
• Coverage expansion after root causes are clean. Evidence required: completed blocking and sprint-level remediation plus a remaining issue inventory. Pass condition: lower-priority work is sequenced only after major access, indexation, and performance defects are controlled. Fail condition: the team spends time expanding markup or tuning secondary pages while higher-severity problems remain open. Severity: Medium. Owner: technical SEO lead. Corrective action: reorder the backlog. Validation step: confirm all higher-severity findings have closed evidence before starting the next tier.

The source checklist previously stated that major CMS changes or redesigns often surface Tier 1 issues. Treat that as an internal operating observation rather than a verified industry benchmark because no supporting source URL is present. The decision rule remains useful: re-audit after material platform changes and let evidence determine the actual severity.