---
name: step-3-identify-money-pages-and-orphan-pages
description: "Find good pages that are hard to reach."
category: SEO & Content Architecture
stage: —
definitive_article: /internal-linking
status: complete
---

# Step 3: Identify money pages and orphan pages

Find good pages that are hard to reach. This guide plans links to real offers and pages with no path in. Start with your page list, the offers you sell and the links the site now has.

**The path:** Actual offers + incoming gaps → Relevance review → Prioritized link rows → Placement owner

**Start when:** The page inventory and supported taxonomy review are ready for an exact source-to-target link plan.

## 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) and [Review WordPress taxonomy](https://local-service-spotlight.github.io/task-library/?task=step-2-fix-categories-and-tags-in-wordpress#task-step-2-fix-categories-and-tags-in-wordpress) results, including actual incoming-path coverage.
- The live offer/service destinations, current business priorities and verified comparable revenue data only if connected.
- Reader purpose, body content and existing links for potential sources; the [Money Pages versus Blog Posts method](https://blitzmetrics.com/money-pages-vs-blog-posts/).

## Steps

1. Identify the actual buying, booking, service and lead-capture destinations from the site and business owner. A “money page” is an offer/action role; its name does not prove it currently earns revenue. Keep the live URL, intended action, source owner and any known duplicate or redirect.
2. Flag pages with no detected incoming internal route using the inventory’s stated scope. Keep outgoing links, navigation links, body-link counts and assigned parent separate. Cross-check orphan candidates with the published source so unlinked content missed by the crawler is not excluded from the plan.
3. Prioritize offers with the owner’s current business goals, relevant proof gaps and measured support. Use verified comparable revenue only when available; otherwise label priority as a business decision, not a revenue rank. An expensive offer or a zero-link count alone does not establish financial impact.
4. For each target, read candidate source pages and their [Goals, Content, Targeting: the result, source material and people served](https://blitzmetrics.com/gct-business-strategy/). Select places where a reader would genuinely benefit from the next destination. Record the actual supporting sentence or section; reject keyword-only matches and avoid turning every source page into a link to every service.
5. For each useful orphan, plan an incoming link from an existing relevant page as well as an appropriate outgoing parent link. Route weak or overlapping content to its separate review task. A page becoming a source for an offer remains orphaned if nothing links into it.
6. Write one action row per exact source-to-target relationship, with proposed anchor/context, target status, relevance reason, source revision and owner. Mark add, improve-existing, no-change or held. A missing hub or unresolved offer duplicate needs its owner’s decision before a misleading target is used.
7. Save two coherent lists: priority offers needing support and orphan/exception dispositions. Review the plan with its release owner and pass only accepted rows to placement. Preserve missing access, unresolved source facts and baseline needs so the next task cannot mistake a proposed link for a published result.

## 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/).

- [ ] Money-page roles and business priorities are sourced; unknown revenue is not labeled zero or proven importance.
- [ ] Orphan repairs include real incoming paths, with intentional exceptions and content-review cases distinct.
- [ ] Each accepted row has an exact source, relevant target, proposed context, current revision and owner.
- [ ] 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 contractor has two service pages and a useful job story with no incoming link. The plan links the roof hub to that story, and the story to its relevant roof service. The owner chooses roofing as a current priority, but no revenue feed is connected. The report calls it an owner priority and does not label it the highest-earning branch.

## 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 accepted rows and source guards. [Review duplicate or weak pages](https://local-service-spotlight.github.io/task-library/?task=remove-duplicate-thin-pages#task-remove-duplicate-thin-pages) receives duplicate-intent cases; [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 target URLs and the baseline request before links are released.

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/internal-linking/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=step-3-identify-money-pages-and-orphan-pages#task-step-3-identify-money-pages-and-orphan-pages)
- [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/)

## Review and evidence still needed

The inherited contributor status is `complete`. 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.