4

Is it valid (and maybe even a best practice) to create "Aliases" or "Slugs" that contain numbers and question marks? The numbers would be integer only, floats are out of the question.

For example: example.com/do-you-want-2-or-3-?

0

5 Answers 5

5
+100

Definition of slug

Slug is not a technically defined term. Depending on who uses/defines the term, there are different criteria involved. For example, the definition from Django says that a slug can only contain "letters, numbers, underscores or hyphens", while the definition from WordPress doesn’t restrict this. But it’s probably not useful to look how the term is defined by various CMS, as each system has its own technical vocabulary.

In my opinion, the following definition for slug (in the context of URLs) makes sense:

  • it describes the document’s main content in a human-readable way, typically by representing the content title
  • it is typically in the path component, where it is typically the last path segment

Allowed characters

Following that definition, valid is every character that is allowed in the path component of the URL. For HTTP(S) URLs, these would be:

  • a-z
  • A-Z
  • 0-9
  • : @ - . _ ~ ! $ & ' ( ) * + , ; =
  • any character in its percent-encoded form

As you can see, the ? is not allowed directly. That is because ? is a reserved character which starts the query component of the URL. So if you want to include a question mark in your slug, you have to percent-encode it with %3F. While it doesn’t appear to be human-readable, note that this string is not necessarily shown to the user. Many browsers will show the decoded form (i.e., %3F as ?) in the address bar.

Content title to slug

You have to make several decisions about how to represent a content title in the URL. This depends on the language of the content, your backend, the URL design of other pages on your site, etc. For example:

  • Which case to use? The path is case-sensitive; many use all lower case.
  • How to represent space characters (if not wanting to use percent-encoded space)? Common choices are - and _.
  • Which maximum length? Titles can be very long, but it can make sense to have shorter slugs.
  • Any words to omit? Some may decide not to include stop words like "a", "the", etc.
  • Any characters to omit? Some may decide not to represent characters like -/_ (as it may conflict with the delimiting character, see above), or punctuation marks, or special characters, etc.

If your title is "Do you want 2 or 3?", using 2 and 3 (instead of two and three) in the slug would be the obvious choice. There’s nothing wrong with that, and I would not change the digits to words, or even omit the digits. Think of titles like "Web 2.0", "Version 1.4 released", or "333333 visitors".

And vice versa, if your title is "Do you want two or three?", there’s no reason to use 2/3 in the slug.

Examples

This very question:

  • Title: Is it valid to include digits and question marks in the URL slug for a permalink?
  • URL: https://webmasters.stackexchange.com/questions/90615/is-it-valid-to-include-digits-and-question-marks-in-the-url-slug-for-a-permalink
  • Slug: is-it-valid-to-include-digits-and-question-marks-in-the-url-slug-for-a-permalink

A Wikipedia article:

  • Title: Düsseldorf
  • URL: https://en.wikipedia.org/wiki/D%C3%BCsseldorf
  • Slug: D%C3%BCsseldorfDüsseldorf

As you can see, Stack Exchange uses all lower case letters, while Wikipedia differs between case. In this example you can see that Wikipedia uses _ to represent spaces, while Stack Exchange uses -. Wikipedia includes characters like . (example: Web_2.0), while Stack Exchange omits these (example: web-2-0).


Conclusion

  • There’s no right or wrong way, as long as you follow the rules from the URI standard and the HTTP(S) specification.

  • Using digits in the slug is perfectly fine. Use the variant which you use in your content title.

  • Using question marks in the slug is only allowed in their percent-encoded form. You may decide to omit this character (or all characters which would have to be percent-encoded), but that’s not necessary.

2

It is valid, I have seen many of website using numbers in URL, like labnol.org, stackexchange.com, howtogeek.com etc.

Using question mark in URL is also valid, Because Google own Blogger product using ?m=1 at the end of URL for mobile search index. For example, just open Google from your mobile and search this "mybloggertricks" and you will see URL like this www​.mybloggertricks.com/?m=1 . So if you're also using parameter function for different kind of things, then Google is pretty smart to handle this type of URL parameter from Google Webmaster Tools.

3
  • It is far better that parameters be terms where possible. The reason for this is simple. Semantics. IDs do not offer semantic value and do not offer clues to the topic of the page. Some sites do use IDs. Granted. I replaced IDs many years ago with aliases that match semantically the title tag and h1 tag of the page. It makes a huge difference. However, parameters are not as powerful as a URI path which should be preferred. Still, this is not always possible depending upon how the site was constructed. IDs still work, but not as SEO friendly.
    – closetnoc
    Commented Feb 29, 2016 at 18:48
  • @closetnoc its actually consider better 'NOT' to have matching URLs, Title and H1 as its unnatural. Differences should occur but that's another topic and a chat for another time. Commented Mar 13, 2016 at 18:14
  • @SimonHayter I am not sure I follow, but I do agree with your comment whole heartedly. URIs should be unique. I have come to the conclusion that it is far better no to use parameters where possible using a unique URI instead. This means I have to change my whole sites structure - galdangit! That is okay. Most of the site will disappear anyway!! Time for a major clean-up.
    – closetnoc
    Commented Mar 13, 2016 at 19:05
2

It is valid but it is not the best practice. If we have an article for example named "Dogs happily barking" it is better both for your SEO and your users, to have a link like : www.example.com/category/dogs-happily-barking and not www.example.com/category/?123 where ?123 is the page ID because if I understood correctly this is what you are involving, if it is about question mark in like www.example.com/category/My-First-Article? or something, it is valid and you won't get penalized but it won't obligate you in any different way than the first example I gave.

