- What is a technical SEO audit?
- Tools you need before you start
- 1. Crawlability and crawl budget
- 2. Indexing issues and indexed pages
- 3. Site architecture and URL structure
- 4. Internal linking
- 5. On-page technical elements
- 6. Duplicate content and canonicalisation
- 7. Broken links and server errors
- 8. Page speed and Core Web Vitals
- 9. Mobile SEO
- 10. Structured data and schema markup
- 11. International SEO and hreflang
- 12. Security and HTTPS
- FAQs
What is a technical SEO audit?
A technical SEO audit is a systematic review of the technical factors that affect how search engines crawl, index, and rank a website. It covers everything from how robots can access your pages to how those pages perform on mobile devices. The purpose is to identify problems that are suppressing organic visibility and prioritise fixes by their potential impact.
Technical SEO sits at the foundation of any organic search programme. You can publish excellent content and earn quality backlinks, but if search engines cannot reliably crawl and index your pages, that investment is wasted. A thorough technical SEO audit checklist ensures you identify the issues that prevent the rest of your SEO work from reaching its potential.
I use this technical SEO checklist as the starting point for every new engagement. It is structured by category rather than by priority, because priority depends on the specific site. A site with severe crawlability problems needs those fixed before anything else. A technically clean site might have its biggest opportunity in internal linking or structured data. Work through each section and score the severity of issues as you find them.
Tools you need before you start
A complete technical SEO audit requires a combination of free tools and at least one crawler. The essential free tools are Google Search Console, Google Analytics 4, and Bing Webmaster Tools. For crawling, Screaming Frog SEO Spider is the industry standard for small to medium sites, and Sitebulb is a strong alternative with a better visualisation of site architecture.
You do not need to pay for every tool in the audit stack. Many of the most critical data points come from Google Search Console, which is free and gives you real-world data from Google's crawling of your site. Screaming Frog has a free tier that crawls up to 500 URLs, which is sufficient for small sites. For larger sites, the paid version at around £200 per year is indispensable.
For more full site audits, tools like Semrush Site Audit and Ahrefs Site Audit automate much of the checklist work and present issues with severity ratings. They are useful for ongoing monitoring but should not replace a manual audit of the most important pages. Automated tools miss context that only a human reviewer can evaluate: whether a noindex directive is intentional, whether a redirect chain was deliberate, whether duplicate content is actually causing a problem given the site's specific architecture.
1. Crawlability and crawl budget
Crawlability refers to how effectively search engine bots can access and navigate your site. Issues here are among the most consequential in SEO because they can prevent otherwise good pages from ever appearing in search results. The crawlability section of your technical SEO audit checklist covers robots.txt, crawl directives, redirect chains, and crawl depth.
Robots.txt audit
The robots.txt file tells crawlers which pages they are and are not allowed to crawl. Errors here can accidentally block Google from crawling important sections of your site. Check the following:
- Robots.txt file exists and is accessible at yourdomain.com/robots.txt
- No accidental disallow rules blocking key content (e.g., Disallow: /)
- CSS and JavaScript files are not blocked (needed for rendering)
- Sitemap URL is referenced in robots.txt
- Crawl-delay directives are not set unnecessarily low for major bots
- No conflicting rules between user-agent groups
A common error I find is a site that was put into maintenance mode during a development period with a blanket Disallow rule, and the rule was never removed after launch. This can cause the entire site to disappear from search results within days of going live. Check robots.txt on any new engagement before doing anything else.
Crawl budget and waste
Crawl budget is the number of pages Googlebot is willing to crawl on your site within a given time period. For most sites under a few thousand pages, crawl budget is not a limiting factor. For larger sites, particularly those with faceted navigation, user-generated content, or URL parameters generating large numbers of near-duplicate pages, crawl budget waste can prevent important pages from being crawled frequently enough to stay indexed.
- Identify URL parameter pages that create duplicate or thin content (block via robots.txt or canonical)
- Check for pagination generating excessive crawlable URLs
- Identify faceted navigation pages that should not be indexed
- Review Google Search Console Coverage report for crawled but not indexed URLs
- Check crawl stats in Google Search Console for unusual patterns in Googlebot activity
- Ensure 404 pages respond with a genuine 404 status (not a soft 404 with a 200 status)
Redirect chains and loops
Each redirect in a chain adds latency and dilutes link equity. Chains of three or more redirects are common on sites that have been through multiple redesigns without cleaning up the redirect map. A Screaming Frog crawl will identify all redirects and show you which are chains versus single-hop redirects.
- No redirect chains longer than two hops
- No redirect loops (A redirects to B, B redirects to A)
- All redirects use 301 (permanent) where appropriate, not 302 (temporary)
- HTTP redirects to HTTPS (not the other way around)
- Non-www redirects to www (or vice versa), consistent canonicalisation
- Old URLs from previous site versions redirect directly to the correct current URL
2. Indexing issues and indexed pages
Indexing issues prevent pages from appearing in search results even when they have been crawled. The most common causes are noindex directives, canonicalisation problems, thin content flags, and manual actions in Google Search Console. Checking your indexed pages against your expected page count is one of the fastest ways to identify whether you have a systemic indexing problem.
Use the Google Search Console Coverage (now called Indexing) report to understand the current indexing status of your site. The report breaks pages into indexed, not indexed, and various subcategories explaining why pages were not indexed. Cross-reference the total indexed page count with a Screaming Frog crawl to identify discrepancies.
- Total indexed pages in Search Console matches expected count from site crawl
- No important pages carry a noindex meta tag or X-Robots-Tag header
- Pages flagged as "Crawled, currently not indexed" are either unimportant or need improvement
- Pages flagged as "Discovered, currently not indexed" are being resolved by improving crawl access
- No manual actions in the Manual Actions report in Search Console
- XML sitemap is submitted and processed without errors in Search Console
- Sitemap contains only canonical, indexable URLs (no redirects, noindex, or 4xx pages)
- URL Inspection tool confirms individual priority pages are indexed
Sitemap audit checklist
XML sitemaps help Google discover and prioritise your pages. A poorly maintained sitemap can include redirected URLs, noindexed pages, or pages that no longer exist, all of which signal sloppiness and waste crawl budget.
- Sitemap validates without errors at yoast.com/tools/xml-sitemap-index or Google Search Console
- No redirected URLs in sitemap (should point to final destination URLs)
- No noindexed pages in sitemap
- No 4xx or 5xx URLs in sitemap
- Sitemap last-modified dates are accurate and not all set to the same historical date
- Sitemap is under 50,000 URLs per file and under 50MB (use sitemap index file if larger)
- Image sitemaps are used if image discovery is important for the site
Automated tools miss context that only humans catch
Automated crawl tools are useful for identifying issues at scale, but they cannot evaluate whether a noindex directive is intentional, whether a redirect chain was deliberate, or whether duplicate content is actually causing a problem. Always combine automated audits with manual review of the most important pages.
3. Site architecture and URL structure
Site architecture affects how efficiently crawlers can navigate your site and how well link equity distributes to important pages. Good architecture puts all important pages within three to four clicks of the homepage, uses a logical URL structure that reflects the site's topic hierarchy, and avoids orphan pages that are not reachable through normal navigation.
Use a site crawler to map your current architecture. Screaming Frog's visualisation and Sitebulb's treemap view both help you see whether your site's depth matches what you intend. Pages buried at five or more clicks from the homepage are at risk of being crawled infrequently and ranking poorly.
- All important pages are reachable within 3–4 clicks from the homepage
- No orphan pages (pages with no internal links pointing to them)
- URL structure is logical, descriptive, and consistent (e.g., /services/seo-audit/, not /page-id=47)
- URLs use hyphens as word separators, not underscores
- No dynamic parameters in URLs for content that should have stable, clean URLs
- Category and subcategory pages exist where appropriate for large content sets
- Homepage links to the most important commercial pages directly or via one level of navigation
4. Internal linking
Internal linking is one of the most underused levers in technical SEO. It controls how link equity flows through your site, signals to Google which pages are most important, and helps crawlers discover new or infrequently visited pages. A poor internal linking structure can leave your most important pages with far less authority than they should have.
Internal linking audit
A Screaming Frog crawl shows you how many internal links each page receives. Cross-reference this with your commercial priority pages. If your most commercially important pages have very few internal links compared to less important pages, you have an internal linking imbalance that is likely suppressing rankings.
- Priority commercial pages receive the most internal links from relevant content
- No pages with zero internal links (orphan pages)
- Anchor text for internal links is descriptive and includes relevant keywords where natural
- Navigation menu links to all top-level category and service pages
- Blog and guide content links to relevant service and category pages
- No links to redirected URLs (update to point to the final destination)
- No broken internal links returning 4xx status codes
- Pagination uses rel="next" and rel="prev" or a single paginated view depending on CMS capabilities
- Footer links are limited to genuinely important pages (excessive footer links dilute equity)
Click depth and link equity
Click depth, also called page depth, measures how many clicks it takes to reach a page from the homepage. Google has indicated that pages deeper in the site structure tend to receive less PageRank. For large sites, this means structuring your internal links so that the highest-priority pages have the shortest click depth and the most internal links pointing to them.
A common internal linking issue I encounter is a site with a strong blog section that never links to the commercial service pages. The blog might rank well for informational queries and accumulate backlinks, but all of that authority stays within the blog section rather than flowing to the pages that drive revenue. Adding contextually relevant links from popular blog posts to commercial pages is often the quickest win available in a technical SEO audit.
5. On-page technical elements
On-page technical elements include title tags, meta descriptions, heading structure, image optimisation, and canonical tags. These are the basic building blocks of a well-optimised page. Errors here are common even on established sites because CMSs make it easy to create duplicate or missing tags at scale without a systematic review.
- Every page has a unique, descriptive title tag (recommended length: 50–60 characters)
- No duplicate title tags across the site
- Title tags include the primary keyword where natural
- Every page has a unique meta description (recommended length: 120–155 characters)
- No pages have missing or auto-generated generic meta descriptions
- Meta descriptions are written to encourage clicks, not just describe content
- Each page has exactly one H1 tag
- H1 tag includes the primary keyword or a close variant
- H2 and H3 tags follow a logical hierarchical structure (no jumping from H1 to H4)
- Headings describe the content that follows, not decorative text
- No heading tags used for styling purposes on non-heading content
- All images have descriptive alt text (not keyword-stuffed, genuinely descriptive)
- Images are compressed appropriately (WebP format preferred for web)
- Images have explicit width and height attributes to prevent layout shift
- Large above-the-fold images are preloaded using rel="preload"
- Images below the fold use lazy loading (loading="lazy" attribute)
- Image file names are descriptive (product-name-colour.webp, not IMG_2047.jpg)
6. Duplicate content and canonicalisation
Duplicate content occurs when the same or substantially similar content is accessible via multiple URLs. It confuses search engines about which version to index and rank, and can dilute the link equity and ranking potential of the canonical version. Common causes include URL parameter variations, HTTP vs HTTPS versions, www vs non-www, and CMS-generated duplicate pages for categories, tags, and author archives.
- All pages have a canonical tag pointing to the preferred URL
- Self-referencing canonicals are implemented on all pages
- Canonicals resolve correctly (do not point to redirected or noindexed URLs)
- Print versions of pages use canonical pointing to the main version
- CMS tag and category archive pages are either canonicalised or noindexed if they contain duplicate content
- Search results pages are blocked from indexing (noindex or robots.txt)
- URL parameters are handled via Google Search Console parameter handling or canonical tags
- No near-duplicate pages targeting the same keyword without differentiated content
- Session ID URLs are blocked from indexing
Canonicalisation errors
Canonical tags are often incorrectly implemented. The three most common errors are: canonical tags pointing to redirected URLs rather than the final destination, canonical tags implemented in the wrong section of the HTML (they must be in the head element), and self-referencing canonicals missing from paginated pages where they are needed to prevent the first page being treated as canonical of all paginated versions.
7. Broken links and server errors
Broken links, also called dead links, are outgoing or internal links that point to pages returning a 4xx or 5xx status code. They create a poor user experience and waste crawl budget by sending bots to non-existent destinations. Server errors return 5xx status codes and indicate server-side problems that prevent pages from loading reliably.
- No internal links returning 404 or 410 status codes
- No external links to pages that return 404 (update to live equivalent or remove)
- 404 page returns a genuine 404 status code (not 200)
- Custom 404 page provides useful navigation to help users find what they were looking for
- No 5xx server errors appearing in site crawl or Search Console
- Server uptime and response times are stable (check Google Search Console Crawl Stats)
- Time to first byte (TTFB) is under 600ms for key pages
Handling 404 pages and gone pages
Not all 404s need to be redirected. If a page was removed because it was low-quality, thin, or no longer relevant, a 404 is appropriate. Pages that were removed but had backlinks pointing to them should be redirected to the most relevant current page, so the link equity is not permanently lost. Use Ahrefs or Semrush to identify which 404 pages have backlinks and prioritise those for redirects.
Pages that have been permanently removed with no relevant redirect destination should return a 410 Gone status rather than 404. This tells Google the page is intentionally gone and helps it remove it from the index faster than a standard 404.
8. Page speed and Core Web Vitals
Page speed and Core Web Vitals are part of Google's Page Experience ranking signals. Google uses real user data from the Chrome User Experience Report to assess whether pages deliver a good user experience. Failing Core Web Vitals thresholds does not cause dramatic ranking drops but contributes to a weaker page experience signal that can affect rankings in competitive positions.
- Google Search Console Core Web Vitals report shows no "Poor" URLs
- LCP (Largest Contentful Paint) is under 2.5 seconds at the 75th percentile
- INP (Interaction to Next Paint) is under 200 milliseconds at the 75th percentile
- CLS (Cumulative Layout Shift) is 0.1 or below at the 75th percentile
- LCP element is preloaded using rel="preload" in the HTML head
- All images and iframes have explicit width and height attributes
- No render-blocking scripts in the document head without async or defer attributes
- JavaScript bundle size is audited and optimised (unused code removed)
For a full technical breakdown of how to diagnose and fix Core Web Vitals issues, see my Core Web Vitals guide.
Additional page speed items
- Browser caching is configured (Cache-Control headers set appropriately)
- Gzip or Brotli compression is enabled on the server
- Images are served in WebP or AVIF format where browser support allows
- A content delivery network (CDN) is used to serve assets from edge locations
- CSS is minified and critical CSS is inlined where needed
- Third-party scripts (analytics, chat, ads) are loaded with defer or after user interaction
- Font files are preloaded and served from the same domain or a preconnect-enabled origin
9. Mobile SEO
Google uses mobile-first indexing for all sites, which means the mobile version of your site is the primary version Google crawls and indexes. If your mobile and desktop sites serve different content, the mobile version must contain all of the content, structured data, and links that you want indexed. Any mobile-specific issues will affect rankings for desktop users too.
- Site passes Google's Mobile Usability test in Search Console (no errors)
- Responsive design is implemented (same HTML served to all devices, layout adapts via CSS)
- No mobile-specific content hiding important text or links that desktop shows
- Tap targets (buttons, links) are at least 48px in size and spaced appropriately
- No intrusive interstitials that cover the main content on mobile immediately on load
- Font sizes are legible without zooming (minimum 16px for body text)
- Viewport meta tag is set correctly: content="width=device-width, initial-scale=1"
- Structured data implemented on both mobile and desktop versions
10. Structured data and schema markup
Structured data uses schema.org vocabulary to give search engines explicit information about the content on your pages. Correctly implemented schema markup can unlock rich results in search (star ratings, FAQ panels, sitelinks search boxes, and more), which improve click-through rates. Incorrect implementation can trigger manual actions or rich result disqualification.
- Schema markup is validated in Google's Rich Results Test with no errors
- Organisation schema is implemented on the homepage with name, logo, URL, and contact information
- Article or BlogPosting schema is implemented on all blog posts
- FAQ schema is implemented on pages with question and answer content
- Local Business schema is implemented if the site represents a physical location
- Review and AggregateRating schema is implemented on product or service pages that have genuine reviews
- BreadcrumbList schema matches the actual breadcrumb navigation on each page
- No schema markup is implemented for content that does not actually appear on the page (this violates Google's guidelines)
- Structured data is tested after any CMS updates that might affect how it renders
11. International SEO and hreflang
For sites targeting multiple languages or regions, hreflang tags tell Google which version of a page is intended for which language and country combination. Incorrectly implemented hreflang is one of the most common technical SEO issues on multinational sites and can result in the wrong language version appearing in search results for the wrong market.
This section only applies to sites with international deployments. If your site targets only UK English speakers, skip to the next section.
- Hreflang tags are implemented in the HTML head or HTTP headers (not only in the sitemap)
- Every hreflang tag has a reciprocal tag on the referenced alternate page
- An x-default hreflang tag is set to indicate the fallback version
- Hreflang values use correct ISO language and region codes (e.g., en-GB, fr-FR, not English or French)
- No hreflang tags point to redirected or noindexed pages
- URL structure clearly differentiates language/region versions (subdirectories like /en/, /de/, or ccTLDs)
- Currency, date formats, and phone numbers are localised for each target region
- Google Search Console properties are set up separately for each subdomain or ccTLD
12. Security and HTTPS
HTTPS is a confirmed Google ranking signal and a basic requirement for any modern website. Browser security warnings on non-HTTPS pages create a significant trust barrier that deters visitors and signals poor maintenance to search engines. Beyond HTTPS, security headers improve protection against common web attacks and are increasingly checked by technical SEO tools as part of a technical audit.
- Site is fully served over HTTPS with no mixed content warnings
- SSL certificate is valid, not expired, and covers all subdomains used by the site
- HTTP to HTTPS redirect is in place (301 redirect)
- Strict-Transport-Security (HSTS) header is implemented
- Content-Security-Policy header is configured where feasible
- X-Content-Type-Options: nosniff header is set
- X-Frame-Options header is set to prevent clickjacking
- Site is listed on Google's Safe Browsing tool with no warnings
- No malware warnings or spam penalties in Google Search Console
After the audit: prioritising what to fix
A thorough technical SEO audit will almost always surface more issues than you can fix at once. The right prioritisation framework weighs impact (how much will fixing this improve organic visibility or traffic) against effort (how much developer or resource time does this require).
Crawlability and indexing issues are always priority one, because they prevent everything else from working. Broken links and server errors causing 5xx responses are priority two. Duplicate content and canonicalisation issues are priority three on most sites. Internal linking improvements and structured data typically fall later in the priority list unless they are causing specific measurable problems.
Document every issue you find, record the evidence (screenshot, URL, tool output), and assign an estimated impact and effort score. Present findings with a recommended fix order rather than a flat list. This makes it easier to get developer resource allocated and track progress over time.
Key takeaways
- A technical SEO audit covers crawlability, indexation, site architecture, internal linking, on-page elements, duplicate content, and page speed.
- Essential tools: Google Search Console (free), Screaming Frog, Ahrefs or Semrush, and PageSpeed Insights.
- Priority depends on the specific site. Severe crawlability problems must be fixed before anything else can be effective.
- Combine automated crawl tools with manual review. Automated tools miss context about intentional directives and site-specific architecture.
- Score issues by severity and prioritise fixes by potential impact rather than working through the checklist alphabetically.
Frequently asked questions
A technical SEO audit should check crawlability (robots.txt, redirect chains, crawl depth), indexing status (noindex directives, sitemap health, Coverage report in Search Console), site architecture (URL structure, internal linking, orphan pages), on-page elements (title tags, meta descriptions, heading structure), duplicate content and canonicalisation, broken links and server errors, page speed and Core Web Vitals, mobile usability, structured data implementation, and HTTPS and security headers. The priority order depends on which issues have the most material impact on the specific site.
A technical SEO checklist is a structured list of items to review when auditing the technical health of a website. It covers all the technical factors that affect how search engines crawl, index, and rank web pages. A good technical SEO checklist includes sections for crawlability, indexation, site architecture, internal linking, on-page elements, duplicate content, broken links, page speed, mobile SEO, structured data, and security. This page contains a full technical SEO audit checklist organised by category, free to use.
A technical SEO audit is a systematic evaluation of a website's technical infrastructure to identify issues that are preventing or limiting its visibility in organic search. Unlike a content audit or link audit, a technical SEO audit focuses on factors like how crawlers access pages, how pages are indexed, how the site architecture distributes link equity, and how the pages perform for users. It is typically the first step in any new SEO engagement and the foundation for all other SEO work.
The four pillars of SEO are technical SEO (site structure, crawlability, indexation, page speed), on-page SEO (content quality, keyword optimisation, page structure, meta data), off-page SEO (backlinks, brand mentions, external authority), and user experience (Core Web Vitals, mobile usability, page design and navigation). Technical SEO is foundational because it enables the other three pillars to function. A technically broken site limits what on-page and off-page work can achieve, regardless of how good the content and link profile are.
Need a full technical SEO audit?
I conduct detailed technical SEO audits that identify the specific issues holding your site back, with prioritised fix recommendations your development team can act on.
Get In Touch