freecourses.digital
Lesson progress: 0 of 3 activities done
All lessons in Technical SEO Auditing Lesson 7.2 of 84

Module 1: Introduction to Technical SEO Auditing

  1. 1.1What Is a Technical SEO Audit?
  2. 1.2Technical SEO Audit vs. General SEO Audit
  3. 1.3When Should You Audit a Website?
  4. 1.4Types of Technical SEO Issues
  5. 1.5Defining Audit Scope and Objectives

Module 2: Website Crawling and URL Discovery

  1. 2.1How SEO Crawlers Discover URLs
  2. 2.2Configuring a Website Crawl
  3. 2.3Crawl Scope, Limits, and Exclusions
  4. 2.4Internal Links and Crawl Depth
  5. 2.5Orphan Pages and URL Discovery
  6. 2.6Crawl Data vs. Search Engine Data
  7. 2.7Identifying Crawl Coverage Gaps

Module 3: HTTP Status Codes and Redirect Auditing

  1. 3.1Understanding HTTP Status Codes
  2. 3.2Finding 4xx Errors and Broken Links
  3. 3.3Identifying 5xx Server Errors
  4. 3.4Redirect Chains and Redirect Loops
  5. 3.5Internal Links to Redirected URLs
  6. 3.6301 vs. 302 Redirects
  7. 3.7Auditing 404 Pages and Soft 404s

Module 4: Crawlability and Indexability Auditing

  1. 4.1Crawling vs. Indexing
  2. 4.2Robots.txt Audit
  3. 4.3Meta Robots and X-Robots-Tag
  4. 4.4Noindex and Canonical Conflicts
  5. 4.5XML Sitemap Validation
  6. 4.6Canonical URL Auditing
  7. 4.7Identifying Indexability Conflicts
  8. 4.8Comparing Crawl Data with Google Search Console

Module 5: URL Structure and Duplicate Content Issues

  1. 5.1URL Structure and Normalization
  2. 5.2Duplicate URLs and Duplicate Pages
  3. 5.3HTTP vs. HTTPS and Hostname Variations
  4. 5.4Trailing Slashes and URL Parameters
  5. 5.5Pagination and Faceted Navigation
  6. 5.6Canonicalization Strategies
  7. 5.7Internal Linking to Preferred URLs

Module 6: Technical On-Page Auditing

  1. 6.1Missing and Duplicate Title Tags
  2. 6.2Missing and Duplicate Meta Descriptions
  3. 6.3Missing, Duplicate, and Multiple H1 Headings
  4. 6.4Heading Hierarchy and HTML Structure
  5. 6.5Missing Image Alt Attributes
  6. 6.6Internal Link and Anchor Text Issues
  7. 6.7Empty, Thin, and Near-Duplicate Pages
  8. 6.8Auditing HTML Metadata at Scale

Module 7: Website Performance and Core Web Vitals

  1. 7.1Core Web Vitals: LCP, INP, and CLS
  2. 7.2Lab Data vs. Field Data
  3. 7.3Identifying Slow Pages
  4. 7.4Image and Resource Optimization Opportunities
  5. 7.5JavaScript and CSS Performance
  6. 7.6Mobile Usability and Responsive Rendering
  7. 7.7Prioritizing Performance Fixes

Module 8: JavaScript SEO and Rendering

  1. 8.1How Search Engines Process JavaScript
  2. 8.2HTML Source vs. Rendered HTML
  3. 8.3Client-Side vs. Server-Side Rendering
  4. 8.4JavaScript-Generated Content and Links
  5. 8.5Rendering Failures and Missing Content
  6. 8.6Lazy Loading and Crawl Accessibility
  7. 8.7Diagnosing JavaScript SEO Problems

Module 9: Structured Data and Schema Auditing

  1. 9.1Structured Data and Schema.org Basics
  2. 9.2JSON-LD and Structured Data Formats
  3. 9.3Finding Structured Data Across a Website
  4. 9.4Detecting Invalid or Incomplete Markup
  5. 9.5Schema Validation and Rich Result Eligibility
  6. 9.6Conflicting or Duplicate Structured Data
  7. 9.7Prioritizing Schema Fixes

