Back here I wrote about the benefits of using as few plugins as possible on your site.
As is typically me, this has turned into a bit of a crusade (removing plugins from my site, that is).
Here, again, are the reasons for my crusade:
Plugins can slow down site load times, they may fall behind WordPress developments (potentially causing problems after upgrades) and they create more to go wrong.
Removing the Redirection Plugin and Doing Redirects Manually
There are often better ways of achieving what your plugins are achieveing, so here’s what I did with Redirection.
Before we go any further let me make it absolutely clear: Redirection did a great job for me.
I experienced absolutely no problems with the plugin itself and, if you’re not ready to play around with your .htaccess file, this plugin will handle redirects for you without any problems.
But remember my crusade: I’m progressively removing as many plugins from my site as I can, replacing them with other ways of achieving the functionality they provide.
My experience and use of Redirection
Redirection does a number of things:
- It enables you to set up manual re-directs where you change a post permalink
- It automatically creates a 301 redirect if a permalink (post URL) on your site changes
- It logs 404 errors
- It provides statistics and reports on anything to do with redirects and 404 errors.
It’s a powerful plugin and I had it installed for about 18 months in total.
During that time I set up 4 manual redirects where article permalinks had changed. I set these up when I originally installed Redirection. In fact the reason for installing it was because I changed the permalinks on those 4 articles to make them more SEO-effective.
No auto redirects were set up by the plugin during that time because no permalinks on any other articles were changed.
I want as few 301 redirects as possible on my site. So I always give a lot of thought to permalinks when I publish new articles in order to avoid any temptation to change them later.
With that low level of use, I figured if I could learn how to set up 301 redirects manually in my .htaccess file I could do away with Redirection, saving myself another plugin.
What I did
I searched online for tutorials on how to set up 301 redirects.
301 type redirects, by the way, are permanent redirects. These are better for SEO purposes (you don’t lose incoming links) and they also update the visitor’s browser if they already have the page bookmarked under the old URL.
Most of the information I found focused on redirecting existing pages to another URL. In other words – there’s an actual page at link (a) and you add the redirect script to that page (or create a page in a folder and add a PHP redirect call) to send visitors to page (b).
Visitors are being redirected from one page to another.
But when you change a permalink in WordPress there’s a big difference:
You’re not redirecting visitors from one page to another. You’re asking the server to display the same page which now has a different file name from the one the searcher typed in.
You achieve this via the .htaccess file.
As long as you’re running WordPress on a Linux/Apache server you will have a .htaccess file in your blog’s root directory. If, for any reason, you don’t then you can add one.
In that .htaccess file you can type the following command to re-direct visitors to the new permalink:
redirect 301 /old-post-slug http://www.example.com/new-post-slug
Take careful note of the spacing.
Notice, also, that you don’t include the entire URL for the old post. You only need to include the
/old-post-slug (if your blog is installed under the root domain name) or
/directory/old-post-slug if your blog is installed in a directory under your domain.
But the new URL does need to include the full address, even if it’s on the same site.
So, using that format, I set up redirects in my .htaccess file for the 4 articles I referred to earlier and, hey presto, another one bit the dust. (Plugin, that is).
This will work for most WordPress users because you’re likely to be hosting your site on a Linux/Apache server. If you’re on a Windows server this won’t work for you because Windows doesn’t support the .htaccess file.
But most importantly: take a copy of your .htaccess file before you make any changes to it. It’s a powerful file and screwing it up will likely make your blog disappear into the ether.
If the unthinkable does happen, you can use FTP to restore the back up copy of your .htaccess and you’ll be back in business in no time.
What would be great to know is what you’ve done to remove plugins. Leave a comment telling us what plugins you’ve removed and how you replaced the functionality they provided.