Internal Linking Strategy: Ship Fixes as Pull Requests, Not Spreadsheets

Organic traffic has been flat for two quarters. Your Screaming Frog exports are piling up in Google Drive, orphan URLs keep appearing in the sitemap, and you're still editing spreadsheets at midnight while engineering tickets sit untouched in the backlog. Without an in-house SEO person, internal linking becomes one more task that everyone agrees matters and nobody ships.

That workflow is backwards. An internal linking strategy only creates value when a developer changes the site, a reviewer checks the diff, and the result gets measured after deployment. The practical unit of work isn't an audit row. It's a scoped pull request that adds a contextual link, repairs a crawl path, or updates a template without creating a new maintenance problem.

Why Internal Links Are Shipping Work, Not Audit Work

Google's own guidance makes the operational requirement clear: every important page should have a crawlable link from another page. A sitemap can list a URL, but a contextual HTML link gives both users and crawlers a route to it. Google's crawlable links documentation is the right foundation for turning that rule into a development task.

The historical reason internal links matter goes deeper than navigation. Google's PageRank system, introduced in 1998 and patented in 1999 as U.S. Patent 6,285,999, established the idea that links can signal importance. The visible toolbar metric was retired in 2016, but the underlying concept remains part of Google's public ranking guidance, as explained in this history of internal links and PageRank.

A spreadsheet row such as "add links to pricing" isn't a deliverable. A shippable version names the source files, destination URL, anchor text, insertion point, and verification command. For example:

• Content change: Add three contextual links to /pricing from comparison posts, each placed beside a sentence about plan fit.
• Repository change: Update the specific Markdown or MDX files, preserve front matter, and return a diff for review.
• Verification: Confirm each source resolves to the canonical pricing URL and that the rendered link is crawlable HTML.

The same applies to orphan recovery. "Fix 47 orphan URLs" should become a script or content patch that identifies each URL, groups it by template, adds relevant inbound links, and commits the change alongside the affected files.

The three ways audit-only work stalls

1. The spreadsheet never reaches a developer. The SEO task stays in Drive or Notion, separate from the repository where the fix belongs.
2. The developer never reads the spreadsheet. A developer can't reliably infer insertion points, anchor rules, or acceptable destinations from a URL list.
3. Nobody owns follow-up. Once a change is made, no one records which pages changed, when they changed, or whether the target improved.

Use one rule for every recommendation in this guide: it must end as a prompt, a checklist, or a measurement hook that an agent can execute and a human can review. Orchory is designed around that handoff, producing ready-to-run prompts for coding agents while keeping the actual site change inside a reviewed pull request.

Auditing Your Current Internal Link Graph

Start with a crawl, then turn the findings into file-level work. Run Screaming Frog or Sitebulb across the indexable site, export each internal-link target with its incoming-link count, and merge that file with page-level Google Search Console data. The crawl shows how pages connect. Search Console shows which URLs already earn impressions, clicks, and positions.

Keep the working CSV narrow:

source_url, target_url, source_template, target_template, anchor_text, incoming_link_count, clicks, impressions, average_position, indexable, sitemap_present, crawl_depth, canonical_url, redirect_status, target_priority.

Build three queues

First, compare sitemap URLs with URLs found in the crawl to isolate orphans. Group them by template, such as blog, documentation, feature, comparison, and use-case pages. An orphan with existing impressions should move ahead of an obsolete URL that has no remaining role.

Second, find under-linked pages with only one or two inbound links and a click-through rate above 1%. Calculate CTR from Search Console clicks and impressions. These pages already show search demand, so adding relevant inbound links may produce more value than publishing another article.

Third, flag over-linked targets receiving more than 8% of all internal links in the crawl. That threshold does not prove the target is wrong. It identifies pages where navigation, footer modules, related-post widgets, or repeated commercial anchors may be consuming links intended for other priority URLs.

The dataset behind this prioritization found that URLs with 0 to 4 internal links received an average of 2 Google Search clicks, while URLs with 40 to 44 internal links received 4 times as many clicks, in a study of 23 million internal links across 1,800 websites, as reported in this large-scale internal-link study. The same analysis found 53% of URLs had three or fewer internal links pointing to them.

Before assigning a fix, confirm that each target is canonical, indexable, live, and useful. Convert every queue item into a coding-agent prompt with source files, proposed anchor text, destination, and acceptance checks. Orchory can prepare that prompt for review, while the actual change stays in a reviewed pull request.

Keep off-site acquisition separate from graph repair. The Orchory Backlink Campaign belongs in an external-link workflow, not as a replacement for fixing internal paths.

The audit is complete only when it produces a ranked fix list with file paths, anchors, destinations, and verification checks. A report deck is not a shipped change.

Choosing an Architecture That Fits a Small SaaS Site

A small SaaS site doesn't need an elaborate taxonomy. It needs an architecture the team can maintain when product pages, comparison pages, documentation, and launch content all change at different speeds.

