After installing WordPress, one of the first things I needed to configure was my permalink structure. I read several articles on how to do this, but none of them had the information I was looking for. In fact, I was pretty shocked at how difficult it was for me to accomplish the permalinks used throughout this site. In this article, I will show you exactly how I achieved natural, SEO-friendly permalinks.
What does a natural SEO-friendly URL look like?
When I say natural URL, I’m talking about a URL that looks like it belongs to a static HTML web page. In other words, I want my URLs to look like they would if I wasn’t using WordPress at all.
Here is the static HTML website I’m trying to represent:
Why are natural permalinks better?
Because Matt Cutts says so. Watch this Matt Cutts video where he answers a question about file name extensions. If you don’t want to watch it…I’ll summarize it for you: Don’t strip your URLs of their file extensions. If it’s an HTML page, let it end with .html.
Okay, here’s how I achieved natural URLs:
To-Do list for achieving natural URLs:
- Add .html to the end of blog posts
- Add .html to the end of WordPress pages
- Remove category base (/category/)
- Add a trailing slash to the end of category archive pages
- Change the default location where Media is uploaded to /img/ instead of /wp-content/uploads/
Step 1: Add .html to the end of blog posts
The first step toward optimizing your permalinks is to change the default URL structure (http://www.seomofo.com/?p=123) to a custom URL structure. In order to do this, go to the Permalink Settings menu (Settings → Permalinks):
In my opinion (and keep in mind…I’m really, really smart), the ONLY custom URL structure that makes sense is this:
[ BTW...this isn't a picture. You can copy this text. ↑ ]
Step 2: Add .html to the end of WordPress pages
Install this plugin, which adds .html to WordPress pages.
Step 3: Remove category base
Install this plugin, which removes the category base from WordPress URLs.
Step 4: Add a trailing slash to the end of category archive pages
Install this plugin, which adds a trailing slash to the end of category URLs.
This plugin requires a simple modification. This plugin will add a trailing slash to category pages AND regular WordPress pages. We only want it to apply to category pages, otherwise we will end up with page URLs like this:
http://www.seomofo.com/about.html/
To prevent the plugin from adding a trailing slash to our WordPress pages, open the plugin in your editor and locate this code:
function ppm_fixe_trailingslash($url, $type)
{
if ('single' === $type)
return $url;
return trailingslashit($url);
}
Replace it with this modified code:
function ppm_fixe_trailingslash($url, $type)
{
if ('single' === $type)
return $url;
if ('page' === $type)
return $url;
return trailingslashit($url);
}
If you have any other plugins that use your permalinks (e.g. the Google XML Sitemaps plugin), they will need to be initiated AFTER your permalinks have been modified by the plugins mentioned above. You can do this by editing the main plugin file and changing the name (the part after “Plugin Name:” that’s usually on line 2 or 3 of the code) to something higher in the alphabetical order. For example, I saved a second copy of the “Permalink Trailing Slash Fixer” plugin and named it “A Permalink Trailing Slash Fixer.” It now appears in my WP admin dashboard BEFORE the Google XML Sitemap Generator plugin, and therefore…my Sitemap URLs are the modified versions. (Tip: to make sure you’re still notified when the plugin needs to be updated, keep a deactivated copy of the original file–the one with the original name–with your other plugins.)
Step 5: Change the Media folder to /img/
This step is optional. Personally, I think storing all your images in a folder like /wp-content/uploads/ is kinda lame. I’d much prefer a traditional folder name like /img/. In order to make this happen, go to your Miscellaneous Settings menu (Settings → Miscellaneous), and modify the defaults to something like this:
If you’ve followed these steps exactly, you should now have a URL structure that gives no indication that you’re using WordPress. They should be clean, natural, and SEO-friendly.
Now before you go…do me a favor and click every single one of these widgets:
{ 27 comments… read them below or add one }
Why do you want your pages to look static with .html? Whats the benefit? I’m just about to convert my static pages to powered by wordpress/thesis and cannot decide what to go for…
seo-friendly-permalinks/
seo-friedly-permalinks.html
seo-friendly-permalinks (no trailing slash-seomoz style)
I’ve also seen Yoast mixing them up.
If you’re moving a static site, don’t your pages end in .html already? If it’s at all possible to keep your old URLs, then that’s what I would recommend. Doing site-wide 301 redirects almost always causes a loss in rankings.
Here are my reasons for using static-looking URLs:
1. They look nicer. This is a matter of opinion, but I think most people prefer traditional, natural URLs.
2. They offer more information to users (and possibly search engines). For example, if I didn’t use trailing slashes and .html extensions, then how would you know what this URL points to:
http://www.seomofo.com/wordpress/thesisSome people might think that’s a post called “Thesis” in a category called “WordPress,” but it’s not–it’s a subcategory archive page.
3. They’re easier to move to another CMS (or static pages), while keeping the same URLs.
4. They are trusted more.
5. I’m serving an HTML document…so why wouldn’t I include that filename extension? Not all user-agents and Web devices are going to assume a document is .html if it’s not labeled explicitly.
The big question is…which option will rank the best? Unfortunately, I have no data to suggest that one is treated any different from the other, but I can certainly imagine natural URLs ranking higher as an indirect result of the reasons I listed above.
Hey Darren,
This information is really good, thanks.
One question – I’ve sorted my normal pages:
http://domain.com/page.html
I’ve sorted my detail pages:
http://domain.com/category/product.html
However, I would also like to have category pages as:
http://domain.com/category.html
Is this possible?
Am I missing something simple?
Thanks,
Rob
Hi Rob,
I’m sure it’s possible, but it would require customizing (or creating) a plugin. With my weak understanding of php and WordPress, this is the kind of task that I would tackle with an FTP program and a healthy dose of “guess and check.”
The first thing I would try…
Open the
top-level-cats.phpplugin and look for a place where you can add ‘.html’ to the category permalinks.After crashing my site several times, if I still couldn’t get it to work, then I would try…
Open the
html-on-pages.phpplugin, save it as a new plugin, and then change all instances of page-specific code to their category-specific counterparts.If I still couldn’t get it to work…I’d grab a beer and drink away my problems.
I just wanted to say I am really enjoying your posts.
Tech savvy post with a hit of sarcasm and general human nature.
Cheers and yur the top of my RSS reader. . .
Excellent read Rob
You earned yourself a natural backlink, and I mean natural, just because I found it excellent information WTG.
hi daren,
i had try to move folder /upload to parent dir, but i’ve got a note “Unable to create directory / Is its parent directory writable by the server?”
then had to changes chmod to 755 or 777, still doesn’t work, and so i’ve try to add full path public_html/sumthingdirectory seems the upload succesed but the image is blank.
i’ve try this at wp 2.9
can you tell me the part i missed?
thanks
Hi Gabril,
If you want the folder “upload” to be in your root directory, your Miscellaneous Settings should be:
Store uploads in this folder:
uploadFull URL path to files:
http://www.domain.com/uploadHowever, I will also mention this…
Ever since I updated WP to 2.9, I have been seeing some strange behavior with my image uploads. If I upload an image through WP, it automatically creates 3 copies of that image at different sizes. I haven’t had a chance to look into it, but I can tell you that WP 2.9 definitely made some changes to the way images are uploaded.
When I updated to 2.9, I got the same error message that you got. I made my /img folder writeable, and that resolved the error…but now WP is creating a bunch of images I don’t need. If you uploaded
example.jpg, there is a chance that WP saved it asexample1.jpg, so try that address and see if the image is there.I’ll keep you updated if I find out any more information.
-Darren
Hi Daren, i resolved it with enter full patch root at Store uploads in this folder and set chmod with 755
you can look at : http://www.wintersvolvo.com/2010-a-r-t-g-streetline-mercedes-benz-g55k-amg/
thanks
I take on board what both you and Matt Cutts have said but I don’t think something like this will appeal to the masses or is even necessary a lot of the time.
I agree that having .htm(l) at the end of a page makes it seem much more friendly, but the majority of people won’t even look at that or notice that. The reason we see it is because we’re SEOs and digital professionals – the general public would just think ‘oh a page, that’s all’.
That being said, I can see the benefit on website directed at people like you or I. However, I think most of us would know whether we’re on a trusted site or not anyway and if we did have doubts, just avoid it all together or find alternatives.
A little off-topic, but I think the forming of a url like http://www.traxor-designs.com/blog/ looks a lot nicer than http://www.traxor-designs.com/blog.htm(l). The former just seems more ‘complete’.
I have a question that I’m sure you know the answer to:
I recently changed my permalink structure to include the trailing slash at the end of all my posts and pages, from
/%postname%-%post_id% to /%postname%-%post_id%/ .
I have attempted to add redirects to my .htaccess to reflect this change, but I have run into a brick wall. I can see that Wordpress automatically redirects the pages to add the trailing / to each post and page, but what do I do about Google?
Keep up the great work, and thanks in advance for answering my question!
Hi Joe,
If I understand you correctly, you’re saying the original URLs are correctly redirecting to the / versions, but Google already has all the slash-less URLs indexed?
If your URLs are redirecting (make sure they’re using 301 Permanent Redirects), then Google will eventually replace the slash-less versions with the / versions.
If you want to try to expedite this transition in Google, you can make sure your sitemap.xml file has the new URLs in it (and then submit it through Google Webmaster Tools), and you can also add the rel=”canonical” meta tag to each page (which should contain the new URL in the tag).
Did that answer your question?
Thank you for the quick reply.
Yes, precisely.
The interesting part is that the redirects occured automatically after I added the trailing slash (i.e. I did not have to add anything to the .htaccess file, or adjust any internal wordpress settings that affect the virtual robots.txt file.)
Clicking on any of my indexed pages on Google will direct it to the new slash-ending page. Life is good, right? BUT, none of the former page’s PR carries forward.
When I do add a line into the .htaccess, such as redirect 301 www.mydomain.com/mypost-123 http://www.mydomain.com/mypost-123/, it will not load the post and shows a DNS (i think?) error.
Do you know any jazzy Rewrite code that I can install into .htaccess to handle redirecting old pages and posts without a slash to the new slash-ending format? Or should I just let nature take its course?
Perhaps this would make for a great post down the road, because there is nada on this topic out there on the web…
I guess moral of the story: if you want the trailing slash, you better add it from the get-go to avoid any heartache and potential loss of PR on posts and pages.
Good advice on the GWT and the canonical. I’ll check those now. Thanks!
Okay, I’m assuming the domain in question is the one you included in your comment form. If that’s the case, you don’t need to worry about it: your pages are already 301 redirecting, and Google will take care of it for you.
There are a few different tools/plugins that show you your server’s http header responses (i.e. 301 Permanent Redirect, 200 OK, 404 Not Found, etc.). Here is one of the better ones, using the following URL as an example:
www.teamensor.com/realestate/eastaustin
If you scroll down that page a bit, you’ll see a section called Server Header Details. The first portion is the request sent to your server, followed by your server response. In this case, it reads: SERVER RESPONSE: 301 Moved Permanently
That’s exactly what it should be. You don’t need to add anything to your .htaccess file. When Google tries to crawl the old URLs, it will be redirected to the new URLs, and eventually it will update its index to reflect the new URLs. You shouldn’t lose any PageRank or any other data associated with the old URLs–it will all be forwarded automatically. You might see a drop in rankings during this transitional period, but it will recover when most of the new URLs are indexed.
As a side note: you’re getting errors from the .htaccess code because you’re using a full URL in the first part. It should only be a relative URL, like this:
redirect 301 /realestate/eastaustin http://www.teamensor.com/realestate/eastaustin/
But again…you don’t need to add that. WordPress is taking care of it for you. Just FYI for future reference. =)
Thank you very, very much for your comprehensive answer to my questions. The hunt for these answers was driving me insane.
You definitely are the SEO mofo.
I’ll find some way to tailor up a nice natural link for you as a thank you. Cheers.
Sorry for the late comment…
I’m kinda new to the whole technical side of seo and found this post really interesting. Currently my permalinks are structured like this
/%postname%/
I don’t use the category like you suggest because the targeted keywords are usually in the domain name and it becomes redundant and long but I’m really perplexed about the whole .html extension after posts and pages…
It makes sense to give the search engines more information about the page but my question is on existing blogs will making these changes create a new page and post that now has to be “re-indexed”?
And will it cause the old format to lose rank?
I plan on using the .html extension going forward on all builds but what do you think about existing blogs?
Does it make any sense to go from this /%postname%/
to this /%postname%.html?
Hi Dan,
I would not recommend changing URLs for sites that are already up and running (i.e. already indexed). There’s no ranking benefit (that I know of) for using the .html extension; it’s mostly just for usability.
If you were to implement a site-wide change to your URL structure (and 301 redirect all old URLs to new URLs), then search engines would re-index your pages under the new URLs.
More often than not, doing a site-wide redirect will cause fluctuations in rankings–usually a temporary drop–so unless you’re okay with that…you’re better off leaving the site how it is.
Hi,
Updating my wordpress blog with new domain today of which I will 301 to new domain.
If I remove the category base only, will Wordpress automatically 301 all the files, someone told me last night that Wordpress always automatically 301’s posts?
For those who have relatively small sites and want to follow Darren’s advice, the Redirection plugin could make your life easier. It allows you to specify that 301 redirects be created automatically any time a URL changes. Very handy.
http://wordpress.org/extend/plugins/redirection/
NOTE: I have not tested this plugin’s effectiveness with regard to the steps specified in the post above, so be sure to check for yourself that 301 redirects are actually being created automatically as you’re making changes. If for some reason they’re not, you can still configure the 301s manually using the plugin.
HINT: keep a copy of your original sitemap.xml file so you can easily check that all the old site URLs are redirecting properly to the new URLs and fix any that may not.
I done all you recomend and everythink works great.
But i have a question im useing a plugin name is Arne Brachhold’s Google XML Sitemaps. when i check my sitemap : http://www.evmagazin.com/sitemap.xml there is no slashes at end of categories example: http://www.evmagazin.com/zemin
http://www.evmagazin.com/yapi
Can any one help pls
Thank you
Fixed thanks
Great. Once again, it’s up to Alan to provide the invaluable insight that has been overlooked in all this nonsense. Screw what Matt Cutts says about leaving the file extensions in place. Not because he’s not a decent enough guy. Because he seems to be a nice guy.
Instead, the reason to ignore that hack-job nonsense, the REASON to ELIMINATE file extensions is because of portability and scalability. Which is just as, if not MORE important than the “Do what Google says” mentality that exists today.
If a site is built in PHP and if that site then has blahdeblah.com/whatever.php, then you go and decide that you want to have your site migrated to a different platform, even if it’s PHP using the Zend framework and an MVC methodology, you’ve got more work to do in a hackish way to keep the .php extensions.
Or if you go to a .aspx environment. Then what? Or if you’re just dealing with a site that’s currently static but has 500 pages and every one ends in .htm because it was built for a Windows server, but now you have to go to a different server that requires .html as the extensions…
And so on and so forth…
By starting out without file extensions, you eliminate what could become a massive beast of a problem later on.
But what the hell do I know? I’ve only been dealing for fifteen years with asshat companies that implement totally unrealistic unscalable and proprietary things that leave the next company that comes along a total nightmare of a task at porting that old garbage. So maybe I don’t know what I’m talking about.
There are a few things I disagree with or don’t understand.
Scalability – I don’t understand how this relates to file extensions at all. Rewriting “.html” to “.php” takes only a few milliseconds, regardless of how many pages are on the site. And even if it DID hinder scalability, that’s not a concern for the average WordPress site owner.
Portability – I don’t understand why this would be an issue. If all servers interpreted extension-less URLs as an implicit use of their native file extensions, then this argument might be valid. But that’s not the case. In reality, if you’re moving a site from a .php framework to .aspx (not that anyone would ever do such a thing), then you’ll still need to rewrite your URLs…whether it’s .php => .aspx or no extension => .aspx. In fact, the only move that wouldn’t require ANY rewrites would be if I moved this site from WordPress to static .html files.
Do what Google says – Unfortunately, this is an unavoidable part of search engine optimization. Google does a lot of stupid shit that doesn’t make any sense, but if stupid websites are ranked better, then that’s what we build. I don’t like it any more than you do, but I’m not going to cripple my websites’ rankings for the sake of being right.
So I guess I disagree with everything you said. Maybe if you learned how to write regular expressions, you wouldn’t have such a huge, nonsensical chip on your shoulder?
Oh wait…I take that back; I agree that Matt Cutts is a nice guy.
We disagree on something? Wonders never cease! Look – I’m not an engineer by trade and the vast majority of site owners can’t keep the same developer or team of developers around long enough to address migration issues. By eliminating file extensions you eliminate any need to deal with rewriting URLs OR doing 301 redirects in many situations.
And I wasn’t just talking about WordPress – but more web sites in general. Of which there are exponentially more on this earth than there are of WP driven sites.
So the real issue then comes down to one of “are we talking about sites built by engineers where those sites are their own, or are owned by a client or employer?” Because if it’s for a client or employer, the responsible thing to do would be to make the site as portable as possible.
So…you dropped the scalability claim and failed to explain the logistics of your portability claim. FAIL.
Explain this:
Darren,
Not every site is a WordPress site and that’s where much of this comes from, so yeah – I hijacked your WP perma-link article for my own rant. Yet even then, the concept I’m focused on still applies.
I’m coming from a different perspective. If a site is not able to always be maintained by developers who know what they’re doing, it’s best practices to make a site as portable as possible – and by eliminating file extensions, it eliminates one aspect of the transition that can quite easily get screwed up. I’ve dealt with hundreds of site migrations over the years where an extension-less architecture would have made the transition a hell of a lot more effortless.
Great stuff you got here SEO mofo! I just bumbed into your site today somehow and I thank my stars!
Can you help me with one basic info but a vital info for me. I got some 300 articles in my site with the common setting – month and name. You also said redirecting the entire links through 301 is not advisable. So how do i go ahead?