URL structure: principles of SEO-friendly URLs

What is URL structure

URL structure is the set of rules by which page addresses are formed on a site: length, folder hierarchy, slug format, use of parameters, and protocol. A good structure is readable by humans, understandable to a crawler, and remains unchanged for years. A bad one creates duplicates, breaks indexing, and forces you to rewrite redirects every time the marketing strategy shifts.

URL is one of the few SEO signals Google has openly called a ranking factor for more than fifteen years. It's not the strongest factor, but it's one of the cheapest: you configure it once during development and it works for years without edits. Mistakes at this level are painful to fix — every changed URL requires a 301 redirect and a fresh evaluation by the search engine.

URLs by the numbers

Anatomy of a URL: seven parts

Before building structure, let's break down what a URL consists of. RFC 3986 describes seven components; in the SEO context, all of them matter except user-info and fragment:

https://www.example.com:443/blog/seo/url-structure/?utm=email#summary
│  │   │            │   │                          │            │
│  │   │            │   │                          │            └─ fragment (anchor)
│  │   │            │   │                          └────────────── query (GET parameters)
│  │   │            │   └─────────────────────────────────────── path
│  │   │            └─────────────────────────────────────────── port (usually hidden)
│  │   └──────────────────────────────────────────────────────── host (domain)
│  └──────────────────────────────────────────────────────────── subdomain
└─────────────────────────────────────────────────────────────── scheme (protocol)

Why URL matters for SEO

URLs influence ranking both directly and indirectly. The direct contribution is small — Google has repeatedly confirmed that a keyword in the URL gives only a "tiny" boost. The indirect impact is much larger: URLs shape snippet click-through rate, user trust, and crawler predictability.

These signals add up. Each one is weak on its own, but in combination URLs become a quiet, persistent advantage — especially for the long tail, where competition for every percent of CTR is critical.

Nine rules of a good URL

Google's URL recommendations have barely changed in fifteen years. The nine rules below are a compilation of official documentation and empirical research from Backlinko, Ahrefs, and Moz. They apply to any stack — from WordPress to Next.js.

• Use Latin characters (unless your audience is local-only). Cyrillic technically works through punycode, but it copies poorly in messengers, breaks when printed, and lowers CTR in international results. /blog/url-structure/ is better than /блог/структура-url/.
• Separate words with hyphens, not underscores. Google explicitly recommends hyphens. Underscores _ merge words during parsing: url_structure is one token url_structure for the bot, not two words.
• Lowercase only. URLs are technically case-sensitive (on UNIX servers). /Page/ and /page/ are two different addresses, creating duplicates. Force lowercase at the server level.
• Length: shorter than feels necessary. Optimum is 50–75 characters. If the URL is longer, you usually have extra words in the slug or redundant categories.
• Folder depth: maximum three levels. /category/subcategory/page/ is the ceiling for most sites. The crawler reaches deeper pages less often, and users struggle to navigate.
• No stop words. Drop and, or, the, a from the slug: /how-to-fix-error/ is better than /how-to-fix-an-error-in-the-code/. Stop words help neither ranking nor readability.
• Keyword: once, and early. Don't repeat the keyword twice (/seo/seo-guide/). Place it as close to the domain as possible: the closer to the root, the higher the weight.
• No IDs or hashes in the slug. /article-12384/ or /post-a3f9b2c8/ are meaningless to humans and add no semantics. Use descriptive slugs that translate the topic.
• The URL must not change. A published address is a commitment. Any change requires a 301 redirect and leaks some equity. Think about structure upfront.

Depth and folder hierarchy

The folder structure in a URL isn't just aesthetics — it's a site map for the crawler and the user. Click depth (the number of clicks from the homepage to a page) correlates with how often Google re-crawls a page and how quickly it discovers new content.

URL depth is not the same as click depth. A page can physically live at /shop/laptops/macbook-pro-14/ and still be one click from the home page via strong internal linking. The search engine considers both signals: the URL path and the actual distance in the link graph.

www, HTTPS, trailing slash and case

Four technical settings that produce duplicates most often. Each is solved at the server level once — but if you skip it, the search engine sees up to eight versions of the same page:

http://example.com/page
http://example.com/page/
https://example.com/page
https://example.com/page/
http://www.example.com/page
http://www.example.com/page/
https://www.example.com/page
https://www.example.com/page/

HTTPS

Mandatory since 2018: Chrome marks HTTP sites as "not secure", and Google uses HTTPS as a weak ranking signal. The setup is a single redirect in nginx or apache:

# nginx — 301 from HTTP to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

www or non-www

