Optimizing Your Page URL Structure for Search Engines

Why URL structure still matters

A URL is the address of a page, but it also does quiet work for users and search engines. People see it in search results, in shared links and in the browser bar. Crawlers use it to discover and organise pages. A clear, consistent structure makes a site easier to crawl, easier to maintain and easier to trust at a glance.

It helps to keep expectations realistic. Google has described words in URLs as a very small ranking factor, and it often shows a breadcrumb trail rather than the full address in results. Nobody climbs to the first page just by rewriting slugs. The real benefits are indirect: fewer duplicate URLs, cleaner crawling, more readable links and less maintenance pain later. This guide covers the practices that deliver those benefits and the mistakes that undo them.

Anatomy of a URL

Take this example address. Each part of it can be designed deliberately:

https://www.example.com/blog/dns/what-is-a-cname-record?ref=newsletter#examples

• Scheme: always HTTPS for a modern site.
• Host: your domain, with or without www. Pick one and redirect the other.
• Path and slug: the part you control most, describing where the page sits and what it is about.
• Query string: parameters for filters, tracking or sessions. These are the main source of duplicate URLs.
• Fragment: the part after #, which points to a section of the page. Search engines generally ignore it for indexing.

The domain name itself is part of your URL structure too. A short, memorable name is easier to share; the TLDix domain name generator can help when you are choosing one, and our article on domain extensions covers the TLD choice.

Best practices for readable slugs

• Describe the content. /guides/renew-ssl-certificate tells users what to expect; /p?id=8812 does not.
• Use hyphens to separate words. Google recommends hyphens over underscores, which may not be treated as word separators.
• Use lowercase. Paths are case-sensitive on many servers, so /About and /about can become two separate URLs.
• Keep slugs short. Drop filler words where meaning survives without them. There is no fixed character limit, but concise URLs are easier to read and less likely to be truncated.
• Avoid keyword stuffing. One natural phrase is enough. Repeating keywords looks spammy to people.
• Leave dates out unless they matter. A year in the slug makes evergreen content look stale and forces a URL change when you update it.
• Handle non-ASCII text deliberately. Google supports UTF-8 characters in URLs, which browsers display readably. Transliterating to ASCII is also fine; just be consistent across a language version.

Designing folders and hierarchy

Folders group related pages and reflect how users think about your content. A logical hierarchy also makes analytics and crawl reports easier to read, because you can filter by section.

Keep it shallow

Two or three levels are usually enough. Deep nesting makes URLs long and brittle without adding value. What matters more for crawling is click depth: how many links it takes to reach a page from the home page. A page can live at a short URL and still be buried if nothing links to it.

Mirror real sections

Use folders that correspond to actual sections, such as /blog/, /docs/ or /tools/. Avoid putting categories into blog post URLs if posts change categories often, because each move creates a URL change.

International sites

For multilingual content, language folders such as /de/ and /es/ are simple to manage on a single domain. Pair them with hreflang annotations so search engines show each audience the right version.

Parameters, duplicates and canonicalisation

The biggest URL problems are rarely ugly slugs. They are many URLs showing the same content. Common sources include:

• http and https, or www and non-www versions both resolving
• Trailing slash and no trailing slash both returning 200
• Tracking parameters such as utm_source
• Sort and filter parameters on category pages
• Session IDs in URLs
• Printer-friendly or AMP duplicates

Fix them in layers. First, redirect protocol and host variants to one preferred version. Second, choose one trailing slash style and redirect the other. Third, link internally only to clean, canonical URLs. Fourth, add a canonical tag to each page pointing at its preferred address:

<link rel="canonical" href="https://example.com/blog/dns-ttl-guide">

A canonical tag is a strong hint, not a command; Google may choose a different canonical if your signals conflict. Keep sitemaps, internal links and redirects pointing at the same version.

For faceted navigation, decide which filter combinations deserve indexable pages and keep the rest out of the crawl, for example by not linking to them or by disallowing parameter patterns in robots.txt. Be careful: a URL blocked in robots.txt cannot be crawled, so Google cannot see a canonical or noindex tag on it.

Server rules for consistent URLs

A few server-level rules enforce your choices automatically. In Nginx, redirecting www to the bare domain over HTTPS looks like this:

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Test the result with curl and confirm each variant reaches the final URL in a single hop:

curl -sIL http://www.example.com/blog/ | grep -iE "^(location|http)"

Our guide to HTTP Strict Transport Security explains how to make the HTTPS choice stick in browsers too.

Changing URLs without losing traffic

Existing URLs have accumulated links, bookmarks and search history. Changing them can cause temporary ranking fluctuations even when done well, so only restructure when the gain is clear, such as removing duplicate systems, fixing parameter-based URLs or merging overlapping content.

1. Export every current URL from your CMS, sitemap and logs.
2. Map each old URL to its closest new equivalent.
3. Implement one-hop 301 redirects and test a sample before launch.
4. Update internal links, canonicals, hreflang and sitemaps to the new URLs.
5. Monitor 404s and the Page indexing report in Search Console for several weeks.

The same process applies at a larger scale when a whole domain moves; see fixing broken links after a domain transfer.

Common URL mistakes in popular platforms

Content management systems and shop platforms generate URLs automatically, and their defaults are not always ideal. Check these settings early, before many pages exist:

Content management systems

• Plain permalinks. Some installations start with numeric or query-based URLs. Switch to a post name structure before publishing.
• Attachment pages. Media uploads can get their own thin pages. Redirect them to the parent content or the file itself if your platform allows it.
• Tag and archive sprawl. Dozens of tag pages with one or two posts each create many low-value URLs. Use tags sparingly or keep thin archives out of the index.

Online shops

• Products in multiple categories. A product reachable at several category paths creates duplicates. Use one canonical product URL that does not depend on the category.
• Filter and sort parameters. Colour, size and price filters can generate thousands of combinations. Decide which deserve indexable landing pages.
• Discontinued products. Redirect to a close replacement or the parent category when one exists; otherwise return a 404 or 410.

Auto-generated slugs

Most platforms build the slug from the title when you first save a page. Review it before publishing: titles are often longer than a good slug needs, and editing the title later does not usually change the URL, which is the safer behaviour.

A quick URL checklist

• One protocol, one host, one trailing slash style
• Lowercase, hyphen-separated, descriptive slugs
• Shallow, meaningful folders
• No session IDs; tracking parameters kept out of internal links
• Canonical tags consistent with sitemaps and internal links
• Redirect maps saved for every past change

Good URL structure is mostly about consistency. Make sensible decisions once, enforce them at the server and CMS level, and avoid changing addresses that already work.