SEO-friendly URL structure

A URL is one of the first things both a searcher and a crawler see about a page — visible in the search result itself, in a shared link, in a browser's address bar, before any content has loaded. This part covers what actually makes one SEO-friendly, separate from the folk wisdom that surrounds it.

Real words beat opaque IDs

Bad:   /tutorials/p?id=4471
Good:  /tutorials/python-requests-library

The second URL tells a searcher — and a search engine — what the page is about before either one loads it. This is a real, live URL pattern on this site: every tutorial's slug is the topic itself, not a database ID or a hash. Beyond the direct relevance signal, it's also just more trustworthy to click — a URL that reads like plain language earns more clicks in a result list than one that looks like an internal database reference.

Keep it shallow

Deep:     /content/2026/articles/tech/python/tutorials/requests-library/index.html
Shallow:  /tutorials/python-requests-library

A URL doesn't need to encode a page's entire category hierarchy in its path. Beyond readability, an unnecessarily deep structure can dilute how a crawler distributes its attention across a site — depth from the homepage is itself a weak signal search engines use when deciding how much to prioritize crawling a given page.

Hyphens, not underscores, not spaces

Wrong: /tutorials/python_requests_library
Wrong: /tutorials/python requests library
Right: /tutorials/python-requests-library

Search engines treat a hyphen as a word separator — python-requests-library parses as three distinct words. An underscore, by contrast, is historically treated as a single unbroken token in many contexts (python_requests_library as one long non-word) — the practical convention every major platform has converged on is hyphens, consistently.

Lowercase, consistently

Inconsistent: /Tutorials/Python-Requests-Library
Consistent:   /tutorials/python-requests-library

On a case-sensitive server, /Tutorials/ and /tutorials/ are technically two different URLs that could serve the same content — a duplicate-content problem (covered fully in part 10) created entirely by inconsistent casing, with no benefit gained anywhere in exchange.

A published URL is effectively permanent

Once a URL is indexed, shared, and possibly linked to from other sites, changing it breaks every one of those references — a search engine has to rediscover and re-rank the new URL from scratch, and every existing backlink (part 16) now points at a dead page unless a redirect is in place. If a URL genuinely has to change, a permanent (301) redirect from the old path to the new one preserves both the ranking signal and the click from anyone following an old link.

# A minimal redirect rule, conceptually
/tutorials/old-slug-name → 301 → /tutorials/new-slug-name

Next: internal linking — how the pages already on a site pass authority and context to each other, entirely independent of any external factor.