Technically equivalent. At the DNS level www is a subdomain, but Google and Yandex treat it as an alias when a 301 is configured. Without www is slightly shorter and more modern; with www is more convenient for cookies (you can separate them by subdomain). The key rule: pick one variant and 301-redirect all traffic to it.

# nginx — 301 from www to non-www
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Trailing slash

A trailing slash (/page/ vs /page) — two different addresses for the server. Convention: directories end with /, files don't. On modern sites every page is a directory, so a single strategy is always with a trailing slash (or always without). Next.js and WordPress use trailing slash by default.

// next.config.ts — enforced trailing slash
const nextConfig = {
  trailingSlash: true,  // /blog/page/  instead of  /blog/page
};
export default nextConfig;

Case

URLs are case-sensitive on most servers (Linux/UNIX). /Page/ and /page/ are two URLs, two duplicates. Force the entire path to lowercase at the reverse proxy or application level:

# nginx — redirect URLs to lowercase (Lua module)
location ~ [A-Z] {
    rewrite ^/(.*)$ /$1 last;
    set_by_lua_block $lower_uri {
        return ngx.var.uri:lower()
    }
    return 301 $lower_uri;
}

URL templates by page type

Different content types require different URL templates. Below are proven patterns for six page types that appear on 90% of websites.

For e-commerce — a separate topic. A product card can live by two schemes: /shop/category/product/ (with category) or /shop/product/ (flat). The first is better for category SEO (the URL signals belonging), the second is better for moving products between categories without redirects. The choice depends on how often products change categories.

Localisation and multilingual URLs

For a multilingual site, URLs are the first part of the strategy. Google recommends three approaches, each with its own trade-offs:

Subfolders win in 80% of cases. They are easier to manage, cheaper for SSL and hosting, and all link equity works for one domain. This is exactly the approach seohead.tech uses: the primary language on the root, the second under /en/.

Slugs in localised URLs are a contentious topic. Translating the slug (/en/url-structure/ ↔ /struktura-url/) gives a better CTR for each language and signals relevance more precisely. The downside — harder to maintain, you need to manage hreflang and redirects when translations change. For most projects, the compromise is to translate only blog slugs and keep a single slug for technical pages.

Common mistakes and how to fix them

Eight most common URL mistakes that come up in SEO audits. Each can be fixed within one sprint; the cost of inaction is gradual loss of rankings and crawl budget.

• Duplication through GET parameters. UTM tags, sortings, and filters create hundreds of variants of one page. Fix: rel="[canonical](/glossary/canonical)" to the primary URL + URL Parameters in GSC.
• Mixed trailing slash. Some pages with /, some without. The search engine sees duplicates. Fix: single convention + 301 from all non-matching variants.
• Cyrillic in URLs for a global project. /услуги/ becomes /%D1%83%D1%81%D0%BB%D1%83%D0%B3%D0%B8/. Fix: transliteration (/uslugi/).
• Too deep a hierarchy. /shop/electronics/computers/laptops/apple/macbook-pro/ — six levels. Fix: a flat structure with categories as facets.
• IDs in the URL instead of a slug. /article?id=12384 or /post/12384/. Fix: switch to semantic URLs + 301 from old IDs.
• Changing a URL without a 301. Any address change without a redirect = loss of equity and traffic. Fix: always set up a 301 when renaming.
• Case in URLs. /Catalog/ and /catalog/ are two duplicates. Fix: enforce lowercase on the server.
• Infinite redirect chains. A → B → C → D. Each link leaks weight. Fix: always 301 directly to the final URL.

# Check redirect chains via curl:
curl -sILo /dev/null -w "%{http_code} %{url_effective}\n" \
     -L https://example.com/old-page/

# Find URLs with uppercase letters in nginx logs:
grep -E 'GET /[a-z]*[A-Z]' /var/log/nginx/access.log | head

# URL audit via Screaming Frog:
# 1. Run a full site crawl
# 2. Open the URL tab → Underscores / Uppercase / Non ASCII Characters
# 3. Export the list of problematic URLs and plan redirects

FAQ

Answers to the most common URL structure questions that come up during audits and redesigns.

Summary

URL structure is a decision you make once and live with for years. A good URL is short, human-readable, reflects content hierarchy, and is stable over time. Three core principles — Latin lowercase, hyphens instead of underscores, max three folder levels — close 80% of common mistakes.

Start with an audit of current URLs: Screaming Frog → "Underscores", "Uppercase", "Non ASCII Characters" reports. That gives you a problem map within an hour. Then build an old → new table, set up 301s, and update internal links. Don't rush a mass migration before peak season: Google takes 4–8 weeks to re-evaluate.