Internal Linking Architecture Prompt

Public field comparison

Internal Linking Architecture Prompt

Internal Linking Architecture Prompt

Plan internal links that connect money pages, supporting articles, category hubs, and topical clusters.

Design an evidence-based internal linking architecture connecting priority pages, supporting content, category hubs, and topical clusters, with implementation controls and measurable QA checks.

—

Use this prompt to diagnose internal-link gaps, map topical relationships, prioritize page-level link recommendations, and create a controlled implementation and verification plan.

Search Intent Review
SEO Content Refresh
Content Briefing
SERP Competitor Review
Internal Linking Review
Citation Readiness

Auditing orphan pages, excessive click depth, and weak internal discovery paths
Designing hub-and-spoke links between category, commercial, and supporting content
Prioritizing contextual links to important pages without anchor stuffing
Planning controlled editorial and sitewide template link changes
Verifying implemented internal-link changes against crawl evidence

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Primary SEO Objectives
Site URL Inventory
Internal Link Evidence
Priority Pages and Page Roles
Search and Crawl Evidence
Constraints and Approval Rules
Success Criteria

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In ChatGPT, replace every bracketed variable with the corresponding site information. Provide a current URL inventory, crawl or internal-link export, priority-page list, search and indexation evidence, architecture constraints, approval rules, and success thresholds. Redact sensitive data, attach or paste the evidence ChatGPT should inspect, then run the prompt. If a source is unavailable, state that explicitly rather than leaving the variable unresolved.

Use this when you need a production-ready seo architecture result in SEO & Blogging, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

An ecommerce content team can provide a Screaming Frog URL and inlink export, Search Console landing-page data, category and product priorities, and CMS constraints. ChatGPT will map category hubs and supporting guides, identify orphaned or excessively deep commercial pages, produce source-to-destination link recommendations, separate template changes from editorial edits, and define the evidence required to verify deployment.

Advanced

Advanced

ChatGPT

ChatGPT

seo architecture

internal linking architecture

chatgpt
SEO & Blogging
internal-links
site structure

chatgpt
seo architecture
internal-linking
site structure
technical-seo
content hubs

Internal Linking Architecture Prompt | AMO.ng

Internal Linking Architecture Prompt | AMO.ng

Plan internal links that connect money pages, supporting articles, category hubs, and topical clusters.

Map topical hubs, priority pages, and contextual links with evidence-based recommendations, implementation controls, and measurable SEO verification.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior SEO & Blogging specialist using ChatGPT. Your task is: [Goal or task].
+Develop an evidence-based internal linking architecture from the materials supplied below.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+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]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Internal Linking Architecture Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+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.
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+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.
 
−Do not give generic advice. Optimize for a production-quality seo architecture outcome.
+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.