One of the things I learned early on when analyzing website traffic to law firms was that it fluctuates on a weekly, not monthly pattern – with low traffic on weekends, and high traffic on Mondays the tapers down over the work week.  Yet most agencies and law firms use monthly reporting.

Granted, monthly reporting is frankly, extremely convenient, as most vendor billing cycles are monthly as well – and most tools report on these monthly cycles as well.  Unfortunately, its extremely inaccurate.  Yesterday’s leap year day will have automagically generated an additional 3% increase in February’s 2016 vs 2015 traffic.  On a typical non-leap year, the number of days in March is 10.7% more than February.  And it’s not just February – as months have small changes in the number of days (or the number of weekends making up those days), the subtle changes hides real performance when looking at month-to-month traffic changes.

This is why we run all of our reporting on 4 week Periods…. a much more accurate approach to monitoring subtle changes in website traffic patterns (no explanations of, “well, last month only had 8 weekend days…”). It also means we sit  down with our clients 13 times a year to review benchmarks and progress, instead of the typical twelve.

Picture this hypothetical website disaster: You are completely overhauling the website for your law firm. You switch domains, implement a beautiful redesign, and migrate all the content from the old site to the new one. One week after launching your new site and pulling the plug on the old one, you notice your traffic has dropped off a cliff and you’re not getting any calls.

The decrease in traffic is probably because some of your old pages no longer load. This causes 2 significant problems for your website.

1. When a page is removed, all the authority it has built up is wasted. On the other hand, new pages don’t have any authority, even if you intend for them to replace old ones. If you don’t let search engines know which of your pages are replacements, they’ll treat those pages like strangers, giving low rankings and little traffic.
2. Prospective clients who visit your site by following a link somewhere on the web won’t want to pick up the phone if that link leads to an error page (or nothing at all). Even if you’re getting a significant amount of traffic, broken pages will prevent that from turning into leads because users are more likely to bounce off your site when they land on a page that doesn’t tell them anything.

Thankfully there is a way to avoid these kinds of traffic-killing disasters. We do this by using URL redirects.

What are URL Redirects?

A URL redirect is an instruction for computers that tell them a webpage has been moved from its old address to a new one. When a computer (such as a prospective client’s PC, or Google’s web crawler, etc.) visits a page with a redirect, it will be automatically sent to the new destination instead of their old page.

This is valuable for users who are attempting to visit a page that has been moved or deleted. Normally a page that doesn’t exist would show an error such as “404 File Not Found”. However, with a redirect you can instruct computers to automatically load the new location of your page, or a related page instead. Now instead of losing a prospective client because you sent them to a blank page, you increase the chance that someone will engage with your site and subsequently contact your firm.

Redirects can also help your performance with search engines. If an old page has built up authority with search engines (in English: a lot of people link to it) but then one day it disappears, you’ll lose all the “link juice” that page provided to your site. Setting up a URL redirect will point search engines to a real page, preserving most of the authority you garnered with Google and keeping your traffic healthy.

Building Blocks of a URL Redirect

While the concept of a URL redirect is constant, the tactical implementation changes for different websites. You might have to declare your redirects on every page individually, put them into a single file, or work with your host’s custom system. Because there is a vast number of ways to set up URL redirects, a comprehensive guide on the topic is outside the scope of this article.

However, there is some common ground for redirect implementation. No matter where or how you implement a redirect, you will always use 3 key pieces of information. Those pieces are:

• Source
• Destination
• Type

Source

The source is the page you don’t want users to see. To write out the source, take the web address that you no longer users to visit, and remove the domain along with everything that comes before it. For example, if we were implementing a redirect with the source:

https://mockingbird.marketing/some-deleted-page/

The domain of our site is mockingbird.marketing, so we remove it and are left with this:

/some-deleted-page/

This would be our source, and we would write that down.

Destination

The destination is the (live and working) page you want to send users towards. Declaring this is as simple as writing down the web address of the desired page. If we were implementing a redirect with the destination

https://mockingbird.marketing/new-page-location/

Then we would just write that.

Type

Redirects come in 8 or 9 types and each one has a different technical reason why it will be used. However, you can learn 2 redirects and use them essentially 100% of the time. These have status codes and nicknames, both of which are good to know:

• 301 – “Permanent”: This is the ‘normal’ redirect, and it should be your go-to option. A 301 redirect does everything we talked about above.
• 302 – “Moved Temporarily” or “Found”: A 302 redirect is very rarely used. It works as expected most of the time, but search engines ignore 302 redirects for the purposes of assigning authority. Use 302 redirects only if you plan on using them temporarily, like if you need to do website maintenance.

Regular Expressions?

Sometimes you may have to redirect a lot of pages at once. Instead of writing every redirect separately, you can make a “bulk” redirect. For example, if we were migrating from an old website:

https://pelican.marketing/

To our current one (“mockingbird.marketing”), and every single page on the old site was the same except for that domain. We might write a source like this:

^/(.*)/?$

And our destination would be:

https://mockingbird.marketing/$1/

Regular expressions are technical, and using them incorrectly can break your site. They’re beyond the scope of this article, but if you want to learn more about regular expressions then you should check out the Resources section below.

In this post we talked about how URL redirects can save you from a possible disasters by engaging viewers and preserving traffic from search engines. We looked at redirects on a basic level, and what information to start gathering when you want to create your own redirects. Proper use of URL redirects can keep your web traffic (and your bottom line) safe.

Resources

If you want to learn more about regular expression and URL redirects, here are some resources that we’ve found useful.

• webconfs.com has a list of ways to declare 301 redirects in different languages or by using htaccess files. These are some of the different tactics we mentioned earlier.
• Moz has another good description of redirects, along with instructions for implementing 301 redirects in Apache.
• Dave Clements of DoItWithWP has a simple introduction to regular expressions (about as simple as it can get).
• WPEngine has a list of common syntax used in regular expressions, along with examples.
• RegexPal lets you test if your regular expressions work. In order to use it properly, you will also have to treat all forward slashes (looks like this: “/”) as special symbols like “^“, “$“, “.“, and “?“.