301 Redirect, How Do I Love You? Let Me Count the Ways
Alex Bennert, Wall Street Journal is the moderator for troublemaking panelists Jordan Kasteler, Co-Founder, SearchandSocial.com, Carolyn Shelby, CShel, Stephan Spencer, Netconcepts, and Jonah Stein, ItsTheROI.
Carolyn Shelby is up first. She gave me her presentation so I’ll be adding the really important stuff from what she actually says. She’s not going to be covering specifically technical examples.
In a perfect world, Web site relaunches would never be more complicated than changing a domain or the presentation (look and feel) of existing data. In the real world, relaunches HAVE to be done to fix horrendous URL structure and just general wrongness with the existing Web site.
She worked on one site that was all static URLs but they screwed up the implementation. Twice. The result was URLs that were ugly, spammy and not at all easy to 301. They had to set up 301s for every single URL individually.
Uses for 301s (review):
These are painful, but necessary to the long term success of the site and the sanity of the SEOs, content creators, and tech people.
- Redirects users and bots from the old location of a given Web page to the new location (URL).
- Automatically redirects users from an old domain to a new domain.
- Automatically redirects users from alternate TLDs to the main TLD (usually the .com).
- Corrects canonical issue.s
- www vs non-www
- Index.* to /
- Keeps unauthorized users and bots from accessing live development environments, redirects them to main site. (IP-specific delivery)
IP-specific delivery gets a bad wrap but there are legitimate uses for it, like this one. Sometimes you have to have a live site so you don’t want that available to be indexed. Hence, IP delivery.
Basic relaunch:
- New frosting, but the cake is original recipe. [Mmm, cake]
- Possibly moving to a new domain.
- URLs might be losing or changing file extensions. It’s important when you’re moving into, say, WordPress.
- New pages, but few new pages are replacing old pages.
- Few old pages are “disappearing”.
- No significant changes to pre-existing information architecture or nomenclature.
- ^/dir-old/(.*).html$ -> /dir-new/$1
- ^/dir-old/(.*).html$ -> /$1.php
- ^/dir-old/(.*)$
Complicated relaunch:
- The frosting is all new AND the cake is a different flavor, a different shape, and has fruity filling between the layers now.
- The site is large (more than a few hundred indexed pages) and…
- There are significant information architecture and/or nomenclature changes that do not follow a consistent pattern.
Before you begin:
- You should have a list or spreadsheet of:
- All of your current site’s indexed pages (and their URLs).
- All of your current site’s indexed pages with backlinks.
- The relationships/translations from the OLD to the NEW.
- You should also have an understanding of:
- How your redirects will be added to your system.
- How you will be watching/tracking your 404s.
- Any weirdness or quirkiness unique to your CMS or Web server.
Give these things to your teams. You need a map in case you have to do this manually. In her earlier example, they literally had someone just watching for errors so that he could update the link every single time.
Preparation:
- Find a software package to do some of the reports for you:
- List of all indexed pages.
- List of all pages w/ back links.
- For tracking 404s:
- Learn to read httpd error logs, or
- Install software to help monitor the traffic.
- Mint is nice and quick.
- AXS by XAV is old school, but free.
- Webmaster Tools and GA are a little slow, but if you don’t care about latency, these work as well.
- The other reports have to be assembled manually.
- This is why God makes interns.
Why the prep is important:
- Your lists will help you write the redirects.
- The patterns (or lack of) determine the method you use.
- Regular .htaccess Mod_Rewrite or Mod_Alias
- Note: Mod_Rewrites execute BEFORE Mod_Alias, no matter how they’re listed in the file.
- A hash table for large (hundreds or thousands) of redirections.
- Regular .htaccess Mod_Rewrite or Mod_Alias
- If a URL isn’t in your reports, skip it.
Fewer redirects, faster response times. If something doesn’t have backlinks or isn’t indexed, who care?
Give the engines the new site map AND the old site map so that they can find the 301s faster.
Once you’ve done your implementation, it’s time to bite your nails and see what happens.
What to expect:
- Major site overhauls will see anywhere from a 20 percent drop in traffic to being completely dropped from the index.
- Recovery time is generally 6 to 18 weeks. After one week they started to see traffic coming back 15 percent week over week.
- The long tail traffic will suffer more than anything else.
You/your client/boss is not going to like this. Not at all. Prepare them well for it.
Recovery:
- Analytics should show 10-20 percent increases in traffic week over week once recovery has begun.
- Reports showing indexed pages will show more and more of the new pages, and fewer and fewer of the old URLs, week over week.
- The sick feeling in your stomach starts going away.
Hurrah!
Alex mentions that you should use Google Webmaster Tools and download the table to get the page with internal links information.
Stephan Spencer follows up Carolyn.
You can (should) download his powerpoint from http://www.netconcepts.com/learn/301-redirect.ppt. He warns that he goes far too quickly for taking notes, just so you know. This will be short. It may involve me crying. [You’ve gotta appreciate the warning. –Virginia]
He loves rewrite rules and thus you should be using those instead. He likes Apache best but if you’re using Microsoft go with the ISAPI_rewrite plugin.
[Sample rewrite rule here. I do not know what it means. Good luck.]
Become a master of pattern matching and learn all the mysterious signals. [Or, in my opinion, hire a great IT guy] It’s incredibly easy to make errors in regular expressions. Learn what the “greedy” expressions are.
Stephan: “Let’s go to a more complex example.” [Livebloggers: wave the white flag]
The title of the current slide is “More Fun with Tracking Parameters”. I think Stephan forgot the ironic quotes around “fun”.
Compile your text files into a DBM file then make that a script. I don’t know what that means but apparently it’s faster.
Don’t daisy-chain 301s.
Don’t do conditional redirects. Matt Cutts will yell at you. Stephan has an article about it on Search Engine Land called Redirects: Good, Bad & Conditional. [This conflicts with Carolyn’s advice from earlier.]
Now that Stephan has completely confused us, it’s Jordan Kasteler who had to be peeled away from the bar to be here. Alex says that we should write the slurs when we hear them. No way, that takes more work.
He’s covering 301s from a social media point of view. Michael Gray posted about this on Search Engine Land.
Digg hates SEOs. Therefore submit on sites that are non-commercial, not SEO. After the hype is over, 301 to your real site.
301 from internal informational pages to product pages. [Shady, shady, shady.]
White hat version: Use a multi-story strategy and then make it all one page and 301 all the stories to one page. Each will get links that will then be consolidated.
Choose your hooks wisely. Some hooks build links over time and you don’t want to redirect those. Resource hooks build links for a long time. Instead, add internal links to pass link equity around.
Some link value can be lost in 301 redirects. Do NOT redirect to your home page — from what some have seen, Google doesn’t pass anchor text when it’s redirected to the home page.
Use your keywords in your page and social submission titles because that’s what they’ll use to link back.
Consolidate to one canonical URL structure.
You can follow his twitter @UtahSEOPro.
Jonah Stein will restore order to these proceedings. He’s going to tell us why 301s aren’t always the answer.
Back in the day, the spammy option was the Meta refresh, then the JavaScript versions and so on.
Eventually duplicate content became a bad thing (back in 2005) and then in 2006 canonicalization showed up on the scene after the BigDaddy update.
What are your other redirect options: 302, 303, 307.
Most people have heard of the 302 because of hijacking, but there are legit uses.
Vanity URLs don’t need to be 301 redirected. If it’s shorter, that might be the better choice so go ahead and use the 302.
Geo-detection is a good use for a 302.
Rapidly changing offers are good candidates for 302s as well. The base page will accumulate link equity while the offers change.
You can bring a microsite back into the fold with a 302.
If you want to create search friendly URLs and you can’t get around your company roadblocks, create new URLs with better URLs and 302 them.
Http vs https: Avoid canonical confusion when the payer or application is moved to the https layer. Users are unlikely to link to the https.
Third-party shopping carts can be masked this way.
Pretty affiliate links! But be careful and open about this.
307 is the mythical beast. It’s not often seen in the wild. It’s almost like the 302 but not. 302 uses a 303 get method but the 307 uses a post method. [I don’t know what that means.]
Q&A
Does page rank really transfer with 301 redirects?
Stephan: This needs to be qualified. PageRank in the toolbar is almost a random number generator. It means nothing. If your rankings dropped, that’s something to be concerned about.
Jordan: You don’t need to change the extension. You can [do something technical].
Jonah: It could have been that you changed your page, not that you moved it.
Isn’t 301ing against Digg’s terms of use?
Jordan: Yes.
Does the home page being linked with and without the slash count as canonical?
Stephan: They’re the same URL.
Jonah: It’ll just be recorded differently in the analytics.
Is there a place to test rewrites before we go live with them?
Stephan: I use a dev site.
And we’re done.