A URL is the only part of your interface that other people copy, paste, bookmark, print and link to. It outlives your design system, your CMS, and usually the team that chose it. That is why URL structure deserves a design decision rather than whatever the framework produced by default.
What a URL should communicate
Three things, in order:
- Where this page sits in the site's hierarchy.
- What the page is about, in words a human recognises.
- Nothing else — no implementation details, no session state, no timestamps of when the CMS happened to publish.
Compare:
https://example.com/solutions/thermal/heat-pump-modules
https://example.com/pages/detail.aspx?cat=3&sub=12&id=88271
Both work. Only one survives a platform migration with its meaning intact, and only one tells a user what they are about to open.
Conventions worth adopting
Lowercase, always. /Products and /products are different URLs to most servers and identical to most users. Pick lowercase and redirect the rest.
Hyphens, not underscores. heat-pump-modules tokenises into words; heat_pump_modules historically does not. This one is settled.
Short, meaningful segments. Three to five words per segment at most. Drop stop words where they carry nothing: /blog/how-to-audit-internal-links is fine; /blog/a-guide-on-how-you-can-audit-the-internal-links-of-your-website is not.
No file extensions on content pages. .html, .do, .aspx leak your stack and make migrations visibly breaking.
One trailing-slash convention. Either always or never, enforced by a 301. Both work; inconsistency does not.
Depth that matches the IA, not the database. If a product belongs to one category conceptually, /category/product is right. If it belongs to five, a flat /products/product-name is more honest than picking one arbitrarily — and your breadcrumb can still express the primary category.
Stop at three or four levels. Every additional level is another click from the homepage, which costs crawl priority and user patience.
Locale placement
For a multilingual site, the locale segment goes first:
/ko/solutions/thermal
/en/solutions/thermal
Not /solutions/ko/thermal, and not /solutions/thermal?lang=ko. A leading locale segment means routing, analytics, sitemap splitting, caching rules and hreflang generation can all key off one path prefix. It also means a crawler scoped to /ko/ crawls exactly the Korean site.
Use the language code (ko, en, ja), not the country code (kr, us), unless you genuinely have market-specific rather than language-specific sites. The distinction matters when you wire up hreflang, where kr is not a valid language value.
Should the default language have a prefix? Yes — /en/ and /ko/ is more consistent than a bare root for English plus /ko/ for Korean. Symmetry makes every downstream rule simpler.
Parameters
Parameters are fine for things that genuinely modify a query and should not be indexed separately:
?page=2— pagination?sort=price— ordering?q=keyword— search
They are not fine as the primary addressing mechanism for content. ?id=88271 is a database key exposed as an interface.
Two rules keep parameters from becoming a crawl problem:
- Order and casing should be deterministic.
?a=1&b=2and?b=2&a=1must not both be reachable. - Tracking parameters (
utm_*,fbclid,gclid) must never appear in internal links, and pages should canonicalise without them.
Our crawler strips these automatically when normalising, and it is worth understanding why: without normalisation, one page with five campaign tags looks like six pages, and the whole crawl budget conversation starts.
Changing URLs without losing traffic
Sooner or later a redesign changes the structure. The sequence that works:
- Inventory the current URLs. Crawl the live site and export every URL with its status code, canonical and title. (DeepAnalyzer produces this as an IA sheet, which doubles as the migration map.)
- Map old to new, one to one. Every old URL gets exactly one destination. Many-to-one is acceptable when pages genuinely merge; many-to-the-homepage is not — it is a soft 404 in disguise.
- Use 301, not 302. Permanent means permanent.
- Avoid chains. Old → new, in one hop. If you are on your third redesign, make sure redesign-one URLs point at today's URL, not at redesign-two's URL.
- Update internal links. Redirects are for external links and bookmarks. Internal links should point at the final address.
- Keep redirects for at least a year. Longer for anything with external backlinks.
- Submit the new sitemap and watch coverage per sitemap file for four to six weeks.
The website redesign checklist covers the wider migration; this is the URL-specific core of it.
A worked example
For a global brand site with products, solutions, support and a newsroom:
/ko/ Home
/ko/company/history Company → History
/ko/solutions/thermal Solutions → Thermal
/ko/solutions/thermal/heat-pump Solutions → Thermal → Heat Pump
/ko/products/lf21 Products → LF21
/ko/support/faq Support → FAQ
/ko/newsroom/2026-q3-results Newsroom → Article
/ko/legal/privacy Legal → Privacy
Every path reads as a breadcrumb, every segment is a real IA node, depth never exceeds three past the locale, and the whole English site is the same tree under /en/. That symmetry is what makes hreflang generation, sitemap splitting and IA documentation mechanical rather than manual.
FAQ
Do keywords in URLs help rankings?
Marginally, and far less than they used to. The stronger argument is human: a readable URL earns clicks in search results and gets shared with its meaning intact. Write for people; the small search benefit follows.
Should I include dates in blog URLs?
Usually not. /blog/post-title stays evergreen; /blog/2023/03/post-title signals age and makes updating a post feel dishonest. Dates make sense for genuinely time-bound content such as press releases or event pages.
Is a flat URL structure better than a nested one?
Neither is universally better. Nested URLs communicate hierarchy and make section-level analytics trivial. Flat URLs are more stable when items get recategorised. Use nesting where the hierarchy is genuinely stable, and flat addressing where items move between categories.
How do I handle product URLs when a product is in several categories?
Flat /products/name with a primary category in the breadcrumb. Nesting a multi-category product under one path creates duplicate reachable addresses, which you then have to canonicalise.
Can I use Korean characters in URLs?
Technically yes — they are percent-encoded and search engines handle them. In practice they become unreadable when copied into chat, email or a spreadsheet, which is exactly where URLs are shared. Romanised or English slugs are safer.