Articles

Even for experienced web developers, learning how to implement 301 redirects with regular expressions can be a black hole of confusion, frustration and infinite loops.

Regular expressions are not just a new language, they’re also a new language that’s a little bit different from context to context. For example, you can use them in PHP, but they’re a little bit different in JavaScript, and different again when dealing with redirects. Add to the mix that this isn’t something most developers need to do on a daily basis, and you end up with a lot of copying-and-pasting, trial-and-error, and a process that’s generally longer than more difficult than it really should be.

Today, we will focus exclusively on building effective 301 redirects by detailing a handful of common, flexible regular expressions. You could theoretically build a similar system of redirects with plain text (that is, with no regular expressions), but this method allows you to accomplish the same thing with far less data entry, and in a way that can cover an infinite number of URLs.

The WordPress Redirection Plugin

You already know that redirecting old, unused URLs to new pages on your site is crucial for SEO purposes, ensuring that any search value held by those old pages transfers to their new counterparts. When you build a new site, you’ll often need to redirect pages en masse. It’s also something you’re likely to do from time to time during the management of an existing site, such as when a page is removed or renamed.

There are many ways to approach redirects, but the simplest and easiest to manage is the Redirection plugin by John Godley. (Note there are a number with similar names, so make sure you grab this one.) While far from perfect, this is a handy tool because:

• You can manage all redirects via the WordPress dashboard, allowing non-technical users to view and update redirects when appropriate.
• You can track the number of hits to your redirects, and it also tracks 404 Not Found errors.
• You can use this even if your server doesn’t run Apache or doesn’t allow you to edit .htaccess (which is the alternative method for adding redirects in most cases).

Install and activate the plugin, then navigate to Tools > Redirection to get started.

Starting and ending your redirect URL with regular expressions

The first crucial components of your regular expression redirect are the “start” and “end” characters. This allows you to dictate the beginning and end of the expression to match, and prevents a lot of accidental redirect loops when you use it correctly. Here’s an example:

^/old-page/$

And here’s what this looks like in the plugin:

Note that the “Regular expression” box must be checked for the plugin to respect your regular expressions.

This expression will only apply to the page http://yourdomain.com/old-page/, in exactly that format. If you didn’t include your start (^) and end ($) characters, though, it could also apply to a page like http://yourdomain.com/about/old-page/.

This is especially important if your page URL is relatively generic and could realistically show up in the middle of another URL, like “about” or “product.” By forcing a start and end to your expression, you save a lot of headache with accidental matches hidden throughout your site.

Making trailing slashes optional

You may have noticed that the previous example applies to “/old-page/” with a trailing slash, but not to “/old-page” without a trailing slash. Since many content management systems are wishy-washy about whether they force a trailing slash, force no trailing slash, or allow both versions, your redirects will always need to account for either version of each URL.

Here’s how to use a single regular expression to apply to a page whether it has a trailing slash or not:

^/old-page[/]?$

We’ve added [/]? (slash in brackets with a question mark after it) to indicate that this character should be treated as optional. If you were to read this expression out loud, it’d sound something like this:

• ^ = Start of URL
• /old-page = This must appear in the URL right after the starting point
• [/]? = At this point, there may or may not be a slash
• $ = End of URL

This technique allows you to create one redirect that covers two possible URLs (with and without a slash). The next technique allows you to really go wild.

Creating wildcard redirects

A wildcard redirect allows you to create a redirect based on any page that matches a pattern, regardless of the URL of a specific page. This is especially handy for redirecting whole directories or sections of an old site to a new site. For example, I recently used this to redirect all URLs starting in “/products/” (plural) to the corresponding URL on the new site, which started with “/product/” (singular).

Here’s the regular expression for the pattern to match (Source URL):

^/old/(.*)$

• ^ = Start URL
• /old/ = URL must contain this string at the beginning
• (.*) = Wildcard. This matches anything that appears after /old/ and saves it for use in the Target URL below.
• $ = End URL. This is not really crucial since we’re picking up anything at the end as a wildcard, but it doesn’t hurt.

And here’s the destination (Target URL):

/new/$1