4
  • What do you think of, for example, a.com/2-nice-lamps instead of a.com/two-nice-lamps?
    – user58733
    Commented Feb 29, 2016 at 9:31
  • It doesn't make any difference for me, and it doesn't really impact on your SEO also Google loves shorten URLs not like 2 symbols are going to change it a lot but it's something, and maybe the biggest advantage of it is that when people search for strings they often type 2 instead of typing two.
    – knif3r
    Commented Feb 29, 2016 at 9:57
  • 1
    It is far better to use terms in place of numbers as in your example in the comment above. The reason is simple. Semantics. It is far easier for semantics analysis using the written language. This does not mean that using a 2 instead of two is bad or will not work. It will. It is just not natural language which semantics prefers. Given a choice, I would prefer the term over the number. It is also correct that links/URLs of this type should be semantically written and not an article ID. URL paths are one of the top important semantic clues for your site.
    – closetnoc
    Commented Feb 29, 2016 at 18:42
  • Good point closetnoc I agree for the "2 and two" example.
    – knif3r
    Commented Feb 29, 2016 at 19:37
1

It's good that you're trying to construct friendly URLs but this particular URL scares me:

example.com/do-you-want-2-or-3-?

This is because it ends in a question mark. The first question mark in a URL is an indicator that what follows is a query string.

Since I developed apache modules, I learned that in some system variables that I can import into my apache module that the question mark is completely filtered out (meaning I won't see it at all).

Integers are perfectly fine.

What I would suggest is to make your URLs as short and informative as possible, otherwise they may not format well in some email clients. You can verify this when using the tool at try.powermapper.com on a long URL. I think the character limit for the URL is 80.

This means try to use abbreviations and numerical characters. For example, use a URL like "http://example.com/mar30/pg1/apple" instead of "http://example.com/march-thirtieth/page-number-one/apple" or "http://example.com/march-30th/page-1/apple"

Another two advantages to shorter URLs is that they are easier to remember AND your webpage size will overall be smaller (unless the URLs are not accessible by links). I'll explain:

Say you have these URLs:

http://example.com/march-thirtieth/page-number-one/apple
http://example.com/january-thirtieth/page-number-two/orange
http://example.com/september-thirtieth/page-number-three/banana

And you have one page linking to the above URLs twice. Let's also assume you're using relatie links (relative to root) Your HTML could look like this:

<html>
<head>
<title>Web</title>
</head>
<body>
<a href="/march-thirtieth/page-number-one/apple">apples</a>
<a href="/january-thirtieth/page-number-two/orange">oranges</a>
<a href="/september-thirtieth/page-number-three/banana">bananas</a>
</body>
</head>
</html>

As you can see, those links take up a lot of bytes. Let's try shorter URLs:

http://example.com/mar30/pg1/apple
http://example.com/jan30/pg2/orange
http://example.com/sep30/pg3/banana

HTML:

<html>
<head>
<title>Web</title>
</head>
<body>
<a href="/mar30/pg1/apple">apples</a>
<a href="/jan30/pg2/orange">oranges</a>
<a href="/sep30/pg3/banana">bananas</a>
</body>
</head>
</html>

As you can see the links still do make sense. Pg. is short for page, and mar, jan, and sep are short forms for March, January and September respectively. Also, if you do a file size comparison of the above two pieces of HTML code, you can see the second one is a lot shorter.

So my answer then is, yes use numbers, and avoid question marks and use abbreviations if possible for the best, most compatible and friendly URL.

0

I thought I would add this because after reading the many answers none have touched upon user experience and have primary focused on the SEO value. There's no need to add a question mark, users and search engines wouldn't careless, this doesn't mean you can't since it is an allowed symbol in the URL.

UX and SEO Value of ?'s in URLS

Since you now know that you can add question marks it to the URLS your decision should be based on SEO (Search Engine Optimisation) and UX (User Experience).

While I don't reject the importance of SEO, I do reject the claims that SEF (Search Engine Friendly) URLS are NEEDED to rank a page for a desired phrase or keyword, it is one signal of many. Pages with parameters and Id's can easily rank just as well because the bots have many ways of establishing what the page is about.

SEF URLS

The main reason why people should use SEF URLS is because the user experience it offers, it provides people information about the page before they visit it, when linked to on a forum or any other platform that links from, to without a anchor text link.

UX, UX, UX, BEFORE SEO!

The best formula for making a UX friendly URL is to show users in as few words as possible what the page is about. Using a question mark in a shortened URL wouldn't make sense, for example:

  • Header: How to train your pet dog in 10 days?
  • URL: how-to-train-your-pet-dog-in-10-days?

Now lets take a look at what a more friendly URL may look like:

  • train-your-dog-in-10-days or even 10-day-dog-training

As you see the above URLs tell people what the page is about, using ? is now obsolete because of the more friendly url usage and the fact adding a question mark wouldn't make sense. Sites like Stack Overflow and Pro Webmasters use system generated URLS, they use exact URLS based on the questions, of course they could shorter the URL by removing the stop words in, the, and etc etc but then they become unreadable. Short UX readable URLS are currently only possible with human interaction.

Machine Generated URLS

Please note that in the example Google will still rank for the 'How to' part without that in the URL, as I said earlier URL is one indication signal of many. Tailor your URLS for people who matter, not for robots.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.