SEO Guides · Technical SEO

What Should a Technical SEO Audit Include?

A practical guide to the checks, evidence, tools and prioritisation a useful technical SEO audit should contain.

A practical guide to the checks, evidence, tools and prioritisation a useful technical SEO audit should contain.

A technical SEO audit should explain what is stopping a website from being crawled, indexed, understood and served efficiently

If you are new to the subject, start with What Is Technical SEO and Why Does It Matter?. This guide focuses on what a professional audit should actually investigate, evidence and prioritise.

A technical SEO audit is a structured investigation of the systems that sit underneath organic search performance. It should identify technical problems, show evidence of their scale, explain why they matter, and put the fixes into a sensible order.

That is different from running a crawler and exporting every warning. Automated tools are excellent at finding patterns, but they do not know which URLs matter commercially, whether a behaviour is intentional, or whether a warning is actually affecting search performance.

For an ecommerce website, that distinction is especially important. A store may contain thousands of product, collection, filter, variant and parameter URLs. A report that treats every one of those URLs as equally important can produce hundreds of pages of noise without answering the question the business actually needs answered: what should we fix first?

A useful technical SEO audit combines crawl data with Google Search Console, analytics, page-level inspection and platform knowledge. The output should be a prioritised roadmap, not a list of red and orange icons.

What should a technical SEO audit achieve?

The purpose of the audit is not to prove that a website has technical imperfections. Every substantial website has them. The purpose is to determine whether those imperfections create meaningful search risk or opportunity.

• Confirm that important pages can be discovered, crawled, rendered and indexed.
• Identify conflicting technical signals, such as a page being internally linked and included in a sitemap while also carrying a noindex directive.
• Find duplicate or alternative URL versions that make the preferred page unclear.
• Understand how redirects, status codes and discontinued URLs are handled.
• Check whether important products, collections and content are supported by the site architecture and internal linking.
• Assess whether JavaScript, mobile rendering, performance or third-party applications are hiding or delaying important content.
• Check that structured data reflects the visible page and is technically valid.
• Separate critical problems from low-impact housekeeping.
• Give developers and site owners enough evidence to implement and verify the fixes.

What should happen before the audit starts?

A technical audit is more useful when the scope and business context are clear before the first crawl begins. The same crawler output can mean very different things on a 100-page brochure site and a 50,000-URL ecommerce catalogue.

• Confirm the primary domain, CMS or ecommerce platform, countries and languages in scope.
• Ask whether there has been a recent migration, redesign, domain change or major traffic loss.
• Identify the commercially important product, collection, service and content templates.
• Request appropriate Google Search Console and analytics access.
• Confirm whether staging sites, subdomains or international versions are included.
• Define whether implementation, backlink analysis, server logs, migration recovery or security investigation are outside the standard scope.

A well-scoped audit is easier to reproduce and easier for the client to act on. It also reduces the risk of silently expanding a focused technical review into an unlimited investigation of every possible SEO discipline.

The 12 areas a technical SEO audit should normally review

1. Crawlability and discovery

Can search engines reach the pages that matter? The audit should examine robots.txt, crawl paths, internal links, blocked resources and whether important URLs are available through normal crawlable navigation.

For ecommerce sites, pay particular attention to products that are reachable only through internal search, load-more interactions or JavaScript events. Google recommends that products intended for indexing should be reachable through links from categories or other site navigation. For a deeper explanation of discovery, crawling and indexing, see How Does Google Crawl and Index an Ecommerce Website?.

The audit should also look for orphan pages: URLs found in sitemaps, Search Console or analytics that cannot be reached through the normal internal-link structure.

2. Indexability and robots directives

Crawlability and indexability are not the same thing. A page can be crawlable but deliberately excluded from the index with a noindex directive. Equally, blocking a page in robots.txt can prevent Google from seeing a noindex instruction on that page.

Check meta robots directives, X-Robots-Tag headers, password protection and any CMS-level visibility controls. Important pages with accidental noindex directives are high-priority findings, while intentional noindex pages such as account or internal-search URLs may be completely appropriate.

Use Search Console and URL Inspection to validate important examples rather than assuming that a crawler represents Google’s current indexing decision.

3. XML sitemaps and robots.txt

XML sitemaps should reinforce the preferred URL set. A useful audit compares sitemap URLs with crawl data and Search Console rather than simply confirming that a sitemap file exists.

Look for redirected, canonicalised, noindex, blocked or 404 URLs in sitemaps, as well as valuable pages that are missing. Review robots.txt for accidental blocks, obsolete rules and blocked resources required for rendering.

Sitemaps are a discovery signal, not a guarantee of indexing. Their real value in an audit comes from comparing what the site says is important with what Google can actually crawl and index.

