So when you type something like you see in the title of this post, with all the funky characters, or even just something like a comma, apostrophe, or semi-colon, WordPress 3.3+ works the magic and automatically creates your post slug without the junk.

Details.

It may not seem like a big deal, but previous versions of WordPress would include those funky characters when auto-creating your permalink slugs. If you glance at URLs while surfing around WordPress-powered sites, keep an eye on the URL in the address bar. It’s common to see all sorts of non-alphanumeric stuff in there.

Does it matter? I think so, for numerous reasons:

• Readability, consistency – simple alphanumeric URLs work great everywhere, no need to clutter them up with redundant information. For example, funky characters can choke URL-shortening services. Also: fewer characters, facilitates better comprehension.
• Safer – certain characters such as `, ^, ", ~, #, %, |, \, <, >, ", ~, [, ], {, }, and the blank space are considered as unsafe and should not be included in the URI (ie., always need encoded). Including them may seem to work, but you’re introducing sort of unknown variable into the mix, a potential vulnerability*
• SEO — do funky characters like blank spaces and percentage signs in the URL hurt your site’s SEO? Maybe not, but why put anything in there that isn’t a keyword?

So smarter auto-slugs in WordPress 3.3, another one of the finer details that improves the overall WP post-editing experience, and something you may not have noticed.

Bonus tip

Another sort of related “smarter-slugs” feature noticed while looking into it, is the automatic removal of the “-2” that WordPress automatically appends to the post slug when a duplicate is detected. So for example, say you’re working on a new post:

1. Create a post with a slug such as “test-post”
2. Delete the post and send to the Trash
3. Create another post with the same “test-post” slug
4. WordPress detects the duplicate post in the database and appends a “-2”, like so: test-post-2 to the post slug
5. Create yet another post with the same slug and WordPress will append a “-3”, and so on..

Nobody likes the “dash-twos” but they are required for the auto-creation of non-duplicate post slugs. What I just noticed with version 3.3 is that, once you empty the Trash, WordPress automagically removes the “-2” from the post slug, improving workflow to save you time. This may have changed in a previous version and I just hadn’t noticed, or it’s another one of the administrative refinements of WordPress 3.3.

Update: it looks like the -2 removal only applies to drafts and pending posts, not to posts that have already been published.. (see comment from Otto)

* More info on forbidden characters and blocking them

© 2012 Digging into WordPress | Permalink | 16 comments | Add to del.icio.us | Post tags: permalink, tips, tricks

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

When working with WordPress, that snippet is the only htaccess code that is actually required by WordPress, and even then, it’s only necessary if you are using so-called “pretty-permalinks” on your site. Needless to say, there are probably millions of instances of these original permalink rules in place on servers and sites all across the Web. The code is so familiar that many WordPress devs can probably write it from memory. So changing things is actually kind of a big deal.

The NEW WordPress Permalink Rules

There’s really no reason to get all excited about anything. I just tend to get hyped up for anything relating to WordPress or htaccess. So mix them together and I’m all over it. For the new WordPress permalink rules, only a single line was added, and it’s a good one to have in there:

RewriteRule ^index\.php$ - [L]

So that’s the new hotness, and it works great at what it does, which we’ll get to here in a moment. For now, let’s go ahead and add that new directive to our original htaccess ruleset to get the new WordPress permalink rules:

For sites installed in root directory:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

And for sites installed in a subdirectory:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /subdirectory/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /subdirectory/index.php [L]
</IfModule>
# END WordPress

I’m not sure exactly when the htaccess permalink rules were changed, and I’m not sure it really matters, but I’m thinking it happened sometime between versions 3.0.0 and 3.0.4. I didn’t notice it until version 3.0.4, but I am guessing that it happened at 3.0. Somebody let me know that I’m wrong here.

So what does it do?

What is the purpose of the new htaccess directive? Why change something that has worked so well for so long? Better have a good reason to go tampering, right? Yes, and as it turns out, this new rule is involved with canonicalization [1] of your WordPress URLs. I don’t think it was by any means necessary, but it’s definitely an improvement over the original code. The new directive basically strips off any dangling index.php from your WordPress permalinks.

[1] Update: As Robert points out, the new line of code is there to fix an issue with Apache’s mod_rewrite; it has nothing to do with canonicalization, which is handled automatically by WordPress.

For example, with the original permalink rules (and no other htaccess modification), the following URLs all refer to the same page:

• http://digwp.com/
• http://digwp.com/index.php
• http://www.digwp.com/index.php

Fortunately, WordPress already handles the www canonicalization, and so the new line of htaccess takes care of the other end of the URL: the index.php. This may not seem like a big deal, but can have a big impact on script performance, search-engine optimization, and user-experience.

Updating your htaccess rules

So the question now is “do I need to go back and add this new directive to my existing permalink rules?” I think the best answer is that you don’t need to do anything – your WordPress-powered sites will continue to work just fine. But if you want the additional canonicalization that the new rule provides, then you probably should stick it in there.

A couple of things to keep in mind about the new htaccess code:

• No need to update existing htaccess files unless you want to
• As with the original code, the new htaccess works in all versions of WordPress
• If you do add the new line, make sure to remove/adapt any similar/related htaccess rules

For example, as I was going through and updating all of those old sites, I had been using my own recipe for proper permalink canonicalization:

# CANONICAL WP RULES
<IfModule mod_rewrite.c>
 RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php [NC]
 RewriteRule ^index\.php$ http://example.com/ [R=301,L]
 RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
 RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]
</IfModule>

This code works on any site – not just WordPress installs – to clean up both ends of the URL: the www and the index.php. As I updated my htaccess files with the new WordPress permalink rules, I had to remove this custom canonicalization code to make room (functionally speaking) for the new stuff, which is a much more elegant solution.

© 2011 Digging into WordPress | Permalink | 28 comments | Add to del.icio.us | Post tags: htaccess, permalink

WordPress makes it so easy

WordPress gives you full control over your permalinks. First, you have control over the general structure of your permalinks. Navigate to Settings > Permalinks and you will see several options for configuring your permalinks:

This is where you configure the general structure of your permalinks, as seen here with green underline. The portion underlined in red is post/page-specific, and will vary depending on your individual posts and pages. For DigWP.com, we chose the “month and name” format, which creates the following permalinks according to page-view:

• Pages → http://digwp.com/about/
• Tag Archives → http://digwp.com/tag/permalinks/
• Category Archives → http://digwp.com/category/seo/
• Single Posts → http://digwp.com/2010/05/wordpress-json-api-plugin/

..and so on. The main thing that you want to optimize at this point is the structure of your single-post permalinks. We chose to include the year and month for our posts, but it has been argued that it is better to omit the date entirely, using a “Custom structure” like so:

/%postname%/

This simple structure will produce single-post permalinks that include only the post name:

http://digwp.com/wordpress-json-api-plugin/

Without the additional date information, this structure is definitely shorter and cleaner, but there may be performance issues involved with using the “name-only” permalink format. Perhaps a good trade-off is to include either the post ID or the year:

/%post_id%/%postname%/
/%year%/%postname%/

I think either of these formats is probably an optimal way to configure your permalinks, but you also want to consider the frequency with which you’ll be posting content. It may be beneficial to further organize/classify your posts by including the month and day as well.

Certain “experts” will tell you that including extraneous date information is bad for SEO. The thinking here is that shorter URLs correspond to a more “flat” directory structure, which may provide some SEO benefits. I think the key is to use what’s necessary and omit any extraneous information.

Post/page-specific permalink structures (slugs!)

Once you’ve defined the general permalink structure in the WordPress Admin, you now have full control over your post-specific and page-specific permalink structures (as seen in the above screenshot, red underline). The part of your permalinks that is specific to each page or post is set in the Write/Edit Post screen in the WordPress Admin.

As shown in the above screenshot, WordPress provides an “Edit” button that enables you to modify the post-specific portion of your permalinks:

This feature enables you to customize your post/page-specific permalinks (also known as a post “slug”) according to your current permalink optimization strategy. Here are a few examples of commonly employed “post-slug” strategies:

Don’t even worry about it

Just let WordPress generate the post-specific slug based on the post or page title. Pros: this is certainly the easiest method of creating permalinks because no thought or action is required. Cons: depending on your post title, you could get some pretty long permalinks that look awkward and sloppy.

Remove extraneous words, leave only keywords

I have seen lots of blogs do this. It basically involves using the permalink that WordPress generates based on your title, then going in and removing words like “the”, “and”, and “you”, as well as other pronouns and such. Basically the idea is to leave only keywords in your permalinks. This helps keep them short, focused, and optimized for the search engines.

Customize every permalink with optimized keywords

This is the most labor-intensive strategy, but also potentially the most lucrative in terms of return on investment. The idea here is to research or otherwise understand which keywords your page is going to rank for, and then crafting a post-specific permalink structure based on those keywords. I have seen cases where this is taken to such an extreme that the post slug is completely different than the original post title.

The same goes for both posts and pages, regardless of which method you choose. Personally, I employ a combination of the first two strategies, whereby I go in, write a title, and then look at it and see if there is anything that could be improved. Usually there are several words that need to go, and possibly a keyword or two is added or removed. It’s funny because I usually end up rewriting some of the post content after spending some time actually thinking about what to name it.

There is always a better title than the one you think should be used.

The take-home message here is that, by paying attention to post titles and permalinks, you benefit from improved relevancy and potential SEO advantage.

Think of your users

When visitors land on your page, does the URL make sense? Does it correlate with the page title? These are some of the things to think about while setting up the general structure and post-specific slugs for your permalinks. Look at the permalink and ask yourself if it makes complete sense based on what the user will be looking at on the page. If you get too carried away with optimization, a user may get a sense that something isn’t quite right. Perhaps the post title says something like:

The Best Name-Brand Shoes

..but then the post slug looks something like this:

http://example.com/nike-adidas-reebok-zip-converse-shoes/

Perhaps a weak example, but it serves to illustrate the semantic gap that may occur when over-thinking your permalinks.

Think of the search engines

After considering your users, think about what the search engines are going to see when they come crawling your pages. Does the permalink match the content of the page? If you aren’t bothering with changing or optimizing your post slugs, then the answer is probably yes because WordPress generates the slug from the post title.

Also, as mentioned previously, some have argued in favor of a more “flat” directory structure in order to improve the SEO value of your blog. Whether or not this is actually the case is up for discussion, but it always makes sense to keep things as simple and concise as possible. So when deciding on the general structure for your permalinks, ask yourself if you really need a directory structure that is over three levels deep, like this:

domain/
	2010/
	      01/
		  1/
			post-slug-1
			post-slug-2
			post-slug-3
		  2/
			post-slug-4
			post-slug-5
			post-slug-6
		  3/
			post-slug-7
			post-slug-8
			post-slug-9
	      .
	      .
	      .
	2011/
	2012/

That’s going to give you some long permalinks, especially if you just use the default WordPress-generated slugs. When you look at a permalink using “year/month/name” format, you are essentially creating a virtual folder structure with a subdirectory for each part of the permalink – the year represents a directory in which you have a bunch of directories for each month, and within each of those directories there could be as many as 31 subdirectories for each day of the month. Then, within each day of the month, you have the post file itself, which may involve further subdirectories when paging is used. It can get crazy pretty quickly, and even though these subdirectories only exist virtually, to a search spider, there is no practical difference between virtual directories that are deeply nested and actual directories that are deeply nested.

When deciding on your permalink structure, ask yourself if you really need the date built into your permalinks. If you are posting prolifically, then you may want to include the date to help keep things organized. Anything less than a few posts a week, and I would opt to go with something simpler, like maybe “year/post” or “id/post”, as mentioned above.

Another thing that needs considering is the notion of “evergreen content”, which generally refers to content that is intended to stay “fresh” or relevant forever. Regardless how silly this SEO idea happens to be, you may want to consider either omitting or including some sort of date information based on how easily you want the publication date to be recognized by your visitors. I.e., if you are trying to “hide” the post date in hopes that your content will rank for a longer period of time, then you should omit it from the general permalink structure. Conversely, if you aren’t that slimy and want to make it easy for people to know when the post was produced, then throw a year or year/month into the mix. Whatever!

Think simplicity

When it comes to organizing the content of your site, there is a fine balance between being well-organized and keeping things simple. For example, the simplest structure would involve all posts and pages directly under the root domain. Clean and simple, but as time goes on and your post count gets into the hundreds or thousands, it could be a drag trying to sort through everything in a flat directory structure. Thus, another reason why breaking things down into categories or dates may help your long-term organizational and maintenance strategy.

For the post-specific portion of the permalinks (the post slug), it is also wise to keep things simple, but not at the risk of duplicating post names. For example, if you are writing a post about jQuery, you might have a post slug that is simply “jquery”, but it’s not going to be very helpful. First, it probably will never rank for that term. Second, telling users that the article is about “jQuery” is about as useless as it gets for both people and machines. So although that would be the simplest permalink possible, it is your interest to specify a little more clearly the content of your post. It just makes everything easier when meaning is readily available from your permalinks.

Do it before posting

Once you hit the “Publish” button, there is one thing that you shouldn’t change: the post slug. After publishing a post, you can easily and without consequence go back and change the title, meta title, post content, and just about everything else. But as soon as you change that permalink, you will need to 301 redirect the former URL to the new one in order to avoid perpetual 404 errors now and in the future. But, if you do need to change the permalink after posting, here is a simple line of HTAccess to help you eliminate any potential 404 errors:

Redirect 301 /old-post-slug/ http://example.com/new-post-slug/

So it’s really very simple: we first call the redirect directive, declare it as status 301 (permanent), and then add the old slug followed by the new one. That line will redirect any requests for your previously “slugged” URL to your new URL. For more information on htaccess redirects, check here and here.

Think of the keywords

As discussed, a great way to create focused, relevant permalinks is to remove the fluff and include only the important keywords. Granted, Google et al may already discount simple words such as “if”, “and”, and “the”, but you may also have keywords for which you don’t necessarily want to rank. For example, if you published a post on why Batman is terrible at website design, you may wind up with a auto-generated post slug like this:

batman-sucks-at-website-design

The word “at” should probably go, leaving this:

batman-sucks-website-design

But you may want to rank primarily for the term “website-design”, while “batman” is merely anecdotal, used as example, or whatever. Chances are low that anybody is searching for “batman website design”, but you never know.

WordPress removes stuff too

It should also be noted that WordPress removes certain things from your post/page slugs as well. Namely, any punctuation that is included in your post titles will be removed when WordPress automatically generates the post slug. This is both a good thing and a bad thing, depending on how you look at it. There are certain characters that are not allowed in any URL, so WordPress is wise to remove them for you. On the downside, removal of punctuation and the use of hyphens as replacements for periods can leave you with some rather odd-looking permalinks. For example, when writing about the latest WordPress update, say version 3.1 specifically, writing this as your title:

Introducing WordPress 3.1

..will give you this as the default post slug:

/introducing-wordpress-3-1/

..which to me just looks incorrect, like somebody wasn’t paying attention. Moral of the story: even if you’re too lazy to optimize your permalink slugs, it is wise to be mindful of what’s going on with the auto-generated stuff. In this regard, the WordPress devs made an excellent decision when they decided to move the permalink edit box to just below the post title. I do think it could be a little longer though. Most of the time you need to scroll sideways a bit to see what the entire permalink is looking like.

WordPress short URLs

What about Twitter-friendly “shortlinks” for your posts? Generally even the shortest permalink is going to be too long for tweeting, posting, sharing, etc. There are many ways to create short links, but WordPress actually has two built-in ways to create and display short URLs. Let’s take a look at each:

First is the “old” way of doing it. By default, WordPress uses a query-string format for your URLs. As discussed throughout this article, most WordPress users opt for the “pretty” permalinks instead of going with the “ugly” default URLs. But even when permalinks are used, WordPress still understands the default query-string URL structure, so you can include short links in your posts by doing something like this:

<?php echo get_bloginfo('url')."/?p=".$post->ID; ?>

Shortlinks have become so common that WordPress 3.0 now includes a built-in template tag for this very purpose. All you need to display shortlinks in WordPress 3 and above is include the following code in your theme template file(s):

<?php the_shortlink('link text', 'link title', 'before link', 'after link'); ?>

Either of these methods will output a link with the following URL structure:

http://example.com/?p=77

Also note that WordPress 3.0 now includes a shortlink in the <head> section of your posts and pages, something like this:

<link rel='shortlink' href='http://example.com/?p=77' />

This is in addition to the canoncial link tag that is also included in the <head> section.

WordPress canonical links

WordPress canonical URLs are included in the <head> section of your posts and pages. They look like this:

<link rel='canonical' href='http://example.com/post-slug/' />

These canonical links help the search engines better understand the structure and content of your site. By including the canoncial element in your pages, you are telling Google et al which pages are the actual, canonical pages for your site. There are several cases where this is extremely helpful, namely:

• Social media linking often involves shortlinks – specifying a canonical link helps ensure that all of the shortlinking is sorted out and that your actual page gets the credit
• Shopping cart sites that feature lots of query-string URLs – when many links look practically identical, having a canonical link specified helps to sort things out
• Guest posting and other duplicate content – when your content is featured (or scraped) in multiple places around the Web, it is nice to have a clear signal as to which case is canonical

You don’t need htaccess to make changes

What if you want to change the general structure of your permalinks? How do you go about doing that without losing your page rank while creating a mess of 404 errors? In older versions of WordPress, this was a real concern. Many folks began with full-date permalinks and then later realized they wanted cleaner, shorter, “dateless” permalinks instead. To do this back in the day, some HTAccess trickery was required to keep the old links from going nowhere.

Fortunately those days are long gone, as WordPress now automagically handles all the redirecting for you when making changes to the general structure of your permalinks (via the Settings > Permalinks options in the WordPress Admin). All you need to do is change the setting to whatever structure you would like and WordPress takes care of the rest. Just remember to backup your database and htaccess file before making any changes.

© 2010 Digging into WordPress | Permalink | 38 comments | Add to del.icio.us | Post tags: optimization, permalink, tips

As good as WordPress happens to be at catching and redirecting non-canonical requests, there are other types of problem URLs that need to be fixed. Specifically, for permalink-enabled WordPress sites, the following three URLs result in dead-end, 404 (Page Not Found) errors:

• http://your-domain.tld/blog/tag/
• http://your-domain.tld/blog/search/
• http://your-domain.tld/blog/category/

The pages referred to by these URLs simply do not exist by default. Although these pages may not be requested by the average visitor, they are frequently visited by search engines such as Google. Whenever Google (or a curious visitor) attempts to load these pages, it encounters a dreaded 404 error. This is not good for your visitors and statistics, and it certainly isn’t helping your site’s search engine position and page rank. Fortunately, an easy fix is available for those on Apache servers with access to either their httpd.conf or root HTAccess file.

If your site is located in the root directory of your domain, place this code into your root HTAccess file:

RedirectMatch 301 ^/tag/$      http://your-domain.com/
RedirectMatch 301 ^/search/$   http://your-domain.com/
RedirectMatch 301 ^/category/$ http://your-domain.com/

Likewise, if your site is located in a subdirectory called “blog”, use this code instead, and place it into your site’s root HTAccess file:

RedirectMatch 301 ^/blog/tag/$      http://your-domain.com/
RedirectMatch 301 ^/blog/search/$   http://your-domain.com/
RedirectMatch 301 ^/blog/category/$ http://your-domain.com/

Almost done! If you are using the first block of code (WordPress installed in site root), edit each of the three instances of “http://your-domain.com/” to reflect the location to which you would like to redirect the dead-end URLs. For example, you may want to redirect all three URLs to your home page to extract any leftover rank juice. Another option would be to redirect each URL to a similar page on your site. Anything is possible here; proceed according to your own strategy.

If you are using the second block of code, in addition to editing each instance of “http://your-domain.com/“, you will also need to edit each instance of “/blog/” to match that of your actual subdirectory.

After editing the code and uploading to your site, you should now enjoy three less dead-end, 404 errors to worry about, while enjoying the SEO benefits of a cleaner, tighter WordPress-powered blog.

© 2009 Digging into WordPress | Permalink | 12 comments | Add to del.icio.us | Post tags: 404, permalink, redirects, search

h3 { color: blue; }
body#about h3 { color: red; }

But how do you get that ID on the About page, but not on any other page? If you have your permalinks set up to show the page name, like http://yoursite.com/about/, you can use PHP to extract the “about” part of that URL.

Here is the magic:

<?php
	$url = explode('/',$_SERVER['REQUEST_URI']);
	$dir = $url[1] ? $url[1] : 'home';
?>

<body id="<?php echo $dir ?>">

© 2009 Digging into WordPress | Permalink | 5 comments | Add to del.icio.us | Post tags: body, CSS, header, permalink