--- title: Internal links are the cheapest SEO feature canonical: "https://subarashi.dev/posts/2026-05-27-internal-links-are-the-cheapest-seo-feature/" pubDate: "2026-05-27T00:00:00.000Z" author: Anton description: "Anton explains why small technical sites should treat internal links as product infrastructure, not decoration." tags: [Workflow] --- Internal links are not glamorous. That is exactly why they work. For a small technical site, the cheapest growth feature is usually not a new design flourish, a social thread, or another page that floats alone in the archive. It is a better path between the pages that already exist. Search engines need those paths. Readers need them more. ## The problem Most small blogs accidentally publish islands. One post explains a useful idea. Another post covers a related failure mode. A topic page exists somewhere. The author page is technically live. The RSS feed works. The schema endpoint is there for crawlers. But none of it behaves like a system because the reader has to guess what to do next. That creates three quiet losses: - crawlers see pages, but not a strong map of priority - readers finish one article and leave instead of moving deeper - the site owner keeps adding content without compounding the older work This is how a site can have decent posts and still feel thin. ## The rule of thumb Every published post should answer one follow-up question before the reader asks it. That does not mean stuffing every paragraph with links. It means giving the page a job inside the larger site. A good internal link should do at least one of these things: - define the lane the post belongs to - point to the next practical step - connect the writer to their body of work - help a crawler understand which pages are hubs - rescue an older post from becoming a dead end That is why the public [topic hub](/topics/) matters. It gives the site lanes. The [Start Here guide](/start-here/) matters because it gives new readers a front door. The [writer pages](/authors/) matter because bylines become archives instead of labels. The links are small. The behavior change is not. ## The workflow For this site, I want every publishable post to pass a simple internal-link review. Before a post moves from draft to public, ask: 1. Does it link to the topic lane that owns the idea? 2. Does it link to at least one related post, tag, or writer archive? 3. Does the homepage, Start Here page, or topic hub have a reason to surface it? 4. Does the command palette or search index make the page discoverable after publish? 5. Does the post make an older page more useful? That last question is the one teams skip. Internal linking is not only about helping the new page rank. It is also how the new page pays rent. A safety post can point readers toward broader AI workflow notes. A Revit troubleshooting post can strengthen the BIM lane. A creator-tools post can connect a flashy demo to the more boring production-readiness checklist. When that happens, each article becomes a node in a useful map instead of another loose receipt. ## What to watch for There are easy ways to fake this and get no benefit. The first trap is footer-only linking. A footer full of links is fine, but it does not explain relationships. A crawler can see it. A reader usually ignores it. The second trap is generic anchor text. "Click here" is wasted context. "AI agent permission design" tells both the reader and the crawler why the destination matters. The third trap is link hoarding. If every sentence points somewhere, no link has priority. A good post usually needs a few deliberate paths, not a confetti cannon. The fourth trap is letting navigation drift from repo reality. If the public site says there are author archives, topic lanes, schema feeds, and review gates, the repository has to keep those surfaces real. Otherwise the site starts making claims the codebase cannot defend. That is why internal links belong in CI/CD thinking. They are not just editorial garnish. They are a cheap, testable way to keep the public surface honest. ## A practical pattern Use three link types: - **Hub links** to pages like [Topics](/topics/) and [Start Here](/start-here/). - **Identity links** to the writer archive, such as [Anton](/authors/anton/), [Cara](/authors/cara/), or [Zack](/authors/zack/). - **Continuation links** to posts that answer the next question. This pattern is boring enough to repeat. Good. Repeatable beats heroic. The goal is not to make every post rank by itself. The goal is to make the whole site easier to crawl, easier to trust, and easier to keep reading. ## Verdict Internal links are the cheapest SEO feature because they are mostly judgment, not budget. They turn scattered notes into a site architecture. They make new posts support old posts. They make writer pages and topic hubs earn their place. They give crawlers a cleaner map and readers a better next step. If a technical blog wants more traffic, it should not start by shouting louder. It should first make the useful paths obvious.