RankBird
Blog

How to Run a Technical SEO Audit Step by Step

A technical SEO audit is a systematic examination of a website's infrastructure to identify crawling, indexing, performance, and structured-data issues that prevent search engines from ranking pages effectively. Complete audits cover crawler access, Core Web Vitals, canonical logic, schema markup, and internal linking architecture. Executed correctly, the process surfaces fixes that lift organic visibility without requiring new content or link acquisition.


1. Set Up Your Crawling Environment Before Touching Anything

Before running a single tool, define the audit's scope: production domain, staging exclusions, and the user-agent to simulate. Screaming Frog SEO Spider (version 21, released in early 2026) remains the industry-standard desktop crawler; pair it with a cloud crawler such as Sitebulb for JavaScript-heavy sites where client-side rendering hides content from basic HTTP requests.

Connect Google Search Console and Google Analytics 4 to your crawl tool so real-traffic data maps directly onto crawl findings. Export the XML sitemap from Search Console → Sitemaps and load it into your crawler as a starting URL list. This cross-referencing step catches orphan pages—URLs that receive organic clicks but sit outside the site's internal link graph—which a domain-wide crawl alone often misses.

Set crawl rate to respect server limits: a common safe default is 2–5 requests per second for shared hosting, rising to 10–20 for dedicated infrastructure. Log every crawl configuration in a shared audit sheet so the next practitioner can reproduce results exactly.


2. Audit Crawlability and Indexation Signals

Crawlability determines whether Googlebot reaches a page; indexation determines whether the page enters the index. Resolve crawlability issues first—fixing indexation logic on a page Googlebot cannot reach wastes effort.

Inspect robots.txt for accidental Disallow directives blocking CSS, JavaScript, or entire site sections. Google's robots.txt Tester in Search Console flags these directly. Cross-reference the crawl's "Blocked by robots.txt" report against high-value pages in GA4 to surface revenue-affecting misconfigurations.

Review noindex directives next. A common audit finding is paginated category pages carrying noindex tags added during a platform migration and never removed. Screaming Frog's "Directives" filter exports every URL tagged noindex for validation against Search Console's Coverage report. Google's Search Console documentation distinguishes between "Excluded" URLs (intentional) and "Crawled – currently not indexed" URLs (problematic)—a distinction auditors must map to actual page intent.

Check crawl budget signals for large sites (100,000+ URLs). Google's crawl budget documentation identifies duplicate parameters, infinite scroll pagination, and URL facets as the primary crawl budget drains.


3. Evaluate Site Architecture and Internal Linking

Site architecture defines click depth—the number of clicks from the homepage to any given URL. Pages beyond three clicks from the homepage receive significantly less crawl attention and pass less PageRank internally.

A "Crawl Depth" report flags every indexable page sitting at depth 4 or greater. For e-commerce sites, category and subcategory hierarchies frequently create depth problems when filters generate unique URLs. The fix is a hub-and-spoke internal linking model: high-authority hub pages link directly to deep spoke pages, compressing click depth without flattening the information architecture.

Anchor text distribution warrants its own pass. Over-optimised anchors (exact-match commercial phrases repeated identically across dozens of internal links) send unnatural signals; under-descriptive anchors ("click here", "read more") waste contextual relevance. Descriptive, varied anchor text matched to the topic of the destination page is the target state.

Identify orphan pages by comparing crawled URLs against GA4's "Pages and screens" report. Any URL receiving organic sessions but absent from the crawl's internal link list is an orphan—it requires placement on at least two contextually relevant pages.


4. Measure Core Web Vitals and Page Experience Signals

Core Web Vitals—Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS)—are confirmed Google ranking signals introduced with the Page Experience update. As of March 2024, INP officially replaced First Input Delay (FID) as the interactivity metric. Google's Web Vitals documentation defines the current thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1 are the "Good" targets.

Field data from the Chrome User Experience Report (CrUX), accessed via PageSpeed Insights, is the correct data source for the top 20–50 traffic pages. Lab scores from Lighthouse measure a single controlled session; CrUX field data reflects real user conditions across devices, connection speeds, and geographies.

Common LCP offenders include render-blocking third-party scripts, unoptimised hero images lacking loading="eager" and fetchpriority="high" attributes, and server response times (TTFB) exceeding 800 milliseconds. TTFB is the correct first target—front-end optimisation cannot fully compensate for a slow origin server. CLS issues most frequently stem from images without explicit width/height attributes, late-loading web fonts, and dynamically injected banners above the fold.

Document findings by page template (homepage, product page, blog post, category page) rather than individual URLs—template-level fixes scale across hundreds of pages simultaneously.


5. Audit Structured Data, Canonical Tags, and Hreflang

Structured data, canonical tags, and hreflang sit at the intersection of technical SEO and content strategy—errors here cause duplicate content dilution, wrong-locale indexing, and missing rich results.