A pillar-cluster model gives the clearest topical relationships. One broad product or category page links to supporting articles, and those articles link back to the pillar. The trade-off is maintenance. A React-rendered blog with inconsistent templates can create cluster sprawl, duplicate navigation, and links that exist in source code but fail to appear in the rendered HTML.

A hub-and-spoke model is easier to operate at first. A feature hub can link to comparison pages, use-case pages, and supporting explanations without requiring every article to behave like a formal cluster member. The structure breaks down when a spoke becomes substantial enough to deserve its own supporting content. At that point, treating it as a spoke hides a new topic center.

A flat architecture can work for documentation-heavy sites where users move from one concept to the next and the docs layer has strong sibling or breadcrumb links. It becomes weak for marketing content because a flat set of cross-links doesn't clearly signal which page represents a category, product pillar, or commercial destination.

A maintainable default

For a bootstrapped team, use one hub per product pillar, two to three clusters of 8 to 12 posts each, and a flat documentation layer underneath. Treat the hub as the commercial and navigational center. Let each cluster page link back to its hub, and let the hub link to the most useful cluster pages rather than every URL you own.

The topic cluster content strategy guide is useful for mapping the relationship between a broad page and its supporting content, but the implementation should remain repository-specific.

Use these escape hatches:

• Promote a cluster to a pillar when several pages repeatedly answer distinct sub-intents and the current hub no longer gives users enough context.
• Merge two spokes when they target the same intent, have overlapping copy, and compete for the same internal links.
• Add a new hub when a product pillar has its own audience, page types, and conversion path, rather than forcing unrelated pages under an existing hub.

The architecture should also support bidirectional links. A hub that links out but never receives links back from its cluster pages is a directory, not a reinforcing topic system. For key pages, keep the route from the homepage short. Independent large-site analysis recommends a maximum crawl depth of three clicks for important pages and a quarterly loop that compares a full crawl, Search Console crawl data, and sitemap URLs, as described in this large-site architecture analysis.

Scoring Opportunities So the Top 10 Matter

A linking opportunity earns a place in the queue only when its expected impact justifies the implementation effort. A shared keyword is weak evidence on its own. Score the opportunity, reject low-value work, and send only reviewed candidates to engineering.

Score each opportunity on two axes. Impact combines source-page impressions, source-to-target relevance, the target's current distance from important entry points, and conversion or business priority. Effort covers the content edit, template change, developer review, and risk involved.

Use a 0 to 5 score for each signal. Zero means there is no useful evidence or fit. Five means the signal strongly supports a priority page.

Calculate the impact score as:

(source impressions × 0.30) + (target relevance × 0.30) + (current target distance × 0.20) + (business priority × 0.20)

Estimate effort separately:

• 1: One Markdown or MDX edit using an existing anchor.
• 2: Several content files using the same pattern.
• 3: A component or template change that requires developer review.
• 4: A cross-template change with rendering or routing risk.
• 5: A migration, data-model change, or broad refactor.

Drop opportunities with an impact score below 3.0. Sort the remaining rows by impact per effort hour, then export the top 10 as the sole input for the next PR batch. Each exported row should state the source, target, proposed anchor, score breakdown, owner, and acceptance check. The Orchory Free SEO Tools can sit alongside crawl and Search Console exports, while the scoring file keeps the implementation decision explicit.

Scoring varies by fix type

A relevant sentence in a high-impression comparison post that points to a pricing page can score strongly on impressions, relevance, and business priority while requiring little effort. It should outrank a footer change that adds links across every article.

A feature page buried three clicks below the homepage, linked from a closely related guide, may score well for distance and relevance. If the source uses a component rather than Markdown, the change deserves a moderate effort score and a reviewed pull request.

An orphan glossary page with no impressions and weak business priority should fall below the threshold, even when the edit is easy. The agent can convert a qualifying row into a bounded implementation prompt. It should not turn low-effort work into a PR merely because the change is technically simple.

Turning the Top Picks Into Ready-to-Run Prompts

The CSV becomes useful when every row can produce one bounded artifact. I use three prompt types: a context-block prompt for editorial links, a template prompt for repeated modules, and a guardrails prompt for policy enforcement.

A context-block prompt should include the exact file path, the current excerpt, the proposed anchor, the canonical target, and the verification method. A template prompt should identify the component, the route list, and the condition that prevents irrelevant links from appearing on unrelated pages. A guardrails prompt should define anchor conventions, internal nofollow handling, and the rule against changing canonical tags or redirects as part of a link-only PR.

Use this skeleton:

Task: Add the specified internal link without changing unrelated copy. Source file: [path] Source excerpt: [exact excerpt] Target URL: [canonical URL] Suggested anchor: [descriptive anchor] Placement: [sentence or component slot] Constraints: Preserve front matter, existing analytics attributes, and rendered HTML semantics. Do not add duplicate links in the same block. Verification: Run [test or build command], then confirm the source contains one crawlable link to the canonical target. Rollback: Revert this commit if the build fails, the route changes, or the rendered link is absent.

Require the agent to return structured JSON:

