Are Automatic Internal Links Good for SEO? 22 Never Render

By Ugur Saritepe · September 16, 2026

Are automatic internal links good for SEO? They fix the failure hand-placed links kept causing on my site: pages with no links into them. They also move on their own. I audited my own site and found 22 configured links that never reach a page, and a link rule that passed on every branch and failed on the merge.

Why I generated the links at all

game-scout.app is the games directory I run and write about openly. It has 108 browseable list pages, and every one of them ends with an Explore More block of links to sibling lists. Those links used to be hand-written, one array per page, and the failure mode was the one the orphan pages post opens with: publish a new page, forget to link to it from anywhere, and it sits unreachable.

So on 2 September 2026 I shipped a second mode. A cluster of lists can be marked as computed, and then each member's six link slots are filled by arithmetic instead of by hand: the next four lists after it in the cluster, then two links into a neighbouring cluster. As of 16 September 2026, 4 of 15 clusters run this way, covering 51 pages. The other 11 clusters are still hand-written.

The generated half does what it promised. Every one of those 51 pages renders exactly six outbound links and receives between four and six, with no way to drop below the floor, because the count is a property of the arithmetic rather than of anyone remembering.

214 links configured, 192 rendered

The hand-written half was a different story, and I only found out by counting what the page outputs rather than what the config holds. Across the 48 pages that still carry a hand-written list of related links, 214 links are configured and 22 of them never reach a page:

browseable pages:                                   108
pages with a hand-written related-links array:       48
configured entries:                                 214
  of those, rendered:                               192
  of those, never rendered:                          22
pages losing at least one configured link:           15
worst: best-open-world-games            8 configured -> 5 rendered

The cause is four lines of code, not a mystery. The block holds six links. Hand-written entries are capped at four so that two slots are always reserved for cluster siblings. The loop that copies them in stops at the fourth, and the fifth entry someone typed a year ago is simply never read. Nothing errors, nothing warns, and the config file keeps saying eight.

This matters beyond my own repository because the same shape is everywhere. A WordPress related-posts block, a Next.js component with a slot limit, a CMS field that takes ten entries and a template that prints three: in each case the place you would audit and the place the link appears are different files, and only one of them is what Google sees. Google's own requirement is that a link be an a element with an href in the served HTML. A configured link that never becomes one is not a weak link. It is not a link.

The rule passed on every branch and failed on main

There is a test in that repository asserting that every browseable list receives at least three inbound links from somewhere on the site. On 2 September 2026 it went red on the main branch while being green on every branch that had just been merged into it. Four pull requests, each one checked against its own base, each one passing. Combined, they orphaned a page.

The reason is that the supply of links is fixed and shared. Each page emits at most six. Add a page to a cluster and it takes sibling slots that were previously pointing elsewhere. Every branch was correct about the site it could see, and no branch could see the other three.

One more thing that audit taught me, and it is the same lesson as the counting one. Before the migration I measured how many hand-written links I was about to retire and got 63. Re-measured on what actually rendered, the real number was 14. Forty-nine of the links I was planning around had never been on a page at all.

Adding one page moves links on pages you did not touch

This is the cost of generating them, and it is not subtle once you see the arithmetic. A page's two cross-cluster links are taken from positions 2i and 2i + 1in a pool built from every member of every neighbouring cluster. The modulo is over the pool size. Change the pool size by one and every member's cross links move.

That includes clusters you did not edit. A cluster which merely names another one as a neighbour has its own links drawn from the combined pool, so publishing into cluster A reshuffles links inside cluster B. The first time I ran this at scale, the arithmetic put genuinely unrelated pairs on live pages: a house-design list linking to dinosaur games, hunting to puzzle, fishing to Lego. The fix was to declare fewer neighbours, which left three lists sitting at exactly three inbound links. We have not migrated the cluster that would lift them, so those three are still at the floor two weeks later.

I raised this as a problem and proposed three fixes: only ever append new members so existing pages keep their links, freeze the link set of any page under measurement, or replace the index arithmetic with a hash so that pool growth stops reshuffling anything. This is what came back:

We have not applied any of the three, so pool growth still reshuffles cross links on pages nobody edited, and that is the deliberate trade. The property being bought is reciprocity: a new list is linked by its siblings with no per-page edits, forever, with no one remembering to do it. Freezing links to protect a measurement would have meant hand-maintaining the exact thing the system exists to automate.

What the trade cost me

It cost an experiment. I had a cluster under measurement with a prediction due on 15 September 2026, and its whole value was that it had received structure and no other change. Once its members' link sets could move inside the measurement window, the readout stopped being clean. I graded it as suggestive rather than conclusive, which is a polite way of saying I spent four weeks waiting for a number I then could not use. The hub pages post is where that grading went.

