---
name: step-1-inventory-content-and-establish-gct-per-page
description: "Know what each page is for before you change its links."
category: SEO & Content Architecture
stage: —
definitive_article: /internal-linking
status: complete
---

# Step 1: Inventory content and establish GCT per page

Know what each page is for before you change its links. This guide puts your pages, readers and next steps in one list. Start with the full set of live pages, then check what each one helps someone do.

**The path:** Published URLs + crawl → Page purpose and role → Opening review state → Shared inventory

**Start when:** The six-step internal-linking process is starting or the maintained content inventory is stale.

## Inputs

- Published URL exports from the actual CMS/source, current sitemap, rendered crawl and their dates.
- [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) conventions and [Goals, Content, Targeting: the result, source material and people served](https://blitzmetrics.com/gct-business-strategy/) for the result, actual material and people each page serves.
- The existing working inventory, access scope, link-count definition and current opening review evidence where available.

## Steps

1. Open the maintained inventory and record its prior date and scope before collecting data. Export all published content types in scope, including Posts and Pages where used, and reconcile them with sitemap and crawl. A crawl alone can miss unlinked URLs; list inaccessible or excluded source areas explicitly.
2. Keep one row per actual canonical content item with URL, source ID/type, title, publish/modified dates, current source revision, categories/tags where supported and page owner if known. Retain aliases and redirects in separate fields so normalization does not erase a real split or routing issue.
3. Add incoming and outgoing link counts with their extraction source and date. Distinguish rendered-body links from theme navigation and count unique sources consistently. Record missing data as unknown. A category, mapped parent or outgoing link does not prove that another page links into this one.
4. Read each major page and write its specific [Goals, Content, Targeting: the result, source material and people served](https://blitzmetrics.com/gct-business-strategy/). State the reader’s actual situation and desired action, the real method or proof supplied, and who the page serves. For money pages, use the genuine offer and buying path; for a recipe, identify the task result rather than a generic traffic goal.
5. Assign the honest content role and map location. Use the current tree legend without inventing a separate homepage/root node. Task recipes, topic hubs, service pages, supporting stories and utility pages have different jobs even if they share keywords; their evidence and readiness states stay distinct.
6. Retain the exact first two or three sentences and their source revision, then bring forward the [Review the opening and context](https://local-service-spotlight.github.io/task-library/?task=step-7-write-hook-and-establish-context#task-step-7-write-hook-and-establish-context) semantic review. Check grade-five context, why the reader should care, useful outcome and the body’s supporting mechanism. Save quoted reviewer evidence; unchecked pages stay unknown and failures go to the existing owner.
7. Flag missing purpose, orphan candidates, possible duplicates, weak proof and unresolved roles as separate findings. A missing brief requires investigation, not automatic deletion or consolidation. Save the completed bounded inventory and ownership gaps as the shared input for Steps 2–6, preserving the prior snapshot for comparison.

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

- [ ] Published-source and crawl coverage reconcile, with excluded and inaccessible areas explicitly listed.
- [ ] Major pages have specific reader purpose, actual content and targeting; unknowns are not filled with generic promises.
- [ ] Counts, roles, exact opening revisions and quoted review evidence have clear sources and states.
- [ ] Existing page rows retain the exact opening/revision and `step-7-write-hook-and-establish-context` review for reader/situation, reason to care, useful outcome and supporting mechanism; unchecked pages stay UNKNOWN, and failures route to the existing owner
- [ ] Save the exact grade-five opening and quoted semantic review from the linked hook task; a reading score alone does not approve the promise.
- [ ] 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’s export contains forty pages, but the crawl finds only thirty-eight. The team adds both missing URLs to the inventory and checks their roles. One is a useful guide with no incoming path; one is an intentional private-form destination outside public scope. The sheet keeps those causes separate and does not invent a passing opening review for either.

## Handoff and Content Factory context

[Review the supported 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) receives the source-backed inventory. [Plan relevant links and orphan repairs](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) receives genuine offers and incoming-link gaps; unresolved opening checks stay with their named owner.

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-1-inventory-content-and-establish-gct-per-page#task-step-1-inventory-content-and-establish-gct-per-page)
- [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.