URL Architecture & Internal Linking Strategy

Your URL structure and internal link graph are the skeleton of your SEO. Get them wrong and nothing else matters. Here's how to build them right.

See the architecture
Mpheroane Harrison
· 11 min read · About Harrison

Your URL structure is the first thing Google sees when it crawls your site. Before it reads your title, your headings, your content, or your schema — it reads the URL. And from that URL alone, it starts forming assumptions about what the page is about and how it relates to other pages.

Most South African websites waste this signal entirely.

Why URLs are an architecture decision

A URL like example.co.za/p=123 tells Google nothing. A URL like example.co.za/services/web-design-johannesburg tells Google three things: this is a service page, it's about web design, and it's location-specific to Johannesburg.

That's not SEO trickery — that's information architecture. The URL encodes the page's position in your site's knowledge hierarchy, and Google uses that hierarchy to understand your content's relationships.

URLs that are planned before content is written produce better rankings than URLs that are generated after the fact. This is why URL architecture is a system intelligence concern, not an SEO afterthought.

Flat vs. hierarchical: the visual

Here's what most South African business sites look like (flat architecture):

example.co.za/ ├── web-design ← orphan, no parent ├── seo-services ← orphan, no parent ├── social-media ← orphan, no parent ├── about ← orphan, no parent ├── contact ← orphan, no parent └── blog ← container, but no hierarchy ├── post-1 └── post-2

And here's what a system-intelligent site looks like (hierarchical architecture):

example.co.za/ ← homepage ├── services/ ← hub page: all services │ ├── web-design/ ← child: web design │ ├── seo/ ← child: SEO │ ├── social-media-marketing/ ← child: SMM │ └── email-marketing/ ← child: email ├── about/ ← hub page: about │ ├── team/ ← child: team │ ├── mission-vision-goals/ ← child: MVG │ └── careers/ ← child: careers ├── blog/ ← hub page: all posts │ ├── web-design/ ← category: web design posts │ │ ├── system-intelligence/ │ │ └── performance-architecture/ │ └── seo/ ← category: SEO posts │ ├── why-sa-sites-fail-seo/ │ └── structured-data-guide/ ├── contact/ ← standalone └── privacy-policy/ ← standalone

In the flat version, Google sees five unrelated pages plus a blog. In the hierarchical version, Google sees two topical clusters (services and about) with parent-child relationships, plus a blog with categorised content. The hierarchical version communicates topical authority — Google understands that this business has deep expertise in services, not just random pages.

The 7 URL rules

1. Use lowercase, hyphenated slugs

/services/web-design not /services/Web_Design or /services/webdesign. Hyphens are the word separator Google recognises best.

2. Include primary keyword in the slug

/services/web-design-johannesburg is better than /services/our-main-offering. The slug should describe the page's content in keywords a human would search for.

3. Keep slugs short: 3–5 words maximum

/services/web-design not /services/affordable-professional-web-design-services-for-small-businesses. Long URLs get truncated in search results and dilute keyword relevance.

4. Never change URLs after publishing

Every URL change requires a 301 redirect, which loses a small amount of link equity. Plan your URLs right the first time so you never need to change them.

5. Use trailing slashes consistently

Choose either /services/web-design/ (with trailing slash) or /services/web-design (without) and stick to it. Both versions resolve to the same page, but inconsistent usage splits your link equity between two URL versions.

6. Remove stop words from slugs

/services/web-design not /services/the-best-web-design. Words like "the", "a", "is", "for", "and" add no keyword value and make URLs longer.

7. Every URL must be unique and permanent

No two pages should share the same URL. No URL should change over time without a 301 redirect. This sounds obvious, but I've seen WordPress sites with ?page_id=47 URLs that change when plugins are activated or themes are switched.

Internal linking as a system

Internal links serve three functions:

  1. Navigation: Help users find related content
  2. Crawlability: Help Google discover all your pages
  3. Link equity distribution: Pass authority from high-authority pages to lower-authority pages

Most sites only use internal links for function #1 (navigation menus and footers). System-intelligent sites design for all three.

The minimum internal linking per page

Hub pages and topical authority

A hub page is a comprehensive page that links out to all related sub-pages. It serves as the "table of contents" for a topic cluster. For example:

The /services/ hub page contains a brief description of each service, with links to each individual service page. Each individual service page links back to the hub page and to related service pages.

This creates a tightly interlinked cluster:

services/ ←→ web-design/ ←→ seo/
    ↑              ↑              ↑
    └──────────────┴──────────────┘
         (cross-linked cluster)

Google interprets this cluster as evidence of topical authority — this site doesn't just have a web design page; it has an interconnected body of knowledge about digital services. That's significantly more powerful than having the same pages in isolation.

Your homepage typically has the most external links pointing to it (from directories, social profiles, etc.). That gives it the highest "link equity" or "PageRank" internally. The question is: where does that equity flow?

In a flat site with only nav links, equity flows equally to all pages. In a hierarchical site with strategic internal linking, you can funnel equity toward your most important pages:

This isn't manipulation — it's architecture. You're using the structure of your site to signal which pages matter most, which is exactly what Google wants to understand.

Common SA-specific mistakes

Next: Component Reusability and Design Systems — how to build once, use everywhere, and maintain design consistency at scale.