Internal linking for small websites

I treat the links on leej.uk the same way I treat the scope of a small, focused Apple app: a short, deliberate set beats a large, automatic one that nobody maintains. The tools I use for a site of this size are the Internal Link Graph, the Internal Link Suggester and the Site Architecture Planner. The method below is what I run them through.

Why a 40-page site still gets this wrong

A site with forty or four hundred pages can still hide its best work. The usual pattern is not a lack of links. It is a lack of useful ones.

Typical symptoms:

• The header points at Home, Work, Blog and Contact. Everything else is expected to be found from a paginated index, or from search.
• A useful guide was published, linked once from the blog list, and then never mentioned again. Six months later it is effectively an orphan, even if the index page still lists it somewhere below the fold.
• Automated “related posts” blocks repeat the same three articles with anchors such as “Read more” or the raw title stuffed into every card.
• A URL change left the old path redirecting, but no in-body link was updated, so the new canonical has almost no internal links of its own.
• Footer links try to compensate by listing twenty pages in a keyword-rich list that appears on every URL. That is navigation noise, not a path a person would follow.

Crawlers use internal links to discover pages and to understand which ones you consider important. People use them to finish a job. If either group has to go back to the home page and guess, the site is poorly linked, however small it is.

Map the important pages, then the paths to them

Start with a list, not with a plugin. Write down, in one column, the URLs that actually earn their place: the home page, the main service or product pages, the contact page, two or three cornerstone guides, and any tool or article that you would be unhappy to see buried. This is the same scoping discipline as the iOS app MVP checklist. If you cannot name the important pages, you cannot link them on purpose.

Then, for each of those URLs, write the paths a person should be able to take:

• From the home page, in the main navigation or in the first screen of content, not only in a footer.
• From at least one hub (a section index, a tools index, an articles index).
• From one or two related pages in the body copy, where the link helps the sentence.

If a page cannot collect those three kinds of path, it is probably in the wrong place in the architecture, or it is not as important as you thought. The Site Architecture Planner is useful here as a sketch, not as a substitute for the list. A tree that looks tidy in a diagram and a site where the only link to “Pricing” is in a blog post from last year are not the same thing.

Do not obsess over “topical clusters” if you have three services and a dozen articles. Group pages by the job the reader is trying to do, then link within and across those groups when a sentence warrants it. A forced cluster with ten thin pages is worse than five complete pages that point to each other clearly.

Click depth, orphans and dead ends

Three measurements matter on a small site, and you can take them from a simple crawl or from the Internal Link Graph.

Click depth is the number of internal clicks from the home page to a URL, following the links a crawler or a person would actually find. Important pages should usually sit at a depth of one or two. A contact page at depth four, reachable only from the last article in a series, is a design error. There is no official maximum depth that search engines publish as a rule, and I will not invent one. The practical test is: would a new visitor, and a crawler that starts at /, reach this page without wandering?

Orphan pages are indexable URLs with no incoming internal links from the rest of the site. They may still appear in a sitemap, and they may still be indexed if they were submitted or linked externally, but you have given them no place in the site’s own map. After a rename, a migration, or a hand-built landing page, orphans are common. Every orphan is either a page that should be linked, or a page that should not be in the sitemap.

Dead ends are the opposite problem: a page that has no useful way onwards. A completed guide that never points at the related tool, the next article, or the contact page, forces the reader to stop. Navigation and a footer reduce the damage; they do not replace a relevant in-body link at the point the reader needs it.

A healthy small site looks like a shallow, well-connected graph: hubs in the middle, important leaves a click away, almost nothing floating unattached, and almost no page that cannot send you to a next step. You can see that shape in a link graph without crawling the whole web.

Anchors that describe the destination

The visible words of the link should tell a person, and a crawler, what is on the other side. “Internal linking for small websites” is a better anchor than “click here”, “this article”, or “learn more”. It is also better than pasting the same exact phrase into every link that points at the page.

A few habits that hold up:

• Write the sentence first, then make the natural phrase the link. If you cannot find a phrase that names the destination, the link may not belong in that sentence.
• Be specific. “XML sitemap coverage checks” is more useful than “SEO tips”.
• Vary the wording when several pages link to the same URL, as long as each anchor remains accurate. The destination is one page; the reasons to open it differ.
• Do not hide the destination in an image without a text alternative, and do not rely on a title attribute that most people will never see.
• Keep navigation labels short and stable. In-body anchors can be longer and more precise.

Anchor text still matters on a small site, not because there is a secret density to hit, but because unclear anchors waste the few links you have. The same clarity helps a page that is written to be quoted, as in writing for AI answers and search. If every card in a related block says “Read more”, you have spent a dozen links and said nothing.

