What a technical audit is for

Content and links win rankings, but technical problems can prevent them from counting. A technical audit looks for barriers: pages that cannot be found, crawled or indexed, content that does not render, signals that conflict, and slow experiences. It should end with prioritized tickets, not just a long report.

Tools

  • A crawler to emulate how search engines traverse your site.
  • Google Search Console for coverage, indexing, crawl stats, performance and Core Web Vitals.
  • Server logs to see what bots actually request.
  • Browser developer tools and the URL Inspection tool for rendering.
  • Lighthouse and field data for performance.
  • Structured data validators.
  • Analytics for landing page performance.

Checklist

1. Crawlability

  • robots.txt exists, is valid and does not block important sections or resources such as CSS and JavaScript needed for rendering.
  • Important pages are linked with crawlable anchor links, not only scripts.
  • No accidental blocks from login walls, firewalls or bot protection against legitimate crawlers.
  • Crawl budget is not wasted on parameters, infinite calendars, session IDs or faceted combinations.
  • XML sitemaps list canonical, indexable URLs only, are updated automatically and are referenced in robots.txt or submitted to Search Console.

2. Indexation

  • Compare indexed pages with the pages you want indexed.
  • Check for noindex tags or headers on pages that should rank.
  • Identify “crawled, not indexed” and “discovered, not indexed” patterns and their causes, such as thin or duplicate content.
  • Find indexed pages that should not be, such as internal search results or staging copies.
  • Verify that x-robots-tag headers are correct on files such as PDFs.

3. Status codes and redirects

  • Important pages return 200.
  • Deleted pages return 404 or 410, not soft 404s.
  • Redirects use 301 for permanent moves, with no chains or loops.
  • Internal links point to final URLs, not redirecting ones.
  • Server errors in the 5xx range are investigated.

4. Canonicals and duplicates

  • Each indexable page has a self-referencing canonical or a deliberate alternative.
  • Canonicals are consistent with sitemaps and internal links.
  • Variants of the domain, such as http, https, www and non-www, redirect to one version.
  • Trailing slash and case variations are normalized.
  • Parameter URLs and pagination follow a defined policy.
  • Near-duplicate content is consolidated.

5. Rendering and JavaScript

  • Critical content, links and metadata appear in rendered HTML. Compare the raw and rendered versions.
  • Server-side rendering or pre-rendering for important content where client-side rendering causes issues.
  • Lazy-loaded content is discoverable.
  • No reliance on user interaction to reveal indexable content.
  • URL changes use real URLs, not fragment-only routing.

6. Site architecture and internal links

  • Important pages are within a few clicks of the home page.
  • Navigation, breadcrumbs and contextual links reflect hierarchy.
  • Orphan pages are identified and either linked or removed.
  • Anchor text is descriptive.
  • Pagination is crawlable.

7. On-page technical elements

  • Unique, appropriately sized titles and meta descriptions.
  • One clear H1 and logical heading structure.
  • Image alt text, and descriptive file names.
  • Language and hreflang tags are correct and reciprocal on international sites.

8. Mobile and page experience

  • Responsive design with the same content and markup on mobile and desktop.
  • Core Web Vitals pass for key templates in field data.
  • No intrusive interstitials.
  • Accessible tap targets and readable text.

9. Structured data

  • Valid markup for relevant types, such as organization, breadcrumb, product, article and FAQ.
  • Markup matches visible content.
  • No duplicate or conflicting blocks from themes and plugins.

10. Security and infrastructure

  • HTTPS everywhere, with a valid certificate and no mixed content.
  • HSTS and other security headers where appropriate.
  • Reasonable server response times and uptime.
  • CDN and caching configured so crawlers receive the same content as users.
  • Staging environments protected from indexing.

11. Log analysis

  • Which sections bots crawl most, and which they ignore.
  • Crawl of error pages and redirects.
  • Frequency of crawling for key pages.
  • Differences between claimed and verified bots.

Prioritize

Score each issue by impact on organic visibility or revenue, the number of affected pages and effort to fix. Group into quick wins, major projects and monitoring items. Write tickets with the problem, examples, expected behavior and how to verify the fix.

Prevent regressions

Add SEO checks to your deployment process: automated tests for status codes, canonicals, robots rules and metadata, a pre-launch crawl and alerts for sudden changes in indexation or errors.

FAQ

How often should I run a technical SEO audit?

A full audit annually, with lighter monthly or continuous monitoring, and an extra check before and after major releases or migrations.

What should I fix first?

Issues that block crawling or indexing of important pages, then redirect and canonical problems, then performance and enhancements.

Is JavaScript bad for SEO?

Not inherently, but client-side rendering adds risk. Make sure critical content and links are rendered reliably, and test using search engine tools.

Do I need log file analysis?

It is valuable on larger sites, where crawl efficiency matters. Smaller sites can start with Search Console crawl stats.

TURN INSIGHT INTO ACTION

Let’s talk about your next step.

Share your workflow, your current systems and what you want to improve. We’ll help shape a practical way forward.

Discuss your project ↗