In my application I'm currently using forms which allow to enter Title and Slug fields. Now I've been struggling with the slugs thing for a while because I can never decide once and for all how to handle them.
1) Make Title and Slug indenpendent
Should I allow users to enter both Title and Slug separetely? This is what I had first. I also had an option that if user did not enter the Slug it was derived from the Title. If both were enter, the Slug field took precedence.
2) Derive Slug from Title, when content is inserted that's it for the Slug, no more changes
Then, I switched to only Title field and derive Slug from title. While doing it I found out that now I have to change all the forms that allowed user to enter a slug. This way of doing it also prevents users to change Slugs - they can change the Title but it has no effect on the Slug. You can think of it like Slug is uniqued ID.
3) Now I'm thinking again of allowing users to change slug
Though I don't think it is all that useful. How many times does the content that someone already added, spent time on writing it, even require a change of either Title or slug? I don't think it is that many times.
The biggest problem with the 3rd option is that If I use Slugs as IDs, I need to update the reference all over the place when Slug changes. Or maintain a table that would contain somekind of Slug history.
What are you thoughts on these, I hope, valid questions?
If someone has a sample DB design for this, it would be appreciated if you share it here.
If you decide to allow users to edit slugs, you could include the ID of the content in the URL and perform a 301 Moved Permanently when the slug doesn't match the current slug. E.g., if /product/42/black-bucket/ is now /product/42/shiny-black-bucket/, you could redirect to the new slug. I saw recommendations not to allow arbitrary slugs for your URLs, as this breaks the concept of canonical links for search engine crawlers and allows malicious folks to game your results.
I've just been going through all of this with a client, sorting out the rules around the URLs, etc.
Your slug should be at the very least slightly independent of the title, if only to ensure that you can take out standard "stop words" - most SEO's would recommend that the page path be as keyword rich as possible so a page title of:
Darling: we will cut deeper and tougher than Thatcher
Could become a slug of:
alistair-darling-cut-deeper-margaret-thatcher
But if possible, you should automate it as much as possible when the author is creating the post, so as they tab/move out of the Title field you populate the Slug/Name/Path field with a string that has removed all symbols, (ideally) removed an agreed list of stop words and replaced spaces with hyphens, so the automated slug from that title could be:
darling-will-cut-deeper-tougher-than-thatcher
But you need to give the author the ability to tweak beyond that.
We've also specified that this automation will only happen when the author creates the post, so subsequent edits would not automatically change the slug, to ensure that we don't suffer from external link rot (the CMS we're using manages all the internal links).
The only time the author should really be changing the slug would be if they'd published a typo, or something libellous.
Personally I would suggest letting the user edit the title and the other contents of the record for the page. Once they have done this you can derive the slug from the title (or anything else you feel like). If they change the title then the slug can change but you could keep a record of the old slugs associated with the same page. If someone comes to the site with an old slug then you can send them 301 response and redirect them to the new page. This would be via an interception page handled by your routing.
Another question would be if they are changing the title, surely it's a new page with new content and with a new slug?
Thoughts?
How about only allowing the user to edit the title or slug while the page is in draft. When the page is published the title and slug become permanent.
Or as #WestDiscGolf said, keep a record of all old slugs and send a redirect.
Related
I'm running a simple site based on Joomla. The SEF URLs are defined by SH404SEF and look like https://[domain]/[category]/[sub category]/[article title alias].html. In some cases there is a 1-to-1 relationship between category and article but in some cases one category has several articles.
Suddenly I have URLs requested following https://[domain]/table/[category]/[sub category]/. Not only does these new URLs in some cases create 404s, they also view my articles in the wrong way and when there is not a 1-to-1 relationship between category and article the link adds several articles on one page.
The correct non-SEF URL ends with &view=article and the new, uncorrect non-SEF URL ends with &view=category. I have no table/ in my correct URLs, neither in any internal link, in the articles' html code, in menu items nor in my sitemap.xml. I've discussed this with the few extension providers I am using and none of them see their extension as doing this request new.
Is there any way to find out what is making these requests?
I cannot make a redirect for these URLs since all of them do not
correspond to one article, but several. Can you see any risk with
making a rewrite rule that puts a 410 on all URLs that starts with
table/?
This is actually a misconfiugration in sh404SEF. Here's what to do:
Login to the backend of your Joomla site
Go to the sh404SEF configuration
Set the field "Insert Content Table Name" to "No"
Flush all URLs and clear your Joomla cache
This should do it.
I'm working on a new advert website and want to implement some good SEO URLs.
I got category URLs like:
/category
/category/sub-category
This seems ok. What about detail pages?
Option 1:
/announcements-and-notices/announcements-various/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
Option 2:
/adverts/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
In reality my website has a pretty long URLs due to multiple areas you can shop. So it would become:
/en/area-name/announcements-and-notices/announcements-various/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
/en/area-name/adverts/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
Which detail page would be a better URL? The first option seems to be better if the product has no long/good title. The second seems better as its the most relevant one and shortest especially with long category names.
I would like to hear your thoughts!
EDIT:
I found this two google docs:
http://www.google.nl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDYQFjAA&url=http%3A%2F%2Fwww.google.com%2Fwebmasters%2Fdocs%2Fsearch-engine-optimization-starter-guide.pdf&ei=lXyaT6T_L8zR4QSM4c2qDw&usg=AFQjCNEMj8KHxhxQz9cMLoMxMDiLdrAbJw
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=76329
I think I will be going for /adverts. Anyone disagree?
i have seen many of SEO analysts miss something about optimizing their webpage and that is your page will be optimized for only some keywords not all keywords. it is not important how length is your URL. you should first analyze whether the contents in your webpage is rich enough to have such URL with these keywords or not. if the answer for every keyword is yes then the more length will give you the more rank.
I think you can even set your pages up in a way to use only the slug and skip the id, such as:
/adverts/suscipit-dis-molestie-malesuada-vestibulum-ut
or even just:
/suscipit-dis-molestie-malesuada-vestibulum-ut
like this and refer straight to the adverts controller and the advert itself, which has this slug assigned to it (the one with id 15880).
This way you'll have nice and clean URLs. Just assign and keep an unique slug for each advert and handle it using .htaccess, or dynamically inside the code of your site, if the system allows it.
Cheers.
I seek some guidedence here ... ( I'm not sure if this is the best title )
At the moment I prepend a "server name" to the url like this:
server10.example.com
This works fine, except that I need to handle all the subdomains on the IIS and I'm not sure google are happy about jumping around from sub to sub to sub, when it seems the links to the other servers.
I'm kind a hoping for a nice way to archive this wioth asp.net mvc.
Most pages are related to a "server" ... there are however a few info pages, contact, home that dont really need a valid "server" name ... but could just be "na" for not available, but the name need to be maintained, if there is already a selected server, when a user are keeps browsing the site. This needs to be as transparent as possible when I need to create the links to the diffenrent pages.
I could extend the Html Action() extensien to automatically add the selected "server" from the previusly request to the page.
In the format:
/{serverParameter}/{controller}/{action}/{parameterInfo}
And if no server is selected, just add "na" as the {server} placeholder.
I'm not sure if more information is needed, but please let me know if ...
I tired of extracting the selected server from the domain part and the other way also seems better, I just can't think of a good way to structure this ...
Updated
90% of all the pages are about a server that the user select at some point. Could be server10, server9, server20 ... just a name. I want to maintain that information across all pages, after the users has selected it or else I just want it to be f.ex: "empty".
I mostly looking for an easy way of doing this or an alternative ... atm I'm prepending the serverParamter to the url so it ends up being: "serverParameter.example.com".
I want to end up with something like
http://example.com/{server}/{controller}/{action}
instread of
http://{server}.example.com/{controller}/{action}
If I understand your question correctly, you just wish to group different collections of content together above the controller/action level. If that's the case, have you considered using ASP.NET MVC areas?
Just right-click on your project, and choose Add -> Area.... Give it a name (what you're calling "server"), and then you can add content, your own controllers, actions, etc. Under this area. You will automatically be able to access it via /AreaName/Controller/Action/etc.
I went with the already impemented routing in ASP.NET MVC.
{server}/{controller}/{action}
When creating the links it takes the set value for {server} and places the value when generating URL's, so I only need to supply controller and action in the #Html.Action helper method ... this could not have been more easy.
I'm not sure why I did not think about this. One just gotta love routing.
Today I heard from my colleague that search bot can index pages with sequential ids.
Is it really happens ?
As an example checkout two urls:
http://sample.com/myProduct?id=765
and
http://sample.com/myProduct?id=35d6eb6c-97f6-4cde-997c-ade657c285d3
So, if search bots can figure out that my product id in url is sequential it can possibly index other products up and down the sequence ...
Have you ever heard anything like that ?
Whomever told you that is mistaken. Search engines will only index pages they know exist. So they won't keep changing the ID in those URLs just see if they find anything. So if you want those other pages to be indexed you should use a HTML sitemap or XML sitemap to tell the search engines where those pages are. Linking to them from other product pages is also a good idea.
I am wondering why the link to profile looks like:
http://stackoverflow.com/users/ID/NAME
not simply:
http://stackoverflow.com/users/ID
or even better:
http://stackoverflow.com/users/NAME
Can there be couple users with the same name? Or can one user have many names?
All SO-URLs are of the form id/description where the ID is unique and the description is optional. So /users/12890/arne-burmeister is the same as /users/12890/huhu and /questions/420380/why-does-the-link-to-the-user-profile-have-both-id-and-name is the same as /questions/420380/foo. The retrieval just uses the ID, but it is much better for google ranking, when the user/question/what-ever-should-be-found occurs in the URL (also for humans this is much more descriptive ;-).
By the way, retrieval by ID is faster than by such a large text string. And of course, the URL remains valid if someone changes their user name or the question.
The part after the last slash seems to be SEO related (i.e. making the url more expressive).
On the urls that I tested you could replace that part with whatever you wanted, it still worked. So the url http://stackoverflow.com/users/37086/othername still points to your profile.
I would assume doing a database lookup solely on the name string would be more expensive than a numerical lookup on the primary key, even if the name column is indexed. The name is then added on to make the URLs more user and SEO friendly.
There is a uservoice request for this. If you want this to happen, uservoice is the right place to discuss / vote up.
Your name on SO is not unique click on users and type Josh, there's a whole page of us. So you have to have the ID. As for why the name everyone else's guess is as good as mine.
Try changing or removing the name and see what happens.
I think it's just so that your URLs tell you what to expect, but the application doesn't need (or actually use) that information.
Amazon does something quite similar with their books, if I remember correctly: They've got both the ASIN (their internal ID) and the name of the book in the URL, but only ever look up the ASIN.
Just speculating: The ID allows very fast retrieval of the data the profile page presents. The name is just for humans and ignored since it's easier for me to no that you are rkj and I am phihag than that your ID is 37086 and mine is 35070.