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

Testing Website Changes Before Deployment

What we will go through

  • Why pre-deployment SEO testing prevents most regressions
  • How to crawl a protected staging site
  • How to compare staging with production
  • A pre-launch SEO QA checklist

Short answer

Test SEO changes on a password-protected staging site before release. Crawl staging with authentication, compare it with a production crawl using URL mapping, and check status codes, redirects, canonicals, robots directives, titles, rendering, and structured data. Confirm staging-only settings, like noindex or blocked robots.txt, will not reach production, then sign off.

In Lesson 1.3, a clinic lost its pages for five days because staging’s “discourage search engines” setting went live. Ten minutes of pre-deployment testing would have caught it. This lesson builds that habit into every release.

Protect staging properly

  • Password protection (HTTP authentication), not just robots.txt.
  • Noindex on staging is fine, as long as it is configured to never deploy to production.

Crawl staging safely

  1. Add staging login details in your crawler’s authentication settings.
  2. Load your saved configuration.
  3. Use URL mapping in compare mode to match staging.example.ph to www.example.ph.
  4. Compare staging against the latest production crawl.

Pre-launch SEO checklist

  • No unexpected status code changes or new 404s
  • Redirects for any changed URLs, one hop to the right destination
  • Canonicals point to production URLs, not staging
  • Meta robots and robots.txt will be production versions
  • Titles, descriptions, H1s unchanged unless planned
  • Internal links do not point to staging hosts
  • Content and links render correctly with JavaScript
  • Structured data valid and unchanged unless planned
  • Core Web Vitals lab tests not worse
  • Analytics and Search Console verification tags present

Practice: catch before launch?

Sort each item into the right group.

  • Canonicals point to staging.example.ph

  • Planned title changes on 5 pages

  • Production robots.txt would be Disallow: /

  • Redirects map old URLs to correct new ones in one hop

  • Analytics tag missing from new template

Common mistakes

  • robots.txt-only staging protection.
  • Staging settings deployed to production.
  • No SEO step in the release process.
1. Best way to protect staging?
2. What does URL mapping do?
3. Canonicals on staging point to staging URLs. Risk at launch?

Your action

Next, you will confirm fixes with Search Console and other evidence.

Key terms

Staging site
A private copy of the website used to test changes before they go live.
Authenticated crawl
A crawl that logs in with a username and password to access protected staging.
URL mapping
Rewriting staging URLs to production URLs so crawls can be compared.
SEO sign-off
An approval step confirming SEO checks passed before deployment.

Questions beginners ask

Should staging be blocked with robots.txt?

Use password protection instead. Robots.txt does not stop indexing of linked staging URLs, and blocked rules often get copied to production.

What if there is no staging site?

Test on a single page or section first, crawl immediately after release, and keep a rollback plan ready.

Can I test JavaScript changes on staging?

Yes. Crawl with rendering enabled. URL Inspection cannot reach password-protected pages, so use your crawler and Chrome DevTools.

Who should own SEO sign-off?

The SEO lead or auditor, added as a required step in the release process for templates, migrations, and plugin updates.

Related lessons

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