SEO Silo

I start with a content audit. I export every URL from the site using a crawler – Screaming Frog or Sitebulb – and dump it into a spreadsheet. Next I map each page to a primary topic based on its target keywords and the user intent behind it. That topic becomes the candidate silo. I group clusters by searching for common keyword themes. For example, if I were working on an ecommerce site that sells climbing gear, I'd see groups around 'climbing shoes', 'ropes', 'harnesses' and 'carabiners'. Each of those gets its own silo.

Once the silos are defined I choose a pillar page per silo. This is the page I want to rank for the broadest term. For the climbing shoes silo, the pillar could be a category page like /climbing-shoes/ that lists all sub-types. If the site has a guide or comparison page, I might use that instead. I make sure the pillar page is substantial – at least 800 words of unique content, with an internal link structure that points deep into the supporting pages.

Then I link the silo. Every supporting page in that group gets a contextual link back to the pillar page. I also connect related supporting pages when it makes sense. For instance, a page on 'how to fit climbing shoes' could link to a page on 'climbing shoe materials'. But I keep cross-silo links minimal – maybe one or two per page, and only when the user journey benefits. I use breadcrumbs and navigation menus to keep click depth shallow. I aim for the pillar page to be reachable within two clicks from the homepage, and supporting pages within three.

I prefer virtual silos – internal links and navigation changes – over restructuring the URL hierarchy. That avoids 301 redirects and potential loss of ranking signals. You can see the difference in how I organise [website structure](/website-structure/) on other projects. Virtual silos also let me experiment: if a silo does not perform, I can adjust links without touching URLs. A real example: on one site I moved the pillar page from position 15 to position 5 in eight weeks just by consolidating internal links from related blog posts and adding a prominent link in the main nav. No URL changed.

I check the impact monthly using a [technical SEO audit](/technical-seo/) to see if crawl depth has decreased and if more pages from the silo are indexed. If I see orphan pages, I add links.

The biggest mistake I see is over-siloing. If you create a silo for every tiny subtopic – say 'blue climbing shoes', 'red climbing shoes' – you end up with dozens of silos that each contain two or three pages. Authority gets spread too thin. I set a rule: a silo needs at least three supporting pages of substantial content to be worth grouping. Fewer than three, and I fold those pages into a broader silo.

Another watch-out is ignoring user intent. A silo must make sense to a human reading it. If you force a link from a page about climbing ropes to a page about climbing shoes just because they're both in the 'climbing' family, the reader will bounce. I only link contextually. If the rope page discusses tying knots to carabiners, then a link to carabiners is natural. Otherwise, skip it. I've ruined silos by linking everything together – the navigation felt like a category dump, not a curated topic cluster.

Broken links and orphan pages kill silo effectiveness. After you rearrange internal links, run a crawl to check for pages that no longer have any inbound links from the silo. I do a quarterly link audit. If I find an orphan, I either add a link from the pillar page or redirect it to a relevant page in the same silo. Using a canonical tag can help if two pages within the silo are too similar – read more about [canonical tag](/canonical-tag/) handling.

Cross-silo linking is another trap. Your pillar page should not link to supporting pages in a different silo unless the connection is tight. Too many cross-silo links blur the topic boundaries that you worked to create. I allow a maximum of two cross-silo links per page, and those only from the pillar page, never from the supporting pages. Some sites also need to handle [duplicate content](/duplicate-content/) when products appear in multiple categories – that's a separate challenge, but it can be worsened by sloppy silo design.

Finally, if you use paginated lists within a silo – e.g. a paginated blog archive – check the [pagination](/pagination/) implementation. If pagination is not handled with rel next/prev or view-all, the paginated URLs may compete for the same keywords. I prefer to have a 'view all' option for smaller silos.

I used to believe silos demanded a complete URL restructuring. I'd plan elaborate directory hierarchies – /shoes/ /ropes/ – and then spend weeks implementing 301 redirects. That was unnecessary and risky. Virtual silos, where the grouping is done entirely through internal links and navigation, achieve the same topical focus without the migration headaches. I now only change URLs if the current structure is genuinely broken (e.g. /category1/ and /category2/ for the same topic).

I also assumed that every page had to live in exactly one silo. But some pages naturally bridge two topics. A 'best climbing shoes for beginners' page could belong in the 'climbing shoes' silo and the 'beginner gear' silo. My earlier approach forced me to pick one, which often meant losing valuable cross-referencing links. Now I allow a page to receive links from two silos as long as its primary pillar page remains the dominant inbound source. The canonical URL still points to the page itself, but I keep the internal link context clear.

I overlooked navigation. In my earlier silo builds, I would design the internal link structure perfectly on the pages, but the global navigation still listed all categories alphabetically. Crawlers entering from the homepage would see the flat menu and often discover pages outside the intended silo path. I now customise breadcrumbs and navigation menus to mirror the silo hierarchy. For instance, the main nav might list 'Climbing Shoes' and under it a dropdown to sub-categories. That alone improved crawl depth for my pillar pages.

Another mistake: focusing on link structure while ignoring content quality. A silo with thin supporting pages does not build topical authority. The pillar page might link to a 200-word product page and expect ranking benefit – it won't. I now enforce a minimum content threshold: every page in a silo must have at least 500 words of original text, or if it's a product page, at least a 150-word unique description plus user reviews. I also check [core web vitals](/core-web-vitals/) because if the pillar page loads slowly, all the linking in the world won't help rankings.