Structured data: Google's Rich Results Test and the Schema.org validator check JSON-LD markup on product, article, FAQ, and how-to pages. A 2025 study by SEO research firm Zyppy found that pages with valid FAQ schema appeared in AI Overviews at a measurably higher rate than equivalent pages lacking schema—a signal that structured data relevance extends beyond traditional SERPs into answer engines.

Canonical tags: Every duplicate or near-duplicate URL requires a rel="canonical" pointing to the preferred version. Audit for self-referencing canonicals (correct), cross-domain canonicals (intentional syndication), and broken canonical chains (page A canonicals to page B, which canonicals to page C—Googlebot follows only one hop reliably). Screaming Frog's "Canonicals" tab surfaces these chains automatically.

Hreflang: For multilingual sites, validate hreflang with Ahrefs' Site Audit or Sitebulb's hreflang cluster report. The three most common failures are missing return tags (page A points to page B in hreflang but page B does not return-point to page A), incorrect ISO language-country codes (e.g., en_US instead of en-US), and hreflang annotations on noindex pages—which Google ignores, breaking the entire cluster.


6. Compile Findings into a Prioritised Action Plan

Translating raw findings into a sequenced remediation roadmap is the final stage of a site infrastructure review. Not all issues carry equal weight; prioritisation prevents development teams from spending sprint capacity on low-impact fixes.

A 2×2 impact-effort matrix structures this well: high-impact/low-effort fixes (missing canonical tags, robots.txt misconfigurations, render-blocking scripts) ship in sprint 1; high-impact/high-effort fixes (site architecture restructuring, full Core Web Vitals overhaul) enter the roadmap as defined projects; low-impact issues queue for later or are accepted as known debt.

Structure the audit deliverable in three layers:

  1. Executive summary — 3–5 critical issues with estimated organic impact, no more than one page.
  2. Technical findings log — every issue, its location (URL or template), severity (critical/warning/notice), and a linked screenshot or crawl export.
  3. Implementation guide — developer-ready specifications with code examples, not vague recommendations.

A re-crawl schedule of monthly for sites under 50,000 URLs and bi-weekly for larger properties is standard practice. Automated Search Console alerts for coverage drops and Core Web Vitals regressions surface issues between audits, before deployment errors propagate across the site.

Track audit outcomes by comparing organic impressions and clicks (Search Console's Performance report, 90-day windows) before and after each remediation sprint. Named before/after windows—"Pre-audit baseline: January 1–March 31, 2026" versus "Post-remediation: April 1–June 30, 2026"—give stakeholders concrete evidence of the work's impact.


Frequently Asked Questions

Q: How long does a complete technical site audit take? For a site with 10,000–50,000 URLs, a thorough audit covering all six areas above requires 20–40 hours of analyst time, depending on site complexity and the availability of log files. Enterprise properties with 500,000+ URLs can take multiple weeks. Crawl time itself is separate—large-site crawls run overnight.

Q: Which tools are essential for conducting a site health review? The core stack for 2026 audits is Screaming Frog SEO Spider (crawling), Google Search Console (indexation and performance data), PageSpeed Insights with CrUX data (Core Web Vitals), Ahrefs or Semrush Site Audit (backlink and canonicalisation checks), and Google's Rich Results Test (structured data). Log-file analysis tools like Screaming Frog Log File Analyser or Splunk add Googlebot behaviour data unavailable from standard crawlers.

Q: How often should a website undergo a technical SEO review? Sites publishing new content daily or running frequent A/B tests warrant monthly audits. Editorial sites with stable architecture can run quarterly. A full technical review is also mandatory after any platform migration, CMS upgrade, or major template redesign—post-migration audits have a defined 30-day window before ranking changes stabilise and become harder to attribute.

Q: What is crawl budget and does it affect small sites? Crawl budget is the number of URLs Googlebot crawls on a site within a given timeframe, governed by crawl rate limit and crawl demand. Sites under 1,000 URLs with clean architecture rarely face crawl budget constraints—Googlebot indexes them fully within days of a sitemap submission. Google's crawl budget documentation explicitly states that small and medium sites need not prioritise this issue.

Q: How do Core Web Vitals findings translate into specific developer tasks? Each failing metric maps to a defined code-level intervention: LCP failures typically require preloading the hero image (<link rel="preload">) and eliminating render-blocking scripts; INP failures require breaking up long JavaScript tasks (over 50 ms) using scheduler.yield() or web workers; CLS failures require adding explicit dimension attributes to images and reserving space for injected elements via CSS aspect-ratio. Google's Web Vitals documentation links each metric to diagnostic guides with code examples.

Q: Can a technical SEO audit improve AI Overview visibility, not just traditional rankings? Structured data, fast page speed, clear heading hierarchy, and accurate canonical signals all improve the machine-parsability of content—the same properties that AI Overviews and answer engines like Perplexity use when selecting passages to surface. Google has not published a direct correlation study, but the Zyppy research cited above and Google's own Search Central documentation both indicate that well-structured, crawlable, schema-annotated pages earn richer representation across all retrieval surfaces in 2026.


Related articles