4. HTTP status codes and redirects

The audit should review successful 200 responses, permanent redirects, temporary redirects, 404/410 responses, soft 404s, server errors and connection failures.

Internal links that pass through redirects create unnecessary steps. Redirect chains and loops can also complicate crawling and maintenance. For migrated or discontinued pages, the audit should check whether redirects point to the closest relevant replacement instead of indiscriminately sending everything to the homepage.

Google’s current site-move guidance recommends keeping migration redirects for at least a year and updating internal links to point directly to the new URLs.

5. Canonicals and duplicate URL versions

Ecommerce platforms can generate multiple URLs that display the same or substantially similar content through parameters, filters, tracking values, product paths and variants. The audit should identify how the preferred version is signalled. Article 8, What Causes Duplicate Content on Ecommerce Websites?, explores this problem in more depth.

Check canonical tags, redirects, sitemap URLs and internal links together. Google treats a rel=canonical annotation as a strong hint rather than an absolute rule, so conflicting signals can still lead Google to select a different canonical URL. Article 9, What Are Canonical Tags and Why Do They Matter?, covers canonical signals in detail.

Canonical targets should normally be live, indexable, relevant and consistent. Common problems include canonicals pointing to redirects, noindex pages, unrelated products or the wrong regional version.

6. Site architecture and internal linking

A technically crawlable site can still be poorly structured. The audit should assess how easily search engines and users can move from the homepage into departments, collections, products and supporting content.

Review crawl depth, internal inlink counts, breadcrumbs, contextual links, navigation and the relationship between commercial pages and informational content. Important pages should not depend on a sitemap alone for discovery.

The goal is not to enforce a universal click-depth rule. It is to make sure the pages that matter are prominent, consistently linked and positioned within a structure that explains how the catalogue fits together.

7. Pagination, filters, facets and parameters

This is one of the most important ecommerce-specific areas. Filtering and sorting can generate large numbers of URL combinations, while infinite scroll or load-more designs can make later products difficult to discover if there are no crawlable paginated URLs.

The audit should map which parameter combinations are useful search landing pages, which should remain crawlable but non-indexable, and which should not be generated or linked at scale. There is no safe universal rule such as “block all filters”.

Pagination should be tested to confirm that products beyond the first page can be discovered through normal anchor links and unique URLs.

8. Rendering, JavaScript and mobile access

Modern ecommerce themes and applications can inject product grids, navigation, reviews, stock information, content and internal links with JavaScript. The audit should compare raw HTML with rendered output where the site relies heavily on client-side rendering.

Check whether important links are actual anchor elements with href attributes, whether lazy-loaded content can appear without user interaction, and whether essential resources are blocked.

The mobile version deserves particular attention because Google primarily crawls with a smartphone user agent. The important content, metadata, structured data and internal links should remain available on mobile.

9. Performance and Core Web Vitals

Performance testing should go beyond a single Lighthouse score. Review representative page templates, real-user Core Web Vitals data where available, and the underlying causes of poor performance.

Investigate large images, slow server responses, render-blocking resources, heavy JavaScript, third-party applications, fonts, layout shifts and main-thread work. On ecommerce sites, theme features, review tools, tracking scripts and merchandising apps frequently affect performance across entire templates.

Performance findings should be connected to the template and cause. “Improve PageSpeed score” is not a developer-ready recommendation.

10. Structured data and product information

The audit should inventory structured data by template and validate representative examples. For ecommerce this commonly includes Product, ProductGroup, Offer, Organisation and BreadcrumbList markup, depending on the page and implementation.

Check that the markup matches visible page content and that prices, availability, product identifiers and variants are represented consistently. Duplicate schema from themes and applications is also common and should be reviewed.

Passing a validation test does not guarantee a rich result or higher rankings. Structured data helps search engines understand eligible information and can support richer search appearances when Google chooses to show them.

11. Search Console signals, manual actions and security

A technical audit should not ignore Google’s own diagnostic data. Review the Page indexing report, Sitemaps, Core Web Vitals and URL Inspection for representative pages. Where relevant, review Search Console messages and crawl-related trends.

Also confirm the Manual Actions and Security Issues status. A full penalty or malware investigation may sit outside a normal technical audit, but the existence of a manual action or security warning can materially change the diagnosis and should not be missed.

Google distinguishes manual actions from security issues: manual actions concern violations of spam policies, while Security Issues reports cover hacked or harmful behaviour.

12. Migration, international and platform-specific signals

Not every site needs the same final audit section. A recent migration should trigger deeper redirect, sitemap, canonical and URL-mapping checks. International sites may require hreflang and regional-canonical review. Shopify, WooCommerce and other platforms each create characteristic URL and template behaviours.