Related blocks, navigation and in-copy links

These three layers do different work, and they should not be asked to replace each other.

Main navigation is the short list of section entries: the work, the writing, the tools, the contact page. It should change rarely. If you add every new article to the header, the header stops being a map.

Section indexes (/articles, /tools, a work list) are hubs. They exist so a crawler and a person can reach the members of a group without already knowing the slug. Keep them complete, paginate them cleanly if you must, and give each item a real title, not a thumbnail alone.

In-copy links are the ones that carry meaning. A paragraph that explains sitemaps should link the sitemap guide, and a paragraph about a tool should link the tool. These are the links I write by hand, and they are the ones I trust most.

Related blocks at the end of a page are a useful safety net, especially when the body already did some of the work. They work better when the suggestions are actually related, when the anchors are the page titles, and when the list is short. A related-posts widget that is only a recency list, or a keyword match on a single word, will slowly point everything at the same popular posts.

I use a related block and a small set of related tools on articles here, generated from a list I maintain in the article’s front matter, not from an unbounded “people also read” loop. The Internal Link Suggester is a way to spot candidates I have missed; I still choose the ones that belong in the sentence.

New pages should arrive already linked

A new URL should not wait for a monthly audit to be discoverable. Before it goes live, give it:

1. A place on the right hub page, even if that is just a new row on /articles.
2. At least one in-body link from an existing page that a person would already read on the same subject.
3. An entry in the sitemap, if you keep one, as described in the XML sitemap guide. A sitemap is not a substitute for a link, but it should not lag behind the HTML either.
4. A reason to exist that does not collide with a page you already have. If two URLs would fight for the same query, fix that before you add a third internal path; the keyword cannibalisation guide covers the check.

This is part of publishing, not a later SEO pass, just as a new screen in an app should be reachable from the existing interface when you maintain the app after launch. If you cannot find a genuine page to link from, that is a signal the new piece may be in the wrong section, or may be a duplicate.

When you replace a page, update the in-body links to point at the new URL. Do not leave the old path as a redirect farm that still collects all the internal anchors.

A monthly check that does not take an afternoon

Once a month, or after a batch of new pages, run a short pass:

1. Crawl the site, or export the current internal link graph. You do not need a commercial platform for a few hundred URLs.
2. List indexable pages with no incoming internal links. Link them, move them onto a hub, or take them out of the sitemap and reconsider whether they should be public.
3. Check click depth for the important pages you already named. If a money page or a cornerstone guide has slipped to the edge of the graph, add a path from a hub or from the home page.
4. Sample anchors that point at those important pages. If they are all “here” or all the same exact phrase, rewrite a few in context.
5. Follow a couple of paths as if you were a first-time visitor. If you get stuck, the graph has a dead end that a metric might still call connected, because the footer counted as a link.

That is enough. You do not need a weekly dashboard. You do need to do the check after migrations, URL changes, and any redesign of the header or footer, because those are the moments orphans appear.

A launch is a good time to run the same pass once, as part of a technical SEO launch checklist, before you announce the site.

What not to do

A few patterns look like internal linking and are not worth the mess:

• Do not use the footer as a dumping ground for keywords. A short list of section links is fine. A site-wide paragraph of exact-match anchors is ugly, and it dilutes the links that were written for a reason.
• Do not insert links that do not help the sentence. A density target will push you into this. There isn’t a useful official number of internal links a page “should” have. Add a link when it helps a person; stop when the paragraph reads like a directory.
• Do not rely only on JavaScript-only navigation if the first HTML response has no real anchors. Crawlers that do not run your scripts will not see the paths.
• Do not leave landing pages detached because a campaign brief said they should “stand alone”. If they are on your domain and indexable, they belong in the site’s map. If they should not be indexed, they have a different problem.
• Do not mass-link every page to every other page. A complete graph is not a useful graph.
• Do not treat a sitemap or a ping as an internal link. Discovery is not the same as being part of the site.

Key takeaways

• On a small site, internal linking is a short, deliberate map: important pages, shallow paths, and anchors that name the destination.
• Measure click depth, orphans and dead ends. You can do that with a simple crawl or a link graph; you do not need an enterprise tool.
• Write in-copy links by hand. Use navigation and hubs for structure, and related blocks as a safety net, not as the only path.
• Every new page should ship already linked from a hub and from at least one relevant existing page, and should not duplicate a URL you already have.
• Recheck the graph monthly and after URL changes. Avoid site-wide keyword dumps, empty “read more” anchors, and pages that exist only in the sitemap.

If you want a second pair of eyes on a small site that has grown a few orphans, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.