What I cannot give you is the thing you actually want to know, which is whether the shuffling costs traffic. Here is the closest I have, pulled on 16 September 2026 for the 28 days to that date:

site: sc-domain:game-scout.app
dimensions: ["page"]   page contains /best/
2026-08-20 to 2026-09-16, vs previous 28 days

totals        2,477 clicks  107,550 impr  pos 9.09
previous      1,264 clicks   57,954 impr  pos 10.55
21 pages at exactly 3 inbound links:  91 clicks between them
best-action-games (23 inbound, most linked): 0 clicks, 66 impr

The 21 pages at the floor returned 91 clicks between them, 4 of them returning no row at all, which means not visible rather than zero. It is tempting to read that as a link-count effect. It is not evidence of one: those 21 are mostly the site's smallest niches, so the pages with the fewest links are also the pages with the least demand, and this data cannot separate the two. A site that doubled cannot be used to prove anything about a change made inside it.

The row at the other end is more useful. The most linked page on the site, best-action-games with 23 inbound links, earned zero clicks from 66 impressions over the same 28 days. Twenty-three links did not make a page succeed, which is the conclusion the internal links post reached by counting from the other direction. Links are a floor, not a lever, and a system that guarantees the floor is worth having precisely because the floor is all it can guarantee.

What the ranked guides say

I checked the search results for "does changing internal links hurt seo" and "are automatic related posts links good for seo" on 16 September 2026. Between them, seven of the seventeen ranked results are Reddit, Quora, Stack Exchange and YouTube. Position 1 on the second query is a Stack Exchange question asking almost exactly this, which is a question, not an answer.

• AIOSEO's internal links guide is roughly 4,000 words and recommends auditing for broken links, orphan pages and crawl depth. It has nothing on links that are configured and never render, and no measurement of its own.
• Yoast's related posts article explains how to automate related links with their own blocks and never addresses what happens to those links as new posts are published, which is the behaviour the automation creates.
• SearchPilot is the only ranked page with a measurement, and it is measuring something else: repointing internal links away from redirects, estimated at between -1% and +4% on target pages, which they call no detectable impact. It is a snapshot split test, not a link set changing over time.

Not one of them reports what a generated link system actually rendered. That is the gap this post exists to fill, and it is the same gap the internal links post found from the other direction: plenty of advice to add links, almost no measurement of what the links you already have are doing.

How to check your own

1. Count the rendered links, not the configured ones. Open one page, view source, and count the links in the related block. Compare that to what your config file or plugin says. If the two disagree, every audit you have run is wrong by the difference.
2. Find your cap. Every related-links system has a number: slots on the page, entries the template reads, items the query returns. Find it, then find the pages configured above it. Those are your silent losses.
3. Check the rule on the merged result. If you enforce a minimum inbound count, run it after merging, not on the branch. Two green branches can merge into a red main.
4. Decide whether links may move, once, on purpose. Automatic links that never change require hand-maintenance somewhere. Automatic links that change cost you attribution. Pick deliberately rather than discovering which one you chose six weeks later.
5. Record the date each change happened.This is the only part that makes the trade survivable. If a page's link set moved on 3 September and its clicks moved on 12 September, you want both dates written down before you start theorising.

The free triage report checks whether a URL is reachable and indexable in the first place, which is the question underneath all of this, and more of the AI-assistant SEO series works through our own data the same way.

FAQ

Are automatic internal links good for SEO?

They are good at the job hand-placed links keep failing: guaranteeing every page has inbound links. They are bad at staying still. On game-scout.app on 16 September 2026, every one of the 51 pages with generated links had at least 4 inbound links and none were orphaned, but adding a single new page moves the link set on pages nobody edited.

Does changing internal links hurt SEO?

Nobody has published a measurement that answers this, and neither have we. What changing them definitely costs is attribution: once a page's link set can move on its own, you can no longer tell whether a traffic change came from your edit or from the link shuffle. That is why the date each change happened is worth recording.

How many internal links does my page actually have?

Fewer than your configuration says, most likely. We configured 214 related links across 48 pages on game-scout.app and 192 of them render, because the component that draws them stops at 4 curated entries. Count what the page outputs, not what the config file or plugin setting lists.

Can I test internal linking changes across branches?

Not with a per-page rule alone. On 2 September 2026 four of our pull requests each passed the same three-inbound-links test against their own base branch, and the merged result orphaned a page. A rule about one page's link count is not preserved when two branches that each satisfy it are combined.

In your AI assistant

Ask your AI about your own site

TrafficTriage plugs into Claude, Cursor, and ChatGPT. Your assistant runs the 8 checks, reads your Search Console data, and can even check your site every morning. Free account, no API key, nothing to install.

Sign up freeSee how it works