If there’s one issue that strikes dread into the hearts of SEO practitioners more than any other, it’s redirects.
It’s no surprise, really. After all, there are so many ways to do redirects — and the rules change depending on where they are put in and the different systems in place.
What is a redirect?
A redirect uses one of many methods to forward from one URL to another and supports canonicalization of signals (such as links) to the correct page.
Forwarding users is usually one of the main considerations for redirects, but as SEOs, we also need to be conscious of the signals being passed. Redirects are one tool for consolidating signals like links and passing them from one page to another.
I know people have varying opinions on how long redirects should be in place, and many use the formula of “no traffic through the link in x amount of time” as a guideline to delete redirects. But I’ve said it before, and I will say it again: until the day I die, I will never delete a redirect that still has useful links to it. Google recommends:
Keep the redirects for as long as possible, and consider keeping them indefinitely.
How do I redirect?
This isn’t a simple question. How you redirect will depend on the technology stack in play and your intent. Are you redirecting one page to another, one domain to another, are you maintaining the file structure, redirecting multiple pages to one, redirecting a folder to another? There are a lot of considerations for where you’re going to put in the redirect, and there are other steps you will need to take depending on the situation.
I know many SEOs whose view of redirects is limited to a plugin and 1:1 redirects, but reality is messy. Let’s take something like a simple domain change. Where do you start? Does your plugin even let you do this? If you redirect in, say, an .htaccess file, then what? Do you leave that server up, or do you move the site to a server with the new domain and leave that active? I’ve seen this many times, but the best way to do this is usually at the DNS level.
Then other problems pop up, like did you redirect all subdomains, did you redirect everything to one page, or did you maintain the folder structure? Now, if you changed the folder structure or URLs, that will produce a lot of 404s that will need to be identified and redirected. Things get messy quickly. Redirecting all to a single page is usually wrong, and many people don’t realize that if they retain the domain name but the new website has a different folder structure (and therefore different URLs), they have to put more redirects on the new server as well in order to redirect to the most relevant pages.
Where can I redirect?
- DNS level. Check with your hosting provider or possibly CDN, whoever is managing your name servers. The rules vary a bit but are usually well-documented, and redirects at this level are perfect for domain changes.
- CDN level like Akamai Edge or Cloudflare Page Rules. Moving redirects from origin to the edge can speed up the process and simplify implementation. Usually for ease, speed and scalability, offloading the redirects to the edge is my preferred method, but many SEOs don’t seem to know this is an option or haven’t taken advantage of it yet.
- Server level. The method changes a bit and may have multiple ways to do it depending on if the server is Apache, nginx, or IIS. All are pretty well-documented, but most people seem to use .htaccess in Apache, while ignoring that it also has a server config file that has many advantages, like caching. If you’re using a plugin on WordPress or tools in Cpanel, you may not even realize it, but you’re likely on an Apache server, and what that tool/plugin is editing is the .htaccess file.
- HTTP header response. Not to be confused with the <head> section, this is one of the most often missed redirects when troubleshooting issues. You will more often see an HTTP response with the redirect specified and a “Location” tag, but there can also be a “Refresh” tag that functions similar to a meta refresh.
- Language-based redirects. You can implement redirects using most languages like PHP, JS, HTML (meta refresh), Ruby on Rails, .NET and so on. In fact, many of these have multiple ways in which redirects can be implemented.
Things can get even more complicated in an enterprise environment which may use several of the above methods, have different infrastructures with different rules, or have processes and internal tools you need to go through in order to put in redirect requests.
Quick tips for redirects
- Figure out how you are going to implement them. This may require use of one or more of the above places.
- Don’t block or noindex anything. Many people think they need to block the old URLs after they redirect to remove them, but what this actually does is cause search engines like Google to not be able to crawl the page and see the redirect, so it can’t pass value to the new URL.
- Watch out for special cases like index pages, which may require rules of their own.
- Watch out for multiple hops. Simple things like trailing slashes or switches from HTTP to HTTPS can cause additional hops and cause delays.
- Check for redirect loops, which can crash your site.
- Learn regular expressions. Google a guide or cheat sheet and find a good regex tester. This will save you a lot of time when it comes to patterns that can be matched for bulk URL redirects.
- Check if a redirect caused a soft 404. (For more information on this, Glenn Gabe has a useful post on soft 404s.)
- Use the right status code: 301, 302, 307. There are others, but they are less common. 301s are called permanent redirects, but they are not actually permanent, just cached. They can be changed, so if you’re moving a page or a domain for more than a few weeks I’d go ahead and make the redirect a 301. Many SEOs will tell you to always use a 301, but it really depends on where you want the signals to consolidate. If, for instance, you’re offloading to another server that changes the address, and then you canonical back to the original URL, or you simply are changing a URL for a short amount of time, I’d use a 302. Nothing is ever as simple as “just do this one thing,” is it? For the most part, use 302s when you want signals at the original URL, and 301s if you want the signals consolidated at the new URL. A 307 these days is mostly from HSTS and being browser cached, there could be a 301 or a 302 behind it. You can check which with a browser with no history, such as in incognito mode and monitoring the redirects, or check the header response using Fetch within Google Search Console.
- Rebuild or pull a page list and check redirects with Screaming Frog, or check individual redirects as Aleyda Solis showed with Chrome Dev Tools (#5), or grab Link Redirect Trace for Chrome.
To get started, I recommend you fix your broken links and learn how to implement redirects now. If you can at least figure out one way now, you’ll have a better understanding of the process, and it will make it easier to learn more as you run into different situations or new systems.
The post 1,000 ways to redirect appeared first on Search Engine Land.
No comments:
Post a Comment