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.
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:
Following that definition, valid is every character that is allowed in the path component of the URL. For HTTP(S) URLs, these would be:
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.,
?) in the address bar.
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:
_(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
3 (instead of
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
3 in the slug.
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
Web_2.0), while Stack Exchange omits these (example:
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.
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.
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.
It's good that you're trying to construct friendly URLs but this particular URL scares me:
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> <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.
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.
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:
Now lets take a look at what a more friendly URL may look like:
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.