3 replies to this topic

[newhat]

There are reasons to have a unique post ID in a URL. This makes sense since text subject lines are likely to be replicated over the course of time, resulting in duplicate URLs that have to be handled by software. There are other technological benefits such as no need to match text with a database entry. On the flip side, article IDs create longer URLs that may be less readable and friendly. There is also the question of whether the search engine will waste time going from left to right on article ID numbers that will continue to grow. Placing article IDs on the right side makes them look awkward at times, subject to removal of the user who may think they are unnecessary, and truncation would result in a problem being seen. I see different conventions being usd here. Is there any thought about putting ids into urls and having them on the left or on the right side?

[Alan Perkins]

Start with the Google News guidelines on article URLs - who knows, one day you might want to be listed there, and it would be good to qualify on technical grounds at least.  Read these and make sure you comply:

 

https://support.goog...81298&ctx=topic

 

Then take a look at how other sites do it. A couple of examples:

 

http://searchenginel...d-search-147297

http://searchenginew...ations-for-2013

 

Personally, I prefer the searchenginewatch.com approach.  But they have used a directory for the article ID, and this takes effort to get right - note what happens if you go to ... 

 

http://searchenginew...rticle/2235925/

 

You get 302 redirected to 

 

http://searchenginew...ations-for-2013

 

They should have made it a 301, but at least they have put the effort in to doing a redirect rather than allowing the content to be served at two URLs.

 

You can save yourself a redirect if you don't use a directory.  That's how searchengineland.com does it.  However, I don't like the article ID being hung out on the end of a variable length .  If it were me, I'd do it like this ...

 

http://searchenginel...2013-and-search

http://searchenginew...ations-for-2013

 

... but clearly any of the above can be made to work.

[newhat]

Alan - thanks for a great response. Google News requirements are bizarre. I would get around it with a sitemap but still the 4 digit unique ID requirement? Go figure that one... I guess five digit article ID minimum it is. I'll have to change the autonumber in all of my blogs...

 

Regarding the above, If all was equal, I am in total agreement. I think that SEwatch is the optimal. But I'm not sure all search engines will be equally kind to additional directories added into the URL. There is also increased issues to watch how the server handles adding directories that aren't really there (and you've pointed out a great use of excellent programming but you have to be on top of all these redirects!) There is also the issue (as below) with decreased legibility. I regularly find Searchengineland's articles at the top although I can't be sure that it's the URL or other factors which could easily be responsible. Let's go into the other aspects:

 

I noticed that URL shortening is much less attractive for the /12345/ suffix (searchenginejournal) versus the -12345 suffix (searchengineland). Look at what happens in Google (although not in IPB). The keywords will be far more visible for the latter rather than the former. I am guessing this is the case because most keywords are contained within the last "directory" that the script sees which is between the front slashes. As a result, the script (including Google) uses the first part of the URL and shows the keywords but not the ending which is omitted entirely (and is the numeric item ID). 

 

SEland:    www.seland. com/article-name-here......

SEwatch www.sewatch .com/art.....re/12345/

 

The flip side is this - it's so much easier for a server to parse the second version because it knows where to look for the article ID. It can skip having to read in e.g. 30 characters and go right to the front slash since it knows that the ID is following. With the SELand example, the server has to get to the end of the article and then go back several spaces until it encounters a dash and the can determine the proper article.

 

The same goes for having the numbers in the URL as in the stock IPB install as is here in this forum. No need for the server to go through the entire URL and any truncation of the URL by a user can STILL be read by the server if it has an option to find the article solely by article ID number. The negative is that people read left to right as do search engines. The numbers are a bit of an intrusion and also will appear in URLs and probably make for the least friendly for the eye.

 

I'm not sure how much of any of this matters. It would seem, though, that either /12345-subject-name/ or /12345/subject-name/ or /subject-name/12345/ would be optimal from a technical perspective, the key being a trade off of readability versus functionality. The searchengineland version seems to perform well but is the least optimized by the machine for both speed and reliability.

[Alan Perkins]

 I'm not sure all search engines will be equally kind to additional directories added into the URL

 

 

There would be no problem at all with the examples I cited.  

 

 

 

I can't be sure that it's the URL or other factors which could easily be responsible

 

 

The URL hardly makes a difference.  Everything else has to be good before the URL will have an impact.

 

 

 

I noticed that URL shortening is much less attractive

 

 

Not an issue.  If it worries you too much, then use semantic markup to get breadcrumb trails in the search results.