Internal Linking Architecture Prompt

Develop an evidence-based internal linking architecture from the materials supplied below.

Inputs
- Primary SEO objectives: [Primary SEO Objectives]
- Site URL inventory and page metadata: [Site URL Inventory]
- Existing internal-link graph or crawl export: [Internal Link Evidence]
- Priority URLs, page roles, and conversion priorities: [Priority Pages and Page Roles]
- Search performance, indexation, and crawl evidence: [Search and Crawl Evidence]
- CMS, editorial, legal, technical, and approval constraints: [Constraints and Approval Rules]
- Required outcomes and acceptance thresholds: [Success Criteria]

ChatGPT operating boundaries
- Work only from information visible in the conversation and files ChatGPT can actually inspect. Do not imply that a live site was crawled, analytics were queried, links were changed, or pages were validated unless corresponding access and execution evidence are present.
- Treat supplied exports, page content, and documented business rules as evidence. Keep facts, observations, assumptions, hypotheses, conflicts, and unknowns distinguishable.
- Recommend changes, but do not claim to edit a CMS, publish content, remove links, alter navigation, or approve deployment. Those actions require an authorized human operator.
- Do not expose credentials, personal data, unpublished commercial information, or sensitive analytics. Request redacted or aggregated evidence when raw data is unnecessary.

Input gate
1. Confirm whether the URL inventory identifies, where available: URL, HTTP status, indexability, canonical target, page type, title or H1, topic, language or market, organic performance, inbound internal-link count, outbound internal-link count, and crawl depth.
2. Confirm that priority pages and their intended roles are identifiable, such as commercial or money page, product or service page, category hub, informational article, comparison page, support page, or utility page.
3. Treat a usable URL inventory plus identifiable objectives and priority pages as blocking prerequisites. If any is missing, ask only the questions required to obtain it and stop before producing page-level recommendations.
4. If current link-graph, crawl, analytics, or Search Console evidence is unavailable, bounded progress is allowed: create a provisional architecture and explicitly mark current-link diagnostics, baseline metrics, and impact estimates as unavailable or unverified.
5. If sources conflict, preserve the conflict, identify which decisions depend on it, and request resolution rather than selecting a convenient value.

Analysis workflow
1. Build an evidence register. For every source, record its date or reporting period, scope, relevant fields, limitations, and whether it represents supplied fact, direct observation, or an unverified assertion. Flag stale exports, partial crawls, inconsistent URL variants, and mismatched reporting periods.
2. Normalize the inventory without silently changing it. Identify protocol, hostname, trailing-slash, parameter, case, canonical, redirect, duplicate, noindex, and non-200 variants. Keep original and normalized URLs traceable.
3. Classify pages by template, search intent, topical cluster, funnel role, business priority, indexability, and canonical status. Mark uncertain classifications and pages that appear to compete for the same intent.
4. Diagnose the current architecture using only available evidence. Assess orphan or near-orphan pages, excessive click depth, weak hub-to-spoke and spoke-to-hub paths, dead-end pages, links to redirects or error pages, noncanonical destinations, irrelevant cross-cluster links, overlinked templates, isolated priority pages, anchor-text concentration, generic anchors, and internal competition or cannibalization risk.
5. Separate navigational, breadcrumb, footer, faceted, related-content, and contextual body links when the evidence permits. Do not treat every sitewide template link as equivalent to an editorially relevant contextual link.
6. Design the target architecture. Define topical hubs and supporting clusters, parent-child and sibling relationships, routes from high-authority or frequently crawled pages to priority destinations, and useful return paths. Preserve user intent and information scent; do not recommend links solely to manipulate ranking signals.
7. Evaluate each proposed link for source-page relevance, destination intent, user usefulness, indexability, canonical destination, likely placement, anchor naturalness, duplication with existing links, and editorial or template dependency.
8. Prioritize recommendations by expected strategic value, evidence confidence, implementation effort, operational risk, and dependency. Use qualitative ratings unless the supplied data supports defensible numeric scoring; explain any scoring formula used.
9. Group changes into reversible implementation batches. Identify CMS template changes separately from page-level editorial changes because their blast radius, ownership, testing, and rollback needs differ.
10. Define verification before implementation. Include baseline capture, pre-publication checks, post-deployment crawl reconciliation, page sampling, exception handling, and monitoring periods. Organic performance changes must not be attributed to internal links without a suitable baseline, elapsed time, and consideration of other changes.

