---
name: identify-and-eliminate-orphan-standalone-articles
description: "Help readers find useful pages that your site has left out."
category: SEO & Content Architecture
stage: —
definitive_article: /seo-tree
status: needs-work
---

# Identify and eliminate orphan/standalone articles

Help readers find useful pages that your site has left out. This guide checks pages with no link leading to them and plans the right fix. Start with the full page list, then compare it with the links people can follow.

**The path:** All published URLs → Incoming-path check → Keep, connect or review → Fresh crawl

**Start when:** A full published-URL inventory and a bounded internal-link crawl are available for the agreed site.

## Inputs

- [Inventory pages and their purpose](https://local-service-spotlight.github.io/task-library/?task=step-1-inventory-content-and-establish-gct-per-page#task-step-1-inventory-content-and-establish-gct-per-page) with source and crawl coverage, including pages a link-only crawl may miss.
- [Map actual content roles](https://local-service-spotlight.github.io/task-library/?task=map-content-hierarchically-root-trunk-branches-leaves#task-map-content-hierarchically-root-trunk-branches-leaves) with actual page roles, parents, incoming body links and site navigation.
- Current content sources and valuable facts/media, search data if available, and authority for exact edits or removals.

## Steps

1. Reconcile the published CMS list, sitemap and crawl before flagging orphans. A crawler that follows only existing links can miss the very pages being sought. Record excluded content types, private pages and failed fetches, and keep inaccessible records unknown rather than treating them as zero-link pages.
2. For each published URL, distinguish incoming internal links, outgoing links and a mapped parent. A page with no detected incoming path is an orphan candidate within the measured scope even if its category or parent is known. Check both body links and usable navigation, recording which definition the count uses.
3. Read each candidate for reader purpose, unique evidence, business function and current relevance. Choose connect, improve, consolidate-review, remove-review or intentionally unlisted with a reason. Utility or campaign pages may have a valid limited role; absence from the main topic tree alone is not permission to delete them.
4. For a useful content page, add a natural incoming link from its relevant existing hub or other suitable page, with a short explanation of its value. Add the page’s own parent or service link where useful. An outgoing link from the orphan does not itself create an incoming route.
5. For overlapping or weak pages, pass unique material and an exact proposed disposition to [Review duplicate or weak pages](https://local-service-spotlight.github.io/task-library/?task=remove-duplicate-thin-pages#task-remove-duplicate-thin-pages). Redirect only when the reviewed replacement truly serves the old intent; no equivalent replacement may require a proper not-found response. Do not hide unresolved decisions behind an irrelevant nearest-hub redirect.
6. Apply only the authorized content and routing changes through their maintained sources, with current-source guards and retained media. Verify the real link in the normal rendered body and the destination’s actual response. A saved row or category reassignment is not evidence that a reader can reach the page.
7. Re-crawl the agreed scope and compare each original candidate with the new incoming paths. Report connected pages, deliberate exceptions, merges/removals and remaining failures separately. Update the content map and owner list; do not claim “zero orphans” when the inventory or rendered crawl remains incomplete.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] The inventory includes unlinked published pages, and the incoming-link definition and coverage are stated.
- [ ] Each accepted connection is a verified incoming path from a relevant live page.
- [ ] Exceptions and destructive decisions have explicit reasons and authority; no blanket redirect or false zero-orphan claim is used.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional site has a useful repair story and an unlisted thank-you page. Neither appears in the body-link crawl. The guide adds an incoming story link from the repair hub and checks it live. The thank-you page has an intentional campaign role and stays separately noted. The report shows one repaired content orphan and one justified exception.

## Handoff and Content Factory context

[Place the accepted links](https://local-service-spotlight.github.io/task-library/?task=step-4-create-links-with-proper-anchor-text-and-placement#task-step-4-create-links-with-proper-anchor-text-and-placement) receives approved incoming-link rows; [Review duplicate or weak pages](https://local-service-spotlight.github.io/task-library/?task=remove-duplicate-thin-pages#task-remove-duplicate-thin-pages) receives reviewed consolidation candidates. [Measure the accepted change set](https://local-service-spotlight.github.io/task-library/?task=step-6-measure-and-iterate-with-maa#task-step-6-measure-and-iterate-with-maa) receives the actual released changes and crawl coverage.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/seo-tree/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=identify-and-eliminate-orphan-standalone-articles#task-identify-and-eliminate-orphan-standalone-articles)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Google’s site-move and removed-content guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.