URL Structure Best Practices for SEO and Usability

A URL is the most permanent identifier a piece of web content has. Search engines use it as a ranking signal and a deduplication key; humans read it in results pages, share it, and edit it; links point at it for years. Yet URLs are routinely designed as an afterthought, generated from database IDs or auto-encoded from a headline, and the cost of that neglect shows up later as broken links, redirected traffic, and pages that look like spam to both crawlers and the people clicking them. A small set of conventions avoids almost all of it.

Keep URLs readable and stable

The single most important property of a URL is that it does not change. A URL is a contract: every external link, every bookmark, every saved citation points at it, and renaming it invalidates all of that at once. Plan the structure before launch, pick slugs you will not want to rename, and leave them alone afterward.

Good   https://example.com/blog/image-optimization-core-web-vitals
Good   https://example.com/tools/hash-generator
Bad    https://example.com/p?id=4827
Bad    https://example.com/Blog/Image_Optimization/Core%20Web%20Vitals
Bad    https://example.com/blog/2026/08/10/14/37/post-9

The two good examples share a shape: lowercase, hyphen-separated words, no query string, no date, no ID, short enough to read at a glance. The bad examples each break a different convention. The query-param-only URL gives crawlers nothing to work with, the mixed-case and space-encoded version is ugly and case-sensitive on some servers, and the deeply nested timestamped URL is both long and a maintenance problem the moment content is reordered.

When a URL genuinely must change, redirect the old one to the new one with a permanent redirect (HTTP 301). That preserves most of the search equity and the inbound links, but it is a bandage, not a fix. The redirect chain is now part of the site forever, and each hop is a small cost.

Slugs, separators, and case

The slug is the human-readable tail of the URL, and the conventions are well established even though they are not formally required by any spec.

• Lowercase, always. Domains are case-insensitive but paths can be case-sensitive depending on the server, and mixed-case URLs are a source of duplicate-content issues and 404 errors from people who typed them by hand.
• Hyphens, not underscores, not spaces. Google has long treated hyphens as word separators and underscores as part of the word. Spaces encode to %20, which is ugly and breaks when pasted into plain text.
• Short and keyword-relevant. Include the word or phrase the page is actually about, near the front. A slug of four to six words is plenty; longer is not better and looks worse.
• Drop stopwords and boilerplate. "the," "and," "a," and your own site name do not belong in the slug; they add length without adding signal.
• No special characters. Accents, ampersands, and punctuation either encode badly or render oddly. Stick to lowercase letters, digits, and hyphens.

Before  "The Complete Guide to Image Optimization (2026 Edition)"
After   image-optimization-guide

Generating the slug from a heading mechanically (lowercasing, replacing spaces and punctuation with hyphens, collapsing repeats, trimming stopwords) is exactly what the slug generator does, and doing it consistently beats inventing a convention per page.

HTTPS, query strings, and nesting depth

A few rules sit alongside the slug.

HTTPS everywhere, with redirects. HTTP URLs should redirect permanently to their HTTPS equivalent. Search engines treat the secure version as canonical, browsers warn users on insecure forms, and there is no good reason to serve plain HTTP in 2026.

Avoid query-param-only pages. Parameters are fine for filtering and sorting, but a page whose entire identity lives in a query string gives crawlers and humans nothing meaningful and tends to create near-duplicate URLs that all resolve to the same content. Give important pages a real path.

Keep the path shallow. Two or three levels of nesting is enough for almost any site. Deep trees look long, encode information that changes (the year, the category), and make restructuring painful, since moving a category means rewriting every URL under it.

Trailing slashes: pick one and be consistent. Some servers treat a path with and without a trailing slash as the same page, some treat them as different, and inconsistent handling produces duplicate-content issues. Choose one, enforce it with redirects, and set the canonical tag to match.

Encode reserved characters when they appear in parameters. Spaces, ampersands, and non-ASCII characters that legitimately need to be in a query value must be percent-encoded, or they will break the URL. The URL encode/decode tool does this round trip correctly; hand-encoding is where most subtle bugs creep in.

Try it: Slug Generator

Turn any title or text into a clean, URL-safe slug.

The payoff

None of these rules are novel, and that is the point. Search engines reward URLs that are stable, readable, and semantically meaningful, and so do the people who have to read them in a results page or paste them into a chat. The work is in applying the conventions consistently across the whole site at launch and then resisting the temptation to "improve" the slugs later, which is where most of the damage gets done. Get the structure right early and the URLs mostly take care of themselves for the life of the site.