---
name: remove-duplicate-thin-pages
description: "Keep your best page and the useful facts it holds."
category: SEO & Content Architecture
stage: —
definitive_article: /seo-tree
status: needs-work
---

# Remove duplicate thin pages

Keep your best page and the useful facts it holds. This guide checks weak or repeated pages and plans what to keep, join or remove. Start with the pages that seem to serve the same need and read what each one adds.

**The path:** Suspect URLs → Intent and evidence review → Keep or change proposal → Guarded release checks

**Start when:** The content inventory has identified possible duplicate intent or pages with little useful original value.

## 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 [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 current roles, links and possible overlap.
- Exact current source, media, search/referral data when available, business function and useful facts for every affected URL.
- The existing source/redirect owner, recovery copy and explicit authority for the exact consolidation, deletion or route change.

## Steps

1. Treat similar titles, low word counts and repeated phrases as review signals, not verdicts. Read each page’s actual promise, audience, method, proof and business function. A short contact page, service page and detailed how-to can all be useful; shared terms do not make them interchangeable.
2. Identify the owning intent and any genuinely equivalent URLs. List unique facts, examples, links, media, attribution, comments or conversion functions that a change must preserve. Review available search and referral evidence with its period and limits; missing measurement is unknown, not proof that a page has no value.
3. Choose keep, improve, merge, canonical-review or remove for each exact URL, with a reason and owner. A canonical hint can identify a preferred duplicate representation but does not itself delete content or guarantee the selected search URL. Avoid turning every overlapping story into a competing-hub problem.
4. For a merge, place the useful unique material into the true equivalent destination and review the new whole page. Preserve source ownership, relevant media and claims; do not copy unsupported assertions merely because they existed in the old draft. Verify that the replacement serves what old visitors expected.
5. Prepare a precise route map. Use a permanent redirect when content has moved to a relevant replacement; if removed content has no equivalent, an appropriate 404 or 410 may be correct. An unrelated closest-hub redirect can mislead readers and be treated as a soft error. Never create a redirect loop or chain as a shortcut.
6. Apply authorized source and routing changes in the agreed sequence with current-source guards and recovery evidence. Update controlled internal links to the final relevant targets and verify generated sitemap behavior through the maintained tool. A sitemap refresh or canonical tag does not guarantee Google has reprocessed the change.
7. Check the normal old and new URLs, actual content/media, statuses, canonical signals and important page functions. Re-crawl affected links and record what changed, what remains pending and the observation date. Pass the accepted change set to measurement; do not claim that consolidation automatically raised rankings.

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

- [ ] Each disposition follows actual intent, value and source evidence, not a word-count threshold.
- [ ] Unique useful material, media, attribution and business function are preserved in the approved result.
- [ ] Every redirect has a relevant replacement, and old/new normal responses and links are checked.
- [ ] 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 two live pages for the same course and a short contact page. One course page contains a unique teacher interview, so the team preserves it in the main course page before proposing a redirect. The contact page remains because it serves a different need. The report records a reviewed consolidation, not three automatic deletions.

## Handoff and Content Factory context

An authorized source/route owner receives the exact disposition and recovery plan. [Check the placed links](https://local-service-spotlight.github.io/task-library/?task=step-5-qa-links-against-google-guidelines#task-step-5-qa-links-against-google-guidelines) receives live destination checks; [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 accepted release date, affected URLs and known baseline.

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=remove-duplicate-thin-pages#task-remove-duplicate-thin-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/)

### Primary method references

- [Google’s duplicate URL guidance](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)
- [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.