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

Identifying Indexability Conflicts

What we will go through

  • The signals that decide whether a URL is indexable
  • How to build an indexability matrix
  • How to spot pages whose signals disagree
  • How to decide the intended state for each URL group

Short answer

An indexability conflict happens when a URL's signals disagree, such as a page linked in the menu and sitemap but carrying noindex, or a canonical pointing to a redirect. Build a matrix of status code, robots.txt, meta robots, canonical, sitemap presence, and internal links for each URL, then decide one intended state per page group.

So far in this module, you checked each signal on its own. Real problems usually show up when signals are compared. This lesson brings them together.

The six signals

For each URL, collect:

  1. Status code (Module 3)
  2. Robots.txt allowed or blocked
  3. Meta robots or X-Robots-Tag index or noindex
  4. Canonical self, other URL, or missing
  5. In XML sitemap yes or no
  6. Internal inlinks count and placement

The indexability matrix

Page groupStatusRobotsMetaCanonicalSitemapInlinksConflict?
Products200AllowedindexselfYesManyNo
Filter URLs200Allowedindexclean URLYesManySitemap lists canonicalized URLs
Branch pages200AllowednoindexselfYesMenuNoindex on linked, listed pages
Old promos301Blockedn/an/aYesFooterRedirected, blocked, still listed and linked

Every row where signals point in different directions is a conflict.

Decide one intended state per group

  • Index: 200, crawlable, index, self-canonical, in sitemap, well linked.
  • Consolidate: canonical or redirect to the preferred URL, out of the sitemap, internal links updated.
  • Hide: noindex, crawlable, out of the sitemap, few links.
  • Remove: 404 or 410, links removed, out of the sitemap.

Then list what must change for each group to match its state.

Practice: what is the intended state?

Sort each item into the right group.

  • Main service pages

  • ?utm_source= tracking duplicates

  • Thank-you pages

  • HTTP versions of pages

  • Expired test pages

  • Location pages for each branch

Common mistakes

  • Checking signals one at a time only. Conflicts appear between them.
  • Deciding per URL instead of per group.
  • No agreed intended state. Developers cannot fix “it depends.”
1. A page is in the sitemap and main menu but has noindex. What is this?
2. Why decide intended states per page group?
3. Which signals fit the 'Consolidate' state?

Your action

Next, you will compare your crawl with Google Search Console to confirm what Google actually did.

Key terms

Indexable URL
A URL that returns 200, is crawlable, has no noindex, and has a self-referencing or no canonical.
Indexability matrix
A table listing each URL's indexing signals side by side so contradictions stand out.
Intended state
The decision for a URL or group: index, consolidate, hide, or remove.
Page group
URLs that share a template or pattern, such as all product pages or all filter URLs.

Questions beginners ask

What is the quickest way to see indexability in a crawl?

Most crawlers have an Indexability column showing Indexable or Non-Indexable plus the reason. Start there.

Why work by page group instead of URL?

Signals come from templates, so groups share the same conflicts. Deciding per group creates fixes developers can apply once.

Are internal links part of indexability?

They are strong supporting signals. Linking heavily to a noindexed or canonicalized URL tells Google it matters, which contradicts the directive.

What if the client does not know which pages should be indexed?

Agree on intended states per page group in the audit brief. It is one of the most valuable decisions of the audit.

Related lessons

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