How to Build a Website Silo Structure with Internal Linking

Internal linking is the practice of connecting pages on the same domain so that readers and crawlers can move between them along a predictable path. It decides which pages get discovered, how often they get recrawled, and how much of a site's authority reaches the pages that actually bring in revenue.

A website silo structure takes that idea further. Every URL sits under one clear parent topic, most contextual links stay inside that topic, and the shape of the site matches the shape of the subject matter. Search engines read the pattern as evidence that a site covers a subject properly rather than in passing.

This guide covers what internal links pass, how click depth and crawl budget interact, what a clean URL structure looks like, how many links a page can reasonably carry, and how to run an internal linking audit without breaking what already works. The earlier planning stage, deciding which pages should exist at all, is covered in our guide to planning a website structure.

An internal link points from one page on a domain to another page on the same domain. Search engines follow those links to find URLs, and they read the anchor text and the words around it as a description of the destination. A page with no incoming internal links is, from a crawler's point of view, a page that has not been published yet.

Internal links do three separate jobs, and mixing them up is where most link plans go wrong:

• Discovery. A crawler reaches a URL by following a link to it. XML sitemaps help, but links are what get a page requeued on a regular schedule.
• Context. Anchor text and the sentence around it tell search engines what the destination page covers, in words the destination page did not write about itself.
• Distribution. Authority earned by one page flows outward along its links, so the pages you link to most often are the pages you are nominating.

External links point at other domains and work as third-party endorsement. Both types matter, but only internal links are fully under your control, which makes them the cheapest structural improvement available to almost any site. That is the short answer to what internal and external linking in SEO actually separate.

Crawling starts from URLs a search engine already knows and spreads outward along links. As Google's documentation on how Search works describes, a bot fetches a page, extracts its links, queues the new addresses, and repeats. Pages a crawler reaches cheaply get refreshed often. Pages sitting behind four or five hops get visited rarely, and sometimes never.

Three measurements explain most crawl problems:

• Click depth. The number of clicks from the homepage to a page. Three is the working ceiling we apply to commercial pages, and a site gets flagged when more than 20% of its indexable URLs sit deeper than that.
• Orphan pages. URLs with zero incoming internal links. For pages that carry revenue, the only acceptable share is 0%.
• Crawl budget. How much crawling a site is granted. Google's crawl budget guidance puts the threshold high: it becomes a genuine constraint above roughly one million pages, or above ten thousand pages that change every day.

Below those thresholds, crawl budget optimization is rarely the real bottleneck. What looks like a crawl budget problem on a 400-page site is almost always a linking problem wearing a disguise: duplicate parameter URLs, faceted navigation with no controls, or a section reachable only from the footer.

According to Web.dev's guide to making content discoverable, a crawlable link is a plain anchor element with an href attribute. Menus built from buttons, spans, or click handlers look like navigation to a person and like nothing at all to a crawler.

A link passes three things at once: a crawl path, an anchor-text description, and a share of the linking page's authority. Knowing which of the three you need decides where the link belongs. A link added for discovery works from navigation or a hub page. A link added for relevance has to sit inside a paragraph, next to the words the destination should rank for.

The benefits tend to show up in a predictable order:

• New pages get indexed in days rather than weeks, because a linked page enters the crawl queue on the next visit to the page that links to it
• Pages start ranking for the phrases used in their anchors, since anchor text is one of the few descriptions of a page written by someone other than its author
• Deep pages stop leaking, because authority that used to dead-end on the homepage now reaches category and detail pages
• Editors stop rewriting the same background section, because they can point at the page that already covers it

Google's guidance on crawlable links is blunt about the mechanics: if the link is not an anchor tag with a resolvable href, none of the above happens. Everything else in this article assumes that basic condition is met.

URL structure is the part of internal linking that people can see. As Google's URL structure best practices put it, a URL should describe its content in words a person could read out loud over the phone. The pattern that survives redesigns is short, lowercase, hyphenated, and organised by topic rather than by whatever software happens to generate the page.

The rules that hold up across projects are unglamorous:

• One directory level per real topic, not one per database table
• Words a customer would use, not internal product codes
• Hyphens as the word separator, never spaces or capital letters
• No session IDs, tracking parameters, or sort orders inside indexable URLs
• Stable slugs, because every change costs a redirect plus a fraction of the value of every link pointing at the old address

Deep directory paths are not penalised on their own. The damage comes from what usually travels with them: pages that need five clicks to reach and category URLs nobody bothers to link to. Keep the path readable and the linking work that follows gets easier.

A silo structure groups every page under exactly one parent topic and keeps contextual links inside that group. A topic cluster is the softer version of the same idea: one pillar page covers a subject broadly, supporting pages cover its parts, and every supporting page links back to the pillar. Both models make the boundaries of a subject legible to a search engine.

The difference is how strict the walls are. A silo limits cross-links between groups so authority concentrates. A cluster allows them wherever a reader benefits. We treat the split as a working convention rather than a rule: a hub page should send at least 70% of its contextual links to pages inside its own group and spend the remainder wherever the reader gains something.

Silos fail in one specific way. When a business sells three services and a customer question spans two of them, a strict silo forces the writer either to duplicate the answer or to leave the reader stranded at a wall. If the choice is open, start with clusters and tighten toward silos only where the topics genuinely do not overlap.

