: Is it valid to include digits and question marks in the URL slug for a permalink? Is it valid (and maybe even a best practice) to create "Aliases" or "Slugs" that contain numbers and question
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-?
More posts by @Courtney195
5 Comments
Sorted by latest first Latest Oldest Best
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.
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:
example.com/march-thirtieth/page-number-one/apple http://example.com/january-thirtieth/page-number-two/orange 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:
example.com/mar30/pg1/apple http://example.com/jan30/pg2/orange 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.
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: 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: en.wikipedia.org/wiki/D%C3%BCsseldorf Slug: D%C3%BCsseldorf → Dü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.
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 : example.com/category/dogs-happily-barking and not 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 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.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.