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

Writing Developer-Ready Recommendations

Inside this lesson

  • Why vague recommendations stall
  • The parts of a developer-ready recommendation
  • How to write acceptance criteria
  • How to avoid prescribing the wrong technical solution

Short answer

A developer-ready recommendation states the current behavior, the expected behavior, where it applies, why it matters, and how to confirm it is done. Write it like a ticket: specific URLs or templates, exact tags or status codes expected, acceptance criteria, and test steps. Describe the required outcome clearly, and let developers choose the implementation when several approaches work.

“Improve canonicalization.” A developer reads that and has no idea what to change, where, or when it is finished. It sits in the backlog for months. The same issue written as a clear ticket gets done in a sprint.

The template

ID and title: CAN-02 Room pages canonical to HTTP non-www URLs Current behavior: 48 room pages output <link rel="canonical" href="http://example.ph/rooms/{slug}">. Expected behavior: Each room page outputs a self-referencing canonical: https://www.example.ph/rooms/{slug}/. Scope: Room template (48 URLs, list attached). Why it matters: Google is choosing HTTP duplicates as canonical, splitting signals for pages that drive bookings. Acceptance criteria:

  1. All 48 URLs return the expected canonical in raw and rendered HTML.
  2. No other template’s canonical changes. How to test: View source on 3 sample URLs, run list crawl of all 48, check URL Inspection on 2. Suggested approach: Canonical is set in the theme’s header. Use the site URL setting instead of the hardcoded host.

Writing tips

  • One ticket per finding or root cause.
  • Use exact values: status codes, tag markup, URL formats.
  • Put the “why” in one or two sentences.
  • Attach evidence and URL lists.
  • Mark suggested approaches as suggestions.

Practice: developer-ready or not?

Sort each item into the right group.

  • Fix redirects

  • All http:// URLs must 301 to https://www in one hop; test with list crawl of attached URLs

  • Make the site faster

  • Remove loading="lazy" from the hero image on product template; LCP image must load with fetchpriority="high"

  • Optimize schema

Common mistakes

  • No acceptance criteria, so “done” is unclear.
  • Bundling ten issues in one ticket.
  • Dictating code for a platform you do not know.
1. What defines when a fix is done?
2. Which states expected behavior best?
3. How many issues per ticket?

Your action

Next, you will map issues to business and search impact.

Key terms

Current behavior
What the site does now, shown with evidence.
Expected behavior
What the site should do after the fix, stated precisely.
Acceptance criteria
Testable conditions that must be true for the fix to be considered done.
User story format
A ticket style such as 'As a search engine, I need X so that Y,' used by some development teams.

Questions beginners ask

Should I tell developers how to code the fix?

Describe the outcome precisely. Suggest an approach when you know the platform, but leave room for their judgment.

How detailed should acceptance criteria be?

Detailed enough to test without asking you, for example 'All /rooms/ URLs return a self-referencing HTTPS www canonical with trailing slash.'

Should one ticket hold many issues?

No. One ticket per finding or root cause keeps work trackable.

What about SEO jargon?

Use precise technical terms like status codes and tags, but skip marketing language and explain why it matters in one sentence.

Related lessons

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