Guardrails and stop conditions
- Do not recommend links to known 4xx or 5xx URLs, unintended redirects, noindex pages, blocked resources, or noncanonical duplicates unless documenting an explicit exception and its rationale.
- Avoid deceptive anchors, repetitive exact-match anchor stuffing, irrelevant cross-topic links, accessibility-hostile wording, or links added only for bots.
- Do not remove legally required, accessibility, account, support, safety, or conversion-critical links merely because they appear to dilute internal authority.
- Flag recommendations affecting global navigation, breadcrumbs, faceted navigation, localization, pagination, or shared templates for technical SEO and product-owner review.
- Require an approved change set, a recoverable backup or version history, staging or controlled preview where available, named implementation ownership, and a rollback path before bulk changes.
- Stop and escalate when the inventory contains widespread canonical or indexation conflicts, the intended ranking page is disputed, proposed destinations are scheduled for migration or retirement, or access evidence is insufficient to determine whether a change is safe.

Required deliverable

A. Scope and evidence register
Provide the analyzed scope, exclusions, reporting dates, evidence sources, source limitations, unresolved conflicts, blocking gaps, assumptions, and an overall confidence assessment.

B. Page-role and cluster map
Create a table with: cluster, page or pattern, normalized URL, page role, primary intent, parent hub, supported priority page, indexability or canonical status, business priority, classification confidence, and notes.

C. Current-state diagnostic
Report evidence-supported findings for orphaning, click depth, inbound and outbound link distribution, broken or redirected destinations, hub-spoke coverage, anchor patterns, dead ends, and cross-cluster leakage. For each finding include the evidence, affected scope, consequence, confidence, and whether it is measured, inferred, unavailable, or disputed.

D. Target architecture
Describe the proposed hub, spoke, sibling, breadcrumb, navigational, and contextual-link relationships. Explain how users and crawlers should reach each priority page, which existing structures should remain unchanged, and the trade-offs among relevance, crawlability, user experience, editorial burden, and template scale.

E. Link recommendation register
Provide one row per recommendation with: recommendation ID, source URL or page pattern, destination URL, source and destination roles, relationship type, suggested placement, anchor guidance with acceptable variants, user rationale, SEO rationale, supporting evidence, current-link status, priority, confidence, owner, dependency, implementation method, risk, approval required, and status. Use statuses such as proposed, blocked, approved, implemented, verified, rejected, or exception; never infer a later status without evidence.

F. Remediation and exception register
List broken-link fixes, redirect-target updates, orphan-page remedies, links requiring removal or consolidation, noncanonical destinations, and intentionally unlinked or low-priority pages. Include evidence, recommended disposition, risk, decision owner, and unresolved questions.

G. Implementation batches and controls
Sequence low-risk page edits, higher-impact template changes, and deferred items. For each batch provide prerequisites, owner, approval point, preview or staging check, expected affected scope, rollback method, and evidence required to mark it implemented.

H. Verification matrix
For every acceptance check provide: check, baseline or expected result, verification method, required evidence, actual result if execution evidence is supplied, status, exception, and owner. At minimum verify:
- recommendation URLs reconcile to the normalized inventory;
- proposed destinations are valid, indexable, and canonical unless an approved exception exists;
- priority pages have relevant discovery paths meeting the supplied success thresholds;
- orphan and excessive-depth findings are resolved or recorded as approved exceptions;
- anchors are descriptive, varied where appropriate, and contextually accurate;
- contextual recommendations are not falsely counted as existing links;
- template changes do not create unintended sitewide duplication or links from irrelevant page types;
- implemented counts reconcile with the approved recommendation register;
- a post-change crawl or equivalent inspection confirms destination status, link presence, crawl depth, and unexpected regressions.
If no implementation or post-change evidence exists, show actual results as unavailable and keep checks pending or unverified.

I. Decision and handoff summary
State what can proceed, what requires approval, what is blocked, which assumptions have the highest consequence, the smallest safe next action, and the exact evidence needed for the next status transition.

Completion language
Use “proposed” for unexecuted recommendations. Use “implemented,” “tested,” “verified,” or “approved” only when the supplied materials show the corresponding action, actor, date, scope, and result. Never present forecast ranking gains as measured outcomes.