The $1 outputs the first wildcard in your Source URL expression. In theory, you could have an unlimited number of wildcards, like this:

^/old/(.*)/old-section/(.*)

Redirects to:

/new/$1/new-section/$2

While that’s not a super-common requirement, be aware you have flexibility to use as many wildcards as necessary.

Making a smooth transition

Those code snippets should help you accomplish the vast majority of your redirection needs. To avoid confusion and issues (and running around in a lot of circles), follow these general guidelines when setting up redirects:

• Before you test, make sure your local caches and hosting caches are totally clear. Using a Chrome Incognito window is handy for this too, because your browser will often cache redirects behind the scenes, preventing you from seeing changes to existing redirects immediately. If you’re using a caching plugin, host-based cache or Cloudflare cache, make sure that is clear too.
• Avoid “stacking” redirects whenever possible. This causes confusion and is less than ideal for SEO (you really want one redirect per URL as a goal, rather than a “chain” of redirects.)
• If you are getting crazy redirect loops with the Redirection plugin, contact your host about redirecting with .htaccess. The regular expression formatting is similar, but using .htaccess can ensure the problematic redirects are executed before the WordPress ones, which usually resolves any lingering issues.

Not long ago, setting up an SSL certificate was a nightmare even for a seasoned technology veteran. Thanks to new services that allow quick, free setup of fully functional SSL on your site, it’s easy and accessible for everyone.

Today, we’ll walk through the simple steps for setting up SSL with Cloudflare.

First, create your free Cloudflare account. You’ll then need to follow their steps for migrating your DNS to the site. Generally speaking, this is a quick process, and you just need to change your nameservers when it’s done (as you would any time you change to a new web host). In addition to providing free SSL, Cloudflare also has tons of excellent free performance, firewall and caching tools, as well as premium options that up the ante even further.

Once you’ve changed your nameservers and are operating your site with Cloudflare as your DNS provider, log into your account and click the “Crypto” button across the top of your dashboard. Then set your SSL to “Full,” as shown in the screenshot below.

This alone will allow your site to function properly under SSL (that is, https://yourdomain.com). You may need to take a few additional steps, depending on your host and how your site has been built.

If you’re hosting with WP Engine, one of our top recommended WordPress hosts, the next step is as simple as clicking a few boxes and buttons to add a free Let’s Encrypt certificate on your hosting account. You can then use the default WP Engine settings to force all traffic to use SSL, which should cause all your pages to appear secure (and will redirect insecure URLs to their secure counterparts).

For other hosts, you may not need to take any direct action at all, assuming your host will present a “self-signed” certificate for SSL traffic. This is a default certificate that exists on most web servers in some form, and normally it would show a “Can’t verify certificate” error in your browser. The great thing about using Cloudflare is that it presents the verified Cloudflare certificate to the end user, allowing you to use the self-signed certificate on your web server (thus saving you the cost of a formal, verified certificate). The key here is that the encryption is the same whether your certificate is self-signed or verified by an external certificate authority. You save the cost and complexity of verifying and installing your own certificate, since most servers have a self-signed one by default (or your host can easily set this up via a support request).

The last important point: you’ll need to make sure you are not running into “mixed content” errors, which occur when you attempt to load an insecure file, such as an image, JavaScript or CSS file, on an otherwise secure page. If your browser bar isn’t showing a “secure” symbol, check your browser error console to see what the culprits are. Usually this is a result of a reference to off-site file where you have “http://” hard-coded in the URL. This needs to change to “https://” or “://” (the latter will pick up whichever protocol is in use by the current page).

Here are the best ways to fix mixed content issues:

1. Change your WordPress URL  and Site URL at Settings > General to use https://.
2. Try a Force SSL WordPress plugin. There are a few, and some behave differently with different hosts, so you’ll need to experiment.
3. If URLs are hard-coded in your theme, you’ll need to edit your theme files directly to change them.
4. If you continue to have issues, contact your host. They’ll either be able to change settings for you or help you make a change to your .htaccess file to do a better job of forcing SSL on all requests.

Questions? Shoot us a message or comment below and we’ll be happy to help.