QuQi

Orphan SKU Discovery Audit

Sitemap inclusion gets treated as discovery, so a product listed in one is assumed reachable. A URL with no internal links pointing at it is crawled late, ranks weakly and is dropped first when crawl demand tightens. On a large catalogue the cause is structural: infinite scroll with no paginated fallback, a grid capped at 60 items, or a range reachable only through a filter, and none of that appears in a sitemap coverage report.

Get the skill file Let the agents run it
CATEGORY
Ecommerce SEO
FORMAT
orphan-sku-discovery-audit.md
STEPS
7
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when a large share of products sit in the XML sitemap but are rarely crawled or never indexed, and nobody can explain how a crawler is meant to reach them.

The skill file

orphan-sku-discovery-audit.md
---
name: orphan-sku-discovery-audit
description: Use when a large share of products sit in the XML sitemap but are rarely crawled or never indexed, and nobody can explain how a crawler is meant to reach them.
---

# Orphan SKU Discovery Audit

Sitemap inclusion gets treated as discovery, so a product listed in one is assumed reachable. A URL with no internal links pointing at it is crawled late, ranks weakly and is dropped first when crawl demand tightens. On a large catalogue the cause is structural: infinite scroll with no paginated fallback, a grid capped at 60 items, or a range reachable only through a filter, and none of that appears in a sitemap coverage report.

## What you need first

- A full crawl started from the home page with sitemap discovery switched off, so it measures real link paths
- The complete sellable SKU list from the database or feed, to diff against what the crawl found
- Server logs showing Googlebot hits per product URL across 30 days
- Search Console page indexing export split by sitemap

## Method

1. Crawl from the home page with sitemap discovery disabled. Anything unreachable this way is orphaned regardless of what the coverage report says.
2. Diff the crawl result against the full SKU list. The missing set is the orphan list, and on catalogues using infinite scroll it is usually far larger than anyone expects.
3. Record click depth for every SKU the crawl did reach. Depth past roughly 4 correlates with slow crawling on large sites, so the depth histogram sizes the problem before you change anything.
4. Trace how the deep and orphaned products are meant to be reached. The answer is almost always a filter, a search box or a scroll event, none of which emit a crawlable anchor.
5. Add real paginated anchors behind any infinite scroll and verify them in the rendered DOM rather than the source, since the pagination frequently exists only after the script runs.
6. Cross-check the orphan list against the logs and against demand. A product that is properly linked and still unvisited after 30 days has a demand problem, and retiring part of that set is the honest answer.
7. Re-run the sitemap-free crawl after the fix and report the shift in the depth histogram rather than the orphan count alone, because moving a SKU from depth 9 to depth 7 changes nothing.

## What this produces

An orphan list and a click-depth histogram for the full catalogue, with the navigation and pagination changes required to bring the tail inside four clicks.

## Where this goes wrong

- Running the audit crawl with sitemaps enabled, which hides the orphans and produces a clean report on a broken structure
- Treating sitemap inclusion as a discovery path, so orphans stay orphaned while coverage looks acceptable
- Fixing depth by dumping thousands of links into the footer, which spreads equity thinly and is discounted anyway
- Measuring success as a lower orphan count when the newly linked products are still six clicks from the home page

---

From the QuQi skill library - https://www.quqi.io/skills/orphan-sku-discovery-audit
Free to download · no account, no email

What you need first

  • A full crawl started from the home page with sitemap discovery switched off, so it measures real link paths
  • The complete sellable SKU list from the database or feed, to diff against what the crawl found
  • Server logs showing Googlebot hits per product URL across 30 days
  • Search Console page indexing export split by sitemap

Method

  1. 01 Crawl from the home page with sitemap discovery disabled. Anything unreachable this way is orphaned regardless of what the coverage report says.
  2. 02 Diff the crawl result against the full SKU list. The missing set is the orphan list, and on catalogues using infinite scroll it is usually far larger than anyone expects.
  3. 03 Record click depth for every SKU the crawl did reach. Depth past roughly 4 correlates with slow crawling on large sites, so the depth histogram sizes the problem before you change anything.
  4. 04 Trace how the deep and orphaned products are meant to be reached. The answer is almost always a filter, a search box or a scroll event, none of which emit a crawlable anchor.
  5. 05 Add real paginated anchors behind any infinite scroll and verify them in the rendered DOM rather than the source, since the pagination frequently exists only after the script runs.
  6. 06 Cross-check the orphan list against the logs and against demand. A product that is properly linked and still unvisited after 30 days has a demand problem, and retiring part of that set is the honest answer.
  7. 07 Re-run the sitemap-free crawl after the fix and report the shift in the depth histogram rather than the orphan count alone, because moving a SKU from depth 9 to depth 7 changes nothing.

What this produces

An orphan list and a click-depth histogram for the full catalogue, with the navigation and pagination changes required to bring the tail inside four clicks.

Where this goes wrong

  • Running the audit crawl with sitemaps enabled, which hides the orphans and produces a clean report on a broken structure
  • Treating sitemap inclusion as a discovery path, so orphans stay orphaned while coverage looks acceptable
  • Fixing depth by dumping thousands of links into the footer, which spreads equity thinly and is discounted anyway
  • Measuring success as a lower orphan count when the newly linked products are still six clicks from the home page

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/orphan-sku-discovery-audit/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When do I run this rather than read the sitemap coverage report?

When products sit in the sitemap and are rarely crawled or never indexed. The coverage report cannot answer it, because sitemap inclusion is not a link path. Use this when you need to know how a crawler is actually meant to reach a SKU, which on a large catalogue is usually through a filter, a search box or a scroll event, and therefore not at all.

How do I set the crawl up, and what else do I need alongside it?

A crawl started from the home page with sitemap discovery switched off, the complete sellable SKU list from the database or feed, thirty days of Googlebot hits per product URL, and the page indexing export split by sitemap. Run the crawl with sitemaps enabled and it reaches every orphan through the sitemap, hiding the problem behind a clean report on a broken structure.

What does the audit produce, and which number should I report?

An orphan list plus a click depth histogram for the whole catalogue, with the navigation and pagination changes needed to bring the tail inside four clicks. The histogram is the part worth reporting, because the orphan count can fall while products merely move from depth nine to depth seven, which changes nothing about how often they are crawled.

Which fix looks like progress and is not?

Fixing depth by dumping thousands of links into the footer. It moves the number, spreads equity thinly across every page and is discounted anyway, so the release ships without changing crawl behaviour. The honest end of the audit is also uncomfortable: a properly linked product still unvisited after thirty days has a demand problem, and part of that set should be retired.

More in Ecommerce SEO