URL Structure Best Practices

URL structure best practice is a topic where Google has its own guide, and it is shorter and stricter than the seven rules in the typical checklist. It has two blocks: requirements, without which a site is crawled badly or not at all, and recommendations for clarity. Much of the familiar — "no more than five words", "no stop words", "no deeper than four levels" — is absent from it. This lesson covers what is confirmed, what is not, and how not to break a site when addresses change.

It rests on the URL structure guide and the canonicalization documentation.

Requirements: without them crawling goes badly

The guide warns that if addresses do not meet these criteria, Google will likely crawl your site inefficiently — including extremely high crawl rates, or not at all. There are three criteria:

• The standard. Google supports URLs as defined by IETF STD 66; characters the standard defines as reserved must be percent encoded.
• Fragments. Don't use fragments to change the content of a page, as Google Search generally doesn't support them; with JavaScript, use the History API. Covered in the lesson on navigation.
• Parameters. An equal sign separates key-value pairs and an ampersand adds parameters; multiple values for one key can be listed with a comma. Non-standard schemes with brackets and colons, or double commas, are not recommended.

Recommendations: so an address is understandable

On hyphens and underscores — precisely

The guide settles this with a recommendation, not a ban, and the reason given is not the one usually retold. Underscores are discouraged for historical reasons: the style is already commonly used for denoting concepts that should be kept together, for example by programming languages to name functions such as format_date. Joining words together, as in greendress, is not recommended either. The statement "Google reads technical_seo as one unknown word" does not appear in the documentation.

Cyrillic and other scripts

For sites not written in Latin this is the most practical part of the guide: write words in the audience's language, and encode them in links. Its own example: an address containing gemüse should appear in an href as gem%C3%BCse. So a Russian or Ukrainian address is acceptable, but in the markup of a link it is encoded. What addresses a crawl ends up with is what the site crawler shows.

What is not in the documentation

These widespread claims do not appear in the documentation, so they cannot be presented as rules:

• "no more than five words in the path" and "drop stop words";
• "a keyword in the address is a weak but real relevance signal";
• "every slash costs PageRank, no deeper than four levels";
• "you must choose a preferred domain in the search console".

That does not make a short readable address bad: the guide itself asks for readability. But figures such as "five words" and "four levels" are habit, not a norm.

Duplicates caused by addresses

The guide names the main source of trouble: overly complex URLs, especially those with multiple parameters, create unnecessarily high numbers of URLs pointing to identical or similar content, so Googlebot may consume much more bandwidth than necessary, or Google Search may be unable to completely index all the content. The typical causes are listed there too: filters combined additively, and irrelevant parameters — referral, sorting, session. How to deal with them is covered in the lesson on navigation and in the faceted navigation guide.

One form of an address: protocol, www, slash

The same material can be reachable as http and https, with and without www, with and without a trailing slash. To Google these are different strings handled under IETF STD 66, so in practice one form is chosen and pinned in two ways: a permanent redirect and rel=canonical. For the slash and www the documentation has no separate rules; this follows from the general principle. For the protocol, though, it is specific: Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues such as an invalid SSL certificate, insecure dependencies other than images, a redirect to or through an HTTP page, or a rel=canonical to the HTTP version.

Which redirect

The difference is described outright. A permanent redirect is used by the indexing pipeline as a signal that the target should be canonical; use it when you're sure the redirect won't be reverted. With a temporary redirect Googlebot follows it but the indexing pipeline doesn't use it as a canonical signal, and the source page is shown in results. Server-side 301 and 308 redirects have the highest chance of being interpreted correctly. So the move from HTTP to HTTPS, and from a secondary form to the main one, is made permanent. Chains are checked by the redirect check.

Canonical: why and how

An important caveat from the duplicates guide: it is generally not critical to specify a canonical preference, but there are reasons to do it explicitly — to choose the address shown in results, to consolidate signals, and to save crawling on duplicates. In the element itself, use absolute paths rather than relative ones: relative paths are supported but can cause problems in the long run. The details are in the lesson on canonical tags.

Pagination and addresses

Here people often overcomplicate. The pagination guidance: give each page a unique URL, for example by including a ?page=n query parameter, as URLs in a paginated sequence are treated as separate pages. Rewriting ?page=2 into /page/2/ is not required. The remaining rules — each page its own canonical, no fragments in page numbers — are covered in the lesson on navigation.

When to change an address

Renaming addresses is a move on a small scale. The site move guidance says 301 and other permanent redirects don't cause a loss in PageRank, so a redirect works — but expect temporary fluctuation in ranking: for medium-sized sites it can take a few weeks or more for Google to gradually show the new URLs instead of the old ones. The conclusions:

The last row is a conclusion from what was said, not a Google rule. The state of addresses after changes shows in URL auditing, and divergence between the sitemap and the new addresses is tracked by sitemap monitoring.

Checklist

1. Readable words rather than IDs, in the audience's language.
2. Hyphens, not underscores; one case.
3. Only parameters that change the content; the key=value& format.
4. No fragments for changing content.
5. One form of an address: HTTPS, one www variant, one slash convention — pinned by a permanent redirect and a canonical with an absolute address.
6. Each list page its own address.
7. When an address changes — a permanent redirect and a check of the result.

Mistakes

• Passing off the five-word and four-level rules as Google requirements.
• Using a temporary redirect where an address changes for good.
• Leaving http and https, with and without www, all reachable without pinning one.
• Not encoding non-ASCII characters in links.
• Changing the addresses of pages that earn traffic for cosmetic reasons.
• Believing an underscore makes a word "unknown" and a 301 passes "99% of the weight".

What comes next

The next module of the course is on-page technical optimisation: the title, the description, images and content.