The audit should adapt to the website rather than force every client through exactly the same checklist. Platform knowledge is valuable because the technically correct recommendation must also be implementable within the client’s CMS, theme and application stack.

What tools are normally used in a technical SEO audit?

No single tool can provide a complete technical diagnosis. The strongest audits combine several data sources so that automated patterns can be checked against what Google sees and what users actually do.

A crawler is essential for scale, but Search Console and manual validation are what stop the report from becoming an automated export.

How should each audit finding be documented?

A finding is useful when a developer or site owner can understand the problem without recreating the entire investigation. Each important item should answer the same questions.

• What is wrong?
• How was it verified?
• How many URLs or templates are affected?
• Why does it matter for search visibility or site operation?
• What should change?
• Who is likely to own the fix?
• How should the fix be tested after implementation?

How should technical SEO audit findings be prioritised?

Not every technical issue deserves immediate development time. Priority should reflect the likely search or business impact, the number and value of pages affected, the confidence in the diagnosis and the implementation effort.

Impact and effort should be kept separate. A difficult critical fix is still critical. Likewise, an easy low-impact change should not automatically jump ahead of a high-impact structural problem just because it is quick to implement.

What should you receive at the end of a technical SEO audit?

The deliverable should make the investigation easier to act on, not harder. For most business and ecommerce audits, three connected outputs work well.

1. Executive technical report

• A concise assessment of the site’s technical condition.
• The most important constraints and opportunities.
• The highest-priority actions in implementation order.
• Scope, methodology, limitations and data ranges.
• Enough explanation for non-technical stakeholders to understand why the work matters.

2. Prioritised findings register

• One row per finding rather than one row per affected URL.
• Priority, impact, effort and confidence.
• Affected templates and example URLs.
• Recommended action and implementation notes.
• Suggested owner, dependencies and validation method.

3. Evidence and walkthrough

• Relevant crawl exports and URL samples.
• Search Console or page-level evidence where it materially supports the finding.
• A walkthrough of the highest-priority problems and implementation order.
• Clear separation between diagnosis and any separately scoped implementation work.

What should a technical SEO audit not be?

• A 100-page export of every crawler warning with no prioritisation.
• A promise that fixing every warning will produce higher rankings.
• A list that treats every noindex, redirect or blocked URL as an error.
• A backlink audit, content-quality review, CRO audit and security investigation disguised as one unlimited technical scope.
• A single PageSpeed score presented as the site’s technical health.
• Recommendations that ignore the CMS, ecommerce platform or development constraints.
• A report that identifies a problem but gives no examples, scale or validation method.

What makes an ecommerce technical SEO audit different?

Ecommerce sites combine search-engine requirements with catalogue logic, stock status, merchandising, navigation, product variants and applications. That creates technical decisions that do not exist on simpler websites.

• Products can sit in several collections and be reachable through several URL paths.
• Filters and sort options can create thousands of parameter combinations.
• Variant handling affects URLs, canonicals and product structured data.
• Sold-out and discontinued products need a policy rather than ad hoc deletion.
• Pagination and infinite scroll determine whether deeper products can be discovered.
• Review, personalisation, search, tracking and merchandising apps can add scripts or duplicate schema.
• Large catalogues make crawl efficiency and consistent internal linking more important.
• International markets can add regional URLs, currencies, hreflang and duplicate-content complexity.

For this reason, an ecommerce audit should group findings by template and behaviour. Fixing one collection-template problem can be more valuable than individually editing hundreds of affected URLs.

Is a technical SEO audit the same as a full SEO audit?

No. A technical audit focuses on the systems that affect discovery, crawling, rendering, indexing, canonicalisation, performance and search understanding. A wider SEO review may also examine keyword targeting, content quality, competitors, backlinks, commercial page relevance and conversion behaviour.

The two can overlap. For example, a collection page may be technically indexable but still fail because it targets the wrong search intent or contains weak product information. The technical audit should identify that the page is technically healthy and avoid pretending that every ranking problem has a technical solution.

If you are unsure which scope is appropriate, start with the business question. If the concern is “why are important pages not being indexed?” a technical audit is a logical starting point. If the concern is “why are we not growing organic revenue?” the answer may require a wider ecommerce SEO review.

How often should a technical SEO audit be carried out?

There is no universal schedule, but technical reviews are particularly useful before and after migrations, redesigns, theme changes, major app changes, international expansion or substantial catalogue restructuring.

For an actively developed ecommerce website, a deeper audit once or twice a year can be sensible, supported by lighter ongoing monitoring in Search Console and regular crawls. A stable small site may need less frequent review. A rapidly changing catalogue or complex multi-market store may need more.

The trigger should be risk and rate of change, not a calendar rule.

A practical technical SEO audit checklist