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

Client-Side vs. Server-Side Rendering

What we will go through

  • How client-side and server-side rendering work
  • Where static generation and hydration fit
  • How to tell which method a site uses
  • Why dynamic rendering is now a workaround

Short answer

Client-side rendering sends a mostly empty HTML page and builds content in the browser with JavaScript. Server-side rendering and static generation send complete HTML from the server, then hydrate it for interactivity. For SEO, server-rendered or static HTML is safer because content and links are visible immediately to every crawler.

Think of a restaurant. With client-side rendering, you get the ingredients and a recipe, and you cook at your table. With server-side rendering, the kitchen cooks and serves the finished dish. With static generation, the dish was prepared earlier and is ready the moment you order. Google can cook, but it prefers being served.

The methods

MethodWhat the HTML containsSEO risk
CSREmpty shell, content built by JSHigher: depends on rendering
SSRFull content per requestLow
SSGFull content, prebuiltLow
HybridMix per routeVaries, check each template

Most modern frameworks hydrate SSR or SSG pages so they become interactive after loading.

How to identify the method

  1. View Source: is the main content there? Yes means SSR or SSG. A near-empty <div id="root"> means CSR.
  2. Disable JavaScript in DevTools and reload. What remains is the raw experience.
  3. Check framework signs: __NEXT_DATA__ (Next.js), data-reactroot, ng-version, Wappalyzer extension.
  4. Check per template: product pages may be SSR while filters or reviews are CSR.

Dynamic rendering

Serving pre-rendered HTML only to bots was once common. Google now treats it as a workaround, not a long-term solution. In audits, recommend SSR or static generation for important templates.

Practice: which rendering method?

Sort each item into the right group.

  • View Source shows only <div id="app"></div>

  • Full product text visible with JavaScript disabled

  • Blog built into HTML files at deploy time

  • Page goes blank when JavaScript is turned off

Common mistakes

  • Assuming one method for the whole site. Check per template.
  • Recommending dynamic rendering as the fix.
  • Recommending a full rebuild when only one template needs SSR.
1. View Source shows only an empty root div. Which method?
2. Why is SSR safer for SEO?
3. How does Google view dynamic rendering today?

Your action

Next, you will check JavaScript-generated content and links.

Key terms

Client-side rendering (CSR)
The browser downloads JavaScript that builds the page content.
Server-side rendering (SSR)
The server builds the full HTML for each request before sending it.
Static site generation (SSG)
Pages are built into HTML files ahead of time and served as is.
Hydration
JavaScript attaching interactivity to server-rendered HTML in the browser.

Questions beginners ask

Can a CSR site rank well?

Yes, if rendering works reliably. But it depends on Google's rendering, is slower to index, and is weaker for non-rendering crawlers.

What is dynamic rendering?

Serving pre-rendered HTML to bots and JavaScript to users. Google now calls it a workaround and recommends SSR or static generation instead.

Which frameworks support SSR?

Next.js, Nuxt, SvelteKit, Remix, Astro, and Angular Universal, among others.

Does WordPress need this?

Standard WordPress is server rendered. Headless WordPress with a JavaScript front end needs checking.

Related lessons

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