{
  "source_file": "",
  "target_url": "",
  "anchor_text": "",
  "change_type": "contextual|template|guardrail",
  "diff_summary": "",
  "verification": [],
  "risks": [],
  "rollback": ""
}

Every prompt should be idempotent. If the link already exists, the agent should report no change instead of adding a duplicate. Keep each prompt scoped to one PR so review remains readable and rollback doesn't require untangling unrelated edits.

Human review before merge

• Destination: The URL is live, canonical, indexable, and matches the surrounding intent.
• Anchor: The phrase describes the destination without forcing an exact-match keyword.
• Placement: The link helps the reader at that point in the page.
• Rendering: The final HTML contains a normal crawlable link.
• Scope: The diff doesn't alter unrelated copy, templates, metadata, or routing.
• Rollback: The commit can be reverted without a follow-up hotfix.

The weekly loop is simple: score the queue, select the top opportunities, generate one prompt per PR, review the diff, merge, and record the measurement baseline.

Anchor Text, Link Depth, and When More Links Stop Helping

More links can make a page less clear. The useful question isn't "How many links can we add?" It's "Does this link provide a relevant next step without competing with the page's primary job?"

Anchor quality is a common failure point. One independent study found that about 81% of anchors were keyword-rich, but 28% had no similarity to the target title, only 8% were strongly aligned, and 14% were 11 or more words long. The same analysis found 71% of contextual links clustered within the first two hierarchy levels, while fewer than 6% reached depth four or beyond, as documented in this internal-link anchor and depth study.

Use descriptive phrases that fit the sentence. Replace "read more" with "compare workflow automation tools" when that is what the target page covers. Don't repeat the same commercial anchor throughout every article, and don't link a pricing page from a paragraph that never discusses plans, fit, or buying criteria.

Three limits to enforce

Relevance threshold: The source and target should share a clear user need, product relationship, or topic relationship. A generic blog widget that links to unrelated pages may increase link count without improving comprehension.

Dilution control: Keep body links purposeful. As an editorial rule, use no more than five internal links per 1,000 words in a normal article body, then review whether each one earns its place. That cap is a readability guardrail, not a universal ranking law.

Depth budget: Aim to keep important pages within three clicks of the homepage. If a priority page is below four clicks, give it a dedicated inbound link before adding more links elsewhere. Google's crawlable-link guidance supports the underlying principle, important URLs need reachable HTML paths, not just sitemap inclusion.

A page can also become over-linked through navigation. If a sidebar pushes the primary CTA below the fold, remove low-value links before adding new contextual links. For page-level budgets, independent analysis reports a practical range of 45 to 50 internal links per page, with traffic losses beyond that range, while other operational guidance recommends keeping priority pages around 30 to 60 outbound links. Treat those ranges as inspection triggers, not automatic deletion rules, and prefer a small set of relevant body links over a sitewide link spray, as summarized in this internal-link planning reference.

Measuring Impact and Feeding Results Back Into the Loop

Measurement should attach to the same PR that changed the graph. Before merging, capture the target URLs, current impressions, clicks, average position, crawl depth, and inbound link count. After deployment, compare the same fields instead of relying on a general traffic chart.

Track four signals:

• Indexable orphan count: The number of sitemap URLs with no discovered inbound path.
• Average link depth: The average click distance from the homepage to priority URLs.
• Target-page clicks and impressions: Search Console performance for the exact URLs changed by the PR.
• Cluster position movement: Average position for the hub and its associated pages, using a consistent query set.

A 30-day win is an improvement in discovery and coverage, such as fewer indexable orphans, shorter average depth, and impressions beginning to rise on updated targets. For a directional baseline, treat a 5 to 10% impression lift on updated clusters as a meaningful early signal, not proof of durable ranking improvement. That benchmark should be recorded with the affected URLs and source pages, not applied to the whole domain.

A 90-day win requires more than an initial impression change. Look for sustained clicks to the target pages, improved average positions across the cluster, and a stable crawl path after new content ships. Search behavior changes for many reasons, so don't claim the internal link caused every movement. Compare changed clusters with unchanged clusters where possible, and document the competing changes.

Log the result beside the merged PR. A failed test isn't wasted if the team records the source, anchor, target, and reason it failed. The SEO experimentation workflow provides a useful model for treating changes as measured iterations rather than permanent assumptions.

Each week, feed the top movers back into the audit. A page that improved becomes a possible source for another relevant target. A new orphan detected by the crawl reopens the same prompt template. If query discovery also needs work, the Orchory AI Keyword Research Tool can be recorded as a separate input, but don't mix keyword expansion with link-graph diagnosis in the same PR.

The loop closes when a merged change creates the next measurable queue, not when someone exports another spreadsheet.

Orchory turns SEO opportunities into ranked work items and ready-to-run prompts for coding agents, including internal-link changes that can be reviewed and merged as PRs. Visit Orchory, connect the opportunity queue to your repository workflow, and ship the next ten internal-link fixes with a human review step.

FAQs