Flat and deep describe the same site measured from the homepage. A flat structure keeps most pages within two or three clicks. A deep one nests content across four levels or more. Neither is correct in the abstract, because a 60-page consultancy site and a 200,000-item catalogue need different answers. The trade-offs are easier to judge side by side.

There is no published limit. Google retired its old guidance of roughly one hundred links per page and never replaced it with a number, so anyone quoting a hard ceiling is quoting a convention rather than a rule. What replaced the limit is a judgement call about attention, because every extra link divides both the reader's focus and the authority the page hands onward.

The conventions we apply on client sites:

• A long-form article carries five to fifteen contextual links, weighted toward the pages it is meant to support
• A category page links to its children and its parent, and little else
• A navigation menu exposes sections, not every page inside them
• Footers carry legal and utility links, not a second sitemap

Count the links a template already emits before adding more. A page with 300 outbound links is not passing much through any single one of them, and a header that repeats the same 80 links sitewide is spending most of a site's link budget on pages that were already easy to reach.

Most linking damage is invisible in a browser. A page looks fine, ranks for nothing, and nobody investigates because the failure sits in how the page connects rather than in what it says. The errors below turn up in almost every audit, roughly in order of how much traffic they return once fixed.

Orphan and Near-Orphan Pages

An orphan page has no incoming internal links at all. A near-orphan has one, usually from a paginated archive that rotates it out within a month. Both behave the same way in search: indexed slowly, recrawled rarely, and ranked as though nobody on the site considers them important.

Anchor Text That Describes Nothing

Links reading click here, read more, or this page waste the one chance a site has to describe a destination in its own words. Replace them with the phrase the destination should rank for, then vary the wording so twenty links do not all carry an identical anchor.

Links That Only Exist in JavaScript

A menu that renders links through click handlers is not a set of links. If the markup has no anchor tag with an href, a crawler queues nothing, and every page behind that menu depends on being found somewhere else.

Redirect Chains Left Behind by Renames

Each rename leaves old links pointing at an address that now forwards somewhere else. One hop is tolerable. Three hops wastes crawls and dilutes what the link passes. Update the links in the source content rather than relying on the redirect map to carry them forever.

An internal linking audit answers four questions: which pages have no incoming links, which important pages have too few, which links are broken or redirected, and which anchors describe the wrong thing. You need a full crawl of the site plus a list of the pages that matter commercially. Everything after that is comparison work.

The sequence that produces usable output:

1. Crawl the site and export every URL with its inlink count, click depth, and status code
2. Export the same URL list from the XML sitemap and from analytics, then diff the three to expose orphans
3. Rank the commercial pages by inlink count, and mark anything receiving under 1% of the site's internal links as under-linked
4. Pull anchor text per destination and look for pages where every anchor is identical or generic
5. Filter for links returning 3xx or 4xx codes, and fix them at the source rather than in the redirect map
6. Write the fix list as page-level tasks, because a linking task nobody owns never ships

Repeat the crawl a month after the fixes land. Inlink counts move immediately, but ranking movement on the target pages usually needs a recrawl cycle to show up in post-launch performance data.

Any crawler that reports inlinks per URL will handle the structural half of the job. The reporting half needs search performance data, because a page with plenty of internal links and no impressions has a different problem from a page with impressions and almost no links. Most teams settle on one crawler plus one performance source.

What each category is good for:

• Desktop crawlers. Screaming Frog and Sitebulb map the whole link graph, report click depth per URL, and export inlink and outlink lists that spreadsheets can diff.
• Cloud site audits. Ahrefs and Semrush run the crawl on a schedule and flag orphan pages against their own index, which catches URLs a fresh crawl would miss.
• Google Search Console. The Links report shows which internal pages Google actually recorded, which is the only view that reflects what a search engine saw rather than what your crawler found.
• Log file analysis. Server logs show which URLs bots requested and how often, and settle crawl budget arguments that no crawler can.

None of these tools decides what should link to what. They surface the gaps; the topical judgement stays with whoever knows the business.

A redesign is where internal linking most often goes backwards. Templates change, sections merge, and contextual links that lived inside old body copy quietly disappear. The pages still exist and still rank, right up until crawlers stop finding paths to them. Capturing the old link graph before launch is the only defence that reliably works.

The checklist we run on every website development project that replaces an existing site:

• Crawl the live site and archive the full inlink and outlink export before anything changes
• Map every old URL to a new one, including URLs that will be merged rather than moved
• Rebuild contextual links inside the migrated body copy, not just the navigation
• Verify that the new templates emit real anchor tags, not scripted click handlers
• Recrawl on the staging environment and compare inlink counts page by page against the archive
• Recrawl again 48 hours after launch, because template edits made during launch week are where links usually vanish

A redesign that keeps the link graph intact is also the cheapest moment to improve it. You can see how the sequencing works across a full project in our development process, and examples of the result in our portfolio.

Internal linking is the part of technical SEO a content team can own without touching the codebase. Adding a paragraph link costs nothing, and the compounding effect across a year of publishing beats most one-off technical fixes.

A silo structure is worth the extra discipline when a business covers several distinct subjects and needs each one to read as deep rather than incidental. When the subjects overlap, looser topic clusters do the same work with fewer arguments about where a page belongs.

Whatever the model, the maintenance habit matters more than the diagram. Crawl the site quarterly, watch the orphan count, keep anchors descriptive, and repair links at the source instead of stacking redirects. Those four habits hold a link graph together long after the launch that created it.