freecourses.digital
Lesson progress: 0 of 3 activities done
All lessons in Technical SEO Auditing Lesson 7.7 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

Prioritizing Performance Fixes

Inside this lesson

  • Why not every performance warning deserves a fix
  • How to score fixes by impact and effort
  • Which fixes usually give the biggest wins
  • How to write performance recommendations

Short answer

Prioritize performance fixes by combining four factors: how many important pages share the issue, how far field metrics are from good thresholds, the traffic and revenue of affected templates, and the effort to fix. Start with high-reach, low-effort template fixes like LCP images, server caching, and unused scripts before complex rebuilds.

Lighthouse can list 25 opportunities for one page. Multiply by templates and you have 150 suggestions. Developers can do maybe five this month. Choosing the right five is the real skill.

Four factors

  1. Reach: how many important URLs share the issue? Template issues beat single pages.
  2. Gap: how far is the field metric from “good”? LCP 4.8 s is more urgent than 2.7 s.
  3. Value: traffic, leads, or revenue from affected templates.
  4. Effort: developer time and risk.

Impact vs. effort

Low effortHigh effort
High impactDo first (quick wins)Plan next
Low impactDo when convenientSkip or defer

Common quick wins

  • Resize and convert the hero image, remove lazy loading from it, add fetchpriority="high"
  • Add width and height to images and reserve space for ads
  • Enable page caching, compression, and a CDN
  • Remove unused plugins and Tag Manager tags
  • Defer non-critical scripts

Writing the recommendation

Each performance finding should include the template, the metric and field value, the cause with evidence (Lighthouse diagnostic, LCP element), the specific fix, affected URL count, and how you will verify it (lab now, field after 28 days).

Practice: do first or plan later?

Sort each item into the right group.

  • Lazy-loaded hero on all 900 product pages

  • Rebuild the whole site in a new framework

  • Remove 6 unused Tag Manager tags

  • Shave 0.1 s off a 1.9 s LCP on the privacy page

  • Enable page caching on slow shared hosting

Common mistakes

  • Sorting by Lighthouse savings only. Ignores business value.
  • Recommending rebuilds without evidence.
  • No verification plan. Fixes go unproven.
1. Which fix should usually come first?
2. What is a sensible target?
3. Why include reach in prioritization?

Your action

You have finished Module 7. In Module 8, you will audit JavaScript SEO and rendering.

Key terms

Impact
How much a fix improves users' experience and business results, based on reach and size of the improvement.
Effort
The developer time, cost, and risk a fix requires.
Quick win
A fix with high impact and low effort.
Performance budget
Agreed limits, like maximum image size or script weight, that keep pages fast after fixes.

Questions beginners ask

Should I aim for a Lighthouse score of 100?

No. Aim for passing field Core Web Vitals on important templates. Chasing 100 often wastes developer time.

What are the most common quick wins?

Resizing and converting hero images, removing lazy loading from the LCP image, adding image dimensions, enabling caching and compression, and removing unused plugins and tags.

When is a rebuild justified?

When the theme or platform makes passing impossible and the affected pages drive significant revenue. Document the evidence first.

How do I keep pages fast after fixes?

Set a performance budget and recheck performance in every scheduled crawl.

Related lessons

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