Putting the “Perma” Back in Permalink

The DotNetNuke Blog module has had a checkered history with Permalinks.  The earliest versions did not use them, so old blog entries never had a Permalink created for them.  Instead, links to entries were generated programmatically, on the fly.

It’s been trouble ever since.

Permalinks were later introduced, but the old code that generated links on the fly was allowed to remain.  In theory, this shouldn’t cause any problems so long as everyone is using the same rules to create the link.  In reality, depending on how a reader navigated to a blog entry, any number of URL formats might be used.  A particular blog entry might reside at any number of URLs.

From a readers point of view, there is really no issue with an entry residing at various URLs.  But from an SEO perspective, it’s a bad idea for a given piece of content to reside at more than one URL: it dilutes the linkback concentration that search engines use to determine relevance.

It’s also a troubleshooting nightmare.  Since there are so many different places in the code where URLs are being created, if a user discovers an incorrect or malformed URL, the source of the problem could be any number of places.

Finally, it’s a maintenance annoyance.  If you are publishing content using the blog, you don’t want URLs that change.  You want the confidence of knowing that when you publish a blog entry, it resides at one URL, and that URL is reasonably immutable.  The old system that generated URLs on the fly was subject to generating different URLs if there were various ways for users to navigate to the blog.

The Permalink Vision

The Blog team has a vision of where we want to take URL handling:

  1. All Blog entries should reside at one URL only (the Permalink).
  2. The Permalink URL for the entry should be “permanently” stored in the database, not generated “on the fly”.
  3. The Permalink should be SEO-friendly.
  4. Once created, the system will never “automatically” change your Permalink URLs for you.

We’ve come really close to achieving this vision in 03.05.x.

With the 03.05.00 version of the Blog module, we have undertaken an effort to ensure that the Permalink (as stored in the database) is always used for every entry URL displayed by the module.  After releasing 03.05.00 we discovered a few remnants of old code, and believe that as of the 03.05.01 maintenance release we will have ensured that all URLs pointing to entries are always using the Permalink stored in the database.

But there was a problem with changing all the URLs to use the Permalink stored in the database.  Since old versions of the Blog didn’t generate Permalinks (and some generations generated broken Permalinks) how could we safely use Permalinks from the database for all entry URLs?  The answer was to force the module to regenerate all the Permalinks on first use.  When you first use the Blog module, it will automatically regenerate all of your Permalinks for the entire portal, ensuring that the database is correctly populated with the appropriate URLs for each entry.

The decision to force all users to regenerate their Permalinks was a measured one.  Obviously, automatically forcing Permalink regeneration violates the third rule listed above, and theoretically could result in URLs for some entries to “move around” depending on how broken their Permalinks were.  But we believed that we required a one-time fix to get all entries on the new Permalink approach, and that this approach was only likely to “move” entries that had truly broken Permalinks in the first place.

Going forward we are confident that this represents the best approach to finally resolving the Permalink issue once and for all.

SEO-Friendly URLs and Permalinks

With version 03.05.00, we introduced SEO-friendly URLs that change the ending of our URLs from “default.aspx” to “my-post-title.aspx”.  We also introduced a 301 redirect that automatically intercepts requests for entries at the old “unfriendly” URL, and redirects to the new “friendly” URL.

When you install 03.05.00, it will by default still be using the old, “unfriendly” URLs.  If you want SEO-friendly URLs, you must enable them using a setting found in Module Options.

When you change the setting, only your new posts will use the new SEO-friendly URLs.  This is consistent with the Third Rule: you shouldn’t click an option and suddenly have all of your existing URLs changed for you.  If you want to make your old entries SEO-friendly, you must change the option, then use the “Regenerate Permalinks” option to apply the change to all entries.

A Couple of Issues

As I mentioned earlier, after the release of 03.05.00, we discovered a few areas in the code where the system was still generating URLs “on the fly” instead of using the Permalink.  So, if you’re using 03.05.00, and change the “SEO-Friendly” setting, you will discover that some of your existing URLs do, in fact, change to the new format.  This is a bug that is being corrected in 03.05.01.

There is one other way that a Permalink URL might change unexpectedly.  If you use the SEO-friendly URL setting, the module uses the post title to create the “friendly” portion of the link.  If, after you post an entry, you change its title, the URL will change.  Fortunately, links to the old URL will be caught by the 301 handler and redirected correctly.  This problem will not be corrected in version 03.05.01 but will probably remain until version 4.

Thoughts About Version 4

Version 4 of the Blog module is still on the back of a cocktail napkin.  No hard and fast decisions have been made yet about its feature set.  But I will preview where I think version 4 might go, at least as regards Permalinks and SEO-friendliness.

In version 4, I believe we will introduce the concept of a “slug” to the blog module.  A slug is simply a unique, SEO-friendly text string that is used to create a portion of a URL and is unchangeable except by the blog editor.  So, for example, given the URL http://www.mysite.com/tabid/109/entryid/302/my-post-title.aspx, the slug is “my-post-title”.

How are slugs different from what we have today?  The only difference is that today, the string “my-post-title” is generated automatically from the title, and if the title changes, the string changes.  With a slug, the string would not change automatically if the title changes, but could only be changed manually.  Slugs ensure that once an entry is posted, it stays put unless the publisher expressly decides to move it.

If we do deploy slugs, then there will have to be a few other changes.

First of all, the entire point of using slugs is that, once created, they can only be changed manually.  That means that the “Regenerate Permalinks” functions will have to be removed.  Once each entry has a slug, it can’t be “regenerated” programmatically.  The very idea of “regenerating” becomes moot.

Secondly, the point of a slug is to provide the SEO-friendly ending to each URL.  It presumes that the blog is “SEO-friendly”.  If you aren’t “SEO-friendly” there is no slug.  So for version 4, we may make “SEO-friendliness” mandatory and force it on all blog entries, old and new.

“But wait!” you cry.  “I thought that the point of Permalinks was to ensure that the system would never again change my URLs, and here you are saying that in a future version, you’re going to change all my URLs whether I like it or not!”

Well, yeah.  Guilty as charged.

First off, think of this as the very last step in achieving SEO-friendly Permalinks that are truly and finally “perma”.  Once we achieve SEO-friendly slugs, we have made it all the way to the goal.  And this is really the only way to get there, at least, the only way that is easy to support and not confusing to the end-user.

Secondly, the 301 redirection built into the module should ensure that the transition from old URL to SEO-friendly slug is completely transparent to all users and to search engines.  All the old links will work, and they will correctly report the move to search engines, which will update themselves accordingly.  Thousands of Blog module users are already testing this in version 03.05.x, and I believe that by version 4 we will be confident in this approach.

Of course, all of this is speculative, since version 4 isn’t even in the design stage yet.  But I hope that this information helps illuminate how the Blog team is thinking about the module and where it is likely to go in the future.  And, as usual, your feedback is highly encouraged.