Module 10: Analyzing Audit Data and Prioritizing Issues

  1. 10.1Reading Crawl Reports and Exports
  2. 10.2Grouping URLs by Issue Type
  3. 10.3Identifying Root Causes vs. Symptoms
  4. 10.4Evaluating Severity, Impact, and Effort
  5. 10.5Separating Sitewide and Isolated Issues
  6. 10.6Identifying False Positives
  7. 10.7Building an Actionable Issue Register

Module 11: Technical SEO Audit Reporting

  1. 11.1Structuring a Technical SEO Audit Report
  2. 11.2Documenting Evidence and Affected URLs
  3. 11.3Writing Developer-Ready Recommendations
  4. 11.4Mapping Issues to Business and Search Impact
  5. 11.5Creating a Prioritized Remediation Roadmap
  6. 11.6Presenting Findings to Stakeholders
  7. 11.7Tracking Fixes and Ownership

Module 12: Fix Verification and Technical QA

  1. 12.1Re-Crawling After Fixes
  2. 12.2Comparing Before-and-After Crawl Results
  3. 12.3Verifying Redirects, Canonicals, and Indexability
  4. 12.4Detecting Regressions and Newly Introduced Issues
  5. 12.5Testing Website Changes Before Deployment
  6. 12.6Confirming Fixes with Search Console and Other Evidence
  7. 12.7Closing Audit Findings and Recording Results

Lab Data vs. Field Data

Covered here

  • What lab data and field data are
  • Where each appears in PageSpeed Insights and Search Console
  • Why the two often disagree
  • How to use each in an audit

Short answer

Field data comes from real Chrome users through the Chrome UX Report and shows how pages actually perform over 28 days. Lab data comes from a single simulated test, such as Lighthouse, under fixed conditions. Use field data to judge whether pages pass Core Web Vitals, and lab data to diagnose causes and test fixes.

A client says, “Our PageSpeed score is 38! We are failing!” But Search Console shows every URL passing Core Web Vitals. Another client scores 92 in Lighthouse, yet real users fail LCP. Both are confused because they are mixing two kinds of data.

Field data: what real users experience

  • Collected from real Chrome visits through CrUX
  • Rolling 28-day window, judged at the 75th percentile
  • Shown in Search Console’s Core Web Vitals report and the top of PageSpeed Insights (“Discover what your real users are experiencing”)
  • This is what Google uses for page experience

Lab data: a controlled test

  • One simulated visit, usually a mid-range phone on a throttled network
  • From Lighthouse, PageSpeed Insights (lower section), Chrome DevTools, or WebPageTest
  • Instant results, repeatable, with detailed diagnostics
  • Not used for rankings

How to use both

  1. Judge with field data: which templates fail which metric on mobile?
  2. Diagnose with lab data: run Lighthouse on sample URLs from failing groups and read the opportunities and diagnostics.
  3. Verify with both: lab results confirm a fix immediately, field data confirms it about four weeks later.

Practice: lab or field?

Sort each item into the right group.

  • Search Console Core Web Vitals report

  • Lighthouse score of 54

  • CrUX 75th percentile LCP of 3.1 s

  • Chrome DevTools Performance panel trace

  • WebPageTest run from Singapore

Common mistakes

  • Reporting the Lighthouse score as the main KPI.
  • Expecting field data to change the day after a fix.
  • Ignoring missing field data. Low-traffic pages need lab testing and origin data.
1. Which data does Google use for page experience?
2. Lab data is best for...
3. How long until CrUX fully reflects a fix?

Your action

Next, you will identify slow pages and templates across the whole site.

Key terms

Field data
Performance measured from real user visits, also called real user monitoring (RUM).
CrUX (Chrome UX Report)
Google's public dataset of real Chrome user experience, used in Search Console and PageSpeed Insights.
Lab data
Performance measured in a controlled test with a set device, network, and location.
Lighthouse performance score
A 0 to 100 lab score. It is not used by Google for rankings.

Questions beginners ask

Does the Lighthouse score affect rankings?

No. Google uses field Core Web Vitals. The Lighthouse score is a diagnostic guide.

Why does PageSpeed Insights show no field data?

The URL or site does not have enough Chrome traffic in CrUX. Use origin-level data, your own RUM, or lab tests instead.

Why does lab LCP differ from field LCP?

Real users have different devices, networks, caches, and locations. Lab tests use one fixed setup.

How long until field data reflects a fix?

CrUX uses a rolling 28-day window, so expect about four weeks for full impact.

Related lessons

Want someone to handle SEO for your business while you learn? The team at Remar Digital can help.